[Bug c++/104426] New: -fsanitize=undefined causes constexpr failures

[Bug c++/104426] New: -fsanitize=undefined causes constexpr failures

[pdimov at gmail dot com]

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

            Bug ID: 104426
           Summary: -fsanitize=undefined causes constexpr failures
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pdimov at gmail dot com
  Target Milestone: ---

The following program

```
struct category
{
    constexpr bool failed() const noexcept
    {
        return true;
    }
};

inline constexpr category s_cat;

struct condition
{
    category const* cat_;

    constexpr bool failed() const noexcept
    {
        if( cat_ )
        {
            return cat_->failed();
        }
        else
        {
            return false;
        }
    }
};

int main()
{
    constexpr condition cond{ &s_cat };
    static_assert( cond.failed() );
}
```

compiles without -fsanitize=undefined (https://godbolt.org/z/Pn9M5ocfz), but
fails with it (https://godbolt.org/z/KKc8Tb9qe) with

```
<source>: In function 'int main()':
<source>:31:31: error: non-constant condition for static assertion
   31 |     static_assert( cond.failed() );
      |                    ~~~~~~~~~~~^~
<source>:31:31:   in 'constexpr' expansion of 'cond.condition::failed()'
<source>:17:13: error: '((& s_cat) != 0)' is not a constant expression
   17 |         if( cat_ )
      |             ^~~~
```

This happens under all GCC versions starting from 7.

(The above is an extract from the test suite for
boost::system::error_condition.)

[Bug c++/104426] -fsanitize=undefined causes constexpr failures

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Maybe a dup of my PR 71962

[Bug c++/104426] -fsanitize=undefined causes constexpr failures

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
And PR 67762

[Bug c++/104426] -fsanitize=undefined causes constexpr failures

[jakub at gcc dot gnu.org]

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

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> ---
That's a consequence of -fsanitize=undefined turning on
-fno-delete-null-pointer-checks (it has to, otherwise -fsanitize=null wouldn't
work properly).
And -fno-delete-null-pointer-checks says that variables or functions can be
placed at NULL address.

[Bug c++/104426] -fsanitize=undefined causes constexpr failures

[pdimov at gmail dot com]

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

--- Comment #4 from Peter Dimov <pdimov at gmail dot com> ---
FWIW, I agree with everything Martin Sebor says in PR71962.
-fallow-address-zero is an entirely separate feature, and shouldn't be implied
by -fsanitize=undefined.

[Bug c++/104426] -fsanitize=undefined causes constexpr failures

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> That's a consequence of -fsanitize=undefined turning on
> -fno-delete-null-pointer-checks (it has to, otherwise -fsanitize=null
> wouldn't work properly).
> And -fno-delete-null-pointer-checks says that variables or functions can be
> placed at NULL address.

Note that's "historical" mostly, the correct way to check whether objects can
be at NULL address is the corresponding address-space hook.  Of course that
leaves us with no way for the user to override what the target thinks (unless
the target provides its own way to do that).

IMHO we can simply take away this option from the user, it was a mistake to
document it that way when it had this effect due to lack of a better way.

[Bug c++/104426] -fsanitize=undefined causes constexpr failures

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52369
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52369&action=edit
gcc12-pr104426.patch

Untested fix.
This stops the implied setting of -fno-delete-null-pointer-checks for
sanitizers and instead introduces an inline function that decides if null
pointer checks should be done or not.  In initializers and C++ manifestly
constant expressions only the -f{,no-}delete-null-pointer-checks from command
line or implied from some DSP targets will be honored (and separate question is
if automatic vars can be assumed to be non-NULL even on those targets), while
outside of those we keep what we've been doing before, i.e. UBSan disables
those optimizations so that -fsanitize=null etc. can continue working
correctly.

[Bug c++/104426] -fsanitize=undefined causes constexpr failures

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-05-15
     Ever confirmed|0                           |1