[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2010-01-15 08:27 --- sorry for replying late, I was missed this problem somehow in my bugzilla folder. The test in question verify that variables that are common or weak are also either public or external. No doubt about that. The problem is, this was installed without mention in the ChangeLog so looks quite unintentional. If this is intentional, you should fix the ChangeLog. I will have time to try to reproduce the problem only tomorrow or during weekend (it will be bit tricky as I know of no machine known to fail here I can access easily), Please read comment #5. but it seems to me that if Ada produce variable failing this test, it is frontend problem uncovered by the sanity check. See utils.c:create_var_decl_1 /* Ada doesn't feature Fortran-like COMMON variables so we shouldn't try to fiddle with DECL_COMMON. However, on platforms that don't support global BSS sections, uninitialized global variables would go in DATA instead, thus increasing the size of the executable. */ if (!flag_no_common TREE_CODE (var_decl) == VAR_DECL !have_global_bss_p ()) DECL_COMMON (var_decl) = 1; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug c/42753] New: _Complex_I is reported as undeclared. Code builds with Sun compiler.
The following piece of code, will not build with gcc 3.4.3 or gcc 4.4.1 on the
above SPARC system. It does build on at least some Linux systems. It is
somewhat similar to bug #21057 though that was reported against the C++
compiler g++, rather than gcc.
It will not build on an Open Solaris system either, but I'll file that as a
separate bug.
kir...@t2:[~] $ uname -a
SunOS t2 5.10 Generic_141414-02 sun4v sparc SUNW,T5240
kir...@t2:[~] $ cat /etc/release
Solaris 10 5/09 s10s_u7wos_08 SPARC
Copyright 2009 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 30 March 2009
Fist, it should be noted it builds with the Sun compiler, and executes as
expected, showing _Complex_I is defined.
kir...@t2:[~] $ /opt/SUNWspro/bin/cc -V simple_complex.c
cc: Sun C 5.9 SunOS_sparc Patch 124867-11 2009/04/30
acomp: Sun C 5.9 SunOS_sparc Patch 124867-11 2009/04/30
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.496
kir...@t2:[~] $ ./a.out
CYTHON_CCOMPLEX 1
Here's the source code.
kir...@t2:[~] $ cat simple_complex.c
#include stdio.h
#include complex.h
#if defined(_Complex_I)
#define CYTHON_CCOMPLEX 1
#else
#define CYTHON_CCOMPLEX 0
#endif
#if CYTHON_CCOMPLEX
typedef double _Complex __pyx_t_double_complex;
#else
typedef struct { double real, imag; } __pyx_t_double_complex;
#endif
#if CYTHON_CCOMPLEX
static __pyx_t_double_complex __pyx_t_double_complex_from_parts(double x,
double y) {
return x + y*(__pyx_t_double_complex)_Complex_I;
//return 0;
}
#else
static __pyx_t_double_complex __pyx_t_double_complex_from_parts(double x,
double y) {
__pyx_t_double_complex z;
z.real = x;
z.imag = y;
return z;
}
#endif
int main(int argc, char** argv) {
printf(CYTHON_CCOMPLEX %d\n, CYTHON_CCOMPLEX);
return 0;
}
kir...@t2:[~] $ /opt/SUNWspro/bin/cc simple_complex.c
kir...@t2:[~] $ ./a.out
CYTHON_CCOMPLEX 1
Here is the failure with gcc
kir...@t2:[~] $ gcc -v -std=c99 simple_complex.c
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.4.1/configure
--prefix=/usr/local/gcc-4.4.1-sun-linker/ --with-as=/usr/ccs/bin/as
--without-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld
--enable-languages=c,c++,fortran --with-mpfr-include=/usr/local/include
--with-mpfr-lib=/usr/local/lib --with-gmp-include=/usr/local/include
--with-gmp-lib=/usr/local/lib CC=/usr/sfw/bin/gcc CXX=/usr/sfw/bin/g++
Thread model: posix
gcc version 4.4.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-std=c99' '-mcpu=v9'
/usr/local/gcc-4.4.1-sun-linker/bin/../libexec/gcc/sparc-sun-solaris2.10/4.4.1/cc1
-quiet -v -iprefix
/usr/local/gcc-4.4.1-sun-linker/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.1/
-D__sparcv8 simple_complex.c -quiet -dumpbase simple_complex.c -mcpu=v9
-auxbase simple_complex -std=c99 -version -o /var/tmp//ccKtOZ4e.s
ignoring nonexistent directory
/usr/local/gcc-4.4.1-sun-linker/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.1/../../../../sparc-sun-solaris2.10/include
ignoring duplicate directory
/usr/local/gcc-4.4.1-sun-linker/bin/../lib/gcc/../../lib/gcc/sparc-sun-solaris2.10/4.4.1/include
ignoring duplicate directory
/usr/local/gcc-4.4.1-sun-linker/bin/../lib/gcc/../../lib/gcc/sparc-sun-solaris2.10/4.4.1/include-fixed
ignoring nonexistent directory
/usr/local/gcc-4.4.1-sun-linker/bin/../lib/gcc/../../lib/gcc/sparc-sun-solaris2.10/4.4.1/../../../../sparc-sun-solaris2.10/include
#include ... search starts here:
#include ... search starts here:
/usr/local/gcc-4.4.1-sun-linker/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.1/include
/usr/local/gcc-4.4.1-sun-linker/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.1/include-fixed
/usr/local/include
/usr/local/gcc-4.4.1-sun-linker/bin/../lib/gcc/../../include
/usr/include
End of search list.
GNU C (GCC) version 4.4.1 (sparc-sun-solaris2.10)
compiled by GNU C version 4.4.1, GMP version 4.3.1, MPFR version 2.4.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e89036b586fe85e82df0096e13fb8898
simple_complex.c: In function __pyx_t_double_complex_from_parts:
simple_complex.c:20: error: _Complex_I undeclared (first use in this
function)
simple_complex.c:20: error: (Each undeclared identifier is reported only once
simple_complex.c:20: error: for each function it appears in.)
I'm somewhat puzzled I can't see any option to attach a file, so I'll put
inline the preprocessed file, generated with:
kir...@t2:[~] $ gcc -v -save-temps -std=c99 simple_complex.c
kir...@t2:[~] $ cat simple_complex.i
# 1 simple_complex.c
# 1 built-in
# 1 command-line
# 1 simple_complex.c
# 1 /usr/include/stdio.h 1 3 4
# 20 /usr/include/stdio.h 3 4
#pragma ident @(#)stdio.h 1.8404/09/28 SMI
# 1
/usr/local/gcc-4.4.1-sun-linker/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.1/include-fixed/sys/feature_tests.h
1 3 4
# 18
[Bug tree-optimization/39251] FAIL: g++.dg/tree-ssa/new1.C scan-tree-dump-not forwprop1 = .* \+ -
--- Comment #9 from ramana at gcc dot gnu dot org 2010-01-15 09:05 --- (In reply to comment #8) Hi Mark, Many thanks for looking into this. However, if this is behaving different on ARM from (say) x86, I think that the ABI is a likely cause because, as you say, the C++ ABI for these bits is subtly different. Do we know that this is ARM-specific? I've compared this with the mips port and the x86 port and in both cases the first bit where there is a difference is after lowering into gimple - i.e there is no address calculation like this sequence that comes in the ARM port. D.1844_3 = (unsigned int *) D.1824_2; D.1845_4 = D.1844_3 + 4; D.1846_5 = D.1845_4 + -4; So yes it does look ARM specific . Also peeking at results on gcc-testresults doesn't show this failure on x86. cheers Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.5.0 |4.4.2 4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39251
[Bug c/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #1 from david dot kirkby at onetel dot net 2010-01-15 09:18 --- Created an attachment (id=19604) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19604action=view) C source code that generates error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug c/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #2 from david dot kirkby at onetel dot net 2010-01-15 09:19 --- Created an attachment (id=19605) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19605action=view) Preprocessed header -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug c/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #3 from david dot kirkby at onetel dot net 2010-01-15 09:27 --- I discovered the bug first on a Sun Blade 2000 running Solaris 10 while building the Sage maths software. http://www.sagemath.org/ A test case was created by Robert Bradshaw. The attached header file was generated on a Sun T5240. If necessary, access can be arranged for a serious developer to the system, but it has failed on every Solaris system tested on, including Open Solaris x86 systems, so I assume you will be able to verify it easily. But if not, I can create an account on the T5240. -- david dot kirkby at onetel dot net changed: What|Removed |Added CC||david dot kirkby at onetel ||dot net Known to fail||3.4.3 4.4.1 Summary|_Complex_I is reported as |_Complex_I is reported as |undeclared. Code builds with|undeclared. Code builds with |Sun compiler. |Sun compiler. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug middle-end/42248] [4.5 Regression] compat test struct-by-value-17 fails execution with -O1 -fschedule-insns
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-01-15 09:41 --- Created an attachment (id=19606) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19606action=view) fixed patch Ah, obvious oversight - I forgot to replace the realpart parameter in the vector of parameters. Can you check the updated patch? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Attachment #19597|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42248
[Bug c/42754] New: ICE on building libgcc.c __mulvdi3.
I got ICE when building m68k-elf on OSX10.6.2. Sources are got via official git repository. I'll attach the preprocessed sources soon. - - - - /Users/monaka/git/sourceforge.jp/pf3gnuchains4x/mpkg-darwin/m68k-elf/build/i386/./gcc/xgcc -B/Users/monaka/git/sourceforge.jp/pf3gnuchains4x/mpkg-darwin/m68k-elf/build/i386/./gcc/ -nostdinc -B/Users/monaka/git/sourceforge.jp/pf3gnuchains4x/mpkg-darwin/m68k-elf/build/i386/m68k-elf/newlib/ -isystem /Users/monaka/git/sourceforge.jp/pf3gnuchains4x/mpkg-darwin/m68k-elf/build/i386/m68k-elf/newlib/targ-include -isystem /Users/monaka/git/sourceforge.jp/pf3gnuchains4x/newlib/libc/include -B/Users/monaka/git/sourceforge.jp/pf3gnuchains4x/mpkg-darwin/m68k-elf/build/i386/m68k-elf/libgloss/m68k -L/Users/monaka/git/sourceforge.jp/pf3gnuchains4x/mpkg-darwin/m68k-elf/build/i386/m68k-elf/libgloss/libnosys -L/Users/monaka/git/sourceforge.jp/pf3gnuchains4x/libgloss/m68k -B/pizza/m68k-elf/bin/ -B/pizza/m68k-elf/lib/ -isystem /pizza/m68k-elf/include -isystem /pizza/m68k-elf/sys-include -L/Users/monaka/git/sourceforge.jp/pf3gnuchains4x/mpkg-darwin/m68k-elf/build/i386/./ld -g -O2 -mcpu=51qe -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../../../../libgcc -I../../../../../../../libgcc/. -I../../../../../../../libgcc/../gcc -I../../../../../../../libgcc/../include -DHAVE_CC_TLS -o _mulvdi3.o -MT _mulvdi3.o -MD -MP -MF _mulvdi3.dep -DL_mulvdi3 -c ../../../../../../../libgcc/../gcc/libgcc2.c \ ../../../../../../../libgcc/../gcc/libgcc2.c: In function e__mulvdi3f: ../../../../../../../libgcc/../gcc/libgcc2.c:400:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. -- Summary: ICE on building libgcc.c __mulvdi3. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: monaka at monami-software dot com GCC host triplet: i386-apple-darwin10.2.0 GCC target triplet: m68k-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42754
[Bug other/38768] -fschedule-insns documentation is wrong for x86 and some other targets
--- Comment #7 from rguenther at suse dot de 2010-01-15 09:46 --- Subject: Re: -fschedule-insns documentation is wrong for x86 and some other targets On Thu, 14 Jan 2010, reza dot yazdani at amd dot com wrote: --- Comment #5 from reza dot yazdani at amd dot com 2010-01-14 22:12 --- Confirmed. Also note -fschedule-insns is basically broken for x86 anyways. Do you have a list of bug reports where -fschedule-insns is broken on x86? We tried to compile all the SPEC 2006 with this option and there are no errors in there. 24319, 38403, 42295, etc. (that's from a -fschedule-insns search) or walk through http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstrshort_desc=known_to_fail_type=allwordssubstrknown_to_work_type=allwordssubstrlong_desc_type=substringlong_desc=unable+to+find+a+register+to+spillbug_file_loc_type=allwordssubstrbug_file_loc=gcchost_type=allwordssubstrgcchost=gcctarget_type=allwordssubstrgcctarget=gccbuild_type=allwordssubstrgccbuild=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=SUSPENDEDbug_status=WAITINGbug_status=REOPENEDemailassigned_to1=1emailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0= basically the issue is increasing register pressure and failure to do register allocation after that. In 4.5 -fsched-pressure might fix some of them. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38768
[Bug c/42754] ICE on building libgcc.c __mulvdi3.
--- Comment #1 from monaka at monami-software dot com 2010-01-15 09:47 --- Created an attachment (id=19607) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19607action=view) Preprocessed source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42754
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-15 09:56:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr
--- Comment #16 from david dot kirkby at onetel dot net 2010-01-15 09:59 --- Subject: Re: gcc fails to build on Solaris x86 - it forgets the locations of libmpfr BlanchardJ at ieee dot org wrote: --- Comment #15 from BlanchardJ at ieee dot org 2010-01-15 05:12 --- (In reply to comment #14) (In reply to comment #10) In reply to #9: I have tried to build gcc with and without my own patch on our solaris machines. While both of them fails they fail at the same place (namely configuration of [arch]/libgcc trying to figure out the object suffix). They It would be good if a patch similar to yours will work, so alloing gcc to be installed in an arbitrary location and used without setting LD_LIBRARY_PATH. The fact is, a lot of people using Solaris do not have root access, so using crle is not an option. It should be noted, gcc binaries from Blastwave install in a non standard location (/opt/csw) and do run without the user having to set LD_LIBRARY_PATH. Of course, you need root acces to install them, but they do *not* modify the linker search path with crle, but work without doing that. Despite asking a couple of times, I've never managed to get an answer how the Blastwave binaries achieve this. I'd like a pound (I'm English) for every time I have seen this issue raised on Solaris forums. It is something wanted by many, but I believe the gcc developers do not feel is necessary. Some have told be /usr/local is a standard though it's not a standard reconised by any official body, like ISO, IEEE etc. But normal users cant write there either. PS, you could always ask your uni system admins if they would set you up in a Solaris 10 zone. The memory overhead of a zone is quite small (well under 100 MB) and if in a zone, they could give you root access. Dave We modify the runpaths of the final binaries to achieve this results. It is done the same way with nearly all of our packages. There is a few way of doing this but the most reliable one is as follow : Define the LD_OPTIONS env variable before building gcc and use it to add the correct runtime path. for example a typical blastwave build would have at a minimum : export LD_OPTIONS='-R/opt/csw/lib' In this case the final shared libraries will contain runtime search paths to find stuff in /opt/csw/lib. Now there is a catch though if you want to build a multilib gcc for the gcc build you should use : export LD_OPTIONS='-R/opt/csw/lib/$ISALIST' In this case the libraries will be able to search for 64 or 32 bit libs accordingly. Hope this help, Jonathan Blanchard Yes, thank you. That is helpful. How do you produce the $ISALIST? Is that simply sparcv9 on a modern SPARC and amd64 on an Open Solaris system, or is it a list. If the latter, how do you every it. drkir...@hawk:~$ isalist amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86 Do I need xport LD_OPTIONS='-R/opt/csw/lib/amd64 -R opt/csw/lib/pentium_pro+mmx etc ? I doubt it, but I'm not sure what you mean there. Is it just this, or anything else I need to do? You say typical blastwave build would have at a minimum .. but I doubt you would consider gcc a typical blastwave build If there are further complications, can you let me know what they are. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481
[Bug c/42755] New: Using _Complex_I on Open Solaris fails to build an executable
I reported this bug against a SPARC system at #42753, but as this is a different version of gcc, on a different operating system with a different processor, I thought it wise to create another ticket. The hardware is a Sun Ultra 27, with a 3.33 GHz Xeon processor. The attached code builds and runs as expected using the Sun Studio 12.1 compiler. drkir...@hawk:~$ /opt/sunstudio12.1/bin/cc -V simple_complex.c cc: Sun C 5.10 SunOS_i386 2009/06/03 acomp: Sun C 5.10 SunOS_i386 2009/06/03 ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1652 drkir...@hawk:~$ ./a.out CYTHON_CCOMPLEX 1 However, it fails with gcc 4.3.4 drkir...@hawk:~$ /usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/bin/gcc -std=c99 -v -save-temps simple_complex.c Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc-4.3.4/configure --prefix=/usr/local/gcc-4.3.4-GNU-assembler-Sun-linker --with-as=/usr/local/binutils-2.20/bin/as --with-ld=/usr/ccs/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.3.4 (GCC) COLLECT_GCC_OPTIONS='-std=c99' '-v' '-save-temps' '-mtune=generic' /usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/libexec/gcc/i386-pc-solaris2.11/4.3.4/cc1 -E -quiet -v simple_complex.c -mtune=generic -std=c99 -fpch-preprocess -o simple_complex.i ignoring nonexistent directory /usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/lib/gcc/i386-pc-solaris2.11/4.3.4/../../../../i386-pc-solaris2.11/include #include ... search starts here: #include ... search starts here: /usr/local/include /usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/include /usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/lib/gcc/i386-pc-solaris2.11/4.3.4/include /usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/lib/gcc/i386-pc-solaris2.11/4.3.4/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-std=c99' '-v' '-save-temps' '-mtune=generic' /usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/libexec/gcc/i386-pc-solaris2.11/4.3.4/cc1 -fpreprocessed simple_complex.i -quiet -dumpbase simple_complex.c -mtune=generic -auxbase simple_complex -std=c99 -version -o simple_complex.s GNU C (GCC) version 4.3.4 (i386-pc-solaris2.11) compiled by GNU C version 4.3.4, GMP version 4.3.1, MPFR version 2.4.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: aa8da34c6527631409af75a63ef2 simple_complex.c: In function __pyx_t_double_complex_from_parts: simple_complex.c:20: error: _Complex_I undeclared (first use in this function) simple_complex.c:20: error: (Each undeclared identifier is reported only once simple_complex.c:20: error: for each function it appears in.) -- Summary: Using _Complex_I on Open Solaris fails to build an executable Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: david dot kirkby at onetel dot net GCC build triplet: SunOS hawk 5.11 snv_111b i86pc i386 i86pc GCC host triplet: SunOS hawk 5.11 snv_111b i86pc i386 i86pc GCC target triplet: SunOS hawk 5.11 snv_111b i86pc i386 i86pc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42755
[Bug middle-end/42749] -O2 and verify_stmts failed agane
--- Comment #3 from dcb314 at hotmail dot com 2010-01-15 10:26 --- (In reply to comment #2) It works for me with 4.5.0 20100114 (experimental) [trunk revision 155925] on Linux/x86-64. I upgraded to the latest snapshot (20010114), trunk revision 155915 and it still seems broken to me. Either one of the ten revisions fixed it, or somethings gone wrong for me locally. I'll try a raw build of 20010114 and report back. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
[Bug c/42755] Using _Complex_I on Open Solaris fails to build an executable
--- Comment #1 from david dot kirkby at onetel dot net 2010-01-15 10:30 --- Created an attachment (id=19608) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19608action=view) simple_complex.c C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42755
[Bug middle-end/42749] -O2 and verify_stmts failed agane
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-15 10:30 --- Confirmed. Reducing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-15 10:30:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
[Bug c/42755] Using _Complex_I on Open Solaris fails to build an executable
--- Comment #2 from david dot kirkby at onetel dot net 2010-01-15 10:31 --- Created an attachment (id=19609) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19609action=view) Preprocessed header -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42755
[Bug middle-end/42749] [4.5 Regression] -O2 and verify_stmts failed agane
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-15 10:42 ---
struct pdf_object { int val; };
int pdf_count_size_object (struct pdf_object * p_obj)
{
return pdf_count_size_object(p_obj) + 2 * sizeof(struct pdf_object);
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-checking, ice-on-valid-
||code
Summary|-O2 and verify_stmts failed |[4.5 Regression] -O2 and
|agane |verify_stmts failed agane
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
[Bug lto/42690] Undefined reference errors with -flto -fuse-linker-plugin
--- Comment #7 from d dot g dot gorbachev at gmail dot com 2010-01-15 11:01 --- Created an attachment (id=19610) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19610action=view) 1. Configured w/o --disable-shared, linking with a shared libgcc. Output of gcc -v -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690
[Bug lto/42690] Undefined reference errors with -flto -fuse-linker-plugin
--- Comment #10 from d dot g dot gorbachev at gmail dot com 2010-01-15 11:02 --- Created an attachment (id=19613) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19613action=view) 4. Configured with --disable-shared, linking with a static libgcc (with -static). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690
[Bug driver/42690] Undefined reference errors with -flto -fuse-linker-plugin
--- Comment #11 from d dot g dot gorbachev at gmail dot com 2010-01-15 11:03 --- GCC was configured with --disable-shared option. It seems that the driver does not understand that --disable-shared implies static libgcc -- d dot g dot gorbachev at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Component|lto |driver Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690
[Bug other/42756] New: Build fails if gold is used as linker and some libraries reside is /usr/local/lib
I have PPL and CLooG installed in /usr/local/lib. The configure script finds these two libraries and generates makefiles that link with them simply by adding -lppl_c -lppl -lcloog. For example, i686-slackware-linux-gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o i386-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o \ dummy-checksum.o main.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lcloog -lppl_c -lppl -lgmpxx -L/home/artem/testing/gcc-build/./gmp/.libs -L/home/artem/testing/gcc-build/./mpfr/.libs -lmpc -lmpfr -lgmp -rdynamic -ldl -lz -lelf This works well when GNU ld is used, because it can be taught to look for libraries in /usr/local/bin by editing /etc/ld.so.conf. However, GNU gold doesn't have such an option and requires that all library paths be passed in the command line explicitly (at least a brief look at options.cc shows no other way to specify additional library paths). The program can be partially resolved by saying LDFLAGS=-L/usr/local/lib ../gcc/configure .., which makes stage1 compiler to build successfully. However, building stage2 compiler fails because -L/usr/local/lib does not get added to the command line during compilation of stage2. I used the following options to configure GCC: ../gcc/configure --prefix=/usr/local/gcc-current --libdir=/usr/local/gcc-current/lib --enable-shared --enable-bootstrap --enable-languages=c,c++ --enable-threads=posix --enable-checking=release --with-system-zlib --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --enable-gold --enable-lto --verbose --with-arch=i686 --target=i686-slackware-linux --build=i686-slackware-linux --host=i686-slackware-linux -- Summary: Build fails if gold is used as linker and some libraries reside is /usr/local/lib Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aanisimov at inbox dot ru GCC build triplet: i686-slackware-linux GCC host triplet: i686-slackware-linux GCC target triplet: i686-slackware-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42756
[Bug c++/42634] ICE with -g -O2 -std=c++0x in copy_fn_p, at cp/decl.c:9973
--- Comment #8 from dodji at gcc dot gnu dot org 2010-01-15 11:23 --- Subject: Bug 42634 Author: dodji Date: Fri Jan 15 11:23:29 2010 New Revision: 155936 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155936 Log: Revert commit of PR c++/42634, which was commit r155868 Removed: trunk/gcc/testsuite/g++.dg/template/error45.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42634
[Bug c++/42634] ICE with -g -O2 -std=c++0x in copy_fn_p, at cp/decl.c:9973
--- Comment #9 from dodji at gcc dot gnu dot org 2010-01-15 11:29 --- Re-opening, as the fix was reverted. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42634
[Bug c++/42740] [4.5 Regression] Many libstdc++ failures
--- Comment #2 from dodji at gcc dot gnu dot org 2010-01-15 11:30 --- The culprit commit was reverted so I think this should be fixed. -- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-15 11:30:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42740
[Bug target/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #4 from jsm28 at gcc dot gnu dot org 2010-01-15 11:49 --- This is a fixincludes bug; it needs to fix Sun's complex.h header to work with GCC. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Component|c |target GCC build triplet|Sun SPARC Enterprise T5240 | |Server running Solaris 10 | |05/2009 | GCC host triplet|Sun SPARC Enterprise T5240 | |Server running Solaris 10 | |05/2009 | GCC target triplet|Sun SPARC Enterprise T5240 |*-*-solaris* |Server running Solaris 10 | |05/2009 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug c/42755] Using _Complex_I on Open Solaris fails to build an executable
--- Comment #3 from jsm28 at gcc dot gnu dot org 2010-01-15 11:51 --- *** This bug has been marked as a duplicate of 42753 *** -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42755
[Bug target/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #5 from jsm28 at gcc dot gnu dot org 2010-01-15 11:51 --- *** Bug 42755 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug target/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #6 from jsm28 at gcc dot gnu dot org 2010-01-15 11:52 --- For reference of people without Solaris headers to hand, the code needing fixing by fixincludes is: /* * Compilation environments for Solaris must provide the _Imaginary datatype * and the compiler intrinsics _Complex_I and _Imaginary_I */ #define _Complex_I _Complex_I #define complex _Complex #define _Imaginary_I_Imaginary_I #define imaginary _Imaginary #undef I #define I _Imaginary_I Note there are some TABs there in the original header. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug middle-end/42739] [4.5 Regression] ICE with computed goto, destructors, and optimization
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-15 11:53 --- Subject: Bug 42739 Author: rguenth Date: Fri Jan 15 11:53:26 2010 New Revision: 155937 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155937 Log: 2010-01-15 Richard Guenther rguent...@suse.de PR middle-end/42739 * tree-cfgcleanup.c (remove_forwarder_block): Move destination labels of computed or non-local gotos to the destination. * tree-cfg.c (gimple_verify_flow_info): Verify that a EH landing pad label is the first label. * g++.dg/torture/pr42739.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr42739.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-cfgcleanup.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42739
[Bug middle-end/42739] [4.5 Regression] ICE with computed goto, destructors, and optimization
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-15 11:53 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42739
[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr
--- Comment #17 from BlanchardJ at ieee dot org 2010-01-15 12:37 --- Yes, thank you. That is helpful. How do you produce the $ISALIST? Is that simply sparcv9 on a modern SPARC and amd64 on an Open Solaris system, or is it a list. If the latter, how do you every it. drkir...@hawk:~$ isalist amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86 Do I need xport LD_OPTIONS='-R/opt/csw/lib/amd64 -R opt/csw/lib/pentium_pro+mmx etc ? I doubt it, but I'm not sure what you mean there. Is it just this, or anything else I need to do? You say typical blastwave build would have at a minimum .. but I doubt you would consider gcc a typical blastwave build If there are further complications, can you let me know what they are. Dave Hi, It's just the string '$ISALIST' so it will appear as-is in the final run path. The runtime linker will take care of expanding it correctly at runtime. So one just export LD_OPTIONS as-is before building. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481
[Bug fortran/42723] Bootstrapping Fortran with GCC 4.4.2 fails on Solaris 5.10: f951: internal compiler error: Arithmetic Exception
--- Comment #5 from Roger dot Jeurninck at home dot nl 2010-01-15 12:47 --- I got GCC bootstrapped now! Instead of building the GMP and MPFR sources together with GCC I did a build of them in advice. Next I configured the GCC with the --with-gmp and --with-mpfr options (see below) and could successfully build GCC. Not sure why the first approach did fail because the MPFR and GMP code was indeed nicely build with the GCC compiler... Testresults are ok and almost match those of Rainer (http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01181.html). I will still look into the differences here. For now this issue can be closed/postponed as I have a workaround. thanks for your help! Roger (the configure options I used, note that the LD_LIBRARY_PATH needs to find the libs too) --- --prefix=../install \ --enable-languages=c,fortran,c++ \ --with-gmp-lib=/scratch/rjeurnin/gmp/gmp-4.3.2/install/lib \ --with-gmp-include=/scratch/rjeurnin/gmp/gmp-4.3.2/install/include \ --with-mpfr-lib=/scratch/rjeurnin/mpfr/mpfr-2.4.2/install/lib \ --with-mpfr-include=/scratch/rjeurnin/mpfr/mpfr-2.4.2/install/include \ --verbose -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42723
[Bug fortran/42723] Bootstrapping Fortran with GCC 4.4.2 fails on Solaris 5.10: f951: internal compiler error: Arithmetic Exception
--- Comment #6 from burnus at gcc dot gnu dot org 2010-01-15 12:53 --- (In reply to comment #5) I got GCC bootstrapped now! Instead of building the GMP and MPFR sources together with GCC I did a build of them in advice. Next I configured the GCC with the --with-gmp and --with-mpfr options (see below) and could successfully build GCC. Not sure why the first approach did fail because the MPFR and GMP code was indeed nicely build with the GCC compiler... Could it be that then the LD_LIBRARY_PATH was not correctly set and a different GMP/MPFR has been picked up? For now this issue can be closed/postponed as I have a workaround. thanks for your help! OK, close as WORKSFORME - if you find something, which should be fixed, feel free to re-open the PR or fill a new one. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42723
[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr
--- Comment #18 from david dot kirkby at onetel dot net 2010-01-15 13:15 --- Subject: Re: gcc fails to build on Solaris x86 - it forgets the locations of libmpfr BlanchardJ at ieee dot org wrote: --- Comment #17 from BlanchardJ at ieee dot org 2010-01-15 12:37 --- Yes, thank you. That is helpful. How do you produce the $ISALIST? Is that simply sparcv9 on a modern SPARC and amd64 on an Open Solaris system, or is it a list. If the latter, how do you every it. drkir...@hawk:~$ isalist amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86 Do I need xport LD_OPTIONS='-R/opt/csw/lib/amd64 -R opt/csw/lib/pentium_pro+mmx etc ? I doubt it, but I'm not sure what you mean there. Is it just this, or anything else I need to do? You say typical blastwave build would have at a minimum .. but I doubt you would consider gcc a typical blastwave build If there are further complications, can you let me know what they are. Dave Hi, It's just the string '$ISALIST' so it will appear as-is in the final run path. The runtime linker will take care of expanding it correctly at runtime. So one just export LD_OPTIONS as-is before building. Thank you. That's very helpful. I really hate having to set LD_LIBRARY_PATH - it is particularly an issue if you have multiple compilers. There's alyways the chance it gets set to the wrong compiler by mistake. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481
[Bug lto/42757] New: lto1 does not emit common symbols
GCC 4.5.0 20100114. -- Summary: lto1 does not emit common symbols Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: d dot g dot gorbachev at gmail dot com 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=42757
[Bug lto/42757] lto1 does not emit common symbols
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-01-15 13:34 --- Created an attachment (id=19614) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19614action=view) Testcase It produces error: undefined reference to 'i' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42757
[Bug lto/42757] lto1 does not emit common symbols with -fuse-linker-plugin
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-15 13:37 --- Works when linking in comm.o main.o order. I guess the linker resolution handling is bogus. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-15 13:37:53 date|| Summary|lto1 does not emit common |lto1 does not emit common |symbols |symbols with -fuse-linker- ||plugin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42757
[Bug c++/42758] New: ICE on assert() in function with complex(?) template argument
The following code compiles fine with g++-4.4 and causes g++-4.5 to segfault.
Removing the assert() or removing the int_less_than parameter no longer lead
to a segfault.
% g++-4.5 --version
g++-4.5 (Debian 4.5-20091226-1) 4.5.0 20091226 (experimental) [trunk revision
155473]
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
% cat bug.cc
#include cassert
#include set
namespace spot
{
struct int_less_than
{
bool operator()(int, int) const { return 0; }
};
int f(const std::setint, int_less_than)
{
assert(0);
return 1;
}
}
% g++-4.4 -c bug.cc# 4.4 runs OK
% g++-4.5 -c bug.cc
g++-4.5: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See file:///usr/share/doc/gcc-4.5/README.Bugs for instructions.
--
Summary: ICE on assert() in function with complex(?) template
argument
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adl at gnu dot org
GCC build triplet: i686-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42758
[Bug c++/42758] ICE on assert() in function with complex(?) template argument
--- Comment #1 from adl at gnu dot org 2010-01-15 13:40 --- Created an attachment (id=19615) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19615action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42758
[Bug c++/42758] ICE on assert() in function with complex(?) template argument
--- Comment #2 from paolo dot carlini at oracle dot com 2010-01-15 14:06 --- This is just crazy, inside the debugger works fine. Outside -fsyntax-only is enough, -E is not. Richard any idea what the heck is going on? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42758
[Bug c++/42740] [4.5 Regression] Many libstdc++ failures
--- Comment #3 from paolo dot carlini at oracle dot com 2010-01-15 14:24 --- Yes, it can, thanks again for the quick turnaround. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42740
[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier
--- Comment #16 from singler at kit dot edu 2010-01-15 14:29 --- First, let's remove superfluous #pragma omp single in two occurences, to make things simpler (see attached patch for trunk). The problem still persists, the program deadlocks. When dropping in some prints (see attached patch), the log ends like this: find going parallel, requesting 2 thread thread 0 of 2 starts thread 0 finished thread 1 of 2 starts thread 1 finished successful join find going parallel, requesting 2 thread thread 0 of 2 starts thread 0 finished Analysis: Thread 1 never starts (or at least does not reach the first printf). In general, for more threads, only thread 0 starts. This obviously leads to the deadlock. So on first sight, I would blame it on the OpenMP implementation. Maybe yet some interference with the pthreads. Any other explanations? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier
--- Comment #17 from singler at kit dot edu 2010-01-15 14:30 --- Created an attachment (id=19616) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19616action=view) Removes superfluous pragma omp single twice -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier
--- Comment #18 from singler at kit dot edu 2010-01-15 14:30 --- Created an attachment (id=19617) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19617action=view) Add printf debug statements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
[Bug lto/42757] lto1 does not emit common symbols with -fuse-linker-plugin
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-15 14:34 --- I see 2 main.o 2 78 PREVAILING_DEF main 81 RESOLVED_IR i comm.o 1 78 RESOLVED_IR i which is obviously bogus for comm.o. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42757
[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier
--- Comment #19 from paolo dot carlini at oracle dot com 2010-01-15 14:35 --- Let's add Jakub in CC, he knows the implementation very well. In case, please keep also in touch privately. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
[Bug other/42756] Build fails if gold is used as linker and some libraries reside is /usr/local/lib
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-01-15 14:45 --- Try to set LIBRARY_PATH, i.e.: export LIBRARY_PATH=/usr/local/lib -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42756
[Bug other/42756] Build fails if gold is used as linker and some libraries reside is /usr/local/lib
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2010-01-15 14:57 --- Well, and LD_LIBRARY_PATH=/usr/local/lib , too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42756
[Bug c++/42758] ICE on assert() in function with complex(?) template argument
--- Comment #3 from matz at gcc dot gnu dot org 2010-01-15 15:06 --- input_location handling is broken. (gdb) bt #0 0x7704a7c3 in strcmp () from /lib64/libc.so.6 #1 0x011be858 in splay_tree_splay (sp=0x1824110, key=0) at ../../gcc/libiberty/splay-tree.c:148 #2 0x011beed6 in splay_tree_lookup (sp=0x1824110, key=0) at ../../gcc/libiberty/splay-tree.c:389 #3 0x007b162a in get_fileinfo (name=0x0) at ../../gcc/gcc/c-lex.c:114 note: name==0, this comes from: #25 0x00765939 in fname_as_string (pretty_p=1) at ../../gcc/gcc/c-common.c:950 #26 0x004e0b3a in cp_make_fname_decl (loc=1708071, id=0x77e91ec8, type_dep=1) at ../../gcc/gcc/cp/decl.c:3559 #27 0x00765a7a in fname_decl (loc=1708071, rid=67, id=0x77e91ec8) at ../../gcc/gcc/c-common.c:999 Where the block in c-common.c is: 995 location_t saved_location = input_location; 996 input_location = UNKNOWN_LOCATION; 997 998 stmts = push_stmt_list (); 999 decl = (*make_fname_decl) (loc, id, fname_vars[ix].pretty); I.e. input_location is reset (that is okay here), then through the make_fname_decl call the c++ frontend is called back, which tries to construct a decl, implicitely (via cxx_make_type) accessing the fileinfo for input_filename. We want to create the __PRETTY_FUNCTION__ string decl here. I can't say if it's more sensible if the C++ frontend would deal with input_location==UNKNOWN_LOCATION sometimes, or if c-common.c should be changed to not reset it temporarily. But the latter really makes sense here, as the __PRETTY_FUNCTION__ decl is created on demand, i.e. a random place, which it then would get. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42758
[Bug tree-optimization/39251] FAIL: g++.dg/tree-ssa/new1.C scan-tree-dump-not forwprop1 = .* \+ -
--- Comment #10 from mark at codesourcery dot com 2010-01-15 15:05 --- Subject: Re: FAIL: g++.dg/tree-ssa/new1.C scan-tree-dump-not forwprop1 = .* \+ - ramana at gcc dot gnu dot org wrote: So yes it does look ARM specific . Also peeking at results on gcc-testresults doesn't show this failure on x86. Thanks for looking at that. I will investigate this bug, but it might not be until week after next, as I will be out of the office this coming week. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39251
[Bug c++/42758] [4.5 Regression] ICE on assert() in function with complex(?) template argument
--- Comment #4 from paolo dot carlini at oracle dot com 2010-01-15 15:18 --- Thanks Michael. It's a serious regression, isn't it? -- paolo dot carlini at oracle dot com changed: What|Removed |Added Summary|ICE on assert() in function |[4.5 Regression] ICE on |with complex(?) template|assert() in function with |argument|complex(?) template argument http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42758
[Bug other/38768] -fschedule-insns documentation is wrong for x86 and some other targets
--- Comment #8 from reza dot yazdani at amd dot com 2010-01-15 15:19 --- We used -O2 -fsched-pressure -fschedule-insns to build the cpu2006 bmks on an amd64-linux machine. Thanks for the list of bugs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38768
[Bug c++/42758] [4.5 Regression] ICE on assert() in function with complex(?) template argument
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42758
[Bug driver/42690] Undefined reference errors with -flto -fuse-linker-plugin
--- Comment #12 from espindola at gcc dot gnu dot org 2010-01-15 15:28
---
(In reply to comment #11)
GCC was configured with --disable-shared option. It seems that the driver does
not understand that --disable-shared implies static libgcc
That is correct. Currently we have
%{static|static-libgcc:-plugin-opt=-pass-through=%(lto_libgcc)} \
%{static:-plugin-opt=-pass-through=-lc} \
That is, --pass-through is only used for libgcc if -static or -static-libgcc is
given. For libgcc we could probably find out if we are using a static one or
not in a more accurate way.
For libc it is harder. The driver doesn't know that libc is static. It just
passes -lc to ld.
It might be possible to change what we test for. I think it would be OK to
always ask the plugin to pass libgcc and libc to the linker a second time *if
they are being used at all*. My understanding is that an unnecessary static
library will be ignored and a shared library will have no effect since it was
already used anyway.
To implement this we should always pass -plugin-opt=-pass-through=%(lto_libgcc)
and -plugin-opt=-pass-through=-lc to the linker unless something like -nostdlib
is used.
What options other than -nostdlib prevent gcc from linking libgcc and libc in
the produced binary?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690
[Bug libfortran/42742] [4.5 Regression] SIGSEGV at libgfortran/io/format.c:111
--- Comment #8 from burnus at gcc dot gnu dot org 2010-01-15 15:40 --- Submitted: Patch by Jerry: http://gcc.gnu.org/ml/fortran/2010-01/msg00091.html It avoids the excessive use of memory that results from the parsed format node tree, probably exceeding available stack or heap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
[Bug c/42759] New: libgcc fails to compile with segmentation fault
In MSYS environment I try to build m68k cross compiler. Both gcc-3.4.5 and gcc-4.4.0 were used The command /opt/gcc-build/./gcc/xgcc -B/opt/gcc-build/./gcc/ -B/usr/local/m68k-elf/bin/ -B/usr/local/m68k-elf/lib/ -isystem /usr/local/m68k-elf/include -isystem /usr/local/m68k-elf/sys-include -g -O2 -mcpu=51qe -Wa,-mno-mac -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../gcc_4_4_2_release/libgcc -I../../../../gcc_4_4_2_release/libgcc/. -I../../../../gcc_4_4_2_release/libgcc/../gcc -I../../../../gcc_4_4_2_release/libgcc/../include -DHAVE_CC_TLS -o _popcountdi2.o -MT _popcountdi2.o -MD -MP -MF _popcountdi2.dep -DL_popcountdi2 -c ../../../../gcc_4_4_2_release/libgcc/../gcc/libgcc2.c -save-temps caused ../../../../gcc_4_4_2_release/libgcc/../gcc/libgcc2.c: In function '__popcountdi2': ../../../../gcc_4_4_2_release/libgcc/../gcc/libgcc2.c:809: internal compiler error: Segmentation fault -- Summary: libgcc fails to compile with segmentation fault Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: onlite at gmail dot com GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: m68k-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42759
[Bug c/42759] libgcc fails to compile with segmentation fault
--- Comment #1 from onlite at gmail dot com 2010-01-15 15:45 --- Created an attachment (id=19618) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19618action=view) the preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42759
[Bug middle-end/42760] New: [4.4 Regression] ICE in convert_move
// { dg-do compile }
// { dg-options -O2 }
template typename T
struct A
{
static T b (T it) { return it; }
};
template typename T, typename U
static U
baz (T x, T y, U z)
{
for (long n = y - x; n 0; --n)
{
*z = *x;
++z;
}
};
template typename T, typename U
U
bar (T x, T y, U z)
{
baz (A T::b (x), A T::b (y), A U::b (z));
}
struct C
{
__complex__ float v;
};
template class T
struct B
{
B (T y[]) { bar (y, y + 1, x); }
operator T *() { return x; }
T x[1];
};
B C
foo ()
{
C y[1];
return B C (y);
};
ICEs in convert_move on x86_64. Works with 4.3 or 4.5.
--
Summary: [4.4 Regression] ICE in convert_move
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42760
[Bug libfortran/42742] [4.5 Regression] SIGSEGV at libgfortran/io/format.c:111
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-01-15 15:58 --- SendingChangeLog Sendingio/format.c Transmitting file data .. Committed revision 155939. This will be back ported to 4.4.4 in a few days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
[Bug c/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #7 from david dot kirkby at onetel dot net 2010-01-15 16:02 --- (In reply to comment #5) *** Bug 42755 has been marked as a duplicate of this bug. *** (In reply to comment #4) This is a fixincludes bug; it needs to fix Sun's complex.h header to work with GCC. I've read the fixincludes README, and http://autogen.SourceForge.net/fixinc.html Perhaps I'm thick, but I have great difficulty in understanding what I am supposed to do. Is this a bug in gcc, or just I've not installed gcc fully? The bug has not been marked as CONFIRMED or INVALID, so I'm unsure what you believe it is. If it's due to the fact I've mis-installed gcc, I would appreciate some clearer instructions about how to fix this problem. Those fixincludes instructions make very little sense to me. The same problem exists with the gcc included by Sun at /usr/sfw/bin/gcc (on SPARC) and also the gcc 4.3.4 build by Blastwave (a well known distributor of Solaris software) Does the fixincludes actually modify the Solaris header (in which case one would need root access)? Would including the above bit of code as another header file solve the problem? -- david dot kirkby at onetel dot net changed: What|Removed |Added Component|target |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug middle-end/42749] [4.5 Regression] -O2 and verify_stmts failed agane
--- Comment #6 from hjl dot tools at gmail dot com 2010-01-15 16:03 --- It is caused by revision 146831: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01473.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
[Bug tree-optimization/42717] [4.5 Regression] ice: verify_ssa failed
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-15 16:07 --- Testing sth else. -- 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|NEW |ASSIGNED Last reconfirmed|2010-01-13 13:16:16 |2010-01-15 16:07:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42717
[Bug lto/42675] lto1 rejects -fdump-core option of gfortran
--- Comment #2 from burnus at gcc dot gnu dot org 2010-01-15 16:08 --- (In reply to comment #1) Huh. lto1 should probably accept all frontend options but ignore most of them. Or lto-wrapper should strip them. I think the crucial part about the option is that it starts with -fdump-*; same result for -fdump-parse-tree while all other options seem to work. Grepping for fdump finds in *opt: common.opt:fdump- common.opt:fdump-final-insns= common.opt:fdump-noaddr common.opt:fdump-unnumbered common.opt:fdump-unnumbered-links fortran/lang.opt:fdump-core fortran/lang.opt:fdump-parse-tree -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42675
[Bug middle-end/42760] [4.4 Regression] ICE in convert_move
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42760
[Bug middle-end/42760] [4.4 Regression] ICE in convert_move
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-15 16:23 --- Trunk has if (COMPLEX_MODE_P (TYPE_MODE (TREE_TYPE (from instead of the 4.4 if (TREE_CODE (TREE_TYPE (from)) == COMPLEX_TYPE) Fixed by 2009-06-17 Steve Ellcey s...@cup.hp.com * expr.c (expand_assignment): Change complex type check. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42760
[Bug target/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #8 from jsm28 at gcc dot gnu dot org 2010-01-15 16:30 --- Fixincludes is part of the compiler sources, and it is the part that should work around GCC-incompatible system headers (such as this one) by making fixed copies when GCC is built and installed. Thus, a failure to fix it indicates a limitation in fixincludes, and the fix would be to enhance fixincludes and rebuild GCC. It is not part of the C front end, so c is not the correct component. Do not change components back if a maintainer changes them to be more accurate. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug other/42756] Build fails if gold is used as linker and some libraries reside is /usr/local/lib
--- Comment #3 from aanisimov at inbox dot ru 2010-01-15 16:32 --- (In reply to comment #1) Try to set LIBRARY_PATH, i.e.: export LIBRARY_PATH=/usr/local/lib This worked much better ;-) -- stage2 finished successfully, but building libstdc++ in stage3 failed with a bunch of /usr/bin/ld: error: unsupported symbol binding Trying to rerun the command to link libstdc++ with -Xlinker --debug=all to see what's going wrong gave no result, because the error message didn't change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42756
[Bug libgcj/39747] [4.4/4.5 Regression] Installation documentation should suggest building libgmp as PIC for building with libjava
--- Comment #6 from David dot Biesack at sas dot com 2010-01-15 16:45 --- I had this problem on a Linux x86_64 build, manifested with the error /usr/local/lib/libgmp.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42750 ) I'm adding that text here so that if someone else has that problem and searches for it, they can find this bug entry. How does one configure gmp to build correctly so that it can be used by gcc? I can't find any doc in the gmp configure/texinfo that describes how to do that. I ran configure for it and it says -fPIC works in the log, but it does not put -fPIC in the Makefile. I explicitly added it to the CFLAGS in my Makefile CFLAGS = -O2 -pedantic -m64 -mtune=k8 -fPIC and rebuilt it; make check work (in gmp). -- David dot Biesack at sas dot com changed: What|Removed |Added CC||David dot Biesack at sas dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39747
[Bug middle-end/42760] [4.4 Regression] ICE in convert_move
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-15 17:01 --- Indeed, that fixes it. Going to bootstrap/regtest it now on several arches, then commit before rolling 4.4.3-rc1. -- 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 |2010-01-15 17:01:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42760
[Bug libstdc++/42761] New: std::bind doesn't work for simple class types
Unfortunately, this very simple example, which we have been discussing for
other reasons, regresses very badly vs tr1. Unfortunately the C++ front-end
doesn't seem ready for a conforming result_of :( Can we prepare a reduced
testcase for Jason?
Maybe he can already tell us whether an error message of the form: sorry,
unimplemented: unable to determine the declared type of expression
declvalX()() points to an issue fixable any time soon...
Otherwise, I'm afraid that for 4.5.0 we have to revert consistently most C++0x
work in functional.
///
#include functional
struct X {
typedef int result_type;
int operator()() { return 0; }
int operator()() const { return 1; }
};
const auto b = std::bind(X());
b(); // b is const, so must return 1
--
Summary: std::bind doesn't work for simple class types
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paolo dot carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42761
[Bug libstdc++/42761] std::bind doesn't work for simple class types
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|normal |blocker Priority|P3 |P1 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42761
[Bug libstdc++/42761] std::bind doesn't work for simple class types
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-15 18:13:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42761
[Bug target/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #9 from david dot kirkby at onetel dot net 2010-01-15 18:25 --- (In reply to comment #8) Fixincludes is part of the compiler sources, and it is the part that should work around GCC-incompatible system headers (such as this one) by making fixed copies when GCC is built and installed. Thus, a failure to fix it indicates a limitation in fixincludes, and the fix would be to enhance fixincludes and rebuild GCC. It is not part of the C front end, so c is not the correct component. Do not change components back if a maintainer changes them to be more accurate. Is this is trivial fix that could be implemted quickly, or it will require quite a bit of work, and so I should not expect a solution soon? Is there any workaround you can suggest? Would simply adding #define _Complex_I _Complex_I #define complex _Complex #define _Imaginary_I_Imaginary_I #define imaginary _Imaginary #undef I #define I _Imaginary_I at the top of the source files work? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug fortran/38822] Compile-time simplification of x**(real)
--- Comment #16 from kargl at gcc dot gnu dot org 2010-01-15 18:31 --- Unassign myself as I have no time to work on gfortran. -- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|kargl 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=38822
[Bug target/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #10 from joseph at codesourcery dot com 2010-01-15 18:32 --- Subject: Re: _Complex_I is reported as undeclared. Code builds with Sun compiler. On Fri, 15 Jan 2010, david dot kirkby at onetel dot net wrote: Is this is trivial fix that could be implemted quickly, or it will require quite a bit of work, and so I should not expect a solution soon? It could be implemented quickly if someone familiar with fixincludes wishes to fix it. Is there any workaround you can suggest? Would simply adding #define _Complex_I _Complex_I #define complex _Complex #define _Imaginary_I_Imaginary_I #define imaginary _Imaginary #undef I #define I _Imaginary_I at the top of the source files work? Adding copies of the non-GCC definitions certainly won't work. I suppose you could add #undef of the problem macros followed by #define to values valid for GCC (such as those used by glibc), after including any system headers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug libstdc++/42761] std::bind doesn't work for simple class types
--- Comment #1 from jwakely dot gcc at gmail dot com 2010-01-15 18:34 --- OK, I'll revert it all tomorrow if necessary -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42761
[Bug lto/42762] New: ICE in get_resolution() when compiling a C++ program with -flto -fuse-linker-plugin
cat bug.cc
int main(void)
{
try { } catch (int) { }
return 0;
}
g++ -flto -fuse-linker-plugin bug.cc
lto1: internal compiler error: in get_resolution, at lto-streamer-in.c:1519
Please submit a full bug report,
with preprocessed source if appropriate.
GCC 4.5.0 20100114.
--
Summary: ICE in get_resolution() when compiling a C++ program
with -flto -fuse-linker-plugin
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot g dot gorbachev at gmail dot com
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=42762
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #12 from jingyu at gcc dot gnu dot org 2010-01-15 18:47 --- Subject: Bug 42691 Author: jingyu Date: Fri Jan 15 18:47:45 2010 New Revision: 155944 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155944 Log: 2010-01-15 Jing Yu jin...@google.com PR rtl-optimization/42691 * combine.c (try_combine): Set changed_i3_dest to 1 when I2 and I3 set a pseudo to a constant and are merged, and adjust comments. 2010-01-15 Jing Yu jin...@google.com PR rtl-optimization/42691 * gcc.c-torture/execute/pr42691.c: New. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr42691.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug c++/42758] [4.5 Regression] ICE on assert() in function with complex(?) template argument
--- Comment #5 from hjl dot tools at gmail dot com 2010-01-15 18:57 --- It is triggered by revision : http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00188.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-15 18:57:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42758
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #13 from jingyu at gcc dot gnu dot org 2010-01-15 19:09 --- Subject: Bug 42691 Author: jingyu Date: Fri Jan 15 19:08:53 2010 New Revision: 155945 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155945 Log: Backport from mainline(4.5) to fix a regression bug. 2010-01-15 Jing Yu jin...@google.com PR rtl-optimization/42691 * combine.c (try_combine): Set changed_i3_dest to 1 when I2 and I3 set a pseudo to a constant and are merged, and adjust comments. 2010-01-15 Jing Yu jin...@google.com PR rtl-optimization/42691 * gcc.c-torture/execute/pr42691.c: New. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr42691.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/combine.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug c++/42761] std::bind doesn't work for simple class types
-- 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|NEW |ASSIGNED Component|libstdc++ |c++ Last reconfirmed|2010-01-15 18:13:58 |2010-01-15 20:15:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42761
[Bug c++/42761] std::bind doesn't work for simple class types
--- Comment #2 from paolo dot carlini at oracle dot com 2010-01-15 20:25 --- Thanks Jason! If we manage to solve this tough problem, then I know how to enable also the volatile / const volatile call operators + other improvements bringing us real close to the WP. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42761
[Bug libfortran/42763] New: internal compiler error: in instantiate_virtual_regs_lossage ERROR 1
internal compiler error: in instantiate_virtual_regs_lossage, at function c:3476 The command line is simply a return at the end of a subroutine (line:561). It is followed by an end on the next line. c c c ** c pltlib ** c ** c c c the following collection of subroutines is designed c to aid in constructing graphic outputs from fortran c programs. these subroutines are designed to run on c a sun under openwindows and drive a postscript printer. c the user only needs to designate the destination device c in subroutine initpt--all other routines function as c nearly identically as possible on all devices. c c c ccopyright 1991,1992 by h. j. melosh. all rights reserved. c cthis code is provided by the author to designated users for cthe purpose of cooperative research. it may not be distributed cto other users without the express consent of the author. c cunder no circumstances is this code to be used for commercial cpurposes without the author's written consent. c c ***legal notice*** c c this code was written as part of the research of h. j. melosh and his c collaborators. none of these authors make any warranty, express or c implied, or assumes any legal liability or responsibility for the c accuracy, completeness or usefulness of this code or its results, c or represents that its use would not infringe privately owned rights. c c c c* c c the subroutines are self documenting--the user is advised c to study the comments in the fortran listing of each c routine. the routines that are availabe for the user are: c c plotxy--draws a complete x,y plot, either line or scatter c contur--draws a complete x,y,z contour plot c axis--draws a labeled axis c initpt--initializes the graphic device c legend--writes a label or ascii string on the plot c line--draws a continuous line between points c newpen--chooses a pen c number--writes a floating point number on the plot c offset--shifts the coordinate zero and scale c scale--scales an array in rational units. use as input c for axis or arbgrd c symbol--draws one of 16 symbols on the plot c arbgrd--draws a contour plot on an irregular grid: specialized for c finite element codes. c c written by h.j.melosh, july, 1985. modified for the mac ii c october, 1987. plot routines improved january, 1989 c contouring improved march 1992 c c adapted for the sun using pgplot by h. j. melosh, may 1992 c c subroutine plotxy(xl,xu,labelx,labely,xarray,yarray, npts,irep,isym) c c program to produce an x-y line or scatter plot of arrays (xarray) and c (yarray). the user specifies the coordinates (xl(1),xl(2)) c of the bottom left corner of the plot and coordinates (xu(1), c xu(2)) of the upper right corner. the axes are labeled, c respectively, 'labelx' and 'labely'. (npts) is the number of c points plotted. c c xarray and yarray are not altered by this routine. c c the switch irep has the following effects: c c irep=0: the coordinate axes are scaled to accomodate the full c range of xarray and yarray. the axes are plotted, c then the logical coordinates are shifted and scaled to c accomodate the arrays, which are then plotted. c scales are returned to their default values when the c plot is complete. this is the normal mode for a c single line or scatter plot. c c irep=1: same as irep=0 except that the scales are not returned c to their default values after plotting. this is the c normal mode for the first plot in a sequence of overlaid c plots. c c irep1: only the arrays are plotted, using a previously set c scale. this mode is used for the second and subsequent c plots in a sequence of overlaid plots. c c irep0: same as irep1, except that the scales are returned to c their default values after the plot is complete. used c to terminate a sequence of overlaid plots. c alternatively, the user may make a call to offset c with parameters offset(0.,0.,1.,1.) to perform this c function after the last plot with irep1. c c the zero axes are drawn as a dashed line if they fall
[Bug libfortran/42763] internal compiler error: in instantiate_virtual_regs_lossage ERROR 1
--- Comment #1 from kargl at gcc dot gnu dot org 2010-01-15 20:43 --- Please update your compiler to at least the latest 4.2.x release. A better choice would be a vesion from the 4.4 releases. In fact, you can get pre-compiled version of gfortran from the gfortran wiki. The 4.0.1 version of the compiler has not been supported for years. Yes, I wrote years. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42763
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #14 from sezeroz at gmail dot com 2010-01-15 20:59 --- For me, the testcase doesn't abort or exit successfully, it just segfaults (i686, x86_64, gcc-4.3, 4.4). $ gcc44 -g -O2 -Wall -W pr42691.c $ gdb ./a.out GNU gdb Fedora (6.8-24.fc9) [...] Program received signal SIGSEGV, Segmentation fault. add (key=0xbf9eef38, table=0xbf9eef28) at pr42691.c:29 29*deletedEntry = 0.0; -- sezeroz at gmail dot com changed: What|Removed |Added CC||sezeroz at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #15 from mikpe at it dot uu dot se 2010-01-15 21:11 --- The test case added with this PR appears to be rather broken. On armv5tel with gcc-4.3 or 4.4 (without the fix) -Os -mthumb I do get an abort(), which seems deliberate. However, replacing -Os -mthumb with -O0 -g results in a segfault because deletedEntry is NULL when *deletedEntry = 0.0; is executed. It also segfaults in the same way on i686/x86_64/powerpc64 even with old non-broken compiler versions. Looking at the code I don't see how it could ever work, that is exit normally with status 0. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #16 from jingyu at google dot com 2010-01-15 21:14 --- Subject: Re: [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG Sorry. The following change would fix it on X86. Index: testsuite/gcc.c-torture/execute/pr42691.c === --- testsuite/gcc.c-torture/execute/pr42691.c (revision 155944) +++ testsuite/gcc.c-torture/execute/pr42691.c (working copy) @@ -26,7 +26,8 @@ i++; } - *deletedEntry = 0.0; + if (deletedEntry) +*deletedEntry = 0.0; return 0; } On Fri, Jan 15, 2010 at 1:11 PM, mikpe at it dot uu dot se gcc-bugzi...@gcc.gnu.org wrote: --- Comment #15 from mikpe at it dot uu dot se 2010-01-15 21:11 --- The test case added with this PR appears to be rather broken. On armv5tel with gcc-4.3 or 4.4 (without the fix) -Os -mthumb I do get an abort(), which seems deliberate. However, replacing -Os -mthumb with -O0 -g results in a segfault because deletedEntry is NULL when *deletedEntry = 0.0; is executed. It also segfaults in the same way on i686/x86_64/powerpc64 even with old non-broken compiler versions. Looking at the code I don't see how it could ever work, that is exit normally with status 0. The test case would fail on ARM -mthumb -Os due to the bug described in the thread. I will fix the problem immediately. Jing -- mikpe at it dot uu dot se changed: What |Removed |Added CC| |mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. You are the assignee for the bug, or are watching the assignee. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #17 from mikpe at it dot uu dot se 2010-01-15 21:42 --- (In reply to comment #16) --- testsuite/gcc.c-torture/execute/pr42691.c (revision 155944) +++ testsuite/gcc.c-torture/execute/pr42691.c (working copy) @@ -26,7 +26,8 @@ i++; } - *deletedEntry = 0.0; + if (deletedEntry) +*deletedEntry = 0.0; return 0; } Thanks, with this fix the test case exits normally with -O0 on both arm and i686, but abort()s as intended with -Os -mthumb with 4.4 (pre-fix) on arm. BTW, gcc-4.3.4 is also broken but gcc-4.2.4 works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #18 from jingyu at google dot com 2010-01-15 21:46 --- Subject: Re: [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG On Fri, Jan 15, 2010 at 1:42 PM, mikpe at it dot uu dot se gcc-bugzi...@gcc.gnu.org wrote: --- Comment #17 from mikpe at it dot uu dot se 2010-01-15 21:42 --- (In reply to comment #16) --- testsuite/gcc.c-torture/execute/pr42691.c (revision 155944) +++ testsuite/gcc.c-torture/execute/pr42691.c (working copy) @@ -26,7 +26,8 @@ i++; } - *deletedEntry = 0.0; + if (deletedEntry) + *deletedEntry = 0.0; return 0; } Thanks, with this fix the test case exits normally with -O0 on both arm and i686, but abort()s as intended with -Os -mthumb with 4.4 (pre-fix) on arm. Sorry for the inconvenience. I only tested -mthumb, which happened to work. I should have proofread the code carefully. I have reverted the whole patch on mainline and 4.4 I will modify the testcase and send the whole patch again. BTW, gcc-4.3.4 is also broken but gcc-4.2.4 works. Thanks for testing 4.3.4. I don't have a working 4.3.x on hands. I tested gcc-4.2.1, which works. So this is a regression bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. You are the assignee for the bug, or are watching the assignee. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2010-01-15 21:50 --- I have reverted the whole patch on mainline and 4.4 That was unnecessary. I will modify the testcase and send the whole patch again. Just send a message to gcc-patches@ and apply the fix to the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #20 from jingyu at gcc dot gnu dot org 2010-01-15 21:54 --- Subject: Bug 42691 Author: jingyu Date: Fri Jan 15 21:54:01 2010 New Revision: 155948 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155948 Log: 2010-01-15 Jing Yu jin...@google.com PR rtl-optimization/42691 * combine.c (try_combine): Set changed_i3_dest to 1 when I2 and I3 set a pseudo to a constant and are merged, and adjust comments. 2010-01-15 Jing Yu jin...@google.com PR rtl-optimization/42691 * gcc.c-torture/execute/pr42691.c: New. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr42691.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #21 from jakub at gcc dot gnu dot org 2010-01-15 21:59 --- FYI, if you always want to test a NaN, you'd need to use big endian ordering for some arches, plus there are targets which don't support NaN at all or where a double isn't as big as 4 shorts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #21 from phil at nwl dot cc 2010-01-15 22:07 --- (In reply to comment #18) Just build everything with default configure options, then go inside the libstdc++-v3 *build* dir and type 'make check'. Ah, hmm. Well, having to compile everything in order to run the tests using an external compiler is a bit of a bummer, isn't it? Compiling will take some time on this X40, so please be patient. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #22 from paolo dot carlini at oracle dot com 2010-01-15 22:15 --- (In reply to comment #21) (In reply to comment #18) Just build everything with default configure options, then go inside the libstdc++-v3 *build* dir and type 'make check'. Ah, hmm. Well, having to compile everything in order to run the tests using an external compiler is a bit of a bummer, isn't it? Maybe there is a communication problem here: I meant, *the whole GCC*, normally, with no special options, to keep things simple. If you want, you can exclude java, which normally takes a while, and fortran, and objective c, the languages you don't need in other terms: just pass --enable-languages=c++ and nothing else. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #23 from jingyu at google dot com 2010-01-15 22:25 --- Subject: Re: [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG On Fri, Jan 15, 2010 at 1:59 PM, jakub at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #21 from jakub at gcc dot gnu dot org 2010-01-15 21:59 --- FYI, if you always want to test a NaN, you'd need to use big endian ordering for some arches, If the floating point format is compatible with IEEE754, on little-endian machine, double float 0x7ff0,,, means an infinite number. on big-endian machine, double float 0x7ff0,,, means a very small number. Then this test does not have problem. plus there are targets which don't support NaN at all or where a double isn't as big as 4 shorts. This is troublesome. We need to limit the test case to run on machines where sizeof(double)=4*sizeof(short) only. Any idea how to add conditions to the test case? Thanks for pointing it out! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. You are the assignee for the bug, or are watching the assignee. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #23 from phil at nwl dot cc 2010-01-15 22:32 --- (In reply to comment #22) (In reply to comment #21) (In reply to comment #18) Just build everything with default configure options, then go inside the libstdc++-v3 *build* dir and type 'make check'. Ah, hmm. Well, having to compile everything in order to run the tests using an external compiler is a bit of a bummer, isn't it? Maybe there is a communication problem here: I meant, *the whole GCC*, Yes, it seems so. normally, with no special options, to keep things simple. If you want, you can exclude java, which normally takes a while, and fortran, and objective c, the languages you don't need in other terms: just pass --enable-languages=c++ and nothing else. What we want to do is to run the libstdc++ testsuite with my distribution-provided g++, in order to see whether it's generally broken or not, right? And what I'm criticising here is that I have to compile *anything* of the gcc-sources in order to run the testsuite. I see no sense in building any binaries at all, since I already have all binaries (executables as well as libraries) in order to run the tests?! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #24 from paolo dot carlini at oracle dot com 2010-01-15 23:07 --- (In reply to comment #23) What we want to do is to run the libstdc++ testsuite with my distribution-provided g++, in order to see whether it's generally broken or not, right? Wrong. You can't use one compiler (older, by the way), with a newer libstdc++. And what I'm criticising here is that I have to compile *anything* of the gcc-sources in order to run the testsuite. I see no sense in building any binaries at all, since I already have all binaries (executables as well as libraries) in order to run the tests?! You don't, you *need* a complete new GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug fortran/42680] [fortran-dev, Regression] ICE in gimplify_expr, at gimplify.c:7176
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-01-15 23:20 --- Same test case fails differently on dev then it did on trunk. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42680
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #26 from paolo dot carlini at oracle dot com 2010-01-16 00:05 --- Hey, I'm telling you the way we all library maintainers (like me) and users check the library: they all fetch everything (either mainline or 4_4-branch, or whatever) via svn, make, make check. Now you want to do something else, you want to check the compiler + library you have already installed, but your obviously missing the testsuite, because you didn't build it yourself. Now, you are on your own, because I have no idea how and where to fetch only the testsuite of the specific GCC you are running on the specific Linux you are running, and then adjust everything to run it with your already installed compiler, this is not the normal way we do those tests. To repeat, the point was checking that your Linux and your hardware are sane, because I told you already that we know **for sure** that on current (and no so current) machines and Ubuntu, OpenSUSE, Fedora, whatever, that snippet works perfectly fine and *much* more than it, a whole testsuite. So, it's up to you, I'll keep this open: if over the nest month or so you provide the testresults you get for either your specific GCC, current 4_4-branch, or current mainline on your OS + hardware, we can hope to make progress on your issue, otherwise nobody will commit suicide, and the issue will be simply closed for lack of meaningful feedback from submitter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
