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

            Bug ID: 94983
           Summary: Empty list initialization of aggregate class with
                    deleted default ctor rejected in C++14 and C++17
           Product: gcc
           Version: 9.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: andrey.vihrov at gmail dot com
  Target Milestone: ---

Consider the following C++ sample:

    struct S
    {
        S() = delete;
    };

    void foo()
    {
        new S{};
    }

In C++11 to C++17, S is an aggregate type. In C++20, S is not an aggregate type
(has a user-declared constructor).

In C++11, list initialization will perform value initialization if the
initializer list is empty and the class has a default constructor; otherwise,
if the class is an aggregate type, aggregate initialization will be performed.
Since C++14, the order is reversed: if the class is an aggregate type,
aggregate initialization will be performed; otherwise, value initialization
will be performed if the initializer list is empty and the class has a default
constructor.

Value initialization performs default initialization for S. Default
initialization calls the deleted default constructor.

Aggregate initialization has no effect and succeeds for S.

Putting this together:
* In C++11: S should be default-initialized and fail to compile
* In C++14: S should be aggregate-initialized and succeed
* In C++17: S should be aggregate-initialized and succeed
* In C++20: S should be default-initialized and fail to compile

GCC correctly rejects the sample with -std=c++11 and -std=c++2a. However, the
sample is also incorrectly rejected with -std=c++14 and -std=c++17.

Additionally, a variation of the sample gives different results, although it
should behave the same:

    void foo()
    {
        S{};
    }

GCC gives:
* -std=c++11: OK (incorrect)
* -std=c++14: OK (correct)
* -std=c++17: OK (correct)
* -std=c++2a: rejected (correct)

It is understandable, though, if GCC does not intend to change behavior for
C++11.


gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-pkgversion='Arch Linux 9.3.0-1'
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
gcc version 9.3.0 (Arch Linux 9.3.0-1)

Reply via email to