This is the mail archive of the
mailing list for the GCC project.
Re: PATCH: tree-ssa-sink breaks stack layout
Richard Guenther wrote:
> It is likely possible to paper over the issue for the testcase we have, but
> this fix-this-single-testcase-with-a-workaround doesn't sound appealing
> to me if we admittedly know other places in the compiler with exactly
> the same issue ...
Do we? Again, that's not a rhetorical question; I don't know the
answer. Do we have other test-cases showing this problem with other
> So, instead of trying to paper over this in tree-ssa-sink.c I would instead
> suggest to detect "overlapping" scopes during cfgexpand and consider
> them as merged for the purpose of stack slot sharing. This will result
> in less sharing but be a more robust fix.
Yes, that sounds plausible to me. It is indeed detectable if a direct
(rather than pointer-based) access to a variable has migrated outside
the lexical scope of that variable. Is that's what happening in this
case? I wasn't sure if it was a pointer escaping, or a direct reference
to the variable escaping. Obviously, both could be problems, but we are
explicitly looking for less-broken approaches here, not right answers...
>> "code doesn't work; debug for a while; looks like compiler is broken;
>> search web for work-around; rebuild with work-around" is not as as good
>> an experience as "code works". :-)
> Heh, but of course we have that all the time with answers like
> "try -fno-strict-aliasing", "try -fwrapv", etc., so adding another one doesn't
> sound too bad here.
That's true -- but those cases are for code that isn't strictly
conforming. To a certain extent, we've taken the attitude that it's the
user's responsibility to write valid C code, and that we can mercilessly
punish those who don't. But, it's only fair, then, that we try hard to
compile the valid C code correctly. :-)
(650) 331-3385 x713