https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114830
--- Comment #2 from Alan Modra ---
Created attachment 58021
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58021=edit
c++filt crash binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114830
--- Comment #1 from Alan Modra ---
Created attachment 58020
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58020=edit
asan report summary
: demangler
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
>From zhoug...@mail.zgclab.edu.cn and wan...@mail.zgclab.edu.cn:
Hi, we found several crashes in c++filt(Binutils 2.42), which is the latest
version.
In det
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93176
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|amodra at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109308
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108727
--- Comment #3 from Alan Modra ---
Yes, looks good to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97361
Alan Modra changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #8 from Alan Modra ---
(In reply to Segher Boessenkool from comment #7)
> '-fpatchable-function-entry=N[,M]'
> Generate N NOPs right at the beginning of each function, with the
> function entry point before the Mth NOP.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894
--- Comment #7 from Alan Modra ---
So, similar code to what we have in rs6000_call_aix to handle
if ((INTVAL (cookie) & CALL_LONG) != 0
&& GET_CODE (func_desc) == SYMBOL_REF)
should be added to rs6000_sibcall_aix, I think.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894
--- Comment #6 from Alan Modra ---
I'm sorry, I forgot exactly what was happening when I talked about this on the
call. What I should have said is that -mlongcall code is correct but is
missing a sibcall optimisation. -fno-plt code (after
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
>From https://sourceware.org/bugzilla/show_bug.cgi?id=28995
c++filt _RYAaca_NRYAaBa_a
AddressSanitizer:DEADLYSIG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894
--- Comment #4 from Alan Modra ---
Do check that the result is not a direct call. I think I was wrong to say the
assert could be removed (or modified as you have done).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104671
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102485
--- Comment #10 from Alan Modra ---
I have spent some time over the last few days digging into history relevant to
this bug as part of looking into a binutils report that an ARCH=powerpc
CROSS_COMPILE=powerpc-linux- pmac32_defconfig linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95126
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #5
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
>From https://sourceware.org/bugzilla/show_bug.cgi?id=28736
valgrind c++filt -s gnat vfSO__fffSO
==1573233== Invalid write of size 1
==1573233==at 0x4848DCC: str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #15 from Alan Modra ---
(In reply to Jiu Fu Guo from comment #14)
> It would be a way to keep the data in memory(.rodata) through adjusting the
> cost of constant.
Yes, I posted a series of patches that fix this problem and other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867
--- Comment #3 from Alan Modra ---
Not that I'm really complaining about this, note also that the error message
referencing "filedata->section_headers + (sizetype)((long unsigned int)i * 80)"
is a little bit too much of compiler internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867
--- Comment #1 from Alan Modra ---
Created attachment 51641
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51641=edit
preprocessed source
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
Compiling the attached readelf.i with -Wall -Werror -O2 using today's gcc
mainline on x86_64-linux results in complaints like
/home/alan/src/binutils-gdb/binutils/readelf.c: In function
||amodra at gmail dot com
Ever confirmed|0 |1
Version|unknown |12.0
Last reconfirmed||2021-09-05
--- Comment #4 from Alan Modra ---
Yes, gcc's libiberty is still considered upstream of binutils
||2021-09-05
Resolution|MOVED |---
Ever confirmed|0 |1
Version|7.5.0 |12.0
CC||amodra at gmail dot com
--- Comment #3 from Alan Modra ---
Even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46981
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101977
--- Comment #6 from Alan Modra ---
(In reply to Martin Sebor from comment #5)
> The -Warray-bounds for section.c is gone
Thanks for fixing that.
> but last night's build still shows
> a large number of -Warray-bounds instances as well as other
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
Seen on attempting to build binutils for x86_64-linux with current mainline gcc
/home/alan/build/gcc-virgin/gcc/xgcc -B/home/alan/build/gcc-virgin/gcc/
-DHAVE_CONFIG_H
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101810
--- Comment #3 from Alan Modra ---
Making SYMESZ a size_t as the patch does, is a complete fix if the code is only
compiled for 64-bit hosts where unsigned int is smaller than size_t. If
compiled for 32-bit then the expression calculating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99759
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101810
--- Comment #1 from Alan Modra ---
Created attachment 51272
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51272=edit
Proposed fix
Component: plugins
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
>From https://sourceware.org/bugzilla/show_bug.cgi?id=28179
binutils/nm-new --plugin ~/build/gcc-virgin/lto-plugin/.libs/liblto_plugin.so
-a pr28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #11 from Alan Modra ---
Preserving certain -m gas options goes back to this patch:
https://sourceware.org/pipermail/binutils/2008-January/054935.html
Given the number of ppc micros around with differing functional units, it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61032
Alan Modra changed:
What|Removed |Added
Assignee|amodra at gmail dot com|unassigned at gcc dot
gnu.org
||https://gcc.gnu.org/piperma
||il/gcc-patches/2020-October
||/555760.html
Assignee|amodra at gmail dot com|unassigned at gcc dot
gnu.org
--- Comment #8 from Alan Modra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #13
||amodra at gmail dot com
--- Comment #4 from Alan Modra ---
The disassembly says this is powerpc64le. Possibly interesting fact: the
offsets used above the stack frame are 400, 432, 440, which all correspond to
the parameter save area. I don't see any reason that DGEBAL should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125
--- Comment #14 from Alan Modra ---
-fpatchable-function-entry isn't used by the powerpc linux kernel.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125
--- Comment #12 from Alan Modra ---
Created attachment 50039
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50039=edit
ELFv1 support
Revised patches. I wasn't happy with the use of a ".text" symbol in the
previous patch since some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125
Alan Modra changed:
What|Removed |Added
Attachment #49701|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98210
Alan Modra changed:
What|Removed |Added
Resolution|MOVED |---
Status|RESOLVED
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
gcc.dg/split-1.exe and other split-stack executables broke recently on
powerpc64le-linux, most likely due to git commit 6fbec038f7a7.
I see
[22] .init_array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125
--- Comment #8 from Alan Modra ---
Created attachment 49701
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49701=edit
fix powerpc64 -fpatchable-function-entry
This makes -fpatchable-function-entry do something sensible on powerpc64 ELFv1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125
--- Comment #7 from Alan Modra ---
(In reply to Alan Modra from comment #5)
> So the "o" flag symbol is one in the .opd section, rather than what would be
> correct here, .L._Z3foov.
Actually, that breakage happened recently with commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125
Alan Modra changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Alan Modra ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93176
Alan Modra changed:
What|Removed |Added
URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97267
Alan Modra changed:
What|Removed |Added
URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #10 from Alan Modra ---
Here's elf32-arc.i creduced.
a;
b();
c() {
void *d;
if (d == b && e())
d = a;
return d;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
Alan Modra changed:
What|Removed |Added
Target||powerpc64le-linux,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
Alan Modra changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #4 from Alan Modra ---
Created attachment 49347
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49347=edit
original .i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #3 from Alan Modra ---
Created attachment 49346
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49346=edit
reduced testcase
-mcpu=power10 -O2 -S
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
-mcpu=power10 -O2 -mno-isel
/home/alan/src/gcc/gcc/testsuite/gcc.target/powerpc/ppc-ne0-1.c: In function
'ne0':
/home/alan/src/gcc/gcc/testsuite/gcc.target/powerpc/ppc-ne0-1.c:12:1: error
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
during GIMPLE pass: evrp
/home/alan/src/gcc/gcc/testsuite/gcc.target/powerpc/mma-double-test.c: In
function 'MMA':
/home/alan/src/gcc/gcc/testsuite/gcc.target/powerpc/mma-double-test.c:186:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92564
Alan Modra changed:
What|Removed |Added
CC|amodra at gcc dot gnu.org |
--- Comment #2 from Alan Modra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97267
Alan Modra changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
static int __attribute__ ((__noclone__, __noinline__))
reg_args (int j1, int j2, int j3, int j4, int j5, int j6, int j7, int j8)
{
return j1 + j2 + j3 + j4 + j5 + j6 + j7 + j8;
}
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97166
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97107
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target|powerpc*
gnu.org |amodra at gmail dot com
Last reconfirmed||2020-09-24
CC||amodra at gmail dot com
Status|UNCONFIRMED |ASSIGNED
--- Comment #2 from Alan Modra ---
Oops didn't put the PR number
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=edit
fix under test
gnu.org |amodra at gmail dot com
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2020-09-18
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
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
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 #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 #1 from Alan Modra ---
Yes, reverting 5d3ae76af13 cures this PR.
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=96493
Alan Modra changed:
What|Removed |Added
Host||gcc
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96525
Alan Modra changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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
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
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
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
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.
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
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=94145
Alan Modra changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=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
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 #1 from Alan Modra ---
Created attachment 48146
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48146=edit
teach gcc more two insn sequences for constants
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=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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #4
at 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=91052
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #14
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
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,
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 >f is the same as
&((*p).f), which is from p->f being the
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
Alan Modra changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
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:
> >field does not dereference p, just as &*p and [i] do not.
>
> Should be
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
1 - 100 of 872 matches
Mail list logo
