Re: g++.eh/unwind1.C

Re: g++.eh/unwind1.C

[Andrew Macleod]

>> 
>>   In message < 4.2.0.32.19990427161524.03e23150@mail.lauterbach.com >you write:
>>   > Hmm, I thought this was scheduled for 1.2?
>> It was on the list of things we would like to have resolved.  But I think the
>> time has past to try to get the code in.  As I mentioned when I posted that
>> list, it is likely that not everything on the list would be resolved in time
>> for egcs-1.2.
>> 
>> 
>> Sorry.
>> 

As am I. Bug me after we branch 1.2 and we'll make sure its in right after 
that. 

Andrew

g++.eh/unwind1.C

[Mark Mitchell]

This test is failing for me on x86-linux-gnu.  It's possible *I* broke
it, but I don't think so; I've got a compiler with most of my recent
changes in that works.  The problem is that the EH tables contain
wrong information about where to put the stack pointer;
coincidentally, the amount by which they're off is, I think, the size
of the stack frame for the function.  I'm wondering if the recent
leaf-function changes could have had something to do with this?

Here's the code that fails.

-- 
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

--

// Test that unwinding properly restores SP.
// Contributed by Jason Merrill <jason@cygnus.com>

int f (int i)
{
  throw i;
}

int main ()
{  
  void *sp1 = __builtin_alloca (0);

  try
    {
      f (0);
    }
  catch (int)
    {
    }

  void *sp2 = __builtin_alloca (0);

  return (sp1 != sp2);
}

Re: g++.eh/unwind1.C

[Jeffrey A Law]

  In message < 4.2.0.32.19990427161524.03e23150@mail.lauterbach.com >you write:
  > Hmm, I thought this was scheduled for 1.2?
It was on the list of things we would like to have resolved.  But I think the
time has past to try to get the code in.  As I mentioned when I posted that
list, it is likely that not everything on the list would be resolved in time
for egcs-1.2.


Sorry.

jeff
>From chris@ludwig-sun1.unil.ch Wed Apr 28 02:03:00 1999
From: Christian Iseli <chris@ludwig-sun1.unil.ch>
To: law@cygnus.com
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: egcs-ss-19990228, alpha-linux, ICE in glibc-2.1 
Date: Wed, 28 Apr 1999 02:03:00 -0000
Message-id: <199904280901.LAA04097@ludwig-sun1.unil.ch>
References: <26478.924341537@upchuck.cygnus.com>
X-SW-Source: 1999-04/msg00784.html
Content-length: 1171

Dear Jeff,

law@upchuck.cygnus.com said:
>   In message < 199904162027.WAA17429@ludwig-alpha.unil.ch >you write:
>   > I just tried here with 19990412.  Still doesn't work with -O2, but seems
>   > fine with -O.  -fPIC does not seem to make a difference.
>   > 
>   > Did you also try with -O2 ? I tried with the same options that
> caused your test to fail.  That's the only sane way to even start to
> reproduce problems. 

I tried again with egcs-2.93.19 19990418.  This time, the ICE is gone.  Guess 
you had a slightly more recent egcs than the snapshot I tried last...

However, the compilation of glibc-2.1.1pre1 still fails a bit later.  The 
ld.so dynamic loader seems to be miscompiled and segfaults.  What I get during 
the make is:
../elf/ld-linux.so.2 --library-path ..:../math:../elf:../nss:../nis:../db2:../rt:../resolv:../linuxthreads ./rpcgen
 -Y `gcc -print-file-name=cpp | sed "s|/cpp$||"` \
       -c rpcsvc/bootparam.x -o xbootparam.T
make[1]: *** [xbootparam.stmp] Segmentation fault

I tried this both with binutils 2.9.1.0.22b and 2.9.1.0.24.  Same thing.
I can try to dig deeper if it is of any use to you (or others).

Regards,
					Christian

Re: g++.eh/unwind1.C

[Franz Sirl]

At 16:53 27.04.99 , Andrew Macleod wrote:
>>> >
>>> >Shortly after we branch the new release of egcs I think. There's no real
>>> >reason it can't go in. Have you had to make any changes to it, or
>>> >has it been working fine?
>>>
>>> Hmm, I thought this was scheduled for 1.2? At least Jeff had it on the 
>>> list
>>> he posted on the egcs mailinglist. The snapshot you sent me works fine 
>>> with
>>> both 1.1.2 and the current mainline, this means noone has reported a
>>> problem related to it (and egcs-1.1.2) for the whole redhat-6.0 stuff +
>>> some big extra packages like mozilla, ddd, etc. If it's too late for 1.2
>>> now, I would appreciate if you could send me a new snapshot of your EH 
>>> stuff
>
>Hmm, this would be my fault since I didn't realize it was on the
>list and needed to go in. I haven't actually looked at it since I gave it to
>you (I've been sidetracked from EH stuff for a while now).
>
>I guess its Jeffs call on whether its too late, it seems to be pretty
>heavily used by you guys, so its reasonably tested... If he does want
>it to go it, your probably in a better spot to check it in since
>you actively use it.  (And you may have had to add to it)

Damned :-), that's just the situation I wanted to avoid with egcs-1.2. Jeff 
probably won't checkin this patch now that feature freeze is announced. 
This means I have to maintain it as an extra patch again during the whole 
1.2.x cycle :-(.
All the other stuff I have pending for 1.2 are some minor bugfixes in the 
rs6000 backend I will post soon and a solution for the varargs problem on PPC.

Franz.

Re: g++.eh/unwind1.C

[Andrew Macleod]

>> >
>> >Shortly after we branch the new release of egcs I think. There's no real
>> >reason it can't go in. Have you had to make any changes to it, or
>> >has it been working fine?
>> 
>> Hmm, I thought this was scheduled for 1.2? At least Jeff had it on the list 
>> he posted on the egcs mailinglist. The snapshot you sent me works fine with 
>> both 1.1.2 and the current mainline, this means noone has reported a 
>> problem related to it (and egcs-1.1.2) for the whole redhat-6.0 stuff + 
>> some big extra packages like mozilla, ddd, etc. If it's too late for 1.2 
>> now, I would appreciate if you could send me a new snapshot of your EH stuff

Hmm, this would be my fault since I didn't realize it was on the
list and needed to go in. I haven't actually looked at it since I gave it to
you (I've been sidetracked from EH stuff for a while now).

I guess its Jeffs call on whether its too late, it seems to be pretty
heavily used by you guys, so its reasonably tested... If he does want 
it to go it, your probably in a better spot to check it in since 
you actively use it.  (And you may have had to add to it)

Andrew

Re: g++.eh/unwind1.C

[Franz Sirl]

At 16:07 27.04.99 , Andrew Macleod wrote:
>>> >This test is failing for me on x86-linux-gnu.  It's possible *I* broke
>>> >it, but I don't think so; I've got a compiler with most of my recent
>>> >changes in that works.  The problem is that the EH tables contain
>>> >wrong information about where to put the stack pointer;
>>> >coincidentally, the amount by which they're off is, I think, the size
>>> >of the stack frame for the function.  I'm wondering if the recent
>>> >leaf-function changes could have had something to do with this?
>>>
>>> Hmm, I don't get this one on powerpc-linux-gnu
>>> ( http://egcs.cygnus.com/ml/egcs-testresults/1999-04/msg00202.html ). Maybe
>>> this is related to Andrew's EH stuff not completely checked in yet? I
>>> currently use an older snapshot of his work on top of the mainline.
>>> Andrew, when will you check in the rest of your EH stuff?
>>>
>
>Shortly after we branch the new release of egcs I think. There's no real
>reason it can't go in. Have you had to make any changes to it, or
>has it been working fine?

Hmm, I thought this was scheduled for 1.2? At least Jeff had it on the list 
he posted on the egcs mailinglist. The snapshot you sent me works fine with 
both 1.1.2 and the current mainline, this means noone has reported a 
problem related to it (and egcs-1.1.2) for the whole redhat-6.0 stuff + 
some big extra packages like mozilla, ddd, etc. If it's too late for 1.2 
now, I would appreciate if you could send me a new snapshot of your EH stuff.

>One thing to try if you are using sjlj on powerpc is this patch:
>(It remains to be seen what the reason the change originally was made for
>was, but reverting solves this problem. Its also a part of the EHTable patch
>for powerpc too. We're trying to figure out what it is that the original
>removal of this check was trying to fix (Any suggestions are welcome :-):

Hmm, after a testphase I completely switched to DWARF EH for PPC with your 
snapshot, so no more sjlj here. Do you have a testcase to compile with 
-fsjlj-exceptions? And yes, the snapshot you sent me contains the 
get_pool_size() fix for rs6000.md.

Franz.

Re: g++.eh/unwind1.C

[Andrew Macleod]

>> >This test is failing for me on x86-linux-gnu.  It's possible *I* broke
>> >it, but I don't think so; I've got a compiler with most of my recent
>> >changes in that works.  The problem is that the EH tables contain
>> >wrong information about where to put the stack pointer;
>> >coincidentally, the amount by which they're off is, I think, the size
>> >of the stack frame for the function.  I'm wondering if the recent
>> >leaf-function changes could have had something to do with this?
>> 
>> Hmm, I don't get this one on powerpc-linux-gnu 
>> ( http://egcs.cygnus.com/ml/egcs-testresults/1999-04/msg00202.html ). Maybe 
>> this is related to Andrew's EH stuff not completely checked in yet? I 
>> currently use an older snapshot of his work on top of the mainline.
>> Andrew, when will you check in the rest of your EH stuff?
>> 

Shortly after we branch the new release of egcs I think. There's no real 
reason it can't go in. Have you had to make any changes to it, or
has it been working fine?

One thing to try if you are using sjlj on powerpc is this patch:
(It remains to be seen what the reason the change originally was made for
was, but reverting solves this problem. Its also a part of the EHTable patch
for powerpc too. We're trying to figure out what it is that the original 
removal of this check was trying to fix (Any suggestions are welcome :-):

Anyway, it causes r30 to have the wrong value..


*** rs6000.md.bak	Tue Apr 20 11:05:00 1999
--- rs6000.md	Tue Apr 20 10:13:44 1999
***************
*** 10220,10226 ****
  
  (define_insn "nonlocal_goto_receiver"
    [(unspec_volatile [(const_int 0)] 1)]
!   "TARGET_TOC && TARGET_MINIMAL_TOC"
    "*
  {
    rs6000_output_load_toc_table (asm_out_file, 30);
--- 10220,10226 ----
  
  (define_insn "nonlocal_goto_receiver"
    [(unspec_volatile [(const_int 0)] 1)]
!   "TARGET_TOC && TARGET_MINIMAL_TOC && get_pool_size() != 0"
    "*
  {
    rs6000_output_load_toc_table (asm_out_file, 30);
>From oliva@dcc.unicamp.br Tue Apr 27 07:13:00 1999
From: Alexandre Oliva <oliva@dcc.unicamp.br>
To: Lavoie Philippe <lavoie@yoho.genie.uottawa.ca>
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: [might be a bug] Solaris vs Linux template handling
Date: Tue, 27 Apr 1999 07:13:00 -0000
Message-id: <or3e1m6xjg.fsf@lua.lbi.dcc.unicamp.br>
References: <199904261523.LAA01992@yoho.genie.uottawa.ca>
X-SW-Source: 1999-04/msg00757.html
Content-length: 629

On Apr 26, 1999, Lavoie Philippe <lavoie@yoho.genie.uottawa.ca> wrote:

> Is there a switch to automagically compile everything that needs to
> compiles with a -fno-implicit-templates (like egcs1.0 did).

Read about -frepo in the gcc manual, particularly the section about
how to create libraries.  It's in the `Template Instantiation' info
node.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: g++.eh/unwind1.C

[Franz Sirl]

At 09:13 27.04.99 , Mark Mitchell wrote:

>This test is failing for me on x86-linux-gnu.  It's possible *I* broke
>it, but I don't think so; I've got a compiler with most of my recent
>changes in that works.  The problem is that the EH tables contain
>wrong information about where to put the stack pointer;
>coincidentally, the amount by which they're off is, I think, the size
>of the stack frame for the function.  I'm wondering if the recent
>leaf-function changes could have had something to do with this?

Hmm, I don't get this one on powerpc-linux-gnu 
( http://egcs.cygnus.com/ml/egcs-testresults/1999-04/msg00202.html ). Maybe 
this is related to Andrew's EH stuff not completely checked in yet? I 
currently use an older snapshot of his work on top of the mainline.
Andrew, when will you check in the rest of your EH stuff?

Franz.