[Bug fortran/41800] [OOP] ICE in fold_convert_loc, at fold-const.c:2789
--- Comment #2 from dominiq at lps dot ens dot fr 2009-10-23 07:37 --- Reduced test case: module abstract_gradient implicit none public :: vector_class public :: inner_product_class public :: gradient_class private type, abstract :: vector_class end type vector_class type, abstract :: inner_product_class end type inner_product_class type, abstract, extends(vector_class) :: gradient_class class(inner_product_class), pointer :: my_inner_product = null() contains procedure, public, non_overridable :: inquire_inner_product end type gradient_class contains function inquire_inner_product (this) class(gradient_class) :: this class(inner_product_class), pointer :: inquire_inner_product inquire_inner_product = this%my_inner_product end function inquire_inner_product end module abstract_gradient module abstract_conjugate_gradients use abstract_gradient implicit none contains subroutine cg (g_initial) class(gradient_class), intent(in):: g_initial class(inner_product_class), pointer :: ip_save ip_save = g_initial%inquire_inner_product() ! ICE end subroutine cg end module abstract_conjugate_gradients The ICE goes away if I comment line 6: private -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41800
[Bug middle-end/37130] warning: array subscript is above array bounds.
--- Comment #3 from enrio at online dot no 2009-10-23 07:41 --- Created an attachment (id=18877) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18877action=view) Code that warns, 50 lines, no #include. #ifdef for variations w/o warning -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37130
[Bug debug/41806] New: G++ fails to compile a testcase with -fcompare-debug
GCC 4.5.0 20091022, compiled with GCC 4.3.3: ../gcc-4.5/configure --enable-languages=c,c++ --disable-bootstrap make CFLAGS=-O0 g++ -fcompare-debug -O2 rtl.ii g++: rtl.ii: -fcompare-debug failure (length) See bug 41340, attachment 18567. -- Summary: G++ fails to compile a testcase with -fcompare-debug Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: d dot g dot gorbachev at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41806
[Bug middle-end/41762] internal compiler error when compiling xorg-server
--- Comment #9 from carrot at google dot com 2009-10-23 09:15 --- (In reply to comment #5) This is fixed on trunk by revision 149082: http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg01067.html The patch 149082 contains two parts: 1. fixed a wrong optimization in tree-ssa-sink.c, it affects performance only. 2. fixed a i386 back end bug in i386.c. I've tried the bug fixing code in i386.c, unfortunately it doesn't work. So it looks more like the better optimization in the patch hides an unknown bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41762
[Bug debug/41340] [4.5 Regression] GCC produces different code with and without -g option
--- Comment #13 from d dot g dot gorbachev at gmail dot com 2009-10-23 09:15 --- The original testcase still fails with -fcompare-debug with GCC 4.5.0 20091022. This bug is now tracked here: bug 41806. The second bug is indeed fixed. -- d dot g dot gorbachev at gmail dot com changed: What|Removed |Added Summary|[4.5 Regression] G++|[4.5 Regression] GCC |produces different code with|produces different code with |and without -g option |and without -g option http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41340
[Bug tree-optimization/41778] missed dead store elimination
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-23 09:34 --- Subject: Bug 41778 Author: rguenth Date: Fri Oct 23 09:34:46 2009 New Revision: 153491 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153491 Log: 2009-10-23 Richard Guenther rguent...@suse.de PR tree-optimization/41778 * tree-ssa-pre.c (do_regular_insertion): Only insert if a redundancy along a path in the CFG we want to optimize for speed is going to be removed. (execute_pre): Do partial-PRE only if the function is to be optimized for speed. (gate_pre): Do not turn off all of PRE when not optimizing a function for speed. * gcc.dg/tree-ssa/ssa-pre-26.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-26.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41778
[Bug tree-optimization/41778] missed dead store elimination
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-23 09:35 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41778
[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
--- Comment #27 from rguenth at gcc dot gnu dot org 2009-10-23 09:45 --- Appearantly I was misguided in comment #24 and likely was thinking about the 4.4 dynamic stack re-alignment code which (guessing again) is probably only in effect for AVX. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
[Bug libstdc++/40852] [parallel-mode] parallel sort run time increases ~10 fold when vector size gets over ~4*10^9
--- Comment #18 from singler at gcc dot gnu dot org 2009-10-23 10:00 --- (In reply to comment #17) Is something known about the actual size of a, b, and c? They can be as large as the input size. Also, I don't know which is the required precision for the result: must be exact if representable? In the last iteration, __n == 0 = __total == __N, and then, the result must absolutely be __rank, according to the specification. Anyway, I think I have found a solution that is easier, faster, and avoids the large intermediate altogether (see attached patch). It also fixes similar problems in two other locations. However, this patch needs further thorough testing. Also, __n == 2 ^ __r - 1, so __n + 1 == 2 ^ __r, and the divisions could be replaced by shifts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40852
[Bug libstdc++/40852] [parallel-mode] parallel sort run time increases ~10 fold when vector size gets over ~4*10^9
--- Comment #19 from singler at gcc dot gnu dot org 2009-10-23 10:01 --- Created an attachment (id=18878) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18878action=view) Patch avoid large intermediates to avoid overflow, for trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40852
[Bug middle-end/41805] possible LTO termination bug
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-23 10:04 --- It is RTL expansion that drops the calls to func_2 () from main. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-23 10:04:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41805
[Bug middle-end/37130] warning: array subscript is above array bounds.
--- Comment #4 from enrio at online dot no 2009-10-23 10:06 ---
In my example code there is a pointer to a struct that has an array as the
first member. I appears that the compiler treats the pointer as a pointer to
this first member, and flags a loop that writes outside the first member
already at the first iteration. The code uses an integer offset from the
pointer, and the pointer itself is not changed.
If the members are reordered so that an unsigned char member becomes the first
one, the warning goes away. (But the example comes from a driver, and the
struct maps hardware registers, so it cannot be reordered at a whim.)
If the loop is modified so that it begins within the array, the warning goes
away, even the iterator has a constant end condition - outside the array.
If the loop is modified so that it begins exactly at the first byte after the
array, there are four warnings rather than three. It makes me wonder if the
compiler is generating code that does access the memory locations intended.
Since we got the strict aliasing optimizations, we probably should learn to
rewrite such old code using a union, or properly accessing the structure
members one by one. I just tried the union approach:
union mac_u {
struct mac_regs regs;
u8 bytes[sizeof(struct mac_regs)];
};
I changed the function argument to a pointer to this union rather than to a
struct mac_regs, initialized the local pointer variable from the 'bytes' union
member, and the warning went away. This appears to be the way to properly tell
the compiler how one plans to use the pointer.
Also if the pointer is incremented to point directly at the bytes of interest
rather than being indexed, the warning goes away.
--
enrio at online dot no changed:
What|Removed |Added
CC||enrio at online dot no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37130
[Bug middle-end/41805] possible LTO termination bug
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-23 10:17 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-10-23 10:04:23 |2009-10-23 10:17:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41805
[Bug target/40836] ICE: insn does not satisfy its constraints (iwmmxt_movsi_insn)
--- Comment #5 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-10-23 10:19 ---
similar issue seen with gcc 4.4.2 (this time in glibc; can not check gcc/libobj
because glibc is required by gcc):
(insn 202 200 195 12 fxprintf.c:48 (set (reg/f:SI 13 sp)
(reg/f:SI 44 wcgr1 [orig:193 saved_stack.38 ] [193])) 441
{*iwmmxt_movsi_insn} (nil))
fxprintf.c:56: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:396
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug middle-end/41805] possible LTO termination bug
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-10-23 10:20 ---
Non-LTO testcase:
void __attribute__((noinline))
foo (void)
{
while (1)
;
}
int main()
{
foo ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41805
[Bug debug/41801] [4.5 Regression] VTA: ICE in loc_cmp.
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org Keywords||ice-on-valid-code Summary|VTA: ICE in loc_cmp.|[4.5 Regression] VTA: ICE in ||loc_cmp. Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41801
[Bug target/40836] ICE: insn does not satisfy its constraints (iwmmxt_movsi_insn)
--- Comment #6 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-10-23 10:33 ---
message on file from comment #2 is now
$ ./cross/iwmmxt/bin/arm-linux-gnueabi-gcc -O2 -march=iwmmxt -mcpu=iwmmxt
-mtune=iwmmxt /tmp/foo.i
(insn 83 81 72 2
/srv/oe/projects/kk/ipan7/tmp/work/iwmmxt-linux-gnueabi/gcc-cross-4.4.1-r1.1/gcc-4.4.1/libobjc/sendmsg.c:280
(set (reg/f:SI 13 sp)
(reg/f:SI 43 wcgr0 [147])) 441 {*iwmmxt_movsi_insn} (nil))
/srv/oe/projects/kk/ipan7/tmp/work/iwmmxt-linux-gnueabi/gcc-cross-4.4.1-r1.1/gcc-4.4.1/libobjc/sendmsg.c:283:
internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
with gcc-4.4.2
--
enrico dot scholz at informatik dot tu-chemnitz dot de changed:
What|Removed |Added
Version|4.4.1 |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug c++/40808] [4.4/4.5 regression] member template specialization causes ICE
--- Comment #2 from dodji at gcc dot gnu dot org 2009-10-23 10:58 ---
I am not sure the example is invalid.
The Dummy()(Gen()) call expression obviously selects the operator template
typename F typename F::template Sig::ResultType operator()(F const f)
const in Dummy.
I believe the critical question is the following:
In:
~=~
template typename R struct CFunType {
template class Dummy1=Void, class Dummy2=Void
struct Sig: public FunTypeWrongNumberOfSigArgs
{
};//#1
template class Dummy
struct SigVoid,Dummy : public FunTypeR
{
};//#2
};
~=~
Which Sig template is instantiated by typename F::template Sig ? Is it //#1
or //#2 ?
I think Sig matches the template #1 (as in Sigvoid,void) which is the
primary template. But then, the best specialization of #1 is selected by the
compiler. The arguments of that specialization are deduced from the arguments
of the primary template. The void,void argument list used to match the
primary template #1 is compatible with the parameters of the specialization #2.
So in the end it's #2 that is going to be instantiated.
The relevant parts of the C++ spec are, I believe, the following:
[temp.class.spec]
7. Partial specialization declarations themselves are not found by name
lookup. Rather, when the primary template name is used, any previously-declared
partial specializations of the primary template are also considered.
[temp.class.spec.match]
1. When a class template is used in a context that requires an instantiation
of the class, it is necessary to determine whether the instantiation is to be
generated using the primary template or one of the partial specializations.
This is done by matching the template arguments of the class template
specialization with the template argument lists of the partial
specializations.
That being said, the crash seems to happens later during the mangling of the
operator template typename F typename F::template Sig::ResultType
operator()(F const f) const, precisely on the Sig template-id because the
mangling code doesn't expect the template argument list to be empty.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2009-08-25 14:16:58 |2009-10-23 10:58:13
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40808
[Bug fortran/41758] [Cleanup] Don't resolve expr in gfc_match_allocate
-- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-23 10:59:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41758
[Bug fortran/41758] [Cleanup] Don't resolve expr in gfc_match_allocate
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-23 11:01 --- Subject: Bug 41758 Author: janus Date: Fri Oct 23 11:01:38 2009 New Revision: 153494 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153494 Log: 2009-10-23 Janus Weil ja...@gcc.gnu.org PR fortran/41758 * match.c (conformable_arrays): Move to resolve.c. (gfc_match_allocate): Don't resolve SOURCE expr yet, and move some checks to resolve_allocate_expr. * resolve.c (conformable_arrays): Moved here from match.c. (resolve_allocate_expr): Moved some checks here from gfc_match_allocate. (resolve_code): Resolve SOURCE tag for ALLOCATE expressions. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/fortran/resolve.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41758
[Bug fortran/41758] [Cleanup] Don't resolve expr in gfc_match_allocate
--- Comment #4 from janus at gcc dot gnu dot org 2009-10-23 11:05 --- Fixed with r153494. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41758
[Bug fortran/41800] [OOP] ICE in fold_convert_loc, at fold-const.c:2789
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-23 11:10 ---
Backtrace:
Breakpoint 1, fold_convert_loc (loc=0, type=0x7fd3e16529a0, arg=0x7fd3e1659000)
at /home/jweil/gcc45/trunk/gcc/fold-const.c:2789
2789 gcc_unreachable ();
(gdb) bt
#0 fold_convert_loc (loc=0, type=0x7fd3e16529a0, arg=0x7fd3e1659000) at
/home/jweil/gcc45/trunk/gcc/fold-const.c:2789
#1 0x00590072 in gfc_trans_scalar_assign (lse=0x7fffe96ea410,
rse=0x7fffe96ea3c0, ts=
{type = BT_CLASS, kind = 0, u = {derived = 0x2310fb0, cl = 0x2310fb0},
interface = 0x0, is_c_interop = 0, is_iso_c = 0, f90_type = BT_UNKNOWN},
l_is_temp=0 '\0',
r_is_var=0 '\0') at /home/jweil/gcc45/trunk/gcc/fortran/trans-expr.c:4675
#2 0x005914f6 in gfc_trans_assignment_1 (expr1=0x23178b0,
expr2=0x2317b20, init_flag=0 '\0') at
/home/jweil/gcc45/trunk/gcc/fortran/trans-expr.c:5119
#3 0x00591916 in gfc_trans_assignment (expr1=0x23178b0,
expr2=0x2317b20, init_flag=0 '\0') at
/home/jweil/gcc45/trunk/gcc/fortran/trans-expr.c:5260
#4 0x0059196e in gfc_trans_assign (code=0x2317bf0) at
/home/jweil/gcc45/trunk/gcc/fortran/trans-expr.c:5272
#5 0x00591bf3 in gfc_trans_class_assign (code=0x2317bf0) at
/home/jweil/gcc45/trunk/gcc/fortran/trans-expr.c:5336
#6 0x0055aac6 in gfc_trans_code (code=0x2317bf0) at
/home/jweil/gcc45/trunk/gcc/fortran/trans.c:1094
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
CC||janus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41800
[Bug fortran/41800] [OOP] ICE in fold_convert_loc, at fold-const.c:2789
--- Comment #4 from janus at gcc dot gnu dot org 2009-10-23 11:27 --- Further reduced test case: module abstract_gradient implicit none private type, public, abstract :: gradient_class contains procedure, nopass :: inner_product end type contains function inner_product () class(gradient_class), pointer :: inner_product inner_product = NULL() end function end module use abstract_gradient class(gradient_class), pointer:: g_initial, ip_save ip_save = g_initial%inner_product() ! ICE end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41800
[Bug target/17994] avr-gcc does not output a dwarf2 .debug_frame section
--- Comment #3 from tsandnes at atmel dot com 2009-10-23 11:41 --- I tried gcc 4.3.2 from the WinAVR distribution and also avr-gcc 4.4.1. The short story is: There is call frame information there, but not enough. Specifically, the Call Frame instructions to reconstruct the pc to unwind rule table are still missing, but the CIE and FDE are present. I compared gcc and avr-gcc output on linux with the following results: gcc: --- The section .debug_frame contains: 0010 CIE Version: 1 Augmentation: Code alignment factor: 1 Data alignment factor: -4 Return address column: 8 DW_CFA_def_cfa: r4 (esp) ofs 4 DW_CFA_offset: r8 (eip) at cfa-4 DW_CFA_nop DW_CFA_nop 0014 0024 FDE cie= pc=08048394..0804840a DW_CFA_advance_loc: 4 to 08048398 DW_CFA_def_cfa: r1 (ecx) ofs 0 DW_CFA_register: r4 (esp) in r1 (ecx) DW_CFA_advance_loc: 6 to 0804839e DW_CFA_def_cfa: r4 (esp) ofs 4 DW_CFA_advance_loc: 1 to 0804839f DW_CFA_def_cfa_offset: 8 DW_CFA_offset: r5 (ebp) at cfa-8 DW_CFA_advance_loc: 2 to 080483a1 DW_CFA_def_cfa_register: r5 (ebp) DW_CFA_advance_loc: 1 to 080483a2 DW_CFA_offset: r4 (esp) at cfa-12 DW_CFA_nop DW_CFA_nop 003c 0014 FDE cie= pc=0804840a..0804841c DW_CFA_advance_loc: 1 to 0804840b DW_CFA_def_cfa_offset: 8 DW_CFA_offset: r5 (ebp) at cfa-8 DW_CFA_advance_loc: 2 to 0804840d DW_CFA_def_cfa_register: r5 (ebp) --- avr-gcc --- 000c CIE Version: 1 Augmentation: Code alignment factor: 1 Data alignment factor: -1 Return address column: 36 DW_CFA_def_cfa: r32 ofs 0 0010 000c FDE cie= pc=00ce..0160 0020 000c FDE cie= pc=0160..018c --- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17994
[Bug middle-end/41805] possible LTO termination bug
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-10-23 12:01 --- Subject: Bug 41805 Author: rguenth Date: Fri Oct 23 12:01:21 2009 New Revision: 153495 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153495 Log: 2009-10-23 Richard Guenther rguent...@suse.de PR middle-end/41805 * cfgexpand.c (expand_call_stmt): Use gimple_has_side_effects and gimple_call_nothrow_p. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41805
[Bug bootstrap/39150] Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).
--- Comment #6 from grobian at gentoo dot org 2009-10-23 12:12 --- this sounds like bug #30726 for what it's worth, my updated patches for gcc-4.4 can be found here: http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/sys-devel/gcc/files/4.4.0/gcc-4.4.1-solaris-x86_64.patch?format=txt (sorry for the download) -- grobian at gentoo dot org changed: What|Removed |Added CC||grobian at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150
[Bug c/41673] [4.5 Regression] variable-length array dereference inside sizeof gives warning: dereferencing type-punned pointer will break strict-aliasing rules
--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-10-23 12:18 --- Subject: Bug 41673 Author: jsm28 Date: Fri Oct 23 12:18:42 2009 New Revision: 153496 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153496 Log: PR c/41673 * alias.c (get_alias_set): Call langhook before returning 0 for types with structural equality. * c-common.c (c_common_get_alias_set): Use alias set of element type for arrays with structural comparison. testsuite: * gcc.dg/Wstrict-aliasing-bogus-vla-1.c: New test. Added: trunk/gcc/testsuite/gcc.dg/Wstrict-aliasing-bogus-vla-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c trunk/gcc/c-common.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41673
[Bug c/41673] [4.5 Regression] variable-length array dereference inside sizeof gives warning: dereferencing type-punned pointer will break strict-aliasing rules
--- Comment #3 from jsm28 at gcc dot gnu dot org 2009-10-23 12:23 --- Fixed for 4.5. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.5.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41673
[Bug fortran/41800] [OOP] ICE in fold_convert_loc, at fold-const.c:2789
--- Comment #5 from janus at gcc dot gnu dot org 2009-10-23 12:26 ---
This patch fixes it:
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(Revision 153493)
+++ gcc/fortran/trans-expr.c(Arbeitskopie)
@@ -4660,7 +4660,7 @@ gfc_trans_scalar_assign (gfc_se * lse, gfc_se * rs
gfc_add_expr_to_block (block, tmp);
}
}
- else if (ts.type == BT_DERIVED)
+ else if (ts.type == BT_DERIVED || ts.type == BT_CLASS)
{
gfc_add_block_to_block (block, lse-pre);
gfc_add_block_to_block (block, rse-pre);
Though I don't quite understand yet, why 'private' makes a difference here.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-10-23 12:26:03
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41800
[Bug fortran/41807] New: [Reg] data statement with nested type constructors
Reported on clf http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/650b2eeeb8d76213# w.f90:53.20: data(dft_water_nuc(i), i=1,n_nuc) / 1 Error: non-constant array in DATA statement (1) These seems to be variable - I can confirm it but others say that they do not see it. Source: === w.f90 = module w implicit none save private real, parameter :: zero = 0.0 type, public :: charge real :: q real :: C real :: A end type charge type, public :: multpol character*12 :: name real :: coor(3) !!! COMMENT THIS TO MAKE IT COMPILE !!! real :: mass type(charge) :: z end type multpol integer, public, parameter :: n_nuc=3 type(multpol), public :: dft_water_nuc(n_nuc) real, parameter :: C_i=zero real, parameter :: A_i=zero !names of multipole character*12, parameter :: mname1=O1 character*12, parameter :: mname2=H2 character*12, parameter :: mname3=H3 !coordinates of multipole centers real, parameter :: mcoor1(3)=(/ zero, zero, -0.119151/) real, parameter :: mcoor2(3)=(/-1.431042, zero, 0.945510/) real, parameter :: mcoor3(3)=(/ 1.431042, zero, 0.945510/) !mass real, parameter :: mass1=15.99491 real, parameter :: mass2=1.007825 real, parameter :: mass3=1.007825 !charges real, parameter :: Zn1=8.0 real, parameter :: Zn2=1.0 real, parameter :: Zn3=1.0 integer :: i ! data(dft_water_nuc(i), i=1,n_nuc) / multpol ( mname1, mcoor1, !!! COMMENT THIS TO MAKE IT COMPILE !!! mass1, charge(Zn1,C_i,A_i) ), multpol ( mname2, mcoor2, !!! COMMENT THIS TO MAKE IT COMPILE !!! mass2, charge(Zn2,C_i,A_i) ), multpol ( mname3, mcoor3, !!! COMMENT THIS TO MAKE IT COMPILE !!! mass3, charge(Zn3,C_i,A_i) ) / end module w -- Summary: [Reg] data statement with nested type constructors Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug fortran/41807] [Reg] data statement with nested type constructors
--- Comment #1 from dominiq at lps dot ens dot fr 2009-10-23 12:46 --- The code in comment #0 gives errors with gfortran 4.4.1 and 4.5.0 (recent patched trunk), compiles with 4.3.4, and gives an ICE with 4.2.4. Also compiles with ifort and gives an ICE with g95. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug target/37954] odd sized packed structures passed by value, under ARM, cause lockup of application
--- Comment #13 from mikpe at it dot uu dot se 2009-10-23 12:49 --- Created an attachment (id=18879) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18879action=view) backport of r141742 to gcc-4.3.4 that I'm testing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37954
[Bug lto/41808] error: non-trivial conversion at assignment
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-23 13:06 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-23 13:06:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41808
[Bug lto/41808] error: non-trivial conversion at assignment
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-23 13:14 ---
I believe this is because in slaveapp.min.cpp the gimplifier drops the
conversion
in
cleanup_point return retval = (struct cNetworkType *) cHead::find
(networks, s);
as useless (it's a conversion to an incomplete type).
cNetworkType* findNetwork(const char*) (const char * s)
{
struct cNetworkType * D.2114;
D.2114 = cHead::find (networks, s);
return D.2114;
}
but the LTO type merging completes this type (because of the networktype
declaration in chead.min.cpp) making the conversion no longer useless
[oddly enough the test still requires -O2 to ICE ...].
The fix might be to not complete pointer types this way but only complete
field-decls and parm-decls (which is where the completion is required to
make two function types or two record types compatible). Note that then
the issue of storage of type INCOMPLETE * vs. COMPLETE * becomes more
appearant (they get assigned different type alias-sets).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41808
[Bug middle-end/41805] possible LTO termination bug
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-10-23 13:16 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41805
[Bug lto/41808] New: error: non-trivial conversion at assignment
x.h
---
class cObject {
public:
cObject *firstchildp;
};
class cHead : public cObject {
public:
cObject *find(const char *objname) const;
};
chead.min.cpp:
--
#include x.h
cObject *cHead::find(const char *objname) const
{
return firstchildp;
}
class cNetworkType : public cObject { };
cNetworkType *networktype;
slaveapp.min.cpp:
-
#include x.h
extern cHead networks;
class cNetworkType;
inline cNetworkType *findNetwork(const char *s)
{
return (cNetworkType *)networks.find(s);
}
int run(const char *opt_network_name)
{
cNetworkType *network = findNetwork(opt_network_name);
if (!network)
throw 1;
}
g++ -c slaveapp.min.cpp chead.min.cpp -O2 -flto
lto1 -quiet slaveapp.min.o chead.min.o -o /dev/null -O2
In file included from :2:0:
slaveapp.min.cpp: In function 'findNetwork':
slaveapp.min.cpp:4:22: error: non-trivial conversion at assignment
struct cNetworkType *
struct cObject *
D.1922_2 = D.1931_5;
slaveapp.min.cpp:4:22: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: error: non-trivial conversion at assignment
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, ice-checking
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41808
[Bug target/40836] ICE: insn does not satisfy its constraints (iwmmxt_movsi_insn)
--- Comment #7 from enrico dot scholz at informatik dot tu-chemnitz dot de 2009-10-23 13:39 --- When I read the RTL dumps correctly, gcc tries to assign SP to wCGR0. This can be done by the tmrc sp, wCGR0 assembly instruction which will be issued by alternative 6 in --- iwmmxt.md --- (define_insn *iwmmxt_movsi_insn [(set (match_operand:SI 0 nonimmediate_operand =rk,r,r,rk, m,z,r,?z,Uy,z) (match_operand:SI 1 general_operand rk, I,K,mi,rk,r,z,Uy,z, z))] ... case 6: return \tmrc\\t%0, %1\; The corresponding constraints pair is ['r', 'z'] and it is matched by [sp, wcgr0] afais. What could be the reason for the ICE? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug target/40836] ICE: insn does not satisfy its constraints (iwmmxt_movsi_insn)
--- Comment #8 from enrico dot scholz at informatik dot tu-chemnitz dot de 2009-10-23 14:31 --- adding 'k' to the 'r' constraints seems to fix the ICE (although I did not tested correctness of the generated code). What is the reason that 'sp' resp. 'r13' is not catched by the 'r' 'l' constraints? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug fortran/37829] ICE in resolve_symbol
--- Comment #7 from dominiq at lps dot ens dot fr 2009-10-23 15:01 --- It seems that the patch in comment #2 has been silently applied (I have been unable to find when) and that the test in comment #0 no longer gives an ICE for gfortran 4.3.4, 4.4.1, and trunk. Apparently the failure of the test in comment #4 is due to the fact that c_funptr is not mangled the way it is defined (through different modules and an only clause). If I remove module 'a' and the comment in module 'b', the code compiles. This pr could probably be closed and a new one open for the problem of comment #4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
[Bug target/40836] ICE: insn does not satisfy its constraints (iwmmxt_movsi_insn)
--- Comment #9 from enrico dot scholz at informatik dot tu-chemnitz dot de 2009-10-23 15:13 --- Core problem seemss to be that 4.4 differs between CORE_REGS and GENERAL_REGS (CORE_REGS without r13/sp) and the r, l + h constraints in the .md rules apply to GENERAL_REGS only. This makes some valid machine code combinations impossible and will cause ICE hence. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug libstdc++/40852] [parallel-mode] parallel sort run time increases ~10 fold when vector size gets over ~4*10^9
--- Comment #20 from paolo dot carlini at oracle dot com 2009-10-23 16:00 --- Excellent. Let's wait a bit for feedback from people experiencing this issue and then commit the patch, first mainline and then probably 4_4-branch too. Make sure to also regression test the fix on a normal ;) machine... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40852
[Bug other/41809] New: escaping address of packed field should trigger warning
A field in a packed struct will often not have the normal alignment for its
type. So taking the address of such a field may yield a misaligned pointer,
but gcc does not warn about that. This is similar to casting a pointer from a
less aligned type to a more aligned type, which does give a warning (with
-Wcast-align).
Example:
cat aopf.c
#include stdio.h
void __attribute__((noinline)) f(int *p)
{
printf(%p\n, p);
}
struct s {
int x;
char c;
} __attribute__((__packed__));
struct s A[10];
int main(void)
{
unsigned int i;
for (i = 0; i sizeof(A)/sizeof(A[0]); ++i) {
f(A[i].x);
f((int*)(char*)A[i].x);
}
return 0;
}
gcc -Wall -Wextra -Wcast-align -O aopf.c
aopf.c: In function 'main':
aopf.c:21:4: warning: cast increases required alignment of target type
Ideally both calls to f() should trigger alignment warnings.
--
Summary: escaping address of packed field should trigger warning
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41809
[Bug fortran/41800] [OOP] ICE in fold_convert_loc, at fold-const.c:2789
--- Comment #6 from janus at gcc dot gnu dot org 2009-10-23 16:10 --- Subject: Bug 41800 Author: janus Date: Fri Oct 23 16:10:08 2009 New Revision: 153504 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153504 Log: 2009-10-23 Janus Weil ja...@gcc.gnu.org PR fortran/41800 * trans-expr.c (gfc_trans_scalar_assign): Handle CLASS variables. 2009-10-23 Janus Weil ja...@gcc.gnu.org PR fortran/41800 * gfortran.dg/class_10.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/class_10.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41800
[Bug fortran/41800] [OOP] ICE in fold_convert_loc, at fold-const.c:2789
--- Comment #7 from janus at gcc dot gnu dot org 2009-10-23 16:13 --- Fixed with r153504. Thanks for the report. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41800
[Bug libstdc++/41810] New: Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope
I'm using a gcc-3.4.3 (csl-sol210-3_4-20050802) to build another instance of gcc-4.4.2. Build fails with the following error message: Making all in include gmake[4]: Entering directory `/home/gprog/build/i386-pc-solaris2.11/libstdc++-v3/include' mkdir -p ./i386-pc-solaris2.11/bits/stdc++.h.gch /home/gprog/build/./gcc/xgcc -shared-libgcc -B/home/gprog/build/./gcc -nostdinc++ -L/home/gprog/build/i386-pc-solaris2.11/libstdc++-v3/src -L/home/gprog/build/i386-pc-solaris2.11/libstdc++-v3/src/.libs -B/tmp/gcc/i386-pc-solaris2.11/bin/ -B/tmp/gcc/i386-pc-solaris2.11/lib/ -isystem /tmp/gcc/i386-pc-solaris2.11/nclude -isystem /tmp/gcc/i386-pc-solaris2.11/sys-include -x c++-header -g -O2 -march=pentium4 -mtune=pentium4 -I/home/gprog/build/i386-pc-solaris2.11/libstdc++-v3/include/i386-pc-solaris2.11 -I/home/gprog/build/i386-pc-solaris2.11/libstdc++-v3/include -I/home/gprog/gcc-4.4.2/libstdc++-v3/libsupc++ -O0 -g /home/gprog/gcc-4.4.2/libstdc++-v3/include/precompiled/stdc++.h -o i386-pc-solaris2.11/bits/stdc++.h.gch/O0g.gch In file included from /home/gprog/build/i386-pc-solaris2.11/libstdc++-v3/include/i386-pc-solaris2.11/bits/gthr.h:162, from /home/gprog/build/i386-pc-solaris2.11/libstdc++-v3/include/ext/atomicity.h:34, from /home/gprog/build/i386-pc-solaris2.11/libstdc++-v3/include/bits/basic_string.h:41, from /home/gprog/build/i386-pc-solaris2.11/libstdc++-v3/include/string:53, from /home/gprog/build/i386-pc-solaris2.11/libstdc++-v3/include/bitset:49, from /home/gprog/gcc-4.4.2/libstdc++-v3/include/precompiled/stdc++.h:64: /home/gprog/build/i386-pc-solaris2.11/libstdc++-v3/include/i386-pc-solaris2.11/bits/gthr-default.h: In function 'int __gthread_mutex_destroy(__gthread_mutex_t*)': /home/gprog/build/i386-pc-solaris2.11/libstdc++-v3/include/i386-pc-solaris2.11/bits/gthr-default.h:466: error: '__mutex' was not declared in this scope gmake[4]: *** [i386-pc-solaris2.11/bits/stdc++.h.gch/O0g.gch] Error 1 gmake[4]: Leaving directory `/home/gprog/build/i386-pc-solaris2.11/libstdc++-v3/include' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/home/gprog/build/i386-pc-solaris2.11/libstdc++-v3' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/gprog/build/i386-pc-solaris2.11/libstdc++-v3' Configure command: ../gcc-4.4.2/configure --prefix=/usr/gnu --exec-prefix=/usr/gnu --srcdir=../gcc-4.4.2 --enable-shared --localstatedir=/var --with-gnu-as --with-gnu-ld --enable-threads=solaris --disable-multilib --enable-languages=c,c++,fortran,objc --with-gmp=/usr/gnu The following environment variables were set before the build started: CFLAGS=-O2 -march=pentium4 -mtune=pentium4 CXXFLAGS=-O2 -march=pentium4 -mtune=pentium4 -- Summary: Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: YLitvinenko at astana dot oilfield dot slb dot com GCC build triplet: i386-pc-solaris2.11 GCC host triplet: i386-pc-solaris2.11 GCC target triplet: i386-pc-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41810
[Bug libstdc++/41810] Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope
--- Comment #1 from YLitvinenko at astana dot oilfield dot slb dot com 2009-10-23 17:03 --- Created an attachment (id=18880) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18880action=view) At line 466: error: '__mutex' was not declared -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41810
[Bug fortran/41784] [OOP] ICE in load_derived_extensions
--- Comment #10 from mikael at gcc dot gnu dot org 2009-10-23 17:17 ---
(In reply to comment #9)
Now here we may need:
if (p == NULL)
{
skip_list ();
continue;
}
skip_list() is unnecessary here as we have parsed everything already and the
locus is on the closing parenthesis. However, mio_rparen() is needed so that we
do not miss any parenthesis (this is also the case without skip_list).
The unformatted patch should look like this (it fixes the reduced testcase, but
not tested further) :
Index: module.c
===
--- module.c(revision 153473)
+++ module.c(working copy)
@@ -4008,6 +4008,7 @@
nuse = number_use_names (name, false);
j = 1;
p = find_use_name_n (name, j, false);
+ if (p) {
st = gfc_find_symtree (gfc_current_ns-sym_root, p);
dt = st-n.sym;
st = gfc_find_symtree (derived-f2k_derived-sym_root, name);
@@ -4019,6 +4020,7 @@
st-n.sym = dt;
st-n.sym-refs++;
}
+ }
mio_rparen ();
}
mio_rparen ();
BTW, is there any good reason why 'p' is NULL?
B is not imported (or use-associated in the fortran jargon)
NB : skip_list() wouldn't work anyway because it stops when the level variable
is 0 (see the code). The character under the locus _shall_ be an opening
parenthesis at the time skip_list() is called.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41784
[Bug target/41762] internal compiler error when compiling xorg-server
--- Comment #10 from jakub at gcc dot gnu dot org 2009-10-23 17:33 --- Created an attachment (id=18881) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18881action=view) gcc44-pr41762.patch Patch I'm going to bootstrap/regtest. As ix86 backend doesn't know what kind of VALUE preserving mode the pass it occurs in uses, it needs to be prepared even for VALUEs discarded as useless by remove_useless_values, similarly e.g. to get_addr in alias.c which also checks for them. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41762
[Bug testsuite/31342] testsuite i386/pic-1.c FAILed for warning -fPIC ignored
--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-10-23 17:37 --- Subject: Bug 31342 Author: jsm28 Date: Fri Oct 23 17:37:13 2009 New Revision: 153506 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153506 Log: * g++.dg/abi/rtti3.C, g++.dg/abi/thunk4.C: Skip for *-*-mingw* and *-*-cygwin. * g++.dg/cpp0x/lambda/lambda-mangle.C: Disable weak symbols tests for *-*-mingw* and *-*-cygwin. * g++.dg/opt/vt1.C: Skip for *-*-mingw* and *-*_cygwin. * g++.dg/template/spec35.C: Disable weak symbol test for *-*-mingw* and *-*-cygwin. PR testsuite/31342 * gcc.target/i386/pic-1.c: Skip for *-*-mingw* and *-*-cygwin. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/abi/rtti3.C trunk/gcc/testsuite/g++.dg/abi/thunk4.C trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-mangle.C trunk/gcc/testsuite/g++.dg/opt/vt1.C trunk/gcc/testsuite/g++.dg/template/spec35.C trunk/gcc/testsuite/gcc.target/i386/pic-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31342
[Bug testsuite/31342] testsuite i386/pic-1.c FAILed for warning -fPIC ignored
--- Comment #3 from jsm28 at gcc dot gnu dot org 2009-10-23 17:38 --- Fixed for 4.5. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31342
[Bug target/41799] __enable_execute_stack introduced for mingw32 in r134089 doesn't work for kernel-mode components
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-10-23 17:59 --- Created an attachment (id=18882) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18882action=view) Patch for enable for mingw32 targets -fset-stack-executable Changelog * config/i386/mingw32.h (CHECK_EXECUTE_STACK_ENABLED): New macro. * config/i386/mingw.opt: Add fset-stack-executable. * config/i386/i386.c (ix86_trampoline_init): Make call to emit_library_call conditional, if CHECK_EXECUTE_STACK_ENABLED is defined and its value is not zero. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41799
[Bug tree-optimization/41811] New: graphite miscompiles 454.calculix of the SPEC 2k6
The kernel that is miscompiled is in shape20h.f and it looks like this:
do i=1,3
do j=1,3
xs(i,j)=0.d0
do k=1,20
xs(i,j)=xs(i,j)+xl(i,k)*shp(j,k)
enddo
enddo
enddo
There is an interchange of the j and k loops that is applied to the
kernel. The statement induction variable order is interchanged for
scat_5 and scat_3, as in S5(scat_1,scat_5,scat_3). The code generated
by CLooG looks like this:
for (scat_1=0;scat_1=2;scat_1++) {
S3(scat_1) ;
for (scat_3=0;scat_3=1;scat_3++) {
S4(scat_1,scat_3) ;
for (scat_5=0;scat_5=2;scat_5++) {
S5(scat_1,scat_5,scat_3) ;
S6(scat_1,scat_5,scat_3) ;
}
S7(scat_1,scat_3) ;
S26(scat_1,scat_3) ;
S8(scat_1,scat_3) ;
}
S4(scat_1,2) ;
for (scat_5=0;scat_5=2;scat_5++) {
S5(scat_1,scat_5,2) ;
S6(scat_1,scat_5,2) ;
}
S7(scat_1,2) ;
S26(scat_1,2) ;
for (scat_3=3;scat_3=18;scat_3++) {
for (scat_5=0;scat_5=2;scat_5++) {
S5(scat_1,scat_5,scat_3) ;
S6(scat_1,scat_5,scat_3) ;
}
}
for (scat_5=0;scat_5=2;scat_5++) {
S5(scat_1,scat_5,19) ;
}
}
--
Summary: graphite miscompiles 454.calculix of the SPEC 2k6
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: spop at gcc dot gnu dot org
ReportedBy: spop at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41811
[Bug tree-optimization/41811] graphite miscompiles 454.calculix of the SPEC 2k6
-- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-23 18:02:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41811
Re: [Bug c++/40808] [4.4/4.5 regression] member template specialization causes ICE
Posted a patch at http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01469.html -- Dodji Seketeli Red Hat
[Bug target/41810] Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope
--- Comment #2 from paolo dot carlini at oracle dot com 2009-10-23 18:14
---
Let's CC Rainer. IMHO something is broken in gthr-solaris.h, I see:
#ifdef __cplusplus
#define UNUSED(x)
#else
#define UNUSED(x) x __attribute__((unused))
#endif
...
static inline int
__gthread_mutex_destroy (__gthread_mutex_t * UNUSED(__mutex))
{
if (__gthread_active_p ())
return __gthrw_(mutex_destroy) (__mutex);
else
return 0;
}
which cannot be Ok when __cplusplus is defined. Not a libstdc++ proper issue.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
CC||ro at techfak dot uni-
||bielefeld dot de
Component|libstdc++ |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41810
[Bug tree-optimization/41811] graphite miscompiles 454.calculix of the SPEC 2k6
--- Comment #1 from spop at gcc dot gnu dot org 2009-10-23 18:16 ---
The bug disappears with disabling the loop interchange, but the code
generated by CLooG still looks strange:
for (scat_1=0;scat_1=2;scat_1++) {
S3(scat_1) ;
for (scat_3=0;scat_3=1;scat_3++) {
S4(scat_1,scat_3) ;
for (scat_5=0;scat_5=18;scat_5++) {
S5(scat_1,scat_3,scat_5) ;
S6(scat_1,scat_3,scat_5) ;
}
S5(scat_1,scat_3,19) ;
S7(scat_1,scat_3) ;
S26(scat_1,scat_3) ;
S8(scat_1,scat_3) ;
}
S4(scat_1,2) ;
for (scat_5=0;scat_5=18;scat_5++) {
S5(scat_1,2,scat_5) ;
S6(scat_1,2,scat_5) ;
}
S5(scat_1,2,19) ;
S7(scat_1,2) ;
S26(scat_1,2) ;
}
given that the original and transformed Loop Statement Trees look like
this:
original_lst (
(root
0 (loop
0 stmt_3
1 (loop
0 stmt_4
1 (loop
0 stmt_5
1 stmt_6)
2 stmt_7
3 stmt_26
4 stmt_8
transformed_lst (
(root
0 (loop
0 stmt_3
1 (loop
0 stmt_4
1 (loop
0 stmt_5
1 stmt_6)
2 stmt_7
3 stmt_26
4 stmt_8
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41811
Re: [Bug c++/41020] [4.5 Regression] Can't declare an extern C friend of a builtin function
Indeed. I am testing the patch below.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 5eb389f..7c01ee2 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -104,6 +104,7 @@ static void store_parm_decls (tree);
static void initialize_local_var (tree, tree);
static void expand_static_init (tree, tree);
static tree next_initializable_field (tree);
+static int decls_match_1 (tree, tree, bool);
/* The following symbols are subsumed in the cp_global_trees array, and
listed here individually for documentation purposes.
@@ -899,6 +900,14 @@ push_local_name (tree decl)
int
decls_match (tree newdecl, tree olddecl)
{
+ return decls_match_1 (newdecl, olddecl, /* newdecl_is_friend */ false);
+}
+
+/* Subroutine of decls_match. */
+
+static int
+decls_match_1 (tree newdecl, tree olddecl, bool newdecl_is_friend)
+{
int types_match;
if (newdecl == olddecl)
@@ -934,9 +943,11 @@ decls_match (tree newdecl, tree olddecl)
#ifdef NO_IMPLICIT_EXTERN_C
/* A new declaration doesn't match a built-in one unless it
-is also extern C. */
+is also extern C. Friend function re-declarations retain the
+the linkage of the original declaration though. */
if (DECL_BUILT_IN (olddecl)
- DECL_EXTERN_C_P (olddecl) !DECL_EXTERN_C_P (newdecl))
+ DECL_EXTERN_C_P (olddecl) !DECL_EXTERN_C_P (newdecl)
+ !newdecl_is_friend)
return 0;
#endif
@@ -1122,7 +1133,7 @@ duplicate_decls (tree newdecl, tree olddecl, bool
newdecl_is_friend)
if (newdecl == olddecl)
return olddecl;
- types_match = decls_match (newdecl, olddecl);
+ types_match = decls_match_1 (newdecl, olddecl, newdecl_is_friend);
/* If either the type of the new decl or the type of the old decl is an
error_mark_node, then that implies that we have already issued an
[Bug c++/41020] [4.5 Regression] Can't declare an extern C friend of a builtin function
--- Comment #8 from dodji at gcc dot gnu dot org 2009-10-23 18:19 ---
Subject: Re: [4.5 Regression] Can't declare an extern C
friend of a builtin function
Indeed. I am testing the patch below.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 5eb389f..7c01ee2 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -104,6 +104,7 @@ static void store_parm_decls (tree);
static void initialize_local_var (tree, tree);
static void expand_static_init (tree, tree);
static tree next_initializable_field (tree);
+static int decls_match_1 (tree, tree, bool);
/* The following symbols are subsumed in the cp_global_trees array, and
listed here individually for documentation purposes.
@@ -899,6 +900,14 @@ push_local_name (tree decl)
int
decls_match (tree newdecl, tree olddecl)
{
+ return decls_match_1 (newdecl, olddecl, /* newdecl_is_friend */ false);
+}
+
+/* Subroutine of decls_match. */
+
+static int
+decls_match_1 (tree newdecl, tree olddecl, bool newdecl_is_friend)
+{
int types_match;
if (newdecl == olddecl)
@@ -934,9 +943,11 @@ decls_match (tree newdecl, tree olddecl)
#ifdef NO_IMPLICIT_EXTERN_C
/* A new declaration doesn't match a built-in one unless it
-is also extern C. */
+is also extern C. Friend function re-declarations retain the
+the linkage of the original declaration though. */
if (DECL_BUILT_IN (olddecl)
- DECL_EXTERN_C_P (olddecl) !DECL_EXTERN_C_P (newdecl))
+ DECL_EXTERN_C_P (olddecl) !DECL_EXTERN_C_P (newdecl)
+ !newdecl_is_friend)
return 0;
#endif
@@ -1122,7 +1133,7 @@ duplicate_decls (tree newdecl, tree olddecl, bool
newdecl_is_friend)
if (newdecl == olddecl)
return olddecl;
- types_match = decls_match (newdecl, olddecl);
+ types_match = decls_match_1 (newdecl, olddecl, newdecl_is_friend);
/* If either the type of the new decl or the type of the old decl is an
error_mark_node, then that implies that we have already issued an
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020
[Bug c++/41020] [4.5 Regression] Can't declare an extern C friend of a builtin function
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-09-18 03:56:23 |2009-10-23 18:34:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020
[Bug fortran/41784] [OOP] ICE in load_derived_extensions
--- Comment #11 from janus at gcc dot gnu dot org 2009-10-23 18:35 --- Created an attachment (id=18883) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18883action=view) patch I propose the attached patch. It's an extended version of Paul's patch from comment #5, plus Mikael's comment #10. It makes Salvatore's PSBLAS compile completely (at least the version I have). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41784
[Bug debug/41700] g++.dg/debug/dwarf2/icf.C
--- Comment #7 from sje at cup dot hp dot com 2009-10-23 18:52 --- I haven't had a chance to test it on PA yet but it fixes the problem on Itanium. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41700
[Bug c++/41020] [4.5 Regression] Can't declare an extern C friend of a builtin function
--- Comment #9 from dodji at gcc dot gnu dot org 2009-10-23 19:32 --- Subject: Re: New: Can't declare an extern C friend. Patch submitted to http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01486.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020
[Bug fortran/41784] [OOP] ICE in load_derived_extensions
--- Comment #12 from dominiq at lps dot ens dot fr 2009-10-23 19:34 --- I propose the attached patch. It's an extended version of Paul's patch from comment #5, plus Mikael's comment #10. It makes Salvatore's PSBLAS compile completely (at least the version I have). Does the executable works as expected? Would it be difficult to extract from the PSBLAS code showing the error in comment #8 with the change in comment #7? If I get the code, I can try to do the reduction. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41784
[Bug bootstrap/41529] [4.5 Regression] LTO configuration should detect if the target is ELF
--- Comment #3 from steven at gcc dot gnu dot org 2009-10-23 19:35 --- There is already a patch for this one. Paolo, can you perhaps (as build system maintainer) foster-parent it that patch into the trunk? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||05/msg01609.html Keywords||patch Last reconfirmed|2009-10-03 22:15:50 |2009-10-23 19:35:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529
[Bug bootstrap/41529] [4.5 Regression] LTO configuration should detect if the target is ELF
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-10-23 19:37 --- (In reply to comment #3) There is already a patch for this one. Paolo, can you perhaps (as build system maintainer) foster-parent it that patch into the trunk? I think the patch should be the opposite way around, disabling LTO if the target is not elf since there are fewer non-elf targets than there are elf targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529
[Bug lto/41578] 7% slower runtime with -flto than without
--- Comment #3 from steven at gcc dot gnu dot org 2009-10-23 19:38 --- This one should just be monitored from week to week. There is so much stuff going into the trunk right now that results vary from one day to another by +5% to -5% in the last four days alone. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-23 19:38:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41578
[Bug fortran/41784] [OOP] ICE in load_derived_extensions
--- Comment #13 from sfilippone at uniroma2 dot it 2009-10-23 19:43 --- (In reply to comment #12) I propose the attached patch. It's an extended version of Paul's patch from comment #5, plus Mikael's comment #10. It makes Salvatore's PSBLAS compile completely (at least the version I have). Does the executable works as expected? I have yet to achieve full compilation under gfortran (the patched compiler is bootstrapping right now), and I will have little to no time to test the executables until next week. Would it be difficult to extract from the PSBLAS code showing the error in comment #8 with the change in comment #7? If I get the code, I can try to do the reduction. If error in comment #8 shows up again I will do the reduction asap. The code is a development version, the stable version is already available with a BSD like license, but the F2003 features are only being used in the development (by definition that is highly unstable). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41784
[Bug tree-optimization/41811] graphite miscompiles 454.calculix of the SPEC 2k6
--- Comment #2 from spop at gcc dot gnu dot org 2009-10-23 19:43 --- With -fno-loop-interchange the code generated is correct but strange as the statement S8(scat_1,scat_3) ; does iterate one less time than the other statements of loop scat_3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41811
[Bug tree-optimization/41811] graphite miscompiles 454.calculix of the SPEC 2k6
--- Comment #3 from spop at gcc dot gnu dot org 2009-10-23 19:46 ---
Also with -O3 the code of the loop body looks much nicer: several statements
disappear as they do not contain code anymore: so we have this LST
transformed_lst (
(root
0 (loop
0 (loop
0 stmt_4
1 (loop
0 stmt_5)
2 stmt_7
3 stmt_18
and the code generated by CLooG for the interchange looks like this:
for (scat_1=0;scat_1=2;scat_1++) {
for (scat_3=0;scat_3=2;scat_3++) {
S4(scat_1,scat_3) ;
for (scat_5=0;scat_5=2;scat_5++) {
S5(scat_1,scat_5,scat_3) ;
}
S7(scat_1,scat_3) ;
S18(scat_1,scat_3) ;
}
for (scat_3=3;scat_3=19;scat_3++) {
for (scat_5=0;scat_5=2;scat_5++) {
S5(scat_1,scat_5,scat_3) ;
}
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41811
Re: [Bug tree-optimization/41811] graphite miscompiles 454.calculix of the SPEC 2k6
On Fri, Oct 23, 2009 at 14:46, spop at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
and the code generated by CLooG for the interchange looks like this:
for (scat_1=0;scat_1=2;scat_1++) {
for (scat_3=0;scat_3=2;scat_3++) {
S4(scat_1,scat_3) ;
for (scat_5=0;scat_5=2;scat_5++) {
S5(scat_1,scat_5,scat_3) ;
}
S7(scat_1,scat_3) ;
S18(scat_1,scat_3) ;
}
S7 and S18 should not be generated before S5 finishes to execute over
all the iterations of the original innermost loop (do k=1,20).
S7 and S18 contain the end of the reduction and the write in the array
xs(i,j) that is independent of the k loop.
for (scat_3=3;scat_3=19;scat_3++) {
for (scat_5=0;scat_5=2;scat_5++) {
S5(scat_1,scat_5,scat_3) ;
}
}
}
[Bug tree-optimization/41811] graphite miscompiles 454.calculix of the SPEC 2k6
--- Comment #4 from sebpop at gmail dot com 2009-10-23 19:54 ---
Subject: Re: graphite miscompiles 454.calculix
of the SPEC 2k6
On Fri, Oct 23, 2009 at 14:46, spop at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
and the code generated by CLooG for the interchange looks like this:
for (scat_1=0;scat_1=2;scat_1++) {
 for (scat_3=0;scat_3=2;scat_3++) {
  S4(scat_1,scat_3) ;
  for (scat_5=0;scat_5=2;scat_5++) {
   S5(scat_1,scat_5,scat_3) ;
  }
  S7(scat_1,scat_3) ;
  S18(scat_1,scat_3) ;
 }
S7 and S18 should not be generated before S5 finishes to execute over
all the iterations of the original innermost loop (do k=1,20).
S7 and S18 contain the end of the reduction and the write in the array
xs(i,j) that is independent of the k loop.
 for (scat_3=3;scat_3=19;scat_3++) {
  for (scat_5=0;scat_5=2;scat_5++) {
   S5(scat_1,scat_5,scat_3) ;
  }
 }
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41811
[Bug debug/41700] g++.dg/debug/dwarf2/icf.C
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2009-10-23 19:56 --- Subject: Re: g++.dg/debug/dwarf2/icf.C I haven't had a chance to test it on PA yet but it fixes the problem on Itanium. It fixes the test on hppa64-hp-hpux11.11. Will test hppa2.0w-hp-hpux11.11 tonight. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41700
[Bug bootstrap/41399] [4.5 Regression] Internal error compiling fortran/intrinsic.c
-- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-23 20:39:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41399
[Bug fortran/41784] [OOP] ICE in load_derived_extensions
--- Comment #14 from sfilippone at uniroma2 dot it 2009-10-23 20:40 --- I can confirm that my code compiles now. Whether it runs is an entirely different matter, which I will look at in the next few days... Salvatore -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41784
[Bug tree-optimization/41811] graphite miscompiles 454.calculix of the SPEC 2k6
--- Comment #5 from spop at gcc dot gnu dot org 2009-10-23 20:52 --- The data dependence analysis is not instructed that the iteration domain of the k loop will be splitted, and thus it answers interchanging stmt_5 is a correct transform. To correct this problem we have to distribute the loop such that we will ask the question is it legal to transform the loops to be interchanged around stmt_5 in a perfect loop nest? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41811
[Bug c++/40808] [4.4/4.5 regression] member template specialization causes ICE
--- Comment #3 from dodji at gcc dot gnu dot org 2009-10-23 21:32 --- Subject: Bug 40808 Author: dodji Date: Fri Oct 23 21:32:35 2009 New Revision: 153516 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153516 Log: Fix for PR c++/40808 gcc/cp/ChangeLog: PR c++/40808 * mangle.c (write_template_args): Allow mangling of empty template argument list. Updated function comments. gcc/testsuite/ChangeLog: PR c++/40808 * g++.dg/abi/mangle33.C: New test Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/abi/mangle34.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/mangle.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40808
[Bug c++/40808] [4.4/4.5 regression] member template specialization causes ICE
--- Comment #4 from dodji at gcc dot gnu dot org 2009-10-23 21:39 --- Subject: Bug 40808 Author: dodji Date: Fri Oct 23 21:38:50 2009 New Revision: 153517 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153517 Log: Fix for PR c++/40808 gcc/cp/ChangeLog: PR c++/40808 * mangle.c (write_template_args): Allow mangling of empty template argument list. Updated function comments. gcc/testsuite/ChangeLog: PR c++/40808 * g++.dg/abi/mangle34.C: New test Added: trunk/gcc/testsuite/g++.dg/abi/mangle34.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40808
[Bug c/40033] [4.5 regression] ICE with invalid statement expression
--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-10-23 21:39 --- Testing a patch. The C++ problem mentioned in comment#1 is definitely unrelated to this bug and needs to be reported as a separate bug. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jsm28 at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-23 21:39:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40033
[Bug c++/40808] [4.4/4.5 regression] member template specialization causes ICE
--- Comment #5 from dodji at gcc dot gnu dot org 2009-10-23 21:42 --- Fixed in 4.4 and 4.5 -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40808
[Bug c++/39987] [4.3 Regression] Rejects default argument that is a template via access failure
-- dodji at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.5.0 |4.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39987
[Bug tree-optimization/41740] [4.5 Regression] ICE in ipcp_analyze_node, at ipa-cp.c:183
--- Comment #9 from denis dot onischenko at gmail dot com 2009-10-23 21:50 --- In revision 153504 this error is no longer reproduced -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41740
[Bug lto/41578] 7% slower runtime with -flto than without
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-23 22:27 --- The bugreport is not useful in its current form anyway (no testcase). Let's close it. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41578
[Bug tree-optimization/40556] [4.5 Regression] ICE in IPA-CP with recursion
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-10-23 22:28 --- *** Bug 41740 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||denis dot onischenko at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40556
[Bug tree-optimization/41740] [4.5 Regression] ICE in ipcp_analyze_node, at ipa-cp.c:183
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-10-23 22:28 --- So it was indeed a dup. *** This bug has been marked as a duplicate of 40556 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41740
[Bug middle-end/41611] [4.5 Regression] guard variable is emitted even when the guarded symbol isn't
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-10-23 23:46 --- This really should be a P1, I ran into this with a benchmark we have here internally. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41611
[Bug middle-end/41611] [4.5 Regression] guard variable is emitted even when the guarded symbol isn't
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-10-23 23:49 --- I almost want to say it was caused by: 2009-06-15 Rafael Avila de Espindola espind...@google.com * cp-objcp-common.h (LANG_HOOKS_COMDAT_GROUP): Remove. * cp-tree.h (cxx_comdat_group): Change signature. * decl.c (duplicate_decls): Use DECL_COMDAT_GROUP. (cxx_comdat_group): Change signature. * decl2.c (comdat_linkage, maybe_make_one_only): Update call to make_decl_one_only. (constrain_visibility, get_guard): Use DECL_COMDAT_GROUP. * method.c (use_thunk): Update call to make_decl_one_only. * optimize.c (maybe_clone_body): Use DECL_COMDAT_GROUP -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||espindola at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41611
[Bug middle-end/41812] New: test 20071030-1.c fails execution on powerpc64
Test gcc.c-torture/execute/20071030-2.c has been failing execution for -m64 with option lists including -O2 and -O3 since this patch was added to trunk: http://gcc.gnu.org/viewcvs?view=revrev=149011 r149011 | bonzini | 2009-06-27 14:50:00 + (Sat, 27 Jun 2009) That patch was added shortly before another one that broke bootstrap, as reported in PR 40597, and this test failure was then lost in the noise. I'll attach a shorter testcase that demonstrates the problem. -- Summary: test 20071030-1.c fails execution on powerpc64 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41812
[Bug middle-end/41812] test 20071030-1.c fails execution on powerpc64
--- Comment #1 from janis at gcc dot gnu dot org 2009-10-23 23:50 --- Created an attachment (id=18884) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18884action=view) minimized testcase Minimized testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41812
[Bug c/40033] [4.5 regression] ICE with invalid statement expression
--- Comment #3 from jsm28 at gcc dot gnu dot org 2009-10-24 00:44 --- Subject: Bug 40033 Author: jsm28 Date: Sat Oct 24 00:44:17 2009 New Revision: 153522 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153522 Log: PR c/40033 * c-typeck.c (c_finish_stmt_expr): Do not wrap error_mark_node in a C_MAYBE_CONST_EXPR. testsuite: * gcc.dg/noncompile/pr40033-1.c: New test. Added: trunk/gcc/testsuite/gcc.dg/noncompile/pr40033-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40033
[Bug c/40033] [4.5 regression] ICE with invalid statement expression
--- Comment #4 from jsm28 at gcc dot gnu dot org 2009-10-24 00:45 --- Fixed for 4.5. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.5.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40033
[Bug target/41813] New: [4.5 Regression] SH: delay slot is filled with a wrong insn
gcc.dg/pr28796-2.c execution test fails on sh for a while. There is a wrong code like fcmp/eq dr2,dr4 bf/s.L93 fcmp/gt dr2,dr4 bra .L92 movtr2 which should be fcmp/eq dr2,dr4 bf/s.L53 movtr2 .L92: ... .L53: fcmp/gt dr2,dr4 .L93: i.e. a delay slot is filled with a wrong insn. It stated to fail between revision 152230 and 152317 but it seems there are no related changes. Perhaps some changes revealed this latent problem. -- Summary: [4.5 Regression] SH: delay slot is filled with a wrong insn Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kkojima at gcc dot gnu dot org GCC target triplet: sh4-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41813
[Bug target/41813] [4.5 Regression] SH: delay slot is filled with a wrong insn
--- Comment #1 from kkojima at gcc dot gnu dot org 2009-10-24 00:48 ---
For a slightly reduced case, the insns before dbr pass are
configured like as:
(insn 460 456 461
(parallel [(set (reg:SI 147 t)
(eq:SI (reg:DF 68 fr4) (reg:DF 66 fr2)))
(use (reg/v:PSI 151 ))]) {cmpeqdf_t})
(jump_insn 461 460 575
(set (pc) (if_then_else (eq (reg:SI 147 t) (const_int 0))
(label_ref:SI 571) (pc))) {branch_false})
(insn 575 461 576
(parallel [(set (pc) (unspec [(const_int 200) (pc)] 4))
(set (reg:SI 147 t) (const_int 1 [0x1]))]) {stuff_delay_slot})
(insn 576 575 572
(set (pc) (unspec [(const_int 200)] 4)))
(jump_insn 572 576 573
(set (pc) (label_ref 200)))
...
(code_label 200 198 263 25 [1 uses])
(note 263 200 202 [bb 20] NOTE_INSN_BASIC_BLOCK)
(insn 202 263 203
(set (reg:QI 2 r2) (reg:QI 147 t)) {movqi_i})
...
(code_label 571 573 501 85 [1 uses])
(note 501 571 502 [bb 32] NOTE_INSN_BASIC_BLOCK)
(jump_insn 502 501 503
(set (pc) (label_ref 471)) {jump_compact})
...
(code_label 471 497 262 53 [2 uses])
(note 262 471 199 [bb 29] NOTE_INSN_BASIC_BLOCK)
(insn 199 262 449
(parallel [(set (reg:SI 147 t)
(gt:SI (reg:DF 68 fr4) (reg:DF 66 fr2)))
(use (reg/v:PSI 151 ))]) {cmpgtdf_t})
and fill_slots_from_thread takes insn 199 as an insn
filling the delay slot of jump_insn 461. When this is done,
the opposite thread is started with stuff_delay_slot having
(set (reg T_REG) (const_int 1)) sub-pattern which makes
the live register analysis consider T_REG is defined here.
Thus fill_slots_from_thread takes insn 199 which changes
T_REG in spite of insn 202 in the opposite thread which
expects the original T_REG value. It seems that the pattern
(set (reg T_REG) ... in stuff_delay_slot insn is the cause
of this problem and stuff_delay_slot is simply used as
a unique marker. I'm testing the patch below.
--- ORIG/trunk/gcc/config/sh/sh.md 2009-08-13 09:46:10.0 +0900
+++ trunk/gcc/config/sh/sh.md 2009-10-23 17:07:19.0 +0900
@@ -6825,7 +6825,7 @@ label:
(define_insn stuff_delay_slot
[(set (pc)
(unspec [(match_operand:SI 0 const_int_operand ) (pc)] UNSPEC_BBR))
- (set (reg:SI T_REG) (match_operand:SI 1 const_int_operand ))]
+ (match_operand:SI 1 const_int_operand )]
TARGET_SH1
[(set_attr length 0)
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41813
[Bug bootstrap/40923] bootstrap failure for 20090730 with --enable-build-with-cxx
-- jlquinn at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-24 04:04:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40923
[Bug bootstrap/40923] bootstrap failure for 20090730 with --enable-build-with-cxx
--- Comment #3 from jlquinn at gcc dot gnu dot org 2009-10-24 04:06 --- Created an attachment (id=18885) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18885action=view) Candidate patch This fixes the bootstrap, though a bunch of plugin tests fail compared to unpatched build with C. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40923
[Bug c++/7740] builtins, and functions marked as extern C++ with incorrect C linkage
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-06-19 15:04:17 |2009-10-24 05:15:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7740
[Bug c++/7740] builtins, and functions marked as extern C++ with incorrect C linkage
--- Comment #6 from jason at gcc dot gnu dot org 2009-10-24 05:16 --- Fixed by the patch for PR 37276. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7740
