[Bug rtl-optimization/58365] [4.7/4.8/4.9 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58365 Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #4 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org --- The underlying bug appears to be in CSA (combine-stack-adj.c) and I would appreciate Richard's insight on how to fix it. Summary: CSA merges stack variable into global one, and then alias analysis thinks that ex-stack-now-global variable does not overlap with global variables. After patch in rev. 162592 code hoisting becomes able to simplify code just a bit, which causes scheduler to generate a different sequence, exposing a latent bug. During expand we have: # BLOCK 3 freq:3900 # PRED: 2 [39.0%] (true,exec) 1 D.2750 = x6; goto bb 5; # SUCC: 5 [100.0%] (fallthru,exec) # BLOCK 4 freq:6100 # PRED: 2 [61.0%] (false,exec) D.2750 = x7; # SUCC: 5 [100.0%] (fallthru,exec) # BLOCK 5 freq:1 # PRED: 4 [100.0%] (fallthru,exec) 3 [100.0%] (fallthru,exec) 2 x8 = D.2750; 3 x6.x2 = 1; D.2733_1 = x8.x2; printf (%d\n, D.2733_1); CSA combines stack variable D.2750 in insn (1) into global x6, but fails to update uses of D.2750. After CSA DECL_RTL of MEM in insn (2) still references D.2750 even though it now reads directly from x6. Because D.2750 is on stack and x6 is global -- alias analysis (nonoverlapping_memrefs_p()) tells scheduler that it is OK to move insn (3) before insn (2).
[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57697 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org --- Submitted patch: http://gcc.gnu.org/ml/fortran/2013-09/msg00016.html As follow up, one should check whether arrays (lhs unallocated, same shape, different shape) are correctly handled.
[Bug rtl-optimization/58365] [4.7/4.8/4.9 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58365
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
That is actually the crossjumping pass after csa (jump2; though yes, previously
it has been part of csa). In any case, I don't see anything wrong with the
cross jumping, it turns the two:
(set (mem/c:BLK (reg:DI 5 di [81]) [3 D.1761+0 S20 A32])
(mem/c:BLK (reg:DI 4 si [82]) [3 x6+0 S20 A32]))
and
(set (mem/c:BLK (reg:DI 5 di [84]) [3 D.1761+0 S20 A32])
(mem/u/c:BLK (reg:DI 4 si [85]) [3 x7+0 S20 A128]))
into:
(set (mem/c:BLK (reg:DI 5 di [84]) [3 D.1761+0 S20 A32])
(mem/u/c:BLK (reg:DI 4 si [85]) [3 S20 A32]))
(note, MEM_EXPR cleared), where si is set conditionally to x6 or x7.
And then we have the:
(insn 29 27 31 6 (set (mem/c:SI (const:DI (plus:DI (symbol_ref:DI (x6)
var_decl 0x7f9ce47572f8 x6)
(const_int 4 [0x4]))) [2 x6.x2+0 S4 A32])
(const_int 1 [0x1])) pr58365.c:31 86 {*movsi_internal}
(nil))
store that sched2 moves over the above rep_movsi, although there is a
(conditional, may, but doesn't have to) aliasing case.
[Bug rtl-optimization/58365] [4.7/4.8/4.9 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58365 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Assignee|mkuvyrkov at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Ah, actually the bug is really in the cross-jumping, in this case that it hasn't cleared MEM_READONLY_P. While x7 is read-only, x6 is not, so merge_memattrs should combine that to !MEM_READONLY_P.
[Bug rtl-optimization/58365] [4.7/4.8/4.9 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58365
--- Comment #6 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
That is actually the crossjumping pass after csa (jump2; though yes,
previously it has been part of csa). In any case, I don't see anything
wrong with the cross jumping, it turns the two:
(set (mem/c:BLK (reg:DI 5 di [81]) [3 D.1761+0 S20 A32])
(mem/c:BLK (reg:DI 4 si [82]) [3 x6+0 S20 A32]))
and
(set (mem/c:BLK (reg:DI 5 di [84]) [3 D.1761+0 S20 A32])
(mem/u/c:BLK (reg:DI 4 si [85]) [3 x7+0 S20 A128]))
into:
(set (mem/c:BLK (reg:DI 5 di [84]) [3 D.1761+0 S20 A32])
(mem/u/c:BLK (reg:DI 4 si [85]) [3 S20 A32]))
(note, MEM_EXPR cleared), where si is set conditionally to x6 or x7.
And then we have the:
(insn 29 27 31 6 (set (mem/c:SI (const:DI (plus:DI (symbol_ref:DI (x6)
var_decl 0x7f9ce47572f8 x6)
(const_int 4 [0x4]))) [2 x6.x2+0 S4 A32])
(const_int 1 [0x1])) pr58365.c:31 86 {*movsi_internal}
(nil))
store that sched2 moves over the above rep_movsi, although there is a
(conditional, may, but doesn't have to) aliasing case.
Jacub, I don't quite understand whether you are saying that the bug is /not/ in
csa (at GCC 4.7 age) or whether you are providing additional analysis.
I'm debugging the gcc-4.7-era revision 162592 and here the source MEM in
rep_movsi references stack variable instead of x6, which causes wrong aliasing
decision.
[Bug ipa/58371] [4.9 Regression] internal compiler error: in ipcp_verify_propagated_values, at ipa-cp.c:892
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58371 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug ipa/58371] [4.9 Regression] internal compiler error: in ipcp_verify_propagated_values, at ipa-cp.c:892
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58371 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-10 CC||mpolacek at gcc dot gnu.org Known to work||4.8.1 Summary|internal compiler error: in |[4.9 Regression] internal |ipcp_verify_propagated_valu |compiler error: in |es, at ipa-cp.c:892 |ipcp_verify_propagated_valu ||es, at ipa-cp.c:892 Ever confirmed|0 |1 Known to fail||4.9.0 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug ipa/58371] [4.9 Regression] internal compiler error: in ipcp_verify_propagated_values, at ipa-cp.c:892
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58371 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r202145.
[Bug rtl-optimization/58365] [4.7/4.8/4.9 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58365 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 30781 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30781action=edit gcc49-pr58365.patch Untested fix.
[Bug tree-optimization/58373] [4.9 Regression] g++: internal compiler error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58373 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de --- Started with rev202296.
[Bug rtl-optimization/51447] [4.7 Regression] global register variable definition incorrectly removed as dead code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51447
Matthijs Kooijman matthijs at stdin dot nl changed:
What|Removed |Added
CC||matthijs at stdin dot nl
--- Comment #19 from Matthijs Kooijman matthijs at stdin dot nl ---
In case anyone else comes across here and wonders: This fix made it into 4.8,
but was not backported into 4.7.3.
Regarding the bug description that says 4.7 regression, I have also observed
this bug on avr-gcc 4.3.3, so it's not a regression introduced in 4.7.
I also noticed this bug on the AVR platform, using 4.7.2. Just in case it helps
(perhaps for others to find this bug when Googling for avr-gcc), here's the
testcase and bugreport I was preparing before I found this one.
//
// Under some circumstances, writes to a global register variable are
// optimized away, even though that changes behaviour. The below example
// illustrates this.
//
// When compiled as-is, the writes to the variable global are removed.
// However, when compiling with -DDO_CALL, which adds a function call to
// the main function, the writes are preserved. This leads me to believe
// that the optimizer sees that main() isn't calling any functions, so
// it must be safe to just remove the writes (even though documentation
// [1] says Stores into this register are never deleted even if they
// appear to be dead, but references may be deleted or moved or
// simplified.)
//
// It seems that a second condition (in addition to no functions called)
// is that the main function does not return. If we add a return path,
// the writes show up again.
//
// However, removing these writes does not seem sane, since there is
// also an interrupt routine, which can access the variable, but the
// optimizer is apparently not aware that this is a possibility.
//
//
// Tested using:
// avr-gcc -mmcu=attiny13 register.c -S -o - -O
// avr-gcc -mmcu=attiny13 register.c -S -o - -O -DDO_CALL
// avr-gcc -mmcu=attiny13 register.c -S -o - -O -DDO_RETURN
//
// [1]: //
http://gcc.gnu.org/onlinedocs/gcc/Global-Reg-Vars.html#Global-Reg-Vars
#include avr/io.h
#include avr/cpufunc.h
// Define a global variable in a register
register char global asm(r16);
// Just a dummy function
void foo()
{
// Add some nops so this function doesn't get inlined
_NOP(); _NOP(); _NOP();
}
// Define an ISR that accesses the global. This doesn't actually seem to
// make a different, except that if this wasn't here, removing writes to
// the global would be acceptable
void ISR(INT0_vect)
{
PORTB = global;
}
void main()
{
global = 1;
while(1) {
#ifdef DO_CALL
foo();
#endif
#ifdef DO_RETURN
return;
#endif
}
}
[Bug c/58346] ICE with SIGFPE at -O1 and above on x86_64-linux-gnu (affecting trunk, 4.8, 4.7, and 4.6)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58346 --- Comment #6 from rguenther at suse dot de rguenther at suse dot de --- On Mon, 9 Sep 2013, joseph at codesourcery dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58346 --- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot com --- I think some of the uses of the zero-size-objects extension are ones for which making an array of such objects is reasonable, but it makes sense to give an error for trying to subtract pointers to such objects. A similar (runtime) error can be provoked by subtracting pointers to array elements of variable size that happen to have zero size at runtime. This all seems to be a can of worms which I'd rather shield the middle-end from. For example we assume that a[0] and a[1] never alias. Can we at least make arrays of zero-sized elements trigger undefined behavior in our extension documentation? We probably can paper over the ICEs as they occur (testing coverage is very weak of course).
[Bug rtl-optimization/51447] [4.7 Regression] global register variable definition incorrectly removed as dead code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51447 --- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Matthijs Kooijman from comment #19) Regarding the bug description that says 4.7 regression, I have also observed this bug on avr-gcc 4.3.3, so it's not a regression introduced in 4.7. That is just because no compilers older than 4.7.0 are supported any longer. The [... Regression] markers only show list of still affected supported compiler versions, if it is a regression from any of the older compilers.
[Bug middle-end/57748] [4.7/4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #36 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 30782 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30782action=edit Next try for a fix OK, I removed the misalign code path completely, and found a one-line fix for read side too. So here is my next try to fix this issue. It seems to boot-strap on x86_64 and all test cases pass. Additional testing would be welcome. Any comments?
[Bug rtl-optimization/58369] [4.8/4.9 regression] ICE in subreg_get_info when compiling boost for m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58369 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- Created attachment 30783 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30783action=edit smaller test case, from C-reduce
[Bug libstdc++/58376] New: regex_iterator::operator== and operator!= not const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58376 Bug ID: 58376 Summary: regex_iterator::operator== and operator!= not const Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: kai.un...@l-3com.com Comparison operators implemented as members of regex_iterator need to be const (required by the C++ standard).
[Bug target/58330] powerpc64 atomic store split in two
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58330 --- Comment #4 from Alan Modra amodra at gcc dot gnu.org --- Author: amodra Date: Tue Sep 10 08:38:57 2013 New Revision: 202428 URL: http://gcc.gnu.org/viewcvs?rev=202428root=gccview=rev Log: PR target/58330 oops, missed from commit Added: trunk/gcc/testsuite/gcc.target/powerpc/pr58330.c
[Bug target/58375] internal compiler error: in push_reload, at reload.c:1360
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58375 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Target|AVR/ATmega2561 |avr Status|UNCONFIRMED |WAITING Last reconfirmed||2013-09-10 CC||gjl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org --- (In reply to Peter Stegemann from comment #0) The culprit Would you please add a minimal test case / preprocessed file and avoid zip files as explained in the bug reporting hints. Thanks. http://gcc.gnu.org/bugs/#need http://gcc.gnu.org/bugs/#detailed
[Bug libstdc++/58376] regex_iterator::operator== and operator!= not const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58376 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- In 4.6.x essentially nothing works as far as regex is concerned, the implementation work is finally happening for 4.9.0.
[Bug tree-optimization/58373] [4.9 Regression] g++: internal compiler error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58373 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Looks like cc1plus being miscompiled - does it reproduce with stage1 cc1plus?
[Bug c++/58372] internal compiler error: ix86_compute_frame_layout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||mingw32-sjlj --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Please also specify how you configured the compiler(s).
[Bug c++/58377] New: spurious may be unused warning with -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
Bug ID: 58377
Summary: spurious may be unused warning with -Og
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rbd at debian dot org
The following code generates a spurious ‘out’ may be used uninitialized in
this function warning when built with -Og; no optimization, -O1, -O2, -O3 and
-Ofast all do not warn.
// gcc -Og -std=c++0x -Wall -Werror -c xx.cpp
struct ordered_tasks
{
int * pop ();
};
struct A
{
ordered_tasks * tasks[];
int * pop ();
};
int pop_first_bucket;
int * A::pop ()
{
int * out;
int cur_bucket = 0;
do {
if (tasks[0]) {
out = tasks[cur_bucket]-pop();
if (out)
return out;
}
} while (pop_first_bucket);
return 0;
}
output / details of my system:
$ gcc -v -Og -std=c++0x -Wall -Werror -c xx.cpp
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.8.1-10ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu1)
COLLECT_GCC_OPTIONS='-v' '-Og' '-std=c++11' '-Wall' '-Werror' '-c' '-E'
'-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/4.8/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE xx.cpp -mtune=generic -march=x86-64 -std=c++11
-Wall -Werror -Og -fstack-protector -Wformat -Wformat-security
ignoring duplicate directory /usr/include/x86_64-linux-gnu/c++/4.8
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../x86_64-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/4.8
/usr/include/x86_64-linux-gnu/c++/4.8
/usr/include/c++/4.8/backward
/usr/lib/gcc/x86_64-linux-gnu/4.8/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-Og' '-std=c++11' '-Wall' '-Werror' '-c' '-E'
'-mtune=generic' '-march=x86-64'
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.8.1-10ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
[Bug tree-optimization/58373] [4.9 Regression] g++: internal compiler error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58373 --- Comment #3 from Markus Trippelsdorf markus at trippelsdorf dot de --- (In reply to Richard Biener from comment #2) Looks like cc1plus being miscompiled - does it reproduce with stage1 cc1plus? Yes. It reproduces with --disable-bootstrap builds using 4.7.3 or 4.8.1.
[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstreamchar, std::char_traitschar, std::allocatorchar '
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314
Pawel Sikora pluto at agmk dot net changed:
What|Removed |Added
CC||pluto at agmk dot net
--- Comment #39 from Pawel Sikora pluto at agmk dot net ---
Hi,
i see mentioned linker error on the current gcc-4.8.2 for i686-gnu-linux target
and somehow it works for x86_64-gnu-linux target.
../../../lib/libUnitTest++.a(Test.cpp.o):Test.cpp:function construction vtable
for std::__7::basic_ostreamchar, std::__7::char_traitschar
-in-UnitTest::MemoryOutStream: error: undefined reference to 'virtual thunk to
std::__7::basic_ostreamchar, std::__7::char_traitschar ::~basic_ostream()'
../../../lib/libUnitTest++.a(Test.cpp.o):Test.cpp:function construction vtable
for std::__7::basic_ostreamchar, std::__7::char_traitschar
-in-UnitTest::MemoryOutStream: error: undefined reference to 'virtual thunk to
std::__7::basic_ostreamchar, std::__7::char_traitschar ::~basic_ostream()'
../../../lib/libUnitTest++.a(Test.cpp.o):Test.cpp:function construction vtable
for std::__7::basic_ostringstreamchar, std::__7::char_traitschar,
std::__7::allocatorchar -in-UnitTest::MemoryOutStream: error: undefined
reference to 'virtual thunk to std::__7::basic_ostringstreamchar,
std::__7::char_traitschar, std::__7::allocatorchar
::~basic_ostringstream()'
../../../lib/libUnitTest++.a(Test.cpp.o):Test.cpp:function construction vtable
for std::__7::basic_ostringstreamchar, std::__7::char_traitschar,
std::__7::allocatorchar -in-UnitTest::MemoryOutStream: error: undefined
reference to 'virtual thunk to std::__7::basic_ostringstreamchar,
std::__7::char_traitschar, std::__7::allocatorchar
::~basic_ostringstream()'
MemoryOutStream is declared in the UnitTest++ as:
#include sstream
namespace UnitTest
{
class MemoryOutStream : public std::ostringstream
{
public:
MemoryOutStream() {}
char const* GetText() const;
private:
MemoryOutStream(MemoryOutStream const);
void operator =(MemoryOutStream const);
mutable std::string m_text;
};
}
[Bug libgomp/58378] New: Protect libgomp against child process hanging after a Unix fork()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58378 Bug ID: 58378 Summary: Protect libgomp against child process hanging after a Unix fork() Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: olivier.grisel at ensta dot org CC: jakub at gcc dot gnu.org Created attachment 30784 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30784action=edit Patch to protect libgomp thread pool against fork() The problem is discussed in [1]. To summarize if a process uses OpenMP features and then calls fork, the threads from the OpenMP thread pool of the parent process are not copied to the child process (which is expected). Then later if the child process uses some OpenMP feature again it will hang, waiting for threads that don't exist in its own process. In practice this can often happen in Python programs that import modules that use OpenMP internally while also using the `multiprocessing` module. This module is in the Python standard library and uses Unix fork for handling multi-core concurrency efficiently at the Python level. I attach the patch to this report and a test that checks that the fix actually works. The patch can also be visualized on this github branch [2]. When running the example snippet from [1] saved in a file called `openmp_fork.c` I get the expected output: $ gcc-head -fopenmp -o openmp_fork openmp_fork.c ./openmp_fork para_a para_a a ended para_b para_b b ended instead of a hanging process. [1] http://bisqwit.iki.fi/story/howto/openmp/#OpenmpAndFork [2] https://github.com/ogrisel/gcc/compare/forksafe-omp-pthread_atfork Note that the OpenMP implementation of ICC does not hang either when using fork. Note 2: this problem is related to (a duplicate of) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52303 which was deemed invalid as the POSIX standard states that it's unsafe to use threading after a fork and prior to calling exec. However as the `pthread_atfork` protection from this patch is rather non-invasive and should not impact any process not initializing the libgomp runtime prior to a fork. Interpreted language implementations such as CPython that (ab)use Unix fork for efficient concurrency would really benefit from such a protection against libraries using OpenMP internally with the caller not necessarily being aware of it.
[Bug libgomp/58378] Protect libgomp against child process hanging after a Unix fork()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58378 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- The PR52303 comment about what you are trying to do being invalid of course applies here too, and the patch isn't anything close to non-invasive, it is just wrong, because it will break valid OpenMP programs.
[Bug c++/58377] spurious may be unused warning with -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- I can't reproduce this issue with stock FSF GCCs. In any case, it doesn't look like a C++ front-end issue, I would recommend preparing an equivalent pure C program for the convenience of middle-end people (changing pop to be free standing functions and little more should be enough). Often I do that kind of work but I can't reproduce the issue in the first place in this case.
[Bug preprocessor/58370] pre compiled headers failure on NetBSD/sparc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58370 --- Comment #4 from Martin Husemann martin at netbsd dot org --- To avoid confusion, I'm splitting this into two separate reports - will dig further into the crash myself, since it is probably not easy to reproduce on other host platforms.
[Bug target/56412] [4.8] libtool: cygpath: command not found for mingw32 host
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56412 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-09-10 CC||ktietz at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org --- Yes, this is a libtool bug. If thing is solved on libtool, then we can continue on that. So long I set bug in status waiting
[Bug libgomp/58378] Protect libgomp against child process hanging after a Unix fork()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58378 --- Comment #2 from Olivier Grisel olivier.grisel at ensta dot org --- What kind of breakage does this introduce? It's a real question, I am not an experienced OpenMP developer. Do you see any solution that would prevent libgomp-based programs such as mentioned in [1] to not hang after a fork(). Is it worth for me to spend time trying to work a better and safer solution (maybe with some guidance)?
[Bug preprocessor/58379] New: default mmap based implementation (mmap_gt_pch_get_address/mmap_gt_pch_use_address) is useless
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58379 Bug ID: 58379 Summary: default mmap based implementation (mmap_gt_pch_get_address/mmap_gt_pch_use_address) is useless Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: martin at netbsd dot org I may be misunderstanding the interface - but it looks to me like it lets the kernel chose an arbitrary mapping address for different compiler invocations but relies on the assumption that the returned address will be the same. If not, the compiler fails with a fatal_error when trying to read a precompiled header file (had to relocate PCH). I can not imagine a host system where this would work reliably (or even typically twice in a row). Please tell me I misunderstood, or consider disabling PCH support for host platforms without host_hooks overriding this function.
[Bug c++/58380] New: ice in fold_comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380 Bug ID: 58380 Summary: ice in fold_comparison Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Created attachment 30785 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30785action=edit gzipped C++ source code I just tried to compile package k3d-0.8.0.2-19 with gcc 4.9 trunk dated 20130909. It said /home/dcb/rpmbuild/BUILD/k3d-source-0.8.0.2/k3dsdk/document_plugin_factory.h:48:9: internal compiler error: Segmentation fault inode* create_plugin(iplugin_factory Factory, idocument Document) ^ 0xacdd4f crash_signal ../../src/trunk/gcc/toplev.c:335 0x8b7709 fold_comparison ../../src/trunk/gcc/fold-const.c:9052 0x8c0b9b fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) ../../src/trunk/gcc/fold-const.c:12780 0xaff5d2 cleanup_control_expr_graph ../../src/trunk/gcc/tree-cfgcleanup.c:96 0xaff5d2 cleanup_control_flow_bb ../../src/trunk/gcc/tree-cfgcleanup.c:171 0xaff5d2 cleanup_tree_cfg_bb ../../src/trunk/gcc/tree-cfgcleanup.c:589 0xb01018 cleanup_tree_cfg_1 ../../src/trunk/gcc/tree-cfgcleanup.c:634 0xb01018 cleanup_tree_cfg_noloop ../../src/trunk/gcc/tree-cfgcleanup.c:690 0xb01018 cleanup_tree_cfg() ../../src/trunk/gcc/tree-cfgcleanup.c:745 0xa27a84 execute_function_todo ../../src/trunk/gcc/passes.c:1791 0xa28167 execute_todo ../../src/trunk/gcc/passes.c:1866 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. Here is valgrind helping out with a stack backtrace ==23967== Invalid read of size 2 ==23967==at 0x8B7709: fold_comparison(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) (fold-const.c:9052) ==23967==by 0x8C0B9B: fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) (fold-const.c:12780) ==23967==by 0xAFF5D2: cleanup_tree_cfg_bb(basic_block_def*) (tree-cfgcleanup.c:96) ==23967==by 0xB01018: cleanup_tree_cfg() (tree-cfgcleanup.c:634) Preprocessed source code attached. Flag -O2 required.
[Bug target/57848] internal compiler error on builtin and '#pragma GCC target()' option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||whitequill at abstractions dot me --- Comment #11 from Kai Tietz ktietz at gcc dot gnu.org --- *** Bug 58061 has been marked as a duplicate of this bug. ***
[Bug libgcc/58061] internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58061 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org --- Duplicate of PR/57848 *** This bug has been marked as a duplicate of bug 57848 ***
[Bug c++/57897] Target x86_64-w64-mingw32 failed with '-mno-fentry isn't compatible with SEH'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57897 --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org --- Hmm, what I don't get is why there is a warning about -mno-fentry. So I would assume there is something else broken. Nevertheless this reminds me about pr/57848. This issue seems to be in general no mingw specific problem, but more an inconsistency about sse and builtins.
[Bug libgomp/58378] Protect libgomp against child process hanging after a Unix fork()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58378
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
Please read OpenMP 4.0, section 2.14.2 (threadprivate directive), or
corresponding sections in older standards.
The implementation must preserve values of threadprivate variables in certain
cases, which your hack violates. If somebody (validly) does:
int v;
#pragma omp threadprivate (v)
...
omp_set_dynamic (0);
#pragma omp parallel num_threads (4)
{
v = omp_get_thread_num () * 16;
}
...
pid = fork ();
if (pid == 0)
{
/* Valid fork child, only calling functions POSIX allows it to. */
execve (...);
}
#pragma omp parallel num_threads (4)
{
if (v != omp_get_thread_num () * 16)
abort ();
}
then the implementation must preserve the threadprivate values, but with your
patch all the threads but the initial one will be lost during fork and thus v
will be 0 instead of the desired value later on.
There is no point trying to hack around bugs in your code inside of libgomp,
simply follow the requirements how you can use fork in multithreaded apps.
[Bug target/54412] Request for 32-byte stack alignment with -mavx on Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org --- MS' abi doesn't allow this. So I doubt we will be able to implement that for this target. If we want to re-align stack on function-base we will run into troubles with SEH-information. Doesn't it work to align explicit the variable itself?
[Bug c++/58377] spurious may be unused warning with -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
--- Comment #2 from Roland Dreier rbd at debian dot org ---
arg, I really apologize. I copied and pasted from the wrong window and ended
up with a test case that does NOT reproduce the issue, even on my system. Here
is one I triple checked does fail (and everything is copied from one window, so
the code is definitely what I built):
$ cat x.cpp
// gcc -Og -Wall -Werror -c x.cpp
int * pop ();
struct A
{
void * tasks[0];
};
int pop_first_bucket;
int * my_pop (struct A * t)
{
int * out;
do {
if (t-tasks[0] (out = pop()))
return out;
} while (pop_first_bucket);
return 0;
}
$ gcc -v -Og -Wall -Werror -c x.cpp
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.8.1-10ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu1)
COLLECT_GCC_OPTIONS='-v' '-Og' '-Wall' '-Werror' '-c' '-E' '-mtune=generic'
'-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/4.8/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE x.cpp -mtune=generic -march=x86-64 -Wall -Werror
-Og -fstack-protector -Wformat -Wformat-security
ignoring duplicate directory /usr/include/x86_64-linux-gnu/c++/4.8
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../x86_64-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/4.8
/usr/include/x86_64-linux-gnu/c++/4.8
/usr/include/c++/4.8/backward
/usr/lib/gcc/x86_64-linux-gnu/4.8/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-Og' '-Wall' '-Werror' '-c' '-E' '-mtune=generic'
'-march=x86-64'
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.8.1-10ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu1)
COLLECT_GCC_OPTIONS='-v' '-Og' '-Wall' '-Werror' '-c' '-o'
'/home/roland/.ccache/0/5/a073b86e9bd44947a6de1615bfe6ad-3402.o.tmp.roland-t410s.19701'
'-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/4.8/cc1plus -fpreprocessed
[Bug rtl-optimization/38614] ICE at simplify-rtx.c:4956
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38614 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org --- If this issue occurs with more recent gcc-version, please open an new bug. gcc 4.4 is no longer maintained (same as gcc 4.5). So closing this bug
[Bug target/52061] compiler internal error in extract_insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52061 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org --- Due this issue is in 4.6 tree, which isn't any longer under maintenance by gcc's team, I close this bug as won't fix.
[Bug lto/49922] I try to build libgmp using PGO and lto, but the test will result in internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49922 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org --- Due issue is solved for gcc 4.7 (and upward), and gcc 4.6 isn't under maintenance by gcc team any more, I close this bug as won't fix.
[Bug c++/58380] ice in fold_comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-10 CC||mpolacek at gcc dot gnu.org Known to work||4.8.1 Target Milestone|--- |4.9.0 Ever confirmed|0 |1 Known to fail||4.9.0 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed, needs -O2. Bisecting...
[Bug c++/58377] spurious may be unused warning with -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
--- Comment #3 from Roland Dreier rbd at debian dot org ---
Even simpler test case for me:
$ cat x.cpp
// gcc -Og -Wall -Werror -c x.cpp
int pop ();
int pop_first_bucket;
int my_pop ()
{
int out;
while (pop_first_bucket)
if (pop_first_bucket (out = pop()))
return out;
return 0;
}
$ for o in Og O0 O1 O2 O3 Ofast; do echo === $o ===; gcc -$o -Wall -Werror -c
x.cpp; done
=== Og ===
x.cpp: In function ‘int my_pop()’:
x.cpp:8:9: error: ‘out’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
int out;
^
cc1plus: all warnings being treated as errors
=== O0 ===
=== O1 ===
=== O2 ===
=== O3 ===
=== Ofast ===
Does not error when built as x.c:
$ cp x.cpp x.c; for o in Og O0 O1 O2 O3 Ofast; do echo === $o ===; gcc -$o
-Wall -Werror -c x.c; done
=== Og ===
=== O0 ===
=== O1 ===
=== O2 ===
=== O3 ===
=== Ofast ===
[Bug target/53485] gcc -O -mavx generates illegal instruction on win64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53485 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- yes, it is an alignment issue. Try to set explicit alignment for this global. That it doesn't fail for 32-bit is just by chance. This seems to me an OP issue.
[Bug target/47596] internal compiler error: in print_reg, at config/i386/i386.c:10894
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47596 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WONTFIX --- Comment #9 from Kai Tietz ktietz at gcc dot gnu.org --- Gcc 4.4 isn't anymore maintained by gcc team. As it works for newer gcc-versions, I close this bug as won't fix.
[Bug libgomp/58378] Protect libgomp against child process hanging after a Unix fork()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58378 --- Comment #4 from Olivier Grisel olivier.grisel at ensta dot org --- Thanks for the explanation. Would you consider a solution that would preserve the state of the parent process and would just reset the thread pool data on the child? Otherwise we will have to consider that the way fork() is used in Python's multiprocessing module is really an abuse and that there is no way to safely use both openmp-libraries and Python multiprocessing in the same program safely.
[Bug preprocessor/58381] New: crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58381
Bug ID: 58381
Summary: crash in diagnostic_report_current_module when a
fatal_error happens during PCH processing on
NetBSD/spa64rc
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
In toplev_main variable line_table is initialized and becomes 0x417dc000,
however, when invoking diagnostic_report_current_module with this backtrace it
is different:
#0 diagnostic_report_current_module (context=0x17b28d0, where=19) at
../../gcc-4.8.1/gcc/diagnostic.c:468
#1 0x003a6368 in cp_diagnostic_starter (context=0x17b28d0,
diagnostic=0xa3e8)
at ../../gcc-4.8.1/gcc/cp/error.c:2907
#2 0x012d5e44 in diagnostic_report_diagnostic (context=0x17b28d0,
diagnostic=0xa3e8)
at ../../gcc-4.8.1/gcc/diagnostic.c:756
#3 0x012d6b90 in fatal_error (gmsgid=0x13e1230 had to relocate PCH)
at ../../gcc-4.8.1/gcc/diagnostic.c:1076
#4 0x008e83dc in gt_pch_restore (f=0x424a0738) at
../../gcc-4.8.1/gcc/ggc-common.c:704
#5 0x005c575c in c_common_read_pch (pfile=0x42765800, name=0x4275dbc0
conftest.h.gch, fd=4,
orig_name=0x4275dbb0 conftest.h) at
../../gcc-4.8.1/gcc/c-family/c-pch.c:370
#6 0x012f05f8 in should_stack_file (pfile=0x42765800, file=0x42788130,
import=false)
at ../../gcc-4.8.1/libcpp/files.c:787
#7 0x012f097c in _cpp_stack_file (pfile=0x42765800, file=0x42788130,
import=false)
at ../../gcc-4.8.1/libcpp/files.c:872
#8 0x012f0fe4 in _cpp_stack_include (pfile=0x42765800,
fname=0x4275db90 conftest.h, angle_brackets=0,
type=IT_INCLUDE) at ../../gcc-4.8.1/libcpp/files.c:1008
#9 0x012e1fc4 in do_include_common (pfile=0x42765800, type=IT_INCLUDE)
at ../../gcc-4.8.1/libcpp/directives.c:793
#10 0x012e2024 in do_include (pfile=0x42765800) at
../../gcc-4.8.1/libcpp/directives.c:804
#11 0x012e13dc in _cpp_handle_directive (pfile=0x42765800, indented=0)
at ../../gcc-4.8.1/libcpp/directives.c:492
#12 0x012f9dc4 in _cpp_lex_token (pfile=0x42765800) at
../../gcc-4.8.1/libcpp/lex.c:1990
#13 0x01306cec in cpp_get_token_1 (pfile=0x42765800,
location=0xb0b8)
at ../../gcc-4.8.1/libcpp/macro.c:2355
#14 0x01307330 in cpp_get_token_with_location (pfile=0x42765800,
loc=0xb0b8)
at ../../gcc-4.8.1/libcpp/macro.c:2537
#15 0x005b9484 in c_lex_with_flags (value=0xb0c0,
loc=0xb0b8,
cpp_flags=0xb0b2 , lex_flags=0) at
../../gcc-4.8.1/gcc/c-family/c-lex.c:300
#16 0x003b225c in cp_lexer_get_preprocessor_token (lexer=0x0,
token=0xb0b0)
at ../../gcc-4.8.1/gcc/cp/parser.c:715
#17 0x003f64e8 in cp_parser_initial_pragma
(first_token=0xb0b0)
at ../../gcc-4.8.1/gcc/cp/parser.c:28139
#18 0x003b1d98 in cp_lexer_new_main () at
../../gcc-4.8.1/gcc/cp/parser.c:585
#19 0x003b6604 in cp_parser_new () at
../../gcc-4.8.1/gcc/cp/parser.c:3253
#20 0x003f6b78 in c_parse_file () at
../../gcc-4.8.1/gcc/cp/parser.c:28335
#21 0x005c30a0 in c_common_parse_file () at
../../gcc-4.8.1/gcc/c-family/c-opts.c:1046
#22 0x00c5f230 in compile_file () at ../../gcc-4.8.1/gcc/toplev.c:543
#23 0x00c62540 in do_compile () at ../../gcc-4.8.1/gcc/toplev.c:1864
#24 0x00c62788 in toplev_main (argc=24, argv=0xb718) at
../../gcc-4.8.1/gcc/toplev.c:1940
#25 0x012bc2c0 in main (argc=24, argv=0xb718) at
../../gcc-4.8.1/gcc/main.c:36
(gdb) print line_table
$6 = (line_maps *) 0x42e7
(gdb) print *line_table
$16 = {info_ordinary = {maps = 0x11400, allocated = 1, used = 1115871712,
cache = 0}, info_macro = {
maps = 0x10500, allocated = 0, used = 1117049688, cache = 0}, depth =
1, trace_includes = 55,
highest_location = 3, highest_line = 1117048808, max_column_hint = 0,
reallocator = 0x11500,
round_alloc_size = 0, location_adhoc_data_map = {htab = 0x0, curr_loc = 1,
allocated = 335544320, data = 0x24282d9e0}}
The used fields look strange. Later in the same call it crashes:
Program received signal SIGSEGV, Segmentation fault.
0x012fff88 in linemap_location_from_macro_expansion_p (set=0x42e7,
location=19)
at ../../gcc-4.8.1/libcpp/line-map.c:948
948 linemap_assert (location = MAX_SOURCE_LOCATION
(gdb) bt
#0 0x012fff88 in linemap_location_from_macro_expansion_p
(set=0x42e7, location=19)
at ../../gcc-4.8.1/libcpp/line-map.c:948
#1 0x012ff31c in linemap_lookup (set=0x42e7, line=19) at
../../gcc-4.8.1/libcpp/line-map.c:642
#2 0x0130065c in linemap_macro_loc_to_def_point (set=0x42e7,
location=19,
[Bug libgomp/58378] Protect libgomp against child process hanging after a Unix fork()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58378 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Having a pthread_atfork child hook that would do freeing of memory, or pthread_mutex_init etc. would only make invalid any OpenMP program using fork, even those that use it correctly.
[Bug boehm-gc/52217] [boehm-gc] revision 184100 causes segmentation fault in mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52217 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-09-10 Ever confirmed|0 |1 --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- Wait for OP check. Still assume it is an issue of static vs. shared. Set bug as waiting.
[Bug libgomp/58378] Protect libgomp against child process hanging after a Unix fork()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58378 --- Comment #6 from Olivier Grisel olivier.grisel at ensta dot org --- Alright thanks again. For reference I just discovered that the issue has recently been fixed in Python 3.4 by adding a new `forkserver` option to multiprocessing. http://bugs.python.org/issue8713
[Bug target/55543] diamond shaped inheritance involving strings leads to crashing executables (MinGW, 32 bit)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55543 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org --- I tested 4.8 and here this issue seems to be solved. Does the issue still exists for more recent 4.7 version?
[Bug target/57495] Compiling mingw targets with -mcmodel=large causes assert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57495 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- Code-models large and medium will be supported beginning with gcc 4.9 version. The feature is already present there. A back-merge of this feature isn't planned. So I close this bug as won't fix.
[Bug target/55491] Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55491 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #8 from Kai Tietz ktietz at gcc dot gnu.org --- hmm, can't reproduce this for i686-w64-mingw32 for gcc 4.7, or gcc 4.8 series. I was using here cygwin-cross, and native compiler. So I assume it might be related to the release of this compiler. So I close this bug as not reproduce-able for me.
[Bug preprocessor/58379] default mmap based implementation (mmap_gt_pch_get_address/mmap_gt_pch_use_address) is useless
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58379 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Well, it doesn't _rely_ on it - it basically makes systems where that is the case work out of the box (every system pre address-space-randomization area). If you have a system that randomizes then you have to re-define the hook.
[Bug c++/58377] spurious may be unused warning with -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- This one works for me but only with 4.8.x, not with mainline, and -Og didn't exist in 4.7.x, thus it would not qualify as a regression, I'm afraid.
[Bug rtl-optimization/58365] [4.7/4.8/4.9 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58365 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Sep 10 11:47:19 2013 New Revision: 202434 URL: http://gcc.gnu.org/viewcvs?rev=202434root=gccview=rev Log: PR rtl-optimization/58365 * cfgcleanup.c (merge_memattrs): Also clear MEM_READONLY_P resp. MEM_NOTRAP_P if they differ, or set MEM_VOLATILE_P if it differs. * gcc.c-torture/execute/pr58365.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr58365.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgcleanup.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/58365] [4.7/4.8/4.9 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58365 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Sep 10 11:48:30 2013 New Revision: 202435 URL: http://gcc.gnu.org/viewcvs?rev=202435root=gccview=rev Log: PR rtl-optimization/58365 * cfgcleanup.c (merge_memattrs): Also clear MEM_READONLY_P resp. MEM_NOTRAP_P if they differ, or set MEM_VOLATILE_P if it differs. * gcc.c-torture/execute/pr58365.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr58365.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/cfgcleanup.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/58365] [4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58365 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.7/4.8/4.9 Regression]|[4.7 Regression] likely |likely wrong code bug |wrong code bug --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed for 4.8.2+ so far.
[Bug c++/58377] spurious may be unused warning with -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.9.0 Version|unknown |4.8.1 Last reconfirmed||2013-09-10 Component|middle-end |c++ CC||xinliangli at gmail dot com Ever confirmed|0 |1 Summary|spurious may be used |spurious may be unused |uninitialized warning with |warning with -Og |-Og | --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed with the C++ FE, works with the C FE. Does not warn on trunk (for no good reason I think, the reason seems to be presence of loop structure and thus some extra BBs). Difference: trunk: [WORKLIST]: add to initial list: out_2 = PHI out_8(D)(2), out_1(8) [CHECK]: examining phi: out_2 = PHI out_8(D)(2), out_1(8) Use in stmt out_1 = PHI out_12(4), out_12(5), out_2(3) is guarded by : if (pop_first_bucket.2_10 != 0) [CHECK] Found def edge 0 in out_1 = PHI out_12(4), out_12(5), out_2(3) [CHECK] Found def edge 1 in out_1 = PHI out_12(4), out_12(5), out_2(3) Operand defs of phi out_2 = PHI out_8(D)(2), out_1(8) is guarded by : if (out_12 != 0) [CHECK]: Found unguarded use: out_1 = PHI out_12(4), out_12(5), out_2(3) [WORKLIST]: Update worklist with phi: out_1 = PHI out_12(4), out_12(5), out_2(3) [CHECK]: examining phi: out_1 = PHI out_12(4), out_12(5), out_2(3) Use in stmt out_2 = PHI out_8(D)(2), out_1(8) is guarded by : (.NOT.) if (iftmp.1_3 != 0) [CHECK] Found def edge 0 in out_1 = PHI out_12(4), out_12(5), out_2(3) [CHECK] Found def edge 1 in out_1 = PHI out_12(4), out_12(5), out_2(3) Operand defs of phi out_1 = PHI out_12(4), out_12(5), out_2(3) is guarded by : if (pop_first_bucket.2_10 != 0) (.AND.) if (out_12 != 0) (.OR.) if (pop_first_bucket.2_10 != 0) (.AND.) (.NOT.) if (out_12 != 0) Normalized to Operand defs of phi out_1 = PHI out_12(4), out_12(5), out_2(3) is guarded by : if (pop_first_bucket.2_10 != 0) ... vs. 4.8 branch: [WORKLIST]: add to initial list: out_2 = PHI out_8(D)(2), out_1(6) [CHECK]: examining phi: out_2 = PHI out_8(D)(2), out_1(6) Use in stmt out_1 = PHI out_12(4), out_12(5), out_2(3) is guarded by : if (pop_first_bucket.2_10 != 0) [CHECK] Found def edge 0 in out_1 = PHI out_12(4), out_12(5), out_2(3) [CHECK] Found def edge 1 in out_1 = PHI out_12(4), out_12(5), out_2(3) Operand defs of phi out_2 = PHI out_8(D)(2), out_1(6) is guarded by : if (out_12 != 0) [CHECK]: Found unguarded use: out_1 = PHI out_12(4), out_12(5), out_2(3) [WORKLIST]: Update worklist with phi: out_1 = PHI out_12(4), out_12(5), out_2(3) [CHECK]: examining phi: out_1 = PHI out_12(4), out_12(5), out_2(3) [CHECK]: Found unguarded use: out_2 = PHI out_8(D)(2), out_1(6) [CHECK]: Found unguarded use: _4 = PHI out_1(6), 0(7) [WORKLIST]: Update worklist with phi: _4 = PHI out_1(6), 0(7) [CHECK]: examining phi: _4 = PHI out_1(6), 0(7) [CHECK]: Found unguarded use: return _4; The IL difference is that we have bb 6: # out_1 = PHI out_12(4), out_12(5), out_2(3) # iftmp.1_3 = PHI 1(4), 0(5), 0(3) if (iftmp.1_3 != 0) goto bb 7; else goto bb 8; bb 7: out_13 = out_1; goto bb 10; ... bb 10: # _4 = PHI out_13(7), 0(9) return _4; which doesn't warn vs. bb 6: # out_1 = PHI out_12(4), out_12(5), out_2(3) # iftmp.1_3 = PHI 1(4), 0(5), 0(3) if (iftmp.1_3 != 0) goto bb 8; else goto bb 7; ... bb 8: # _4 = PHI out_1(6), 0(7) return _4; which does. The issue seems to be that the analysis doesn't consider the PHI uses in if (iftmp.1_3 != 0) goto bb 8; else goto bb 7; bb 7: # out_2 = PHI out_8(D)(2), out_1(6) guarded by anything (the out_1 use is guarded by iftmp.1_3 == 0). David - the code does if (gimple_code (use_stmt) == GIMPLE_PHI) use_bb = gimple_phi_arg_edge (use_stmt, PHI_ARG_INDEX_FROM_USE (use_p))-src; else use_bb = gimple_bb (use_stmt); if (is_use_properly_guarded (use_stmt, use_bb, ... so it chooses the source block (as approximation?). Splitting all edges results in us no longer warning here and: Use in stmt out_2 = PHI out_8(D)(15), out_1(16) is guarded by : (.NOT.) if (iftmp.1_3 != 0) Can you see to fix that please? Thanks.
[Bug middle-end/58382] New: [4.9 Regression] unwind.inc:136:1: ICE: in trunc_int_for_mode, at explow.c:55
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58382 Bug ID: 58382 Summary: [4.9 Regression] unwind.inc:136:1: ICE: in trunc_int_for_mode, at explow.c:55 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 Created attachment 30786 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30786action=edit Preprocessed source /test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu64/gcc/g cc-4.9/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.9/hppa64-hp-hpux11.11/lib / -isystem /opt/gnu64/gcc/gcc-4.9/hppa64-hp-hpux11.11/include -isystem /opt/gnu6 4/gcc/gcc-4.9/hppa64-hp-hpux11.11/sys-include-g -O2 -O2 -g -O2 -DIN_GCC - W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing -prototypes -Wold-style-definition -isystem ./include -frandom-seed=fixed-see d -Dpa64=1 -DELF=1 -mlong-calls -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-pr otector -frandom-seed=fixed-seed -Dpa64=1 -DELF=1 -mlong-calls -I. -I. -I../. ././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/../g cc -I../../../gcc/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c ../../../gcc/libgcc/ unwind-dw2.c -fvisibility=hidden -DHIDE_EXPORTS In file included from ../../../gcc/libgcc/unwind-dw2.c:1698:0: ../../../gcc/libgcc/unwind.inc: In function '_Unwind_RaiseException': ../../../gcc/libgcc/unwind.inc:136:1: internal compiler error: in trunc_int_for_mode, at explow.c:55 } ^ /test/gnu/gcc/objdir/./gcc/cc1 -fpreprocessed unwind-dw2.i -quiet -dumpbase unw ind-dw2.c -mlong-calls -auxbase-strip unwind-dw2.o -g -g -g -O2 -O2 -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-p rototypes -Wold-style-definition -version -frandom-seed=fixed-seed -fbuilding-li bgcc -fno-stack-protector -frandom-seed=fixed-seed -fexceptions -fvisibility=hidden -o unwind-dw2.s GNU C (GCC) version 4.9.0 20130909 (experimental) [trunk revision 202391] (hppa64-hp-hpux11.11) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.2, MPC version 1.0 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.9.0 20130909 (experimental) [trunk revision 202391] (hppa64-hp-hpux11.11) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.2, MPC version 1.0 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 1887fdfaba237bed4d949cbaeffd7a9b In file included from ../../../gcc/libgcc/unwind-dw2.c:1698:0: ../../../gcc/libgcc/unwind.inc: In function '_Unwind_RaiseException': ../../../gcc/libgcc/unwind.inc:136:1: internal compiler error: in trunc_int_for_mode, at explow.c:55 } ^ Introduced in r202391: 2013-09-09 Richard Sandiford rdsandif...@googlemail.com * alias.c (addr_side_effect_eval): Use gen_int_mode with the mode of the associated gen_rtx_* call. * caller-save.c (init_caller_save): Likewise. * combine.c (find_split_point, make_extraction): Likewise. (make_compound_operation): Likewise. * dwarf2out.c (mem_loc_descriptor): Likewise. * explow.c (plus_constant, probe_stack_range): Likewise. * expmed.c (expand_mult_const): Likewise. * expr.c (emit_single_push_insn_1, do_tablejump): Likewise. * reload1.c (init_reload): Likewise. * valtrack.c (cleanup_auto_inc_dec): Likewise. * var-tracking.c (adjust_mems): Likewise. * modulo-sched.c (sms_schedule): Likewise, but use gen_rtx_GT rather than gen_rtx_fmt_ee.
[Bug tree-optimization/58343] [4.9 Regression] ICE in dfs_enumerate_from, at cfganal.c:1036
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58343 --- Comment #4 from Jeffrey A. Law law at gcc dot gnu.org --- Author: law Date: Tue Sep 10 12:29:58 2013 New Revision: 202441 URL: http://gcc.gnu.org/viewcvs?rev=202441root=gccview=rev Log: PR tree-optimization/58343 * tree-ssa-threadupdate.c (thread_block): Identify and disable jump threading requests through loop headers buried in the middle of a jump threading path. * tree-ssa-threadedge.c (thread_around_empty_blocks): Fix thinko in return value/type. * gcc.c-torture/compile/pr58343.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr58343.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-threadedge.c trunk/gcc/tree-ssa-threadupdate.c
[Bug tree-optimization/58343] [4.9 Regression] ICE in dfs_enumerate_from, at cfganal.c:1036
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58343 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jeffrey A. Law law at redhat dot com --- Fixed on trunk.
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||paolo.carlini at oracle dot com --- Comment #18 from Paolo Carlini paolo.carlini at oracle dot com --- Chris, I'm going to slightly tweak / test again locally / post to the mailing list your patch in order to apply it. Please have a look to Comment #15, in the meanwhile, thanks!
[Bug c++/58380] [4.9 Regression] ice in fold_comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Seems to have started with r202296. I'll try to reduce it.
[Bug tree-optimization/58343] [4.9 Regression] ICE in dfs_enumerate_from, at cfganal.c:1036
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58343 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot de --- Comment #6 from Markus Trippelsdorf markus at trippelsdorf dot de --- *** Bug 58373 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/58373] [4.9 Regression] g++: internal compiler error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58373 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Markus Trippelsdorf markus at trippelsdorf dot de --- dup of PR58373, fixed by rev202441 . *** This bug has been marked as a duplicate of bug 58343 ***
[Bug tree-optimization/58373] [4.9 Regression] g++: internal compiler error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58373 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com --- Comment #5 from Jeffrey A. Law law at redhat dot com --- Thanks Markus -- I was going to look at this once I figure out this IA64 mis-compilation issue. One less thing to worry about now ;-)
[Bug rtl-optimization/58369] [4.8/4.9 regression] ICE in subreg_get_info when compiling boost for m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58369 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se --- Created attachment 30787 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30787action=edit hand-reduced test case This is as small as I can get it without losing the ICE.
[Bug rtl-optimization/58383] New: ICE when RTL folds vector operations using constants after gne_int_mode changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58383 Bug ID: 58383 Summary: ICE when RTL folds vector operations using constants after gne_int_mode changes Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jgreenhalgh at gcc dot gnu.org The patch set around [1/4] Using gen_int_mode instead of GEN_INT causes a number of similair regressions when building for AArch64. To pick one example, when building gcc.target/aarch64/vect-fcm-eq-d.c we can get in to the situation where simplify_unary_expression_1 is trying to simplify (V2DI: NOT (NEG X)) and will thus try to generate (V2DI: PLUS (X - 1)). Now we will call plus_constant, and from there gen_int_mode (-1, v2di). From here we call trunc_int_for_mode (-1, v2di) and trigger the assert: /* You want to truncate to a _what_? */ gcc_assert (SCALAR_INT_MODE_P (mode)); The failures eventually look like: In file included from ../src/gcc/gcc/testsuite/gcc.target/aarch64/vect-fcm-eq-d.c:9:0: ../src/gcc/gcc/testsuite/gcc.target/aarch64/vect-fcm.x: In function 'foo': ../src/gcc/gcc/testsuite/gcc.target/aarch64/vect-fcm.x:25:1: internal compiler error: in trunc_int_for_mode, at explow.c:55 } ^ 0x6abc8e trunc_int_for_mode(long, machine_mode) /work/gcc-dev/src/gcc/gcc/explow.c:55 0x69bb28 gen_int_mode(long, machine_mode) /work/gcc-dev/src/gcc/gcc/emit-rtl.c:420 0x6abcf2 plus_constant /work/gcc-dev/src/gcc/gcc/explow.c:189 0x6abcf2 plus_constant /work/gcc-dev/src/gcc/gcc/explow.c:79 0x8f107f simplify_gen_unary(rtx_code, machine_mode, rtx_def*, machine_mode) /work/gcc-dev/src/gcc/gcc/simplify-rtx.c:369 0xc55e09 propagate_rtx_1 /work/gcc-dev/src/gcc/gcc/fwprop.c:490 0xc55e6f propagate_rtx_1 /work/gcc-dev/src/gcc/gcc/fwprop.c:497 0xc55e86 propagate_rtx_1 /work/gcc-dev/src/gcc/gcc/fwprop.c:498 0xc56409 propagate_rtx /work/gcc-dev/src/gcc/gcc/fwprop.c:675 0xc57dff forward_propagate_and_simplify /work/gcc-dev/src/gcc/gcc/fwprop.c:1337 0xc57dff forward_propagate_into /work/gcc-dev/src/gcc/gcc/fwprop.c:1394 0xc58593 forward_propagate_into /work/gcc-dev/src/gcc/gcc/fwprop.c:1359 0xc58593 fwprop /work/gcc-dev/src/gcc/gcc/fwprop.c:1479 0xc58593 execute /work/gcc-dev/src/gcc/gcc/fwprop.c:1515 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.
[Bug preprocessor/58379] default mmap based implementation (mmap_gt_pch_get_address/mmap_gt_pch_use_address) is useless
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58379 --- Comment #2 from Martin Husemann martin at netbsd dot org --- (In reply to Richard Biener from comment #1) If you have a system that randomizes then you have to re-define the hook. Besides ASLR there are various things out of control of the compiler that do result in varying mapping adresses (like malloc using mmap instead of brk), so chances are low in any modern system. I'm not opposed to create a hook for NetBSD, but I have a hard time seeing a possible sensible implementation. Look at the #ifdef cascade in config/host-openbsd.c for a disgusting example of code that should not be in a compiler (IMHO). How hard is making the externalized format address neutral?
[Bug rtl-optimization/58383] ICE when RTL folds vector operations using constants after gne_int_mode changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58383 jgreenhalgh at gcc dot gnu.org changed: What|Removed |Added CC||jgreenhalgh at gcc dot gnu.org --- Comment #1 from jgreenhalgh at gcc dot gnu.org --- Created attachment 30788 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30788action=edit Proposed fix A patch along these lines works for me, covering the case where gen_int_mode is called to generate a vector integer.
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #19 from Chris Jefferson chris at bubblescope dot net --- (In reply to Mitsuru Kariya from comment #15) Created attachment 30775 [details] Patch For your convenience, I attached a patch for this problem. This algorithm is always scanned to reverse order. If a scan fails in less than enough, a re-scan is performed from the point that advanced necessary elements from the original starting point. For example, if __count is 20 and a scan fails after 18 elements succeeded, a re-scan is performed from the point that advanced 2 elements. This patch is good, but takes a different route., trying to always skip as far forwards as possible. On a small test (compiling the 'search_n/iterator.cc' test, disabling forward checking and bidirection tests, increasing TEST_DEPTH to 23, compiling -O3): Both implementations pass correctness and number of comparison tests. Mitsuru's code is about 1K smaller. My code is slightly faster (3.74sec vs 4.12sec) I think I might choose Mitsuru's code, as his code is smaller in terms of both source and binary, and the performance difference is not that big, but either would be fine.
[Bug tree-optimization/58364] [4.8/4.9 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58364 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org --- r195642 is an equivalent fix in the folder (make_range_step).
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Severity|minor |normal --- Comment #20 from Paolo Carlini paolo.carlini at oracle dot com --- I see, thanks Chris. Don't you have the performance numbers for the baseline, naive code, do you? To put in better perspective 3.74secs vs 4.12secs. Like, if the baseline is 1 or 3.5 isn't the same! In fact, I also like Mitsuru' patch, it's simplicity in particular. But again, I would not choose it if the baseline is 3.5secs.
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #21 from Paolo Carlini paolo.carlini at oracle dot com --- Sorry. Take my 1sec and 3.5secs, as, say, 4.5secs and 20secs. You see may point.
[Bug tree-optimization/58380] [4.9 Regression] ice in fold_comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com --- Comment #3 from Jeffrey A. Law law at redhat dot com --- Just a note, I'm currently looking at a mis-compilation due to those changes; it may not be worth your time to try and reduce this test until I've sorted out this other issue.
[Bug middle-end/58382] [4.9 Regression] unwind.inc:136:1: ICE: in trunc_int_for_mode, at explow.c:55
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58382 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Target Milestone|--- |4.9.0
[Bug tree-optimization/58380] [4.9 Regression] ice in fold_comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Thanks, the .ii file is huge and after an ~hour of reducing the creduce is still at original file...
[Bug tree-optimization/58380] [4.9 Regression] ice in fold_comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot de --- Comment #5 from Markus Trippelsdorf markus at trippelsdorf dot de --- Created attachment 30789 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30789action=edit reduced testcase This is what creduce came up with.
[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 --- Comment #24 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to David Fang from comment #22) Do one of these apple libunwind sources (0.30, 0.35.1) correspond to what's bundled in libgcc_s in darwin8,9,10? http://opensource.apple.com/tarballs/libunwind/ No. The libunwind sources are the replacement compact and compatibility unwinders that Apple introduced in 10.7. You will see that the 0.30 release first appears at http://www.opensource.apple.com/release/mac-os-x-107/. Note that if you look at http://www.opensource.apple.com/source/libgcc/libgcc-13/stub.c from 10.6.8, you will see that the unwinder calls resided in libgcc_s up to 10.5 after which they were subsumed into libSystem. I am unclear if the subsumed unwinder calls in 10.6.x were based on the code from libgcc but these certainly aren't based on libunwind. Since Apple never released the source code for theses files, it is difficult to know their heritage in 10.6.x. Also see... http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html
[Bug tree-optimization/58380] [4.9 Regression] ice in fold_comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- The symptom hints at a released SSA name being looked at. That happens if cfgcleanup looks at a dead code region (we especially run TODO_cleanup_cfg before TODO_update_ssa to allow passes to be forgiving with not removing dead blocks). Eventually we guarded these foldings but seem to have removed the guarding again.
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #22 from Chris Jefferson chris at bubblescope dot net --- Her are some comparisons. Just to compare, I also checked doing away with skipping optimisations altogether. Binary sizes (-O3, stripped) current head: 11928 my code: 12248 Mitsuru: 11384 No skip: 10904 Timing: current head: 3.70 my code: 3.70 Mitsuru: 4.04 No skip: 15.37 So we clearly want to do skipping. The tradeoff is between same speed and bigger executables (my code) or ~10% slower but saving 1K or so binary and some source (Mitsuru's code). I don't know what gcc/libstdc++'s general direction in that area is. I actually would expect Mitsuru's code to be faster (as it tries harder to skip forwards), but it is hard to predict how these things interact with optimisers/caches/branch predictors at a low level.
[Bug tree-optimization/58380] [4.9 Regression] ice in fold_comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380 --- Comment #7 from Jeffrey A. Law law at redhat dot com --- 202296 doesn't change anything WRT sequencing of operations; it merely allows the threader to dive a bit deeper into the CFG to determine a final target for a jump threading opportunity. Presumably David bootstrapped the trunk, then built k3d? If so, then it might be a mis-compilation of GCC itself. As I mentioned in c#3 I'm looking at one of those right now. If this failure occurs in a stage1 cc1plus, then, well, that's totally different (and much easier to track down). Either way, it's mine.
[Bug preprocessor/58381] crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58381 --- Comment #2 from Martin Husemann martin at netbsd dot org --- Created attachment 30790 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30790action=edit Restore line_table and input_location before calling fatal_error when failing a pch load With this patch, the fatal_error is properly reported: $BUILDDIR/stage1-gcc/xg++ -B $BUILDDIR/stage1-gcc -Werror -Winvalid-pch -Wno-deprecated -c conftest.cc conftest.cc:1:0: fatal error: had to relocate PCH #include conftest.h ^ compilation terminated.
[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstreamchar, std::char_traitschar, std::allocatorchar '
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314 --- Comment #40 from Pawel Sikora pluto at agmk dot net --- $ grep ZTv0 * gnu.ver:_ZTv0_n12_NS*; gnu.ver:_ZTv0_n24_NS*; gnu-versioned-namespace.ver:_ZTv0_n24_NS*; versioned namespace doesn't provide *n12* for i686.
[Bug middle-end/58335] S/390: reload vs lra regression - testcase builtin-in-setjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58335 Vladimir Makarov vmakarov at gcc dot gnu.org changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #1 from Vladimir Makarov vmakarov at gcc dot gnu.org --- LRA does not update elimination offset on subsequent passes as insns for previous elimination offset updates are more complicated on s390 than usual. I guess we need a different elimination approach (without parsing already generated offset elimination insn) independent on insns generated. It is necessary not only for s390 but for better LRA portability in whole. I hope to finish this until end of the week.
gcc cc1 seg fault on large file with many function calls
I have a generated C code file that contains a very large number of function calls, all with similar function names (ie ff1, ff2, ff3, ..., ff50). It compiles using gcc versions 3.4.6 and 4.1.2. But using version 4.4.7, it gets gcc: Internal error: Segmentation fault (program cc1) The code file is 786Mb, so it's large, but not that large. But there are a lot of static functions declared, and a lot of calls to these functions. Any ideas? -- View this message in context: http://gcc.1065356.n5.nabble.com/gcc-cc1-seg-fault-on-large-file-with-many-function-calls-tp967294.html Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug preprocessor/58381] crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58381 --- Comment #1 from Martin Husemann martin at netbsd dot org --- The global pointer line_table is changed to the contents of the precompiled header file in gt_pch_restore in this loop: /* Read in all the global pointers, in 6 easy loops. */ for (rt = gt_ggc_rtab; *rt; rt++) for (rti = *rt; rti-base != NULL; rti++) for (i = 0; i rti-nelt; i++) if (fread ((char *)rti-base + rti-stride * i, sizeof (void *), 1, f) != 1) fatal_error (can%'t read PCH file: %m); but not reset to the previous values when the compiler decides to not use the pch contents (for example because the address of the mmap differs). We probably need to save at least line_table (and maybe input_location) at the start of this function and restore it before invoking fatal_error.
[Bug middle-end/58382] [4.9 Regression] unwind.inc:136:1: ICE: in trunc_int_for_mode, at explow.c:55
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58382
--- Comment #1 from John David Anglin danglin at gcc dot gnu.org ---
Breakpoint 1, trunc_int_for_mode (c=8, mode=DFmode)
at ../../gcc/gcc/explow.c:55
55gcc_assert (SCALAR_INT_MODE_P (mode));
(gdb) bt
#0 trunc_int_for_mode (c=8, mode=DFmode) at ../../gcc/gcc/explow.c:55
#1 0x406bb254 in gen_int_mode (c=8, mode=DFmode)
at ../../gcc/gcc/emit-rtl.c:420
#2 0x4110e470 in adjust_mems (loc=0x83fffd533100, old_rtx=0x0,
data=0x83fffdff14b8) at ../../gcc/gcc/var-tracking.c:1058
#3 0x40c36a20 in simplify_replace_fn_rtx (x=0x83fffd533100,
old_rtx=0x0, fn=0x402ec440, data=0x83fffdff14b8)
at ../../gcc/gcc/simplify-rtx.c:426
#4 0x4110e168 in adjust_mems (loc=0x83fffd5cc558, old_rtx=0x0,
data=0x83fffdff14b8) at ../../gcc/gcc/var-tracking.c:1035
#5 0x40c36a20 in simplify_replace_fn_rtx (x=0x83fffd5cc558,
old_rtx=0x0, fn=0x402ec440, data=0x83fffdff14b8)
at ../../gcc/gcc/simplify-rtx.c:426
#6 0x4110eb78 in adjust_mem_stores (loc=0x83fffd5cc558,
expr=0x83fffd5cc570, data=0x83fffdff14b8)
at ../../gcc/gcc/var-tracking.c:1157
#7 0x40bc7e98 in note_stores (x=0x83fffd5cc570,
fun=0x402ec450, data=0x83fffdff14b8)
at ../../gcc/gcc/rtlanal.c:1518
#8 0x4110ec64 in adjust_insn (bb=0x83fffda7eb60,
insn=0x83fffdae8798) at ../../gcc/gcc/var-tracking.c:1207
#9 0x41139de8 in vt_initialize ()
at ../../gcc/gcc/var-tracking.c:9973
---Type return to continue, or q return to quit---
#10 0x4113ad54 in variable_tracking_main_1 ()
at ../../gcc/gcc/var-tracking.c:10171
#11 0x4113b074 in variable_tracking_main ()
at ../../gcc/gcc/var-tracking.c:10224
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) frame 8
#8 0x4110ec64 in adjust_insn (bb=0x83fffda7eb60,
insn=0x83fffdae8798) at ../../gcc/gcc/var-tracking.c:1207
1207 note_stores (PATTERN (insn), adjust_mem_stores, amd);
(gdb) p debug_rtx(insn)
(insn/f:TI 248 240 249 2 (set (mem:DF (post_inc:DF (reg:DI 1 %r1)) [0 S8 A64])
(reg:DF 49 %fr21)) ../../../gcc/libgcc/unwind.inc:83 119 {*pa.md:4025}
(expr_list:REG_DEAD (reg:DF 49 %fr21)
(expr_list:REG_FRAME_RELATED_EXPR (set (mem:DF (plus:DI (reg/f:DI 30
%r30)
(const_int -200 [0xff38])) [0 S8 A64])
(reg:DF 49 %fr21))
(nil
$1 = void
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #23 from Paolo Carlini paolo.carlini at oracle dot com --- Thanks a lot Chris. Sorry if I bother you for a few minutes more: when you say doing away with skipping optimizations altogether, you mean, essentially, using the algorithm we have got now for forward iterators? Which is also, if I remember correctly, what we had earlier for random access iterators too? In that case, I'm really unsure: I'm tempted by what Mitsuru is proposing, but I'm not 100% sure, not because of the 10% difference, but more importantly because we know well what we have got, nobody complained for so many years, and your change would be only a small tweak of it. Also, I know you are around to maintain it, which isn't a minor detail! In case, would you be willing to maintain Mitsuru's code too? Eventually, I think I will send both patches to the mailing list with my personal opinion, and I will ask.
[Bug rtl-optimization/58384] New: [4.9 regression] Runfail on spec2000/253.perlbmk if lto and pre-reload scheduler is used on x86 after r200133.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58384 Bug ID: 58384 Summary: [4.9 regression] Runfail on spec2000/253.perlbmk if lto and pre-reload scheduler is used on x86 after r200133. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ysrumyan at gmail dot com We also assume that arm can have the same problem at given benchmark if -flto is used to compile since pre-reload scheduler is used by default on it. The issue can be reproduced at attached test-case extracted from 253.perlbmk sources (function Perl_pp_entersub, file pp_hot.c). Before r200133 forward propagation (fwprop1 for rtl) performs substitution of stored value to subsequent load with the same base, but after this fix does not. Looking at assembly files for test-case we can see that -- before fix -- callrealloc movq(%rbx), %r8 movq%rax, %r9 movq%rax, %rcx movq8(%rsp), %rdx movq%rax, 24(%r8) movq%rax, (%r8) jmp.L4 i.e. return value of 'realloc' is copied to %r9 and %rcx which correspondent to pre temporaries. -- after fix -- (without pre-reload scheduler) callrealloc movq(%rbx), %rcx movq(%rbx), %r8 movq8(%rsp), %rdx movq%rax, 24(%rcx) movq%rax, (%rcx) movq(%r8), %rcx --- redundant load movq%rcx, %rax jmp.L4 i.w. we can see redundant load from %r8. But if we turn on pre-reload scheduler, this load will be unlegal hoisted cross interleaved store (we got RT error on 253.perlbmk) and we can see it in assembly: callrealloc movq(%rbx), %r8 movq8(%rsp), %rdx movq(%r8), %rcx --- non-legal code motion movq%rax, 24(%r8) movq%rax, (%r8) movq%rcx, %rax jmp.L4 To reproduce compile attached test-case with options -Ofast -march=corei7 -fschedule-insns --param sched-pressure-algorithm=1 -fsched-pressure
[Bug target/58361] Wrong floating point code generated for ARM target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58361 --- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org --- Author: rearnsha Date: Tue Sep 10 16:46:55 2013 New Revision: 202475 URL: http://gcc.gnu.org/viewcvs?rev=202475root=gccview=rev Log: PR target/58361 * arm/vfp.md (combine_vcvt_f32_FCVTI32typename): Fix pattern to support conditional execution. (combine_vcvt_f64_FCVTI32typename): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/vfp.md
[Bug rtl-optimization/58384] [4.9 regression] Runfail on spec2000/253.perlbmk if lto and pre-reload scheduler is used on x86 after r200133.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58384 --- Comment #1 from Yuri Rumyantsev ysrumyan at gmail dot com --- Created attachment 30791 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30791action=edit test-case to reproduce This is compile only test which must be compiled with pre-reload scheduler, i.e. with '-Ofast -march=corei7 -fschedule-insns --param sched-pressure-algorithm=1 -fsched-pressure' options.
[Bug c++/58377] spurious may be used uninitialized warning with -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
davidxl at google dot com changed:
What|Removed |Added
CC||davidxl at google dot com
--- Comment #6 from davidxl at google dot com ---
There are some spurious PHIs (for out) with -g.
Bad dot file (-g):
digraph t.cc.153t.uninit2 {
overlap=false;
subgraph int my_pop() {
color=black;
label=int my_pop();
fn_0_basic_block_1
[shape=Mdiamond,style=filled,fillcolor=white,label=EXIT];
fn_0_basic_block_2 [shape=record,style=filled,fillcolor=lightgrey,label={
FREQ:880 |\bb\ 2\:\l\
goto\ \bb\ 7\;\l\
}];
fn_0_basic_block_7 [shape=record,style=filled,fillcolor=lightgrey,label={
FREQ:1 |\bb\ 7\:\l\
|#\ out_2\ =\ PHI\ \out_8(D)(2),\ out_1(6)\\l\
|pop_first_bucket.2_10\ =\ pop_first_bucket;\l\
|if\ (pop_first_bucket.2_10\ !=\ 0)\l\
\ \ goto\ \bb\ 3\;\l\
else\l\
\ \ goto\ \bb\ 8\;\l\
}];
fn_0_basic_block_3 [shape=record,style=filled,fillcolor=lightgrey,label={
FREQ:9550 |\bb\ 3\:\l\
|if\ (pop_first_bucket.2_10\ !=\ 0)\l\
\ \ goto\ \bb\ 4\;\l\
else\l\
\ \ goto\ \bb\ 6\;\l\
}];
fn_0_basic_block_4 [shape=record,style=filled,fillcolor=lightgrey,label={
FREQ:2769 |\bb\ 4\:\l\
|out_12\ =\ pop\ ();\l\
|if\ (out_12\ !=\ 0)\l\
\ \ goto\ \bb\ 6\;\l\
else\l\
\ \ goto\ \bb\ 5\;\l\
}];
fn_0_basic_block_5 [shape=record,style=filled,fillcolor=lightgrey,label={
FREQ:2520 |\bb\ 5\:\l\
}];
fn_0_basic_block_6 [shape=record,style=filled,fillcolor=lightgrey,label={
FREQ:9550 |\bb\ 6\:\l\
|#\ out_1\ =\ PHI\ \out_12(4),\ out_12(5),\ out_2(3)\\l\
|#\ iftmp.1_3\ =\ PHI\ \1(4),\ 0(5),\ 0(3)\\l\
|if\ (iftmp.1_3\ !=\ 0)\l\
\ \ goto\ \bb\ 8\;\l\
else\l\
\ \ goto\ \bb\ 7\;\l\
}];
fn_0_basic_block_8 [shape=record,style=filled,fillcolor=lightgrey,label={
FREQ:880 |\bb\ 8\:\l\
|#\ _4\ =\ PHI\ \out_1(6),\ 0(7)\\l\
|return\ _4;\l\
}];
fn_0_basic_block_0
[shape=Mdiamond,style=filled,fillcolor=white,label=ENTRY];
fn_0_basic_block_0:s - fn_0_basic_block_2:n
[style=solid,bold,color=blue,weight=100,constraint=true, label=[100%]];
fn_0_basic_block_2:s - fn_0_basic_block_7:n
[style=solid,bold,color=blue,weight=100,constraint=true, label=[100%]];
fn_0_basic_block_3:s - fn_0_basic_block_4:n
[style=solid,bold,color=black,weight=10,constraint=true, label=[29%]];
fn_0_basic_block_3:s - fn_0_basic_block_6:n
[style=solid,bold,color=black,weight=10,constraint=true, label=[71%]];
fn_0_basic_block_4:s - fn_0_basic_block_6:n
[style=solid,bold,color=black,weight=10,constraint=true, label=[9%]];
fn_0_basic_block_4:s - fn_0_basic_block_5:n
[style=solid,bold,color=black,weight=10,constraint=true, label=[91%]];
fn_0_basic_block_5:s - fn_0_basic_block_6:n
[style=solid,bold,color=blue,weight=100,constraint=true, label=[100%]];
fn_0_basic_block_6:s - fn_0_basic_block_8:n
[style=solid,bold,color=black,weight=10,constraint=true, label=[4%]];
fn_0_basic_block_6:s - fn_0_basic_block_7:n
[style=dotted,bold,color=blue,weight=10,constraint=false, label=[95%]];
fn_0_basic_block_7:s - fn_0_basic_block_3:n
[style=solid,bold,color=black,weight=10,constraint=true, label=[95%]];
fn_0_basic_block_7:s - fn_0_basic_block_8:n
[style=solid,bold,color=black,weight=10,constraint=true, label=[4%]];
fn_0_basic_block_8:s - fn_0_basic_block_1:n
[style=solid,bold,color=black,weight=10,constraint=true, label=[100%]];
fn_0_basic_block_0:s - fn_0_basic_block_1:n
[style=invis,constraint=true];
}
}
GCC reports unguarded use of out at return statement. return value is defined
by
_4 = PHI (out_1(6), 0(7))
where
out_1 = PHI (out_12 (4), out_12 (5), out_2 (3))
where
out_2 = PHI (out_8(D)(2), out_1 (6))
This phi introduces uninitialized variable use.
To compare, the good dot file is :
digraph t.cc.133t.uninit1 {
overlap=false;
subgraph int my_pop() {
color=black;
label=int my_pop();
subgraph cluster_0_1 {
style=filled;
color=darkgreen;
fillcolor=grey88;
label=loop 1;
labeljust=l;
penwidth=2;
fn_0_basic_block_5 [shape=record,style=filled,fillcolor=lightgrey,label={
FREQ:1 |\bb\ 5\:\l\
|pop_first_bucket.2_10\ =\ pop_first_bucket;\l\
|if\ (pop_first_bucket.2_10\ !=\ 0)\l\
\ \ goto\ \bb\ 3\;\l\
else\l\
\ \ goto\ \bb\ 6\;\l\
}];
fn_0_basic_block_3 [shape=record,style=filled,fillcolor=lightgrey,label={
FREQ:2769 |\bb\ 3\:\l\
|out_12\ =\ pop\ ();\l\
|if\ (out_12\ !=\ 0)\l\
\ \ goto\ \bb\ 6\;\l\
else\l\
\ \ goto\ \bb\ 4\;\l\
}];
fn_0_basic_block_4 [shape=record,style=filled,fillcolor=lightgrey,label={
FREQ:2520 |\bb\ 4\:\l\
}];
}
fn_0_basic_block_0
[shape=Mdiamond,style=filled,fillcolor=white,label=ENTRY];
fn_0_basic_block_1
[shape=Mdiamond,style=filled,fillcolor=white,label=EXIT];
fn_0_basic_block_2 [shape=record,style=filled,fillcolor=lightgrey,label={
FREQ:880 |\bb\ 2\:\l\
goto\ \bb\ 5\;\l\
}];
fn_0_basic_block_6
[Bug target/58361] Wrong floating point code generated for ARM target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58361 --- Comment #4 from Richard Earnshaw rearnsha at gcc dot gnu.org --- Author: rearnsha Date: Tue Sep 10 16:55:44 2013 New Revision: 202477 URL: http://gcc.gnu.org/viewcvs?rev=202477root=gccview=rev Log: PR target/58361 * arm/vfp.md (combine_vcvt_f32_FCVTI32typename): Fix pattern to support conditional execution. (combine_vcvt_f64_FCVTI32typename): Likewise. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/arm/vfp.md
[Bug rtl-optimization/58369] [4.8/4.9 regression] ICE in subreg_get_info when compiling boost for m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58369 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se --- The ICE occurs because reload is asking for a DFmode (8-byte) subreg of an XFmode (12-byte) hardreg, but 12 % 8 != 0 so the gcc_assert fails.
[Bug tree-optimization/58380] [4.9 Regression] ice in fold_comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380 --- Comment #9 from David Binderman dcb314 at hotmail dot com --- (In reply to Jeffrey A. Law from comment #7) Presumably David bootstrapped the trunk, then built k3d? Yes, the bootstrap ran fine with the usual -g -O2 on BOOT_CFLAGS. If this failure occurs in a stage1 cc1plus, then, well, that's totally different (and much easier to track down). Yes, exactly the same Segmentation fault does occur in a stage1 cc1plus. Command line was $ ../results/bin/gcc -c -O2 -B/home/dcb/gcc/working/stage1-gcc/ -v bug118.cc ... /home/dcb/gcc/working/stage1-gcc/cc1plus -quiet ...
[Bug target/58375] internal compiler error: in push_reload, at reload.c:1360
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58375 --- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org --- Created attachment 30792 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30792action=edit Channel.cpp C++ source Confirmed with this source, looks like a register allocator issue. $ avr-g++ Channel.cpp -mmcu=atmega2561 -Os -c -v Target: avr Configured with: ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-4.8-mingw32 --host=i386-mingw32 --build=i686-linux-gnu --enable-languages=c,c++ --disable-nls --disable-shared --with-dwarf2 Thread model: single gcc version 4.8.0 20130306 (experimental) (GCC) GNU C++ (GCC) version 4.8.0 20130306 (experimental) (avr) compiled by GNU C version 3.4.5 (mingw-vista special r2), GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 Channel.cpp: In member function 'virtual void Screen_Setup_Channel::display()': Channel.cpp:101:1: internal compiler error: in push_reload, at reload.c:1360 } ^ Channel.cpp:101:1: internal compiler error: Segmentation fault
[Bug target/54412] Request for 32-byte stack alignment with -mavx on Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412 --- Comment #2 from R Copley rcopley at gmail dot com --- Created attachment 30793 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30793action=edit As before, but with explicitly 32-byte aligned variables
[Bug other/58375] [4.8 Regression] internal compiler error: in push_reload, at reload.c:1360
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58375 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Keywords||ra Status|WAITING |NEW Component|target |other Known to work||4.7.2 Host|MacOS 10.8 (Darwin | |linus.fritz.box 12.4.0 | |Darwin Kernel Version | |12.4.0: Wed May 1 17:57:12 | |PDT 2013; | |root:xnu-2050.24.15~1/RELEA | |SE_X86_64 x86_64) | Blocks||56183 Summary|internal compiler error: in |[4.8 Regression] internal |push_reload, at |compiler error: in |reload.c:1360 |push_reload, at ||reload.c:1360
