User Details
- User Since
- Jul 1 2016, 4:12 AM (352 w, 1 d)
Mon, Mar 27
Fri, Mar 24
Even with this patch, the ScopedPrinterTest.PrintNumber test still FAILs on Solaris:
/vol/llvm/src/llvm-project/dist/llvm/unittests/Support/ScopedPrinterTest.cpp:91: Failure Expected equality of these values: [...] With diff: @@ -23,5 +23,5 @@ \"float-max\": 3.4028234663852886e+38, \"float-min\": 1.1754943508222875e-38, - \"float-inf\": inf, + \"float-inf\": infinity, \"float-nan\": nan, \"float-42.0\": 42, @@ -29,5 +29,5 @@ \"double-max\": 1.7976931348623157e+308, \"double-min\": 2.2250738585072014e-308, - \"double-inf\": inf, + \"double-inf\": infinity, \"double-nan\": nan, \"double-42.0\": 42,
Wed, Mar 22
LGTM, thanks.
Feb 22 2023
- You still haven't mentioned which target is affected.
- There needs to be a comment explaining why _TIME_BITS is #undefed.
- Please pass the patch through clang-format-diff.py: there's a TAB before !defined which should just be a blank.
Feb 21 2023
Please state what target the problem occurs on and how/where the patch was tested. _TIME_BITS doesn't exist on Solaris 11.4 and, AFAICS, neither on Illumos.
Feb 6 2023
Feb 3 2023
I forgot: this is certainly something that should go onto the release/16.x branch ASAP.
Jan 17 2023
Ping? It's been a week. Thanks.
Jan 13 2023
The patch is no longer crucial: since third-party/benchmark doesn't build with -Werror anymore, so there are just warnings left. Besides, the patch is now upstream, so whenever someone imports the current version into LLVM, even those will be gone.
Jan 12 2023
Jan 10 2023
Dec 22 2022
I just ran 2-stage builds on sparcv9-sun-solaris2.11 (with both gcc 12.2.0 and clang 15.0.0 in stage 1) : the builds completed successfully and
test results are back to what they were about a month ago (with two unrelated issues). Thanks.
Dec 21 2022
This patch broke Solaris/sparcv9 bootstrap. Details in Issue #59646.
Dec 13 2022
I got distracted after returning from vacation, but I'll reland the patch shortly after retesting on x86_64-pc-linux-gnu.
Dec 7 2022
For good measure tested on sparcv9-sun-solaris2.11, amd64-pc-solaris2.11, and x86_64-pc-linux-gnu.
Dec 6 2022
As usual, it's complicated ;-)
Nov 30 2022
Nov 24 2022
This introduced a new failure on Solaris:
FAIL: Flang :: Driver/pass-plugin-not-found.f90
Running the failing command manually shows:
error: unable to load plugin 'X.Y': 'Could not load library 'X.Y': ld.so.1: flang-new: X.Y: open failed: No such file or directory'
while the test currently expects
error: unable to load plugin 'X.Y': 'Could not load library 'X.Y': X.Y: cannot open shared object file: No such file or directory'
This expectation is unjustified, I believe: the message is produced by PassPlugin::Load -> sys::DynamicLibrary::getPermanentLibrary -> HandleSet::DLOpen -> ::dlerror. Obviously the output of the last is system-dependent; I don't think we can put any requirements on it (maybe not even the exact wording of the No such file or directory part.
Oct 31 2022
Oct 24 2022
Ping? It's been 2 1/2 weeks...
Oct 14 2022
Disable subtests of tsan/tests/unit/tsan_trace_test.cpp that deadlock with SANITIZER_DEBUG.
Oct 6 2022
I'd be grateful if the owners of the affected builders could retest the patch before relanding, preferably in Release and Debug/COMPILER_RT_DEBUG builds. Thanks a lot.
- Use string(APPEND) for COMPILER_RT_TEST_COMPILER_CFLAGS.
- Omit -O3 from COMPILER_RT_TEST_COMPILER_CFLAGS in non-debug builds for now.
- Provide __sanitizer::integral_constant<bool, true>::value instantiation.
- XFAIL tsan/Linux/check_memcpy.c in debug builds.
I think I've figured out what's wrong. AFAICS there are three separate issues:
Oct 5 2022
[...]
The -O3;-g on the link line seems to come from compiler-rt/test/lit.common.configured. I suspect that can be traced down to code in compiler-rt/CMakeLists.txt which replaces " " by ";" in COMPILER_RT_TEST_COMPILER_CFLAGS. I don't really understand this and it seems terribly fragile to me, but I believe this can be avoided by prepending the new instances of setting COMPILER_RT_TEST_COMPILER_CFLAGS in compiler-rt/CMakeLists.txt with a blank. I have a patch for that and am trying to test it, but as mentioned the issue hasn't affected me. @uweigand may be able to help.
I don't see anything particularly special to s390x here, with the only exception of -mbackchain. This flag is added to sanitizer tests on s390x, where we need it for the same reason other platforms tend to need -fno-omit-frame-pointer. It's unclear how that would be related to this ";" issue.
This seems to cause another regression, apparently only visible in cross builds: clang-s390x-linux buildbot: a link failure like this:
******************** TEST 'AddressSanitizer-s390x-linux :: TestCases/Linux/init-order-dlopen.cpp' FAILED ******************** Script: [...]
This patch caused a regression on the sanitizer-x86_64-linux-autoconf buildbot running a debug build:
ThreadSanitizer-x86_64 :: Linux/check_memcpy.c
The executable now contains calls to memset. AFAICS this is a consequence of changing debug builds from -O1 to -O0 and thus is expected. Therefore I suggest to just add
XFAIL: !compiler-rt-optimized
Unfortunately I missed this in my local builds: I had run Debug builds on x86_64-pc-linux-gnu both with a vanilla tree and my patch, but already the vanilla results were insanely bad (309 FAILs), so I didn't notice the regression.
Oct 4 2022
- Update COMPILER_RT_UNITTEST_CFLAGS as requested.
- Change SANITIZER_COMMON_CFLAGS to -O0 for COMPILER_RT_DEBUG, cannot reliably debug with optimization.
- compiler-rt/lib/sanitizer_common/tests/sanitizer_type_traits_test.cpp tests SanitizerCommon.IsTriviallyDestructible and SanitizerCommon.IsTriviallyCopyable fail to link with debug build:
FAILED: projects/compiler-rt/lib/sanitizer_common/tests/Sanitizer-i386-Test [...] Undefined first referenced symbol in file _ZN11__sanitizer17integral_constantIbLb1EE5valueE SANITIZER_TEST_OBJECTS.sanitizer_type_traits_test.cpp.i386.o ld: fatal: symbol referencing errors
Maybe one can provide a definition of `__sanitizer::integral_constant<bool, true>::value`?
Oct 3 2022
Given that there were no comments from the SPARC reviewers in more than a week, I've now committed the patch as is.
Sep 27 2022
Never use RLIMIT_RSS on Apple systems.
Run test on Linux/sparc64, too.
[...]
Not sure what the issue is there. I'm actually a bit surprised that it works for i386. When I tried to enable flang for armv7, MLIR didn't have very good support for 32-bit platforms, so I left it at that. If you know that users of 32-bit sparc really have a great need for a Fortran compiler, then feel free to investigate further, but I'm not sure how many other 32-bit platforms have an interest in flang/mlir, so maintaining it might turn out to be a non-trivial amount of work.
Sep 23 2022
No worries: I could easily keep the patch local to gcc for a while, and LLVM isn't affected anyway (apart from the staging buildmaster being down for more than a week).
Sep 22 2022
Add testcase.
Sep 20 2022
Ping? It's been a weed and a half.
Sep 13 2022
Sep 12 2022
Sep 11 2022
Sep 10 2022
Sep 9 2022
Add comment, tests.
Sep 8 2022
Sure, done: Issue #57626.
Sep 7 2022
Aug 26 2022
Aug 22 2022
Aug 19 2022
I've looked around some more and it seems the Solaris libm acts within the C standard: all of C99, p.219, C11, p.239, and C17, p.147 state
A domain error may occur if both arguments are zero.
I've also found the atan2 docs on cppreference.com which says the same, adding
If the implementation supports IEEE floating-point arithmetic (IEC 60559),
Retested on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu.
Aug 18 2022
The llvm/test/Transforms/EarlyCSE/atan.ll test FAILs on Solaris (both sparcv9 and amd64):
/vol/llvm/src/llvm-project/local/llvm/test/Transforms/EarlyCSE/atan.ll:55:15: error: CHECK-NEXT: expected string not found in input ; CHECK-NEXT: ret float -0.000000e+00 ^
Comparing to the Linux/x86_64 version of the output, the only difference is
--- /homes/ro/atan.ll.x86_64 2022-08-18 12:38:48.313115000 +0200 +++ /homes/ro/atan.ll.sparcv9 2022-08-18 11:50:22.976866000 +0200 @@ -25,7 +25,8 @@ }