On 5/12/19 10:01 PM, Hans-Peter Nilsson wrote:
>> Date: Tue, 30 Apr 2019 11:37:17 -0600
>> From: Jeff Law
>
>> On 2/10/19 6:09 PM, Hans-Peter Nilsson wrote:
>>> Here's the follow-up, getting rid of the observed
>>> alignment-padding in execute/930126-1.c: the x parameter in f
>>> spuriously being
> Date: Tue, 30 Apr 2019 11:37:17 -0600
> From: Jeff Law
> On 2/10/19 6:09 PM, Hans-Peter Nilsson wrote:
> > Here's the follow-up, getting rid of the observed
> > alignment-padding in execute/930126-1.c: the x parameter in f
> > spuriously being runtime-aligned to BITS_PER_WORD. I separated
> >
On 2/10/19 6:09 PM, Hans-Peter Nilsson wrote:
> Here's the follow-up, getting rid of the observed
> alignment-padding in execute/930126-1.c: the x parameter in f
> spuriously being runtime-aligned to BITS_PER_WORD. I separated
> this change because this is an older issue, a change introduced
> in
> Date: Mon, 11 Feb 2019 10:22:12 +0100
> From: Jakub Jelinek
> Is PREFERRED_STACK_BOUNDARY what we want here? Shouldn't that be
> STACK_BOUNDARY, or PARM_BOUNDARY? Though, PARM_BOUNDARY on cris is 32...
Hm.
I wish there was a better distinction both in the code and in
peoples minds between b
On Mon, Feb 11, 2019 at 10:00:03AM +0100, Hans-Peter Nilsson wrote:
> > Date: Mon, 11 Feb 2019 07:38:14 +0100
> > From: Richard Biener
>
> > >+ HOST_WIDE_INT min_parm_align
> > >+ = STRICT_ALIGNMENT ? BITS_PER_WORD : PREFERRED_STACK_BOUNDARY;
> >
> > Shouldn't it be MIN (...) of BOTH?
>
> Date: Mon, 11 Feb 2019 07:38:14 +0100
> From: Richard Biener
> >+ HOST_WIDE_INT min_parm_align
> >+= STRICT_ALIGNMENT ? BITS_PER_WORD : PREFERRED_STACK_BOUNDARY;
>
> Shouldn't it be MIN (...) of BOTH?
That *does* seem logical... Take 2 as follows, in testing as
before.
Ok to commi
> To fix the r267812 incorrectness we need to use the *stored*
> size, i.e. that which will be stored into using register-sized
> writes. It's seems like the bug is just a typo, so the fix is
> as simple as follows. Note the usage of "diff -U 10" to show
> that size_stored is used in the "then"-a
On February 11, 2019 2:09:30 AM GMT+01:00, Hans-Peter Nilsson
wrote:
>Here's the follow-up, getting rid of the observed
>alignment-padding in execute/930126-1.c: the x parameter in f
>spuriously being runtime-aligned to BITS_PER_WORD. I separated
>this change because this is an older issue, a ch
> Date: Mon, 11 Feb 2019 02:05:11 +0100
> From: Hans-Peter Nilsson
> Regtested on cris-elf, where it "introduces" gcc.dg/pr84877.c
Correction: "no regressions" (not introduced by this proposed
patch, I misread).
brgds, H-P
Here's the follow-up, getting rid of the observed
alignment-padding in execute/930126-1.c: the x parameter in f
spuriously being runtime-aligned to BITS_PER_WORD. I separated
this change because this is an older issue, a change introduced
in r94104 where BITS_PER_WORD was chosen perhaps because we
> Date: Thu, 10 Jan 2019 00:06:01 +0100
> From: Jakub Jelinek
> 2019-01-09 Jakub Jelinek
>
> PR middle-end/84877
> PR bootstrap/88450
> * function.c (assign_stack_local_1): Revert the 2018-11-21 changes.
> (assign_parm_setup_block): Do the argument slot realignment her
On January 10, 2019 4:36:35 PM GMT+01:00, Eric Botcazou
wrote:
>> Another problem is that in way too many cases we decide to choose
>> BIGGEST_ALIGNMENT for stack slots, even when not strictly needed.
>E.g. any
>> BLKmode stack slot requests that BIGGEST_ALIGNMENT, even if
>TYPE_ALIGN is
>> much
> Another problem is that in way too many cases we decide to choose
> BIGGEST_ALIGNMENT for stack slots, even when not strictly needed. E.g. any
> BLKmode stack slot requests that BIGGEST_ALIGNMENT, even if TYPE_ALIGN is
> much smaller and assign_stack_local_1 even asserts that for BLKmode the
> a
Hi!
The r266345 change breaks mingw bootstraps for quite some time.
The problem is that the dynamic realignment is done IMHO way too low.
The biggest problem is that when assign_stack_local_1 decides to do this
dynamic_align_addr, it emits wherever it is currently expanding code about 3
instructi
14 matches
Mail list logo
