-
Notifications
You must be signed in to change notification settings - Fork 10.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Regression with -D_FORTIFY_SOURCE=2 #61691
Comments
Clang has to do some weird stuff to "correctly" lower the strange functions that call themselves defined by glibc Could use a reduced testcase. |
Here is a reduced testcase Compile with clang -flto -x c -std=gnu89 -O2 -S -emit-llvm reduced.ii -o reduced.ll The generated ; Function Attrs: alwaysinline nofree nounwind willreturn memory(argmem: readwrite) uwtable
define available_externally ptr @strncpy(ptr noalias noundef nonnull returned writeonly %0, ptr noalias nocapture noundef nonnull readonly %1, i64 noundef %2) local_unnamed_addr #3 {
br label %4
4: ; preds = %4, %3
%5 = phi ptr [ poison, %3 ], [ %7, %4 ]
%6 = phi i1 [ false, %3 ], [ true, %4 ]
%7 = select i1 %6, ptr %5, ptr %0
br label %4
} |
https://reviews.llvm.org/D147307 << potential fix. |
@llvm/issue-subscribers-clang-frontend |
Also add libkdumpfile status.
/cherry-pick fd8745c |
/branch llvm/llvm-project-release-prs/issue61691 |
/pull-request llvm/llvm-project-release-prs#417 |
Fix llvm#61691 Differential Revision: https://reviews.llvm.org/D147307
Since this commit introduced a regression, we will not be backporting it to 16.0.x. |
Closing this as the issue has been fixed and this was now tracking the backport -- with the backport declined, we can close this again. |
There was a regression compiling libmbim between clang-14 and clang-15, and it's still present in main.
The bad behavior began after bfb9b8e, however, I think the root cause is a bug in Clang's handling of
-D_FORTIFY_SOURCE=2
. When building libmbim, the libmbim-glib-scan utility hangs, and from some limited debugging I did, it appears that it gets stuck in a loop ofstrncpy
calling itself, which I think has happened before due to inlining of the*_chk
functions in glibc.I am able to reliably reproduce this bug in a Fedora 37 container using the script below:
@serge-sans-paille
The text was updated successfully, but these errors were encountered: