https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91031

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Alexey Makhalov from comment #5)
> (In reply to Andrew Pinski from comment #1)
> > In previous versions of gcc, the compound literal was put in the function
> > level scope rather than in the current scope. Which is why it worked
> > previously.  But the code was undefined.  This was added to the changes page
> > too.
> 
> Hi Andrew, thanks for the update.
> 
> There is an inconsistency which is really worried me.
> 
> 1) The behavior of GCC is different (from user point of view). -O0 allocates
> anonymous variable per function, but -01 and higher allocate it per scope?

Because it is an optimization to be able to reuse the stack space.  Undefined
code at runtime is just that undefined.

> 
> 2) this sample will allocate anonymous (char *)"test" per function scope
> with any optimization

NO this example does not use compound literals so it does not have an anonymous
variable in play.  In fact in below testcase, "test" is allocated in a static
read only region.
I think you want:
j = (char[]){"test"};

See PR 89113 for an example.

> --------------------
> #include <string.h>
> 
> int testme(char *j) {
>         if (!j)
>                 j = (char *)"test";
> 
>         return strlen(j) == 4;
> }
> 
> int main(void) {
>         return testme(0) == 0;
> }
> ----------------------
> 3) Why GCC does not provide any warning/errors in that case?

Because escape analysis is "hard".  This can be found at runtime though with
-fsanitize=address (which enables -fsanitize-address-use-after-scope).

> 
> 4) Even if anonymous variable put only in current scope (with optimization),
> I still see space for it was allocated in function frame.
> I can give you bigger example where array of pointers was allocated on stack
> in prologue, but was not initialized.

It could have been shared with a different anonymous variable.


>  
> Can you point to the commit which introduced this change, please?

r259641

Reply via email to