This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH v2] Fix PR64242
On Fri, Dec 07, 2018 at 04:19:22PM +0000, Wilco Dijkstra wrote:
> Jakub Jelinek wrote:
> > On Fri, Dec 07, 2018 at 02:52:48PM +0000, Wilco Dijkstra wrote:
> >> - struct __attribute__((aligned (32))) S { int a[4]; } s;
> >> - bar (&s);
> >
> > Any reason to remove the above?
>
> The test case doesn't need an aligned object to fail, so why did you add it?
It needed it on i686, because otherwise it happened to see the value it
wanted in the caller's stack frame.
> >> + /* Compute expected next alloca offset - some targets don't align properly
> >> + and allocate too much. */
> >> + p = q + (q - p);
> >
> > This is UB, pointer difference is only defined within the same object.
> > So, you can only do such subtraction in some integral type rather than as
> > pointer subtraction.
>
> __builtin_setjmp is already undefined behaviour, and the stack corruption is
> even more undefined - trying to avoid harmless theoretical undefined behaviour
> wouldn't be helpful.
No, __builtin_setjmp is a GNU extension, not undefined behavior. And
something that is UB and might be harmless today might be harmful tomorrow,
gcc optimizes heavily on the assumption that UB doesn't happen in the
program, so might optimize that subtraction to 0 or 42 or whatever else.
>
> > And I'm not sure you have a guarantee that every zero sized alloca is at the
> > same offset from the previous one.
>
> The above pointer adjustment handles the case where alloca overallocates.
> It passes on x86-64 which always adds 8 unnecessary bytes.
What guarantee is there that it overallocates each time the same though?
Jakub