Re: [avr-gcc-list] avr-gcc 3.4.3 confused about function pointers

[Joerg Wunsch]

As John Regehr wrote:

> > Sorry, I can't follow the somewhat tangled logic of that code, so
> > I can't see whether GCC 4.1.0 still produces buggy code for it or
> > not.

> You weren't supposed to follow the logic, it was an automatically
> extracted subset of a machine generated file.

Sure, I assumed that.

> A shorter program that gcc 4.1.0 miscompiles is below.  Compile with
> -Os and the problem should be obvious: the program icalls to the
> byte address of bar() rather than the double-byte address.

I can see it now.  However, I'm not even sure whether GCC is really at
fault here, I'd have to look into the standard.

>   c[0].e = bar + 1;

This is the root of your evil.  You are performing address
calculations on a function pointer address.  Without looking into the
standard, I'd say you can't do that: what is supposed to be "next"
address of a function pointer?  If the standard specifies the result
to be undefined, the compiler's resulting misbehaviour must be
tolerated, and cannot be considered a bug.

The problem here is that this statement obviously confuses the
compiler's address computation logic, and it `forgets' that these
function pointer addresses are actually word addresses that need to be
byte-shifted.  Sure, your +1 address cannot meaningfully be
byte-shifted by one, but subsequently, it also `forgets' this for the
address of bar() itself.

If you omit that nonsensical statement, everything gets fine again.

Things become different if you write it as:

struct fseqp_void
{
  void (*p) (void);
  char *e;
};
...
int main (void)
{
  c[0].e = (char *)bar + 2;
  c[0].p = bar;

This still triggers the bug, but now it's clearly a bug, and I'd say
you should report that one.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)