[Bug middle-end/30700] [4.2 Regression] YA bogus undefined reference error to static func with -g and -O
--- Comment #4 from tbm at cyrius dot com 2007-04-12 07:24 --- If you click on View Bug Activity you'll see that the bug used to be marked as 4.2/4.3. Richi changed it to 4.2 only when the patch got committed to mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30700
[Bug fortran/29785] Fortran 2003: POINTER Rank Remapping
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-12 09:19 --- Cf. http://gcc.gnu.org/ml/fortran/2007-04/msg00120.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29785
[Bug fortran/31472] gfortran does not detect the illegal use of an access specification in a program, subroutine, or function
--- Comment #5 from burnus at gcc dot gnu dot org 2007-04-12 09:46 --- Subject: Bug 31472 Author: burnus Date: Thu Apr 12 09:46:30 2007 New Revision: 123735 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123735 Log: 2007-04-12 Tobias Burnus [EMAIL PROTECTED] PR fortran/31472 * decl.c (match_attr_spec): Allow PRIVATE/PUBLIC attribute in type definitions. (gfc_match_private): Allow PRIVATE statement only in specification part of modules. (gfc_match_public): Ditto for PUBLIC. (gfc_match_derived_decl): Allow PRIVATE/PUBLIC attribute only in specificification part of modules. 2007-04-12 Tobias Burnus [EMAIL PROTECTED] PR fortran/31472 * gfortran.dg/access_spec_1.f90: New test. * gfortran.dg/access_spec_2.f90: New test. * gfortran.dg/non_module_public.f90: Match new error message. Added: trunk/gcc/testsuite/gfortran.dg/access_spec_1.f90 trunk/gcc/testsuite/gfortran.dg/access_spec_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/non_module_public.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31472
[Bug fortran/31472] gfortran does not detect the illegal use of an access specification in a program, subroutine, or function
--- Comment #6 from burnus at gcc dot gnu dot org 2007-04-12 09:58 --- Fixed in 4.3. No regression and rejects only valid Fortran 2003 code - no backporting to 4.2 - Fixed. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31472
[Bug tree-optimization/24689] operand_equal_p does not return true for some equivalent ARRAY_REF
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-04-12 10:16 --- Subject: Bug 24689 Author: rguenth Date: Thu Apr 12 10:15:53 2007 New Revision: 123736 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123736 Log: 2007-04-12 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/24689 PR tree-optimization/31307 * fold-const.c (operand_equal_p): Compare INTEGER_CST array indices by value. * gimplify.c (canonicalize_addr_expr): To be consistent with gimplify_compound_lval only set operands two and three of ARRAY_REFs if they are not gimple_min_invariant. This makes it never at this place. * tree-ssa-ccp.c (maybe_fold_offset_to_array_ref): Likewise. * g++.dg/tree-ssa/pr31307.C: New testcase. * gcc.dg/tree-ssa/pr24689.c: Likewise. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr31307.C trunk/gcc/testsuite/gcc.dg/tree-ssa/pr24689.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24689
[Bug middle-end/31307] Interaction between x86_64 builtin function and inline functions causes poor code
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-04-12 10:16 --- Subject: Bug 31307 Author: rguenth Date: Thu Apr 12 10:15:53 2007 New Revision: 123736 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123736 Log: 2007-04-12 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/24689 PR tree-optimization/31307 * fold-const.c (operand_equal_p): Compare INTEGER_CST array indices by value. * gimplify.c (canonicalize_addr_expr): To be consistent with gimplify_compound_lval only set operands two and three of ARRAY_REFs if they are not gimple_min_invariant. This makes it never at this place. * tree-ssa-ccp.c (maybe_fold_offset_to_array_ref): Likewise. * g++.dg/tree-ssa/pr31307.C: New testcase. * gcc.dg/tree-ssa/pr24689.c: Likewise. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr31307.C trunk/gcc/testsuite/gcc.dg/tree-ssa/pr24689.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31307
[Bug target/31544] PPC object code generation
--- Comment #2 from trog24 at comcast dot net 2007-04-12 10:18 --- Subject: Re: PPC object code generation Hello, Thank you for your response. I have monitored the temperature and it is not overheating. The manner in which the register is corrupted from a non freeze crash (I have established that freezes are because of an infinite loop in an ISR although I am not sure which one; but, suspect the sound) does not trace from the instruction stream where the crash is noted which is why I suspect an ISR (memory is good). I have not figured out a way to trap ISR's under Darwin with a single computer like I could under OS9 where the problem does not occur (never had a freeze or DSI running a faster CPU under OS9). I do not think that the module entry protocol change will fix this problem; but, such a change will eliminate an area with a potential to corrupt a register via an errant ISR. I also just wanted to make note that there are safer ways to transition between modules in an interrupt driven environment and bug reporting was the only way to make such a note. I would make the change myself for my system only; but, do not know gcc well enough to determine where such a change would occur. In any case, I do again thank you for your response. Frank On Apr 11, 2007, at 8:55 PM, pinskia at gcc dot gnu dot org wrote: --- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-12 04:54 --- There is a red zone (stack cushion) for ppc-darwin so that the interrupt's stack should not be using the space between r1 and r1-220. So either someone wrote an interrupt incorrectly based on the ABI or you are incorrect at what you thinking is the real problem. The thing to check next is if your machine is overheating this can cause these random crashes. Also I have been using GCC on darwin for about 5 years without any issues like this except when I know either the memory is bad or the machine was overheating. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -- -- Status|UNCONFIRMED |RESOLVED Component|preprocessor|target Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31544 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31544
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #50 from rguenth at gcc dot gnu dot org 2007-04-12 10:20 --- Subject: Bug 31169 Author: rguenth Date: Thu Apr 12 10:20:42 2007 New Revision: 123737 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123737 Log: 2007-04-12 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/31169 * gcc.c-torture/execute/pr31169.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr31169.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug middle-end/31307] Interaction between x86_64 builtin function and inline functions causes poor code
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-04-12 10:27 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31307
[Bug tree-optimization/24689] operand_equal_p does not return true for some equivalent ARRAY_REF
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-04-12 10:28 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24689
[Bug target/31535] ICE on attempt to put SPE vector variables in SDA
--- Comment #1 from m dot reszat at kostal dot com 2007-04-12 10:34 --- SDA relative access renders useless for the vector load/store opcodes, as the displacement is limited to +0..+248. Hence, the compiler should not try anyway. With this bug persisting, one has to limit SDA access to variables smaller than 8 bytes (-G 7), which makes the rest of the code less efficient. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31535
[Bug c++/31545] New: No warning on missing return in if construct
This happens on other gcc versions too. It seems the checks on whether the
necessary return statement is used fail when using an if statement.
I included a little code snippet here. It compiles without warnings or errors
(all optimizations and even with -Wall no warnings are given). When executed it
crashes ofcourse because a function is called and return value expected which
is never pushed onto stack:
walter-schreppers-computer:~/ClassGen wschrep$ cat cppbug.cpp
#include iostream
using namespace std;
class Test{
public:
Test(){ fOk = false; }
~Test(){}
string indent(){
return ;
}
string faultyReturn(){
if( !fOk ) indent(); //forgot return here (but compiler does not warn
me!)
else return indent();
}
private:
bool fOk;
};
int main(){
cout testing faulty class we forgot to return in member faultyReturn
endl;
cout this should not compile, but it does and then crashes on runtime!
endl;
Test t;
cout ' t.faultyReturn() ' endl;
return 0;
}
walter-schreppers-computer:~/ClassGen wschrep$ g++ --version
i686-apple-darwin8-g++-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
walter-schreppers-computer:~/ClassGen wschrep$ g++ -Wall -O2 cppbug.cpp -o
cppbug
walter-schreppers-computer:~/ClassGen wschrep$ ./cppbug
testing faulty class we forgot to return in member faultyReturn
this should not compile, but it does and then crashes!
Bus error
--
Summary: No warning on missing return in if construct
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: walter at schreppers dot com
GCC build triplet: 5367
GCC host triplet: i686-apple-darwin8
GCC target triplet: i686-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31545
[Bug fortran/31320] Illegal read with gfortran.dg/alloc_comp_assign_2.f90 and *_3.f90
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-12 10:52 --- Is this example (PR 20541) really valid? Lahey does not complain. At compile time? Or at run time? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31320
[Bug c++/31545] No warning on missing return in if construct
--- Comment #1 from walter at schreppers dot com 2007-04-12 10:55 --- Created an attachment (id=13355) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13355action=view) Compile with any optimization (i used -O2) A similar type of bug occured to me a lot in the past. When using if's sometimes a warning is issued that a return statement is needed (even if it's not the case, or rather there is a return issued in every part of the if construct but compiler insists on writing another dummy return on the end of function just to get rid of the warning when using -Wall). Might be related to current problem where no warning or error is given when there really should be because code will crash on runtime because of the missing return statement (could be hard to find bug in a large project!). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31545
[Bug c++/31078] [4.3 Regression] warning: same canonical type node for different types with const strings
--- Comment #13 from dgregor at gcc dot gnu dot org 2007-04-12 12:48 --- Subject: Bug 31078 Author: dgregor Date: Thu Apr 12 12:47:56 2007 New Revision: 123740 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123740 Log: 2007-04-12 Douglas Gregor [EMAIL PROTECTED] PR c++/31078 PR c++/31103 * c-common.c (c_build_qualified_type): Set canonical type appropriately. 2007-04-12 Douglas Gregor [EMAIL PROTECTED] PR c++/31078 * g++.dg/other/pr31078.C: New. Added: trunk/gcc/testsuite/g++.dg/other/pr31078.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
[Bug c++/31103] [4.3 Regression] same canonical type node for VLAs
--- Comment #4 from dgregor at gcc dot gnu dot org 2007-04-12 12:48 --- Subject: Bug 31103 Author: dgregor Date: Thu Apr 12 12:47:56 2007 New Revision: 123740 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123740 Log: 2007-04-12 Douglas Gregor [EMAIL PROTECTED] PR c++/31078 PR c++/31103 * c-common.c (c_build_qualified_type): Set canonical type appropriately. 2007-04-12 Douglas Gregor [EMAIL PROTECTED] PR c++/31078 * g++.dg/other/pr31078.C: New. Added: trunk/gcc/testsuite/g++.dg/other/pr31078.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31103
[Bug c++/31078] [4.3 Regression] warning: same canonical type node for different types with const strings
--- Comment #14 from dgregor at gcc dot gnu dot org 2007-04-12 12:50 --- Fixed on mainline -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
[Bug c++/31103] [4.3 Regression] same canonical type node for VLAs
--- Comment #5 from dgregor at gcc dot gnu dot org 2007-04-12 12:50 --- Fixed on mainline -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31103
[Bug c++/31505] [4.3 Regression] Canonical types failures
--- Comment #13 from dgregor at gcc dot gnu dot org 2007-04-12 12:52 --- Same problem/cause as 31103, which is now fixed on mainline. *** This bug has been marked as a duplicate of 31103 *** -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31505
[Bug c++/31103] [4.3 Regression] same canonical type node for VLAs
--- Comment #6 from dgregor at gcc dot gnu dot org 2007-04-12 12:52 --- *** Bug 31505 has been marked as a duplicate of this bug. *** -- dgregor at gcc dot gnu dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31103
[Bug middle-end/31322] [4.3 Regression] ld: Invalid symbol type for plabel (.libs/debug_list.o, __gxx_personality_v0).
--- Comment #6 from patchapp at dberlin dot org 2007-04-12 12:55 --- Subject: Bug number PR middle-end/31322 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00611.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31322
[Bug fortran/31546] New: add --enable-intermodule
add option to build libgfortran and fortran with -combine. This creates a smaller binary and may also create a faster binary. The former is the main motivation from my POV. -- Summary: add --enable-intermodule Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aldot at gcc dot gnu dot org BugsThisDependsOn: 31537 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31546
[Bug fortran/31546] add --enable-intermodule
--- Comment #1 from aldot at gcc dot gnu dot org 2007-04-12 15:03 --- Created an attachment (id=13356) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13356action=view) patch to add --enable-intermodule to libgfortran -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31546
[Bug fortran/31547] New: Document when CPP is called and document the f95-cpp-input option
Currently, nowhere is documented that gfortran calls for .F, .FPP, .F90, .F95 and .F2003 the C Preprocessor (in the traditional mode, cf. PR 18428). I don't know whether it fits better to gfortran.texi or invoke.texi. In addition, we don't document the option to call the preprocessor for files without capital letter (this is especially needed on operating systems where the file extension is case insensitive): -x f95-cpp-input -x f77-cpp-input and how to suppress the calling of the preprocessor, i.e. -x f77 -x f95 f95 and f95-cpp-input are documented (or rather mentioned) in gcc(1). However, one should also add f77 and f77-cpp-input to the gcc manpage. (Cross ref: a -cpp option is proposed for gfortran in PR 18428) -- Summary: Document when CPP is called and document the f95-cpp- input option Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: documentation 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=31547
[Bug middle-end/31548] New: __builtin_cabsf(z) squared should be optimized
The following Fortran program program test complex :: z real :: r r = abs(z)**2 print *, r end program test produces the following tree: D.1352 = __builtin_cabsf (z); D.1353 = D.1352 * D.1352; r = D.1353; The complex value is naively calculated as: sqrt( (_Real_ z)*(_Real_ z) + (_Imag_ z)*(_Imag_ z) ) However, since the value is squared afterwards, the square root can be simply removed. Calculating |...|^2 is not that uncommon in some codes. -- Summary: __builtin_cabsf(z) squared should be optimized Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: middle-end 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=31548
[Bug middle-end/31548] __builtin_cabsf(z) squared should be optimized
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-04-12 15:41 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-12 15:41:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31548
[Bug middle-end/31548] __builtin_cabsf(z) squared should be optimized
--- Comment #2 from ubizjak at gmail dot com 2007-04-12 15:53 --- (In reply to comment #0) The complex value is naively calculated as: sqrt( (_Real_ z)*(_Real_ z) + (_Imag_ z)*(_Imag_ z) ) However, since the value is squared afterwards, the square root can be simply removed. This optimization can also be applied to squared hypot(). -- ubizjak at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31548
[Bug rtl-optimization/31549] New: Documentation for -frtl-abstract-sequences is in the wrong place
In invoke.texi, the description for -frtl-abstract-sequences is located between -frounding-math and -fsignaling-nans. It means that the description is located in a @table specially dedicated to GCC floating-point compliance, while the option is not related to floating-point arithmetic at all. It should be moved in another table, perhaps before --param. -- Summary: Documentation for -frtl-abstract-sequences is in the wrong place Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: guillaume dot melquiond at ens-lyon dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31549
[Bug c/31331] ICE on invalid function attribute syntax for main()
--- Comment #1 from j at uriah dot heep dot sax dot de 2007-04-12 16:32 --- I disagree the invalid syntax. According to the formal attribute syntax description: ``Any list of specifiers and qualifiers at the start of a declaration may contain attribute specifiers, whether or not such a list may in that context contain storage class specifiers.'' it is a perfectly valid use. Syntactically, the ``int main(void)'' part of that function definition is a declarator, so it essentially combines a declaration with a definition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31331
[Bug fortran/31550] New: [regression] f951: segfault in fold-const.c:1963
gfortran-20070412 segfaults on the code below, gfortran-20070316 doesn't. $ cat segfault.f90 MODULE class_dummy_atom_types TYPE :: dummy_atom_list TYPE(dummy_atom), DIMENSION(:), POINTER :: table INTEGER :: nused END TYPE TYPE :: dummy_atom TYPE(dummy_atom_private), POINTER :: p END TYPE TYPE :: dummy_atom_private TYPE(dummy_atom_list) :: neighbours END TYPE END MODULE MODULE class_dummy_atom_list USE class_dummy_atom_types, ONLY: dummy_atom_list INTERFACE SUBROUTINE dummy_atom_list_init_copy(this, other) USE class_dummy_atom_types, ONLY: dummy_atom_list TYPE(dummy_atom_list), INTENT(out) :: this TYPE(dummy_atom_list), INTENT(in) :: other END SUBROUTINE END INTERFACE INTERFACE SUBROUTINE dummy_atom_list_merge(this, other) USE class_dummy_atom_types, ONLY: dummy_atom_list TYPE(dummy_atom_list), INTENT(inout) :: this TYPE(dummy_atom_list), INTENT(in):: other END SUBROUTINE END INTERFACE END MODULE SUBROUTINE dummy_atom_list_init_copy(this, other) USE class_dummy_atom_list, ONLY: dummy_atom_list, dummy_atom_list_merge TYPE(dummy_atom_list), INTENT(out) :: this TYPE(dummy_atom_list), INTENT(in) :: other this%table(1:this%nused) = other%table(1:other%nused) END SUBROUTINE $ gfortran-svn -g -Wall segfault.f90 segfault.f90: In function 'dummy_atom_list_init_copy': segfault.f90:42: internal compiler error: Segmentation fault $ gfortran-svn -v gcc version 4.3.0 20070412 (experimental) Backtrace: run -g -Wall segfault.f90 Starting program: /h/franke/packages/i686-pc-linux-gnu/gcc/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951 -g -Wall segfault.f90 dummy_atom_list_init_copy Program received signal SIGSEGV, Segmentation fault. size_binop (code=EXACT_DIV_EXPR, arg0=0x0, arg1=0xb7c8c4b4) at ../../../svn/gcc/gcc/fold-const.c:1963 1963 tree type = TREE_TYPE (arg0); (gdb) bt #0 size_binop (code=EXACT_DIV_EXPR, arg0=0x0, arg1=0xb7c8c4b4) at ../../../svn/gcc/gcc/fold-const.c:1963 #1 0x08230389 in gimplify_compound_lval (expr_p=0xb7c912ec, pre_p=0xbff57a00, post_p=0xbff579fc, fallback=fb_lvalue) at ../../../svn/gcc/gcc/gimplify.c:1788 #2 0x0822c6da in gimplify_expr (expr_p=0xb7c912ec, pre_p=0xbff57a00, post_p=0xbff579fc, gimple_test_f=0x8337ec0 is_gimple_lvalue, fallback=fb_lvalue) at ../../../svn/gcc/gcc/gimplify.c:5503 #3 0x0823e507 in gimplify_modify_expr (expr_p=0xb7ce7a28, pre_p=0xbff57a00, post_p=0xbff579fc, want_value=0 '\0') at ../../../svn/gcc/gcc/gimplify.c:3597 #4 0x0822bfcb in gimplify_expr (expr_p=0xb7ce7a28, pre_p=0xbff57a00, post_p=0xbff579fc, gimple_test_f=0x8338360 is_gimple_stmt, fallback=fb_none) at ../../../svn/gcc/gcc/gimplify.c:5543 #5 0x0823239f in gimplify_stmt (stmt_p=0xb7ce7a28) at ../../../svn/gcc/gcc/gimplify.c:4334 #6 0x0822bd55 in gimplify_expr (expr_p=0xbff57b30, pre_p=0xbff57ae0, post_p=0xbff57adc, gimple_test_f=0x8338360 is_gimple_stmt, fallback=fb_none) at ../../../svn/gcc/gcc/gimplify.c:3794 #7 0x0823239f in gimplify_stmt (stmt_p=0xbff57b30) at ../../../svn/gcc/gcc/gimplify.c:4334 #8 0x08234d0f in gimplify_and_add (t=0xb7cfb914, list_p=0xbff57c00) at ../../../svn/gcc/gcc/gimplify.c:340 #9 0x082355b0 in gimplify_loop_expr (expr_p=0xb7ce7a40, pre_p=0xbff57c00) at ../../../svn/gcc/gcc/gimplify.c:1305 #10 0x0822c417 in gimplify_expr (expr_p=0xb7ce7a40, pre_p=0xbff57c00, post_p=0xbff57bfc, gimple_test_f=0x8338360 is_gimple_stmt, fallback=fb_none) at ../../../svn/gcc/gcc/gimplify.c:5658 #11 0x0823239f in gimplify_stmt (stmt_p=0xb7ce7a40) at ../../../svn/gcc/gcc/gimplify.c:4334 #12 0x0822bd55 in gimplify_expr (expr_p=0xb7ce02f0, pre_p=0xbff57ce0, post_p=0xbff57cdc, gimple_test_f=0x8338360 is_gimple_stmt, fallback=fb_none) at ../../../svn/gcc/gcc/gimplify.c:3794 #13 0x0823239f in gimplify_stmt (stmt_p=0xb7ce02f0) at ../../../svn/gcc/gcc/gimplify.c:4334 #14 0x08233bd7 in gimplify_to_stmt_list (stmt_p=0xb7ce02f0) at ../../../svn/gcc/gcc/gimplify.c:4342 #15 0x082341ad in gimplify_bind_expr (expr_p=0xb7ce7a58, pre_p=0xbff57e30) at ../../../svn/gcc/gcc/gimplify.c:1095 #16 0x0822c07c in gimplify_expr (expr_p=0xb7ce7a58, pre_p=0xbff57e30, post_p=0xbff57e2c, gimple_test_f=0x8338360 is_gimple_stmt, fallback=fb_none) at ../../../svn/gcc/gcc/gimplify.c:5654 #17 0x0823239f in gimplify_stmt (stmt_p=0xb7ce7a58) at ../../../svn/gcc/gcc/gimplify.c:4334 #18 0x0822bd55 in gimplify_expr (expr_p=0xb7ce0318, pre_p=0xbff57f10, post_p=0xbff57f0c, gimple_test_f=0x8338360 is_gimple_stmt, fallback=fb_none) at ../../../svn/gcc/gcc/gimplify.c:3794 #19 0x0823239f in gimplify_stmt (stmt_p=0xb7ce0318) at ../../../svn/gcc/gcc/gimplify.c:4334 #20 0x08233bd7 in gimplify_to_stmt_list (stmt_p=0xb7ce0318) at ../../../svn/gcc/gcc/gimplify.c:4342 #21 0x082341ad in gimplify_bind_expr (expr_p=0xb7cfd470, pre_p=0xbff58060) at ../../../svn/gcc/gcc/gimplify.c:1095 #22 0x0822c07c in gimplify_expr (expr_p=0xb7cfd470, pre_p=0xbff58060, post_p=0xbff5805c, gimple_test_f=0x8338360 is_gimple_stmt
[Bug fortran/31550] [regression] f951: segfault in fold-const.c:1963
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-04-12 17:08 --- Please note, that the USE-ONLY of dummy_atom_list_merge is crucial. Without it, the segfault does not occur. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31550
[Bug fortran/31250] Initialization expr as constant character length rejected
-- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-03-17 21:28:22 |2007-04-12 17:38:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31250
[Bug fortran/31551] New: ice in fold_convert, at fold-const.c:2330
internal compiler error: in fold_convert, at fold-const.c:2330
$ gfortran-svn -v
gcc version 4.3.0 20070412 (experimental)
Backtrace:
#0 fancy_abort (file=0x86fb400 ../../../svn/gcc/gcc/fold-const.c, line=2330,
function=0x86fb326 fold_convert)
at ../../../svn/gcc/gcc/diagnostic.c:656
#1 0x082084ec in fold_convert (type=0xb7cfe1b0, arg=0xb7cf4ed8) at
../../../svn/gcc/gcc/fold-const.c:2330
#2 0x080c94d4 in gfc_trans_scalar_assign (lse=0xbfe037b4, rse=0xbfe0378c,
ts={type = BT_DERIVED, kind = 0, derived = 0x889da90, cl = 0x0},
l_is_temp=0 '\0', r_is_var=1 '\001') at
../../../svn/gcc/gcc/fortran/trans-expr.c:3444
#3 0x080ce642 in gfc_trans_assignment (expr1=0x889e870, expr2=0x8897a68,
init_flag=0 '\0') at ../../../svn/gcc/gcc/fortran/trans-expr.c:3839
#4 0x080cee13 in gfc_trans_assign (code=0x8898ee0) at
../../../svn/gcc/gcc/fortran/trans-expr.c:3991
#5 0x080b075d in gfc_trans_code (code=0x8898ee0) at
../../../svn/gcc/gcc/fortran/trans.c:473
#6 0x080c7aba in gfc_generate_function_code (ns=0x8896a40) at
../../../svn/gcc/gcc/fortran/trans-decl.c:3208
#7 0x0808c4f4 in gfc_parse_file () at
../../../svn/gcc/gcc/fortran/parse.c:3264
#8 0x080ab600 in gfc_be_parse_file (set_yydebug=0) at
../../../svn/gcc/gcc/fortran/f95-lang.c:305
#9 0x08300ee8 in toplev_main (argc=4, argv=0xbfe03a64) at
../../../svn/gcc/gcc/toplev.c:1050
#10 0x080ed132 in main (argc=15, argv=0x0) at ../../../svn/gcc/gcc/main.c:35
I currently can not provide a testcase ordering seems to be important ...
--
Summary: ice in fold_convert, at fold-const.c:2330
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31551
[Bug fortran/31551] ice in fold_convert, at fold-const.c:2330
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-04-12 17:46 --- Adding FX to CC as requested on the mailing list. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31551
[Bug middle-end/30700] [4.2 Regression] YA bogus undefined reference error to static func with -g and -O
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2007-04-12 17:58 --- Does that mean that the patch for mainline wouldn't work on gcc 4.2 branch or that the patch just hasn't been applied to gcc 4.2 branch yet? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30700
[Bug rtl-optimization/31552] New: -fcall-used-vXX turns into ICE
If gcc runs out of volatile VMX registers, he is going to save the non volatile registers. This fails if one of them is defined in -fcall-used-vXX (test case attaced) -- Summary: -fcall-used-vXX turns into ICE Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at breakpoint dot cc GCC build triplet: powerpc-unknown-linux-gnu GCC host triplet: powerpc-unknown-linux-gnu GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31552
[Bug rtl-optimization/31552] -fcall-used-vXX turns into ICE
--- Comment #1 from gcc at breakpoint dot cc 2007-04-12 18:02 --- Created an attachment (id=13357) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13357action=view) test case for the internal compiler error: in propagate_one_insn, at flow.c:1699 Reults ins: powerpc64-unknown-linux-gnu-gcc -Wall -maltivec -Os -mabi=altivec -fcall-used-v20 -o altivec_prolog.o altivec_prolog.c -c altivec_prolog.c: In function 'f2': altivec_prolog.c:64: error: Attempt to delete prologue/epilogue insn: (insn 231 230 232 2 (set (reg:V4SI 97 20) (mem:V4SI (plus:DI (reg/f:DI 1 1) (reg:DI 0 0)) [1 S16 A8])) -1 (nil) (nil)) altivec_prolog.c:64: internal compiler error: in propagate_one_insn, at flow.c:1699 Please submit a full bug report, with preprocessed source if appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31552
[Bug rtl-optimization/31552] -fcall-used-vXX turns into ICE
--- Comment #2 from gcc at breakpoint dot cc 2007-04-12 18:04 --- Created an attachment (id=13358) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13358action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31552
[Bug fortran/31471] gfortran does not detect a labeled FORALL with an unlabeled END FORALL
--- Comment #4 from patchapp at dberlin dot org 2007-04-12 18:10 --- Subject: Bug number PR31471 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00694.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31471
[Bug fortran/31553] New: incorrect processing of formatted character output
a edit descriptor for character output produces repeatable, but incorrect output in some situations when the width of the field is not explicitly specified in the edit descriptor, but is inferred from the number of characters in the write list item. -- Summary: incorrect processing of formatted character output Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brad dot finney at humboldt dot edu GCC build triplet: 4.3.0 GCC host triplet: i386-pc-mingw32 GCC target triplet: i386-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31553
[Bug fortran/31250] Initialization expr as constant character length rejected
--- Comment #2 from patchapp at dberlin dot org 2007-04-12 18:12 --- Subject: Bug number PR 31250 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00693.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31250
[Bug fortran/31266] Spurious(?) warning about character truncation
--- Comment #3 from patchapp at dberlin dot org 2007-04-12 18:13 --- Subject: Bug number PR31266 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00695.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31266
[Bug fortran/30871] Pointer to substring rejected with Different character lengths in pointer assignment
--- Comment #2 from tobi at gcc dot gnu dot org 2007-04-12 18:17 --- This is not fixed with the patch for PR31266. The remaining issue looks closely related to not using byte-sized strides in array descriptors. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30871
[Bug fortran/31553] incorrect processing of formatted character output
--- Comment #1 from brad dot finney at humboldt dot edu 2007-04-12 18:20 --- Created an attachment (id=13359) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13359action=view) test program demonstrating bug behavior along with program output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31553
[Bug fortran/31553] incorrect processing of formatted character output
--- Comment #2 from brad dot finney at humboldt dot edu 2007-04-12 18:22 --- same bug noted on version 4.0.3 (intel linux 64bit) noted. -- brad dot finney at humboldt dot edu changed: What|Removed |Added CC||brad dot finney at humboldt ||dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31553
[Bug fortran/31550] [regression] f951: segfault in fold-const.c:1963
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-12 18:52 --- (In reply to comment #1) Please note, that the USE-ONLY of dummy_atom_list_merge is crucial. Without it, the segfault does not occur. Confirmed - I have a bad feeling about this one! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-12 18:52:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31550
[Bug fortran/31553] incorrect processing of formatted character output
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-12 19:00 --- Which version are you using under i386-pc-mingw32? (I see Reported against 4.3.0, however - see below.) I'm asking because 4.0.3 (intel linux 64bit) is very old. GCC 4.0.x contained the freshly added and still a bit buggy gfortran. One should use version 4.1.x, which is much more stable, or the 4.2.0 or 4.3.0 which contain even fewer Fortran bugs. Binaries are available from: http://gcc.gnu.org/wiki/GFortranBinaries Using gfortran 4.1.3 20070302 (prerelease) gfortran 4.2.0 20070412 (prerelease) gfortran 4.3.0 20070412 (experimental) I get the same result as with NAG f95, sunf95 and Intel ifort: (4(a,' | ')) 1234 | 12345678 | 1234567890123456 | 12345678901234567890 | 1234 | 12345678 | 1234567890123456 | 12345678901234567890 | 1234 | 12345678 | 1234567890123456 | 12345678901234567890 | 1234 | 12345678 | 1234567890123456 | 12345678901234567890 | -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31553
[Bug libstdc++/31554] New: stable_partition assumes iterator difference type is always ptrdiff_t
Instantiating stable_partition with an iterator where the difference_type is something different than ptrdiff_t results in an error like this: .../bits/stl_algo.h: In function `_ForwardIterator std::stable_partition(_ForwardIterator, _ForwardIterator, _Predicate) [with _ForwardIterator = my_iterator, _Predicate = bool (*)(double)]': test.c:32: instantiated from here .../bits/stl_algo.h:2154: error: no matching function for call to `__stable_partition_adaptive(my_iterator, my_iterator, bool (*)(double), short int, double*, ptrdiff_t)' The __stable_parition_adaptive effectively requires the __len and __buffer_size arguments to have the same type, and stable_parition calls it with one of them always as ptrdiff_t. -- Summary: stable_partition assumes iterator difference type is always ptrdiff_t Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: djg at cray dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31554
[Bug libstdc++/31555] New: stable_partition assumes iterator difference type is always ptrdiff_t
Instantiating stable_partition with an iterator where the difference_type is something different than ptrdiff_t results in an error like this: .../bits/stl_algo.h: In function `_ForwardIterator std::stable_partition(_ForwardIterator, _ForwardIterator, _Predicate) [with _ForwardIterator = my_iterator, _Predicate = bool (*)(double)]': test.c:32: instantiated from here .../bits/stl_algo.h:2154: error: no matching function for call to `__stable_partition_adaptive(my_iterator, my_iterator, bool (*)(double), short int, double*, ptrdiff_t)' The __stable_parition_adaptive effectively requires the __len and __buffer_size arguments to have the same type, and stable_parition calls it with one of them always as ptrdiff_t. -- Summary: stable_partition assumes iterator difference type is always ptrdiff_t Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: djg at cray dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31555
[Bug libstdc++/31555] stable_partition assumes iterator difference type is always ptrdiff_t
--- Comment #1 from djg at cray dot com 2007-04-12 19:09 --- *** This bug has been marked as a duplicate of 31554 *** -- djg at cray dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31555
[Bug libstdc++/31554] stable_partition assumes iterator difference type is always ptrdiff_t
--- Comment #1 from djg at cray dot com 2007-04-12 19:09 --- *** Bug 31555 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31554
[Bug fortran/31266] Spurious(?) warning about character truncation
--- Comment #4 from tobi at gcc dot gnu dot org 2007-04-12 19:10 --- Subject: Bug 31266 Author: tobi Date: Thu Apr 12 19:10:10 2007 New Revision: 123759 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123759 Log: PR fortran/31266 fortran/ * primary.c (gfc_variable_attr): Don't copy string length if it doesn't make sense. * resolve.c (resolve_code): Clarify error message. testsuite/ * gfortran.dg/char_assign_1.f90: New. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31266
[Bug fortran/31234] Thread-safety of random_number should be documented.
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-04-12 19:23 --- Subject: Bug 31234 Author: dfranke Date: Thu Apr 12 19:23:03 2007 New Revision: 123760 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123760 Log: 2007-04-12 Daniel Franke [EMAIL PROTECTED] PR fortran/31234 * intrinsic.texi (RANDOM_SEED, RANDOM_NUMBER): New. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31234
[Bug fortran/31234] Thread-safety of random_number should be documented.
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-04-12 19:27 --- Subject: Bug 31234 Author: dfranke Date: Thu Apr 12 19:27:07 2007 New Revision: 123761 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123761 Log: 2007-04-12 Daniel Franke [EMAIL PROTECTED] PR fortran/31234 * intrinsic.texi (RANDOM_SEED, RANDOM_NUMBER): New. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31234
[Bug fortran/31234] Thread-safety of random_number should be documented.
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-04-12 19:28 --- Documented in trunk and 4.2 branch. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31234
[Bug libstdc++/31556] New: find_if uses operator! instead of conversion to bool
Section 25, lib.algorithms, paragraph 7, defines the Predicate parameter in std::find_if and others as returning a value that need only be usable in the controlling-expression of an if statement. libstdc++'s find_if incorrectly relies on the operator! function, which may not be usable. In a case where operator! is private, this error results: test.c: In function `_InputIterator std::__find_if(_InputIterator, _InputIterator, _Predicate, std::input_iterator_tag) [with _InputIterator = std::_List_iteratordouble, _Predicate = my_bool (*)(double)]': .../include/c++/4.1.1/bits/stl_algo.h:338: instantiated from `_InputIterator std::find_if(_InputIterator, _InputIterator, _Predicate) [with _InputIterator = std::_List_iteratordouble, _Predicate = my_bool (*)(double)]' test.c:16: instantiated from here test.c:7: error: `bool my_bool::operator!() const' is private .../include/c++/4.1.1/bits/stl_algo.h:188: error: within this context -- Summary: find_if uses operator! instead of conversion to bool Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: djg at cray dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31556
[Bug fortran/31550] [regression] f951: segfault in fold-const.c:1963
--- Comment #3 from pault at gcc dot gnu dot org 2007-04-12 19:37 ---
What is really odd is that the same code (see below) is produced, with or
without the ONLY... It looks fine in either case and identical to that produced
by 4.2. *sigh*
Is this a problem with the backend?
Paul
dummy_atom_list_init_copy (this, other)
{
int8 D.1373;
int8 D.1372;
struct dummy_atom[0:] * D.1371;
int8 D.1370;
int8 D.1369;
struct dummy_atom[0:] * D.1368;
D.1368 = (struct dummy_atom[0:] *) other-table.data;
D.1369 = other-table.offset;
D.1370 = (int8) other-nused;
D.1371 = (struct dummy_atom[0:] *) this-table.data;
D.1372 = this-table.offset;
D.1373 = (int8) this-nused;
{
int8 D.1376;
int8 D.1375;
int8 S.0;
D.1375 = other-table.dim[0].stride;
D.1376 = this-table.dim[0].stride;
S.0 = 1;
while (1)
{
if (S.0 (int8) other-nused) goto L.1;
(*D.1371)[S.0 * D.1376 + D.1372] = (*D.1368)[S.0 * D.1375 + D.1369];
S.0 = S.0 + 1;
}
L.1:;
}
}
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31550
[Bug libstdc++/31556] find_if uses operator! instead of conversion to bool
--- Comment #1 from chris at bubblescope dot net 2007-04-12 19:37 --- There is also a large number of other places which do !pred in various functions I believe there are other bugs of this type, relating to and ||. If someone really cared about this, they could do a complete sweep of the library. Have you actually had a problem with this? Or is it just a problem with strict standards compliance? -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31556
[Bug fortran/31250] Initialization expr as constant character length rejected
--- Comment #3 from tobi at gcc dot gnu dot org 2007-04-12 19:48 --- Subject: Bug 31250 Author: tobi Date: Thu Apr 12 19:48:06 2007 New Revision: 123763 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123763 Log: PR fortran/31250 fortran/ * decl.c (match_char_spec): Move check for negative CHARACTER length ... * resolve.c (resolve_charlen): ... here. (resolve_types): Resolve CHARACTER lengths earlier. teststuite/ * gfortran.dg/char_length_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/char_length_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31250
[Bug libstdc++/31554] stable_partition assumes iterator difference type is always ptrdiff_t
--- Comment #2 from pcarlini at suse dot de 2007-04-12 19:59 --- Confirmed. I will look into this as soon as possible, first blush, I'm wondering whether just calling __stable_partition_adaptive with a last argument: ..., _DistanceType(__buf.size())) would be enough to fix the problem? What do you think? -- pcarlini at suse dot de changed: What|Removed |Added CC||pcarlini at suse dot de Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-12 19:59:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31554
[Bug middle-end/31307] Interaction between x86_64 builtin function and inline functions causes poor code
--- Comment #13 from michael dot meissner at amd dot com 2007-04-12 20:18 --- How hard would it be to back port the change to 4.1.3 and 4.2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31307
[Bug libstdc++/31556] find_if uses operator! instead of conversion to bool
--- Comment #2 from pcarlini at suse dot de 2007-04-12 20:26 --- Thanks Chris. Apparently, we don't have *that* many ! on the return of the predicates or other logicals, maybe ~10. The task of fixing all of them seems manageable rather easily. Let's make sure I understand: it would be just matter of explicitely converting to bool, like !bool(__pred(*__first)), right? -- pcarlini at suse dot de changed: What|Removed |Added CC||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31556
[Bug fortran/31553] incorrect processing of formatted character output
--- Comment #4 from brad dot finney at humboldt dot edu 2007-04-12 20:29 --- (In reply to comment #3) Which version are you using under i386-pc-mingw32? (I see Reported against 4.3.0, however - see below.) gcc version 4.3.0 20061021 I had not tried on the latest version, so I apologize for posting a problem that has already been corrected. I'm asking because 4.0.3 (intel linux 64bit) is very old. GCC 4.0.x contained the freshly added and still a bit buggy gfortran. One should use version 4.1.x, which is much more stable, or the 4.2.0 or 4.3.0 which contain even fewer Fortran bugs. Binaries are available from: http://gcc.gnu.org/wiki/GFortranBinaries Using gfortran 4.1.3 20070302 (prerelease) gfortran 4.2.0 20070412 (prerelease) gfortran 4.3.0 20070412 (experimental) I get the same result as with NAG f95, sunf95 and Intel ifort: (4(a,' | ')) 1234 | 12345678 | 1234567890123456 | 12345678901234567890 | 1234 | 12345678 | 1234567890123456 | 12345678901234567890 | 1234 | 12345678 | 1234567890123456 | 12345678901234567890 | 1234 | 12345678 | 1234567890123456 | 12345678901234567890 | As do I with version 4.3.0 20070406 Thanks, and again sorry. I did check the list of bugs first, but didn't see one that seemed to fit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31553
[Bug libstdc++/31556] find_if uses operator! instead of conversion to bool
--- Comment #3 from pcarlini at suse dot de 2007-04-12 20:34 --- Forgot ;) -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-12 20:34:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31556
[Bug libstdc++/31556] find_if uses operator! instead of conversion to bool
--- Comment #4 from chris at bubblescope dot net 2007-04-12 20:36 --- Thats my understanding yes. It might possibly at the same time be worth fixing predicates appears in and ||, which have to be changed into nested ifs I think. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31556
[Bug libstdc++/31556] find_if uses operator! instead of conversion to bool
--- Comment #5 from pcarlini at suse dot de 2007-04-12 20:39 --- (In reply to comment #4) Thats my understanding yes. Ok, thanks. It might possibly at the same time be worth fixing predicates appears in and ||, which have to be changed into nested ifs I think. Luckily, very, very few of those: in most of the cases, we have just one expression not involving the predicate ANDed or ORed with the negation of the predicate. Or the negated predicate alone. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31556
[Bug libstdc++/31554] stable_partition assumes iterator difference type is always ptrdiff_t
--- Comment #3 from djg at cray dot com 2007-04-12 21:53 --- (In reply to comment #2) At a glance, that looks right to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31554
[Bug libstdc++/31556] find_if uses operator! instead of conversion to bool
-- pcarlini at suse dot de changed: What|Removed |Added CC|pcarlini at suse dot de | AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31556
[Bug libstdc++/31554] stable_partition assumes iterator difference type is always ptrdiff_t
-- pcarlini at suse dot de changed: What|Removed |Added CC|pcarlini at suse dot de | AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31554
[Bug target/31557] New: return 0x80000000UL code gen can be improved
Testcase:
unsigned int f(void)
{
return 0x8001UL;
}
This should be able to done in three instructions:
.f:
li 3,1
oris 3,3,0x8000
blr
Right now it is done as:
.L.f:
li 3,0
ori 3,3,32768
sldi 3,3,16
ori 3,3,1
blr
Which is (0x8000 16) | 1 but (0x8000 16) is what is done for oris.
--
Summary: return 0x8000UL code gen can be improved
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31557
[Bug middle-end/31307] Interaction between x86_64 builtin function and inline functions causes poor code
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-04-12 22:32 --- (In reply to comment #13) How hard would it be to back port the change to 4.1.3 and 4.2? Why do you want to that, this is not a regression at all. I am tried of people asking questions like this for missed optimization bugs. It is not like we have a policy for patches already that should be clear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31307
[Bug middle-end/31307] Interaction between x86_64 builtin function and inline functions causes poor code
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-04-12 22:36 --- 4.2.0 wouldn't be too difficult (a svn merge of the change to 4.2.0 branch succeeds without problems), but 4.1.3 has ineffective store copyprop (see PR26135). Of course this is not a regression, so a backport is not appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31307
[Bug middle-end/30700] [4.2 Regression] YA bogus undefined reference error to static func with -g and -O
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-04-12 22:41 --- The latter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30700
[Bug c++/2204] G++ doesn't check (member) function parameter for abstract-ness.
--- Comment #14 from pedro dot lamarao at mndfck dot org 2007-04-12 23:12 --- This bug is not reproducible with current mainline. I suspect it was closed years ago and should be closed by now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2204
[Bug target/31558] New: ICE with __builtin_vec_splat
C++ testcase (compile with -maltivec):
struct SubData
{
inline const Float Clamp(Float f, Float f0, Float f1)
}
inline const void SinCos(Float angle, Float sine, Float cosine)
{
C0 = __builtin_vec_splat(_simdCosEstCoefficients, 0);
C1 = __builtin_vec_splat(_simdCosEstCoefficients, 1);
---
cable.ii:3: error: 'Float' does not name a type
cable.ii:5: error: 'Float' has not been declared
cable.ii:5: error: 'Float' has not been declared
cable.ii:5: error: 'Float' has not been declared
cable.ii:8: error: expected `}' at end of input
cable.ii: In member function 'const void SubData::SinCos(int, int, int)':
cable.ii:7: error: 'C0' was not declared in this scope
cable.ii:7: error: '_simdCosEstCoefficients' was not declared in this scope
cable.ii:8: error: 'C1' was not declared in this scope
cable.ii:8: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in cxx_types_compatible_p, at
cp/cp-objcp-common.c:173
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE with __builtin_vec_splat
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, error-recovery
Severity: minor
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31558
gfortran crash
I'm not going to get into registering to submit a bug in the formal way, I am trying urgently to get some quick and dirty results. But the gfortran compiler told me to report a bug, so I am doing so Command line [EMAIL PROTECTED] QDPfig]# gfortran -o contour_fun contour_fun.f90 Error message contour_fun.f90: In function 'findval': contour_fun.f90:91: internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:403 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Version [EMAIL PROTECTED] QDPfig]# gfortran -v Using built-in specs. Target: i386-apple-darwin8 Configured with: ../gcc-4.2-20060610/configure --prefix=/sw --prefix=/sw/lib/gcc4 --enable-languages=c,c++,fortran,objc,java --with-gmp=/sw --with-included-gettext --host=i386-apple-darwin8 --with-as=/sw/lib/odcctools/bin/as --with-ld=/sw/lib/odcctools/bin/ld --with-nm=/sw/lib/odcctools/bin/nm --mandir=/sw/lib/gcc4/share/man --infodir=/sw/lib/gcc4/share/info --disable-multilib Thread model: posix gcc version 4.2.0 20060610 (experimental) Code Attached Regards Gerry Skinner PROGRAM countour_fun ! ! write a qdp file to draw contour line of the likelihood and chisqd functions ! for the few photon coded mask case ! IMPLICIT NONE ! INTEGER, PARAMETER:: ncntr = 4 REAL :: cntr_levels(ncntr)=(/16.0, 25.0, 36.0, 49.0/) INTEGER, PARAMETER:: nf=2 REAL :: f_values(2) = (/0.4,0.6/) REAL :: c1, c0, f REAL :: c1_min=1.0, c1_max=100.0 REAL :: c0_min=1.0, c0_max=100.0, c0step = 1.0 REAL :: fmin, fmax INTEGER :: n, fun, k ! REAL, EXTERNAL:: findval, funget ! !--- ! OPEN ( 1, FILE='contour_fun.qdp', STATUS='unknown') WRITE (1,'(A)') ' skip on' f=f_values(1) c1=c1_min DO WHILE (c1 c1_max) write (2,*) c1 , funget ( 1, c1, c0_min, f ) c1 = c1 + 1.0 end DO DO n = 1,2 DO fun = 1,nf f = f_values(fun) DO k = 1, ncntr c0 = c0_min DO WHILE (c0 c0_max ) ! seek c1 which gives the required level of function f with current c0 c1 = findval( fun, c0, f, c1_min, c1_max, cntr_levels(k)) IF (c1 0.0) THEN WRITE (1,'(2F10.4)') c1, c0 END IF c0 = c0 + c0step END DO WRITE (1,'(A)') ' no no no' END DO END DO! next function f = fmax END DO ! next f value END PROGRAM countour_fun REAL FUNCTION findval( fun, c0, f, c1_min, c1_max, contour) ! ! finds point on c1 axis at which function number fun ! has value contour when other parameter are c0, f IMPLICIT NONE ! INTEGER, INTENT(in) :: fun REAL, INTENT(in) :: c0 REAL, INTENT(in) :: f REAL, INTENT(in) :: c1_min, c1_max REAL, INTENT(in) :: contour ! INTEGER, PARAMETER :: maxloop=20 REAL, PARAMETER:: tol = 1.0E-3 ! INTEGER :: n REAL :: c1a, c1b, c REAL :: v_1, v_2, v ! REAL, EXTERNAL:: funget ! c1a = c1_min c1b = c1_max DO n = 1, maxloop v_1 = funget ( fun, c1a, c0, f ) v_2 = funget ( fun, c1b, c0, f ) IF ( ABS (v_2 - v_1) tol ) THEN findval = (c1a+c1b)/2.0 RETURN END IF IF (( v_1 contour).OR. (v_2 contour) ) THEN !write (*,'(i6,9F12.4)') n, contour, c1a, c, c1b, v_1, v, v_2 !WRITE (*,*) ' outside range', fun, c0, f STOP funget = -99.9 RETURN END IF IF ( v_1 v_2 ) THEN write (*,'(i6,9F12.4)') n, contour, c1a, c, c1b, v_1, v, v_2 WRITE (*,*) ' reverse slope', fun, c0, f STOP END IF c = ( c1a + c1b ) /2.0 v = funget ( fun, c, c0, f ) write (*,'(i6,9F12.4)') n, contour, c1a, c, c1b, v_1, v, v_2 IF ( v = contour ) THEN ! in first half c1b = c ELSE c1a = c END IF END DO END FUNCTION findval REAL FUNCTION funget( fun, c1, c0, f ) ! ! returns function number fun ! IMPLICIT NONE ! INTEGER, INTENT(in) :: fun REAL, INTENT(in) :: c1, c0 REAL, INTENT(in) :: f ! REAL, EXTERNAL:: cash, chi2 ! !--- ! IF (fun == 1 ) THEN funget = cash( c1, c0, f ) ELSE IF (fun == 2 ) THEN funget = chi2( c1, c0, f ) ELSE WRITE (*,*) ' Bad fun' STOP END IF END FUNCTION funget REAL FUNCTION cash( c1, c0, f ) ! ! returns cash function ! IMPLICIT NONE ! REAL, INTENT(in) :: c1, c0 REAL, INTENT(in) :: f ! REAL :: b, s ! !--- ! b = c0 /(1.0-f) s = (c1/f) - b IF (s 0.0 ) THEN cash = 0.0 ELSE cash = (2*(c1*log(c1/f)+c0*log(c0/(1.0-f))-(c1+c0)*log(c1+c0))) END IF END FUNCTION cash REAL FUNCTION chi2( c1, c0, f ) ! ! returns chisqd function ! IMPLICIT NONE ! REAL, INTENT(in) :: c1, c0 REAL, INTENT(in) :: f ! REAL :: e0, e1, b, s !--- ! b = c1 /(1.0-f)
[Bug libstdc++/28277] __builtin_alloca with no limit in libstdc++
--- Comment #17 from paolo at gcc dot gnu dot org 2007-04-13 00:06 --- Subject: Bug 28277 Author: paolo Date: Fri Apr 13 00:06:37 2007 New Revision: 123770 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123770 Log: 2007-04-12 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/28277 (partial: vstring bits) * include/bits/ostream_insert.h: New. * include/Makefile.am: Add. * include/ext/vstring.h (operator(basic_ostream, const __versa_string): Forward to __ostream_insert. * include/bits/basic_string.h (operator(basic_ostream, const string)): Likewise. * include/std/std_ostream.h (operator(basic_ostream, _CharT), operator(basic_ostreamchar,, char), operator(basic_ostream, const _CharT*), operator(basic_ostreamchar,, const char*)): Likewise. * include/ext/vstring.tcc (operator(basic_ostream, const __versa_string)): Remove. (class basic_ostream): Remove friend declarations. (basic_ostream::_M_write(char_type, streamsize), _M_insert(const char_type*, streamsize)): Remove. * include/bits/ostream.tcc (_M_insert(const char_type*, streamsize)): Remove definition. (operator(basic_ostream, const char*)): Use __ostream_insert. * include/ext/vstring_util.h: Include bits/ostream_insert.h. * include/std/std_string.h: Likewise. * config/abi/pre/gnu.ver: Adjust. * src/ostream-inst.cc: Add __ostream_insert instantiations. * include/Makefile.in: Rebuild. * testsuite/ext/vstring/inserters_extractors/char/28277.cc: New. * testsuite/ext/vstring/inserters_extractors/wchar_t/28277.cc: New. Added: branches/gcc-4_2-branch/libstdc++-v3/include/bits/ostream_insert.h branches/gcc-4_2-branch/libstdc++-v3/testsuite/ext/vstring/inserters_extractors/ branches/gcc-4_2-branch/libstdc++-v3/testsuite/ext/vstring/inserters_extractors/char/ branches/gcc-4_2-branch/libstdc++-v3/testsuite/ext/vstring/inserters_extractors/char/28277.cc branches/gcc-4_2-branch/libstdc++-v3/testsuite/ext/vstring/inserters_extractors/wchar_t/ branches/gcc-4_2-branch/libstdc++-v3/testsuite/ext/vstring/inserters_extractors/wchar_t/28277.cc Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/config/abi/pre/gnu.ver branches/gcc-4_2-branch/libstdc++-v3/include/Makefile.am branches/gcc-4_2-branch/libstdc++-v3/include/Makefile.in branches/gcc-4_2-branch/libstdc++-v3/include/bits/basic_string.h branches/gcc-4_2-branch/libstdc++-v3/include/bits/ostream.tcc branches/gcc-4_2-branch/libstdc++-v3/include/ext/vstring.h branches/gcc-4_2-branch/libstdc++-v3/include/ext/vstring.tcc branches/gcc-4_2-branch/libstdc++-v3/include/ext/vstring_util.h branches/gcc-4_2-branch/libstdc++-v3/include/std/std_ostream.h branches/gcc-4_2-branch/libstdc++-v3/include/std/std_string.h branches/gcc-4_2-branch/libstdc++-v3/src/ostream-inst.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28277
[Bug c++/2708] ambiguity check fails for namespace vs class scope
--- Comment #7 from pedro dot lamarao at mndfck dot org 2007-04-13 01:44 --- Created an attachment (id=13360) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13360action=view) First attempt at fixing the bug. This patch gives a diagnostic compiling the test case. I just copied something for the error call; I'm not familiar with the diagnostic stuff. Is this the right approach? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2708
[Bug fortran/31559] New: Assigning to an EXTERNAL leads to ICE
subroutine a(fun) implicit none integer, intent(in) :: fun real, external :: funget real v v = funget(fun) funget = -99.9 end subroutine a laptop:kargl[221] gfc4x -c -O g.f90 g.f90: In function 'a': g.f90:6: internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:444 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Clearly, the assignment to funget is not legal. -- Summary: Assigning to an EXTERNAL leads to ICE Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31559
[Bug c++/2708] ambiguity check fails for namespace vs class scope
--- Comment #8 from fang at csl dot cornell dot edu 2007-04-13 02:40 --- Note: PR 30734 is a dupe of this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2708
[Bug tree-optimization/29585] [4.2 Regression] tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:558
--- Comment #17 from mrs at apple dot com 2007-04-13 03:09 --- The followup problem has now been fixed in 4.2. -- mrs at apple dot com changed: What|Removed |Added CC|mrs at apple dot com| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29585
[Bug fortran/31550] [regression] f951: segfault in fold-const.c:1963
--- Comment #4 from pault at gcc dot gnu dot org 2007-04-13 05:11 --- (In reply to comment #3) Is this a problem with the backend? Dream on, Mr Thomas! It's my own patch: 2007-03-18 Paul Thomas [EMAIL PROTECTED] PR fortran/30531 PR fortran/31086 * symbo.c : Add gfc_derived_types. (gfc_free_dt_list): Free derived type list gfc_derived_types. (gfc_free_namespace): Remove call to gfc_free_dt_list. (gfc_symbol_done_2): Call gfc_free_dt_list. * gfortran.h : Declare gfc_derived_types to be external. Remove derived types field from gfc_namespace. * resolve.c (resolve_fl_derived): Refer to gfc_derived types rather than namespace derived_types. (resolve_fntype): Remove special treatment for module derived type functions. * trans-types.c (gfc_get_derived_type): Remove search for like derived types. Finish by copying back end declaration to like derived types in the derived type list gfc_derived_types. My bad feeling was warranted. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31550
[Bug fortran/31551] ice in fold_convert, at fold-const.c:2330
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-13 05:13 --- (In reply to comment #1) Adding FX to CC as requested on the mailing list. Daniel, Does this also disappear, like 31550, with versions earlier than 20070318? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31551
[Bug libfortran/31052] [4.2 only] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #44 from hjl at lucon dot org 2007-04-13 05:28 --- sixtrack in SPEC CPU 2K started to fail on Mar. 19: http://people.redhat.com/dnovillo/spec2000.em64t/gcc/log/20070319/CFP2000.002.html and it still fails today. Is it caused by this bug fix? -- hjl at lucon dot org changed: What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug libfortran/31052] [4.2 only] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #45 from pinskia at gcc dot gnu dot org 2007-04-13 05:32 --- (In reply to comment #44) sixtrack in SPEC CPU 2K started to fail on Mar. 19: And then start passing and then again started to fail again on/around April 1st. HJL when will you please get your dates correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
