[Bug c++/105737] New: Incorrect evaluation order in new expression

[Bug c++/105737] New: Incorrect evaluation order in new expression

[m.cencora at gmail dot com]

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

            Bug ID: 105737
           Summary: Incorrect evaluation order in new expression
           Product: gcc
           Version: 11.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: m.cencora at gmail dot com
  Target Milestone: ---

Following program when compiled with -std=c++17 prints 1243, while it should
print 1234.
All gcc < 12 versions are affected.

#include <cstdio>

struct MyStruct
{
};

struct MyTuple
{
    int a;
    int b;
    MyStruct c;
    int d;
};

int deserializeInt(const char*s) noexcept
{
    std::puts(s);
    return 0;
}

MyStruct deserializeStruct(const char*s) noexcept
{
    std::puts(s);
    return {};
}


int main()
{
#if 0 // this disabled version works fine
    MyTuple a = {
        deserializeInt("1"),
        deserializeInt("2"),
        deserializeStruct("3"),
        deserializeInt("4")
    };
#else
    new MyTuple{
        deserializeInt("1"),
        deserializeInt("2"),
        deserializeStruct("3"),
        deserializeInt("4")
    };
#endif
}

Similar bug exists when placement new is used.
While this problem seems to be fixed in gcc 12, I have not found a bug report
for such a fix, so it may have been fixed by accident, so it would be good to
at least have a test case that this doesn't regress in future.
But the best would be get this fixed in gcc9, 10 and 11.

[Bug c++/105737] Incorrect evaluation order in new expression

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|needs-bisection             |
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-05-26
     Ever confirmed|0                           |1

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
It was fixed by r12-6325

c++: don't preevaluate new-initializer

The preevaluation code was causing trouble with my fix for PR94041, and now
I see that it's actually wrong since P0145 was adopted for C++17, mandating
order of evaluation for many expressions that were previously unspecified.
I don't see a need to preserve the preevaluation code for older standard
modes.

gcc/cp/ChangeLog:

* init.c (build_new_1): Remove preevaluation code.

gcc/testsuite/ChangeLog:

* g++.old-deja/g++.martin/new1.C: Don't expect preeval.
* g++.dg/tree-ssa/stabilize1.C: Removed.

[Bug c++/105737] [10/11 only] Incorrect evaluation order in new expression

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Incorrect evaluation order  |[10/11 only] Incorrect
                   |in new expression           |evaluation order in new
                   |                            |expression
   Target Milestone|---                         |10.4

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>It was fixed by r12-6325

Right that was a change explictly for this case and I don't know if we want to
backport it or not.
Note the last release in the 9 series is days away from being released so I
doubt it should even be tried to backport to that release.

[Bug c++/105737] [10/11 only] Incorrect evaluation order in new expression

[m.cencora at gmail dot com]

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

--- Comment #3 from m.cencora at gmail dot com ---
FWIW Ordered evaluation of elements in braced-init-list exists since C++11 (it
was not a part of P0145).

[Bug c++/105737] [10/11 only] Incorrect evaluation order in new expression

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug c++/105737] [11 only] Incorrect evaluation order in new expression

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[10/11 only] Incorrect      |[11 only] Incorrect
                   |evaluation order in new     |evaluation order in new
                   |expression                  |expression
      Known to fail|                            |10.5.0
   Target Milestone|10.5                        |11.5