[Bug target/94145] Longcalls mis-optimize loading the function address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Last reconfirmed||2020-03-11 Ever confirmed|0 |1
[Bug target/94145] Longcalls mis-optimize loading the function address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #4 from Alan Modra --- Created attachment 48022 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48022&action=edit gcc fix to make plt loads volatile This patch has some commentary explaining what is going on. Strictly speaking what is in the PLT is *not* the "address of a function". I haven't bootstrapped it yet, but Mike has used it to build spec with -mlongcalls which probably is better testing for this patch than a bootstrap anyway.
[Bug target/94145] Longcalls mis-optimize loading the function address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145 --- Comment #6 from Alan Modra --- Transformations to indirect calls and hoisting function addresses out of loops is fine. That sort of thing has nothing to do with this problem. The problem is that the PLT really is volatile, and the inline PLT code for powerpc exposes those PLT loads without letting gcc know they are in fact volatile. If gcc decides to cache a PLT load in a register and then use it for multiple calls to the same function you might end up going via the ld.so symbol resolver for every one of those calls rather than only on the first call. That is very definitely not an optimisation.
[Bug target/94145] Longcalls mis-optimize loading the function address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145 --- Comment #8 from Alan Modra --- (In reply to Richard Biener from comment #7) > OTOH CSEing the load from the PLT once it is resolved _would_ be an > optimization. Possibly. Sometimes making the call sequence seem more efficient runs into stalls particularly when the called function is short. > Asks for loop peeling I guess? Yeah, that might be one way to get the first call of a function inside a loop over and done with. And so you'd know the PLT entry was resolved and thus no longer volatile.
[Bug target/94393] Powerpc suboptimal 64-bit constant comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393 Alan Modra changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Last reconfirmed||2020-03-30 CC|amodra at gmail dot com| Status|UNCONFIRMED |ASSIGNED
[Bug target/94393] Powerpc suboptimal 64-bit constant comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393 --- Comment #1 from Alan Modra --- Created attachment 48146 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48146&action=edit teach gcc more two insn sequences for constants
[Bug target/57836] large constants evaluated inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57836 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|5.5 |11.0 Resolution|--- |DUPLICATE --- Comment #7 from Alan Modra --- Some issues related to large constants have already been fixed, thus closing this bug as a dup of pr94393 *** This bug has been marked as a duplicate of bug 94393 ***
[Bug target/94393] Powerpc suboptimal 64-bit constant comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #2 from Alan Modra --- *** Bug 57836 has been marked as a duplicate of this bug. ***
[Bug target/94393] Powerpc suboptimal 64-bit constant comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393 --- Comment #3 from Alan Modra --- There are two parts to fixing this PR. 1) We can do better in the sequences generated for some constants. 2) rs6000_rtx_costs needs to be accurate, so that expensive constants are put in memory and stay there with optimisation. Having looked at part 2 a little, I'd say fixes for that are definitely not stage 4 material.
[Bug target/94504] On powerpc, -ffunction-sections -fdata-sections is not as effective as expected for PIE and PIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504 Alan Modra changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX Summary|On powerpc, |On powerpc, |-ffunction-sections |-ffunction-sections |-fdata-sections is not as |-fdata-sections is not as |effective as expected for |effective as expected for |non-PIE executables.|PIE and PIC --- Comment #6 from Alan Modra --- For -fPIC or -fPIE on ppc32 gcc uses a per-object file compiler managed GOT (.got2). Fixed position code doesn't use a GOT. -fpic/-fpie uses a linker managed GOT but with limited size. So, correcting the summary. The problem reported here is due to the per-object file nature of .got2. (.got2 is similar to the per-object file ppc64 .toc, where compiling the testcase with -mcmodel=large gives the same link failure.) To handle -gc-sections properly, ld needs to treat .got2 specially so that a relocation reference to .got2 does not mark .got2 but rather the section referenced by the relevant .got2 entry, and then remove unneeded .got2 entries. No one has cared enough to write such linker support for ppc32 or for large code model ppc64 .toc. Alternatively gcc code generated for -fPIC/-fPIE could be changed, but again no one has cared enough to do that. Since it is very unlikely that a bugzilla entry for gcc or binutils will prompt anyone to write the necessary linker support or change gcc, I'm closing this as won't fix.
[Bug target/94145] Longcalls mis-optimize loading the function address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from Alan Modra --- Fixed for gcc-10 and next gcc-9 release.
[Bug tree-optimization/95353] [10/11 Regression] GCC can't build binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95353 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #6 from Alan Modra --- binutils code was written originally in K&R C, with quite a lot of the code base still having K&R flavour. We no doubt could move to C99 to use flexible array members and other nice features. For now, binutils is a useful "old" code base to test new gcc warnings..
[Bug target/94393] Powerpc suboptimal 64-bit constant comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393 --- Comment #7 from Alan Modra --- (In reply to Peter Bergner from comment #5) > Alan, I think you pushed some changes to help with 1) above, correct? > Is there more to do for 1)? Possibly, I haven't looked at what needs to be done (if anything) for pli. > As for 2), we're in stage1 now. Do you have ideas about what must be done > there? Do we still want to do something for 2)? I wrote a series of patches in early April.
[Bug lto/96385] [8/9/10/11 Regression] GCC generates separate debug info with undefined symbols without relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96385 --- Comment #16 from Alan Modra --- It looks fine to me, assuming you don't need to keep any of these undefined symbols.
[Bug target/96493] New: powerpc local call linkage failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96493
Bug ID: 96493
Summary: powerpc local call linkage failure
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
/* -O2 -mcpu=power8 */
static int __attribute__ ((target("cpu=power10"),noclone,noinline))
local_func (int x)
{
return x;
}
int main()
{
return local_func (0);
}
results in a linker complaint "call to `local_func' lacks nop, can't restore
toc; (toc save/adjust stub)".
rs6000.md call_local et al patterns can't be allowed to match when
caller/callee disagree about r2 usage.
[Bug target/96493] powerpc local call linkage failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96493 Alan Modra changed: What|Removed |Added Last reconfirmed||2020-08-06 Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug target/96493] powerpc local call linkage failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96493 --- Comment #2 from Alan Modra --- Yes, it is a bug present in any gcc version supporting pcrel.
[Bug testsuite/96525] new test gcc.target/powerpc/pr96493.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96525
Alan Modra changed:
What|Removed |Added
Last reconfirmed||2020-08-10
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
CC|amodra at gcc dot gnu.org |
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #4 from Alan Modra ---
Yes, the test needs power10_ok, but *not* power10_hw. Despite being a "run"
test with one function cpu=power10, no power10 insns are generated. So the
executable could in fact be run (even on a power3).
If you make the test power10_hw, then it won't be linked unless of course you
have power10 hardware or a simulator. Most people don't. We really do want
to at least link the compiler output as it is the link stage that shows up the
pr96493 problem.
I could make the test { do-do link } but running the test is just that little
bit better test of the linker output, and as far as I know there isn't a way of
saying "link this but only run on power10".
[Bug testsuite/96525] new test gcc.target/powerpc/pr96493.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96525 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Alan Modra --- Fixed
[Bug target/96493] powerpc local call linkage failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96493 Alan Modra changed: What|Removed |Added Host||gcc Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Alan Modra --- Patches applied to master and gcc-10
[Bug target/97042] New: powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042
Bug ID: 97042
Summary: powerpc64 UINT_MAX constant
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
/* -O2 -S */
long foo (long x) { return ~0u - x; }
for gcc-8 to current master
lis 9,0x
ori 9,9,0x
rldicl 9,9,0,32
subf 3,3,9
blr
a regression from gcc-7
li 9,-1
rldicl 9,9,0,32
subf 3,3,9
blr
Both sequences give the same result, this is just a code quality regression.
I haven't properly debugged this but I suspect commit 5d3ae76af13
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 --- Comment #1 from Alan Modra --- Yes, reverting 5d3ae76af13 cures this PR.
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 --- Comment #6 from Alan Modra --- That's easy. rs6000_emit_set_long_const doesn't generate that sequence. Incidentally, a patch I had to generate more constants from li;rldicl also fixes this pr.
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 --- Comment #7 from Alan Modra --- and of course, li 0x is li -1 which sets all bits.
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 --- Comment #9 from Alan Modra --- I think that splitter should disappear and rs6000_emit_set_long_const handle all special cases where you might want combinations of two logical instructions before handling the li;rldicl, li;rldicr or any other expansions with rotates.
[Bug target/97107] New: libgo fails to build for power10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97107 Bug ID: 97107 Summary: libgo fails to build for power10 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com Target Milestone: --- ld.gold: error: runtime/.libs/go-cdiv.o: failed to match split-stack sequence at section 1 offset 0 ld.gold: error: runtime/.libs/go-cdiv.o: failed to match split-stack sequence at section 1 offset 70 ld.gold: error: runtime/.libs/runtime_c.o: failed to match split-stack sequence at section 1 offset 310 ld.gold: error: reflect/.libs/makefunc_ffi_c.o: failed to match split-stack sequence at section 1 offset 1a0 Recently added rs6000 backend code allows sibcalls when pcrel. In the go-cdiv.o cases we have tail calls to __divsc3 and __divdc3 both of which are non-split-stack functions. The functions making those calls don't have a stack frame, and therefore don't have the magic split-stack instruction sequence that gold patches to allocate a larger stack. Now those __div libgcc functions don't have large stack frames that might blow the very limited stack provided, but in general you can't tail call non-split-stack functions from split-stack code. It isn't actually the sibcall that is the problem, but that rs6000_expand_split_stack_prologue didn't emit the magic code gold patches and a __morestack call. ie. a sibcall to non-split-stack code from split-stack is fine if there is sufficient stack memory mapped. __morestack is quite a surprising function on powerpc in that it calls back to its caller - and a tail call will continue running in the context of extra stack mapped until it returns.
[Bug target/97107] libgo fails to build for power10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97107 Alan Modra changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-09-18
[Bug target/97107] libgo fails to build for power10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97107 --- Comment #1 from Alan Modra --- Created attachment 49241 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49241&action=edit fix under test
[Bug sanitizer/92634] New: [gcc-8 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634 Bug ID: 92634 Summary: [gcc-8 regression] -fsanitize=undefined erroneous null pointer check Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Created attachment 47337 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47337&action=edit testcase -fsanitize=undefined inserts bogus pointer checks on expressions that effectively cast a pointer to a union to a pointer to one of the elements of that union. &p->field does not dereference p, just as &*p and &p[i] do not. This bites in binutils sources (eg. see ldlang.c lang_for_each_input_file), where &p->field is used in preference to (type_of_field *) p, since the cast loses some type checking.
[Bug sanitizer/92634] [8/9/10 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634 --- Comment #2 from Alan Modra --- (In reply to Andrew Pinski from comment #1) > No those are still officially considered a referencing. > > In fact all three cases: > &p->field does not dereference p, just as &*p and &p[i] do not. > > Should be considered a deference even though the deference does not happen. The ISO C standard ISO/IEC 9899:1999 appears to disagree with you. From 6.5.3.2 "3 The unary & operator returns the address of its operand. If the operand has type ‘‘type’’, the result has type ‘‘pointer to type’’. If the operand is the result of a unary * operator, neither that operator nor the & operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue. Similarly, if the operand is the result of a [] operator" [snip rest] I do not see anything under "constraints on the operators" that precludes &*p on a null p, in fact there is a note that says "83) Thus, &*E is equivalent to E (even if E is a null pointer)" [snip rest] So what is more official than the C standard that makes you say "those are still officially considered a referencing"?
[Bug sanitizer/92634] [8/9/10 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634
Alan Modra changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed||2019-11-23
Resolution|DUPLICATE |---
Ever confirmed|0 |1
--- Comment #5 from Alan Modra ---
How is it that "clang does this" overrides the C standard?
And yes, I quite realise that the C standard does not explicitly say &p->field
does not dereference p, but the analogy with &p[i] is strong and the fact is
that &p->field does not cause a dereference. So it ought to be good when p is
null.
I'll note that we are talking C here, not C++.
If you're going to close this bug again then do so with an explanation from a
language viewpoint as to why
void
lang_for_each_input_file (void (*func) (lang_input_statement_type *))
{
lang_input_statement_type *f;
for (f = &input_file_chain.head->input_statement;
f != NULL;
f = f->next_real_file)
if (f->flags.real)
func (f);
}
is wrong. I'm genuinely interested, not just pissed off that you've closed my
bug..
[Bug sanitizer/92634] [8/9/10 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634 --- Comment #7 from Alan Modra --- Here's another example, a typical offsetof. #define offsetof(TYPE, MEMBER) ((unsigned long) &((TYPE *)0)->MEMBER)
[Bug sanitizer/92634] [8/9/10 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634 --- Comment #11 from Alan Modra --- Oh wow, so the line of reasoning relies on what the C standard *doesn't* say in 6.5.3.2. I also think the deductions are somewhat suspect. You say &p->f is the same as &((*p).f), which is from p->f being the same as (*p).f. While I agree that is generally true, it's relying on note 79 in the spec isn't it? 79) If &E is a valid pointer expression (where & is the ‘‘address-of’’ operator, which generates a pointer to its operand), the expression (&E)->MOS is the same as E.MOS. But if we don't have &E, which we don't when p is the null pointer (by 6.3.2.3/3), then how can you use note 79 to say p->f is the same as (*p).f when p is the null pointer? Quite likely I'm missing something. However, the fact that there is old C code around from many years ago that uses the offsetof macro as I wrote it, and the fact that no compiler on earth actually dereferences p in &p->f lends credence to the idea that there is no dereference here.
[Bug lto/93384] [10 Regression] Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384 --- Comment #16 from Alan Modra --- It is possible to fix this in the assembler too, but I'm reluctant to do so. If we make some sort of promise that .set x,y .set x,y gives the same results as when only the first .set is present, then gas needs to correctly calculate "no change in y". That is complicated in the general case of an arbitrary expression for y. It's even surprisingly complicated if y is just a single symbol.
[Bug sanitizer/92634] [8/9/10 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634 --- Comment #13 from Alan Modra --- Yes, I came to the conclusion myself that this is really nothing to do with dereferencing. So my original claim and Andrew's replies about dereferencing are not relevant. The standard says of unary & "The operand of the unary & operator shall be either a function designator, the result of a [] or unary * operator, or an lvalue that designates an object that is not a bit-field and is not declared with the register storage-class specifier." We don't have a function designator, the result of a [] or unary *, so the & operand must be an lvalue. Of lvalues, the standard says (in part): "if an lvalue does not designate an object when it is evaluated, the behavior is undefined" And that along with lack of a special case for &p->f is the language reason why the binutils code was UB.
[Bug target/91052] [10 Regression] ICE in fix_reg_equiv_init, at ira.c:2705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91052 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #14 from Alan Modra --- I agree with your analysis, and that combine_and_move_insns has a bug. (That doesn't mean I should be viewed as any sort of expert on ira.c. The fact that my name appears on git blame for much of combine_and_move_insns is just due to me splitting out existing code into that function!) "!multiple_sets (def_insn)" seems the correct solution too, but I'd be inclined to move that test earlier, either before or after can_throw_internal on the grounds that asm insns might have the same problem with multiple sets. Perhaps comment that instructions with multiple sets can only be moved if DF analysis is performed for all of the registers set.
[Bug libgomp/56073] SPEComp2012 376.kdtree fails to complete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56073 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Alan Modra 2013-02-05 13:43:51 UTC --- Fixed
[Bug target/53040] nested functions may trash floating point registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53040 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Alan Modra 2013-02-06 02:39:54 UTC --- Fixed. Not a regression so not applying to FSF branches.
[Bug target/53038] cfi_restore for cr before cr is actually restored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53038 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Alan Modra 2013-02-06 03:04:58 UTC --- Fixed mainline. Not a regression so not applying to FSF branches.
[Bug target/54009] incorrect code generated for DFmode lo_sum mem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54009 --- Comment #4 from Alan Modra 2013-02-06 13:04:43 UTC --- Regressed due to pr54131 fix.
[Bug target/53040] nested functions may trash floating point registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53040 --- Comment #6 from Alan Modra 2013-02-06 13:31:45 UTC --- This one is hardly an annoying bug. You need a) nested functions, b) using floating point, c) with an unusual set of callee saved fprs, d) and -Os. I found the bug only because I wrote a fairly complete test for prologue/epilogue code. OTOH, the patch is quite obvious and completely safe..
[Bug target/44364] Wrong code with e500 double floating point
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #50 from Alan Modra 2013-02-07 01:44:07 UTC --- Fixed all currently active branches.
[Bug target/54009] incorrect code generated for DFmode lo_sum mem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54009 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Alan Modra 2013-02-07 02:46:30 UTC --- Fixed.
[Bug target/45053] libgcc_s link command misses crtsavgpr_s and crtresgpr_s for powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45053 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED CC||amodra at gmail dot com AssignedTo|unassigned at gcc dot |amodra at gmail dot com |gnu.org | --- Comment #12 from Alan Modra 2013-02-07 08:36:45 UTC --- Some of the claims made in various comments are wrong, at least for current gcc-4.7 svn rev 195829. Even the subject is wrong. libgcc_s.so *is* linked with the crtsav/res objects. They are contained in libgcc.a, and libgcc.a is used when linking libgcc_s.so. I have verified that libgcc_s.so built with -Os due to --enable-target-optspace does need various _savegpr* and _restgpr* functions. Comment #4 shows the real problem nicely. Notice that the reference to _savegpr_31 comes from crtend.o which the penultimate object on the linker command line, *after* libgcc.a. So if no other object linked needs the out-of-line register save functions they won't be extracted from libgcc.a. $ nm crtbegin.o | grep gpr U _restgpr_29_x $ nm crtend.o | grep gpr U _restgpr_31_x U _savegpr_31
[Bug target/45053] libgcc_s link command misses crtsavgpr_s and crtresgpr_s for powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45053 --- Comment #13 from Alan Modra 2013-02-07 08:40:15 UTC --- Created attachment 29382 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29382 Fix
[Bug target/55431] Invalid auxv search in ppc linux-unwind code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED CC|amodra at gcc dot gnu.org |amodra at gmail dot com AssignedTo|unassigned at gcc dot |amodra at gmail dot com |gnu.org |
[Bug target/55431] Invalid auxv search in ppc linux-unwind code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431 --- Comment #5 from Alan Modra 2013-02-12 03:04:28 UTC --- Created attachment 29420 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29420 use /proc/self/auxv At the time the original code was being developed, linux-2.4.x was in widespread use. /proc/self/auxv was introduced with linux-2.6.0 in Dec 2003. I guess it's reasonable to rely on that nowadays. BTW, it's not entirely an optimization to condition reading of altivec regs on AT_HWCAP. I believe it may be possible to segv if the unwinder tries to dereference a location past the end of struct sigcontext.
[Bug target/55431] Invalid auxv search in ppc linux-unwind code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431 --- Comment #7 from Alan Modra 2013-02-12 13:23:59 UTC --- On thinking about this a little more, the idea of using /proc/self/auxv isn't that good. MD_FALLBACK_FRAME_STATE_FOR is only needed for older kernels; Kernels 2.6.15 and later provide a vdso with unwind info for signal frames. So I don't think it makes sense to restrict libgcc's support for old kernels to 2.6.0 thru 2.6.14. If we're going to support old kernels, then we ought to continue supporting them all as best we can. And, yes, really old kernels used a different sigcontext for the simple reason that they predated altivec. I'm inclined to close this bug as WONTFIX, or possibly make __libc_stack_end weak so that libgcc builds with musl libc.
[Bug target/55431] Invalid auxv search in ppc linux-unwind code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-02/msg00744.htm ||l Resolution||FIXED --- Comment #10 from Alan Modra 2013-02-15 13:54:58 UTC --- Fixed
[Bug target/55431] Invalid auxv search in ppc linux-unwind code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431 Alan Modra changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug target/57052] New: missed optimization with rotate and mask
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57052
Bug #: 57052
Summary: missed optimization with rotate and mask
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amo...@gmail.com
/* -m32 -O -S */
int
foo (unsigned int x, int r)
{
return ((x << r) | (x >> (32 - r))) & 0xff;
}
results in:
foo:
rlwnm 3,3,4,0x
rlwinm 3,3,0,24,31
blr
Compiling the same code with -m32 -O -S -mlittle gives the properly optimized
result of:
foo:
rlwnm 3,3,4,0xff
blr
This is because many of the rs6000.md rotate/shift and mask patterns use
subregs with wrong byte offsets. eg. rotlsi3_internal7, the insn that ought to
match here, has (subreg:QI (rotate:SI ...) 0). The 0 selects the most
significant byte when BYTES_BIG_ENDIAN and the least significant when
!BYTES_BIG_ENDIAN.
Fortunately combine doesn't seem to generate subregs for high parts, so
changing the testcase mask to 0xff00 doesn't result in wrong code.
Annoyingly, rotlsi3_internal4 would match here too if combine_simplify_rtx()
didn't simplify (set (reg:SI) (and:SI () 255)) to use subregs.
[Bug target/57052] missed optimization with rotate and mask
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57052 Alan Modra changed: What|Removed |Added Target||powerpc-linux Status|UNCONFIRMED |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-04/msg01370.htm ||l Keywords||missed-optimization Last reconfirmed||2013-04-24 AssignedTo|unassigned at gcc dot |amodra at gmail dot com |gnu.org | Ever Confirmed|0 |1
[Bug target/57052] missed optimization with rotate and mask
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57052 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #1 from Alan Modra 2013-04-25 07:57:39 UTC --- http://gcc.gnu.org/ml/gcc-cvs/2013-04/msg00982.html
[Bug middle-end/57134] ICE with -mstrict-align and inline assembly on ppc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57134 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-01 CC||amodra at gmail dot com Ever Confirmed|0 |1 --- Comment #1 from Alan Modra 2013-05-01 14:32:49 UTC --- I think the bug here is that we lose EXPAND_MEMORY when recursively calling expand_expr() for the inner part of a COMPONENT_REF.
[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #2 from Alan Modra 2013-05-02 08:18:45 UTC --- BTW, running gkeytool without any args shows the problem too. When libjava is built with -g -O2, I get Exception in thread "main" java.lang.NoClassDefFoundError: gnu.classpath.tools.keytool.Main at java.lang.Class.initializeClass(natClass.cc) Caused by: java.lang.IllegalMonitorStateException: current thread not owner at java.lang.Object.notifyAll(natObject.cc:1437) at gnu.gcj.runtime.SystemClassLoader.findClass(natSystemClassLoader.cc:29) at java.lang.ClassLoader.loadClass(ClassLoader.java) at java.lang.ClassLoader.loadClass(ClassLoader.java:387) at java.lang.Class.initializeClass(natClass.cc:728) But note that natObject.cc:1437 is a lie! The real failure occurs natObject.cc:1431 and it looks like the two identical throws have merged. Putting a break on the right place, I see (gdb) p this $8 = (java::lang::Object * const) 0xffc6aec (gdb) p/x addr $9 = 0xffc6aec Uh oh! The address is not 8-byte aligned, so one of the flag bits appears to be set. This is why we appear to have locking problems.
[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074 --- Comment #3 from Alan Modra 2013-05-02 08:54:39 UTC --- In libgcj-tools.so 20316: 00456aec 144 OBJECT LOCAL DEFAULT 22 _ZN3gnu9classpath5tools7keytool17Main$ShutdownHook6class$E That's in .data, as expected. >From the .o file (classpath/tools/.libs/libgcj_tools_la-tools.o) I see this is laid out *not* at an 8 byte address. 26803: 000680ac 144 OBJECT GLOBAL HIDDEN 110 _ZN3gnu9classpath5tools7keytool17Main$ShutdownHook6class$E While the containing section is 8-byte aligned. [110] .data.rel.local PROGBITS 2151b8 07358c 00 WA 0 0 8 So a gcj bug by the look of it.
[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074 --- Comment #4 from Alan Modra 2013-05-02 11:35:20 UTC --- I believe this is triggered by powerpc turning on -fsection-anchors by default, and a section anchor bug loses the alignment. The classes are all nicely aligned if I compile with -fno-section-anchors
[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074
--- Comment #5 from Alan Modra 2013-05-02 14:01:59
UTC ---
So the section anchor code places vars (and constants) in blocks according to
their alignment and sizes (varasm.c:place_block_symbol). The calculations are
all good, offsets are properly aligned, and the overall block aligned. The
problem is that when we come to actually output the vars, in some cases we emit
*more* data than given by the size. That results in following vars being at a
different offset than originally calculated, and sometimes misaligned.
Here's an example of output showing the mismatch.
.type _atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook,
@object
.size _atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook, 24
_atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook:
.long _Utf259
.long _Utf111
.long _Utf110
.long _Utf166
.long _Utf111
.long _Utf257
.long 0
.long 0
.long 0
Notice the actual size is 36 bytes, not the 24 give by .size.
unit size
align 32 symtab 0 alias set 22 canonical type 0xfffb60f46e0 fields
pointer_to_this >
BLK
size
unit size
align 32 symtab 0 alias set 22 canonical type 0xfffb60f4788
domain
SI
size
unit size
align 32 symtab 0 alias set -1 canonical type 0xfffb60f4248
precision 32 min max >
pointer_to_this >
constant addressable asm_written used static ignored BLK file
/home/alan/src/gcc-virgin/libjava/classpath/tools/gnu/classpath/tools/keytool/Main.java
line 0 col 0 size unit size
align 32 initial
(mem/c:BLK (symbol_ref:SI
("_atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook") [flags 0x82]
) [22
_atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook+0 S24 A32]) chain
>
I'm not sure how we came to think the array had 3 elements rather than 2.
Here's that "initial" field.
unit size
align 32 symtab 0 alias set 22 canonical type 0xfffb60f46e0 fields
pointer_to_this >
BLK
size
unit size
align 32 symtab 0 alias set 22 canonical type 0xfffb60f4788
domain
SI
size
unit size
align 32 symtab 0 alias set -1 canonical type 0xfffb60f4248
precision 32 min max >
pointer_to_this >
constant lngt 3
val
constant lngt 3
idx
unsigned SI file line 0 col 0 size unit size
align 32 offset_align 128
offset
bit offset context
chain >
val
readonly constant arg 0 >
idx
unsigned SI file line 0 col 0 size unit size
align 32 offset_align 128 offset bit
offset context chain
>
val
readonly constant arg 0 >
idx
unsigned SI file line 0 col 0 size unit size
align 32 offset_align 128 offset
bit offset context
>
val
readonly constant arg 0 >>
val
constant lngt 3 idx
val
readonly constant arg 0 > idx
val idx
val
readonly constant arg 0 >>
val
constant lngt 3 idx
val idx val idx val >>
[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074 Alan Modra changed: What|Removed |Added Target Milestone|4.8.1 |--- --- Comment #10 from Alan Modra 2013-05-02 23:04:37 UTC --- Another fairly easy fix is to make output_object_block() emit the .align directives instead of padding. Yes, this covers up the real bug that Jakub has been looking at, but it might be worth doing for robustness.
[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074 --- Comment #11 from Alan Modra 2013-05-03 10:42:12 UTC --- No, of course that doesn't work. We make references into the section anchor block as .LANCHORn+offset, so the items in the block must be exactly where place_block_symbol() expects them to be.
[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074 --- Comment #12 from Alan Modra 2013-05-03 10:47:22 UTC --- Created attachment 30017 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30017 Use .org instead of padding in section anchor block This one ensures that offsets of emitted items exactly match the values calculated in place_block_symbol(). Right now that means we die building libjava with lots of "Error: attempt to move .org backwards" from gas.
[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074
--- Comment #15 from Alan Modra 2013-05-04 01:21:50
UTC ---
With this patch I'm still seeing odd trees in place_block_symbol(). In the
following, the type is the correct size (168 bytes), but the var_decl size too
small (48 bytes). place_block_symbol() uses the var_decl size. Hmm, I reckon
that's a bug in place_block_symbol(). Shouldn't it be using DECL_INITIAL size?
unit size
align 64 symtab 0 alias set 20 canonical type 0xf6072b80 fields
pointer_to_this >
BLK
size
unit size
align 64 symtab 0 alias set 20 canonical type 0xf61115c0
domain
DI
size
unit size
align 64 symtab 0 alias set -1 canonical type 0xf6111560 precision
64 min max >
pointer_to_this >
constant addressable asm_written static ignored BLK file
/home/amodra/src/gcc-current/libjava/classpath/gnu/java/awt/dnd/peer/gtk/GtkDragSourceContextPeer.java
line 0 col 0
size
constant 384>
unit size
constant 48>
align 64 initial
(mem/c:BLK (symbol_ref:DI
("_atable_syms_gnu_java_awt_dnd_peer_gtk_GtkDragSourceContextPeer") [flags
0x82] ) [20
_atable_syms_gnu_java_awt_dnd_peer_gtk_GtkDragSourceContextPeer+0 S48 A64])
chain >
[Bug middle-end/28865] Structures with a flexible arrray member have wrong .size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865
--- Comment #9 from Alan Modra 2013-05-04 14:34:39
UTC ---
>From what I see on current mainline for a testcase based on
glibc/nss/nss_files/files-init.c the var_decl size and the type size agree and
are correct. What causes a problem with -fsection-anchors is that the actual
data emitted by output_constant() is wrong.
struct traced_file
{
long pad;
char fname[];
};
#define TF(id, filename, ...)\
union\
{\
struct traced_file file;\
char buf[sizeof (struct traced_file) + sizeof (filename)];\
} id##_traced_file =\
{\
.file =\
{\
.fname = filename\
}\
}
TF (pwd, "/etc/passwd");
TF (grp, "/etc/group");
Gives me
.file"unioninit.c"
.globl grp_traced_file
.globl pwd_traced_file
.section".data"
.align 2
.LANCB0:
.org .LANCB0+0
.typegrp_traced_file, @object
.sizegrp_traced_file, 16
grp_traced_file:
.zero4
.string"/etc/group"
.zero12
.org .LANCB0+16
.typepwd_traced_file, @object
.sizepwd_traced_file, 16
pwd_traced_file:
.zero4
.string"/etc/passwd"
.zero12
.ident"GCC: (GNU) 4.9.0 20130502 (experimental)"
.section.note.GNU-stack,"",@progbits
Those ".zero 12" lines shouldn't be there.
[Bug middle-end/28865] Structures with a flexible arrray member have wrong .size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865 --- Comment #10 from Alan Modra 2013-05-04 14:39:34 UTC --- Incidentall, I expect the patch referred to in comment #6 will ICE with tree-checking on due to CONSTRUCTOR nodes not having the required fields for DECL_SIZE_UNIT.
[Bug c/57180] New: Structures with a flexible arrray member have wrong size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57180
Bug #: 57180
Summary: Structures with a flexible arrray member have wrong
size
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amo...@gmail.com
CC: algr...@acm.org, amo...@gmail.com,
fredrickprasha...@gmail.com, gcc-bugs@gcc.gnu.org,
lauro.venan...@gmail.com, qrc...@knm.org.pl,
sbsid...@gmail.com
Depends on: 28865
+++ This bug was initially created as a clone of Bug #28865 +++
Cloned from 28865, because the problem is more than just getting .size wrong.
The following testcase fails on all targets at all optimization levels.
The testcase was taken from glibc/nss/nss_files/files-init.c, which is
miscompiled on powerpc or any other target using -fsection-anchors.
union
{
struct { long j; char c[]; } s;
char pad[32];
} x[2] =
{
{ .s = { .c = "abc123" } },
{ .s = { .c = "xyz" } }
};
int
main (void)
{
if (sizeof (x[0]) != 32)
__builtin_abort ();
if (x[1].s.c[0] != 'x')
__builtin_abort ();
return 0;
}
[Bug c/57180] Structures with a flexible arrray member have wrong size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57180 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-06 Ever Confirmed|0 |1
[Bug target/55033] [4.7/4.8/4.9 Regression] PowerPC section type conflict error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-10 CC||amodra at gmail dot com Ever confirmed|0 |1 --- Comment #7 from Alan Modra --- Fix mainline and 4.8 http://gcc.gnu.org/ml/gcc-cvs/2013-05/msg00282.html http://gcc.gnu.org/ml/gcc-cvs/2013-05/msg00283.html
[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27619 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #16 from Alan Modra 2012-10-24 05:35:06 UTC --- gas is broken. http://sourceware.org/bugzilla/show_bug.cgi?id=14758
[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27619 --- Comment #17 from Alan Modra 2012-10-26 03:51:35 UTC --- Fixed in gas and ld. I think the only thing that needs doing in gcc is fixing the lwa constraint.
[Bug libstdc++/52839] [4.7/4.8 Regression] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 --- Comment #36 from Alan Modra 2012-11-02 02:13:20 UTC --- The change I mention in #c22 http://gcc.gnu.org/viewcvs?view=revision&revision=184110 tests for atomic ops on all of bool, short, int and long long, where the previous test was for *either* atomic bool or atomic short. My fix for powerpc removed the long long test. Does mips lack atomic on bool or short?
[Bug libstdc++/52839] [4.7/4.8 Regression] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 --- Comment #38 from Alan Modra 2012-11-02 02:39:29 UTC --- Ah, the #c3 fail on powerpc was due to a powerpc glibc pthread_once bug. And comment #36 should have read: ..previous test was for *either* atomic bool or atomic int.
[Bug rtl-optimization/46556] Code size regression in struct access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556 Alan Modra changed: What|Removed |Added Target||powerpc-linux Status|UNCONFIRMED |NEW Last reconfirmed|2010-11-22 10:22:43 |2011.01.19 06:31:18 Ever Confirmed|0 |1
[Bug bootstrap/47279] Bootstrap fails in stage1 with GCC 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47279 --- Comment #3 from Alan Modra 2011-01-27 22:52:29 UTC --- This is odd. The error is given when a plt call, or a call needing an r2 offsetting stub is made but the code does not have a following nop which can be replaced with an r2 restoring instruction. Assuming the linker has not gone completely crazy, the fact that it is complaining about a call to '.opd' says the call is to a static function. Static functions ought to be using the same toc, so no need for r2 adjusting stub. Can I have a look at your cse.o?
[Bug bootstrap/47279] Bootstrap fails in stage1 with GCC 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47279 Alan Modra changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | --- Comment #7 from Alan Modra 2011-01-28 15:45:37 UTC --- Is the older 4.6 snapshot compiler still around on your system? If so, I'd really like to investigate the linker error, to make sure that powerpc64 ld isn't doing something stupid with toc partitioning..
[Bug bootstrap/47279] Bootstrap fails in stage1 with GCC 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47279 --- Comment #9 from Alan Modra 2011-01-31 01:40:15 UTC --- I can't duplicate the failure, even using 167488 as host compiler. -Wl,--stats shows: /usr/local/powerpc-linux/bin/ld: linker stubs in 2 groups /usr/local/powerpc-linux/bin/ld: branch 0 /usr/local/powerpc-linux/bin/ld: toc adjust 0 /usr/local/powerpc-linux/bin/ld: long branch 0 /usr/local/powerpc-linux/bin/ld: long toc adj 0 /usr/local/powerpc-linux/bin/ld: plt call 165 so no toc adjusting stubs needed, as expected for -mcmodel=medium. That makes your ld failure even weirder.
[Bug bootstrap/47279] Bootstrap fails in stage1 with GCC 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47279 --- Comment #10 from Alan Modra 2011-01-31 08:47:16 UTC --- With enough fiddling around, I finally duplicated the error, in my case when linking lto1. libbackend.a(cse.o): In function `insert_const_anchors': /src/gcc-current/gcc/cse.c:1293: sibling call optimization to `.opd' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.opd' extern /src/gcc-current/gcc/cse.c:1296: sibling call optimization to `.opd' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.opd' extern /home/alan/build/ppc/bin/ld/ld-new: final link failed: Bad value It is a GNU ld bug.
[Bug bootstrap/47279] Bootstrap fails in stage1 with GCC 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47279 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |amodra at gmail dot com |gnu.org | --- Comment #11 from Alan Modra 2011-01-31 22:53:48 UTC --- http://sourceware.org/ml/binutils/2011-01/msg00403.html
[Bug lto/47607] New: FAIL: gcc.c-torture/execute/builtins/abs-2.c execution, -O2 -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47607 Summary: FAIL: gcc.c-torture/execute/builtins/abs-2.c execution, -O2 -flto Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: amo...@gmail.com Created attachment 23244 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23244 compile with -w -O2 -m32 -flto abs-2.i abs-2-lib.i main.i -lm Fails due to "bl main_test" branching to a bogus location. This is because the only definition for main_test is one from the IR file, and ld doesn't check that the symbol has been replaced with a real one. With the patch in http://sourceware.org/ml/binutils/2011-02/msg00037.html we get a linker error. Reversing the order of inputs.. ../gcc/xgcc -B ../gcc/ -w -O2 -m32 -flto main.i abs-2.i abs-2-lib.i -lm lto1: internal compiler error: in lto_varpool_replace_node, at lto-symtab.c:305
[Bug lto/47607] FAIL: gcc.c-torture/execute/builtins/abs-2.c execution, -O2 -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47607 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Alan Modra 2011-02-04 14:28:21 UTC --- No, I was on 169779. Updating to 169827 gives me a compiler that passes this test.
[Bug target/47487] ICE in rs6000_output_function_epilogue, at config/rs6000/rs6000.c:21782 building 64bit libgo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47487 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.21 12:10:03 CC||amodra at gmail dot com Ever Confirmed|0 |1 --- Comment #2 from Alan Modra 2011-02-21 12:10:03 UTC --- This is just a lack of else if (strcmp (language_string, "GNU Go") == 0) i = mumble;
[Bug target/47935] New: PowerPC64 -mcmodel=medium invalid lwa offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47935
Summary: PowerPC64 -mcmodel=medium invalid lwa offset
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amo...@gmail.com
/* Testcase extracted from perl cpu2006
-m64 -O2 -S results in
.L.foo:
addis 9,2,.LANCHOR0@toc@ha
lwa 0,.LANCHOR0+3@toc@l(9)
...
*/
static long PL_statusvalue;
void foo (void)
{
int exitstatus;
exitstatus = PL_statusvalue >> 8;
if (exitstatus & 255)
PL_statusvalue = exitstatus;
else
PL_statusvalue = 255;
}
[Bug target/47935] PowerPC64 -mcmodel=medium invalid lwa offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47935 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.03.01 07:09:14 AssignedTo|unassigned at gcc dot |amodra at gmail dot com |gnu.org | Ever Confirmed|0 |1
[Bug target/47935] PowerPC64 -mcmodel=medium invalid lwa offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47935 --- Comment #1 from Alan Modra 2011-03-01 07:10:18 UTC --- res6000/predicates.md:lwa_operand needs to handle -mcmodel=medium code
[Bug target/47935] PowerPC64 -mcmodel=medium invalid lwa offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47935 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Alan Modra 2011-03-02 04:04:02 UTC --- patch applied
[Bug target/47986] New: gcc.c-torture/execute/20040709-1.c fails with non-delegitimized UNSPEC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47986
Summary: gcc.c-torture/execute/20040709-1.c fails with
non-delegitimized UNSPEC
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amo...@gmail.com
On powerpc64-linux at -O3 -g -m64, this testcase has the following snippet in
150r.into_cfglayout. Note the duplicated debug_insns for p (and i).
(insn 39 38 40 2 (set (reg:DI 234)
(plus:DI (reg:DI 2 2)
(high:DI (const:DI (unspec:DI [
(symbol_ref/u:DI ("*.LC5") [flags 0x2])
] 49)
/home/alan/src/gcc-current/gcc/testsuite/gcc.c-torture/execute/20040709-1.c:90
517 {largetoc_high}
(nil))
(insn 40 39 41 2 (set (reg/v/f:DI 209 [ p ])
(mem/u/c:DI (lo_sum:DI (reg:DI 234)
(const:DI (unspec:DI [
(symbol_ref/u:DI ("*.LC5") [flags 0x2])
] 49))) [6 S8 A8]))
/home/alan/src/gcc-current/gcc/testsuite/gcc.c-torture/execute/20040709-1.c:90
405 {*movdi_internal64}
(expr_list:REG_EQUAL (const:DI (plus:DI (symbol_ref:DI ("sA") [flags 0x80]
)
(const_int 1 [0x1])))
(nil)))
(debug_insn 41 40 42 2 (var_location:DI p (reg/v/f:DI 209 [ p ]))
/home/alan/src/gcc-current/gcc/testsuite/gcc.c-torture/execute/20040709-1.c:90
-1
(nil))
(debug_insn 42 41 43 2 (var_location:SI i (debug_expr:SI D#16))
/home/alan/src/gcc-current/gcc/testsuite/gcc.c-torture/execute/20040709-1.c:90
-1
(nil))
(debug_insn 43 42 44 2 (var_location:DI p (reg/v/f:DI 209 [ p ])) -1
(nil))
(debug_insn 44 43 45 2 (var_location:SI i (debug_expr:SI D#16)) -1
(nil))
In 151r.jump insn 39 and 40 are deleted (reg 209 is dead) and we are left with:
(debug_insn 505 38 504 2 (var_location:DI D#21 (plus:DI (reg:DI 2 2)
(high:DI (const:DI (unspec:DI [
(symbol_ref/u:DI ("*.LC5") [flags 0x2])
] 49) -1
(nil))
(debug_insn 504 505 43 2 (var_location:DI D#20 (mem/u/c:DI (lo_sum:DI
(debug_expr:DI D#21)
(const:DI (unspec:DI [
(symbol_ref/u:DI ("*.LC5") [flags 0x2])
] 49))) [6 S8 A8])) -1
(nil))
(debug_insn 43 504 44 2 (var_location:DI p (debug_expr:DI D#20)) -1
(nil))
(debug_insn 44 43 45 2 (var_location:SI i (debug_expr:SI D#16)) -1
(nil))
Note how one set of the debug_insns have also been removed, but we are left
with some garbage. dwarf2out tries to output debug info for p by substituting
the debug_exprs and we get something that rs6000_delegitimize_address can't
handle.
(mem/u/c:DI (lo_sum:DI (plus:DI (reg:DI 2 2)
(high:DI (const:DI (unspec:DI [
(symbol_ref/u:DI ("*.LC11") [flags 0x2])
] 49
(const:DI (unspec:DI [
(symbol_ref/u:DI ("*.LC11") [flags 0x2])
] 49))) [6 S8 A8])
[Bug target/47986] gcc.c-torture/execute/20040709-1.c fails with non-delegitimized UNSPEC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47986 --- Comment #1 from Alan Modra 2011-03-04 11:24:02 UTC --- I can easily fix rs6000_delegitimize_address to handle this debug expression, but I suspect that would be papering over the real problem, the duplicate debug_insns.
[Bug target/47986] gcc.c-torture/execute/20040709-1.c fails with non-delegitimized UNSPEC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47986 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.03.04 12:34:31 AssignedTo|unassigned at gcc dot |amodra at gmail dot com |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Alan Modra 2011-03-04 12:34:31 UTC --- Created attachment 23541 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23541 delegitimize_address fix
[Bug target/47986] gcc.c-torture/execute/20040709-1.c fails with non-delegitimized UNSPEC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47986 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Alan Modra 2011-03-04 23:05:13 UTC --- Fixed
[Bug middle-end/57134] [4.9 Regression] ICE with -mstrict-align and inline assembly on ppc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57134 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-06/msg00642.htm ||l Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
[Bug middle-end/57586] ICE when expanding volatile asm using unaligned pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57586 Alan Modra changed: What|Removed |Added Status|WAITING |ASSIGNED CC||amodra at gmail dot com Component|target |middle-end Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Severity|major |normal
[Bug target/57717] error: unrecognizable insn compiling ./strtod_l.c from glibc on powerpc-gnuspe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57717 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #3 from Alan Modra --- Created attachment 30383 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30383&action=edit potential fix This reverts part of the patch identified in comment #1, and cures the testcase failure.
[Bug target/57836] New: large constants evaluated inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57836
Bug ID: 57836
Summary: large constants evaluated inline
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
On powerpc64 with -mcmodel=small -O1, this
int x;
void f1 (long long hx)
{
if (hx < 0x3ff0LL)
x++;
}
results in
.L.f1:
lis 9,0x3fef
ori 9,9,65535
sldi 9,9,32
oris 9,9,0x
ori 9,9,65535
cmpd 7,3,9
bgtlr 7
ld 9,.LC1@toc(2)
lwz 10,0(9)
addi 10,10,1
stw 10,0(9)
blr
The -mcmodel isn't significant, just there to make comparison with older
compilers easy. Prior to gcc-4.5 we generated
.L.f1:
ld 0,.LC0@toc(2)
cmpd 7,3,0
bgtlr 7
ld 9,.LC1@toc(2)
lwz 11,0(9)
addi 0,11,1
stw 0,0(9)
blr
Both pre- and post-4.5 compilers initially expand rtl using the constant load
from toc, but 4.5 and later substitute the constant in the first cse pass.
The problem stems from rtx cost for the load from toc being the same as the
inline constant form.
The costs are the same both pre- and post-4.5. The reason pre-4.5 does not
substitute the constant is related to this comment is cse.c:
/* Find cheapest and skip it for the next time. For items
of equal cost, use this order:
src_folded, src, src_eqv, src_related and hash table entry. */
Pre-4.5 src_folded is NULL, src is a mem, src_eqv the constant.
Post-4.5 src_folded is the constant, src is a mem, src_eqv the constant again.
Pre-4.5, rs6000.c lacked delegitimize_address. src_folded is set by fold_rtx,
which calls equiv_constant, which calls avoid_constant_pool_reference, which
calls targetm.delegitimize_address. When this is missing, we don't get to see
the constant..
[Bug target/57865] Broken _save64gpr and _rest64gpr usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-07-10 Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Ever confirmed|0 |1 --- Comment #2 from Alan Modra --- My guess is that it's this change -#define FIRST_SAVED_GP_REGNO 13 +#define FIRST_SAVED_GP_REGNO (FIXED_R13 ? 14 : 13) messing with ool_adjust.
[Bug target/57865] Broken _save64gpr and _rest64gpr usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865 --- Comment #4 from Alan Modra --- Created attachment 30489 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30489&action=edit Fix ool_adjust Please verify that this fixes the problem
[Bug rtl-optimization/58034] New: glibc nptl/tst-cleanup2 fail due to scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58034
Bug ID: 58034
Summary: glibc nptl/tst-cleanup2 fail due to scheduling
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Created attachment 30575
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30575&action=edit
preprocessed test case
nprl/tst-cleanup2 fails when compiled with -O2 -mcpu=power6 due to sched1
moving an assignment to a REG over code that traps.
The relevant test case source:
if (setjmp (jmpbuf))
{
puts ("Exiting main...");
return 0;
}
sprintf (p, "This should segv\n");
return 1;
}
The sprintf is optimised to three loads and stores. The problem occurs due to
the assignment of 1 to the REG holding the function return value being
scheduled before the sprintf expansion.
[Bug rtl-optimization/58034] glibc nptl/tst-cleanup2 fail due to scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58034
Alan Modra changed:
What|Removed |Added
Known to work||4.7.2
Known to fail||4.8.1, 4.8.2, 4.9.0
--- Comment #5 from Alan Modra ---
This somewhat reduced testcase fails with mainline.
#include
#include
static sigjmp_buf jmpbuf;
static void
sig_handler (int signo)
{
siglongjmp (jmpbuf, 1);
}
int
main (void)
{
char *p = 0;
struct sigaction sa;
sa.sa_handler = sig_handler;
sigemptyset (&sa.sa_mask);
sa.sa_flags = SA_SIGINFO;
if (sigaction (SIGSEGV, &sa, 0))
return 1;
if (setjmp (jmpbuf))
return 0;
__builtin_memcpy (p, "abc", 4);
return 1;
}
[Bug target/57865] Broken _save64gpr and _rest64gpr usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Alan Modra --- Fixed mainline and 4.8. 4.7 doesn't need the patch.
[Bug target/58330] powerpc64 atomic store split in two
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58330 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #2 from Alan Modra --- I think this is a backend problem, specifically with bswapdi2_64bit accepting a DImode mem then splitting to two SImode. Potential fix is to add && !(MEM_P (operands[0]) && MEM_VOLATILE_P (operands[0])) && !(MEM_P (operands[1]) && MEM_VOLATILE_P (operands[1])) to the insn condition.
[Bug middle-end/57134] [4.9 Regression] ICE with -mstrict-align and inline assembly on ppc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57134 --- Comment #5 from Alan Modra --- r200086 fixed Anton's first testcase but then he found another one. See http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00983.html
[Bug target/57589] Linux powerpc -mcpu=native returns pointer to variable on stack in driver-rs6000.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57589 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com Resolution|FIXED |INVALID
