[Bug debug/102290] New: ICE with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102290
Bug ID: 102290
Summary: ICE with -gsplit-dwarf
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: kilobyte at angband dot pl
Target Milestone: ---
void foo()
{
int c = 0;
do ; while (bar(, c));
}
riscv64-linux-gnu-gcc-11 -O2 -gsplit-dwarf -gdwarf-5 -c foo.i
foo.i:5:1: internal compiler error: Segmentation fault
5 | }
| ^
0x7eff8a765eef ???
./signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7eff8a750e49 __libc_start_main
../csu/libc-start.c:314
(The original file was arch/riscv/kernel/cpu.c in linux-5.15-rc0)
Debian unstable, gcc-11 11.2.0-5, amd64 host, riscv64 target.
[Bug driver/80271] Support environment variable CLICOLOR_FORCE to enable -fdiagnostics-color
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80271 Adam Borowski changed: What|Removed |Added CC||kilobyte at angband dot pl --- Comment #6 from Adam Borowski --- Created attachment 44260 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44260=edit patch for CLICOLOR_FORCE So, here's a patch.
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 Adam Borowski changed: What|Removed |Added CC||kilobyte at angband dot pl --- Comment #28 from Adam Borowski --- Please tell me: what would be other likely uses for such an explicit (void) cast _other_ than trying to silence this warning? I can't think of any. Thus, I'd recommend to keep it simple and instead of adding complex really_strict_unavoidable_warn_unused_result options, just make (void) shut it down. It did the thing for many years before. There's too many system headers which abuse this attribute. On one hand you have realloc(), on the other write(STDERR, "error message").
[Bug middle-end/77991] New: ICE on x32 in plus_constant, at explow.c:87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77991 Bug ID: 77991 Summary: ICE on x32 in plus_constant, at explow.c:87 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: kilobyte at angband dot pl Target Milestone: --- Created attachment 39816 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39816=edit reduced reproducer The attached test case ICEs on x32 target in plus_constant, at explow.c:87, when compiling with -O1 or higher. No splat with -O0. The test case comes from a new version of qemu, where this ICE triggers on a number of files. No other target seems to be affected, as qemu built successfully on all architectures but x32. Host arch doesn't seem to matter, only target: reproducible with -mx32 on amd64 too. Reproduced on Debian packages of gcc 5.4.1-2, 6.2.0-6 and 20161006-1 trunk snapshot. Minimal invocation: (on x32) gcc -O -c f.i (on amd64) gcc -mx32 -O -c f.i
[Bug c++/59240] ICE in varpool_get_node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59240 --- Comment #2 from Adam Borowski kilobyte at angband dot pl --- Created attachment 31271 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31271action=edit smaller test case that compiles with 4.8 A funny thing: this ICE does not show in the original file, it just happened that an additional unrelated ICE popped up while deltaing a test case for another. It turns out that it's enough to just declare something as __weakref__, reducing the reproducer to a single line that compiles with g++-4.8.
[Bug c++/59240] New: ICE in varpool_get_node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59240 Bug ID: 59240 Summary: ICE in varpool_get_node Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kilobyte at angband dot pl Created attachment 31266 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31266action=edit deltaed test case With gcc-snapshot 20131121-1, running g++ on the attached code fails with: cc1plus: internal compiler error: in varpool_get_node, at cgraph.h:890 (the actual file the delta comes from is valid code).
[Bug tree-optimization/59241] New: ICE in initialize_flags_in_bb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59241 Bug ID: 59241 Summary: ICE in initialize_flags_in_bb Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: kilobyte at angband dot pl Created attachment 31267 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31267action=edit deltaed test case When running g++ -O2, in a trunk snapshot 20131121-1 (from Debian) on attached code, I get: internal compiler error: in initialize_flags_in_bb, at tree-into-ssa.c:459 void MenuDescriptor::init() ^ Lower optimization levels compile ok, so does any prior version, including snapshot 20131021-1 from a month ago. I don't know the build rituals for vanilla gcc (using Matthias Klose's snapshots instead), so sorry for not bisecting myself.
[Bug c++/53330] new() operator can return NULL on a zero-length allocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53330 --- Comment #2 from Adam Borowski kilobyte at angband dot pl 2013-03-29 13:13:21 UTC --- Created attachment 29750 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29750 updated testcase Updated testcase: it checks for invalid pointers (by freeing them), and returns an exit code (if it won't crash first).
[Bug c++/53330] new() operator can return NULL on a zero-length allocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53330 --- Comment #3 from Adam Borowski kilobyte at angband dot pl 2013-03-29 13:20:53 UTC --- Re-tested: * gcc-4.7.2 works on amd64, armhf, x32, fails on i386 * gcc-4.8.0 works on all of the above (all Debian) So it appears to be fixed in 4.8, at least on architectures I tried. Regardless of whether you'll fix it in 4.7 or not, it may be worth adding to the test suite.
[Bug lto/55736] New: lto ICE: tree code ''junl is not supported in LTO streams
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55736 Bug #: 55736 Summary: lto ICE: tree code ''junl is not supported in LTO streams Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: kilob...@angband.pl Created attachment 29004 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29004 massive amd64 example Another LTO breakage: lto1: internal compiler error: tree code ‘�’ is not supported in LTO streams Too bad, the smallest test case I have right now is 73 files big (attached, preprocessed for x86-64). Multidelta takes an enormous amount of time: after ~36 hours, it processed only first --level=0 run on four of the files, and they're still massive after deltaing. Thus, this test case is enormous, sorry. Fails on amd64 with gcc-4.8 svn 194557 (Debian 4.8-20121217-1) and gcc-snapshot (trunk), 4.7 works fine. So does 4.8 on i386.
[Bug lto/55736] lto ICE: tree code ''junl is not supported in LTO streams
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55736 --- Comment #1 from Adam Borowski kilobyte at angband dot pl 2012-12-19 00:57:12 UTC --- Fails on armhf as well: lto1: internal compiler error: tree code ‘\�PF9F���G�P.�.lЕ�0�+’ is not supported in LTO streams Works on i386.
[Bug lto/53019] [4.7 regression] ICE (segfault) with -flto=jobserver -fwhole-program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53019 --- Comment #6 from Adam Borowski kilobyte at angband dot pl 2012-06-01 08:04:43 UTC --- Ok, works correctly on current trunk as well. Since the testcase is messy and vulnerable to small alterations, and I guess the underlying bug fixes already include a test for it, it's probably pointless to try to introduce a variant of this one. Thus, nothing more to do here. Thanks guys for the fix, let's close this one.
[Bug lto/53019] [4.7 regression] ICE (segfault) with -flto=jobserver -fwhole-program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53019 --- Comment #5 from Adam Borowski kilobyte at angband dot pl 2012-05-30 21:56:36 UTC --- The changelog for Debian upload which included the fix is: * Update to SVN 20120509 (r187339) from the gcc-4_7-branch. - Fix PR libstdc++/53193, PR target/53272, PR tree-optimization/53239, PR tree-optimization/53195, PR target/52999, PR target/53228, PR tree-optimization/52633, PR tree-optimization/52870, PR target/48496, PR target/53199, PR target/52684, PR lto/52605, PR plugins/53126, PR debug/53174, PR target/53187, PR tree-optimization/53144, PR c++/53186, PR fortran/53255, PR fortran/53111, PR fortran/52864. Previous one was SVN 20120502 (r187039). I'll try trunk, although with its complex build system and me being quite busy, I sadly don't promise to finish it by tonight.
[Bug c++/53330] New: new() operator can return NULL on a zero-length allocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53330 Bug #: 53330 Summary: new() operator can return NULL on a zero-length allocation Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: kilob...@angband.pl Created attachment 27386 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27386 test case While in general C++ disallows zero-length arrays, they are explicitly allowed by the new() operator (C++ 3.7.4.1.2), with a guarantee that such an allocation will always return an unique non-null pointer. This worked correctly in 4.6 and before (and clang, and MSVC, ...), 4.7.0 (Debian 4.7.0-8) and trunk@187013 return null if elements of the array have a constructor and have sizeof() 0 themselves. For simple types or structs, all is ok. Also, if there's a constructor (no regards for sizeof(element)) and the array length is known at compile time, -Wuninitialized returns incorrect diagnostics that the returned value is uninitialized.
[Bug c++/53330] new() operator can return NULL on a zero-length allocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53330 --- Comment #1 from Adam Borowski kilobyte at angband dot pl 2012-05-12 11:01:23 UTC --- Correction: after testing with valgrind, the return value is indeed uninitialized; the pointer in contructor-but-no-fields case happens to be non-zero but is junk and will cause a crash when you try to free it.
[Bug c++/41916] New: psignal() declaration needs const char*
In libiberty/strsignal.c, psignal() is declared using non-const char. This causes a conflict with DJGPP headers which use const char just like POSIX and everyone else. This bug was found in gcc 4.4.2, but considering the unpopularity of this target, it's likely to be present in other recent versions as well. -- Summary: psignal() declaration needs const char* Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kilobyte at angband dot pl GCC target triplet: i586-pc-msdosdjgpp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41916
