RE: bug in implementation of __throw in gcc?

[biswapesh dot chattopadhyay at bt dot com]

Hi all

Thanks for your replies. However, it seems to me that all the instructions
and downloads are for the current GCC snapshot. I'm interested in the
testsuite (C and C++) for 2.95.2 - will the current one work ? The reason is
because I'm getting some warnings while compiling simple programs :
-----------------------------------------------------------
/usr/home/swbxc01/cpp>cat hello.cpp
#include <iostream>

int main()
{
  cout << "Hello, World!\n";
}
/usr/home/swbxc01/cpp>g++ -o hello hello.cpp
/var/opt/spool/out/em/biswa/gnu/i386-sequent-sysv4/bin/ld: warning: type and
size of dynamic symbol `__huge_val' are not defi
ned
/usr/home/swbxc01/cpp>
------------------------------------------------------------------

So I was wondering if there is something wrong with the installation. Does
anyone have any idea about what this might mean ?
I configured GCC with --enable-shared --with-gnu-ld --with-gnu-as.

BTW, how do I send the patches that I had to make to make gcc 2.95.2 build
out of the box in Dynix/ptx 4.4.8 ?

Thanks.
Biswa.

> -----Original Message-----
> From: Geoff Keating [mailto:geoffk@geoffk.org]
> Sent: 12 December 2000 19:57
> To: Kevin B. Hendricks
> Cc: gcc@gcc.gnu.org
> Subject: Re: bug in implementation of __throw in gcc?
> 
> 
> 
> Kevin B. Hendricks <kevin.hendricks@sympatico.ca> writes:
> 
> > The libgcc2.c _throw code is:
> > 
> >   /* Now reset pc to the right throw point.  */
> >   pc = __builtin_extract_return_addr 
> (__builtin_return_address (0)) - 1;
> > 
> >   handler = throw_helper (eh, pc, my_udata, &offset);
> > 
> > If I disassemble this code under ppc linux, it shows pc 
> getting decremented 
> > by 1 (not by 4) which makes pc on entry to throw_helper not 
> point to the 
> > address of the __throw but instead to 3 bytes after it.
> > 
> > Is this a bug?  Why use the "-1" here and not -4 (bytes) so 
> that the actual 
> > address of the __throw is in pc as the comments in 
> libgcc2.c indicate they 
> > should for entry to throw_helper.
> 
> This works.  I don't know if it was intentional, but note that on many
> other ports it has the same effect: `pc' points somewhere inside the
> call instruction, not necessarily at its start.
> 
> I think the important thing is that `pc' doesn't point just after the
> end of the call instruction, because that might be the 
> boundary between
> two EH regions.
> 
> -- 
> - Geoffrey Keating <geoffk@geoffk.org>
>