[Bug c++/59211] New: init_priority doesn't work with constant expressions

[Bug c++/59211] New: init_priority doesn't work with constant expressions

[nyh at math dot technion.ac.il]

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

            Bug ID: 59211
           Summary: init_priority doesn't work with constant expressions
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nyh at math dot technion.ac.il

It seems that __attribute__((init_priority(...))) demands an integer constant,
and doesn't work with constant *expressions*. For example, the following
doesn't compile:

constexpr int prio = 123;
__attribute__((init_priority(prio))) t a;

Even more sadly for me, the following attempt to avoid manually defining
priority numbers doesn't compile:

enum class init_prio : int {
    first = 101,
    second,
    third,
};
__attribute__((init_priority(init_prio::second))) t a;

There is no real reason why this shouldn't be allowed. Interestingly, with
__attribute((constructor(...)), exactly the same constructs do work!

[Bug c++/59211] init_priority doesn't work with constant expressions

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
Similar to PR 53017 (does the same +0 workaround work?). The main difference
with constructor seems to be a call to default_conversion.

[Bug c++/59211] init_priority doesn't work with constant expressions

[nyh at math dot technion.ac.il]

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

--- Comment #2 from Nadav Har'El <nyh at math dot technion.ac.il> ---
Amazing, this workaround indeed works :-) Thanks!

With the constexpr prio, indeed using prio+0 solved the problem.

For the enum class, prio::second, I can't use addition (because it isn't
implemented in this class), but a simple cast to int works!

__attribute__((init_priority((int)init_prio::second)))

[Bug c++/59211] init_priority doesn't work with constant expressions

[daniel.kruegler at googlemail dot com]

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

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

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

--- Comment #3 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
(In reply to Nadav Har'El from comment #2)
> For the enum class, prio::second, I can't use addition (because it isn't
> implemented in this class), but a simple cast to int works!

IMO the explicit conversion is necessary here and the fact that it doesn't work
without it is not a bug. Note that a scoped enumeration type does not
implicitly convert to integral types and only a very small number of core
language constructs accept scoped enums without a case.
>From gcc-bugs-return-435452-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Nov 21 21:25:01 2013
Return-Path: <gcc-bugs-return-435452-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23028 invoked by alias); 21 Nov 2013 21:25:00 -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 22882 invoked by uid 48); 21 Nov 2013 21:24:56 -0000
From: "jsm28 at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/21718] real.c rounding not perfect
Date: Thu, 21 Nov 2013 21:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.1.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: jsm28 at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-21718-4-70rQRuigDp@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-21718-4@http.gcc.gnu.org/bugzilla/>
References: <bug-21718-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-11/txt/msg02229.txt.bz2
Content-length: 748

http://gcc.gnu.org/bugzilla/show_bug.cgi?id!718

--- Comment #27 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
No, it was lack of precision.  MPFR may need to use many more than
SIGNIFICAND_BITS internally in order to compute a result that is correctly
rounded towards zero to SIGNIFICAND_BITS (plus the ternary value), but GCC
doesn't need to know or care how many bits MPFR uses; all it needs to know is
that SIGNIFICAND_BITS is at least 2 more than the largest number in any
supported binary floating-point format.

Having got the C11 features I wanted into 4.9 I then looked for bugs on my list
of conformance issues that would be more suited to development stage 1 (ends
today) than to subsequent stabilization stages.  This was one.

[Bug c++/59211] init_priority doesn't work with constant expressions

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Daniel Krügler from comment #3)
> IMO the explicit conversion is necessary here and the fact that it doesn't
> work without it is not a bug. Note that a scoped enumeration type does not
> implicitly convert to integral types and only a very small number of core
> language constructs accept scoped enums without a case.

I filed PR 59281 for the fact that scoped enums are accepted in
attribute((constructor)) without a cast.
>From gcc-bugs-return-435732-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Nov 24 23:33:21 2013
Return-Path: <gcc-bugs-return-435732-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30899 invoked by alias); 24 Nov 2013 23:33:21 -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 30878 invoked by uid 48); 24 Nov 2013 23:33:17 -0000
From: "aron at udel dot edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/59277] x86_64 code generation defects when SSE instructions are disabled
Date: Sun, 24 Nov 2013 23:33:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.7.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: aron at udel dot edu
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-59277-4-clB5UCeAzp@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59277-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59277-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-11/txt/msg02509.txt.bz2
Content-length: 666

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

--- Comment #2 from Aaron Myles Landwehr <aron at udel dot edu> ---
Right, a fix for this is really a question of whether the ABI holds king here.

It is worth mentioning that the current behavior of passing the FP arguments
via the stack is in itself also against what the ABI dictates for x86_64.

LLVM also has the same issue and I passed this along to them with very much the
same question of whether this should be handled at all or whether it should
simply be left as a "you can try disabling sse in x86_64 if you want, it may
work, it may not -- it really depends on what you are doing -- all bets are
off"

[Bug c++/59211] init_priority doesn't work with constant expressions

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse <glisse at gcc dot gnu.org> ---
Author: glisse
Date: Mon Feb  3 19:07:55 2014
New Revision: 207436

URL: http://gcc.gnu.org/viewcvs?rev=207436&root=gcc&view=rev
Log:
2014-02-03  Marc Glisse  <marc.glisse@inria.fr>

    PR c++/53017
    PR c++/59211
gcc/c-family/
    * c-common.c (handle_aligned_attribute, handle_alloc_size_attribute,
    handle_vector_size_attribute, handle_nonnull_attribute): Call
    default_conversion on the attribute argument.
    (handle_nonnull_attribute): Increment the argument number.
gcc/cp/
    * tree.c (handle_init_priority_attribute): Call default_conversion on
    the attribute argument.
gcc/
    * doc/extend.texi (Function Attributes): Typo.
gcc/testsuite/
    * c-c++-common/attributes-1.c: New testcase.
    * g++.dg/cpp0x/constexpr-attribute2.C: Likewise.


Added:
    trunk/gcc/testsuite/c-c++-common/attributes-1.c   (with props)
    trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-attribute2.C   (with props)
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-common.c
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/tree.c
    trunk/gcc/doc/extend.texi
    trunk/gcc/testsuite/ChangeLog

Propchange: trunk/gcc/testsuite/c-c++-common/attributes-1.c
            ('svn:eol-style' added)

Propchange: trunk/gcc/testsuite/c-c++-common/attributes-1.c
            ('svn:keywords' added)

Propchange: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-attribute2.C
            ('svn:eol-style' added)

Propchange: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-attribute2.C
            ('svn:keywords' added)

[Bug c++/59211] init_priority doesn't work with constant expressions

[glisse at gcc dot gnu.org]

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

Marc Glisse <glisse at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
      Known to work|                            |4.9.0
         Resolution|---                         |FIXED
   Target Milestone|---                         |4.9.0

--- Comment #6 from Marc Glisse <glisse at gcc dot gnu.org> ---
.