gcc dot gnu.org |amodra at gmail dot com
Last reconfirmed||2020-03-11
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #4
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 PL
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
sta
gnu.org |amodra at gmail dot com
Last reconfirmed||2020-03-30
CC|amodra at gmail dot com|
Status|UNCONFIRMED |ASSIGNED
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57836
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|5.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #2
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 wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504
Alan Modra changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
Alan Modra changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95353
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #6
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)
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.
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 i
at gcc dot gnu.org |amodra at gmail dot com
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96525
Alan Modra changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96493
Alan Modra changed:
What|Removed |Added
Host||gcc
Status|ASSIGNED
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042
--- Comment #1 from Alan Modra ---
Yes, reverting 5d3ae76af13 cures this PR.
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.
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.
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
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
gnu.org |amodra at gmail dot com
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2020-09-18
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634
Alan Modra changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
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)
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
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, t
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 op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91052
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #14
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56073
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53040
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53038
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
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.
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 becau
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54009
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
||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
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
at gcc dot gnu.org |amodra at gmail dot com
AssignedTo|unassigned at gcc dot |amodra at gmail dot com
|gnu.org |
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
wid
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 pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
URL|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431
Alan Modra changed:
What|Removed |Added
Target Milestone|--- |4.8.0
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
||missed-optimization
Last reconfirmed||2013-04-24
AssignedTo|unassigned at gcc dot |amodra at gmail dot com
|gnu.org |
Ever Confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57052
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
||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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
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
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
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 p
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 Modr
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() expect
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
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
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
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.
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57180
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27619
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
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.
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
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556
Alan Modra changed:
What|Removed |Added
Target||powerpc-linux
Status|UNCONFIRMED
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 ins
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47279
Alan Modra changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|WORKSFORME
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
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: sibl
||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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47607
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
||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")
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: unas
||2011.03.01 07:09:14
AssignedTo|unassigned at gcc dot |amodra at gmail dot com
|gnu.org |
Ever Confirmed|0 |1
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47935
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
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
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.
||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/show_bug.cgi?id=47986
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
||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
||amodra at gmail dot com
Component|target |middle-end
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Severity|major |normal
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
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,0xf
||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_
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
: 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
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|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57589
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
Resolution
1 - 100 of 872 matches
Mail list logo
