Assignee: unassigned at gcc dot gnu.org
Reporter: kilobyte at angband dot pl
Target Milestone: ---
void foo()
{
int c = 0;
do ; while (bar(&c, c));
}
riscv64-linux-gnu-gcc-11 -O2 -gsplit-dwarf -gdwarf-5 -c foo.i
foo.i:5:1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80271
Adam Borowski changed:
What|Removed |Added
CC||kilobyte at angband dot pl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Adam Borowski changed:
What|Removed |Added
CC||kilobyte at angband dot pl
--- Comment
-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&action=edit
reduced reproducer
The attached test case ICEs on x32 ta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59240
--- Comment #2 from Adam Borowski ---
Created attachment 31271
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31271&action=edit
smaller test case that compiles with 4.8
A funny thing: this ICE does not show in the original file, it just happ
Assignee: unassigned at gcc dot gnu.org
Reporter: kilobyte at angband dot pl
Created attachment 31267
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31267&action=edit
deltaed test case
When running g++ -O2, in a trunk snapshot 20131121-1 (from Debian) on attached
: unassigned at gcc dot gnu.org
Reporter: kilobyte at angband dot pl
Created attachment 31266
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31266&action=edit
deltaed test case
With gcc-snapshot 20131121-1, running g++ on the attached code fails with:
cc1plus: internal compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53330
--- Comment #3 from Adam Borowski 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 architectur
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53330
--- Comment #2 from Adam Borowski 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 re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55736
--- Comment #1 from Adam Borowski 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.
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53019
--- Comment #6 from Adam Borowski 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53019
--- Comment #5 from Adam Borowski 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-optimiz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53330
--- Comment #1 from Adam Borowski 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 cras
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
t org
ReportedBy: kilobyte at angband dot pl
GCC target triplet: i586-pc-msdosdjgpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41916
16 matches
Mail list logo