This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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. :-)

Mark Mitchell
(650) 331-3385 x713

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]