[Bug c++/27547] New: [4.0/4.1/4.2 regression] ICE on invalid operator=
Since GCC 3.4.0 the C++ frontend ICEs on the following invalid code snippet:
int operator=(int);
void foo()
{
operator=(0);
}
bug.cc:1: error: 'int operator=(int)' must be a nonstatic member function
bug.cc: In function 'void foo()':
bug.cc:5: internal compiler error: in copy_fn_p, at cp/decl.c:8821
Please submit a full bug report, [etc.]
I'll post a patch soon.
--
Summary: [4.0/4.1/4.2 regression] ICE on invalid operator=
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27547
[Bug target/27537] XMM alignment fault when compiling for i386 with -Os
--- Comment #4 from agner at agner dot org 2006-05-11 07:11 --- Thanks for confirming this bug. If Gcc relies on the stack being aligned then it has to be an official ABI requirement. It makes perfectly sense to compile the whole program, or some of it, with -Os and also use XMM. -Os can be the optimal option if code cache or data cache is a critical resource. It is also a perfectly justifiable solution to compile the part of the program that contains the innermost loop with -O3 and the rest of the program with -Os. The error also occurs if part of the program is compiled with the Intel C++ compiler, because the Intel people follow the official ABI which hasn't been updated for many years. The Intel compiler is intended to be 100% binary compatible with Gnu. Gcc is no longer a hobby project for a limited group of nerds. It is one of the most used compilers in the world and it is used for critical applications. Therefore, you have to be strict about ABI standards. Either the ABI must be changed and made public, or the compiler must be changed so that it doesn't rely on the stack being aligned by 16. I can find the "SYSTEM V. APPLICATION BINARY INTERFACE. Intel386 Architecture Processor Supplement" at www.caldera.com. It says "DRAFT COPY, March 19, 1997". Nothing indicates that this is the official or the latest version. It says nothing about MMX or XMM. I have documented the things that are not clear from the ABI in http://www.agner.org/assem/calling_conventions.pdf as good as I can. I am going to change this document when this issue is resolved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27537
[Bug c++/27547] [4.0/4.1/4.2 regression] ICE on invalid operator=
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||05/msg00445.html Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27547
[Bug c++/27384] [4.0/4.1/4.2 regression] ICE with invalid array size
--- Comment #3 from patchapp at dberlin dot org 2006-05-11 07:15 --- Subject: Bug number PR27384 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00443.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27384
[Bug middle-end/27488] [4.1/4.2 regression] ICE in tree_expr_nonnegative_p
--- Comment #3 from patchapp at dberlin dot org 2006-05-11 07:15 --- Subject: Bug number PR27488 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00444.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27488
[Bug c++/27547] [4.0/4.1/4.2 regression] ICE on invalid operator=
--- Comment #1 from patchapp at dberlin dot org 2006-05-11 07:16 --- Subject: Bug number PR c++/27547 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00445.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27547
[Bug c++/27505] [4.2 Regression] ICE in const folding with bitfields
--- Comment #3 from kazu at gcc dot gnu dot org 2006-05-11 07:31 --- Some analysis at: http://gcc.gnu.org/ml/gcc/2006-05/msg00263.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27505
[Bug tree-optimization/27283] [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge
--- Comment #7 from tbm at cyrius dot com 2006-05-11 08:22 --- While the test case submitted to this PR indeed works now, the software program which originally showed the bug shows that it's still there. Here's a new test case. -- tbm at cyrius dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27283
[Bug tree-optimization/27283] [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge
--- Comment #8 from tbm at cyrius dot com 2006-05-11 08:24 --- Created an attachment (id=11438) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11438&action=view) new test case 1657:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O1 mini.c Conflict NewMins$maxdex_407(ab) and NewMins$maxdex_379(ab) across an abnormal edge from BB8->BB42 mini.c: In member function 'gIndexOdometer gIndexOdometer::AfterExcisionOf(int&) const': mini.c:45: internal compiler error: SSA corruption Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. zsh: exit 1 /usr/lib/gcc-snapshot/bin/g++ -c -O1 mini.c 1658:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c mini.c 1659:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -v Using built-in specs. Target: powerpc-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,fortran,objc,obj-c++,treelang --prefix=/usr/lib/gcc-snapshot --enable-shared --with-system-zlib --disable-nls --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/gcc-snapshot/jre --enable-mpfr --disable-multilib --disable-werror powerpc-linux-gnu Thread model: posix gcc version 4.2.0 20060508 (experimental) 1660:[EMAIL PROTECTED]: ~] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27283
[Bug tree-optimization/27283] [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-05-11 08:26 --- The orginal problem is fixed and Martin is opening a new bug for the other issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27283
[Bug tree-optimization/27548] New: [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge
I get a SSA corruption ICE with the following test case. This is not the same as PR27283 which I originally submitted: the test case from the previous bug indeed works now, but the original software package still ICEs. Here's a test case that still procudes an ICE. gcc version 4.2.0 20060508 (experimental) 1657:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O1 mini.c Conflict NewMins$maxdex_407(ab) and NewMins$maxdex_379(ab) across an abnormal edge from BB8->BB42 mini.c: In member function 'gIndexOdometer gIndexOdometer::AfterExcisionOf(int&) const': mini.c:45: internal compiler error: SSA corruption Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. zsh: exit 1 /usr/lib/gcc-snapshot/bin/g++ -c -O1 mini.c 1658:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c mini.c 1659:[EMAIL PROTECTED]: ~] -- Summary: [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com GCC build triplet: powerpc-linux-gnu GCC host triplet: powerpc-linux-gnu GCC target triplet: powerpc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27548
[Bug middle-end/27529] Does not fold (char *)(size_t)char_ptr or (size_t)(char *)size_t_var
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-11 08:30 --- Subject: Bug 27529 Author: rguenth Date: Thu May 11 08:29:40 2006 New Revision: 113692 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113692 Log: 2006-05-11 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/27529 * fold-const.c (fold_unary): Handle intermediate conversion to a pointer type like intermediate conversion to an integer type in folding of (T1)(T2)var to var. Match the code to the comment in the final conversion for (T1)(T2)var to (T1)var regarding to type precision. Rather than disallow T1 being of pointer type, assert that both T1 and var are of pointer type or not. Make sure not to fall over the frontends lazyness wrt array to pointer decay though. * gcc.dg/tree-ssa/foldcast-1.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/foldcast-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27529
[Bug middle-end/27529] Does not fold (char *)(size_t)char_ptr or (size_t)(char *)size_t_var
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-11 08:30 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27529
[Bug tree-optimization/27283] [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge
--- Comment #10 from tbm at cyrius dot com 2006-05-11 08:30 --- See PR27548 for the new one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27283
[Bug tree-optimization/27548] [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge
--- Comment #1 from tbm at cyrius dot com 2006-05-11 08:31 --- Created an attachment (id=11439) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11439&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27548
[Bug tree-optimization/27548] [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27548
[Bug tree-optimization/27549] New: [4.1 Regression] ICE in coalesce_abnormal_edges
typedef __SIZE_TYPE__ size_t;
struct E
{
virtual ~E () {}
virtual size_t e () const = 0;
virtual void f (char *x) const = 0;
};
struct F : public E
{
virtual ~F () {}
virtual size_t e () const { return 0; }
virtual void f (char *x) const { *x = '\0'; }
};
struct S
{
S () { a = new char[32]; b = 32; c = 0; a[0] = 0; }
void s (const char *x, size_t y) { v (c + y + 1); __builtin_memcpy(a + c, x,
y); c += y; a[c] = '\0'; }
void s (const E *x) { size_t l = x->e(); v (c + l + 1); x->f (a + c); c += l;
}
const char *t () { return a; }
void v (size_t n)
{
if (b >= n) return;
size_t b2 = b;
char *a2 = a;
for (;;)
{
b *= 2;
if (b >= n)
break;
}
a = new char[b];
if (b2)
{
__builtin_memcpy(a, a2, c);
a2[0] = 0;
for (size_t i = 1; i < b2; i++)
a2[i] = a2[i - 1];
delete[] a2;
}
}
~S ()
{
if (b)
{
a[0] = 0;
for (size_t i = 1; i < b; i++)
a[i] = a[i - 1];
}
delete[] a;
}
char * a;
size_t b, c;
};
const char *p;
size_t q;
const F u;
const char *
foo ()
{
S s;
s.s (p, q);
s.s (&u);
return s.t ();
}
ICEs at -O{1,2,3} in coalesce_abnormal_edges, at least on x86_64 and i386
linux.
--
Summary: [4.1 Regression] ICE in coalesce_abnormal_edges
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27549
[Bug tree-optimization/27548] [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-11 08:44 --- The good news is that IV-OPTs is not the cause. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27548
[Bug tree-optimization/27549] [4.1 Regression] ICE in coalesce_abnormal_edges
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-11 08:48 --- This worked in "4.1.0 20060208" and in "4.1.0 20051026". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27549
[Bug tree-optimization/27549] [4.1 Regression] ICE in coalesce_abnormal_edges
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-11 08:50 --- Does the patch for PR 27283 fix this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27549
[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-05-11 08:56 ---
Reduced testcase:
double zero;
double matmul_c8 (_Complex double * dest)
{
*dest += 1;
return zero;
}
we go from before cplxlower
matmul_c8 (dest)
{
double D.1526;
complex double D.1525;
complex double D.1524;
:
# VUSE ;
D.1524_2 = *dest_1;
D.1525_3 = D.1524_2 + __complex__ (1.0e+0, 0.0);
# zero_7 = V_MAY_DEF ;
*dest_1 = D.1525_3;
# VUSE ;
D.1526_5 = zero;
return D.1526_5;
}
to after it
;; basic block 2, loop depth 0, count 0
;; prev block 0, next block 1
;; pred: ENTRY [100.0%] (fallthru,exec)
;; succ: EXIT [100.0%]
:
# VUSE ;
D.1538 = REALPART_EXPR <*dest_1>;
# VUSE ;
D.1539 = IMAGPART_EXPR <*dest_1>;
D.1524_2 = COMPLEX_EXPR ;
CR.9_9 = D.1538;
CI.10_10 = D.1539;
D.1542 = CR.9_9 + 1.0e+0;
D.1525_3 = COMPLEX_EXPR ;
CR.11_11 = D.1542;
# zero_7 = V_MAY_DEF ;
*dest_1 = D.1525_3;
# VUSE ;
D.1526_5 = zero;
return D.1526_5;
note that for the complex dest, we have Vops for zero only, but later
a SMT falls out of the sky.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27341
[Bug middle-end/27536] [4.2 Regression] -fsection-anchors breaks Ada
--- Comment #3 from schwab at suse dot de 2006-05-11 09:03 ---
(gdb) bt
#0 fancy_abort (file=0x10849bb8 "../../gcc/emit-rtl.c", line=1784,
function=0x10849954 "change_address_1") at ../../gcc/diagnostic.c:642
#1 0x103d975c in change_address_1 (memref=0xf7976af0, mode=BLKmode,
addr=0xf7a906e0, validate=)
at ../../gcc/emit-rtl.c:1784
#2 0x103e73f0 in use_anchored_address (x=0xf7976af0) at ../../gcc/explow.c:592
#3 0x10401c68 in expand_expr_real_1 (exp=,
target=, tmode=,
modifier=EXPAND_CONST_ADDRESS, alt_rtl=0x0) at ../../gcc/expr.c:6831
#4 0x88004282 in ?? ()
#5 0x10408970 in expand_expr_real (exp=0xf7f4d000, target=0x0, tmode=SImode,
modifier=EXPAND_CONST_ADDRESS, alt_rtl=0x0) at ../../gcc/expr.c:6638
#6 0x1040e9e4 in expand_expr_addr_expr_1 (exp=0x10849bb8, target=0x0,
tmode=SImode, modifier=EXPAND_NORMAL) at ../../gcc/expr.h:494
#7 0x103ff4f0 in expand_expr_real_1 (exp=, target=0x0,
tmode=, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at ../../gcc/expr.c:6525
#8 0x88004282 in ?? ()
#9 0x10408970 in expand_expr_real (exp=0xf7f78680, target=0x0,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at ../../gcc/expr.c:6638
#10 0x103df6b0 in output_ttype (type=0xf7f78680, tt_format=155,
tt_format_size=4) at ../../gcc/expr.h:500
#11 0x103e3a90 in output_function_exception_table () at ../../gcc/except.c:3787
#12 0x4282 in ?? ()
#13 0x10416158 in rest_of_handle_final () at ../../gcc/final.c:3929
#14 0x105d9a00 in execute_one_pass (pass=0x1098d30c) at ../../gcc/passes.c:864
#15 0x105d9c08 in execute_pass_list (pass=0x1098d30c) at ../../gcc/passes.c:911
#16 0x105d9c20 in execute_pass_list (pass=0x1098de98) at ../../gcc/passes.c:912
#17 0x105d9c20 in execute_pass_list (pass=0x1098de64) at ../../gcc/passes.c:912
#18 0x102da51c in tree_rest_of_compilation (fndecl=0xf7efbb00)
at ../../gcc/tree-optimize.c:418
#19 0x1001d8a4 in gnat_expand_body (gnu_decl=0x10849bb8)
at ../../gcc/ada/misc.c:653
#20 0x1063f8d8 in cgraph_expand_function (node=0xf7f49300)
at ../../gcc/cgraphunit.c:1106
#21 0x10642c4c in cgraph_optimize () at ../../gcc/cgraphunit.c:1171
#22 0x1001e48c in gnat_parse_file (set_yydebug=)
at ../../gcc/ada/misc.c:245
#23 0x1059b724 in toplev_main (argc=,
argv=) at ../../gcc/toplev.c:999
#24 0x102d04d0 in main (argc=277126072, argv=0x6f8) at ../../gcc/main.c:35
(gdb) up
#1 0x103d975c in change_address_1 (memref=0xf7976af0, mode=BLKmode,
addr=0xf7a906e0, validate=)
at ../../gcc/emit-rtl.c:1784
1784gcc_assert (memory_address_p (mode, addr));
(gdb) p addr
$1 = (rtx) 0xf7a906e0
(gdb) pr
(symbol_ref:SI ("*.LANCHOR1") [flags 0x182])
(gdb) up
#2 0x103e73f0 in use_anchored_address (x=0xf7976af0) at ../../gcc/explow.c:592
592 return replace_equiv_address (x, plus_constant (base, offset));
(gdb) p x
$2 = (rtx) 0xf7976af0
(gdb) pr
(mem/s/c:BLK (symbol_ref:SI ("copy_error.1376") [flags 0x82] ) [98 copy_error+0 S24 A32])
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27536
[Bug tree-optimization/27550] New: [4.1 Regression] ICE in coalesce_abnormal_edges
typedef __SIZE_TYPE__ size_t;
struct E
{
virtual ~E () {}
virtual size_t e () const = 0;
virtual void f (char *x) const = 0;
};
struct F : public E
{
virtual ~F () {}
virtual size_t e () const { return 0; }
virtual void f (char *x) const { *x = '\0'; }
};
struct S
{
S () { a = new char[32]; b = 32; c = 0; a[0] = 0; }
void s (const char *x, size_t y) { v (c + y + 1); __builtin_memcpy(a + c, x,
y); c += y; a[c] = '\0'; }
void s (const E *x) { size_t l = x->e(); v (c + l + 1); x->f (a + c); c += l;
}
const char *t () { return a; }
void v (size_t n)
{
if (b >= n) return;
size_t b2 = b;
char *a2 = a;
for (;;)
{
b *= 2;
if (b >= n)
break;
}
a = new char[b];
if (b2)
{
__builtin_memcpy(a, a2, c);
a2[0] = 0;
for (size_t i = 1; i < b2; i++)
a2[i] = a2[i - 1];
delete[] a2;
}
}
~S ()
{
if (b)
{
a[0] = 0;
for (size_t i = 1; i < b; i++)
a[i] = a[i - 1];
}
delete[] a;
}
char * a;
size_t b, c;
};
const char *p;
size_t q;
const F u;
const char *
foo ()
{
S s;
s.s (p, q);
s.s (&u);
return s.t ();
}
ICEs at -O{1,2,3} in coalesce_abnormal_edges, at least on x86_64 and i386
linux.
--
Summary: [4.1 Regression] ICE in coalesce_abnormal_edges
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27550
[Bug tree-optimization/27551] New: [4.1 Regression] ICE in coalesce_abnormal_edges
typedef __SIZE_TYPE__ size_t;
struct E
{
virtual ~E () {}
virtual size_t e () const = 0;
virtual void f (char *x) const = 0;
};
struct F : public E
{
virtual ~F () {}
virtual size_t e () const { return 0; }
virtual void f (char *x) const { *x = '\0'; }
};
struct S
{
S () { a = new char[32]; b = 32; c = 0; a[0] = 0; }
void s (const char *x, size_t y) { v (c + y + 1); __builtin_memcpy(a + c, x,
y); c += y; a[c] = '\0'; }
void s (const E *x) { size_t l = x->e(); v (c + l + 1); x->f (a + c); c += l;
}
const char *t () { return a; }
void v (size_t n)
{
if (b >= n) return;
size_t b2 = b;
char *a2 = a;
for (;;)
{
b *= 2;
if (b >= n)
break;
}
a = new char[b];
if (b2)
{
__builtin_memcpy(a, a2, c);
a2[0] = 0;
for (size_t i = 1; i < b2; i++)
a2[i] = a2[i - 1];
delete[] a2;
}
}
~S ()
{
if (b)
{
a[0] = 0;
for (size_t i = 1; i < b; i++)
a[i] = a[i - 1];
}
delete[] a;
}
char * a;
size_t b, c;
};
const char *p;
size_t q;
const F u;
const char *
foo ()
{
S s;
s.s (p, q);
s.s (&u);
return s.t ();
}
ICEs at -O{1,2,3} in coalesce_abnormal_edges, at least on x86_64 and i386
linux.
--
Summary: [4.1 Regression] ICE in coalesce_abnormal_edges
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27551
[Bug tree-optimization/27550] [4.1 Regression] ICE in coalesce_abnormal_edges
--- Comment #1 from jakub at gcc dot gnu dot org 2006-05-11 09:06 --- Oops, sorry. *** This bug has been marked as a duplicate of 27549 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27550
[Bug tree-optimization/27549] [4.1 Regression] ICE in coalesce_abnormal_edges
--- Comment #3 from jakub at gcc dot gnu dot org 2006-05-11 09:06 --- *** Bug 27550 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27549
[Bug tree-optimization/27551] [4.1 Regression] ICE in coalesce_abnormal_edges
--- Comment #1 from jakub at gcc dot gnu dot org 2006-05-11 09:06 --- Oops, sorry. *** This bug has been marked as a duplicate of 27549 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27551
[Bug tree-optimization/27549] [4.1 Regression] ICE in coalesce_abnormal_edges
--- Comment #4 from jakub at gcc dot gnu dot org 2006-05-11 09:06 --- *** Bug 27551 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27549
[Bug tree-optimization/27549] [4.1 Regression] ICE in coalesce_abnormal_edges
--- Comment #5 from jakub at gcc dot gnu dot org 2006-05-11 09:07 --- Yes, PR 27283 patch fixes this. So, we need it on gcc-4_1-branch too... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27549
[Bug tree-optimization/27548] [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-11 09:22 ---
This is a SCCP issue:
--- t.cc.073t.lim 2006-05-11 02:21:50.0 -0700
+++ t.cc.075t.sccp 2006-05-11 02:21:50.0 -0700
@@ -53,8 +53,8 @@ void f(int&) (to_be_zapped)
:;
goto ();
- # i_29 = PHI ;
:;
+ i_29 = NewMins$maxdex_2(ab);
# i_7 = PHI ;
:;
-
Reduced testcase:
void g(void);
struct Array
{
int mindex, maxdex;
int InsertAt (const int & t, int n)
{
int *new_data = new int[++this->maxdex - this->mindex + 1];
int i;
for (i = this->mindex; i <= n - 1; i++)
new_data[i] = 1;
new_data[i] = t;
}
Array (void) : mindex (1) {}
};
int NoIndices(void);
void f (int &to_be_zapped)
{
Array NewMins;
int i;
try
{
for (i = 1; i <= NoIndices (); i++)
NewMins.InsertAt (to_be_zapped, NewMins.maxdex);
}catch(...) {}
if (NewMins.maxdex >= 1)
g();
}
--
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-05-11 09:22:21
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27548
[Bug tree-optimization/27548] [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-11 09:23 --- Oh, note with my reduced testcase you have to compile with -fno-ivopts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27548
[Bug fortran/25090] Bad automatic character length
--- Comment #1 from paul dot richard dot thomas at cea dot fr 2006-05-11
10:22 ---
The following patch fixes this bug. It makes use of existing calls to
gfc_resolve_expr, whilst resolving specification expressions, to check that
variables used are parameters of each and every entry. Since existing code is
recycled and the test in gfc_resolve_epr is pretty exclusive, the load on
resolution is negligible.
I will submit asap.
Paul
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (révision 113111)
+++ gcc/fortran/resolve.c (copie de travail)
@@ -60,6 +60,9 @@
resets the flag each time that it is read. */
static int formal_arg_flag = 0;
+/* True if we are resolving a specification expression. */
+static int resolving_index_expr = 0;
+
int
gfc_is_formal_arg (void)
{
@@ -2623,6 +2639,50 @@
}
+/* Emits an error if the expression is a variable that is
+ not a parameter in all entry formal argument lists for
+ the namespace. */
+
+static void
+entry_parameter (gfc_expr *e)
+{
+ gfc_symbol *sym, *esym;
+ gfc_entry_list *entry;
+ gfc_formal_arglist *f;
+ bool p;
+
+ if (e->expr_type != EXPR_VARIABLE)
+return;
+
+ sym = e->symtree->n.sym;
+ if (sym->ns->entries
+ && !sym->attr.use_assoc
+ && sym->attr.dummy
+ && sym->ns == gfc_current_ns)
+{
+ entry = sym->ns->entries;
+ for (; entry; entry = entry->next)
+ {
+ esym = entry->sym;
+ p = false;
+ f = esym->formal;
+ for (; f && !p; f = f->next)
+ {
+ if (f->sym && f->sym->name
+ && sym->name == f->sym->name)
+ {
+ p = true;
+ }
+ }
+ if (!p)
+ gfc_error ("%s at %L must be a parameter of the entry at %L",
+ sym->name, &e->where, &esym->declared_at);
+ }
+}
+ return;
+}
+
+
/* Resolve an expression. That is, make sure that types of operands agree
with their operators, intrinsic operators are converted to function calls
for overloaded types and unresolved function references are resolved. */
@@ -2647,6 +2707,10 @@
case EXPR_VARIABLE:
t = resolve_variable (e);
+
+ if (gfc_current_ns->entries && resolving_index_expr)
+ entry_parameter (e);
+
if (t == SUCCESS)
expression_rank (e);
break;
@@ -4597,7 +4661,6 @@
static try
resolve_index_expr (gfc_expr * e)
{
-
if (gfc_resolve_expr (e) == FAILURE)
return FAILURE;
@@ -4620,9 +4683,12 @@
cl->resolved = 1;
+ resolving_index_expr = 1;
+
if (resolve_index_expr (cl->length) == FAILURE)
return FAILURE;
+ resolving_index_expr = 0;
return SUCCESS;
}
@@ -4709,20 +4775,29 @@
if (resolve_fl_var_and_proc (sym, mp_flag) == FAILURE)
return FAILURE;
- /* The shape of a main program or module array needs to be constant. */
- if (sym->ns->proc_name
- && (sym->ns->proc_name->attr.flavor == FL_MODULE
-|| sym->ns->proc_name->attr.is_main_program)
- && !sym->attr.use_assoc
+ /* Set this flag to check that variables are parameters of all entries.
+ This check is effected by the call to gfc_resolve_expr through
+ is_non_contant_shape_array. */
+ resolving_index_expr = 1;
+
+ if (!sym->attr.use_assoc
&& !sym->attr.allocatable
&& !sym->attr.pointer
&& is_non_constant_shape_array (sym))
{
- gfc_error ("The module or main program array '%s' at %L must "
-"have constant shape", sym->name, &sym->declared_at);
- return FAILURE;
+ /* The shape of a main program or module array needs to be constant.
*/
+ if (sym->ns->proc_name
+ && (sym->ns->proc_name->attr.flavor == FL_MODULE
+ || sym->ns->proc_name->attr.is_main_program))
+ {
+ gfc_error ("The module or main program array '%s' at %L must "
+ "have constant shape", sym->name, &sym->declared_at);
+ return FAILURE;
+ }
}
+ resolving_index_expr = 0;
+
if (sym->ts.type == BT_CHARACTER)
{
/* Make sure that character string variables with assumed length are
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25090
[Bug tree-optimization/27548] [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-05-11 09:22:21 |2006-05-11 10:56:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27548
[Bug c++/26757] [4.1/4.2 regression] C++ front-end producing two DECLs with the same UID
--- Comment #19 from tbm at cyrius dot com 2006-05-11 11:03 --- (In reply to comment #17) > Created an attachment (id=11336) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11336&action=view) [edit] > Possible patch > > Maybe. there is a work around I have an initial patch for. It re-covers up > the problem I think :-) Andrew, what's the status of this patch? -- tbm at cyrius dot com changed: What|Removed |Added CC||tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757
[Bug c++/26755] [4.0 regression] may fail to generate code for base destructor defined inline with pragma interface
--- Comment #9 from tbm at cyrius dot com 2006-05-11 11:05 --- (In reply to comment #8) > 4.1.0 is correct as it is the same as 3.4.x. 4.0.x is incorrect and does not > correspond to 3.4.x. So this is a bug in 4.0.x and not in 4.1.0. > > Confirmed. Thanks for the short testcase. Do you think this will be fixed in 4.0.x? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26755
[Bug fortran/27552] New: -fdump-parse-tree doesn't like Holleriths (but then, who does?)
The following testcases encounter an ICE when compiled with -fdump-parse-tree: hollerith2.f90, hollerith4.f90, hollerith_f95.f90 and hollerith_legacy.f90 (in the gfortran.dg testsuite directory) (I've been compiling the whole testsuite with -fdump-parse-tree to isolate potential problems with -fdump-parse-tree, as a consequence of PR 27320). -- Summary: -fdump-parse-tree doesn't like Holleriths (but then, who does?) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran 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=27552
[Bug fortran/27553] New: Testsuite ICE with -Wall
label_2.f90, from the testsuite, encounters an ICE when compiled with -Wall:
$ cat src/label_2.f90
! { dg-do compile }
! PR fortran/24640. We needed to check that whitespace follows
! a statement label in free form.
!
program pr24640
10: a=10 ! { dg-error "character in statement" }
end program
$ gfortran -c src/label_2.f90 -Wall
In file src/label_2.f90:7
10: a=10 ! { dg-error "character in statement" }
1
Error: Non-numeric character in statement label at (1)
src/label_2.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.
--
Summary: Testsuite ICE with -Wall
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: fortran
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=27553
[Bug fortran/25392] ICEs with -ff2c
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-11 11:36 --- File entry-4.f90 from the gfortran testsuite also ICEs with -ff2c: $ gfortran -c entry_4.f90 -ff2c src/entry_4.f90: In function f2: src/entry_4.f90:12: internal compiler error: in make_decl_rtl, at varasm.c:1002 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2006-01-27 20:44:10 |2006-05-11 11:36:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25392
Bug in gfortran libraries statically linked in Linux
I found an other bug in gfortran now for the Linux distribution only. You must be able to link the gfortran libraries static or linked. For the linked *.so no problem For the static *.a it did not work and at the compilation time. To force the linker to compile the gfortran libraries static and not linked, you change the name of the *.so libraries and do not touch the *.a libraries. The -static does not work because now, all the libraries must be static, and it did not work with libX11.a, the same problem so I use this patch : rename the *.so gfortran files such as to only have static gfortran files and the others linked. My program is a mix gfortran and C. You can load the files on my site if necessary : http://perso.wanadoo.fr/claude.gerdy on : download->Linux->new->install.zip If I use the Intel compiler (freeware with Linux) Fortran95 ifort and C icc with the command -i-static which make an exec files with the intel libraries only static it works but not with -static because problem with libX11.a. I have not this problem with Windows because all the libraries are static with no choice. So if you distribute exec files, they must be statically linked with the fortran libraries, with Linux I use the Intel compiler on my site and gfortran with Windows. All my readers have not the gfortran libraries on there Linux system, so static link is vital for my site.
[Bug fortran/27554] New: Strange assembler produced
Humpf, that one is scary... can't even think of what to put as a Summary :) $ cat abs_complex.f90 real x x = abs(x) call foo(abs) end $ ./bin/gfortran abs_complex.f90 -c /tmp/ccdGqqDj.s: Assembler messages: /tmp/ccdGqqDj.s:14: Error: junk `(intrinsic)__abs' after expression Indeed, the assembler produced on i686-linux is not very nice; note the "movl $__(intrinsic)__abs, (%esp)" line: .file "abs_complex.f90" .text .globl MAIN__ .type MAIN__, @function MAIN__: pushl %ebp movl%esp, %ebp subl$40, %esp movl$0, 8(%esp) movl$127, 4(%esp) movl$70, (%esp) call_gfortran_set_std andb$127, -1(%ebp) movl$__(intrinsic)__abs, (%esp) callfoo_ leave ret .size MAIN__, .-MAIN__ .ident "GCC: (GNU) 4.2.0 20060510 (experimental)" .section.note.GNU-stack,"",@progbits -- Summary: Strange assembler produced Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran 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=27554
[Bug fortran/25082] Subroutine with RETURN value, ICE in gfc_conv_scalarized_array_ref
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-05-11
14:02 ---
The patch is simple:
12.5.2.6 RETURN statement
R1226 return-stmt is RETURN [ scalar-int-expr ]
The int-expr part is implemented in resolve.c(resolve_code); a further
condition has been imposed to implement scalar-int-expr.
Paul
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (r├®vision 113694)
+++ gcc/fortran/resolve.c (copie de travail)
@@ -4345,9 +4345,10 @@
break;
case EXEC_RETURN:
- if (code->expr != NULL && code->expr->ts.type != BT_INTEGER)
- gfc_error ("Alternate RETURN statement at %L requires an INTEGER "
- "return specifier", &code->expr->where);
+ if (code->expr != NULL
+ && (code->expr->ts.type != BT_INTEGER || code->expr->rank))
+ gfc_error ("Alternate RETURN statement at %L requires an SCALAR-"
+ "INTEGER return specifier", &code->expr->where);
break;
case EXEC_ASSIGN:
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25082
[Bug target/27158] [4.1/4.2 regression] ICE in extract_insn with -maltivec
--- Comment #16 from sayle at gcc dot gnu dot org 2006-05-11 14:17 --- Subject: Bug 27158 Author: sayle Date: Thu May 11 14:17:19 2006 New Revision: 113695 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113695 Log: PR target/27158 * reload.c (find_reloads_toplev): Only return the simplified SUBREG of a reg_equiv_constant if the result is a legitimate constant. * gcc.target/powerpc/pr27158.c: New test case. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.target/powerpc/pr27158.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/reload.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27158
[Bug tree-optimization/27003] [4.0 Regression] ivcanon bug
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-05-11 14:19 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00463.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||05/msg00463.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27003
[Bug c/27556] New: Wrong code generation when cross compile for attiny2313
I found a bug in gcc compiler. I'm trying to cross compile simple program using
debian package avr-gcc (gcc version 4.1.0) using command
avr-gcc -mmcu=attiny2313 -Wall -Os -c test.c
I have problem with very simple code when using array bigger than 128 bytes.
char text[] = "AB... YZ"; // 128 characters
char *pointer = text;
while (*pointer) {
UDR = *pointer;
while ( !(UCSRA & (1< ldi r24,lo8(-128)
There is no other code working with the higher byte.
r* registers are just 8bit so it can't work at all.
--
Summary: Wrong code generation when cross compile for attiny2313
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: p dot mateja at sh dot cvut dot cz
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: attiny2313
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27556
[Bug c++/27547] [4.0/4.1/4.2 regression] ICE on invalid operator=
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-05-11 14:41 --- Subject: Bug 27547 Author: reichelt Date: Thu May 11 14:41:03 2006 New Revision: 113696 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113696 Log: PR c++/27547 * decl.c (copy_fn_p): Return early on non-member functions. * g++.dg/other/operator1.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/operator1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27547
[Bug c++/27557] New: OpenMP threadprivate directive does not work with non-POD types
Compiling the fragment
struct A {
A() {}
};
extern A a;
#pragma omp threadprivate(a)
A a;
with svn from yesterday yields
LANG=C g++-4.2 -fopenmp -c x.cpp -o x.o
x.cpp:6: error: 'a' cannot be thread-local because it has non-POD type 'A'
x.cpp:6: error: 'a' is thread-local and so cannot be dynamically initialized
It works if I remove the definition of a (last line).
I could not find anything in the OpenMP spec (version 2.5) stating that non-POD
threadprivate variables are not allowed. If I change the above to
struct A {
A() {}
};
A a;
#pragma omp threadprivate(a)
I get
LANG=C g++-4.2 -fopenmp -c x.cpp -o x.o
x.cpp:5: error: 'a' declared 'threadprivate' after first use
I believe that both variants are allowed by the OpenMP spec (version 2.5) and
they compile fine with icc 8.1. The spec says something about non-POD
variaables with explicit initializers in section 2.8.2 on page 69, but that
does not apply here. Please correct me if I am wrong.
--
Summary: OpenMP threadprivate directive does not work with non-
POD types
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Georg dot Baum at post dot rwth-aachen dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557
[Bug c++/27547] [4.0/4.1/4.2 regression] ICE on invalid operator=
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-05-11 14:46 --- Subject: Bug 27547 Author: reichelt Date: Thu May 11 14:45:56 2006 New Revision: 113697 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113697 Log: PR c++/27547 * decl.c (copy_fn_p): Return early on non-member functions. * g++.dg/other/operator1.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/operator1.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27547
[Bug c/27558] New: Wrong type in warning
Compiling this code:
#include
void f(char* line) {
char test_char[40];
sscanf(line, "%s", &test_char);
}
gives the following warning:
warning: format '%s' expects type 'char *', but argument 3 has type 'char
(*)[39u]'
I'd have though that &test_char had type char (*)[40].
--
Summary: Wrong type in warning
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jm at bourguet dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27558
[Bug c++/27547] [4.0/4.1/4.2 regression] ICE on invalid operator=
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-11 14:49 --- Subject: Bug 27547 Author: reichelt Date: Thu May 11 14:49:17 2006 New Revision: 113698 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113698 Log: PR c++/27547 * decl.c (copy_fn_p): Return early on non-member functions. * g++.dg/other/operator1.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/other/operator1.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/decl.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27547
[Bug c++/27547] [4.0/4.1/4.2 regression] ICE on invalid operator=
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-05-11 14:53 --- Fixed on mainline, 4.1 branch, and 4.0 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27547
[Bug middle-end/27488] [4.1/4.2 regression] ICE in tree_expr_nonnegative_p
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-11 14:59 --- Subject: Bug 27488 Author: reichelt Date: Thu May 11 14:58:54 2006 New Revision: 113699 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113699 Log: PR middle-end/27488 * fold-const.c (tree_expr_nonnegative_p): Return early on invalid expression. * gcc.dg/fold-nonneg-1.c: New test. Added: trunk/gcc/testsuite/gcc.dg/fold-nonneg-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27488
[Bug middle-end/27488] [4.1/4.2 regression] ICE in tree_expr_nonnegative_p
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-05-11 15:01 --- Subject: Bug 27488 Author: reichelt Date: Thu May 11 15:01:40 2006 New Revision: 113700 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113700 Log: PR middle-end/27488 * fold-const.c (tree_expr_nonnegative_p): Return early on invalid expression. * gcc.dg/fold-nonneg-1.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/fold-nonneg-1.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/fold-const.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27488
[Bug middle-end/27488] [4.1/4.2 regression] ICE in tree_expr_nonnegative_p
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-05-11 15:02 --- Fixed on mainline and 4.1 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27488
[Bug c/27556] Wrong code generation when cross compile for attiny2313
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-11 15:07 --- That's not a complete testcase, which we need to reproduce/fix the bug. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27556
[Bug c++/27384] [4.0/4.1/4.2 regression] ICE with invalid array size
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-11 15:08 --- Subject: Bug 27384 Author: reichelt Date: Thu May 11 15:07:45 2006 New Revision: 113701 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113701 Log: PR middle-end/27384 * fold-const.c (size_binop): Move sanity check for arguments to the beginning of the function. * g++.dg/other/fold1.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/fold1.C Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27384
[Bug c++/27384] [4.0/4.1/4.2 regression] ICE with invalid array size
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-05-11 15:12 --- Subject: Bug 27384 Author: reichelt Date: Thu May 11 15:11:50 2006 New Revision: 113702 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113702 Log: PR middle-end/27384 * fold-const.c (size_binop): Move sanity check for arguments to the beginning of the function. * g++.dg/other/fold1.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/fold1.C Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/fold-const.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27384
[Bug middle-end/27536] [4.2 Regression] -fsection-anchors breaks Ada
--- Comment #4 from dje at gcc dot gnu dot org 2006-05-11 15:13 --- It looks like something in exception handling is creating a new object very late, after reload, and the new address is not validized before being handed to replace_equiv_address(). Should explow.c:use_anchored_address() add if (reload_in_progress || reload_completed) return x; Either the block should not be created so late or it should be validized. Although, I am curious how this works in expand_expr_real_1 when section anchors is not enabled. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||richard at codesourcery dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27536
[Bug c++/27384] [4.0/4.1/4.2 regression] ICE with invalid array size
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-05-11 15:17 --- Subject: Bug 27384 Author: reichelt Date: Thu May 11 15:16:49 2006 New Revision: 113703 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113703 Log: PR middle-end/27384 * fold-const.c (size_binop): Move sanity check for arguments to the beginning of the function. * g++.dg/other/fold1.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/other/fold1.C Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/fold-const.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27384
[Bug c++/27384] [4.0/4.1/4.2 regression] ICE with invalid array size
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-05-11 15:17 --- Fixed on mainline, 4.1 branch, and 4.0 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27384
[Bug c++/27559] New: [4.2 regression] ICE on templated operator new
The following testcase ICEs on mainline:
===
struct A
{
template
static void* operator new(T) {}
};
===
bug.cc:4: error: 'operator new' takes type 'size_t' ('long unsigned int') as
first parameter
bug.cc:4: error: invalid template declaration of 'static void* A::operator
new(long unsigned int)'
bug.cc:4: error: invalid member template declaration 'static void* A::operator
new(long unsigned int)'
bug.cc: In static member function 'static void* A::operator new(long unsigned
int)':
bug.cc:4: internal compiler error: in dependent_type_p, at cp/pt.c:12383
Please submit a full bug report, [etc.]
--
Summary: [4.2 regression] ICE on templated operator new
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27559
[Bug c++/27559] [4.2 regression] ICE on templated operator new
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-05-11 15:35 --- Testing a patch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org Severity|normal |minor Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27559
[Bug c++/27560] New: template function not recognized when invoked with enum defined in function
Compiling this file, with mainline, gcc 4.0, or 4.1
template void f(t a) { }
void g() { enum e { v }; f(v); }
gives this error message:
foo.cc: In function void g():
foo.cc:2: error: no matching function for call to f(g()::e)
If the enum definition is moved out of the function, this works. With gcc 3.2,
this works. I didn't try 3.4.
My C++ fu is weak, and I do not know for sure that this is valid C++, although
I don't see anything wrong with it. But either 1) it is valid and gcc should
accept it, or 2) gcc should provide a list of candidates which did not match,
since there is manifestly a function named 'f'.
--
Summary: template function not recognized when invoked with enum
defined in function
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27560
[Bug fortran/18315] missing error for incompatible array assignment involving lbound
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-05-11 15:54 --- > I think what is happening is that lbound's type is becoming a scalar and not > > an array with size of 1. I believe that I fixed this with either the bounds scalarization patch or some of the work on conformance or both. Will close tonight. Paul Note the following: [EMAIL PROTECTED] /cygdrive/d/svn/prs $ cat pr18315.f90;rm a.exe;/irun/bin/gfortran pr18315.f90;./a program main implicit none real :: a(0:9) integer :: bn(10) bn(1:1) = lbound(a) print *, bn(1) end program main 0 [EMAIL PROTECTED] /cygdrive/d/svn/prs $ cat pr18315.f90;rm a.exe;/irun/bin/gfortran pr18315.f90;./a program main implicit none real :: a(0:9) integer :: bn(10) bn = lbound(a) print *, bn(1) end program main In file pr18315.f90:5 bn = lbound(a) 1 Error: different shape for Array assignment at (1) on dimension 1 (10/1) bash: ./a: No such file or directory [EMAIL PROTECTED] /cygdrive/d/svn/prs $ cat pr18315.f90;rm a.exe;/irun/bin/gfortran pr18315.f90;./a program main implicit none real :: a(0:9) integer :: bn(10) bn(1) = lbound(a) print *, bn(1) end program main rm: cannot remove `a.exe': No such file or directory In file pr18315.f90:5 bn(1) = lbound(a) 1 Error: Incompatible ranks 0 and 1 in assignment at (1) bash: ./a: No such file or directory -- paul dot richard dot thomas at cea dot fr changed: What|Removed |Added CC||paul dot richard dot thomas ||at cea dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18315
[Bug c/27558] Wrong type in warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-11 15:55 --- I cannot reproduce this in "4.1.0 20060208" or "4.2.0 20060507". t.c:5: warning: format '%s' expects type 'char *', but argument 3 has type 'char (*)[40]' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27558
[Bug middle-end/27536] [4.2 Regression] -fsection-anchors breaks Ada
--- Comment #5 from richard at codesourcery dot com 2006-05-11 15:56 --- Subject: Re: [4.2 Regression] -fsection-anchors breaks Ada "dje at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: > It looks like something in exception handling is creating a new object > very late, after reload, and the new address is not validized before > being handed to replace_equiv_address(). > > Should explow.c:use_anchored_address() add > > if (reload_in_progress || reload_completed) > return x; > > Either the block should not be created so late or it should be validized. > Although, I am curious how this works in expand_expr_real_1 when section > anchors is not enabled. I find this a little surprising too. Could someone do: call debug_tree (...) on the type that output_ttype is trying to expand? Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27536
[Bug c++/27560] template function not recognized when invoked with enum defined in function
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-11 15:58 --- This is not valid, the type is a local type which causes it be rejected for templates. The same happens with local classes. -- 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=27560
[Bug c++/27560] template function not recognized when invoked with enum defined in function
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-11 16:07 --- 14.3.1/2 A local type, a type with no linkage, an unnamed type or a type compounded from any of these types shall not be used as atemplate-argument for a template type-parameter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27560
[Bug middle-end/27536] [4.2 Regression] -fsection-anchors breaks Ada
--- Comment #6 from schwab at suse dot de 2006-05-11 16:08 ---
unit size
align 32 symtab -135699664 alias set 98 fields Ada size
pointer_to_this chain >
sizes-gimplified unsigned SI
size
unit size
user align 32 symtab 0 alias set -1>
constant invariant
arg 0
addressable used static BLK file g-os_lib.adb line 296 size
unit size
align 32 context
initial
(mem/s/c:BLK (symbol_ref:SI ("copy_error.1376") [flags 0x82] ) [98 copy_error+0 S24 A32])
chain
ignored VOID file g-os_lib.adb line 296
align 1 context
chain >>>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27536
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #28 from perry at kundert dot ca 2006-05-11 16:12 ---
This test case *still* exhibits the failure using only g++ 3.3.6, and binutils
2.16.1:
[EMAIL PROTECTED]:binutils-bug$ apt-show-versions g++-3.3
g++-3.3/testing uptodate 1:3.3.6-13
[EMAIL PROTECTED]:binutils-bug$ apt-show-versions binutils
binutils/testing uptodate 2.16.1cvs20060413-1
[EMAIL PROTECTED]:binutils-bug$ cat GNUmakefile
all: main
clean:
rm *.o
lib1.o: lib1.C
lib2.o: lib2.C
main: main.C lib1.o lib2.o
[EMAIL PROTECTED]:binutils-bug$ make clean all
rm *.o
g++-c -o lib1.o lib1.C
g++-c -o lib2.o lib2.C
g++ main.C lib1.o lib2.o -o main
`.gnu.linkonce.t._ZN3Foo1fEi' referenced in section `.rodata' of lib2.o:
defined in discarded section `.gnu.linkonce.t._ZN3Foo1fEi' of lib2.o
collect2: ld returned 1 exit status
make: *** [main] Error 1
[EMAIL PROTECTED]:binutils-bug$
(In reply to comment #27)
> Here's a relatively simple test case, in case anyone wants one, that
> reproduces
> either this problem, or a very similar one. It requires a mix of compilers,
> and of optimization selections, to reproduce, though. One gcc 3 compiler and
> one gcc 4 one should do it.
>
>
> $ cat foo.h
> class Foo {
> public:
> virtual ~Foo() {}
> virtual inline int f(int x) {
> switch (x) {
> case 0: return 0; break;
> case 1: return 1; break;
> case 2: return 2; break;// cases 0 to 2 bulk out the switch
> statement
>
> case 3: return 999; break; // cases 3 and 4 can be coalesced
> case 4: return 999; break;
> }
> return -1;
> }
> };
>
> extern int g(int);
> extern int h();
>
> $ cat lib1.cc
> #include "foo.h"
>
> int g(int i) {
> Foo f;
> return f.f(i);
> }
>
> $ cat lib2.cc
> #include "foo.h"
>
> int h() {
> Foo f;
> return f.f(0) + g(0);
> }
>
> $ cat main.cc
> #include "foo.h"
>
> int main() {
> return g(0) + h();
> }
>
> $ ./g++-3.4.5 -Wall -W -pedantic -O2 -c lib1.cc
> $ ./g++-3.4.5 -Wall -W -pedantic -O0 -c lib2.cc
> $ ./g++-4.1.0 -Wall -W -pedantic -o main lib1.o lib2.o main.cc
> /path/to/i686-unknown-linux-gnu/bin/ld: `.gnu.linkonce.t._ZN3Foo1fEi'
> referenced in section `.rodata' of lib2.o: defined in discarded section
> `.gnu.linkonce.t._ZN3Foo1fEi' of lib2.o
> ... and so on
>
> In this case, the ld in gcc 4.1 is version 2.16.1.
>
--
perry at kundert dot ca changed:
What|Removed |Added
CC||perry at kundert dot ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #29 from pinskia at gcc dot gnu dot org 2006-05-11 16:16 --- (In reply to comment #28) > This test case *still* exhibits the failure using only g++ 3.3.6, and binutils > 2.16.1: Well 3.3.x is no longer being updated (likewise for 3.4.x). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug middle-end/27536] [4.2 Regression] -fsection-anchors breaks Ada
--- Comment #7 from richard at codesourcery dot com 2006-05-11 16:18 --- Subject: Re: [4.2 Regression] -fsection-anchors breaks Ada Thanks Andreas. I might be barking up the wrong tree here, but it seems odd to me is that output_ttype is using expand_normal () to expand this tree. That in general allows arbitrary code to be generated. output_ttype does seem to want an assembly constant. Shouldn't it be using EXPAND_INITIALIZER instead? Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27536
[Bug target/27158] [4.1/4.2 regression] ICE in extract_insn with -maltivec
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-05-11 16:19 --- Fixed. -- 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=27158
[Bug c++/27560] template function not recognized when invoked with enum defined in function
--- Comment #3 from gdr at integrable-solutions dot net 2006-05-11 16:24
---
Subject: Re: New: template function not recognized when invoked with enum
defined in function
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| Compiling this file, with mainline, gcc 4.0, or 4.1
|
| template void f(t a) { }
| void g() { enum e { v }; f(v); }
|
| gives this error message:
|
| foo.cc: In function Âvoid g()Â:
| foo.cc:2: error: no matching function for call to Âf(g()::e)Â
|
| If the enum definition is moved out of the function, this works. With gcc
3.2,
| this works. I didn't try 3.4.
There is a core issue for this. We discussed it again at the last
meeting in Berlin. There are proposals to make it "just work", but
that is still in the open state.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27560
[Bug target/27421] [4.0/4.1 regression] ICE with invalid array in struct
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-05-11 16:32 --- Subject: Bug 27421 Author: reichelt Date: Thu May 11 16:32:20 2006 New Revision: 113705 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113705 Log: PR target/27421 * config/i386/i386.c (classify_argument): Skip fields with invalid types. * gcc.dg/array-9.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/array-9.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/i386/i386.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27421
[Bug c++/27560] template function not recognized when invoked with enum defined in function
--- Comment #4 from gdr at gcc dot gnu dot org 2006-05-11 16:33 --- See http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#488 http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1945.pdf The later paper is under active consideration. The PR should be suspended, instead of being hastly closed. -- gdr at gcc dot gnu dot org changed: What|Removed |Added CC||gdr at gcc dot gnu dot org Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27560
[Bug target/27421] [4.0/4.1 regression] ICE with invalid array in struct
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-05-11 16:34 --- Subject: Bug 27421 Author: reichelt Date: Thu May 11 16:34:39 2006 New Revision: 113706 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113706 Log: PR target/27421 * config/i386/i386.c (classify_argument): Skip fields with invalid types. * gcc.dg/array-9.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/array-9.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/i386/i386.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27421
[Bug target/27421] [4.0/4.1 regression] ICE with invalid array in struct
--- Comment #10 from reichelt at gcc dot gnu dot org 2006-05-11 16:35 --- Now also fixed on 4.1 branch and 4.0 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27421
[Bug c++/27560] template function not recognized when invoked with enum defined in function
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-11 16:38 --- (In reply to comment #4) > The PR should be suspended, instead of being hastly closed. It was not hastly closed, the current standard says this is invalid. Anyways there is already a PR open about DR 488. *** This bug has been marked as a duplicate of 20589 *** -- 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=27560
[Bug c++/20589] [DR 488] error: '' is/uses anonymous type'
--- Comment #21 from pinskia at gcc dot gnu dot org 2006-05-11 16:38 --- *** Bug 27560 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
[Bug c++/27560] template function not recognized when invoked with enum defined in function
--- Comment #6 from gdr at integrable-solutions dot net 2006-05-11 16:47 --- Subject: Re: template function not recognized when invoked with enum defined in function "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | It was not hastly closed, the current standard says this is invalid. and the current standard is known to be defective in that aspect, which is why we had the core issue in the first place. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27560
[Bug libobjc/13946] ObjC configured --with-objc-gc needs external Boehm gc
--- Comment #6 from halcy0n at gentoo dot org 2006-05-11 17:01 --- You can't build with objc-gc at all right now since only half of these patches were applied. It tries to use the internal boehm-gc, but that hasn't been built yet since the patch in the first email was never applied. After adding these, everything works perfectly. -- halcy0n at gentoo dot org changed: What|Removed |Added CC||toolchain at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13946
[Bug fortran/27552] -fdump-parse-tree doesn't like Holleriths (but then, who does?)
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-11 17:08
---
I think this is taken care of by the following patch:
Index: dump-parse-tree.c
===
--- dump-parse-tree.c (revision 113671)
+++ dump-parse-tree.c (working copy)
@@ -348,6 +348,13 @@
break;
case EXPR_CONSTANT:
+ if (p->from_H)
+{
+ gfc_status ("%dH", p->value.character.length);
+ gfc_status ("%s", p->value.character.string);
+ break;
+ }
+
switch (p->ts.type)
{
case BT_INTEGER:
--
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
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Keywords||patch
Known to fail||4.1.1 4.2.0
Last reconfirmed|-00-00 00:00:00 |2006-05-11 17:08:22
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27552
[Bug fortran/27561] New: i386-pc-mingw32 version incorrect error
The i386-pc-mingw32 version errors incorrectly on this program fragment - [EMAIL PROTECTED] /d/Docume~1/rantad/mydocu~1/tests $ gfortran -c eps.f90 In file eps.f90:10 xmax1 = min ( xx, ONE / epsilon ( xx ) ) 1 Error: Division by zero at (1) [EMAIL PROTECTED] /d/Docume~1/rantad/mydocu~1/tests $ cat eps.f90 module test implicit none integer, parameter :: REAL8 = SELECTED_REAL_KIND(12) real(REAL8), parameter :: ONE = 1.0_REAL8 contains real(REAL8) function digamma (xx) real(REAL8), intent(in) :: xx real(REAL8) :: xmax1 xmax1 = min ( xx, ONE / epsilon ( xx ) ) digamma=xmax1; end function digamma end module test [EMAIL PROTECTED] /d/Docume~1/rantad/mydocu~1/tests $ gfortran --v Using built-in specs. Target: i386-pc-mingw32 Configured with: ../gcc/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads=win32 --with-win32-nlsapi=unicode --host=i386-pc-mingw32 Thread model: win32 gcc version 4.2.0 20060504 (experimental) -- Summary: i386-pc-mingw32 version incorrect error Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov GCC host triplet: i386-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27561
[Bug target/26600] [4.1/4.2 Regression] internal compiler error: in push_reload, at reload.c:1303
--- Comment #8 from roger at eyesopen dot com 2006-05-11 17:22 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00472.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26600
[Bug java/20418] ICE if variable name is ommitted in an initialiser and a qualified type for the variable is used
--- Comment #2 from daney at gcc dot gnu dot org 2006-05-11 17:54 --- Test case committed as: * testsuite/libjava.compile/PR20418.java: New. * testsuite/libjava.compile/PR20418.xfail: New. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20418
[Bug testsuite/24128] ICE in libjava.compile/PR6865.java reported as "PASS" in testsuite.
--- Comment #1 from daney at gcc dot gnu dot org 2006-05-11 17:55 --- New testcase for this problme is testsuite/libjava.compile/PR20418.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24128
[Bug c/27562] New: SSE instruction selection wrong for Athlon processors.
GCC provides the programmer the ability to use SIMD instructions by primitives. These are defined in header files. Unfortunately, GCC follows Intel compiler conventions. But these conventions, dictated by Intel interests, not always reflect correctly the reality, specially of AMD processors. According to these conventions, there are four levels of SIMD instructions: Pentium MMX: MMX instructions. Pentium III and higher: MMX + SSE single precission floating point instructions. Pentium IV and higher: MMX + SSE single precission + SSE2 integer and double precission Newer Pentium IV: MMX + SSE + SSE2 + SSE3 This model does not reflect correctly AMD Atlon processors, that support SSE integer SIMD instructions but do not support SSE2 double precission instructions. While it is natural that Intel compiler is aligned with the company's interests, it is not acceptable that a vendor neutral free software project follows them. Thus it is necessary to add a new level that includes integer SSE instructions without including double precission SIMD instructions. What I request is: - A flag to support Athlon SSE set of instructions. As it is in the middle of SSE and SSE2 it might be called SSE1.5, with the option -msse1.5. - A header file that defines SSE integer instructions without define SSE double precission instructions. Since GCC already ships xmmintrin.h, a new header file immintrin.h could be added. This second part is trivial to do and in my opinion should be included in GCC 4.1.1. Both changes are backward compatible. -- Summary: SSE instruction selection wrong for Athlon processors. Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ramsgar-gccbug at yahoo dot com GCC target triplet: i586-anyone-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27562
[Bug target/27562] SSE instruction selection wrong for Athlon processors.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-11 18:37 --- Which Athlon processor, there are so many and some support full SSE2 also (K8). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target GCC target triplet|i586-anyone-linux |i?86-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27562
[Bug target/27562] SSE instruction selection wrong for Athlon processors.
--- Comment #2 from ramon dot garcia dot f+gcc at gmail dot com 2006-05-11 18:42 --- That is correct. However for those developerers that want to target the existing installed base of Pentium IV and Athlon processors, a set of flags and headers that provide the common subset of them is useful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27562
[Bug target/27538] execute/20030128-1.c FAILs
--- Comment #1 from kazu at gcc dot gnu dot org 2006-05-11 18:44 ---
Just for a reference, here is execute/20030128-1.c.
unsigned char x = 50;
volatile short y = -5;
int main ()
{
x /= y;
if (x != (unsigned char) -10)
abort ();
exit (0);
}
Now, with -O1, the load of y completely disappears.
Here is the dump of 20030128-1.c.160r.shorten up to a call to
a division subroutine.
(insn/f 55 8 56 (parallel [
(set (mem/c:BLK (pre_dec:BLK (reg/f:SI 13 sp)) [0 A8])
(unspec:BLK [
(reg:SI 4 r4)
] 2))
(use (reg:SI 14 lr))
]) 302 {*push_multi} (nil)
(expr_list:REG_DEAD (reg:SI 14 lr)
(expr_list:REG_DEAD (reg:SI 4 r4)
(expr_list:REG_FRAME_RELATED_EXPR (sequence [
(set/f (reg/f:SI 13 sp)
(plus:SI (reg/f:SI 13 sp)
(const_int -8 [0xfff8])))
(set/f (mem/c:SI (reg/f:SI 13 sp) [0 S4 A32])
(reg:SI 4 r4))
(set/f (mem/c:SI (plus:SI (reg/f:SI 13 sp)
(const_int 4 [0x4])) [0 S4 A32])
(reg:SI 14 lr))
])
(nil)
(note 56 55 10 NOTE_INSN_PROLOGUE_END)
(note 10 56 11 NOTE_INSN_DELETED)
(note 11 10 13 NOTE_INSN_DELETED)
(note 13 11 14 NOTE_INSN_DELETED)
(note 14 13 15 NOTE_INSN_DELETED)
(insn 15 14 16 (set (reg/f:SI 4 r4 [108])
(mem:SI (label_ref 59) [0 S4 A32])) 145 {*arm_movsi_insn} (nil)
(expr_list:REG_EQUIV (symbol_ref:SI ("x") [flags 0x2] )
(nil)))
(note 16 15 17 NOTE_INSN_DELETED)
(note 17 16 18 NOTE_INSN_DELETED)
(note 18 17 19 NOTE_INSN_DELETED)
(insn 19 18 20 (set (reg:SI 0 r0 [ x ])
(zero_extend:SI (mem/c/i:QI (reg/f:SI 4 r4 [108]) [0 x+0 S1 A8]))) 128
{*arm_zero_extendqis\i2} (insn_list:REG_DEP_TRUE 15 (nil))
(nil))
(insn 20 19 21 (set (reg:SI 1 r1)
(const_int 0 [0x0])) 145 {*arm_movsi_insn} (nil)
(nil))
(call_insn/u 21 20 23 (parallel [
(set (reg:SI 0 r0)
(call (mem:SI (symbol_ref:SI ("__aeabi_idiv") [flags 0x41]) [0
S4 A32])
(const_int 0 [0x0])))
(use (const_int 0 [0x0]))
(clobber (reg:SI 14 lr))
]) 230 {*call_value_symbol} (insn_list:REG_DEP_TRUE 19
(insn_list:REG_DEP_TRUE 20 (nil)))
(expr_list:REG_DEAD (reg:SI 1 r1)
(expr_list:REG_UNUSED (reg:SI 14 lr)
(expr_list:REG_EH_REGION (const_int -1 [0x])
(nil
(expr_list:REG_DEP_TRUE (use (reg:SI 1 r1))
(expr_list:REG_DEP_TRUE (use (reg:SI 0 r0 [ x ]))
(nil
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27538
[Bug target/27562] SSE instruction selection wrong for Athlon processors.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-11 18:45 --- Have you tried using the -march=athlon options (where is replaced with your CPU type)? Also do you have a list of instructions which supported on which Athlon? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27562
[Bug fortran/27553] Testsuite ICE with -Wunused-labels
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-11 18:46
---
The ICE is due to -Wunused-labels. We try to issue a warning about the label
(already marked as an error because it contains a non-numeric character) being
unused, but said label has no locus (because the parser errored out before
assigning it.
Steve, I'm adding you in the CC list since you were the one who rewrote that
codepath a few months ago, IIRC.
I propose we strengthen the errorn in that case and also for the "Too many
digits" and "Zero is not a valid label", by the following patch:
Index: parse.c
===
--- parse.c (revision 113671)
+++ parse.c (working copy)
@@ -439,6 +439,7 @@
if (!gfc_is_whitespace (c))
gfc_error_now ("Non-numeric character in statement label at %C");
+ return ST_NONE;
}
else
{
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org, kargl at gcc dot gnu
||dot org
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Keywords||error-recovery, patch
Last reconfirmed|-00-00 00:00:00 |2006-05-11 18:46:22
date||
Summary|Testsuite ICE with -Wall|Testsuite ICE with -Wunused-
||labels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27553
[Bug target/27538] execute/20030128-1.c FAILs
--- Comment #2 from kazu at gcc dot gnu dot org 2006-05-11 18:54 ---
Here is a reduced testcase.
volatile short y;
int
foo (void)
{
return y;
}
With -O1, this function magically turns into "return 0;" like so
foo:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
@ lr needed for prologue
mov r0, #0
bx lr
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27538
[Bug fortran/27553] Testsuite ICE with -Wunused-labels
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu
2006-05-11 19:23 ---
Subject: Re: Testsuite ICE with -Wunused-labels
On Thu, May 11, 2006 at 06:46:22PM -, fxcoudert at gcc dot gnu dot org
wrote:
> The ICE is due to -Wunused-labels. We try to issue a warning about the label
> (already marked as an error because it contains a non-numeric character) being
> unused, but said label has no locus (because the parser errored out before
> assigning it.
>
> Steve, I'm adding you in the CC list since you were the one who rewrote that
> codepath a few months ago, IIRC.
>
> I propose we strengthen the errorn in that case and also for the "Too many
> digits" and "Zero is not a valid label", by the following patch:
>
> Index: parse.c
> ===
> --- parse.c (revision 113671)
> +++ parse.c (working copy)
> @@ -439,6 +439,7 @@
> if (!gfc_is_whitespace (c))
> gfc_error_now ("Non-numeric character in statement label at %C");
>
> + return ST_NONE;
> }
>else
> {
>
Yes, the above looks correct; otherwise, we fall through to
the decode_statement() call.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27553
[Bug target/27538] execute/20030128-1.c FAILs
--- Comment #3 from kazu at gcc dot gnu dot org 2006-05-11 19:40 ---
The combiner combines
=== i1 ===
(insn 10 8 11 2 (set (reg/f:SI 103)
(symbol_ref:SI ("y") )) 145 {*arm_movsi_insn}
(nil)
(nil))
=== i2 ===
(insn 11 10 13 2 (set (reg:SI 105 [ y ])
(zero_extend:SI (mem/v/c/i:HI (reg/f:SI 103) [0 y+0 S2 A16]))) 123
{*arm_zero_extendhisi2} (insn_list:REG_DEP_TRUE 10 (nil))
(expr_list:REG_DEAD (reg/f:SI 103)
(nil)))
=== i3 ===
(insn 13 11 14 2 (set (reg:SI 106)
(ashift:SI (reg:SI 105 [ y ])
(const_int 16 [0x10]))) 101 {*arm_shiftsi3} (insn_list:REG_DEP_TRUE
11 (nil))
(expr_list:REG_DEAD (reg:SI 105 [ y ])
(nil)))
into
(set (subreg:HI (reg:SI 106) 0)
(const_int 0 [0x0]))
Doh!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27538
[Bug target/27538] [4.2 Regression] execute/20030128-1.c FAILs
--- Comment #4 from kazu at gcc dot gnu dot org 2006-05-11 20:36 --- I just confirmed that 4.1 generates correct code with -O1, so this is a regression. -- kazu at gcc dot gnu dot org changed: What|Removed |Added Summary|execute/20030128-1.c FAILs |[4.2 Regression] ||execute/20030128-1.c FAILs Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27538
[Bug fortran/27552] -fdump-parse-tree doesn't like Holleriths (but then, who does?)
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-05-11 20:58 --- Patched formally submitted for review on the ml: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00485.html -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||05/msg00485.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27552
[Bug target/27565] New: [4.1/4.2 Regression] ICE in assign_stack_temp_for_type for vectors with SPE
Many GCC tests such as gcc.c-torture/compile/simd-3.c fail on
powerpc-none-eabispe with an ICE in assign_stack_temp_for_type. This happens
with trunk and 4.1 branch but not with 4.0 branch. Reduced testcase:
typedef double V __attribute__((vector_size (16)));
void f(void)
{
volatile V t = { 0.0, 0.0 };
}
t.c: In function 'f':
t.c:5: internal compiler error: in assign_stack_temp_for_type, at
function.c:716
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: [4.1/4.2 Regression] ICE in assign_stack_temp_for_type
for vectors with SPE
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
GCC target triplet: powerpc*-*-*spe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27565
[Bug target/27566] New: [4.1/4.2 Regression] ICEs in final_scan_insn and reload_cse_simplify_operands for vectors with SPE
Some GCC tests such as gcc.c-torture/execute/simd-5.c fail on
powerpc-none-eabispe with an ICE in final_scan_insn (not optimizing) or
reload_cse_simplify_operands (optimizing). This happens with trunk and 4.1
branch but not with 4.0 branch. Reduced testcase:
typedef short Q __attribute__((vector_size(8)));
Q a, b, c;
void
f (void)
{
c = a * b;
}
Non-optimizing:
t.c: In function 'f':
t.c:9: error: insn does not satisfy its constraints:
(insn 45 74 75 (set (reg:V4HI 0 0 [158])
(mem/u/c/i:V4HI (lo_sum:SI (reg:SI 10 10)
(symbol_ref/u:SI ("*.LC0") [flags 0x2])) [0 S8 A64])) 1059
{*movv4hi_internal} (nil)
(nil))
t.c:9: internal compiler error: in final_scan_insn, at final.c:2379
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
With -O:
t.c: In function 'f':
t.c:9: error: insn does not satisfy its constraints:
(insn 18 68 66 2 (set (reg:V4HI 0 0 [127])
(mem/u/c/i:V4HI (lo_sum:SI (reg:SI 6 6)
(symbol_ref/u:SI ("*.LC0") [flags 0x82])) [0 S8 A64])) 1059
{*movv4hi_internal} (nil)
(nil))
t.c:9: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:393
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: [4.1/4.2 Regression] ICEs in final_scan_insn and
reload_cse_simplify_operands for vectors with SPE
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
GCC target triplet: powerpc*-*-*spe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27566
[Bug fortran/27553] Testsuite ICE with -Wunused-labels
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-11 21:37 --- Subject: Bug 27553 Author: fxcoudert Date: Thu May 11 21:37:10 2006 New Revision: 113712 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113712 Log: PR fortran/27553 * parse.c (next_free): Return instead of calling decode_statement upon error. * gfortran.dg/label_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/label_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/parse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27553
