[Bug c/96019] New: Optimization forgets non-default scalar_storage_order

[Bug c/96019] New: Optimization forgets non-default scalar_storage_order

[arthur200126 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96019

            Bug ID: 96019
           Summary: Optimization forgets non-default scalar_storage_order
           Product: gcc
           Version: 9.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: arthur200126 at gmail dot com
  Target Milestone: ---

Created attachment 48818
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48818&action=edit
test case

The attached code uses a scalar_storage_order to access a byte field in big
endian. 

On an x86-64 Windows system, the output without optimization, as expected, is
"aabbccdd 1122". The output with optimization (Og) is "ddccbbaa 2211".

The same happens on the https://gcc.godbolt.org/ site. With O0 a bswap can be
found, but it is gone in -O1 and -Og.

I was unable to find the responsible option by bisection on the godbolt
instance, but that could just be a godbolt thing.

[Bug c/96019] Optimization forgets non-default scalar_storage_order

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96019

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think Eric posted patches for this?

[Bug c/96019] Optimization forgets non-default scalar_storage_order

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96019

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #2 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
See the manual:

     Moreover, the use of type punning or aliasing to toggle the
     storage order is not supported; that is to say, a given scalar
     object cannot be accessed through distinct types that assign a
     different storage order to it.

[Bug c/96019] Optimization forgets non-default scalar_storage_order

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96019

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
So AFAIU

int main(int argc, char *argv[]) {
    uint8_t raw[] = { 0xaa, 0xbb, 0xcc, 0xdd, 0x11, 0x22 };
    SS instance;
    memcpy (&instance, raw, sizeof (SS));
    printf("%x, %x\n", instance.a, instance.b);
    return 0;
}

would be OK(?)

[Bug c/96019] Optimization forgets non-default scalar_storage_order

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96019

--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> So AFAIU
> 
> int main(int argc, char *argv[]) {
>     uint8_t raw[] = { 0xaa, 0xbb, 0xcc, 0xdd, 0x11, 0x22 };
>     SS instance;
>     memcpy (&instance, raw, sizeof (SS));
>     printf("%x, %x\n", instance.a, instance.b);
>     return 0;
> }
> 
> would be OK(?)

Yes, this should work once the patch (or a variant thereof) I posted some time
ago to make memcpy a storage order barrier is installed. :-)