[Bug driver/40960] POSIX requires that option -D have a lower precedence than -U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40960 Eric Gallager changed: What|Removed |Added See Also||https://github.com/ossf/wg- ||best-practices-os-developer ||s/issues/658 --- Comment #7 from Eric Gallager --- (In reply to Vincent Lefèvre from comment #0) > [This concerns the POSIX c99 utility, but gcc should probably behave in the > same way, as on some platforms, c99 is gcc.] > > In http://www.opengroup.org/onlinepubs/9699919799/utilities/c99.html POSIX > specifies Update: the new link for this is: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/c17.html This was pointed out in the following GitHub issue: https://github.com/ossf/wg-best-practices-os-developers/issues/658
[Bug bootstrap/109310] --enable-link-mutex is quite duplicate to --enable-link-serialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109310 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- (In reply to GCC Commits from comment #3) > The master branch has been updated by Martin Liska : > > https://gcc.gnu.org/g:8b2766e87dbf0d20808bc92d8e6ee7f876d19ab2 > > commit r13-6929-g8b2766e87dbf0d20808bc92d8e6ee7f876d19ab2 > Author: Martin Liska > Date: Wed Mar 29 14:52:42 2023 +0200 > > configure: deprecate --enable-link-mutex option > > PR bootstrap/109310 > > gcc/ChangeLog: > > * configure.ac: Emit a warning for deprecated option > --enable-link-mutex. > * configure: Regenerate. IMO this should also get a mention in the GCC 13 release notes: https://gcc.gnu.org/gcc-13/changes.html
[Bug bootstrap/117407] [15 regression] bootstrap fails after r15-4847-g79a75b1f551821
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117407 Eric Gallager changed: What|Removed |Added Keywords||build, diagnostic CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=44209 --- Comment #4 from Eric Gallager --- Also, the warning involved here not having its own flag is an example of bug 44209
[Bug web/117401] Spell that ./configure --enable-link-mutex is deprecated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117401 --- Comment #4 from Eric Gallager --- (In reply to Jakub Jelinek from comment #3) > That doesn't really matter. Anybody who used the option in GCC 13/14 got > that deprecation message. They might not have seen it, though, as it is easy for warning messages to get lost in the sea of configure output
[Bug web/117401] Spell that ./configure --enable-link-mutex is deprecated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117401 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Jakub Jelinek from comment #1) > We should just remove the option, it has been deprecated already in GCC 13. I don't see that mentioned in its release notes: https://gcc.gnu.org/gcc-13/changes.html
[Bug bootstrap/117396] gcc/configure --help should print --disable-multilib instead of --enable-multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117396 Eric Gallager changed: What|Removed |Added Keywords||build, documentation CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- If this had been fixed previously, I probably wouldn't have gotten in the habit of making my configure lines as long as I currently do!
[Bug preprocessor/94535] __LINE__ value changed for function-like macro invocations spanning multiple lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #14 from Eric Gallager --- (In reply to Alisdair Meredith from comment #13) > As this has shipped for two releases now (gcc9 and 10) I recommend closing > as Works As Designed, citing C standard paper N2322 as reason for the change. "Works As Designed" could mean any of FIXED, INVALID, WORKSFORME, or WONTFIX; which specifically did you mean?
[Bug preprocessor/111900] newlines in arguments in function-like macros are not preserved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111900 Eric Gallager changed: What|Removed |Added Keywords||documentation Last reconfirmed||2024-10-29 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- Confirmed that the documentation still contains the line in question; linking to it for reference: https://gcc.gnu.org/onlinedocs/cpp/Newlines-in-Arguments.html
[Bug preprocessor/77723] Add a diagnostic note for macro functions which take one argument but have more than one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77723 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=101125 --- Comment #2 from Eric Gallager --- bug 101125 is kinda similar
[Bug c/101125] warn when a construct would become invalid if a function were replaced by a function-like macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101125
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
Blocks||87403
--- Comment #3 from Eric Gallager ---
I modified the testcase a bit to include the suggested fix as its own line:
$ cat 101125.c
struct s { int a, b; };
void f (int);
#define F(X) f(X)
void g (void)
{
f ((struct s){0,1}.a); /* dg-warning "" */
F ((struct s){0,1}.a); /* dg-error "passed 2 arguments, but takes just 1" */
F (((struct s){0,1}.a)); /* dg-bogus "passed 2 arguments, but takes just 1"
*/
}
$
I get the following diagnostics from it:
$ /usr/local/bin/gcc -c -Wall -Wextra -Wtraditional -pedantic -Wc++-compat
101125.c
101125.c: In function 'g':
101125.c:4:6: warning: traditional C rejects ISO C style function definitions
[-Wtraditional]
4 | void g (void)
| ^
101125.c:6:14: warning: traditional C rejects automatic aggregate
initialization [-Wtraditional]
6 | f ((struct s){0,1}.a); /* dg-warning "" */
| ^
101125.c:7:23: error: macro "F" passed 2 arguments, but takes just 1
7 | F ((struct s){0,1}.a); /* dg-error "passed 2 arguments, but takes
just 1" */
| ^
101125.c:3:9: note: macro "F" defined here
3 | #define F(X) f(X)
| ^
101125.c:7:23: warning: function-like macro "F" must be used with arguments in
traditional C [-Wtraditional]
7 | F ((struct s){0,1}.a); /* dg-error "passed 2 arguments, but takes
just 1" */
| ^
101125.c:7:3: error: 'F' undeclared (first use in this function)
7 | F ((struct s){0,1}.a); /* dg-error "passed 2 arguments, but takes
just 1" */
| ^
101125.c:7:3: note: each undeclared identifier is reported only once for each
function it appears in
101125.c:8:15: warning: traditional C rejects automatic aggregate
initialization [-Wtraditional]
8 | F (((struct s){0,1}.a)); /* dg-bogus "passed 2 arguments, but takes
just 1" */
| ^
101125.c:3:16: note: in definition of macro 'F'
3 | #define F(X) f(X)
|^
$
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug preprocessor/93677] Create a warning for duplicate macro definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93677 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- clang calls this -Wmacro-redefined, for reference: https://clang.llvm.org/docs/DiagnosticsReference.html#wmacro-redefined
[Bug c/80653] Enhancement: better location info for -Wunsafe-loop-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80653 Eric Gallager changed: What|Removed |Added Severity|normal |enhancement
[Bug driver/37820] need command line option that prints all defaults and predefined macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37820 --- Comment #3 from Eric Gallager --- (In reply to brian from comment #1) > To list predefined macros, use -dM with an empty input file, e.g. "gcc > -dM -E -
[Bug preprocessor/98021] #warning issues redundant diagnostic lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=105963 --- Comment #18 from Eric Gallager --- Another bug about the underliner printing excess output: bug 105963
[Bug other/117263] genautomata.cc does not compile with -DNDEBUG due to unused but set variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117263 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Keywords||build --- Comment #1 from Eric Gallager --- Hi, thanks for the patch! Please send it to the gcc-patches mailing list for review.
[Bug libstdc++/117221] Add smoketest for alternative compiler for libstdc++ headers (like CXX_UNDER_TEST)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117221 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 #2 from Eric Gallager --- Related: bug 103324 for a more general smoketest
[Bug go/113143] Remove usage of ucontext.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143 --- Comment #18 from Eric Gallager --- (In reply to Sergey Fedorov from comment #17) > (In reply to Eric Gallager from comment #15) > > This is one of the things blocking bug 46986, isn't it? > > ucontext is supported on macOS, AFAIK. Only on certain versions of it, though; review the discussion in 46986 for further details
[Bug go/113143] Remove usage of ucontext.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #15 from Eric Gallager --- This is one of the things blocking bug 46986, isn't it?
[Bug target/117150] mstack-protector-guard-symbol= is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117150 Eric Gallager changed: What|Removed |Added Ever confirmed|0 |1 CC||egallager at gcc dot gnu.org Last reconfirmed||2024-10-16 Status|UNCONFIRMED |NEW --- Comment #1 from Eric Gallager --- Hm, that's strange, the Option Summary page says that it should be under x86 Options: https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html ...but then when going to actually look there, it isn't there: https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html So, confirmed, I guess. (btw the cross-referencing between the two pages could be a bit better, IMO)
[Bug c++/117156] not applied option “-Wchanges-meaning”
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117156 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Keywords||diagnostic, documentation --- Comment #6 from Eric Gallager --- Maybe Marek can update the blog post?
[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Bug 89863 depends on bug 47170, which changed state. Bug 47170 Summary: [cppcheck][PATCH] found resource leaks in gcc/intl/localealias.c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47170 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX
[Bug other/47170] [cppcheck][PATCH] found resource leaks in gcc/intl/localealias.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47170 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- GCC no longer contains this file; closing.
[Bug target/49564] [cppcheck][patch] fixed resource and memory leaks in /gcc/gcc/config/alpha/host-osf.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49564 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- (In reply to Martin Ettl from comment #0) > Created attachment 24619 [details] > proposed patch to fix the issues > > cppcheck revealed two resource leaks and a memory leak in > /gcc/gcc/config/alpha/host-osf.c. > > Please refer the attached patch that fixed the issues. > > Best regards from the cppcheck team > > Martin Please send the patch to the gcc-patches mailing list for review, if it still applies. Although it looks like the whitespace may need a bit of cleanup to be consistent.
[Bug pch/79306] ICE on valid code building WebRTC with PCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79306 Eric Gallager changed: What|Removed |Added Summary|ICE on valid code |ICE on valid code building ||WebRTC with PCH Resolution|--- |INVALID Status|WAITING |RESOLVED CC||egallager at gcc dot gnu.org Keywords||ice-on-valid-code, ||needs-reduction, ||needs-testcase --- Comment #2 from Eric Gallager --- (In reply to Richard Biener from comment #1) > Usually an invalid use of PCH not correctly diagnosed. GCC 4.8 is no longer > maintained and later releases contain mitigations against more invalid uses > so please check at least GCC 5. Reporter never got back with this info, so closing.
[Bug pch/54050] Add support for chaining of PCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54050 Eric Gallager changed: What|Removed |Added Summary|chaining|Add support for chaining of ||PCH CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- retitling to clarify
[Bug target/87832] AMD pipeline models are very costly size-wise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87832 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #14 from Eric Gallager --- so is this fixed now?
[Bug c++/92900] Cannot use member of packed struct in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92900 --- Comment #5 from Eric Gallager --- (In reply to Eric Gallager from comment #1) > possibly related to bug 60972 ...and, from the other direction, bug 68160 and bug 36566
[Bug jit/102824] building pdf/dvi documentation for libgccjit fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102824 Eric Gallager changed: What|Removed |Added Status|WAITING |NEW --- Comment #14 from Eric Gallager --- (In reply to Eric Gallager from comment #13) > (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. ...thus, moving from WAITING back to NEW.
[Bug bootstrap/43301] top-level configure script ignores ---with-build-time-tools
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43301 --- Comment #9 from Eric Gallager --- (In reply to Eric Gallager from comment #8) > we've got an idea that I just need to test (well, either I, or someone else, I guess...)
[Bug c/108310] Some warnings that -Wtraditional-conversion causes to be emitted aren't actually controlled by it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108310 Eric Gallager changed: What|Removed |Added Assignee|egallager at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #7 from Eric Gallager --- (In reply to Eric Gallager from comment #6) > I think I might be able to figure this out myself Actually never mind, I forgot what I was thinking here; unassigning...
[Bug ada/81114] GNAT mishandles filenames with UTF8 chars on case-insensitive filesystems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114 --- Comment #10 from Eric Gallager --- (In reply to simon from comment #9) > Created attachment 56140 [details] > C demonstrator > > As noted in comment 8, the C compiler doesn’t have a problem with > finding a file with a combining filename when the #include > directice uses a composed filename. clang has -Wnonportable-include-path, which judging by the text looks like it's for case differences only, but if adding it for GCC, too, we'd probably want to extend it to handle this sort of thing as well: https://clang.llvm.org/docs/DiagnosticsReference.html#wnonportable-include-path
[Bug c/117059] Make -Wzero-as-null-pointer-constant available in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059 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=77502 --- Comment #1 from Eric Gallager --- If making it available for C, too, it would be worthwhile to fix bug 77502 while at it, too
[Bug c++/77502] -Wzero-as-null-pointer-constant : misleading/imprecise messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77502 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=91187 --- Comment #5 from Eric Gallager --- See bug 91187 for another -Wzero-as-null-pointer-constant bug
[Bug jit/111396] Segfault when using -flto with libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111396 --- Comment #6 from Eric Gallager --- (In reply to Antoni from comment #5) > I believe so, but there might always be cases that we need to fix. > Why do you ask? Did you get any issue? I was just wondering if I could close it.
[Bug jit/111396] Segfault when using -flto with libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111396 --- Comment #4 from Eric Gallager --- (In reply to GCC Commits from comment #3) > The master branch has been updated by David Malcolm : > > https://gcc.gnu.org/g:8415bceea9d3ca86adc00ae8ad92deaec0457dd1 > > commit r14-7117-g8415bceea9d3ca86adc00ae8ad92deaec0457dd1 > Author: Antoni Boucher > Date: Wed Jan 10 17:13:20 2024 -0500 > > libgccjit: Fix GGC segfault when using -flto > > gcc/ChangeLog: > PR jit/111396 > * ipa-fnsummary.cc (ipa_fnsummary_cc_finalize): Call > ipa_free_size_summary. > * ipa-icf.cc (ipa_icf_cc_finalize): New function. > * ipa-profile.cc (ipa_profile_cc_finalize): New function. > * ipa-prop.cc (ipa_prop_cc_finalize): New function. > * ipa-prop.h (ipa_prop_cc_finalize): New function. > * ipa-sra.cc (ipa_sra_cc_finalize): New function. > * ipa-utils.h (ipa_profile_cc_finalize, ipa_icf_cc_finalize, > ipa_sra_cc_finalize): New functions. > * toplev.cc (toplev::finalize): Call ipa_icf_cc_finalize, > ipa_prop_cc_finalize, ipa_profile_cc_finalize and > ipa_sra_cc_finalize > Include ipa-utils.h. > > gcc/testsuite/ChangeLog: > PR jit/111396 > * jit.dg/all-non-failing-tests.h: Add note about test-ggc-bugfix. > * jit.dg/test-ggc-bugfix.c: New test. did this fix this successfully?
[Bug c/117028] [C2y] Implement N3353, Obsolete implicitly octal literals and add delimited escape sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117028 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=60523 --- Comment #3 from Eric Gallager --- Note that there's also bug 60523 about octal literals
[Bug bootstrap/116951] Use -D_GLIBCXX_ASSERTIONS for --enable-checking=yes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116951 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- (In reply to Andrew Pinski from comment #3) > Maybe add a new level for checking which can be later on included in yes. At > least then it can easily enabled and even enabled seperately from others. > E.g. someone could do even --enable-checking=release,stl I support this approach.
[Bug c/116920] GCC should warn about redundant case around default in switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116920 Eric Gallager changed: What|Removed |Added Keywords||diagnostic Blocks||87403 CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- I'd be careful to check how this interacts with the other switch-related warnings; sometimes I've added a default case like that just to silence -Wswitch-default. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug testsuite/112297] Failure of pr100936.c on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112297 --- Comment #6 from Eric Gallager --- (In reply to GCC Commits from comment #5) > The releases/gcc-12 branch has been updated by Iain D Sandoe > : > > https://gcc.gnu.org/g:0eb6f8874047f7e7f13027aaac14d3de276c5e69 > > commit r12-10370-g0eb6f8874047f7e7f13027aaac14d3de276c5e69 > Author: Francois-Xavier Coudert > Date: Mon Dec 11 09:26:23 2023 +0100 > > Testsuite: restrict test to nonpic targets > > The test is currently failing on x86_64-apple-darwin. > > gcc/testsuite/ChangeLog: > > PR testsuite/112297 > * gcc.target/i386/pr100936.c: Require nonpic target. > > (cherry picked from commit 02f562484c17522d79a482ac702a5fa3c2dfdd10) This is about as far back as it can be backported, correct? OK to close now?
[Bug other/116792] RFE: should we be able to generate diagnostics in HTML format?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116792 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- clang requires a separate `scan-build` executable to do this, doesn't it? Or have they changed that? I'm not necessarily saying that GCC should do likewise, just that it might be worthwhile to compare...
[Bug other/116613] RFE: support outputting diagnostics in *multiple* formats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- Yeah, in particular, I'd want to send text to stdout while also sending SARIF to a file that shares the input file's name, except with the .sarif extension. (i.e., compiling foo.c would create foo.sarif)
[Bug driver/116794] gcc -pipe does not work on macOS with as from Xcode 16 (on macOS 15)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116794 Eric Gallager changed: What|Removed |Added Last reconfirmed||2024-09-21 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Ever confirmed|0 |1 Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #2 from Eric Gallager --- (In reply to Andrew Pinski from comment #1) > Fixed by r15-3737-g33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e . Reopening because Iain said he wanted to backport the change to older branches.
[Bug rtl-optimization/116774] ICE bootstrapping on cfarm92 (a riscv64 machine)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116774 --- Comment #5 from Eric Gallager --- (In reply to Sam James from comment #3) > The problem is that it's riscv (so 11 is prehistoric in that context) and > it's also a huge generated file. > > tbh, I suspect if you re-run the failing command, it might even succeed. The > riscv boards often aren't very stable.. Hm, indeed, I'm trying it without the `-j2` this time, and it seems to be getting past that spot... maybe it was hitting some sort of resource limit due to the parallelism?
[Bug rtl-optimization/116774] ICE bootstrapping on cfarm92 (a riscv64 machine)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116774 --- Comment #2 from Eric Gallager --- well, I mean, it *ought* to be possible to bootstrap with GCC 11 as the host compiler, right? The "transition to C++14" thread on the mailing lists was just talking about raising the requirement for the host compiler to GCC 5, which is still significantly older than GCC 11...
[Bug target/116774] New: ICE bootstrapping on cfarm92 (a riscv64 machine)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116774 Bug ID: 116774 Summary: ICE bootstrapping on cfarm92 (a riscv64 machine) Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: egallager at gcc dot gnu.org Target Milestone: --- Host: riscv64-unknown-linux-gnu Target: riscv64-unknown-linux-gnu Build: riscv64-unknown-linux-gnu No special arguments to configure, building with 2 make jobs, and I got this ICE: g++ -std=c++11 -fno-PIE -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -fno-PIE -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libcody -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/../libbacktrace -o insn-emit-5.o -MT insn-emit-5.o -MMD -MP -MF ./.deps/insn-emit-5.TPo insn-emit-5.cc during RTL pass: jump insn-emit-5.cc: In function ‘rtx_def* gen_pred_indexed_ustorervvm4x2bfrvvm2qi(rtx, rtx, rtx, rtx, rtx, rtx)’: insn-emit-5.cc:65168:1: internal compiler error: Segmentation fault 65168 | } | ^ 0x3f3b33a77b __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0x3f3b33a827 __libc_start_main_impl ./csu/libc-start.c:392 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. make[3]: *** [Makefile:1194: insn-emit-5.o] Error 1 make[3]: *** Waiting for unfinished jobs rm gfdl.pod gcc.pod gcov-dump.pod gcov-tool.pod fsf-funding.pod gpl.pod cpp.pod gcov.pod lto-dump.pod make[3]: Leaving directory '/home/egallager/gcc/AAA_cfarm92.build/gcc' make[2]: *** [Makefile:5053: all-stage1-gcc] Error 2 make[2]: Leaving directory '/home/egallager/gcc/AAA_cfarm92.build' make[1]: *** [Makefile:25986: stage1-bubble] Error 2 make[1]: Leaving directory '/home/egallager/gcc/AAA_cfarm92.build' make: *** [Makefile:1099: all] Error 2
[Bug middle-end/44032] internals documentation is not legally safe to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44032 --- Comment #12 from Eric Gallager --- I'm hearing this came up at Cauldron this year... I wasn't there, so could somebody who was summarize in this bug report for us?
[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=37210 CC||egallager at gcc dot gnu.org --- Comment #38 from Eric Gallager --- Related: bug 37210 (in that they're both about cases where the build system should warn the user about trying to build from an unsupported directory setup)
[Bug other/116744] RFE: can generated SARIF file be a container for "everything" needed for a bug-report against gcc?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116744 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- I think tying this in with the existing -freport-bug option would make sense
[Bug preprocessor/96842] enhancement: copy clang Wheader-guard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96842 Eric Gallager changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-Septemb ||er/662836.html Keywords||patch --- Comment #3 from Eric Gallager --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662836.html
[Bug c/116642] miscompilation involving vfork child.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #31 from Eric Gallager --- (In reply to Xi Ruoyao from comment #30) > (In reply to Andrew Pinski from comment #29) > > That is: `-static -pie` which should remove the requirement of > > `-Wl,--no-dynamic-linker` too. > > > > Basically a (non-static) PIE binary requires using the dynamic loader to do > > the relocations while a static PIE does not. > > Actually -static-pie. -static-pie is different from -static -pie (with a > space) That's kind of confusing, tbh...
[Bug c++/54140] -Wswitch shouldn't complain about out-of-range values that are cast to the correct type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54140 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- There are several other bugs open about the interaction between -Wswitch and enums, too
[Bug c++/46457] Bogus warning about bitwise combination of enum flags in case statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46457 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-Septemb ||er/662214.html Keywords||patch CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- Jason has a patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662214.html
[Bug c/81665] Please introduce flags attribute for enums which will mimic one from C#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81665 --- Comment #7 from Eric Gallager --- This patch for bug 46457 looks kind of related: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662214.html
[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324 --- Comment #34 from Eric Gallager --- Yeah I think GCC should support the __attribute__ style syntax for this attribute, too
[Bug driver/110522] `-fdiagnostics-format=sarif-file`: file name conflicts / races
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110522 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- (In reply to David Malcolm from comment #4) > But it would also be nice to support multiple output streams e.g. > > -fdiagnostics-format=text,sarif-file=path/to/foo.sarif Yeah, I was hoping for multiple output streams myself, to be able to bring things closer to how `clang --analyze` operates (outputs analysis results to both stdout and a plist file)
[Bug target/116021] Ada build on Darwin: gen_il-main: Symbol not found: ___builtin_nested_func_ptr_created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021 --- Comment #11 from Eric Gallager --- Update: I finally managed to bootstrap using one of Simon Wright's releases: https://github.com/simonjwright/distributing-gcc/releases I still think there might be a bug in the build system somewhere leading to the wrong tools getting used, but since I've managed to build now, I'm not going to bother looking too much harder...
[Bug tree-optimization/116481] [12/13/14/15 Regression] `arrays of functions are not meaningful` error message happens with -W -Wall -O2 even though there are no arrays of function types used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116481 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #8 from Eric Gallager --- (In reply to Bruno Haible from comment #7) > (In reply to Richard Biener from comment #6) > > For portability you likely want to convert the function pointer to uintptr_t > > and only that to char */long *. That might also avoid GCCs diagnostic. > > Thanks for the attempted advice. But, no, converting a pointer to uintptr_t > and later back to a pointer is bad for portability: It does not work on the > CHERI architecture and its implementation on the ARM Morello chip > https://developer.arm.com/Architectures/Morello, because it loses the tag > bits that are essential for accessing the pointer. See > https://www.gnu.org/software/gnulib/manual/html_node/C99-features-avoided. > html and https://lists.gnu.org/archive/html/bug-gnulib/2023-12/msg00021.html > . Related to the CHERI part: bug 111908
[Bug c/80060] RFE: -Wformat knob to ignore same-width incorrect types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80060 --- Comment #2 from Eric Gallager --- Another example: off_t is sometimes defined as long long, and sometimes as just long, but in each case sizeof(off_t) == 8, so it shouldn't really matter whether you use "ll" or just "l" as the modifier for it
[Bug ada/116438] Ada FE should use libbacktrace to print backtraces on ICE with bug boxes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116438 --- Comment #4 from Eric Gallager --- (In reply to Eric Botcazou from comment #3) > In my experience a backtrace is not sufficient to debug compiler issues. It might not be sufficient on its own, but it'd at least be an improvement
[Bug ada/116438] Ada FE should use libbacktrace to print backtraces on ICE with bug boxes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116438 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||egallager at gcc dot gnu.org Last reconfirmed||2024-08-21 Ever confirmed|0 |1 --- Comment #1 from Eric Gallager --- Confirmed.
[Bug tree-optimization/109565] -Wstrict-overflow false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109565 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #7 from Eric Gallager --- I personally think it would be worthwhile to split out the pointer-related instances of -Wstrict-overflow into a separate flag (-Wstrict-pointer-overflow, perhaps), that can be toggled separately. In this case the user just wants to know about overflow on integers, but not pointers, but I can see of cases where a user might want the reverse (i.e., to know about overflow on pointers, but not on integers)
[Bug c/111654] Introduce clang's invalid-noreturn warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111654 --- Comment #8 from Eric Gallager --- (In reply to Julian Waters from comment #7) > I recently stumbled upon -Wno-attributes, which can apparently take a > parameter like -Wno-attributes=vendor:: and I think that's appropriate for > this particular situation. How does -Wno-invalid-noreturn, > -Wno-invalid-noreturn=explicit and -Wno-invalid-noreturn=implicit sound? I personally would just prefer hyphenated options, instead of using the equals sign for this. Having separate hyphenated options has the benefit of being individually toggleable, controllable by pragmas, and showing up properly in the diagnostic output.
[Bug testsuite/116252] variation in C++ filename extensions in testsuite ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116252 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- I think there should be at least one set of tests where the file extensions vary intentionally, just to exercise the driver's ability to handle them all correctly.
[Bug testsuite/88002] libbacktrace and libiberty tests don't use dejagnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88002 --- Comment #2 from Eric Gallager --- (In reply to Ian Lance Taylor from comment #1) > I really have no intention of running the libbacktrace tests under DejaGNU. > But if someone wants to copy the .sum file generation out of libgo (which > also does not use DejaGNU), that would be fine with me. I just took a look at the .sum file generation in libgo's Makefile.am and holy cow, that's really complicated; would all of that really be necessary for libbacktrace as well?
[Bug libbacktrace/115212] testsuite should produce DejaGnu style summary, log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115212 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=112396 --- Comment #4 from Eric Gallager --- (In reply to Eric Gallager from comment #3) > (In reply to Andrew Pinski from comment #2) > > (In reply to Eric Gallager from comment #1) > > > I think there's another bug for this, but I can't seem to remember which > > > one > > > at the moment... > > > > PR 88002 > > I think I might've actually been thinking of PR 112396? ...actually no, on second thought, PR 88002 is a better match, but I guess PR 112396 is still related to go under "See Also" at least...
[Bug fortran/80256] Cygwin test fail: bind_c_array_params_2.f90 scan-assembler-times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80256 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from Eric Gallager --- (In reply to anlauf from comment #7) > (In reply to nightstrike from comment #6) > > This fails on x86_64-w64-mingw32 as well. > > Can you provide details about that failure? > > It appears that the original report is fixed. re-closing
[Bug testsuite/102735] privatization-1-compute.c results in both XFAIL and PASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102735 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to GCC Commits from comment #2) > The master branch has been updated by Thomas Schwinge > : > > https://gcc.gnu.org/g:31c200c6e110ced8732332376e69c0958985b926 > > commit r12-5766-g31c200c6e110ced8732332376e69c0958985b926 > Author: Thomas Schwinge > Date: Wed Sep 22 12:42:41 2021 +0200 > > Make sure that we get unique test names if several DejaGnu directives > refer to the same line [PR102735] > > gcc/testsuite/ > PR testsuite/102735 > * lib/gcc-dg.exp (process-message): Make sure that we get unique > test names. Did this fix it?
[Bug go/94466] libgo reflect test compilation very slow on 64-bit SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94466 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Richard Biener from comment #1) > We need a var-tracking meta-bug ;) I thought I'd seen one, but can't seem to find it at the moment... maybe I'm misremembering...
[Bug testsuite/91437] Problem with multi-line test outputs on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91437 Eric Gallager changed: What|Removed |Added Keywords||diagnostic CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- since this is from the fortran testsuite specifically, I wonder how this relates to the project for moving fortran diagnostics to use the common diagnostics machinery? (I can't seem to the bug number for it at the moment...)
[Bug testsuite/90481] Unclean DejaGnu global state after ERROR in one '*.exp' file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90481 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- Are you sure that this is specific to GCC's usage of dejagnu, or is this an issue with upstream dejagnu?
[Bug testsuite/71931] build sysroot flags are not passed to target lib tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71931 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=79885 --- Comment #2 from Eric Gallager --- I wonder if this is related to bug 79885 at all?
[Bug testsuite/53222] dejagnu trims leading whitespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53222 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org, ||egallager at gcc dot gnu.org Keywords||diagnostic --- Comment #3 from Eric Gallager --- Diagnostic output formatting has changed a lot since this was filed; I wonder if it's still relevant?
[Bug go/56017] libgo testsuite log and summary file only contain a single test run (the last one)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56017
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
Severity|normal |minor
Summary|libgo testsuite does not|libgo testsuite log and
|support cross testing |summary file only contain a
||single test run (the last
||one)
--- Comment #15 from Eric Gallager ---
(In reply to Andreas Schwab from comment #14)
> testsuite/libgo.{log,sum} contains only a single test run (the last one).
Retitling, then.
[Bug testsuite/53028] add dg-pedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53028 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #12 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #7) > Another alternative could be if -pedantic warnings always were associated to > an option, then dg-warning tried to match that option. That would avoid > having to add three testcases. I think that this would probably be the best way to go.
[Bug preprocessor/116087] Add optional warning for too large macro expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116087 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2024-07-25 Status|UNCONFIRMED |NEW --- Comment #3 from Eric Gallager --- "-Wmacro-expansion-larger-than=" I guess? Anyways, confirmed.
[Bug target/116021] Ada build on Darwin: gen_il-main: Symbol not found: ___builtin_nested_func_ptr_created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021 --- Comment #9 from Eric Gallager --- Ah, looking at gcc/ada/gcc-interface/Makefile.in, perhaps the issue is that I need to set GNATLINK in my environment, too, besides just GNATMAKE and GNATBIND... perhaps the issue was arising due to having had a version mismatch previously...
[Bug target/116021] Ada build on Darwin: gen_il-main: Symbol not found: ___builtin_nested_func_ptr_created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021 --- Comment #7 from Eric Gallager --- Well ok, could someone send me a binary x86_64 build of GCC for darwin20 with Ada support that they can bootstrap with successfully, then, so that I can get back to bootstrapping, too? Either that, or send me the files that gen_il-main generates...
[Bug debug/96635] Feature request: PDB/Codeview support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96635 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mark at harmstone dot com Last reconfirmed||2024-07-22 Ever confirmed|0 |1
[Bug target/116021] Ada build on Darwin: gen_il-main: Symbol not found: ___builtin_nested_func_ptr_created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021 --- Comment #4 from Eric Gallager --- (In reply to Andreas Schwab from comment #3) > You need to use an older Ada compiler (13 or older) for bootstrapping, not > any of the broken intermediate versions between Aug 2023 and Jan 2024. I wonder if maybe there could be a configure check added for whether the Ada compiler is broken or not? Maybe one of the Ada maintainers could chime in?
[Bug debug/96635] Feature request: PDB/Codeview support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96635 --- Comment #5 from Eric Gallager --- (In reply to Mark Harmstone from comment #4) > (In reply to Andrew Pinski from comment #2) > > The patches to support CodeView is being added (and improved) for GCC 15. I > > am not sure how much will be finished by the release of GCC 15. > > Support for C is very nearly finished. I hope to get all the C++ stuff > (namespaces, templates, class member functions) done for GCC 15 too. OK to put you as the assignee for this?
[Bug target/116021] New: Ada build on Darwin: gen_il-main: Symbol not found: ___builtin_nested_func_ptr_created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021
Bug ID: 116021
Summary: Ada build on Darwin: gen_il-main: Symbol not found:
___builtin_nested_func_ptr_created
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: egallager at gcc dot gnu.org
CC: iains at gcc dot gnu.org
Target Milestone: ---
I was trying to figure this out with Iain on IRC the other day, but we never
managed to solve it, so I'm putting it here so it doesn't get lost:
Lately (as of r15-1899-g2b3027bea3f218) when I've been trying to build GCC with
Ada, I've been getting errors like the following:
mkdir -p ada/gen_il
cd ada/gen_il; gnatmake -q -g -gnata -gnat2012 -gnatw.g -gnatyg -gnatU
-I/Users/ericgallager/gcc_newgit/gcc/ada gen_il-main
# Ignore errors to work around finalization issues in older compilers
cd ada/gen_il; ./gen_il-main
dyld: lazy symbol binding failed: Symbol not found:
___builtin_nested_func_ptr_created
Referenced from:
/Users/ericgallager/gcc_newgit/abcdefghijklmnopqrstuvwxyz_01234567890.build/gcc/ada/gen_il/./gen_il-main
Expected in:
/Users/ericgallager/gcc_newgit/abcdefghijklmnopqrstuvwxyz_01234567890.build/./prev-gcc/libgcc_s.1.1.dylib
dyld: Symbol not found: ___builtin_nested_func_ptr_created
Referenced from:
/Users/ericgallager/gcc_newgit/abcdefghijklmnopqrstuvwxyz_01234567890.build/gcc/ada/gen_il/./gen_il-main
Expected in:
/Users/ericgallager/gcc_newgit/abcdefghijklmnopqrstuvwxyz_01234567890.build/./prev-gcc/libgcc_s.1.1.dylib
raised PROGRAM_ERROR : unhandled signal
make[3]: [ada/stamp-gen_il] Error 1 (ignored)
/Users/ericgallager/gcc_newgit/gcc/../move-if-change
ada/gen_il/seinfo_tables.ads ada/seinfo_tables.ads
mv: rename ada/gen_il/seinfo_tables.ads to ada/seinfo_tables.ads: No such file
or directory
make[3]: *** [ada/stamp-gen_il] Error 1
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2
Apparently __builtin_nested_func_ptr_created has been renamed to
__gcc_nested_func_ptr_created in recent revisions, so I don't get why the build
process is still looking for the old name? Here's what shows up when I search
the repo for the common part shared between those strings:
$ git grep _nested_func_ptr_created
gcc/ChangeLog:rename the library fallbacks to
__gcc_nested_func_ptr_created and
gcc/ChangeLog:* doc/invoke.texi: Rename these to
__gcc_nested_func_ptr_created
gcc/builtins.def:DEF_EXT_LIB_BUILTIN (BUILT_IN_GCC_NESTED_PTR_CREATED,
"__gcc_nested_func_ptr_created", BT_FN_VOID_PTR_PTR_PTR, ATTR_NOTHROW_LIST)
gcc/config/darwin.h: -U ___gcc_nested_func_ptr_created \
gcc/config/darwin.h: -exported_symbol ___gcc_nested_func_ptr_created \
gcc/doc/invoke.texi:@code{__gcc_nested_func_ptr_created} and
gcc/tree.cc: local_define_builtin
("__builtin___gcc_nested_func_ptr_created", ftype,
gcc/tree.cc:"__gcc_nested_func_ptr_created",
ECF_NOTHROW);
libgcc/ChangeLog:(__gcc_nested_func_ptr_created): Implement a basic
trampoline
libgcc/ChangeLog:* libgcc2.h (__gcc_nested_func_ptr_created): Change
type of last
libgcc/ChangeLog:* config/i386/heap-trampoline.c
(__gcc_nested_func_ptr_created):
libgcc/ChangeLog:* config/aarch64/heap-trampoline.c
(__gcc_nested_func_ptr_created):
libgcc/ChangeLog:(__gcc_nested_func_ptr_created): Likewise.
libgcc/ChangeLog:(__gcc_nested_func_ptr_created): Likewise.
libgcc/ChangeLog:__builtin_nested_func_ptr_created to
__gcc_nested_func_ptr_created and
libgcc/ChangeLog:__gcc_nested_func_ptr_created and
libgcc/ChangeLog:* libgcc2.h (__builtin_nested_func_ptr_created):
Declare.
libgcc/config/aarch64/heap-trampoline.c:void __gcc_nested_func_ptr_created
(void *chain, void *func, void *dst);
libgcc/config/aarch64/heap-trampoline.c:__gcc_nested_func_ptr_created (void
*chain, void *func, void *dst)
libgcc/config/i386/heap-trampoline.c:void __gcc_nested_func_ptr_created (void
*chain, void *func, void *dst);
libgcc/config/i386/heap-trampoline.c:__gcc_nested_func_ptr_created (void
*chain, void *func, void *dst)
libgcc/libgcc-std.ver.in: __gcc_nested_func_ptr_created
libgcc/libgcc2.h:extern void __gcc_nested_func_ptr_created (void *, void *,
void *);
$
So, none of the Ada source files used to build gen_il-main contain references
to it... I'm wondering if it might be due to the version of gnatmake I'm using
to bootstrap? Here's its version info:
$ /usr/local/bin/gnatmake --version
GNATMAKE 14.0.0 20231204 (experimental) [master 2fde54ad7be]
Copyright (C) 1995-2023, Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even
[Bug debug/96635] Feature request: PDB/Codeview support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96635 Eric Gallager changed: What|Removed |Added CC||mark at harmstone dot com --- Comment #3 from Eric Gallager --- (In reply to Andrew Pinski from comment #2) > The patches to support CodeView is being added (and improved) for GCC 15. I > am not sure how much will be finished by the release of GCC 15. > > BUT it might be the case there is enough for at least minidump already. Right, cc-ing Mark Harmstone, who has been the one submitting those patches.
[Bug c/116018] New: Feature request: #pragma GCC unpoison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116018 Bug ID: 116018 Summary: Feature request: #pragma GCC unpoison Product: gcc Version: 14.1.0 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: egallager at gcc dot gnu.org Target Milestone: --- Sometimes a header outside of my control will do #pragma GCC poison on an identifier that I disagree about its deservingness for poisoning. Say, for example, an identifier defined in another header outside of my control. In such a case, I would find it easier to just reverse the poisoning instead of trying get the upstream header(s) to change things. Some ideas of ways to achieve this: - a #pragma GCC unpoison, as per the title - have #pragma GCC poison support push and pop, as with #pragma GCC diagnostic push/pop, or any of the other pragmas with push/pop - have the errors caused by #pragma GCC poison instead be permerrors that can be downgraded to warnings, say with -Wno-error=poison or something
[Bug debug/96635] Feature request: PDB support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96635 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- I think I may have seen some patches for this, but don't have the links on-hand now...
[Bug c/6906] warn about asserts with side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6906 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #10 from Eric Gallager --- See also related issues bug 105369 and bug 44
[Bug middle-end/85563] [12/13/14/15 regression] -Wmaybe-uninitialized false alarm regression with __builtin_unreachable and GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=110405 --- Comment #27 from Eric Gallager --- (In reply to Andrew Pinski from comment #25) > (In reply to Richard Biener from comment #23) > > > > So somewhat of a pass ordering issue. The next CSE is DOM and then PRE. > > I was going to say this is related to PR 110405 but pointers don't record > ranges (nor nonzerobits) but have a different kind of flow senative > information. eh, I think it might be worth putting it under "See Also" anyways; doing so now...
[Bug driver/47229] Objective C and C++ compiler specific drivers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47229 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- Apparently some distros ship such drivers: https://lists.gnu.org/archive/html/bug-autoconf/2024-07/msg0.html
[Bug c/68524] Please support attributes between function definition and opening brace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68524 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- (In reply to Martin Sebor from comment #1) > Clang also supports the syntax with a warning. Yeah "with a warning" would be my preferred approach for GCC, too...
[Bug libstdc++/115885] Build errors when libstdc++ math.h included in extern "C" block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115885 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to Andrew Pinski from comment #2) > Note doing extern "C" around includes is bad form and is even undefined > according to the C++ standard. Perhaps g++ could issue a warning about it, then?
[Bug target/115880] [14 regression] GCC 14+ fails to parse CoreFoundation header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115880 --- Comment #3 from Eric Gallager --- (In reply to Iain Sandoe from comment #2) > I have posted patches (which need an update [on my shorter TODO] that > implement the availability attribute). That makes a fix unnecessary - I > would much rather pursue the implementation of the attribute than keep on > applying band-aid fixincludes - the latter have been causing us some > difficulties where SDKs change even within one OS rev. > > The availability patches are on my darwin branches, along with patches to > remove the existing fixincludes which break on some SDK versions. ...it looks like the caret is underlining the CF_INLINE macro, though, not the API_UNAVAILABLE junk at the end? If this *is* actually just the availability attributes again, then I guess this is just a dup of bug 90835... or maybe bug 109877?
[Bug target/115880] [14 regression] GCC 14+ fails to parse CoreFoundation header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115880
Eric Gallager changed:
What|Removed |Added
Known to work||10.4.0, 11.4.0, 12.3.0,
||14.0, 7.5.0, 8.5.0, 9.5.0
Known to fail||13.3.0, 14.1.0
--- Comment #1 from Eric Gallager ---
Ah wait, looks like 13 fails, too... 8 through 12 all work fine, though:
$ for i in $(seq 8 14); do gcc-mp-${i} --version && gcc-mp-${i} -c
cf_include.c; done
gcc-mp-8 (MacPorts gcc8 8.5.0_1) 8.5.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
gcc-mp-9 (MacPorts gcc9 9.5.0_1) 9.5.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
gcc-mp-10 (MacPorts gcc10 10.4.0_5+stdlib_flag) 10.4.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
gcc-mp-11 (MacPorts gcc11 11.4.0_1+stdlib_flag) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
gcc-mp-12 (MacPorts gcc12 12.3.0_4+stdlib_flag) 12.3.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
gcc-mp-13 (MacPorts gcc13 13.3.0_0+stdlib_flag) 13.3.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
In file included from
/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:43,
from cf_include.c:1:
/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:126:1:
error: attributes should be specified before the declarator in a function
definition
126 | CF_INLINE CFOptionFlags CFUserNotificationCheckBoxChecked(CFIndex i)
API_AVAILABLE(macos(10.0)) API_UNAVAILABLE(ios, watchos, tvos) {return
((CFOptionFlags)(1UL << (8 + i)));}
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:127:1:
error: attributes should be specified before the declarator in a function
definition
127 | CF_INLINE CFOptionFlags CFUserNotificationSecureTextField(CFIndex i)
API_AVAILABLE(macos(10.0)) API_UNAVAILABLE(ios, watchos, tvos) {return
((CFOptionFlags)(1UL << (16 + i)));}
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:128:1:
error: attributes should be specified before the declarator in a function
definition
128 | CF_INLINE CFOptionFlags CFUserNotificationPopUpSelection(CFIndex n)
API_AVAILABLE(macos(10.0)) API_UNAVAILABLE(ios, watchos, tvos) {return
((CFOptionFlags)(n << 24));}
| ^
gcc-mp-14 (MacPorts gcc14 14.1.0_0+stdlib_flag) 14.1.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
In file included from
/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:43,
from cf_include.c:1:
/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:126:1:
error: attributes should be specified before the declarator in a function
definition
126 | CF_INLINE CFOptionFlags CFUserNotificationCheckBoxChecked(CFIndex i)
API_AVAILABLE(macos(10.0)) API_UNAVAILABLE(ios, watchos, tvos) {return
((CFOptionFlags)(1UL << (8 + i)));}
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:127:1:
error: attributes should be specified before the declarator in a function
definition
127 | CF_INLINE CFOptionFlags CFUserNotificationSecureTextField(CFIndex i)
API_AVAILABLE(macos(10.0)) API_UNAVAILABLE(ios, watchos, tvos) {return
((CFOptionFlags)(1UL << (16 + i)));}
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/System/Library/Frameworks/CoreFoun
[Bug target/115880] New: [14 regression] GCC 14+ fails to parse CoreFoundation header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115880
Bug ID: 115880
Summary: [14 regression] GCC 14+ fails to parse CoreFoundation
header
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: egallager at gcc dot gnu.org
CC: iains at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-apple-darwin
Testcase:
$ cat cf_include.c
#include
$
My self-built copy of GCC (14.0) in /usr/local from last November compiles it
fine, but my MacPorts-built copy (14.1) in /opt/local from earlier this month
fails to compile it with:
$ /opt/local/bin/gcc -c cf_include.c
In file included from
/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:43,
from cf_include.c:1:
/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:126:1:
error: attributes should be specified before the declarator in a function
definition
126 | CF_INLINE CFOptionFlags CFUserNotificationCheckBoxChecked(CFIndex i)
API_AVAILABLE(macos(10.0)) API_UNAVAILABLE(ios, watchos, tvos) {return
((CFOptionFlags)(1UL << (8 + i)));}
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:127:1:
error: attributes should be specified before the declarator in a function
definition
127 | CF_INLINE CFOptionFlags CFUserNotificationSecureTextField(CFIndex i)
API_AVAILABLE(macos(10.0)) API_UNAVAILABLE(ios, watchos, tvos) {return
((CFOptionFlags)(1UL << (16 + i)));}
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:128:1:
error: attributes should be specified before the declarator in a function
definition
128 | CF_INLINE CFOptionFlags CFUserNotificationPopUpSelection(CFIndex n)
API_AVAILABLE(macos(10.0)) API_UNAVAILABLE(ios, watchos, tvos) {return
((CFOptionFlags)(n << 24));}
| ^
$
Perhaps the header needs to be fixincluded? If so, this bug would depend on bug
105719.
[Bug analyzer/115735] Analyzer misses trivial syslog() call in signal handler for -Wanalyzer-unsafe-call-within-signal-handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115735 --- Comment #12 from Eric Gallager --- (In reply to David Malcolm from comment #9) > Note that the POSIX list might not be redistributable, and the stuff in > glibc is probably under the GFDL rather than the GPL. Using glibc's is > probably the better bet; maybe we can get blanket permissions from the FSF > to regenerate this GCC file from glibc's docs? There's a similar problem with GCC's own docs, btw: bug 44032
[Bug analyzer/115735] Analyzer misses trivial syslog() call in signal handler for -Wanalyzer-unsafe-call-within-signal-handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115735 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=15338 CC||egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- See also bug 15338 for another issue with the compiler failing to know enough about syslog()
[Bug c/115684] No warning for pointer and enum field comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115684 --- Comment #5 from Eric Gallager --- (In reply to Andrew Pinski from comment #4) > C++ has -Wzero-as-null-pointer-constant . > Maybe it should be added for C also for at least C23 where nullptr exists > now. > > Note for C++, the enum value is NOT considered a null ptr. That is different > from C though. ...so it sounds like there should be a warning from -Wc++-compat, too, then?
[Bug c/115684] No warning for pointer and enum field comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115684
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment #2 from Eric Gallager ---
I modified it slightly and got it it to warn:
$ cat 115684.c
#include
int main(void) {
enum { myEnumField0, myEnumField1 };
int a = 0;
int *b = &a;
if (b == myEnumField0)
return puts("hey");
else if (b == myEnumField1)
return puts("yeh");
return a;
}
$ /usr/local/bin/gcc -c -g3 -O3 -Wall -Wextra -Wconversion -pedantic
-Wc++-compat -Wunused 115684.c
115684.c: In function 'main':
115684.c:9:16: warning: comparison between pointer and integer
9 | else if (b == myEnumField1)
|^~
$
So, it depends on the value of the enumerator, it seems. Also it's a problem
that the existing warning doesn't seem to be linked to a flag; see bug 44209
[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 --- Comment #31 from Eric Gallager --- (In reply to Sergey Fedorov from comment #29) > (In reply to Eric Gallager from comment #25) > > Cross-referencing against > > https://github.com/apple/swift-corelibs-libdispatch/issues/765 > > By the way, have you got some example code at hand which can serve as a > test? It must not require C/C++ 2011, of course. > I can try compiling it on 10.6 with its gcc. Check any of the testcases in either of these directories starting with the `block-` prefix: https://github.com/apple-oss-distributions/gcc/tree/e19d86db70127e160b1c32557e0bb80ebc272f92/gcc/testsuite/g%2B%2B.apple https://github.com/apple-oss-distributions/gcc/tree/e19d86db70127e160b1c32557e0bb80ebc272f92/gcc/testsuite/gcc.apple (It's got to be from that particular commit, because that was the last release before Apple stopped shipping the testsuite with their distribution of GCC)
[Bug analyzer/115662] New: Feature request: support for linking SARIF files together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115662 Bug ID: 115662 Summary: Feature request: support for linking SARIF files together Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: SARIF Severity: enhancement Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: egallager at gcc dot gnu.org Target Milestone: --- I brought this up on IRC previously, but since I can't remember when, I'll rewrite it the best I can here: Basically, there are cases where one might want to combine a bunch of SARIF files together into a single one. Previously I thought it might be possible to simply `cat` them together, but apparently it involves something a little bit more complex, like json-ld: https://json-ld.org/ So basically, my proposal is this: if a build has taken place where -fdiagnostics-format=sarif-file has been used for some of the individual compilations, and then the gcc driver is invoked for the linking step with that same flag, and it can still find all the SARIF files, it should then invoke json-ld (or possibly our own implementation) to link all of the SARIF files together into a new one. This would be helpful for applications that might want to just read a single SARIF file at a time.
[Bug preprocessor/48839] #error should terminate compilation - similar to missing #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48839 Eric Gallager changed: What|Removed |Added CC||valsiterb at gmail dot com --- Comment #14 from Eric Gallager --- *** Bug 79465 has been marked as a duplicate of this bug. ***
[Bug preprocessor/79465] infinite #include cycle is not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79465 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to valsiterb from comment #0) > I was working on a 20 years old codebase and in order to increase > compilation speed, I've converted all header guards to #ifdef ... #error to > go on and change things around, but there was a cycle somewhere in the > headers (a.h includes b.h but b.h also includes a.h) cpp does not detect > this case and goes on unil it gets killed. > I don't know if cycle detection is even supposed to part of the > preprocessor, but I expected that #error would make it stop there. I know > that there is -Wfatal-errors directive. Shouldn't #error be be fatal or am I > missing something? This is bug 48839; closing this as a dup of that. *** This bug has been marked as a duplicate of bug 48839 ***
