https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #24 from Segher Boessenkool ---
I do see the problems for savegpr/restgpr with that suggestion, but maybe
something
in that vein can be done.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #23 from Segher Boessenkool ---
savegpr/restgpr are special ABI-defined functions that do not have all the same
ABI
calling conventions as normal functions. They indeed write into the parent's
frame
(red zone, in this case).
Maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #22 from jseward at acm dot org ---
Looking back at the above, it's now clearer what the problem is:
# Park potentially live data in the red zone
_savegpr0_14: std r14,-144(r1)
_savegpr0_15: std r15,-136(r1)
_savegpr0_16:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #21 from jseward at acm dot org ---
(In reply to Jakub Jelinek from comment #20)
> Can you disable it just for these magic entrypoints (either by name or by
> content)?
In principle yes. I prefer by-content rather than by-name, in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
jseward at acm dot org changed:
What|Removed |Added
CC||jseward at acm dot org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #18 from Mark Wielaard ---
The current thinking (Julian did the thinking, I am just repeating) is that
this is caused by the way the _savegpr and/or restgpr functions return using
blr.
PPC has two special "lets zap the red zone"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #17 from Mark Wielaard ---
Thanks for the step-by-step explanation of the assembly instructions and
calling conventions.
(In reply to Segher Boessenkool from comment #16)
> (In reply to Mark Wielaard from comment #13)
> > ==25741==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #16 from Segher Boessenkool ---
(In reply to Mark Wielaard from comment #13)
> ==25741== Use of uninitialised value of size 8
> ==25741==at 0x1504: main (pr9862.C:16)
r4 is argv here
>0x14f0 <+16>: ld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #15 from Segher Boessenkool ---
(In reply to Will Schmidt from comment #14)
> The _restgpr* and _savegpr* functions are not referenced when the test is
> built at other optimization levels. (I've looked at disassembly from -O0 ..
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #14 from Will Schmidt ---
Using gdb/vgdb to view the valgrind shadow register values, it looks like
the uninitialized values are being loaded in via the
_restgpr0_25 call being made at the end of isVariable().
Dump of assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #13 from Mark Wielaard ---
I could replicate this with gcc 9.1.1 with the following source:
#define variables (const char* []){ "PK", "KEK", "db"}
int ret, len;
void isVariable(char *var)
{
for (int v = 0; v < 2; v++)
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #12 from Mark Wielaard ---
OK, so according to memcheck the load uses a pointer value that isn't
initialized properly. And it thinks that value originated from a stack value in
the isVariable call. Unfortunately my powerpc assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #11 from Will Schmidt ---
(In reply to Mark Wielaard from comment #10)
> (In reply to Will Schmidt from comment #9)
> > (In reply to Segher Boessenkool from comment #5)
> > > Have you tried a new valgrind?
> > >
> > > Either this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #10 from Mark Wielaard ---
(In reply to Will Schmidt from comment #9)
> (In reply to Segher Boessenkool from comment #5)
> > Have you tried a new valgrind?
> >
> > Either this is (or was) a known problem in valgrind, or it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
Will Schmidt changed:
What|Removed |Added
CC||willschm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #8 from Nick Child ---
Hello all,
Thanks for taking a look at this. In response to some questions:
I am using Valgrind 3.16.1 (latest release).
And I have encountered this issue on a Power 8 and Power 9 LE machine with
multiple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #7 from acsawdey at gcc dot gnu.org ---
The inline expansion should be disabled by -Os, the patterns for cmpstr[n]si
both have this:
if (optimize_insn_for_size_p ())
FAIL;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
Martin Liška changed:
What|Removed |Added
Host|powerpcle-*-linux-gnu* |powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
Segher Boessenkool changed:
What|Removed |Added
CC||acsawdey at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #4 from Segher Boessenkool ---
Are you sure that target is correct?!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
Martin Liška changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #1 from Nick Child ---
Created attachment 49971
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49971=edit
source
24 matches
Mail list logo
