https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122326
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Summary|incorrect variable location |-O0 -g -fstack-protector-*
|in debug information with |can an unused variable at
|-fstack-protector-strong |the toplevel be the same
|enabled |address as used variable at
| |the toplevel
Ever confirmed|0 |1
--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
fstack-protector defers all stack variables. While -O0 normally defers just
non-smallish ones and ones NOT at the toplevel.
```
-param=min-size-for-stack-sharing=
Common Joined UInteger Var(param_min_size_for_stack_sharing) Init(32) Param
Optimization
The minimum size of variables taking part in stack slot sharing when not
optimizing.
```
```
/* Whether the variable is small enough for immediate allocation not to be
a problem with regard to the frame size. */
bool smallish
= (poly_int_tree_p (size_unit, &size)
&& (estimated_poly_value (size)
< param_min_size_for_stack_sharing));
...
/* If stack protection is enabled, *all* stack variables must be deferred,
so that we can re-order the strings to the top of the frame.
Similarly for Address Sanitizer. */
if (flag_stack_protect || asan_sanitize_stack_p ())
return true;
...
/* Variables declared in the outermost scope automatically conflict
with every other variable. The only reason to want to defer them
at all is that, after sorting, we can more efficiently pack
small variables in the stack frame. Continue to defer at -O2. */
if (toplevel && optimize < 2)
return false;
...
/* Without optimization, *most* variables are allocated from the
stack, which makes the quadratic problem large exactly when we
want compilation to proceed as quickly as possible. On the
other hand, we don't want the function's stack frame size to
get completely out of hand. So we avoid adding scalars and
"small" aggregates to the list at all. */
if (optimize == 0 && smallish)
return false;
```
These arrays are at the toplevel. So they are not defered for -O0
-fno-stack-protect-* but -fstack-protect defers them.
But then ones at the toplevel are not conflicted with others at the toplevel if
NOT used.
This is harder to implement than I am expecting.
But confirmed.
