[Bug c++/57588] New: [C++11][constexpr] static constexpr in class fails to link

[Bug c++/57588] New: [C++11][constexpr] static constexpr in class fails to link

[mattyclarkson at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57588

            Bug ID: 57588
           Summary: [C++11][constexpr] static constexpr in class fails to
                    link
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mattyclarkson at gmail dot com

The following code, links in optimisation modes but not others:

  #include <iostream>

 
///////////////////////////////////////////////////////////////////////////////
  class Literal {
  private:
    Literal() = delete;
    Literal(const Literal&) = delete;
    Literal(Literal&&) = delete;
    Literal& operator=(const Literal&) = delete;
    Literal& operator=(Literal&&) = delete;
    ~Literal() = default;

  public:
    constexpr Literal(const int i);

  public:
    constexpr operator int() const;

  private:
    int int_;
  };

  constexpr Literal::Literal(const int i) : int_(i) {};

  constexpr Literal::operator int() const {
    return int_;
  }

 
///////////////////////////////////////////////////////////////////////////////
  class Test {
  private:
    Test(const Test&) = delete;
    Test(Test&&) = delete;
    Test& operator=(const Test&) = delete;
    Test& operator=(Test&&) = delete;
    ~Test() = default;

  public:
    static constexpr const Literal kLiteral = Literal(99);

  public:
    constexpr Test();

  public:
    constexpr operator int() const;

  private:
    int int_;
  };

  constexpr Test::Test() : int_(kLiteral) {};

  constexpr Test::operator int() const {
    return int_;
  }

 
///////////////////////////////////////////////////////////////////////////////
  int main() {
    std::cout << Literal(15) << std::endl;
    std::cout << Test() << std::endl;
    return 0;
  }

Has some odd compilation on my machine:

  [matt test] uname -a
  Linux office.acer-m5810 3.8.13-100.fc17.x86_64 #1 SMP Mon May 13 13:36:17 UTC
2013 x86_64 x86_64 x86_64 GNU/Linux
  [matt test] g++ -std=c++11 test.cpp -o test -O0 -g && ./test
  /tmp/ccZtV9ku.o: In function `Test::Test()':
  /home/matt/test/test.cpp:51: undefined reference to `Test::kLiteral'
  collect2: error: ld returned 1 exit status
  [matt test] g++ -std=c++11 test.cpp -o test -O1 -g && ./test
  15
  99
  [matt test] g++ -std=c++11 test.cpp -o test -O2 -g && ./test
  15
  99
  [matt test] g++ -std=c++11 test.cpp -o test -O3 -g && ./test
  15
  99

However, on gcc.godbolt.org and ideone.com I cannot get the same compilation
error with 4.7.2.  I'm assuming I'm not being a donkey and doing something
against the standard? :/

If I can help with any debugging, please ask.

[Bug c++/57588] [C++11][constexpr] static constexpr in class fails to link

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57588

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Isn't this just
http://gcc.gnu.org/wiki/VerboseDiagnostics#missing_static_const_definition ?

[Bug c++/57588] [C++11][constexpr] static constexpr in class fails to link

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57588

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Although shouldn't it fail to compile, due to private destructor and copy
constructor?

[Bug c++/57588] [C++11][constexpr] static constexpr in class fails to link

[mattyclarkson at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57588

--- Comment #3 from Matt Clarkson <mattyclarkson at gmail dot com> ---
Thanks for that link, its very informative :) I can see why it fails to link
now.

About the private destructor, I'd expect it to not compile, but it does.  I
actually didn't even realise I'd made it private as I was just hacking together
a quick testcase.  Is that a bug?

[Bug c++/57588] [C++11][constexpr] static constexpr in class fails to link

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57588

Daniel Krügler <daniel.kruegler at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler@googlemail.
                   |                            |com

--- Comment #4 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
(In reply to Jonathan Wakely from comment #1)
> Isn't this just
> http://gcc.gnu.org/wiki/VerboseDiagnostics#missing_static_const_definition ?

I don't think that this correct here (In C++11 the rules became relaxed). Just
having a quick look at it, it looks like this depends on bug 53628.
>From gcc-bugs-return-424241-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 12 10:01:42 2013
Return-Path: <gcc-bugs-return-424241-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 927 invoked by alias); 12 Jun 2013 10:01:42 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 863 invoked by uid 48); 12 Jun 2013 10:01:33 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/49630] [OOP] ICE on obsolescent deferred-length type bound character function
Date: Wed, 12 Jun 2013 10:01:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.7.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-49630-4-4G3UaEJxFN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-49630-4@http.gcc.gnu.org/bugzilla/>
References: <bug-49630-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg00620.txt.bz2
Content-length: 1159

http://gcc.gnu.org/bugzilla/show_bug.cgi?idI630

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-06-12
     Ever confirmed|0                           |1

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
For the code in comment #0, I get the following ICE:

In function 'do_something':
Segmentation fault
     print *,this%abc_function()
 ^

Internal compiler error: Error reporting routines re-entered.
gfcc: internal compiler error: Abort trap (program f951)

or

pr49630.f90: In function 'do_something':
pr49630.f90:26:0: internal compiler error: in build_int_cst_wide, at
tree.c:1213
     print *,this%abc_function()
 ^

pr49630.f90:26:0: internal compiler error: Abort trap
gfca: internal compiler error: Abort trap (program f951)

for versions configured with --enable-checking=release.

AFAICT the code in comment #1 compiles with 4.8 and trunk (it is not supported
in 4.7).

[Bug c++/57588] [C++11][constexpr] static constexpr in class fails to link

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57588

--- Comment #5 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
(In reply to Jonathan Wakely from comment #2)
> Although shouldn't it fail to compile, due to private destructor and copy
> constructor?

I agree, it should fail. Interesting is, that the code compiles even when I use
--no-elide-constructors.
>From gcc-bugs-return-424243-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 12 10:37:37 2013
Return-Path: <gcc-bugs-return-424243-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16103 invoked by alias); 12 Jun 2013 10:37:36 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 16082 invoked by uid 48); 12 Jun 2013 10:37:32 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57594] New: [C++11] in-class static initializer can use deleted copy constructor
Date: Wed, 12 Jun 2013 10:37:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: accepts-invalid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status keywords bug_severity priority component assigned_to reporter
Message-ID: <bug-57594-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg00622.txt.bz2
Content-length: 642

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW594

            Bug ID: 57594
           Summary: [C++11] in-class static initializer can use deleted
                    copy constructor
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Keywords: accepts-invalid
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redi at gcc dot gnu.org

This should be rejected:

struct Private
{
    Private(const Private&) = delete;
    Private() = default;
};

struct A
{
    static constexpr Private p = Private();
};

[Bug c++/57588] [C++11][constexpr] static constexpr in class fails to link

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57588

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Daniel Krügler from comment #4)
> I don't think that this correct here (In C++11 the rules became relaxed).

It was post-C++11, but as a DR we should implement it, and I see you're right,
the initialization of int_ uses the lvalue-to-rvalue conversion immediately so
it isn't odr-used.

I've created PR 57594 and PR 57595 for the missing diagnostics.
>From gcc-bugs-return-424244-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 12 10:42:11 2013
Return-Path: <gcc-bugs-return-424244-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19046 invoked by alias); 12 Jun 2013 10:42:11 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 19024 invoked by uid 48); 12 Jun 2013 10:42:08 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57595] New: [C++11] Destructor defaulted on first declaration is treated as public
Date: Wed, 12 Jun 2013 10:42:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: accepts-invalid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status keywords bug_severity priority component assigned_to reporter
Message-ID: <bug-57595-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg00623.txt.bz2
Content-length: 617

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW595

            Bug ID: 57595
           Summary: [C++11] Destructor defaulted on first declaration is
                    treated as public
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Keywords: accepts-invalid
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redi at gcc dot gnu.org

This should be rejected:

class Private
{
    ~Private() = default;
public:
    Private() = default;
};

int main()
{
    (void)Private{};
}

[Bug c++/57588] [C++11] static constexpr in class fails to link

[richard-gccbugzilla at metafoo dot co.uk]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57588

Richard Smith <richard-gccbugzilla at metafoo dot co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |richard-gccbugzilla@metafoo
                   |                            |.co.uk

--- Comment #7 from Richard Smith <richard-gccbugzilla at metafoo dot co.uk> ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Daniel Krügler from comment #4)
> > I don't think that this correct here (In C++11 the rules became relaxed).
> 
> It was post-C++11, but as a DR we should implement it, and I see you're
> right, the initialization of int_ uses the lvalue-to-rvalue conversion
> immediately so it isn't odr-used.

The mem-initializer in question is "int_(kLiteral)", or after performing
overload resolution, "int_(kLiteral.operator int())". This is an odr-use of
kLiteral, therefore a definition is required. There is no lvalue-to-rvalue
conversion here; 'Literal::operator int' returns an rvalue (and in any case,
kLiteral is not in the set of potential results of the expression).
>From gcc-bugs-return-425498-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 01 06:25:43 2013
Return-Path: <gcc-bugs-return-425498-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22289 invoked by alias); 1 Jul 2013 06:25:43 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 22233 invoked by uid 48); 1 Jul 2013 06:25:36 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/57763] [4.9 Regression]: comp-goto-1.c: ICE verify_flow_info failed, error: EDGE_CROSSING missing across section boundary
Date: Mon, 01 Jul 2013 06:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: steven at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cf_gcctarget target_milestone
Message-ID: <bug-57763-4-16qknCGm1R@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57763-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57763-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-07/txt/msg00005.txt.bz2
Content-length: 718

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |alpha-linux-gnu
   Target Milestone|---                         |4.9.0

--- Comment #5 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Steven Bosscher from comment #4)
> Can you please give the revision number for the compiler that gives
> you this problem? The revision number must match to make sure the
> gcda file is valid.

The revision is:

xgcc (GCC) 4.9.0 20130630 (experimental) [trunk revision 200569]
>From gcc-bugs-return-425499-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 01 06:26:19 2013
Return-Path: <gcc-bugs-return-425499-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23147 invoked by alias); 1 Jul 2013 06:26:19 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 23122 invoked by uid 55); 1 Jul 2013 06:26:16 -0000
From: "zeccav at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0
Date: Mon, 01 Jul 2013 06:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: zeccav at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57749-4-yAXUgIwK9n@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57749-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57749-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-07/txt/msg00006.txt.bz2
Content-length: 592

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW749

--- Comment #12 from Vittorio Zecca <zeccav at gmail dot com> ---
> --- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
>> Yes, I agree that there is a bug, ...
>
> Then you should report to the library maintainers, not to gfortran.

The notion that this may be a library bug was not obvious to me from
the beginning.
I think that if the gfortran developers suspect there is a bug in a
library called
by gfortran to handle a numeric intrinsic operator like exponentiation,
then they should be worried, more than I am.

[Bug c++/57588] [C++11] static constexpr in class fails to link

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #8 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Thus, if I understand correctly the discussion (otherwise, please, reopen!)
modulo access control issues in the testcase, we correctly fail at linktime.