[Bug c/87581] Misaligned 16-bit read trap on x86 platform should be either fixed or documented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87581 --- Comment #9 from Jakub Jelinek --- (In reply to David Svoboda from comment #8) > A clarification: > The SSE2 instructions are not new. (20 years old) > Their use by the optimizer is (relatively) new. (between 4.8.5 and 4.9.4 > from my testing). Maybe for a specific testcase, the vectorizer is being constantly improved. For many other testcases you'll find that it changed already in various releases starting with 4.0 (when the vectorizer has been added). 4.0 is just 13 years ago, still it is nothing I'd call recently.
[Bug c/87581] Misaligned 16-bit read trap on x86 platform should be either fixed or documented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87581 --- Comment #8 from David Svoboda --- A clarification: The SSE2 instructions are not new. (20 years old) Their use by the optimizer is (relatively) new. (between 4.8.5 and 4.9.4 from my testing).
[Bug c/87581] Misaligned 16-bit read trap on x86 platform should be either fixed or documented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87581 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #7 from Alexander Monakov --- SSE2 is not anywhere "relatively new", it's almost 20 years old. GCC makes it easy for portable code to perform unaligned accesses and have them well-optimized without any arch-specific ifdeffery (nor undefined behavior): simply use memcpy, fixed-size memcpy calls are recognized and transformed to unaligned loads/stores internally.
[Bug c/87581] Misaligned 16-bit read trap on x86 platform should be either fixed or documented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87581 --- Comment #6 from James Carlson --- "Partial strict" seems a stretch to me. The SSE2 instructions are relatively new, as is their use by the optimizer. That makes this a surprising change in behavior, particularly given that a vast quantity of software has been written assuming that x86 supports unaligned access directly. Nobody's arguing that the general behavior of the source code in question is anything other than "undefined." That's obviously the case. However, it is also a fair argument to say that alignment behavior for x86 has been very well known and understood ... right up to this point, where this optimization breaks it. It would be impractical (in the extreme) to use cast-align=strict. In nearly all cases where this macro is used, we're targeting x86 instructions that handle the request perfectly well. There is no actual bug, in source or runtime, and a warning would just be lost in the noise. Treating all usages as "bugs" in the code is just absurd, as is forcing x86 code to go through the painful paths that most RISC code (the other side of the #ifdef around that #define) uses merely because someone now calls x86 "partial strict." There's just one narrow, rare case where the problem happens -- loops that can be optimized by the use of SSE2 instructions -- and it's *VERY* hard to defend at the source level. Perhaps the ideal solution for those of us suffering through this disaster would be a new option that tells the optimizer NOT to assume alignment based solely on pointer type when targeting SSE2. (There are clearly cases where the alignment is known to be good, as when getting the value from a function [such as malloc] that always returns good alignment, or referencing a static or auto variable. But just seeing "short *" in the source would not be enough.)
[Bug c/87581] Misaligned 16-bit read trap on x86 platform should be either fixed or documented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87581 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #5 from Jakub Jelinek --- It is not a problem, your program is simply invalid. On partial strict alignment architectures like x86 you sometimes get away with that, but that doesn't mean it is valid, it is still undefined behavior. As has been said, use -fsanitize=undefined to detect these cases and fix them.
[Bug c/87581] Misaligned 16-bit read trap on x86 platform should be either fixed or documented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87581 David Svoboda changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #4 from David Svoboda --- Yes, this is an old problem. But being old does not invalidate the problem.
[Bug c/87581] Misaligned 16-bit read trap on x86 platform should be either fixed or documented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87581 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Richard Biener --- It's been this way for quite some time now.
[Bug c/87581] Misaligned 16-bit read trap on x86 platform should be either fixed or documented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87581
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment #2 from Eric Gallager ---
There are warnings from -Wcast-align=strict and -Wconversion that might be
relevant:
$ /usr/local/bin/gcc -c -O3 -fPIC -Wall -Wextra -pedantic -Wconversion
-Wcast-align=strict c.c
c.c: In function 'compute':
c.c:11:34: warning: cast increases required alignment of target type
[-Wcast-align]
11 | #define READ_UINT16(ptr) (*(uint16_t *)(ptr))
| ^
c.c:19:23: note: in expansion of macro 'READ_UINT16'
19 | int newval = (int)READ_UINT16(b1) + value;
| ^~~
c.c:12:34: warning: cast increases required alignment of target type
[-Wcast-align]
12 | #define WRITE_UINT16(ptr, val) (*(uint16_t *)(ptr) = (val))
| ^
c.c:20:5: note: in expansion of macro 'WRITE_UINT16'
20 | WRITE_UINT16(b2, newval);
| ^~~~
c.c:12:54: warning: conversion from 'int' to 'uint16_t' {aka 'short unsigned
int'} may change value [-Wconversion]
12 | #define WRITE_UINT16(ptr, val) (*(uint16_t *)(ptr) = (val))
| ^
c.c:20:5: note: in expansion of macro 'WRITE_UINT16'
20 | WRITE_UINT16(b2, newval);
| ^~~~
$
[Bug c/87581] Misaligned 16-bit read trap on x86 platform should be either fixed or documented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87581 --- Comment #1 from Andrew Pinski --- Use -fsantizer=undefined to catch this at runtime even without sse or otherwise.
