User Details
- User Since
- Aug 7 2017, 9:53 PM (256 w, 16 h)
Thu, Jun 9
I uploaded D127465, weakening the test.
This change is needed to keep the clang/test/Preprocessor/cuda-types.cu test passing after D28213 changes the value of __CLANG_ATOMIC_LLONG_LOCK_FREE from 1 to 2 for i586 and up.
Ok, I can upload a patch omitting *_ATOMIC_LLONG_LOCK_FREE from the macro testing.
Wed, Jun 8
I don't expect this change to affect the compiler behavior by itself -- is there a particular test that should be written?
Tue, Jun 7
This change is needed for D28213, so that the __GCC_ATOMIC_LLONG_LOCK_FREE macro matches for -target i386-unknown-linux-gnu between --cuda-host-only and --cuda-device-only. This is tested in clang/test/Preprocessor/cuda-types.cu.
Rebase this revision.
May 26 2022
May 25 2022
The fix and the test both look good to me.
May 23 2022
I'm seeing this test fail on 32-bit x86 Linux currently because __CLANG_ATOMIC_LLONG_LOCK_FREE is still 1.
Maybe this change is obsolete now that D59566 is merged?
May 2 2022
Apr 29 2022
Apr 28 2022
Apr 26 2022
Apr 12 2022
I think this change broke libc++ tests. _executeScriptInternal in libcxx/utils/libcxx/test/dsl.py does not pass an argument for LitConfig's new order parameter:
Apr 11 2022
... that's still subject to time-of-check-to-time-of-use issues
Apr 5 2022
Mar 28 2022
Suggested issue title: [libcxx] locale_bionic.h: skip ndk-version.h on Android platform
Mar 14 2022
Mar 10 2022
Mar 4 2022
Mar 3 2022
Mar 2 2022
Yeah, I'm OK with this change. (I'm not really familiar with the MTE stuff.)
Dec 7 2021
Dec 6 2021
... but it seems much easier to put the -fno-outline-atomics flag into the linker's .bp file instead of changing the behavior of __system_property_get.
Dec 1 2021
Nov 29 2021
Also: is it OK to use a mix of LSE and non-LSE atomic operations to access the same memory concurrently? I would think that should be fine, but it seems worth mentioning.
I noticed that using __system_property_get from a constructor function probably doesn't work within the Bionic loader (linker[64]), but maybe Bionic ought to be fixed (and it shouldn't matter much in practice):
- The Bionic dynamic loader calls the constructor functions before calling __system_properties_init. (see tmp_linker_so.call_constructors();)
- However, a static executable calls __system_properties_init before the constructors, so static executables should be OK.
- Maybe the dynamic loader ought to call __system_properties_init before constructors.
- Calling __system_property_get before __system_properties_init is probably OK? It looks like SystemProperties::Find would return nullptr, and __system_property_get would return 0.
- In any case, it wouldn't actually matter unless someone ran a new loader on an affected device+kernel.
Nov 5 2021
The motivating issue happened with Android (D107509).
Adding some Android folks to the subscriber list.
Sep 29 2021
The dereferenceable.ll and dereferenceable-inseltpoison.ll files are also confusing to me. It *sounds* like they're trying to test inferred attributes, but its CHECK* lines would allow any or no attributes on the functions, so it's not actually testing anything attribute-related.
Aug 5 2021
Follow up from D107527 review.
Aug 4 2021
I noticed this inconsistency while reviewing D107509.
Update test.
Yes, Android did add stpcpy and stpncpy in API 21:
https://android.googlesource.com/platform/bionic/+/refs/heads/android11-dev/libc/libc.map.txt
Jul 30 2021
Yeah, this looks fine to me.
May 27 2021
May 26 2021
Update another place.
May 19 2021
May 13 2021
Apr 9 2021
error: [FE_UPWARD] in __compiler_rt_scalbn(-0x1p+0 [BFF0000000000000], 10000) = -0x1.fffffffffffffp+1023 [FFEFFFFFFFFFFFFF] != -inf [FFF0000000000000]
Mar 22 2021
Mar 19 2021
Mar 9 2021
Rebase this revision.
I think this is OK for Android.
Feb 26 2021
MSVC's scalbn appears to ignore the current rounding mode, so the value returned from __compiler_rt_scalbn[f] disagreed with the value returned from scalbn[f]. I think it's sufficient to disable the non-default-rounding-mode tests for MSVC. With this change, the __divdc3 and __divsc3 builtins, when compiled with MSVC, should produce the same results as on Linux systems (or as with MinGW and the other Unix systems I tested).
Disable non-default-rounding-mode scalbn[f] tests when using the MSVC libraries.
Feb 25 2021
Feb 24 2021
The new unit tests failed on sanitizer-windows. I reverted it for now. https://lab.llvm.org/buildbot/#builders/127/builds/6620