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

--- Comment #13 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Georg-Johann Lay from comment #9)
> (In reply to Segher Boessenkool from comment #8)
> > That is invalid C code, of course (an out of bounds access).
> What about the other test case
> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59148 ?

Same problem there.  It is not valid C.

> That's from an already existing test case for PR64088, so why has an ICE
> been fixed for that PR instead of closing it as invalid? -- Or ar least
> rejecting that test case?

Many such problems cannot ever be diagnosed by the compiler.  Simple cases like
here could be of course, but in general it is the halting problem.

It is fine to have testcases that are invalid C, if there is no reasonable
other
way to get at the same problems otherwise, but it of course would be a lot
nicer
to have a testcase that is valid C :-)

> Segher, can you suggest how to obtain information (from internal GCC 
> structures) > about such cases ?

I would do something scan-assembler.  I have no idea what instructions
accessing
the frame look like on AVR, but I imagine it won't be too hard to see this?

But I know nothing that can be (or *could* be, even) done that is not
target-specific.  But this testcase is in gcc.target/ anyway, right?

Reply via email to