[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23

--- Comment #15 from bonzini at gnu dot org 2009-08-07 07:24 --- Subject: Re: version 150336 broke bootstrap on ia64-hp-hpux11.23 > After applying the most recent patch the ia64 bootstrap started working but > the > pa bootstrap (hppa2.0w-hp-hpux11.11) started failing. The stage2/st

[Bug fortran/29785] Fortran 2003: POINTER Rank Remapping

--- Comment #3 from jv244 at cam dot ac dot uk 2009-08-07 07:35 --- still missing 4.5.0, this seems a particularly useful F03 feature ;-) For an expert, should be 'easy' to add (ignoring the F2008 variant) ? -- jv244 at cam dot ac dot uk changed: What|Removed

[Bug c/40987] Wrong optimization with if-conversion

--- Comment #7 from thomas at coware dot com 2009-08-07 07:37 --- This is how function func looks after the if conversion (test.c.144r.ce1): (note 4 0 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK) (insn 2 4 3 2 test.c:3 (set (reg/v:SI 63 [ arg ]) (mem/c/i:SI (reg/f:SI 16 argp) [0 arg+0 S4

[Bug fortran/40994] New: ICE with BIND(C)

The following semi-invalid code ICEs (but compiles fine with ifort): MODULE f03_test USE, INTRINSIC :: ISO_C_BINDING INTERFACE FUNCTION build(lib, np) BIND(C) END FUNCTION END INTERFACE PROCEDURE(build), POINTER :: pbuild CONTAINS SUBROUTINE test_asc() END SUBROUTINE te

[Bug fortran/40995] New: Spurious "Type specified for intrinsic function...ignored" message

> uname -a Linux loanamd25 2.6.16.46-0.10-smp #1 SMP Mon May 7 13:37:05 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux > gfortran --version GNU Fortran (GCC) 4.5.0 20090730 (experimental) > cat type.f90 subroutine sub(n,x) intrinsic abs integer n, x(abs(n)) end > gfortran -Wall -c type.f90 type.f90:2.1

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

--- Comment #4 from paolo dot carlini at oracle dot com 2009-08-07 08:22 --- Nice that we have a workaround, still, the problem should not happen anyway: in normal builds on x86_64-linux, no fenv.h is generated during the build and the one provided by the underlying libc is of course fi

[Bug regression/40886] [4.3/4.4/4.5 Regression] No loop counter reversal for simple loops anymore

--- Comment #3 from rakdver at gcc dot gnu dot org 2009-08-07 08:44 --- (In reply to comment #1) > The tree optimizers canonicalize the loop to > > : > # i_5 = PHI > # ivtmp.23_1 = PHI > f2 (); > i_3 = i_5 + 1; > ivtmp.23_4 = ivtmp.23_1 - 1; > if (ivtmp.23_4 != 0) > go

[Bug regression/40886] [4.3/4.4/4.5 Regression] No loop counter reversal for simple loops anymore

--- Comment #4 from andi-gcc at firstfloor dot org 2009-08-07 08:50 --- The RTL loop optimizer does this optimization. I had to fix it a couple of years ago for unsigned variables. I think the loop optimizer still does it, just the gcc 4 frontend doesn't give it input RTL with a suitab

[Bug regression/40886] [4.3/4.4/4.5 Regression] No loop counter reversal for simple loops anymore

--- Comment #5 from rakdver at kam dot mff dot cuni dot cz 2009-08-07 08:54 --- Subject: Re: [4.3/4.4/4.5 Regression] No loop counter reversal for simple loops anymore > The RTL loop optimizer does this optimization. I had to fix it a couple > of years ago for unsigned variables. >

[Bug tree-optimization/36127] bad choice of loop IVs above -Os on x86

--- Comment #7 from rguenth at gcc dot gnu dot org 2009-08-07 08:32 --- Err, that's not exactly a fix for -O2/-O3 ;) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/40996] New: [F03] ALLOCATABLE scalars

The ALLOCATABLE attribute was only allowed for arrays in F95, but F03 also allows allocatable scalars (which will be useful for polymorphism). Simple example: real, allocatable :: scalar allocate(scalar) scalar = exp(1.) print *,scalar deallocate(scalar) end With current trunk you get: as.f90:

[Bug fortran/40994] ICE with BIND(C)

--- Comment #1 from jv244 at cam dot ac dot uk 2009-08-07 09:15 --- for reference: elete_root (t=0x1306d40) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/bbt.c:149 149 if (t->left->priority > t->right->priority) (gdb) bt #0 delete_root (t=0x1306d40) at /data03/vondele/gcc_trunk/gc

[Bug fortran/40994] ICE with BIND(C)

--- Comment #2 from janus at gcc dot gnu dot org 2009-08-07 09:27 --- Before the ICE one gets the error: SUBROUTINE test_bind_c BIND(C,name="test_bind_c") 1 Error: Missing required parentheses before BIND(C) at (1) If this error is cor

[Bug regression/40886] [4.3/4.4/4.5 Regression] No loop counter reversal for simple loops anymore

--- Comment #6 from andi-gcc at firstfloor dot org 2009-08-07 09:38 --- It worked on x86 at least -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40886

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

--- Comment #5 from bonzini at gnu dot org 2009-08-07 09:46 --- No, the build system should support everything; not just host==target != build which is not so uncommon -- for example this is how cygwin worked before it could host GCC -- but even the admittedly crazy target==build != host

[Bug regression/40886] [4.3/4.4/4.5 Regression] No loop counter reversal for simple loops anymore

--- Comment #7 from steven at gcc dot gnu dot org 2009-08-07 09:47 --- Re. comment #6: doloop never worked on x86 except for the AMD K6. x86 does not have a doloop pattern. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40886

[Bug regression/40886] [4.3/4.4/4.5 Regression] No loop counter reversal for simple loops anymore

--- Comment #8 from andi-gcc at firstfloor dot org 2009-08-07 09:52 --- At least my example in the original bug description shows that the optimization worked on gcc 3.3. If your theory doesn't explain this then your theory is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40

[Bug c++/39987] [4.3/4.4/4.5 Regression] Rejects default argument that is a template via access failure

--- Comment #5 from mikpe at it dot uu dot se 2009-08-07 10:06 --- The test case doesn't appear to be in the repository. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39987

[Bug fortran/40994] ICE with BIND(C)

--- Comment #3 from jv244 at cam dot ac dot uk 2009-08-07 10:11 --- (In reply to comment #2) > Before the ICE one gets the error: > > SUBROUTINE test_bind_c BIND(C,name="test_bind_c") > 1 that's why I called the testcase semi-invalid.

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

--- Comment #6 from paolo dot carlini at oracle dot com 2009-08-07 10:12 --- Paolo, if you could help, it would be great. About the driver, really I have no idea. And I have never seen that almost-empty generated fenv.h, if it's really happening maybe the library-proper isn't at fault..

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

--- Comment #7 from bonzini at gnu dot org 2009-08-07 10:45 --- What's the content of gcc/fenv.h in the build directory? If I have to guess, I'd suppose it's generated by fixincludes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug c++/40997] New: Wrong adress returned in covariant return

Linux buildhost 2.6.30.1amd64-kvm #1 SMP Tue Jul 7 10:55:30 UTC 2009 x86_64 GNU/Linux ../gcc-4.4.1/configure --disable-multilib --enable-languages=c,c++ (Also found to fail with gcc4.3.4 (64bit), gcc4.3.2 (32bit)) Test.cpp: #include #include using std::cout; using std::endl; class BaseIf { pu

[Bug fortran/40996] [F03] ALLOCATABLE scalars

--- Comment #1 from janus at gcc dot gnu dot org 2009-08-07 11:22 --- The following is enough to make the test case work: Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c (revision 150529) +++ gcc/fortran/re

[Bug fortran/40996] [F03] ALLOCATABLE scalars

--- Comment #2 from burnus at gcc dot gnu dot org 2009-08-07 11:48 --- Of cause, you need to add a -std=f95 check - and one should do some thinking/testing whether other items are missing. There are some other related issues, which should be handled separately: - Allocate on assignment

[Bug fortran/40996] [F03] ALLOCATABLE scalars

--- Comment #3 from janus at gcc dot gnu dot org 2009-08-07 11:54 --- (In reply to comment #2) > and one should do some thinking/testing whether other items are missing. One things which is missing is the ALLOCATED intrinsic. Working on it ... -- http://gcc.gnu.org/bugzilla/show_bu

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

--- Comment #8 from booleandomain at gmail dot com 2009-08-07 11:58 --- Created an attachment (id=18316) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18316&action=view) x86_64-unknown-linux-gnu/libstdc++-v3/include/fenv.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

--- Comment #9 from booleandomain at gmail dot com 2009-08-07 12:00 --- Created an attachment (id=18317) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18317&action=view) x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1/fenv.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=409

[Bug c++/40997] Wrong address returned in covariant return

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-08-07 12:01 --- What is the expected output and what is the wrong output you see? The Intel compiler produces bas...@0x7fffdd88 b...@0x7fffdd98 bart: 0x7fffdd88 baseIf: 0x7fffdd88 bar:0x7fffdd98 baseIf2:0

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

--- Comment #10 from booleandomain at gmail dot com 2009-08-07 12:03 --- Created an attachment (id=18318) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18318&action=view) build-stage1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

[Bug fortran/40995] [4.5 Regression] Spurious "Type specified for intrinsic function...ignored" message

--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-07 12:06 --- Confirmed. Thanks for the report. Janus, I think it is another side effect of your intrinsic patches. In 4.4 attr.implicit_type is "1" but now on 4.5 it is "0". ts is set in resolve_intrinsic. Maybe it was no additio

[Bug tree-optimization/40992] [4.2/4.3/4.4/4.5 Regression] cunroll ignoring asm size

--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-07 12:06 --- asms are predicted to have a small size/cost because they should be used to implement single instructions that cannot be mapped to C easily. No easy way out without pessimizing more legitimate uses of asms. --

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

--- Comment #11 from booleandomain at gmail dot com 2009-08-07 12:10 --- There is no gcc/fenv.h in the build directory. I attached the only fenv.h files I could find in it. I attached the script I use for building the cross-toolchain, too. I slightly modified the build process: I remove

[Bug rtl-optimization/40987] Wrong optimization with if-conversion

--- Comment #8 from rguenth at gcc dot gnu dot org 2009-08-07 12:10 --- Seems to be a HWI32 issue as I cannot reproduce the fail on x86_64 with -m32. Which would indeed hint at a RTL if-conversion problem (I guess it uses scc in a wrong way). -- rguenth at gcc dot gnu dot org changed

[Bug fortran/40996] [F03] ALLOCATABLE scalars

--- Comment #4 from janus at gcc dot gnu dot org 2009-08-07 12:11 --- (In reply to comment #3) > > and one should do some thinking/testing whether other items are missing. > > One things which is missing is the ALLOCATED intrinsic. Working on it ... Also: allocatable scalar components

[Bug tree-optimization/40991] [4.5 Regression] ICE: at optimization -02

--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-07 12:13 --- It ICEs during PRE. Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/40997] Wrong address returned in covariant return

--- Comment #2 from jwakely dot gcc at gmail dot com 2009-08-07 12:26 --- The line before the assertion shows the address of the 'Bar' subobject, which is not the same value as previously given for that subobject (on the 2nd and 5th lines of output.) Like the reporter, I expected the l

[Bug c++/40997] Wrong address returned in covariant return

--- Comment #3 from jwakely dot gcc at gmail dot com 2009-08-07 12:31 --- Adding this to Bart::InnerBart::getOuter(): cout << "BaseIf1: " << (BaseIf*)&outer << endl; and this to Bar::InnerBar::getVal(): cout << "BaseIf2: " << (BaseIf*)&bar << endl; shows diff

[Bug tree-optimization/40991] [4.5 Regression] ICE: at optimization -02

--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-07 12:41 --- Created an attachment (id=18319) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18319&action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40991

[Bug c++/40997] Wrong address returned in covariant return

--- Comment #4 from jwakely dot gcc at gmail dot com 2009-08-07 12:42 --- Ah, [class.virtual] paragraph 5 says: If the return type of D::f differs from the return type of B::f, the class type in the return type of D::f shall be complete at the point of declaration of D::f or shall be th

[Bug c++/40997] Wrong address returned in covariant return

--- Comment #5 from jwakely dot gcc at gmail dot com 2009-08-07 12:47 --- Moving the definition of InnerBart outside the body of Bart (which requires making Bart::createInner non-covariant) allows the assertion to pass, the addresses are all correct. So I believe this program is invali

[Bug fortran/40998] New: Source with routine in CONTAINS section and a local variable: No symbol "nerr" in current context

The following source, compiled with a recent 4.5 snapshot using -ggdb as the only compiler option: MODULE x04aafe_aux IMPLICIT NONE CONTAINS SUBROUTINE dummy INTEGER :: nerr CALL x04aaf(0,nerr) PRINT *, 'Hello',nerr EN

[Bug tree-optimization/40999] New: ICE in extract_component, at tree-complex.c:625

We ICE there because we don't fold CONST_DECLs substituted by inlining. ./f951 -quiet -O2 -finline-functions zheev.min7.f -fwhole-file zheev.min7.f: In function 'zlarfg': zheev.min7.f:1:0: internal compiler error: in extract_component, at tree-complex.c:625 Please submit a full bug report, with pr

[Bug tree-optimization/40999] ICE in extract_component, at tree-complex.c:625

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-08-07 12:56 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned

[Bug c/41000] New: Optional optimization error�@(m32r-elf)

I use m32r-elf. When optional optimization was applied, the value is 25536. If there is no optional optimization, the value is -4. command -- u...@user-laptop:~/study/error/m32r$ /usr/local/gcc-4.4.1_m32r-elf/bin/m32r-elf-gcc m32r.c u...@u

[Bug c/41000] Optional optimization error�@(m32r-elf)

--- Comment #1 from n-takeda at kwansei dot ac dot jp 2009-08-07 12:58 --- Created an attachment (id=18320) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18320&action=view) c program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41000

[Bug c++/40997] Wrong address returned in covariant return

--- Comment #6 from jwakely dot gcc at gmail dot com 2009-08-07 12:59 --- (In reply to comment #4) > Ah, [class.virtual] paragraph 5 says: > If the return type of D::f differs from the return type of B::f, the class > type > in the return type of D::f shall be complete at the point of

[Bug c/41000] Optional optimization error�@(m32r-elf)

--- Comment #2 from n-takeda at kwansei dot ac dot jp 2009-08-07 13:00 --- Created an attachment (id=18321) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18321&action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41000

[Bug c/40989] -Werror= and #pragma diagnostics do not work with group flags

--- Comment #2 from manu at gcc dot gnu dot org 2009-08-07 13:07 --- This is because neither Werror= nor #pragma GCC diagnositcs work with "group flags", that is, flags that enable other flags. Until this is fixed, you need to give exactly the flag reported by -fdiagnostics-show-option

[Bug tree-optimization/40999] ICE in extract_component, at tree-complex.c:625

--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-07 13:07 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords|

[Bug c++/39987] [4.3/4.4/4.5 Regression] Rejects default argument that is a template via access failure

--- Comment #6 from dodji at gcc dot gnu dot org 2009-08-07 13:13 --- Subject: Bug 39987 Author: dodji Date: Fri Aug 7 13:13:12 2009 New Revision: 150568 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150568 Log: 2009-08-07 Dodji Seketeli PR c++/39987 * gcc/

[Bug c++/39987] [4.3/4.4/4.5 Regression] Rejects default argument that is a template via access failure

--- Comment #7 from dodji at gcc dot gnu dot org 2009-08-07 13:16 --- Subject: Bug 39987 Author: dodji Date: Fri Aug 7 13:15:43 2009 New Revision: 150569 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150569 Log: 2009-08-07 Dodji Seketeli PR c++/39987 * gcc/

[Bug c++/39987] [4.3/4.4/4.5 Regression] Rejects default argument that is a template via access failure

--- Comment #8 from dodji at gcc dot gnu dot org 2009-08-07 13:16 --- Subject: Re: [4.3/4.4/4.5 Regression] Rejects default argument that is a template via access failure Le 07/08/2009 12:06, mikpe at it dot uu dot se a écrit : > --- Comment #5 from mikpe at it dot uu dot se 2009

[Bug c++/40866] [4.5 Regression] ICE in create_tmp_var, at gimplify.c:504

--- Comment #4 from dodji at gcc dot gnu dot org 2009-08-07 13:20 --- Subject: Re: New: [4.5 Regression] ICE in create_tmp_var, at gimplify.c:504 Patch posted at http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00428.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40866

[Bug fortran/40995] [4.5 Regression] Spurious "Type specified for intrinsic function...ignored" message

--- Comment #2 from janus at gcc dot gnu dot org 2009-08-07 13:25 --- (In reply to comment #1) > Janus, I think it is another side effect of your intrinsic patches. Probably yes. But: I have a patch (regtesting right now). -- janus at gcc dot gnu dot org changed: What

[Bug fortran/40995] [4.5 Regression] Spurious "Type specified for intrinsic function...ignored" message

--- Comment #3 from janus at gcc dot gnu dot org 2009-08-07 13:27 --- Created an attachment (id=18322) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18322&action=view) patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40995

[Bug target/41000] Optional optimization error

--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-07 13:39 --- I guess m32c implements a widening multiplication that isn't correctly implemented. Because (short)(40 * -1000) is exactly 25526. -- rguenth at gcc dot gnu dot org changed: What|Removed

[Bug c++/40997] Wrong address returned in covariant return

--- Comment #7 from rguenth at gcc dot gnu dot org 2009-08-07 13:40 --- EDG accepts the code in strict-ansi mode as well, without a diagnostic. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added -

[Bug fortran/40998] Source with routine in CONTAINS section and a local variable: No symbol "nerr" in current context

--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-07 13:57 --- I think there is a general GCC 4.5 problem with debugging symbols. I opened a PR about this (PR 40660) - which is regarding Fortran - but there was recently also GCC complaining at #gcc about this issue when debugging

[Bug fortran/40995] [4.5 Regression] Spurious "Type specified for intrinsic function...ignored" message

--- Comment #4 from janus at gcc dot gnu dot org 2009-08-07 14:14 --- The attached patch regresses on: FAIL: gfortran.dg/gamma_2.f90 -O (test for excess errors) FAIL: gfortran.dg/intrinsic_subroutine.f90 -O (test for errors, line 6) FAIL: gfortran.dg/intrinsic_subroutine.f90 -O (

[Bug fortran/40998] Source with routine in CONTAINS section and a local variable: No symbol "nerr" in current context

--- Comment #2 from burnus at gcc dot gnu dot org 2009-08-07 14:23 --- Hmm, actually your example works here: (gdb) b 7 Breakpoint 1 at 0x4007a0: file hjff.f90, line 7. (gdb) run [...] Breakpoint 1, dummy () at hjff.f90:7 7 PRINT *, 'Hello',nerr (gdb) p nerr $1 = 666 Th

Variables in Specified Registers

Hello, Following code (written just for fun) leads to: Program received signal SIGSEGV, Segmentation fault. main () at main-general.cpp:95 95 printf("%d\n", x_reg); BTW, there is warning when using ecx, eax, edx. should there be any warning for esp? GCC 4.4 X86 Compile flags: -g3

[Bug fortran/40998] Source with routine in CONTAINS section and a local variable: No symbol "nerr" in current context

--- Comment #3 from burnus at gcc dot gnu dot org 2009-08-07 14:32 --- The result of eu-readelf looks OK, however, since I read "module" for item 175, I wonder whether this is a problem that gdb is too old. There was a change (I think in the later stages of 4.4.0) which wrote the proper

[Bug debug/40660] [4.5 Regression] Wierd break points with 4.5, works with 4.4

--- Comment #2 from burnus at gcc dot gnu dot org 2009-08-07 14:41 --- Using 4.5.0 20090805 with GDB 6.8.50.20090803-10.1 (includes patches of Fedora/Jan Kratochvil which support F90 arrays/C99 VLA and module variables), the result is now: Breakpoint 1, test () at fhjf.f90:3 3 a

[Bug middle-end/41001] New: alloca broken for -fno-builtin

The function alloca (for cygwin/mingw target _alloca) is broken or not available (for linux64), when using option -fno-builtin. The linux and win32 targets the symbol alloca isn't present. For windows targets there is an implementation (_alloca) in gcc/config/i386/cygwin.asm present. But when usin

[Bug fortran/40995] [4.5 Regression] Spurious "Type specified for intrinsic function...ignored" message

--- Comment #5 from janus at gcc dot gnu dot org 2009-08-07 15:37 --- Created an attachment (id=18323) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18323&action=view) updated patch Updating patch to take care of the two observed regressions. -- janus at gcc dot gnu dot org ch

[Bug middle-end/41001] alloca broken for -fno-builtin

--- Comment #1 from ktietz at gcc dot gnu dot org 2009-08-07 15:38 --- Created an attachment (id=18324) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18324&action=view) Testcase for alloca/_alloca to be compiled with option -fno-builtins -- http://gcc.gnu.org/bugzilla/show_bu

[Bug fortran/40995] [4.5 Regression] Spurious "Type specified for intrinsic function...ignored" message

--- Comment #6 from janus at gcc dot gnu dot org 2009-08-07 15:46 --- (In reply to comment #1) > When fixing it, one should make sure that > intrinsic abs > real abs > still prints a warning with -Wsurprising. This is done by intrinsic.f90 and intrinsic_2.f90 in the testsuite. --

[Bug fortran/40998] Source with routine in CONTAINS section and a local variable: No symbol "nerr" in current context

--- Comment #4 from burnus at gcc dot gnu dot org 2009-08-07 16:00 --- > There was a change (I think in the later stages of 4.4.0) which wrote the > proper > DWARF_MODULE* to the ELF binary. However, gdb did ignore that bit. > There was a fix for the gdb trunk See: http://sourceware.o

[Bug fortran/40993] Empty error message with long lines

--- Comment #1 from jvdelisle at gcc dot gnu dot org 2009-08-07 16:06 --- The problem is that the error locus is at the end of the line rather then the end of the non-whitespace characters of the related statement. -- jvdelisle at gcc dot gnu dot org changed: What|Re

[Bug target/41000] Optional optimization error

--- Comment #4 from dj at redhat dot com 2009-08-07 16:26 --- m32c != m32r -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41000

[Bug target/32895] Clobber list isn't working

--- Comment #6 from eric dot weddington at atmel dot com 2009-08-07 16:38 --- The test case works for me on AVR GCC 4.3.2 using -Wall and -O[0123s]. Closing bug. -- eric dot weddington at atmel dot com changed: What|Removed |Added

[Bug fortran/40998] Source with routine in CONTAINS section and a local variable: No symbol "nerr" in current context

--- Comment #5 from toon at moene dot org 2009-08-07 16:58 --- Could indeed be the version of gdb. Mine is: $ gdb -v GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software:

[Bug tree-optimization/40999] ICE in extract_component, at tree-complex.c:625

--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-07 17:02 --- Subject: Bug 40999 Author: rguenth Date: Fri Aug 7 17:02:43 2009 New Revision: 150572 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150572 Log: 2009-08-07 Richard Guenther PR tree-optimization/

[Bug tree-optimization/40999] ICE in extract_component, at tree-complex.c:625

--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-07 17:19 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug middle-end/41001] alloca broken for -fno-builtin

--- Comment #2 from joseph at codesourcery dot com 2009-08-07 17:24 --- Subject: Re: New: alloca broken for -fno-builtin On Fri, 7 Aug 2009, ktietz at gcc dot gnu dot org wrote: > The function alloca (for cygwin/mingw target _alloca) is broken or not > available (for linux64), when u

[Bug debug/40660] [4.5 Regression] Wierd break points with 4.5, works with 4.4

--- Comment #3 from jv244 at cam dot ac dot uk 2009-08-07 17:28 --- Is there some meta-bug about Fortran-related debug issues? I've added PR 40823 about another debug issue. It likely requires a FE fix, so the component 'debug' is somewhat too vague. -- http://gcc.gnu.org/bugzilla/s

[Bug c++/41002] New: Redundant diagnostic when class member function's name overlaps with class field's name

Compiling following code [1] in the following way [2] with gcc 4.3.3 leads to the diagnostics [3]. To my mind statement test.cpp: In constructor 'testclass::testclass()': test.cpp:4: error: class 'testclass' does not have any field named 'number' is redundant because statements test.cpp:15:

[Bug fortran/41003] New: Array constructor gives seg fault

program bug integer :: a(5) = (/1,2,3,4,5/) integer, allocatable:: b(:) b = (/ a(1:5), a(1:5) /) print *, b endprogram bug integer :: a(5) = (/1,2,3,4,5/) integer, allocatable:: b(:) b = (/ a(1:5), a(1:5) /) print *, b end The assignment to b generates a seg fault. I believe this to be standard

[Bug c++/41002] Redundant diagnostic when class member function's name overlaps with class field's name

--- Comment #1 from b0ntrict0r at yandex dot ru 2009-08-07 18:11 --- By the way using gcc instead of g++ doesn't changed things. And I've just tested this code with Comeau online C++ compiler and it gave exactly what I want to get: Comeau C/C++ 4.3.10.1 (Oct 6 2008 11:28:09) for ONLI

[Bug tree-optimization/40985] -msse -ftree-vectorize cause segfaults (zlib)

--- Comment #7 from mahatma at eu dot by 2009-08-07 18:21 --- (In reply to comment #6) > You can try my patch for PR 40838. No error. Current i386.h must be fixed by hands. Next I attach gcc-4.4.1 version of this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40985

[Bug tree-optimization/40985] -msse -ftree-vectorize cause segfaults (zlib)

--- Comment #8 from mahatma at eu dot by 2009-08-07 18:24 --- Created an attachment (id=18325) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18325&action=view) PR 40838 for gcc 4.4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40985

[Bug middle-end/20355] MEM_READONLY_P & MEM_VOLATILE_P properties are lost on BLKmode rtl operands.

--- Comment #4 from eric dot weddington at atmel dot com 2009-08-07 18:56 --- No news on this for several years. Closing as WONTFIX. -- eric dot weddington at atmel dot com changed: What|Removed |Added -

[Bug target/40112] [avr] C++, __attribute__((__progmem__)) lost in typedefs.

--- Comment #1 from eric dot weddington at atmel dot com 2009-08-07 19:16 --- *** This bug has been marked as a duplicate of 34734 *** -- eric dot weddington at atmel dot com changed: What|Removed |Added -

[Bug target/34734] attribute((progmem)) not handled properly in C++ for AVRs

--- Comment #3 from eric dot weddington at atmel dot com 2009-08-07 19:16 --- *** Bug 40112 has been marked as a duplicate of this bug. *** -- eric dot weddington at atmel dot com changed: What|Removed |Added --

[Bug target/34734] attribute((progmem)) not handled properly in C++ for AVRs

-- eric dot weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Kno

[Bug bootstrap/40923] bootstrap failure for 20090730 with --enable-build-with-cxx

--- Comment #2 from d dot g dot gorbachev at gmail dot com 2009-08-07 19:25 --- Keywords: mangling, anonymous namespaces. Adding option such as -frandom-seed=271828 to CXXFLAGS_FOR_TARGET allows to bootstrap. -- d dot g dot gorbachev at gmail dot com changed: What|R

[Bug fortran/41003] Array constructor gives seg fault

--- Comment #1 from kargl at gcc dot gnu dot org 2009-08-07 19:27 --- *** This bug has been marked as a duplicate of 35810 *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added --

[Bug fortran/35810] [TR 15581 / F2003] Automatic reallocation on assignment to allocatable variables

--- Comment #5 from kargl at gcc dot gnu dot org 2009-08-07 19:27 --- *** Bug 41003 has been marked as a duplicate of this bug. *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug middle-end/41001] alloca broken for -fno-builtin

--- Comment #3 from ktietz at gcc dot gnu dot org 2009-08-07 21:05 --- (In reply to comment #2) > Subject: Re: New: alloca broken for -fno-builtin > > On Fri, 7 Aug 2009, ktietz at gcc dot gnu dot org wrote: > > > The function alloca (for cygwin/mingw target _alloca) is broken or not

[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding

--- Comment #18 from skunk at iskunk dot org 2009-08-07 21:13 --- Confirmed correct fixincluding of if.h in the GCC 4.4.1 build. Ding, dong, this bug is dead! -- skunk at iskunk dot org changed: What|Removed |Added -

[Bug middle-end/41001] alloca broken for -fno-builtin

--- Comment #4 from joseph at codesourcery dot com 2009-08-07 22:36 --- Subject: Re: alloca broken for -fno-builtin On Fri, 7 Aug 2009, ktietz at gcc dot gnu dot org wrote: > Well, if so. It makes no sense that -fno-builtins tries to call a function > which isn't present. But for othe

[Bug target/41004] New: missed merge of basic blocks

Compile the attached source code with options -Os -march=armv5te -mthumb Gcc generates following code snippet: ... cmp r0, r2 bne .L5 b .L15<--- A .L9: ldr r3, [r1] cmp r3, #0 beq .L7 str

[Bug target/41004] missed merge of basic blocks

--- Comment #1 from carrot at google dot com 2009-08-08 00:10 --- Created an attachment (id=18326) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18326&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41004

[Bug libstdc++/41005] New: Unable to link fstream open and ctor with std::string argument.

I was trying to build a simple app and use the std::string to build an ofstream as allowed by C++-0X. The source and header allows this. You can compile but not link. I've verified this on powerpc-apple-darwin7.9.0 and on x86_64-linux-unknown. I think symbols are getting stripped out of the fin