https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #52 from post+gcc at ralfj dot de ---
For the point discussed earlier with the `restrict` in the musl memcpy, I had
another look at the definition of `restrict` and it's not entirely clear to me
any more that there is UB here. The rest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #51 from post+gcc at ralfj dot de ---
Oh great, I love it when one part of the C standard just adds exceptions to
statements made elsewhere. It's almost as if the authors want this to be as
hard to understand as possible...
That then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #49 from post+gcc at ralfj dot de ---
Even glibc itself seems to use `restrict`:
https://codebrowser.dev/glibc/glibc/string/string.h.html#43
So the compiler building glibc might inadvertently rely on the memory written
through dst an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #48 from post+gcc at ralfj dot de ---
> Note, clang makes the same assumption apparently (while MSVC emits rep movs
> inline and ICC either that, or calls _intel_fast_memcpy).
MSVC does the same thing as clang and GCC, if godbolt is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #43 from post+gcc at ralfj dot de ---
That is not my reading of the standard, but absent a proper (formal,
mathematical) spec I guess it is hard to tell.
With your reading, "if ((uintptr_t)src == 0x400400)" is UB, since changing the
"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #41 from post+gcc at ralfj dot de ---
> This entitles a compiler to emit asm equivalent to if (src==dest) system("rm
> -rf /") if it likes.
No it does not. restrict causes UB if the two pointers are used to access the
same memory. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #30 from post+gcc at ralfj dot de ---
There have been several assertions above that a certain way to solve this
either has no performance cost at all or severe performance cost. That sounds
like we are missing data -- ideally, someone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #12 from post+gcc at ralfj dot de ---
> GCC will not create an sNaN out of nowhere.
That's the part I was hoping for. :) I just don't think it obviously follows
from any docs (the C standard or GCC docs).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #10 from post+gcc at ralfj dot de ---
The standard says
> This annex does not require the full support for signaling NaNs specified in
> IEC 60559. This
annex uses the term NaN, unless explicitly qualified, to denote quiet NaNs.
Whe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #7 from post+gcc at ralfj dot de ---
I guess the idea is that by passing a signaling NaN to a float operation, I am
already entering unspecified behavior, so it's okay for that float operation to
violate its usual contract and return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #6 from post+gcc at ralfj dot de ---
Hm, OTOH the C standard says
> The expressions 1×x, x/1, and x are equivalent (on IEC 60559 machines, among
others).
So, it seems like when they say "The + ,- , * , and / operators provide the IE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #5 from post+gcc at ralfj dot de ---
> See
> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fsignaling-nans
That's unrelated. That's about whether operation on signaling NaNs can trap. I
am asking when operations can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
Bug ID: 112449
Summary: Arithmetic operations can produce signaling NaNs
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
post+gcc at ralfj dot de changed:
What|Removed |Added
CC||post+gcc at ralfj dot de
--- C
14 matches
Mail list logo
