public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/96019] New: Optimization forgets non-default scalar_storage_order
@ 2020-07-01 12:38 arthur200126 at gmail dot com
2020-07-01 12:52 ` [Bug c/96019] " rguenth at gcc dot gnu.org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: arthur200126 at gmail dot com @ 2020-07-01 12:38 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c/96019] Optimization forgets non-default scalar_storage_order
2020-07-01 12:38 [Bug c/96019] New: Optimization forgets non-default scalar_storage_order arthur200126 at gmail dot com
@ 2020-07-01 12:52 ` rguenth at gcc dot gnu.org
2020-07-01 13:36 ` ebotcazou at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-07-01 12:52 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c/96019] Optimization forgets non-default scalar_storage_order
2020-07-01 12:38 [Bug c/96019] New: Optimization forgets non-default scalar_storage_order arthur200126 at gmail dot com
2020-07-01 12:52 ` [Bug c/96019] " rguenth at gcc dot gnu.org
@ 2020-07-01 13:36 ` ebotcazou at gcc dot gnu.org
2020-07-01 14:00 ` rguenth at gcc dot gnu.org
2020-07-01 14:22 ` ebotcazou at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2020-07-01 13:36 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c/96019] Optimization forgets non-default scalar_storage_order
2020-07-01 12:38 [Bug c/96019] New: Optimization forgets non-default scalar_storage_order arthur200126 at gmail dot com
2020-07-01 12:52 ` [Bug c/96019] " rguenth at gcc dot gnu.org
2020-07-01 13:36 ` ebotcazou at gcc dot gnu.org
@ 2020-07-01 14:00 ` rguenth at gcc dot gnu.org
2020-07-01 14:22 ` ebotcazou at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-07-01 14:00 UTC (permalink / raw)
To: gcc-bugs
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(?)
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c/96019] Optimization forgets non-default scalar_storage_order
2020-07-01 12:38 [Bug c/96019] New: Optimization forgets non-default scalar_storage_order arthur200126 at gmail dot com
` (2 preceding siblings ...)
2020-07-01 14:00 ` rguenth at gcc dot gnu.org
@ 2020-07-01 14:22 ` ebotcazou at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2020-07-01 14:22 UTC (permalink / raw)
To: gcc-bugs
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. :-)
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-07-01 14:22 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-01 12:38 [Bug c/96019] New: Optimization forgets non-default scalar_storage_order arthur200126 at gmail dot com
2020-07-01 12:52 ` [Bug c/96019] " rguenth at gcc dot gnu.org
2020-07-01 13:36 ` ebotcazou at gcc dot gnu.org
2020-07-01 14:00 ` rguenth at gcc dot gnu.org
2020-07-01 14:22 ` ebotcazou at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).