[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)

thesamesam wrote: > The compromise is to make it a warning which defaults to an error so users > who hit the false positives have an escape hatch. OK, that's fair enough, I think. I can see it being controversial but I think it's a defensible choice (that I agree with). https://github.com/llv

[libclc] [libclc] [cmake] Fix per-target *_convert.cl dependencies (PR #127315)

https://github.com/thesamesam approved this pull request. Please note in the commit message that you're using the same check from `libclc/CMakeLists.txt`. LGTM with that. https://github.com/llvm/llvm-project/pull/127315 ___ cfe-commits mailing list cf

[clang] [TBAA] Don't emit pointer-tbaa for void pointers. (PR #122116)

@@ -2486,6 +2486,23 @@ are listed below. $ clang -fuse-ld=lld -Oz -Wl,--icf=safe -fcodegen-data-use code.cc +Strict Aliasing +--- + +Clang by default applies C/C++'s strict aliasing rules during optimizations. In thesamesam wrote: Thanks! It

[clang] [TBAA] Don't emit pointer-tbaa for void pointers. (PR #122116)

@@ -2486,6 +2486,23 @@ are listed below. $ clang -fuse-ld=lld -Oz -Wl,--icf=safe -fcodegen-data-use code.cc +Strict Aliasing +--- + +Clang by default applies C/C++'s strict aliasing rules during optimizations. In thesamesam wrote: I believe t

[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)

thesamesam wrote: Thanks. I expect there'll be some fallout but you also get missed optimisation bugs out of that in some cases, so. > Another option would be to make this default to an error depending on the > language mode (e.g. only in C23 or later, and either unconditionally in C++ > or

[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)

thesamesam wrote: > The way -Wreturn-type is implemented in Clang is we build a CFG from the AST > and then walk that to determine whether all paths return a value, if that’s > what you’re asking. What I'm asking is: isn't this more susceptible to FPs than other typical Clang warnings, and he

[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)

thesamesam wrote: @AaronBallman On another note, we've had people request this many times in GCC for C++ at least, but it has FPs as a result of how it's implemented. I was under the impression Clang generally didn't do "middle-end"-style (or optimisation-dependent) warnings. Is it implemented

[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)

thesamesam wrote: > Is that something you've looked into by any chance? If not, it would be > worthwhile to know what the fallout is. I'm worried about the fallout and I have vague recollections of some early work I did when I assumed we were making this change for the C99 enforcement work,

[clang] [llvm] [openmp] [OpenMP] Use generic IR for the OpenMP DeviceRTL (PR #119091)

https://github.com/thesamesam approved this pull request. LGTM (thanks for pinging mgorny and I), notwithstanding mgorny's comment, but we could handle that as a followup too. https://github.com/llvm/llvm-project/pull/119091 ___ cfe-commits mailing li

[clang] [flang] [clang][driver] Special care for linker flags in config files (PR #117573)

https://github.com/thesamesam approved this pull request. https://github.com/llvm/llvm-project/pull/117573 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [flang] [clang][driver] Special care for linker flags in config files (PR #117573)

thesamesam wrote: This looks good to me but no doc updates? https://github.com/llvm/llvm-project/pull/117573 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [flang] [clang][driver] Special care for -l flags in config files (PR #117573)

thesamesam wrote: I thought I recognised your name from somewhere ;) Apparently I completely forgot about https://github.com/llvm/llvm-project/issues/67209 too. https://github.com/llvm/llvm-project/pull/117573 ___ cfe-commits mailing list cfe-commits

[clang] [flang] [clang][driver] Special care for -l flags in config files (PR #117573)

thesamesam wrote: @pawosm-arm See also https://wiki.gentoo.org/wiki/Project:Quality_Assurance/As-needed#Importance_of_linking_order. It is common for distributions to enable `-Wl,--as-needed` via patches to the compiler or configuration files. https://github.com/llvm/llvm-project/pull/117573

[clang] [flang] [clang][driver] Special care for -l flags in config files (PR #117573)

thesamesam wrote: I took a look and I think it may be too awkward to do, as we'd want to run e.g. readelf afterwards. But an example is `lld/test/ELF/as-needed-not-in-regular.s`. The idea being: if `-Wl,--as-needed` is in the config file, do we correctly prune an unnecessary library from a bu

[clang] [flang] [clang][driver] Special care for -l flags in config files (PR #117573)

https://github.com/thesamesam edited https://github.com/llvm/llvm-project/pull/117573 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [flang] [clang][driver] Special care for -l flags in config files (PR #117573)

https://github.com/thesamesam commented: This seems OK to me, although I'd feel more comfortable if we had a test which relied on `--Wl,--as-needed`. https://github.com/llvm/llvm-project/pull/117573 ___ cfe-commits mailing list cfe-commits@lists.llvm.

[clang] [clang] Make LazyOffsetPtr more portable (PR #112927)

thesamesam wrote: I appreciate it's not exactly a straightforward change given the discussion it provoked, but any chance you'd be okay with a backport to 19? Clang isn't really usable on ppc32 without this. We could pull it in just for ppc32 downstream but we generally dislike doing condition

[clang] [clang] LazyOffsetPtr: Use native pointer width (PR #111995)

thesamesam wrote: cc @glaubitz (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341) https://github.com/llvm/llvm-project/pull/111995 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [LLVM] [Clang] Support for Gentoo `*t64` triples (64-bit time_t ABIs) (PR #111302)

=?utf-8?q?Micha=C5=82_G=C3=B3rny?= , =?utf-8?q?Micha=C5=82_G=C3=B3rny?= Message-ID: In-Reply-To: https://github.com/thesamesam approved this pull request. https://github.com/llvm/llvm-project/pull/111302 ___ cfe-commits mailing list cfe-commits@list

[clang] [Driver][Sparc] Default to -mcpu=v9 for 32-bit Linux/sparc64 (PR #109278)

thesamesam wrote: (I'm fine with maskray's idea as well.) https://github.com/llvm/llvm-project/pull/109278 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Driver][Sparc] Default to -mcpu=v9 for 32-bit Linux/sparc64 (PR #109278)

https://github.com/thesamesam approved this pull request. https://github.com/llvm/llvm-project/pull/109278 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [compiler-rt] [libcxx] [lld] [lldb] [llvm] [mlir] [polly] python: use raw strings for regex (PR #105990)

https://github.com/thesamesam edited https://github.com/llvm/llvm-project/pull/105990 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [compiler-rt] [libcxx] [lld] [lldb] [llvm] [mlir] [polly] python: use raw strings for regex (PR #105990)

@@ -284,7 +284,7 @@ def sync_csv(rows: List[Tuple], from_github: List[PaperInfo]) -> List[Tuple]: results.append(gh.for_printing()) continue elif paper.status != gh.status: -print(f"We found a CSV row and a Github issue with differen

[clang] [clang] Turn -Wenum-constexpr-conversion into a hard error (PR #102364)

thesamesam wrote: re boost: I was thinking the same re waiting until it's out but I didn't want to say it. Sounds good. https://github.com/llvm/llvm-project/pull/102364 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi

[clang] [clang] Turn -Wenum-constexpr-conversion into a hard error (PR #102364)

https://github.com/thesamesam edited https://github.com/llvm/llvm-project/pull/102364 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Turn -Wenum-constexpr-conversion into a hard error (PR #102364)

https://github.com/thesamesam approved this pull request. Thanks @AaronBallman! Other than gdb (thank you Carlos for working on that), I'm only aware of two issues: * qtlocation -> boost (https://bugs.gentoo.org/895516 -> https://bugreports.qt.io/browse/QTBUG-116652 -> https://github.com/boos

[clang] Add option -fstdlib-hardening= (PR #78763)

thesamesam wrote: > So if the libc++ maintainers have a strong opinion about the flag, I think > more work needs to be done to ensure a good user experience. > Personally, I think going with the macro until the flag has more > functionality it controls makes sense. However, I'm also not opposed

[clang] Add option -fstdlib-hardening= (PR #78763)

thesamesam wrote: > > I am on the fence whether a driver option is really needed. It is a very > > shallow layer of extra abstraction that a curious reader has to look > > through. I guess I'll not object to this, if people really want to add it. > > Setting macros that are reserved names is r

[llvm] [compiler-rt] [mlir] [clang] [libcxx] [sanitizer] Skip /include/c++/ from summary (PR #78534)

thesamesam wrote: Unfortunately, it's been a while since I've done Darwin (although may be doing a bit more soon), so no ideas for that side yet. https://github.com/llvm/llvm-project/pull/78534 ___ cfe-commits mailing list cfe-commits@lists.llvm.org h

[clang] Add option -fstdlib-hardening= (PR #78763)

thesamesam wrote: > > Yes, please, unless there's a strong reason not to, consider `-fhardened`. > > `-fhardened` also enables a few compiler flags. I think it would be better to > have a separate flag that only affects the library and hopefully in the > future start supporting `-fhardened` fl

[llvm] [clang] [libcxx] [mlir] [compiler-rt] [sanitizer] Skip /include/c++/ from summary (PR #78534)

thesamesam wrote: Note that on Gentoo, this isn't right either, we have e.g.: ``` /usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/new_allocator.h /usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/ext/new_allocator.h ``` https://github.com/llvm/llvm-project/pull/78534 _

[clang] Add option -fstdlib-hardening= (PR #78763)

thesamesam wrote: > No other thoughts for now. GCC has `-fhardened` now, which already defines > that macro. This seems kinda redundant with it. Yes, please, unless there's a strong reason not to, consider `-fhardened`. Otherwise we may as well just be telling people to set `-D...` themselves.

[llvm] [clang] [Clang][IR] add TBAA metadata on pointer, union and array types. (PR #75177)

thesamesam wrote: > I put union TBAA under the option that is disabled by default. I am also > considering to put pointer TBAA under option too, if it raises enough > concerns too. Let's please file a bug once this is merged so we remember to come back to that. https://github.com/llvm/llvm-pr

[clang] [clang] Reword apologetic Clang diagnostic messages (PR #76310)

@@ -9913,11 +9913,11 @@ def warn_new_dangling_initializer_list : Warning< "will be destroyed at the end of the full-expression">, InGroup; def warn_unsupported_lifetime_extension : Warning< - "sorry, lifetime extension of " + "lifetime extension of " "%select{temporary

[clang] 3403686 - [Clang] Fix JIT test on 32-bit systems

Author: Sam James Date: 2023-09-05T16:04:22+01:00 New Revision: 3403686b72507e3fdbcd69f21fb9235ffa0ca169 URL: https://github.com/llvm/llvm-project/commit/3403686b72507e3fdbcd69f21fb9235ffa0ca169 DIFF: https://github.com/llvm/llvm-project/commit/3403686b72507e3fdbcd69f21fb9235ffa0ca169.diff LOG

[clang-tools-extra] 4ddae8b - [clangd] Fix test failure when it's built with compiler flags unknown by clang

Author: Xi Ruoyao Date: 2023-05-16T03:56:26+01:00 New Revision: 4ddae8b941398a6579d3a6f25aa39a260e441371 URL: https://github.com/llvm/llvm-project/commit/4ddae8b941398a6579d3a6f25aa39a260e441371 DIFF: https://github.com/llvm/llvm-project/commit/4ddae8b941398a6579d3a6f25aa39a260e441371.diff LOG

[clang] 136f778 - [Clang] [Python] Fix tests when default config file contains -include

Author: Sam James Date: 2023-01-23T21:15:10Z New Revision: 136f77805fd89cd30e69b3d1204fbf7efedd9a12 URL: https://github.com/llvm/llvm-project/commit/136f77805fd89cd30e69b3d1204fbf7efedd9a12 DIFF: https://github.com/llvm/llvm-project/commit/136f77805fd89cd30e69b3d1204fbf7efedd9a12.diff LOG: [Cl

Re: How can Autoconf help with the transition to stricter compilation defaults?

> On 16 Nov 2022, at 15:27, Richard Biener wrote: > > On Wed, Nov 16, 2022 at 4:02 PM Michael Matz via Gcc wrote: >> >> Hey, >> >> On Wed, 16 Nov 2022, Alexander Monakov wrote: >> The idea is so obvious that I'm probably missing something, why autoconf can't use that idiom instead

Re: How can Autoconf help with the transition to stricter compilation defaults?

> On 13 Nov 2022, at 00:43, Paul Eggert wrote: > > On 2022-11-11 07:11, Aaron Ballman wrote: >> We believe the runtime behavior is sufficiently dangerous to >> warrant a conservative view that any call to a function will be a call >> that gets executed at runtime, hence a definitive signature m

Re: How can Autoconf help with the transition to stricter compilation defaults?

> On 12 Nov 2022, at 03:40, Zack Weinberg wrote: > > Florian Weimer writes: >> based on a limited attempt to get this fixed about three years >> ago, I expect that many of the problematic packages have not had their >> configure scripts regenerated using autoconf for a decade or more. This >>

Re: How can Autoconf help with the transition to stricter compilation defaults?

> On 10 Nov 2022, at 17:16, Zack Weinberg wrote: > > I’m the closest thing Autoconf has to a lead maintainer at present. > > It’s come to my attention (via https://lwn.net/Articles/913505/ and > https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and > Clang both plan to disable

[libunwind] 32a2af4 - [CMake] Fix -Wstrict-prototypes

Author: Sam James Date: 2022-11-08T01:37:04Z New Revision: 32a2af44e1e882f13d1cc2817f0a8d4d8b375d4d URL: https://github.com/llvm/llvm-project/commit/32a2af44e1e882f13d1cc2817f0a8d4d8b375d4d DIFF: https://github.com/llvm/llvm-project/commit/32a2af44e1e882f13d1cc2817f0a8d4d8b375d4d.diff LOG: [CM