[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 for MERCHANTABILITY or FITNESS FOR A PARTICUL
[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)));}
| ^
[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 =
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 ***
[Bug c/97687] -Wfatal-errors prints some notes but not others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97687 Eric Gallager changed: What|Removed |Added Ever confirmed|0 |1 CC||dmalcolm at gcc dot gnu.org, ||egallager at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2024-06-26 --- Comment #1 from Eric Gallager --- Confirmed, I've seen this too. I think some of David's work with auto diagnostic groups might help here?
[Bug c/80528] reimplement gnulib's "useless-if-before-free" script as a compiler warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80528 Eric Gallager changed: What|Removed |Added CC||collin.funk1 at gmail dot com --- Comment #7 from Eric Gallager --- I see Collin Funk has been working on improving the gnulib version; cc-ing: https://lists.gnu.org/archive/html/bug-gnulib/2024-06/msg00193.html
[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 CC||fjahanian at apple dot com, ||mikestump at comcast dot net --- Comment #27 from Eric Gallager --- (In reply to Eric Gallager from comment #25) > Cross-referencing against > https://github.com/apple/swift-corelibs-libdispatch/issues/765 Note that there is some confusion in that issue about if/when Apple's GCC ever had c-blocks support; if someone knowledgeable on the topic could comment there, it'd be helpful.
[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 #26 from Eric Gallager --- (In reply to Eric Gallager from comment #25) > Cross-referencing against > https://github.com/apple/swift-corelibs-libdispatch/issues/765 Note that there is some confusion in that issue about if/when Apple's GCC ever had c-blocks support; if someone knowledgeable on the topic could comment there, it'd be helpful.
[Bug rtl-optimization/951] Documentation of compiler passes and sources very out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=951 --- Comment #15 from Eric Gallager --- (In reply to Richard Biener from comment #14) > (In reply to Andrew Pinski from comment #13) > > (In reply to Eric Gallager from comment #12) > > > Patch posted that might help with this a little bit: > > > https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648306.html > > > > I don't know how much of that patch overlaps with what Richi pushed: > > https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655312.html > > Forgot about that, but ISTR I approved something in the end? > > Anyway, reading over it the situation isn't as bad as described. So, is it ok to close this yet, or...?
[Bug c/71176] trunk/fixincludes/fixincl.c:162: bad % specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71176 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=78014 --- Comment #8 from Eric Gallager --- (In reply to Eric Gallager from comment #7) > (In reply to Jonathan Wakely from comment #5) > > Patch posted to https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01511.html > > I thought the format code for size_t was %zu? ...actually I guess we can't actually use that here; see discussion in bug 78014...
[Bug c/98819] Wall Wformat-signedness suggests %u for %u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98819 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=78014 --- Comment #8 from Eric Gallager --- Semi-related: bug 78014
[Bug c/28492] -Wsuggest-attribute=format points to vsnprintf() or related functions instead of the function that needs the attribute added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28492 Eric Gallager changed: What|Removed |Added Summary|-Wmissing-format-attribute |-Wsuggest-attribute=format |points to vsnprintf() or|points to vsnprintf() or |related functions instead |related functions instead |of the function that needs |of the function that needs |the attribute added |the attribute added --- Comment #7 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #6) > The option is called now -Wsuggest-attribute=format OK, I fixed this part of the title now, too
[Bug middle-end/47081] Macro usage too clever for localization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47081 Eric Gallager changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org, ||pinskia at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to Göran Uddeborg from comment #5) > These messages are no longer included in the po files. I'm not sure exactly > what prevents it; gengtype-state.cc is still not in po/EXCLUDES (while plain > gengtype.cc is). In any case, I would say we can close this report. Does > anyone want it kept open for any reason? I have no objection to closing it, but let's check with Andrew or Joseph first...
[Bug web/115391] Suggest add current size of git repository to git page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115391 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #7 from Eric Gallager --- Tips for doing this with the GitHub mirror of it: https://stackoverflow.com/questions/8646517/how-can-i-see-the-size-of-a-github-repository-before-cloning-it
[Bug bootstrap/112422] Build process does a redundant number of checks ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112422 --- Comment #4 from Eric Gallager --- (In reply to Sam James from comment #3) > There's some stuff we could cache for sure but it wouldn't be the majority > of the checks - stuff like finding tools like awk, sed should work > regardless of which stage we're in and so on. gawk and sed were potential host modules at one point previously, too, but it looks like they've been removed, so yeah I guess it'd be safe for them now... anything that might fall in this category should get checked against Makefile.def to make sure there aren't already potential modules for them for people trying to combine trees or something...
[Bug c/115496] RFE: new warning to detect suspicious multiline string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115496 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=99131 --- Comment #7 from Eric Gallager --- Semi-related: bug 99131 (for the case of missing commas)
[Bug c++/102223] no warning when calling member function on dangling reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102223 --- Comment #9 from Eric Gallager --- (In reply to Federico Kircheis from comment #6) > > are you expecting this to go under an existing warning flag, or a new one? > > Ideally -Wall, but there might already be some flags related to dangling > pointers and references. Yes, there's one for each of those now: -Wdangling-pointer and -Wdangling-reference, so I presume that this one would go under the latter...
[Bug c++/106393] Add warnings for common dangling problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106393 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to Marek Polacek from comment #2) > The rest may have to be implemented in the analyzer. Hm, let's ask David?
[Bug target/115409] avx512 intrinsics trigger -Wshift-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115409 Eric Gallager changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-June/65 ||4016.html CC||egallager at gcc dot gnu.org Keywords||patch --- Comment #4 from Eric Gallager --- (In reply to Collin Funk from comment #3) > I'll read the page you sent and send a patch to gcc-patches referencing this > bug report. Linking the sent patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654016.html
[Bug other/15694] fixincl.sh bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15694 --- Comment #4 from Eric Gallager --- Also, there's a lot of `shellcheck` output for fixincl.sh, too; should I paste it here?
[Bug other/40789] fixincludes/fixincl.c: duplicate call to close ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40789 --- Comment #2 from Eric Gallager --- (In reply to Eric Gallager from comment #1) > did you discover this with cppcheck or by looking manually? Also does -fanalyzer catch this?
[Bug other/37036] fixincludes does not understand sysroot!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37036 Eric Gallager changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #7 from Eric Gallager --- (In reply to jayk123 from comment #6) > I'll login later and put that in the bug once I reset password etc. Any progress on this?
[Bug target/105719] RFE: fixincludes should handle Frameworks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105719 Eric Gallager changed: What|Removed |Added Status|ASSIGNED|NEW CC||fxcoudert at gcc dot gnu.org Assignee|egallager at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #7 from Eric Gallager --- (In reply to Eric Gallager from comment #6) > (In reply to Iain Sandoe from comment #4) > > Created attachment 55084 [details] > > Implement the use of fixed framework headers > > > > this was a proof-of-principle exercise while looking into issues caused by > > implementing __has_feature () [PR60512]. > > > > This does not have any of the mechanism to *create* or *install* the fixed > > headers (for my testing I just built a > > CoreFoundation.framework/Headers/CFBase.h and edited bye hand to fix the > > problems found). > > > > So, still plenty to do ;) > > Remind me to test this patch later; I've kind of forgotten where I was with > this... distracted with other stuff... (maybe I should unassign it from > myself?) Unassigning from myself due to being distracted by too many other things; maybe FX would like to take over?
[Bug analyzer/111567] RFE: support __attribute__((counted_by)) in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111567 Eric Gallager changed: What|Removed |Added Last reconfirmed||2024-06-06 Status|UNCONFIRMED |NEW Keywords||diagnostic CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Eric Gallager --- Confirmed.
[Bug middle-end/32911] Function __attribute__ ((idempotent))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32911 --- Comment #8 from Eric Gallager --- It might also be worth comparing against the attributes [[unsequenced]] and [[reproducible]] proposed for the C standard: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2956.htm
[Bug other/115268] gcc --target --sysroot support?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115268 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=46489 --- Comment #3 from Eric Gallager --- (In reply to Andrew Pinski from comment #1) > This is a huge project. That involves finishing up removing target macros > into target hooks. (this is bug 46489, right?) > And a bunch more things. There has been many attempts > over the years in this direction but never finishes up.
[Bug libbacktrace/115212] testsuite should produce DejaGnu style summary, log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115212 --- Comment #3 from Eric Gallager --- (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?
[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 CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- I think there's another bug for this, but I can't seem to remember which one at the moment...
[Bug c++/77465] [DR909] rejected C-style cast involving casting away constness from result of conversion operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77465 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- Maybe at least special-case the -Wold-style-cast warning to say something special about it?
[Bug bootstrap/115077] bootstrap fails with in-tree isl-0.25/6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115077 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- (In reply to Iain Sandoe from comment #0) > The isl configure checks for this support using AX_CXX_COMPILE_STDCXX_17 > which updates CXX to include the addition of -std=c++17, if that is required > to enable it. LMK if you open a bug with the autoconf-archive about that macro
[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008 --- Comment #13 from Eric Gallager --- (In reply to Jonathan Wakely from comment #12) > There's nothing fake about them, they are definitely inline functions as far > as the language rules. But in some cases we don't want the compiler to use > that fact as an optimisation hint. "quasi_inline"? "pseudo_inline"? "unoptimizable_inline"? "strictly_inline"? "honorary_inline"? "inline_in_name_only"? "ceremonially_inline"?
[Bug c++/71482] Add -Wglobal-constructors warning option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71482 --- Comment #9 from Eric Gallager --- (In reply to Jonathan Wakely from comment #8) > (In reply to Eric Gallager from comment #6) > > Another reason this warning might be wanted: name mangling and demangling of > > global constructors has been buggy for awhile now; see bug 54254 > > Looks like that's just a problem demangling the symbol name to print it in a > human-readable form. What's buggy about the mangling? Well, I guess I was just remembering that "mangler dogfooding" proposal that would have added a checking option to ensure that every mangling of a symbol name that the mangler emits can also be demangled by the demangler... that didn't go in, did it? If it had, this would be an example of something that might trip it up...
[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008 --- Comment #11 from Eric Gallager --- (In reply to Jan Hubicka from comment #8) > Reading the discussion again, I don't think we have a way to make inline > keyword ignored by inliner. We can make not_really_inline attribute (better > name would be welcome). "fake_inline"?
[Bug other/101166] Add SPDX license identifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101166 --- Comment #3 from Eric Gallager --- The FSFE's REUSE tool could be helpful for this: https://github.com/fsfe/reuse-tool
[Bug tree-optimization/99475] [11 Regression] bogus -Warray-bounds accessing an array element of empty structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99475 Eric Gallager changed: What|Removed |Added Keywords||needs-bisection --- Comment #8 from Eric Gallager --- (In reply to Siddhesh Poyarekar from comment #7) > This doesn't appear to be reproducible on trunk anymore, should we close it? Might be worth bisecting to find out when exactly it was fixed, but I'll leave that decision up to someone else to make...
[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=2474, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=56009 --- Comment #7 from Eric Gallager --- (In reply to Eric Gallager from comment #6) > Another reason this warning might be wanted: name mangling and demangling of > global constructors has been buggy for awhile now; see bug 54254 Some more bugs about global constructors/destructors that might lead one to want this warning: bug 2474 and bug 56009
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #78 from Eric Gallager --- (In reply to Ilya Leoshkevich from comment #77) > Apparently fixing the message in GCC will produce maintenance overhead [1]. > If that's not very important to you, I'd rather leave this message as is. > > [1] https://gcc.gnu.org/pipermail/gcc-patches/2024-April/648775.html OK, I haven't actually seen GCC emit the message in the wild myself yet, actually; I only came across it due to searching for bugs related to MSan...
[Bug c++/114928] #pragma packed(push, 1) should give the same warning as __attribute__((packed))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114928 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=60972 --- Comment #1 from Eric Gallager --- There are a number of other bugs open regarding inconsistencies between #pragma pack and __attribute__((packed)); see for instance bug 60972 and related bugs (not sure if this is a dup or even fully related, but it's at least worth putting under "See Also"...)
[Bug target/79646] Typos in vax.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79646 --- Comment #5 from Eric Gallager --- (In reply to Abe from comment #4) > Anybody who wants to chime in, but especially Eric Gallager: please let me > know whether or not my patch looks good enough for submission to the > gcc-patches mailing list, and if not then _why_ not [please]. I think it looks fine to submit; if there are any problems with it, the review will happen there on the mailing list
[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?
