[Bug target/55212] [SH] Switch from IRA to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Sun Aug 3 09:47:15 2014 New Revision: 213524 URL: https://gcc.gnu.org/viewcvs?rev=213524root=gccview=rev Log: PR target/55212 Create branch. Added: branches/sh-lra/ - copied from r213515, trunk/
[Bug pch/62001] Many tests fail with PCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62001 --- Comment #1 from Winston Smith smith_winston_6079 at hotmail dot com --- The same for g++: Running /home/zoidberg/1/gcc-4.9.1/gcc/testsuite/g++.dg/pch/pch.exp ... FAIL: g++.dg/pch/array-1.C -g -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/array-1.C -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/array-1.C -g assembly comparison FAIL: g++.dg/pch/array-1.C -O2 -g -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/array-1.C -O2 -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/array-1.C -O2 -g assembly comparison FAIL: g++.dg/pch/array-1.C -O2 -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/array-1.C -O2 -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/array-1.C -O2 assembly comparison FAIL: g++.dg/pch/empty.C -g -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/empty.C -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/empty.C -g assembly comparison FAIL: g++.dg/pch/empty.C -O2 -g -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/empty.C -O2 -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/empty.C -O2 -g assembly comparison FAIL: g++.dg/pch/empty.C -O2 -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/empty.C -O2 -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/empty.C -O2 assembly comparison FAIL: g++.dg/pch/externc-1.C -g -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/externc-1.C -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/externc-1.C -g assembly comparison FAIL: g++.dg/pch/externc-1.C -O2 -g -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/externc-1.C -O2 -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/externc-1.C -O2 -g assembly comparison FAIL: g++.dg/pch/local-1.C -g -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/local-1.C -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/local-1.C -g assembly comparison FAIL: g++.dg/pch/local-1.C -O2 -g -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/local-1.C -O2 -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/local-1.C -O2 -g assembly comparison FAIL: g++.dg/pch/local-1.C -O2 -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/local-1.C -O2 -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/local-1.C -O2 assembly comparison FAIL: g++.dg/pch/pch.C -g -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/pch.C -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/pch.C -g assembly comparison FAIL: g++.dg/pch/pch.C -O2 -g -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/pch.C -O2 -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/pch.C -O2 -g assembly comparison FAIL: g++.dg/pch/pch.C -O2 -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/pch.C -O2 -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/pch.C -O2 assembly comparison FAIL: g++.dg/pch/static-1.C -g -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/static-1.C -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/static-1.C -g assembly comparison FAIL: g++.dg/pch/static-1.C -O2 -g -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/static-1.C -O2 -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/static-1.C -O2 -g assembly comparison FAIL: g++.dg/pch/static-1.C -O2 -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/static-1.C -O2 -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/static-1.C -O2 assembly comparison FAIL: g++.dg/pch/system-1.C -g -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/system-1.C -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/system-1.C -g assembly comparison FAIL: g++.dg/pch/system-1.C -O2 -g -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/system-1.C -O2 -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/system-1.C -O2 -g assembly comparison FAIL: g++.dg/pch/system-1.C -O2 -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/system-1.C -O2 -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/system-1.C -O2 assembly comparison FAIL: g++.dg/pch/system-2.C -g -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/system-2.C -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/system-2.C -g assembly comparison FAIL: g++.dg/pch/system-2.C -O2 -g -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/system-2.C -O2 -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/system-2.C -O2 -g assembly comparison FAIL: g++.dg/pch/system-2.C -O2 -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/system-2.C -O2 -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/system-2.C -O2 assembly comparison FAIL: g++.dg/pch/template-1.C -g -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/template-1.C -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/template-1.C -g assembly comparison FAIL: g++.dg/pch/template-1.C -O2
[Bug pch/62001] New: Many tests fail with PCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62001 Bug ID: 62001 Summary: Many tests fail with PCH Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch Assignee: unassigned at gcc dot gnu.org Reporter: smith_winston_6079 at hotmail dot com gcc 4.9.1 compiles fine, but the tests for PCH fail: $ ../gcc-4.9.1/configure --prefix=/usr/ --with-local-prefix=/usr/local/ --with-native-system-header-dir=/usr/include/ --disable-libada --enable-libssp --enable-libquadmath --disable-libsanitizer --enable-nls --with-included-gettext --enable-shared --enable-threads --disable-bootstrap --enable-languages=c,c++,fortran,go,objc,obj-c++ --enable-werror --enable-gather-detailed-mem-stats --disable-multilib checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /bin/sed checking for gawk... gawk checking for libatomic support... yes checking for libcilkrts support... yes checking for libitm support... yes checking for libvtv support... yes checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking whether g++ accepts -static-libstdc++ -static-libgcc... no checking for gnatbind... gnatbind checking for gnatmake... gnatmake checking whether compiler driver understands Ada... yes checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 checking for objdir... .libs checking for version 0.10 of ISL... no checking for version 0.11 of ISL... no checking for version 0.12 of ISL... no 'c++' language required by 'go' in stage 1; enabling The following languages will be built: c,c++,fortran,go,lto,objc,obj-c++ *** This configuration is not supported in the following subdirectories: gnattools target-libada target-zlib target-libjava target-libsanitizer target-boehm-gc (Any other directories should still work fine.) checking for default BUILD_CONFIG... checking for --enable-vtable-verify... no checking for bison... bison -y checking for bison... bison checking for gm4... no checking for gnum4... no checking for m4... m4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for expect... expect checking for runtest... runtest checking for ar... ar checking for as... as checking for dlltool... no checking for ld... ld checking for lipo... no checking for nm... nm checking for ranlib... ranlib checking for strip... strip checking for windres... no checking for windmc... no checking for objcopy... objcopy checking for objdump... objdump checking for readelf... readelf checking for cc... cc checking for c++... c++ checking for gcc... gcc checking for gcj... no checking for gfortran... gfortran checking for gccgo... no checking for ar... no checking for ar... ar checking for as... no checking for as... as checking for dlltool... no checking for dlltool... no checking for ld... no checking for ld... ld checking for lipo... no checking for lipo... no checking for nm... no checking for nm... nm checking for objdump... no checking for objdump... objdump checking for ranlib... no checking for ranlib... ranlib checking for readelf... no checking for readelf... readelf checking for strip... no checking for strip... strip checking for windres... no checking for windres... no checking for windmc... no checking for windmc... no checking where to find the target ar... host tool checking where to find the target as... host tool checking where to find the target cc... just compiled checking where to find the target c++... just compiled checking where to find the target c++ for libstdc++... just compiled checking where to find the target dlltool... host tool checking where to find the target gcc... just compiled checking where to find the target gcj... host tool checking where to find the target gfortran... just compiled checking where to find the target gccgo... just compiled checking where to find the target ld... host tool checking where to find the target lipo... host tool checking where to find the target nm... host tool checking where to find the target objdump... host tool checking where to find the target ranlib... host tool checking where to find the target readelf... host
[Bug pch/62001] Many tests fail with PCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62001 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- As reported in PR61250, I see also random PCH failures on darwin, but much fewer: g++.dg/pch/pch.C and gcc.dg/pch/save-temps-1.c only.
[Bug fortran/61999] [4.8/4.9/4.10 Regression] `gfc_simplify_dot_product` causes ICE for constant arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61999
--- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr ---
The ICE is due to the line
gcc_assert (gfc_compare_types (vector_a-ts, vector_b-ts));
i.e., gfc_simplify_dot_product works only if the two vectors have the same
type. Replacing the assert with
--- ../_clean/gcc/fortran/simplify.c2014-07-26 13:13:21.0 +0200
+++ gcc/fortran/simplify.c2014-08-03 15:43:35.0 +0200
@@ -1883,7 +1883,8 @@ gfc_expr*
gfc_simplify_dot_product (gfc_expr *vector_a, gfc_expr *vector_b)
{
if (!is_constant_array_expr (vector_a)
- || !is_constant_array_expr (vector_b))
+ || !is_constant_array_expr (vector_b)
+ || !gfc_compare_types (vector_a-ts, vector_b-ts))
return NULL;
gcc_assert (vector_a-rank == 1);
fixes the problem. Indeed this prevents the dot product to be computed at
compile time. A better solution will be to do the type conversion, but I don't
know how to do it.
[Bug other/62002] New: -fcilkplus switch breaks format attribute.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62002
Bug ID: 62002
Summary: -fcilkplus switch breaks format attribute.
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: astellar at ro dot ru
~/src/test# cat test.cpp
struct foo
{
void bar(char const *, ...) __attribute__((__format__(__printf__, 2, 3)));
};
`g++-4.9 -c test.cpp` compiles without errors. However, `g++-4.9 -fcilkplus -c
test.cpp` produces this message:
test.cpp:3:77: error: format string argument is not a string type
void bar(char const *, ...) __attribute__((__format__(__printf__, 2, 3)));
I've compiled GCC from git mirror's 4.9 branch.
[Bug other/62002] -fcilkplus switch breaks format attribute.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62002 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-03 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 Rose Garcia rose.garcia-eggl2fk at yopmail dot com changed: What|Removed |Added CC||rose.garcia-eggl2fk@yopmail ||.com --- Comment #16 from Rose Garcia rose.garcia-eggl2fk at yopmail dot com --- Created attachment 33228 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33228action=edit backported fix for gcc 4.7.4 backported fix for gcc 4.7.4 attached. was tested building about 500 packages, no regressions have been detected.
[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 --- Comment #17 from Marek Polacek mpolacek at gcc dot gnu.org --- I'm sorry, GCC 4.7 branch is already closed.
[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 --- Comment #18 from Rose Garcia rose.garcia-eggl2fk at yopmail dot com --- Created attachment 33229 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33229action=edit backported fix for gcc 4.8.3 oh, is that so? that's unfortunate, as gcc 4.7 requires a C++ compiler to bootstrap a C compiler. either way, attaching a backport to gcc 4.8.3. unlike the previous backport it wasn't heavily tested, but it seemed to do the right thing in some simple testcases; and there was only one minor change needed to get the upstream patch to apply (different argument count for init_warning()).
[Bug c++/58704] [c++11] ICE initializing array member of template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58704 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.10.0 |4.9.1
[Bug gcov-profile/61889] [4.10 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889
--- Comment #3 from Rainer Emrich rai...@emrich-ebersheim.de ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 23.07.2014 17:17, schrieb ktietz at gcc dot gnu.org:
--- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- Yes, issue is
here that ftw API is used for cleanup.
... static int unlink_profile_dir (const char *path) { return nftw(path,
unlink_gcda_file, 64, FTW_DEPTH | FTW_PHYS); } ...
This method isn't present on none glibc-systems. So there should be at
least a header-check (HAVE_FTW_H) be added to gcov-tool.c and to
configure.
As Richard mentioned, libiberty would be a good place to add
implementation.
It's still breaking bootstrap on mingw targets, more than 3 weeks now!
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJT3qPrAAoJEB3HOsWs+KJbzMgH/0kciCmfQu+Bqc7drVDPmabH
xgjF2RKEMXg8XhueSpq5MADkh8cUvGv0skExtknwiEgr84TxK/SwinmDvCADUVWY
AXQuODgDnrRS8VNugyckfVZ11wm/uK2ywfp8zlRyNreR54OezOXtXWAtJ0Z8wDc6
0GUvJqK+SP6RbKJLNrRDiowN8bwq+cGK/TAdgIRq7bztY69nzkO604MY8zDQsbaS
ykPv+uwF9uCrmDuKA/L0uYBgd+E2t8WkMi4AbYJebqaiegLrYj16oEPYaJem1j39
uIqIpP/p6ylkQPmclSePOd7TbKTVi++YP3N3czNTXjvogYc20fyDoUl5/9cKCSs=
=IM/a
-END PGP SIGNATURE-
[Bug c++/60189] ICE with invalid use of _Cilk_sync
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60189 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.9.1 Resolution|--- |FIXED Target Milestone|--- |4.9.1 --- Comment #6 from Volker Reichelt reichelt at gcc dot gnu.org --- Fixed for GCC 4.9.1 by Igor's patch.
[Bug fortran/61768] Fortran compiler goes into infinite loop while compiling SPEC2000 applu.f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61768 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-08-03 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- minimal Fortran code to reproduce this should contain subroutine setbv and exact. Such code, or better, a reduced reproducer, should be provided. From comment 0, it seems that this PR a graphite problem on arm processor, thus not a gfortran bug.
[Bug c++/62003] New: Possible bug in std::complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62003
Bug ID: 62003
Summary: Possible bug in std::complex
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wilczak at ii dot uj.edu.pl
Dear MinGW users,
I have found a strange behaviour of std::complex class with double template
parameter. The program given below causes segfault (gcc-4.8.1-4, Windows) when
compiled with -O1 or -O2 flag.
The output of the program is given below (note that the second column equal to
e=v.end() should be constant).
No errors when:
- typedef Complex=double
- parameter -O0 is used
- volatile added to definition of iterator 'e'
volatile Vector::iterator e = u.end();
- type of variable 'p' is changed to double instead of Complex
Daniel Wilczak
// ###
// Output
0x3f19b0 0x3f1a40 (0,0)
0x3f19c0 0x3f1a40 (0,0)
0x3f19d0 0x3f1a40 (0,0)
0x3f19e0 0 (0,0)
0x3f19f0 0 (0,0)
0x3f1a00 0x4000 (0,0)
0x3f1a10 0 (0,0)
0x3f1a20 0 (0,0)
0x3f1a30 0x1 (0,0)
0x3f1a40 0x405064 (2.06124e-309,3.4598e-307)
0x3f1a50 0x6fcc43c0 (0,4.24399e-314)
0x3f1a60 0x4038dd (2.04322e-317,3.711e+261)
0x3f1a70 0x28fee8 (1.73018e-307,2.47437e+261)
// ###
// The program
#include iostream
#include complex
templateclass T
struct V{
typedef T* iterator;
iterator begin() { return data; }
iterator end() { return data+capacity; }
V(unsigned c) : capacity(c) { data = new T[c]; }
~V(){ delete[] data; }
T *data;
unsigned capacity;
};
int main()
{
typedef std::complexdouble Complex;
typedef VComplex Vector;
Vector u(9);
Vector::iterator j = u.begin();
Vector::iterator e = u.end();
for(; j!=e; ++j) {
Complex p(2.,0.);
Complex q = *j;
Complex z = q*p;
std::cout j e z std::endl;
}
return 0;
}
[Bug rtl-optimization/62004] New: dead type-unsafe load replaces type-safe load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62004
Bug ID: 62004
Summary: dead type-unsafe load replaces type-safe load
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Created attachment 33230
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33230action=edit
test-case
I've tried to write a program in which there is a type-unsafe load, which is
never executed, to see if tail-merge would fail. In other words, I've tried to
come up with a 'load' variant of PR61964.
With attached test-case load-4.c and current 4.8 branch, I get the following
results:
...
$ gcc -O2 load-4.c; ./a.out ; echo $?
1
...
Adding -fno-strict-aliasing allows the test to pass:
...
$ gcc -O2 load-4.c -fno-strict-aliasing ; ./a.out ; echo $?
0
...
However AFAICT, the test-case is correct, in the sense that the only
type-unsafe code is dead, so -fno-strict-aliasing should not be necessary to
allow the test to pass.
My intention was to trigger a a problem in tail-merge. However, skipping
tail-merge still doesn't make the test pass:
...
$ gcc -O2 load-4.c -fstrict-aliasing -fno-tree-tail-merge; ./a.out ; echo $?
1
...
At rtl level, the same type of optimization as tail-merge is done. We start out
with the if-then-else-join before expand:
...
if (_13 == h_10)
goto bb 3;
else
goto bb 4;
bb 3:
p_14 = MEM[(struct head *)_13].first;
goto bb 5;
bb 4:
p_15 = _13-next;
bb 5:
...
And this is expanded into rtl:
...
(jump_insn 23 22 24 2 (set (pc)
(if_then_else (ne (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 28)
(pc))) load-4.c:44 -1
(expr_list:REG_BR_PROB (const_int 8986 [0x231a])
(nil))
- 28)
(note 24 23 25 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 25 24 26 4 (set (reg/v/f:DI 59 [ p ])
(mem/f:DI (reg/f:DI 66 [ D.1751 ]) [4 MEM[(struct head *)_13].first+0
S8 A64])) load-4.c:46 -1
(nil))
(jump_insn 26 25 27 4 (set (pc)
(label_ref 31)) -1
(nil)
- 31)
(barrier 27 26 28)
(code_label 28 27 29 5 2 [1 uses])
(note 29 28 30 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn 30 29 31 5 (set (reg/v/f:DI 59 [ p ])
(mem/f:DI (reg/f:DI 66 [ D.1751 ]) [4 _13-next+0 S8 A64])) load-4.c:49
-1
(nil))
(code_label 31 30 32 6 3 [1 uses])
...
Already at into_cfglayout, the jump 26 is removed, causing the 'dead' bb4 to
become alive:
...
try_optimize_cfg iteration 1
Removing jump 26.
SNIP
(jump_insn 23 22 24 2 (set (pc)
(if_then_else (ne (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 28)
(pc))) load-4.c:44 612 {*jcc_1}
(expr_list:REG_BR_PROB (const_int 8986 [0x231a])
(nil))
- 28)
(note 24 23 25 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 25 24 28 3 (set (reg/v/f:DI 59 [ p ])
(mem/f:DI (reg/f:DI 66 [ D.1751 ]) [4 MEM[(struct head *)_13].first+0
S8 A64])) load-4.c:46 87 {*movdi_internal_rex64}
(nil))
(code_label 28 25 29 4 2 [1 uses])
(note 29 28 30 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 30 29 31 4 (set (reg/v/f:DI 59 [ p ])
(mem/f:DI (reg/f:DI 66 [ D.1751 ]) [4 _13-next+0 S8 A64])) load-4.c:49
87 {*movdi_internal_rex64}
(nil))
...
And after ce1, we're just left with the code from bb4:
...
IF-THEN-ELSE-JOIN block found, pass 1, test 2, then 3, else 4, join 5
changing bb of uid 30
from 4 to 2
deleting insn with uid = 29.
deleting insn with uid = 28.
deleting block 4
Removing jump 23.
SNIP
(insn 30 22 33 2 (set (reg/v/f:DI 59 [ p ])
(mem/f:DI (reg/f:DI 66 [ D.1751 ]) [4 _13-next+0 S8 A64])) load-4.c:49
87 {*movdi_internal_rex64}
(expr_list:REG_DEAD (reg/f:DI 66 [ D.1751 ])
(nil)))
...
Using -fno-if-conversion allows the test to pass:
...
$ gcc -O2 load-4.c -fstrict-aliasing -fno-tree-tail-merge -fno-if-conversion;
./a.out ; echo $?
0
...
And indeed, the problem also triggers for tail-merge:
...
$ gcc.sh -O2 load-4.c -fstrict-aliasing -ftree-tail-merge -fno-if-conversion;
./a.out ; echo $?
1
...
[Bug tree-optimization/61964] [4.8/4.9 regression] krb5 database propagation enters infinite loop; reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964 --- Comment #18 from vries at gcc dot gnu.org --- (In reply to Richard Biener from comment #13) (In reply to vries from comment #12) Furthermore, I suspect that a similar issue exists for loads, I'll look into that. I don't think so. How about PR62004 ?
