[Bug fortran/34946] [4.3 Regression] internal compiler error: in gfc_trans_create_temp_array, at fortran/trans-array.c:592

--- Comment #3 from jv244 at cam dot ac dot uk 2008-01-24 07:27 --- reduced testcase: MODULE test TYPE realspace_grid_input_type INTEGER :: distribution_layout(3) END TYPE realspace_grid_input_type TYPE realspace_grid_type INTEGER, DIMENSION (3) :: npts

[Bug fortran/34876] Can't read/write array sections with negative stride not specified

--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-01-24 07:03 --- Created an attachment (id=15014) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15014&action=view) Preliminary patch This patch illustrates the fix. What remains is to check cases of all other I/O (formatt

[Bug c++/25701] gcc.texi missing @direntry for g++

--- Comment #2 from bje at gcc dot gnu dot org 2008-01-24 06:08 --- Patch posted at: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg01126.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25701

[Bug fortran/32760] [4.3 Regression] Error defining subroutine named PRINT

--- Comment #23 from jvdelisle at gcc dot gnu dot org 2008-01-24 05:20 --- Oh, I see, the trick is dealing with implicit_11.f90 as well. and around and around we go. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32760

[Bug fortran/34876] Can't read/write array sections with negative stride not specified

--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-01-24 05:15 --- Answering your question. Putting the write in front of the failing one causes seeking to that record, writing it out and flushing the buffers. Writing "grows" the file. This creates "undefined" records from th

[Bug fortran/32760] [4.3 Regression] Error defining subroutine named PRINT

--- Comment #22 from jvdelisle at gcc dot gnu dot org 2008-01-24 04:52 --- Putting this back in fixes the new test case in comment #21 Index: primary.c === --- primary.c (revision 131752) +++ primary.c (working copy) @

[Bug rtl-optimization/323] optimized code gives strange floating point results

--- Comment #101 from pinskia at gcc dot gnu dot org 2008-01-24 04:51 --- *** Bug 34951 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug rtl-optimization/34951] gcse+O1 triggers invalid floating point stack management

--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-24 04:51 --- Actually no this is not really a "bug" in GCC, just your assumption about x87 fp math. Anyways this is duplicate of bug 323. Adding -ffloat-store fixes the issue. *** This bug has been marked as a duplicate of 323

[Bug c/34951] gcse+O1 triggers invalid floating point stack management

--- Comment #1 from tterribe at xiph dot org 2008-01-24 04:02 --- Created an attachment (id=15013) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15013&action=view) Pre-processed source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34951

[Bug c/34951] New: gcse+O1 triggers invalid floating point stack management

-fgcse (only at optimization level -O1 or higher) causes the compare at line 3639 of the pre-processed linprog.i (attached) to fire with only one of its operands on the stack. This leads to non-sensical results such as normal floating point number being declared less than itself. If the je .L345 i

[Bug middle-end/34931] FAIL: gcc.dg/pr28796-[12].c (test for excess errors)

--- Comment #8 from danglin at gcc dot gnu dot org 2008-01-24 02:39 --- Testing backend fix. -- danglin at gcc dot gnu dot org changed: What|Removed |Added St

[Bug c/34720] ICE in real_to_decimal, at real.c:1656

--- Comment #6 from bje at gcc dot gnu dot org 2008-01-24 02:33 --- Thanks; I will keep investigating. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34720

[Bug c++/34950] ICE in svn boost math toolkit

--- Comment #1 from inform at tiker dot net 2008-01-24 01:27 --- Created an attachment (id=15012) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15012&action=view) ICE'ing preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34950

[Bug c++/34950] New: ICE in svn boost math toolkit

The attached preprocessed source causes the following ICE: - /home/andreas/pool/include/boost-1_35/boost/math/policies/policy.hpp: In instantiation of ‘boost::math::policies::precision’: /home/andreas/pool/include/boost-1_35/bo

[Bug middle-end/34931] FAIL: gcc.dg/pr28796-[12].c (test for excess errors)

--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-24 00:47 --- Subject: Re: FAIL: gcc.dg/pr28796-[12].c (test for excess errors) > Fixed. Unfortunately, only the first testcase is fixed. We still have FAIL: gcc.dg/pr28796-2.c (test for excess errors) Excess errors:

[Bug other/22232] Bug in "fixproto" (missing escape)

--- Comment #3 from bje at gcc dot gnu dot org 2008-01-24 00:12 --- Subject: Bug 22232 Author: bje Date: Thu Jan 24 00:11:47 2008 New Revision: 131769 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131769 Log: Revert this patch, as it is not a regression. 2008-01-24 Ben Ellist

[Bug fortran/34858] [4.3 Regression] ICE on invalid depending of the length of the source name

--- Comment #6 from dfranke at gcc dot gnu dot org 2008-01-23 23:43 --- integer :: c! anything, makes block data invalid block data bd common d ! 'd' undefined, new symbol generated that needs to be undone end block data bd end In the code above, the newly generated s

[Bug other/31405] [4.3 Regression] fixincludes needed for wchar from glibc 2.3.6

--- Comment #2 from hp at gcc dot gnu dot org 2008-01-23 23:35 --- Patch at awaiting approval. -- hp at gcc dot gnu dot org changed: What|Removed |Added -

[Bug other/22232] Bug in "fixproto" (missing escape)

--- Comment #2 from bje at gcc dot gnu dot org 2008-01-23 23:27 --- Subject: Bug 22232 Author: bje Date: Wed Jan 23 23:26:24 2008 New Revision: 131768 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131768 Log: PR other/22232 * fixproto: Escape "." in sed expressi

[Bug c++/34949] Dead code in empty destructors.

--- Comment #2 from spark at gcc dot gnu dot org 2008-01-23 23:23 --- I understand why it's difficult to delete the code in the middle-end. But this case seems to be quite common - not the empty body but more common cases are destructors whose body doesn't need vtable. -- http://gcc

[Bug middle-end/34926] [4.3 Regression] FAIL: gcc.c-torture/execute/va-arg-15.c execution, -O3 -fomit-frame-pointer -funroll-loops

--- Comment #6 from zadeck at naturalbridge dot com 2008-01-23 23:22 --- Subject: Re: [4.3 Regression] FAIL: gcc.c-torture/execute/va-arg-15.c execution, -O3 -fomit-frame-pointer -funroll-loops danglin at gcc dot gnu dot org wrote: > --- Comment #5 from danglin at gcc dot gnu do

[Bug middle-end/34926] [4.3 Regression] FAIL: gcc.c-torture/execute/va-arg-15.c execution, -O3 -fomit-frame-pointer -funroll-loops

--- Comment #5 from danglin at gcc dot gnu dot org 2008-01-23 23:20 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING

[Bug c++/34862] [4.3 Regression] operator new placement variant with reference arg not accepted by g++ 4.3

--- Comment #6 from jakub at gcc dot gnu dot org 2008-01-23 23:19 --- The c#2 testcase compiles and works with 4.1.x, so all of rejects-valid (rev 127639+), wrong-code (rev 125653 .. rev 127638 at -O0) and ice-on-valid-code (rev 125653 .. rev 127638 at -O2) are regressions. -- jakub

[Bug c++/34949] Dead code in empty destructors.

--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-23 23:17 --- hmmm, it is hard for middle-end to know these are dead, the C++ front-end needs to comuniticate to the middle-end that after the function ends, this is not going to be valid. By the way, please don't call this a tri

[Bug middle-end/34949] New: Dead code in trivial destructors.

# cat dead.cpp class Foo { public: virtual ~Foo(); }; Foo::~Foo() { } # g++ -O2 -S dead.cpp # cat dead.cpp ... .globl _ZN3FooD2Ev .type _ZN3FooD2Ev, @function _ZN3FooD2Ev: .LFB3: pushl %ebp .LCFI0: movl%esp, %ebp .LCFI1: movl8(%ebp), %eax mov

[Bug fortran/34325] Wrong error message for syntax error

--- Comment #9 from terry at chem dot gu dot se 2008-01-23 23:00 --- Actually, with bad parentheses it's easy to generate strange error messages: do while ((.true.) 1 Error: Invalid character in name at (1) do while (.true. 1 Error: Unclassifiable statement at (1) Yes,

[Bug middle-end/32395] false positive warning about use of uninitialized variable.

--- Comment #15 from manu at gcc dot gnu dot org 2008-01-23 22:57 --- (In reply to comment #14) > > :-( I cannot compile this testcase > > please try the latest testcase. > Thanks. It compiles fine now. The weirdest thing is that I cannot see the uninitialized warning but I can see th

[Bug middle-end/34926] [4.3 Regression] FAIL: gcc.c-torture/execute/va-arg-15.c execution, -O3 -fomit-frame-pointer -funroll-loops

--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-23 22:51 --- Please confirm this is fixed and close this bug. Thx. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --

[Bug c++/34913] [4.1/4.2/4.3 Regression] ICE vector in template

--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-23 22:50 --- I don't have checking enabled compilers from before 4.1 to actually verify this is a regression. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/34824] [4.1/4.2/4.3 Regression] ICE with explicit copy constructor

--- Comment #8 from fang at csl dot cornell dot edu 2008-01-23 22:48 --- As long as we're digging back... the test case in Comment #4 also ICEs: gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7) also "works": gcc version 2.95.3 [FreeBSD] 20010315 (release) -- http://gcc.gnu.org/

[Bug middle-end/34856] [4.2/4.3 Regression] ICE with some constant vectors

--- Comment #13 from pinskia at gcc dot gnu dot org 2008-01-23 22:40 --- Most likely we should just return NULL here instead of crashing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34856

[Bug c++/34862] [4.3 Regression] operator new placement variant with reference arg not accepted by g++ 4.3

--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-23 22:38 --- We should possibly separate the two issues, rejects-valid and wrong-code, as only rejects-valid is a regression. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug middle-end/34856] [4.2/4.3 Regression] ICE with some constant vectors

--- Comment #12 from rguenth at gcc dot gnu dot org 2008-01-23 22:35 --- The ICE in simplify_immed_subreg is reproducible with 4.2.3. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --

[Bug c++/34824] [4.1/4.2/4.3 Regression] ICE with explicit copy constructor

-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||2.95.4 Priority|P3 |P2 http://gc

[Bug middle-end/34934] -O1 crash compile *** glibc detected *** /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1: double free or corruption (!prev)

--- Comment #8 from Ralf dot Wildenhues at gmx dot de 2008-01-23 22:33 --- Subject: Re: -O1 crash compile *** glibc detected *** /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1: double free or corruption (!prev) * rguenth at gcc dot gnu dot org wrote on Wed, Jan 23, 2008 at 10:44:51PM CET: > I

[Bug other/31955] [4.2/4.3 Regression] gcc_release does not generate HTML files from install manual

-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 Summary|[4.2/4.3 regression]|[4.2/4.3 Regressio

[Bug other/31405] [4.3 Regression] fixincludes needed for wchar from glibc 2.3.6

-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hp at axis dot com Priority|P3 |P2

[Bug target/31070] ICE in function_arg_slotno

--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-23 22:27 --- Not clear if this is a regresion, those tests are new in 4.1. Not release critical, as sparc64 is neither primary nor secondary platform. -- rguenth at gcc dot gnu dot org changed: What|Removed

[Bug middle-end/34852] [4.3 Regression] Revision 131576 miscompiled 178.galgel

--- Comment #19 from rguenth at gcc dot gnu dot org 2008-01-23 22:21 --- Run is fine, invalid. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/34325] Wrong error message for syntax error

--- Comment #8 from terry at chem dot gu dot se 2008-01-23 21:54 --- Rather than open a new bug, I'll tack onto this one as it's pretty much the same bug in a different context. The latest gfortran does indeed give a sensible error for the test case above. However, if we put something

[Bug c++/34948] += operator on pointers with a function call having side effects on the right hand side

--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-23 21:49 --- There's no sequence point, the order of evaluation is undefined. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/34946] [4.3 Regression] internal compiler error: in gfc_trans_create_temp_array, at fortran/trans-array.c:592

--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-23 21:46 --- Fortran is not release-critical. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug middle-end/34934] -O1 crash compile *** glibc detected *** /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1: double free or corruption (!prev)

--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-23 21:44 --- I checked both a 32bit compiler and x86_64 with -m32 (with the reduced testcase). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34934

[Bug tree-optimization/33826] [4.1/4.2 Regression] GCC generates wrong code for infinitely recursive functions

--- Comment #20 from rguenth at gcc dot gnu dot org 2008-01-23 21:35 --- Not fixed on the branches. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug c/34720] ICE in real_to_decimal, at real.c:1656

--- Comment #5 from tgall dot foo at gmail dot com 2008-01-23 21:31 --- so the call path involved here is from gcc/c-cppbuiltin.c builtin_define_with_hex_fp_value which is calling real_to_decimal and its in that function we're running into problems. The string rep of the real is : 0x0

[Bug c++/34944] Tree check: at cp/typecheck.c

--- Comment #4 from jason at gcc dot gnu dot org 2008-01-23 21:24 --- That's bizarre, I'm not sure how I managed to check in a different version of that patch on 4.2 than the one I tested. Fixed. -- jason at gcc dot gnu dot org changed: What|Removed

[Bug c++/34944] Tree check: at cp/typecheck.c

--- Comment #3 from jason at gcc dot gnu dot org 2008-01-23 21:24 --- Subject: Bug 34944 Author: jason Date: Wed Jan 23 21:23:32 2008 New Revision: 131765 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131765 Log: PR bootstrap/34944 Modified: branches/gcc-4_2-branch

[Bug libgomp/28482] Cannot use libgomp in shared library

--- Comment #8 from peter dot waller at gmail dot com 2008-01-23 21:15 --- Still no sign of 4.2 fix? -- peter dot waller at gmail dot com changed: What|Removed |Added

[Bug c++/34948] New: += operator on pointers with a function call having side effects on the right hand side

The problem is shown by the following code: basically, when using the += operator on a pointer which is the member of a class as in a line like below: a.myptr += a.SideEffect(); if the a.myptr pointer is modified by the a.SideEffect() call, the += still takes into account only the old po

[Bug middle-end/32395] false positive warning about use of uninitialized variable.

--- Comment #14 from pluto at agmk dot net 2008-01-23 21:01 --- > :-( I cannot compile this testcase please try the latest testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32395

[Bug target/34916] [4.3 Regression] gcc.c-torture/execute/pr27364.c fails with -O1, -O2 and -Os

-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34916

[Bug c++/34944] Tree check: at cp/typecheck.c

--- Comment #2 from aj at gcc dot gnu dot org 2008-01-23 20:43 --- Note: This appears with *both* x86_64-unknown-linux-gnu and powerpc64-suse-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34944

[Bug c++/34824] [4.1/4.2/4.3 Regression] ICE with explicit copy constructor

--- Comment #7 from jakub at gcc dot gnu dot org 2008-01-23 20:26 --- *** Bug 28475 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug c++/28475] [4.1/4.2/4.3 Regression] Internal error: Segmentation fault (program cc1plus)

--- Comment #5 from jakub at gcc dot gnu dot org 2008-01-23 20:26 --- *** This bug has been marked as a duplicate of 34824 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added --

[Bug c/34947] New: Clobbered float registers not popped

This problem is about functions that push some float registers at the beginning, but forget to pop them at the end. The stack pointer is not adjusted as expected, so the function return to an invalid address. It appears when the following is true: - the file is compiled with -m68020-60 -O1 -fomit-

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

--- Comment #146 from jv244 at cam dot ac dot uk 2008-01-23 19:30 --- (In reply to comment #145) > current gfortran trunk seems to fail on CVS sources of CP2K with: PR34946 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975

[Bug fortran/34946] internal compiler error: in gfc_trans_create_temp_array, at fortran/trans-array.c:592

--- Comment #1 from jv244 at cam dot ac dot uk 2008-01-23 19:25 --- Created an attachment (id=15010) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15010&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34946

[Bug fortran/34946] New: internal compiler error: in gfc_trans_create_temp_array, at fortran/trans-array.c:592

GNU Fortran (GCC) 4.3.0 20080121 (experimental) [trunk revision 131689] yields > gfortran -ffree-form bug.F bug.F: In function ‘rs_grid_create’: bug.F:147: internal compiler error: in gfc_trans_create_temp_array, at fortran/trans-array.c:592 Please submit a full bug report, with preprocessed sourc

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

--- Comment #145 from jv244 at cam dot ac dot uk 2008-01-23 19:02 --- current gfortran trunk seems to fail on CVS sources of CP2K with: /data03/vondele/clean/cp2k/src/../src/realspace_grid_types.F: In function ‘rs_grid_create’: /data03/vondele/clean/cp2k/src/../src/realspace_grid_types.

[Bug target/34916] [4.3 Regression] gcc.c-torture/execute/pr27364.c fails with -O1, -O2 and -Os

--- Comment #6 from manu at gcc dot gnu dot org 2008-01-23 18:37 --- Regressions should have a target milestone -- manu at gcc dot gnu dot org changed: What|Removed |Added

[Bug other/31405] [4.3] fixincludes needed for wchar from glibc 2.3.6

--- Comment #1 from manu at gcc dot gnu dot org 2008-01-23 18:36 --- Regressions should have a target milestone. -- manu at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug target/31070] [4.1/4.2/4.3] ICE in function_arg_slotno

--- Comment #3 from manu at gcc dot gnu dot org 2008-01-23 18:35 --- Regressions should have a target milestone -- manu at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/28475] [4.1/4.2/4.3 Regression] Internal error: Segmentation fault (program cc1plus)

--- Comment #4 from manu at gcc dot gnu dot org 2008-01-23 18:34 --- Regressions should have a target milestone -- manu at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/34784] [4.2/4.3 Regression] implicit character(s) hides type of selected_int_kind intrinsic

--- Comment #8 from dick dot hendrickson at gmail dot com 2008-01-23 18:31 --- Subject: Re: [4.2/4.3 Regression] implicit character(s) hides type of selected_int_kind intrinsic I have another example of what might be the same problem, although the symptoms are a little different. the

[Bug other/31955] [4.2/4.3 regression] gcc_release does not generate HTML files from install manual

-- manu at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31955

[Bug other/31955] [4.2/4.3 regression] gcc_release does not generate HTML files from install manual

--- Comment #5 from manu at gcc dot gnu dot org 2008-01-23 18:13 --- I think this is a regression since it used to work in GCC 4.0.0 and 4.1.0. >From the duplicated report: gcc_release is supposed to generate html files in HTML/ from gcc/doc/install.texi for release candidates and fina

[Bug c/34389] -Wconversion produces wrong warning

--- Comment #5 from manu at gcc dot gnu dot org 2008-01-23 18:00 --- I don't think this will be fixed before GCC 4.3 is released, which is a shame. But if anyone has a suggestion on how to fix this, I will try to submit a patch ASAP. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34

[Bug libgcj/31700] [JNI] -X options not recognised by JNI_CreateJavaVM

--- Comment #5 from tromey at gcc dot gnu dot org 2008-01-23 17:59 --- Fix checked in a while ago. -- tromey at gcc dot gnu dot org changed: What|Removed |Added

[Bug rtl-optimization/34902] Wrong code on -O3

--- Comment #8 from manu at gcc dot gnu dot org 2008-01-23 17:57 --- (In reply to comment #7) > This is bison 2.0. > The latest version is 2.3. If haven't found anything in the ChangeLog which > sounds like there was a bug fix in this area. > You should really try bison 2.3 just in cas

[Bug fortran/34945] New: LBOUND fails for array with KIND(complex) used in zero-sized dimension

With compiler gcc version 4.3.0 20080109 (experimental) [trunk revision 131426] (GCC) I get the following error message >gfortran vf0009.f vf0009.f: In function 'vf0009': vf0009.f:11: error: size of variable 'test_array' is too large If I replace the second line in the declaration of test_array

[Bug bootstrap/34944] Tree check: at cp/typecheck.c

--- Comment #1 from aj at gcc dot gnu dot org 2008-01-23 17:30 --- configure line is: # /cvs/gcc-svn/branches/gcc-4_2-branch/configure --prefix=/opt/gcc/4.2-devel --enable-checking=yes,rtl --enable-threads=posix --enable-clocale=gnu --enable-ssp --disable-libssp --enable-libstdcxx-allo

[Bug bootstrap/34944] New: Tree check: at cp/typecheck.c

On both Linux/x86-64 and Linux/ppc I get an tree check error bootstrapping current GCC 4.2 SVN: /abuild/aj/gcc/powerpc64-suse-linux-gnu/libstdc++-v3/include/bits/cpp_type_traits.h:3 71: internal compiler error: tree check: expected class ‘type’, have ‘declaration’ (n amespace_decl) in complete_typ

[Bug tree-optimization/34940] contained subroutines called only once are not inlined

--- Comment #5 from jv244 at cam dot ac dot uk 2008-01-23 17:22 --- just a note, ifort does inline the function cs1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940

[Bug middle-end/34934] -O1 crash compile *** glibc detected *** /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1: double free or corruption (!prev)

--- Comment #6 from Ralf dot Wildenhues at gmx dot de 2008-01-23 17:12 --- With the patch I get this: xgcc -m32 -O1 -c send_tiny.i send_tiny.i: In function ‘sendto_realops_lev’: send_tiny.i:77: warning: incompatible implicit declaration of built-in function ‘strlen’ send_tiny.i:25: in

[Bug debug/34895] [4.1/4.2/4.3 Regression] ICE in force_type_die, at dwarf2out.c:12923

--- Comment #6 from matz at gcc dot gnu dot org 2008-01-23 16:54 --- Fixed. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|NEW

[Bug c++/34829] [4.3 Regression] placement new with primitive Java types rejected

--- Comment #10 from pinskia at gcc dot gnu dot org 2008-01-23 16:49 --- (In reply to comment #9) > Reopened while I look at the new problem > Jakub fixed it last night with: Author: jakub Date: Wed Jan 23 08:33:22 2008 New Revision: 131756 URL: http://gcc.gnu.org/viewcvs?root=gcc&v

[Bug tree-optimization/34943] -fno-strict-overflow fails to prevent use of signed overflow

--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-23 16:48 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC|

[Bug tree-optimization/34943] -fno-strict-overflow fails to prevent use of signed overflow

--- Comment #1 from ian at airs dot com 2008-01-23 16:46 --- Created an attachment (id=15009) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15009&action=view) Proposed patch I believe that this is the correct patch for this bug. This should be tested and committed for gcc 4.4.

[Bug tree-optimization/34943] New: -fno-strict-overflow fails to prevent use of signed overflow

Consider this C test case: const char * f(long v) { if (v < 0) v = - v; if (v > 0x7fff) return "negative"; else return "positive"; } When this is compiled with -O2, it always returns "positive". This is fine because when v == LONG_MIN, negating it is undefined signed overfl

[Bug debug/34895] [4.1/4.2/4.3 Regression] ICE in force_type_die, at dwarf2out.c:12923

--- Comment #5 from matz at gcc dot gnu dot org 2008-01-23 16:45 --- Subject: Bug 34895 Author: matz Date: Wed Jan 23 16:44:27 2008 New Revision: 131761 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131761 Log: PR debug/34895 * dwarf2out.c (force_type_die): Use

[Bug c++/34829] [4.3 Regression] placement new with primitive Java types rejected

--- Comment #9 from tromey at gcc dot gnu dot org 2008-01-23 16:43 --- Reopened while I look at the new problem -- tromey at gcc dot gnu dot org changed: What|Removed |Added --

[Bug fortran/32760] [4.3 Regression] Error defining subroutine named PRINT

--- Comment #21 from burnus at gcc dot gnu dot org 2008-01-23 16:36 --- Another test case module m public :: volatile contains subroutine foo volatile :: bar end subroutine foo subroutine volatile end subroutine volatile end module -- http://gcc.gnu.org/bugzilla/show_

[Bug c++/34937] [4.1/4.2/4.3 regression] ICE with attribute weak

--- Comment #2 from steven at gcc dot gnu dot org 2008-01-23 16:30 --- What would be the semantics of "weak" on a template member? That is, how would the weak reference be overridden? What I'm looking for is an example of what GCC did with this declaration when it was still accepted.

[Bug c++/34935] [4.3 regression] ICE with attribute may_alias

--- Comment #2 from steven at gcc dot gnu dot org 2008-01-23 16:20 --- CCing the canonical type expert. -- steven at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/34942] New: -frepo only works with C locale

[forwarded from http://bugs.debian.org/426809] seen with trunk 20080123 another possibility might be to unset the locale, or set it to C Matthias The g++ -frepo option only works with C locale, not with es_UY for example. A possible test case is: template class C { public: C

[Bug preprocessor/34692] [4.2/4.3 regression] Internal error with pragma in macro

--- Comment #4 from jakub at gcc dot gnu dot org 2008-01-23 15:59 --- Testing a patch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|una

[Bug middle-end/34921] Misalign stack variable referenced by nested function

--- Comment #6 from hjl dot tools at gmail dot com 2008-01-23 15:47 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-01/msg01062.html -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

[Bug tree-optimization/34940] contained subroutines called only once are not inlined

--- Comment #4 from jv244 at cam dot ac dot uk 2008-01-23 15:45 --- (In reply to comment #2) > It's considered too big and it's not static. > not sure if my C is good enough to reply, but CS1 is visible only from within the subroutine S1. That's somewhat similar to (or stricter than) '

[Bug c/34720] ICE in real_to_decimal, at real.c:1656

--- Comment #4 from tgall dot foo at gmail dot com 2008-01-23 15:28 --- Hi Ben, Yesterday I picked this up again using the 0118 snapshot. Same failure. Yes this is being built inside of portage. No patches are being applied. (I've disabled that) Following the direction of Peter Bergn

[Bug fortran/32760] [4.3 Regression] Error defining subroutine named PRINT

-- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot |

[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions

--- Comment #60 from joel at gcc dot gnu dot org 2008-01-23 15:12 --- I did a build of powerpc-rtems4.9 on the trunk and it built much more quickly. I haven't had a chance to run the ACATS yet to check run-time behavior. Thanks for all the effort for this one. -- http://gcc.gnu.or

[Bug tree-optimization/26854] Inordinate compile times on large routines

--- Comment #61 from lucier at math dot purdue dot edu 2008-01-23 15:03 --- Subject: Re: Inordinate compile times on large routines Kenny: Even after you backed out this latest patch the CPU usage was down (to 203 seconds from 280 seconds on my machine) and the maximum memory usa

[Bug c/34941] New: Option to warn on printf of ptrdiff_t without t size modifier

[forwarded from http://bugs.debian.org/425623] This code: #include int main(int argc, char *argv[]) { void *a, *b; printf("%d\n", a - b); return 0; } will generate this warning on a 64-bit platform: temp.c:5: warning: format ‘%d’ expects type ‘int’, but argument 2 has t

[Bug bootstrap/33396] add --enable-intermodule

--- Comment #7 from aldot at gcc dot gnu dot org 2008-01-23 14:41 --- Created an attachment (id=15008) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15008&action=view) libgcc patch #2 Updated patch -- aldot at gcc dot gnu dot org changed: What|Removed

[Bug middle-end/8081] ICE with variably sized types and nested functions

--- Comment #19 from debian-gcc at lists dot debian dot org 2008-01-23 14:38 --- $ gcc-4.3 --version gcc-4.3 (Debian 4.3-20080116-1) 4.3.0 20080116 (experimental) [trunk revision 131577] Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying

[Bug c++/33887] [4.1/4.2/4.3 Regression] Reference to bitfield gets wrong value when optimizing

--- Comment #32 from rguenth at gcc dot gnu dot org 2008-01-23 14:24 --- Patches pending for review: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00862.html http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00951.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887

[Bug middle-end/31529] [4.3 Regression] ICE in cgraph_expand_function with IMA

--- Comment #13 from rguenth at gcc dot gnu dot org 2008-01-23 14:20 --- Subject: Bug 31529 Author: rguenth Date: Wed Jan 23 14:20:07 2008 New Revision: 131758 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131758 Log: 2008-01-23 Richard Guenther <[EMAIL PROTECTED]>

[Bug middle-end/31529] [4.3 Regression] ICE in cgraph_expand_function with IMA

--- Comment #12 from rguenth at gcc dot gnu dot org 2008-01-23 14:20 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNE

[Bug tree-optimization/34940] contained subroutines called only once are not inlined

--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-23 13:55 --- Considering cs1 with 52 insns to be inlined into s1 Estimated growth after inlined into all callees is -13 insns. Estimated badness is 86, frequency 1.00. Not inlining into s1:--param large-stack-frame-growth lim

[Bug tree-optimization/34940] contained subroutines called only once are not inlined

--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-23 13:54 --- It's considered too big and it's not static. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940

  1   2   >