aboutsummaryrefslogtreecommitdiff
path: root/gcc/d/expr.cc
diff options
context:
space:
mode:
authorJakub Jelinek <jakub@redhat.com>2022-04-13 15:43:34 +0200
committerJakub Jelinek <jakub@redhat.com>2022-04-13 15:43:34 +0200
commit13c32c1984f5857ccce2aeb00ce34343e5a26954 (patch)
tree7b56ee580f8b155feb72512353933e83facced47 /gcc/d/expr.cc
parentdd61ee6fde5fcf1d503b679bb9b5e0a0ba7a515d (diff)
downloadgcc-13c32c1984f5857ccce2aeb00ce34343e5a26954.zip
gcc-13c32c1984f5857ccce2aeb00ce34343e5a26954.tar.gz
gcc-13c32c1984f5857ccce2aeb00ce34343e5a26954.tar.bz2
c++: Treat alignas align_expr and aligned attribute's operand as manifestly constant evaluation [PR105233]
The following testcase fails, because we only constant evaluate the alignas argument as non-manifestly constant-evaluated and as __builtin_is_constant_evaluated appears, we make it non-constant (the reason is that we often try to evaluate some expression without manifestly_const_eval perhaps even multiple times before actually evaluating it with manifestly_const_eval (e.g. when folding for warnings and in many other places), and we don't want __builtin_is_constant_evaluated to evaluate to false in those cases, because we could get a different result from when we actually evaluate it with manifestly_const_eval set). Now, for alignas the standard seems to be clear, it says the argument is constant-expression, which means we should manifestly-constant-eval it. Attributes are a fuzzy area, they are extensions and various attributes take e.g. identifiers, or string literals etc. as arguments. Either we can just treat alignas as manifestly-const-eval, for that we'd need some way how to differentiate between alignas and gnu::aligned or aligned attribute. Another possibility is what the patch below implements, treat both alignas and gnu::aligned and aligned attribute's argument as manifestly-const-eval and not do that for other attributes. Another is to go through all attributes and figure out for which such treatment is useful (e.g. those that expect INTEGER_CST as argument), and either add a new column in the attribute table or have another table in the C++ FE to find out which attribute needs that. Another is do that for all the attribute arguments that are EXPR_P and see what breaks (bet that it could be quite risky this late in GCC 12 cycle and especially for backporting). 2022-04-13 Jakub Jelinek <jakub@redhat.com> PR c++/105233 * decl2.cc (cp_check_const_attributes): For aligned attribute pass manifestly_const_eval=true to fold_non_dependent_expr. * g++.dg/cpp2a/is-constant-evaluated13.C: New test.
Diffstat (limited to 'gcc/d/expr.cc')
0 files changed, 0 insertions, 0 deletions