https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #23 from Fredrik Hederstierna
<fredrik.hederstie...@securitas-direct.com> ---
Ah ok, yes I think you are right. The check could possibly be in "cp/typeck.c"
and "cp/tree.c"? but I'm not familiar with this C++ parsing code.
Interesting that this code gets warning:
B* foo(A a) {
B *b = &(a.getB());
return b;
}
test.c: In function ‘B* foo2(A)’:
test.c:28:20: error: taking address of temporary [-fpermissive]
B *b = &(a.getB());
but this does not (as you example)
double foo(A a) {
double *x = &(a.getB().x[0]);
return x[0];
}
though the addressing taken was done implicit when taking addressing of the
array x?
Checking flow in "typeck.c", it does not give warning since the 'kind' of
lvalue is not clk_class but clk_ordinary in latter case since its ARRAY_REF.
The warning-code in typeck.c does check for this, but I saw that recently some
code was made to consider an array to be a 'class' in PR 80415 patch:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80415
Could it be possible to also include more 'kinds' or types in the warning-test
to also include this example?
Though checking this small patch will trigger the warning, but probably its not
the right thing to do, but maybe a starting point to seek for a solution?
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 2122450..4dab925 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -163,7 +163,6 @@ lvalue_kind (const_tree ref)
/* FALLTHRU */
case INDIRECT_REF:
case ARROW_EXPR:
- case ARRAY_REF:
case ARRAY_NOTATION_REF:
case PARM_DECL:
case RESULT_DECL:
@@ -212,6 +211,7 @@ lvalue_kind (const_tree ref)
case COMPOUND_EXPR:
return lvalue_kind (TREE_OPERAND (ref, 1));
+ case ARRAY_REF:
case TARGET_EXPR:
return clk_class;
This will return lvalue 'kind' as clk_class also for arrays, and then the
warning will trigger in typeck.c. Probably this is just nonsense, so I will
leave this to someone else to solve that understands this part of code (not
me).
Still I think other path is also interesting about warning for uninitialized
artificials (that was removed in PR 43347 by unclear reasons - I think the
warning was correct, and the issue was rather that generated SRA name was not
the real variable name, which is a completely other problem related to debug
info I think)...
