[Bug fortran/40011] Problems with -fwhole-file
--- Comment #20 from jv244 at cam dot ac dot uk 2009-05-25 06:13 --- (In reply to comment #19) It's good news that cp2k is now OK - did the performance improve? I didn't check that, I suspect that, since everything is module based, it needs the stuff for module procedure inlining first. Right now, trunk seems broken (PR40240) and I'm busy (PR00042) so there is no need to hurry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug middle-end/40240] [4.5 regression] ICE in execute_cse_reciprocals, at tree-ssa-math-opts.c:469
--- Comment #1 from jv244 at cam dot ac dot uk 2009-05-25 07:48 --- this is likely being fixed by Ira -- jv244 at cam dot ac dot uk changed: What|Removed |Added CC||irar at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40240
[Bug tree-optimization/40238] [4.5 Regression] ICE in gimple_verify_flow_info, at tree-cfg.c:4603
--- Comment #3 from irar at gcc dot gnu dot org 2009-05-25 07:56 --- Subject: Bug 40238 Author: irar Date: Mon May 25 07:56:32 2009 New Revision: 147844 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147844 Log: PR tree-optimization/40238 * tree-vect-stmts.c (vect_init_vector): Insert initialization statements after basic block's labels. * tree-vect-slp.c (vect_slp_transform_bb): Call destroy_bb_vec_info() to free the allocated memory. Added: trunk/gcc/testsuite/gcc.dg/vect/pr40238.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c trunk/gcc/tree-vect-stmts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40238
[Bug middle-end/40240] [4.5 regression] ICE in execute_cse_reciprocals, at tree-ssa-math-opts.c:469
--- Comment #2 from irar at il dot ibm dot com 2009-05-25 08:20 --- (In reply to comment #1) this is likely being fixed by Ira I committed the fix. Could you please check if it really fixes this one as well? Thanks, Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40240
[Bug c/40241] New: ?: operator incorrectly groups left in cpp
The ?: operators are supposed to group right. In gcc they do, but in cpp they
do not (i.e., they seem to group left in #if statements).
Example:
#include iostream
using std::hex;
using std::dec;
using std::cout;
using std::endl;
int main()
{
# if ( 1 ? 0x0DFF : 3 5 ? 1ull 36 : 1ull 40 ) = 0xDFFF
cout OK GROUPING endl;
# else
# error BAD GROUPING
# endif
# if ( 1 ? 0x0DFF : ( 3 5 ? 1ull 36 : 1ull 40 ) ) = 0xDFFF
cout OK WITH UNNESSARY PARENTHESES endl;
# else
# error BAD WITH UNNECESSARY PARENTHESES
# endif
}
This outputs the BAD GROUPING error.
--
Summary: ?: operator incorrectly groups left in cpp
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: walton at seas dot harvard dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40241
[Bug middle-end/40240] [4.5 regression] ICE in execute_cse_reciprocals, at tree-ssa-math-opts.c:469
--- Comment #3 from jv244 at cam dot ac dot uk 2009-05-25 10:04 --- fixed on current trunk. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40240
[Bug tree-optimization/40238] [4.5 Regression] ICE in gimple_verify_flow_info, at tree-cfg.c:4603
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-25 10:31 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40238
[Bug bootstrap/40027] [4.4/4.5 regression] i686-pc-solaris2.10 bootstrap fails using Sun ld
--- Comment #6 from ro at gcc dot gnu dot org 2009-05-25 12:12 --- Subject: Bug 40027 Author: ro Date: Mon May 25 12:12:08 2009 New Revision: 147845 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147845 Log: PR bootstrap/40027 * config/i386/i386.c (USE_HIDDEN_LINKONCE): Only define if missing. * config/i386/sol2.h [!TARGET_GNU_LD] (USE_HIDDEN_LINKONCE): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/sol2.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40027
[Bug bootstrap/40027] [4.4/4.5 regression] i686-pc-solaris2.10 bootstrap fails using Sun ld
--- Comment #7 from ro at gcc dot gnu dot org 2009-05-25 12:13 --- Subject: Bug 40027 Author: ro Date: Mon May 25 12:13:38 2009 New Revision: 147846 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147846 Log: PR bootstrap/40027 * config/i386/i386.c (USE_HIDDEN_LINKONCE): Only define if missing. * config/i386/sol2.h [!TARGET_GNU_LD] (USE_HIDDEN_LINKONCE): Define. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/i386/i386.c branches/gcc-4_4-branch/gcc/config/i386/sol2.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40027
[Bug bootstrap/40027] [4.4/4.5 regression] i686-pc-solaris2.10 bootstrap fails using Sun ld
--- Comment #8 from ro at gcc dot gnu dot org 2009-05-25 12:56 --- Fixed for 4.4.1, 4.5.0. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40027
[Bug preprocessor/40241] ?: operator incorrectly groups left in cpp
--- Comment #1 from jakub at gcc dot gnu dot org 2009-05-25 13:28 --- This has been fixed for 4.4 and above somewhen between r134840 and r136241, likely http://gcc.gnu.org/viewcvs?root=gccview=revrev=134989. I don't think it was a regression, so fixing it just in 4.4 is sufficient. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40241
[Bug libffi/40242] New: unsupported asm instructions in libffi/src/arm/sysv.S
Hello, during cross compilation of gcc, the libffi build for the target breaks with this error message: libtool: compile: /home/frogger/pengutronix/toolchain/libffi/build/./gcc/xgcc -B/home/frogger/pengutronix/toolchain/libffi/build/./gcc/ -B/usr/local/arm-1136jfs-linux-gnueabi/bin/ -B/usr/local/arm-1136jfs-linux-gnueabi/lib/ -isystem /usr/local/arm-1136jfs-linux-gnueabi/include -isystem /usr/local/arm-1136jfs-linux-gnueabi/sys-include -I. -I../../../gcc-4.4.0/libffi/include -Iinclude -I../../../gcc-4.4.0/libffi/src -g -O2 -c ../../../gcc-4.4.0/libffi/src/arm/sysv.S -fPIC -DPIC -o src/arm/.libs/sysv.o ../../../gcc-4.4.0/libffi/src/arm/sysv.S: Assembler messages: ../../../gcc-4.4.0/libffi/src/arm/sysv.S:202: Error: selected processor does not support `stfeqs f0,[r2]' ../../../gcc-4.4.0/libffi/src/arm/sysv.S:207: Error: selected processor does not support `stfeqd f0,[r2]' ../../../gcc-4.4.0/libffi/src/arm/sysv.S:282: Error: selected processor does not support `ldfs f0,[sp]' ../../../gcc-4.4.0/libffi/src/arm/sysv.S:285: Error: selected processor does not support `ldfd f0,[sp]' ../../../gcc-4.4.0/libffi/src/arm/sysv.S:288: Error: selected processor does not support `ldfd f0,[sp]' the offending code is: #ifndef __SOFTFP__ beq LSYM(Lepilogue) @ return FLOAT cmp r3, #FFI_TYPE_FLOAT stfeqs f0, [r2] beq LSYM(Lepilogue) @ return DOUBLE or LONGDOUBLE cmp r3, #FFI_TYPE_DOUBLE stfeqd f0, [r2] #endif gcc is configured this way: ../gcc-4.4.0/configure --enable-languages=c,c++,java --target=arm-1136jfs-linux-gnueabi --with-mpfr=/home/frogger/pengutronix/toolchain/OSELAS.Toolchain-trunk/platform-arm-v4t-linux-gnueabi-gcc-4.4.0-glibc-2.9-binutils-2.19.1-kernel-2.6.29-sanitized/sysroot-host --with-gmp=/home/frogger/pengutronix/toolchain/OSELAS.Toolchain-trunk/platform-arm-v4t-linux-gnueabi-gcc-4.4.0-glibc-2.9-binutils-2.19.1-kernel-2.6.29-sanitized/sysroot-host --with-float=softfp --with-fpu=vfp --with-cpu=arm1136jf-s --with-sysroot=/opt/OSELAS.Toolchain-1.99.3/arm-1136jfs-linux-gnueabi/gcc-4.3.2-glibc-2.8-binutils-2.19-kernel-2.6.27-sanitized/sysroot-arm-1136jfs-linux-gnueabi I.e. as an arm-eabi target, --with-fpu=vfp and --with-float=softfp. Which means floats are passed in integer registers, but in function the compiler generates floating point instructions, the preprocessor doesn't define a __SOFTFP__ symbol. If configuring the compiler with --with-float=soft it will pass floats in integer registers and it will generate softfloat emulation code. In this case the preprocessor defines __SOFTFP__. In both variants the function calling convention is the same, but in one case we have the __SOFTFP__ symbol in the other not. libffi changes it's behaviour depending on this symbol, which is IMHO not correct. I've tested some combinations, this is the summary of (echo | arm-v4t-linux-gnueabi-cpp -dM -mfloat-abi=XXX -mfpu=YYY| egrep -i 'vfp|fp|soft|hard|float'): -mfloat-abi=soft -mfpu=vfp__SOFTFP__ __VFP_FP__ -mfloat-abi=softfp -mfpu=vfp __VFP_FP__ -mfloat-abi=hard -mfpu=vfp __VFP_FP__ (sorry, unimplemented) -mfloat-abi=soft -mfpu=fpa__SOFTFP__ -mfloat-abi=softfp -mfpu=fpa -mfloat-abi=hard -mfpu=fpa I'm not sure which of these combinations makes sense, or are actually used, the 3rd one seems not to be implemented, though. We at pengutronix use usually 1. and 2. In some weird projects 4. and 6. but not with the current gcc. This table shows that it's not possible to distinguish between the hard and softfp case, a diff off the preprocessor's output shows no difference in the symbols tough. On the upside the vfp-hard case seems not to be implemented. So the question is which is the correct symbol for libffi? cheers, Marc -- Summary: unsupported asm instructions in libffi/src/arm/sysv.S Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mkl at pengutronix dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: arm-1136jfs-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40242
[Bug target/40243] New: no aligned instruction generated for i386
Even a simple program like: for(i=0;i1000;i++) a[i]= b[i]+c[i]; is vectorized using -ftree-vectorize -msse2 -O2 flag. Unaligned instruction are generated. For any program, Not even a single aligned instruction is generated. As, the variable STACK_BOUNDARY in function vect_can_force_dr_alignment_p in file tree-vectorizer.c:1798 is defined to be BITS_PER_WORD(32) for i386 in i386.h . while this should be 128, so this variable should be replaced by some other variable or might be again restored to PREFERRED_STACK_BOUNDARY, like previous versions. In version 4.4.0 , it is replaced by MAX_STACK_ALIGNMENT, which is defined as MAX_OFILE_ALIGNEMENT in i386.h. So, both conditions return ,the same answer ( alignment = MAX_OFILE_ALIGNMENT). -- Summary: no aligned instruction generated for i386 Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: abhishek dot shrivastav24 at gmail dot com GCC build triplet: i686-unknown-linux GCC host triplet: i686-unknown-linux GCC target triplet: i686-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40243
[Bug target/40243] no aligned instruction generated for i386
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-25 14:23 --- Works for me (your simple program is not a valid program). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40243
[Bug target/40243] no aligned instruction generated for i386
--- Comment #2 from abhishek dot shrivastav24 at gmail dot com 2009-05-25
14:36 ---
(In reply to comment #1)
Works for me (your simple program is not a valid program).
The whole program is like this:
/* sample.c */
#include stdio.h
#define N 1000
int main()
{
int a[N], b[N], c[N], i;
for(i=0;iN;i++)
b[i]=c[i]=i;
for(i=0;iN;i++)
a[i]=b[i]+c[i];
for(i=0;iN;i++)
printf(%d, a[i]);
}
compile using gcc version 4.3.*, using
gcc -S -ftree-vectorize -ftree-vectorizer-verbose=10 -msse2 -O2 sample.c
Now, view the assembly file generated and also the verbose, it always prints
when analyzing in function vect_analyze_data_refs_alignment ***can't force
alignment of ref: b[i_43]***, while it does not need alignment, as it is
already aligned.
Simply changed the instruction movdqu to movdqa and no segmentation fault would
occur, as the array references are aligned.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40243
[Bug middle-end/40244] New: [4.5 Regression] Revision147829 caused extra failures
On Linux/ia64, revision 147829: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00806.html caused: FAIL: Matrix4f -O3 compilation from source FAIL: gcc.dg/vect/bb-slp-10.c scan-tree-dump-times slp unsupported alignment in basic block. 1 FAIL: gcc.dg/vect/bb-slp-4.c scan-tree-dump-times slp basic block vectorized using SLP 0 -- Summary: [4.5 Regression] Revision147829 caused extra failures Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40244
[Bug fortran/40176] Fortran 2003: Procedure pointers with array return value
--- Comment #4 from janus at gcc dot gnu dot org 2009-05-25 14:48 --- Subject: Bug 40176 Author: janus Date: Mon May 25 14:48:24 2009 New Revision: 147850 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147850 Log: 2009-05-25 Janus Weil ja...@gcc.gnu.org PR fortran/40176 * primary.c (gfc_match_varspec): Handle procedure pointer components with array return value. * resolve.c (resolve_expr_ppc): Ditto. (resolve_symbol): Make sure the interface of a procedure pointer has been resolved. * trans-array.c (gfc_walk_function_expr): Handle procedure pointer components with array return value. * trans-expr.c (gfc_conv_component_ref,gfc_conv_procedure_call, gfc_trans_arrayfunc_assign): Ditto. (gfc_trans_pointer_assignment): Handle procedure pointer assignments, where the rhs is a dummy argument. * trans-types.c (gfc_get_ppc_type,gfc_get_derived_type): Handle procedure pointer components with array return value. 2009-05-25 Janus Weil ja...@gcc.gnu.org PR fortran/40176 * gfortran.dg/proc_ptr_18.f90: New. * gfortran.dg/proc_ptr_19.f90: New. * gfortran.dg/proc_ptr_comp_9.f90: New. * gfortran.dg/proc_ptr_comp_10.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_18.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_19.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_10.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40176
[Bug middle-end/40245] New: [4.5 Regression] Revision 147829 breaks SPEC CPU 2K/2006 at -O3
On Linux/ia32 and Linux/x86-64, revision 147829: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00806.html breaks SPEC CPU 2K/2006 at -O3: http://gcc.gnu.org/ml/gcc-regression/2009-05/msg00239.html http://gcc.gnu.org/ml/gcc-regression/2009-05/msg00238.html They haven't been fixed as of revision 147843. -- Summary: [4.5 Regression] Revision 147829 breaks SPEC CPU 2K/2006 at -O3 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40245
[Bug target/40243] no aligned instruction generated for i386
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-25 14:58 --- Please try gcc 4.4. We have fixed a bunch of alignment issues. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40243
[Bug c++/38064] [c++0x] operator== doesn't work for enum classes
--- Comment #5 from paolo dot carlini at oracle dot com 2009-05-25 16:11 --- CC-ing Jason... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38064
[Bug c++/38064] [c++0x] operator== doesn't work for enum classes
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-05-25 15:15:07 |2009-05-25 16:45:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38064
[Bug c++/38064] [c++0x] operator== doesn't work for enum classes
--- Comment #6 from ian at airs dot com 2009-05-25 18:32 --- With unscoped enums the similar code works because cp_build_binary_op applies the default integral promotions to the enums, and winds up comparing two int values. The promotions are not applied to scoped enums because default_conversion checks INTEGRAL_OR_UNSCOPED_ENUMERATION_TYPE_P. I would guess that this would work if several checks in cp_build_binary_op also checked for ENUMERAL_TYPE in cases where they currently check for INTEGER_TYPE. But I haven't tried to read the standard to understand where the right fix is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38064
[Bug target/40171] GCC does not pass -mtune and -march options to assembler!
--- Comment #4 from vvv at ru dot ru 2009-05-25 19:54 --- (In reply to comment #2) This is very odd? What is the assembler doing that the compiler isn't? There are exist some optimizations impossible without exact knowledge of address and opcodes, One example avoiding of branch mispredicts - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942 Other example - Ensure instructions using 0xF7 opcode byte does not start at offset 14 of a fetch line... Unfortunately, current version GNU AS cat't do this optimizations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40171
[Bug fortran/40176] Fortran 2003: Procedure pointers with array return value
--- Comment #5 from dominiq at lps dot ens dot fr 2009-05-25 20:05 ---
The following invalid code (reduced from the original code):
! { dg-do compile }
! This tests various error messages for PROCEDURE declarations.
! Contributed by Janus Weil jaydu...@gmail.com
program prog
contains
subroutine foo(a,c)
procedure(c),intent(in):: c ! { dg-error PROCEDURE attribute conflicts
with INTENT attribute }
end subroutine foo
end program
seems stuck in an infinite loop (r147851 + '-fwhole-file' patch):
ibook-dhum] f90/bug% gfc proc_decl_1_red.f90
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
proc_decl_1_red.f90:9.20:
subroutine foo(a,c)
1
Error: Interface 'c', used by procedure 'c' at (1), is declared in a later
PROCEDURE statement
Fatal Error: Error count reached limit of 25.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40176
[Bug c/2803] casts in asm act as lvalues
--- Comment #12 from astrange at ithinksw dot com 2009-05-25 20:26 ---
I noticed this is still accepted by gcc 4.5; one stuck into ffmpeg and broke
the build with another compiler.
For instance, this only fails in c():
int as(int a)
{
asm ( : : m((int)a));
}
int c(int a)
{
return *((int)a);
}
/usr/local/gcc45/bin/gcc -S test.c
test.c: In function 'c':
test.c:8: error: lvalue required as unary '' operand
--
astrange at ithinksw dot com changed:
What|Removed |Added
CC||astrange at ithinksw dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2803
[Bug fortran/40246] New: ICE on invalid SOURCE= using NULLIFY
real, pointer :: ptr nullify(ptr, mesh%coarser) end gives an ICE: nullify(ptr, mesh%coarser) 1 Internal Error at (1): free_expr0(): Bad expr type -- Summary: ICE on invalid SOURCE= using NULLIFY Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40246
[Bug middle-end/40247] New: [4.5 Regression] Revision 147848 failed gcc.dg/struct/wo_prof_escape_substr_pointer.c
Revision 147848: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00825.html caused: FAIL: gcc.dg/struct/wo_prof_escape_substr_pointer.c scan-ipa-dump ipa_struct_reorg is a field in the structure -- Summary: [4.5 Regression] Revision 147848 failed gcc.dg/struct/wo_prof_escape_substr_pointer.c Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40247
[Bug c++/38064] [c++0x] operator== doesn't work for enum classes
--- Comment #7 from jason at gcc dot gnu dot org 2009-05-25 23:01 --- Subject: Bug 38064 Author: jason Date: Mon May 25 23:01:02 2009 New Revision: 147854 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147854 Log: PR c++/38064 * typeck.c (cp_build_binary_op): Allow ENUMERAL_TYPE in arithmetic comparisons. (cp_common_type): Handle scoped enums. * call.c (promoted_arithmetic_type_p): Don't use INTEGRAL_TYPE_P. (add_builtin_candidate, add_builtin_candidates): Likewise. (convert_like_real): Likewise. * class.c (check_bitfield_decl): Likewise. * decl.c (check_static_variable_definition): Likewise. (compute_array_index_type): Likewise. * decl2.c (grokbitfield): Likewise. * init.c (build_new_1): Likewise. * pt.c (convert_nontype_argument): Likewise. (current_instantiation): Likewise. * tree.c (pod_type_p): Likewise. * typeck.c (build_static_cast_1): Likewise. (build_reinterpret_cast_1): Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/enum3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/class.c trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c trunk/gcc/cp/init.c trunk/gcc/cp/pt.c trunk/gcc/cp/tree.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38064
[Bug fortran/34053] -frecursive: No need to use the stack for local variables of the main program
--- Comment #3 from burnus at gcc dot gnu dot org 2009-05-25 23:02 --- The following should be enough. gfc_can_put_var_on_stack is also called elsewhere but those calls shouldn't matter so much. Index: trans-decl.c === --- trans-decl.c(Revision 147558) +++ trans-decl.c(Arbeitskopie) @@ -544,10 +544,12 @@ TREE_TYPE (decl) = new_type; } - /* Keep variables larger than max-stack-var-size off stack. */ + /* Keep variables larger than max-stack-var-size off stack and + - even with -frecursive - variables of the main program. */ if (!sym-ns-proc_name-attr.recursive INTEGER_CST_P (DECL_SIZE_UNIT (decl)) - !gfc_can_put_var_on_stack (DECL_SIZE_UNIT (decl)) + (!gfc_can_put_var_on_stack (DECL_SIZE_UNIT (decl)) + || sym-ns-proc_name-attr.main_program) /* Put variable length auto array pointers always into stack. */ (TREE_CODE (TREE_TYPE (decl)) != POINTER_TYPE || sym-attr.dimension == 0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34053
[Bug c++/38064] [c++0x] operator== doesn't work for enum classes
--- Comment #8 from jason at gcc dot gnu dot org 2009-05-25 23:07 --- Subject: Bug 38064 Author: jason Date: Mon May 25 23:07:05 2009 New Revision: 147855 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147855 Log: PR c++/38064 * typeck.c (cp_build_binary_op): Allow ENUMERAL_TYPE in arithmetic comparisons. (cp_common_type): Handle scoped enums. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/enum3.C - copied unchanged from r147854, trunk/gcc/testsuite/g++.dg/cpp0x/enum3.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/typeck.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38064
[Bug c++/38064] [c++0x] operator== doesn't work for enum classes
--- Comment #9 from jason at gcc dot gnu dot org 2009-05-25 23:12 --- Fixed for 4.4.1. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38064
[Bug middle-end/40248] New: FAIL: gcc.c-torture/compile/20090518-1.c at -O1 and above
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ - O1 -w -c -o 20090518-1.o /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile /20090518-1.c(timeout = 300) /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/20090518-1.c: In function 'foo': /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/20090518-1.c:6: error: unr ecognizable insn: (insn 8 7 9 3 /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/20090518-1.c :3 (set (reg:SF 73) (const_int 0 [0x0])) -1 (nil)) /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/20090518-1.c:6: internal c ompiler error: in extract_insn, at recog.c:2078 I don't believe that (const_int 0 [0x0]) is the CONST0_RTX for SFmode. So, I think the generated RTL is invalid. -- Summary: FAIL: gcc.c-torture/compile/20090518-1.c at -O1 and above Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40248
[Bug tree-optimization/40249] New: [4.5 Regression]: build breakage with inline heuristics change
With revision 147851 cris-elf built. From revision 147853 and on, bild is broken as follows: /tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/xgcc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/ -nostdinc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/ -isystem /tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/targ-include -isystem /tmp/hpautotest-gcc1/gcc/newlib/libc/include -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libgloss/cris -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libgloss/libnosys -L/tmp/hpautotest-gcc1/gcc/libgloss/cris -B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/bin/ -B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/lib/ -isystem /tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/include -isystem /tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/sys-include-g -O2 -march=v10 -mbest-lib-options -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -I. -I. -I/tmp/hpautotest-gcc1/gcc/gcc -I/tmp/hpautotest-gcc1/gcc/gcc/. -I/tmp/hpautotest-gcc1/g! cc/gcc/../include -I/tmp/hpautotest-gcc1/gcc/gcc/../libcpp/include -I/tmp/hpautotest-gcc1/cris-elf/gccobj/./gmp -I/tmp/hpautotest-gcc1/gcc/gmp -I/tmp/hpautotest-gcc1/cris-elf/gccobj/./mpfr -I/tmp/hpautotest-gcc1/gcc/mpfr -I/tmp/hpautotest-gcc1/gcc/gcc/../libdecnumber -I/tmp/hpautotest-gcc1/gcc/gcc/../libdecnumber/dpd -I../libdecnumber-g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize -Dinhibit_libc -I. -I. -I../../.././gcc -I/tmp/hpautotest-gcc1/gcc/libgcc -I/tmp/hpautotest-gcc1/gcc/libgcc/. -I/tmp/hpautotest-gcc1/gcc/libgcc/../gcc -I/tmp/hpautotest-gcc1/gcc/libgcc/../include -o crtend.o -MT crtend.o -MD -MP -MF crtend.dep -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -moverride-best-lib-options \ -c /tmp/hpautotest-gcc1/gcc/libgcc/../gcc/crtstuff.c -DCRT_END /tmp/hpautotest-gcc1/gcc/libgcc/../gcc/crtstuff.c:50: warning: IN_LIBGCC2 redefined command-line:0: note: this is the location of the previous definition /tmp/cc8fpic3.s: Assembler messages: /tmp/cc8fpic3.s:227: Error: operation combines symbols in different segments Author of patches in suspect revision range CC:ed. Will add preprocessed source. -- Summary: [4.5 Regression]: build breakage with inline heuristics change Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code, build Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: cris-axis-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40249
[Bug tree-optimization/40249] [4.5 Regression]: build breakage with inline heuristics change
--- Comment #1 from hp at gcc dot gnu dot org 2009-05-26 00:35 --- Created an attachment (id=17914) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17914action=view) preprocessed code from compiling crtend.o At a glance, one would believe some function in crtstuff.c is lacking a noinline tag, particularly those with the hideous .section asms. OTOH, the compile options do include -fno-inline-functions... Run cc1 with -fpreprocessed crtstuff.i -melf -quiet -dumpbase crtstuff.c -march=v10 -mpdebug -auxbase-strip crtend.o -g-O2 -W -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -version -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize -o crtstuff.s Observe in crtstuff.s at line 232 in the section .debug_loc: .dword .LVL2-.Ltext0 where .LVL2 is in section .init and .Ltext0 is in .text -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40249
[Bug target/40249] [4.5 Regression]: build breakage with inline heuristics change
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-26 03:24 --- This sounds like either an as bug or a bug in the target back-end accepting some memory address it should not. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |target Keywords||assemble-failure http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40249
[Bug target/40249] [4.5 Regression]: build breakage with inline heuristics change
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40249
[Bug c/40097] inconsistent printf handling
--- Comment #4 from hp at gcc dot gnu dot org 2009-05-26 03:27 --- When porting code such as in the description, it can be argued that robustifying the code is an important part; that undefined code that just happened to work for the initial target(s) is corrected to use defined constructs that work everywhere. If that's not an option here, perhaps you can add application-specific printf and puts, versions that handles NULL arguments such as the application expects. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40097
[Bug bootstrap/40250] New: make bootstrap fails on IRIX64: ar: libbackend.a: Error reading tree-phinodes.o
When I try to build gcc-4.4.0 on the IRIX64 platform, the build fails with: ar rc libbackend.a insn-attrtab.o insn-automata.o insn-emit.o insn-extract.o insn-modes.o insn-opinit.o insn-output.o insn-peep.o insn-preds.o insn-recog.o ggc-page.o alias.o alloc-pool.o auto-inc-dec.o bb-reorder.o bitmap.o bt-load.o builtins.o caller-save.o calls.o cfg.o cfganal.o cfgbuild.o cfgcleanup.o cfgexpand.o cfghooks.o cfglayout.o cfgloop.o cfgloopanal.o cfgloopmanip.o cfgrtl.o combine.o combine-stack-adj.o convert.o coverage.o cse.o cselib.o dbxout.o dbgcnt.o dce.o ddg.o debug.o df-byte-scan.o df-core.o df-problems.o df-scan.o dfp.o diagnostic.o dojump.o dominance.o domwalk.o double-int.o dse.o dwarf2asm.o dwarf2out.o ebitmap.o emit-rtl.o et-forest.o except.o explow.o expmed.o expr.o final.o fixed-value.o fold-const.o function.o fwprop.o gcse.o genrtl.o ggc-common.o gimple.o gimple-iterator.o gimple-low.o gimple-pretty-print.o gimplify.o graph.o graphds.o graphite.o gtype-desc.o haifa-sched.o hooks.o ifcvt.o init-regs.o integrate.o intl.o ira.o ira-build.o ira-costs.o ira-conflicts.o ira-color.o ira-emit.o ira-lives.o jump.o lambda-code.o lambda-mat.o lambda-trans.o langhooks.o lcm.o lists.o loop-doloop.o loop-init.o loop-invariant.o loop-iv.o loop-unroll.o loop-unswitch.o lower-subreg.o mcf.o mode-switching.o modulo-sched.o omega.o omp-low.o optabs.o options.o opts-common.o opts.o params.o passes.o pointer-set.o postreload-gcse.o postreload.o predict.o pretty-print.o print-rtl.o print-tree.o profile.o real.o recog.o reg-stack.o reginfo.o regmove.o regrename.o regstat.o reload.o reload1.o reorg.o resource.o rtl-error.o rtl-factoring.o rtl.o rtlanal.o rtlhooks.o sbitmap.o sched-deps.o sched-ebb.o sched-rgn.o sched-vis.o sdbout.o see.o sel-sched-ir.o sel-sched-dump.o sel-sched.o simplify-rtx.o sparseset.o sreal.o stack-ptr-mod.o statistics.o stmt.o stor-layout.o stringpool.o targhooks.o timevar.o toplev.o tracer.o tree-affine.o tree-call-cdce.o tree-cfg.o tree-cfgcleanup.o tree-chrec.o tree-complex.o tree-data-ref.o tree-dfa.o tree-dump.o tree-eh.o tree-if-conv.o tree-into-ssa.o tree-iterator.o tree-loop-distribution.o tree-loop-linear.o tree-nested.o tree-nrv.o tree-object-size.o tree-optimize.o tree-outof-ssa.o tree-parloops.o tree-phinodes.o tree-predcom.o tree-pretty-print.o tree-profile.o tree-scalar-evolution.o tree-sra.o tree-switch-conversion.o tree-ssa-address.o tree-ssa-alias.o tree-ssa-ccp.o tree-ssa-coalesce.o tree-ssa-copy.o tree-ssa-copyrename.o tree-ssa-dce.o tree-ssa-dom.o tree-ssa-dse.o tree-ssa-forwprop.o tree-ssa-ifcombine.o tree-ssa-live.o tree-ssa-loop-ch.o tree-ssa-loop-im.o tree-ssa-loop-ivcanon.o tree-ssa-loop-ivopts.o tree-ssa-loop-manip.o tree-ssa-loop-niter.o tree-ssa-loop-prefetch.o tree-ssa-loop-unswitch.o tree-ssa-loop.o tree-ssa-math-opts.o tree-ssa-operands.o tree-ssa-phiopt.o tree-ssa-phiprop.o tree-ssa-pre.o tree-ssa-propagate.o tree-ssa-reassoc.o tree-ssa-sccvn.o tree-ssa-sink.o tree-ssa-structalias.o tree-ssa-ter.o tree-ssa-threadedge.o tree-ssa-threadupdate.o tree-ssa-uncprop.o tree-ssa.o tree-ssanames.o tree-stdarg.o tree-tailcall.o tree-vect-analyze.o tree-vect-generic.o tree-vect-patterns.o tree-vect-transform.o tree-vectorizer.o tree-vrp.o tree.o value-prof.o var-tracking.o varasm.o varray.o vec.o version.o vmsdbgout.o web.o xcoffout.o mips.o host-default.o cgraph.o cgraphbuild.o cgraphunit.o cppdefault.o incpath.o ipa-cp.o ipa-inline.o ipa-prop.o ipa-pure-const.o ipa-reference.o ipa-struct-reorg.o ipa-type-escape.o ipa-utils.o ipa.o matrix-reorg.o prefix.o tree-inline.o tree-nomudflap.o varpool.o ar: libbackend.a: Error reading tree-phinodes.o: File truncated make[3]: *** [libbackend.a] Error 1 make[3]: Leaving directory `/appl/local_sde_dev/src/gcc/gcc-4.4.0/mips-IRIX64-6.5/gcc-4.4.0-obj/gcc' make[2]: *** [all-stage3-gcc] Error 2 make[2]: Leaving directory `/appl/local_sde_dev/src/gcc/gcc-4.4.0/mips-IRIX64-6.5/gcc-4.4.0-obj' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/appl/local_sde_dev/src/gcc/gcc-4.4.0/mips-IRIX64-6.5/gcc-4.4.0-obj' make: *** [bootstrap] Error 2 $ ar --version GNU ar (GNU Binutils) 2.18 Copyright 2007 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. Repeated attempts kept failing at the same point, although I get no errors when tree-phinodes.o is built. In most cases, it failed at stage2, but in the last case it failed at stage3. The stage2 and stage3 versions of tree-phinodes.o is a lot smaller than the stage1 version: $ find . -name tree-phinodes.o | xargs ls -l -rw-rw-r-- 1 stpierre sdedev 84400 May 25 15:09 ./gcc/tree-phinodes.o -rw-rw-r-- 1 stpierre sdedev 84400 May 25 13:12 ./prev-gcc/tree-phinodes.o -rw-rw-r-- 1 stpierre sdedev 725424 May 25 10:42 ./stage1-gcc/tree-phinodes.o I'm configuring gcc this way: ../gcc-4.4.0/configure
[Bug target/40249] [4.5 Regression]: build breakage with inline heuristics change
--- Comment #3 from hp at gcc dot gnu dot org 2009-05-26 04:42 --- (In reply to comment #2) This sounds like either an as bug An expression that is the difference between two *other* sections is not regularly allowed for ELF targets... or a bug in the target back-end accepting some memory address it should not. This guess also seems easy to discard: the line pointed out was in the *debug information*. Andrew, you're not helping. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40249
[Bug bootstrap/40250] make bootstrap fails on IRIX64: ar: libbackend.a: Error reading tree-phinodes.o
--- Comment #1 from Jay dot St dot Pierre at Colorado dot EDU 2009-05-26 05:11 --- Created an attachment (id=17915) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17915action=view) config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40250
[Bug c++/40036] Initializer incorrectly reordering arguments
--- Comment #6 from jwbates at mac dot com 2009-05-26 05:26 --- Update: after some restructuring, the problem still occurs when using the -g flag, but does not occur when the -O flag is used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40036
