User Details
- User Since
- Dec 12 2016, 10:04 PM (328 w, 2 d)
Mon, Mar 27
This is firing even in checked length codes, is that expected?
Tue, Mar 21
Wed, Mar 8
Jan 25 2023
At least for ChromeOS, as long as this change is limited to clang not making calls to it and function is not removed from compiler-rt, it works for us . We ship a libgcc_s.so using compiler-rt sources so we need so compatibility there so that older binaries keep working.
Jan 20 2023
The change looks simple enough and do not see any issues raised.
Jan 18 2023
The patch looks simple enough to me. But I do not know this code patch well enough to accept it. Agree that Inlining cost estimation work should not block this.
Dec 16 2022
If ChromeOS needs time for migration, I think -Xcompiler can be temporarily ignored.
Here are a few instances of Xcompiler usage for a non-exhaustive search (I can't look inside package tarballs if they are using it ):
Without -Xcompiler, ChromeOS code will break. It may not be supported by GCC but it is supported in some other compilers like Cuda and a few others if you search. Also being supported by libtool makes it more important to keep it working.
Dec 15 2022
Xlinker still works. Xcompiler is failing.
Dec 12 2022
We use -Xcompiler and -Xlinker which are passed in programs and they raise error now.
Dec 9 2022
The removal is also breaking ChromeOS builds which use -Xpattern in some cases.
Nov 3 2022
Updated test.
Restore back to C++ only.
restore back to C++ only
Oct 28 2022
@tomhughes has more details on this but if we do not define it in clang itself, we'll need to define it for every package manually at build time since the usage goes deep inside newlib headers.
Oct 26 2022
thanks, I assume @MaskRay is a good reviewer for it.
Oct 25 2022
Removed c++ limitation.
Abandon in favor of D136708
Oct 7 2022
Oct 5 2022
address comments and check CI.
Oct 3 2022
friendly ping for review.
Sep 22 2022
Thanks for the patch. Can you please post a full diff (git diff -U9999).
Aug 10 2022
Aug 9 2022
Going back to older handlesTarget() style in Baremetal.
Apparently RISCV can be both Baremetal or RISCVToolchain for the
same tuple. I do not know of the nuances so trying not to disturb that for
now.
Fix clang-format complains.
Address maskray comments.
Aug 8 2022
Address more style lints.
Address style nits.
Moved defs to Triple.cpp
Moved Baremetal triple related code to Triple.h.
Aug 4 2022
Jun 27 2022
Thanks, I can verify that this fixes the crash I reported.
Still crashes on trunk.
Jun 26 2022
Heads up: I am seeing a clang crash on arm with this commit:
Jun 25 2022
If you can't wait until Wednesday or Thursday you can always revert the diff downstream.
Will submit after CI results come back.
Will submit after CI results.
Jun 24 2022
Jun 22 2022
The following code now longer works after this patch:
This seems like same as the problem that was fixed by https://reviews.llvm.org/rGe6a39f00e8d0cd3684df54fb03d288efe2969202 and re-introduced by this patch.
Jun 5 2022
Thanks for clarifying that ELF is not affected, I just wanted someone from ARM to verify.
@danielkiss can you please review?
Daniel, can you please check if this removal is ok. I am particularly worried about pthread_cancel which is often hard to debug.
Jun 3 2022
Yes, LLVM_ENABLE_RUNTIMES and LLVM_ENABLE_PER_TARGET_RUNTIME_DIR are two separate things.
May 25 2022
May 16 2022
We are noticing a clang crash after this commit: https://github.com/llvm/llvm-project/issues/55510
May 10 2022
Thanks Christopher,
May 5 2022
We can close the discussion as Fangrui has uploaded https://reviews.llvm.org/D125074 to keep older behavior.
Thanks fangrui.
This change is breaking rust embedded use cases where NOLOAD in a linker script is no longer being honored. So we had to revert it (locally) in ChromeOS.
Apr 30 2022
Hmm, the commit message says that Wno-error should work but this is not really the case :(.
Following behavior is also surprising:
Tried locally but I still see the warning with -fno-knr-functions. It also says that the argument is unused.
We are finding a lot of failures in our ToT builds with this change. here is an example for a configure script:
Apr 29 2022
Unless I probably mis-interpreted something, -fno-knr-functions does not suppress the warning: https://godbolt.org/z/rbEfbbb33
Basically, I'm wondering if you'd be able to enable -fno-knr-function?
Thanks. this looks promising. Any ideas when -fno-knr-function support was added?
Is disabling the pedantic warning an option for your users?
Apr 28 2022
Some of our users are not very happy with the churn probably caused by this change where the declaration has the "void" argument but the later definition does not have explicit "void".
Apr 27 2022
Thanks, this also fixes one of the test failures we were seeing on AArch64 boards.
Apr 14 2022
We noticed a new crash that still repros at head.
Mar 15 2022
Replaced uses of /dev/stdin by /dev/null and added asserts.
Added tests for stat64 and fstatat64
Mar 14 2022
Fixed crash and added suggested tests.
I am noticing a unit tests error with this change for glob_altdirfunc.cpp file but not sure how to resolve it.
MemorySanitizer:DEADLYSIGNAL ==3854677==ERROR: MemorySanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000000000 bp 0x7ffeeab8eb60 sp 0x7ffeeab8eb28 T3854677) ==3854677==Hint: pc points to the zero page. ==3854677==The signal is caused by a READ memory access. ==3854677==Hint: address points to the zero page.
Mar 9 2022
For the background, we had hit this in Chrome OS when building bluetooth code.
Mar 4 2022
We are noticing some failures in internal unit tests with this change.
Mar 3 2022
We noticed another crash with this change that still repros on ToT: https://github.com/llvm/llvm-project/issues/54190
Mar 2 2022
Feb 28 2022
Running readelf shows following in our shipping shared libs.