public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/93031] Wish: When the underlying ISA does not force pointer alignment, option to make GCC not assume it
       [not found] <bug-93031-4@http.gcc.gnu.org/bugzilla/>
@ 2020-05-13 14:18 ` felix.von.s at posteo dot de
  2021-03-16 15:38 ` vladislav.valtchev at gmail dot com
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 4+ messages in thread
From: felix.von.s at posteo dot de @ 2020-05-13 14:18 UTC (permalink / raw)
  To: gcc-bugs

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

felix <felix.von.s at posteo dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |felix.von.s at posteo dot de

--- Comment #4 from felix <felix.von.s at posteo dot de> ---
Given the discussion above apparently ended with the conclusion that code which
performs misaligned accesses is ill-formed even on architectures that are
permissive of such accesses, would it not make sense to make -Wcast-align
synonymous to -Wcast-align=strict?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug c/93031] Wish: When the underlying ISA does not force pointer alignment, option to make GCC not assume it
       [not found] <bug-93031-4@http.gcc.gnu.org/bugzilla/>
  2020-05-13 14:18 ` [Bug c/93031] Wish: When the underlying ISA does not force pointer alignment, option to make GCC not assume it felix.von.s at posteo dot de
@ 2021-03-16 15:38 ` vladislav.valtchev at gmail dot com
  2021-05-03  7:54 ` rguenth at gcc dot gnu.org
  2021-05-03 14:58 ` amonakov at gcc dot gnu.org
  3 siblings, 0 replies; 4+ messages in thread
From: vladislav.valtchev at gmail dot com @ 2021-03-16 15:38 UTC (permalink / raw)
  To: gcc-bugs

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

Vladislav Valtchev <vladislav.valtchev at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vladislav.valtchev at gmail dot co
                   |                            |m

--- Comment #5 from Vladislav Valtchev <vladislav.valtchev at gmail dot com> ---
Guys, in the Linux kernel too unaligned access is used when the ISA supports it
natively. Take a look at:

https://elixir.bootlin.com/linux/latest/source/lib/strncpy_from_user.c#L15

When CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is 1, we have:
    #define IS_UNALIGNED(src, dst) 0

The initial IS_UNALIGNED() check in do_strncpy_from_user() always fails and the
following statement is executed:

    *(unsigned long *)(dst+res) = c;

Where 'dst' is a char* pointer, while 'res' is an unsigned long.

CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is widely used:
https://elixir.bootlin.com/linux/latest/A/ident/CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS

What protects us from undefined behavior? We all agree that
-fno-strict-aliasing doesn't help in this case. Maybe we're *temporarily* kind
of safe because FPU instructions are not allowed in the kernel and we're not
aliasing anything? But that doesn't guarantee us that, in the future, some new
fancy optimization won't break everything, right?


My point is that out there there is a *ton* of code using unaligned access
(when the ISA supports it) and while it's great to optimize as much as the C
standard allows the new code, we still need to build legacy code as well, in
MANY cases. And for "legacy" code, I mean all the code that we used to compile
with GCC up to version 7.x, which is fairly recent.

I believe that it's *not a good idea* to just drop support for millions of
lines of code that potentially, somewhere, might rely on unaligned access
without not even adding an option to make that safe. It's simply not realistic
to fix ALL the "legacy" C code that uses unaligned access, no matter if, even
at the time, the C standard stated that unaligned access is UB. Therefore, it
will be really great to have an option such as "-fno-strict-align" or something
like that.


Side question: now we have "-Wcast-align=strict", which will trigger a warning
in cases like the example above, which is helpful, even if it cannot warn us in
all the cases (see Pascal's example). BUT, this warning can be suppressed this
way:

    *(unsigned long *)(void *)(dst+res) = c;

Question: does that mean that GCC *won't make assumptions* anymore about the
alignment of the pointer, or it's still UB from the GCC point of view?

Thanks in advance,
Vlad

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug c/93031] Wish: When the underlying ISA does not force pointer alignment, option to make GCC not assume it
       [not found] <bug-93031-4@http.gcc.gnu.org/bugzilla/>
  2020-05-13 14:18 ` [Bug c/93031] Wish: When the underlying ISA does not force pointer alignment, option to make GCC not assume it felix.von.s at posteo dot de
  2021-03-16 15:38 ` vladislav.valtchev at gmail dot com
@ 2021-05-03  7:54 ` rguenth at gcc dot gnu.org
  2021-05-03 14:58 ` amonakov at gcc dot gnu.org
  3 siblings, 0 replies; 4+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-05-03  7:54 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's still UB.  Note that GCC has for a _long_ time made this assumption - just
the places we take advantage of it have grown.

Note it would be _very_ difficult to provide a -fno-strict-alignment option
because we can't really make all data types unaligned since that would break
the ABI.  So instead we'd have to sprinkle flag_strict_alignment checks
all over the place so I'm very sure you won't get a "fixed" compiler and
you might get one that doesn't adhere to the platform ABI any more (in case
we put one flag_strict_alignment too many).

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug c/93031] Wish: When the underlying ISA does not force pointer alignment, option to make GCC not assume it
       [not found] <bug-93031-4@http.gcc.gnu.org/bugzilla/>
                   ` (2 preceding siblings ...)
  2021-05-03  7:54 ` rguenth at gcc dot gnu.org
@ 2021-05-03 14:58 ` amonakov at gcc dot gnu.org
  3 siblings, 0 replies; 4+ messages in thread
From: amonakov at gcc dot gnu.org @ 2021-05-03 14:58 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #7 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
In comment #2 I touched upon a potentially more practical way to offer
-fno-strict-alignment:

Run early work with ABI alignments: compute __alignof correctly, lay out
composite types as required by ABI, and assign alignments to variables
(including stack variables and function parameters). Then make a pass over
types and reduce their alignment. This way, optimizations see a universe where
types have alignment 1, and variables are defined as if they had an explicit
attribute-align with increased alignment (and likewise for structure fields).

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-05-03 14:58 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-93031-4@http.gcc.gnu.org/bugzilla/>
2020-05-13 14:18 ` [Bug c/93031] Wish: When the underlying ISA does not force pointer alignment, option to make GCC not assume it felix.von.s at posteo dot de
2021-03-16 15:38 ` vladislav.valtchev at gmail dot com
2021-05-03  7:54 ` rguenth at gcc dot gnu.org
2021-05-03 14:58 ` amonakov 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).