[Bug target/63304] Aarch64 pc-relative load offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304 --- Comment #13 from David Abdurachmanov david.abdurachmanov at gmail dot com --- Created attachment 34416 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34416action=edit 31-lines, minimal testcase I am adding 31-lines minimal testcase. Should be good enough for GCC testsuite. $ gcc -O0 -c pr63304-testcase.c /tmp/ccKdBqsL.s: Assembler messages: /tmp/ccKdBqsL.s:58: Error: pc-relative load offset out of range /tmp/ccKdBqsL.s:62: Error: pc-relative load offset out of range Yesterday I looked into RTL output and assembly of some failures for OpenLoops. The function was 400+K lines in assembly. On x86_64 it was something 180+K lines of assembly and ~1.3MB for function body size. I can confirm that offset is above 1MB mark and it was trying to load __float128/long double to q1 from constant pool for passing to `addtf3`.
[Bug c++/64491] warning: loop exit may only be reached after undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491
joona.kiiski at iki dot fi changed:
What|Removed |Added
CC||joona.kiiski at iki dot fi
--- Comment #2 from joona.kiiski at iki dot fi ---
Hi,
My name is Joona Kiiski, I'm one the authors of Stockfish chess software
(https://stockfishchess.org/). This bug was originally reported to us a week
ago.
After initial analysis it looked obviously like a gcc bug, so we advised the
reporter to raise a bug against GCC. Unfortunately, he wasn't able to give you
nearly enough details. I hope that what I can provide below meets your
expectations:
- Environment: qemu-x86-64 running debian sid
- GCC: Debian snapshot 20141812 5.0
- The bug appears when compiling the Stockfish master branch from
https://github.com/official-stockfish/Stockfish.git with this snapshot.
- For you convenience I've reduced the problem to:
test.cpp
int A[8];
int B[8];
int C;
int main() {
for (int f = 0; f = 7; ++f)
A[f] = f;
for (int f = 0; f = 7; ++f)
B[f] = (f 0 ? A[f - 1] : 0) | (f 7 ? A[f + 1] : 0);
C = B[7];
}
/test.cpp
Compile with
Makefile
CXXFLAGS += -O3 -flto
LDFLAGS += $(CXXFLAGS)
test: test.o
$(CXX) -o $@ test.o $(LDFLAGS)
/Makefile
Files above are also viewable at
https://github.com/official-stockfish/Stockfis/tree/gcc_bug/src
This produces the bogus warning mentioned in the original bug report.
If you need any further details, please let me know.
Kind Regards,
Joona Kiiski
[Bug fortran/64555] Fail to compile array pointer to derived-type components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64555 Thomas Fanning thfanning at gmail dot com changed: What|Removed |Added Severity|blocker |major
[Bug c++/64491] [5 Regression] incorrect warning: loop exit may only be reached after undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2015-01-04 00:00:00 |2015-1-10 CC||Joost.VandeVondele at mat dot ethz ||.ch Summary|warning: loop exit may only |[5 Regression] incorrect |be reached after undefined |warning: loop exit may only |behavior|be reached after undefined ||behavior Known to fail||5.0 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- The incorrect warning is confirmed. I wonder if this incorrect analysis could lead to wrong code generation.
[Bug fortran/64555] Fail to compile array pointer to derived-type components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64555 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Keywords||ice-on-valid-code Known to fail||4.8.5, 4.9.3, 5.0 Severity|major |normal --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Fortran PRs are 'normal' or below.
[Bug libstdc++/64553] [5 Regression] Missing '# ifdef _GLIBCXX_USE_WCHAR_T' in src/c++11/cxx11-shim_facet.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64553 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-01-10 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |5.0 Summary|Missing '# ifdef|[5 Regression] Missing '# |_GLIBCXX_USE_WCHAR_T' in|ifdef _GLIBCXX_USE_WCHAR_T' |src/c++11/cxx11-shim_facet. |in |cc |src/c++11/cxx11-shim_facet. ||cc Ever confirmed|0 |1
[Bug c++/32039] Using declaration accepts non-visible members from base classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32039 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||ville.voutilainen at gmail dot com Resolution|--- |INVALID --- Comment #7 from Ville Voutilainen ville.voutilainen at gmail dot com --- This is invalid. [namespace.udecl]/3 says that if the declaration names a constructor, the nested-name-specifier shall name a direct base, but if the declaration names something else than a constructor, indirect bases are fine. The name is looked up by member name lookup, which will look in A first, and the hiding in B does not matter. Clang agrees with this interpretation.
[Bug fortran/64555] New: Fail to compile array pointer to derived-type components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64555 Bug ID: 64555 Summary: Fail to compile array pointer to derived-type components Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: thfanning at gmail dot com When assigning an array pointer to a scalar component of an array of a derived type, compilation fails with undefined span.n. Given the following code, test.f90: module mod_abc type a integer :: item end type type(a), pointer :: array(:) integer, pointer :: item(:) = NULL() contains subroutine init(n) integer :: n allocate(array(n)) item = array%item ! problem occurs here end subroutine end module program test use mod_abc integer, parameter :: n = 10 integer :: i print *, Hello, World! call init(n) do i = 1,n array(i)%item = i enddo do i = 1,n print (i6,': ',i6), i, item(i) enddo end program On an Intel architecture... gfortran -m32 test.f90: /var/folders/l9/qcd__g594cv5qn_nc1nwyvvrd6xjn9/T//ccmNxERg.s:209:non-relocatable subtraction expression, _span.0 minus L2$pb /var/folders/l9/qcd__g594cv5qn_nc1nwyvvrd6xjn9/T//ccmNxERg.s:209:symbol: _span.0 can't be undefined in a subtraction expression /var/folders/l9/qcd__g594cv5qn_nc1nwyvvrd6xjn9/T//ccmNxERg.s:93:non-relocatable subtraction expression, _span.0 minus L1$pb /var/folders/l9/qcd__g594cv5qn_nc1nwyvvrd6xjn9/T//ccmNxERg.s:93:symbol: _span.0 can't be undefined in a subtraction expression gfortran -m64 test.f90: Undefined symbols for architecture x86_64: _span.0, referenced from: ___mod_abc_MOD_init in ccyXTbtG.o _MAIN__ in ccyXTbtG.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status On an embedded ARM architecture: gfortran test.f90: /tmp/cccNTntp.o: In function `__mod_abc_MOD_init': span.f90:(.text+0x1b4): undefined reference to `span.0' /tmp/cccNTntp.o: In function `MAIN__': span.f90:(.text+0x38c): undefined reference to `span.0' collect2: ld returned 1 exit status HOWEVER, if optimization is used on the ARM, then the code compiles correctly: gfortran -O test.f90 ./a.out Hello, World! 1: 1 2: 2 3: 3 4: 4 5: 5 6: 6 7: 7 8: 8 9: 9 10: 10
[Bug fortran/64555] Fail to compile array pointer to derived-type components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64555 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-01-10 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- I think this is a duplicate of pr34640 and/or pr40737.
[Bug fortran/64522] [4.8/4.9/5 Regression] Free-form source code: -Wline-truncation is no longer enabled by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64522 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Sat Jan 10 15:49:37 2015 New Revision: 219424 URL: https://gcc.gnu.org/viewcvs?rev=219424root=gccview=rev Log: 2015-01-10 Tobias Burnus bur...@net-b.de PR fortran/64522 * invoke.texi (Wline-truncation): Document new behaviour. * lang.opt (Wline-truncation): Add Init(-1). * options.c (gfc_post_options): If -Wline-truncation is unset, enable it for free-form source files; for the latter, also use -Werror=line-truncation, unless -Wno-error has been specified. 2015-01-10 Tobias Burnus bur...@net-b.de PR fortran/64522 * gfortran.dg/line_length_5.f90: Change dg-warning to dg-error and add dg-excess-errors. * gfortran.dg/line_length_6.f90: New. * gfortran.dg/line_length_7.f90: New. * gfortran.dg/line_length_8.f90: New. * gfortran.dg/line_length_9.f90: New. * gfortran.dg/line_length_10.f90: New. * gfortran.dg/line_length_11.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/line_length_10.f90 trunk/gcc/testsuite/gfortran.dg/line_length_11.f90 trunk/gcc/testsuite/gfortran.dg/line_length_6.f90 trunk/gcc/testsuite/gfortran.dg/line_length_7.f90 trunk/gcc/testsuite/gfortran.dg/line_length_8.f90 trunk/gcc/testsuite/gfortran.dg/line_length_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/line_length_4.f90 trunk/gcc/testsuite/gfortran.dg/line_length_5.f90
[Bug c++/64491] warning: loop exit may only be reached after undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491 --- Comment #3 from joona.kiiski at iki dot fi --- The correct link is: https://github.com/official-stockfish/Stockfish/tree/gcc_bug/src
[Bug c++/32039] Using declaration accepts non-visible members from base classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32039 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Status|RESOLVED|NEW Resolution|INVALID |--- --- Comment #9 from Ville Voutilainen ville.voutilainen at gmail dot com --- Pardon that, I failed to notice that part (and yes, sorry I missed it in the original report). Back to open, then. I think the standard needs to be clarified about what it wants. :)
[Bug fortran/60334] Segmentation fault on character pointer assignments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60334 Andre Vehreschild vehre at gmx dot de changed: What|Removed |Added CC||vehre at gmx dot de --- Comment #4 from Andre Vehreschild vehre at gmx dot de --- Patch available in: https://gcc.gnu.org/ml/fortran/2015-01/msg00048.html
[Bug testsuite/62250] FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=lib -O2 -lcaf_single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62250 --- Comment #14 from David Edelsohn dje at gcc dot gnu.org --- It seems to be fixed on AIX again. The status is confusing with the flurry of patches.
[Bug c++/32039] Using declaration accepts non-visible members from base classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32039 --- Comment #8 from Harald van Dijk harald at gigawatt dot nl --- (In reply to Ville Voutilainen from comment #7) This is invalid. [namespace.udecl]/3 says that if the declaration names a constructor, the nested-name-specifier shall name a direct base, but if the declaration names something else than a constructor, indirect bases are fine. Yes, but you're ignoring p14 (now p17 in N4140) which was mentioned right in the initial report, which adds The base class members mentioned by a using-declaration shall be visible in the scope of at least one of the direct base classes of the class where the using-declaration is specified. That is not limited to constructors, that is a separate requirement in the standard that GCC and clang both fail to implement.
[Bug ada/64548] Lost visibility of package System after raise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64548 --- Comment #1 from simon at pushface dot org --- As you may have gathered, I’m building an RTS. It turns out that the fault is triggered - regardless of -gnatg - if there is a-except.ads in the same directory which says “private with System;”. I have resolved this for myself by changing Ada.Exceptions.Exception_Id to “new Integer”.
[Bug rtl-optimization/64557] get_addr in true_dependence_1 cannot handle VALUE inside an expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64557 --- Comment #1 from wmi at google dot com --- The experimental patch is to call get_addr for VALUE of base before plus other constant, when creating mem_addr for dependence check and for store_info. bootstrap and regression on x86_64-linux-gnu are ok. Index: dse.c === --- dse.c(revision 219421) +++ dse.c(working copy) @@ -1564,6 +1564,7 @@ record_store (rtx body, bb_info_t bb_inf = rtx_group_vec[group_id]; mem_addr = group-canon_base_addr; } + mem_addr = get_addr (mem_addr); if (offset) mem_addr = plus_constant (get_address_mode (mem), mem_addr, offset); } @@ -2177,6 +2178,7 @@ check_mem_read_rtx (rtx *loc, bb_info_t = rtx_group_vec[group_id]; mem_addr = group-canon_base_addr; } + mem_addr = get_addr (mem_addr); if (offset) mem_addr = plus_constant (get_address_mode (mem), mem_addr, offset); }
[Bug c++/32039] Using declaration accepts non-visible members from base classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32039 --- Comment #10 from Ville Voutilainen ville.voutilainen at gmail dot com --- Ok, this is http://open-std.org/JTC1/SC22/WG21/docs/cwg_closed.html#1960 which says The rule was introduced because the hiding of a base class member by an intermediate derived class is potentially intentional and should not be capable of circumvention by a using-declaration in a derived class. The consensus of CWG preferred not to change the restriction. So yes, we need to fix this. :)
[Bug rtl-optimization/64557] get_addr in true_dependence_1 cannot handle VALUE inside an expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64557 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #2 from Paul Pluzhnikov ppluzhnikov at google dot com --- Google ref: b/18933287
[Bug lto/64374] [5.0 regression] LTO ICE in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64374 --- Comment #4 from Dmitry G. Dyachenko dimhen at gmail dot com --- start FAIL r218767
[Bug ada/64556] New: Aspect Preelaborate is ignored on library-level subprogram
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64556 Bug ID: 64556 Summary: Aspect Preelaborate is ignored on library-level subprogram Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Attempting to mark a library-level supbprogram as preelaborable via an aspect doesn’t work; you still need to use the pragma. This: with System; procedure Last_Chance_Handler (Message : System.Address; Line : Integer) with Preelaborate, Export, Convention = C, External_Name = __gnat_last_chance_handler; results in arm-eabi-gcc -c -gnatpgn -gnatqQ -nostdinc -ffunction-sections -fdata-sections -g -O0 -g -O1 -fno-inline -fno-toplevel-reorder a-except.adb a-except.adb:21:06: warning: cannot depend on Last_Chance_Handler (wrong categorization) a-except.adb:21:06: warning: preelaborated unit cannot depend on non-preelaborated unit Also in gcc version 5.0.0 20141228 (experimental) (GCC)
[Bug c++/57971] Improve copy elision when returning structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57971
Eelis gcc-bugzilla at contacts dot eelis.net changed:
What|Removed |Added
CC||gcc-bugzilla at contacts dot
eelis
||.net
--- Comment #1 from Eelis gcc-bugzilla at contacts dot eelis.net ---
struct foo { foo(); foo(foo const ); };
foo bar();
foo fast(bool b) {
if (b) return foo();
return bar();
}
/* produces (with -O3):
_Z4fastb:
.LFB0:
testb%sil, %sil
pushq%rbx
movq%rdi, %rbx
jne.L6
call_Z3barv
movq%rbx, %rax
popq%rbx
ret
.p2align 4,,10
.p2align 3
.L6:
call_ZN3fooC1Ev
movq%rbx, %rax
popq%rbx
ret
*/
foo slow(bool b) {
if (b) return foo();
foo f = bar();
return f;
}
/* produces (with -O3):
_Z4slowb:
.LFB1:
pushq%rbx
movq%rdi, %rbx
subq$16, %rsp
testb%sil, %sil
jne.L11
leaq15(%rsp), %rdi
call_Z3barv
leaq15(%rsp), %rsi
movq%rbx, %rdi
call_ZN3fooC1ERKS_
addq$16, %rsp
movq%rbx, %rax
popq%rbx
ret
.p2align 4,,10
.p2align 3
.L11:
call_ZN3fooC1Ev
addq$16, %rsp
movq%rbx, %rax
popq%rbx
ret
*/
[Bug rtl-optimization/64557] New: get_addr in true_dependence_1 cannot handle VALUE inside an expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64557
Bug ID: 64557
Summary: get_addr in true_dependence_1 cannot handle VALUE
inside an expr
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wmi at google dot com
We saw a bug in dse2 after porting the patch
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01209.html from gcc-4_9 to
google-4_9 branch. From the analysis below, I think the problem exists but is
hidden in trunk and gcc-4_9 too. I cannot extract a small testcase to show it
independently without turning on some optimization in google-4_9, so I just
described it here:
We have such IR in a case:
The IR before dse2:
(insn/f 67 4 68 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8])
(reg/f:DI 6 bp)) contentads/adx/mixer/auction/candidate.cc:14 -1
(nil))
(insn/f 68 67 69 2 (set (reg/f:DI 6 bp)
(reg/f:DI 7 sp)) contentads/adx/mixer/auction/candidate.cc:14 -1
(nil))
(insn/f 70 69 71 2 (parallel [
(set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int -24 [0xffe8])))
(clobber (reg:CC 17 flags))
(clobber (mem:BLK (scratch) [0 A8]))
]) contentads/adx/mixer/auction/candidate.cc:14 -1
(nil))
(note 71 70 2 2 NOTE_INSN_PROLOGUE_END)
(insn 7 3 9 2 (set (mem/c:SI (reg/f:DI 7 sp) [0 MEM[(void *)D.3507754]+0 S4
A128])
(const_int 0 [0])) ./ads/base/money.h:67 90 {*movsi_internal}
(nil))
(insn 9 7 10 2 (set (mem/c:HI (reg/f:DI 7 sp) [0 MEM[(void *)D.3507754]+0 S2
A128])
(const_int 21333 [0x5355])) ./ads/base/money.h:68 92 {*movhi_internal}
(nil))
(insn 10 9 11 2 (set (mem/c:QI (plus:DI (reg/f:DI 7 sp)
(const_int 2 [0x2])) [0 MEM[(void *)D.3507754]+2 S1 A16])
(const_int 68 [0x44])) ./ads/base/money.h:68 93 {*movqi_internal}
(nil))
(insn 11 10 12 2 (set (reg:SI 0 ax [orig:87 D.3507754 ] [87])
(mem/c:SI (reg/f:DI 7 sp) [0 D.3507754+0 S4 A128]))
./ads/base/money.h:302 90 {*movsi_internal}
(expr_list:REG_EQUIV (mem/c:SI (plus:DI (reg/f:DI 20 frame)
(const_int -16 [0xfff0])) [0 D.3507754+0 S4 A128])
(nil)))
...
(insn 15 13 17 2 (set (mem/c:SI (reg/f:DI 7 sp) [0 MEM[(void *)D.3507756]+0 S4
A128])
(const_int 0 [0])) ./ads/base/money.h:67 90 {*movsi_internal}
(nil))
The IR after dse2:
The store in insn 10 is deleted. The other part is the same as above.
(mem/c:QI (plus:DI (reg/f:DI 7 sp) (const_int 2 [0x2])) in insn10 is regarded
to have no alias with (mem/c:SI (reg/f:DI 7 sp) in insn11, which is wrong. This
is because with the applied patch, get_addr is used to extract original
addresses for x_addr and mem_addr before they are used to find_base_term and
used in base_alias_check. See the description of x_addr and mem_addr below:
x is (mem/c:SI (reg/f:DI 7 sp)
x_addr before calling get_addr is:
(value:DI 4:12939 @0x84355f8/0x84354a0)
x_addr after calling get_addr is:
(plus:DI (value:DI 3:8637 @0x84355e8/0x8435478)
(const_int -24 [0xffe8]))
x_addr_base is: (address:DI -4)
mem is (mem/c:QI (plus:DI (reg/f:DI 7 sp) (const_int 2 [0x2]))
mem_addr before calling get_addr is:
(plus:DI (value:DI 4:12939 @0x84355f8/0x84354a0)
(const_int 2 [0x2]))
mem_addr after calling get_addr is: // Notice: get_addr cannot handle plus
expr, so it returns the origin expr.
(plus:DI (value:DI 4:12939 @0x84355f8/0x84354a0)
(const_int 2 [0x2]))
mem_addr_base is: (address:DI -1)
// value:DI 4:12939 @0x84355f8/0x84354a0 corresponds to reg/f:DI 7 sp
// value:DI 3:8637 @0x84355e8/0x8435478 corresponds to reg/f:DI 6 bp
// address:DI -1 corresponds to reg/f:DI 7 sp
// address:DI -4 corresponds to reg/f:DI 6 bp
x_addr_base and mem_addr_base are different, and unique_base_value_p will
return true for (address:DI -1) and (address:DI -4), so base_alias_check will
return 0, which is wrong.
I think the root cause of the problem is get_addr can only handle VALUE but
cannot handle VALUE inside an expr, like:(plus:DI (value:DI 4:12939
@0x84355f8/0x84354a0) (const_int 2 [0x2])), so find_base_term cannot know
x_addr and mem_addr actually have the same base.
[Bug ipa/64559] New: ICE at -Os on x86_64-linux-gnu in remove_unreachable_nodes, at ipa.c:582
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64559
Bug ID: 64559
Summary: ICE at -Os on x86_64-linux-gnu in
remove_unreachable_nodes, at ipa.c:582
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-Os only on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It is a regression from 4.9.x.
It seems to be the same as PR 64068, but -fno-ipa-icf does not make this ICE
disappear.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20150110 (experimental) [trunk revision 219421] (GCC)
$
$ gcc-trunk -O1 small.c; a.out
$ gcc-4.9 -Os small.c; a.out
$
$ gcc-trunk -Os -fno-ipa-icf small.c
small.c:36:1: internal compiler error: in remove_unreachable_nodes, at
ipa.c:582
}
^
0x91228d symbol_table::remove_unreachable_nodes(_IO_FILE*)
../../gcc-trunk/gcc/ipa.c:582
0x110910b ipa_inline
../../gcc-trunk/gcc/ipa-inline.c:2198
0x110910b execute
../../gcc-trunk/gcc/ipa-inline.c:2564
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
$
$ gcc-trunk -Os small.c
small.c:36:1: internal compiler error: in remove_unreachable_nodes, at
ipa.c:582
}
^
0x91228d symbol_table::remove_unreachable_nodes(_IO_FILE*)
../../gcc-trunk/gcc/ipa.c:582
0x110910b ipa_inline
../../gcc-trunk/gcc/ipa-inline.c:2198
0x110910b execute
../../gcc-trunk/gcc/ipa-inline.c:2564
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
$
-
int a, b, c, d;
struct S
{
int f0;
};
static int
fn1 (int p)
{
return p == 0 || a;
}
static int
fn2 ()
{
d = fn1 (c);
return 0;
}
static int
fn3 (struct S p)
{
p.f0 || fn2 ();
if (fn1 (1))
b = 0;
return 0;
}
int
main ()
{
struct S e = { 1 };
fn3 (e);
return 0;
}
