On Thu, 27 Jun 2024 at 20:07, Andrew Pinski via Gcc <gcc@gcc.gnu.org> wrote:
>
> On Thu, Jun 27, 2024 at 11:57 AM Jason Merrill via Gcc <gcc@gcc.gnu.org> 
> wrote:
> >
> > On Thu, Jun 27, 2024 at 2:38 PM Richard Biener
> > <richard.guent...@gmail.com> wrote:
> > > > Am 27.06.2024 um 19:04 schrieb Jason Merrill via Gcc <gcc@gcc.gnu.org>:
> > > >
> > > > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2434r1.html
> > > > proposes to require that repeated unspecified comparisons be
> > > > self-consistent, which does not match current behavior in either GCC
> > > > or Clang.  The argument is that the current allowance to be
> > > > inconsistent is user-unfriendly and does not enable significant
> > > > optimizations.  Any feedback about this?
> > >
> > > Can you give an example of an unspecified comparison?  I think the only 
> > > way to do what the paper wants is for the implementation to make the 
> > > comparison specified (without the need to document it).  Is the 
> > > self-consistency required only within some specified scope (a single 
> > > expression?) or even across TUs (which might be compiled by different 
> > > compilers or compiler versions)?
> > >
> > > So my feedback would be to make the comparison well-defined.
> > >
> > > I’m still curious about which ones are unspecified now.
> >
> > https://eel.is/c++draft/expr#eq-3.1
> > "If one pointer represents the address of a complete object, and
> > another pointer represents the address one past the last element of a
> > different complete object, the result of the comparison is
> > unspecified."
> >
> > This is historically unspecified primarily because we don't want to
> > force a particular layout of multiple variables.
> >
> > See the example under "consequences for implementations" in the paper.
>
> There is instability due to floating point too;
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93681
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
>
> and uninitialized variables:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301
> (but that might be fixed via https://wg21.link/P2795R5).

And https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420 required some
horrible complexity in libstdc++ to solve it.

Reply via email to