[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions
--- Comment #15 from hp at gcc dot gnu dot org 2008-05-10 06:59 --- (In reply to comment #14) If there is no CONST wrapping the difference of symbols, does the CRIS port continue to believe the address is legitimate? As I said, for the failure on CRIS, it's not passed as an *address*, just an ordinary operand. In other words, Paolo's patch without the CONST? The CONST changes the world, so hopefully the right thing would happen. Separate from the specific grouping satisfying legitimate_address, the RTL does contain a difference of SYMBOL_REFs from different sections. If it is not a valid address, valid instruction, valid relocation, GCC will generate the difference as an explicit subtraction across multiple instructions because it is trying to calculate that operation. Correct. I do not understand how the operation GCC is trying to perform in the CRIS port is valid using multiple instructions. Maybe it'll help if I just quote the faulty assembly code: ... move.d $r12,$r13 add.d .LC6-__ZN...mangling elided...rep_storageE-12,$r13 ba .L98 nop ... (The add.d does what you think; adds the offset to register $r13). The .LC6-__ZN...mangling elided...rep_storageE-12 (wrapped in a CONST) is just passed to LEGITIMATE_CONSTANT_P at replacement time. No MEM in sight, hence no GO_IF_LEGITIMATE_ADDRESS call. brgds, H-P -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182
[Bug middle-end/35964] ICE with -funroll-loops on arm/arm eabi
--- Comment #8 from aurelien at aurel32 dot net 2008-05-10 08:28 --- I confirm that those patches actually fix the problem on ARM oldabi, so the problem is *not* fixed in the gcc 4.3 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35964
[Bug middle-end/35964] ICE with -funroll-loops on arm/arm eabi
--- Comment #9 from tbm at gcc dot gnu dot org 2008-05-10 08:34 --- Seems like we should reopen this bug then. Aurelien, how big are those patches you're talking about? Are they aimed at 4.3 or only or 4.4? -- tbm at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35964
[Bug middle-end/35964] ICE with -funroll-loops on arm/arm eabi
--- Comment #10 from tbm at gcc dot gnu dot org 2008-05-10 08:35 --- Also confirm the bug. -- tbm at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-10 08:35:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35964
[Bug tree-optimization/36198] New: expected integer_cst, have mult_expr
/data03/vondele/clean/cp2k/src/../src/d3_poly.F: In function init_d3_poly_module: /data03/vondele/clean/cp2k/src/../src/d3_poly.F:68: internal compiler error: tree check: expected integer_cst, have mult_expr in int_cst_value, at tree.c:8002 after the fix for PR36129, gfortran ([trunk revision 135124]) ICEs with the above. I'll try to get to a testcase, but it only happens with -fprofile-use, so it will be an ugly testcase at best. -- Summary: expected integer_cst, have mult_expr Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk OtherBugsDependingO 29975 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36198
[Bug tree-optimization/36198] expected integer_cst, have mult_expr
--- Comment #1 from jv244 at cam dot ac dot uk 2008-05-10 08:44 --- Created an attachment (id=15624) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15624action=view) all files needed to reproduce and a README with the command all files needed to reproduce and a README with the command -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36198
[Bug tree-optimization/36129] [4.3 Regression] ICE with -fprofile-use
--- Comment #14 from jv244 at cam dot ac dot uk 2008-05-10 08:46 --- (In reply to comment #13) Fixed for 4.4, patch needs to be backported to 4.3 branch. thanks for the patch, testing it, I ran into another ICE (PR36198) before reaching the crucial point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36129
[Bug middle-end/35964] ICE with -funroll-loops on arm/arm eabi
--- Comment #11 from aurelien at aurel32 dot net 2008-05-10 09:09 --- About 20kB in total: -rw-r--r-- 1 aurel32 aurel32 3975 May 9 15:15 armel-hilo-union-class.dpatch -rw-r--r-- 1 aurel32 aurel32 15153 May 9 15:15 gfortran-armel-updates.dpatch -rw-r--r-- 1 aurel32 aurel32 11092 May 9 15:15 libobjc-armel.dpatch I don't know if they will be applied for 4.3, but I would guess they are originally aimed to 4.4. I a currently running the testsuite to make sure they don't introduce any regression, and then I will try to find which one actually fixes the problem. But my machine is not really fast... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35964
[Bug tree-optimization/36198] expected integer_cst, have mult_expr
--- Comment #2 from jv244 at cam dot ac dot uk 2008-05-10 10:03 --- backtrace #0 internal_error (gmsgid=0xc2d800 tree check: %s, have %s in %s, at %s:%d) at /data03/vondele/gcc_trunk/gcc/gcc/diagnostic.c:594 #1 0x008a284e in tree_check_failed (node=0x2b6a9f6ec4c0, file=0xc2d628 /data03/vondele/gcc_trunk/gcc/gcc/tree.c, line=8002, function=0xc2f7fc int_cst_value) at /data03/vondele/gcc_trunk/gcc/gcc/tree.c:6764 #2 0x008a2c08 in int_cst_value (x=0x) at /data03/vondele/gcc_trunk/gcc/gcc/tree.c:8002 #3 0x0072ca52 in analyze_subscript_affine_affine (chrec_a=0x2b6a9faf5410, chrec_b=0x2b6a9fc29000, overlaps_a=0x7fff0bb79240, overlaps_b=0x7fff0bb79238, last_conflicts=0x7fff0bb79248) at /data03/vondele/gcc_trunk/gcc/gcc/tree-data-ref.c:2076 #4 0x0072eb86 in analyze_siv_subscript (chrec_a=0xc2d800, chrec_b=0x7fff0bb78f70, overlaps_a=0xba887e, overlaps_b=0xc2f7fc, last_conflicts=0xc2d64a) at /data03/vondele/gcc_trunk/gcc/gcc/tree-data-ref.c:2394 #5 0x0072f783 in subscript_dependence_tester_1 (ddr=0x102c620, dra=0x126dea0, drb=0x102c570, loop_nest=0x2b6a9fc15820) at /data03/vondele/gcc_trunk/gcc/gcc/tree-data-ref.c:2633 #6 0x007300cd in subscript_dependence_tester (ddr=0x102c620, loop_nest=0x2b6a9fc15820) at /data03/vondele/gcc_trunk/gcc/gcc/tree-data-ref.c:3219 #7 0x007315e8 in compute_all_dependences (datarefs=0x1046270, dependence_relations=0x7fff0bb795e8, loop_nest=0x104ca60, compute_self_and_rr=1 '\001') at /data03/vondele/gcc_trunk/gcc/gcc/tree-data-ref.c:3849 #8 0x00732899 in compute_data_dependences_for_loop (loop=0x2b6a9fc15820, compute_self_and_read_read_dependences=252 '', datarefs=0x7fff0bb795f0, dependence_relations=0x7fff0bb795e8) at /data03/vondele/gcc_trunk/gcc/gcc/tree-data-ref.c:4169 #9 0x007786f2 in tree_predictive_commoning_loop (loop=0x2b6a9fc15820) at /data03/vondele/gcc_trunk/gcc/gcc/tree-predcom.c:2495 #10 0x00779d5d in tree_predictive_commoning () at /data03/vondele/gcc_trunk/gcc/gcc/tree-predcom.c:2604 #11 0x007fe6c7 in run_tree_predictive_commoning () at /data03/vondele/gcc_trunk/gcc/gcc/tree-ssa-loop.c:191 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36198
[Bug tree-optimization/35215] ICE: verify_histograms failed with -fprofile-use
--- Comment #9 from ubizjak at gmail dot com 2008-05-10 11:21 --- Current 4.3.1 branch doesn't generate memset with zero length anymore. Closed as WORKSFORME, but if still fails, please reopen and attach new *.i, *.gcda and *.gcno files, produced with latest SVN HEAD versions of the compiler. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35215
[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences
--- Comment #23 from rsandifo at gcc dot gnu dot org 2008-05-10 12:01 --- Subject: Bug 33642 Author: rsandifo Date: Sat May 10 12:00:37 2008 New Revision: 135142 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135142 Log: gcc/testsuite/ PR rtl-optimization/33642 * gcc.c-torture/compile/pr11832.c: Skip for MIPS. * gcc.c-torture/compile/pr33009.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/compile/pr11832.c trunk/gcc/testsuite/gcc.c-torture/compile/pr33009.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences
--- Comment #24 from rsandifo at gcc dot gnu dot org 2008-05-10 12:03 --- As per the last message, I've skipped these tests for MIPS until the PR is fixed. -- 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=33642
[Bug rtl-optimization/31021] gfortran 20% slower than ifort on CP2K computational kernel
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-05-10 12:16 --- With current trunk, I see current mainline gfortran being 5% faster than Intel 10.0 on a Dual-Core AMD Opteron(tm) Processor 2212 at 2GHz. Joost, on your particular setup, does this still run too slow? -- 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=31021
[Bug rtl-optimization/31021] gfortran 20% slower than ifort on CP2K computational kernel
--- Comment #7 from jv244 at cam dot ac dot uk 2008-05-10 12:30 --- (In reply to comment #6) With current trunk, I see current mainline gfortran being 5% faster than Intel 10.0 on a Dual-Core AMD Opteron(tm) Processor 2212 at 2GHz. Joost, on your particular setup, does this still run too slow? Right now, the testcase in comment 1 still is 20% slower ifort/gcc. This is, however, with gfortran 4.3.0. Furthermore, it matters on which CPU you run this (in particular Intel vs. AMD). To summarize:processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz stepping: 6 ifort (IFORT) 9.1 20060707 Kernel time 3.812238 gcc version 4.3.0 (GCC) Kernel time 4.5482836 I'll try to build trunk on this machine and test again, but it might not be for today. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31021
[Bug tree-optimization/36198] expected integer_cst, have mult_expr
--- Comment #3 from ubizjak at gmail dot com 2008-05-10 12:36 ---
This is what goes into int_cst_value:
#2 0x008a60c8 in int_cst_value (x=0x2e72a4c0) at
../../gcc-svn/trunk/gcc/tree.c:8002
8002 unsigned HOST_WIDE_INT val = TREE_INT_CST_LOW (x);
(gdb) p debug_generic_expr (x)
((integer(kind=8)) {1, +, {1, +, 1}_1}_1 + -1) * 2
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-05-10 12:36:11
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36198
[Bug tree-optimization/36198] expected integer_cst, have mult_expr
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-05-10 12:58 --- That looks more like a fallout from: 2008-05-09 Jan Sjodin [EMAIL PROTECTED] Sebastian Pop [EMAIL PROTECTED] * tree-scalar-evolution.c: Document instantiate_scev. (instantiate_parameters_1): Renamed instantiate_scev_1. Don't use the same loop for instantiation_loop and evolution_loop. (instantiate_scev): New. (instantiate_parameters): Moved... (resolve_mixers): Update call to instantiate_scev_1 to pass the same loop twice. Maintains the semantics for this function. * tree-scalar-evolution.h (instantiate_scev): Declare. (instantiate_parameters): ...here. Now static inline. * tree-data-ref.c (dr_analyze_indices): Call instantiate_scev instead of resolve_mixers. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||spop at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36198
[Bug rtl-optimization/31021] gfortran 20% slower than ifort on CP2K computational kernel
--- Comment #8 from jv244 at cam dot ac dot uk 2008-05-10 13:43 --- (In reply to comment #7) This is, however, with gfortran 4.3.0. Trunk is marginally faster than 4.3.0, still about 20% slower than ifort Kernel time 4.5042820 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31021
[Bug fortran/36139] ICE in snapshot of 05/02/08 under HPPA Linux with IMPLICIT, PARAMETER, and function call
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-05-10 15:03 --- Though I do not get segfault, I can confirm valgrind errors. ==3660== 158 bytes in 1 blocks are definitely lost in loss record 3 of 9 ==3660==at 0x4A04D1F: calloc (vg_replace_malloc.c:279) ==3660==by 0xB3853A: xcalloc (xmalloc.c:162) ==3660==by 0x557B87: init_emit (emit-rtl.c:5012) ==3660==by 0x5EFD32: prepare_function_start (function.c:3902) ==3660==by 0x5F1D48: init_function_start (function.c:3949) ==3660==by 0x49054D: trans_function_start (trans-decl.c:1599) ==3660==by 0x49731D: gfc_generate_function_code (trans-decl.c:3108) ==3660==by 0x45439B: gfc_parse_file (parse.c:3582) ==3660==by 0x47B4CD: gfc_be_parse_file (f95-lang.c:258) ==3660==by 0x6E0190: toplev_main (toplev.c:962) ==3660==by 0x3FF061E073: (below main) (libc-start.c:220) ==4563==at 0x4A059F6: malloc (vg_replace_malloc.c:149) ==4563==by 0xB38587: xmalloc (xmalloc.c:147) ==4563==by 0x447154: gfc_getmem (misc.c:37) ==4563==by 0x46FBD7: gfc_get_namespace (symbol.c:2079) ==4563==by 0x46FD1C: gfc_symbol_init_2 (symbol.c:2928) ==4563==by 0x446E98: gfc_init_2 (misc.c:270) ==4563==by 0x4541C9: gfc_parse_file (parse.c:3502) ==4563==by 0x47B4CD: gfc_be_parse_file (f95-lang.c:258) ==4563==by 0x6E0190: toplev_main (toplev.c:962) ==4563==by 0x3FF061E073: (below main) (libc-start.c:220) -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-10 15:03:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36139
[Bug fortran/36197] [4.4 Regressio]: gfortran.dg/initialization_12.f90
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-05-10 15:12 --- Passes with -m32 and -m64 on x86-64-linux. May be i686 specific. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36197
[Bug fortran/36197] [4.4 Regressio]: gfortran.dg/initialization_12.f90
--- Comment #2 from hjl dot tools at gmail dot com 2008-05-10 15:31 --- Can you run valgrind on f951? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36197
[Bug fortran/36197] [4.4 Regressio]: gfortran.dg/initialization_12.f90
--- Comment #3 from hjl dot tools at gmail dot com 2008-05-10 15:36 ---
The bug is in quote_string:
/* Calculate the length we'll need: a backslash takes two (\\),
non-printable characters take 10 (\U) and others take 1. */
for (p = s, i = 0; i slength; p++, i++)
{
if (*p == '\\')
len += 2;
else if (!gfc_wide_is_printable (*p))
len += 10;
else
len++;
}
q = res = gfc_getmem (len + 1);
for (p = s, i = 0; i slength; p++, i++)
{
if (*p == '\\')
*q++ = '\\', *q++ = '\\';
else if (!gfc_wide_is_printable (*p))
{
sprintf (q, \\U%08 HOST_WIDE_INT_PRINT ux,
(unsigned HOST_WIDE_INT) *p);
q += 10;
}
\\U%08 takes 11 bytes, not 10, if you count trailing '\0'.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36197
[Bug fortran/36197] [4.4 Regressio]: gfortran.dg/initialization_12.f90
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-05-10 16:02
---
(In reply to comment #3)
else if (!gfc_wide_is_printable (*p))
{
sprintf (q, \\U%08 HOST_WIDE_INT_PRINT ux,
(unsigned HOST_WIDE_INT) *p);
q += 10;
}
\\U%08 takes 11 bytes, not 10, if you count trailing '\0'.
Yes, but the trailing '\0' will be overwritten with the next character, as it
should be. The issue is really that the format %08lux is not valid, it should
simply be %08lx (as x means unsigned hexadecimal, no need for a u). The
most depressing is that I spent quite some time reading the printf man page to
make sure I got it right :( And it's not seen in other cases, because the x is
overwritten by the next character.
So, the following patch should fix it:
Index: module.c
===
--- module.c(revision 135109)
+++ module.c(working copy)
@@ -1502,7 +1502,7 @@ quote_string (const gfc_char_t *s, const
*q++ = '\\', *q++ = '\\';
else if (!gfc_wide_is_printable (*p))
{
- sprintf (q, \\U%08 HOST_WIDE_INT_PRINT ux,
+ sprintf (q, \\U%08 HOST_WIDE_INT_PRINT x,
(unsigned HOST_WIDE_INT) *p);
q += 10;
}
(It fixes the valgrind message on x86_64-linux). I'll commit it as obvious as
soon as my regtesting is over.
Now, there is a another problem in that we shouldn't have this wide char in the
first place.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-05-10 16:02:52
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36197
[Bug fortran/36197] [4.4 Regressio]: gfortran.dg/initialization_12.f90
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2008-05-10 16:18 --- (In reply to comment #4) Now, there is a another problem in that we shouldn't have this wide char in the first place. I take that back, the wide char (a non-breaking space) is in the source file, so it's OK :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36197
[Bug fortran/36197] [4.4 Regressio]: gfortran.dg/initialization_12.f90
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-05-10 16:40 --- Subject: Bug 36197 Author: fxcoudert Date: Sat May 10 16:39:27 2008 New Revision: 135154 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135154 Log: PR fortran/36197 * module.c (quote_string): Fix sprintf format. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36197
[Bug fortran/36197] [4.4 Regressio]: gfortran.dg/initialization_12.f90
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2008-05-10 16:41 --- Fixed my mess. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36197
[Bug libfortran/36200] New: [mingw] Wrong rounding in floating-point I/O
The following short testcase (reduced from gfortran.dg/fmt_zero_precision.f90): write(*,200) 37.9 200 format(es8.0,) end ouputs 3.E+01 instead of 4.E+01. This happens on both i686-pc-mingw32 and x86_64-pc-mingw32. -- Summary: [mingw] Wrong rounding in floating-point I/O Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36200
[Bug libfortran/36200] [mingw] Wrong rounding in floating-point I/O
--- Comment #1 from dominiq at lps dot ens dot fr 2008-05-10 19:32 --- get 4.E+01 on darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36200
[Bug middle-end/36201] New: NVR in the front-end causes missed optimization later on (retval thought to alias arguments)
Testcase:
#define SIZE 1024
While looking into why manually SRA'd testcase worked better. I found this
interesting problem.
Take:
struct a
{
long long b;
a();
};
a f(a g, a h)
{
int i;
a res = g;
for (i = 0; i SIZE; i++)
res.b += h.b;
return res;
}
at -O2 we change res here to retval so we have retval in the inner loop.
If we supply -fno-elide-constructors which disables NVR in C++ front-end, we
get good code of doing loop based Copy Prop (SCEV copy prop) as we able to pull
out res.b. The issue is that we say h can alias retval but we don't say the
same thing for res though.
--
Summary: NVR in the front-end causes missed optimization later on
(retval thought to alias arguments)
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: missed-optimization, alias
Severity: enhancement
Priority: P3
Component: middle-end
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=36201
[Bug c++/36185] [4.4 Regression] wrong code with -O2 -fgcse-sm
--- Comment #4 from zadeck at gcc dot gnu dot org 2008-05-10 20:29 --- Subject: Bug 36185 Author: zadeck Date: Sat May 10 20:28:19 2008 New Revision: 135159 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135159 Log: 2008-05-10 Kenneth Zadeck [EMAIL PROTECTED] * gcse.c (store_killed_in_insn): Negated call to RTL_CONST_CALL_P. 2008-05-10 Kenneth Zadeck [EMAIL PROTECTED] PR rtl-optimization/36185 * g++.dg/opt/pr36185.C Added: trunk/gcc/testsuite/g++.dg/opt/pr36185.C Modified: trunk/gcc/ChangeLog trunk/gcc/gcse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36185
[Bug c++/36185] [4.4 Regression] wrong code with -O2 -fgcse-sm
--- Comment #5 from zadeck at naturalbridge dot com 2008-05-10 20:29
---
Subject: Re: [4.4 Regression] wrong code with -O2 -fgcse-sm
rguenth at gcc dot gnu dot org wrote:
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-09 15:04
---
Kenny, that's your PURE/CONST patch.
I am checking this in as obvious because given the frag from the first
pure const patch, this is an obvious fix. I left out the '!' when I
converted this conditional.(I also discussed this with Iant before i
tested the fix).
The patch was tested on x86-64.
committed as revision 135185.
Kenny
@@ -5987,7 +5987,7 @@ store_killed_in_insn (const_rtx x, const
{
/* A normal or pure call might read from pattern,
but a const call will not. */
- if (! CONST_OR_PURE_CALL_P (insn) || pure_call_p (insn))
+ if (RTL_CONST_CALL_P (insn))
return true;
/* But even a const call reads its parameters. Check whether the
2008-05-10 Kenneth Zadeck [EMAIL PROTECTED]
* gcse.c (store_killed_in_insn): Negated call to RTL_CONST_CALL_P.
2008-05-10 Kenneth Zadeck [EMAIL PROTECTED]
PR rtl-optimization/36185
* g++.dg/opt/pr36185.C
Index: ChangeLog
===
--- ChangeLog (revision 135153)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2008-05-10 Kenneth Zadeck [EMAIL PROTECTED]
+
+ * gcse.c (store_killed_in_insn): Negated call to RTL_CONST_CALL_P.
+
2008-05-10 H.J. Lu [EMAIL PROTECTED]
* config/i386/i386.c (bdesc_ptest): Removed.
Index: testsuite/g++.dg/opt/pr36185.C
===
--- testsuite/g++.dg/opt/pr36185.C (revision 0)
+++ testsuite/g++.dg/opt/pr36185.C (revision 0)
@@ -0,0 +1,24 @@
+// PR rtl-optimization/36185
+// { dg-do run }
+// { dg-options -O2 -fgcse-sm }
+
+struct Base {
+virtual ~Base() {}
+virtual void f() = 0;
+};
+struct Derived : Base {
+Derived();
+virtual void f() {}
+};
+struct Foo {
+Foo(Base);
+};
+Derived::Derived() {
+Foo foo(*this);
+}
+Foo::Foo(Base base) {
+base.f();
+}
+int main() {
+Derived d;
+}
Index: gcse.c
===
--- gcse.c (revision 135153)
+++ gcse.c (working copy)
@@ -5987,7 +5987,7 @@ store_killed_in_insn (const_rtx x, const
{
/* A normal or pure call might read from pattern,
but a const call will not. */
- if (RTL_CONST_CALL_P (insn))
+ if (!RTL_CONST_CALL_P (insn))
return true;
/* But even a const call reads its parameters. Check whether the
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36185
[Bug c++/36185] [4.4 Regression] wrong code with -O2 -fgcse-sm
--- Comment #6 from zadeck at naturalbridge dot com 2008-05-10 21:27 --- fixed with commit of patch. -- zadeck at naturalbridge dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36185
[Bug libfortran/36202] New: [mingw] Namelist read fails with CRLF
gfortran.dg/namelist_44.f90 fails on mingw (both 32-bit and 64-bit) due to a bug in namelist reading, which can be reduced to: program gfcbug77 implicit none character(len=128) :: file = logical:: default namelist /BLACKLIST/ file, default integer, parameter :: nnml = 10 default = .true. open (nnml,file='gfcbug77.nml') read (nnml,nml=BLACKLIST) close(nnml,status=delete) end program gfcbug77 with gfcbug77.nml having the following content: blacklist ! foo file= 'myfile' default = F / with DOS-style (ie CRLF) line terminators. The CRLF that actually trigers the error is the one after the namelist name and the space (blacklist ^M, where ^M is the CRLF); all others can be removed and it still fails. The error is: At line 11 of file namelist_44.f90 (unit = 10, file = 'gfcbug77.nml') Fortran runtime error: Cannot match namelist object name ! -- Summary: [mingw] Namelist read fails with CRLF Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org GCC target triplet: *-*-mingw* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36202
[Bug libfortran/36202] [mingw] Namelist read fails with CRLF
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-10 22:04:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36202
[Bug libfortran/36200] [mingw] Wrong rounding in floating-point I/O
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet||*-*-mingw* Last reconfirmed|-00-00 00:00:00 |2008-05-10 22:05:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36200
[Bug c++/36203] New: explicit member function template lookup fails from templated function
BEGIN_TESTCASE
#include iostream
using namespace std;
class C {
public:
templateint V int f();
};
template int C::f0() { return 10; }
template int C::f1() { return 11; }
templateclass TC, int V
class Cx {
public:
int fx(TC*);
};
templateclass TC, int V int CxTC, V::fx(TC* tc) { return tc-fV(); }
int main()
{
C c;
CxC,0* c0 = new CxC,0;
CxC,1* c1 = new CxC,1;
cout c0-fx(c) endl;
cout c1-fx(c) endl;
delete c1;
delete c0;
return 0;
}
END_TESTCASE
Test case fails to compile with vanilla GCC 4.2.3 x86_64 and i386.
Checked RH 3.4.6 and RH compat 3.2.3, also fails.
testcase.C:18: error: expected primary-expression before ')' token
testcase.C:18: error: invalid operands of types 'unresolved overloaded
function type' and 'int' to binary 'operator'
Compiles and runs correctly under
Sun32: CC: Forte Developer 7 C++ 5.4 Patch 111715-13 2003/12/11
Sun64: CC: Forte Developer 7 C++ 5.4 Patch 111715-13 2003/12/11
IBM32: XL C++ 8.0.0.17
IBM64: XL C++ 8.0.0.17
MS32: Microsoft 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for
80x86
MS64: Microsoft C/C++ Optimizing Compiler Version 14.00.50727.762 for x64
Curiously fails with EDG (ICC 10.1.014), but this may
be due to EDG support of GCC bugs per
http://www.edg.com/index.php?location=c_lang
A GNU C and C++ compatibility mode, which provides the extensions supported
by GCC (versions 3.2-4.2), along with various undocumented features and bugs.
Lexical support laid out in first paragraph of ISO 14882:
3.4.5 Class member access [basic.lookup.classref]
In a class member access expression (5.2.5), if the . or - token is
immediately followed by an identifier followed by a , the identifier must be
looked up to determine whether the is the beginning of a template argument
list (14.2) or a less-than operator. . .
Would greatly appreciate fix on high priority track with 4.2.3 patch as this
critical for us.
--
Summary: explicit member function template lookup fails from
templated function
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: starlight at binnacle dot cx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36203
[Bug c++/36203] explicit member function template lookup fails from templated function
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-10 23:01 ---
This is not a bug:
templateclass TC, int V int CxTC, V::fx(TC* tc) { return tc-fV(); }
You frogot the template keyword. That is the above should be:
templateclass TC, int V int CxTC, V::fx(TC* tc) { return tc-template
fV(); }
as tc is dependent, you need to tell the compiler that it will be a template,
otherwise it will try to parse the as a that it is parsing it as (tc-f
V) () .
Also EDG in strict mode (non GNU extension mode) rejects it as expected.
See also http://gcc.gnu.org/gcc-3.4/changes.html (You must now use the typename
and template keywords to disambiguate dependent names, as required by the C++
standard. ) .
--
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=36203
[Bug c++/36203] explicit member function template lookup fails from templated function
--- Comment #2 from starlight at binnacle dot cx 2008-05-10 23:41 --- This was more of a learning experience than a forgetting and remembering one. Thank you for the help. Several template behaviors required by a strict ISO standard reading are miles distant from intuition. This surely qualifies, especially as three major vendor compilers accept it without the keyword. An improved error message from GCC would help immensely. Spent several hours googling this and coming up dry (including a review of closed GCC bug reports) before reporting it. Can't afford to read ISO 14882 from start to finish every time this happens. Another example is the despicable exclusion of base template member names from the default scope. Regardless of any correctness, it's an nightmare to constantly insert 'this-' and/or 'using' constructs to overcome the behavior that 99.999% of the time serves no useful purpose. A command switch separate from -fpermissive should exist for relaxing this one insanely annoying rule. At least the error message here finally provides a meaningful indication regarding the cause of the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36203
[Bug tree-optimization/36204] New: [4.4 Regression] missed store sinking out of a loop
At first I thought this was not a generic issue but I noticed it in generic
places that did not have any aliasing issues.
An example is the following program should not have any loop in it:
struct BUF1
{
int b1;
int b12;
};
void link_error();
int foo(int n, int * p)
{
int i = 0;
for (i = 0; i 1024*1024; i++)
{
p[0] = 1;
}
if (p[0] != 1)
link_error ();
return 0;
}
GNU C (GCC) version 4.4.0 20080304 (experimental) [trunk revision 132852]
(i386-apple-darwin8.10.1)
Worked but:
GNU C (GCC) version 4.4.0 20080510 (experimental) [trunk revision 135142]
(i386-apple-darwin8.11.1)
does not.
--
Summary: [4.4 Regression] missed store sinking out of a loop
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
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=36204
[Bug tree-optimization/36204] [4.4 Regression] missed store sinking out of a loop
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36204
[Bug c++/36203] explicit member function template lookup fails from templated function
--- Comment #3 from starlight at binnacle dot cx 2008-05-10 23:54 --- Now that I'm fixing the -template f() member references in the code it's obvious this one is just a much of a hemorrhoidal pain as the scope rule resolution. It deserves a command switch for turning off the strict behavior. Something like -fdisable-non-intuitive-template-behavior-that-serves-no-real-purpose -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36203
[Bug c++/36203] explicit member function template lookup fails from templated function
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-10 23:57 --- -fdisable-non-intuitive-template-behavior-that-serves-no-real-purpose It is hard to figure out just from the context of the sources that it is going to be a template or not in some cases. Guessing makes it worse. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36203
[Bug c++/36203] explicit member function template lookup fails from templated function
--- Comment #5 from starlight at binnacle dot cx 2008-05-11 00:08 --- Yet Sun, IBM and Microsoft all somehow manage it. Now what was once a clean, elegant and easy to read function is a hideous hairball template function. I've become so frustrated with C++ generics over the last couple of years that I've started to just use M4 macros to accomplish the same result. When done correctly they are just as type-safe and ten times more readable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36203
[Bug target/24713] objc/execute/exceptions/foward-1.m fails on sh-elf with -O3
--- Comment #1 from kkojima at gcc dot gnu dot org 2008-05-11 00:10 --- Kenny made me notice that julian proposed a patch for ARM which had similar failures for foward-1.m. Although it turned out that the cause of failure on SH is different from that on ARM, his analysis helps to see what is going on here. I've confirmed that foward-1.m fails on trunk for sh-elf even with -O0 -fomit-frame-pointer. sh-elf compiler generates a wrong frame info for libobjc/sendmsg.c:__objc_word_forward for non fpu arches. In problematic case, __objc_word_forward was compiled like as: __objc_word_forward: .LFB2: mov.l r7,@-r15 mov.l r6,@-r15 mov.l r14,@-r15 .LCFI0: sts.l pr,@-r15 and there are no frame info for first 2 instructions. It results a bad stack pointer value after unwinding when -fomit-frame-pointer is specified. I'm testing the attached patch. diff -uprN ORIG/trunk/gcc/config/sh/sh.c LOCAL/trunk/gcc/config/sh/sh.c --- ORIG/trunk/gcc/config/sh/sh.c 2008-04-27 13:53:04.0 +0900 +++ LOCAL/trunk/gcc/config/sh/sh.c 2008-05-10 14:27:53.0 +0900 @@ -6320,7 +6320,6 @@ sh_expand_prologue (void) )) break; insn = push (rn); - RTX_FRAME_RELATED_P (insn) = 0; } } } -- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC||kkojima at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|rtl-optimization|target Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-11 00:10:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24713
[Bug tree-optimization/36204] [4.4 Regression] missed store sinking out of a loop
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-11 00:17 --- Lim is no longer doing this which means this is most likely caused by the LIM aliasing oracle patch. -- pinskia 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36204
[Bug tree-optimization/36204] [4.4 Regression] missed store sinking out of a loop
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-11 00:53 ---
Note if we have the following source:
void link_error();
int foo(int n, int * p)
{
int i = 0;
p[0] = 0;
for (i = 0; i 1024*1024; i++)
{
p[0]++;
}
if (p[0] != 1024*1024)
link_error ();
return 0;
}
Since PRE is doing LIM's job, we get rid of the loop at -O1 but miss it at -O2.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |major
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-05-11 00:53:36
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36204
[Bug tree-optimization/36204] [4.4 Regression] missed store sinking out of a loop
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-11 00:54 --- I think this bit did it: (movement_possibility): Do not allow moving statements that store to memory. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36204
[Bug tree-optimization/36204] [4.4 Regression] missed store sinking out of a loop
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-11 01:06 --- (In reply to comment #3) I think this bit did it: (movement_possibility): Do not allow moving statements that store to memory. Yes reverting this part of the patch fixes the regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |major http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36204
[Bug tree-optimization/36204] [4.4 Regression] missed store sinking out of a loop
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-11 01:35 ---
Reverting that part of the patch causes an ICE with the following code:
struct BUF1
{
int b1;
int b12;
};
void link_error();
int foo(int n, struct BUF1 * p)
{
int i = 0;
for (i = 0; i 1024*1024; i++)
p-b1 = 1;
if (p-b1 != 1)
link_error ();
return 0;
}
Which means we can't even to LIM that case either :(.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36204
[Bug c++/36203] explicit member function template lookup fails from templated function
--- Comment #6 from bangerth at dealii dot org 2008-05-11 02:17 ---
(In reply to comment #5)
Yet Sun, IBM and Microsoft all somehow manage it.
But which function do they take in this case:
--
void f();
template typename T struct B
{
void f();
};
template typename T struct D : BT
{
void g()
{
f();
}
};
---
The standard prescribes that in D::g() the function ::f() is called. Are
you suggesting that the compiler pick B::f() instead? Or do you suggest
that the compiler picks B::f() if such a function exists, and ::f() otherwise?
That wouldn't be very intuitive either.
The rules may not always be intuitive, but they're there for a good reason,
not to annoy users.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36203
[Bug c++/36203] explicit member function template lookup fails from templated function
--- Comment #7 from starlight at binnacle dot cx 2008-05-11 02:42 --- That little bit of ambiguity bothers me a lot less that writing 55,000 freaking 'using' statements, which is what I've had to do for several years now. In the real world nobody except idiots name their functions 'f', so it doesn't arise as a practical problem. To the extent it does, writing an occasional ::f() and B::f() are much less of a problem than the hundreds of stupid 'using' statements I've had to write ever since GCC 3.4. The resulting code is much harder to maintain as every time I add some logic I then have spend 30 minutes or an hour chasing down more 'using's. The theoretical side of the issue makes no impression on people who work for living. Have a switch option for masochists who give a s**t. Let me be perfectly clear: Thousands of lines of code worked perfectly fine before this slavish standard nonsense. All that's changed is that people like me who used to like templates like them a lot less now. M4 looks better every day. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36203
[Bug c++/36203] explicit member function template lookup fails from templated function
--- Comment #8 from bangerth at dealii dot org 2008-05-11 02:59 --- (In reply to comment #7) That little bit of ambiguity bothers me a lot less that [...] If that's your opinion, then you've never worked with large software systems. Writing a few this- here and there because the compiler complains is a small effort compared to debugging why your code doesn't work. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36203
[Bug bootstrap/25502] Werror problem in build
--- Comment #13 from aaronavay62 at aaronwl dot com 2008-05-11 03:04 --- What would be an acceptable solution other than having bootstrap perpetually broken, and other than --disable-werror? 1) We could only enable this warning when in strict mode, eg -std=c99 -pedantic. -std=gnu99 -pedantic would not warn. This seems like it might be best. 2) Adding __extension__ will silence this warning. Should we make a macro to decorate these uses of HOST_WIDEST_INT_PRINT_DEC? 3) Worse case, can we just HOST_WIDEST_INT long? -- aaronavay62 at aaronwl dot com changed: What|Removed |Added CC||aaronavay62 at aaronwl dot ||com Last reconfirmed|2005-12-23 05:44:30 |2008-05-11 03:04:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
[Bug c++/36203] explicit member function template lookup fails from templated function
--- Comment #9 from starlight at binnacle dot cx 2008-05-11 03:14 --- You're speaking of large systems of code written by bad programmers, who by definition should never be let anywhere near C++. Let them write Java and C#, languages that were designed specifically for bad programmers. No class layer should be so large and complex that it isn't quickly obvious when a conflict arises. Any anyone who has large collections of global scope function names, or re-uses function names found in the STL should be shot. On the other hand it easy to write base class template hierarchies with 30 to 50 members referenced in derived classes. You seem to think that writing and maintaining dozens of 'using' statements in each layer is a great way to spend your days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36203
[Bug c++/36203] explicit member function template lookup fails from templated function
--- Comment #10 from starlight at binnacle dot cx 2008-05-11 03:29 --- Oh, and let's not forget about the millions of lines of C++ code written for the Windows platform that will *never* be ported to Linux. How's that for a domain of large software systems? If that scary old ambiguity monster was really so bad, why doesn't VC6,7,8,9 enforce the scope rule? If template member names were such a problem, why does VC8 not demand the '-template f()' syntax? You can mumble bad things about Microsoft all day long, but they sell a lot of software and make a *lot* of money supporting a commercial realm that's surely much larger than the *nix world. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36203
[Bug c++/36203] explicit member function template lookup fails from templated function
--- Comment #11 from bangerth at dealii dot org 2008-05-11 03:32 --- (In reply to comment #10) VC6,7,8,9 I suppose that's the compiler you should use then. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36203
[Bug c++/36203] explicit member function template lookup fails from templated function
--- Comment #12 from starlight at binnacle dot cx 2008-05-11 03:36 --- It could happen. All of our new customers for the last two years run Windows, not Linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36203
[Bug bootstrap/25502] I64d format Werror problem in build
--- Comment #14 from aaronavay62 at aaronwl dot com 2008-05-11 04:48 --- Another question: why does lld not cause warnings on linux here? I don't see what the difference is. Whatever the situation is, I don't see any reason that I64d should behave differently from lld in gnu89 mode. -- aaronavay62 at aaronwl dot com changed: What|Removed |Added GCC build triplet|i686-pc-mingw32 | GCC target triplet|i686-pc-mingw32 | Last reconfirmed|2008-05-11 03:04:43 |2008-05-11 04:48:20 date|| Summary|Werror problem in build |I64d format Werror problem ||in build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
[Bug libfortran/36200] [mingw] Wrong rounding in floating-point I/O
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-05-11 05:19 --- Works OK on Cygwin 4.E+01 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36200
[Bug fortran/36205] New: Hangup with array_constructor_24.f90 at -O3
This test case fails at -O3 with Cygwin. Works fine with -O, and -O2 $ gfc -v Using built-in specs. Target: i686-pc-cygwin Configured with: ../gcc44/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran --disable-bootstrap --enable-threads=posix --enable-sjlj-exceptions --enable-version-specific-runtime-libs --enable-nls --disable-libmudflap --disable-shared --disable-win32-registry --with-system-zlib --enable-checking=release --enable-werror --without-included-gettext --without-x --enable-libgomp Thread model: posix gcc version 4.4.0 20080510 (experimental) [trunk revision 135164] (GCC) $ gfc -O3 array_constructor_24.f $ ./a.exe Hangup $ -- Summary: Hangup with array_constructor_24.f90 at -O3 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org GCC host triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36205
