[Bug middle-end/52078] Bogus may be used uninitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52078 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez 2012-02-01 08:17:27 UTC --- I haven't followed development for a while, but I don't think GCC uninit analysis is powerful enough to detect this or even simpler cases like PR36550 and PR20968.
[Bug fortran/52059] [4.7 Regression] ICE in gfc_conv_variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52059 --- Comment #5 from Tobias Burnus 2012-02-01 08:34:32 UTC --- Submitted patch: http://gcc.gnu.org/ml/fortran/2012-01/msg00276.html
[Bug middle-end/52074] ICE: RTL flag check: MEM_VOLATILE_P used with unexpected rtx code 'plus' in extract_fixed_bit_field, at expmed.c:1734
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52074 --- Comment #1 from Richard Guenther 2012-02-01 09:22:39 UTC --- I suppose you can provide at least a backtrace and some debug_rtx output?
[Bug tree-optimization/52070] missing integer comparison optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52070 Richard Guenther changed: What|Removed |Added Severity|normal |enhancement
[Bug middle-end/52078] Bogus may be used uninitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52078 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-01 Blocks||24639 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2012-02-01 09:28:49 UTC --- Yeah, it's simply too confusing code for GCCs static analysis. Thus the "may be used uninitialized".
[Bug target/52076] bloated code for setting single bits in bitfields on m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52076 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-01 Ever Confirmed|0 |1 Severity|normal |enhancement
[Bug tree-optimization/52073] [4.7 Regression] ICE: vector VEC(vec_void_p,base) index domain error, in vinfo_for_stmt at tree-vectorizer.h:620
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52073 --- Comment #3 from Jakub Jelinek 2012-02-01 09:43:07 UTC --- Created attachment 26538 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26538 gcc47-pr52073.patch Thanks for the report. Untested fix.
[Bug tree-optimization/52073] [4.7 Regression] ICE: vector VEC(vec_void_p,base) index domain error, in vinfo_for_stmt at tree-vectorizer.h:620
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52073 Jakub Jelinek changed: What|Removed |Added CC||irar at gcc dot gnu.org --- Comment #4 from Jakub Jelinek 2012-02-01 09:45:18 UTC --- Ira, does this look reasonable? We give up later on because we don't handle such reductions, but for the test "is this pattern result used by some other pattern stmt" I think it is correct to ignore uses outside of the loop.
[Bug target/52080] New: Stores to bitfields introduce a store-data-race on adjacent data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080
Bug #: 52080
Summary: Stores to bitfields introduce a store-data-race on
adjacent data
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
Target: ia64-*-linux
For the following testcase we generate a 8 byte RMW cycle on IA64 which
causes locking problems in the linux kernel btrfs filesystem.
struct x {
long a;
unsigned int lock;
unsigned int full : 1;
};
void
wrong(struct x *ptr)
{
ptr->full = 1;
}
[Bug c++/17729] [4.4/4.5/4.6/4.7 Regression] Duplicate __attribute__((deprecated)) warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17729 Iain Sandoe changed: What|Removed |Added Attachment #20407|0 |1 is obsolete|| --- Comment #24 from Iain Sandoe 2012-02-01 10:18:58 UTC --- Created attachment 26539 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26539 rebased patch This rebased to r183760. Hm. What pr50308 shows is that it's not just about eliminating a duplicate messages, but also about where the test is done. I.E. late enough in the proceedings that overloading and ADL are accounted. Perhaps this patch could be re-considered on that basis (IIUC, Jason's proposed amendment was to replace this change with a hash table recording the fact that we had already emitted a warning and thus suppressing subsequent ones) [see the thread referred above for details]. Clearly just recording the fact we've emitted a warning doesn't help if that warning should not have been emitted in the first place. This patch does NOT fix PR50308 (so, there is either another problem or we are still not making the test in the right place). The patch still fixes the current PR (17729). It might be that it can be amended to deal with PR50308 as well - don't have any time available right now to look. Otherwise, I don't think I know the c++ FE well enough to suggest a better place to put the test.
[Bug target/52080] Stores to bitfields introduce a store-data-race on adjacent data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080 Richard Guenther changed: What|Removed |Added Target|ia64-*-linux|ia64-*-linux, ||sparc64-*-linux CC||ebotcazou at gcc dot ||gnu.org --- Comment #1 from Richard Guenther 2012-02-01 10:22:51 UTC --- SPARC64 is also affected. ;; ptr_1(D)->full = 1; (insn 6 5 7 (set (reg:DI 110) (mem/j:DI (plus:DI (reg/v/f:DI 109 [ ptr ]) (const_int 8 [0x8])) [0+8 S8 A64])) t.c:10 -1 (nil)) (insn 7 6 8 (set (reg:DI 112) (const_int 2147483648 [0x8000])) t.c:10 -1 (nil)) (insn 8 7 9 (set (reg:DI 111) (ior:DI (reg:DI 110) (reg:DI 112))) t.c:10 -1 (nil)) (insn 9 8 0 (set (mem/j:DI (plus:DI (reg/v/f:DI 109 [ ptr ]) (const_int 8 [0x8])) [0+8 S8 A64]) (reg:DI 111)) t.c:10 -1 (nil)) wrong: ldx [%o0+8], %g2 sethi %hi(2147483648), %g1 or %g2, %g1, %g1 jmp %o7+8 stx%g1, [%o0+8] At least IA64 also can do 4-byte loads/stores (but not sure the HW wouldn't re-introduce the data race).
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #30 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-02-01 10:23:33 UTC --- > --- Comment #29 from Jonathan Wakely 2012-01-31 > 19:09:00 UTC --- > (N.B. that ChangeLog entry cited the wrong PR) I know, I've already corrected the ChangeLog. > The wording quoted in comment 25 is a POSIX defect: > http://austingroupbugs.net/view.php?id=70#c127 Ok. Unfortunately this doesn't help for Tru64 UNIX, which won't change at this point. I wonder if we could use pthread_mutex_init() only for the threads support instead of globally? Otherwise, we should probably disable it on osf instead of leaving it broken. Rainer
[Bug tree-optimization/52081] New: Missed tail merging with pure calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52081
Bug #: 52081
Summary: Missed tail merging with pure calls
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vr...@gcc.gnu.org
pr51879-12.c:
...
__attribute__((pure)) int bar (int);
__attribute__((pure)) int bar2 (int);
void baz (int);
int x, z;
void
foo (int y)
{
int a = 0;
if (y == 6)
{
a += bar (7);
a += bar2 (6);
}
else
{
a += bar2 (6);
a += bar (7);
}
baz (a);
}
...
When compiling at -O2, pr51879-12.c.094t.pre looks like this:
...
# BLOCK 3 freq:1991
# PRED: 2 [19.9%] (true,exec)
# VUSE <.MEMD.1722_12(D)>
# USE = nonlocal escaped
D.1717_4 = barD.1703 (7);
# VUSE <.MEMD.1722_12(D)>
# USE = nonlocal escaped
D.1718_6 = bar2D.1705 (6);
aD.1713_7 = D.1717_4 + D.1718_6;
goto ;
# SUCC: 5 [100.0%] (fallthru,exec)
# BLOCK 4 freq:8009
# PRED: 2 [80.1%] (false,exec)
# VUSE <.MEMD.1722_12(D)>
# USE = nonlocal escaped
D.1720_8 = bar2D.1705 (6);
# VUSE <.MEMD.1722_12(D)>
# USE = nonlocal escaped
D.1721_10 = barD.1703 (7);
aD.1713_11 = D.1720_8 + D.1721_10;
# SUCC: 5 [100.0%] (fallthru,exec)
# BLOCK 5 freq:1
# PRED: 3 [100.0%] (fallthru,exec) 4 [100.0%] (fallthru,exec)
# aD.1713_1 = PHI
# .MEMD.1722_13 = VDEF <.MEMD.1722_12(D)>
# USE = nonlocal
# CLB = nonlocal
bazD.1707 (aD.1713_1);
# VUSE <.MEMD.1722_13>
return;
...
Value numbering numbers the two phi arguments a_7 and a_11 the same so the
problem is not in value numbering:
...
Setting value number of a_11 to a_7 (changed)
...
[Bug target/52080] Stores to bitfields introduce a store-data-race on adjacent data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080
--- Comment #2 from Richard Guenther 2012-02-01
10:25:21 UTC ---
SPARC64 also can do 32bit loads/stores as the following testcase shows:
struct x {
long a;
unsigned int lock;
unsigned int full;
};
void
wrong(struct x *ptr)
{
ptr->full = 1;
}
here we simply use a 32bit store.
[Bug tree-optimization/52081] Missed tail merging with pure calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52081 --- Comment #1 from vries at gcc dot gnu.org 2012-02-01 10:27:01 UTC --- Created attachment 26540 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26540 tentative patch
[Bug middle-end/52082] New: Memory loads not rematerialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52082
Bug #: 52082
Summary: Memory loads not rematerialized
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: missed-optimization, ra
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: vmaka...@gcc.gnu.org
Target: x86_64-linux
On the following testcase at -O2 (distilled from genautomata.c):
struct S { unsigned long *s1; struct S *s2; };
int v1 __attribute__((visibility ("hidden")));
struct T
{
int a, b, c;
} *v2 __attribute__((visibility ("hidden")));
struct S **v3 __attribute__((visibility ("hidden")));
struct S **v4 __attribute__((visibility ("hidden")));
int __attribute__((noinline, noclone))
foo (unsigned long *x, unsigned long *y, int z)
{
int j, k, l;
unsigned int i;
struct S *m;
for (j = 0; j < v1; j++)
if (y[j])
for (i = 0; i < 8 * sizeof (unsigned long); i++)
if ((y[j] >> i) & 1)
{
k = j * 8 * sizeof (unsigned long) + i;
if (k >= v2->c)
break;
for (m = (z ? v4 [k] : v3 [k]); m != ((void *)0); m = m->s2)
{
for (l = 0; l < v1; l++)
if ((x [l] & m->s1 [l]) != m->s1 [l] && m->s1 [l])
break;
if (l >= v1)
return 0;
}
}
return 1;
}
tree LIM moves the loads from v2/v3/v4 before the loop, but unfortunately the
register pressure is high and the pseudos holding the v3/v4 pointers don't get
a a hard register and are immediately spilled to the stack. I wonder whether
we couldn't instead just rematerialize them and put the original MEM loads into
the loop (assuming they don't alias with anything on the way, but that must be
the case here when LIM moved them there first, after all this loop doesn't have
any MEM stores at all).
[Bug target/52080] Stores to bitfields introduce a store-data-race on adjacent data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080 Richard Guenther changed: What|Removed |Added Depends on||48124 --- Comment #3 from Richard Guenther 2012-02-01 10:38:58 UTC --- For SPARC64 optimize_bitfield_assignment_op fails so we fall into the store_field path with mode1 == VOIDmode (what get_inner_refrence says). to_rtx is (mem/j:BLK (reg/v/f:DI 109 [ ptr ]) [2 *ptr_1(D)+0 S1 A64]) Related bug: PR48124.
[Bug tree-optimization/52073] [4.7 Regression] ICE: vector VEC(vec_void_p,base) index domain error, in vinfo_for_stmt at tree-vectorizer.h:620
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52073 Ira Rosen changed: What|Removed |Added CC||irar at il dot ibm.com --- Comment #5 from Ira Rosen 2012-02-01 10:42:42 UTC --- Yes, looks fine to me.
[Bug libgcj/51500] [4.7 regression] 106 unexpected libjava testsuite failures with mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51500 --- Comment #19 from Kai Tietz 2012-02-01 10:46:40 UTC --- Author: ktietz Date: Wed Feb 1 10:46:36 2012 New Revision: 183794 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183794 Log: PR target/51500 * interpret.cc (_Jv_init_cif): Handle thiscall convention for 32-bit Windows. * java/lang/reflect/natMethod.cc (_Jv_CallAnyMethodA): Likewise. * java/lang/reflect/natVMProxy.cc (invoke_t): Add thiscall-attribute for 32-bit Windows. Modified: trunk/libjava/ChangeLog trunk/libjava/interpret.cc trunk/libjava/java/lang/reflect/natMethod.cc trunk/libjava/java/lang/reflect/natVMProxy.cc
[Bug c++/52069] ARM: initialization of static member in template struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52069 --- Comment #8 from Thomas Betker 2012-02-01 10:51:58 UTC --- > There's a reason the standard says "no diagnostic required." > > When compiling libtmpl.so, how is the compiler supposed to know that a > different translation unit which it can't see (and which might not even have > been written yet) will implicitly instantiate the member? When compiling > main.o, how is the compiler supposed to know that an explicit specialization > exists in a separate translation unit which it can't see? Okay. So if I read the quote correctly, the standard does not require explicit specialization, it just requires that an explicit specialization, if present, is declared before any implicit instantiation. This explains why no there is no warning if the explicit specialization is missing. However, this also means that the test case does not violate the quoted rule because there is simply no explicit specialization at all. I am quite willing to believe that it is ill-formed, but the reason lies probably in the rules for implicit specialization; I will have to read up on this. > With optimisation enabled the compilation of main.o probably removes condition > because the constant is known to be zero because there has been no explicit > specialization declared. Without optimisation a weak symbol is emitted, which > may or may not be replaced by the weak symbol in libtmpl.so that has a > different value. objdump says that the symbol S::id both in testbug and in libtmpl.so (with and without optimization) is a global, strong object in .bss; the symbol (exists and) is undefined in main.o. Without optimization, S::id is initialized in libtmpl.so by __static_initialization_and_destruction_0(int, int) [which is called by '::id']. When run on the target, the function is relocated to point to the object in testbug (i did a disassembly in gdb). So in some sense, it S::id in libtmpl.so is indeed treated as a weak object. With optimization, S::id is initialized in libtmpl.so directly by 'global constructors keyed to S::id'. When run on the target, the function still points to the object in libtmpl.so, which no longer seems to be weak. I am afraid that this inconsistency still bothers me, apart from the fact that I couldn't reproduce the problem for x86. When the explicit specialization is added in tmpl.h, or just in tmpl.cpp, the symbol S::id both in testbug and in libtmpl.so (with optimization) is a global, weak object in .bss.
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |4.7.0 --- Comment #31 from Jonathan Wakely 2012-02-01 10:58:32 UTC --- (In reply to comment #30) > I wonder if we could use pthread_mutex_init() only for > the threads support instead of globally? I'll add some extra preprocessor conditions around the mutex init code, so that os_defines.h can force std::mutex to use the init function even if the INIT macro is defined by gthr-posix.h That should also help for PR 51906
[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-01 AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #35 from Jonathan Wakely 2012-02-01 11:01:12 UTC --- (In reply to comment #34) > A recursive mutex using pthread_mutex_init() works. Thanks for the analysis. I'm going to add some extra preprocessor conditions around the __mutex_base and __recursive_mutex_base initialization so that target maintainers can force use of the pthread_mutex_init function on an OS-by-OS basis. That should allow this issue to be fixed for Lion and PR 51296 to be fixed for Tru64.
[Bug libstdc++/51795] linear_congruential_engine doesn't work correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795 --- Comment #29 from paolo at gcc dot gnu.org 2012-02-01 11:10:35 UTC --- Author: paolo Date: Wed Feb 1 11:10:30 2012 New Revision: 183795 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183795 Log: 2012-02-01 Paolo Carlini PR libstdc++/51795 * include/bits/random.h (linear_congruential_generator): Add static_assert preventing instantiation for values of 'a' and 'm' currently handled incorrectly but _Mod::__calc. * include/bits/random.tcc (seed_seq::generate): Avoid unsafe uses of _Mod::__calc. Modified: branches/gcc-4_6-branch/libstdc++-v3/ChangeLog branches/gcc-4_6-branch/libstdc++-v3/include/bits/random.h branches/gcc-4_6-branch/libstdc++-v3/include/bits/random.tcc
[Bug target/52080] Stores to bitfields introduce a store-data-race on adjacent data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080 --- Comment #4 from Richard Guenther 2012-02-01 11:12:41 UTC --- Btw, offset = bitnum / unit; bitpos = bitnum % unit; byte_offset = (bitnum % BITS_PER_WORD) / BITS_PER_UNIT + (offset * UNITS_PER_WORD); byte_offset is bollocks (or has a really poor name). On SPARC64 I see (gdb) p unit $11 = 8 (gdb) p offset $12 = 12 (gdb) p bitpos $13 = 0 (gdb) p byte_offset $14 = 100 Other than that we are falling into the generic store_fixed_bit_field routine which at the top does unsigned int total_bits = BITS_PER_WORD; and mode = GET_MODE (op0); if (GET_MODE_BITSIZE (mode) == 0 || GET_MODE_BITSIZE (mode) > GET_MODE_BITSIZE (word_mode)) mode = word_mode; (now, why we use a BLKmode mem here and not a QImode mem may be surprising) get_best_mode still returns DImode because that's the largest mode the given alignment supports. After that we're lost. So it seems that to fix this case we'd need to figure out some other largest mode we can pass to get_best_mode. The only hint would be from providing a different mode for the initial MEM we create, like with Index: gcc/expr.c === --- gcc/expr.c (revision 183791) +++ gcc/expr.c (working copy) @@ -4705,6 +4705,12 @@ expand_assignment (tree to, tree from, b to_rtx = adjust_address (to_rtx, mode1, 0); else if (GET_MODE (to_rtx) == VOIDmode) to_rtx = adjust_address (to_rtx, BLKmode, 0); + else if (TREE_CODE (to) == COMPONENT_REF + && DECL_BIT_FIELD (TREE_OPERAND (to, 1)) + && DECL_MODE (TREE_OPERAND (to, 1)) != BLKmode) + to_rtx = adjust_address (to_rtx, +TYPE_MODE (DECL_BIT_FIELD_TYPE + (TREE_OPERAND (to, 1))), 0); } if (offset != 0) That avoids the use of QImode we have on the field-decl but also adjusts MEM_SIZE ...
[Bug target/52076] bloated code for setting single bits in bitfields on m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52076 --- Comment #1 from Andreas Schwab 2012-02-01 11:15:57 UTC --- gcc 4.1 and before generate or.b #-128,(%a0) instead of bfins. As a consequence of this they also generate moveq.l #4,%d0 instead of move.b, but never shorten the write.
[Bug tree-optimization/51879] Missed tail merging with non-const/pure calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51879 --- Comment #8 from vries at gcc dot gnu.org 2012-02-01 11:20:31 UTC --- submitted patch: http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01513.html
[Bug rtl-optimization/51374] [avr] insn combine reorders volatile memory accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51374 --- Comment #9 from Georg-Johann Lay 2012-02-01 11:35:37 UTC --- Author: gjl Date: Wed Feb 1 11:35:34 2012 New Revision: 183796 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183796 Log: gcc/ PR rtl-optimization/51374 * combine.c (can_combine_p): Don't allow volatile_refs_p insns to cross other volatile_refs_p insns. gcc/testsuite/ PR rtl-optimization/51374 * testsuite/gcc.target/avr/torture/pr51374-1.c: New. Added: trunk/gcc/testsuite/gcc.target/avr/torture/pr51374-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/52074] ICE: RTL flag check: MEM_VOLATILE_P used with unexpected rtx code 'plus' in extract_fixed_bit_field, at expmed.c:1734
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52074
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek 2012-02-01
11:47:00 UTC ---
C testcase (-m64 -O2):
struct S { const char *d, *e; } __attribute__((packed));
void
foo (const char **p, struct S *q)
{
*p = "abcdef";
q->d = "ghijk";
}
I'd say the bug is in the section anchor support (and the bug goes away with
-O2 -fno-section-anchors; so I'd expect this is a regression since
-fsection-anchors has been introduced and made default on ppc64), because
expand_normal on ADDR_EXPR of the STRING_CST returns a PLUS (which IMHO should
be ok only for EXPAND_SUM etc. but not EXPAND_NORMAL).
[Bug middle-end/52074] ICE: RTL flag check: MEM_VOLATILE_P used with unexpected rtx code 'plus' in extract_fixed_bit_field, at expmed.c:1734
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52074 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-01 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Jakub Jelinek 2012-02-01 12:05:29 UTC --- Created attachment 26541 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26541 gcc47-pr52074.patch Untested fix.
[Bug middle-end/48124] [4.4/4.5/4.6/4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124
Richard Guenther changed:
What|Removed |Added
Blocks|52080 |
--- Comment #9 from Richard Guenther 2012-02-01
12:34:55 UTC ---
Simpler patch I am going to test. Let's hope the wreckage adjust_address
does to the to_rtx MEM (apart from setting its mode) is harmless.
Index: expr.c
===
--- expr.c (revision 183791)
+++ expr.c (working copy)
@@ -4705,6 +4705,21 @@ expand_assignment (tree to, tree from, b
to_rtx = adjust_address (to_rtx, mode1, 0);
else if (GET_MODE (to_rtx) == VOIDmode)
to_rtx = adjust_address (to_rtx, BLKmode, 0);
+ /* If the alignment of tem is larger than its size and we
+are performing a bitfield access limit the mode we use
+for the access to make sure we do not access the decl
+beyond its end. See PR48124. */
+ else if (GET_MODE (to_rtx) == BLKmode
+ && mode1 == VOIDmode
+ && DECL_P (tem)
+ && TREE_CODE (DECL_SIZE (tem)) == INTEGER_CST
+ && TREE_INT_CST_LOW (DECL_SIZE (tem)) % DECL_ALIGN (tem))
+ {
+ mode1 = mode_for_size (TREE_INT_CST_LOW (DECL_SIZE (tem))
+% DECL_ALIGN (tem),
+MODE_INT, 0);
+ to_rtx = adjust_address (to_rtx, mode1, 0);
+ }
}
if (offset != 0)
[Bug rtl-optimization/51374] [avr] insn combine reorders volatile memory accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51374 --- Comment #10 from Georg-Johann Lay 2012-02-01 12:40:26 UTC --- Author: gjl Date: Wed Feb 1 12:40:23 2012 New Revision: 183797 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183797 Log: gcc/ Backport from mainline r183796 PR rtl-optimization/51374 * combine.c (can_combine_p): Don't allow volatile_refs_p insns to cross other volatile_refs_p insns. gcc/testsuite/ Backport from mainline r183796 PR rtl-optimization/51374 * testsuite/gcc.target/avr/torture/pr51374-1.c: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.target/avr/torture/pr51374-1.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/combine.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug ada/51483] [4.7 regression] cstand.adb:Register_Float_Type makes invalid assumptions about FP representation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51483 --- Comment #9 from Mikael Pettersson 2012-02-01 12:42:44 UTC --- (In reply to comment #8) > /tmp/gcc-4.7-20110820/gcc/ada -g -O2 -W -Wall -Wwrite-strings > -Wstrict-prototypes -Wmissing-prototypes -gnatpg -gnata -I- > /tmp/gcc-4.7-20110820/gcc/ada/ali-util.adb > scng.adb:1799:47: "SPARK" is undefined > gnatmake: "/tmp/gcc-4.7-20110820/gcc/ada/ali-util.adb" compilation error This is a generic problem affecting all cross-builds, caused by r177183. For instance, a gcc-4.6.2 host gcc fails to build gcc-4.7-20120128 as a cross to sparc64-linux with the above error, even though native builds on sparc64-linux have no problems building the same gcc-4.7-20120128 with an even older gcc-4.4.6 host compiler. However, in the brief period between r177141 and r177183, applying my tentative patch did allow a successful build of a gcc-4.7 cross to m68k w/ ada, so I'll try a native bootstrap with it soonish.
[Bug rtl-optimization/51374] [avr] insn combine reorders volatile memory accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51374 --- Comment #11 from Georg-Johann Lay 2012-02-01 12:46:42 UTC --- Author: gjl Date: Wed Feb 1 12:46:39 2012 New Revision: 183798 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183798 Log: PR rtl-optimization/51374 * gcc.target/avr/torture/pr51374-1.c: Also fail if SBIS is seen. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/avr/torture/pr51374-1.c
[Bug middle-end/48124] [4.4/4.5/4.6/4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124
--- Comment #10 from Richard Guenther 2012-02-01
12:48:56 UTC ---
(In reply to comment #9)
> Simpler patch I am going to test. Let's hope the wreckage adjust_address
> does to the to_rtx MEM (apart from setting its mode) is harmless.
>
> Index: expr.c
> ===
> --- expr.c (revision 183791)
> +++ expr.c (working copy)
> @@ -4705,6 +4705,21 @@ expand_assignment (tree to, tree from, b
> to_rtx = adjust_address (to_rtx, mode1, 0);
> else if (GET_MODE (to_rtx) == VOIDmode)
> to_rtx = adjust_address (to_rtx, BLKmode, 0);
> + /* If the alignment of tem is larger than its size and we
> +are performing a bitfield access limit the mode we use
> +for the access to make sure we do not access the decl
> +beyond its end. See PR48124. */
> + else if (GET_MODE (to_rtx) == BLKmode
> + && mode1 == VOIDmode
> + && DECL_P (tem)
> + && TREE_CODE (DECL_SIZE (tem)) == INTEGER_CST
> + && TREE_INT_CST_LOW (DECL_SIZE (tem)) % DECL_ALIGN (tem))
> + {
> + mode1 = mode_for_size (TREE_INT_CST_LOW (DECL_SIZE (tem))
> +% DECL_ALIGN (tem),
> +MODE_INT, 0);
> + to_rtx = adjust_address (to_rtx, mode1, 0);
> + }
> }
>
>if (offset != 0)
Or rather
Index: gcc/expr.c
===
--- gcc/expr.c (revision 183791)
+++ gcc/expr.c (working copy)
@@ -4705,6 +4705,22 @@ expand_assignment (tree to, tree from, b
to_rtx = adjust_address (to_rtx, mode1, 0);
else if (GET_MODE (to_rtx) == VOIDmode)
to_rtx = adjust_address (to_rtx, BLKmode, 0);
+ /* If the alignment of tem is larger than its size and we
+are performing a bitfield access limit the mode we use
+for the access to make sure we do not access the decl
+beyond its end. See PR48124. */
+ else if (GET_MODE (to_rtx) == BLKmode
+ && mode1 == VOIDmode
+ && DECL_P (tem)
+ && TREE_CODE (DECL_SIZE (tem)) == INTEGER_CST
+ && (TREE_INT_CST_LOW (DECL_SIZE (tem))
+ & (DECL_ALIGN (tem) - 1)) != 0)
+ {
+ unsigned HOST_WIDE_INT mis;
+ mis = TREE_INT_CST_LOW (DECL_SIZE (tem)) & (DECL_ALIGN (tem) -
1);
+ mode1 = mode_for_size (mis & -mis, MODE_INT, 0);
+ to_rtx = adjust_address (to_rtx, mode1, 0);
+ }
}
if (offset != 0)
[Bug rtl-optimization/51374] [avr] insn combine reorders volatile memory accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51374 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #12 from Georg-Johann Lay 2012-02-01 12:56:06 UTC --- Fixed for the milestone.
[Bug middle-end/48124] [4.4/4.5/4.6/4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 --- Comment #11 from Richard Guenther 2012-02-01 12:57:12 UTC --- *** Bug 49758 has been marked as a duplicate of this bug. ***
[Bug target/49758] -O2 incorrectly swaps overlapping memory accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49758 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Richard Guenther 2012-02-01 12:57:12 UTC --- Fixed by my proposed fix for PR48124. *** This bug has been marked as a duplicate of bug 48124 ***
[Bug middle-end/48124] [4.4/4.5/4.6/4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 --- Comment #12 from Richard Guenther 2012-02-01 13:05:33 UTC --- *** Bug 51176 has been marked as a duplicate of this bug. ***
[Bug c/51176] possible integer wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51176 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Richard Guenther 2012-02-01 13:05:33 UTC --- It is. *** This bug has been marked as a duplicate of bug 48124 ***
[Bug target/52079] ICE in aggregate_value_p while building libgo on arm-linux-gnueabihf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52079 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-01 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek 2012-02-01 13:43:03 UTC --- Created attachment 26542 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26542 gcc47-pr52079.patch Untested fix. While the c-family/fortran/lto/ada lang_hooks.types.type_for_mode returns non-NULL for TImode (it creates a type for 2 * HOST_BITS_PER_WIDE_INT bitsize), go (and assuming java too) just return NULL. This is an attempt to try harder in this case, another alternative would be for go/java type_for_mode and type_for_size langhooks to return non-NULL for TImode resp. 128-bit size (using build_nonstandard_integer_type), at least when HOST_BITS_PER_WIDE_INT >= 64 (like other FEs do).
[Bug middle-end/48124] [4.4/4.5/4.6/4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 --- Comment #13 from Richard Guenther 2012-02-01 13:57:52 UTC --- Doesn't work. MEM_SIZE also seems to be somewhat random, because we re-initialize it via set_mem_attributes_minus_bitpos. So we can't fixup the caller to get_best_mode easily without passing down extra knowledge. We could pass down fieldmode from store_bit_field_1 to store_fixed_bit_field and give it some more meaningful mode in the ultimate caller (expand_assignment). But then there is the HAVE_insv path which uses mode_for_extraction which would need to be disabled if that mode is bigger than fieldmode (but we don't do that at the moment, not sure why). As usual, bitfield expansion seems to be quite a messy area.
[Bug target/52079] ICE in aggregate_value_p while building libgo on arm-linux-gnueabihf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52079 --- Comment #2 from Jakub Jelinek 2012-02-01 14:01:09 UTC --- Created attachment 26543 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26543 gcc47-pr52079.patch Alternate patch for the GO FE. There are hundreds of other lang_hooks.types.type_for_mode callers, so this variant seems to be safer to me, at least at this point.
[Bug middle-end/48124] [4.4/4.5/4.6/4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 --- Comment #14 from Richard Guenther 2012-02-01 14:17:05 UTC --- I remember (bug number?) we have the same issue with multi-word accesses where the last part uses word_mode (all other pieces as well, of course) and that accesses the object out-of-bounds.
[Bug target/52079] ICE in aggregate_value_p while building libgo on arm-linux-gnueabihf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52079 Jakub Jelinek changed: What|Removed |Added Attachment #26543|0 |1 is obsolete|| --- Comment #3 from Jakub Jelinek 2012-02-01 14:17:54 UTC --- Created attachment 26544 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26544 gcc47-pr52079-2.patch The alternate patch for real this time.
[Bug target/52079] ICE in aggregate_value_p while building libgo on arm-linux-gnueabihf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52079 --- Comment #4 from Ian Lance Taylor 2012-02-01 14:22:36 UTC --- The patch to gcc/go/go-lang.c is OK. You don't need the #if as far as I'm concerned. (The whole idea of a frontend hook for type_for_mode is somewhat broken anyhow.)
[Bug middle-end/45416] [4.5/4.6 Regression] Code size regression from 4.4 for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45416 Richard Earnshaw changed: What|Removed |Added Target||arm Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.5.4 |4.7.0 --- Comment #17 from Richard Earnshaw 2012-02-01 14:47:09 UTC --- fixed. Not a wrong-code bug, so not backporting.
[Bug target/50235] Wrong code with volatile bitfields and -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50235 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Richard Guenther 2012-02-01 14:53:21 UTC --- It is. *** This bug has been marked as a duplicate of bug 48124 ***
[Bug middle-end/48124] [4.4/4.5/4.6/4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 --- Comment #15 from Richard Guenther 2012-02-01 14:53:21 UTC --- *** Bug 50235 has been marked as a duplicate of this bug. ***
[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 #25 from Eric Botcazou 2012-02-01 15:34:37 UTC --- I've changed my mind: given that we shouldn't have references outside the base object in valid programs, there must be an offset if the bitpos is negative, so we can simply add the (rounded) latter to the former. That's what the callers would have to do anyway, so we'd better factor it in get_inner_reference.
[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 #26 from Eric Botcazou 2012-02-01 15:36:06 UTC --- Created attachment 26545 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26545 Tentative fix Uros, does it fix the original issue?
[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 #28 from Richard Guenther 2012-02-01 15:41:52 UTC --- (In reply to comment #27) > (In reply to comment #25) > > I've changed my mind: given that we shouldn't have references outside the > > base > > object in valid programs, there must be an offset if the bitpos is > > negative, so > > we can simply add the (rounded) latter to the former. That's what the > > callers > > would have to do anyway, so we'd better factor it in get_inner_reference. > > I'm not sure it's the best thing to do (adjusting 'offset' by > a BITS_PER_UNIT multiple instead of whatever the caller would like the most). > Only the callers would know how they want to adjust for negative bitpos. Oh, and if you do that, please change bitpos to unsigned HOST_WIDE_INT *.
[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 #27 from Richard Guenther 2012-02-01 15:41:15 UTC --- (In reply to comment #25) > I've changed my mind: given that we shouldn't have references outside the base > object in valid programs, there must be an offset if the bitpos is negative, > so > we can simply add the (rounded) latter to the former. That's what the callers > would have to do anyway, so we'd better factor it in get_inner_reference. I'm not sure it's the best thing to do (adjusting 'offset' by a BITS_PER_UNIT multiple instead of whatever the caller would like the most). Only the callers would know how they want to adjust for negative bitpos.
[Bug middle-end/48124] [4.4/4.5/4.6/4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 --- Comment #16 from Richard Guenther 2012-02-01 15:48:15 UTC --- Created attachment 26546 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26546 another patch This patch passes bootstrap on x86_64-unknown-linux-gnu but ICEs in struct-layout tests.
[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 Eric Botcazou changed: What|Removed |Added Attachment #26545|0 |1 is obsolete|| --- Comment #29 from Eric Botcazou 2012-02-01 15:49:14 UTC --- Created attachment 26547 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26547 Correct fix This adds the missing division...
[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 #30 from Eric Botcazou 2012-02-01 15:53:25 UTC --- > I'm not sure it's the best thing to do (adjusting 'offset' by > a BITS_PER_UNIT multiple instead of whatever the caller would like the most). > Only the callers would know how they want to adjust for negative bitpos. I don't think the callers are prepared for a reference outside the base object, so there must be a offset. And I don't see what they would want to do with a negative bitpos, apart from translating it somehow or other.
[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 #31 from rguenther at suse dot de 2012-02-01 16:00:41 UTC --- On Wed, 1 Feb 2012, ebotcazou at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994 > > --- Comment #30 from Eric Botcazou 2012-02-01 > 15:53:25 UTC --- > > I'm not sure it's the best thing to do (adjusting 'offset' by > > a BITS_PER_UNIT multiple instead of whatever the caller would like the > > most). > > Only the callers would know how they want to adjust for negative bitpos. > > I don't think the callers are prepared for a reference outside the base > object, > so there must be a offset. And I don't see what they would want to do with a > negative bitpos, apart from translating it somehow or other. The base object can be an indirect reference, so yes, there doesn't have to be an overall positive offset (well, yes, to the _real_ object, but we don't see that). Yes, you have to adjust for a negative _bit_ position. But fact is the whole constant offset (even if negative) is usually returned via bitpos.
[Bug target/52055] load of 64-bit pointer reads 64 bits even when only 32 are used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52055 --- Comment #4 from Eric Botcazou 2012-02-01 16:13:43 UTC --- > So, shell we do this kind of shortening in fwprop instead? If a MEM load has > all uses subregged to a narrower mode, try to subreg it and adjust the > callers? This would be backward combining (a la REE) though, not forward propagating.
[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 #32 from Eric Botcazou 2012-02-01 16:34:30 UTC --- > The base object can be an indirect reference, so yes, there doesn't have > to be an overall positive offset (well, yes, to the _real_ object, > but we don't see that). If this is an indirect reference, there is no base object by definition. So I'm not sure we should care in get_inner_reference and, in any case, I'm not sure what to do. Probably avoid sending MEM_REF to get_inner_reference in this case, after all it's clearly not a handled_component_p-like thing.
[Bug target/52055] load of 64-bit pointer reads 64 bits even when only 32 are used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52055 --- Comment #5 from Jakub Jelinek 2012-02-01 16:35:13 UTC --- That's true, but currently REE is after reload, this combining would be better done before reload. Perhaps a separate post-combine pre-ira pass could handle that and also perhaps PR50176 (if it is somehow possible to insert CC clobbers to insns that don't have it safely). The UD/DU links computation REE does is very expensive I think.
[Bug fortran/52083] New: Misleading warning for internal procedures with names of intrinsic procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52083 Bug #: 52083 Summary: Misleading warning for internal procedures with names of intrinsic procedures Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org The following warning does not make much sense for internal procedures - their interface is known by construction The example prints: Warning: 'fraction' declared at (1) is also the name of an intrinsic. It can only be called via an explicit interface or if declared EXTERNAL. Expected: Do the same as for module procedures, namely print: Warning: 'fraction' declared at (1) may shadow the intrinsic of the same name. In order to call the intrinsic, explicit INTRINSIC declarations may be required. Example: x = fraction() contains function fraction() fraction = 1./42. end function fraction end * * * One probably needs to check: sym->ns->parent && sym->ns->parent->proc_name && sym->ns->parent->proc_name->attr.flavor != FL_MODULE The current checks are done in intrinsic.c's gfc_warn_intrinsic_shadow.
[Bug target/52080] Stores to bitfields introduce a store-data-race on adjacent data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-01 Ever Confirmed|0 |1 --- Comment #5 from Eric Botcazou 2012-02-01 17:11:10 UTC --- You probably need to add a 'volatile' somewhere to really have wrong code.
[Bug target/52080] Stores to bitfields introduce a store-data-race on adjacent data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080 --- Comment #6 from Eric Botcazou 2012-02-01 17:45:08 UTC --- get_best_mode returns DImode because of: /* Nonzero if access to memory by bytes is slow and undesirable. For RISC chips, it means that access to memory by bytes is no better than access by words when possible, so grab a whole word and maybe make use of that. */ #define SLOW_BYTE_ACCESS 1
[Bug target/52080] Stores to bitfields introduce a store-data-race on adjacent data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080 Michael Matz changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #7 from Michael Matz 2012-02-01 17:49:45 UTC --- Yeah. Which is okay for reading, but doing the same when writing is problematic.
[Bug c++/50308] __attribute__((deprecated)) incorrectly generates warning in ADL lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50308 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #2 from Iain Sandoe 2012-02-01 17:57:04 UTC --- the warning is generated from: /GCC/gcc-live-trunk/gcc/cp/semantics.c:3342 the decl is unused on entry to finish_id_expression () .. .. and marked as used (on line 3306) ... is that expected? Otherwise, I'd assume that we could guard line 3342 with say... if (TREE_USED (decl) && TREE_DEPRECATED (decl)) warn_deprecated_use (decl, NULL_TREE); dunno.. === (gdb) call debug_tree(node) > QI size unit size align 8 symtab 0 alias set -1 canonical type 0x42129f00 arg-types chain >>> used public deprecated external QI file ../tests-attr/pr50308-1.C line 1 col 6 align 8 context arguments unit size align 32 symtab 0 alias set -1 canonical type 0x4211a3c0 precision 32 min max pointer_to_this > SI file ../tests-attr/pr50308-1.C line 1 col 9 size unit size align 32 context arg-type > full-name "void A(int)" chain >
[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 #33 from Uros Bizjak 2012-02-01 18:41:59 UTC --- (In reply to comment #29) > Created attachment 26547 [details] > Correct fix > > This adds the missing division... This patch fixes both the testcase and original issue. Thanks!
[Bug target/52080] Stores to bitfields introduce a store-data-race on adjacent data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080 Peter Bergner changed: What|Removed |Added Target|ia64-*-linux, |ia64-*-linux, |sparc64-*-linux |sparc64-*-linux, ||powerpc64-*-linux CC||bergner at gcc dot gnu.org --- Comment #8 from Peter Bergner 2012-02-01 18:52:06 UTC --- This fails on powerpc64-linux as well (-m64), where we generate: ld 9,8(3) li 10,1 rldimi 9,10,31,32 std 9,8(3) blr
[Bug target/52079] ICE in aggregate_value_p while building libgo on arm-linux-gnueabihf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52079 --- Comment #5 from Jakub Jelinek 2012-02-01 18:58:51 UTC --- Author: jakub Date: Wed Feb 1 18:58:44 2012 New Revision: 183806 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183806 Log: PR target/52079 * go-lang.c (go_langhook_type_for_mode): For TImode and 64-bit HWI return build_nonstandard_integer_type result if possible. Modified: trunk/gcc/go/ChangeLog trunk/gcc/go/go-lang.c
[Bug fortran/52059] [4.7 Regression] ICE in gfc_conv_variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52059 --- Comment #6 from Tobias Burnus 2012-02-01 19:01:54 UTC --- Author: burnus Date: Wed Feb 1 19:01:49 2012 New Revision: 183807 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183807 Log: 2012-02-01 Tobias Burnus PR fortran/52059 * trans-expr.c (gfc_conv_procedure_call): Add array ref only to variables. 2012-02-01 Tobias Burnus PR fortran/52059 * gfortran.dg/elemental_function_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/elemental_function_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug boehm-gc/46311] boehm-gc build problem with uclibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46311 Douglas Mencken changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|MOVED | --- Comment #3 from Douglas Mencken 2012-02-01 19:04:19 UTC --- Re-opening this. uClibc can't stop defining __GLIBC__ due to compatibility with a lot of stuff, especially ones which use autotools. I still must apply this patch: ftp://ftp.osuosl.org/pub/manulix/scripts/build-scripts/PPFILES/ppfiles-gcc/boehm-gc_uclibc_gc.h.patch to get the current GCC to be built with GCJ. Also, by the way, in bdw-gc, starting from the http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/bdwgc-7_2alpha5-20110107.tar.bz2 release, this issue has been already fixed.
[Bug fortran/52024] [OOP] GENERIC operator cannot be resolved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52024 --- Comment #10 from Tobias Burnus 2012-02-01 19:06:11 UTC --- Author: burnus Date: Wed Feb 1 19:06:07 2012 New Revision: 183808 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183808 Log: 2012-02-01 Tobias Burnus PR fortran/52024 * module.c (MOD_VERSION): Bump. (mio_typebound_proc): Read/write is_operator from/to the .mod file. 2012-02-01 Tobias Burnus PR fortran/52024 * gfortran.dg/typebound_operator_14.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_operator_14.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/52059] [4.7 Regression] ICE in gfc_conv_variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52059 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Tobias Burnus 2012-02-01 19:12:27 UTC --- FIXED on the trunk (4.7).
[Bug fortran/52024] [OOP] GENERIC operator cannot be resolved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52024 Tobias Burnus changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #11 from Tobias Burnus 2012-02-01 19:14:54 UTC --- FIXED on the trunk (4.7). Thanks Dominique for updated test case. (In reply to comment #9) > However, I believe that test case is valid. Actually, I now think that it invalid and correctly rejected by gfortran, cf. http://gcc.gnu.org/ml/fortran/2012-01/msg00278.html
[Bug fortran/51958] [4.7 Regression] -ffrontend-optimize generates wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51958 --- Comment #3 from Thomas Koenig 2012-02-01 19:40:29 UTC --- Author: tkoenig Date: Wed Feb 1 19:40:25 2012 New Revision: 183812 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183812 Log: 2012-02-01 Thomas König PR fortran/51958 * frontend-passes.c (convert_elseif): New function. (optimize_namespace): Call it. 2012-02-01 Thomas König PR fortran/51958 * gfortran.dg/function_optimize_10.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/function_optimize_10.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/48071] [4.6/4.7 Regression] Blank line after 'all warnings being treated as errors'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48071 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-01 Component|driver |middle-end Target Milestone|--- |4.6.3 Summary|Blank line after 'all |[4.6/4.7 Regression] Blank |warnings being treated as |line after 'all warnings |errors' |being treated as errors' Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski 2012-02-01 19:41:49 UTC --- Confirmed.
[Bug driver/45166] gcc -MD misses multiple command line source files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45166 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski 2012-02-01 19:45:50 UTC --- >b.c was lost, but should be listed. It is in b.d. cat *.d a.o: a.c b.o: b.c
[Bug boehm-gc/46311] boehm-gc build problem with uclibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46311 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Andrew Pinski 2012-02-01 19:51:58 UTC --- This is a bug in uclibc defining __GLIBC__ and yes they partly get away with it but that is still the bug. Maybe if they define __GLIBC__ they should implement all the features of glibc including execinfo.h . This is why this is not a beohm-gc issue but rather an uclibc issue.
[Bug c++/50986] weak static data members with constant initializers emitted in .rodata, leading to segfault on startup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50986 --- Comment #1 from Andrew Pinski 2012-02-01 19:58:12 UTC --- I think you are violating ODR here.
[Bug middle-end/25912] Problem compiling Asterisk 1.2.2 with Debian 3.1 (Sarge) gcc (3.3.5 (Debian 1:3.3.5-13))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25912 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work|| Resolution||INVALID --- Comment #5 from Andrew Pinski 2012-02-01 20:12:16 UTC --- No feedback in almost 5 years so closing.
[Bug middle-end/31892] optimization: Loop not optimized away because of static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31892 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-01 Summary|optimization: Loop not |optimization: Loop not |optimized away |optimized away because of ||static Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski 2012-02-01 20:17:47 UTC --- Confirmed, the issue is the fortran front-end promotes A to being static. Maybe we should just add code to the middle-end that does that.
[Bug middle-end/35082] 841 unexpected failures in gfortran testsuite with GMP 2.0n ABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35082 --- Comment #5 from Andrew Pinski 2012-02-01 20:20:31 UTC --- Do you know if these work after the fixes you did recently?
[Bug go/52084] New: go tests fail to link on powerpc-linux-gnu (undefined reference to __sync_add_and_fetch_8)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52084 Bug #: 52084 Summary: go tests fail to link on powerpc-linux-gnu (undefined reference to __sync_add_and_fetch_8) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: d...@gcc.gnu.org with the patch proposed in PR52074 the build of libgo succeeds, but every test case fails with: /home/doko/gcc/snap/gcc-snapshot-20120131/build/powerpc-linux-gnu/libgo/.libs/libgo.so: undefined reference to `__sync_add_and_fetch_8' /home/doko/gcc/snap/gcc-snapshot-20120131/build/powerpc-linux-gnu/libgo/.libs/libgo.so: undefined reference to `__sync_bool_compare_and_swap_8' collect2: error: ld returned 1 exit status FAIL: fmt make[2]: *** [fmt/check] Error 1
[Bug middle-end/52074] ICE: RTL flag check: MEM_VOLATILE_P used with unexpected rtx code 'plus' in extract_fixed_bit_field, at expmed.c:1734
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52074 --- Comment #4 from Matthias Klose 2012-02-01 20:24:08 UTC --- libgo builds with this fix. libgo now fails to run every test (see PR52084).
[Bug middle-end/31509] FAIL: libgomp.fortran/omp_parse3.f90 -O3 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31509 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Andrew Pinski 2012-02-01 20:38:54 UTC --- (In reply to comment #1) > This is fixed. So closing it as such.
[Bug middle-end/35082] 841 unexpected failures in gfortran testsuite with GMP 2.0n ABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35082 --- Comment #6 from dave.anglin at bell dot net 2012-02-01 20:40:07 UTC --- On 2/1/2012 3:20 PM, pinskia at gcc dot gnu.org wrote: > Do you know if these work after the fixes you did recently? Unlikely, however, I should recheck the report and try to find the problem.
[Bug middle-end/38528] ICE while building libgfortran (gcc bootstrap)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38528 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.6.0 --- Comment #5 from Andrew Pinski 2012-02-01 20:40:30 UTC --- -combine has gone away now in 4.6.0 and above so closing as won't fix.
[Bug middle-end/39744] component references with VIEW_CONVERT_EXPR should be canonicalized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39744 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-01 Ever Confirmed|0 |1 --- Comment #2 from Andrew Pinski 2012-02-01 20:43:54 UTC --- Confirmed, right now we get: D.1711_2 = VIEW_CONVERT_EXPR(1).y.z; return D.1711_2;
[Bug fortran/51958] [4.7 Regression] -ffrontend-optimize generates wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51958 Tobias Burnus changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||burnus at gcc dot gnu.org Resolution||FIXED --- Comment #4 from Tobias Burnus 2012-02-01 20:53:15 UTC --- Mark as FIXED (4.7 trunk). Thanks for the patch Thomas!
[Bug c++/50986] weak static data members with constant initializers emitted in .rodata, leading to segfault on startup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50986 --- Comment #2 from Richard Smith 2012-02-01 21:14:35 UTC --- As noted in comment#0, I believe there is no ODR violation here. Each definition of U::k consists of the same sequence of tokens, every name refers to the same entity in both definitions, and none of the other provisions of [basic.def.odr]p5 applies. After some discussion, the proposed approach in clang is (roughly) to always generate a guard variable (initialized to 1 for a statically-initialized variable), and to put the variable and its guard variable in the same COMDAT group. Full details are in this thread: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-November/018816.html
[Bug c/52085] New: sizeof packed enum can vary without warning depending on include order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52085
Bug #: 52085
Summary: sizeof packed enum can vary without warning depending
on include order
Classification: Unclassified
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joe.eykh...@gmail.com
An enum that can be packed to 1 byte will be 4 bytes long if it is used in a
function prototype return type (or perhaps a parameter) before its declaration.
Suppose the enum is declared in header file enum.h and used in a function
prototype in header use.h. If enum.h is included first, the enum will be 1
byte long, otherwise it'll be 4 bytes.
It would be very nice if there was a warning about this at least. It would be
even better if the size of the enum was treated as indeterminate until the
declaration.
Otherwise, a structure using this enum would have different sizes in different
C files if they include those headers in different orders.
#include
enum name func(void); /* comment this out to get 1-byte enum */
enum name {
val = 1,
} __attribute__ ((__packed__));
enum name x;
int main(int argc, char **argv)
{
printf("%zd\n", sizeof(x));
return 0;
}
Here's the build and version info:
$ gcc -v -save-temps -o t t.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-redhat-linux/4.5.1/lto-wrapper
Target: i686-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch=i686
--build=i686-redhat-linux
Thread model: posix
gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 't' '-mtune=generic' '-march=i686'
/usr/libexec/gcc/i686-redhat-linux/4.5.1/cc1 -E -quiet -v t.c -mtune=generic
-march=i686 -fpch-preprocess -o t.i
ignoring nonexistent directory
"/usr/lib/gcc/i686-redhat-linux/4.5.1/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/i686-redhat-linux/4.5.1/../../../../i686-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/i686-redhat-linux/4.5.1/include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 't' '-mtune=generic' '-march=i686'
/usr/libexec/gcc/i686-redhat-linux/4.5.1/cc1 -fpreprocessed t.i -quiet
-dumpbase t.c -mtune=generic -march=i686 -auxbase t -version -o t.s
GNU C (GCC) version 4.5.1 20100924 (Red Hat 4.5.1-4) (i686-redhat-linux)
compiled by GNU C version 4.5.1 20100924 (Red Hat 4.5.1-4), GMP version
4.3.1, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128270
GNU C (GCC) version 4.5.1 20100924 (Red Hat 4.5.1-4) (i686-redhat-linux)
compiled by GNU C version 4.5.1 20100924 (Red Hat 4.5.1-4), GMP version
4.3.1, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128270
Compiler executable checksum: 96e2ff891a3517bf2aed246a142fe05d
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 't' '-mtune=generic' '-march=i686'
as -V -Qy --32 -o t.o t.s
GNU assembler version 2.20.51.0.7 (i686-redhat-linux) using BFD version version
2.20.51.0.7-6.fc14 20100318
COMPILER_PATH=/usr/libexec/gcc/i686-redhat-linux/4.5.1/:/usr/libexec/gcc/i686-redhat-linux/4.5.1/:/usr/libexec/gcc/i686-redhat-linux/:/usr/lib/gcc/i686-redhat-linux/4.5.1/:/usr/lib/gcc/i686-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/i686-redhat-linux/4.5.1/:/usr/lib/gcc/i686-redhat-linux/4.5.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 't' '-mtune=generic' '-march=i686'
/usr/libexec/gcc/i686-redhat-linux/4.5.1/collect2 --build-id --no-add-needed
--eh-frame-hdr -m elf_i386 --hash-style=gnu -dynamic-linker /lib/ld-linux.so.2
-o t /usr/lib/gcc/i686-redhat-linux/4.5.1/../../../crt1.o
/usr/lib/gcc/i686-redhat-linux/4.5.1/../../../crti.o
/usr/lib/gcc/i686-redhat-linux/4.5.1/crtbegin.o
-L/usr/lib/gcc/i686-redhat-linux/4.5.1
-L/usr/lib/gcc/i686-redhat-linux/4.5.1/../../.. t.o -lgcc --as-needed -lgcc_s
--no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/i686-redhat-linux/4.5.1/crtend.o
/usr/lib/gcc/i686-redhat-linux/4.5.1/../../../crtn.o
[Bug target/52086] New: [4.7 Regression] ICE caused by wrong peephole2 for QImode mem += reg followed by test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52086
Bug #: 52086
Summary: [4.7 Regression] ICE caused by wrong peephole2 for
QImode mem += reg followed by test
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
Target: i?86-linux
/* { dg-do compile } */
/* { dg-options "-O2" } */
/* { dg-additional-options "-fpic" { target fpic } } */
struct S { char a; char b[100]; };
int bar (void);
int baz (int);
void
foo (struct S *x)
{
if (bar () & 1)
{
char c = bar ();
baz (4);
x->a += c;
while (x->a)
x->b[c] = bar ();
}
}
ICEs on i?86-linux (and x86_64-linux -m32) starting with:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179646
[Bug target/52086] [4.7 Regression] ICE caused by wrong peephole2 for QImode mem += reg followed by test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52086 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-01 Known to work||4.6.3 Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 Known to fail||4.7.0
[Bug target/52086] [4.7 Regression] ICE caused by wrong peephole2 for QImode mem += reg followed by test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52086 --- Comment #1 from Jakub Jelinek 2012-02-01 22:01:04 UTC --- Created attachment 26548 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26548 gcc47-pr52086.patch Untested fix.
[Bug middle-end/38575] free() accept argument that has the same name with standard/builtin function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38575 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #3 from Andrew Pinski 2012-02-01 22:25:49 UTC --- t7.c:4:13: warning: attempt to free a non-heap object [-Wfree-nonheap-object] Fixed in 4.6.0 and above.
[Bug middle-end/38126] suboptimal code for (a && b || !a && !b)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38126 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-01 Ever Confirmed|0 |1 --- Comment #2 from Andrew Pinski 2012-02-01 22:37:56 UTC --- Confirmed.
[Bug middle-end/34010] [4.4/4.5/4.6/4.7 Regression] ppc64 bad stdargs codegen for zero sized objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34010 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Target|powerpc-apple-darwin9 |powerpc-apple-darwin9, ||mips*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-01 Target Milestone|--- |4.4.7 Summary|ppc64 bad stdargs codegen |[4.4/4.5/4.6/4.7 |for zero sized objects |Regression] ppc64 bad ||stdargs codegen for zero ||sized objects Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski 2012-02-01 23:01:37 UTC --- A patch was posted here: http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01564.html
[Bug c/41809] escaping address of packed field should trigger warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41809 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-01 Ever Confirmed|0 |1 --- Comment #2 from Andrew Pinski 2012-02-01 23:28:03 UTC --- Confirmed.
[Bug bootstrap/48815] configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48815 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|other |bootstrap Resolution||INVALID --- Comment #11 from Andrew Pinski 2012-02-01 23:30:35 UTC --- Closing as invalid as --disabled-shared is invalid for darwin.
[Bug driver/44080] Call GNU ld with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44080 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-01 Component|other |driver Ever Confirmed|0 |1 --- Comment #2 from Andrew Pinski 2012-02-01 23:31:17 UTC --- Confirmed. Patches goto gcc-patches@.
[Bug c++/52035] internal compiler error: tree code ‘template_type_parm’ is not supported in LTO streams
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52035 Marcin Baczyński changed: What|Removed |Added Known to work||4.6.2 --- Comment #4 from Marcin Baczyński 2012-02-01 23:39:38 UTC --- I think this should be marked as a 4.7 regression. I just tested 4.6.2 and it works. gcc version 4.6.2 (Gentoo 4.6.2 p1.3, pie-0.5.0)
[Bug testsuite/29527] make clean in libiberty/testsuite does nothing when EXEEXT is defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29527 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-01 Summary|make clean in |make clean in |libiberty/testsuite does|libiberty/testsuite does |nothing under cygwin|nothing when EXEEXT is ||defined Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski 2012-02-01 23:44:26 UTC --- Confirmed.
