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
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
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
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 godb
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 ch
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
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 quie
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 r
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 pro
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
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: post+gcc at ralfj dot de
Target Milestone: ---
According to the IEEE 754 specification, the output of an arithmetic operation
can never be a signaling NaN. However, GCC performs optimizations that turn `x
* 1.0` into just
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #59 from post+gcc at ralfj dot de ---
> With the C provenance proposal this example is undefined since 'a' is not
exposed (it's address is not converted to an integer).
However, from what I can tell, GCC's beha
15 matches
Mail list logo
