[avr-gcc-list] Re: AVR-GCC-list Digest, Vol 15, Issue 15

[Björn Haase]

address@hidden wrote on Dienstag, 18. April 2006 18:07 :
> Send AVR-GCC-list mailing list submissions to
>       address@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
>       http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
> or, via email, send a message with subject or body 'help' to
>       address@hidden
>
> You can reach the person managing the list at
>       address@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of AVR-GCC-list digest..."
>
>
> Today's Topics:
>
>    1. Re: avr-gcc 3.4.3 confused about function pointers (Joerg Wunsch)
>    2. Re: avr-gcc 3.4.3 confused about function pointers (John Regehr)
>    3. Re: avr-gcc 3.4.3 confused about function pointers (Joerg Wunsch)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 17 Apr 2006 22:43:22 +0200 (MET DST)
> From: address@hidden (Joerg Wunsch)
> Subject: Re: [avr-gcc-list] avr-gcc 3.4.3 confused about function
>       pointers
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> John Regehr <address@hidden> wrote:
> > The problematic object code is in OS_BackendM_xx_StdControl_xx_init.
>
> But where's an icall in that?
>
> 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.
>
> > I haven't tried gcc 4.1.0 since it doesn't compile for me.
>
> Why does it not compile for you?  If you're talking about
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26504
>
> first, there is a patch mentioned in the bug tracker, and second, this
> bug only triggers if you configure --with-dwarf2.  If you omit that
> (so you'll get only stabs debugging support), there are no known bugs
> that keep GCC 4.1.0 from compiling.
>
> --
> cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL
>
> http://www.sax.de/~joerg/                        NIC: JW11-RIPE
> Never trust an operating system you don't have sources for. ;-)
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 17 Apr 2006 20:55:48 -0600
> From: John Regehr <address@hidden>
> Subject: Re: [avr-gcc-list] avr-gcc 3.4.3 confused about function
>       pointers
> To: Joerg Wunsch <address@hidden>
> Cc: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
>
> > 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.
>
> 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.
>
> John Regehr
>
>
> struct fseqp_void
> {
>   void (*p) (void);
>   void (*e) (void);
> };
>
> struct fseqp_void c[2];
>
> void bar (void)
> {
> }
>
> void foo (void)
> {
>     int i;
>     for (i=0; i<32; i++);
> }
>
> int main (void)
> {
>   c[0].e = bar + 1;
>   c[0].p = bar;
>   foo ();
>   struct fseqp_void x = c[0];
>   void (*start) (void) = x.p;
>   ((*start)) ();
>   return 0;
> }
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 18 Apr 2006 07:11:21 +0200
> From: Joerg Wunsch <address@hidden>
> Subject: Re: [avr-gcc-list] avr-gcc 3.4.3 confused about function
>       pointers
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> 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.