On Fri, Dec 20, 2019 at 12:26 AM Jakub Jelinek wrote:
>
> On Thu, Dec 19, 2019 at 06:23:59PM +0100, Jakub Jelinek wrote:
> > On Thu, Dec 19, 2019 at 04:50:40PM +0100, Jan Hubicka wrote:
> > > Outputting the move as RIP relative movq would work.
> > > LC12 is string "s" and has nothing to do with
On Thu, Dec 19, 2019 at 06:23:59PM +0100, Jakub Jelinek wrote:
> On Thu, Dec 19, 2019 at 04:50:40PM +0100, Jan Hubicka wrote:
> > Outputting the move as RIP relative movq would work.
> > LC12 is string "s" and has nothing to do with stack protecting.
>
> This should fix it by doing more carefully
On Thu, Dec 19, 2019 at 04:50:40PM +0100, Jan Hubicka wrote:
> Outputting the move as RIP relative movq would work.
> LC12 is string "s" and has nothing to do with stack protecting.
This should fix it by doing more carefully what *movdi_internal
does. Will bootstrap/regtest it tonight.
> On Thu, Dec 19, 2019 at 04:01:31PM +0100, Jan Hubicka wrote:
> > I now get build failure of Firefox with LTO due to:
> >
> > movabsq $.LC12, %rax
> >
> > which is output by:
> >
> > (insn:TI 468 3 849 2 (parallel [
> >
> > (set
On Thu, Dec 19, 2019 at 04:01:31PM +0100, Jan Hubicka wrote:
> I now get build failure of Firefox with LTO due to:
>
> movabsq $.LC12, %rax
>
> which is output by:
>
> (insn:TI 468 3 849 2 (parallel [
>
> (set (mem/v/f/c:DI (plus:DI
> Hi!
>
> I'd like to ping this patch (with the sizeof (c) -> sizeof (c) / sizeof (c[0])
> testsuite fix Andreas pointed out).
>
> Thanks!
>
> On Tue, Dec 10, 2019 at 10:57:35AM +0100, Jakub Jelinek wrote:
> > 2019-12-10 Jakub Jelinek
> >
> > PR target/92841
> > *
On Tue, Dec 10, 2019 at 10:57 AM Jakub Jelinek wrote:
>
> Hi!
>
> The stack_protect_set_1_ pattern intentionally clears the register it
> used as a temporary to read the canary from the register and push it back
> on the stack for security reasons, to make sure the stack canary isn't
> spilled
Hi!
I'd like to ping this patch (with the sizeof (c) -> sizeof (c) / sizeof (c[0])
testsuite fix Andreas pointed out).
Thanks!
On Tue, Dec 10, 2019 at 10:57:35AM +0100, Jakub Jelinek wrote:
> 2019-12-10 Jakub Jelinek
>
> PR target/92841
> * config/i386/i386.md
On Tue, Dec 10, 2019 at 11:02:39AM +0100, Andreas Schwab wrote:
> On Dez 10 2019, Jakub Jelinek wrote:
>
> > --- gcc/testsuite/gcc.target/i386/pr92841.c.jj 2019-12-09
> > 19:38:29.572759215 +0100
> > +++ gcc/testsuite/gcc.target/i386/pr92841.c 2019-12-09 19:40:59.642492417
> > +0100
> > @@
On Dez 10 2019, Jakub Jelinek wrote:
> --- gcc/testsuite/gcc.target/i386/pr92841.c.jj2019-12-09
> 19:38:29.572759215 +0100
> +++ gcc/testsuite/gcc.target/i386/pr92841.c 2019-12-09 19:40:59.642492417
> +0100
> @@ -0,0 +1,17 @@
> +/* PR target/92841 */
> +/* { dg-do compile { target
Hi!
The stack_protect_set_1_ pattern intentionally clears the register it
used as a temporary to read the canary from the register and push it back
on the stack for security reasons, to make sure the stack canary isn't
spilled somewhere else etc. On the following testcase, we end up with a
11 matches
Mail list logo