Port gcc-dg tests from GCC, continued #72
Conversation
common parts between C/gcc-c-torture/CMakeLists.txt and the new C/gcc-dg/CMakeLists.txt are put in DgOptions.txt
|
I'll test it once I have time next week. Thanks. |
|
I am getting error when compiling RFC of DFP: https://discourse.llvm.org/t/rfc-decimal-floating-point-support-iso-iec-ts-18661-2-and-c23/62152 |
Yes, I've removed the test from the list. I've turned off Also turned off I've "fixed" two tests, Currently investigating a newly found compiler crash that didn't happen before: |
|
Sorry, not |
|
Hi all, quick update: I managed to bisect the crash down to The particular line in question that clang trips over is unsigned _BitInt(575) h = 123665200736552267030251260509823595017565674550605919957031528046448612553265933585158200530621522494798835713008069669675682517153375604983773077550946583958303386074349567uwb;If we change it to |
|
Hi all, current status is theres 5 failing runtime tests, with 1 that hangs ( I am currently looking into these |
The `pr89313.c` and `pr87600-1.c` tests were passing fine on LLVM trunk (specifically I was on `c1eef483b2c1`), but failed on 17.0.5. I bisected the failure down to the following LLVM commit: d79ccee8dc4a [X86][MC] Support encoding/decoding for APX variant ADD/SUB/ADC/SBB/OR/XOR/NEG/NOT instructions (#76319) So it turns out that the three-operand form of `add`, on x86_64, is actually a very recent addition. We should therefore probably avoid using it incase someone wants to run against an older but still recent LLVM version.
RISC-V does not support the __bf16 datatype, therefore disable test.
|
Theres currently 2 (well, technically 3) non-working tests:
These two pass on |
|
Somehow I am getting compile error on And my gcc is which is built on RHEL8 Could you please tell me your configuration? Thanks! |
|
Hi @jerryzj, TL;DR: I think you need to pass the
which seems to imply that with or without 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 (P.S. Invoking the compilation with 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. |
|
Quick update regarding the 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 |
|
Current latest results for x86_64: 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? |
by adding However, I still getting clang compiler error, it seems that clang 17.0.4 is not supporting |
@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 |
|
Hi all,
@jerryzj I also get warnings about
I think this would be good, as its not completely straightforward. Clang quite happily accepts We could write a separate CMake function that manually checks if we can actually compile a C program with the |
|
ping |
1 similar comment
|
ping |
|
Sorry that I was on vacation. |
|
ping |
I am not able to compile this on my M1 Mac, I suppose that we should remove it for AArch64. |
|
There are total 703 tests added when I run |
|
It seems that ther are sth. wrong, |
GCC has the notion of "default test behaviour", which is stored in the
`dg-do-what-default` global variable. It specified what should happen
when there is no `dg-do` comment found in the test suite.
Our current behaviour is that if there's no `dg-do`, then we just
compile the test. But for the `gcc.c-torture/execute` directory, the
default behaviour is to run the test, because the `execute.exp` script
manaully sets it so:
```
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}
```
We should probably model this behaviour in our CMake scripts, but for
now undo the refactoring in the execute/CMakeLists.txt script, and for
tests in that particular directory we always try to run the file.
@jerryzj I had a look, and I think what happened is as follows: Commit However in the GCC from here: I've added a commit to bring back the original code in The |
In the GCC test suite many tests don't have an explicit `dg-do` directive telling the test driver what to do. In these cases, the default action is taken from a TCL variable called `dg-do-what-default`, which can be set freely (see for example gcc/testsuite/gcc.c-torture/execute/execute.exp) Emulate this behaviour in our CMakeScripts also.
|
Updated to fix the 19 test failures under Current results for Native x86_64: RISC-V QEMU: |
|
ping |
1 similar comment
|
ping |
|
ping P.S. I've created an additional MR based on this work to import the |
|
@mablinov Sorry for being quite busy recently. I will find time to check again next week. Thank you. |
|
ping |
4 similar comments
|
ping |
|
ping |
|
ping |
|
ping |
Hi all,
I've been asked internally to pick up the work done by Mohammed in a previous MR. I don't have access to Mohammed's branch, so I've copied his branch over to my repo and continued my work from that point onwards.
If this isn't the right workflow, please let me know.
@jerryzj
I had a closer look at these tests, and found out that they are infact currently totally unused within GCC. The specific tests in question are:
atomic-compare-exchange-5.catomic-load-5.catomic-store-5.catomic-store-6.catomic-op-5.cThey are specified with
/* { dg-require-effective-target sync_int_128_runtime } */However, in 2019 the only target that supported
sync_int_128_runtimewas removed:2f2aeda98f3("Remove Cell Broadband Engine SPU targets"): From the patch,proc check_effective_target_sync_int_128_runtime { } { - if { [istarget spu-*-*] } { - return 1 - } else { - return 0 - } + return 0 }In other words, GCC will currently skip these tests under all conditions.
One can verify that upstream GCC for x86_64 indeed skips these tests:
I've therefore added these 5 to
UnsupportedTests, to avoid clutteringcflagswith-latomic.There are also some compiler "crashes" due to the use of
-fsplit-stack: I get the error (and backtrace):The tests in question are:
split-6.csplit-3.cpr85388-5.cpr85388-3.cGlancing at the LLVM source code, it seems like the only backends that complain about this are X86 and ARM, so I disabled them from running on those specific platforms.
There are still a couple of issues that I see, for example
pr87600-1.c, which is a compile-only (no assembly) tests:This is fine in GCC, since it is only interested in the argument substitution, but clang will actually check the instruction name, even if we're building with
-S. So these will need to be turned into real instructions, etc. I will post some more commits for these issues.