[Bug c++/106409] New: GCC with LTO: Warning: argument 1 value ‘18...615’ (SIZE_MAX) exceeds maximum object size

[Bug c++/106409] New: GCC with LTO: Warning: argument 1 value ‘18...615’ (SIZE_MAX) exceeds maximum object size

[lluis.alemany.puig at gmail dot com]

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

            Bug ID: 106409
           Summary: GCC with LTO: Warning: argument 1 value ‘18...615’
                    (SIZE_MAX) exceeds maximum object size
           Product: gcc
           Version: 11.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: lluis.alemany.puig at gmail dot com
  Target Milestone: ---

I'm using g++ (Ubuntu 11.1.0-1ubuntu1~20.04) 11.1.0. I'm getting the following
warning when I compile my code using -flto and -fno-fat-lto-objects:

```
    In member function ‘alloc_data’,
        inlined from ‘__ct ’ at data_array.hpp:9:67,
        inlined from ‘__ct ’ at main.cpp:26:5,
        inlined from ‘main’ at main.cpp:61:16:
    data_array.hpp:29:50: warning: argument 1 value ‘18446744073709551615’
exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=]
       29 |                 m_data = m_size == 0 ? nullptr : new T[m_size];
          |                                                  ^
    data_array.hpp: In function ‘main’:
    /usr/include/c++/11/new:128:26: note: in a call to allocation function
‘operator new []’ declared here
      128 | _GLIBCXX_NODISCARD void* operator new[](std::size_t) _GLIBCXX_THROW
(std::bad_alloc)
          |                          ^
```

The two sets of commands I use to compile my code are (-fsanitize=undefined):

```
    g++ -pipe -std=c++17 -fPIC -fopenmp -flto -fno-fat-lto-objects -O3 -Wall
-Wextra -Wshadow -Wnon-virtual-dtor -Wold-style-cast -Wcast-align -Wunused
-Woverloaded-virtual -Wpedantic -Wconversion -Wsign-conversion
-Wnull-dereference -Wdouble-promotion -Wformat=2 -Wduplicated-cond
-Wduplicated-branches -Wlogical-op -Wuseless-cast -Wrestrict -UDEBUG -DNDEBUG
-fstrict-aliasing -D_REENTRANT -fPIC -fsanitize=undefined -c main.cpp
    g++ -fPIC -O3 -flto -fno-fat-lto-objects -DNDEBUG -UDEBUG -Wl,-O3
-fsanitize=undefined -o main main.o
```

and (-fsanitize=address)

```
    g++ -pipe -std=c++17 -fPIC -fopenmp -flto -fno-fat-lto-objects -O3 -Wall
-Wextra -Wshadow -Wnon-virtual-dtor -Wold-style-cast -Wcast-align -Wunused
-Woverloaded-virtual -Wpedantic -Wconversion -Wsign-conversion
-Wnull-dereference -Wdouble-promotion -Wformat=2 -Wduplicated-cond
-Wduplicated-branches -Wlogical-op -Wuseless-cast -Wrestrict -UDEBUG -DNDEBUG
-fstrict-aliasing -D_REENTRANT -fPIC -fsanitize=address -c main.cpp
    g++ -fPIC -O3 -flto -fno-fat-lto-objects -DNDEBUG -UDEBUG -Wl,-O3 -o main
main.o -lasan
```

Both sets of commands produce the warning above. With both, the program
executes normally and finishes without issuing any error message.

I generated the *i file with the following command
```
    g++ -E -std=c++17 -fPIC -fopenmp -flto -fno-fat-lto-objects -O3 -Wall
-Wextra -Wshadow -Wnon-virtual-dtor -Wold-style-cast -Wcast-align -Wunused
-Woverloaded-virtual -Wpedantic -Wconversion -Wsign-conversion
-Wnull-dereference -Wdouble-promotion -Wformat=2 -Wduplicated-cond
-Wduplicated-branches -Wlogical-op -Wuseless-cast -Wrestrict -UDEBUG -DNDEBUG
-fstrict-aliasing -D_REENTRANT -fPIC -save-temps -c main.cpp
```

[Bug c++/106409] GCC with LTO: Warning: argument 1 value ‘18...615’ (SIZE_MAX) exceeds maximum object size

[lluis.alemany.puig at gmail dot com]

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

--- Comment #1 from llualpu <lluis.alemany.puig at gmail dot com> ---
This was originally submitted at Stack Overflow:
https://stackoverflow.com/questions/73047957/gcc-with-lto-warning-argument-1-value-18-615-size-max-exceeds-maximum-ob

[Bug c++/106409] GCC with LTO: Warning: argument 1 value ‘18...615’ (SIZE_MAX) exceeds maximum object size

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
                 CC|                            |marxin at gcc dot gnu.org
   Last reconfirmed|                            |2022-07-22

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Please attach the pre-processed source file.

[Bug c++/106409] GCC with LTO: Warning: argument 1 value ‘18...615’ (SIZE_MAX) exceeds maximum object size

[lluis.alemany.puig at gmail dot com]

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

--- Comment #3 from llualpu <lluis.alemany.puig at gmail dot com> ---
Created attachment 53336
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53336&action=edit
(Compressed) preprocessed file generated by GCC as required by "What we need"

I couldn't upload it raw (in plain text, without compressing) because it was
bigger than the file size limit (around 1300 KB).

[Bug tree-optimization/106409] GCC with LTO: Warning: argument 1 value ‘18...615’ (SIZE_MAX) exceeds maximum object size

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|1                           |0
             Status|WAITING                     |UNCONFIRMED

[Bug tree-optimization/106409] GCC with LTO: Warning: argument 1 value ‘18...615’ (SIZE_MAX) exceeds maximum object size

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=80922
     Ever confirmed|0                           |1
           Keywords|                            |lto
   Last reconfirmed|2022-07-22 00:00:00         |2023-05-17
             Status|UNCONFIRMED                 |NEW

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I suspect the issue is for LTO we don't stream out the ignore part .

Anyways confirmed, you can reproduce it with the following single file
testcase:
```
typedef struct st_mysql_bind
{
  int t;
  int t1;
  int t2;
  int t3;
} bb;

[[gnu::noipa]]
void *f(unsigned long paramCount)
{
    if (paramCount == 0)
      return nullptr;
    return new bb[paramCount]();
}

int main(void)
{
  f(100);
}
```
Compile it with `-flto -W -Wall -O2` and see the warning.

[Bug tree-optimization/106409] GCC with LTO: Warning: argument 1 value ‘18...615’ (SIZE_MAX) exceeds maximum object size

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thiago at kde dot org

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 109895 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/106409] GCC with LTO: Warning: argument 1 value ‘18...615’ (SIZE_MAX) exceeds maximum object size with new

[thiago at kde dot org]

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

--- Comment #6 from Thiago Macieira <thiago at kde dot org> ---
Suggestion: add a function to libgcc to be called instead of
__cxa_throw_bad_array_new_length when exceptions are disabled. That function
can be a mere two instructions, but it provides two advantages:
* no need to stream something into LTO
* allows post-compilation tools to know what's happened (Valgrind, debuggers,
etc.)

I don't know if this is an acceptable solution, but I thought I'd make the
suggestion.

[Bug tree-optimization/106409] GCC with LTO: Warning: argument 1 value ‘18...615’ (SIZE_MAX) exceeds maximum object size with new

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=58525

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Thiago Macieira from comment #6)
> Suggestion: add a function to libgcc to be called instead of
> __cxa_throw_bad_array_new_length when exceptions are disabled. That function
> can be a mere two instructions, but it provides two advantages:
> * no need to stream something into LTO

Except there is still a generic issue (which I did link, PR 80922).

> * allows post-compilation tools to know what's happened (Valgrind,
> debuggers, etc.)
> 
> I don't know if this is an acceptable solution, but I thought I'd make the
> suggestion.

See PR 58525 also which added that code path.

[Bug tree-optimization/106409] GCC with LTO: Warning: argument 1 value ‘18...615’ (SIZE_MAX) exceeds maximum object size with new

[thiago at kde dot org]

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

--- Comment #8 from Thiago Macieira <thiago at kde dot org> ---
(In reply to Andrew Pinski from comment #7)
> See PR 58525 also which added that code path.

That explains why it won't call __cxa_throw_bad_array_new_length, but not why
it will call operator new[](-1). My suggestion is to keep
__cxa_throw_bad_array_new_length for the exceptions case and add a new function
for the non-exceptional case. This function could:
* call operator new[], which would probably cause the stack unwinder to
terminate the application
* call std::terminate() directly, possibly after printing something to stderr
* return null pointer
* something else (generate debug break, raise(SIGKILL), etc.)