> I'll take your word for it ;)
Thanks. Testing on PowerPC64 revealed a couple of nits:
1. SSA names with zero uses need to be excluded from the computation, because
the first SSA name in a function returning a GIMPLE type is associated with
the RESULT_DECL and is undefined, so it would propa
On Tue, Oct 3, 2017 at 8:39 PM, Eric Botcazou wrote:
>> Reading the patch I think that it gets conservativeness wrong -- shouldn't
>> it be
>>
>> if (is_definitely_initialized)
>>{
>> SUBREG_PROMOTED_VAR_P (temp) = 1;
>> SUBREG_PROMOTED_SET (temp, unsignedp);
>>}
>>
>> ? Of
> Reading the patch I think that it gets conservativeness wrong -- shouldn't
> it be
>
> if (is_definitely_initialized)
>{
> SUBREG_PROMOTED_VAR_P (temp) = 1;
> SUBREG_PROMOTED_SET (temp, unsignedp);
>}
>
> ? Of course it's not easy to compute is_definitely_initialized
> co
On Mon, Sep 25, 2017 at 11:35 AM, Eric Botcazou wrote:
>> ISTR SUBREG_PROMOTED_* gets set by RTL expansion, the problematic
>> one should be the one in expr.c setting it on all SSA_NAMEs, maybe it is
>> enough to avoid setting it for SSA_NAME_IS_DEFAULT_DEF ones?
>
> No, it's not enough in this ca
> ISTR SUBREG_PROMOTED_* gets set by RTL expansion, the problematic
> one should be the one in expr.c setting it on all SSA_NAMEs, maybe it is
> enough to avoid setting it for SSA_NAME_IS_DEFAULT_DEF ones?
No, it's not enough in this case, you need to work a little harder and look at
the argument
On Mon, Sep 11, 2017 at 9:59 PM, Eric Botcazou wrote:
>> I think the issue is that we set SUBREG_PROMOTED_* on something that is
>> possibly not so (aka uninitialized in this case).
>
> Yes, that's what I called inherent weakness of the promoted subregs mechanism.
>
>> We may only set it if either
> I think the issue is that we set SUBREG_PROMOTED_* on something that is
> possibly not so (aka uninitialized in this case).
Yes, that's what I called inherent weakness of the promoted subregs mechanism.
> We may only set it if either the ABI or a previous operation forced it to.
> Maybe this is
On September 11, 2017 12:26:09 PM GMT+02:00, Eric Botcazou
wrote:
>Hi,
>
>this is a bug originally reported in Ada on 32-bit PowerPC with the
>SVR4 ABI
>(hence not Linux) and reproducible in C with the attached testcase at
>-O1.
>
>The problem lies in function 'foo':
>
> struct S ret;
> char r
> this is a bug originally reported in Ada on 32-bit PowerPC with the SVR4 ABI
> (hence not Linux) and reproducible in C with the attached testcase at -O1.
With the right C testcase this time...
--
Eric Botcazoustruct S { char c1, c2, c3, c4; } __attribute__((aligned(4)));
static char bar (char
Hi,
this is a bug originally reported in Ada on 32-bit PowerPC with the SVR4 ABI
(hence not Linux) and reproducible in C with the attached testcase at -O1.
The problem lies in function 'foo':
struct S ret;
char r, s, c1, c2;
char *p = &r;
s = bar (&p);
if (s)
c2 = *p;
c1 = 0;
10 matches
Mail list logo
