[Bug fortran/45827] [4.6 Regression] [OOP] mio_component_ref(): Component not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827 --- Comment #37 from janus at gcc dot gnu.org 2010-12-28 08:14:46 UTC --- (In reply to comment #36) (In reply to comment #35) Yes, I think I know what's going on. One way to fix it is the following: I managed to get an ICE with your version (sym == NULL) No, that's not possible. My version (i.e. comment #35) is inserted at a slightly different place than yours, where the existence of 'sym' is already established. Also I have checked that it regtests cleanly. Ok if I commit it to trunk?
[Bug ada/47056] [4.6 Regression] 10 Ada ACATS tests fail to link with undefined reference on ia64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47056 --- Comment #2 from Laurent GUERBY laurent at guerby dot net 2010-12-28 08:48:11 UTC --- Reduced test case: procedure C390002 is type Object is tagged null record; begin null; end C390002; gue...@babe:~/tmp$ gnatmake -f -O1 c390002.adb gcc -c -O1 c390002.adb gnatbind -x c390002.ali gnatlink c390002.ali -O1 ./c390002.o: In function `_ada_c390002': c390002.adb:(.text+0x661): undefined reference to `c390002___alignment.1835' c390002.adb:(.text+0x6a1): undefined reference to `c390002__objectSR.1844' c390002.adb:(.text+0x6e1): undefined reference to `c390002__objectSW.1850' c390002.adb:(.text+0x771): undefined reference to `c390002__objectSO.1861' c390002.adb:(.text+0x7b1): undefined reference to `c390002__Oeq.1865' c390002.adb:(.text+0x7f1): undefined reference to `c390002___assign.1869' c390002.adb:(.text+0x831): undefined reference to `c390002__objectDA.1887' c390002.adb:(.text+0x871): undefined reference to `c390002__objectDF.1891' collect2: ld returned 1 exit status gnatlink: error when calling /home/guerby/install-trunk/bin/gcc gnatmake: *** link failed. gue...@babe:~/tmp$ gnatmake -f -O0 c390002.adb gcc -c -O0 c390002.adb gnatbind -x c390002.ali gnatlink c390002.ali -O0 gue...@babe:~/tmp$
[Bug c++/47074] New: tree check fail in create_access_replacement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47074 Summary: tree check fail in create_access_replacement Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 22855 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22855 gzipped C++ source code I just tried to compile package freefem++-3.11 with the latest 4.6 snapshot 20101225 on a Linux x86_64 box. The compiler said array_long.cpp:167:1: internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'pointer_type' in create_access_replacement, at tree-sra.c:1679 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Source code attached. Flag -O2 required.
[Bug fortran/46838] [OOP] Initialization of polymorphic allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46838
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2010.12.28 10:52:23
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
Summary|[OOP] Wrong allocation |[OOP] Initialization of
|status for polymorphic |polymorphic allocatable
|component INTENT(OUT) dummy |components
Ever Confirmed|0 |1
--- Comment #4 from janus at gcc dot gnu.org 2010-12-28 10:52:23 UTC ---
(In reply to comment #2)
The default initializer is obtained via expr.c's gfc_default_initializer.
Indeed this is the place where things go wrong. Here's a patch:
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(revision 168277)
+++ gcc/fortran/expr.c(working copy)
@@ -3648,7 +3648,8 @@ gfc_default_initializer (gfc_typespec *ts)
/* See if we have a default initializer in this, but not in nested
types (otherwise we could use gfc_has_default_initializer()). */
for (comp = ts-u.derived-components; comp; comp = comp-next)
-if (comp-initializer || comp-attr.allocatable)
+if (comp-initializer || comp-attr.allocatable
+|| (comp-ts.type == BT_CLASS CLASS_DATA (comp)-attr.allocatable))
break;
if (!comp)
@@ -3664,8 +3665,9 @@ gfc_default_initializer (gfc_typespec *ts)
if (comp-initializer)
ctor-expr = gfc_copy_expr (comp-initializer);
-
- if (comp-attr.allocatable)
+ else if (comp-attr.allocatable
+ || (comp-ts.type == BT_CLASS
+CLASS_DATA (comp)-attr.allocatable))
{
ctor-expr = gfc_get_expr ();
ctor-expr-expr_type = EXPR_NULL;
This fixes the test case in comment #1. However, I was not able to see a
failure with the test case in comment #0. Salvatore, can you check whether the
patch cures your troubles?
[Bug fortran/45827] [4.6 Regression] [OOP] mio_component_ref(): Component not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827 --- Comment #38 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-28 12:22:48 UTC --- Created attachment 22856 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22856 testcase, ICE with patch in comment #35 (In reply to comment #37) I managed to get an ICE with your version (sym == NULL) No, that's not possible. My version (i.e. comment #35) is inserted at a slightly different place than yours, where the existence of 'sym' is already established. Err, sure it is possible: + if (sym-attr.is_class) + sym = sym-components-ts.u.derived; After this, sym is not checked any more and the ICE occurs in the next line: if (sym-components != NULL p-u.pointer == NULL) ^^^ That's why I moved it up a few lines and double check that sym really is non-NULL.
[Bug fortran/46838] [OOP] Initialization of polymorphic allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46838
--- Comment #5 from janus at gcc dot gnu.org 2010-12-28 12:51:22 UTC ---
(In reply to comment #4)
Here's a patch:
The patch in comment #4 had a few regressions (e.g. on alloc_comp_basics_1.f90
etc), but the following version regtests cleanly:
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(revision 168293)
+++ gcc/fortran/expr.c(working copy)
@@ -3648,7 +3648,8 @@ gfc_default_initializer (gfc_typespec *ts)
/* See if we have a default initializer in this, but not in nested
types (otherwise we could use gfc_has_default_initializer()). */
for (comp = ts-u.derived-components; comp; comp = comp-next)
-if (comp-initializer || comp-attr.allocatable)
+if (comp-initializer || comp-attr.allocatable
+|| (comp-ts.type == BT_CLASS CLASS_DATA (comp)-attr.allocatable))
break;
if (!comp)
@@ -3665,7 +3666,8 @@ gfc_default_initializer (gfc_typespec *ts)
if (comp-initializer)
ctor-expr = gfc_copy_expr (comp-initializer);
- if (comp-attr.allocatable)
+ if (comp-attr.allocatable
+ || (comp-ts.type == BT_CLASS CLASS_DATA (comp)-attr.allocatable))
{
ctor-expr = gfc_get_expr ();
ctor-expr-expr_type = EXPR_NULL;
[Bug fortran/45827] [4.6 Regression] [OOP] mio_component_ref(): Component not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827 --- Comment #39 from janus at gcc dot gnu.org 2010-12-28 13:18:41 UTC --- (In reply to comment #38) I managed to get an ICE with your version (sym == NULL) No, that's not possible. My version (i.e. comment #35) is inserted at a slightly different place than yours, where the existence of 'sym' is already established. Err, sure it is possible: Ok, I get it. Sorry about the misconception. Feel free to commit the patch in comment #36 (provided it regtests ok). Or should I take care of it?
[Bug fortran/46838] [OOP] Initialization of polymorphic allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46838 --- Comment #6 from Salvatore Filippone sfilippone at uniroma2 dot it 2010-12-28 13:40:52 UTC --- (In reply to comment #5) (In reply to comment #4) Here's a patch: The patch in comment #4 had a few regressions (e.g. on alloc_comp_basics_1.f90 etc), but the following version regtests cleanly: For me, it cures the reduced test case (bug28.f90) in comment #0, so it's definitely a step in the right direction. Unfortunately in the full application I still get this: [localhost:15473] Signal: Segmentation fault (11) [localhost:15473] Signal code: Address not mapped (1) [localhost:15473] Failing at address: 0x1344133b [localhost:15472] [ 0] /lib64/libpthread.so.0(+0xf4a0) [0x7fae89b8b4a0] [localhost:15472] [ 1] /lib64/libc.so.6(cfree+0x1c) [0x7fae898782dc] [localhost:15472] [ 2] ./ppde(__copy_psb_gen_block_map_mod_psb_gen_block_map_+0x143) [0x4c45b3] [localhost:15472] [ 3] ./ppde(psb_cdcpy_+0x700) [0x4bf850] [localhost:15472] [ 4] ./ppde(psb_dcdbldext_+0x7e2) [0x4b2762] [localhost:15472] [ 5] ./ppde() [0x41985f] [localhost:15472] [ 6] ./ppde() [0x41c6dd] [localhost:15472] [ 7] /lib64/libc.so.6(__libc_start_main+0xfd) [0x7fae8981cc5d] [localhost:15472] [ 8] ./ppde() [0x418ef9] [localhost:15472] *** End of error message *** I suppose this means that the original test case did not catch all there was; I guess it would be best to declare this fixed and open a new one, as soon as I have time to get a new reduced test case.
[Bug middle-end/46597] configure -enable-checking=... -enable-build-with-cxx and bootstrap is g++ 3.3 hit minor problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46597 --- Comment #1 from Jay jay.krell at cornell dot edu 2010-12-28 13:50:06 UTC --- I put #define ENABLE_CHECKING_GCC_VERSION ((GCC_VERSION 3003) || (!defined(__cplusplus) (GCC_VERSION 2007))) in include/ansidecl.h after #define GCC_VERSION and I this with the #if FOO_CHECKING in rtl.h, tree.h, ira-int.h. Alternatively, reject g++ 3.4 entirely, or if enable-checking. Or, well, I'm using -disable-bootstrap, and probably checking is never enabled in the first phase anyway, so this all would just work if I didn't use that. The patch is ok, but it might never make a difference if I didn't -disable-bootstrap. But I really really really like -disable-bootstrap, given how little I build, which is still a very useful amount, it saves a ton (just libbackend.a and a small frontend, no libraries, and I patched out gmp/mpfr/mpc dependencies, so overall build is short even on slower machines (we run a range of machines..)).
[Bug tree-optimization/46801] [4.6 Regression] FAIL: gnat.dg/pack9.adb scan-tree-dump-not optimized gnat_rcheck
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46801 --- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org 2010-12-28 14:36:58 UTC --- This seems to be a fallout from the fix to PR 46351 and PR 46377 (revision 166535, patch at http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00933.html). The problem is that struct pack9__copy__t___PAD apparently contains aggregate bit-fields which we reject in type_internals_preclude_sra_p even before we make the variable a candidate. This seems to be a good reason to have another look at the rather crude fix, although my still fresh memories of the bit-field mess make me refrain from any promises of a quick better solution.
[Bug ada/47017] [4.6 Regression] gnatlib ICE on sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47017 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug rtl-optimization/47010] Missed optimization: x86-64 prologue not deleted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47010 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-28 14:50:51 UTC --- I think it sets up a frame to have possible spills of xmm registers land in aligned stack slots.
[Bug ada/47005] [4.6 Regression] ACATS c62002a wrong code on arm-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug target/47000] [4.5 Regression] Failure to inline SSE intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47000 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.5.3 --- Comment #27 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-28 14:57:37 UTC --- (In reply to comment #24) VCE is often very expensive though (often a memory store followed by memory load into a different register, etc.), so 0 unconditionally is IMHO wrong. Perhaps for some TYPE_MODE combinations at most. I think assuming VCE is zero-cost on the tree level makes sense though, as they tend to get away usually (that is, when they appear in regular code, not as a result of weird type punnings).
[Bug tree-optimization/47061] VRP doesn't propagate through x=1, but it does for x*=2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47061 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.28 15:04:25 CC||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-28 15:04:25 UTC --- VRP needs a lot of TLC with respect to how it treats ranges with constant bounds. Yes, it doesn't handle shifts at all at the moment.
[Bug ada/47056] [4.6 Regression] 10 Ada ACATS tests fail to link with undefined reference on ia64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47056 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.28 15:21:44 Version|unknown |4.6.0 Ever Confirmed|0 |1 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-12-28 15:21:44 UTC --- I took one of the test and it fails to link at -O2 and -O1 but works and PASS at -O0, see below. So I'm assuming some optimization is creating the issue, any idea on what to look for? Probably a hole related to descriptors in reachability analysis. The dump file .043i.whole-program contains: Reclaiming functions: P.Objectdf P.Objectda P P.= P.Objectso P.Objectsw P.Objectsr P
[Bug ada/47056] [4.6 Regression] 10 Ada ACATS tests fail to link with undefined reference on ia64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47056 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC|ebotcazou at gcc dot| |gnu.org | AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-12-28 15:23:28 UTC --- Investigating.
[Bug target/47038] [4.6 Regression] failure of gcc.dg/pr46685.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47038 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0 Summary|gcc.dg/pr46685.c FAILs on |[4.6 Regression] failure of |Solaris 10/SPARC|gcc.dg/pr46685.c
[Bug c++/47068] [C++0x] internal compiler error on decltype(~ expression)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47068 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2010-12-28 15:34:44 UTC --- Looking.
[Bug objc/47075] New: Missed deprecation warnings for @property when using getter/setter directly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47075
Summary: Missed deprecation warnings for @property when using
getter/setter directly
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org
When you deprecate a @property, and then use the getter/setter directly, no
deprecation warning is currently produced. That is, the following fails --
/* Contributed by Nicola Pero nicola.p...@meta-innovation.com, October 2010.
*/
/* { dg-do compile } */
/* Test that deprecation warnings are produced when a setter/getter of
a @property is used directly. */
#include objc/objc.h
@interface MyClass
{
Class isa;
int variable;
}
@property (assign, nonatomic) int property __attribute__ ((deprecated));
@end
void foo (void)
{
MyClass *object = nil;
if ([object property] 0) /* { dg-warning is deprecated } */
{
[object setProperty: 43]; /* { dg-warning is deprecated } */
}
}
Thanks
[Bug objc/47075] Missed deprecation warnings for @property when using getter/setter directly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47075 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.28 15:40:37 Ever Confirmed|0 |1 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2010-12-28 15:40:37 UTC --- Confirmed. Thanks
[Bug fortran/47051] [4.6 Regression] wrong reallocate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47051 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug rtl-optimization/47036] [4.6 Regression] ICE: in move_cond_jump, at sel-sched.c:4901 with -fschedule-insns -fselective-scheduling -fno-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47036 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug regression/47037] 465.tonto Segmentation Fault in memset with -fcaller-saves (default at -O2 or higher)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47037 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.12.28 16:06:39 Ever Confirmed|0 |1 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-28 16:06:39 UTC --- Does your glibc have CPU specific optimizations?
[Bug target/47032] libgfortran references complex long double functions missing on AIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47032 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||build Target||powerpc-ibm-aix --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-28 16:09:49 UTC --- David, does GCC 4.5.x build on AIX?
[Bug other/47029] fixincludes: the fix for c99 inlines in the glibc header files fixes function declarations as well as function definitions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47029 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.12.28 16:11:23 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-28 16:11:23 UTC --- The glibc is a little bit old. Please attach the headerfile.
[Bug middle-end/47033] loop distribution has problems on sane testcases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47033 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||spop at gcc dot gnu.org --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-28 16:11:35 UTC --- I suppose the same problem can be seen if you make the function artificially hot by calling it from inside a loop.
[Bug target/47025] Dead stores in varadic functions not eliminated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47025
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2010.12.28 16:19:51
CC||rguenth at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-28
16:19:51 UTC ---
I think this is because ap is thought to escape to __builtin_va_start (which
also makes it address-taken), same for __builtin_va_end. Now, with
__builtin_va_end there is the problem that it also constitutes a use of
ap and what that points to.
bb 2:
__builtin_va_start (ap, 0);
D.2726_2 = ap.fp_offset;
if (D.2726_2 = 176)
goto bb 4;
else
goto bb 3;
bb 3:
D.2728_3 = ap.reg_save_area;
D.2726_4 = ap.fp_offset;
D.2729_5 = (long unsigned int) D.2726_4;
addr.0_6 = D.2728_3 + D.2729_5;
D.2726_7 = ap.fp_offset;
D.2730_8 = D.2726_7 + 16;
ap.fp_offset = D.2730_8;
goto bb 5;
bb 4:
addr.0_9 = ap.overflow_arg_area;
D.2732_11 = addr.0_9 + 8;
ap.overflow_arg_area = D.2732_11;
bb 5:
# addr.0_1 = PHI addr.0_6(3), addr.0_9(4)
d.1_12 = MEM[(double * {ref-all})addr.0_1];
d = d.1_12;
__builtin_va_end (ap);
return;
so the question is really what __builtin_va_end is allowed to do
(that ap doesn't escape to those fns is obvious and easy to fix).
[Bug objc/47076] New: Protocol referenced in @interface declarations should be defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47076
Summary: Protocol referenced in @interface declarations should
be defined
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org
All the protocols in the list of protocols in an @interface declaration should
have been defined; forward-references are not enough. Here is a testcase --
/* Contributed by Nicola Pero nicola.p...@meta-innovation.com, December 2010.
*/
/* { dg-do compile } */
/* Test that all protocols appearing in @interface declarations are
real (ie, we saw a full @protocol definition with list of methods),
and not just forward-references (ie, @protocol NSObject;). */
#include objc/objc.h
@protocol MyProtocol;
@protocol MyProtocol2
- (int)method2;
@end
@interface MyClass MyProtocol /* { dg-warning definition of protocol
.MyProtocol. not found } */
@end
@interface MyClass2 MyProtocol2 /* Ok */
@end
@interface MyClass2 (Category) MyProtocol /* { dg-warning definition of
protocol .MyProtocol. not found } */
@end
Thanks
[Bug objc/47076] Protocol referenced in @interface declarations should be defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47076 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.28 16:30:49 Ever Confirmed|0 |1 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2010-12-28 16:30:49 UTC --- Confirmed Thanks
[Bug target/47025] Dead stores in varadic functions not eliminated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47025 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-28 16:41:36 UTC --- Created attachment 22857 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22857 patch The attached patch makes us remove the stores on the tree level (on x86_64 the testcase has the stores removed on RTL already, at least on trunk).
[Bug middle-end/47019] [4.6 Regression] ICE: in rename_uses, at sese.c:535 with -O -ftree-pre -fgraphite-identity -fno-tree-copy-prop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47019 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug c++/47022] [4.6 Regression] ICE: in tsubst_copy, at cp/pt.c:11682
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47022 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug c++/47074] [4.6 Regression] tree check fail in create_access_replacement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47074 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||jamborm at gcc dot gnu.org Target Milestone|--- |4.6.0 Summary|tree check fail in |[4.6 Regression] tree check |create_access_replacement |fail in ||create_access_replacement
[Bug other/47062] -mfpmath=sse,387 causes pow() to produce incorrect results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47062 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.12.28 16:50:07 Ever Confirmed|0 |1
[Bug objc/47077] New: ICE on invalid code (method implementation outside of implementation context)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47077
Summary: ICE on invalid code (method implementation outside of
implementation context)
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org
Here is a minimal testcase --
- (int) method: (int)argument
{
return argument;
}
The crash is due to the fact that, when we find a method outside an
implementation context, we don't even create a function context. So, all the
code in the method will be parsed in a void and crash the compiler at the first
reference to the local bind or such like.
We most likely ought to review the code start/closing the method, and if the
method is outside of an implementation context, start/close it normally but
without associating it with a class. I suppose 'self' could be set to be of
type 'id'.
Thanks
[Bug fortran/45827] [4.6 Regression] [OOP] mio_component_ref(): Component not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827 --- Comment #40 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-28 17:27:00 UTC --- (In reply to comment #39) Ok, I get it. Sorry about the misconception. Feel free to commit the patch in comment #36 (provided it regtests ok). Or should I take care of it? Please, you did the hard work - it's yours :) Regression tested on i686-pc-linux-gnu - there is one regression in realloc_on_assign_2.f03, but that does not seem to be related to this patch?!
[Bug objc/47078] New: ICE on invalid type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47078
Summary: ICE on invalid type
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org
The following minimal testcase seems to crash the compiler --
@implementation MyClass
- (x) method
{
return 0;
}
@end
Thanks
[Bug fortran/44232] function result with pointer to strided component of argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44232 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.12.28 17:55:10 CC||dfranke at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #13 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-28 17:55:10 UTC --- Anything new here or can this report be closed?
[Bug fortran/44352] ICE in string_to_single_character
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44352 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||dfranke at gcc dot gnu.org --- Comment #11 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-28 17:59:25 UTC --- Tobias, anything left to do here or can this report be closed?
[Bug debug/47079] New: [4.6 Regression] FAIL: gcc.dg/guality/nrv-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47079 Summary: [4.6 Regression] FAIL: gcc.dg/guality/nrv-1.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: aol...@gcc.gnu.org On Linux/ia32, revision 168160: http://gcc.gnu.org/ml/gcc-cvs/2010-12/msg00845.html caused: FAIL: gcc.dg/guality/nrv-1.c -O1 line 20 a2.i[0] == 42 FAIL: gcc.dg/guality/nrv-1.c -O2 line 20 a2.i[0] == 42 FAIL: gcc.dg/guality/nrv-1.c -Os line 20 a2.i[0] == 42
[Bug c++/47080] New: explicit conversion function return conversions not restricted to qualifications
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47080
Summary: explicit conversion function return conversions not
restricted to qualifications
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schaub.johan...@googlemail.com
n3225 only allows a qualification conversion for the return of an explicit
conversion function when converting to a non-class type:
struct A {
explicit operator int();
};
int main() {
bool b((A())); // should not work
!A(); // should not work!
}
Both are not valid according to 13.3.1.5/1 (second case uses candidate function
provided by 13.6/23, for which the bool parameter uses contextual conversion).
GCC accepts both.
[Bug fortran/45654] -fwhole-file doesn't warn about INTERFACE vs. definition mismatches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45654 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||dfranke at gcc dot gnu.org Blocks||29670 Resolution||DUPLICATE --- Comment #2 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-28 18:23:33 UTC --- Same as #27318. *** This bug has been marked as a duplicate of bug 27318 ***
[Bug fortran/45086] For whole-file checking, also check whether an INTERFACE matches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45086 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added CC||dfranke at gcc dot gnu.org Blocks||29670 --- Comment #3 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-28 18:23:56 UTC --- Same as #27318.
[Bug fortran/27318] gfortran should warn if a interface does not match
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27318 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-28 18:23:33 UTC --- *** Bug 45654 has been marked as a duplicate of this bug. ***
[Bug fortran/27318] gfortran should warn if a interface does not match
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27318 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-28 18:26:20 UTC --- *** Bug 45086 has been marked as a duplicate of this bug. ***
[Bug fortran/33117] Improve error message for generic interface with subroutines functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33117 --- Comment #1 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-28 18:27:08 UTC --- *** Bug 46478 has been marked as a duplicate of this bug. ***
[Bug fortran/45086] For whole-file checking, also check whether an INTERFACE matches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45086 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #4 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-28 18:26:20 UTC --- Bugger, should have been closed as dupe, 2nd try. *** This bug has been marked as a duplicate of bug 27318 ***
[Bug fortran/46478] Missing diagnosis for combining SUBROUTINE and FUNCTION in a GENERIC interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46478 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||dfranke at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-28 18:27:08 UTC --- Same as #33117. *** This bug has been marked as a duplicate of bug 33117 ***
[Bug debug/47079] [4.6 Regression] FAIL: gcc.dg/guality/nrv-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47079 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug fortran/45827] [4.6 Regression] [OOP] mio_component_ref(): Component not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827 --- Comment #41 from janus at gcc dot gnu.org 2010-12-28 18:53:19 UTC --- (In reply to comment #40) Feel free to commit the patch in comment #36 (provided it regtests ok). Or should I take care of it? Please, you did the hard work - it's yours :) Alright, will commit shortly. Regression tested on i686-pc-linux-gnu - there is one regression in realloc_on_assign_2.f03, but that does not seem to be related to this patch?! No, it's unrelated. For me this failure only appears for simple builds, but not if I do a full boostrap. Maybe one should open a PR for it. Anyway, thanks for regtesting.
[Bug c++/47080] explicit conversion function return conversions not restricted to qualifications
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47080
--- Comment #1 from Johannes Schaub schaub.johannes at googlemail dot com
2010-12-28 19:10:25 UTC ---
It should be noted that this can yield to ambiguities in combination with other
conversion functions. Consider
enum E { };
struct A {
explicit operator int();
operator E();
};
bool operator!(E);
int main() {
!A(); // should work, but GCC rejects!
}
In this case, since GCC considers both operator int and operator E for the
contextual conversion to bool, but neither is better than the other, it assigns
the ambiguous conversion sequence for the builtin operator. For conversion to
the E-taking one, it unambiguously uses operator E. Since the ambiguous
conversion sequence cannot be compared to any other conversion sequence, we
have an ambiguity between the builtin operator and our own defined one.
On a n3225-conforming implementation, both operator functions would use
operator E, and then it would be found that operator!(E) matches the return
of the conversion function better than the built-in candidate, and would thus
be selected.
So it's really a rejects-valid, as is basically any C++ issue of this sort
anyway, since they can all be exploited by using SFINAE.
[Bug middle-end/47081] New: Macro usage too clever for localization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47081
Summary: Macro usage too clever for localization
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: goe...@uddeborg.se
In gcc/gentype-state.c there is a macro like this:
#define fatal_reading_state_printf(Tok,Fmt,...) do {\
...
fatal (%s:%d:%d: Invalid state file; Fmt,\
Normally, the first argument to fatal() is extracted for localization. But
that extraction apparently fails here. Each usage of the macro will create a
unique format string to fatal(). But the extractor for localization only
extracts the invariant part that is in the macro, %s:%d:%d: Invalid state
file; . That will never be the string looked up for translation at run time.
And the strings actually looked up are not available in the pot file.
Seen in the po file distributed for 4.6-b20101218.
[Bug middle-end/47081] Macro usage too clever for localization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47081 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2010-12-28 19:21:25 UTC --- I don't know if generator files should be have translated error messages. Unlike other programs, the gen* programs are only used internally inside gcc.
[Bug middle-end/47081] Macro usage too clever for localization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47081 --- Comment #2 from Göran Uddeborg goeran at uddeborg dot se 2010-12-28 19:23:57 UTC --- Oh, I see. You mean this message is never seen by an end user? In that case, maybe they could be excluded from the set of files scanned for messages to translate? Or would that be complex?
[Bug middle-end/47081] Macro usage too clever for localization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47081 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com 2010-12-28 19:44:02 UTC --- On Tue, 28 Dec 2010, pinskia at gcc dot gnu.org wrote: I don't know if generator files should be have translated error messages. Unlike other programs, the gen* programs are only used internally inside gcc. If Basile's proposal to install gengtype goes ahead, then maybe it should all be properly internationalized. Otherwise, gengtype-state.c should be added to po/EXCLUDES.
[Bug fortran/47082] New: [OOP] ICE in gfc_conv_component_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47082 Summary: [OOP] ICE in gfc_conv_component_ref Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sfilipp...@uniroma2.it Created attachment 22858 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22858 test case trunk at r168261: [sfili...@localhost V1]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: posix gcc version 4.6.0 20101227 (experimental) (GCC) [sfili...@localhost V1]$ gfortran -ggdb -fbacktrace bug29_1.f90 -c bug29_1.f90: In function 'psb_cdall': bug29_1.f90:244:0: internal compiler error: in gfc_conv_component_ref, at fortran/trans-expr.c:501 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/47083] New: alpha-dec-osf5.1 fails to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47083
Summary: alpha-dec-osf5.1 fails to build
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Host: x86_64-pc-linux-gnu
Target: alpha-dec-osf5.1
gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-Wold-style-definition -Wc++-compat -fno-common -Wno-error -DHAVE_CONFIG_H -I.
-I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include
-I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include
-I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber../../../gcc/gcc/mips-tfile.c -o mips-tfile.o
../../../gcc/gcc/mips-tfile.c:671:24: fatal error: mips/a.out.h: No such file
or directory
compilation terminated.
make[2]: *** [mips-tfile.o] Error 1
mips-tfile is mentioned in EXTRA_PASSES, because of this stanza in config.gcc:
alpha*-dec-osf5.1*)
if test x$stabs = xyes
then
tm_file=${tm_file} dbx.h
fi
if test x$gas != xyes
then
extra_passes=mips-tfile mips-tdump
fi
[Bug target/47083] alpha-dec-osf5.1 fails to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47083 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2010-12-28 20:15:39 UTC --- This is a dup of the old bug 3746. *** This bug has been marked as a duplicate of bug 3746 ***
[Bug target/3746] compilation of mips-tfile missing mips/a.out.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3746 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||amylaar at gcc dot gnu.org --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org 2010-12-28 20:15:39 UTC --- *** Bug 47083 has been marked as a duplicate of this bug. ***
[Bug debug/46931] [4.6 Regression] Subversion id 167184 breaks building perlbench on power7 with debug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46931 --- Comment #7 from Alexandre Oliva aoliva at gcc dot gnu.org 2010-12-28 20:20:32 UTC --- Author: aoliva Date: Tue Dec 28 20:20:29 2010 New Revision: 168299 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168299 Log: PR debug/46931 * tree-vect-loop-manip.c (slpeel_tree_peel_loop_to_edge): Update SSA before removing dead stmts. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-loop-manip.c
[Bug target/47084] New: am33_2.0-linux fails to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47084 Summary: am33_2.0-linux fails to build Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org CC: ni...@redhat.com Host: x86_64-pc-linux-gnu Target: am33_2.0-linux ../../../gcc/gcc/targhooks.c: In function ‘default_print_operand’: ../../../gcc/gcc/targhooks.c:328:3: error: implicit declaration of function ‘print_operand’ [-Werror=implicit-function-declaration] ../../../gcc/gcc/targhooks.c: In function ‘default_print_operand_address’: ../../../gcc/gcc/targhooks.c:342:3: error: implicit declaration of function ‘print_operand_address’ [-Werror=implicit-function-declaration] cc1: all warnings being treated as errors config/mn10300/linux.h has not been updated in the recent function renamings.
[Bug fortran/47085] New: [OOP] Problem in allocate( SOURCE=) for polymorphic component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47085 Summary: [OOP] Problem in allocate( SOURCE=) for polymorphic component Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sfilipp...@uniroma2.it Created attachment 22859 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22859 test case With trunk at r168261 plus the patch for PR46838 I get the following error when running under valgrind: [sfili...@localhost bug29]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnudev/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-dev/configure --prefix=/usr/local/gnudev --enable-languages=c,c++,fortran --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc : (reconfigured) ../gcc-dev/configure --prefix=/usr/local/gnudev --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: posix gcc version 4.6.0 20101227 (experimental) (GCC) [sfili...@localhost bug29]$ gfortran -o ppde ppde.f90 [sfili...@localhost bug29]$ valgrind ./ppde ==9847== Memcheck, a memory error detector ==9847== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==9847== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==9847== Command: ./ppde ==9847== ==9847== Conditional jump or move depends on uninitialised value(s) ==9847==at 0x400C08: __copy_psb_gen_block_map_mod_psb_gen_block_map_ (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847==by 0x4019C7: psb_cdcpy_ (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847==by 0x401B85: MAIN__ (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847==by 0x401BD9: main (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847== ==9847== Conditional jump or move depends on uninitialised value(s) ==9847==at 0x400C2E: __copy_psb_gen_block_map_mod_psb_gen_block_map_ (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847==by 0x4019C7: psb_cdcpy_ (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847==by 0x401B85: MAIN__ (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847==by 0x401BD9: main (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847== ==9847== Conditional jump or move depends on uninitialised value(s) ==9847==at 0x400C51: __copy_psb_gen_block_map_mod_psb_gen_block_map_ (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847==by 0x4019C7: psb_cdcpy_ (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847==by 0x401B85: MAIN__ (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847==by 0x401BD9: main (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847== ==9847== ==9847== HEAP SUMMARY: ==9847== in use at exit: 648 bytes in 6 blocks ==9847== total heap usage: 22 allocs, 16 frees, 4,473 bytes allocated ==9847== ==9847== LEAK SUMMARY: ==9847==definitely lost: 0 bytes in 0 blocks ==9847==indirectly lost: 0 bytes in 0 blocks ==9847== possibly lost: 0 bytes in 0 blocks ==9847==still reachable: 648 bytes in 6 blocks ==9847== suppressed: 0 bytes in 0 blocks ==9847== Rerun with --leak-check=full to see details of leaked memory ==9847== ==9847== For counts of detected and suppressed errors, rerun with: -v ==9847== Use --track-origins=yes to see where uninitialised values come from ==9847== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 6 from 6) The test case is reduced from a complex application, where the error shows up as follows: [sfili...@localhost runs]$ ./ppde Generating Matrix (size=64)... The matrix has been generated and assembled in CSR format. -allocation time : 1.42813E-04 -coeff. gen. time : 3.26872E-04 -assemblytime : 6.09159E-04 -total time : 1.11485E-03 Overall matrix creation time : 1.47796E-03 Program received signal 11 (SIGSEGV): Segmentation fault. Backtrace for this error: + /lib64/libc.so.6(+0x32970) [0x7fa574efe970] + /lib64/libc.so.6(cfree+0x1c) [0x7fa574f462dc] + function __copy_psb_gen_block_map_mod_psb_gen_block_map_ (0x4382E6) at line 97 of file psb_gen_block_map_mod.f03 + function psb_cdcpy_ (0x420B06) at line 93 of file psb_cdcpy.f90 + function ppde (0x403E4A) at line 82 of file ppde.f90 + /lib64/libc.so.6(__libc_start_main+0xfd) [0x7fa574eeac5d] With the reduced test case the segfault is not apparent, but the cause is still operational.
[Bug tree-optimization/47086] New: ICE: verify_flow_info failed: BB 3 can not throw but has an EH edge with -O -fexceptions -fnon-call-exceptions -ftrapv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47086 Summary: ICE: verify_flow_info failed: BB 3 can not throw but has an EH edge with -O -fexceptions -fnon-call-exceptions -ftrapv Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: ste...@gcc.gnu.org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 22860 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22860 reduced testcase (from gcc.c-torture/execute/pr43220.c) Compiler output: $ gcc -O -fexceptions -fnon-call-exceptions -ftrapv pr47086.c pr47086.c: In function 'foo': pr47086.c:2:1: error: BB 3 can not throw but has an EH edge pr47086.c:2:1: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r168296 - crash I don't know if this is a regression or not.
[Bug tree-optimization/47087] New: ICE: verify_stmts failed: statement marked for throw, but doesn't with -O -fexceptions -fnon-call-exceptions -ftrapv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47087 Summary: ICE: verify_stmts failed: statement marked for throw, but doesn't with -O -fexceptions -fnon-call-exceptions -ftrapv Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: ste...@gcc.gnu.org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 22861 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22861 reduced testcase (from gcc.c-torture/execute/pr43220.c) After submitting PR47086, I noticed the reduced testcase fails with different message than the original testcase. This one shows the same ICE as original testcase. Compiler output: $ gcc -O -fexceptions -fnon-call-exceptions -ftrapv pr47087.c pr47087.c: In function 'foo': pr47087.c:2:1: error: statement marked for throw, but doesn't D.2685_4 = (int) ivtmp.8_32; pr47087.c:2:1: 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. Tested revisions: r168296 - crash I don't know if this is a regression or not.
[Bug debug/46931] [4.6 Regression] Subversion id 167184 breaks building perlbench on power7 with debug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46931 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-28 21:01:08 UTC --- Fixed.
[Bug ada/47005] [4.6 Regression] ACATS c62002a wrong code on arm-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 CC||jakub at gcc dot gnu.org
[Bug ada/47017] [4.6 Regression] gnatlib ICE on sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47017 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 CC||jakub at gcc dot gnu.org
[Bug c++/47074] [4.6 Regression] tree check fail in create_access_replacement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47074 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-28 21:04:26 UTC --- For me it ICEs in build_int_cst_wide, TYPE_CACHED_VALUES has been corrupted, so it looks like a GC issue to me.
[Bug fortran/47082] [OOP] ICE in gfc_conv_component_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47082 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||janus at gcc dot gnu.org --- Comment #1 from janus at gcc dot gnu.org 2010-12-28 21:05:34 UTC --- Here is a reduced test case: module m0 implicit none type :: t0 end type end module module m1 use m0 implicit none type, extends(t0) :: t1 integer, allocatable :: i end type class(t0), pointer, private :: idxmap end module module m2 use m0 implicit none type t2 class(t0), allocatable :: indxmap end type end module program bug29 use m1 use m2 implicit none type(t2) :: desc allocate(t1 :: desc%indxmap) end
[Bug target/47088] New: arm-freebsd6 fails to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47088 Summary: arm-freebsd6 fails to build Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org CC: obr...@freebsd.org, pbr...@gcc.gnu.org Blocks: 44756 Host: x86_64-pc-linux-gnu Target: arm-freebsd6 In file included from ./tm.h:27:0, from ../../../gcc/gcc/gensupport.c:24: ../../../gcc/gcc/config/arm/arm.h:650:0: error: WCHAR_TYPE_SIZE redefined [-Werror] ../../../gcc/gcc/config/arm/freebsd.h:61:0: note: this is the location of the previous definition cc1: all warnings being treated as errors make[2]: *** [build/gensupport.o] Error 1 While the change to config/arm/arm.h in r81665 broke the arm*-*-freebsd* configuration, I think config/arm/freebsd.h was bogus from the start, in defining WCHAR_TYPE_SIZE, but not WCHAR_TYPE.
[Bug fortran/45827] [4.6 Regression] [OOP] mio_component_ref(): Component not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827 --- Comment #42 from janus at gcc dot gnu.org 2010-12-28 21:21:56 UTC --- Author: janus Date: Tue Dec 28 21:21:53 2010 New Revision: 168302 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168302 Log: 2010-12-28 Janus Weil ja...@gcc.gnu.org Daniel Franke dfra...@gcc.gnu.org PR fortran/45827 * module.c (mio_component_ref): Handle components of CLASS variables. 2010-12-28 Janus Weil ja...@gcc.gnu.org PR fortran/45827 * gfortran.dg/class_32.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/class_32.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog
[Bug debug/47079] [4.6 Regression] FAIL: gcc.dg/guality/nrv-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47079 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.12.28 21:30:43 AssignedTo|unassigned at gcc dot |aoliva at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Alexandre Oliva aoliva at gcc dot gnu.org 2010-12-28 21:30:43 UTC --- Mine
[Bug fortran/20896] ambiguous interface not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20896 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|NEW --- Comment #15 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-28 21:41:57 UTC --- (In reply to comment #11) I think this effectively a duplicate of PR 34004. Another possible dupe: PR39290.
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427 --- Comment #24 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-28 21:49:39 UTC --- *** Bug 40824 has been marked as a duplicate of this bug. ***
[Bug fortran/40824] F2003: GENERIC interface with generic name = derived-type name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40824 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||dfranke at gcc dot gnu.org Resolution||DUPLICATE --- Comment #2 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-28 21:49:39 UTC --- Same as the other. *** This bug has been marked as a duplicate of bug 39427 ***
[Bug middle-end/47089] New: ICE: in gimple_redirect_edge_and_branch_force, at tree-cfg.c:5003 with -O -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47089
Summary: ICE: in gimple_redirect_edge_and_branch_force, at
tree-cfg.c:5003 with -O -fgraphite-identity
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: s...@gcc.gnu.org
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 22862
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22862
reduced testcase (from gfortran.dg/debug/pr46576.f)
Compiler output:
$ gcc -O -fgraphite-identity testcase.f
testcase.f:3.72:
ASSIGN 801 TO I800 ! { dg-warning Deleted feature: ASSIGN Delet
1
Warning: Deleted feature: ASSIGN statement at (1)
testcase.f:12.72:
ASSIGN 641 to I640 ! { dg-warning Deleted feature: ASSIGN
1
Warning: Deleted feature: ASSIGN statement at (1)
testcase.f:19.16:
GOTO I640 ! { dg-warning Deleted feature: Assigned Assigned GO
1
Warning: Deleted feature: Assigned GOTO statement at (1)
testcase.f:22.16:
GOTO I800 ! { dg-warning Deleted feature: Assigned Assigned GO
1
Warning: Deleted feature: Assigned GOTO statement at (1)
testcase.f: In function 'MAIN__':
testcase.f:1:0: internal compiler error: in
gimple_redirect_edge_and_branch_force, at tree-cfg.c:5003
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
(gdb) bt
#0 fancy_abort (file=0x11cfb08 /home/smatz/gcc-trunk/gcc/tree-cfg.c,
line=5003, function=0x11d27a0 gimple_redirect_edge_and_branch_force)
at /home/smatz/gcc-trunk/gcc/diagnostic.c:892
#1 0x0094ae39 in gimple_redirect_edge_and_branch_force (e=value
optimized out, dest=value optimized out)
at /home/smatz/gcc-trunk/gcc/tree-cfg.c:5003
#2 gimple_redirect_edge_and_branch_force (e=value optimized out, dest=value
optimized out) at /home/smatz/gcc-trunk/gcc/tree-cfg.c:5000
#3 0x0064be92 in redirect_edge_and_branch_force (e=0x75ccd9c0,
dest=0x75cdbc30) at /home/smatz/gcc-trunk/gcc/cfghooks.c:400
#4 0x0064c961 in make_forwarder_block (bb=0x75cdbc30,
redirect_edge_p=0x1034f90 sd_region_without_exit, new_bb_cbk=0)
at /home/smatz/gcc-trunk/gcc/cfghooks.c:763
#5 0x01037553 in create_single_exit_edge (regions=0x1861320) at
/home/smatz/gcc-trunk/gcc/graphite-scop-detection.c:938
#6 create_sese_edges (regions=0x1861320) at
/home/smatz/gcc-trunk/gcc/graphite-scop-detection.c:1008
#7 0x01037a5a in build_scops (scops=0x7fffd7c8) at
/home/smatz/gcc-trunk/gcc/graphite-scop-detection.c:1306
#8 0x01029a27 in graphite_transform_loops () at
/home/smatz/gcc-trunk/gcc/graphite.c:254
#9 0x00a159d7 in graphite_transforms () at
/home/smatz/gcc-trunk/gcc/tree-ssa-loop.c:296
#10 0x0084fd26 in execute_one_pass (pass=0x16b2a00) at
/home/smatz/gcc-trunk/gcc/passes.c:1553
#11 0x00850015 in execute_pass_list (pass=0x16b2a00) at
/home/smatz/gcc-trunk/gcc/passes.c:1608
#12 0x00850027 in execute_pass_list (pass=0x16b2a60) at
/home/smatz/gcc-trunk/gcc/passes.c:1609
#13 0x00850027 in execute_pass_list (pass=0x16b2d00) at
/home/smatz/gcc-trunk/gcc/passes.c:1609
#14 0x00850027 in execute_pass_list (pass=0x16b1f20) at
/home/smatz/gcc-trunk/gcc/passes.c:1609
#15 0x00990276 in tree_rest_of_compilation (fndecl=0x77fc8d00) at
/home/smatz/gcc-trunk/gcc/tree-optimize.c:422
#16 0x00b55922 in cgraph_expand_function (node=0x75ccc000) at
/home/smatz/gcc-trunk/gcc/cgraphunit.c:1508
#17 0x00b57ffa in cgraph_expand_all_functions () at
/home/smatz/gcc-trunk/gcc/cgraphunit.c:1567
#18 cgraph_optimize () at /home/smatz/gcc-trunk/gcc/cgraphunit.c:1827
#19 0x00b5857a in cgraph_finalize_compilation_unit () at
/home/smatz/gcc-trunk/gcc/cgraphunit.c:1031
#20 0x00808fed in write_global_declarations () at
/home/smatz/gcc-trunk/gcc/langhooks.c:303
#21 0x00939a46 in compile_file (argc=16, argv=0x7fffdb08) at
/home/smatz/gcc-trunk/gcc/toplev.c:591
#22 do_compile (argc=16, argv=0x7fffdb08) at
/home/smatz/gcc-trunk/gcc/toplev.c:1874
#23 toplev_main (argc=16, argv=0x7fffdb08) at
/home/smatz/gcc-trunk/gcc/toplev.c:1937
#24 0x76594bbd in __libc_start_main () from /lib/libc.so.6
#25 0x004fe975 in _start ()
Tested revisions:
r168296 - crash
I don't know if this is a regression or not.
[Bug fortran/45128] Segmentation fault with -fwhole-file for subref_array_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45128 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added CC||dfranke at gcc dot gnu.org --- Comment #5 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-28 22:30:14 UTC --- Isn't this the same as PR34640?
[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640 --- Comment #19 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-28 22:30:10 UTC --- Other potential dupes: PR40737, PR45128.
[Bug fortran/40737] Pointer references sometimes fail to define span symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40737 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added CC||dfranke at gcc dot gnu.org Known to fail|| --- Comment #12 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-28 22:30:16 UTC --- Isn't this the same as PR34640?
[Bug fortran/40899] Leakage with derived types with ALLOCATABLE components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40899 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||dfranke at gcc dot gnu.org Resolution||INVALID --- Comment #3 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-28 22:42:19 UTC --- The quoted clf post does not provide a complete testcase. Closing as INVALID. Please reopen if you feel that this PR should stay alive.
[Bug c/47090] New: Incorrect parsing by ssanf/fscanf with scanset.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47090
Summary: Incorrect parsing by ssanf/fscanf with scanset.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gaven...@gmail.com
This happen with gcc (GCC) 4.3.4 20090804 (release) 1 from Cygwin
and gcc (GCC) 4:4.3.2-2 from Debian.
$ cat 1.c
#include stdio.h
int main()
{
char str[30] = ===;
char ch = '!';
int cnt = sscanf(hello\n, %5s%1[\n], str, ch);
printf(xxx%sxxx\n%d\nyyy%czzz, str, cnt, ch);
return 0;
}
$ gcc 1.c -o 1.exe ./1.exe
xx# I expect get xxxhelloxxx
2
yyy
zzz
$ sed -i 's=%5s=%10s=' 1.c
$ gcc 1.c -o 1.exe ./1.exe
xx# I expect get xxxhelloxxx
2
yyy
zzz
$ sed -i 's=%10s=%4s=' 1.c
xxxhellxxx# Seems all OK
1
yyy!zzz
[Bug fortran/40850] double free in nested types with allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40850 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added Known to fail|| --- Comment #10 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-28 22:55:55 UTC --- This looks like a dupe of the nested constructor case of #38319?!
[Bug c/47090] Incorrect parsing by ssanf/fscanf with scanset.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47090 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2010-12-28 22:58:42 UTC --- GCC does not include sscanf. And can you quote where in the standard it says what the output supposed to be?
[Bug debug/47079] [4.6 Regression] FAIL: gcc.dg/guality/nrv-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47079 --- Comment #2 from Alexandre Oliva aoliva at gcc dot gnu.org 2010-12-28 23:04:39 UTC --- Created attachment 22863 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22863 Patch that fixes the problem Here's the patch that I'm testing.
[Bug fortran/45318] Do more parenthesis simplification with -fno-protect-parens
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45318 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.12.28 23:37:54 CC||dfranke at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-28 23:37:54 UTC --- Given Richard's comments and no testcase, I'm in doubt if this PR is meaningful?!
[Bug tree-optimization/46801] [4.6 Regression] FAIL: gnat.dg/pack9.adb scan-tree-dump-not optimized gnat_rcheck
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46801 --- Comment #7 from Martin Jambor jamborm at gcc dot gnu.org 2010-12-29 00:07:02 UTC --- Proposed fix posted to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01912.html
[Bug target/47091] New: arm-netbsd fails to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47091 Summary: arm-netbsd fails to build Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org Blocks: 44756 Host: x86_64-pc-linux-gnu Target: arm-netbsd ../../../gcc/gcc/config/arm/arm.c:16888:1: error: ‘arm_elf_asm_constructor’ defined but not used [-Werror=unused-function] ../../../gcc/gcc/config/arm/arm.c:16896:1: error: ‘arm_elf_asm_destructor’ defined but not used [-Werror=unused-function] cc1: all warnings being treated as errors The offending functions have ATTRIBUTE_UNUSED prototypes in arm.c, but these prototypes are inside an #ifdef OBJECT_FORMAT_ELF block. Either these prototypes have to be made unconditional, or the function definitions have to be made likewise conditional.
[Bug target/47091] non-elf arm targets fail to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47091 Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed: What|Removed |Added Target|arm-netbsd, arm-pe |arm-netbsd, arm-pe, ||arm-wince-pe Summary|arm-netbsd fails to build |non-elf arm targets fail to ||build --- Comment #1 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2010-12-29 00:40:32 UTC --- The arm-pe / arm-wince-pe targets are saddled with another unused function: ../../../gcc/gcc/config/arm/arm.c:4874:1: error: ‘arm_handle_notshared_attribute’ defined but not used [-Werror=unused-function] Declaration and definition depend on TARGET_DLLIMPORT_DECL_ATTRIBUTES, but the only use also depends on !defined(ARM_PE), and the declaration has no ATTRIBUTE_UNUSED marker.
[Bug fortran/46478] Missing diagnosis for combining SUBROUTINE and FUNCTION in a GENERIC interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46478 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2010.12.29 00:44:29 Resolution|DUPLICATE | Ever Confirmed|0 |1 --- Comment #2 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-29 00:44:29 UTC --- (In reply to comment #1) *** This bug has been marked as a duplicate of bug 33117 *** Too quick - very close, but not a dupe. Reopening.
[Bug middle-end/47092] New: [4.6 Regression] gfortran.fortran-torture/execute/forall_4.f90 is VERY slow with -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47092 Summary: [4.6 Regression] gfortran.fortran-torture/execute/forall_4.f90 is VERY slow with -fgraphite-identity Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: s...@gcc.gnu.org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu $ gfortran-4.4.5 -O -fgraphite-identity forall_4.f90 $ time ./a.out real0m0.002s user0m0.000s sys 0m0.000s $ gfortran-4.5.2 -O -fgraphite-identity forall_4.f90 $ time ./a.out real0m0.002s user0m0.000s sys 0m0.000s $ gfortran -O -fgraphite-identity forall_4.f90 $ time ./a.out real0m26.461s user0m26.290s sys 0m0.050s The problem seems to be this empty loop: .L24: movrax, rdx# D.1888, D.1888 .L7: leardx, [rax+1]# D.1888, cmprax, rcx# D.1888, D.1848 jl.L24#, which iterates many times (rcx 132), and maybe the whole loop is executed more than once Tested revisions: r168296 - fail
[Bug target/47093] New: [meta-bug]: broken configurations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47093 Summary: [meta-bug]: broken configurations Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: build, meta-bug Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org Depends on: 3746,44756,47084 config.gcc has cases for a number of configurations that do not build at all. I've constructed a list of 215 targets to get reasonable coverage of the cases in config.gcc, and found that one of these would not configure, and a further 36 would not build.
[Bug target/47094] New: i386-freebsd6.0_aout fails to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47094 Summary: i386-freebsd6.0_aout fails to build Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org Blocks: 47093 Host: x86_64-pc-linux-gnu Target: i386-freebsd6.0_aout ../../../gcc/gcc/gcc.c:1199:53: error: ‘FBSD_DYNAMIC_LINKER’ undeclared here (not in a function) ../../../gcc/gcc/gcc.c:1199:21: error: missing initializer [-Werror=missing-field-initializers] ../../../gcc/gcc/gcc.c:1199:21: error: (near initialization for ‘extra_specs_1[1].ptr’) [-Werror=missing-field-initializers]
[Bug target/47095] New: defunct configuration v850e1-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47095 Summary: defunct configuration v850e1-*-* Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org Blocks: 47093 Target: v850e1-elf config.gcc has a case for v850e1-*-*, but config.sub rejects v850e1.
[Bug objc/47076] Protocol referenced in @interface declarations should be defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47076 --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2010-12-29 01:16:59 UTC --- Author: nicola Date: Wed Dec 29 01:16:55 2010 New Revision: 168307 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168307 Log: In gcc/objc/: 2010-12-28 Nicola Pero nicola.p...@meta-innovation.com PR objc/47076 * objc-act.c (lookup_protocol): Added 'definition_required' argument. If 'definition_required', and the protocol is not defined, emit a warning. (objc_declare_protocols): Updated call to lookup_protocol. (start_protocol): Same change. (check_protocol_recursively): Same change. (objc_build_protocol_expr): Same change. (lookup_and_install_protocols): Added definition_required argument. Pass it to lookup_protocol. (objc_get_protocol_qualified_type): Updated call to lookup_and_install_protocols. (start_class): Updated calls to lookup_and_install_protocols; pass true to 'definition_required' to get the warnings. (start_protocol): Updated calls to lookup_and_install_protocols. In gcc/testsuite/: 2010-12-28 Nicola Pero nicola.p...@meta-innovation.com PR objc/47076 * objc.dg/protocol-forward-1.m: New. * obj-c++.dg/protocol-forward-1.mm: New. * objc.dg/attributes/proto-attribute-2.m: Updated. * objc.dg/class-protocol-1.m: Updated. * obj-c++.dg/attributes/proto-attribute-2.mm: Updated. * obj-c++.dg/class-protocol-1.mm: Updated. Added: trunk/gcc/testsuite/obj-c++.dg/protocol-forward-1.mm trunk/gcc/testsuite/objc.dg/protocol-forward-1.m Modified: trunk/gcc/objc/ChangeLog trunk/gcc/objc/objc-act.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/obj-c++.dg/attributes/proto-attribute-2.mm trunk/gcc/testsuite/obj-c++.dg/class-protocol-1.mm trunk/gcc/testsuite/objc.dg/attributes/proto-attribute-2.m trunk/gcc/testsuite/objc.dg/class-protocol-1.m
[Bug target/47096] New: i686-interix3 fails building dbxout.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47096 Summary: i686-interix3 fails building dbxout.o Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org Blocks: 44756 Host: x86_64-pc-linux-gnu Target: i686-interix3 ../../../gcc/gcc/dbxout.c: In function ‘dbxout_symbol_location’: ../../../gcc/gcc/dbxout.c:3037:13: error: signed and unsigned type in conditional expression [-Werror=sign-compare] ../../../gcc/gcc/dbxout.c:3037:13: error: signed and unsigned type in conditional expression [-Werror=sign-compare] ../../../gcc/gcc/dbxout.c: In function ‘dbxout_parms’: ../../../gcc/gcc/dbxout.c:3428:15: error: signed and unsigned type in conditional expression [-Werror=sign-compare] ../../../gcc/gcc/dbxout.c:3428:15: error: signed and unsigned type in conditional expression [-Werror=sign-compare] cc1: all warnings being treated as errors
[Bug target/47096] i686-interix3 fails building dbxout.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47096 --- Comment #1 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2010-12-29 01:47:28 UTC --- The definition of DBX_REGISTER_NUMBER comes from config/i386/i386-interix.h .
[Bug target/47097] New: i686-lynxos fails building dbxout.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47097 Summary: i686-lynxos fails building dbxout.o Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org Blocks: 44756 Host: x86_64-pc-linux-gnu Target: i686-lynxos ../../../gcc/gcc/dbxout.c: In function ‘dbxout_symbol_location’: ../../../gcc/gcc/dbxout.c:3037:13: error: signed and unsigned type in conditional expression [-Werror=sign-compare] ../../../gcc/gcc/dbxout.c:3037:13: error: signed and unsigned type in conditional expression [-Werror=sign-compare] ../../../gcc/gcc/dbxout.c: In function ‘dbxout_parms’: ../../../gcc/gcc/dbxout.c:3428:15: error: signed and unsigned type in conditional expression [-Werror=sign-compare] ../../../gcc/gcc/dbxout.c:3428:15: error: signed and unsigned type in conditional expression [-Werror=sign-compare] cc1: all warnings being treated as errors The definition of DBX_REGISTER_NUMBER comes from config/i386/lynx.h .
[Bug target/47098] New: i686-openbsd3.0: OBSD_LIB_SPEC missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47098 Summary: i686-openbsd3.0: OBSD_LIB_SPEC missing Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org Blocks: 47093 Host: x86_64-pc-linux-gnu Target: i686-openbsd3.0 ../../../gcc/gcc/gcc.c:684:31: error: ‘OBSD_LIB_SPEC’ undeclared here (not in a function) make[2]: *** [gcc.o] Error 1
[Bug c++/47068] [C++0x] internal compiler error on decltype(~ expression)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47068 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2010-12-29 02:17:51 UTC --- Author: jason Date: Wed Dec 29 02:17:47 2010 New Revision: 168309 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168309 Log: PR c++/47068 * semantics.c (finish_id_expression): Don't note non-names as being used in the class. Added: trunk/gcc/testsuite/g++.dg/cpp0x/decltype24.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
