llvm-iwg Do we want to have IWG office hours?

From IWG meeting on 2022-02-01:

Do we want to offer office hours get community input and listen to their concerns?

The idea would be to offer a communication channel beyond written communication where folks can reach out and discuss infrastructure issues.

Feb 02 '22 09:02 ChristianKuehnel

I'll test it once I have time next week. Thanks.

Jan 05 '24 11:01 jerryzj

I am getting error when compiling bitint-10.c and it appears that llvm doesn't have DFP support for now. I guess we should disable the test for now?

RFC of DFP: https://discourse.llvm.org/t/rfc-decimal-floating-point-support-iso-iec-ts-18661-2-and-c23/62152

/tools/clang/17.0.4/bin/clang -DNDEBUG  -O3   -w -Werror=date-time -w -Wno-implicit-function-declaration -Wno-implicit-int -Wno-int-conversion -O2 -std=gnu2x -pedantic-errors -MD -MT SingleSource/Regression/C/gcc-dg/CMakeFiles/GCC-DG_bitint-10.dir/bitint-10.c.o -MF SingleSource/Regression/C/gcc-dg/CMakeFiles/GCC-DG_bitint-10.dir/bitint-10.c.o.d -o SingleSource/Regression/C/gcc-dg/CMakeFiles/GCC-DG_bitint-10.dir/bitint-10.c.o -c /scratch/llvm-test-suite/SingleSource/Regression/C/gcc-dg/bitint-10.c
/scratch/llvm-test-suite/SingleSource/Regression/C/gcc-dg/bitint-10.c:7:23: error: GNU decimal type extension not supported
    7 | foo (_BitInt(129) *x, _Decimal64 *y)
      |                       ^
1 error generated.

Jan 08 '24 06:01 jerryzj

I am getting error when compiling bitint-10.c and it appears that llvm doesn't have DFP support for now. I guess we should disable the test for now?

Yes, I've removed the test from the list. pr57104.c and pr34351.c are also removed for trying to declare global register variables.

I've turned off pr57104.c for trying to use the p constraint, which doesn't appear to exist in LLVM (doxygen link).

Also turned off pr43564.c: Judging from the commit that introduced this test we seem to be testing correct preservation of per-function optimisation level. But since its not target-specific, theres no way to make the inline asm work for all possible backends.

I've "fixed" two tests, pr87600-1.c and pr89313.c, by making it so the asm part of the inline asm is a syntactically actual legal (but nonsensical) assembly instruction. However, this makes them different from upstream, so I'm not sure if perhaps it would be better to just turn them off altogether? Or try contributing the changes upstream to GCC?

Currently investigating a newly found compiler crash that didn't happen before: bitint-10.c currently crashes on 1ea7a56057492d9da1124787a9855cc2edca7df9, but not on llvmorg-17.0.1, currently working on bisecting it.

Jan 09 '24 09:01 mablinov

Sorry, not bitint-10.c - I meant, bitint-3.c

Jan 09 '24 09:01 mablinov

Hi all, quick update: I managed to bisect the crash down to a21abc782a8e ("[X86] Align i128 to 16 bytes in x86 datalayouts"), which seems to already have some issues open against it (e.g. https://github.com/llvm/llvm-project/issues/60925.)

The particular line in question that clang trips over is SingleSource/Regression/C/gcc-dg/bitint-3.c:37:

unsigned _BitInt(575) h = 123665200736552267030251260509823595017565674550605919957031528046448612553265933585158200530621522494798835713008069669675682517153375604983773077550946583958303386074349567uwb;

If we change it to _BitInt(128) then it compiles fine. Nudging it up to _BitInt(129) also crashes the compiler.

Jan 09 '24 17:01 mablinov

Hi all, current status is theres 5 failing runtime tests, with 1 that hangs (setjmp-4)

FAIL: test-suite :: SingleSource/Regression/C/gcc-dg/GCC-DG_setjmp-4.test (711 of 711)
  interrupted by user, skipping remaining tests
********************
Failed Tests (5):
  test-suite :: SingleSource/Regression/C/gcc-dg/GCC-DG_attr-ms_struct-1.test
  test-suite :: SingleSource/Regression/C/gcc-dg/GCC-DG_attr-ms_struct-2.test
  test-suite :: SingleSource/Regression/C/gcc-dg/GCC-DG_bf-spl1.test
  test-suite :: SingleSource/Regression/C/gcc-dg/GCC-DG_cwsc1.test
  test-suite :: SingleSource/Regression/C/gcc-dg/GCC-DG_setjmp-3.test


Testing Time: 67.98s

Total Discovered Tests: 711
  Skipped: 170 (23.91%)
  Passed : 536 (75.39%)
  Failed :   5 (0.70%)

I am currently looking into these

Jan 15 '24 17:01 mablinov

Theres currently 2 (well, technically 3) non-working tests:

/home/swtoolsteam/mabi/prj/gcc-dg/test-suite/SingleSource/Regression/C/gcc-dg/stdckdint-1.c This currently on 17.0.5 since its not available in that version of Clang, but will pass on head of trunk. The commit that adds the stdckdint.h system header is 3694697003bb [clang] Implement C23 <stdckdint.h>, so I will leave this test failure as-is since it should be fixed in Clang 18.
SingleSource/Regression/C/gcc-dg/GCC-DG_setjmp-4.test
SingleSource/Regression/C/gcc-dg/GCC-DG_setjmp-3.test

These two pass on -O0 but not on anything higher, so it does look like a bug of some kind. We try to jump through a register which is set to garbage in non--O0 cases.

Jan 23 '24 09:01 mablinov

Somehow I am getting compile error on SingleSource/Regression/C/gcc-dg/loop-2.c

gcc -O0 ../SingleSource/Regression/C/gcc-dg/loop-2.c
/tmp/ccDf6fYM.o: In function `main':
loop-2.c:(.text+0x25): undefined reference to `tag'
collect2: error: ld returned 1 exit status

And my gcc is which is built on RHEL8

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/tools/gcc/gcc/13.2.0/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/tools/gcc/gcc/13.2.0 --enable-gold --enable-lto
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (GCC)

Could you please tell me your configuration? Thanks!

Jan 24 '24 01:01 jerryzj

Hi @jerryzj,

TL;DR: I think you need to pass the -ansi flag. I still don't quite understand this behaviour, the GCC docs on -ansi mention that

The alternate keywords __asm__, __extension__, __inline__ and __typeof__ continue to work despite -ansi.

which seems to imply that with or without -ansi, __inline__ should do the same thing, but here it clearly doesn't.

I scraped the flag from inovking the test suite directly, which works:

$ make check-gcc-c RUNTESTFLAGS="dg.exp=loop-2.c"

...

                === gcc Summary ===

# of expected passes            2
/home/maxim/prj/gcc/build/gcc/xgcc  version 14.0.0 20240108 (experimental) (GCC)

the gcc.log shows the invocation was:

/home/maxim/prj/gcc/build/gcc/xgcc -B/home/maxim/prj/gcc/build/gcc/ /home/maxim/prj/gcc/gcc/gcc/tests
uite/gcc.dg/loop-2.c    -fdiagnostics-plain-output    -ansi -pedantic-errors  -lm  -o ./loop-2.exe

(P.S. Invoking the compilation with -v doesn't yield any differences - I can't find any "hidden" flags that GCC is passing as a function of the presence of -ansi.)

I get this result for both of my installed GCCs: The Ubuntu 22.04 system version 11.4.0, and a locally-built head of trunk.

Jan 25 '24 09:01 mablinov

Quick update regarding the setjmp-3.c/setjmp-4.c tests that were failing:

I've had a discussion internally about it, and we've concluded that its probably not a bug. Theres another relevant discussion about this on the LLVM forums here, where if I understand it correctly, the general attitude is that if you want to re-read variables after longjmping back, the expectation is that you will mark them volatile.

Jan 26 '24 10:01 mablinov

Current latest results for x86_64:

Executable Missing Tests (1):
  test-suite :: SingleSource/Regression/C/gcc-dg/GCC-DG_stdckdint-1.test


Testing Time: 17.98s
  Passed            : 702
  Executable Missing:   1

I would prefer not to disable this test, because it should start passing on Clang 18 (17.0.5 doesn't implement C23.)

Jan 26 '24 10:01 mablinov

I would prefer not to disable this test, because it should start passing on Clang 18 (17.0.5 doesn't implement C23.)

Would it be possible to check in cmake if the compiler supports C23 and if not disable the test?

Jan 26 '24 10:01 fhahn

which seems to imply that with or without -ansi, inline should do the same thing, but here it clearly doesn't. I scraped the flag from inovking the test suite directly, which works:

by adding -ansi works on my end (gcc 13.2.0 x86)

However, I still getting clang compiler error, it seems that clang 17.0.4 is not supporting -pie ?!

FAILED: SingleSource/Regression/C/gcc-dg/GCC-DG_pie-static-1
: && /home/jzhangjian/scratch/llvm-test-suite/build/tools/timeit --summary SingleSource/Regression/C/gcc-dg/GCC-DG_pie-static-1.link.time /sifive/tools/clang/17.0.4/bin/clang -O3  SingleSource/Regression/C/gcc-dg/CMakeFiles/GCC-DG_pie-static-1.dir/pie-static-1.c.o -o SingleSource/Regression/C/gcc-dg/GCC-DG_pie-static-1  -static -fpie -pie && cd /home/jzhangjian/scratch/llvm-test-suite/build/SingleSource/Regression/C/gcc-dg && /sifive/tools/clang/17.0.4/bin/llvm-size --format=sysv /home/jzhangjian/scratch/llvm-test-suite/build/SingleSource/Regression/C/gcc-dg/GCC-DG_pie-static-1 > /home/jzhangjian/scratch/llvm-test-suite/build/SingleSource/Regression/C/gcc-dg/GCC-DG_pie-static-1.size
clang: warning: argument unused during compilation: '-pie' [-Wunused-command-line-argument]
/usr/bin/ld: cannot find -lc
clang: error: linker command failed with exit code 1 (use -v to see invocation)
[2095/4867] Linking C executable SingleSource/Regression/C/gcc-dg/GCC-DG_pie-static-2
FAILED: SingleSource/Regression/C/gcc-dg/GCC-DG_pie-static-2
: && /home/jzhangjian/scratch/llvm-test-suite/build/tools/timeit --summary SingleSource/Regression/C/gcc-dg/GCC-DG_pie-static-2.link.time /sifive/tools/clang/17.0.4/bin/clang -O3  SingleSource/Regression/C/gcc-dg/CMakeFiles/GCC-DG_pie-static-2.dir/pie-static-2.c.o -o SingleSource/Regression/C/gcc-dg/GCC-DG_pie-static-2  -fpie -pie -static && cd /home/jzhangjian/scratch/llvm-test-suite/build/SingleSource/Regression/C/gcc-dg && /sifive/tools/clang/17.0.4/bin/llvm-size --format=sysv /home/jzhangjian/scratch/llvm-test-suite/build/SingleSource/Regression/C/gcc-dg/GCC-DG_pie-static-2 > /home/jzhangjian/scratch/llvm-test-suite/build/SingleSource/Regression/C/gcc-dg/GCC-DG_pie-static-2.size
clang: warning: argument unused during compilation: '-pie' [-Wunused-command-line-argument]
/usr/bin/ld: cannot find -lc
clang: error: linker command failed with exit code 1 (use -v to see invocation)
[2255/4867] Building C object SingleSource/Regression/C/gcc-dg/CMakeFiles/GCC-DG_c11-atomic-2.dir/c11-atomic-2.c.o
ninja: build stopped: subcommand failed.

Jan 29 '24 05:01 jerryzj

I would prefer not to disable this test, because it should start passing on Clang 18 (17.0.5 doesn't implement C23.)

Would it be possible to check in cmake if the compiler supports C23 and if not disable the test?

@fhahn I suppose there is a way to achieve this, like this page mentioned: https://stackoverflow.com/questions/10984442/how-to-detect-c11-support-of-a-compiler-with-cmake I think we can handle that in another PR?

Jan 29 '24 05:01 jerryzj

Hi all,

FAILED: SingleSource/Regression/C/gcc-dg/GCC-DG_pie-static-1 : && /home/jzhangjian/scratch/llvm-test-suite/build/tools/timeit --summary SingleSource/Regression/C/gcc-dg/GCC-DG_pie-static-1.link.time /sifive/tools/clang/17.0.4/bin/clang -O3 SingleSource/Regression/C/gcc-dg/CMakeFiles/GCC-DG_pie-static-1.dir/pie-static-1.c.o -o SingleSource/Regression/C/gcc-dg/GCC-DG_pie-static-1 -static -fpie -pie && cd /home/jzhangjian/scratch/llvm-test-suite/build/SingleSource/Regression/C/gcc-dg && /sifive/tools/clang/17.0.4/bin/llvm-size --format=sysv /home/jzhangjian/scratch/llvm-test-suite/build/SingleSource/Regression/C/gcc-dg/GCC-DG_pie-static-1 > /home/jzhangjian/scratch/llvm-test-suite/build/SingleSource/Regression/C/gcc-dg/GCC-DG_pie-static-1.size clang: warning: argument unused during compilation: '-pie' [-Wunused-command-line-argument] /usr/bin/ld: cannot find -lc

@jerryzj I also get warnings about -pie being unused, but i think in your case it can't find the C library - I think this might be an issue with the sifive toolchain perhaps? I haven't tried the sifive toolchain myself, but the upstream Clang 17.0.4 for x86_64 seems to link on my end for this particular test.

@jerryzj @fhahn

I think we can handle that in another PR?

I think this would be good, as its not completely straightforward. Clang quite happily accepts -std=c2x even though we don't implement the stdckdint.h header, and although using CMake to require a particular C standard for a target might work, the C23 definition was only added in CMake 3.21 whereas llvm-test-suite uses 3.13.4.

We could write a separate CMake function that manually checks if we can actually compile a C program with the stdckdint.h header included, sets a variable if we can't compile it, and conditionally add the source files in the filter list - how does that approach sound? It is a lot of work for only two tests though...

Jan 30 '24 10:01 mablinov

ping

Feb 05 '24 18:02 mablinov

ping

Feb 15 '24 09:02 mablinov

Sorry that I was on vacation. I will check this next week if I have time…

Feb 15 '24 10:02 jerryzj

ping

Feb 26 '24 14:02 mablinov

FAILED: SingleSource/Regression/C/gcc-dg/CMakeFiles/GCC-DG_20020103-1.dir/20020103-1.c.o
/Users/jerry/snippet/llvm-test-suite/build/tools/timeit --summary SingleSource/Regression/C/gcc-dg/CMakeFiles/GCC-DG_20020103-1.dir/20020103-1.c.o.time /opt/homebrew/opt/ccache/libexec/cc -DNDEBUG  -O3 -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk   -w -Werror=date-time -w -Wno-implicit-function-declaration -Wno-implicit-int -Wno-int-conversion -O2 -fpic -fno-omit-frame-pointer -fno-asynchronous-unwind-tables -MD -MT SingleSource/Regression/C/gcc-dg/CMakeFiles/GCC-DG_20020103-1.dir/20020103-1.c.o -MF SingleSource/Regression/C/gcc-dg/CMakeFiles/GCC-DG_20020103-1.dir/20020103-1.c.o.d -o SingleSource/Regression/C/gcc-dg/CMakeFiles/GCC-DG_20020103-1.dir/20020103-1.c.o -c /Users/jerry/snippet/llvm-test-suite/SingleSource/Regression/C/gcc-dg/20020103-1.c
/Users/jerry/snippet/llvm-test-suite/SingleSource/Regression/C/gcc-dg/20020103-1.c:24:2: error: no clobber macro defined
#error no clobber macro defined
 ^
/Users/jerry/snippet/llvm-test-suite/SingleSource/Regression/C/gcc-dg/20020103-1.c:37:3: error: use of undeclared identifier 'clobber'
  clobber;
  ^

I am not able to compile this on my M1 Mac, I suppose that we should remove it for AArch64. @fhahn could you help to check on this? Thanks.

Feb 26 '24 14:02 jerryzj

There are total 703 tests added when I run lit /SingleSource/Regression/C/gcc-dg/, I don't understand why there are 5000+ files changed...?

Feb 26 '24 15:02 jerryzj

It seems that ther are sth. wrong, lit -v -j 32 -o results.json ./SingleSource/Regression/C/gcc-c-torture/ show 2 test cases, this is not right.

Feb 26 '24 15:02 jerryzj

It seems that ther are sth. wrong, lit -v -j 32 -o results.json ./SingleSource/Regression/C/gcc-c-torture/ show 2 test cases, this is not right.

@jerryzj I had a look, and I think what happened is as follows:

Commit a400a7fc8 factored-out the test-adding logic from gcc-c-torture/execute/CMakeLists.txt to a common file SingleSource/Regression/DgOptions.txt, however in doing so also changed how it worked: The default "behaviour" went from always running the test, to parsing the dg-do directive and skipping the test if the directive is missing.

However in the GCC gcc.c-torture/execute directory, almost all of the tests are missing a dg-do directive: This is because in upstream execute.exp, we manually set the dg-do-what-default variable to run the test by default (when the dg-do directive is missing):

from here:

set saved-dg-do-what-default ${dg-do-what-default}
set dg-do-what-default "run"
gcc-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.\[cS\]]] "" "-w"
set dg-do-what-default ${saved-dg-do-what-default}

I've added a commit to bring back the original code in gcc-c-torture/execute/CMakeLists.txt, and now see 1432 tests under the gcc-c-torture/execute directory.

The llvm-lit results for it after my last commit:

Executable Missing Tests (19):
  test-suite :: SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-pr78438.test
  test-suite :: SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-pr78726.test
  test-suite :: SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-pr79354.test
  test-suite :: SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-pr79737-2.test
  test-suite :: SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-pr80421.test
  test-suite :: SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-pr82524.test
  test-suite :: SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-pr82954.test
  test-suite :: SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-pr84478.test
  test-suite :: SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-pr84524.test
  test-suite :: SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-pr85156.test
  test-suite :: SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-pr85756.test
  test-suite :: SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-pr88904.test
  test-suite :: SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-pr89434.test
  test-suite :: SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-simd-4.test
  test-suite :: SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-stdarg-1.test
  test-suite :: SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-stdarg-4.test
  test-suite :: SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-stkalign.test
  test-suite :: SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-va-arg-14.test
  test-suite :: SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-va-arg-22.test


Testing Time: 33.36s
  Passed            : 1412
  Executable Missing:   19

Mar 01 '24 09:03 mablinov

Updated to fix the 19 test failures under SingleSource/Regression/C/gcc-c-torture, the bug was that CFLAGS were not being reset between invocations.

Current results for -DTEST_SUITE_SUBDIRS='SingleSource/Regression/C/gcc-c-torture':

Native x86_64:

Testing Time: 34.21s
  Passed: 1431

RISC-V QEMU:

Testing Time: 19.68s
  Passed: 1428

Mar 08 '24 09:03 mablinov

ping

Mar 19 '24 09:03 mablinov

ping

Mar 25 '24 10:03 mablinov

ping

P.S. I've created an additional MR based on this work to import the gcc-dg/vect subdirectory from upstream gcc here, reviews appreciated

Apr 08 '24 09:04 mablinov

@jerryzj @fhahn @asb Hi all, just wondering if another review would be possible in the near future?

Apr 11 '24 08:04 mablinov

@mablinov Sorry for being quite busy recently. I will find time to check again next week. Thank you.

Apr 18 '24 05:04 jerryzj

ping

May 02 '24 11:05 mablinov

llvm-iwg llvm-iwg copied to clipboard

Do we want to have IWG office hours?

llvm-iwg
llvm-iwg copied to clipboard