[Bug c++/107521] New: clang rejects invalid code in libstdc++

[Bug c++/107521] New: clang rejects invalid code in libstdc++

[tim at klingt dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107521

            Bug ID: 107521
           Summary: clang rejects invalid code in libstdc++
           Product: gcc
           Version: 12.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tim at klingt dot org
  Target Milestone: ---

compare https://github.com/llvm/llvm-project/issues/58754

https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/char_traits.h#L216-L217
```
          if (__s1 == __s2) // unlikely, but saves a lot of work
            return __s1;
```

according to aaron ballman:

> Heh, that's a fun one. http://eel.is/c++draft/lex.string#9 is what that code is referring to and I believe Clang is correct to reject it as a core constant expression per http://eel.is/c++draft/expr.const#5.24 because the equality operator's results are unspecified.

according to jonathan wakely:
> This is a libstdc++ bug.
> And a g++ bug, for letting me do it.

[Bug c++/107521] clang rejects invalid code in libstdc++

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107521

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The funny part is clang says:
implementation-defined whether distinct literals will have distinct addresses
In ____clang____, the result of such a comparison is unspecified, so it is not
a constant expression. 

I think that means it is not a bug in either GCC nor clang. Just libstdc++
depends on GCC (implementation defined) behavior here ...

[Bug c++/107521] clang rejects invalid code in libstdc++

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107521

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Oh the GCC front-end bug is already recorded as PR 70248 (see bug 70248 comment
#2).

[Bug c++/107521] clang rejects invalid code in libstdc++

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107521

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
http://eel.is/c++draft/expr.eq#3
only talks about unspecified behavior if one is a pointer to a start of an
object and another to one past the end of another.
I believe we implement that in GCC, try e.g.

constexpr const char *f (const char* a, const char *b) {
  if (a == b)
    return a;

  return b;
}

char a, b;

constexpr const char *k = f(&a, &b);
constexpr const char *l = f(&a, &b + 1);

When string literals are involved, I think this is PR86369 instead, and Jason
said he thinks GCC is correct there, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369#c8

[Bug c++/107521] clang rejects invalid code in libstdc++

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107521

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And e.g. https://godbolt.org/z/qfzTT5jna from that PR is I think clearly a
clang bug, not a grey area, neither string literal is evaluated there multiple
times.