CLOBBER(eol)

CLOBBER(eol)

[Krister Walfridsson]

I'm working on an updated version of my translation validator [*], and I 
have some problems with CLOBBER(eol).

I currently treat CLOBBER(eol) as making the memory invalid (i.e. all 
subsequent accesses is undefined behavior), but the tool reports 
miscompilation for a few cases where the tree-nrv pass makes the IR 
clobber <retval> by changing code such as [**]

   union bu o;
   ...
   o = i;
   MEM[(union  *)&o].b18 = _11;
   MEM[(union  *)&o].b20 = _11;
   <retval> = o;
   o ={v} {CLOBBER(eol)};
   return <retval>;

to use <retval> instead of o

   union bu o [value-expr: <retval>];
   ...
   <retval> = i;
   MEM[(union  *)&<retval>].b18 = _11;
   MEM[(union  *)&<retval>].b20 = _11;
   <retval> ={v} {CLOBBER(eol)};
   return <retval>;

As a result, the tool therefore thinks the returned value is unavailable.

Is my understanding of CLOBBER(eol) correct? (I.e., is this a bug in 
tree-nrv?) Or is <retval> special so that I should just ignore 
CLOBBER(eol) for this case?

    /Krister


[*] I'm planning to release the updated version in a few weeks. Meanwhile, 
you can find the old version at https://github.com/kristerw/pysmtgcc

[**] This example originates from gcc.c-torture/execute/921204-1.c 
compiled for x86 using the flags "-O -m32".

Re: CLOBBER(eol)

[Richard Biener]

On Tue, Jun 27, 2023 at 12:07 PM Krister Walfridsson via Gcc
<gcc@gcc.gnu.org> wrote:
>
> I'm working on an updated version of my translation validator [*], and I
> have some problems with CLOBBER(eol).
>
> I currently treat CLOBBER(eol) as making the memory invalid (i.e. all
> subsequent accesses is undefined behavior), but the tool reports
> miscompilation for a few cases where the tree-nrv pass makes the IR
> clobber <retval> by changing code such as [**]
>
>    union bu o;
>    ...
>    o = i;
>    MEM[(union  *)&o].b18 = _11;
>    MEM[(union  *)&o].b20 = _11;
>    <retval> = o;
>    o ={v} {CLOBBER(eol)};
>    return <retval>;
>
> to use <retval> instead of o
>
>    union bu o [value-expr: <retval>];
>    ...
>    <retval> = i;
>    MEM[(union  *)&<retval>].b18 = _11;
>    MEM[(union  *)&<retval>].b20 = _11;
>    <retval> ={v} {CLOBBER(eol)};
>    return <retval>;
>
> As a result, the tool therefore thinks the returned value is unavailable.
>
> Is my understanding of CLOBBER(eol) correct? (I.e., is this a bug in
> tree-nrv?) Or is <retval> special so that I should just ignore
> CLOBBER(eol) for this case?

I think this is a bug in NRV, yes, <retval> is special but the above would
allow to DSE the three stores.

Can you open a bugreport?

Thanks,
Richard.

>
>     /Krister
>
>
> [*] I'm planning to release the updated version in a few weeks. Meanwhile,
> you can find the old version at https://github.com/kristerw/pysmtgcc
>
> [**] This example originates from gcc.c-torture/execute/921204-1.c
> compiled for x86 using the flags "-O -m32".

Re: CLOBBER(eol)

[Krister Walfridsson]

On Tue, 27 Jun 2023, Richard Biener wrote:

> I think this is a bug in NRV, yes, <retval> is special but the above would
> allow to DSE the three stores.
>
> Can you open a bugreport?

Done! https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110434