[Bug libgomp/29494] [4.2 Regression] libgomp build fails with missing pthread_mutexattr_settype
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC|ebotcazou at gcc dot gnu dot| |org | AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-18 05:18:32 |2006-10-21 08:08:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29494
[Bug target/29512] compile time hog / deadloop.
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-10-21 10:05 --- Subject: Bug 29512 Author: rguenth Date: Sat Oct 21 10:05:21 2006 New Revision: 117927 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117927 Log: 2006-10-21 Richard Guenther <[EMAIL PROTECTED]> PR target/29512 * config/i386/i386.c (classify_argument): Remove redundant walking of the BINFOs. (contains_128bit_aligned_vector_p): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
[Bug target/29512] compile time hog / deadloop.
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-10-21 10:09 --- Fixed for 4.3. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #18 from rguenth at gcc dot gnu dot org 2006-10-21 10:13 --- Subject: Bug 28796 Author: rguenth Date: Sat Oct 21 10:13:13 2006 New Revision: 117928 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117928 Log: 2006-10-21 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/28796 * simplify-rtx.c (simplify_const_relational_operation): Do not constant-fold ORDERED and UNORDERED for flag_unsafe_math_optimizations but only we do not need to honor NaNs for the given mode. Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
[Bug target/19116] -funsafe-math-optimizations make nan compares equal to one another (-finite-math-only should be doing that)
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-10-21 10:41 --- Subject: Bug 19116 Author: rguenth Date: Sat Oct 21 10:40:57 2006 New Revision: 117930 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117930 Log: 2006-10-21 Richard Guenther <[EMAIL PROTECTED]> PR target/19116 * config/i386/i386.c (override_options): Do not set MASK_IEEE_FP if flag_unsafe_math_optimizations is specified. We have flag_finite_math_only for that. * config/i386/i386.md (sqrtxf2): Do not require TARGET_IEEE_FP or flag_unsafe_math_optimizations. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19116
[Bug target/19116] -funsafe-math-optimizations make nan compares equal to one another (-finite-math-only should be doing that)
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-10-21 10:42 --- 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=19116
[Bug other/29534] New: ICE in "gcc -O -ftrapv" with decreasing array index
bash$ cat bug.c
int foo(int arr[]) {
int i = 2;
while (arr[--i]) ;
return i;
}
bash$ gcc -O -ftrapv -c bug.c
gcc: Internal error: Segmentation fault (program cc1)
bash$ g++ -O -ftrapv -c bug.c
g++: Internal error: Segmentation fault (program cc1plus)
Compilation succeeds if -O is removed. OTOH, it still crashes
with -O -fno-:
bash$ gcc -O -fno-defer-pop -fno-delayed-branch \
-fno-guess-branch-probability -fno-cprop-registers -fno-loop-optimize \
-fno-if-conversion -fno-if-conversion2 -fno-tree-ccp -fno-tree-dce \
-fno-tree-dominator-opts -fno-tree-dse -fno-tree-ter -fno-tree-lrs \
-fno-tree-sra -fno-tree-copyrename -fno-tree-fre -fno-tree-ch \
-fno-merge-constants -fno-omit-frame-pointer \
-ftrapv -c bug.c
gcc: Internal error: Segmentation fault (program cc1)
--
Summary: ICE in "gcc -O -ftrapv" with decreasing array index
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
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=29534
[Bug c++/29535] New: [4.1/4.2 Regression] ICE in instantiate_class_template, at cp/pt.c:5728
For the following testcase
typedef long unsigned int size_t;
typedef int int16_t __attribute__ ((__mode__ (__HI__)));
typedef int int32_t __attribute__ ((__mode__ (__SI__)));
typedef unsigned char uint8_t;
typedef unsigned short int uint16_t;
template class Ident { };
template class Less { };
template class Pixel { };
typedef Pixel PixelY;
template class Region2D {
public:
class Extent { };
};
template class Allocator {
class Chunk { };
};
template class SkipList {
struct Node { };
enum { HEADERCHUNK = 10 };
public:
typedef Allocator Allocator;
class Iterator;
class ConstIterator { };
struct InsertResult { };
};
template > class Set {
typedef SkipList,PRED> Imp;
Imp m_oImp;
public:
typedef typename Imp::Allocator Allocator;
Set (const PRED &a_rPred = PRED(),
Allocator &a_rAlloc = Imp::sm_oNodeAllocator)
: m_oImp (a_rPred, a_rAlloc) { }
typedef typename Imp::Iterator Iterator;
typedef typename Imp::ConstIterator ConstIterator;
Iterator Begin (void) {}
};
template class SetRegion2D {
typedef Region2D BaseClass;
typedef typename BaseClass::Extent Extent;
typedef Set Extents;
public:
typedef typename Extents::ConstIterator ConstIterator;
ConstIterator Begin (void) const { }
class FloodFillControl;
};
template
class SetRegion2D::FloodFillControl {
bool ShouldUseExtent (Extent &a_rExtent) { }
};
template
class MotionSearcher {
typedef SetRegion2D Region_t;
class MatchThrottleFloodFillControl {
typedef typename Region_t::FloodFillControl BaseClass;
MatchThrottleFloodFillControl (typename BaseClass::Allocator
&a_rAllocator);
};
MatchThrottleFloodFillControl m_oMatchThrottleFloodFillControl;
};
class MotionSearcherY : public MotionSearcher {};
--
Summary: [4.1/4.2 Regression] ICE in instantiate_class_template,
at cp/pt.c:5728
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29535
[Bug libgcj/29205] lib/pkgconfig/libgcj.pc needs to become version dependent
--- Comment #6 from gerald at pfeifer dot com 2006-10-21 11:28 --- Thanks, Tom! I updated some packages I maintain and verified that this indeed nicely fixes the problem. As for GCC 4.1, as you say, I don't think it's strictly needed, though it could be useful for some (using GCC 4.0 and GCC 4.1 in parallel for example). Your call, I'd say. In any case, thanks a lot for tackling this problem! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29205
[Bug other/29534] [4.1 Regression] ICE in "gcc -O -ftrapv" with decreasing array index
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-10-21 12:12 --- Confirmed. Works with 4.2. We endlessly fold #5 0x08206aa1 in fold_unary (code=NEGATE_EXPR, type=0xb7c5c284, op0=0xb7cd3258) at /home/richard/src/gcc-4_1-branch/gcc/fold-const.c:6876 #6 0x08212e3e in fold_build1_stat (code=NEGATE_EXPR, type=0xb7c5c284, op0=0xb7cd3258) at /home/richard/src/gcc-4_1-branch/gcc/fold-const.c:10475 #7 0x081f8a05 in negate_expr (t=0xb7cd3258) at /home/richard/src/gcc-4_1-branch/gcc/fold-const.c:1167 #8 0x08206aa1 in fold_unary (code=NEGATE_EXPR, type=0xb7c5c284, op0=0xb7cd3258) at /home/richard/src/gcc-4_1-branch/gcc/fold-const.c:6876 #9 0x08212e3e in fold_build1_stat (code=NEGATE_EXPR, type=0xb7c5c284, op0=0xb7cd3258) at /home/richard/src/gcc-4_1-branch/gcc/fold-const.c:10475 #10 0x081f8a05 in negate_expr (t=0xb7cd3258) ... #28 0x081f8a05 in negate_expr (t=0xb7cd3258) at /home/richard/src/gcc-4_1-branch/gcc/fold-const.c:1167 1167 tree temp = fold_convert (ntype, TREE_OPERAND (t, 0)); (gdb) call debug_generic_expr (t) -07fff which has overflowed. #29 0x08206aa1 in fold_unary (code=NEGATE_EXPR, type=0xb7c5c284, op0=0xb7cd3258) at /home/richard/src/gcc-4_1-branch/gcc/fold-const.c:6876 #30 0x08212e3e in fold_build1_stat (code=NEGATE_EXPR, type=0xb7c5c284, op0=0xb7cd3258) at /home/richard/src/gcc-4_1-branch/gcc/fold-const.c:10475 #31 0x081f8a05 in negate_expr (t=0xb7cd3258) at /home/richard/src/gcc-4_1-branch/gcc/fold-const.c:1167 #32 0x0820cb87 in fold_binary (code=CEIL_DIV_EXPR, type=0xb7c5c284, op0=0xb7cd3258, op1=0xb7c4da50) at /home/richard/src/gcc-4_1-branch/gcc/fold-const.c:8420 #33 0x08212e8e in fold_build2_stat (code=CEIL_DIV_EXPR, type=0xb7c5c284, op0=0xb7cd3258, op1=0xb7c4da50) at /home/richard/src/gcc-4_1-branch/gcc/fold-const.c:10521 #34 0x080fe243 in infer_loop_bounds_from_undefined (loop=0x86a5310) #32 0x0820cb87 in fold_binary (code=CEIL_DIV_EXPR, type=0xb7c5c284, op0=0xb7cd3258, op1=0xb7c4da50) at /home/richard/src/gcc-4_1-branch/gcc/fold-const.c:8420 8420case ROUND_DIV_EXPR: (gdb) call debug_generic_expr (op0) -07fff (gdb) call debug_generic_expr (op1) -1 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, rakdver at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.1.2 Known to work||4.0.3 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-10-21 12:12:55 date|| Summary|ICE in "gcc -O -ftrapv" with|[4.1 Regression] ICE in "gcc |decreasing array index |-O -ftrapv" with decreasing ||array index http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29534
[Bug middle-end/26898] Fold does not fold signed + CST1 CMP signed + CST2
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-10-21 13:21 --- Subject: Bug 26898 Author: rguenth Date: Sat Oct 21 13:21:06 2006 New Revision: 117931 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117931 Log: 2006-10-21 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/26898 * fold-const.c (fold_comparison): Fold signed comparisons of the form X +- C1 CMP Y +- C2. * gcc.dg/torture/pr26898-1.c: New testcase. * gcc.dg/torture/pr26898-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr26898-1.c trunk/gcc/testsuite/gcc.dg/torture/pr26898-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26898
[Bug middle-end/26898] Fold does not fold signed + CST1 CMP signed + CST2
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-10-21 13:21 --- 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=26898
[Bug tree-optimization/3511] Inlined strlen() could be smarter
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-21 13:23 --- Subject: Bug 3511 Author: rguenth Date: Sat Oct 21 13:23:41 2006 New Revision: 117932 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117932 Log: 2006-10-21 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/3511 * tree-ssa-pre.c (phi_translate): Fold CALL_EXPRs that got new invariant arguments during PHI translation. * gcc.dg/tree-ssa/ssa-pre-15.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-15.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3511
[Bug tree-optimization/3511] Inlined strlen() could be smarter
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-10-21 13:23 --- 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=3511
[Bug java/29536] New: ICE building libjava
./../.././gcc/gcjh -d . -classpath '' -bootclasspath classpath/lib $name gnu/CORBA/DynAn/gnuDynAny.java: In class 'gnu.CORBA.DynAn.gnuDynAny': gnu/CORBA/DynAn/gnuDynAny.java: In method 'gnu.CORBA.DynAn.gnuDynAny.get_any()': gnu/CORBA/DynAn/gnuDynAny.java:0: 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. make[3]: *** [gnu-CORBA.lo] Error 1 and /home/dave/gnu/gcc-4.2/objdir/gcc/gcj -B/home/dave/gnu/gcc-4.2/objdir/hppa-linux /libjava/ -B/home/dave/gnu/gcc-4.2/objdir/gcc/ -fclasspath= -fbootclasspath=/hom e/dave/gnu/gcc-4.2/objdir/hppa-linux/libjava/classpath/lib --encoding=UTF-8 -Wno -deprecated -fbootstrap-classes -g -O2 -fjni -findirect-dispatch -fno-indirect-c lasses -c @gnu-CORBA.list -fPIC -o .libs/gnu-CORBA.o gnu/CORBA/CDR/gnuRuntime$1.java: In class 'gnu.CORBA.CDR.gnuRuntime$1': gnu/CORBA/CDR/gnuRuntime$1.java: In constructor '(gnu.CORBA.CDR.gnuRuntime)': gnu/CORBA/CDR/gnuRuntime$1.java:0: 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. make[3]: *** [gnu-CORBA.lo] Error 1 make[3]: *** Waiting for unfinished jobs gnu/java/awt/dnd/peer/gtk/GtkDragSourceContextPeer.java: In class 'gnu.java.awt. dnd.peer.gtk.GtkDragSourceContextPeer': gnu/java/awt/dnd/peer/gtk/GtkDragSourceContextPeer.java: In method 'gnu.java.awt .dnd.peer.gtk.GtkDragSourceContextPeer.startDrag(java.awt.dnd.DragSourceContext, java.awt.Cursor,java.awt.Image,java.awt.Point)': gnu/java/awt/dnd/peer/gtk/GtkDragSourceContextPeer.java:0: internal compiler err or: Segmentation fault -- Summary: ICE building libjava Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29536
[Bug c++/29535] [4.1/4.2 Regression] ICE in instantiate_class_template, at cp/pt.c:5728
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-10-21 13:50 --- Caused by URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117695 Log: PR c++/28506 * parser.c (function_declarator_p): New function. (cp_parser_init_declarator): Use it. (cp_parser_member_declaration): Likewise. PR c++/28506 * g++.dg/parse/pure1.C: New test. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||28506 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29535
[Bug middle-end/29536] [4.2 Regression] ICE building libjava
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-21 14:19 --- Fixed right before the branch of 4.2 by: 2006-10-20 Daniel Berlin <[EMAIL PROTECTED]> * tree.h (DECL_PTA_ARTIFICIAL): Remove. (tree_decl_with_vis): Remove artificial_pta_var flag. * tree-flow.h (referenced_var_check_and_insert): Expose. (nonlocal_all): New prototype. * tree-ssa-structalias.c (nonlocal_for_type): Remove. (nonlocal_all): Make global. (nonlocal_lookup): Remove. (nonlocal_insert): Ditto. (create_nonlocal_var): Do not call nonlocal_insert. (get_nonlocal_id_for_type): Remove. (find_global_initializers): Mark new vars we find for renaming. (intra_create_variable_infos): Only create one nonlocal. (expand_nonlocal_solutions): Remove. (compute_points_to_sets): Don't call it. (ipa_pta_execute): Ditto. (init_alias_heapvars): Don't create nonlocal_for_type. (delete_alias_heapvars): Don't remove it. * tree-ssa-operands.c (access_can_touch_variable): Don't prune nonlocal_all. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|java|middle-end Resolution||FIXED Summary|ICE building libjava|[4.2 Regression] ICE ||building libjava Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29536
[Bug c++/29535] [4.1/4.2 Regression] ICE in instantiate_class_template, at cp/pt.c:5728
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29535
[Bug c++/29535] [4.1/4.2 Regression] ICE in instantiate_class_template, at cp/pt.c:5728
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-21 14:31 --- The code provided here is not valid code at all. With 4.0.4 and 4.2.0 before the patch I get: t.cc: In instantiation of MotionSearcher::MatchThrottleFloodFillControl: t.cc:58: instantiated from MotionSearcher t.cc:60: instantiated from here t.cc:56: error: no type named Allocator in class SetRegion2D::FloodFillControl -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29535
[Bug c++/29535] [4.1/4.2 Regression] ICE in instantiate_class_template, at cp/pt.c:5728
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-21 14:34 --- Created an attachment (id=12470) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12470&action=view) unreduced testcase from mjpegtools -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29535
[Bug c++/29535] [4.1/4.2 Regression] ICE in instantiate_class_template, at cp/pt.c:5728
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-10-21 14:38 --- Add public: typedef int Allocator; to the SetRegion2D::FloodFillControl definition and it becomes valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29535
[Bug c++/29535] [4.1/4.2 Regression] ICE in instantiate_class_template, at cp/pt.c:5728
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-21 14:58 ---
Reduced testcase:
template struct SetRegion2D
{
struct FloodFillControl
{
struct Allocator{};
};
};
template
struct MotionSearcher {
typedef SetRegion2D Region_t;
MotionSearcher (typename Region_t::FloodFillControl::Allocator
&a_rAllocator);
MotionSearcher();
};
struct MotionSearcherY
: MotionSearcher{};
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-10-21 14:58:08
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29535
[Bug fortran/25707] support for Fortran 2003 USE statements, INTRINSIC and NONINTRINSIC
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-21 17:30 --- It's an enhancement (and actually, it's being worked on). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Severity|normal |enhancement Status|NEW |ASSIGNED Last reconfirmed|2006-01-07 17:58:22 |2006-10-21 17:30:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25707
[Bug fortran/29537] New: ICE in gfc_match_common
$ cat foo.f90
! { dg-compile }
! { dg-options "-W -Wall" }
type a_t
sequence
integer i
end type a_t
block data bd
sequence
common c
type c_t
sequence
integer i
end type c_t
end block data bd
common /a_t/ c
end
$ gfortran-4.1 --version
GNU Fortran 95 (GCC) 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)
$ gfortran-4.1 -S -o foo.s foo.f90
In file foo.f90:9
block data bd
1
Error: Unexpected BLOCK DATA statement at (1)
In file foo.f90:10
sequence
1
Error: Unexpected SEQUENCE statement at (1)
In file foo.f90:11
common c
1
Error: Unexpected COMMON statement at (1)
In file foo.f90:12
type c_t
1
Error: Unexpected derived type declaration statement at (1)
In file foo.f90:13
sequence
1
Error: Unexpected SEQUENCE statement at (1)
In file foo.f90:14
integer i
1
Error: Unexpected data declaration statement at (1)
In file foo.f90:15
end type c_t
1
Error: Expecting END PROGRAM statement at (1)
In file foo.f90:16
end block data bd
1
Error: Expecting END PROGRAM statement at (1)
foo.f90:0: 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.
For Debian GNU/Linux specific bug reporting instructions,
see .
With trunk from 20061018
this gives:
Program received signal SIGSEGV, Segmentation fault.
0x08078b1a in gfc_match_common ()
at ../../../src/gcc-4.2.orig/gcc/fortran/match.c:2299
2299 while (old_blank_common->common_next)
(gdb) bt
#0 0x08078b1a in gfc_match_common ()
at ../../../src/gcc-4.2.orig/gcc/fortran/match.c:2299
#1 0x08083489 in match_word (
str=0x6e656d65 ,
subr=0x8078af7 , old_locus=0xafcfc614)
at ../../../src/gcc-4.2.orig/gcc/fortran/parse.c:65
#2 0x0808402e in decode_statement ()
at ../../../src/gcc-4.2.orig/gcc/fortran/parse.c:193
#3 0x0808439b in next_statement ()
at ../../../src/gcc-4.2.orig/gcc/fortran/parse.c:493
#4 0x0808630a in parse_progunit (st=)
at ../../../src/gcc-4.2.orig/gcc/fortran/parse.c:2910
#5 0x0808675b in gfc_parse_file ()
at ../../../src/gcc-4.2.orig/gcc/fortran/parse.c:3206
#6 0x080a5b29 in gfc_be_parse_file (set_yydebug=0)
at ../../../src/gcc-4.2.orig/gcc/fortran/f95-lang.c:303
#7 0x082f542d in toplev_main (argc=13, argv=0xafcfc7f4)
at ../../../src/gcc-4.2.orig/gcc/toplev.c:1033
#8 0x080cfc26 in main (argc=1630478446, argv=0x202f745f)
at ../../../src/gcc-4.2.orig/gcc/main.c:35
--
Summary: ICE in gfc_match_common
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: minor
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aldot at gcc dot gnu dot org
GCC build triplet: i686-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: i686-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29537
[Bug fortran/25003] [4.1 only] Non-standard-conforming behaviour on pointer association special case
--- Comment #4 from steven at gcc dot gnu dot org 2006-10-21 17:32 --- Since this is not a regression in GCC 4.1, and because it will work in GCC 4.2, I'm closing this as WONTFIX. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25003
[Bug libfortran/21881] Array descriptors limit derived type sizes
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-21 17:39 --- Thomas, isn't the 4.3 branching a good time to work on this? Would you have time for that? -- fxcoudert 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=21881
[Bug fortran/29537] ICE in gfc_match_common
--- Comment #1 from aldot at gcc dot gnu dot org 2006-10-21 17:42 --- Shorter testcase: $ egrep -v "(^\!|^$)" foo2.f90 block data common c end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29537
[Bug fortran/29537] ICE in gfc_match_common
--- Comment #2 from aldot at gcc dot gnu dot org 2006-10-21 18:04 --- (In reply to comment #1) > Shorter testcase: > $ egrep -v "(^\!|^$)" foo2.f90 > block data > common c > end > According to lahey's checker, this code is valid. Still it ICEs -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29537
[Bug c/29538] New: Incorrect interpretation of floating-point unary minus
Testcase:
void f(float);
void g(double x) { f(-x); }
Using -fdump-tree-original shows that GCC understands the above code as
"f(-(float)x)", although it should really be "f((float)(-x))". As a
consequence, the generated code is not efficient (on x86), as GCC will have to
store x to memory as a float before loading it again and changing its sign.
Moreover, the computed value is not the expected one when the rounding mode is
a directed rounding, as the conversion happens before the sign change.
Tested with Debian GCC 3.3.6, 3.4.6, 4.0.4, and 4.1.2. Version 3.3 generates
the correct code, the other ones don't.
--
Summary: Incorrect interpretation of floating-point unary minus
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
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=29538
[Bug fortran/29537] ICE in gfc_match_common
--- Comment #3 from aldot at gcc dot gnu dot org 2006-10-21 18:05 --- (In reply to comment #2) > (In reply to comment #1) > > Shorter testcase: > > $ egrep -v "(^\!|^$)" foo2.f90 > > block data > > common c > > end > > > According to lahey's checker, this code is valid. Still it ICEs Program received signal SIGSEGV, Segmentation fault. 0x080b0982 in gfc_trans_common (ns=0x85e2f20) at ../../../src/gcc-4.2/gcc/fortran/trans-common.c:1059 1059 c->where = ns->proc_name->declared_at; (gdb) bt #0 0x080b0982 in gfc_trans_common (ns=0x85e2f20) at ../../../src/gcc-4.2/gcc/fortran/trans-common.c:1059 #1 0x080b15a4 in gfc_generate_block_data (ns=0x85e2f20) at ../../../src/gcc-4.2/gcc/fortran/trans-decl.c:3316 #2 0x08086b25 in gfc_parse_file () at ../../../src/gcc-4.2/gcc/fortran/parse.c:3237 #3 0x080a5db9 in gfc_be_parse_file (set_yydebug=0) at ../../../src/gcc-4.2/gcc/fortran/f95-lang.c:303 #4 0x082f5d6d in toplev_main (argc=15, argv=0xaffe1ad4) at ../../../src/gcc-4.2/gcc/toplev.c:1033 #5 0x080cffe6 in main (argc=Cannot access memory at address 0x0 ) at ../../../src/gcc-4.2/gcc/main.c:35 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29537
[Bug fortran/29539] New: ICE in variable_decl
According to lahey's web checker, this is legal code:
$ cat foo.f90
! { dg-compile }
! { dg-options "-W -Wall" }
block data
common /c/ d(5)
data d /5*1./
type c_t
sequence
integer i
end type c_t
type (c_t) :: cc ! bugger
end
end
It ICEs with 4.1.2 20060901 (prerelease).
bt with 4.2:
(gdb) run
Starting program: /opt/gcc-4.2/lib/gcc/i686-linux-gnu/4.2.0/f951 foo.f90 -quiet
-dumpbase foo.f90 -mtune=generic -auxbase-strip foo.s -W -Wall -version -o
foo.s -I /opt/gcc-4.2/bin/../lib/gcc/i686-linux-gnu/4.2.0/finclude
GNU F95 version 4.2.0 20061019 (experimental) (i686-linux-gnu)
compiled by GNU C version 4.2.0 20061019 (experimental).
GGC heuristics: --param ggc-min-expand=94 --param ggc-min-heapsize=121333
Program received signal SIGSEGV, Segmentation fault.
0x0805a5e0 in variable_decl (elem=)
at ../../../src/gcc-4.2/gcc/fortran/decl.c:1201
1201 if (current_ts.type == BT_DERIVED
(gdb) bt
#0 0x0805a5e0 in variable_decl (elem=)
at ../../../src/gcc-4.2/gcc/fortran/decl.c:1201
#1 0x0805ae4f in gfc_match_data_decl ()
at ../../../src/gcc-4.2/gcc/fortran/decl.c:2356
#2 0x08083519 in match_word (str=0x0, subr=0x805adc9 ,
old_locus=0xafa27a74) at ../../../src/gcc-4.2/gcc/fortran/parse.c:65
#3 0x08083aa0 in decode_statement ()
at ../../../src/gcc-4.2/gcc/fortran/parse.c:134
#4 0x0808442b in next_statement ()
at ../../../src/gcc-4.2/gcc/fortran/parse.c:493
#5 0x08085e3f in parse_spec (st=ST_DERIVED_DECL)
at ../../../src/gcc-4.2/gcc/fortran/parse.c:1878
#6 0x08086911 in gfc_parse_file ()
at ../../../src/gcc-4.2/gcc/fortran/parse.c:3025
#7 0x080a5db9 in gfc_be_parse_file (set_yydebug=0)
at ../../../src/gcc-4.2/gcc/fortran/f95-lang.c:303
#8 0x082f5d6d in toplev_main (argc=15, argv=0xafa27d14)
at ../../../src/gcc-4.2/gcc/toplev.c:1033
#9 0x080cffe6 in main (argc=Cannot access memory at address 0x0
) at ../../../src/gcc-4.2/gcc/main.c:35
--
Summary: ICE in variable_decl
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aldot at gcc dot gnu dot org
GCC build triplet: i686-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: i686-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29539
[Bug target/29538] Incorrect interpretation of floating-point unary minus
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-10-21 18:19 --- Unary negation does not affect rounding, so I fail to see how it shall matter what type the negation is done on. It is true that for x87 math the -(float)x sequence is slower: g: pushl %ebp movl%esp, %ebp subl$4, %esp fldl8(%ebp) fstps -4(%ebp) flds-4(%ebp) fchs fstps 8(%ebp) leave jmp f so, confirmed as missed-optimization. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|c |target Ever Confirmed|0 |1 GCC target triplet||i?86-*-* Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2006-10-21 18:19:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29538
[Bug other/29540] New: Obverse of PR 28177, regression patches for 4.2.0 ending up in trunk
With Mark Mitchel branching 4.2.0 of from trunk on 2006-10-20 it appears that some regression patches, dated 2006-10-21 andreally destined for 4.2.0, ended up in trunk only (e.g. six from Richard Guenther). Perhaps administratively they could be back-ported from trunk to the 4.2.0 branch as they do not seem to cause any harm in trunk. This appears to by just a minor administrative matter. -- Summary: Obverse of PR 28177, regression patches for 4.2.0 ending up in trunk Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: malitzke at metronets dot com GCC build triplet: *-*-* GCC host triplet: *-*-* GCC target triplet: *-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29540
[Bug other/29540] Obverse of PR 28177, regression patches for 4.2.0 ending up in trunk
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-21 18:41 --- Those were not regressions at all. They were patches which had been approved for 4.3 but Richard forgot to mark the bugs as blocking the 4.3 pending patches bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29540
[Bug middle-end/29519] [4.2 Regression] Bad code on MIPS with -fnon-call-exceptions
--- Comment #5 from rsandifo at gcc dot gnu dot org 2006-10-21 18:44 --- The wrapping check was added by: http://gcc.gnu.org/ml/gcc-patches/2002-10/msg00360.html I think this check is wrong for exactly the reason seen here; without type information, and without context, there's no guarantee that the PLUS itself is a pointer, or indeed that the constant was originally positive. We could only do something like this if we know the address is being dereferenced -- but in that case, we generally care about whether the value might trap, not whether it's zero (and rtlanal.c rightly says that (plus reg (const_int ...)) can trap). For example, something like: (uintptr_t) foo == 0x9000 could legitimately be implemented as: (eq (plus foo (const_int 0x7000)) (const_int 0)) And AIUI, gcc allows things like: (uintptr_t) foo - 0x9000 and allows the result to be zero (assuming the result is not dereferenced). All uses of nonzero_address_p appear to using it for general rtx simplification, i.e. in cases where the value is not known to be a pointer. So I think this check should just be removed. Hopefully the check is less important now than it was when it was originally committed. This sort of optimisation can be done at the tree level instead. Richard -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added CC||rsandifo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29519
[Bug fortran/29539] ICE in variable_decl
-- aldot at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29539
[Bug fortran/29537] ICE in gfc_match_common
-- aldot at gcc dot gnu dot org changed: What|Removed |Added Keywords|ice-on-invalid-code | Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29537
[Bug fortran/29537] ICE in gfc_match_common
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |normal Target Milestone|4.2.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29537
[Bug fortran/29393] Vector subscript rejected
-- eedelman at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |eedelman at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-08 21:31:18 |2006-10-21 19:26:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29393
[Bug rtl-optimization/19398] secondary reloads don't consider "m" alternatives
--- Comment #11 from uros at gcc dot gnu dot org 2006-10-21 19:27 --- Subject: Bug 19398 Author: uros Date: Sat Oct 21 19:27:02 2006 New Revision: 117935 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117935 Log: PR target/19398 * config/i386/i386.md (fix_trunc?f?i_sse): Add peephole2 patterns to use memory input operand in x87->mem->XMM reload sequences. Skip transformation for TARGET_K8. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19398
[Bug middle-end/28252] pow(x,1/3.0) should be converted to cbrt(x)
--- Comment #4 from uros at gcc dot gnu dot org 2006-10-21 20:05 --- Subject: Bug 28252 Author: uros Date: Sat Oct 21 20:05:35 2006 New Revision: 117937 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117937 Log: 2006-10-21 Uros Bizjak <[EMAIL PROTECTED]> PR middle-end/28252 * builtins.c (fold_builtin): Fold pow(x,1.0/3.0) as cbrt(x) if flag_unsafe_math_optimizations is set. testsuite/ChangeLog: PR middle-end/28252 * gcc.dg/builtins-8.c: Also check pow(x,1.0/3.0) to cbrt(x) transformation. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/builtins-8.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28252
[Bug target/29538] Incorrect interpretation of floating-point unary minus
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-21 20:17 --- Though minus cannot change the rounding but the rounding mode can be different for rounding from double to float in that we could have a negative number with round towards zero which causes us to get different answers. Now the default rounding we are fine. *** This bug has been marked as a duplicate of 21032 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29538
[Bug middle-end/21032] GCC 3.4.3 wrongly reorders floating-point operations
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-10-21 20:17 --- *** Bug 29538 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||guillaume dot melquiond at ||ens-lyon dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
[Bug middle-end/21032] With -frounding-math, incorrectly reorders unary minus
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-10-21 20:21 --- Confirmed, we should not be reordering unary minus with -frounding-math but we are, even on the mainline. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|i686-pc-linux-gnu | Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2006-10-21 20:21:17 date|| Summary|GCC 3.4.3 wrongly reorders |With -frounding-math, |floating-point operations |incorrectly reorders unary ||minus http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
[Bug c++/22363] Problems with friend function injection and destructor
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-21 20:23 --- (In reply to comment #3) > For the testcase in comment #2, on the mainline, we get a different error > message: That is the correct error so closing as fixed for 4.2.0 as friends don't inject at all. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22363
[Bug target/20808] Unrecognizable insn
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-21 20:24 --- Fixed for 3.4.3 as reported in comment #4. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20808
[Bug middle-end/21032] With -frounding-math, incorrectly reorders unary minus
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-10-21 20:27 --- It's convert.c:convert_to_real which does this. Should be easy to fix. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-21 20:21:17 |2006-10-21 20:27:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
[Bug c++/21413] diagnostic for instantiation should also reference the function which it is where the instantiation happens
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-21 20:36 --- My reduced testcase, you get the following error: t.cc: In instantiation of a: t.cc:11: instantiated from here t.cc:3: error: float is not a class, struct, or union type I don't see how this is the incorrect diagnostic for this case. Maybe it should reference line 7 but that is asking for an improvement. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2006-10-21 20:36:45 date|| Summary|bogus diagnostic from |diagnostic for instantiation |unidentified template |should also reference the ||function which it is where ||the instantiation happens http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21413
[Bug c++/21413] diagnostic for instantiation should also reference the function which it is where the instantiation happens
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-21 20:39 --- Comeau online has the same issue: "ComeauTest.c", line 3: error: name followed by "::" must be a class or namespace name... Wild guess: Did you #include the right header? typedef typename TT::value_type value_type; ^ detected during instantiation of class "a [with TT=float]" at line 11 See how it refers to a and line 11 in the same way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21413
[Bug target/24308] endless looping and memory allocation in i386.c:classify_argument
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-21 20:58 --- *** This bug has been marked as a duplicate of 29512 *** -- 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=24308
[Bug target/29512] compile time hog / deadloop.
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-10-21 20:58 --- *** Bug 24308 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
[Bug target/29512] compile time hog / deadloop.
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-10-21 21:03 --- Fixed so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
[Bug c++/21413] diagnostic for instantiation should also reference the function which it is where the instantiation happens
--- Comment #7 from igodard at pacbell dot net 2006-10-21 21:16 --- Please forgive my naive understanding of the standard, but it was my impression that the return type of a function never participated in overload resolution. That is, for any given set of overloads and a call, the return types of the overloads can be changed arbitrarily and in all cases the compiler should produce the same identification (if successful) or same diagnostic (if not). We have here a case where this rule (if rule it is) is violated. If the overloads are: template void foo(int); template typename a::value_type foo(const C&); then you get a diagnostic, but if the overloads are: template void foo(int); template void foo(const C&); then you don't. I leave to wiser heads whether a diagnostic should issue, but whether it should or should not then it should (or should not) in both cases. Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21413
[Bug target/25864] Enable IBM long double format in 32-bit PowerPC Linux
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-10-21 21:19 --- I think we can declare this as fixed and open a new bug about 128bit long double and soft fp. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25864
[Bug target/29541] New: Enable IBM long double format in PowerPC Linux soft float
This is just a reminder that soft float and IBM long double support don't get along on powerpc. This is a split off from PR 25864 really. -- Summary: Enable IBM long double format in PowerPC Linux soft float Product: gcc Version: 4.0.4 Status: UNCONFIRMED Keywords: ABI Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org GCC target triplet: powerpc*-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29541
[Bug target/25864] Enable IBM long double format in 32-bit PowerPC Linux
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-10-21 21:24 --- (In reply to comment #18) > I think we can declare this as fixed and open a new bug about 128bit long > double and soft fp. And the new bug is PR 29541. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25864
[Bug target/29541] Enable IBM long double format in PowerPC Linux soft float
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-21 21:25 --- Confirmed. There was talking about this on the mailing list but I cannot find it right now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-21 21:25:57 date|| Version|4.0.4 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29541
[Bug middle-end/28252] pow(x,1/3.0) should be converted to cbrt(x)
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-21 21:26 --- Fixed. -- pinskia 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=28252
[Bug c++/29295] ++ operator with bool typedef increments or operator -- with bool typedef
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-21 21:34 --- Mine, this bug is easy to fix. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29295
[Bug libgcj/29205] lib/pkgconfig/libgcj.pc needs to become version dependent
--- Comment #7 from tromey at gcc dot gnu dot org 2006-10-21 21:49 --- I'm going to close this as fixed. Thanks Gerald. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29205
[Bug fortran/29537] ICE in gfc_match_common
--- Comment #4 from kargl at gcc dot gnu dot org 2006-10-21 22:04 --- First, I agree there is a bug because gfortran should not have an ICE. However, I believe the code is invalid. The Fortran 95 standard specifically mentions "named common blocks" in the description of "block data". "common c" is a blank common block. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29537
[Bug c/29465] warning for overlapping memcpy()
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-21 22:07 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-21 22:07:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29465
[Bug c++/29542] New: Error compiling c++ program with overloaded operator<< and postfix increment when using them (cout << obj++)
--
#include
using namespace std;
class test
{
friend ostream &operator <<(ostream &, test &);
friend test operator ++(test &, int);
public:
test(int = 0);
private:
int t;
};
test::test(int g)
{
t = g;
}
test operator ++(test &tt, int)
{
test h = tt;
(tt.t)++;
return h;
}
ostream &operator <<(ostream &out, test &tt)
{
cout << tt.t <&
std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_ostream<_CharT,
_Traits>&(*)(std::basic_ostream<_CharT, _Traits>&)) [with _CharT = char,
_Traits = std::char_traits]
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/include/g++-v3/bits/ostream.tcc:74:
note: std::basic_ostream<_CharT, _Traits>&
std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_ios<_CharT,
_Traits>&(*)(std::basic_ios<_CharT, _Traits>&)) [with _CharT = char, _Traits =
std::char_traits]
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/include/g++-v3/bits/ostream.tcc:86:
note: std::basic_ostream<_CharT, _Traits>&
std::basic_ostream<_CharT,
_Traits>::operator<<(std::ios_base&(*)(std::ios_base&)) [with _CharT = char,
_Traits = std::char_traits]
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/include/g++-v3/bits/ostream.tcc:121:
note: std::basic_ostream<_CharT, _Traits>&
std::basic_ostream<_CharT, _Traits>::operator<<(long int) [with _CharT = char,
_Traits = std::char_traits]
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/include/g++-v3/bits/ostream.tcc:155:
note: std::basic_ostream<_CharT, _Traits>&
std::basic_ostream<_CharT, _Traits>::operator<<(long unsigned int) [with _CharT
= char, _Traits = std::char_traits]
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/include/g++-v3/bits/ostream.tcc:98:
note: std::basic_ostream<_CharT, _Traits>&
std::basic_ostream<_CharT, _Traits>::operator<<(bool) [with _CharT = char,
_Traits = std::char_traits]
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/include/g++-v3/ostream:178: note:
std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT,
_Traits>::operator<<(short int) [with _CharT = char, _Traits =
std::char_traits]
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/include/g++-v3/ostream:189: note:
std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT,
_Traits>::operator<<(short unsigned int) [with _CharT = char, _Traits =
std::char_traits]
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/include/g++-v3/ostream:193: note:
std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT,
_Traits>::operator<<(int) [with _CharT = char, _Traits =
std::char_traits]
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/include/g++-v3/ostream:204: note:
std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT,
_Traits>::operator<<(unsigned int) [with _CharT = char, _Traits =
std::char_traits]
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/include/g++-v3/bits/ostream.tcc:179:
note: std::basic_ostream<_CharT, _Traits>&
std::basic_ostream<_CharT, _Traits>::operator<<(long long int) [with _CharT =
char, _Traits = std::char_traits]
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/include/g++-v3/bits/ostream.tcc:214:
note: std::basic_ostream<_CharT, _Traits>&
std::basic_ostream<_CharT, _Traits>::operator<<(long long unsigned int) [with
_CharT = char, _Traits = std::char_traits]
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/include/g++-v3/bits/ostream.tcc:238:
note: std::basic_ostream<_CharT, _Traits>&
std::basic_ostream<_CharT, _Traits>::operator<<(double) [with _CharT = char,
_Traits = std::char_traits]
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/include/g++-v3/ostream:219: note:
std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT,
_Traits>::operator<<(float) [with _CharT = char, _Traits =
std::char_traits]
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/include/g++-v3/bits/ostream.tcc:261:
note: std::basic_ostream<_CharT, _Traits>&
std::basic_ostream<_CharT, _Traits>::operator<<(long double) [with _CharT =
char, _Traits = std::char_traits]
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/include/g++-v3/bits/ostream.tcc:284:
note: std::basic_ostream<_CharT, _Traits>&
std::basic_ostream<_CharT, _Traits>::operator<<(const void*) [with _CharT =
char, _Traits = std::char_traits]
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/include/g++-v3/bits/ostream.tcc:307:
note: std::basic_ostream<_CharT, _Traits>&
std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_streambuf<_CharT,
_Traits>*) [with _CharT = char, _Traits = std::char_traits]
test.cpp:28: note: std::ostream& operator<<(std::ostream&,
test&)
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/include/g++-v3/ostream:504: note:
std::basic_ostream&
std::operator<<(std::basic_ostream&, const unsigned char*) [with
_Traits = std::char_trai
[Bug c++/29542] Error compiling c++ program with overloaded operator<< and postfix increment when using them (cout << obj++)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-21 23:04 --- Your code is incorrect, you cannot bind a rvalue to a (non-const) reference. The way to fix it is do: friend ostream &operator <<(ostream &, const test &); ostream &operator <<(ostream &out, const test &tt) Note the error message is not giving a good error message but that is a different bug, PR 21631. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29542
[Bug fortran/17741] ICE in gfc_free_namespace, at fortran/symbol.c:2208
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-10-22 00:09 --- Created an attachment (id=12472) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12472&action=view) A prelimary patch as one concept for handling this This patch gives a good result for error messages. However we are still left with some memory leak. I will have to explore this some more. The concept is to reset the locus and then return the correct end statement after emitting the error message. Whats nice about this is it gives errors for all the nested statements missing the correct "END" Comments anyone? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17741
[Bug ada/29543] New: Ada produces substantially slower code than FORTRAN for identical inputs - looping over double subscripted arrays
I understand comparing very very small benchmarks like this can be misleading
but I believe I've looked at this enough to have a sense that it is
demonstrating a basic truth and not a narrow performance issue.
The test case that has been attached shows a FORTRAN and Ada program that are
equivalent (within their matrix multiply loop). The Ada one runs about 2x
slower with about 3x the number of machine instructions in the inner loop.
(Note that running with Ada run time checks disabled).
I dumped the optimized trees (as the original tree of the Ada version was
difficult to read because of the node types not being known to the pretty
printer). The Ada tree is certainly a mess compared to the FORTRAN version.
The core of the FORTRAN code looks like
do I = 1,N
do J = 1,N
sum = 0.0
do R = 1,N
sum = sum + A(I,R)*B(R,J)
end do
C(I,J) = sum
end do
end do
With the resulting optimized tree fragment (of the inner most loop) being
:;
sum = MEM[base: (real4 *) ivtmp.97] * MEM[base: (real4 *) pretmp.81, index:
(real4 *) ivtmp.161 + (real4 *) ivtmp.94, step: 4B, offset: 4B] + sum;
ivtmp.94 = ivtmp.94 + 1;
ivtmp.97 = ivtmp.97 + ivtmp.157;
if (ivtmp.94 == () D.1273) goto ; else goto ;
While the core of the Ada code looks like:
for I in A'range(1) loop
for J in A'range(2) loop
Sum := 0.0;
for R in A'range(2) loop
Sum := Sum + A(I,R)*B(R,J);
end loop;
C(I,J) := Sum;
end loop;
end loop;
With the resulting optimized tree fragment of the inner most loop being :
:;
D.2370 = (*D.2277)[pretmp.627]{lb: tst_array__L_3__T16b___L sz: pretmp.709 *
4}[() r]{lb: tst_array__L_4__T17b___L sz: 4};
:
temp.721 = D.2344->LB0;
:
temp.720 = D.2344->UB1;
:
temp.719 = D.2344->LB1;
:
j.73 = () j;
D.2373 = (*D.2298)[() r]{lb: temp.721 sz: MAX_EXPR <(temp.720 +
1 - temp.719) * 4, 0> + 3 & -4}[j.73]{lb: temp.719 sz: 4};
:
D.2374 = D.2370 * D.2373;
:
sum = D.2374 + sum;
:
if (r == tst_array__L_4__T17b___U) goto ; else goto ;
:;
r = r + 1;
goto ();
Now, I'll be the first to admit that I know very little about the innards of
compiler technology but that tree looks like a horrible mess. It is no wonder
the resulting assembly is such a mess.
I am attaching a tar file that has the complete source for the Ada and the
FORTRAN version.
--
Summary: Ada produces substantially slower code than FORTRAN for
identical inputs - looping over double subscripted
arrays
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff at thecreems dot com
GCC build triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
[Bug ada/29543] Ada produces substantially slower code than FORTRAN for identical inputs - looping over double subscripted arrays
--- Comment #1 from jeff at thecreems dot com 2006-10-22 02:02 --- Created an attachment (id=12473) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12473&action=view) Source code and very simple build script for Ada and FORTRAN code capable of showing poor tree and runtime performance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
[Bug tree-optimization/29543] Ada produces substantially slower code than FORTRAN for identical inputs - looping over double subscripted arrays
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-22 02:20 --- Well actually Fortran front-end flattens the arrays which causes the difference. In fact the Fortran front-end is incorrect in flattening it for reasons of debugging. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|ada |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
[Bug tree-optimization/29543] Ada produces substantially slower code than FORTRAN for identical inputs - looping over double subscripted arrays
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-22 02:23 --- But the real problem is that IV-opts does not know how to handle non-constant array sizes and bounds. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Version|unknown |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
[Bug bootstrap/29544] New: [4.2 Regression] Not building with checking in stage1
In 4.1 (and maybe even 4.0), we used to build with checking enable in stage1 to check some bugs but now with the toplevel bootstrap, this no longer happens. -- Summary: [4.2 Regression] Not building with checking in stage1 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29544
[Bug bootstrap/29544] [4.2 Regression] Not building with checking in stage1
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29544
[Bug bootstrap/29544] [4.2 Regression] Not building with checking in stage1
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-22 02:29 --- In 4.2 and above: gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I/src/gcc/eh/gcc/gcc -I/src/gcc/eh/gcc/gcc/. -I/src/gcc/eh/gcc/gcc/../include -I/src/gcc/eh/gcc/gcc/../libcpp/include -I/src/gcc/eh/gcc/gcc/../libdecnumber -I../libdecnumber/src/gcc/eh/gcc/gcc/tree-ssa.c -o tree-ssa.o In 4.1: gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -I. -I. -I/home/pinskia/src/gcc/gcc-4.1/gcc/gcc -I/home/pinskia/src/gcc/gcc-4.1/gcc/gcc/. -I/home/pinskia/src/gcc/gcc-4.1/gcc/gcc/../include -I/home/pinskia/src/gcc/gcc-4.1/gcc/gcc/../libcpp/include /home/pinskia/src/gcc/gcc-4.1/gcc/gcc/tree-ssa.c -o tree-ssa.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29544
[Bug bootstrap/29544] [4.2 Regression] Not building with checking in stage1
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-22 02:40 --- I think there are two ways of fixing this is do --enable-checking=yes for stage1 gcc configuring or the way 4.1 does it via CFLAGS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29544
[Bug bootstrap/29544] [4.2 Regression] Not building with checking in stage1
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-22 03:01 --- I am going to fix it via the configure option, for the mainline I am going to recommend to also add rtl checking for stage1. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-22 03:01:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29544
[Bug middle-end/29519] [4.2 Regression] Bad code on MIPS with -fnon-call-exceptions
--- Comment #6 from daney at gcc dot gnu dot org 2006-10-22 04:11 --- Created an attachment (id=12474) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12474&action=view) Potential fix. As per Richard's analysis, I am testing this patch. It seems to fix the testcase. I will bootstrap and test i686-pc-linux-gnu as well as mipsel-linux-gnu. Richard, does this look right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29519
[Bug fortran/29391] LBOUND and UBOUND are broken
--- Comment #14 from pault at gcc dot gnu dot org 2006-10-22 04:47 --- > (from PR29489) > Thanks FX, I forgot all about it. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug c++/28088] [4.1 Regression] Internal compiler error on boost mpl test/apply.cpp
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-10-22 04:59 --- Technically, I think it would be feasible to backport the patch. However, because that patch eliminates a GNU extension we would change the set of programs accepted on the 4.1 branch. I'm not sure that's a good idea, even to fix a failure to accept conforming code. I can see arguments both ways, so I'd like to see if there's a consensus in the community and among Nathan and Jason. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28088
[Bug fortran/29507] INDEX in an array initialization causes ICE
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-22 05:01 --- I have a general fix, in place of that of #1, more or less working. It'll be a day or two yet before it's ready for exposure. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-22 05:01:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29507
[Bug c++/29545] New: error when mixing virtual and non virtual increment operators
an error occur when mixing non virtual post increment operator
with virtual pre increment operator
$ cat test.cpp
struct A {
const A& operator ++ (int) { return *this; }
virtual const A& operator++() = 0;
};
struct B : public A {
virtual const A& operator++() { return *this; }
};
int main(void) {
B teste;
teste++;
return 0;
}
$ g++-4.1 test.cpp
test.cpp: In function 'int main()':
test.cpp:12: error: no 'operator++(int)' declared for postfix '++', trying
prefix operator instead
$
and if I remove pre increment operator it compiles ok
$ cat test.cpp
struct A {
const A& operator ++ (int) { return *this; }
//virtual const A& operator++() = 0;
};
struct B : public A {
//virtual const A& operator++() { return *this; }
};
int main(void) {
B teste;
teste++;
return 0;
}
$ g++-4.1 test.cpp
$
--
Summary: error when mixing virtual and non virtual increment
operators
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raphael dot ribas at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29545
[Bug c++/29545] error when mixing virtual and non virtual increment operators
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-22 05:40 ---
This is invalid code as the operator++ in B hides both operator++.
In the same way, the following code is also invalid:
struct A {
const A& f(int) { return *this; }
virtual const A& f() = 0;
};
struct B : public A {
virtual const A& f() { return *this; }
};
int main(void) {
B teste;
teste.f(1);
return 0;
}
Adding
using A::operator++;
inside B, makes this valid code and have GCC accept the code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29545
[Bug tree-optimization/29543] Poor code generated for arrays with variable bounds
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-10-22 06:45 --- > The test case that has been attached shows a FORTRAN and Ada program that are > equivalent (within their matrix multiply loop). The Ada one runs about 2x > slower with about 3x the number of machine instructions in the inner loop. Why do you go through an indirection in Ada? Just write: type Real_Matrix is array(Integer range <>,Integer range <>) of Float; N : Positive := Positive'Value (Argument (1)); G : Ada.Numerics.Float_Random.Generator; A,B,C : Real_Matrix (1..N, 1..N); Start, Finish : Ada.Calendar.Time; Sum : Float := 0.0; and you'll probably significantly narrow the gap. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-22 06:45:13 date|| Summary|Ada produces substantially |Poor code generated for |slower code than FORTRAN for|arrays with variable bounds |identical inputs - looping | |over double subscripted | |arrays | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
