[Bug fortran/40267] New: Eventually get rid of libgfortranbegin.a
Follow up to PR 39178. Until that patch for GCC 4.5, gfortran generated for the main PROGRAM only "MAIN__" and no "main"; the latter was then included by linking libgfortran.a With the patch (PR 39178), libgfortran.a became obsolete and is no longer linked by gfortran. It is still present, however, and thus "gcc ... -llibgfortranbegin" still works - but it has no effect. (At least when the *.o file with "main()" comes first - otherwise one gets a double-"main" linker error.) Some makefiles explicitly link libgfortranbegin thus they will break when libgfortranbegin.a is removed (cf. link below). Removal: Remove libgfortran/fmain.c, update libgfortran/Makefile.am and (re)generate libgfortran/Makefile.in See the following thread about sentiments regarding the removal: http://gcc.gnu.org/ml/gcc-patches/2009-05/threads.html#01604 -- Summary: Eventually get rid of libgfortranbegin.a Product: gcc Version: 4.5.0 Status: UNCONFIRMED 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=40267
[Bug fortran/39178] Generate main() rather than using a main in libgfortran/fmain.c
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-27 07:29 --- FIXED on the trunk (4.5). Regarding libgfortranbegin.a, see PR 40267. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39178
[Bug fortran/40019] LEADZ and TRAILZ give wrong results
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-27 07:44 --- I don't think your patch fixes the following, print *, leadz(-1_1), leadz(-1_2), leadz(-1_4), leadz(-1_8), leadz(-1_16) which yields 7 15 31 63 127 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40019
[Bug target/40266] march-native gives -mno-sse4, but cpuinfo sse4_1
--- Comment #1 from ubizjak at gmail dot com 2009-05-27 08:06 --- (In reply to comment #0) > cat /proc/cpuinfo: > > flags : .sse sse2 ssse3 sse4_1 ... Please post complete /proc/cpuinfo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40266
[Bug bootstrap/40268] New: continued build failures from PR39791 and PR40061 fixes
gcc-4.3-20090524 fails to build for target=alpha-unknown-linux: /tmp/gcc-4.3-20090524/gcc/dwarf2out.c: In function 'add_subscript_info': /tmp/gcc-4.3-20090524/gcc/dwarf2out.c:11328: error: break statement not within loop or switch gcc-4.3.3 and earlier build fine so this is a regression. The problem is that the PR39791 fix put a break statement in a block which is a loop body only when !MIPS_DEBUGGING_INFO. This and an undeclared variable issue were reported as PR40061, but the fix for PR40061 only fixed the undeclared variable issue, not the invalid break statement issue. The break issue could be fixed by turning this block into a loop body also in the !MIPS_DEBUGGING_INFO case, but that looks like it will require more #ifdefs and local variables. So I suggest to just #ifdef the break statement. I'm attaching patch which does just that. -- Summary: continued build failures from PR39791 and PR40061 fixes Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikpe at it dot uu dot se GCC target triplet: alpha-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40268
[Bug bootstrap/40268] continued build failures from PR39791 and PR40061 fixes
--- Comment #1 from mikpe at it dot uu dot se 2009-05-27 08:26 --- Created an attachment (id=17921) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17921&action=view) fix alpha compile failure in dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40268
[Bug bootstrap/40061] [4.3 Regression] Bootstrap failure in dwarf2out.c, function add_subscript_info: 'dimension_number' undefined
--- Comment #6 from ubizjak at gmail dot com 2009-05-27 08:41 --- *** Bug 40268 has been marked as a duplicate of this bug. *** -- ubizjak at gmail dot com changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40061
[Bug bootstrap/40268] continued build failures from PR39791 and PR40061 fixes
--- Comment #2 from ubizjak at gmail dot com 2009-05-27 08:41 --- *** This bug has been marked as a duplicate of 40061 *** -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40268
[Bug bootstrap/40061] [4.3 Regression] Bootstrap failure in dwarf2out.c, function add_subscript_info: 'dimension_number' undefined
--- Comment #7 from ubizjak at gmail dot com 2009-05-27 08:42 --- (In reply to comment #5) > FIXED on the 4.3 branch. Thanks for reporting the problem and sorry for the > breakage. Not really, see PR 40268 for description and proposed patch. Confirmed fail on cross to alpha-linux-gnu. -- ubizjak at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40061
[Bug tree-optimization/40254] [4.5 Regression] SPEC2006 403.gcc miscompares
--- Comment #4 from irar at il dot ibm dot com 2009-05-27 08:43 --- The bug is in data-refs analysis for basic blocks: two accesses that are not adjacent (reload.c:1370) are considered as adjacent, and, therefore, get vectorized together, causing the wrong code generation. -- irar at il dot ibm dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-27 08:43:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40254
[Bug middle-end/40259] Unintended code in find_givs_in_stmt_scev (gcc/tree-ssa-loop-ivopts.c)?
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-27 08:57 --- No idea. Invalid. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40259
[Bug libffi/40242] unsupported asm instructions in libffi/src/arm/sysv.S
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-27 09:50 --- (In reply to comment #0) > 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. Using mfpu=fpa in eabi configurations is wrong. Trunk is now patched to no longer allow this. > > 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. The difference between vfp-hard and softfp is whether we use the VFP registers for passing parameters or not. Currently softfp is the only one implemented in trunk and all release branches though an implementation is under way in an architecture specific branch viz. ARM/hardvfp_4_4_branch. > > So the question is which is the correct symbol for libffi? If there is code in here that tries to return values in floating point registers if SOFTFP is not defined then it is clearly wrong and we need another macro to distinguish the case. I am not sure if there exists a symbol for this and I am not sure about the code in this. CC'ing Andrew Haley about this one. > > cheers, Marc > -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC
[Bug tree-optimization/40254] [4.5 Regression] SPEC2006 403.gcc miscompares
--- Comment #5 from irar at il dot ibm dot com 2009-05-27 09:59 ---
I'll test this patch tomorrow:
Index: tree-data-ref.c
===
--- tree-data-ref.c (revision 147903)
+++ tree-data-ref.c (working copy)
@@ -718,17 +725,26 @@ dr_analyze_innermost (struct data_refere
base_iv.no_overflow = true;
}
- if (!poffset || !in_loop)
+ if (!poffset)
{
offset_iv.base = ssize_int (0);
offset_iv.step = ssize_int (0);
}
- else if (!simple_iv (loop, loop_containing_stmt (stmt),
- poffset, &offset_iv, false))
+ else
{
- if (dump_file && (dump_flags & TDF_DETAILS))
- fprintf (dump_file, "failed: evolution of offset is not affine.\n");
- return false;
+ if (!in_loop)
+{
+ offset_iv.base = poffset;
+ offset_iv.step = ssize_int (0);
+}
+ else if (!simple_iv (loop, loop_containing_stmt (stmt),
+ poffset, &offset_iv, false))
+{
+ if (dump_file && (dump_flags & TDF_DETAILS))
+fprintf (dump_file, "failed: evolution of offset is not"
+" affine.\n");
+ return false;
+}
}
init = ssize_int (pbitpos / BITS_PER_UNIT);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40254
[Bug fortran/40019] LEADZ and TRAILZ give wrong results
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-05-27 10:27 --- (In reply to comment #1) > I don't think your patch fixes the following, > > print *, leadz(-1_1), leadz(-1_2), leadz(-1_4), leadz(-1_8), leadz(-1_16) > > which yields > >7 15 31 63 127 I think it does: $ cat h.f90 print *, leadz(-1_1), leadz(-1_2), leadz(-1_4), leadz(-1_8), leadz(-1_16) end $ gfortran h.f90 && ./a.out 0 0 0 0 0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40019
[Bug pch/13675] #including a precompiled header more than once in the same unit fails
--- Comment #19 from gafunchal at gmail dot com 2009-05-27 10:56 --- (In reply to comment #18) > Fixed in 4.4. > I still have this bug on 4.4.0, when using pch and -g3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13675
[Bug fortran/40168] missing unrolling/scalarization/reassoc/free
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-05-27 11:01 --- The issue is not the temporary array but the way how CSE works. In S2 there are simply no CSE opportunities - for example consider t1 = a * b; t2 = t1 * c; t3 = a * c; t4 = t3 * b; The current CSE implementation cannot see the opportunity here. (*b_3(D))[79] = (*b_3(D))[1] * (*s_1(D))[2] * (*s_1(D))[5] * (*s_1(D))[8] * (*s_1(D))[10]; (*b_3(D))[80] = (*b_9(D))[0] * (*s_1(D))[2] * (*s_1(D))[5] * (*s_1(D))[8] * (*s_1(D))[11]; I will try to do something here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168
[Bug c++/40269] New: ICE during procesing class attributes
#include
class __declspec(dllexport) A {};
int main(int argc, char *argv[]) {
return 0;
}
$ gcc testcase.cpp
testcase.cpp:3: internal compiler error: tree check: expected function_decl,
hav
e type_decl in handle_dll_attribute, at tree.c:4172
Please submit a full bug report,
with preprocessed source if appropriate.
--
Summary: ICE during procesing class attributes
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC host triplet: Cygwin/GCC-trunk rev. 147886
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40269
[Bug middle-end/40249] [4.5 Regression]: build breakage with inline heuristics change
--- Comment #8 from hp at gcc dot gnu dot org 2009-05-27 12:40 --- Subject: Bug 40249 Author: hp Date: Wed May 27 12:40:09 2009 New Revision: 147907 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147907 Log: PR middle-end/40249 * Makefile.in (CRTSTUFF_CFLAGS): Replace -fno-inline-functions with -fno-inline. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40249
[Bug middle-end/40249] [4.5 Regression]: build breakage with inline heuristics change
--- Comment #9 from hp at gcc dot gnu dot org 2009-05-27 12:40 --- . -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40249
[Bug target/35079] [arm] ICE (segfault) with gfortran -O3 -funroll-loops
--- Comment #3 from ramana at gcc dot gnu dot org 2009-05-27 13:01 --- I just tried this with gfortran 4.3.3 that I have on my ubuntu box. I don't get a failure with arm-linux-gnueabi. Can you verify that this still exists with arm-linux configurations ? Thanks. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35079
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #21 from burnus at gcc dot gnu dot org 2009-05-27 13:02 --- Regarding -fwhole-file issues, see also PR 40176 comment 5 (endless loop for invalid program with -fwhole-file). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40270] New: [4.5 Regression] Revision 147883 caused many Fortran regressions
Revision 147883: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00860.html caused many Fortran regressions: http://gcc.gnu.org/ml/gcc-regression/2009-05/msg00265.html -- Summary: [4.5 Regression] Revision 147883 caused many Fortran regressions Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran 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=40270
[Bug middle-end/40271] New: [4.5 Regression] SPEC CPU 2000 failed to build
On Linux/ia32 and Linux/x86-64, revision 147887 SPEC CPU 2000 failed to build at -O2/-O3: Error with make 'specmake build > make.out 2> make.err': check file '/export/gnu/import/svn/gcc-test/spec/2000/x86_64/spec/benchspec/CFP2000/171.swim/run/0001/make.err' Error with make! *** Error building 171.swim Error with make 'specmake build > make.out 2> make.err': check file '/export/gnu/import/svn/gcc-test/spec/2000/x86_64/spec/benchspec/CFP2000/172.mgrid/run/0001/make.err' Error with make! *** Error building 172.mgrid Error with make 'specmake build > make.out 2> make.err': check file '/export/gnu/import/svn/gcc-test/spec/2000/x86_64/spec/benchspec/CFP2000/173.applu/run/0001/make.err' Error with make! *** Error building 173.applu Error with make 'specmake build > make.out 2> make.err': check file '/export/gnu/import/svn/gcc-test/spec/2000/x86_64/spec/benchspec/CFP2000/178.galgel/run/0001/make.err' Error with make! *** Error building 178.galgel Error with make 'specmake build > make.out 2> make.err': check file '/export/gnu/import/svn/gcc-test/spec/2000/x86_64/spec/benchspec/CFP2000/189.lucas/run/0001/make.err' Error with make! *** Error building 189.lucas Error with make 'specmake build > make.out 2> make.err': check file '/export/gnu/import/svn/gcc-test/spec/2000/x86_64/spec/benchspec/CFP2000/301.apsi/run/0001/make.err' Error with make! *** Error building 301.apsi Error: 1x171.swim 1x172.mgrid 1x173.applu 1x178.galgel 1x189.lucas 1x301.apsi Revision 147866 can compile them. -- Summary: [4.5 Regression] SPEC CPU 2000 failed to build 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=40271
[Bug middle-end/40271] [4.5 Regression] SPEC CPU 2000 failed to build
--- Comment #1 from hjl dot tools at gmail dot com 2009-05-27 13:29 --- It may be a dup for PR 40270. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||burnus at net-b dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40271
[Bug fortran/40270] [4.5 Regression] Revision 147883 caused many Fortran regressions
--- Comment #1 from dominiq at lps dot ens dot fr 2009-05-27 13:57 --- Did you do a clean bootstrap? I have noticed that with an incremental update, the failure is due to a warning about something like "main() defined but not used" for compilations with -O1 -Wall -pedantic. I did not have the time to do a full regression testing, but these warnings disappeared after a clean bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40270
[Bug pch/40272] New: error using precompiled headers with extra debug info (-g3)
+++ This bug was initially created as a clone of Bug #13675 +++
The error occurs when using a precompiled header which was compiled with -g3.
It works with -g2. The error message is "file number 2 already allocated".
This was first reported at Bug #13675 comment #16 by lukas, but it seems to me
that this bug is unrelated to that one, so I'm reporting it again here.
This is how to reproduce it:
$ cat header1.h
$ cat header2.h
#include "header1.h"
$ cat test.cpp
#include "header2.h"
main() {}
$ g++ -c -g3 -o header1.h.gch header1.h
$ g++ -c -g3 test.cpp
/tmp/ccPfw5P5.s: Assembler messages:
/tmp/ccPfw5P5.s:445: Error: file number 2 already allocated
-v reports the following:
GNU C++ (GCC) version 4.4.0 (x86_64-unknown-linux-gnu) compiled by GNU C
version 4.4.0, GMP version 4.1.4, MPFR version 2.3.2.
GNU assembler version 2.19 (x86_64-unknown-linux-gnu) using BFD version (GNU
Binutils) 2.19
/tmp/ccfJxSqk.s: Assembler messages:
/tmp/ccfJxSqk.s:445: Error: file number 2 already allocated
--
Summary: error using precompiled headers with extra debug info (-
g3)
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: pch
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gafunchal at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40272
[Bug fortran/40270] [4.5 Regression] Revision 147883 caused many Fortran regressions
--- Comment #2 from hjl dot tools at gmail dot com 2009-05-27 14:02 --- I did a clean bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40270
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #22 from dominiq at lps dot ens dot fr 2009-05-27 14:05 --- (In reply to comment #21) > Regarding -fwhole-file issues, see also PR 40176 comment 5 (endless loop for > invalid program with -fwhole-file). My post in PR 40176 #5 was ambiguous: the infinite loop does not need the -fwhole-file flag. I only wanted to say that I was using a clean tree+ the patch from http://gcc.gnu.org/ml/fortran/2009-05/msg00244.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug target/40266] march-native gives -mno-sse4, but cpuinfo sse4_1
--- Comment #2 from hjl dot tools at gmail dot com 2009-05-27 14:08 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01739.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||05/msg01739.html Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-27 14:08:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40266
[Bug fortran/40176] Fortran 2003: Procedure pointers with array return value
--- Comment #6 from dominiq at lps dot ens dot fr 2009-05-27 14:08 --- The infinite loop in comment #5 can be seen without the -fwhole-file flag (see comment #22 in pr40011). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40176
[Bug pch/40272] error using precompiled headers with extra debug info (-g3)
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-27 14:10 --- You have to include a precompiled header from the toplevel source file as the very first thing or preferably via the -include command-line parameter. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40272
[Bug pch/40272] error using precompiled headers with extra debug info (-g3)
--- Comment #2 from gafunchal at gmail dot com 2009-05-27 14:25 --- (In reply to comment #1) > You have to include a precompiled header from the toplevel source file as the > very first thing or preferably via the -include command-line parameter. > I do not agree with that. The documentation section 3.20 says: * A precompiled header can't be used once the first C token is seen. You can have preprocessor directives before a precompiled header; you can even include a precompiled header from inside another header, so long as there are no C tokens before the `#include'. Please at least read what I'm saying before closing the bug as "invalid", the error shows only when using -g3 so it's clearly NOT a matter of "order-of-things". -- gafunchal at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40272
[Bug fortran/40270] [4.5 Regression] Revision 147883 caused many Fortran regressions
--- Comment #3 from dominiq at lps dot ens dot fr 2009-05-27 14:26 --- Some tests fail such as: ibook-dhum] f90/bug% gfc /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/actual_procedure_1.f90 Undefined symbols: "_proc_ext_", referenced from: _proc_ext_$non_lazy_ptr in ccGPjrnd.o ld: symbol(s) not found collect2: ld returned 1 exit status while others pass such as: [ibook-dhum] f90/bug% gfc /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90 [ibook-dhum] f90/bug% a.out [ibook-dhum] f90/bug% -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40270
[Bug fortran/40270] [4.5 Regression] Revision 147883 caused many Fortran regressions
--- Comment #4 from burnus at gcc dot gnu dot org 2009-05-27 14:26 ---
Thanks for reporting it. I don't quite understand why I did not see it. Anyhow,
for
PROGRAM TEST
END PROGRAM TEST
one gets the dump:
test ()
{
(void) 0;
}
main (integer(kind=4) argc, character(kind=1) * * argv)
{
static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1};
_gfortran_set_args (argc, argv);
_gfortran_set_options (8, &options.0[0]);
test ();
return 0;
}
Which looks OK. But with "-Wall -O" one gets the
warning: 'test' defined but not used
I don't see ad hoc why "test();" is not enough to be regarded as "used", but
writing TREE directly probably means that one has to do everything manually.
How about the following patch:
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 147906)
+++ gcc/fortran/trans-decl.c(working copy)
@@ -4000,6 +4001,9 @@ create_main_function (tree fndecl)
tmp = build_call_expr (fndecl, 0);
gfc_add_expr_to_block (&body, tmp);
+ /* Mark MAIN__ as used. */
+ TREE_USED (fndecl) = 1;
+
/* "return 0". */
tmp = fold_build2 (MODIFY_EXPR, integer_type_node, DECL_RESULT (ftn_main),
build_int_cst (integer_type_node, 0));
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-05-27 14:26:29
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40270
[Bug pch/13675] #including a precompiled header more than once in the same unit fails
--- Comment #20 from gafunchal at gmail dot com 2009-05-27 14:34 --- For the problem reported on Comment #16, see Bug #40272. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13675
[Bug target/40266] march-native gives -mno-sse4, but cpuinfo sse4_1
--- Comment #3 from hjl at gcc dot gnu dot org 2009-05-27 14:39 --- Subject: Bug 40266 Author: hjl Date: Wed May 27 14:39:23 2009 New Revision: 147913 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147913 Log: 2009-05-27 H.J. Lu PR target/40266 * config/i386/driver-i386.c (host_detect_local_cpu): Support AVX, SSE4, AES, PCLMUL and POPCNT. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/driver-i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40266
[Bug target/40266] march-native gives -mno-sse4, but cpuinfo sse4_1
--- Comment #4 from hjl at gcc dot gnu dot org 2009-05-27 14:54 --- Subject: Bug 40266 Author: hjl Date: Wed May 27 14:54:00 2009 New Revision: 147914 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147914 Log: 2009-05-27 H.J. Lu Backport from mainline: 2009-05-27 H.J. Lu PR target/40266 * config/i386/driver-i386.c (host_detect_local_cpu): Support AVX, SSE4, AES, PCLMUL and POPCNT. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/i386/driver-i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40266
[Bug target/40266] march-native gives -mno-sse4, but cpuinfo sse4_1
--- Comment #5 from hjl dot tools at gmail dot com 2009-05-27 14:54 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40266
[Bug target/40266] march-native gives -mno-sse4, but cpuinfo sse4_1
--- Comment #6 from seandarcy2 at gmail dot com 2009-05-27 15:10 --- (In reply to comment #1) > (In reply to comment #0) > > > cat /proc/cpuinfo: > > > > flags : .sse sse2 ssse3 sse4_1 ... > > Please post complete /proc/cpuinfo. > It's quad-core, so here's just 0 cpu: [r...@intel64-office ffmpeg]# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPUQ8300 @ 2.50GHz stepping: 10 cpu MHz : 2003.000 cache size : 2048 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm bogomips: 6000.06 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40266
[Bug fortran/40270] [4.5 Regression] Revision 147883 caused many Fortran regressions
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-27 15:06 ---
> Some tests fail such as:
> /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/actual_procedure_1.f90
> Undefined symbols:
> "_proc_ext_", referenced from:
> _proc_ext_$non_lazy_ptr in ccGPjrnd.o
Ditto here:
/tmp/ccu8LjG6.o: In function `MAIN__':
actual_procedure_1.f90:(.text+0x1aa): undefined reference to `proc_ext_'
Somehow proc_ext disappears between 003t.original and 004t.gimple. I looked at
the patch, but I cannot see anything obvious which could cause this. The
problem seems to be functions which are not contained functions which appear
after PROGRAM (and thus also after "main()"). Shortest test case:
program test
call ext()
end program test
subroutine ext()
end subroutine ext
Reversing the order is a work around. It has presumably something to do with
either to much or to little "poplevel" - at least there are no other obvious
changes regarding. How about the following patch:
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 147906)
+++ gcc/fortran/trans-decl.c(working copy)
@@ -3838,11 +3839,20 @@ add_argument_checking (stmtblock_t *bloc
static void
create_main_function (tree fndecl)
{
-
+ tree old_context;
tree ftn_main;
tree tmp, decl, result_decl, argc, argv, typelist, arglist;
stmtblock_t body;
+ old_context = current_function_decl;
+
+ if (old_context)
+{
+ push_function_context ();
+ saved_parent_function_decls = saved_function_decls;
+ saved_function_decls = NULL_TREE;
+}
+
/* main() function must be declared with global scope. */
gcc_assert (current_function_decl == NULL_TREE);
@@ -4000,6 +4010,9 @@ create_main_function (tree fndecl)
tmp = build_call_expr (fndecl, 0);
gfc_add_expr_to_block (&body, tmp);
+ /* Mark MAIN__ as used. */
+ TREE_USED (fndecl) = 1;
+
/* "return 0". */
tmp = fold_build2 (MODIFY_EXPR, integer_type_node, DECL_RESULT (ftn_main),
build_int_cst (integer_type_node, 0));
@@ -4023,6 +4036,14 @@ create_main_function (tree fndecl)
gfc_gimplify_function (ftn_main);
cgraph_finalize_function (ftn_main, false);
+
+ if (old_context)
+{
+ pop_function_context ();
+ saved_function_decls = saved_parent_function_decls;
+}
+ current_function_decl = old_context;
+
}
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2009-05-27 14:26:29 |2009-05-27 15:06:57
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40270
[Bug libstdc++/40273] New: [C++0x] Invalid conwersion to bool is reported
#include
#include
int main(int argc, char *argv[]) {
std::function f = 0;
if (f != 0) {}
return 0;
}
gcc -std=gnu++0x testcase.cpp
$ gcc -std=gnu++0x testcase.cpp
In file included from
/opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/fu
nctional:70,
from testcase.cpp:2:
/opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/tr1_impl/functional: In
function 'bool std::operator!=(const std::function<_Signature>&,
std::_M_clear_t
ype*) [with _Signature = void*()]':
testcase.cpp:8: instantiated from here
/opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/tr1_impl/functional:2116
: error: could not convert '__f' to 'bool'
--
Summary: [C++0x] Invalid conwersion to bool is reported
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC host triplet: Cygwin/GCC-trunk rev. 147886
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40273
[Bug c++/40274] New: [regression] ice in tsubst, at cp/pt.c:9289
When I compile the reduced testcase below *with -g*, I get:
$ g++ -g example_valuelist.ii
example_valuelist.ii:5: internal compiler error: in tsubst, at cp/pt.c:9289
Without -g, it is accepted. With 3.4.1, the code worked w and w/ -g.
template struct valuelist_types
{
struct null { };
template struct list { };
};
template void foo()
{
typename valuelist_types::template list v;
}
void bar()
{
valuelist_types::list<2> v;
}
--
Summary: [regression] ice in tsubst, at cp/pt.c:9289
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan at epgmod dot phys dot tue dot nl
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40274
[Bug c++/40274] [regression] ice in tsubst, at cp/pt.c:9289
--- Comment #1 from jan at epgmod dot phys dot tue dot nl 2009-05-27 16:05 --- I forgot to mention that the ICE disappears when I remove *either* the function template foo, or the function bar. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40274
[Bug fortran/40270] [4.5 Regression] Revision 147883 caused many Fortran regressions
--- Comment #6 from jb at gcc dot gnu dot org 2009-05-27 16:15 --- The patch in comment #5 fixes most of the issues, not all. Remaining gfortran.dg/elemental_dependency_1.f90 gfortran.dg/parameter_unused.f90 gfortran.dg/blockdata_3.f90 gfortran.dg/vector_subscript_4.f90 elemental_dependency and vector_subscript apparently fail due to the scan-tree-dump-times directive, the fix is probably just to update the test cases. parameter_unused and blockdata_3 fail because it complains that argc and argv are unused, even though the 003t.original shows that _gfortran_set_args is called as it should. -- jb at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40270
[Bug fortran/40270] [4.5 Regression] Revision 147883 caused many Fortran regressions
--- Comment #7 from jb at gcc dot gnu dot org 2009-05-27 16:42 ---
The patch below fixes the elemental_dependency_1 and vector_subscript_4
failures:
diff --git a/gcc/testsuite/gfortran.dg/elemental_dependency_1.f90
b/gcc/testsuite/gfortran.dg/elemental_dependency_1.f90
index 3e1f67b..d76fad6 100644
--- a/gcc/testsuite/gfortran.dg/elemental_dependency_1.f90
+++ b/gcc/testsuite/gfortran.dg/elemental_dependency_1.f90
@@ -40,14 +40,14 @@ PROGRAM main
b = a
CALL double((a(1:sz-1)), a(2:sz)) ! paren expression, temporary created
-! { dg-final { scan-tree-dump-times "A\.17\\\[4\\\]" 1 "original" } }
+! { dg-final { scan-tree-dump-times "A\.16\\\[4\\\]" 1 "original" } }
IF (ANY(a /= (/ b(1), (2*b(i), i=1,sz-1) /))) CALL abort
b = a
CALL double(a(1:sz-1)+1, a(2:sz)) ! op expression, temporary created
-! { dg-final { scan-tree-dump-times "A\.26\\\[4\\\]" 1 "original" } }
+! { dg-final { scan-tree-dump-times "A\.25\\\[4\\\]" 1 "original" } }
IF (ANY(a /= (/ b(1), (2*b(i)+2, i=1,sz-1) /))) CALL abort
@@ -59,7 +59,7 @@ PROGRAM main
b = a
CALL double(self(a(1:sz-1)), a(2:sz)) ! function expr, temporary created
-! { dg-final { scan-tree-dump-times "A\.38\\\[4\\\]" 1 "original" } }
+! { dg-final { scan-tree-dump-times "A\.37\\\[4\\\]" 1 "original" } }
IF (ANY(a /= (/ b(1), (2*b(i), i=1,sz-1) /))) CALL abort
diff --git a/gcc/testsuite/gfortran.dg/vector_subscript_4.f90
b/gcc/testsuite/gfortran.dg/vector_subscript_4.f90
index 2044684..5c341da 100644
--- a/gcc/testsuite/gfortran.dg/vector_subscript_4.f90
+++ b/gcc/testsuite/gfortran.dg/vector_subscript_4.f90
@@ -9,5 +9,5 @@
integer :: i(-1:1) = 1, j(3) = 1, k(3)
k = j((/1,1,1/)+i)
end
-! { dg-final { scan-tree-dump-times "A\.3\\\[3\\\]" 1 "original" } }
+! { dg-final { scan-tree-dump-times "A\.2\\\[3\\\]" 1 "original" } }
! { dg-final { cleanup-tree-dump "original" } }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40270
[Bug fortran/40270] [4.5 Regression] Revision 147883 caused many Fortran regressions
--- Comment #8 from burnus at gcc dot gnu dot org 2009-05-27 16:43 --- (In reply to comment #6) > The patch in comment #5 fixes most of the issues, not all. Remaining [...] > parameter_unused and blockdata_3 fail because it complains that argc and argv > are unused, even though the 003t.original shows that _gfortran_set_args is > called as it should. See patch below. The problem is (as always) that GIMPLE requires the user to do everything - while in C the compiler does all the work :-) @@ -3903,6 +3912,8 @@ /* Call some libgfortran initialization routines, call then MAIN__(). */ /* Call _gfortran_set_args (argc, argv). */ + TREE_USED (argc) = 1; + TREE_USED (argv) = 1; tmp = build_call_expr (gfor_fndecl_set_args, 2, argc, argv); gfc_add_expr_to_block (&body, tmp); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40270
[Bug libstdc++/40273] [C++0x] Invalid conwersion to bool is reported
--- Comment #1 from paolo dot carlini at oracle dot com 2009-05-27 16:52 --- Benjamin, can you have a look? Thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||bkoz at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40273
[Bug fortran/39654] ABI bug: FTELL intrinsic function not capable of large files
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-27 17:29 --- See also: http://gcc.gnu.org/wiki/LibgfortranAbiCleanup -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39654
[Bug fortran/39654] ABI bug: FTELL intrinsic function not capable of large files
--- Comment #2 from jb at gcc dot gnu dot org 2009-05-27 17:44 --- (In reply to comment #1) > See also: http://gcc.gnu.org/wiki/LibgfortranAbiCleanup > Yes, I know; I added the note to the wiki page after I filed this bug. ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39654
[Bug driver/40275] New: -combine should work for Fortran
with -fwhole-file (and -fwhole-program) coming for Fortran, it would make sense to enable -combine for Fortran as well. This should be easy as Fortran -combine doesn't need any Fortran knowledge gfortran -combine a.f90 b.f90 c.f90 is literally equivalent to cat a.f90 b.f90 c.f90 > tmp.f90 gfortran tmp.f90 things might be more complicated for .F90 (and similar) as the preprocessor needs to run before combining the files. -- Summary: -combine should work for Fortran Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40275
[Bug driver/40275] -combine should work for Fortran
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-27 17:48 --- Really -combine is going away and LTO is replacing it. It might be better to help out implementing LTO rather than wasting time on working on getting -combine working. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40275
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #23 from jv244 at cam dot ac dot uk 2009-05-27 17:51 --- I've added a 'related' PR40275 on -combine not working for Fortran. I think that as soon as the -fwhole-file patch is added (default or not yet ;-) there would be interest in -combine doing the right thing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug middle-end/40257] [4.5 Regression] Revision 147852 miscompiled 252.eon in SPEC CPU 2K
--- Comment #1 from hjl dot tools at gmail dot com 2009-05-27 17:53 --- Adding -mpc64 fixed the problem. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40257
[Bug driver/40275] -combine should work for Fortran
--- Comment #2 from jv244 at cam dot ac dot uk 2009-05-27 17:54 --- (In reply to comment #1) > Really -combine is going away and LTO is replacing it. It might be better to > help out implementing LTO rather than wasting time on working on getting > -combine working. unfortunately, I looks unlikely that LTO will support Fortran in the 4.5 time frame. Furthermore, I guess the will be differences in compile time efficiency between LTO and -combine (e.g. no need to read/write some intermediate data to disk). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40275
[Bug fortran/40197] [4.5 Regression] Spu fortran does not build
--- Comment #3 from hp at gcc dot gnu dot org 2009-05-27 17:56 --- The referred patch was committed as r147712, so I presume this is now fixed. -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40197
[Bug fortran/40276] New: Matching GENERIC procedure: Wrong INTENT should give directly an error message
Starting with PR 40039, gfortran checks the INTENT of procedures. This works - especially with the patch for PR 36947/PR 40039 - rather well if one calls a SPECIFIC procedure. However, if one calls a GENERIC procedure the error message is just: Error: There is no specific subroutine for the generic 'gen' at (1) The issue is: There is already a matching specific procedure, it just has the problem that the INTENT is wrong. If one checks for GENERIC procedures, one should continue checking the interface and if everything except of the INTENT matches, one should print an error message. Otherwise one can search for ages for the problem. NAG f95 prints for the example: Error: line 14: Dummy proc A arg 1 has different INTENT from actual proc SUB arg Error: line 14: Incompatible procedure argument for A (no. 1) of SPECIFIC Example: - module m implicit none interface gen subroutine specific(a) interface subroutine a(x) integer, intent(in) :: x end subroutine a end interface end subroutine specific end interface gen contains subroutine test() call gen(sub) end subroutine test subroutine sub(a) integer, intent(inout) :: a end subroutine sub end module m - * * * Without NAG f95 I would not have easily found the problem for the real-world program (now fixed). To show bad the error message is, here the interface (from octopus, see http://www.tddft.org). The problem was that the actual argument to "f" had for "val" intent(inout) instead of "intent(out)". interface loct_minimize function oct_minimize(method, dim, x, step, tolgrad, toldr, maxiter, f, & write_iter_info, minimum) integer :: oct_minimize integer, intent(in):: method integer, intent(in):: dim real(8), intent(inout) :: x real(8), intent(in):: step integer, intent(in):: maxiter real(8), intent(in):: tolgrad real(8), intent(in):: toldr real(8), intent(out) :: minimum interface subroutine f(n, x, val, getgrad, grad) integer, intent(in) :: n real(8), intent(in) :: x(n) real(8), intent(out) :: val integer, intent(in) :: getgrad real(8), intent(out) :: grad(n) end subroutine f subroutine write_iter_info(iter, n, val, maxdr, maxgrad, x) integer, intent(in) :: iter integer, intent(in) :: n real(8), intent(in) :: val real(8), intent(in) :: maxdr real(8), intent(in) :: maxgrad real(8), intent(in) :: x(n) end subroutine write_iter_info end interface end function oct_minimize end interface -- Summary: Matching GENERIC procedure: Wrong INTENT should give directly an error message Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: diagnostic 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=40276
[Bug fortran/40270] [4.5 Regression] Revision 147883 caused many Fortran regressions
--- Comment #9 from burnus at gcc dot gnu dot org 2009-05-27 19:49 --- Subject: Bug 40270 Author: burnus Date: Wed May 27 19:49:22 2009 New Revision: 147926 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147926 Log: 2009-05-27 Tobias Burnus PR fortran/40270 * trans-decl.c (create_main_function): Mark MAIN__ and argc/argv as TREE_USED and push/pop function_decl context if needed. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40270
[Bug libstdc++/40273] [C++0x] Invalid conwersion to bool is reported
-- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-27 20:09:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40273
[Bug fortran/40270] [4.5 Regression] Revision 147883 caused many Fortran regressions
--- Comment #10 from burnus at gcc dot gnu dot org 2009-05-27 20:12 --- > The patch below fixes the elemental_dependency_1 and vector_subscript_4 > failures: Janne committed it as Rev. 147919. Together with the fix of comment 9 and with the ABI revert-patch http://gcc.gnu.org/ml/fortran/2009-05/msg00411.html, it fixes this PR. Closing as FIXED. Thanks for the report and sorry for the breakage. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40270
[Bug libstdc++/40263] random unform real distro: tr1 vs c++0x
--- Comment #2 from bkoz at gcc dot gnu dot org 2009-05-27 20:15 --- TR1 uniform_real is not normalized, thus the surprising results. So, I used variate_generator. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40263
[Bug libstdc++/40273] [C++0x] Invalid conwersion to bool is reported
--- Comment #2 from bkoz at gcc dot gnu dot org 2009-05-27 20:32 --- Subject: Bug 40273 Author: bkoz Date: Wed May 27 20:32:30 2009 New Revision: 147930 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147930 Log: 2009-05-27 Benjamin Kosnik PR libstdc++/40273 * include/tr1_impl/functional: Add explicit cast. * testsuite/20_util/function/requirements/ explicit_instantiation.cc: New. * testsuite/20_util/function/null_pointer_comparisons.cc: New. Added: trunk/libstdc++-v3/testsuite/20_util/function/ trunk/libstdc++-v3/testsuite/20_util/function/null_pointer_comparisons.cc trunk/libstdc++-v3/testsuite/20_util/function/requirements/ trunk/libstdc++-v3/testsuite/20_util/function/requirements/explicit_instantiation.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/tr1_impl/functional -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40273
[Bug libstdc++/40273] [C++0x] Invalid conwersion to bool is reported
--- Comment #3 from bkoz at gcc dot gnu dot org 2009-05-27 20:36 --- Fixed -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40273
[Bug middle-end/40029] [4.5 Regression] Big degradation on swim/mgrid on powerpc 32/64 after alias improvement merge (gcc r145494)
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-27 20:57 --- Actually PRE seems to be more powerful than predictive commoning here. We just lose one opportunity while gaining. With predictive commoning we have 8 loads and 4 stores, 11 multiplications and one division. With PRE it is 6 loads and 4 stores, 10 multiplications and one division. The only thing we gain from predictive commoning in 4.4 is unrolling the loop once. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40029
[Bug fortran/40276] Matching GENERIC procedure: Wrong INTENT should give directly an error message
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-27 21:40 --- Created an attachment (id=17922) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17922&action=view) Very initial draft patch Some patch; now it prints: call gen(sub) 1 Error: Type/rank mismatch in argument 'a' at (1) Maybe together with the patch which gives better error messages this will produce something useful. Currently it is better than before, but only marginally. I think it should state somewhere that the generic procedure matches a specific one (and only the INTENT goes wrong). I think it should print somewhere the procedure name of the specific function. With all the recursion, having a proper error message is not trivial. I had to remove the intents_check() as it does not do recursive checks. And I could not easily do a a recursive call as then one has two formal arguments rather than a formal and an actual arguments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40276
[Bug middle-end/40271] [4.5 Regression] SPEC CPU 2000 failed to build
--- Comment #2 from burnus at gcc dot gnu dot org 2009-05-27 21:48 --- Now that PR 40270 is fixed, can you re-check? If it is still broken, I need more details. (I don't have access to SPEC CPU.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40271
[Bug target/40277] New: Spill failures for VFP_REGS with scalar-return_5.c in the testsuite.
A number of tests in today's trunk fail with -mcpu=cortex-a8 -mfloat-abi=softfp
-mfpu=neon with spill failures for the following form of instructions.
/home/ramana/cos/combined-git-master-cloned/gcc/testsuite/gcc.c-torture/compile/2804-1.c:20:
error: this is the insn:
(insn 53 29 30 2
/home/ramana/cos/combined-git-master-cloned/gcc/testsuite/gcc.c-torture/compile/2804-1.c:16
(set (subreg:TI (reg:CDI 2 r2 [151]) 0)
(subreg:TI (reg:CDI 2 r2 [154]) 0)) 715 {*neon_movti}
(expr_list:REG_DEAD (reg:CDI 2 r2 [154])
(nil)))
/home/ramana/cos/combined-git-master-cloned/gcc/testsuite/gcc.dg/compat//scalar-return-3_x.c:
In function 'checkcll':
/home/ramana/cos/combined-git-master-cloned/gcc/testsuite/gcc.dg/compat//scalar-return-3_x.c:90:
error: unable to find a register to spill in class 'VFP_REGS'
/home/ramana/cos/combined-git-master-cloned/gcc/testsuite/gcc.dg/compat//scalar-return-3_x.c:90:
error: this is the insn:
(insn 4 3 5 2
/home/ramana/cos/combined-git-master-cloned/gcc/testsuite/gcc.dg/compat//scalar-return-3_x.c:90
(set (mem/s/c:TI (reg/f:SI 12 ip [141]) [0 x+0 S16 A64])
(subreg:TI (reg:CDI 0 r0 [ x ]) 0)) 718 {*neon_movti}
(expr_list:REG_DEAD (reg/f:SI 12 ip [141])
(nil)))
This occurs today on arm-none-eabi cross with r147930 and a related fix might
be http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00703.html for one of the test
failures (2804-1.c) .
I am testing the following patch based on Paul Brook's comments later in that
thread which might fix the problem
(http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01618.html)
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -14746,7 +14746,7 @@ arm_hard_regno_mode_ok (unsigned int regno, enum
machine_mode mode)
they would use too many. */
if (regno <= LAST_ARM_REGNUM)
return !(TARGET_LDRD && GET_MODE_SIZE (mode) > 4 && (regno & 1) != 0)
- && !VALID_NEON_STRUCT_MODE (mode);
+ && (ARM_NUM_REGS (mode) <= 4);
if (regno == FRAME_POINTER_REGNUM
|| regno == ARG_POINTER_REGNUM)
--
Summary: Spill failures for VFP_REGS with scalar-return_5.c in
the testsuite.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40277
[Bug target/40277] Spill failures for VFP_REGS with scalar-return_5.c in the testsuite.
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-27 23:19:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40277
[Bug libstdc++/40278] New: -std=c++0x is error, but ;-std=gnu++0x
-- Summary: -std=c++0x is error, but ;-std=gnu++0x Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: loaden at gmail dot com GCC build triplet: mingw32 GCC host triplet: mingw32 GCC target triplet: mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40278
[Bug libstdc++/40278] -std=c++0x is error, but -std=gnu++0x is OK!
--- Comment #1 from loaden at gmail dot com 2009-05-28 00:28 --- if use -std=c++0x, will error: d:\ycdeng\qpdev\bin\..\lib\gcc\mingw32\4.4.1\include\c++\cwchar|159|error: '::swprintf' has not been declared| d:\ycdeng\qpdev\bin\..\lib\gcc\mingw32\4.4.1\include\c++\cwchar|166|error: '::vswprintf' has not been declared| ||=== Build finished: 2 errors, 0 warnings ===| if want fix, need #undef __STRICT_ANSI__, see: stdio.h or option is: -U__STRICT_ANSI__ but when change to: -std=gnu++0x, it's OK! -- loaden at gmail dot com changed: What|Removed |Added CC||loaden at gmail dot com Summary|-std=c++0x is error, but ;- |-std=c++0x is error, but - |std=gnu++0x |std=gnu++0x is OK! http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40278
[Bug libstdc++/40278] -std=c++0x is error, but -std=gnu++0x is OK!
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-28 00:31 --- This sounds like a bug in mingw's stdio.h and not GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40278
[Bug libstdc++/40278] -std=c++0x is error, but -std=gnu++0x is OK!
--- Comment #3 from loaden at gmail dot com 2009-05-28 00:48 --- (In reply to comment #2) > This sounds like a bug in mingw's stdio.h and not GCC. But why -std=gnu++0x is OK? Only -std=c++0x error? So, I think: this is not MinGW's bug, it's GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40278
[Bug libstdc++/40278] -std=c++0x is error, but -std=gnu++0x is OK!
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-05-28 00:59 --- Because __STRICT_ANSI__ means strict to the standard so -std=c++0x enables __STRICT_ANSI__. But the mingw headers don't know about C++0x standard so it does not know those functions should be enabled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40278
[Bug middle-end/40271] [4.5 Regression] SPEC CPU 2000 failed to build
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-28 02:39 --- Fixed as of revision 147931. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40271
[Bug c/40279] New: incorrect code generated when testing 31st bit of 64bit integer with optimiaztion on
$ cat bittest_64.c
extern int puts(const char *s);
typedef unsigned long long uint64;
typedef unsigned uint32;
#define BITPOS (31)
int bittest(uint64 in)
{
if ( ((uint32)(in >> BITPOS)) & 1 ) {
puts("bit is set");
return 1;
}
return 0;
}
int main()
{
return bittest(0x1000ULL);
}
$ gcc-4.4 bittest_64.c
$ ./bittest_64
$ gcc-4.4 -O2 bittest_64.c
$ ./bittest_64
bit is set
$
The assembly code generated with -O2 seems to have spurious OR-ing with the
high-order word:
bittest:
pushl %ebp
xorl%eax, %eax
movl%esp, %ebp
subl$24, %esp
movl8(%ebp), %edx
andl$-2147483648, %edx
orl 12(%ebp), %edx
jne .L6
leave
ret
.p2align 4,,7
.p2align 3
.L6:
movl$.LC0, (%esp)
callputs
movl$1, %eax
leave
ret
- This problem only happens when BITPOS is 31; correct code is generated for
other BITPOS values.
- I got the same incorrect results from both gcc 4.4.0 and my RHEL5 gcc 4.1.2
20080704 (Red Hat 4.1.2-44).
--
Summary: incorrect code generated when testing 31st bit of 64bit
integer with optimiaztion on
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jisooy at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40279
[Bug libstdc++/40278] -std=c++0x is error, but -std=gnu++0x is OK!
--- Comment #5 from loaden at gmail dot com 2009-05-28 04:01 --- (In reply to comment #4) > Because __STRICT_ANSI__ means strict to the standard so -std=c++0x enables > __STRICT_ANSI__. But the mingw headers don't know about C++0x standard so it > does not know those functions should be enabled. > Oh. I see. Thanks! I report this bug to MinGW project term now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40278
[Bug middle-end/40280] New: ICE with -fipa-pta
current trunk ICEs on : SUBROUTINE zgetmo ( a, lda, m, n, b, ldb ) INTEGER :: lda, m, n COMPLEX(8) :: a( lda, n ) INTEGER :: ldb COMPLEX(8) :: b( ldb, m ) b ( 1:n, 1:m ) = TRANSPOSE ( a ( 1:m, 1:n ) ) END SUBROUTINE zgetmo gfortran -v -c -O0 -fipa-pta test.f90 Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /data03/vondele/gcc_trunk/gcc/configure --prefix=/data03/vondele/gcc_trunk/build --enable-languages=c,c++,fortran --disable-multilib --with-ppl=/data03/vondele/gcc_trunk/build/ --with-cloog=/data03/vondele/gcc_trunk/build/ Thread model: posix gcc version 4.5.0 20090527 (experimental) [trunk revision 147915] (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-O0' '-fipa-pta' '-mtune=generic' /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/f951 test.f90 -quiet -dumpbase test.f90 -mtune=generic -auxbase test -O0 -version -fipa-pta -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/finclude -o /tmp/ccFQ9nWm.s GNU Fortran (GCC) version 4.5.0 20090527 (experimental) [trunk revision 147915] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.0 20090527 (experimental) [trunk revision 147915], GMP version 4.2.2, MPFR version 2.3.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.5.0 20090527 (experimental) [trunk revision 147915] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.0 20090527 (experimental) [trunk revision 147915], GMP version 4.2.2, MPFR version 2.3.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 test.f90: In function zgetmo: test.f90:8: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. -- Summary: ICE with -fipa-pta Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40280
[Bug middle-end/40281] New: -fprefetch-loop-arrays: ICE: in initialize_matrix_A, at tree-data-ref.c:1887
for the testcase to be attached (what about enhancing bugzilla with an option to attach files at initial submit time?) gfortran -v -c -O2 -funroll-loops -fprefetch-loop-arrays test.f90 Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /data03/vondele/gcc_trunk/gcc/configure --prefix=/data03/vondele/gcc_trunk/build --enable-languages=c,c++,fortran --disable-multilib --with-ppl=/data03/vondele/gcc_trunk/build/ --with-cloog=/data03/vondele/gcc_trunk/build/ Thread model: posix gcc version 4.5.0 20090527 (experimental) [trunk revision 147915] (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-O2' '-funroll-loops' '-fprefetch-loop-arrays' '-mtune=generic' /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/f951 test.f90 -quiet -dumpbase test.f90 -mtune=generic -auxbase test -O2 -version -funroll-loops -fprefetch-loop-arrays -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/finclude -o /tmp/ccDzkBkL.s GNU Fortran (GCC) version 4.5.0 20090527 (experimental) [trunk revision 147915] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.0 20090527 (experimental) [trunk revision 147915], GMP version 4.2.2, MPFR version 2.3.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.5.0 20090527 (experimental) [trunk revision 147915] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.0 20090527 (experimental) [trunk revision 147915], GMP version 4.2.2, MPFR version 2.3.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 test.f90: In function makedcoul: test.f90:7: internal compiler error: in initialize_matrix_A, at tree-data-ref.c:1887 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. -- Summary: -fprefetch-loop-arrays: ICE: in initialize_matrix_A, at tree-data-ref.c:1887 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40281
[Bug middle-end/40281] -fprefetch-loop-arrays: ICE: in initialize_matrix_A, at tree-data-ref.c:1887
--- Comment #1 from jv244 at cam dot ac dot uk 2009-05-28 04:57 --- Created an attachment (id=17923) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17923&action=view) testcase compile as gfortran -v -c -O2 -funroll-loops -fprefetch-loop-arrays PR40281.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40281
[Bug middle-end/40282] New: ICE with -fipa-type-escape
the to be attached testcase (with modules unfortunately) ICEs with current trunk as : > gfortran -v -c -O2 -fipa-type-escape dbcsr_util.F90 Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /data03/vondele/gcc_trunk/gcc/configure --prefix=/data03/vondele/gcc_trunk/build --enable-languages=c,c++,fortran --disable-multilib --with-ppl=/data03/vondele/gcc_trunk/build/ --with-cloog=/data03/vondele/gcc_trunk/build/ Thread model: posix gcc version 4.5.0 20090527 (experimental) [trunk revision 147915] (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-O2' '-fipa-type-escape' '-mtune=generic' /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/f951 dbcsr_util.F90 -cpp /tmp/ccoeb48T.f90 -quiet -v dbcsr_util.F90 -quiet -dumpbase dbcsr_util.F90 -mtune=generic -auxbase dbcsr_util -O2 -version -fipa-type-escape -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/finclude -o /tmp/ccO8pp8D.s GNU Fortran (GCC) version 4.5.0 20090527 (experimental) [trunk revision 147915] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.0 20090527 (experimental) [trunk revision 147915], GMP version 4.2.2, MPFR version 2.3.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../x86_64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/finclude /usr/local/include /data03/vondele/gcc_trunk/build/include /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include-fixed /usr/include End of search list. GNU Fortran (GCC) version 4.5.0 20090527 (experimental) [trunk revision 147915] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.0 20090527 (experimental) [trunk revision 147915], GMP version 4.2.2, MPFR version 2.3.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 dbcsr_util.F90:263: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. -- Summary: ICE with -fipa-type-escape Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40282
[Bug middle-end/40282] ICE with -fipa-type-escape
--- Comment #1 from jv244 at cam dot ac dot uk 2009-05-28 05:16 --- Created an attachment (id=17924) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17924&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40282
[Bug middle-end/40280] ICE with -fipa-pta
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-28 05:18 --- -fipa-pta does nothing for optimization yet. And it is known to be broken. *** This bug has been marked as a duplicate of 29212 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40280
[Bug tree-optimization/29212] ICE with -fipa-pta
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-05-28 05:18 --- *** Bug 40280 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29212
