[Bug middle-end/82365] stack locations are consolidated if noreturn function is on the path

["arnd at linaro dot org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #6 from Arnd Bergmann <arnd at linaro dot org> ---
(In reply to Jakub Jelinek from comment #5)

> Now, if you change the code so that 
> i2c_new_device(&info);
> comes first and then
> f(a);
> this would no longer be optimized, because in the common fortify_panic call
> all 4 info vars would be addressable (even escaped to another function).
> 
> That said, if it is the same type of variable and it can't be shared, I
> wonder why the kernel just doesn't use the same variable.

That is one of multiple workarounds I already implemented, the others are

1. split out the long case statements into separate functions (much too large
to be backported into stable kernel releases, but reduces the stack frames more
than the other approaches).
2. have only one variable (in the original driver the variables don't all have
the same name, so this patch also ends up being larger than the usual limit for
backported patches)
3. use strncpy() rather than strlcpy() (the fortified strncpy doesn't use
   strnlen()).
4. add the empty asm statement in strnlen()

Any of the above work fine, we just need to decide which one to use. I'm
currently leaning toward 3, followed by 1.

We will need to work around older compilers anyway, I mainly reported this
because it seemed like something that gcc should be able to handle better and
it could in theory cause problems elsewhere. I have only observed the problem
in one file in the kernel (an older device driver that probably has very few
users), so if this turns out hard to avoid in gcc, it won't be a big deal.