[Bug tree-optimization/38984] [4.2/4.3 Regression] NULL pointers always considered distinct by PTA, even with -fno-delete-null-pointer-checks
--- Comment #16 from bonzini at gnu dot org 2009-02-02 08:26 --- Subject: Re: [4.2/4.3 Regression] NULL pointers always considered distinct by PTA, even with -fno-delete-null-pointer-checks rguenth at gcc dot gnu dot org wrote: > --- Comment #15 from rguenth at gcc dot gnu dot org 2009-02-01 22:02 > --- > Err, that last comment probably didn't make much sense. I wanted to say I see > > # VUSE <.MEM_6(D)> > a = *p; > # .MEM_7 = VDEF <.MEM_6(D)> > *0B = 5; > return *p == a; > > so the pattern for two = *p does not match. I'll check out alias-improvements-branch and fix it. I'll also add a testcase for PR38985 there. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38984
[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.
--- Comment #19 from pluto at agmk dot net 2009-02-02 08:55 ---
(In reply to comment #16)
> Subject: Bug 38503
>
> Author: rguenth
> Date: Tue Jan 27 10:42:59 2009
> New Revision: 143700
this patch doesn't fix testcase that i found yesterday.
i found another testcase for gcc-4.4.0-20090130 not covered
by patch commited on january, the 27.
$ cat bug2.cpp
#include
#include
struct X
{
std::string s;
bool f;
};
extern boost::optional< X > x;
void foo( std::string const& );
bool bar()
{
if ( !x )
return false;
if ( x->f )
foo( x->s );
return false;
}
$ make
rm -f *.ii *.o *.s
/local/devel/toolchain44/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ -c -Wall -O2
-g0 -fPIC --save-temps -isystem ./sys-headers bug2.cpp
bug2.cpp: In function 'bool bar()':
bug2.cpp:14: warning: dereferencing pointer '' does break
strict-aliasing rules
bug2.cpp:14: note: initialized from here
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
[Bug debug/39073] New: [4.4 Regression] unable to debug CP2K (no local symbols)
I find that I can not print local variables (none that is) if I use 4.4 for compiling CP2K, while it goes fine with 4.3. Reproducing requires these steps: wget http://www.pci.uzh.ch/vandevondele/tmp/CP2K_2008_12_03.tgz tar -xzvf CP2K_2008_12_03.tgz cd CP2K_2008_12_03/ # # change FCFLAGS to read # FCFLAGS = -O0 -g # be sure lapack/blas are available for linking # vi Makefile make gdb ./cp2k.sopt (gdb) run test.inp ^C Program received signal SIGINT, Interrupt. 0x006bb92a in __distribution_optimize_MOD_update_cost_cpu_diff () at distribution_optimize.F:361 361IF (local_cols_new(i).NE.local_cols_old(i)) THEN (gdb) print i No symbol "i" in current context. (gdb) info locals No locals. wherever one breaks, local symbols can not be found. The same goes fine using 4.3.1 -- Summary: [4.4 Regression] unable to debug CP2K (no local symbols) Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39073
[Bug debug/39073] [4.4 Regression] unable to debug CP2K (no local symbols)
--- Comment #1 from jv244 at cam dot ac dot uk 2009-02-02 08:59 --- > gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /data03/vondele/gcc_trunk/gcc/configure --prefix=/data03/vondele/gcc_trunk/build --enable-languages=c,fortran --disable-multilib --with-ppl=/data03/vondele/gcc_trunk/build/ --with-cloog=/data03/vondele/gcc_trunk/build/ Thread model: posix gcc version 4.4.0 20090114 (experimental) [trunk revision 143362] (GCC) -- jv244 at cam dot ac dot uk changed: What|Removed |Added GCC target triplet||x86_64-unknown-linux-gnu Known to fail||4.4.0 Known to work||4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39073
[Bug debug/39073] [4.4 Regression] unable to debug CP2K (no local symbols)
-- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39073
[Bug libstdc++/35942] Self Reference In Dynamic Linked Library builds for building Cross-Compiler
--- Comment #10 from jzb2 at aexorsyst dot com 2009-02-02 09:31 --- I can confirm this is a real problem. I have hit this exact same bug on gcc-4.2.2. However, one difference in my setup is that I _do_ have libstdc++.so available as part of my cross toolchain, with the result the libtool happily generates code that ends up linking the cross-toolchain's libstdc++.so into the cross-native (not Canandian) libstdc++.so just being built, and adds an ugly RPATH to it as well. I've sent the following to gcc-help mailing list, before I found this current bug on bugzilla: I'm doing a cross-native of build gcc-4.2.2 on --build=i686-pc-linux-gnu using cross-compiler/toolchain built with --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-uclibc and currently building gcc-4.2.2 for --build=i686-pc-linux-gnu --host=i686-pc-linux-uclibc --target=i686-pc-linux-uclibc with ... --enable-shared --enable-languages=c,c++ --with-sysroot=/data/devo/builds/i686-pc-linux-gnu-cross-i686-pc-linux-uclibc/crucis-1/cross-rootfs ... The generated libtool in gcc_native-build/i686-pc-linux-uclibc/libstdc++v3/libtool ends up with ... postdeps="-lstdc++ -lm -lgcc_s -lc -lgcc_s" ... which seems in error, as it creates a circular dependency of SONAME libstdc++.so on NEEDED libstdc++.so and makes for an ugly RPATH: Dynamic section at offset 0xe789c contains 28 entries: TagType Name/Value 0x0001 (NEEDED) Shared library: [libm.so.0] 0x0001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0001 (NEEDED) Shared library: [libc.so.0] 0x0001 (NEEDED) Shared library: [libintl.so.0] 0x0001 (NEEDED) Shared library: [libstdc++.so.6] 0x000e (SONAME) Library soname: [libstdc++.so.6] 0x000f (RPATH) Library rpath: [/data/devo/builds/i686-pc-linux-gnu-cross-i686-pc-linux-uclibc/crucis-1/cross-tools/i686-pc-linux-uclibc/lib] Note that if instead of libstdc++.so I only have libstdc++.a in the toolchain, then I get a bunch of duplicate symbols and the link fails (I suppose that's expected at this point). I'm pretty sure this used to work in earlier versions, but its broken in 4.2.2 and has nothing to do with (in 4.2.2) the --build option, as I do specify it. Here's my full cross-native configure command: cd $(OBJDIR)/gcc_native-build ; \ CXXFLAGS=-fpermissive \ CC=$(ARCH)-$(CUSTOMER)-$(PLATFORM)-gcc \ $(PKGDIR)/configure --prefix=/usr \ --libexecdir=/usr/lib \ --enable-shared \ --enable-threads=posix \ --enable-__cxa_atexit \ --enable-clocale=uclibc \ --with-cpu=pentium4 \ --with-local-prefix=$(TGTROOT)/usr \ --with-sysroot=$(TGTROOT) \ --enable-languages=c,c++ \ --disable-libstdcxx-pch \ --build=$(BUILDHOST) \ --host=$(ARCH)-$(CUSTOMER)-$(PLATFORM) \ --target=$(ARCH)-$(CUSTOMER)-$(PLATFORM) And here's how the cross-compiler was built (prior to building gcc_native): cd $(OBJDIR)/gcc_p2-build ; \ CXXFLAGS=-fpermissive $(PKGDIR)/configure \ --prefix=$(PREFIX) \ --disable-werror \ --disable-multilib \ --enable-clocale=uclibc \ --enable-shared \ --libexecdir=$(PREFIX)/lib \ --with-headers=$(TGTROOT)/usr/include \ --with-sysroot=$(TGTROOT) \ --enable-threads=posix \ --enable-__cxa_atexit \ --with-cpu=pentium4 \ --enable-languages=c,c++ \ --target=$(ARCH)-$(CUSTOMER)-$(PLATFORM) Note that -fpermissive flag is to overcome uClibc's gettext issues, and was suggested by the gcc itself as it tried to build. It works with, not without, but probably has nothing to do this generated libtool issue. The uclibc locale was supplied via patches. I am a programmer, but not a autoconf/automake/libtool expert, so if someone could just please point out where that postdeps gets instantiated, and how it has come to include -lstdc++, I'd be happy to run some tests. Is it possible that this may have to do with the version(s) of the autoconf/automake tools? Is that where perhaps the postdeps gets its value? I'm just guessing, as I've grepped the whole gcc source tree, and couldn't find anything useful. That would also explain the unexpected difference in behavior. I'm running autoconf-2.61 and automake-1.10.1 and libtool-1.5.24
[Bug debug/39073] [4.4 Regression] unable to debug CP2K (no local symbols)
--- Comment #9 from jan dot kratochvil at redhat dot com 2009-02-02 13:48 --- Confirming it is a GDB bug, DW_TAG_module is completely ignored by dwarf2read.c. Older GCCs did not support module namespaces so it may look as a regression. I hope to patch it soon although I have no such patch right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39073
[Bug tree-optimization/39075] New: alignment for "unsigned short a[10000
-- Summary: alignment for "unsigned short a[1 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dann at godzilla dot ics dot uci dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39075
[Bug tree-optimization/39075] alignment for "unsigned short a[10000]" vs "extern unsigned short a[10000]"
--- Comment #1 from dann at godzilla dot ics dot uci dot edu 2009-02-02
14:50 ---
This code:
unsigned short a[1];
void test()
{
int i;
for (i = 0; i < 1; ++i) a[i] = 5;
}
will be vectorized with -O3 -march=core2 to this:
.L2:
movdqa %xmm0, a(%eax)
addl$16, %eax
cmpl$2, %eax
jne .L2
but this one:
extern unsigned short a[1];
void test()
{
int i;
for (i = 0; i < 1; ++i) a[i] = 5;
}
will get a lot of extra code before the loop because the vectorizer thinks it
needs to do peeling for alignment:
test.c:7: note: Alignment of access forced using peeling.
Intel's compiler does not generate the extra peeling code.
--
dann at godzilla dot ics dot uci dot edu changed:
What|Removed |Added
Summary|alignment for "unsigned |alignment for "unsigned
|short a[1 |short a[1]" vs "extern
||unsigned short a[1]"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39075
[Bug c/39076] New: internal compiler error when cross-compiling flac
I am trying to cross-compile flac 1.2.1 (from http://downloads.sourceforge.net/flac/) for an ARM processor. The toolchain I am using is based on a pretty recent buildroot snapshot (20090130). Here's the output of gcc -v: Using built-in specs. Target: arm-linux-uclibcgnueabi Configured with: /home/sven/buildroot/toolchain_build_arm/gcc-4.3.2/configure --prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=arm-linux-uclibcgnueabi --enable-languages=c,c++ --with-sysroot=/home/sven/buildroot/build_arm/staging_dir --with-build-time-tools=/home/sven/buildroot/build_arm/staging_dir/usr/arm-linux-uclibcgnueabi/bin --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --enable-shared --with-gmp=/home/sven/buildroot/toolchain_build_arm/gmp --with-mpfr=/home/sven/buildroot/toolchain_build_arm/mpfr --disable-nls --enable-threads --disable-multilib --disable-decimal-float --with-float=soft --with-abi=aapcs --with-arch=iwmmxt --with-tune=iwmmxt Thread model: posix gcc version 4.3.2 (GCC) Here's the command that breaks and the output from the compiler: /home/sven/buildroot/build_arm/staging_dir/usr/bin/arm-linux-uclibcgnueabi-gcc -Os -I/home/sven/buildroot/build_arm/staging_dir/usr/include -I/home/sven/buildroot/build_arm/staging_dir/include --sysroot=/home/sven/buildroot/build_arm/staging_dir/ -isysroot /home/sven/buildroot/build_arm/staging_dir -mabi=aapcs -msoft-float -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DARM_UNROLL_FIX -DHAVE_CONFIG_H -I. -I. -I../.. -DFLaC__INLINE=__inline__ -DNDEBUG -I../.. -I./include -I../../include -I/home/sven/buildroot/build_arm/staging_dir/usr/include -I/usr/include -O3 -funroll-loops -finline-functions -Wall -W -Winline -Os -I/home/sven/buildroot/build_arm/staging_dir/usr/include -I/home/sven/buildroot/build_arm/staging_dir/include --sysroot=/home/sven/buildroot/build_arm/staging_dir/ -isysroot /home/sven/buildroot/build_arm/staging_dir -mabi=aapcs -msoft-float -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DARM_UNROLL_FIX -MT bitreader.lo -MD -MP -MF .deps/bitreader.Tpo -c bitreader.c -fPIC -DPIC -o .libs/bitreader.o bitreader.c: In function 'bitreader_read_from_client_': bitreader.c:288: internal compiler error: Segmentation fault -- Summary: internal compiler error when cross-compiling flac Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: s dot neumann at phase-zero dot de GCC host triplet: i486-linux-gnu GCC target triplet: arm-linux-uclibcgnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39076
[Bug c/39076] internal compiler error when cross-compiling flac
--- Comment #1 from s dot neumann at phase-zero dot de 2009-02-02 16:08 --- Created an attachment (id=17228) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17228&action=view) preprocessed file that triggers the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39076
[Bug libstdc++/35942] Self Reference In Dynamic Linked Library builds for building Cross-Compiler
--- Comment #11 from jzb2 at aexorsyst dot com 2009-02-02 16:26 --- Well, I answered my own question, sort of... In my /usr/bin/libtool, in the CXX tag section, I have postdeps="-lstdc++ -lm -lgcc_s -lc -lgcc_s" so voila, that's where it comes from, probably. So this issue can now be reduced to the following: Native builds and cross-compiles of libstdc++.so override this postdeps and zero it out. However, using a cross-compiler to generate host=target native compiler with build!=host leaves it pulled in, being responsible, I believe, for this bug. Whether that's a libtool bug or a libstdc++ configure bug remain unanswered... Maybe this is a new wrinkle that newish versions of libtool have and perhaps has not needed to be dealt with before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35942
[Bug tree-optimization/39068] signed short plus and signed char plus not vectorized
--- Comment #3 from dann at godzilla dot ics dot uci dot edu 2009-02-02 16:42 --- (In reply to comment #2) > (reminds me of a couple missed-optimization PRs where vectorization is also > failing due to casts - PR31873 , PR26128 - don't know if this is related) Are the casts actually needed in this case? It seems the get introduced very early on, the .original dump already has: a[i] = (short int) ((short unsigned int) b[i] + (short unsigned int) c[i]); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39068
[Bug tree-optimization/38977] [4.4 Regression] bash no longer builds with profile-feedback
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-02-02 16:46 --- I'll see if it helps bash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38977
[Bug target/39079] New: MIPS: __builtin___clear_cache() broken on SMP ISA_HAS_SYNCI systems.
We expand __builtin___clear_cache() to a 'synci' instruction on ISA_HAS_SYNCI systems, which invalidates the icache only on the local CPU. On an SMP system, the caches on all CPUs should be invalidated. To achieve this we need to drop back to the old way of doing things by using the cache flush system call. -- Summary: MIPS: __builtin___clear_cache() broken on SMP ISA_HAS_SYNCI systems. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: daney at gcc dot gnu dot org GCC build triplet: mips64-unknown-linux-gnu GCC host triplet: mips64-unknown-linux-gnu GCC target triplet: mips64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39079
[Bug c/33466] mixed-case suffix for decimal float constants
--- Comment #2 from janis at gcc dot gnu dot org 2009-02-02 17:39 --- Yes, this is indeed a bug. -- janis at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janis at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-02 17:39:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33466
[Bug preprocessor/39080] New: -MF writes dependencies for last file only
This command produces dependencies for several source files and write them to the standard output: gcc -M -MM file1.c file2.c file3.c Problem appears when I try to save them to file using -MF option: gcc -M -MM -MF makefile.dep file1.c file2.c file3.c In this case gcc write dependencies for last file only (in this case for file3.c). -- Summary: -MF writes dependencies for last file only Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bugzilla at poradnik-webmastera dot com GCC build triplet: sparc-sun-solaris2.9 GCC host triplet: sparc-sun-solaris2.9 GCC target triplet: sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39080
[Bug rtl-optimization/39081] New: missed optimization: un-needed copy of structure.
The following block of code appears to produce an un-needed memcpy on both
Intel and PowerPC platforms. There is no aliasing or side-effect that I can
think of that could possibly force such copying to occur -- the problem seems
to be that gcc is not aware of the lifetime of large structures kept on stack.
The full source code:
class TV
{
private:
float truth;
float confidence;
int stuff[444];
public:
TV(void);
float getT(void);
};
extern TV my_tv_maker(float tr);
extern void other(TV *);
float my_subr(float tr)
{
TV tv;
other (&tv); // force constructor TV::TV to run first
tv = my_tv_maker(434.23); // over-write previous tv.
return tv.getT();
}
PowerPC assembly, created with gcc -S -O2 -c
.L._Z7my_subrf:
.LFB2:
mflr 0
.LCFI0:
std 28,-32(1)
.LCFI1:
std 29,-24(1)
.LCFI2:
std 0,16(1)
.LCFI3:
stdu 1,-3728(1)make room for two instances of TV on stack
.LCFI4:
addi 29,1,112 one instance of TV
addi 28,1,1904 second instance of TV
mr 3,29
bl _ZN2TVC1Ev call constructor on instance 1
nop
mr 3,29
bl _Z5otherP2TVcall other() on instance 1
nop
lfs 1,@toc(2)
mr 3,28
bl _Z11my_tv_makerf call my_tv_make on instance 2
nop
mr 4,28
mr 3,29
li 5,1784
bl memcpy copy instance 2 over to 1! waste of CPU!
nop
mr 3,29
bl _ZN2TV4getTEvcall method on instance 1
nop
addi 1,1,3728
ld 0,16(1)
ld 28,-32(1)
ld 29,-24(1)
mtlr 0
blr
The missed optimizations are: -- two copies of the instance are not needed; the
copy is not needed either. For large structures, this can be a significant
time-waster.
Exactly the same problem shows up in Intel as well:
_Z7my_subrf:
.LFB2:
pushl %ebp
.LCFI0:
movl %esp, %ebp
.LCFI1:
subl $3608, %esp
.LCFI2:
movl %ebx, -8(%ebp)
.LCFI3:
leal -1792(%ebp), %ebxinstance 1 of TV
movl %esi, -4(%ebp)
.LCFI4:
leal -3592(%ebp), %esiinstance 2 of TV
movl %ebx, (%esp)
call _ZN2TVC1Ev call constructor on instance 1
movl %ebx, (%esp)
call _Z5otherP2TV call other() on instance 1
movl %esi, (%esp)
movl $0x43d91d71, 4(%esp)
call _Z11my_tv_makerf call my_tv_maker on instance 2
subl $4, %esp
movl %esi, 4(%esp)
movl %ebx, (%esp)
movl $1784, 8(%esp)
call memcpy copy instance 2 to instance 1
movl %ebx, (%esp)
call _ZN2TV4getTEv call getT() on instance 1
movl -8(%ebp), %ebx
movl -4(%ebp), %esi
movl %ebp, %esp
popl %ebp
ret
--
Summary: missed optimization: un-needed copy of structure.
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: linasvepstas at gmail dot com
GCC build triplet: powerpc64-unknown-linux-gnu
GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39081
[Bug inline-asm/39058] [4.3 regression] ICE with double in inline-asm
--- Comment #4 from jakub at gcc dot gnu dot org 2009-02-02 13:24 --- Fixed on the trunk so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4 regression] ICE|[4.3 regression] ICE with |with double in inline-asm |double in inline-asm http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39058
[Bug rtl-optimization/39081] missed optimization: un-needed copy of structure.
--- Comment #1 from linasvepstas at gmail dot com 2009-02-02 17:57 --- Happens both for 4.1.2 on powerpc, and 4.2.4 on Intel: gcc -v Using built-in specs. Target: powerpc64-unknown-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure --prefix=/usr --bindir=/usr/powerpc64-unknown-linux-gnu/gcc-bin/4.1.2 --includedir=/usr/lib/gcc/powerpc64-unknown-linux-gnu/4.1.2/include --datadir=/usr/share/gcc-data/powerpc64-unknown-linux-gnu/4.1.2 --mandir=/usr/share/gcc-data/powerpc64-unknown-linux-gnu/4.1.2/man --infodir=/usr/share/gcc-data/powerpc64-unknown-linux-gnu/4.1.2/info --with-gxx-include-dir=/usr/lib/gcc/powerpc64-unknown-linux-gnu/4.1.2/include/g++-v4 --host=powerpc64-unknown-linux-gnu --build=powerpc64-unknown-linux-gnu --enable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --enable-libmudflap --disable-libssp --enable-objc-gc --enable-languages=c,c++,java,objc,obj-c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2) and also: gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3) -- linasvepstas at gmail dot com changed: What|Removed |Added Version|4.1.2 |4.2.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39081
[Bug debug/39073] [4.4 Regression] unable to debug CP2K (no local symbols)
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39073
[Bug target/37520] junk `(,%eax,4)' after expression / suffix or operands invalid for `lea' for libstdc++ deque/init-list.cc
--- Comment #8 from bkoz at gcc dot gnu dot org 2009-02-02 18:26 --- This looks like it happens on FreeBSD 7.1 as well: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00142.html Any news on what is going on here? Please note that i386-bsd is a primary platform for a release, as per: http://gcc.gnu.org/gcc-4.4/criteria.html Thus, this should really be a higher priority than P3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37520
[Bug c++/39054] [4.3/4.4 regression] ICE with invalid pseudo-dtor in template
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-02 18:28:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39054
[Bug tree-optimization/39074] New: PTA constraint processing for *x = y is wrong
if the solution of x includes ANYTHING we fail to add the solution of y to all
variables. Testcase (fails on a-i branch):
int i;
void __attribute__((noinline))
foo(long b, long q)
{
int *y;
int **a = &y, **x;
int ***p;
if (b)
p = (int ***)q;
else
p = &a;
x = *p;
*x = &i;
*y = 0;
}
extern void abort (void);
int main()
{
i = 1;
foo (0, 0);
if (i != 0)
abort ();
return 0;
}
I guess we should warn for dereferenced pointers whos points-to set is empty
with "warning: dereferencing uninitialized pointer".
--
Summary: PTA constraint processing for *x = y is wrong
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code, alias
Severity: major
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074
[Bug debug/39073] [4.4 Regression] unable to debug CP2K (no local symbols)
--- Comment #2 from burnus at gcc dot gnu dot org 2009-02-02 09:36 --- Jakub, do you have an idea? This might be a side effect of one of your DWARF patches. Reduced test case: module m contains subroutine a() integer :: i do i = 1, 5 if(i == 8) call abort() end do end subroutine a end module m use m call a() end $ gfortran-4.4 -g -O0 aaa.f90 $ gdb --quiet a.out (gdb) b 6 Breakpoint 1 at 0x400704: file aaa.f90, line 6. (gdb) run Starting program: /dev/shm/a.out Breakpoint 1, __m_MOD_a () at aaa.f90:6 6 if(i == 8) call abort() Current language: auto; currently fortran (gdb) p i No symbol "i" in current context. (gdb) pt i No symbol "i" in current context. $ gfortran-4.3 -g -O0 aaa.f90 $ gdb --quiet a.out (gdb) b 6 Breakpoint 1 at 0x400701: file aaa.f90, line 6. (gdb) run Starting program: /dev/shm/a.out Breakpoint 1, a () at aaa.f90:6 6 if(i == 8) call abort() Current language: auto; currently fortran (gdb) p i $1 = 1 (gdb) pt i type = integer(kind=4) -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39073
[Bug c++/39054] [4.3/4.4 regression] ICE with invalid pseudo-dtor in template
--- Comment #1 from jason at gcc dot gnu dot org 2009-02-02 18:38 --- Subject: Bug 39054 Author: jason Date: Mon Feb 2 18:38:10 2009 New Revision: 143876 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143876 Log: PR c++/39054 * parser.c (cp_parser_unqualified_id): Don't wrap error_mark_node in BIT_NOT_EXPR. Added: trunk/gcc/testsuite/g++.dg/parse/dtor14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39054
[Bug c++/39054] [4.3 regression] ICE with invalid pseudo-dtor in template
--- Comment #2 from jason at gcc dot gnu dot org 2009-02-02 18:38 --- Fixed in 4.4. -- jason at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4 regression] ICE|[4.3 regression] ICE with |with invalid pseudo-dtor in |invalid pseudo-dtor in |template|template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39054
[Bug c++/27078] [4.2/4.3/4.4 Regression] Duplicate error message for ambiguous enum
--- Comment #10 from aaw at gcc dot gnu dot org 2009-02-02 19:13 --- There were problems with my original patch (Sadly, I don't recall the details.). I haven't looked at this in a while and am unlikely to do so soon. If someone else wants to look at this, please feel free to do so. -- aaw at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|aaw at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27078
[Bug tree-optimization/32921] [4.3/4.4 Regression] Revision 126326 causes 12% slowdown
--- Comment #60 from pthaugen at gcc dot gnu dot org 2009-02-02 19:16 --- I tried leslie3d on PPC. The alias-improvements branch does indeed seem to fix the issue. The version of leslie3d built with the alias-improvements branch is about 10% faster than a version built with trunk, and is equivalent to a trunk version built with --param max-aliased-vops=1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
[Bug tree-optimization/39074] PTA constraint processing for *x = y is wrong
--- Comment #3 from dberlin at gcc dot gnu dot org 2009-02-02 19:42 --- Eyeballing this, I think y should not end up empty anyway. Shouldn't it have i in it's points-to set? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074
[Bug c++/39054] [4.3 regression] ICE with invalid pseudo-dtor in template
--- Comment #3 from jason at gcc dot gnu dot org 2009-02-02 19:57 --- Subject: Bug 39054 Author: jason Date: Mon Feb 2 19:57:29 2009 New Revision: 143879 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143879 Log: PR c++/39054 * parser.c (cp_parser_unqualified_id): Don't wrap error_mark_node in BIT_NOT_EXPR. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/parse/dtor14.C - copied unchanged from r143876, trunk/gcc/testsuite/g++.dg/parse/dtor14.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/parser.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39054
[Bug tree-optimization/38401] TreeSSA-PRE load after store missed optimization
--- Comment #24 from amylaar at gcc dot gnu dot org 2009-02-02 20:02 --- (In reply to comment #22) > If you post a patch to add the option to enable/disable partial-PRE I will > happily review and approve it for 4.4. I experimented using Seteven Bosscher's patch as a starting point and augmenting the test in do_regular_insertion with a speed based heuristic to throttle the calls to insert_into_preds_of_block. That was worse than turning off partial-PRE altogether. Then I added the heuristic also in do_partial_insertion, which worked better. Then I tried to remove the speed heuristoc from do_regular_insertion, and taht change only very tiny, although overall beneficial, effects. To get meaningful results we had to modify the linking a bit to reduce instruction cache effects: the most needed libgcc function were pulled out early and placed next to the core benchmark objects. applying heuristic only to partial-partial vs. not applying it at all is... automotive: 6.55389% faster consumer: 0.00048% worse networking: 0.03793% faster office: 0.07269% worse telecom:0.0% faster applying heuristic only to partial-partial vs. applying it in general is... automotive: 0.00674% faster consumer: 0.00076% worse networking: 0.01746% faster office: 0.00440% worse telecom:0.2% worse Unfortunately, there is still no word from the FSF on what they did with our Copyright Assignment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38401
[Bug testsuite/38263] gcc.dg/ipa/ipacost-2.c fails with -fpic/-fPIC
--- Comment #4 from ghazi at gcc dot gnu dot org 2009-02-02 20:10 --- Subject: Bug 38263 Author: ghazi Date: Mon Feb 2 20:10:04 2009 New Revision: 143880 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143880 Log: PR testsuite/38263 * gcc.dg/ipa/ipacost-2.c: Add -fpie when pic. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/ipa/ipacost-2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38263
[Bug debug/39073] [4.4 Regression] unable to debug CP2K (no local symbols)
--- Comment #5 from jakub at gcc dot gnu dot org 2009-02-02 09:51 --- The generated unwind info looks good to me, so it is likely a gdb issue. [58]module name "m" decl_file1 decl_line1 sibling [89] [61] subprogram external name "a" decl_file1 decl_line3 low_pc 0x0040065c <__m_MOD_a> high_pc 0x00400698 frame_base location list [24] [7b]variable name "i" decl_file1 decl_line4 type [89] location 2 byte block [ 0] fbreg -20 [89]base_type byte_size4 encoding signed (5) name "integer(kind=4)" is in the CU (together with MAIN__, but that is not relevant to i in the module function). -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jan dot kratochvil at redhat ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39073
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #74 from jason at gcc dot gnu dot org 2009-02-02 20:27 --- Since my suggested patch proved somewhat controversial, for 4.4 I'd like to fall back on the simpler solution that Howard proposed in the initial bug report; it is inappropriate for library headers to redefine keywords. -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jason at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug c/38957] [4.3 Regression] return of local variable pointer
--- Comment #5 from cnstar9988 at gmail dot com 2009-02-02 13:19 --- ping 4.3.4, thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38957
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #76 from paolo dot carlini at oracle dot com 2009-02-02 21:11 --- Ok, let's wait a couple of days and, assuming there are no objections, I volunteer to implement that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug tree-optimization/38937] [4.4 Regression] dereferencing pointer '' does break strict-aliasing
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-02-02 10:39 --- Subject: Bug 38937 Author: rguenth Date: Mon Feb 2 10:39:12 2009 New Revision: 143864 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143864 Log: 2009-02-02 Richard Guenther PR tree-optimization/38937 * g++.dg/warn/Wstrict-aliasing-bogus-escape.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-bogus-escape.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38937
[Bug inline-asm/39058] [4.3/4.4 regression] ICE with double in inline-asm
--- Comment #3 from jakub at gcc dot gnu dot org 2009-02-02 13:23 --- Subject: Bug 39058 Author: jakub Date: Mon Feb 2 13:23:43 2009 New Revision: 143867 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143867 Log: PR inline-asm/39058 * recog.h (asm_operand_ok): Add constraints argument. * recog.c (asm_operand_ok): Likewise. If it is set, for digits recurse on matching constraint. (check_asm_operands): Pass constraints as 3rd argument to asm_operand_ok. Don't look up matching constraint here. * stmt.c (expand_asm_operands): Pass NULL as 3rd argument to asm_operand_ok. * gcc.target/i386/pr39058.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr39058.c Modified: trunk/gcc/ChangeLog trunk/gcc/recog.c trunk/gcc/recog.h trunk/gcc/stmt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39058
[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-02-02 10:23
---
Same issue. Only possible fix is to not apply TBAA pruning to escaped
symbols, which will - well - basically disable TBAA. Testcase:
inline void *operator new (__SIZE_TYPE__, void *__p) throw() { return __p; }
struct Y {
Y() {}
int i;
};
struct X {
X() {}
void construct(const Y& y)
{
new (&m_data[0]) Y(y);
}
template
Y& get() { return reinterpret_cast(m_data); }
bool initialized;
char m_data[sizeof (Y)];
};
X x;
void bar(const X&);
void foo(Y& y)
{
x.get() = y;
x.initialized = true;
bar(x);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #75 from mark at codesourcery dot com 2009-02-02 20:29 --- Subject: Re: exception_defines.h #defines try/catch jason at gcc dot gnu dot org wrote: > Since my suggested patch proved somewhat controversial, for 4.4 I'd like to > fall back on the simpler solution that Howard proposed in the initial bug > report; it is inappropriate for library headers to redefine keywords. Makes sense to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug target/39065] libiberty hashtab.c:hash_pointer() needs intptr_t
--- Comment #2 from dj at redhat dot com 2009-02-02 21:52 --- You should put the new code in a #ifdef HAVE_STDINT and use the old code otherwise. Else, any platforms without stdint.h would not compile. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39065
[Bug tree-optimization/39075] alignment for "unsigned short a[10000]" vs "extern unsigned short a[10000]"
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-02 14:53 --- The ABI does not guarantee alignment bigger than 2 for the external array. The vectorizer adjusts the alignment for the internal one. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39075
[Bug debug/39073] [4.4 Regression] unable to debug CP2K (no local symbols)
--- Comment #4 from jv244 at cam dot ac dot uk 2009-02-02 09:49 --- (In reply to comment #3) thanks for the reduced testcase... will help :-) > Hmm, maybe this is only a gdb bug / missing feature. just as a note, I tried gdb 6.8 and it failed as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39073
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc
--- Comment #46 from mmitchel at gcc dot gnu dot org 2009-02-02 22:00 --- As I understand it, the complaint here is that GCC_EXEC_PREFIX being set affects HOSTCC, when HOSTCC is itself some other GCC. But, we have to make sure that the newly built compiler searches the right directory. That's why GCC_EXEC_PREFIX is set. (You can fix this by arranging to fix GCC's build process, so that components are installed within the build tree in the same way they would be at install time, and then you can forget all about GCC_EXEC_PREFIX, -B options, and everything else. But, it's a huge project.) HOSTCC is an arbitrary compiler. It need not even be a GNU compiler. DejaGNU, "make check", etc. set all manner of random environment variables. Therefore, if you want to be robust, HOSTCC needs to set/unset any environment variables relevant to its operation. -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug debug/39073] [4.4 Regression] unable to debug CP2K (no local symbols)
--- Comment #6 from jv244 at cam dot ac dot uk 2009-02-02 11:09 --- (In reply to comment #5) > The generated unwind info looks good to me, so it is likely a gdb issue. 1) how does one get this generated unwind info (I'd like to see what is different from 4.3)? 2) Do you see a way to work around this issue (other than using idb), since this impacts the debugability of Fortran code significantly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39073
[Bug c/39076] internal compiler error when cross-compiling flac
--- Comment #2 from falk at debian dot org 2009-02-02 19:02 ---
No problem with the trunk, but it's still there in the 4.3 branch.
Here's a test case. Requires -funroll-loops -Os, no problem with any other -O,
or without -funroll-loops, curiously.
int f(int x, int y) {
int bytes = 4 * x + y;
if (bytes == 0)
return 0;
return bytes + 1;
}
--
falk at debian dot org changed:
What|Removed |Added
CC||falk at debian dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail||4.3.4
Known to work||4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39076
[Bug middle-end/39075] alignment for "unsigned short a[10000]" vs "extern unsigned short a[10000]"
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|tree-optimization |middle-end Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2009-02-02 15:03:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39075
[Bug tree-optimization/39074] PTA constraint processing for *x = y is wrong
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-02 14:03 ---
We could for example warn for
/* { dg-do compile } */
/* { dg-options "-O -Wuninitialized" } */
int i;
int __attribute((const,noinline))
foo (int **p)
{
return i;
}
int bar(int *q)
{
int *p;
*q = 0;
int j = foo(&p);
return *p + j; /* { dg-warning "dereferencing uninitialized" } */
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-02-02 14:03:04
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074
[Bug target/39082] New: union with long double doesn't follow x86-64 psABI
x86-64 psABI says:
The 64-bit mantissa of arguments of type {long double
belongs to class X87, the 16-bit exponent plus 6 bytes of padding
belongs to class X87UP.
...
If one of the classes is X87, X87UP, COMPLEX\_X87 class,
MEMORY is used as class.
But I got
[...@gnu-6 avx-abi]$ cat u4.i
union sse2
{
int i;
long double x;
};
long double
bar2 (union sse2 x)
{
return x.x;
}
long double
foo2 (long double x)
{
union sse2 y;
y.x = x;
return bar2 (y);
}
[...@gnu-6 avx-abi]$ gcc -S u4.i -O -fno-asynchronous-unwind-tables
[...@gnu-6 avx-abi]$ cat u4.s
.file "u4.i"
.text
.globl bar2
.type bar2, @function
bar2:
movq%rdi, -24(%rsp)
movq%xmm0, -16(%rsp)
fldt-24(%rsp)
ret
.size bar2, .-bar2
.globl foo2
.type foo2, @function
foo2:
subq$24, %rsp
movq32(%rsp), %rax
movl40(%rsp), %edx
movq%rax, (%rsp)
movl%edx, 8(%rsp)
movq(%rsp), %rdi
movq8(%rsp), %xmm0
callbar2
addq$24, %rsp
ret
.size foo2, .-foo2
Dave, does icc follow psABI?
--
Summary: union with long double doesn't follow x86-64 psABI
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: x86_64-*-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39082
[Bug debug/39073] [4.4 Regression] unable to debug CP2K (no local symbols)
--- Comment #8 from jv244 at cam dot ac dot uk 2009-02-02 12:14 --- (In reply to comment #7) > 2) report this to gdb and help them fix it. OK, I've at least been able to add a PR for this in the gdb bugzilla: http://sourceware.org/bugzilla/show_bug.cgi?id=9806 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39073
[Bug c++/39050] [c++0x] rvalue reference & copy construction issue
--- Comment #1 from s dot gesemann at gmail dot com 2009-02-02 15:18 --- This is probably just another manifestation of the same bug (#36744) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36744 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39050
[Bug tree-optimization/38977] [4.4 Regression] bash no longer builds with profile-feedback
--- Comment #11 from sje at cup dot hp dot com 2009-02-02 16:27 --- Has anyone tested the patch in comment #9. I didn't test it with bash but I did test it with Python (PR 38292) because I was looking at that bug and it seemed to fix the problem. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38977
[Bug c++/39077] GCSE-optimization causes enormous binary size increase (~20 times !)
--- Comment #1 from comer352l at googlemail dot com 2009-02-02 16:22 --- Created an attachment (id=17229) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17229&action=view) Preprocessed file (created with gcc4.3.2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39077
[Bug c++/39056] [4.4 regression] [c++0x] ICE with invalid initializer list for complex variable
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-02 11:18 ---
I think this depends on whether we want as an exception allow this or not.
If not, e.g.:
--- typeck2.c.jj22009-01-13 18:32:14.0 +0100
+++ typeck2.c2009-02-02 12:15:58.0 +0100
@@ -789,7 +789,8 @@ digest_init_r (tree type, tree init, boo
}
/* Handle scalar types (including conversions) and references. */
- if (TREE_CODE (type) != COMPLEX_TYPE
+ if ((TREE_CODE (type) != COMPLEX_TYPE
+ || BRACE_ENCLOSED_INITIALIZER_P (init))
&& (SCALAR_TYPE_P (type) || code == REFERENCE_TYPE))
{
tree *exp;
gets rid of the ICE, instead it will reject it with:
pr39056.C:1: error: cannot convert '' to 'int
__complex__' in initialization
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39056
[Bug tree-optimization/38964] TBAA side-effects of C++ new still missing
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-02-02 10:24 ---
Nice testcase from PR38503:
inline void *operator new (__SIZE_TYPE__, void *__p) throw() { return __p; }
struct Y {
Y() {}
int i;
};
struct X {
X() {}
void construct(const Y& y)
{
new (&m_data[0]) Y(y);
}
template
Y& get() { return reinterpret_cast(m_data); }
bool initialized;
char m_data[sizeof (Y)];
};
X x;
void bar(const X&);
void foo(Y& y)
{
x.get() = y;
x.initialized = true;
bar(x);
}
we have to assume that any globally accessible decl has a different dynamic
type than its declared type. Thus we may not apply TBAA to any ESCAPED
symbol.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38964
[Bug tree-optimization/39074] PTA constraint processing for *x = y is wrong
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-02 14:07 --- Created an attachment (id=17227) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17227&action=view) patch to warn about uninitialized pointer dereferences This patch causes a warning for both testcases, the program and the PTA bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074
[Bug target/39065] libiberty hashtab.c:hash_pointer() needs intptr_t
--- Comment #3 from sezeroz at gmail dot com 2009-02-02 22:59 --- (In reply to comment #2) > You should put the new code in a #ifdef HAVE_STDINT and use the old code > otherwise. Else, any platforms without stdint.h would not compile. > I would do that and it would be easy, but then one may say that having intptr_t doesn't have to depend on having stdint.h: in MSVC, for one, you get it via the stddef.h header. Maybe adding an AC_CHECK_TYPE(intptr_t,long) to configure.ac would be better solution? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39065
[Bug c/39034] Decimal floating-point math done wrong
--- Comment #4 from bje at gcc dot gnu dot org 2009-02-02 23:03 --- Subject: Bug 39034 Author: bje Date: Mon Feb 2 23:03:20 2009 New Revision: 143884 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143884 Log: PR c/39034 * gcc.dg/dfp/pr39034.c: New test. Added: trunk/gcc/testsuite/gcc.dg/dfp/pr39034.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39034
[Bug tree-optimization/39075] alignment for "unsigned short a[10000]" vs "extern unsigned short a[10000]"
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-02 14:55 --- Err, it seems at least the x86_64 ABI guarantees alignment of 16 bytes for arrays bigger than 16 bytes (including variable length arrays). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39075
[Bug debug/39073] [4.4 Regression] unable to debug CP2K (no local symbols)
--- Comment #3 from burnus at gcc dot gnu dot org 2009-02-02 09:45 --- Hmm, maybe this is only a gdb bug / missing feature. $ gfortran-4.4 -O0 -g aaa.f90 $ idbc a.out Intel(R) Debugger for applications running on Intel(R) 64, Version 11.1 Beta, Build [1.2097.2.21] [...] (idb) b 6 Breakpoint 1 at 0x4006e4: file /dev/shm/aaa.f90, line 6. (idb) run [...] 6 if(i == 8) call abort() (idb) pt i type = INTEGER(4) (idb) p i $1 = 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39073
[Bug c++/38928] infinite loop on error message in C++ only
--- Comment #7 from paolo dot carlini at oracle dot com 2009-02-02 10:19 --- Ok Mark, agreed, thanks. For the moment, I'm not going to work on this one and I'm unassigning myself in order not to prevent anyone else quicker than me... -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38928
[Bug inline-asm/39078] New: Registers in on clober list are cloberred when compiled with optimization (x86_64) ?
Source file:
file test.c
===
#define __NR_close 2
#define CLOBBER_LIST "memory", "cc", "r11", "r12", "r13", "r14", "r15", "rbx"
#define MY_SYSCALL_1(ARG)
\
__extension__ ((
\
{
\
register unsigned long result;
\
register unsigned long _arg1 asm("rdi") = (unsigned
long)ARG; \
asm volatile (
\
"call my_syscall\n\t"
\
: "=a" (result)
\
: "0" (__NR_close), "r" (_arg1)
\
: CLOBBER_LIST
\
);
\
result;
\
} ))
\
void func_1(int arg)
{
MY_SYSCALL_1(arg);
}
Compilation command:
gcc -O2 -S -o test.S test.c
Output file (test.S)
=
.file "bb.c"
.text
.p2align 4,,15
.globl func_1
.type func_1, @function
func_1:
.LFB2:
movq%rbx, -40(%rsp)
.LCFI0:
movq%r12, -32(%rsp)
.LCFI1:
movslq %edi,%rdi
movq%r13, -24(%rsp)
.LCFI2:
movq%r14, -16(%rsp)
.LCFI3:
movl$2, %eax
movq%r15, -8(%rsp)
.LCFI4:
#APP
call my_syscall
#NO_APP
movq-40(%rsp), %rbx
movq-32(%rsp), %r12
movq-24(%rsp), %r13
movq-16(%rsp), %r14
movq-8(%rsp), %r15
ret
=
All registers mentioned in the CLOBERR_LIST (but r11) are moved to the stack.
Stack pointer doesn't adjusted !!!
Than 'call my_syscall' overwrite on the stack saved value of 'r15'.
Than, future instructions in the 'my_syscall' can overwrite other saved
registers.
After return from 'my_syscall' overwritten values copied to registers.
I.e while compiler tried to save CLOBER_LIST registers' content it failed to do
it.
I tried to compile code both with gcc-3.4.2 (FedoraCore 3) and gcc-4.1.2
(Fedora 8) - results are same.
Result are same when compile with any of -O1,-O2 or -O3.
When compile without optimization, stack pointer is adjusted, i.e generated
code is OK.
--
Summary: Registers in on clober list are cloberred when compiled
with optimization (x86_64) ?
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: valery_reznic at yahoo dot com
GCC host triplet: file bb.c
=
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39078
[Bug debug/39073] [4.4 Regression] unable to debug CP2K (no local symbols)
--- Comment #7 from jakub at gcc dot gnu dot org 2009-02-02 11:57 --- 1) eu-readelf -w info. If you don't have elfutils, binutils readelf -wi generates similar output, though without the indentation, so it is harder to find out the parent/child/sibling relation between consecutive DIEs. 2) report this to gdb and help them fix it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39073
[Bug c++/39056] [4.4 regression] [c++0x] ICE with invalid initializer list for complex variable
--- Comment #2 from jason at gcc dot gnu dot org 2009-02-02 19:02 ---
Jakub's patch looks fine to me.
Benjamin, does you have an opinion about initializer-lists and complex? I
guess the library complex class will accept { real, imag } naturally because it
has a suitable constructor.
Note that initialization with = { 0 } still works normally, and = { 0, 0 } is
still rejected as having too many initializers for a scalar, like in C.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
CC||bkoz at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39056
[Bug tree-optimization/38844] [4.3/4.4 Regression] deadlock with __attribute__((always_inline)) at -O1 and above
--- Comment #12 from hubicka at gcc dot gnu dot org 2009-02-02 16:35
---
try_inline should not recurse when edge is already inlined. The following
patch should fix the problem, I will benchmark it tonight
Index: ipa-inline.c
===
--- ipa-inline.c(revision 143680)
+++ ipa-inline.c(working copy)
@@ -1330,16 +1330,18 @@ try_inline (struct cgraph_edge *e, enum
cgraph_node_name (e->caller));
}
if (e->inline_failed)
-cgraph_mark_inline (e);
+{
+ cgraph_mark_inline (e);
- /* In order to fully inline always_inline functions, we need to
- recurse here, since the inlined functions might not be processed by
- incremental inlining at all yet.
+ /* In order to fully inline always_inline functions, we need to
+recurse here, since the inlined functions might not be processed by
+incremental inlining at all yet.
- Also flattening needs to be done recursively. */
+Also flattening needs to be done recursively. */
- if (mode == INLINE_ALL || always_inline)
-cgraph_decide_inlining_incrementally (e->callee, mode, depth + 1);
+ if (mode == INLINE_ALL || always_inline)
+ cgraph_decide_inlining_incrementally (e->callee, mode, depth + 1);
+}
callee->aux = (void *)(size_t) callee_mode;
return true;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38844
[Bug c++/39077] New: GCSE-optimization causes enormous binary size increase (~20 times !)
The example attached is a simple data-container-class. The data is stored as Qt4-QStringLists. Everything was fine with gcc 4.1 (330KB). 4.2 already caused a significant increase. With 4.3, the binary size increased enormously again (6.7MB !). When I disable GCSE-optimization using the additional flag "-fnogcse", I get normal binary sizes (360KB with 4.3.2). Command line use for compilation: g++ -c -pipe -O2 -march=i586 -mtune=i686 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/default -I. -I/usr/include/QtCore -I/usr/include/QtCore -I/usr/include/QtGui -I/usr/include/QtGui -I/usr/include -I. -Isrc -Isrc/linux -I. -I. -o SSMprotocol_def_en.o src/SSMprotocol_def_en.cpp => no errors or warnings GCC-info (Output of 'g++ -v'): Target: i586-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.3 --enable-linux-futex --without-system-libunwind --with-cpu=generic --build=i586-suse-linux Thread model: posix gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) -- Summary: GCSE-optimization causes enormous binary size increase (~20 times !) Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: comer352l at googlemail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39077
[Bug inline-asm/39058] [4.3/4.4 regression] ICE with double in inline-asm
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-02 10:06 --- I think the bug is in check_asm_operands/asm_operand_ok. The latter has: case '0': case '1': case '2': case '3': case '4': case '5': case '6': case '7': case '8': case '9': /* For best results, our caller should have given us the proper matching constraint, but we can't actually fail the check if they didn't. Indicate that results are inconclusive. */ but the former only handles the simple case: if (c[0] == '%') c++; if (ISDIGIT ((unsigned char) c[0]) && c[1] == '\0') c = constraints[c[0] - '0']; Together this allows combine to combine something that definitely shouldn't be combined. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-02 10:06:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39058
[Bug bootstrap/39025] ICE in start_function, at c-decl.c:6225 while configuring libgcc
--- Comment #1 from ro at gcc dot gnu dot org 2009-02-02 23:43 ---
It turns out that there are two problems here:
* If you invoke cc1 conftest.c (i.e. without -quiet), you get the ICE from the
assertion failure in c-decl.c:6225:
/* This is the earliest point at which we might know the assembler
name of the function. Thus, if it's set before this, die horribly. */
gcc_assert (!DECL_ASSEMBLER_NAME_SET_P (decl1));
decl1 has an assembler_name of "main" at this point, which is due to this
change in toplev.c (announce_function):
@@ -419,10 +432,7 @@ announce_function (tree decl)
{
if (!quiet_flag)
{
- if (rtl_dump_and_exit)
- fprintf (stderr, "%s ", IDENTIFIER_POINTER (DECL_NAME (decl)));
- else
- fprintf (stderr, " %s", lang_hooks.decl_printable_name (decl, 2));
+ fprintf (stderr, "%s ", IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME
(decl)));
fflush (stderr);
pp_needs_newline (global_dc->printer) = true;
diagnostic_set_last_function (global_dc, (diagnostic_info *) NULL);
Unlike lang_hooks.decl_printable_name, decl_assembler_name sets
assembler_name
if unset, thus breaking the later assert. Since announce_functions gards
this with !quiet_flag, it only breaks without that flag.
* If instead on runs cc1 -g -quiet conftest.c (-g is necessary to trigger the
bug which breaks configure, -quiet works around the first problem), on gets
this instead.
> ./cc1 -g -quiet conftest.c
conftest.c:9: internal compiler error: Segmentation Fault
Running cc1 under gdb reveals
Program received signal SIGSEGV, Segmentation fault.
0x083fdd54 in get_personality_function (decl=0x0) at
/vol/gcc/src/gcc-lto/gcc/expr.h:806
(gdb) where
#0 0x083fdd54 in get_personality_function (decl=0x0) at
/vol/gcc/src/gcc-lto/gcc/expr.h:806
#1 0x08404f08 in output_call_frame_info (for_eh=0) at
/vol/gcc/src/gcc-lto/gcc/dwarf2out.c:2914
#2 0x08405fce in dwarf2out_frame_finish () at
/vol/gcc/src/gcc-lto/gcc/dwarf2out.c:3351
#3 0x0899930a in compile_file () at /vol/gcc/src/gcc-lto/gcc/toplev.c:1023
#4 0x0899acc4 in do_compile () at /vol/gcc/src/gcc-lto/gcc/toplev.c:2220
#5 0x0899ad2b in toplev_main (argc=4, argv=0x80476cc) at
/vol/gcc/src/gcc-lto/gcc/toplev.c:2252
#6 0x0821c2f9 in main (argc=4, argv=0x80476cc) at
/vol/gcc/src/gcc-lto/gcc/main.c:35
I.e. get_personality_function is called with current_function_decl = NULL.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39025
[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)
--- Comment #14 from av1474 at comtv dot ru 2009-02-02 23:44 ---
(In reply to comment #8)
> Please provide a preprocessed reduced testcase as similar to the original as
> possible.
>
> I think this is not only predicated PHI but our representation of loops may
> also have something to do.
>
I'm not sure whether following warrants a new bug entry so doing it here,
sorry,
if it was inappropriate.
Following code, triggers:
"repro.c:5: warning: 'b' may be used uninitialized in this function"
with 4.3.0 and 4.3.1 on PowerPC when invoked like this:
gcc -c -O -Wuninitialized repro.c
int f (void);
int g (int a)
{
int b;
if (a) b = f ();
asm volatile ("#");
if (a) return b;
return 1;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
[Bug c++/39017] ice for legal C++ with -O3
--- Comment #3 from reichelt at gcc dot gnu dot org 2009-02-02 23:46 --- Looks indeed like a duplicate. I can reproduce the bug with GCC 4.4-20090123, but not with GCC 4.4-20090131. *** This bug has been marked as a duplicate of 38926 *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39017
[Bug tree-optimization/38926] [4.4 Regression] ice in find_or_generate_expression, at tree-ssa-pre.c:2769
--- Comment #11 from reichelt at gcc dot gnu dot org 2009-02-02 23:46 --- *** Bug 39017 has been marked as a duplicate of this bug. *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||dcb314 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38926
[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)
--- Comment #15 from manu at gcc dot gnu dot org 2009-02-03 00:27 --- (In reply to comment #14) > I'm not sure whether following warrants a new bug entry so doing it here, > sorry, > if it was inappropriate. That is a different case. This PR is about loops. Your case is about initialization and use guarded by the same predicate. I think there is already a bug report for this. But it is always better to open a new bug report in case of doubt. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
[Bug c++/29974] Segmentation fault on simple input file. Omission of #include prevents error. WinXP x64, cygwin
--- Comment #4 from dannysmith at users dot sourceforge dot net 2009-02-03 02:02 --- > /usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1plus.exe -quiet -v -D__CYGWIN32__ > -D__CYGWIN__ -Dunix - > D__unix__ -D__unix -idirafter > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api -i > dirafter > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/../../include/w32ap > i testFail.h -quiet -dumpbase testFail.h -mtune=pentiumpro -auxbase testFail > -version -o /cyg > drive/c/DOCUME~1/JAMESF~1/LOCALS~1/Temp/ccGNtP5T.s --output-pch=testFail.h.gch PCH support for cywgin was not available until 4.0 series. Your testcase compiles correctly on cygwin with recent (>=4.1) gcc. -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29974
[Bug c++/38950] [4.3/4.4 regression] ICE: deducing function template arguments for array type.
--- Comment #4 from schaub-johannes at web dot de 2009-02-03 02:02 --- Yes, sorry for not mentioning it. I also think the code is valid. In the link to stackoverflow.com, where i answered that guys question, i gave reasons why i think so. Next time i will put what i think about that directly into the bugreport :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38950
[Bug libfortran/39083] New: stage 3 libgfortran build fails
appears to be similar to reported bug against 4.3.2 -- Summary: stage 3 libgfortran build fails Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tony_eckert at umsl dot edu GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39083
[Bug libfortran/39083] stage 3 libgfortran build fails
--- Comment #1 from tony_eckert at umsl dot edu 2009-02-03 04:33 --- appears similar to bug 37865, but without --enable-intermodule. Only departure from defaults is --prefix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39083
Re: [Bug libfortran/39083] stage 3 libgfortran build fails
Sent from my iPhone On Feb 2, 2009, at 8:33 PM, "tony_eckert at umsl dot edu" > wrote: --- Comment #1 from tony_eckert at umsl dot edu 2009-02-03 04:33 --- appears similar to bug 37865, but without --enable-intermodule. Only departure from defaults is --prefix Are you building in the source tree? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39083
[Bug libfortran/39083] stage 3 libgfortran build fails
--- Comment #2 from pinskia at gmail dot com 2009-02-03 04:35 --- Subject: Re: stage 3 libgfortran build fails Sent from my iPhone On Feb 2, 2009, at 8:33 PM, "tony_eckert at umsl dot edu" wrote: > > > --- Comment #1 from tony_eckert at umsl dot edu 2009-02-03 > 04:33 --- > appears similar to bug 37865, but without --enable-intermodule. > Only departure from defaults is --prefix Are you building in the source tree? > > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39083 > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39083
[Bug fortran/39072] I/O READing logical value beyond end of string
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-02-03 04:43 --- I believe gfortran is correct as far as giving an error. The last logical value does not begin with a T(t) or F(f). On the commented out case gfortran agrees with g77. The string has one extra space in it so it misses the 1 character wide logical field. Adjusting that one byte, both gfortran and g77 get a valid read. The only thing remaining here to me is are we attempting to read past the end of record with the error case and so should we really be giving an EOR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39072
[Bug target/35318] [4.3/4.4 regression] ICE with inline asm in reload
--- Comment #7 from reichelt at gcc dot gnu dot org 2009-02-03 07:12 --- The ICE reappeared on the trunk: bug.c:5: internal compiler error: output_operand: floating constant misused Please submit a full bug report, [etc.] Jakub, this was probably caused by your the patch for PR39058. Maybe the IRA merge just papered over the real problem. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org Summary|[4.3 regression] ICE with |[4.3/4.4 regression] ICE |inline asm in reload|with inline asm in reload http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35318
