| Message ID | AANLkTimvmM6o5mPbjyb3Lkec-f9_P5BNSDod3U903rh1@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
How about just calling maybe_constant_value call after the fold_non_dependent_expr call in cp_parser_parenthesized_expression_list? Jason
On Fri, Mar 11, 2011 at 6:51 AM, Jason Merrill <jason@redhat.com> wrote: > How about just calling maybe_constant_value call after the > fold_non_dependent_expr call in cp_parser_parenthesized_expression_list? Well, I first tried something like this, but the key problem is the *non_dependent* part, so it does nothing if the expression involves templates: $ g++ -std=gnu++0x constexpr-attribute.C .../constexpr-attribute.C: At global scope: .../constexpr-attribute.C: In instantiation of S3<int>: .../constexpr-attribute.C:63:9: instantiated from here .../constexpr-attribute.C:59:44: error: requested alignment is not a constant void fun() [with T = int] .../constexpr-attribute.C:33:14: instantiated from here .../constexpr-attribute.C:24:7: error: requested alignment is not a constant .../constexpr-attribute.C:25:7: error: requested alignment is not a constant BTW, a general question, why isn't there a call to maybe_constant_value just at the end of fold_non_dependent_expr? My patch calls maybe_constant_value after taking away any dependent expression (cplus_decl_attributes does all the job). -- Rodrigo
On 03/11/2011 04:33 AM, Rodrigo Rivas wrote: > On Fri, Mar 11, 2011 at 6:51 AM, Jason Merrill<jason@redhat.com> wrote: >> How about just calling maybe_constant_value call after the >> fold_non_dependent_expr call in cp_parser_parenthesized_expression_list? > > Well, I first tried something like this, but the key problem is the > *non_dependent* part, so it does nothing if the expression involves > templates: Ah, yes, you would also need to call it in apply_late_template_attributes. > BTW, a general question, why isn't there a call to > maybe_constant_value just at the end of fold_non_dependent_expr? I tried combining the two functions at one point but it didn't work so well. It might make sense to try again, though. The problem is that we don't want to call fold_non_dependent_expr on an expression that has already been folded, but it's fine to repeat maybe_constant_value. > My patch calls maybe_constant_value after taking away any dependent > expression (cplus_decl_attributes does all the job). Sure, I guess calling it in one place is better. But I think let's wait until 4.6.1 for this patch. Jason
On Fri, Mar 11, 2011 at 4:58 PM, Jason Merrill <jason@redhat.com> wrote: > Sure, I guess calling it in one place is better. But I think let's wait > until 4.6.1 for this patch. Oh, I didn't notice the only-regression-fixes status. No problem. -- Rodrigo.
Applied on trunk. Jason
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c index eb5d4f5..8a2c2e3 100644 --- a/gcc/cp/decl2.c +++ b/gcc/cp/decl2.c @@ -1264,6 +1264,25 @@ cp_reconstruct_complex_type (tree type, tree bottom) return cp_build_qualified_type (outer, cp_type_quals (type)); } +/* Replaces any constexpr expression that may be into the attributes + arguments with their reduced value. */ + +static void +cp_check_const_attributes (tree attributes) +{ + tree attr; + for (attr = attributes; attr; attr = TREE_CHAIN (attr)) + { + tree arg; + for (arg = TREE_VALUE (attr); arg; arg = TREE_CHAIN (arg)) + { + tree expr = TREE_VALUE (arg); + if (EXPR_P (expr)) + TREE_VALUE (arg) = maybe_constant_value (expr); + } + } +} + /* Like decl_attributes, but handle C++ complexity. */ void @@ -1284,6 +1303,8 @@ cplus_decl_attributes (tree *decl, tree attributes, int flags) return; } + cp_check_const_attributes(attributes); + if (TREE_CODE (*decl) == TEMPLATE_DECL) decl = &DECL_TEMPLATE_RESULT (*decl); diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-attribute.C b/gcc/testsuite/g++.dg/cpp0x/constexpr-attribute.C new file mode 100644 index 0000000..58b3793 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-attribute.C @@ -0,0 +1,63 @@ +// { dg-options -std=c++0x } + +//A few constexpr's +constexpr int foo() { return __alignof__(int); } + +template<typename T> +constexpr int fooT() { return __alignof__(T); } + +template<int N> +constexpr int fooN() { return N; } + +//Now the attributes + +//with normal variables, +int a __attribute__((aligned(foo()))); +int b __attribute__((aligned(fooT<int>()))); +int c __attribute__((aligned(fooN<__alignof__(int)>()))); + +//with variables inside a template, +template <typename T> +void fun() +{ + T a __attribute__((aligned(foo()))); + T b __attribute__((aligned(fooT<T>()))); + T c __attribute__((aligned(fooN<__alignof__(T)>()))); + T d __attribute__((aligned(fooT<int>()))); + T e __attribute__((aligned(fooN<__alignof__(int)>()))); +} + +//instantiate it, +void bar() +{ + fun<int>(); +} + +//with classes +struct __attribute__((aligned(foo()))) S0 +{ + char dummy; +}; +S0 s0; + +struct __attribute__((aligned(fooT<int>()))) S1 +{ + char dummy; +}; +S1 s1; + +//and class templates +template <typename T> +struct __attribute__((aligned(foo()))) S2 +{ + char dummy; +}; + +S2<int> s2; + +template <typename T> +struct __attribute__((aligned(fooT<T>()))) S3 +{ + char dummy; +}; +S3<int> s3;
Hi! Checking the new constexpr support in the C++0x frontend, I've notices that there is one place where a plain constant is accepted but a constexpr is not. Probably you have guessed (from the subject line above), it is in an attribute argument, e.g: constexpr int foo() { return 4; } int __attribute__((aligned(4))) a; //ok int __attribute__((aligned(foo()))) b; //error: requested alignment is not a constant IMHO, this code is correct. The attached patch solves this issue cleanly, I think. In the included testsuite I've used only the attribute ((aligned)), but I don't think that should matter too much. Regards -- Rodrigo Changelog: gcc/cp/ 2011-03-10 Rodrigo Rivas Costa <rodrigorivascosta@gmail.com> * decl2.c (cp_check_const_attributes): New. (cplus_decl_attributes): Call cp_check_const_attributes. gcc/testsuite/ 2011-03-10 Rodrigo Rivas Costa <rodrigorivascosta@gmail.com> * g++.dg/cpp0x/constexpr-attribute.C: New. commit fbd79f3f22242a865d57fd106b4d8202a5e60241 Author: Rodrigo Rivas Costa <rodrigorivascosta@gmail.com> Date: Thu Mar 10 15:57:47 2011 +0100 constexpr attribute