george.burgess.iv added a comment. (It's interesting to me if gcc doesn't warn about that libcxx code, since the whole point of the gnuc 5.0 check there was "the compiler should check this for us now"...)
If a glibc-side fix for this does materialize, IMO `-fgnuc-version=5.0` isn't a good path forward. It's best if workarounds are limited in scope, lifespan, and user impact: - Presumably `-fgnuc-version=5.0` implies many more changes that are unrelated to this particular bug. - Glibc upgrades can take years to materialize for users[1]. - A lot of packages build with `-D_FORTIFY_SOURCE=2` by default. Requiring extra CPPFLAGS (either `-D_FORTIFY_SOURCE=0` or `-fgnuc-version=5.0`) would break `CC=clang make`-style builds that already work today, if any statement in them folds to `memset(x, non_zero, 0);` after optimizations. Looks like this landed on the branch, so unless I'm mistaken, we probably need to revert there, as well? [1] -- Anecdotally, I upgraded a project's host toolchain from using glibc 2.15 to 2.17 last year. I wanted to do 2.19, but 2.17 usage was still large enough that 2.19 wasn't an option. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71082/new/ https://reviews.llvm.org/D71082 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
