[Bug target/38988] Cannot build crtstuff.c with -mcmodel=large -fPIC -O2

--- Comment #10 from uros at gcc dot gnu dot org 2009-01-28 07:58 --- Subject: Bug 38988 Author: uros Date: Wed Jan 28 07:58:07 2009 New Revision: 143720 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143720 Log: PR target/38988 * config/i386/i386.md (set_rip_rex

[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]

--- Comment #10 from burnus at gcc dot gnu dot org 2009-01-28 07:11 --- Someone (Toon?) mentioned a plan to make the GOMP backend infrastructure usable for shared memory. I also found the following paper: "Prototyping the automatic generation of MPI code from OpenMP programs in GCC" at h

[Bug tree-optimization/38997] New: -ftree-loop-distribution ICEs

Consider: char a[8][8]; char b[8]; void foo (int i) { int j; for (j = 0; j < 8; j++) { a[i][j] = 0; b[j] = j; } } I get: $ ./cc1 -quiet -O2 -ftree-loop-distribution min.c min.c: In function 'foo': min.c:5: internal compiler error: in build2_stat, at tree.c:3298 Please su

[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

--- Comment #20 from rob1weld at aol dot com 2009-01-28 06:23 --- (In reply to comment #17) > Subject: Re: [4.3/4.4 Regression] ICE in set_value_range, > On Tue, 27 Jan 2009, bonzini at gnu dot org wrote: > > > > It's very clear to me by now that HOST_WIDE_INT should only depend on the

[Bug fortran/38915] [Fix pending] wrong results for structure assignment of character components when left and right sides overlap

--- Comment #3 from pault at gcc dot gnu dot org 2009-01-28 06:21 --- See http://gcc.gnu.org/ml/fortran/2009-01/msg00331.html -- pault at gcc dot gnu dot org changed: What|Removed |Added -

[Bug target/34163] [4.3/4.4 Regression] 10% performance regression since Nov 1 on Polyhedron's "NF" on AMD64

--- Comment #12 from rob1weld at aol dot com 2009-01-28 03:54 --- On the Trunk using "-O2" or "-O3" can produce slower code. I built gcc version 4.4.0 20090126 [trunk revision 143680] for i386-redhat-linux and was dismayed to find that libmudflaps had a few FAILs: Results for 4.4.0 200

[Bug target/38941] CX isn't preserved with shift

--- Comment #11 from hjl dot tools at gmail dot com 2009-01-28 03:39 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFI

[Bug target/38941] CX isn't preserved with shift

--- Comment #10 from hjl at gcc dot gnu dot org 2009-01-28 03:38 --- Subject: Bug 38941 Author: hjl Date: Wed Jan 28 03:38:41 2009 New Revision: 143719 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143719 Log: 2009-01-27 H.J. Lu PR target/38941 * doc/extend.

[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++

--- Comment #15 from bkoz at gcc dot gnu dot org 2009-01-28 03:25 --- Here are my thoughts on how to fix this. None of the presented options is workable, IMHO. The preferred end goal is to only have the compatibilty.cc and compatibilty-ldbl.cc objects in the shared library, and not in

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

--- Comment #39 from rob1weld at aol dot com 2009-01-28 03:08 --- H.J. Lu, This comment ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14435#c25 ) requests that Bug Report be modified "restore to P3 if it affects non-Ada testsuites or any case where the compiler exports GCC_EXEC_PREFIX i

[Bug middle-end/38996] [LTO] lto1 doesn't work on RHEL5

--- Comment #1 from hjl dot tools at gmail dot com 2009-01-28 01:51 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01342.html -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

[Bug middle-end/38996] New: [LTO] lto1 doesn't work on RHEL5

[...@gnu-3 gcc]$ /export/gnu/import/svn/gcc-test/bld/gcc/xgcc -B/export/gnu/import/svn/gcc-test/bld/gcc/ /export/gnu/import/svn/gcc-test/src-lto/gcc/testsuite/gcc.c-torture/execute/builtins/fputs.c /export/gnu/import/svn/gcc-test/src-lto/gcc/testsuite/gcc.c-torture/execute/builtins/fputs-lib.c /exp

[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++

--- Comment #14 from bkoz at gcc dot gnu dot org 2009-01-28 01:41 --- Mine. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at g

[Bug other/38995] lto1 uses unaligned data accesses

--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-28 01:20 --- data_ptr = (const uint32_t *) ((const char*) data + decl_offset); num_decl_states = *data_ptr++; So either decl_offset is unaligned. Are we storing this packed? -- pinskia at gcc dot gnu dot org changed:

[Bug other/38995] New: lto1 uses unaligned data accesses

$ awk '/lto1.*unaligned access to/ {sub(/.*ip=/, ""); print}' testsuite/*/*.log | sort -u | addr2line -e lto1 ../../gcc/lto/lto.c:186 ../../gcc/lto/lto.c:197 ../../gcc/lto/lto.c:201 ../../gcc/lto/lto.c:272 ../../gcc/lto/lto.c:273 ../../gcc/lto/lto.c:216 ../../gcc/lto/lto.c:229 ../../gcc/lto/lto.c:2

[Bug bootstrap/38992] [LTO] Bootstrap failed on RHEL5/ia32 and RHEL5/ia64

--- Comment #4 from hjl dot tools at gmail dot com 2009-01-27 23:51 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01338.html -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

[Bug testsuite/38946] [4.4 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

--- Comment #13 from rob1weld at aol dot com 2009-01-27 23:47 --- This post: http://gcc.gnu.org/ml/gcc/2008-12/msg00135.html says: To get on the radar regressions have to be marked [4.4 Regression], with the target milestone set to 4.4.0 ... Changing "Summary" from / to: [trunk regre

[Bug target/38988] Cannot build crtstuff.c with -mcmodel=large -fPIC -O2

--- Comment #9 from sje at cup dot hp dot com 2009-01-27 23:45 --- Yes, your patch does fix my problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38988

[Bug libgcj/36640] Build gcc-4.2.1 release fails when configured with --with-xmlj using Sun's ld

--- Comment #7 from rob1weld at aol dot com 2009-01-27 23:33 --- Added "Known to work" 4.4.0 (gcc version 4.4.0 20090126 (experimental) [trunk revision 143680]). Tested on OpenSolaris 2008.11 i386-pc-solaris2.11 and Fedora 10 i386-redhat-linux-gnu . Rob -- rob1weld at aol dot com c

[Bug testsuite/38946] [trunk regression]�gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

--- Comment #12 from rob1weld at aol dot com 2009-01-27 23:26 --- (In reply to comment #11) > (In reply to comment #9) > Two alternatives are: I guess there is three. 3. The gcc Testsuite is testing 'outside of gcc' and exercising the libraries of the Operating System (maybe GNU libc /

[Bug c++/38880] [4.4 Regression] g++.dg/init/const7.C XFAILed

--- Comment #5 from jason at redhat dot com 2009-01-27 23:25 --- Subject: Re: [4.4 Regression] g++.dg/init/const7.C XFAILed rguenth at gcc dot gnu dot org wrote: > I just found this, I tried to fix this in fold but in the end agreed with > Andrew that the C++ FE should do what the C FE

[Bug bootstrap/38994] [LTO] lto1 isn't built when configured with --enable-languages=c,c++,fortran

--- Comment #1 from dnovillo at gcc dot gnu dot org 2009-01-27 23:00 --- No, of course not. This is by design. The lto1 binary is the front end for GIMPLE, as with any other front end, it has to be specifically requested when configuring the compiler. You have to add 'lto' to the li

[Bug bootstrap/38994] New: [LTO] lto1 isn't built when configured with --enable-languages=c,c++,fortran

When I configured gcc with --enable-languages=c,c++,fortran, lto1 wasn't built. -- Summary: [LTO] lto1 isn't built when configured with --enable- languages=c,c++,fortran Product: gcc Version: lto Status: UNCONFIRMED Sever

[Bug testsuite/38946] [trunk regression]�gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

--- Comment #11 from rob1weld at aol dot com 2009-01-27 22:45 --- (In reply to comment #9) > Subject: Re: [trunk regression]?gcc trunk 143562 - Testsuite - gfortran > failing tests that worked previously > > > I think adding a printf() clone to libiberty is WAY overkill just to > sile

[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

-- 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

[Bug fortran/38993] New: better error needed for incompatible f90 modules

When using gfortran 4.3.1 with Fortran modules compiled by older, incompatible releases like 4.2.4, the error message emitted is vague and does not attempt to point out the possible incompatibility between compiler and Fortran module. Many users keep Fortran modules around and would encounter this

[Bug testsuite/38946] [trunk regression]�gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

--- Comment #10 from rob1weld at aol dot com 2009-01-27 22:28 --- (In reply to comment #1) Note that some of the tests require specific features (such as denormalized long doubles) and are ... (In reply to comment #4) > (In reply to comment #3) > > This is not so much an error in Fortr

[Bug bootstrap/38992] [LTO] Bootstrap failed on RHEL5/ia32 and RHEL5/ia64

--- Comment #3 from hjl dot tools at gmail dot com 2009-01-27 22:17 --- I will give it a try. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38992

[Bug bootstrap/38992] [LTO] Bootstrap failed on RHEL5/ia32 and RHEL5/ia64

--- Comment #2 from dnovillo at gcc dot gnu dot org 2009-01-27 22:10 --- The libelf included in Red Hat based distros is different than the one we used to develop LTO. There was a thread on IRC recently where Jakub proposed a way of working around this: (16:27:18) jakub: dnovillo: ver

[Bug bootstrap/38992] [LTO] Bootstrap failed on RHEL5/ia32 and RHEL5/ia64

--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-27 22:00 --- Yes this comes down to having the correct version of libelf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38992

[Bug bootstrap/38992] New: [LTO] Bootstrap failed on RHEL5/ia32 and RHEL5/ia64

On RHEL5/ia32 and RHEL5/ia64, revision 143711 gave /export/gnu/import/svn/gcc-test/bld/./prev-gcc/xgcc -B/export/gnu/import/svn/gcc-test/bld/./prev-gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -c -g -O2 -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes

[Bug target/38991] ICE in extract_insn at recog.c:1990

--- Comment #1 from rmansfield at qnx dot com 2009-01-27 21:36 --- Also reproducible with gcc version 4.4.0 20090127 (experimental) [trunk revision 143711] (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38991

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

--- Comment #38 from rob1weld at aol dot com 2009-01-27 21:32 --- Clearly, it is wrong: # locate crtprec80.o /mnt/drive2/gcc_build/gcc/crtprec80.o /mnt/drive2/gcc_build/i386-redhat-linux/libgcc/crtprec80.o /mnt/drive2/gcc_build/prev-gcc/crtprec80.o /mnt/drive2/gcc_build/prev-i386-redhat

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

--- Comment #37 from rob1weld at aol dot com 2009-01-27 21:26 --- (In reply to comment #20) > (In reply to comment #19) > > Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work > > with installed gcc > > hjl dot tools at gmail dot com wrote: > > > They sound to me the ideal usage for

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

--- Comment #36 from rob1weld at aol dot com 2009-01-27 21:12 --- (In reply to comment #33) *** Bug 38820 has been marked as a duplicate of this bug. *** (In reply to comment #34) > If I have an old gcc 4.4 installed on my machine, will setting > GCC_EXEC_PREFIX use the old installed gcc

[Bug libstdc++/15088] 27_io/ostream_inserter_arith test05/06 failures

--- Comment #9 from jifl-bugzilla at jifvik dot org 2009-01-27 21:07 --- I've just tried it on gcc 4.3.2 for arm-eabi, and can't reproduce it with either 5.cc or 6.cc any more. -O0 or -O2 didn't make a difference either. While the principle sort-of seems sound that you shouldn't push t

[Bug fortran/37614] [Fix pending] Change position of padding for aligned COMMONs

--- Comment #3 from pault at gcc dot gnu dot org 2009-01-27 20:53 --- See http://gcc.gnu.org/ml/fortran/2009-01/msg00217.html and subsequent postings. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added --

[Bug libstdc++/14608] nukes isfinite macro from

--- Comment #9 from bkoz at gcc dot gnu dot org 2009-01-27 20:49 --- Looks to me like the flipside of libstdc++/7439. More broadly speaking, C99 macros vs. C++98/0x. The current status on this issue is: For 4.1/4.2/4.3/trunk, C99 macros should be visible with 1) -std=gnu99/c99 in "C

[Bug target/38988] Cannot build crtstuff.c with -mcmodel=large -fPIC -O2

--- Comment #8 from ubizjak at gmail dot com 2009-01-27 20:28 --- (In reply to comment #7) > Did you change cselib_hash_rtx too? I don't see that change in your patch but > I know I need it to get to the shared rtx bug that your patch will hopefully > fix. The fix is not necessary, sin

[Bug target/38991] New: ICE in extract_insn at recog.c:1990

$ cat /home/ryan/reduced.i typedef unsigned int _Uint16t __attribute__((__aligned__(2))) __attribute__((__mode__(__HI__))); struct timeval { unsigned tv_sec; }; extern volatile struct timeval mono_time; struct a { unsigned int time1; }; void sppp_input() { struct

[Bug ada/38989] How much stack space should c380004 take?

--- Comment #4 from joel dot sherrill at oarcorp dot com 2009-01-27 20:21 --- Subject: Re: How much stack space should c380004 take? laurent at guerby dot net wrote: > --- Comment #3 from laurent at guerby dot net 2009-01-27 20:16 --- > in gcc/testsuite/ada/acats/run_all.sh t

[Bug ada/38989] How much stack space should c380004 take?

--- Comment #3 from laurent at guerby dot net 2009-01-27 20:16 --- in gcc/testsuite/ada/acats/run_all.sh there is already some handling of special tests: case $i in cxb30*) EXTERNAL_OBJECTS="$dir/support/cxb30040.o $dir/support/cxb30060.o $dir/support/cxb30130.o $dir/suppo

[Bug ada/38989] How much stack space should c380004 take?

--- Comment #2 from joel dot sherrill at oarcorp dot com 2009-01-27 20:10 --- Subject: Re: How much stack space should c380004 take? laurent at guerby dot net wrote: > --- Comment #1 from laurent at guerby dot net 2009-01-27 19:31 --- > This test has arrays of complicated Ada

[Bug target/38988] Cannot build crtstuff.c with -mcmodel=large -fPIC -O2

--- Comment #7 from sje at cup dot hp dot com 2009-01-27 20:03 --- Did you change cselib_hash_rtx too? I don't see that change in your patch but I know I need it to get to the shared rtx bug that your patch will hopefully fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38988

[Bug middle-end/38969] [4.3 Regression] -foptimize-sibling-calls generates wrong code on alpha

--- Comment #7 from aurelien at aurel32 dot net 2009-01-27 20:00 --- Thanks a lot, I confirm it also fixes the original problem, that is problem in glibc testsuite (test-float and test-ifloat failing on most of the complex number functions). -- http://gcc.gnu.org/bugzilla/show_bug.c

[Bug target/38988] Cannot build crtstuff.c with -mcmodel=large -fPIC -O2

--- Comment #6 from ubizjak at gmail dot com 2009-01-27 19:57 --- Steve, can you test this patch if it fixes your bootstrap? -- ubizjak at gmail dot com changed: What|Removed |Added --

[Bug target/38988] Cannot build crtstuff.c with -mcmodel=large -fPIC -O2

--- Comment #5 from ubizjak at gmail dot com 2009-01-27 19:55 --- Created an attachment (id=17195) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17195&action=view) Patch to fix crtstuff.c failure This patch fixes crtstuff failure with -mcmodel=large. -- ubizjak at gmail dot co

[Bug c++/37554] [4.3 regression] ICE with invalid cast

--- Comment #6 from paolo dot carlini at oracle dot com 2009-01-27 19:48 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added

[Bug c++/37554] [4.3/4.4 regression] ICE with invalid cast

--- Comment #5 from paolo at gcc dot gnu dot org 2009-01-27 19:47 --- Subject: Bug 37554 Author: paolo Date: Tue Jan 27 19:47:28 2009 New Revision: 143711 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143711 Log: /cp 2009-01-27 Paolo Carlini PR c++/37554 * c

[Bug libstdc++/15088] 27_io/ostream_inserter_arith test05/06 failures

--- Comment #8 from bkoz at gcc dot gnu dot org 2009-01-27 19:47 --- 4.2.1 arm-eabi doesn't show this: http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00989.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15088

[Bug testsuite/38946] [trunk regression]�gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

--- Comment #9 from dj at redhat dot com 2009-01-27 19:38 --- Subject: Re: [trunk regression]?gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously I think adding a printf() clone to libiberty is WAY overkill just to silence one failing test. -- http://gcc.

Re: [Bug testsuite/38946] [trunk regression]?gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

I think adding a printf() clone to libiberty is WAY overkill just to silence one failing test.

[Bug ada/38989] How much stack space should c380004 take?

--- Comment #1 from laurent at guerby dot net 2009-01-27 19:31 --- This test has arrays of complicated Ada entities so I'm not surprised by stack usage. Could you report at what task size it passes? -- laurent at guerby dot net changed: What|Removed

[Bug c++/38990] New: preprocessing different in g++ -E and regular compiling.

(This might affect the C front end also, I have not tried). Basically, there are situations where g++ -E accepts multi-line string literals and glues them together into a proper string literal token. If the resulting preprocessor output is compiled, there are no diagnostics. But if the compiler is

[Bug ada/37430] [4.4 Regression] C974013 gives exception

--- Comment #5 from laurent at guerby dot net 2009-01-27 19:12 --- Note: C974013 was in the past victim of another miscompilation bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737 It was about type based aliasing with a quite long discussion. -- laurent at guerby dot net chang

[Bug ada/38989] New: How much stack space should c380004 take?

RTEMS has fixed size task stacks. This test is blowing a stack that is ~100K large. How large does it need to be? Is is a bug to use this much stack? ,.,. C380004 ACATS 2.5 88-01-01 00:00:00 C380004 Check evaluation of discriminant expressions when the constraint depends on

[Bug ada/37430] [4.4 Regression] C974013 gives exception

--- Comment #4 from joel at gcc dot gnu dot org 2009-01-27 19:04 --- (In reply to comment #3) > Fixed as of revision 139039. > Disagree. http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02352.html is ACATS for powerpc-rtems on psim. Test C974013 fails with exactly the same backtrace a

[Bug other/38983] GPL version 3 transition incomplete

--- Comment #1 from bkoz at gcc dot gnu dot org 2009-01-27 18:55 --- http://gcc.gnu.org/ml/gcc/2009-01/msg00417.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38983

[Bug middle-end/38615] [4.2/4.3 Regression] invalid promotion to static from auto

--- Comment #5 from sje at cup dot hp dot com 2009-01-27 18:48 --- Fixed on trunk for 4.4.0 and on 4.3 branch for 4.3.4. -- sje at cup dot hp dot com changed: What|Removed |Added -

[Bug middle-end/38615] [4.2/4.3 Regression] invalid promotion to static from auto

--- Comment #4 from sje at gcc dot gnu dot org 2009-01-27 18:46 --- Subject: Bug 38615 Author: sje Date: Tue Jan 27 18:45:49 2009 New Revision: 143708 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143708 Log: PR middle-end/38615 * gimplify.c (gimplify_init_const

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

--- Comment #35 from janis at gcc dot gnu dot org 2009-01-27 18:45 --- In response to comment #34, the -B option overrides GCC_EXEC_PREFIX and the compiler being tested in the build directory is invoked with -B. GCC_EXEC_PREFIX will only be used to find files that are not in the build d

[Bug ada/37430] [4.4 Regression] C974013 gives exception

--- Comment #3 from hjl dot tools at gmail dot com 2009-01-27 18:39 --- Fixed as of revision 139039. -- hjl dot tools at gmail dot com changed: What|Removed |Added

[Bug c++/37737] [c++0x] ICE in get_innermost_template_args at cp/pt.c:516 during variadic function overload deduction

--- Comment #8 from ethouris at gmail dot com 2009-01-27 18:35 --- I added as attachment the code that causes the same error message. Please note that this code was compiling and working correctly with the old Doug Gregor's patch, which was the first version of 'variadic template' featu

[Bug c++/37737] [c++0x] ICE in get_innermost_template_args at cp/pt.c:516 during variadic function overload deduction

--- Comment #7 from ethouris at gmail dot com 2009-01-27 18:33 --- Created an attachment (id=17194) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17194&action=view) Preprocessed source that caused the problem The problem is reported for line 40 in msigslot.h, where a 'friend' decl

[Bug fortran/38883] [4.4 Regression] ICE for MVBITS with derived type argument that has run-time subscripts

--- Comment #8 from domob at gcc dot gnu dot org 2009-01-27 18:10 --- Fixed on trunk. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSI

[Bug fortran/38883] [4.4 Regression] ICE for MVBITS with derived type argument that has run-time subscripts

--- Comment #7 from domob at gcc dot gnu dot org 2009-01-27 18:08 --- Subject: Bug 38883 Author: domob Date: Tue Jan 27 18:07:54 2009 New Revision: 143707 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143707 Log: 2009-01-27 Daniel Kraft PR fortran/38883 * tr

[Bug target/38988] Cannot build crtstuff.c with -mcmodel=large -fPIC -O2

--- Comment #4 from hjl dot tools at gmail dot com 2009-01-27 18:07 --- Assuming you have solved crtstuff.c issue, will /usr/lib64/crt1.o work with -Wl,--section-start,.text=0x11000? Can you try the latest binutils from CVS with [...@gnu-6 pr38988]$ cat f.c #include int main () {

[Bug c++/37554] [4.3/4.4 regression] ICE with invalid cast

--- Comment #4 from paolo dot carlini at oracle dot com 2009-01-27 17:56 --- On it. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedT

[Bug target/38988] Cannot build crtstuff.c with -mcmodel=large -fPIC -O2

--- Comment #3 from sje at cup dot hp dot com 2009-01-27 17:54 --- No, I don't have a user application. I believe the problem was that the user was compiling a program with something like -Wl,--section-start,.text=0x11000 and because the crt files weren't compiled with -mcmodel=larg

[Bug target/38988] Cannot build crtstuff.c with -mcmodel=large -fPIC -O2

--- Comment #2 from hjl dot tools at gmail dot com 2009-01-27 17:48 --- By testcase, I meant a user application, not crtstuff.c, like # gcc -mcmodel=large foo.c # ./a.out -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38988

[Bug target/38988] Cannot build crtstuff.c with -mcmodel=large -fPIC -O2

--- Comment #1 from hjl dot tools at gmail dot com 2009-01-27 17:46 --- Do you have a testcase to show that -mcmodel=large doesn't work for you? -- hjl dot tools at gmail dot com changed: What|Removed |Added

[Bug libstdc++/25956] Memory error when dynamic linking STL specializations

--- Comment #5 from bkoz at gcc dot gnu dot org 2009-01-27 17:26 --- Duplicate *** This bug has been marked as a duplicate of 28017 *** -- bkoz at gcc dot gnu dot org changed: What|Removed |Added --

[Bug c++/28017] lack of guard variables for explicitly instantiated template static data

--- Comment #13 from bkoz at gcc dot gnu dot org 2009-01-27 17:26 --- *** Bug 25956 has been marked as a duplicate of this bug. *** -- bkoz at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/38987] Including a precompiled header from another header causes invalid assembly to be generated

--- Comment #3 from frank dot richter at gmail dot com 2009-01-27 17:18 --- No ICE here (gcc version 4.2.4 (Gentoo 4.2.4 p1.0)), but the underlying cause might be the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38987

[Bug target/38988] New: Cannot build crtstuff.c with -mcmodel=large -fPIC -O2

If you compile the following code (cut down from crtstuff.c) with -mcmodel=large -fPIC -O2 on a 64 bit x86 target GCC will ICE. There are at least two problems, one in cselib_hash_rtx, and if that is fixed then I get a shared rtx abort. The test case is typedef long unsigned int size_t;

[Bug c++/38987] Including a precompiled header from another header causes invalid assembly to be generated

--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-27 17:14 --- CXX=g++-4.3 ./cause-error.sh In file included from :0: :0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for in

[Bug tree-optimization/38977] [4.4 Regression] bash no longer builds with profile-feedback

--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-27 17:01 --- Hm, unfortunately simply disabling that error doesn't fix my bash build. Instead we now error on jobs.c:4121: error: corrupted profile info: number of executions for edge 10-11 thought to be -1726 jobs.c:4121: error

[Bug bootstrap/38867] [Regression] gcc 4.4.0 20090114 - libjava/configure sets "NONE/share/python", need "${prefix}/share/python"

--- Comment #1 from rob1weld at aol dot com 2009-01-27 17:00 --- Trunk revision 143680 works on Fedora 10: # gcc/xgcc -v Using built-in specs. Target: i386-redhat-linux Configured with: ../gcc_trunk/configure --enable-languages=c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-s

[Bug rtl-optimization/38583] huge test case makes register allocator run out of memory while constructing the conflict graph

--- Comment #4 from hjl dot tools at gmail dot com 2009-01-27 16:50 --- (In reply to comment #0) > This is split off from PR38474 for clarity. Compiling the testcase of that PR > > (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16873) > > as > > gfortran -ffree-line-length-512 -g -ff

[Bug c++/38880] [4.4 Regression] g++.dg/init/const7.C XFAILed

--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-27 16:33 --- Created an attachment (id=17193) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17193&action=view) example patch I just found this, I tried to fix this in fold but in the end agreed with Andrew that the C++ FE

[Bug testsuite/38910] gcc 4.4.0 - Testsuite charset.exp not checking my locale

--- Comment #1 from rob1weld at aol dot com 2009-01-27 16:30 --- On Fedora 10 (i386-redhat-linux) trunk revision 143680 using: # iconv --version iconv (GNU libc) 2.9 # iconv -l | grep IBM1047 IBM1047// Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38910

[Bug c++/38987] Including a precompiled header from another header causes invalid assembly to be generated

--- Comment #1 from frank dot richter at gmail dot com 2009-01-27 16:28 --- Created an attachment (id=17192) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17192&action=view) Test case for precompiled header inclusion This test case is a simple scenario where a precompiled header

[Bug c++/38987] New: Including a precompiled header from another header causes invalid assembly to be generated

When a header(A) is precompiled and included from another header(B), compiling a source file using B results in invalid assembly. The message from the assembler is "file number X already allocated". -- Summary: Including a precompiled header from another header cau

[Bug target/38924] gcc 4.4.0 20090117 - init_priority incorrect for GNU ld in "gcc/config/sol2.h"

--- Comment #2 from rob1weld at aol dot com 2009-01-27 16:26 --- (In reply to comment #1) > With that dropped in gcc seems to build and test correctly. It _might_ be > that gcc builds Faster and uses Less memory during the two peaks in libjava > after this patch, more testing required.

[Bug tree-optimization/38977] [4.4 Regression] bash no longer builds with profile-feedback

--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-27 16:25 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned

[Bug tree-optimization/38984] [4.2/4.3/4.4 Regression] NULL pointers always considered distinct by PTA, even with -fno-delete-null-pointer-checks

-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38984

[Bug testsuite/38946] [trunk regression]�gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

--- Comment #8 from rob1weld at aol dot com 2009-01-27 16:18 --- (In reply to comment #4) > (In reply to comment #3) > > This is not so much an error in Fortran than it is an error in the > > scripting and it's ability to add it's own LD_LIBRARY_PATH components. > No. The current linking

[Bug c++/38908] [4.4 regression] Unexplained "'' is used uninitialized in this function" warning in cc1plus -m64

--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-27 16:11 --- Well, it is a duplicate really, just this testcase involves one more case: # VUSE # _3 = VDEF <_2(D)> __comp_ctor (&, D.2044); where the uninitialized aggregate use appears as a function argument. While I

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

--- Comment #34 from hjl dot tools at gmail dot com 2009-01-27 16:06 --- If I have an old gcc 4.4 installed on my machine, will setting GCC_EXEC_PREFIX use the old installed gcc 4.4 for "make check"? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443

[Bug c++/38908] [4.4 regression] Unexplained "'' is used uninitialized in this function" warning in cc1plus -m64

-- bangerth at gmail dot com changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38908

[Bug c++/38908] [4.4 regression] Unexplained "'' is used uninitialized in this function" warning in cc1plus -m64

--- Comment #5 from bangerth at gmail dot com 2009-01-27 16:00 --- Richard, this isn't a duplicate of PR 38851: while the testcase there indeed now passes, the one in the current PR still fails. Best Wolfgang -- bangerth at gmail dot com changed: What|Removed

[Bug testsuite/38946] [trunk regression]�gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

--- Comment #7 from rob1weld at aol dot com 2009-01-27 16:00 --- (In reply to comment #5) > ! Test XFAILed on these platforms because the system's printf() lacks > ! proper support for denormalized long doubles. See PR24685 > > Looks like this testcase should be xfailed on solaris also.

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

--- Comment #33 from hjl dot tools at gmail dot com 2009-01-27 15:54 --- I think it is a very bad idea to set GCC_EXEC_PREFIX for "make check". If some people want binary tools, which aren't the part of installed gcc, in the GCC_EXEC_PREFIX directory when running "make check", they shou

[Bug testsuite/38946] [trunk regression]�gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

--- Comment #6 from rob1weld at aol dot com 2009-01-27 15:50 --- Here is a newer result on Fedora 10: === gfortran tests === Running target unix === gfortran Summary === # of expected passes29107 # of expected failures 14 # of unsu

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

--- Comment #32 from hjl dot tools at gmail dot com 2009-01-27 15:48 --- *** Bug 38820 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added -

[Bug testsuite/38820] During "make -i check" we set GCC_EXEC_PREFIX="/usr/local/lib/gcc/"

--- Comment #5 from hjl dot tools at gmail dot com 2009-01-27 15:48 --- *** This bug has been marked as a duplicate of 36443 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added --

[Bug testsuite/38820] During "make -i check" we set GCC_EXEC_PREFIX="/usr/local/lib/gcc/"

--- Comment #4 from hjl dot tools at gmail dot com 2009-01-27 15:47 --- Reopen ... -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|RESOL

[Bug testsuite/38820] During "make -i check" we set GCC_EXEC_PREFIX="/usr/local/lib/gcc/"

--- Comment #3 from rob1weld at aol dot com 2009-01-27 15:38 --- (In reply to comment #2) > It's not a bug that GCC EXEC_PREFIX is defined when the testsuite is run, as > explained in these patches: > > http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00708.html > http://gcc.gnu.org/ml/

[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

--- Comment #19 from bonzini at gnu dot org 2009-01-27 15:21 --- > The problem on ix86 is I believe that on such a register starved host, using > long long in many places will mean very noticeable performance degradation. Probably noticeable; however, Debian and Apple are already distri

[Bug boehm-gc/38967] gcc 4.4.0 20090125 [trunk revision 143660] - Boehm Testsuite failure is not unreported

--- Comment #1 from rob1weld at aol dot com 2009-01-27 15:18 --- Running trunk revision 143680 on Fedora 10 I get: # ../gcc_build/gcc/xgcc -v Using built-in specs. Target: i386-redhat-linux Configured with: ../gcc_trunk/configure --enable-languages=c,c++,fortran,java,objc,obj-c++ --enab

  1   2   >