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).