[Bug target/52129] wrong code to pass parameters to tail call function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52129
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 2012-02-06
08:02:36 UTC ---
Reduced testcase (-march=armv7-a -mthumb -O2):
extern void abort (void);
struct S { void *p; unsigned int q; };
struct T { char a[64]; char b[64]; } t;
__attribute__((noinline, noclone)) int
foo (void *x, struct S s, void *y, void *z)
{
if (x != t.a[2] || s.p != t.b[5] || s.q != 27 || y != t.a[17] || z !=
t.b[17])
abort ();
return 29;
}
__attribute__((noinline, noclone)) int
bar (void *x, void *y, void *z, struct S s, int t, struct T *u)
{
return foo (x, s, u-a[t], u-b[t]);
}
int
main ()
{
struct S s = { t.b[5], 27 };
if (bar (t.a[2], (void *) 0, (void *) 0, s, 17, t) != 29)
abort ();
return 0;
}
[Bug c++/52131] dynamic allocation?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52131 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-06 08:20:49 UTC --- This is a documented extension, see http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc/Variable-Length.html#Variable-Length Use -pedantic to get a diagnostic.
[Bug debug/52132] New: [4.7 Regression] ICE in loc_descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52132 Bug #: 52132 Summary: [4.7 Regression] ICE in loc_descriptor Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: debug AssignedTo: ja...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Target: i686-linux The following testcase ICEs with -m32 -g -O2 -std=c99 on x86_64-linux. The bug is likely in regstack, which changes: rh787518.i.216r.sched2:(debug_insn 20 58 21 2 (var_location:SI D#1 (subreg:SI (reg:SF 8 st [orig:66 D.1248 ] [66]) 0)) rh787518.i:10 -1 to: rh787518.i.218r.stack:(debug_insn 20 58 21 2 (var_location:SI D#1 (reg:SF 8 st)) rh787518.i:10 -1 (note the lost subreg). The regression started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=178597 though that likely just made a latent bug into a reprduceable one.
[Bug rtl-optimization/48374] ICE: in single_succ_edge, at basic-block.h:562 with -fselective-scheduling2 and __builtin_unreachable()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48374 --- Comment #5 from Andrey Belevantsev abel at gcc dot gnu.org 2012-02-06 08:32:30 UTC --- (In reply to comment #4) Seems you forgot to actually add the test case. Thanks, I forgot to svn add, fixed in 183928.
[Bug debug/52132] [4.7 Regression] ICE in loc_descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52132 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-06 Known to work||4.6.2 Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 Known to fail||4.7.0
[Bug debug/52132] [4.7 Regression] ICE in loc_descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52132
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-06
08:34:22 UTC ---
int l;
void bar (void);
void
foo (int *x, float y)
{
float b;
union { float f; int i; } u = { .f = y };
u.i += 127 23;
u.f = ((-1.0f / 3) * u.f + 2) * u.f - 2.0f / 3;
b = 0.5 * (u.f + l);
if (b = *x)
bar ();
}
[Bug libstdc++/52133] New: Undefined Symbol to _Bind_simple_helper
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52133 Bug #: 52133 Summary: Undefined Symbol to _Bind_simple_helper Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: mario-baum...@web.de Hi All, since 1st of February i get an undefined symbol to U std::_Bind_simple_helpervoid (std::thread::*)()std::reference_wrapperstd::thread ::__type std::__bind_simplevoid (std::thread::*)(), std::reference_wrapperstd::thread (void (std::thread::*)(), std::reference_wrapperstd::thread) within libstdc++.so.6.0.17. Does anyone know why? Last gcc svn revision i tried was 183468. Mario. uname -a Linux yoda55.intec.dom 2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:14 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux rpm -qa glibc* | grep -e 'glibc-[0-9]' | sort -u glibc-2.5-49.el5_5.7 g++ -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20080704 (Red Hat 4.1.2-48) ld -v GNU ld version 2.17.50.0.6-14.el5 20061020
[Bug c++/52088] [4.7 Regression] ICE in delete with template convertion operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52088 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug tree-optimization/52091] [4.7 Regression] ICE: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52091 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Ira Rosen irar at il dot ibm.com 2012-02-06 08:42:00 UTC --- Fixed.
[Bug libstdc++/52128] [4.7 regression] r183788 caused massive libstdc++ testsuite regression on i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52128 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||mario-baumann at web dot de --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-06 08:52:48 UTC --- *** Bug 52133 has been marked as a duplicate of this bug. ***
[Bug libstdc++/52133] Undefined Symbol to _Bind_simple_helper
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52133 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-06 08:52:48 UTC --- dup *** This bug has been marked as a duplicate of bug 52128 ***
[Bug libstdc++/52128] [4.7 regression] r183788 caused massive libstdc++ testsuite regression on i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52128 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-06 09:32:28 UTC --- Created attachment 26579 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26579 does this patch fix it? I can't reproduce this on i686-pc-linux-gnu x86_64-unknown-linux-gnu x86_64-unknown-netbsd5.1 powerpc64-unknown-linux-gnu I don't see those failures in i686-pc-linux-gnu testresults: http://gcc.gnu.org/ml/gcc-testresults/2012-02/msg00415.html http://gcc.gnu.org/ml/gcc-testresults/2012-02/msg00413.html http://gcc.gnu.org/ml/gcc-testresults/2012-02/msg00410.html http://gcc.gnu.org/ml/gcc-testresults/2012-02/msg00310.html What configure command are you running? Have you tried a clean build in an empty objdir? what version of binutils are you using?
[Bug libstdc++/52128] [4.7 regression] r183788 caused massive libstdc++ testsuite regression on i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52128 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug target/52129] wrong code to pass parameters to tail call function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52129 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-06 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-06 09:46:59 UTC --- Created attachment 26580 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26580 gcc47-pr52129.patch Untested fix. Seems on this testcase pretend_args_size is non-zero, and argblock is initialized for sibcall sequences as: argblock = crtl-args.internal_arg_pointer; argblock #ifdef STACK_GROWS_DOWNWARD = plus_constant (argblock, crtl-args.pretend_args_size); #else = plus_constant (argblock, -crtl-args.pretend_args_size); #endif and what is stored into stored_args_map is relative to that argblock (arg-locate.slot_offset.constant based), while the testing is done with offsets relative to crtl-args.internal_arg_pointer.
[Bug debug/52132] [4.7 Regression] ICE in loc_descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52132 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-06 10:23:31 UTC --- Created attachment 26581 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26581 gcc47-pr52132.patch Untested fix. What get_true_reg does might be reasonable for code where we have quite strict requirements on what SUBREG can be applied or not, but it is definitely wrong for arbitrary SUBREGs in DEBUG_INSNs. In fact, I don't see what get_true_reg would buy us, we get at the real REG in for_each_rtx anyway and can keep the SUBREGs, FLOAT_EXTEND etc. in the DEBUG_INSN.
[Bug c/52118] The explanation of Wunused-local-typedefs is truncated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52118 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-02-06 10:31:23 UTC --- Author: paolo Date: Mon Feb 6 10:31:18 2012 New Revision: 183932 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183932 Log: 2012-02-06 Paolo Carlini paolo.carl...@oracle.com PR c/52118 * c.opt ([Wunused-local-typedefs]): Fix description. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt
[Bug c/52118] The explanation of Wunused-local-typedefs is truncated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52118 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-02-06 10:34:51 UTC --- Fixed.
[Bug middle-end/52134] New: Does not fold (x * 4) -4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52134 Bug #: 52134 Summary: Does not fold (x * 4) -4 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org CC: ebotca...@gcc.gnu.org We appearantly do not fold ((sizetype) MAX_EXPR R1b, 0 + 2) * 4 BIT_AND_EXPR -4 as it happens for TYPE_SIZE_UNIT of a struct for gnat.dg/opt9.adb. This causes an issue with trying to compute the extent/padding of a trailing bitfield in such a struct when you do size_diffop (TYPE_SIZE_UNIT (DECL_CONTEXT (field)), DECL_FIELD_OFFSET (repr)); where repr is the first field of a bitfield group and field is the last field of a bitfield group. The above expression computes non-constant ((ssizetype) (((sizetype) MAX_EXPR R1b, 0 + 2) * 4) -4) - (ssizetype) ((sizetype) MAX_EXPR R1b, 0 * 4) Not sure if such an expression cannot be reliably required to be constant in ada though. Certainly this looks like a missed folding (not sure how often this odd BIT_AND_EXPR for sizes happen in Ada).
[Bug fortran/51514] [OOP] Wrong code when passing a scalar CLASS to a TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51514 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Summary|[OOP] Wrong code when |[OOP] Wrong code when |passing a CLASS to a TYPE |passing a scalar CLASS to a ||TYPE --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-06 11:04:25 UTC --- Actually, the issue seems to only affect scalar polymorphic variables. If the actual argument is a polymorphic array, it works. Both as argument to an elemental function and to an array dummy argument.
[Bug target/51106] [4.5/4.6 Regression] ICE in move_insn, at haifa-sched.c:2314
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51106 --- Comment #7 from Andrey Belevantsev abel at gcc dot gnu.org 2012-02-06 12:10:17 UTC --- (In reply to comment #6) Can this be applied to 4.5/4.6 please? Well, the patch was approved for trunk only, but it is committed for two weeks now and looks safe -- Jakub?
[Bug target/51106] [4.5/4.6 Regression] ICE in move_insn, at haifa-sched.c:2314
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51106 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-06 12:26:48 UTC --- Yes, it is ok for the affected branches if bootstrap/regtest passes.
[Bug middle-end/51994] [4.6/4.7 Regression] git-1.7.8.3 miscompiled due to negative bitpos from get_inner_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994 --- Comment #35 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-02-06 12:29:06 UTC --- So your patch is probably ok (can you try verifying we don't get (too much) codegen differences on a bootstrap?) There are no differences for a compiler build on Alpha and i586 (4.6 branch).
[Bug middle-end/51929] [4.7 Regression] ICE: verify_cgraph_node failed with -O2 -fno-guess-branch-probability -fipa-cp-clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51929 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.7.0
[Bug libstdc++/52128] [4.7 regression] r183788 caused massive libstdc++ testsuite regression on i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52128 --- Comment #4 from Mario Baumann mario-baumann at web dot de 2012-02-06 12:41:11 UTC --- Hi Jonathan, the attached fix works for bug 52133. Thanks! Mario.
[Bug libstdc++/52128] [4.7 regression] r183788 caused massive libstdc++ testsuite regression on i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52128 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-06 12:46:27 UTC --- Great, thanks for testing it, I'll check it in this evening.
[Bug other/52115] ICE: verify_ssa failed (missing definition for SSA_NAME)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52115 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-06 12:59:23 UTC --- Mine.
[Bug tree-optimization/52115] [4.7 Regression] ICE: verify_ssa failed (missing definition for SSA_NAME)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52115
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target|avr |
Component|other |tree-optimization
Known to work||4.6.2
Target Milestone|--- |4.7.0
Summary|ICE: verify_ssa failed |[4.7 Regression] ICE:
|(missing definition for |verify_ssa failed (missing
|SSA_NAME) |definition for SSA_NAME)
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-06
13:08:27 UTC ---
Testcase that fails on x86_64:
struct S
{
float f;
long l;
};
extern int gi;
extern float gf;
long foo (long p)
{
struct S s;
float *pf;
s.l = p;
pf = s.f;
pf++;
pf--;
gf = *pf + 3.3;
gi = *((short *)pf) + 2;
return s.l + 6;
}
I have a patch.
[Bug c++/52136] New: g++ is wrongly propagating friend class to the parent class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52136
Bug #: 52136
Summary: g++ is wrongly propagating friend class to the
parent class
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sylves...@debian.org
---
class address
{
protected:
static int parseNext(int a);
};
class mailbox : public address
{
friend class mailboxField;
};
class mailboxField
{
void parse(int a)
{
address::parseNext(a);
// will work with:
// mailbox::parseNext(a);
}
};
---
It should trigger:
address.cpp: In member function ‘void mailboxField::parse(int)’:
address.cpp:4:16: error: ‘static int address::parseNext(int)’ is protected
address.cpp:17:33: error: within this context
Tested with g++ 4.6.2
[Bug target/52129] wrong code to pass parameters to tail call function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52129 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-06 13:33:09 UTC --- Author: jakub Date: Mon Feb 6 13:33:05 2012 New Revision: 183933 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183933 Log: PR target/52129 * calls.c (mem_overlaps_already_clobbered_arg_p): If val is CONST_INT_P, subtract resp. add crtl-args.pretend_args_size to it. * gcc.c-torture/execute/pr52129.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr52129.c Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c trunk/gcc/testsuite/ChangeLog
[Bug target/52129] wrong code to pass parameters to tail call function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52129 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-06 13:35:18 UTC --- Fixed on the trunk so far.
[Bug c++/52136] g++ is wrongly propagating friend class to the parent class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52136
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-06
13:40:08 UTC ---
EDG and Solaris CC also accept it, clang doesn't
The code looks similar to this example from [class.protected] in the standard:
class B {
protected:
int i;
static int j;
};
class D1 : public B {
};
class D2 : public B {
friend void fr(B*,D1*,D2*);
};
void fr(B* pb, D1* p1, D2* p2) {
// ...
p2-i = 3;// OK (access through a D2)
p2-B::i = 4; // OK (access through a D2, even though
// naming class is B)
// ...
B::j = 5; // OK (because refers to static member)
D2::j = 6;// OK (because refers to static member)
}
Note that the friend of D2 can access non-static members of B through D2* and
can access static members of B directly.
[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955 --- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-06 13:43:06 UTC --- Author: rguenth Date: Mon Feb 6 13:43:03 2012 New Revision: 183934 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183934 Log: 2012-02-06 Richard Guenther rguent...@suse.de PR tree-optimization/50955 * tree-ssa-loop-ivopts.c (get_computation_cost_at): Artificially raise cost of expressions that replace an address with an expression based on a different pointer. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c
[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-06 13:43:23 UTC --- Fixed.
[Bug c++/52136] g++ is wrongly propagating friend class to the parent class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52136 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-06 13:50:40 UTC --- I think G++ is correct here. [class.protected]p1 An additional access check beyond those described earlier in Clause 11 is applied when a non-static data member or non-static member function is a protected member of its naming class (11.2)* * This additional check does not apply to other members, e.g., static data members or enumerator member constants. address::parseNext refers to the same entity as mailbox::parseNext and access to static members does not involve an object expression, so there is no need for that access to be done through an object expression of the derived type.
[Bug target/38342] [4.4/4.5/4.6/4.7 Regression] __attribute__((__progmem__)) not propagated from typedef to data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38342 --- Comment #13 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-06 13:55:09 UTC --- For avr-libc users, please f'up to http://savannah.nongnu.org/bugs/?33716
[Bug c++/52136] g++ is wrongly propagating friend class to the parent class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52136 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-06 13:56:58 UTC --- Clang gets this wrong on purpose: http://llvm.org/bugs/show_bug.cgi?id=6840 But G++ implements what the standard says, so INVALID
[Bug fortran/51514] [OOP] Wrong code when passing a scalar CLASS to a TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51514 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-06 14:04:29 UTC --- Created attachment 26583 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26583 Completely untested/not compiled draft patch The attached patch is completely untested. It additionally contains some - also untested - fixes for polymophic coarrays. Variant: subroutine subpr2(x) type(foo) :: x print *,x%i if (x%i /= 55) call abort () end subroutine function f() class(foo), allocatable :: f allocate (f) f%i = 55 end function f with call subpr(f())
[Bug middle-end/52134] Does not fold (x * 4) -4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52134 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-06 Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-02-06 14:08:13 UTC --- The above expression computes non-constant ((ssizetype) (((sizetype) MAX_EXPR R1b, 0 + 2) * 4) -4) - (ssizetype) ((sizetype) MAX_EXPR R1b, 0 * 4) Not sure if such an expression cannot be reliably required to be constant in ada though. Reassociation/simplification of size expressions can generally be done at will. Certainly this looks like a missed folding (not sure how often this odd BIT_AND_EXPR for sizes happen in Ada). Quite a lot, but it's created by the folder itself (round_up).
[Bug c++/52136] g++ is wrongly propagating friend class to the parent class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52136 --- Comment #4 from Sylvestre Ledru sylvestre at debian dot org 2012-02-06 14:08:21 UTC --- I found this bug (or behavior) while playing with clang. I am not really sure to understand why friend class should impact his parent but if g++ respects the standard, why not...
[Bug tree-optimization/51528] [4.6 Regression] SRA should not create BOOLEAN_TYPE replacements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51528
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Depends on||52115
--- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-06
14:13:48 UTC ---
On ppc the main SRA pass does nothing to foo () because of differences in
how the return value is returned. Still the IL at expansion time looks
great:
foo ()
{
bb 2:
retval.b = 1;
use_bool (retval);
retval.i = 65534;
return retval;
}
compared to x86_64 where we have the uglier
foo ()
{
union U u;
union U D.1733;
bb 2:
u.b = 1;
use_bool (u);
u = VIEW_CONVERT_EXPRunion U(65534);
D.1733 = u;
u ={v} {CLOBBER};
return D.1733;
Compared to -fno-tree-sra on PPC we have
foo ()
{
union U u;
bb 2:
retval.b = 1;
use_bool (retval);
u.i = 65534;
retval = u;
u ={v} {CLOBBER};
return retval;
so SRA managed to remove the aggregate temporary and its copy.
So, I don't see what's wrong on PPC (with SRA, that is). This must be
a target bug if at all (note I'm only inspecting dumps and did not
reproduce the execute fail).
[Bug fortran/41587] [OOP] ICE with ALLOCATABLE CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41587 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #7 from Paul Thomas pault at gcc dot gnu.org 2012-02-06 14:20:22 UTC --- As of yesterday, the testcase in comment #1 compiles and runs successfully. We now just need the error message for the original problem. Cheers Paul
[Bug c++/52136] g++ is wrongly propagating friend class to the parent class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52136 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-06 14:24:39 UTC --- (In reply to comment #4) I am not really sure to understand why friend class should impact his parent but if g++ respects the standard, why not... It doesn't impact his parent Read comment 2 again. To access a protected non-static member you must do so though an object expression of the derived type, because in the expression 'p-address::m' you only know if 'm' is a member of a 'mailbox' object when 'p' has type 'mailbox*' But for a static member that is irrelevant, the static member just exists independently of any 'mailbox' or 'address' instance, so if mailboxField can access members of 'mailbox' then it can access the static member, and it doesn't matter if you refer to it as 'mailbox::parseNext' or 'address::parseNext' because both refer to the exact same entity.
[Bug rtl-optimization/52060] Incorrect mask/and (ARM bic) instruction generated for shifted expression parameter, triggered by -O2 -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52060
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed|2012-02-03 00:00:00 |2012-02-06 0:00
Component|target |rtl-optimization
--- Comment #5 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-02-06
14:28:20 UTC ---
Looks like a combine bug to me. We have the following three insns passed to
combine:
i3 = (insn 49 48 50 5 (set (reg:SI 192)
(lshiftrt:SI (reg/v:SI 155 [ linear ])
(const_int 13 [0xd]))) bug.c:47 125 {*arm_shiftsi3}
(nil))
i2 = (insn 46 72 48 5 (set (reg/v:SI 155 [ linear ])
(and:SI (reg:SI 154 [ iftmp.1 ])
(reg:SI 176 [ prephitmp.29 ]))) bug.c:24 75 {*arm_andsi3_insn}
(expr_list:REG_DEAD (reg:SI 176 [ prephitmp.29 ])
(expr_list:REG_DEAD (reg:SI 154 [ iftmp.1 ])
(nil
i1 = (insn 72 41 46 5 (set (reg:SI 154 [ iftmp.1 ])
(if_then_else:SI (eq (reg:CC_NOOV 24 cc)
(const_int 0 [0]))
(const_int -2 [0xfffe])
(const_int -1 [0x]))) bug.c:23 234 {*movsicc_insn}
(expr_list:REG_DEAD (reg:CC 24 cc)
(nil)))
Note that the result of i2 does not die in i3. Nevertheless, we simplify this
expression to the form
(parallel [
(set (reg:SI 192)
(lshiftrt:SI (and:SI (if_then_else:SI (eq (reg:CC_NOOV 24 cc)
(const_int 0 [0]))
(const_int -8192 [0xe000])
(const_int -8192 [0xe000]))
(reg:SI 176 [ prephitmp.29 ]))
(const_int 13 [0xd])))
(set (reg/v:SI 155 [ linear ])
(and:SI (if_then_else:SI (eq (reg:CC_NOOV 24 cc)
(const_int 0 [0]))
(const_int -8192 [0xe000])
(const_int -8192 [0xe000]))
(reg:SI 176 [ prephitmp.29 ])))
])
The choice of -8192 for the constant in the if-then-else expressions seems to
come from the fact that i3 will shift the result right by 13 (ie 0x1fff) and
that therefore we can exclude those bits from the and operation (which will
ultimately collapse the if-then-else into a single constant). However, that is
only true in the first of the two operations in the parallel above. It's not
true for the second operation.
Over to the combine experts.
[Bug middle-end/52047] [trans-mem] ICE: SIGSEGV in execute_tm_mark (trans-mem.c:2270) with -O -fgnu-tm -fprefetch-loop-arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52047 Patrick Marlier patrick.marlier at gmail dot com changed: What|Removed |Added CC||patrick.marlier at gmail ||dot com --- Comment #2 from Patrick Marlier patrick.marlier at gmail dot com 2012-02-06 14:34:24 UTC --- Proposed fix here: http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00096.html Waiting Rth approval and Aldy's kindness for commit. -- Patrick Marlier.
[Bug middle-end/52047] [trans-mem] ICE: SIGSEGV in execute_tm_mark (trans-mem.c:2270) with -O -fgnu-tm -fprefetch-loop-arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52047 --- Comment #3 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-02-06 14:42:11 UTC --- Author: aldyh Date: Mon Feb 6 14:42:07 2012 New Revision: 183936 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183936 Log: PR middle-end/52047 * trans-mem.c (expand_call_tm): Add an assertion. * calls.c (flags_from_decl_or_type): Add ECF_TM_PURE to 'no vops' functions. Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c trunk/gcc/trans-mem.c
[Bug middle-end/52047] [trans-mem] ICE: SIGSEGV in execute_tm_mark (trans-mem.c:2270) with -O -fgnu-tm -fprefetch-loop-arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52047 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||aldyh at gcc dot gnu.org Resolution||FIXED --- Comment #4 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-02-06 14:44:31 UTC --- fixed on trunk
[Bug tree-optimization/52115] [4.7 Regression] ICE: verify_ssa failed (missing definition for SSA_NAME)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52115 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-06 14:54:54 UTC --- Author: rguenth Date: Mon Feb 6 14:54:47 2012 New Revision: 183937 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183937 Log: 2012-02-06 Richard Guenther rguent...@suse.de PR tree-optimization/52115 * tree-sra.c (access_has_replacements_p): New function. (sra_modify_assign): Use it to decide whether a use is uninitialized. * gcc.c-torture/compile/pr52115.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr52115.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c
[Bug bootstrap/7125] libz is built even if configured with --with-system-zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7125 Richard Purdie richard.purdie at linuxfoundation dot org changed: What|Removed |Added CC||richard.purdie at ||linuxfoundation dot org --- Comment #10 from Richard Purdie richard.purdie at linuxfoundation dot org 2012-02-06 15:09:38 UTC --- This bug is still present in gcc 4.6 as I've configured with --with-system-zlib yet it still builds zlib for the host.
[Bug tree-optimization/52115] [4.7 Regression] ICE: verify_ssa failed (missing definition for SSA_NAME)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52115 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-06 15:14:46 UTC --- Fixed.
[Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 --- Comment #2 from steven hirshman sphirshman at yahoo dot com 2012-02-06 15:37:35 UTC --- Thank you for the information. THe work-around works with the newer (4.6.2) compiler, but is unrecognized by older versions of gcc that are in use on - for example - NERSC computers. Is there a FIX other than the workaround planned, that will be backwards compatible with older compilers? Also, the B(:) fails on some platforms, I'm told by some of my co-workers. From: burnus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org To: sphirsh...@yahoo.com Sent: Friday, February 3, 2012 3:41 PM Subject: [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 Tobias Burnus burnus at gcc dot gnu.org changed: What |Removed |Added Status|UNCONFIRMED |RESOLVED CC| |burnus at gcc dot gnu.org Resolution| |DUPLICATE --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-03 20:41:32 UTC --- Work around: -fno-realloc-lhs Or add (:) B(:) = RESHAPE(A, SHAPE(B)) Solution: Update - it has just been fixed in the last days. Thanks for the report! *** This bug has been marked as a duplicate of bug 52012 ***
[Bug libstdc++/52128] [4.7 regression] r183788 caused massive libstdc++ testsuite regression on i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52128 --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2012-02-06 16:03:09 UTC --- (In reply to comment #3) Created attachment 26579 [details] does this patch fix it? It does, thanks. What configure command are you running? /tmp/gcc-4.7-20120204/configure --prefix=/tmp/install47 --with-gmp=/home/mikpe/pkgs/linux-x86/gmp-5.0.2 --with-mpfr=/home/mikpe/pkgs/linux-x86/mpfr-3.1.0 --with-mpc=/home/mikpe/pkgs/linux-x86/mpc-0.9 --disable-build-poststage1-with-cxx --disable-libquadmath --disable-plugin --disable-lto --disable-nls --disable-shared --disable-libmudflap --disable-libgomp --enable-threads=posix --enable-checking=release --enable-languages=c,c++ Have you tried a clean build in an empty objdir? I always build gcc in an empty objdir. what version of binutils are you using? binutils-2.20.51.0.7-8.fc14.i686 Fedora 14 user-space, but with a gcc-4.5.3 host compiler and a linux-3.2 kernel.
[Bug libgcj/51500] [4.7 regression] 106 unexpected libjava testsuite failures with mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51500 gee jojelino at gmail dot com changed: What|Removed |Added Attachment #26574|0 |1 is obsolete|| --- Comment #24 from gee jojelino at gmail dot com 2012-02-06 16:18:44 UTC --- Created attachment 26584 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26584 proposed patch for workaround TestEarlyGC failure fixed wrong assumption to the code. but got following in ExtraClassLoader test Starting program: /tmp/gcc/i686-pc-mingw32/libjava/.libs/gij -cp D:\\cygwin\\tmp\\gcc\\libjava\\testsuite\\libjava.lang\\ExtraClassLoader.jar ExtraClassLoader [New Thread 5268.0x140c] [New Thread 5268.0xd84] Exception in thread main java.lang.SecurityException: attempt to use uninitialized class loader at java.lang.Throwable.init(/tmp/gcc/libjava/classpath/java/lang/Throwable.java:161) at java.lang.ClassLoader.checkInitialized(/tmp/gcc/libjava/classpath/java/lang/Exception.java:78) at java.lang.ClassLoader.findLoadedClass(/tmp/gcc/libjava/java/lang/ClassLoader.java:694) at java.lang.Class.forName(/tmp/gcc/i686-pc-mingw32/libjava/../.././libjava/java/lang/natClass.cc:105) at ExtraClassLoader.main(ExtraClassLoader.java:8) [Inferior 1 (process 5268) exited with code 01] (gdb)
[Bug bootstrap/7125] libz is built even if configured with --with-system-zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7125 --- Comment #11 from Richard Purdie richard.purdie at linuxfoundation dot org 2012-02-06 16:23:16 UTC --- Sorry, my previous report should be disregarded as it was user error. The option does appear to work for me, removing the zlib compile where it was previously present.
[Bug target/52137] New: bdver2 scheduler needs to be added to bdver1 insn reservations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52137 Bug #: 52137 Summary: bdver2 scheduler needs to be added to bdver1 insn reservations Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: qne...@gcc.gnu.org Created attachment 26585 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26585 Add bdver2 to list of cpu attributes for bdver1.md insn reservations The bdver2 scheduler lacks insn reservation conditions for cpu attributes in the bdver1.md model. The resulting generated code regresses on bdver2 hardware for SPEC and polyhedron. The attached patch recovers most of this performance regression.
[Bug target/52137] bdver2 scheduler needs to be added to bdver1 insn reservations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52137 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Severity|blocker |normal
[Bug rtl-optimization/52060] [4.7 regression] Invalid constant simplification in combine with parallel result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52060
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-06
17:44:36 UTC ---
Created attachment 26586
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26586
gcc47-pr52060.patch
I think the important question is if it is ok that combine_simplify_rtx may
modify the given rtl in place, as opposed to keeping it unmodified and just
allocating new rtx and returning it. A brief look at combine.c suggests that
SUBST () is used in so many places that it is meant to be ok to modify it in
place.
Then we for added_sets_{1,2} should just make copies of i1src resp. i0src
upfront, which means perhaps slightly bigger amount of GC, but at least it
won't miscompile things.
If the modification in place is undesirable, then e.g. force_to_mode is
something that modifies rtx in place very deep into it.
This untested fix cures the testcase on a cross to arm.
[Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-06 17:45:36 UTC --- (In reply to comment #2) Thank you for the information. THe work-around works with the newer (4.6.2) compiler, but is unrecognized by older versions of gcc that are in use on - for example - NERSC computers. Well, the bug is related to (re)allocation on assignment (a Fortran 2003 features), which is new in GCC 4.6. Thus, both the flag -f(no-)realloc-lhs but also the bug is only in GCC 4.6 (and 4.7). You could also use -std=f95, which implies -fno-realloc-lhs with GCC 4.6/4.7 but is also supported in older gfortrans; however, you need to have a code which follows Fortran 95 close enough to be compilable with that flag. Is there a FIX other than the workaround planned, that will be backwards compatible with older compilers? The actual bug has been fixed on both the GCC 4.6 branch (on 2012-02-03) and on the GCC 4.7 trunk (on 2012-02-02). Thus, if you have a newer version of GCC 4.6/4.7, you are also not affected. (Cf. the nightly build from http://gcc.gnu.org/wiki/GFortranBinaries ) See bug 52012 for details. Also, the B(:) fails on some platforms, I'm told by some of my co-workers. Can you provides more details? Using B(:) = prevents the (re)allocation of the left-hand side and thus it should also prevent the bug. In particular: - How does it fail? At compile time? At run time? With which error? - Which version/platform of the compiler are you using? - Is that with the code of comment 0 with only B = RESHAPE... changed to B(:) = RESHAPE... or is it for some other code?
[Bug c/52138] New: Operations on complex values are not inlined, even with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52138 Bug #: 52138 Summary: Operations on complex values are not inlined, even with -O3 Classification: Unclassified Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: gon...@maths.ox.ac.uk Irrespective of the optimization level selected, multiplying or dividing two complex doubles generates a call to __muldc3 or __divdc3 respectively. Using the -fcx-limited-range flag inlines the operations, but then the range may be limited. Strangely enough, in the gfortran frontend, complex arithmetic is inlined even with no optimization (-O0).
[Bug c/52138] Operations on complex values are not inlined, even with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52138 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 2012-02-06 18:25:47 UTC --- Why do you think inlining a ~ 750B long routine would be beneficial? Note that if one of the operands has 0 either the imaginary or real part, gcc will inline it.
[Bug c/52138] Operations on complex values are not inlined, even with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52138 --- Comment #2 from Pedro gonnet at maths dot ox.ac.uk 2012-02-06 18:33:11 UTC --- I'm a bit confused... In the gfortran output the multiplication only about 40 bytes. Does that mean that gfortran is using a reduced range by default?
[Bug c/52138] Operations on complex values are not inlined, even with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52138 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org 2012-02-06 18:50:41 UTC --- (In reply to comment #2) I'm a bit confused... In the gfortran output the multiplication only about 40 bytes. Does that mean that gfortran is using a reduced range by default? From gcc/toplev.c /* With -fcx-limited-range, we do cheap and quick complex arithmetic. */ if (flag_cx_limited_range) flag_complex_method = 0; /* With -fcx-fortran-rules, we do something in-between cheap and C99. */ if (flag_cx_fortran_rules) flag_complex_method = 1; So, yes, gfortran does something different than gcc.
[Bug c/52138] Operations on complex values are not inlined, even with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52138 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-02-06 18:58:00 UTC --- From the manual: -fcx-limited-range When enabled, this option states that a range reduction step is not needed when performing complex division. Also, there is no checking whether the result of a complex multiplication or division is NaN + I*NaN, with an attempt to rescue the situation in that case. The default is -fno-cx-limited-range, but is enabled by -ffast-math. This option controls the default setting of the ISO C99 CX_LIMITED_RANGE pragma. Nevertheless, the option applies to all languages. -fcx-fortran-rules Complex multiplication and division follow Fortran rules. Range reduction is done as part of complex division, but there is no checking whether the result of a complex multiplication or division is NaN + I*NaN, with an attempt to rescue the situation in that case. The default is -fno-cx-fortran-rules.
[Bug c/52138] Operations on complex values are not inlined, even with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52138 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-06 19:28:41 UTC --- This is invalid as mentioned above.
[Bug middle-end/52134] Does not fold (x * 4) -4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52134
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Keywords||TREE
--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-06
19:45:41 UTC ---
Short testcase:
unsigned f(unsigned t)
{
return (t*4)-4;
}
int f1(int t)
{
return (t*4)-4;
}
Both should be optimized to just t*4. In fact we do it on the RTL level.
*4 is changed to a 2 on the RTL level and simplified with the when doing
combine.
[Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 --- Comment #4 from steven hirshman sphirshman at yahoo dot com 2012-02-06 19:45:53 UTC --- Thanks. I tried the -std=f95 flag and it gave the same (wrong) answer as without it, in the test code I sent you. What is not Fortran95 compatible with the code snippet I sent you? From: burnus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org To: sphirsh...@yahoo.com Sent: Monday, February 6, 2012 12:45 PM Subject: [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-06 17:45:36 UTC --- (In reply to comment #2) Thank you for the information. THe work-around works with the newer (4.6.2) compiler, but is unrecognized by older versions of gcc that are in use on - for example - NERSC computers. Well, the bug is related to (re)allocation on assignment (a Fortran 2003 features), which is new in GCC 4.6. Thus, both the flag -f(no-)realloc-lhs but also the bug is only in GCC 4.6 (and 4.7). You could also use -std=f95, which implies -fno-realloc-lhs with GCC 4.6/4.7 but is also supported in older gfortrans; however, you need to have a code which follows Fortran 95 close enough to be compilable with that flag. Is there a FIX other than the workaround planned, that will be backwards compatible with older compilers? The actual bug has been fixed on both the GCC 4.6 branch (on 2012-02-03) and on the GCC 4.7 trunk (on 2012-02-02). Thus, if you have a newer version of GCC 4.6/4.7, you are also not affected. (Cf. the nightly build from http://gcc.gnu.org/wiki/GFortranBinaries ) See bug 52012 for details. Also, the B(:) fails on some platforms, I'm told by some of my co-workers. Can you provides more details? Using B(:) = prevents the (re)allocation of the left-hand side and thus it should also prevent the bug. In particular: - How does it fail? At compile time? At run time? With which error? - Which version/platform of the compiler are you using? - Is that with the code of comment 0 with only B = RESHAPE... changed to B(:) = RESHAPE... or is it for some other code?
[Bug tree-optimization/52139] New: ICE: in remove_insn, at emit-rtl.c:3960 with -O -fPIC -fno-tree-dominator-opts -fno-tree-fre --param case-values-threshold=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52139 Bug #: 52139 Summary: ICE: in remove_insn, at emit-rtl.c:3960 with -O -fPIC -fno-tree-dominator-opts -fno-tree-fre --param case-values-threshold=1 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 26587 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26587 reduced testcase Compiler output: $ gcc -O -fPIC -fno-tree-dominator-opts -fno-tree-fre --param case-values-threshold=1 testcase.c testcase.c: In function 'foo': testcase.c:17:1: internal compiler error: in remove_insn, at emit-rtl.c:3960 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=0x1264468 /mnt/svn/gcc-trunk/gcc/emit-rtl.c, line=3960, function=0x1265661 remove_insn) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:898 #1 0x0073f55c in remove_insn (insn=0x75bc6580) at /mnt/svn/gcc-trunk/gcc/emit-rtl.c:3960 #2 0x0069c541 in delete_insn (insn=0x75bc6580) at /mnt/svn/gcc-trunk/gcc/cfgrtl.c:145 #3 0x0069fb8a in cfg_layout_merge_blocks (a=0x75ba5410, b=0x75ba5340) at /mnt/svn/gcc-trunk/gcc/cfgrtl.c:2896 #4 0x0068c5f6 in merge_blocks (a=0x75ba5410, b=0x75ba5340) at /mnt/svn/gcc-trunk/gcc/cfghooks.c:683 #5 0x010810b7 in try_optimize_cfg (mode=optimized out) at /mnt/svn/gcc-trunk/gcc/cfgcleanup.c:2696 #6 cleanup_cfg (mode=optimized out) at /mnt/svn/gcc-trunk/gcc/cfgcleanup.c:2940 #7 0x010d6cc6 in rest_of_handle_cse () at /mnt/svn/gcc-trunk/gcc/cse.c:7327 #8 rest_of_handle_cse () at /mnt/svn/gcc-trunk/gcc/cse.c:7310 #9 0x008fbba5 in execute_one_pass (pass=0x17ced80) at /mnt/svn/gcc-trunk/gcc/passes.c:2081 #10 0x008fbf65 in execute_pass_list (pass=0x17ced80) at /mnt/svn/gcc-trunk/gcc/passes.c:2136 #11 0x008fbf77 in execute_pass_list (pass=0x17c9f40) at /mnt/svn/gcc-trunk/gcc/passes.c:2137 #12 0x00a5e24e in tree_rest_of_compilation (fndecl=0x75ba6e00) at /mnt/svn/gcc-trunk/gcc/tree-optimize.c:422 #13 0x006affca in cgraph_expand_function (node=0x75a976c0) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1829 #14 0x006b1ebc in cgraph_expand_all_functions () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1896 #15 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2210 #16 0x006b250a in cgraph_finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1338 #17 0x0058ec70 in c_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/c-decl.c:10030 #18 0x009f0a2c in compile_file () at /mnt/svn/gcc-trunk/gcc/toplev.c:573 #19 do_compile () at /mnt/svn/gcc-trunk/gcc/toplev.c:1938 #20 toplev_main (argc=18, argv=0x7fffd7f8) at /mnt/svn/gcc-trunk/gcc/toplev.c:2014 #21 0x761cc09d in __libc_start_main () from /lib64/libc.so.6 #22 0x00572371 in _start () Tested revisions: r183913 - crash
[Bug c++/52088] [4.7 Regression] ICE in delete with template convertion operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52088 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2012-02-06 19:52:47 UTC --- Author: jason Date: Mon Feb 6 19:52:43 2012 New Revision: 183940 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183940 Log: PR c++/52088 * cvt.c (build_expr_type_conversion): Check for template conversion. Added: trunk/gcc/testsuite/g++.dg/template/conv13.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cvt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/52088] [4.7 Regression] ICE in delete with template convertion operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52088 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2012-02-06 19:54:04 UTC --- Fixed.
[Bug rtl-optimization/52139] ICE: in remove_insn, at emit-rtl.c:3960 with -O -fPIC -fno-tree-dominator-opts -fno-tree-fre --param case-values-threshold=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52139 Zdenek Sojka zsojka at seznam dot cz changed: What|Removed |Added Attachment #26587|0 |1 is obsolete|| --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2012-02-06 19:55:30 UTC --- Created attachment 26588 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26588 testcase failing in 4.5, 4.6 and 4.7 $ gcc -O -fPIC -fno-tree-dominator-opts -fno-tree-fre testcase2.c testcase2.c: In function 'foo': testcase2.c:44:1: internal compiler error: in remove_insn, at emit-rtl.c:3960 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/48490] delete with template convertion operator does overload resolution for class operands, but shouldn't.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48490 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2012-02-06 20:01:04 UTC --- Fixed by patch for PR52088.
[Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-06 20:01:15 UTC --- (In reply to comment #4) Thanks. I tried the -std=f95 flag and it gave the same (wrong) answer as without it, in the test code I sent you. What is not Fortran95 compatible with the code snippet I sent you? I works for me both with GCC 4.6 and GCC 4.7 both with the current version but also with a version which still had bug 52012. Can you please answer the following question? You only kind of answered the third question, namely that you used the original program (of comment 0). Additional, could you provide more information about the version you used (gfortran -v), of interest are the complete of Target and of gcc version. (In reply to comment #3) Can you provides more details? In particular: - How does it fail? At compile time? At run time? With which error? - Which version/platform of the compiler are you using? - Is that with the code of comment 0 with only B = RESHAPE... changed to B(:) = RESHAPE... or is it for some other code? Example on my system for a 4.6 version which has still the bug: $ gfortran-4.6 -v | grep -E 'gcc version|Target' Target: x86_64-suse-linux gcc version 4.6.2 20111212 [gcc-4_6-branch revision 18] (SUSE Linux) $ gfortran-4.6 -std=f95 test.f90 test.f90:37.11: PAUSE 1 Error: Deleted feature: PAUSE statement at (1) And after commenting that line: $ gfortran-4.6 -std=f95 test.f90 A( 1 , 1 ) =1. B =1. A( 2 , 1 ) =2. B =2. A( 1 , 2 ) =3. B =3. A( 2 , 2 ) =4. B =4. A( 1 , 3 ) =5. B =5. A( 2 , 3 ) =6. B =6. A( 1 , 4 ) =7. B =7. A( 2 , 4 ) =8. B =8. The output looks correct and is the same as with other compilers. However, if I use the buggy version of the compiler without -std=f95, I get: $ gfortran-4.6 hj4.f90 ./a.out A( 1 , 1 ) =1. B =3. A( 2 , 1 ) =2. B =4. A( 1 , 2 ) =3. B =5. A( 2 , 2 ) =4. B =6. A( 1 , 3 ) =5. B =7. A( 2 , 3 ) =6. B =8. A( 1 , 4 ) =7. B =3.36311631E-44 A( 2 , 4 ) =8. B =9.62964972E-35 As written, using (:) - or to be more precise (it's a rank-3 array) - B(:,:,:) = , -fno-realloc-lhs, or a newer version of the compiler solves the problem as well.
[Bug rtl-optimization/52139] [4.5/4.6/4.7 Regression] ICE: in remove_insn, at emit-rtl.c:3960 with -O -fPIC -fno-tree-dominator-opts -fno-tree-fre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52139 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-06 CC||jakub at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-06 20:02:29 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=145494 Will have a look.
[Bug c++/48491] ICE in delete with template convertion operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48491 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2012-02-06 20:03:11 UTC --- Fixed by patch for PR52088.
[Bug c/52140] New: ICE in Libdfp testcase when compiled with soft-dfp (no -mcpu).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52140
Bug #: 52140
Summary: ICE in Libdfp testcase when compiled with soft-dfp (no
-mcpu).
Classification: Unclassified
Product: gcc
Version: 4.5.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@us.ibm.com
The following Libdfp test-case produces an ICE on PowerPC when compiled w/o
-mcpu (implies soft-dfp) and -O1 or greater optimization:
#ifndef __STDC_WANT_DEC_FP__
#define __STDC_WANT_DEC_FP__
#endif
int
foo (_Decimal64 x, _Decimal64 y)
{
/* This is known to cause a GCC ICE when libdfp is compiled w/o -mcpu and -O1
optimization level or greater. */
return (x y) || (x y);
}
int main(void)
{
int ret = -1;
_Decimal64 a = 12.45DD;
_Decimal64 b = 12.43DD;
ret = foo (a,b);
return 0;
}
/opt/at4.0/bin/gcc -v:
Using built-in specs.
COLLECT_GCC=/opt/at4.0/bin/gcc
COLLECT_LTO_WRAPPER=/opt/at4.0/libexec/gcc/powerpc64-linux/4.5.4/lto-wrapper
Target: powerpc64-linux
Configured with: /home/cseo/at4.0/at4.0-5/src/gcc/configure
--build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux
--with-cpu=default64 --prefix=/opt/at4.0 --with-long-double-128
--enable-decimal-float --enable-secureplt --enable-threads=posix
--enable-languages=c,c++,fortran --enable-__cxa_atexit --enable-shared
--enable-checking --enable-lto --enable-gnu-indirect-function
--with-gmp-include=/opt/at4.0/include --with-gmp-lib=/opt/at4.0/lib64
--with-mpfr-include=/opt/at4.0/include --with-mpfr-lib=/opt/at4.0/lib64
--with-mpc-include=/opt/at4.0/include --with-mpc-lib=/opt/at4.0/lib64
--with-ppl-include=/opt/at4.0/include --with-ppl-lib=/opt/at4.0/lib64
--with-cloog-include=/opt/at4.0/include --with-cloog-lib=/opt/at4.0/lib64
--with-libelf-include=/opt/at4.0/include --with-libelf-lib=/opt/at4.0/lib64
--with-host-libstdcxx='-L/opt/at4.0/lib64 -lstdc++ -lsupc++ -lppl -lppl_c -lpwl
-lgmp -lgmpxx' --with-cpu=power4 --with-tune=power6
Thread model: posix
gcc version 4.5.4 20110524 (Advance-Toolchain-4.0-5) [ibm/gcc-4_5-branch
revision 179810] (GCC)
/opt/at4.0/bin/gcc -DSHARED -O2 -fpic -g -m32 -c ../tests/test-GCC-PR.c
-D__STDC_DEC_FP__=200704L -D__STDC_WANT_DEC_FP__=1
-DOPTION_EGLIBC_LOCALE_CODE=1 -D_POSIX_C_SOURCE=200809L -std=gnu99
-D_SVID_SOURCE -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
-Wno-long-long -include ../include/libdfp-symbols.h -include ./config.h
-I../include -I../dfp -I../dfp/decimal -I../libdecnumber/dpd
-I../libdecnumber -I../sysdeps/powerpc/powerpc32
-I../sysdeps/powerpc/fpu/bits -I../sysdeps/powerpc/fpu -I../sysdeps/powerpc
-I../sysdeps/soft-dfp/dpd -I../sysdeps/soft-dfp -I../sysdeps/dpd
-I../decNumberMath/ -I../ieee754/ -I../base-math/ -I.. -I. -o
test-GCC-PR.os
../tests/test-GCC-PR.c:30:1: warning: no previous prototype for 'foo'
../tests/test-GCC-PR.c: In function 'foo':
../tests/test-GCC-PR.c:34:3: internal compiler error: in prepare_float_lib_cmp,
at optabs.c:4414
I've attached the test-GCC-PR.i and test-GCC-PR.s files generated with
--save-temps.
[Bug c/52140] ICE in Libdfp testcase when compiled with soft-dfp (no -mcpu).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52140 --- Comment #1 from Ryan S. Arnold rsa at us dot ibm.com 2012-02-06 20:46:00 UTC --- Created attachment 26589 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26589 preprocessed .i file
[Bug c/52140] ICE in Libdfp testcase when compiled with soft-dfp (no -mcpu).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52140 --- Comment #2 from Ryan S. Arnold rsa at us dot ibm.com 2012-02-06 20:46:34 UTC --- Created attachment 26590 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26590 Preprocessed .s file
[Bug c/52140] ICE in Libdfp testcase when compiled with soft-dfp (no -mcpu).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52140 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Severity|major |normal --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-06 20:47:54 UTC --- Have you tried an FSF released 4.6.2?
[Bug middle-end/52141] New: [trans-mem] ICE due to asm statement in trans-mem.c:expand_block_tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52141 Bug #: 52141 Summary: [trans-mem] ICE due to asm statement in trans-mem.c:expand_block_tm Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: al...@gcc.gnu.org, r...@gcc.gnu.org Created attachment 26591 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26591 testcase ICE with -fgnu-tm -O1 In the continuation of PRs: 46269, 47606, 51443. ../../trunk-debug/gcc/xgcc -B ../../trunk-debug/gcc -fgnu-tm -O1 -S -o ICE-inline.s ICE-inline2.c ICE-inline2.c:2:13: warning: always_inline function might not be inlinable [-Wattributes] ICE-inline2.c:13:5: internal compiler error: in expand_block_tm, at trans-mem.c:2366 (gdb) bt ... #5 0x00b1714f in expand_block_tm (region=0x1b99160, bb=0x769aa208) at ../../trunk/gcc/trans-mem.c:2366 #6 0x00b17455 in execute_tm_mark () at ../../trunk/gcc/trans-mem.c:2467 #7 0x00a1672f in execute_one_pass (pass=0x196c0a0) at ../../trunk/gcc/passes.c:2081 ...
[Bug middle-end/52140] Libdfp testcase encounters ICE when compiled with soft-dfp (no -mcpu).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52140 --- Comment #4 from Ryan S. Arnold rsa at us dot ibm.com 2012-02-06 20:51:01 UTC --- (In reply to comment #3) Have you tried an FSF released 4.6.2? This also fails in the same way with: gcc version 4.6.3 20111209 (Advance-Toolchain-5.0-2) [ibm/gcc-4_6-branch revision 182176] (GCC) Bergner said that he'd take a look.
[Bug libstdc++/52128] [4.7 regression] r183788 caused massive libstdc++ testsuite regression on i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52128 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-06 20:51:57 UTC --- Author: redi Date: Mon Feb 6 20:51:52 2012 New Revision: 183942 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183942 Log: PR libstdc++/52128 * src/c++11/future.cc: Add explicit instantiation. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++11/future.cc
[Bug middle-end/52142] New: [trans-mem] inlined transaction_pure functions are instrumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52142 Bug #: 52142 Summary: [trans-mem] inlined transaction_pure functions are instrumented Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: al...@gcc.gnu.org, r...@gcc.gnu.org Created attachment 26592 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26592 testcase with -fgnu-tm -O1 In this testcase, the function 'purefunc' has inline and transaction_pure attribute. In the optimized mode (-O), the function becomes inlined but also instrumented whereas it was annotated transaction_pure.
[Bug fortran/52044] [OOP] Invalid memory access with ALLOCATE, default initializer and polymorphic array components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52044 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||pault at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Paul Thomas pault at gcc dot gnu.org 2012-02-06 21:24:12 UTC --- This is now fixed, since __builtin_memset (two.a._data.data, 0, 96); appears after allocation. Thanks for this and all the other extracts from Damian and co.'s book! Cheers Paul
[Bug fortran/32373] not vectorized: can't determine dependence (equivalence)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32373 --- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-02-06 21:25:00 UTC --- Author: tkoenig Date: Mon Feb 6 21:24:54 2012 New Revision: 183943 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183943 Log: 2012-02-06 Thomas König tkoe...@gcc.gnu.org PR fortran/32373 * gfortran.dg/vect/vect-8.f90: Use vect_double effective target. Remove module. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/vect/vect-8.f90
[Bug libstdc++/52128] [4.7 regression] r183788 caused massive libstdc++ testsuite regression on i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52128 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-06 21:24:21 UTC --- fixed
[Bug c++/52035] [4.7 regression] internal compiler error: tree code ‘template_type_parm’ is not supported in LTO streams
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52035 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2012-02-06 21:28:32 UTC --- The problem here is that when we go to instantiate QVectorint, we step through the members in order. When we instantiate the declaration of insert, we're using the declaration from the out-of-class definition, which uses the size_type typedef. But we haven't instantiated size_type yet, so tsubst thinks that we're instantiating it now, and we end up just returning the version from the template.
[Bug c++/52126] [4.7 Regression] compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52126 --- Comment #3 from fabien at gcc dot gnu.org 2012-02-06 21:31:30 UTC --- I'll be assigning myself to this bug when I come back from vacation next monday.
[Bug fortran/52143] New: [OOP] ICE with polymorphic function result in gfc_class_vptr_get
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52143 Bug #: 52143 Summary: [OOP] ICE with polymorphic function result in gfc_class_vptr_get Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: pa...@gcc.gnu.org Found when creating a test case for PR 51514. The following code causes an test.f90:8:0: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_class_vptr_get, at fortran/trans-expr.c:78 which is at vptr = gfc_advance_chain (TYPE_FIELDS (TREE_TYPE (decl)), CLASS_VPTR_FIELD); Backtrace: #0 gfc_class_vptr_get (decl=0x2cce2600) at trans-expr.c:78 #1 0x005d3f0d in gfc_vtable_field_get (decl=optimized out, field=1) at trans-expr.c:91 #2 0x005b1fa5 in build_class_array_ref (index=0x2cbc3c90, base=0x2cced2a8, se=optimized out) at trans-array.c:2984 #3 gfc_conv_scalarized_array_ref (se=0x7fffce20, ar=optimized out) at trans-array.c:3037 #4 0x005b2852 in gfc_conv_array_ref (se=0x7fffce20, ar=0x174a888, sym=optimized out, where=optimized out) at trans-array.c:3112 #5 0x005db098 in gfc_conv_variable (se=0x7fffce20, expr=0x174a620) at trans-expr.c:1333 #6 0x005da874 in gfc_conv_expr_reference (se=0x7fffce20, expr=optimized out) at trans-expr.c:5610 #7 0x005de0b0 in gfc_conv_procedure_call (se=0x7fffcff0, sym=0x173e1f0, args=0x1746b50, expr=0x174aa10, append_args=0x0) at trans-expr.c:3540 #8 0x006020c5 in gfc_trans_call (code=0x174af90, dependency_check=optimized out, mask=0x0, count1=0x0, invert=false) at trans-stmt.c:468 module mod_subpr type :: foo integer :: i = 2 end type contains function g () class(foo), allocatable :: g(:) allocate (g(3)) end function g end module
[Bug middle-end/52142] [trans-mem] inlined transaction_pure functions are instrumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52142 --- Comment #1 from Patrick Marlier patrick.marlier at gmail dot com 2012-02-06 21:35:09 UTC --- Created attachment 26593 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26593 another testcase but with an asm statement the asm statement is in a transaction_pure function but diagnose a asm statement into an atomic transaction. $ ../gcc/xgcc -B/../gcc/ asm-2.c -fgnu-tm -O0 -S -o asm-2.s $ ../gcc/xgcc -B/../gcc/ asm-2.c -fgnu-tm -O1 -S -o asm-2.s asm-2.c:7:3: error: asm not allowed in atomic transaction
[Bug middle-end/28685] Multiple comparisons are not simplified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28685
--- Comment #19 from Uros Bizjak ubizjak at gmail dot com 2012-02-06 21:36:01
UTC ---
(In reply to comment #4)
Another similar, but yet different case:
Yet another similar test:
int test (int a, int b)
{
int lt = a + b 0;
int eq = a + b == 0;
if (lt)
return 1;
return eq;
}
combine pass creates:
(set (reg:CCZ 17 flags)
(compare:CCZ (plus:SI (reg/v:SI 63 [ a ])
(reg/v:SI 64 [ b ]))
(const_int 0 [0])))
(set (reg:SI 60 [ D.1710 ])
(plus:SI (reg/v:SI 63 [ a ])
(reg/v:SI 64 [ b ])))
we have a discrepancy here, since compare elimination pass expects RTX in the
form of:
[(operate)
(set-cc)]
[Bug libstdc++/52104] go1 fails to link on Solaris 8/9 x86 with native TLS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52104 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-06 21:37:09 UTC --- please let me know what issues remain on Solaris after r183920
[Bug tree-optimization/50969] 17% degradation in 168.wupwise for interleave via permutation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50969 --- Comment #3 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-02-06 21:39:38 UTC --- Author: wschmidt Date: Mon Feb 6 21:39:34 2012 New Revision: 183944 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183944 Log: 2012-02-06 Bill Schmidt wschm...@linux.vnet.ibm.com PR tree-optimization/50969 * tree-vect-stmts.c (vect_model_store_cost): Correct statement cost to use vec_perm rather than vector_stmt. (vect_model_load_cost): Likewise. * config/i386/i386.c (ix86_builtin_vectorization_cost): Change cost of vec_perm to be the same as other vector statements. * config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost): Revise cost of vec_perm for TARGET_VSX. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/rs6000/rs6000.c trunk/gcc/tree-vect-stmts.c
[Bug middle-end/30442] Expanded array initialization can use memset builtin function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30442 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Last reconfirmed|2007-01-14 05:01:04 |2012-02-06 --- Comment #6 from Uros Bizjak ubizjak at gmail dot com 2012-02-06 21:40:50 UTC --- Reconfirmed with 4.7.
[Bug tree-optimization/50969] 17% degradation in 168.wupwise for interleave via permutation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50969 William J. Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-02-06 21:41:47 UTC --- Fixed with simple permute cost change for now. A better analysis of permutes will be considered in 4.8.
[Bug fortran/51825] Fortran runtime error: Cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51825 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-06 21:55:33 UTC --- Seems to be related to PR 49791, though the patch in PR 49791 comment 19 does not help.
[Bug target/52107] IBM 128bit long double constant loaded inefficiently
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52107 --- Comment #4 from Alan Modra amodra at gcc dot gnu.org 2012-02-06 22:09:17 UTC --- Author: amodra Date: Mon Feb 6 22:09:13 2012 New Revision: 183945 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183945 Log: PR target/52107 * config/rs6000/rs6000.c (rs6000_emit_move): Don't create DImode subregs of TFmode. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791 --- Comment #20 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-06 22:18:39 UTC --- (In reply to comment #19) --- ../../libgfortran/io/list_read.c(Revision 183913) @@ -2206,3 +2211,4 @@ nml_parse_qualifier (st_parameter_dt *dt @@ -2517,2 +2518,19 @@ nml_read_obj (st_parameter_dt *dtp, name Using the two patches, the related PR 51825 is not fixed - and one additionally gets the following failures: gfortran.dg/namelist_17.f90 gfortran.dg/namelist_23.f90 gfortran.dg/namelist_42.f90 gfortran.dg/namelist_43.f90 gfortran.dg/namelist_44.f90 gfortran.dg/pr19657.f
[Bug debug/52132] [4.7 Regression] ICE in loc_descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52132 Piero Finizio p.finizio at gmail dot com changed: What|Removed |Added CC||p.finizio at gmail dot com --- Comment #3 from Piero Finizio p.finizio at gmail dot com 2012-02-06 22:59:25 UTC --- (In reply to comment #2) Created attachment 26581 [details] gcc47-pr52132.patch Untested fix. What get_true_reg does might be reasonable for code where we have quite strict requirements on what SUBREG can be applied or not, but it is definitely wrong for arbitrary SUBREGs in DEBUG_INSNs. In fact, I don't see what get_true_reg would buy us, we get at the real REG in for_each_rtx anyway and can keep the SUBREGs, FLOAT_EXTEND etc. in the DEBUG_INSN. Fix tested with gcc-4.7.0-20120126 sources, this last extracted from gcc-4.7.0-0.10.fc17.src.rpm. Now gmake works with mesa from git repository.
[Bug target/52144] New: ARM should support arm/thumb function attribute to permit different instruction sets in the same source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144 Bug #: 52144 Summary: ARM should support arm/thumb function attribute to permit different instruction sets in the same source Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: rafael.ca...@gmail.com Reference: First message of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40419 Mixing thumb and ARM in the same source is currently not possible. That would permit LTO to work when mixing those and close http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45729
[Bug debug/52132] [4.7 Regression] ICE in loc_descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52132 --- Comment #4 from Piero Finizio p.finizio at gmail dot com 2012-02-06 23:01:56 UTC --- (In reply to comment #2) Created attachment 26581 [details] gcc47-pr52132.patch Untested fix. What get_true_reg does might be reasonable for code where we have quite strict requirements on what SUBREG can be applied or not, but it is definitely wrong for arbitrary SUBREGs in DEBUG_INSNs. In fact, I don't see what get_true_reg would buy us, we get at the real REG in for_each_rtx anyway and can keep the SUBREGs, FLOAT_EXTEND etc. in the DEBUG_INSN. Fix tested with gcc-4.7.0-20120126 sources, this last extracted from gcc-4.7.0-0.10.fc17.src.rpm. Now gmake works with mesa from git repository.
[Bug target/52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||arm*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-06 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-06 23:03:04 UTC --- Confirmed.
