[Bug libmudflap/58230] multiple test fail in german language version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58230 --- Comment #1 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 30845 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30845action=edit proposed patch
[Bug c++/58455] New: spurious may be used uninitialized warning with -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58455
Bug ID: 58455
Summary: spurious may be used uninitialized 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
(My gcc 4.8 is new enough that it has the fix for PR middle-end/58377)
I have a case of C++ code that spuriously warns about a may be used
uninitialized variable. I haven't been able to turn this into similar C code
that still warns. Also the || false in the if statement seems to do
something -- without it I don't get the warning!
$ cat y.cpp
struct B
{
int offset;
bool is_loaded(unsigned char *p1)
{
if (offset) {
*p1 = offset;
return true;
}
return false;
}
};
unsigned char match(struct B ref)
{
unsigned char ref_offset;
if (!ref.is_loaded(ref_offset) || false)
return ref_offset;
else
return 0;
}
$ gcc -v -Wall -Og -Werror -c ~/y.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-10ubuntu3' --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-10ubuntu3)
COLLECT_GCC_OPTIONS='-v' '-Wall' '-Og' '-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 /home/roland/y.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' '-Wall' '-Og' '-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-10ubuntu3' --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
[Bug c++/58455] spurious may be used uninitialized warning with -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58455 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Why do you think this is spurious? You are returning ref_offset if is_loaded method returns false, i.e. exactly when ref_offset hasn't been initialized.
[Bug c++/58455] spurious may be used uninitialized warning with -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58455
--- Comment #2 from Roland Dreier rbd at debian dot org ---
Arg, I don't seem to be able to avoid breaking my test cases while minimizing
them. So for my first test case here the issue seems to be that -Og is the
only level that *correctly* warns, which is surprising and I guess is a bug in
it's own right!
Sorry for the confusion.
However the test case I was originally working with and then broke is the
following:
$ cat y.cpp
struct B
{
int offset;
bool is_loaded(unsigned char *p1)
{
if (offset) {
*p1 = offset;
return true;
}
return false;
}
};
unsigned char match(struct B ref)
{
do {
unsigned char ref_offset;
if (!ref.is_loaded(ref_offset) || false)
continue;
return ref_offset;
} while (false);
return 0;
}
$ for o in Og O0 O1 O2 O3; do echo == $o ==; gcc -Wall -$o -Werror -c ~/y.cpp;
done
== Og ==
/home/roland/y.cpp: In function ‘unsigned char match(B)’:
/home/roland/y.cpp:17:31: error: ‘ref_offset’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
unsigned char ref_offset;
^
cc1plus: all warnings being treated as errors
== O0 ==
== O1 ==
== O2 ==
== O3 ==
in that case is_loaded returns true when it sets the pointer; if it returns
false we continue, fall out of the loop and don't touch the pointer value. So
I'm pretty sure this case is correctly classified as spurious.
[Bug ipa/58332] [4.9 Regression] error: inlined_to pointer is set but no predecessors found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58332 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/58456] New: FAIL: gcc.dg/tree-ssa/slsr-39.c scan-tree-dump-times slsr MEM 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58456 Bug ID: 58456 Summary: FAIL: gcc.dg/tree-ssa/slsr-39.c scan-tree-dump-times slsr MEM 4 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: amker at gcc dot gnu.org Target: ia64-*-* Created attachment 30846 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30846action=edit slsr-39.c.126t.slsr $ ../../xgcc -B../../ ../../../../gcc/testsuite/gcc.dg/tree-ssa/slsr-39.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fdump-tree-slsr -S -o slsr-39.s $ grep MEM slsr-39.c.126t.slsr _12 = MEM[(int[50] *)_17]; MEM[(int[50] *)_20] = _13;
[Bug target/58442] bootstrapping vax crashes on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #3 from Martin Husemann martin at netbsd dot org --- 0x92c9fc recog_1(rtx, rtx, int*)+2:movab 0xff60(sp),sp 0x92ca01 recog_1(rtx, rtx, int*)+7: movab *0xef3cfc _GLOBAL_OFFSET_TABLE_+1548,0xffd8(fp) 0x92ca09 recog_1(rtx, rtx, int*)+15: movl 0x4(ap),r0 0x92ca0d recog_1(rtx, rtx, int*)+19: movl 0x4(r0),0xffdc(fp) 0x92ca12 recog_1(rtx, rtx, int*)+24: movw *0xffdc(fp),r0 0x92ca16 recog_1(rtx, rtx, int*)+28: movzwl r0,r0 0x92ca19 recog_1(rtx, rtx, int*)+31: movl r0,0xff64(fp) 0x92ca1e recog_1(rtx, rtx, int*)+36: cmpl 0xff64(fp),$0x2c 0x92ca23 recog_1(rtx, rtx, int*)+41: beql 0x92ca60 recog_1(rtx, rtx, int*)+102 0x92ca25 recog_1(rtx, rtx, int*)+43: cmpl 0xff64(fp),$0x007a 0x92ca2e recog_1(rtx, rtx, int*)+52: bneq 0x92ca33 recog_1(rtx, rtx, int*)+57 0x92ca30 recog_1(rtx, rtx, int*)+54: brw 0x92cbe1 recog_1(rtx, rtx, int*)+487 0x92ca33 recog_1(rtx, rtx, int*)+57: pushl $0x6 0x92ca35 recog_1(rtx, rtx, int*)+59: pushl 0xffdc(fp) 0x92ca38 recog_1(rtx, rtx, int*)+62: calls $0x2,0x6715e8 nonimmediate_operand(rtx_def*, machine_mode) 0x92ca3f recog_1(rtx, rtx, int*)+69: clrb 0xff6b(fp) 0x92ca43 recog_1(rtx, rtx, int*)+73: tstl r0 0x92ca45 recog_1(rtx, rtx, int*)+75: beql 0x92ca4c recog_1(rtx, rtx, int*)+82 0x92ca47 recog_1(rtx, rtx, int*)+77: movb $0x1,0xff6b(fp) 0x92ca4c recog_1(rtx, rtx, int*)+82: tstb 0xff6b(fp) 0x92ca50 recog_1(rtx, rtx, int*)+86: bneq 0x92ca55 recog_1(rtx, rtx, int*)+91 0x92ca52 recog_1(rtx, rtx, int*)+88: brw 0x92df46 recog_1(rtx, rtx, int*)+5452 0x92ca55 recog_1(rtx, rtx, int*)+91: movl 0xffdc(fp),*0xef3cfc _GLOBAL_OFFSET_TABLE_+1548 0x92ca5d recog_1(rtx, rtx, int*)+99: brw 0x92cf4a recog_1(rtx, rtx, int*)+1360 0x92ca60 recog_1(rtx, rtx, int*)+102: pushl $0x6 0x92ca62 recog_1(rtx, rtx, int*)+104: pushl 0xffdc(fp) 0x92ca65 recog_1(rtx, rtx, int*)+107: calls $0x2,0x66d802 push_operand(rtx_def*, machine_mode) 0x92ca6c recog_1(rtx, rtx, int*)+114: clrb 0xff6c(fp) 0x92ca70 recog_1(rtx, rtx, int*)+118: tstl r0 0x92ca72 recog_1(rtx, rtx, int*)+120: beql 0x92ca79 recog_1(rtx, rtx, int*)+127 0x92ca74 recog_1(rtx, rtx, int*)+122: movb $0x1,0xff6c(fp) 0x92ca79 recog_1(rtx, rtx, int*)+127: tstb 0xff6c(fp) 0x92ca7d recog_1(rtx, rtx, int*)+131: beql 0x92ca33 recog_1(rtx, rtx, int*)+57 0x92ca7f recog_1(rtx, rtx, int*)+133: movl 0xffdc(fp),*0xef3cfc _GLOBAL_OFFSET_TABLE_+1548 0x92ca87 recog_1(rtx, rtx, int*)+141: movl 0x4(ap),r0 0x92ca8b recog_1(rtx, rtx, int*)+145: movl 0x8(r0),0xffdc(fp) 0x92ca90 recog_1(rtx, rtx, int*)+150: movl 0xffdc(fp),r0 0x92ca94 recog_1(rtx, rtx, int*)+154: movb 0x2(r0),r0 0x92ca98 recog_1(rtx, rtx, int*)+158: movzbl r0,r0 0x92ca9b recog_1(rtx, rtx, int*)+161: cmpl r0,$0x6 0x92ca9e recog_1(rtx, rtx, int*)+164: bneq 0x92caac recog_1(rtx, rtx, int*)+178 0x92caa0 recog_1(rtx, rtx, int*)+166: movw *0xffdc(fp),r0 0x92caa4 recog_1(rtx, rtx, int*)+170: movzwl r0,r0 0x92caa7 recog_1(rtx, rtx, int*)+173: cmpl r0,$0x32 0x92caaa recog_1(rtx, rtx, int*)+176: beql 0x92cab8 recog_1(rtx, rtx, int*)+190 0x92caac recog_1(rtx, rtx, int*)+178: movl 0x4(ap),r0 0x92cab0 recog_1(rtx, rtx, int*)+182: movl 0x4(r0),0xffdc(fp) 0x92cab5 recog_1(rtx, rtx, int*)+187: brw 0x92ca33 recog_1(rtx, rtx, int*)+57 0x92cab8 recog_1(rtx, rtx, int*)+190: movl 0xffdc(fp),r0 0x92cabc recog_1(rtx, rtx, int*)+194: movl 0x4(r0),0xffe0(fp) 0x92cac1 recog_1(rtx, rtx, int*)+199: pushl $0x6 0x92cac3 recog_1(rtx, rtx, int*)+201: pushl 0xffe0(fp) 0x92cac6 recog_1(rtx, rtx, int*)+204: calls $0x2,0x671620 register_operand(rtx_def*, machine_mode) 0x92cacd recog_1(rtx, rtx, int*)+211: clrb 0xff6d(fp) 0x92cad1 recog_1(rtx, rtx, int*)+215: tstl r0 0x92cad3 recog_1(rtx, rtx, int*)+217: beql 0x92cada recog_1(rtx, rtx, int*)+224 0x92cad5 recog_1(rtx, rtx, int*)+219: movb $0x1,0xff6d(fp) 0x92cada recog_1(rtx, rtx, int*)+224: tstb 0xff6d(fp) 0x92cade recog_1(rtx, rtx, int*)+228: beql 0x92caf0 recog_1(rtx, rtx, int*)+246 0x92cae0 recog_1(rtx, rtx, int*)+230: movab *0xef3cfc _GLOBAL_OFFSET_TABLE_+1548,r0 0x92cae7 recog_1(rtx, rtx, int*)+237: addl2 $0x4,r0 0x92caea recog_1(rtx, rtx, int*)+240: movl 0xffe0(fp),(r0) 0x92caee recog_1(rtx, rtx, int*)+244: brb 0x92cafc recog_1(rtx, rtx, int*)+258 0x92caf0 recog_1(rtx, rtx, int*)+246: movl
[Bug c++/58457] New: ICE when placement new operator is used with using keyword and custom constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58457
Bug ID: 58457
Summary: ICE when placement new operator is used with using
keyword and custom constructor
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzilla.gcc at buszta dot info
Created attachment 30847
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30847action=edit
Preprocessed source
Minimal reproduction code:
struct allocator
{
void operator delete(void*) {}
void* operator new(unsigned int, void*) {}
};
struct type : public allocator
{
type() {}
using allocator::operator new;
using allocator::operator delete;
};
int main()
{
new (0) type;
return 0;
}
Compiler output:
g++ main.cpp -o main
main.cpp: In function 'int main()':
main.cpp:16:13: internal compiler error: in instantiate_type, at
cp/class.c:7512
new (0) type;
^
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.8/README.Bugs for instructions.
Preprocessed source stored into /tmp/cc4KIZ6k.out file, please attach this to
your bugreport.
make: *** [main] Error 1
Compiler version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.8/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.1-10'
--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-i386/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-i386
--with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-targets=all --enable-multiarch --with-arch-32=i586
--with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.8.1 (Debian 4.8.1-10)
Non reproducible on older compilers.
[Bug tree-optimization/58456] FAIL: gcc.dg/tree-ssa/slsr-39.c scan-tree-dump-times slsr MEM 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58456 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-18 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug c++/58455] spurious may be used uninitialized warning with -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58455
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-09-18
Ever confirmed|0 |1
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Roland Dreier from comment #2)
Arg, I don't seem to be able to avoid breaking my test cases while
minimizing them. So for my first test case here the issue seems to be that
-Og is the only level that *correctly* warns, which is surprising and I
guess is a bug in it's own right!
Sorry for the confusion.
However the test case I was originally working with and then broke is the
following:
$ cat y.cpp
struct B
{
int offset;
bool is_loaded(unsigned char *p1)
{
if (offset) {
*p1 = offset;
return true;
}
return false;
}
};
unsigned char match(struct B ref)
{
do {
unsigned char ref_offset;
if (!ref.is_loaded(ref_offset) || false)
continue;
return ref_offset;
} while (false);
return 0;
}
$ for o in Og O0 O1 O2 O3; do echo == $o ==; gcc -Wall -$o -Werror -c
~/y.cpp; done
== Og ==
/home/roland/y.cpp: In function ‘unsigned char match(B)’:
/home/roland/y.cpp:17:31: error: ‘ref_offset’ may be used uninitialized in
this function [-Werror=maybe-uninitialized]
unsigned char ref_offset;
^
cc1plus: all warnings being treated as errors
== O0 ==
== O1 ==
== O2 ==
== O3 ==
in that case is_loaded returns true when it sets the pointer; if it returns
false we continue, fall out of the loop and don't touch the pointer value.
So I'm pretty sure this case is correctly classified as spurious.
Confirmed. -Og misses a simple jump-threading to un-confuse the CFG here:
bb 2:
_7 = ref.offset;
if (_7 != 0)
goto bb 3;
else
goto bb 4;
bb 3:
ref_offset_8 = (unsigned char) _7;
bb 4:
# _9 = PHI 0(2), 1(3)
# ref_offset_6 = PHI ref_offset_5(D)(2), ref_offset_8(3)
if (_9 != 0)
goto bb 5;
else
goto bb 6;
bb 5:
bb 6:
# iftmp.1_1 = PHI 1(4), 0(5)
if (iftmp.1_1 != 0)
goto bb 8;
else
goto bb 7;
bb 7:
bb 8:
# _2 = PHI ref_offset_6(7), 0(6)
return _2;
which is caused by not folding the || false and gimplifying it to
D.2218 = B::is_loaded (ref, ref_offset);
D.2219 = ~D.2218;
if (D.2219 != 0) goto D.2215; else goto D.2220;
D.2220:
if (0 != 0) goto D.2215; else goto D.2216;
D.2215:
iftmp.1 = 1;
goto D.2217;
D.2216:
iftmp.1 = 0;
D.2217:
retval.0 = iftmp.1;
if (retval.0 != 0) goto D.2221; else goto D.;
D.2221:
goto D.2211;
D.:
D.2223 = ref_offset;
return D.2223;
After early CCP we then alreay have the final
bb 7:
# iftmp.1_1 = PHI 1(5), 0(6)
retval.0_10 = iftmp.1_1;
if (retval.0_10 != 0)
goto bb 9;
else
goto bb 8;
bb 8:
ref_offset_11 = ref_offset_13;
goto bb 10;
bb 9:
_14 = 0;
patterns. With -O1+ phiopt merges those blocks. IMHO this asks for
moving/adding phiopt in early optimizations. phiopt needs copyproped
IL, so the natural place is to add it after a copyprop pass (relying
on copyprops simple DCE to clean out empty forwarder blocks and CFG cleanup
for removing them).
[Bug tree-optimization/58451] ICE with segfault at -O3 on x86_64-linux-gnu (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58451 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Should be already fixed by richi's r202644.
[Bug tree-optimization/58447] ICE: verify_gimple failed tree-cfg.c:4819
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58447 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Should be already fixed by richi's r202644.
[Bug c++/58457] [4.8/4.9 Regression] ICE when placement new operator is used with using keyword and custom constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58457 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-18 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.8.2 Summary|ICE when placement new |[4.8/4.9 Regression] ICE |operator is used with using |when placement new operator |keyword and custom |is used with using keyword |constructor |and custom constructor Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug c++/58455] spurious may be used uninitialized warning with -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58455 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Mine. Adding a phiopt pass isn't enough to fix this as we still end up with bb 4: # _9 = PHI 0(2), 1(3) # ref_offset_6 = PHI ref_offset_5(D)(2), ref_offset_8(3) _10 = ~_9; if (_10 != 0) goto bb 6; else goto bb 5; bb 5: bb 6: # _2 = PHI ref_offset_6(5), 0(4) where -O1 needs DOM to thread the two jumps out of bb 4 and phicprop to clean up the result. But at -Og we definitely do not want to perform jump threading. During gimplification we are confused by the condition being wrapped inside a CLEANUP_POINT and thus gimplify_cond_expr does not break apart and ||. So it looks like gimplification could only handle the || 0 specially, but that looks like a hack. While for code quality a simple phiopt pass might make sense for debugging it would be better to generate improved initial code for the sequence.
[Bug c++/58455] spurious may be used uninitialized warning with -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58455 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Which means - don't hold your breath ;) This one isn't easy to fix without sacrifying what -Og is supposed to provide.
[Bug c/58454] Potentially wrong(or at least weird/inconsistent) code generation with -O2 -fno-strict-overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58454 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||documentation Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-18 CC||iant at google dot com Ever confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- -fno-strict-overflow should have never been added because it certainly does not disable all use of undefined signed overflow behavior. Which makes it kind-of useless. Ian, the documentation of -fno-strict-overflow suggests that the compiler will not rely on signed overflow not happening. That's not true, so this is definitely a documentation bug.
[Bug tree-optimization/58444] [4.9 regression] Runfail on spec2006/434.zeusmp after r202516.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58444 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- 58453 has more details. *** This bug has been marked as a duplicate of bug 58453 ***
[Bug tree-optimization/58453] Revision 202431 results in miscompare for CPU2006 434.zeusmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58453 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||ysrumyan at gmail dot com --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 58444 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/58453] [4.9 Regression] Revision 202431 results in miscompare for CPU2006 434.zeusmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58453 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-09-18 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|Revision 202431 results in |[4.9 Regression] Revision |miscompare for CPU2006 |202431 results in |434.zeusmp |miscompare for CPU2006 ||434.zeusmp Ever confirmed|0 |1 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug c++/58455] spurious may be used uninitialized warning with -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58455 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 30848 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30848action=edit phiopt pass for -Og
[Bug libstdc++/53324] Crash when mixing _GLIBCXX_DEBUG and non-_GLIBCXX_DEBUG std::deque
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53324 dominik.stras...@onespin-solutions.com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from dominik.stras...@onespin-solutions.com --- I see the point, so no need to change anything.
[Bug c++/58457] [4.8/4.9 Regression] ICE when placement new operator is used with using keyword and custom constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58457 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Note the testcase has to use __SIZE_TYPE__ instead of unsigned int.
[Bug c++/58457] [4.8/4.9 Regression] ICE when placement new operator is used with using keyword and custom constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58457 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r184873.
[Bug sanitizer/58411] no_sanitize_undefined function attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58411 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Sep 18 10:01:40 2013 New Revision: 202682 URL: http://gcc.gnu.org/viewcvs?rev=202682root=gccview=rev Log: 2013-09-18 Marek Polacek pola...@redhat.com PR sanitizer/58411 * doc/extend.texi: Document no_sanitize_undefined attribute. * builtins.c (fold_builtin_0): Don't sanitize function if it has the no_sanitize_undefined attribute. Added: trunk/gcc/testsuite/c-c++-common/ubsan/attrib-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/58411] no_sanitize_undefined function attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58411 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed. I do not plan to add any other attributes at the moment.
[Bug tree-optimization/47059] compiler fails to coalesce loads/stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47059 Denis Vlasenko vda.linux at googlemail dot com changed: What|Removed |Added CC||vda.linux at googlemail dot com --- Comment #3 from Denis Vlasenko vda.linux at googlemail dot com --- I encountered this behavior with 4.8.0: struct pollfd pfd[3]; ... pfd[2].events = POLLOUT; pfd[2].revents = 0; This compiled to: movw$4, 44(%rsp)#, pfd[2].events movw$0, 46(%rsp)#, pfd[2].revents
[Bug libstdc++/58458] New: ISO 14882 typo in docs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58458 Bug ID: 58458 Summary: ISO 14882 typo in docs Product: gcc Version: unknown Status: UNCONFIRMED Severity: trivial Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danielm at ecoscentric dot com Created attachment 30849 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30849action=edit trivial patch to correct typos in ISO 14882 references Just updating our own documentation and I noticed an anomaly in the ISO standard for STL. The correct standard is ISO 14882, but there are lots of references across the web to 14822, including some of the online pages from GNU which are auto-generated from the gcc's documentation. Attached is a trivial patch to correct the typos.
[Bug c++/58458] ISO 14882 typo in docs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58458 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||documentation, patch Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-18 Component|libstdc++ |c++ Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- N.B. gcc.info is a generated file, only implement-cxx.texi needs to be changed.
[Bug c++/58458] ISO 14882 typo in docs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58458 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.7.5 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Thanks, I'm handling this.
[Bug c++/58458] ISO 14882 typo in docs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58458 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Target Milestone|4.7.5 |4.7.4
[Bug ada/58264] incorrect bounds of string when assigned from dereference of function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58264 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Summary|Incorrect 'First when |incorrect bounds of string |assigning function-call.all |when assigned from |(of access String;) to an |dereference of function |indefinite String object|result
[Bug tree-optimization/58459] New: [4.9 regression] Loop invariant is not hoisted out of loop after r202525.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58459 Bug ID: 58459 Summary: [4.9 regression] Loop invariant is not hoisted out of loop after r202525. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ysrumyan at gmail dot com We noticed significant performance regression on important bench from eembc2.0 suite which can be exhibit with attached test-case. Assembly produced compiler prior to r202525 for innermost loop: .L18: movl%esi, %ebp movl8(%eax), %edx sall%cl, %ebp movl12(%eax), %eax testl%ebp, %ebx -- p-key is hoisted out of loop cmove%edx, %eax movl%ecx, %edx but assembly produced compiler after r202525 contains redundant load: .L17: movl%esi, %ebp movl8(%eax), %edx sall%cl, %ebp movl12(%eax), %eax testl%ebp, (%ebx) -- p-key is not hoisted out of loop cmove%edx, %eax movl%ecx, %edx The test-case must be compiled with -Ofast -m32 -march=atom -mtune=atom options.
[Bug ada/58264] incorrect bounds of string when assigned from dereference of function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58264 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Wed Sep 18 10:51:43 2013 New Revision: 202694 URL: http://gcc.gnu.org/viewcvs?rev=202694root=gccview=rev Log: PR ada/58264 * gcc-interface/trans.c (Attribute_to_gnu): Define GNAT_PREFIX local variable and use it throughout. Attr_Length: Note whether the prefix is the dereference of a pointer to unconstrained array and, in this case, capture the result for both Attr_First and Attr_Last. Added: trunk/gcc/testsuite/gnat.dg/array_bounds_test2.adb Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/trans.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/58459] [4.9 regression] Loop invariant is not hoisted out of loop after r202525.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58459 --- Comment #1 from Yuri Rumyantsev ysrumyan at gmail dot com --- Created attachment 30850 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30850action=edit test-case to reproduce Test must be compiled on x86 with options -Ofast -m332 -march=atom -mtune=atom
[Bug ada/58264] incorrect bounds of string when assigned from dereference of function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58264 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Wed Sep 18 10:55:36 2013 New Revision: 202695 URL: http://gcc.gnu.org/viewcvs?rev=202695root=gccview=rev Log: PR ada/58264 * gcc-interface/trans.c (Attribute_to_gnu): Define GNAT_PREFIX local variable and use it throughout. Attr_Length: Note whether the prefix is the dereference of a pointer to unconstrained array and, in this case, capture the result for both Attr_First and Attr_Last. Added: branches/gcc-4_8-branch/gcc/testsuite/gnat.dg/array_bounds_test2.adb - copied unchanged from r202694, trunk/gcc/testsuite/gnat.dg/array_bounds_test2.adb Modified: branches/gcc-4_8-branch/gcc/ada/ChangeLog branches/gcc-4_8-branch/gcc/ada/gcc-interface/trans.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/58459] [4.9 regression] Loop invariant is not hoisted out of loop after r202525.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58459 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-09-18 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- I will have a look.
[Bug ada/58264] incorrect bounds of string when assigned from dereference of function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58264 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.2 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Fixed in 4.8.x and later.
[Bug c++/58458] ISO 14882 typo in docs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58458 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Sep 18 11:06:15 2013 New Revision: 202696 URL: http://gcc.gnu.org/viewcvs?rev=202696root=gccview=rev Log: 2013-09-18 Daniel Morris dani...@ecoscentric.com Paolo Carlini paolo.carl...@oracle.com PR c++/58458 * doc/implement-cxx.texi: Fix references to the C++ standards. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/implement-cxx.texi
[Bug c++/58458] ISO 14882 typo in docs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58458 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Sep 18 11:07:16 2013 New Revision: 202697 URL: http://gcc.gnu.org/viewcvs?rev=202697root=gccview=rev Log: 2013-09-18 Daniel Morris dani...@ecoscentric.com Paolo Carlini paolo.carl...@oracle.com PR c++/58458 * doc/implement-cxx.texi: Fix references to the C++ standards. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/doc/implement-cxx.texi
[Bug c++/58458] ISO 14882 typo in docs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58458 --- Comment #5 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Sep 18 11:08:02 2013 New Revision: 202698 URL: http://gcc.gnu.org/viewcvs?rev=202698root=gccview=rev Log: 2013-09-18 Daniel Morris dani...@ecoscentric.com Paolo Carlini paolo.carl...@oracle.com PR c++/58458 * doc/implement-cxx.texi: Fix references to the C++ standards. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/doc/implement-cxx.texi
[Bug c++/58458] ISO 14882 typo in docs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58458 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.7.4/4.8.2/4.9.0.
[Bug tree-optimization/58459] [4.9 regression] Loop invariant is not hoisted out of loop after r202525.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58459 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- It is actually different behavior of PRE and not LIM doing the invariant motion. So it should reproduce with -O2 already (maybe you can double-check that).
[Bug tree-optimization/58459] [4.9 regression] Loop invariant is not hoisted out of loop after r202525.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58459 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Richard Biener from comment #3) It is actually different behavior of PRE and not LIM doing the invariant motion. So it should reproduce with -O2 already (maybe you can double-check that). Yes, that's right.
[Bug libstdc++/58338] Add noexcept to functions with a narrow contract
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338 --- Comment #4 from Marc Glisse glisse at gcc dot gnu.org --- Author: glisse Date: Wed Sep 18 11:21:51 2013 New Revision: 202699 URL: http://gcc.gnu.org/viewcvs?rev=202699root=gccview=rev Log: 2013-09-18 Marc Glisse marc.gli...@inria.fr PR libstdc++/58338 * include/bits/list.tcc (_List_base::_M_clear, list::erase): Mark as noexcept. * include/bits/stl_list.h (_List_iterator) [_List_iterator, _M_const_cast, operator*, operator-, operator++, operator--, operator==, operator!=]: Likewise. (_List_const_iterator) [_List_const_iterator, _M_const_cast, operator*, operator-, operator++, operator--, operator==, operator!=]: Likewise. (operator==(const _List_iterator, const _List_const_iterator), operator!=(const _List_iterator, const _List_const_iterator)): Likewise. (_List_impl) [_List_impl(const _Node_alloc_type), _List_impl(_Node_alloc_type)]: Likewise. (_List_base) [_M_put_node, _List_base(const _Node_alloc_type), _List_base(_List_base), _M_clear, _M_init]: Likewise. (list) [list(), list(const allocator_type)]: Merge. (list) [list(const allocator_type), front, back, pop_front, pop_back, erase, _M_erase]: Mark as noexcept. * include/debug/list (list) [list(const _Allocator), front, back, pop_front, pop_back, _M_erase, erase]: Likewise. * include/profile/list (list) [list(const _Allocator), front, back, pop_front, pop_back, erase]: Likewise. * testsuite/23_containers/list/requirements/dr438/assign_neg.cc: Adjust line number. * testsuite/23_containers/list/requirements/dr438/constructor_1_neg.cc: Likewise. * testsuite/23_containers/list/requirements/dr438/constructor_2_neg.cc: Likewise. * testsuite/23_containers/list/requirements/dr438/insert_neg.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/list.tcc trunk/libstdc++-v3/include/bits/stl_list.h trunk/libstdc++-v3/include/debug/list trunk/libstdc++-v3/include/profile/list trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/assign_neg.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/constructor_2_neg.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/insert_neg.cc
[Bug tree-optimization/58459] [4.9 regression] Loop invariant is not hoisted out of loop after r202525.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58459
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
Value-numbering it is (-good +bad):
-Value numbering _29 stmt = _29 = _7-key;
+Value numbering _29 stmt = _29 = MEM[(struct S *)a][j_40].key;
Setting value number of _29 to _29
...
Value numbering _18 stmt = _18 = _7-key;
-Setting value number of _18 to _29 (changed)
+Setting value number of _18 to _18 (changed)
and this is because
static bool
forward_propagate_addr_expr (tree name, tree rhs)
{
...
/* If the use is in a deeper loop nest, then we do not want
to propagate non-invariant ADDR_EXPRs into the loop as that
is likely adding expression evaluations into the loop. */
if (bb_loop_depth (gimple_bb (use_stmt)) stmt_loop_depth
!is_gimple_min_invariant (rhs))
{
all = false;
continue;
so we do not replace the address in the loop.
Value-numbering does some limited forward propagation, but it does not
handle varying addresses.
The best fix would be to SCCVN, another fix is to either propagate into to
all uses or into no uses. I lean towards all uses (the above is too strict,
forwarding of say p-a.b.c should not be constrained). Note that dependence
analysis will also be confused when present with a mix of a[i][j] and *p
addressing. Which really boils down to canonicalizing everything to
*p style addressing and lowering the address computation ... (as was my
original MEM_REF plan).
[Bug target/58460] New: Error: shift amount out of range 0 to 4 at operand 3 -- `sub sp,x1,x0,lsl 9'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58460 Bug ID: 58460 Summary: Error: shift amount out of range 0 to 4 at operand 3 -- `sub sp,x1,x0,lsl 9' Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: marcus.shawcroft at arm dot com Target: aarch64-*-* Created attachment 30851 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30851action=edit Preprocessed source $ gcc/xgcc -Bgcc/ -O -c set_mlock.i /tmp/ccHX90M4.s: Assembler messages: /tmp/ccHX90M4.s:22: Error: shift amount out of range 0 to 4 at operand 3 -- `sub sp,x1,x0,lsl 9'
[Bug fortran/55901] [OOP] type is (character(len=*)) misinterpreted as array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-18 CC||janus at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from janus at gcc dot gnu.org --- Here is another code which triggers this error: ftp://ftp.numerical.rl.ac.uk/pub/MRandC/oo.f90 (cf. also https://groups.google.com/forum/?fromgroups#!topic/comp.lang.fortran/aRz3HMpblTs)
[Bug tree-optimization/58453] [4.9 Regression] Revision 202431 results in miscompare for CPU2006 434.zeusmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58453
--- Comment #7 from Richard Biener rguenth at gcc dot gnu.org ---
loop distribution distributes this into
q2 = ( g2a(i+1) * g31a(i+1) * v1(i+1,j,k)
1- g2a(i ) * g31a(i ) * v1(i ,j,k) )
2 * dvl1ai(i)
3 + ( g32a(j+1) * v2(i,j+1,k)
4- g32a(j ) * v2(i,j ,k) )
5 * g2bi(i) * dvl2ai(j)
6 + ( v3(i,j,k+1) - v3(i,j,k) )
7 * g31bi(i) * g32bi(j) * dvl3ai(k)
q2 = q2 * q1
e(i,j,k) = ( 1.0 - q2 ) / ( 1.0 + q2 ) * e(i,j,k)
and a memcpy for
dlo(i,j,k) = d(i,j,k)
and
eod(i,j,k) = e(i,j,k) / d(i,j,k)
(re-computing e(i,j,k) instead of loading it from the stored value - a known
deficiency)
This doesn't look wrong on the first glance (but it's probably slower).
What the revision in question changed was remove some very odd code
from rdg_flag_uses:
- if (gimple_code (stmt) != GIMPLE_PHI)
-{
- if ((use_p = gimple_vuse_op (stmt)) != NULL_USE_OPERAND_P)
- {
- tree use = USE_FROM_PTR (use_p);
-
- if (TREE_CODE (use) == SSA_NAME
- !SSA_NAME_IS_DEFAULT_DEF (use))
- {
- gimple def_stmt = SSA_NAME_DEF_STMT (use);
- int v = rdg_vertex_for_stmt (rdg, def_stmt);
-
- if (v = 0
- !already_processed_vertex_p (processed, v))
- rdg_flag_vertex_and_dependent (rdg, v, partition, loops,
- processed);
- }
- }
-}
that just doesn't make sense, but it likely made sure everything ended up
in a single partition.
Does the benchmark fail if you build with -ftree-loop-distribution
-fno-tree-loop-distribute-patterns? (it should emit a loop instead of the
memcpy call)
[Bug libstdc++/57899] bind/function with data member: infinite recursion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57899
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org ---
Reduced a bit more to only depend on std::bind
#include functional
using std::bind;
using std::placeholders::_1;
struct S { int i; };
struct P { S s; };
struct get_s
{
const S operator()(const P p) const { return p.s; }
} gs;
int gi(const S s) { return s.i; }
bool cmp(int, int) { return true; }
int main()
{
P p{};
auto f1 = bind(gs, _1);
auto f2 = bind(gi, f1);
auto f3 = bind(cmp, f2, 5);
f3(p);
}
[Bug rtl-optimization/58461] [MIPS] Using LRA instead of reload increases code size for mips16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58461 --- Comment #1 from Matthew Fortune matthew.fortune at imgtec dot com --- Created attachment 30853 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30853action=edit Patch to enable LRA for mips16
[Bug rtl-optimization/58461] New: [MIPS] Using LRA instead of reload increases code size for mips16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58461 Bug ID: 58461 Summary: [MIPS] Using LRA instead of reload increases code size for mips16 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: matthew.fortune at imgtec dot com Created attachment 30852 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30852action=edit Test case to trigger LRA reload issue While working on enabling LRA for MIPS (mips16 in particular) I have observed that LRA is not producing as optimal code as classic reload. The underlying cause of this is that the register allocation decisions made in IRA were sub-optimal but classic reload 'fixes' them whereas LRA does not. Regardless of fixing the IRA issues there is probably something to fix in LRA. I have attached a patch that applies to top of tree to enable LRA for mips/mips16 and exposes two options to demonstrate how LRA differs from classic reload. I have also attached a test case (reload_test_mips16.i) which is a function from libjpeg. The two options added by the patch are -mreload and -mfix-regalloc. LRA is default on with the patch applied: * mips-sde-elf-gcc -Os -mips16 -march=m4kec reload_test_mips16.i LRA introduces a number of reloads that involve $24 which is inaccessible to most mips16 instructions leading to an increase in code size. * mips-sde-elf-gcc -Os -mips16 -march=m4kec -mreload ... Classic reload manages to avoid the reloads of $24 as its reloads converge to use the same reload register and eliminate $24 altogether. * mips-sde-elf-gcc -Os -mips16 -march=m4kec -mfix-regalloc ... LRA now outperforms classic reload as the initial register allocation by IRA is better so LRA does not hit the problem I am reporting. The original register allocation from IRA is: Disposition: 26:r245 l0 22:r246 l0 4 28:r249 l0 23:r250 l016 4:r251 l0175:r252 l0 86:r253 l0 9 19:r260 l011 15:r266 l024 12:r275 l0 3 11:r276 l0 2 10:r278 l010 27:r281 l0 47:r282 l0 58:r283 l0 61:r284 l0 7 29:r285 l0 mem 24:r286 l024 25:r287 l0 2 23:r288 l024 22:r289 l024 21:r290 l024 20:r291 l024 18:r292 l024 17:r293 l011 16:r294 l011 14:r295 l011 13:r296 l024 9:r297 l0240:r298 l024 The fixed register allocation from IRA is as follows, note the mems instead of hard registers 8-11,24: Disposition: 26:r245 l0 22:r246 l0 4 28:r249 l0 23:r250 l0 mem 4:r251 l0 mem5:r252 l0166:r253 l017 19:r260 l0 mem 15:r266 l0 mem 12:r275 l0 3 11:r276 l0 2 10:r278 l0 mem 27:r281 l0 47:r282 l0 58:r283 l0 61:r284 l0 7 29:r285 l0 mem 24:r286 l0 mem 25:r287 l0 2 23:r288 l0 mem 22:r289 l0 mem 21:r290 l0 mem 20:r291 l0 mem 18:r292 l0 mem 17:r293 l0 mem 16:r294 l0 mem 14:r295 l0 mem 13:r296 l0 mem 9:r297 l0240:r298 l024 So the issue (I believe) is that reloads from LRA do not converge as well as reloads introduced by classic reload. While this example can (and should) be fixed in the original register allocation it feels as though there is a problem to fix in LRA. == [mfortune@mfortune-linux lra_bugreport]$ /althome/mips/tk/bin/mips-sde-elf-gcc -v Using built-in specs. COLLECT_GCC=/althome/mips/tk/bin/mips-sde-elf-gcc COLLECT_LTO_WRAPPER=/althome/mips/tk/libexec/gcc/mips-sde-elf/4.9.0/lto-wrapper Target: mips-sde-elf Configured with: /althome/mips/git_br/gcc/configure --prefix=/althome/mips/tk --target=mips-sde-elf --with-gnu-as --with-gnu-ld --with-arch=mips32r2 --with-mips-plt --with-synci --with-llsc --with-newlib target_alias=mips-sde-elf --enable-languages=c,c++,lto Thread model: single gcc version 4.9.0 20130918 (experimental) (GCC)
[Bug libstdc++/57899] bind/function with data member: infinite recursion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57899 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- Clang compiles the preprocessed source OK, so the problem may be in the front-end not the library. Commenting out the volatile and const volatile overloads of _Bind::operator() allows the program to compile with G++.
[Bug tree-optimization/58453] [4.9 Regression] Revision 202431 results in miscompare for CPU2006 434.zeusmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58453 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Richard Biener from comment #7) Does the benchmark fail if you build with -ftree-loop-distribution -fno-tree-loop-distribute-patterns? (it should emit a loop instead of the memcpy call) of course not - we fuse the partitions because of the similar memory accesses again.
[Bug tree-optimization/58417] Incorrect optimization in SCEV const-prop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58417 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Sep 18 12:31:45 2013 New Revision: 202700 URL: http://gcc.gnu.org/viewcvs?rev=202700root=gccview=rev Log: 2013-09-18 Richard Biener rguent...@suse.de PR tree-optimization/58417 * tree-chrec.c (chrec_fold_plus_1): Assert that we do not have chrecs with symbols defined in the loop as operands. (chrec_fold_multiply): Likewise. * tree-scalar-evolution.c (interpret_rhs_expr): Instantiate parameters before folding binary operations. (struct instantiate_cache_entry_hasher): Remove. (struct instantiate_cache_type): Use a pointer-map. (instantiate_cache_type::instantiate_cache_type): New function. (instantiate_cache_type::get): Likewise. (instantiate_cache_type::set): Likewise. (instantiate_cache_type::~instantiate_cache_type): Adjust. (get_instantiated_value_entry): Likewise. (global_cache): New global. (instantiate_scev_r, instantiate_scev_poly, instantiate_scev_binary, instantiate_array_ref, instantiate_scev_convert, instantiate_scev_3, instantiate_scev_2, instantiate_scev_1): Do not pass along cache. (instantiate_scev_name): Adjust. (instantiate_scev): Construct global instead of local cache. (resolve_mixers): Likewise. * gcc.dg/torture/pr58417.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr58417.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-chrec.c trunk/gcc/tree-scalar-evolution.c
[Bug tree-optimization/58417] Incorrect optimization in SCEV const-prop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58417 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.9.0 Resolution|--- |FIXED --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk.
[Bug tree-optimization/58453] [4.9 Regression] Revision 202431 results in miscompare for CPU2006 434.zeusmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58453
--- Comment #9 from Richard Biener rguenth at gcc dot gnu.org ---
Ah, so we have
_103 = fieldr.e[_51];
_104 = _102 * _103;
fieldr.e[_51] = _104;
_106 = fieldr.d[_51];
*dlo_107(D)[_51] = _106;
_109 = _104 / _106;
*eod_110(D)[_51] = _109;
and distribute it as
_103 = fieldr.e[_51];
_104 = _102 * _103;
fieldr.e[_51] = _104;
memcpy (dlo, fieldr.d, ...)
_103 = fieldr.e[_51];
_104 = _102 * _103;
_106 = fieldr.d[_51];
_109 = _104 / _106;
*eod_110(D)[_51] = _109;
but that's obviously wrong as we are re-loading a different fieldr.e.
Testcase:
extern void abort (void);
int a[128], b[128], c[128], d[128];
void __attribute__((noinline,noclone))
foo (void)
{
int i;
for (i = 0; i 128; ++i)
{
a[i] = a[i] + 1;
b[i] = d[i];
c[i] = a[i] / d[i];
}
}
int main()
{
int i;
for (i = 0; i 128; ++i)
a[i] = i;
for (i = 0; i 128; ++i)
d[i] = 1;
foo ();
if (c[0] != 1)
abort ();
return 0;
}
[Bug libgomp/58462] New: gomp4: invalid controlling predicate for != ( is ok)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58462
Bug ID: 58462
Summary: gomp4: invalid controlling predicate for != ( is ok)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: vincenzo.innocente at cern dot ch
CC: jakub at gcc dot gnu.org
took me years to learn and teach to use != instead of ….
float a[1024];
float b[1024];
void err() {
#pragma omp simd
for (int i=0;i!=1024;++i) {
a[i]=b[i];
}
}
void ok() {
#pragma omp simd
for (int i=0;i1024;++i) {
a[i]=b[i];
}
}
c++ -std=c++11 -O2 -march=core-avx2 -S twoif.cc -fopenmp
twoif.cc: In function ‘void err()’:
twoif.cc:7:3: error: invalid controlling predicate
for (int i=0;i!=1024;++i) {
^
pb-d-128-141-131-26:vectorize innocent$ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin12.4.0/4.9.0/lto-wrapper
Target: x86_64-apple-darwin12.4.0
Configured with: ./configure --disable-multilib --disable-bootstrap
--enable-lto -disable-libitm --enable-languages=c,c++,fortran,lto
--disable-libsanitizer
Thread model: posix
gcc version 4.9.0 20130918 (experimental) (GCC)
[Bug libgomp/58462] gomp4: invalid controlling predicate for != ( is ok)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58462 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- That is invalid. See OpenMP 4.0, section 2.6. != is valid only in Cilk+ (i.e. #pragma simd).
[Bug sanitizer/58443] ubsan doesn't properly honor fsanitize= flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58443 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Sep 18 13:31:34 2013 New Revision: 202701 URL: http://gcc.gnu.org/viewcvs?rev=202701root=gccview=rev Log: 2013-09-18 Marek Polacek pola...@redhat.com PR sanitize/58443 cp/ * typeck.c (cp_build_binary_op): Properly honor -fsanitize options. Remove unnecessary check. c/ * c-typeck.c (build_binary_op): Properly honor -fsanitize options. Remove unnecessary check. testsuite/ * g++.dg/ubsan/div-by-zero-1.C: Use the integer-divide-by-zero option instead of the shift option. * c-c++-common/ubsan/pr58443-1.c: New test. * c-c++-common/ubsan/pr58443-3.c: New test. * c-c++-common/ubsan/pr58443-2.c: New test. Added: trunk/gcc/testsuite/c-c++-common/ubsan/pr58443-1.c trunk/gcc/testsuite/c-c++-common/ubsan/pr58443-2.c trunk/gcc/testsuite/c-c++-common/ubsan/pr58443-3.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ubsan/div-by-zero-1.C
[Bug sanitizer/58443] ubsan doesn't properly honor fsanitize= flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58443 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/58459] [4.9 regression] Loop invariant is not hoisted out of loop after r202525.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58459 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- LIM does not move the invariant because it does not see that _7 in _7-key is always dereferenced in the innermost loop. This is because LIM computes this property as a basic-block property, not as a reference property (if all references are in the same form we could track that on a per reference basis). OTOH this again boils down to the fact that we do not have a code hoisting pass. PRE figures this out one level but fails to catch the third occurance for some reason (just testing with -fno-tree-forwprop). So, without major restructuring LIM won't do this and it certainly wouldn't do it with partial rewritten _7 as we have it now with the interesting loop still using the dereference form.
[Bug c++/58457] [4.8/4.9 Regression] ICE when placement new operator is used with using keyword and custom constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58457 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Severity|major |normal --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Very likely the patch which will fix this will also fix PR57444.
[Bug c++/57444] [4.8/4.9 Regression] ICE in instantiate_type for invalid use of member with using-declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57444 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Summary|ICE in instantiate_type for |[4.8/4.9 Regression] ICE in |invalid use of member with |instantiate_type for |using-declaration |invalid use of member with ||using-declaration --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Very likely PR58457 is a Dup.
[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 #37 from Martin Jambor jamborm at gcc dot gnu.org --- Created attachment 30854 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30854action=edit Testcase for both the assignment and read issues For the record, this is a slightly extended original x86_64 testcase which also exposes the bug in the read expansion. So far I have not been able to come up with a grave problem with passing EXPAND_MEMORY to tem expansion (and looking at history of this code, the passed modifier has changed quite a lot and for not immediately apparent reasons). In order to use movmisalign_optab instructions when we can, we should probably only do it if tem is a structure with a zero sized array.
[Bug tree-optimization/58464] New: [4.9 Regression] Crashes with SIGSEGV (infinite recursion in phi_translate)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58464 Bug ID: 58464 Summary: [4.9 Regression] Crashes with SIGSEGV (infinite recursion in phi_translate) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: d.g.gorbachev at gmail dot com Host: i686-pc-linux-gnu Target: i686-pc-linux-gnu Build: i686-pc-linux-gnu Created attachment 30856 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30856action=edit Backtrace GCC 4.9.0 20130915 (experimental). This happens when building GCC itself (libcpp/lex.c) with -O3.
[Bug tree-optimization/58464] [4.9 Regression] Crashes with SIGSEGV (infinite recursion in phi_translate)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58464 --- Comment #1 from Dmitry Gorbachev d.g.gorbachev at gmail dot com --- Created attachment 30857 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30857action=edit Testcase (somewhat minimized). Compile with -O3. GCC 20130331 (rev. 197291) - works, 20130526 (rev. 199345) - fails.
[Bug tree-optimization/58464] [4.9 Regression] Crashes with SIGSEGV (infinite recursion in phi_translate)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58464 --- Comment #2 from Dmitry Gorbachev d.g.gorbachev at gmail dot com --- Created attachment 30858 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30858action=edit Original preprocessed file
[Bug sanitizer/58465] New: TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 Bug ID: 58465 Summary: TSan deadlock in a single-threaded program Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: oleg at smolsky dot net CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Created attachment 30859 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30859action=edit the full stack Just got a deadlock in a single-theaded program. It appears to be stuck in __tsan::user_realloc that is called from strerror_r, which is intercepted after the initial call to operator new. The full stack is attached.
[Bug c++/58457] [4.8/4.9 Regression] ICE when placement new operator is used with using keyword and custom constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58457 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Seems easy.
[Bug middle-end/58463] New: ICE with -fdump-tree-all-all in vector indexed access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58463 Bug ID: 58463 Summary: ICE with -fdump-tree-all-all in vector indexed access Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pa...@matos-sorge.com Created attachment 30855 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30855action=edit Code example to reproduce ICE GCC tries to access varmap through get_varinfo in tree-ssa-structalias.c, but it fails with an ICE. I have attached a reduced code example to reproduce the problem. The command line and output with 4.8.1 is: $ ~/work/tmp/gcc-4.8.1/gcc/cc1 -fpreprocessed -fdump-tree-all-all -O2 core_list_join.i core_list_join.i:4:1: warning: no semicolon at end of struct or union [enabled by default] } ^ fn1 Analyzing compilation unit Performing interprocedural optimizations *free_lang_data visibility early_local_cleanups core_list_join.i: In function 'fn1': core_list_join.i:9:1: internal compiler error: in operator[], at vec.h:815 } ^ 0xbfd572 vecvariable_info*, va_heap, vl_embed::operator[](unsigned int) /home/pmatos/work/gcc-releases/gcc-4.8.1/gcc/vec.h:815 0xbfcea0 vecvariable_info*, va_heap, vl_ptr::operator[](unsigned int) /home/pmatos/work/gcc-releases/gcc-4.8.1/gcc/vec.h:1244 0xbeb5ba get_varinfo /home/pmatos/work/gcc-releases/gcc-4.8.1/gcc/tree-ssa-structalias.c:319 0xbefa59 perform_var_substitution /home/pmatos/work/gcc-releases/gcc-4.8.1/gcc/tree-ssa-structalias.c:2244 0xbfb279 solve_constraints /home/pmatos/work/gcc-releases/gcc-4.8.1/gcc/tree-ssa-structalias.c:6569 0xbfb679 compute_points_to_sets /home/pmatos/work/gcc-releases/gcc-4.8.1/gcc/tree-ssa-structalias.c:6665 0xbfbdca compute_may_aliases() /home/pmatos/work/gcc-releases/gcc-4.8.1/gcc/tree-ssa-structalias.c:6814 0x967b9e execute_function_todo /home/pmatos/work/gcc-releases/gcc-4.8.1/gcc/passes.c:1941 0x966f88 do_per_function /home/pmatos/work/gcc-releases/gcc-4.8.1/gcc/passes.c:1701 0x967d64 execute_todo /home/pmatos/work/gcc-releases/gcc-4.8.1/gcc/passes.c:1996 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 libgomp/58462] gomp4: invalid controlling predicate for != ( is ok)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58462 --- Comment #2 from vincenzo Innocente vincenzo.innocente at cern dot ch --- Thanks Jakub. Downloaded the standard. waiting for more examples of usage It is a pity that it does not support c++ range loop Let me highjack this bug to congratulate you and your collaborators for the great and fast work to implement openmp 4.0 simd syntax. I already found out that at the moment is the only way to convince gcc that a pointer is restrict! I hope it will go in main-stream 4.9 soon. Vincenzo
[Bug sanitizer/58465] TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #1 from Oleg Smolsky oleg at smolsky dot net --- I wonder if I just need to merge this: http://llvm.org/viewvc/llvm-project?view=revisionrevision=187978
[Bug c++/58466] New: [4.8/4.9 Regression] ICE in cxx_eval_constant_expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58466
Bug ID: 58466
Summary: [4.8/4.9 Regression] ICE in
cxx_eval_constant_expression
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: jason at gcc dot gnu.org
template char first, char... data
struct CTArray
{
static constexpr unsigned long count = sizeof... (data);
};
struct Str
{
template typename T
Str(T...) {}
};
template typename T
struct ToStr;
template char... letters
struct ToStr CTArray letters...
{
static Str
get ()
{
return { letters... };
}
};
using Foo = CTArray 'F', 'o', 'o';
Str str(ToStr Foo::get ());
ICEs with -std=c++11. Before r198750 it just errored out on the testcase (is
it invalid, right?), in r198800 ICEs, haven't bisected more.
[Bug c++/58466] [4.8/4.9 Regression] ICE in cxx_eval_constant_expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58466 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.2
[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 #38 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Richard, I've split up the patch as requested: Part 1 was posted here, but not yet approved: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01292.html Just for the record, part 1 has been bootstrapped and regression tested. For part 2: For simplicity I'd propose to use simply pass EXPAND_MEMORY here. These misaligned uses are quite rare hopefully. I will replace my test cases 3+4 with Martin's test case, maybe without the get_i() because otherwise the test will die from the ICE before the check runs. Will do this after Part 1 if you agree...
[Bug c/58467] New: Documentation of the used variable attribute needs additional information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58467 Bug ID: 58467 Summary: Documentation of the used variable attribute needs additional information Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: psmith at gnu dot org The used variable attribute in the GCC documentation (gcc/doc/extend.texi, section Variable Attributes) says that it can be attached to a variable. However, this attribute cannot be applied to auto variables, only global or static variables. If you try to attach __attribute__((used)) to an auto variable you'll get a confusing error saying that you can't do that, with no reason why, and the documentation doesn't provide any guidance.
[Bug tree-optimization/55860] Turn segmented iteration into nested loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55860 --- Comment #3 from Jeffrey A. Law law at redhat dot com --- The other issue here is the loop header which looks like: bb4: # iii_16 = PHI iii_12(8), 0(3) # jkl_17 = PHI jkl_4(8), 0(3) L1: if (m_8(D) iii_16) goto bb 5; else goto bb 6; [... ] bb7 # iii_12 = PHI 0(6), iii_10(5) # jkl_4 = PHI jkl_11(6), jkl_17(5) L2: if (jkl_4 n_7(D)) goto bb 8; else goto bb 9; The path 4-5-7-8-4 is the path we want to optimize. The problem is we can't record anything useful about the value of jkl_17 in bb4 and propagate that to bb4's children. We don't have a useful path to follow backwards because of the multiple predecessors of bb4. What would be more promising would be Bodik's approach of walking backwards from the test expression to discover the redundancy. That would require reimplementing the jump threading code as a separate pass from DOM, which would probably be a good thing. In this particular case it'd work something like this At the end of bb7 we have this expression and we want to see if it's already been computed and available on a useful path. jkl_4 n_7 We look up jlk_4's definition statement (PHI in bb7) and substitute values from both paths. The path from 6-7 gets followed and nothing useful will be found. The path from block 5-7 is the interesting one and results in jkl_17 n_7 We then look up jlk_17's definition statement (PHI in bb4) and substitute values from path paths. The path from bb8 is obviously not useful, but the path from bb3 is useful resulting in 0 n_7 We then would find 0 n_7 with the value as true when bb4 is reached from bb3. This tells us that the path 3-4-5-7 has a redundant condition and if we can isolate the path it can be optimized. But this is definitely future work. I'm looking at some limited code to walk up the control dependence tree to pick up more expressions for the tables. At first glance it seems to factor out nicely. It won't help this case, but may help others.
[Bug c++/52869] [DR 1207] this not being allowed in noexcept clauses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-18 Summary|this not being allowed in |[DR 1207] this not being |noexcept clauses|allowed in noexcept clauses Ever confirmed|0 |1
[Bug rtl-optimization/58438] [4.9 Regression] ICE: in check_rtl, at lra.c:2036
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58438 --- Comment #5 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Wed Sep 18 18:24:49 2013 New Revision: 202714 URL: http://gcc.gnu.org/viewcvs?rev=202714root=gccview=rev Log: 2013-09-18 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/58438 * lra.c (lra): Clear lra_optional_reload_pseudos in upper loop. * lra-constraints.c (undo_optional_reloads): Keep optional reloads from previous subpasses. 2013-09-18 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/58438 * g++.dg/pr58438.C: New test. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/lra.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/58338] Add noexcept to functions with a narrow contract
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338 --- Comment #5 from Marc Glisse glisse at gcc dot gnu.org --- Author: glisse Date: Wed Sep 18 18:31:01 2013 New Revision: 202716 URL: http://gcc.gnu.org/viewcvs?rev=202716root=gccview=rev Log: 2013-09-18 Marc Glisse marc.gli...@inria.fr PR libstdc++/58338 * include/bits/stl_iterator.h (__normal_iterator) [__normal_iterator, _M_const_cast, operator*, operator-, operator++, operator--, operator[], operator+=, operator+, operator-=, operator-, base]: Mark as noexcept. (operator==(const __normal_iterator, const __normal_iterator), operator!=(const __normal_iterator, const __normal_iterator), operator(const __normal_iterator, const __normal_iterator), operator(const __normal_iterator, const __normal_iterator), operator=(const __normal_iterator, const __normal_iterator), operator=(const __normal_iterator, const __normal_iterator), operator-(const __normal_iterator, const __normal_iterator), operator+(difference_type, const __normal_iterator)): Likewise. * include/bits/stl_list.h (list) [splice, _M_check_equal_allocators]: Likewise. (list::_M_check_equal_allocators): Abort instead of throwing. * include/debug/array (array) [operator[], front, back]: Mark as noexcept. * include/profile/array (array) [operator[], front, back]: Likewise. * include/std/array (array) [operator[], front, back]: Likewise. * include/debug/list (list::splice): Likewise. * include/profile/list (list::splice): Likewise. * testsuite/23_containers/list/operations/5.cc: Remove file. * testsuite/23_containers/list/operations/5.h: Likewise. Removed: trunk/libstdc++-v3/testsuite/23_containers/list/operations/5.cc trunk/libstdc++-v3/testsuite/23_containers/list/operations/5.h Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_iterator.h trunk/libstdc++-v3/include/bits/stl_list.h trunk/libstdc++-v3/include/debug/array trunk/libstdc++-v3/include/debug/list trunk/libstdc++-v3/include/profile/array trunk/libstdc++-v3/include/profile/list trunk/libstdc++-v3/include/std/array
[Bug target/58394] unrecognizable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58394 xperience at interia dot pl changed: What|Removed |Added CC||xperience at interia dot pl --- Comment #2 from xperience at interia dot pl --- Created attachment 30860 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30860action=edit preprocessed source
[Bug c++/58457] [4.8/4.9 Regression] ICE when placement new operator is used with using keyword and custom constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58457 --- Comment #8 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Sep 18 18:13:15 2013 New Revision: 202712 URL: http://gcc.gnu.org/viewcvs?rev=202712root=gccview=rev Log: /cp 2013-09-18 Paolo Carlini paolo.carl...@oracle.com PR c++/58457 * class.c (instantiate_type): Loosen a bit the gcc_assert. /testsuite 2013-09-18 Paolo Carlini paolo.carl...@oracle.com PR c++/58457 * g++.dg/parse/using4.C: New. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/parse/using4.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/class.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug c++/58457] [4.8/4.9 Regression] ICE when placement new operator is used with using keyword and custom constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58457 --- Comment #7 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Sep 18 18:11:46 2013 New Revision: 202711 URL: http://gcc.gnu.org/viewcvs?rev=202711root=gccview=rev Log: /cp 2013-09-18 Paolo Carlini paolo.carl...@oracle.com PR c++/58457 * class.c (instantiate_type): Loosen a bit the gcc_assert. /testsuite 2013-09-18 Paolo Carlini paolo.carl...@oracle.com PR c++/58457 * g++.dg/parse/using4.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/using4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/43366] [OOP][F08] Intrinsic assign to polymorphic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366 --- Comment #17 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Wed Sep 18 18:14:57 2013 New Revision: 202713 URL: http://gcc.gnu.org/viewcvs?rev=202713root=gccview=rev Log: 2013-09-15 Tobias Burnus bur...@net-b.de PR fortran/43366 * primary.c (gfc_variable_attr): Also handle codimension. * resolve.c (resolve_ordinary_assign): Add invalid-diagnostic * for polymorphic assignment. 2013-09-15 Tobias Burnus bur...@net-b.de PR fortran/43366 * gfortran.dg/class_39.f03: Update dg-error. * gfortran.dg/class_5.f03: Ditto. * gfortran.dg/class_53.f90: Ditto. * gfortran.dg/realloc_on_assign_20.f90: New. * gfortran.dg/realloc_on_assign_21.f90: New. * gfortran.dg/realloc_on_assign_22.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_20.f90 trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_21.f90 trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_22.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/class_39.f03 trunk/gcc/testsuite/gfortran.dg/class_5.f03 trunk/gcc/testsuite/gfortran.dg/class_53.f90
[Bug c++/58457] [4.8/4.9 Regression] ICE when placement new operator is used with using keyword and custom constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58457 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot com --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 57444 has been marked as a duplicate of this bug. ***
[Bug c++/58457] [4.8/4.9 Regression] ICE when placement new operator is used with using keyword and custom constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58457 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.8.2 and 4.9.0.
[Bug c++/57444] [4.8/4.9 Regression] ICE in instantiate_type for invalid use of member with using-declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57444 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Dup. *** This bug has been marked as a duplicate of bug 58457 ***
[Bug target/58452] GCC 4.8 and trunk do not compile simple powerpc-linuxpaired -O3 case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58452 --- Comment #3 from Michael Meissner meissner at gcc dot gnu.org --- Author: meissner Date: Wed Sep 18 18:54:06 2013 New Revision: 202719 URL: http://gcc.gnu.org/viewcvs?rev=202719root=gccview=rev Log: 2013-09-18 Michael Meissner meiss...@linux.vnet.ibm.com PR target/58452 * config/rs6000/paired.md (movmisalignv2sf): Fix to allow memory operands. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/paired.md
[Bug preprocessor/58468] New: Macro gets undefined when source directory is same as macro name.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58468 Bug ID: 58468 Summary: Macro gets undefined when source directory is same as macro name. Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: ateuscher at datacomm dot ch Content of file src/test.c: #ifndef SRC # error SRC not defined! #endif When precompiled from base directory: cpp -P -DSRC src/test.c src/test.c:3:3: error: #error SRC not defined! # error SRC not defined! ^ There seems to be conflict problem with the macro SRC and the directory src. Tested with MinGW under Windows 7. Older versions doesn't have that problem.
[Bug tree-optimization/58451] ICE with segfault at -O3 on x86_64-linux-gnu (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58451 --- Comment #2 from Zhendong Su su at cs dot ucdavis.edu --- (In reply to Marek Polacek from comment #1) Should be already fixed by richi's r202644. Verified (for 202680). Thanks.
[Bug fortran/58469] New: Defined assignment: ICE, possible wrong value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58469
Bug ID: 58469
Summary: Defined assignment: ICE, possible wrong value
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
The following code segfaults, unless the patch below is applied. With the patch
applied, valgrind shows that the gfc_code allocated at
if ((*code)-expr1-symtree-n.sym-name[2] != '@')
{
this_code = build_assignment (EXEC_ASSIGN,
leaks memory. (I have no idea why.)
Additionally, I wonder what the code should print - 20 or 42. With the current
code (plus patch) and with crayftn it prints 20. (ifort and pgf95 segfault.) I
have the vague feeling that 42 is correct, but I am far from being positive.
module m0
implicit none
type :: component
integer :: i = 42
contains
procedure :: assign0
generic :: assignment(=) = assign0
end type
type, extends(component) :: comp2
real :: aa
end type comp2
type parent
type(comp2) :: foo
end type
contains
elemental subroutine assign0(lhs,rhs)
class(component), intent(INout) :: lhs
class(component), intent(in) :: rhs
lhs%i = 20
end subroutine
end module
program main
use m0
implicit none
type(parent), allocatable :: left
type(parent) :: right
print *, right%foo
left = right
print *, left%foo
! if (left%foo%i /= 42) call abort()
end
Patch which does three things:
a) Correct indenting
b) Remove pointless code. this_code is either freed or (via
add_code_to_chain) nullified.
c) Fix for the segfault.
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -9623,3 +9623,3 @@ generate_component_assignments (gfc_code **code,
}
- }
+}
else if (this_code-op == EXEC_ASSIGN !this_code-next)
@@ -9645,9 +9645,2 @@ generate_component_assignments (gfc_code **code,
- /* This is probably not necessary. */
- if (this_code)
-{
- gfc_free_statements (this_code);
- this_code = NULL;
-}
-
/* Put the temporary assignments at the top of the generated code. */
@@ -9669,3 +9662,4 @@ generate_component_assignments (gfc_code **code,
**code = *head;
- free (head);
+ if (head != tail)
+free (head);
*code = tail;
[Bug fortran/58469] [4.8/4.9 Regression] Defined assignment: ICE, possibly wrong value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58469 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Known to work||4.7.3 Target Milestone|--- |4.8.2 Summary|Defined assignment: ICE,|[4.8/4.9 Regression] |possible wrong value|Defined assignment: ICE, ||possibly wrong value Known to fail||4.8.1, 4.9.0 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- As defined assignment (for components with intrinsic assignment) is new since 4.8, previously working code fails. Hence, I marked it as 4.8/4.9 regression.
[Bug fortran/58469] [4.8/4.9 Regression] Defined assignment: ICE, possibly wrong value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58469 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #0) Additionally, I wonder what the code should print - 20 or 42. With the current code (plus patch) and with crayftn it prints 20. (ifort and pgf95 segfault.) I have the vague feeling that 42 is correct Correction: I meant that gfortran(+comment 0 patch) and crayftn print 42 - while I (wrongly?) expect that the defined assignment gets invoked, leading to the value 20.
[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57697 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Wed Sep 18 22:19:03 2013 New Revision: 202725 URL: http://gcc.gnu.org/viewcvs?rev=202725root=gccview=rev Log: 2013-09-18 Tobias Burnus bur...@net-b.de PR fortran/57697 * gfortran.dg/defined_assignment_11.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/defined_assignment_11.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/58470] New: ICE on invalid with FINAL function and type extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58470 Bug ID: 58470 Summary: ICE on invalid with FINAL function and type extension Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gmail dot com The following causes an ICE with gfortran 4.9.0 (r202667): module cf type :: cfml contains final :: mld end type cfml type, extends(cfml) :: cfmde end type cfmde contains subroutine mld(s) class(cfml), intent(inout) :: s end subroutine mld end module cf $ gfortran -v Using built-in specs. COLLECT_GCC=/opt/gcc-trunk/bin/gfortran COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/opt/gcc-trunk --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.9.0 20130917 (experimental) (GCC) $ gfortran -c bug.F90 -o bug.o bug.F90: In function ‘__final_cf_Cfml’: bug.F90:12:0: internal compiler error: Segmentation fault end module cf ^ 0x99112f crash_signal ../../gcc-trunk/gcc/toplev.c:335 0x5f8e0c gfc_conv_derived_to_class(gfc_se*, gfc_expr*, gfc_typespec, tree_node*, bool, bool) ../../gcc-trunk/gcc/fortran/trans-expr.c:424 0x5f1140 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vectree_node*, va_gc, vl_embed*) ../../gcc-trunk/gcc/fortran/trans-expr.c:4028 0x61cd04 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) ../../gcc-trunk/gcc/fortran/trans-stmt.c:406 0x5bf010 trans_code ../../gcc-trunk/gcc/fortran/trans.c:1700 0x621a40 gfc_trans_integer_select ../../gcc-trunk/gcc/fortran/trans-stmt.c:1990 0x621a40 gfc_trans_select(gfc_code*) ../../gcc-trunk/gcc/fortran/trans-stmt.c:2484 0x5bed77 trans_code ../../gcc-trunk/gcc/fortran/trans.c:1743 0x5e7dae gfc_generate_function_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans-decl.c:5528 0x5c0781 gfc_generate_module_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans.c:1955 0x57eee7 translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.c:4496 0x57eee7 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:4706 0x5baab5 gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:189 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. The code is invalid because the finalization subroutine defines its argument as CLASS rather than TYPE. Removing the cfmde type (or removing the , extends(cfml)) results in the correct error message: $ gfortran -c bug.F90 -o bug.o bug.F90:9.18: subroutine mld(s) 1 Error: Argument of FINAL procedure at (1) must be of type 'cfml'
[Bug fortran/58471] New: ICE on invalid with missing type constructor and -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58471 Bug ID: 58471 Summary: ICE on invalid with missing type constructor and -Wall Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gmail dot com The following causes an ICE with gfortran 4.9.0 (r202667) when compiled with -Wall: module cf type :: cfmde end type cfmde interface cfmde module procedure mdedc end interface cfmde contains subroutine cfi() implicit none type(cfmde), pointer :: cfd cfd=cfmde() return end subroutine cfi end module cf $ gfortran -v Using built-in specs. COLLECT_GCC=/opt/gcc-trunk/bin/gfortran COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/opt/gcc-trunk --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.9.0 20130917 (experimental) (GCC) $ gfortran -c bug1.F90 -o bug1.o -Wall bug1.F90:5.22: module procedure mdedc 1 Error: Procedure 'mdedc' in generic interface 'cfmde' at (1) is neither function nor subroutine f951: internal compiler error: Segmentation fault 0x99112f crash_signal ../../gcc-trunk/gcc/toplev.c:335 0x582892 gfc_expr_attr(gfc_expr*) ../../gcc-trunk/gcc/fortran/primary.c:2259 0x53a40c gfc_check_assign(gfc_expr*, gfc_expr*, int) ../../gcc-trunk/gcc/fortran/expr.c:3160 0x58f872 resolve_ordinary_assign ../../gcc-trunk/gcc/fortran/resolve.c:9200 0x58f872 resolve_code ../../gcc-trunk/gcc/fortran/resolve.c:9810 0x591b0e resolve_codes ../../gcc-trunk/gcc/fortran/resolve.c:14507 0x591a17 resolve_codes ../../gcc-trunk/gcc/fortran/resolve.c:14493 0x591bf2 gfc_resolve ../../gcc-trunk/gcc/fortran/resolve.c:14535 0x57efdf gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:4645 0x5baab5 gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:189 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. without -Wall the correct error message is generated: $ gfortran -c bug1.F90 -o bug1.o bug1.F90:5.22: module procedure mdedc 1 Error: Procedure 'mdedc' in generic interface 'cfmde' at (1) is neither function nor subroutine bug1.F90:11.8: cfd=cfmde() 1 Error: Can't convert REAL(4) to TYPE(cfmde) at (1) Adding a suitable mdedc procedure results in successful compilation.
[Bug rtl-optimization/58438] [4.9 Regression] ICE: in check_rtl, at lra.c:2036
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58438 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Markus Trippelsdorf markus at trippelsdorf dot de --- Fixed. Thanks.
