[Bug other/71760] libiberty - Segmentation fault when attempting to delete a non-existent element in a hash table
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71760 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Andrew Pinski from comment #1) > Fixed in GCC 9 by r9-6544-g62de703f1990d2 . > > https://gcc.gnu.org/pipermail/gcc-patches/2019-March/518751.html . Wonder if it's worth adding the testcase?
[Bug c++/88371] Gratuitous (?) warning regarding an implicit conversion in pointer arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88371 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to Eyal Rozenberg from comment #2) > (In reply to Andrew Pinski from comment #1) > > Looks to be fixed in GCC 10+. > > Indeed... mark this as RESOLVED FIXED perhaps? OK.
[Bug analyzer/114588] Analyzer buffer overflow ASCII art hardcodes "RED" and "GREEN" as the terminal colors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114588 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Andrew Pinski from comment #1) > Confirmed. I should note that Red/Green is the opposite meaning in some > places than western cultures. That is Red is good and Green is bad. Most of > China is where that is true. > > See > https://graphicdesign.stackexchange.com/questions/6982/except-china-which- > country-will-use-red-for-up-and-green-for-down also. Japan, too, it's why the (chart with upwards trend) emoji uses red, and the (chart with downwards trend) emoji uses blue, because they were originally from Japan. Red = "heating up" (which is good for shares of a stock) and blue = "cooling off" (which is bad for shares of a stock)
[Bug c++/71482] Add -Wglobal-constructors warning option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71482 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=54254 --- Comment #6 from Eric Gallager --- Another reason this warning might be wanted: name mangling and demangling of global constructors has been buggy for awhile now; see bug 54254
[Bug demangler/54254] libiberty: demangling for global constructor is broken since r167781
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54254 --- Comment #7 from Eric Gallager --- (In reply to Andrew Pinski from comment #5) > *** Bug 90039 has been marked as a duplicate of this bug. *** Symbol for this one was _GLOBAL__sub_I__Z11print_tracev
[Bug demangler/59518] C++ demangler does not handle some global constructor & LTO names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59518 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Andrew Pinski from comment #1) > _GLOBAL__sub_ issue is PR 54254 How about the others?
[Bug demangler/54254] libiberty: demangling for global constructor is broken since r167781
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54254 --- Comment #6 from Eric Gallager --- (In reply to Andrew Pinski from comment #4) > *** Bug 56755 has been marked as a duplicate of this bug. *** symbol from this one was _GLOBAL__sub_I__ZN4AMOS12ContigEdge_t5NCODEE
[Bug analyzer/101713] -Wanalyzer-malloc-leak false positive with GNU coreutils hash table code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101713 Eric Gallager changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-04-02 --- Comment #3 from Eric Gallager --- Confirming due to the link to it from gnulib's manywarnings.m4
[Bug bootstrap/105474] GCC fails to bootstrap with --disable-libstdcxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105474
Eric Gallager changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=102665
CC||egallager at gcc dot gnu.org
--- Comment #5 from Eric Gallager ---
(In reply to Andrew Pinski from comment #4)
> Something like should provided an error while configuring so much earlier:
> ```
> case "$enable_bootstrap:${noconfigdirs}" in
> yes:*target-libstdc++-v3*)
> AC_MSG_ERROR([cannot also disable libstdcxx if bootstrapping]) ;;
> ;;
> esac
>
> ```
>
> Let me test that out and submit it for GCC 15.
Related: bug 102665
[Bug c++/66487] sanitizer/warnings for lifetime DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66487 --- Comment #30 from Eric Gallager --- (In reply to Eric Gallager from comment #29) > (In reply to Alexander Monakov from comment #28) > > The bug is about the issue of lacking diagnostics, it should be fine to make > > note of various approaches to remedy the problem in one bug report. > > > > OK, well, in this case, I'd like to make this the bug report for MSan > support in general, too, then; it's documented here: > https://github.com/google/sanitizers/wiki/MemorySanitizer ...see also this wiki page, since GCC supports building with libc++ now: https://github.com/google/sanitizers/wiki/MemorySanitizerLibcxxHowTo ...although, be aware that it's outdated, as per this issue: https://github.com/google/sanitizers/issues/1685
[Bug c++/66487] sanitizer/warnings for lifetime DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66487 --- Comment #29 from Eric Gallager --- (In reply to Alexander Monakov from comment #28) > The bug is about the issue of lacking diagnostics, it should be fine to make > note of various approaches to remedy the problem in one bug report. > OK, well, in this case, I'd like to make this the bug report for MSan support in general, too, then; it's documented here: https://github.com/google/sanitizers/wiki/MemorySanitizer (In reply to Martin Liška from comment #20) > (In reply to Jan Hubicka from comment #19) > > Martin, I suppose the sanitizer bits can be tracked as enhancement and not > > regression. It is a firefox bug so I suppose we can declare this a > > non-regression. > > Sure, maybe I would return to support of MSAN in GCC 7. Maybe for GCC 14 now?
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #75 from Eric Gallager --- (In reply to Dominik Vogt from comment #25) > Looks better, but now we get this quite often: > > -- > ==23722==ERROR: Your kernel seems to be vulnerable to CVE-2016-2143. Using > ASa\ > n, > MSan, TSan, DFSan or LSan with such kernel can and will crash your > machine, or worse. > -- > > I'll try to figure out what kernel version we need. Why does this error message mention all of those sanitizers, when GCC only supports some of them?
[Bug c/12411] Missed -Wsequence-point on functions (example reduced from historical GCC source)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12411 --- Comment #10 from Eric Gallager --- I think the dup is a point for reopening
[Bug lto/110710] LTO linker on Windows creates an invalid Makefile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110710 Eric Gallager changed: What|Removed |Added Keywords||patch CC||egallager at gcc dot gnu.org URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-March/6 ||48427.html Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |peter0x44 at disroot dot org --- Comment #14 from Eric Gallager --- (In reply to Peter Damianov from comment #13) > https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648427.html > > Patch submitted. Couldn't figure out how to assign myself in bugzilla. There's a privilege for it; I just assigned you.
[Bug libgcc/113402] Incorrect symbol versions for __builtin_nested_func_ptr_created, __builtin_nested_func_ptr in libgcc_s.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113402 Eric Gallager changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED CC||egallager at gcc dot gnu.org --- Comment #11 from Eric Gallager --- (In reply to dave.anglin from comment #10) > Warning is fixed on hppa. OK, closing as FIXED, then.
[Bug jit/102824] building pdf/dvi documentation for libgccjit fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102824 --- Comment #13 from Eric Gallager --- (In reply to Iain Sandoe from comment #12) > what input is this waiting for at the moment? >From checking the bug history, it looks like Martin Liška was the one to put this in the WAITING status, which came along with this comment: (In reply to Martin Liška from comment #7) > Well, running 'make latexpdf' works if you jump into gcc/jit/docs folder. Do > I miss something? ...which I thought we'd answered, but to make it a bit more clear: we shouldn't have to do that to get the jit docs to build properly. They should build properly when doing `make dvi` and/or `make pdf` from the top-level, rather than requiring their own special procedures.
[Bug other/114496] Documentation: "Non-Bugs" page should update/mention something about -Wsign-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114496 --- Comment #3 from Eric Gallager --- Maybe the update could be just to clarify the "EnabledBy" rules for the warning? i.e., something like "-Wsign-conversion is only and will only ever be enabled by -Wconversion in C, and we will never have it enabled by -Wall or -Wextra (unlike -Wsign-compare, which is enabled by -Wall in C++, and -Wextra in C)." (and maybe also include something about the new -Warith-conversion flag too?)
[Bug rtl-optimization/951] Documentation of compiler passes and sources very out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=951 Eric Gallager changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-March/6 ||48306.html Keywords||patch --- Comment #12 from Eric Gallager --- Patch posted that might help with this a little bit: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648306.html
[Bug tree-optimization/13756] [tree-ssa] documentation missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13756 Eric Gallager changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-March/6 ||48306.html --- Comment #19 from Eric Gallager --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648306.html
[Bug c/109835] -Wincompatible-function-pointer-types as a subset of -Wincompatible-pointer-types?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109835 --- Comment #6 from Eric Gallager --- (In reply to Sam James from comment #5) > FWIW, after doing more of this work, I've decided I don't really care that > much about this one. > > I still think FP mismatches are often worse, but there's enough junk pointer > type mismatches that I'm not sure we should provide this (it's not like one > case is OK and the other is way less scary or something). I mean, I might still use just one but not the other in a case where I've got a huge project, and need to narrow down the warnings so that I can just focus on a manageable subset, rather than being overwhelmed by having to try to look at all of them at once.
[Bug target/42818] Static C++ linking breakage "undefined reference to ___real__Znwj" and others in libcygwin.a(_cygwin_crt0_common.o)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42818 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #10 from Eric Gallager --- (In reply to Dave Korn from comment #6) > That would work fine for --static, but as things stand now, it will still > fail when just --static-libstdc++ is in use. This is because of the > situation described in the two dependency PRs (Bug 41594 and Bug 41596) Both bugs upon which this one depends have been closed; time to revise this one's SUSPENDED status?
[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 --- Comment #35 from Eric Gallager --- (In reply to Дилян Палаузов from comment #34) > Created attachment 57662 [details] > Proposed patch > > This fixes the problem. > > I do not understand the build system to say, that this is the best approach, > so if there are questions I might or might not be able to answer them. > > I also do not know, if 2×`maybe-` is necessary. Please send this patch to the gcc-patches mailing list and cc the build system maintainers. I think the `maybe-` things are supposed to get generated in some sort of way that would require digging into the whole autogen generation method a bit more deeply, but I'm not too sure myself... maybe this ought to be a `depend=` entry in Makefile.def instead?
[Bug libgomp/66553] openmp tasks produce libgomp warnings with fsanitize=thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66553 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- dup of, or at least related to, bug 55561?
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Last reconfirmed||2024-02-29 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #54 from Eric Gallager --- Confirmed that providing an instrumented libgomp would be worthwhile.
[Bug c++/66487] sanitizer/warnings for lifetime DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66487 --- Comment #27 from Eric Gallager --- (In reply to Alexander Monakov from comment #26) > RFC patch for detecting lifetime-dse issues via Valgrind (rather than MSan): > https://inbox.sourceware.org/gcc-patches/20231024141124.210708-1-exactl...@ispras.ru/ So, if this bug is now specifically for the valgrind approach, is there a separate one for MSan?
[Bug analyzer/105898] RFE: -fanalyzer should complain about overlapping args to mempcpy, wmemcpy, and wmempcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105898 Eric Gallager changed: What|Removed |Added Summary|RFE: -fanalyzer should |RFE: -fanalyzer should |complain about overlapping |complain about overlapping |args to memcpy and mempcpy |args to mempcpy, wmemcpy, ||and wmempcpy --- Comment #5 from Eric Gallager --- (In reply to David Malcolm from comment #4) > I implemented this a different way, for memcpy, in r14-3556-g034d99e81484fb > (by special-casing it). > > We don't yet check mempcpy, wmemcpy, or wmempcp; keeping bug open to handle > those. Retitling.
[Bug target/113679] long long minus double with gcc -m32 produces different results than other compilers or gcc -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #12 from Eric Gallager --- (In reply to Jakub Jelinek from comment #10) > Oh, you mean the pow equality comparison. I think you should study > something about floating point, errors, why equality comparisons of floating > point values are usually a bad idea etc. > There is no gcc bug, just bad user expectations. This is why gcc has the -Wfloat-equal warning flag, isn't it?
[Bug target/53929] [meta-bug] -masm=intel with global symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #27 from Eric Gallager --- is this really a meta-bug? Normally meta-bugs depend on other bugs...
[Bug c/80036] Source line not printed for diagnostic if expanded from a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80036 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #2) > Variable-uses don't have locations in GCC Update: now they do
[Bug c/70730] Inconsistent column number in "error: attempt to take address of bit-field structure member"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70730 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #1) > If not, this then depends on PR43486 (that's now fixed, btw... so maybe that's had an impact on this?)
[Bug c/113414] Incorrent checking for printf format: does not distinguish whether the variable is signed or unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113414 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Keywords||diagnostic --- Comment #4 from Eric Gallager --- I forget which other bug I mentioned this in, but this reminds me that I still think a -Wformat=3 that includes -Wformat-signedness would be nice, as currently it only goes up to -Wformat=2, which doesn't include -Wformat-signedness currently.
[Bug c/67819] -Wduplicated-cond should take macros into account
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67819 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #7 from Eric Gallager --- This blocks the enablement of -Wduplicated-cond with -Wall/-Wextra; see bug 87656
[Bug c/89072] -Wall -Werror should be defaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89072 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=87656 --- Comment #14 from Eric Gallager --- Now we're straying into bug 87656...
[Bug c/105401] Improved diagnostics for code from "Labels as Values" documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105401 --- Comment #2 from Eric Gallager --- putting the words "computed gotos" here for easier searchability
[Bug middle-end/37722] destructors not called on computed goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37722 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=105401 Keywords||diagnostic --- Comment #9 from Eric Gallager --- see also bug 105401 for another issue about diagnostics and documentation related to computed gotos
[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 Eric Gallager changed: What|Removed |Added See Also||https://github.com/apple/sw ||ift-corelibs-libdispatch/is ||sues/765 --- Comment #25 from Eric Gallager --- Cross-referencing against https://github.com/apple/swift-corelibs-libdispatch/issues/765
[Bug other/113168] ABOUT-NLS seems way out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113168 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- I think ABOUT-NLS is vendored in from gettext; if you run `gettextize` it will replace the content of the file with a simple link to <https://www.gnu.org/software/gettext/manual/html_node/Users.html>. See for example: https://github.com/cooljeanius/gcc/commit/d9661641f89ee1baae768a006ef2d7b1f2db15f7
[Bug target/113019] [NOT A BUG] Multi-architecture binaries for Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113019 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #7 from Eric Gallager --- Perhaps you're looking for something like cosmocc? https://github.com/jart/cosmopolitan/blob/master/tool/cosmocc/bin/cosmocc ...or perhaps a port of driverdriver.c and lipo from the old Apple GCC to Linux? https://opensource.apple.com/source/gcc_42/gcc_42-5566/driverdriver.c.auto.html
[Bug target/112973] Documentation for __builtin_preserve_access_index is not wrapped in extend.texi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112973 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Severity|normal |trivial Keywords||easyhack
[Bug c++/60512] would be useful if gcc implemented __has_feature similarly to clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #24 from Eric Gallager --- (In reply to Alex Coplan from comment #23) > Implemented for GCC 14. Thanks! Could you add a note to gcc-14/changes.html in gcc-wwwdocs so that people can be aware of it?
[Bug other/112897] Have a configure option for all common flags used by default on distros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112897 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to Agostino Sarubbo from comment #2) > I don't know if I was able to provide the concept, but in other words if we > know that something like -fstack-clash-protection is widely used nowadays, > it make no sense rebase patches for 10 years and then in the 2033 make the > proper configure option :) > > > What's the flag you want to enable this time? > > I'm not a gcc downstream maintainer so I can speak for what I can see as > external people, so you might want to involve downstream maintainers. > From what I can see I'd say that a starting point is: > > -D_FORTIFY_SOURCE=2 > -D_FORTIFY_SOURCE=3 > -fstack-clash-protection > -fcf-protection > -z,relro / -z now > _GLIBCXX_ASSERTIONS > -Wformat > -Wformat-security This sounds like basically the same set of options enabled by the new -fhardened flag coming in GCC 14?
[Bug jit/102824] building pdf/dvi documentation for libgccjit fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102824 --- Comment #11 from Eric Gallager --- I'm wondering if it'd be possible to insert a line like: \batchmode into the tex files? Ref: https://tex.stackexchange.com/questions/25267/what-reasons-if-any-are-there-for-compiling-in-interactive-mode
[Bug target/96895] ABI of returning V1DF differs between GCC and clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895 Eric Gallager changed: What|Removed |Added URL|https://gitlab.com/x86-psAB | |Is/x86-64-ABI/-/issues/1| CC||egallager at gcc dot gnu.org See Also||https://gitlab.com/x86-psAB ||Is/x86-64-ABI/-/issues/1 --- Comment #8 from Eric Gallager --- (In reply to H.J. Lu from comment #3) > I opened: > > https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/1 I'm moving this to the "See Also" field, now that that's possible.
[Bug target/99741] dllexport attribute is not compatible with c99 inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99741 Eric Gallager changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill |https://gcc.gnu.org/bugzill |a/show_bug.cgi?id=90161 |a/show_bug.cgi?id=99901 --- Comment #2 from Eric Gallager --- (In reply to Andrew Aladjev from comment #0) > PS this issue is indirectly related to > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90161 That has been closed as a dup of bug 99901, which has since been closed as fixed.
[Bug target/65146] alignment of _Atomic structure member is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65146 Eric Gallager changed: What|Removed |Added URL|https://gitlab.com/x86-psAB | |Is/i386-ABI/-/issues/1 | See Also||https://gitlab.com/x86-psAB ||Is/i386-ABI/-/issues/1 CC||egallager at gcc dot gnu.org --- Comment #26 from Eric Gallager --- (In reply to H.J. Lu from comment #23) > I created: > > https://gitlab.com/x86-psABIs/i386-ABI/-/issues/1 Let's move that to the "See Also" field, now that that's possible.
[Bug web/108473] bugzilla see also should support gitlab.com URLs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108473 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #9 from Eric Gallager --- (In reply to Mark Wielaard from comment #7) > OK, applied all 12 above commits to both both gcc and sourceware bugzilla. > There were some small whitespace issues, but most applied cleanly. > > Could you check that everything looks fine and the new trackers can be added > through See Also now? GitLab links added to See Also without issue in bug 112380
[Bug c/88088] -Wtrampolines should be enabled by -Wall (or -Wextra)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088 Eric Gallager changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #27 from Eric Gallager --- Marek Polacek has had a new idea to have it be enabled by the new -fhardened flag instead: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/638987.html
[Bug ipa/110334] [13/14 Regresssion] unused functions not eliminated before LTO streaming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #26 from Eric Gallager --- (In reply to Richard Biener from comment #20) > Unfortunately there isn't a knob to diagnose late inlined always-inline > functions. Is there a separate bug for this?
[Bug c/112463] ternary operator / -Wsign-compare inconsistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112463 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Keywords||diagnostic --- Comment #1 from Eric Gallager --- I think I've seen this bug before, but I can't seem to find the one I was thinking it might be a dup of...
[Bug bootstrap/112422] Build process does a redundant number of checks ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112422 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Keywords||build --- Comment #2 from Eric Gallager --- A lot of that's just the way that autoconf works. You'd probably have to change the upstream implementation of certain autoconf macros to fix this. Alternatively, you could also try configuring with the "-C" flag to your configure script, which should cause configure results to be cached, but that can be rather fragile, as the config.cache files can stop your build if the slightest things to change. I suppose GCC could try sharing its config.cache files more widely between its various subdirectories, but that would be somewhat risky, given that some of the things that configure checks for could change due to the whole bootstrap process (fixincludes changes the headers available, the new compiler getting built changes which compiler should be found, and what features it has, the new runtime libraries getting built change what functions are available, and so on...)
[Bug libbacktrace/112396] "make check" should not error out, even when some checks failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112396 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Andrew Pinski from comment #1) > https://gcc.gnu.org/install/test.html > > Even mentions -k option for a long time. Still, it's kind of inconvenient having to do it that way, though. I think this is an aspect of the testsuite worth changing.
[Bug c++/112377] Implement -Walloc-size in c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112377 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to David Binderman from comment #0) > Following on from discussion in bug report 112347, > in file gcc/c-family/c.opt, is the new text > > Walloc-size > C ObjC Var(warn_alloc_size) Warning LangEnabledBy(C ObjC, Wextra) > Warn when allocating insufficient storage for the target type of the > assigned pointer. > > IMHO, it should say: > > Walloc-size > C ObjC Var(warn_alloc_size) Warning LangEnabledBy(C ObjC C++, Wextra) > Warn when allocating insufficient storage for the target type of the > assigned pointer. > > I think that should be enough to implement the new warning for C++. If adding it to C++, then IMO it ought to be enabled for ObjC++, too, since the current implementation is for both C and ObjC.
[Bug c/70954] -Wmisleading-indentation false positive on code from GNU "ed" (featuring a label)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70954 Eric Gallager changed: What|Removed |Added Summary|-Wmisleading-indentation|-Wmisleading-indentation |false positive on GNU "ed" |false positive on code from ||GNU "ed" (featuring a ||label) CC| |egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to Martin Uecker from comment #2) > Here is another example of what appears to be the same bug. Reported here: > https://gcc.gnu.org/pipermail/gcc/2023-November/242803.html > > I think it would be useful of the title of this report could be changed to > mention "label". OK, updated.
[Bug modula2/111956] Many powerpc platforms do _not_ have support for IEEE754 long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956 --- Comment #3 from Eric Gallager --- (In reply to Thomas Schwinge from comment #2) > While you (Gaius) here report test failure, similar to what Maciej had > reported in PR112091 "rs6000: redefinition of 'constexpr long double > std::abs(long double)', while building libgm2", I can't even build libgm2 > anymore. > > Similar had reported Eric (CCed here) on GCC IRC, 2023-10-20: > > ok now this is an error I haven't seen before > > /home/egallager/gcc/.cfarm135_build.build/powerpc64le-unknown-linux-gnu/ > libstdc++-v3/include/bits/std_abs.h:137:3: error: redefinition of 'constexpr > long double std::abs(long double)' > seen on cfarm135 > I think I remember something about __float128 being weird > on certain powerpc systems? Is there a configure flag that affects it? > I'll open a bug about it... > although actually wait... I'm not quite sure the > component, though... it's an error from a libstdc++ header, but it shows up > while building KeyBoardLEDs.lo for libm2cor in libgm2, but only for a > specific target... Ah, thanks for the cc! I'd meant to look further into this, but got distracted by other things...
[Bug ada/111909] Filename case sensitivity defaulted wrongly on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111909 Eric Gallager changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-October ||/634636.html Keywords||patch Last reconfirmed||2023-10-30 Assignee|unassigned at gcc dot gnu.org |simon at pushface dot org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #2 from Eric Gallager --- Patch posted to mailing lists: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634636.html
[Bug c++/19538] [DR 407] Bogus diagnostic for typedef name in elaborated type specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19538 Eric Gallager changed: What|Removed |Added Keywords||diagnostic --- Comment #5 from Eric Gallager --- (In reply to Jonathan Wakely from comment #4) > Un-suspending, and changing from accepts-invalid to rejects-valid. > > Both [1] and [2] are valid now and should be accepted. Still a diagnostic issue even it's now rejects-valid instead of accepts-valid, IMO.
[Bug target/111908] Port CheriBSD-specific compiler warnings to GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111908 --- Comment #3 from Eric Gallager --- (In reply to Alex Coplan from comment #2) > Indeed, you can see an example of the CHERI warnings in the Morello GCC port > here: https://godbolt.org/z/eWPfqYYYo Where do the sources for the Morello GCC port currently live? If they haven't been upstreamed yet, are there plans to do so?
[Bug c++/110848] Consider enabling -Wvla by default in non-GNU C++ modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848 --- Comment #15 from Eric Gallager --- (In reply to Eric Gallager from comment #14) > Oh right, if we're considering changing things for plain-C here, too, then > maybe have it enabled by -Wc++-compat there? Or rather, for plain-C modes, where "XY" is 99 or newer: -std=cXY: enabled by -Wc++-compat -std=gnuXY: still completely opt-in; -Wvla must be enabled explicitly (and then for the pre-c99 modes, well, I guess they'd just keep their current behavior)
[Bug c++/110848] Consider enabling -Wvla by default in non-GNU C++ modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848 --- Comment #14 from Eric Gallager --- Oh right, if we're considering changing things for plain-C here, too, then maybe have it enabled by -Wc++-compat there?
[Bug ada/111909] Filename case sensitivity defaulted wrongly on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111909 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- Cross-referencing against some related issues: https://github.com/iains/gcc-darwin-arm64/issues/101 Bug 81114
[Bug target/111908] New: Port CheriBSD-specific compiler warnings to GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111908 Bug ID: 111908 Summary: Port CheriBSD-specific compiler warnings to GCC Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: build, diagnostic Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: egallager at gcc dot gnu.org CC: jrtc27 at jrtc27 dot com Blocks: 44756, 87403 Target Milestone: --- Target: CheriBSD The GCC compile farm has a CheriBSD machine, cfarm240, where the C/C++ memory rules are stricter than normal. CheriBSD modifications to C/C++ are described in the CHERI C/C++ Programming Guide: https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-947.pdf The document outlines a number of warnings that their compiler has for code that will break on CheriBSD, specifically: - -Wcheri-prototypes (kinda like -Wstrict-prototypes) - -Wcheri-capability-misuse (kinda like -Wint-to-pointer-cast and -Wpointer-to-int-cast; says something like "warning: cast from provenance-free integer type to pointer type will give pointer that can not be dereferenced") - -Wcheri-provenance (says something like "warning: binary expression on capability types; it is not clear which should be used as the source of provenance") Note that some of these warnings will show up in a build of GCC itself, and will cause the build to fail if configured with --enable-werror --enable-werror-always. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44756 [Bug 44756] [meta-bug] --enable-werror-always issues https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug tree-optimization/80532] warning on pointer access after free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80532 --- Comment #11 from Eric Gallager --- (In reply to CVS Commits from comment #9) > The master branch has been updated by Martin Sebor : > > https://gcc.gnu.org/g:671a283636de75f7ed638ee6b01ed2d44361b8b6 > > commit r12-6605-g671a283636de75f7ed638ee6b01ed2d44361b8b6 > Author: Martin Sebor > Date: Sat Jan 15 16:37:54 2022 -0700 > [...snip...] > libiberty/ChangeLog: > > * regex.c: Suppress -Wuse-after-free. Was this part necessary? I'm wondering if it might be covering up an actual error that I'm seeing on CheriBSD on cfarm240...
[Bug jit/102824] building pdf/dvi documentation for libgccjit fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102824 --- Comment #9 from Eric Gallager --- I've been testing this on the compile farm, and there seems to be a wide amount of variation between machines with regards to whether this fails or not; I think it might have to do with different machines having different sphinx versions... I'm wondering if the minimum sphinx version documented to work in https://gcc.gnu.org/install/prerequisites.html needs to be updated? --- Comment #10 from Eric Gallager --- I've been testing this on the compile farm, and there seems to be a wide amount of variation between machines with regards to whether this fails or not; I think it might have to do with different machines having different sphinx versions... I'm wondering if the minimum sphinx version documented to work in https://gcc.gnu.org/install/prerequisites.html needs to be updated?
[Bug other/103331] There should be a rule to make build.log in the top-level Makefile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103331 --- Comment #3 from Eric Gallager --- (In reply to Eric Gallager from comment #2) > I'm assuming that the way that build.log is normally generated is by just > appending `| tee build.log` to the end of a normal `make` command? hm, doing it that way results in an empty `warning.log` when doing `make warning.log` to extract the warnings from `build.log`, even when warnings are printed during the actual build output; maybe I need to throw a `2>&1` in there...
[Bug c++/111842] Unable to disable conversion warning in case of _Float16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111842 --- Comment #10 from Eric Gallager --- (In reply to Andrew Pinski from comment #6) > (In reply to n.deshm...@samsung.com from comment #5) > > The code is part of a third party library hence adding a explicit cast is > > not possible. > > Well that third party library is NOT valid C++ code ... The whole point of > the warning (and the reason why -Wno-pedantic does not turn off the warning) > is point that out and more over point out the code should be fixed. That is not a reason that I have ever heard for not assigning a flag to a warning before. I was under the impression that the principle of "All warnings should have a flag assigned to them" held regardless of how invalid the code they warn about is, or how badly said code should be fixed. Again, see bug 44209.
[Bug middle-end/111843] [meta-bug] wrong-code due to -fstack-reuse=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111843 Eric Gallager changed: What|Removed |Added Keywords||meta-bug CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- Don't meta-bugs usually put all their other bugs in the "Depends on" field, rather than "Blocks"?
[Bug c++/111842] Unable to disable conversion warning in case of _Float16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111842 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- I think the part about the warning not being controlled by a specific flag is still valid, though? It'd fit under the bug 44209 meta-bug.
[Bug testsuite/103324] RFE: Add a `make quickcheck` or `make smoketest` Makefile target to allow only running a portion of the testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103324 --- Comment #11 from Eric Gallager --- (In reply to Eric Gallager from comment #10) > (In reply to Richard Biener from comment #2) > > Thus, > > > > make check RUNTESTFLAGS="execute.exp" > > make check RUNTESTFLAGS="dg-torture.exp" > > > Just confirming that the proper way to combine these would be: > make check RUNTESTFLAGS="execute.exp dg-torture.exp" > ...correct? > (The docs said something about being whitespace-delimited, but I wasn't > quite sure if that just applied to the globbing part, or also to the .exp > filenames...) (ok, from testing, it appears that that's correct...)
[Bug testsuite/103324] RFE: Add a `make quickcheck` or `make smoketest` Makefile target to allow only running a portion of the testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103324 --- Comment #10 from Eric Gallager --- (In reply to Richard Biener from comment #2) > Thus, > > make check RUNTESTFLAGS="execute.exp" > make check RUNTESTFLAGS="dg-torture.exp" Just confirming that the proper way to combine these would be: make check RUNTESTFLAGS="execute.exp dg-torture.exp" ...correct? (The docs said something about being whitespace-delimited, but I wasn't quite sure if that just applied to the globbing part, or also to the .exp filenames...)
[Bug other/103331] There should be a rule to make build.log in the top-level Makefile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103331 --- Comment #2 from Eric Gallager --- I'm assuming that the way that build.log is normally generated is by just appending `| tee build.log` to the end of a normal `make` command?
[Bug c/86418] warn about mismatch in type between argument and parameter type for declaration without prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86418 Eric Gallager changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #6 from Eric Gallager --- Possibly relevant to Florian Weimer's work on stricter warnings
[Bug c++/71283] Inconsistent location for C++ warning options in the manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71283 Eric Gallager changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #18 from Eric Gallager --- Florian Weimer was wondering about this general issue (of inconsistency in location of documentation for common C/C++ options) on the mailing lists recently: https://gcc.gnu.org/pipermail/gcc/2023-October/242669.html
[Bug c/111693] -Wuse-after-free is documented in the wrong location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111693 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=71283 --- Comment #9 from Eric Gallager --- related: bug 71283
[Bug c/111654] Introduce clang's invalid-noreturn warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111654 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #4) > Unfortunately, gcc does not have any patch tracking system I thought someone was getting a patchwork installation set up? ...ok yeah, here it is; it's being hosted on sourceware currently: https://patchwork.sourceware.org/project/gcc/list/ (could be made a little more discoverable from gcc.gnu.org IMO)
[Bug middle-end/111429] NO_COLOR env should disable color
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111429 Eric Gallager changed: What|Removed |Added URL||https://no-color.org/ Last reconfirmed||2023-10-01 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- Confirmed. https://no-color.org/ currently has GCC under its "Disabling color in software not supporting `NO_COLOR`" section.
[Bug ada/81114] GNAT mishandles filenames with UTF8 chars on case-insensitive filesystems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114 --- Comment #7 from Eric Gallager --- (In reply to simon from comment #6) > (In reply to simon from comment #1) > > Further: > > > > $ GNAT_FILE_NAME_CASE_SENSITIVE=1 gnatmake -c p*.ads > > gcc -c páck3.ads > > páck3.ads:1:10: warning: file name does not match unit name, should be > > "páck3.ads" > > > > The reason for this apparently-bizarre message is[1] that macOS takes > > the composed form (lowercase a acute) and converts it under the hood > > to what HFS+ insists on, the fully decomposed form (lowercase a, combining > > acute); thus the names are actually different even though they _look_ > > the same. > > This behaviour (I think it was an error) was fixed by darwin 19. Opening by > a name with the composed form now correctly finds the file named with the > fully decomposed form. OK, so do we still want to fix it for older darwin versions, or...?
[Bug c/111604] bogus warning: '#' flag used with ‘%m’ gnu_printf format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111604 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=88270 --- Comment #2 from Eric Gallager --- related to bug 88270?
[Bug target/111481] MacOS, linker issues with Xcode 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111481 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||iains at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to simon from comment #2) > A fix for the Ada issue is to link with the classic linker: > > $ gnatmake hello -largs -Wl,-ld_classic > gcc -c hello.adb > gnatbind -x hello.ali > gnatlink hello.ali -Wl,-ld_classic > $ This is annoying how Apple is reusing the name `ld_classic` for something new, after it previously referred to something else...
[Bug libstdc++/111390] 'make check-compile' target is not useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111390 --- Comment #3 from Eric Gallager --- (In reply to Jonathan Wakely from comment #2) > The fact nobody has tried to use it in 10+ years makes me think it's not all > that useful. Only reason I haven't tried to use it is because I didn't know it existed; if it were also available from the top-level Makefile, it would be more discoverable, and more likely to be used.
[Bug libstdc++/111390] 'make check-compile' target is not useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111390 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103324 CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- kinda related: bug 103324 (In reply to Jonathan Wakely from comment #0) > If we want to do compilation-only testing, I think it would be better to > modify the dejagnu procs so that "dg-do run" tests are treated as "dg-do > compile". Yes, I think this solution would be preferable to ripping it out entirely. Also, it would be useful if such a target were available tree-wide, rather than just for libstdc++.
[Bug other/111360] contrib/gcc_update: bad test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111360 --- Comment #5 from Eric Gallager --- (In reply to Jonathan Wakely from comment #4) > Fixed on trunk Cool, thanks. I'm wondering if it might be worthwhile to run shellcheck[1] on GCC's various shell scripts to catch similar mistakes? I just tried running it on all the ones in contrib/, but the output seemed rather noisy... [1]: https://www.shellcheck.net/
[Bug other/111368] contrib/test_summary should check to ensure the git branch being put in the email matches the branch actually tested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111368 --- Comment #3 from Eric Gallager --- (In reply to Jonathan Wakely from comment #2) > N.B. test_summary doesn't print that "[master r14-3825-g0d50fac]" string > itself, it just scrapes it from the logs, and the string in the logs comes > straight from the xgcc. xg++ etc. binaries. > > I don't think it's the test_summary script's job to correct bad info in the > logs. Well ok, maybe the check could be performed earlier, then, say build time or configure time?
[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #14 from Eric Gallager --- (In reply to Jakub Jelinek from comment #13) > I think the main problem of -Og for debug info is that we don't artificially > use all automatic vars at the end of their scopes, so if they aren't used > everywhere in the scope, they might not be available for debugging (or use > DW_OP_entry_value and the like that will only sometimes work but aren't > guaranteed to work all the time). That's bug 78685, isn't it?
[Bug other/111368] New: contrib/test_summary should check to ensure the git branch being put in the email matches the branch actually tested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111368 Bug ID: 111368 Summary: contrib/test_summary should check to ensure the git branch being put in the email matches the branch actually tested Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: egallager at gcc dot gnu.org Target Milestone: --- contrib/gcc_update will put the git branch being updated into gcc/REVISION. That's cool, except sometimes I'll change branches and forget to run contrib/gcc_update, meaning I'll have a stale gcc/REVISION left over. The branch name put in there will get used in other places, as well. Meanwhile, contrib/test_summary will put the branch name that it finds into the email subject line that it generates. Take a look at, say: https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/795648.html It says: "[master r14-3825-g0d50fac]" However, this wasn't actually the branch that I had tested in that particular set of test results; it should actually be users/me/autotools-tinkering in that case. The contrib/test_summary script should test the git branch that it's printing against the git branch that was actually tested to help guard against errors like this.
[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 --- Comment #32 from Eric Gallager --- (In reply to matoro from comment #31) > (In reply to Eric Gallager from comment #30) > > (In reply to matoro from comment #26) > > > We also had somebody report on IRC that they observed this on powerpc (not > > > sure what tuple), again with -j1. It does not seem to show up with -j2, > > > so > > > likely -j1 is necessary to trigger. > > > > I can also confirm that switching to -j2 makes this particular error go away > > It may make it "go away", but how can it be worked around on real > single-core systems? All that does is get lucky by throwing more > parallelism at it. I've been completely unable to even try out gccgo > because of this bug. Right, yes, this is still definitely a bug, I was just confirming that I was able to get the workaround to work for me personally
[Bug bootstrap/102665] ELF-specific configure flags should be rejected on non-ELF platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102665 --- Comment #7 from Eric Gallager --- Making some more progress on this: https://github.com/gcc-mirror/gcc/compare/master...cooljeanius:gcc:me/PR102665 Some notes: - There are a lot of these; I'm not quite sure how many to include in a single patch, or where I should stop... - I'm currently testing platform based on target, but I'm not quite sure if that's correct? Are these target flags or host flags? - All I've done so far has been to test to make sure that the flags are properly rejected on platforms where they're unsupported; I'd appreciate it if people could help with testing that they're still accepted on platforms where they're supposed to be accepted, though...
[Bug bootstrap/91972] Bootstrap should use -Wmissing-declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91972 Eric Gallager changed: What|Removed |Added Keywords|easyhack| --- Comment #9 from Eric Gallager --- so, I've tried enabling this flag while building, and one problem with it is that GCC's genfoo machinery for its garbage collection system creates a bunch of gt-*.h headers with a bunch of autogenerated gt_ggc_mx and gt_pch_nx functions in them that all get warned about... this will require messing with the generator utilities to get them to stop generating code that warns, so this will be more difficult than I thought; removing the "easyhack" keyword...
[Bug ada/81114] GNAT mishandles filenames with UTF8 chars on case-insensitive filesystems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Status|SUSPENDED |UNCONFIRMED Ever confirmed|1 |0 --- Comment #5 from Eric Gallager --- (In reply to simon from comment #4) > (In reply to Eric Botcazou from comment #2) > > When I said in comment 1 > > >I have to say that, great as it would be to have this fixed, the changes > >required would be extensive, and I can’t see that anyone would think it > >worth the trouble. > > I meant that coping with macOS’s HFS+ behaviour w.r.t. NFC vs NFD was > something it’d be unreasonable to spend effort on fixing. > > The main point of this PR is that you can’t use extended characters in > unit names on case-insensitive filesystems, *which includes Windows*. > Fixing that problem (I can see it might mean introducing a new adaint.c > interface "is filesystem UTF8?") would be a good thing. Can the compiler > use iconv? or Ada.Wide_Characters.Handling, > Ada.Strings.UTF_Encoding.[Wide_]Strings? > > The awkwardness discussed in comment 1 isn’t really a problem except > when compiling the offending unit from the command line; when compiled > as part of the closure by gnatmake there’s no problem, I guess gnatmake > reads the unit name in NFC and gets the file name in NFD from the file > system. > > I think there _is_ a problem in gprbuild but of course that’s nothing > to do with GCC. > > Please can this PR be reopened? Well, it was never closed in the first place, just marked as SUSPENDED, but I can put it back to UNCONFIRMED, I guess...
[Bug other/111360] contrib/gcc_update: bad test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111360 Eric Gallager changed: What|Removed |Added CC||belyshev at depni dot sinp.msu.ru --- Comment #1 from Eric Gallager --- git blame says that Serge Belyshev was the last to touch this line in r12-3370-g78b34cd8a803aa; adding to cc
[Bug other/111360] New: contrib/gcc_update: bad test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111360
Bug ID: 111360
Summary: contrib/gcc_update: bad test
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: egallager at gcc dot gnu.org
Target Milestone: ---
Running contrib/gcc_update on the gcc111 machine on the compile farm includes
the following message in its output:
./contrib/gcc_update[346]: test: argument expected
The line in question has:
if test -n $r; then
Shouldn't the "${r}" be quoted or something? Or maybe the issue is actually
that the command to set it on the previous lines is failing; it's set like
this:
# Open-coded version of "git gcc-descr" from
contrib/gcc-git-customization.sh
revision=`$GCC_GIT log -n1 --pretty=tformat:%h`
r=`$GCC_GIT describe --all --match 'basepoints/gcc-[0-9]*' HEAD \
| sed -n
's,^\(tags/\)\?basepoints/gcc-\([0-9]\+\)-\([0-9]\+\)-g[0-9a-f]*$,r\2-\3,p;s,^\(tags/\)\?basepoints/gcc-\([0-9]\+\)$,r\2-0,p'`;
[Bug other/17239] gcc_update not being writable while it is running
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17239 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- patch in question references CVS; is it still relevant now that gcc has migrated to git?
[Bug other/111359] contrib/gcc-git-customization.sh uses getent, which is non-portable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111359 Eric Gallager changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org --- Comment #1 from Eric Gallager --- git blame says Richard Earnshaw added the line in r10-6003-g545f5fad17ff0d; adding to cc
[Bug other/111359] New: contrib/gcc-git-customization.sh uses getent, which is non-portable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111359 Bug ID: 111359 Summary: contrib/gcc-git-customization.sh uses getent, which is non-portable Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: egallager at gcc dot gnu.org Target Milestone: --- On both darwin and AIX, running contrib/gcc-git-customization.sh will print messages like this: contrib/gcc-git-customization.sh[49]: getent: not found. Running `which getent` confirms: which: 0652-141 There is no getent in /usr/bin /etc /usr/sbin /usr/ucb /home/egallager/bin /usr/bin/X11 /sbin .. Suggest switching to a different sort of test when getent isn't available.
[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 --- Comment #30 from Eric Gallager --- (In reply to matoro from comment #26) > We also had somebody report on IRC that they observed this on powerpc (not > sure what tuple), again with -j1. It does not seem to show up with -j2, so > likely -j1 is necessary to trigger. I can also confirm that switching to -j2 makes this particular error go away
[Bug go/90685] failure of go in gcc-9.1.0 to build in i686-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90685 --- Comment #4 from Eric Gallager --- (In reply to Eric Gallager from comment #3) > (In reply to Eric Gallager from comment #2) > > I just got a similar error on gcc13 on the compile farm; config.guess there > > reports: > > > > $ ../config.guess > > x86_64-pc-linux-gnu > > > > So, confirmed. > > Oops wait make that gcc14, not gcc13 (since there isn't even any machine > called gcc13 on the compile farm in the first place) Also happens on the machine called "gcc45" on the compile farm, where ../config.guess reports i686-pc-linux-gnu
[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 Eric Gallager changed: What|Removed |Added Status|WAITING |NEW CC||egallager at gcc dot gnu.org --- Comment #29 from Eric Gallager --- just ran into this on the machine called "gcc45" on the compile farm with a single-job build; confirming (it's an i686-pc-linux-gnu machine)
[Bug go/90685] failure of go in gcc-9.1.0 to build in i686-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90685 Eric Gallager changed: What|Removed |Added Host||i?86-*-* --- Comment #3 from Eric Gallager --- (In reply to Eric Gallager from comment #2) > (In reply to Ian Lance Taylor from comment #1) > > What kind of system are you running on? > > > > What is the output of > > ../gcc-9.1.0/config.guess > > ? > > I just got a similar error on gcc13 on the compile farm; config.guess there > reports: > > $ ../config.guess > x86_64-pc-linux-gnu > > So, confirmed. Oops wait make that gcc14, not gcc13 (since there isn't even any machine called gcc13 on the compile farm in the first place)
[Bug go/90685] failure of go in gcc-9.1.0 to build in i686-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90685 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-09-09 --- Comment #2 from Eric Gallager --- (In reply to Ian Lance Taylor from comment #1) > What kind of system are you running on? > > What is the output of > ../gcc-9.1.0/config.guess > ? I just got a similar error on gcc13 on the compile farm; config.guess there reports: $ ../config.guess x86_64-pc-linux-gnu So, confirmed.
[Bug tree-optimization/107876] [13 Regression] ICE in verify_dominators, at dominance.cc:1184 (error: dominator of 4 should be 14, not 16) since r13-3749-g7314b98b1bcd382c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107876 Eric Gallager changed: What|Removed |Added Resolution|FIXED |--- Keywords||testsuite-fail CC||egallager at gcc dot gnu.org Status|RESOLVED|REOPENED --- Comment #8 from Eric Gallager --- (In reply to Francois-Xavier Coudert from comment #7) > The test case (g++.dg/tree-ssa/pr107876.C) fails on aarch64-darwin. > > FAIL: g++.dg/tree-ssa/pr107876.C -std=gnu++14 scan-tree-dump unswitch > "unswitching loop 1 on .switch. with condition: i_[0-9]+\\(D\\) == 2" > FAIL: g++.dg/tree-ssa/pr107876.C -std=gnu++17 scan-tree-dump unswitch > "unswitching loop 1 on .switch. with condition: i_[0-9]+\\(D\\) == 2" > FAIL: g++.dg/tree-ssa/pr107876.C -std=gnu++20 scan-tree-dump unswitch > "unswitching loop 1 on .switch. with condition: i_[0-9]+\\(D\\) == 2" > > The output says: > > ;; Function test17 (_Z6test17i, funcdef_no=0, decl_uid=4194, cgraph_uid=1, > symbol_order=0) > > Estimating # of iterations of loop 1 > g++.dg/tree-ssa/pr107876.C:21:7: optimized: unswitching loop 1 on 'if' with > condition: i_7(D) == 0 > g++.dg/tree-ssa/pr107876.C:21:7: note: optimized sizes estimated to 0 (true) > and 0 (false) from original size 16 reopening, then
[Bug c++/66487] sanitizer/warnings for lifetime DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66487 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=66163 CC||egallager at gcc dot gnu.org --- Comment #25 from Eric Gallager --- this came up on the gcc-help mailing list here: https://gcc.gnu.org/pipermail/gcc-help/2023-August/142848.html
