Bootstrap failure of gcc-ss-20010409 in ia64

Bootstrap failure of gcc-ss-20010409 in ia64

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3205 bytes --]

gcc-ss-20010409 does not bootstrap on ia64:

/bin/sh ../libtool --tag CXX --mode=compile /usr/src/packages/BUILD/gcc-3.0-20010409/obj-ia64-suse-linux/gcc/xgcc -B/usr/src/packages/BUILD/gcc-3.0-20010409/obj-ia64-suse-linux/gcc/ -nostdinc++  -L/usr/src/packages/BUILD/gcc-3.0-20010409/obj-ia64-suse-linux/ia64-suse-linux/libstdc++-v3/src -L/usr/src/packages/BUILD/gcc-3.0-20010409/obj-ia64-suse-linux/ia64-suse-linux/libstdc++-v3/src/.libs -B/usr/ia64-suse-linux/bin/ -B/usr/ia64-suse-linux/lib/ -isystem /usr/ia64-suse-linux/include -nostdinc++ -I../../../../libstdc++-v3/include -I../../../../libstdc++-v3/include/std -I../../../../libstdc++-v3/include/c_std -I../include -I../../../../libstdc++-v3/libsupc++ -I../libio -I../../../../libstdc++-v3/libio -I../../../../libstdc++-v3/libmath     -O2 -fvtable-thunks -D_GNU_SOURCE -fno-implicit-templates  -Wall -Wno-format -W -Wwrite-strings -Winline  -fdiagnostics-show-location=once  -ffunction-sections -fdata-sections  -g    -c ../../../../libstdc++-v3/src/string-inst.cc
/usr/src/packages/BUILD/gcc-3.0-20010409/obj-ia64-suse-linux/gcc/xgcc -B/usr/src/packages/BUILD/gcc-3.0-20010409/obj-ia64-suse-linux/gcc/ -nostdinc++ -L/usr/src/packages/BUILD/gcc-3.0-20010409/obj-ia64-suse-linux/ia64-suse-linux/libstdc++-v3/src -L/usr/src/packages/BUILD/gcc-3.0-20010409/obj-ia64-suse-linux/ia64-suse-linux/libstdc++-v3/src/.libs -B/usr/ia64-suse-linux/bin/ -B/usr/ia64-suse-linux/lib/ -isystem /usr/ia64-suse-linux/include -nostdinc++ -I../../../../libstdc++-v3/include -I../../../../libstdc++-v3/include/std -I../../../../libstdc++-v3/include/c_std -I../include -I../../../../libstdc++-v3/libsupc++ -I../libio -I../../../../libstdc++-v3/libio -I../../../../libstdc++-v3/libmath -O2 -fvtable-thunks -D_GNU_SOURCE -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -c ../../../../libstdc++-v3/src/string-inst.cc  -fPIC -DPIC -o .libs/string-inst.o
../../../../libstdc++-v3/include/bits/basic_string.tcc: In copy constructor 
   `std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const 
   std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = 
   std::char_traits<char>, _Alloc = std::allocator<char>]':
../../../../libstdc++-v3/include/bits/basic_string.tcc:187:   instantiated from `std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]'
../../../../libstdc++-v3/src/string-inst.cc:48:   instantiated from here
../../../../libstdc++-v3/include/bits/basic_string.tcc:187: Internal compiler 
   error in add_abstract_origin_attribute, at dwarf2out.c:9234
Please submit a full bug report, with preprocessed source if appropriate.
See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Jim Wilson]

In article < jezodny1za.fsf@hawking.suse.de > you write:
>gcc-ss-20010409 does not bootstrap on ia64:

This was introduced by a C++ front end change by Mark Mitchell on March 28.
See < http://gcc.gnu.org/ml/gcc-bugs/2001-04/msg00081.html >.  See also
< http://gcc.gnu.org/ml/gcc-bugs/2001-03/msg00879.html > from Alan Modra
reporting the same bug for other targets.  I believe all DWARF2 targets are
broken at the moment.

Jim

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Mark Mitchell]

>>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:

    Jim> http://gcc.gnu.org/ml/gcc-bugs/2001-04/msg00081.html

I didn't see you're original posting, but I saw this one.

I'll look into it.

Thanks,

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

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Mark Mitchell]

>>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:

    Jim> This was introduced by a C++ front end change by Mark
    Jim> Mitchell on March 28.  See
    Jim> < http://gcc.gnu.org/ml/gcc-bugs/2001-04/msg00081.html >.  See
    Jim> also < http://gcc.gnu.org/ml/gcc-bugs/2001-03/msg00879.html >
    Jim> from Alan Modra reporting the same bug for other targets.  I
    Jim> believe all DWARF2 targets are broken at the moment.

Jim --

  I tried adding -gdwarf-2 to the command-line on i686-pc-linux-gnu,
but I didn't see any problems with the stock 3.0 branch.

  I will try Alan's .ii file, which is apparently different from the
checked-in version.  (But, of course, if the problem is related to the
difference, then people shouldn't be seeing this elsewhere.)

  If you send me the usual (target triplet, preprocessed source,
cc1plus command-line flags) I will try to figure it out.

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

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Daniel Berlin]

Mark Mitchell <mark@codesourcery.com> writes:

> >>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:
> 
>     Jim> This was introduced by a C++ front end change by Mark
>     Jim> Mitchell on March 28.  See
>     Jim> < http://gcc.gnu.org/ml/gcc-bugs/2001-04/msg00081.html >.  See
>     Jim> also < http://gcc.gnu.org/ml/gcc-bugs/2001-03/msg00879.html >
>     Jim> from Alan Modra reporting the same bug for other targets.  I
>     Jim> believe all DWARF2 targets are broken at the moment.
> 
> Jim --
> 
>   I tried adding -gdwarf-2 to the command-line on i686-pc-linux-gnu,
> but I didn't see any problems with the stock 3.0 branch.

I also constantly use dwarf2 with C++, since i'm finishing up moving
some stuff from a GDB in C++ rewrite back to GDB, like location
expression evaluation at runtime, using the call frame info, redoing
some of the symbol structures, etc.

I can say for a certainty that all DWARF2 targets are not broken, in
the general case.  
I can also say for a certainty that they are also outputting proper
location expressions, even for complex cases.

Unless, of course, you have the -feliminate-dwarf2-dups flag
somewhere. It's currently outputting broken dwarf2.  It does't create
references to dies in another CU properly all the time. It ends up
getting the offset right, but in the wrong place (IE it's saying it's
at an offset in the current compilation unit, when it it's at that
offset in *another* compilation unit).  forcing it to use absolute die
references for everything fixes the problem, so it's certainly just
not marking something properly (It attempts to mark all the dies in
the current CU to figure out which are referencing things in other
CU's) , or something of the sort.


> 
>   I will try Alan's .ii file, which is apparently different from the
> checked-in version.  (But, of course, if the problem is related to the
> difference, then people shouldn't be seeing this elsewhere.)
> 
>   If you send me the usual (target triplet, preprocessed source,
> cc1plus command-line flags) I will try to figure it out.
> 

Ahh, actually, i think i know what's causing this.

Reordering the blocks and inlining is causing us to come across a type
or declaration, before we normally would (IE where "normal" is the
place where we generate
the type/decl die.)
This happens with templates and inlining, (or at least, it's the only
cases i've ever seen it happening), particularly with inlined
templated class members.
So it goes to add the abstract origin of the die, it tries to lookup
the decl/type of the origin, which we don't have.  I don't know if
this *should* ever happen, but it does.  So it aborts.  It's likely the cause is that
we are deferring outputting whatever the real origin is, but not the
actual inlined copy.  So when it goes to output the debug info, it
hits an inlined copy, with an origin that it hasn't processed yet, and
thus, doesn't have the die for in it's tables.


A quick fix would be to call gen_decl_die/gen_type_die if the lookups
fail, rather than aborting.
This is correct if the behavior above is correct.



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

-- 
In my house there's this light switch that doesn't do anything.
Every so often I would flick it on and off just to check.
Yesterday, I got a call from a woman in Germany.  She said, "Cut
it out."

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Mark Mitchell]

Thanks for the analysis.

It's certainly the case that we now try to output an inlined instance
of a function without having first shown the back end the un-inlined
instance.  In my opinion, that's a good thing -- there's no need for
it to know about anything except what we want it to know about.

However, the debug-generation routines need to be able to cope with
that.  If you can reproduce Jim's problem, maybe you could help him
with the solution?  I've asked him privately to look into it as
quickly as possible -- as a favor to me, the bug-causer -- since it
does apparently affect GCC 3.0 bootstraps on some targets.  If you
were willing to help, that would be great.

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

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Daniel Berlin]

[-- Attachment #1: Type: text/plain, Size: 2217 bytes --]

Mark Mitchell <mark@codesourcery.com> writes:

> Thanks for the analysis.
> 
> It's certainly the case that we now try to output an inlined instance
> of a function without having first shown the back end the un-inlined
> instance.  In my opinion, that's a good thing -- there's no need for
> it to know about anything except what we want it to know about.
> 
> However, the debug-generation routines need to be able to cope with
> that. 

Yes. In fact, the reason i knew about this was because i ran into a
similar problem working up a patch to use the correct virtual context for virtual
functions (since it's now DECL_VIRTUAL_CONTEXT, not DECL_CONTEXT). We
would end up seeing virtual function calls before seeing the type they
came from, go to lookup the type die, which wouldn't exist, and
segfault.  The correct fix, is, of course, to generate the die if it
doesn't exist, not segfault.

> If you can reproduce Jim's problem, maybe you could help him
> with the solution?  

The attached patch should actually fix it, even though i haven't been able to
reproduce it on my platforms.

I can't even fathom another explanation for this bug, given it doesn't
occur if you turn off inlining, this is the only abort in the area,
etc.

There are probably a few other places like this case, that need to be
fixed in the same way (IE it's likely you may see a similar type of
abort or a segfault because of a null value passed somewhere that
originated from a lookup of a die or decl)

A lot of things don't bother to check if the lookup_{decl,type_die}
failed.  At least add_abstract_origin was checking the return value
and aborting.

(add_pure_or_virtual_attribute does the same thing when you give it
the correct virtual context sometimes,because without checking,
it just passes the result along to anothner function, which promptly
crashes trying to deref a null pointer
it segfaults in the same type of situation, when you hit a type you
haven't hit in the "normal way" first.)
> I've asked him privately to look into it as
> quickly as possible -- as a favor to me, the bug-causer -- since it
> does apparently affect GCC 3.0 bootstraps on some targets.  If you
> were willing to help, that would be great.
> 



[-- Attachment #2: attrdiff --]
[-- Type: text/x-diff, Size: 876 bytes --]

Index: dwarf2out.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/dwarf2out.c,v
retrieving revision 1.262
diff -c -3 -p -w -B -b -r1.262 dwarf2out.c
*** dwarf2out.c	2001/04/05 01:43:17	1.262
--- dwarf2out.c	2001/04/12 03:13:17
*************** add_abstract_origin_attribute (die, orig
*** 8537,8545 ****
--- 8531,8553 ----
      }
  
    if (DECL_P (origin))
+     {
      origin_die = lookup_decl_die (origin);
+     if (origin_die == NULL)
+       {
+ 	gen_decl_die (origin, die->die_parent);
+ 	origin_die = lookup_decl_die (origin);
+       }
+     }
    else if (TYPE_P (origin))
+     {
+       origin_die = lookup_type_die (origin);
+       if (origin_die == NULL)
+ 	{
+ 	  gen_type_die (origin, die->die_parent);
  	  origin_die = lookup_type_die (origin);
+ 	}
+     }
    
    if (origin_die == NULL)
      abort ();

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Mark Mitchell]

Daniel -

  Thanks for the patch.

Jim -- 

  Would you mind trying out Daniel's patch?

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

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Daniel Berlin]

Mark Mitchell <mark@codesourcery.com> writes:

> Daniel -
> 
>   Thanks for the patch.
> 
> Jim -- 
> 
>   Would you mind trying out Daniel's patch?

Please note the patch might not work in all cases, but it should still
get you past the point you are at now, and if it does, i'll submit a
correct patch.

I'm *assuming* the correct place to put the generated decl/type die is
the parent of whatever you passed in. Really, we need an extra
argument to add_abstract_origin_attribute that is the context to place
the decl/type dies we may generate.

This is pretty trivial, it just didn't occur to me until I remembered
you could have nested inlines, or other cases where you want to place
it in some other scope than the parent of the DIE we are
generating the abstract attribute for.

If the patch works, i'll work up a correct version.

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

-- 

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Bill Nottingham]

Daniel Berlin <dan@cgsoftware.com> said:
>Mark Mitchell <mark@codesourcery.com> writes:
>Please note the patch might not work in all cases, but it should still
>get you past the point you are at now, and if it does, i'll submit a
>correct patch.

It doesn't here, in brief testing - it still dies at the same place:

/space/ook/gcc-foo/gcc/gcc/xgcc -B/space/ook/gcc-foo/gcc/gcc/ -nostdinc++
-L/space/ook/gcc-foo/gcc/ia64-unknown-linux/libstdc++-v3/src
-L/space/ook/gcc-foo/gcc/ia64-unknown-linux/libstdc++-v3/src/.libs
-B/usr/local/foo/ia64-unknown-linux/bin/
-B/usr/local/foo/ia64-unknown-linux/lib/ -isystem
/usr/local/foo/ia64-unknown-linux/include -nostdinc++ -I../include
-I../include/std -I../include/c_std -I../include -I../libsupc++ -I../libio
-I../libio -I../libmath -g -O2 -fvtable-thunks -D_GNU_SOURCE
-fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -c
string-inst.cc  -fPIC -DPIC -o .libs/string-inst.o
../include/bits/basic_string.tcc: In copy constructor 
   std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const 
   std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = 
   std::char_traits<char>, _Alloc = std::allocator<char>]':
../include/bits/basic_string.tcc:187:   instantiated from
   std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const
   std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char,
   _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]'
string-inst.cc:48:   instantiated from here
../include/bits/basic_string.tcc:187: Internal compiler error in  add_abstract_origin_attribute, at dwarf2out.c:9261
Please submit a full bug report, with preprocessed source if appropriate.
See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.
	    
Do you need more info?

Bill

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Jim Wilson]

I applied the patch by hand to the gcc trunk.  It didn't apply automatically,
I don't know why.  I did a make all, and libstdc++ built without error.
Not too surprising, because the patch is creating the missing dies at the
point where we notice that they are missing.  It isn't obvious that this is
the right fix, but Dan's explanation is pretty convincing, so it sounds like
this is the right approach.

Jim

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Daniel Berlin]

Bill Nottingham <notting@redhat.com> writes:

> Daniel Berlin <dan@cgsoftware.com> said:
> >Mark Mitchell <mark@codesourcery.com> writes:
> >Please note the patch might not work in all cases, but it should still
> >get you past the point you are at now, and if it does, i'll submit a
> >correct patch.
> 
> It doesn't here, in brief testing - it still dies at the same place:
> 


> Do you need more info?

Yes, I need to know what the locals and args look like in gcc when it crashes.


Using alan's test file on the same bug report, i am unable to
reproduce at all.

Umm, actually, are you sure you applied the patch?

The abort location should be moved down a few lines, yet it's claiming
an ICE at the exact same location it did before (there is no other
abort() in that routine).


> 
> Bill

-- 
I installed a skylight in my apartment....  The people who live
above me are furious!

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Daniel Berlin]

Jim Wilson <wilson@cygnus.com> writes:

> I applied the patch by hand to the gcc trunk.  It didn't apply automatically,
> I don't know why.  

Probably my fault, I had to hand edit out an irrelevant change or two, related to
trying to get dwarf2 elimination working again.  I must have accidently
removed one line too many.
I checked out a new copy to do the work to make the patch work all the
time, so it shouldn't happen again.
> I did a make all, and libstdc++ built without error.
> Not too surprising, because the patch is creating the missing dies at the
> point where we notice that they are missing.  It isn't obvious that this is
> the right fix, but Dan's explanation is pretty convincing, so it sounds like
> this is the right approach.

Well, Mark says this *can* happen, in normal cases, so IMHO, it's the
right thing to do. There's certainly no other way around it than to
create the DIE's, they must exist to be able to set the attribute :).


I'll make the patch put the decl's and type's in the right place all
the time, and
submit it.

> 
> Jim

-- 
The other day, I was walking my dog around my building...  on
the ledge.  Some people are afraid of heights.  Not me, I'm
afraid of widths.

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Bill Nottingham]

(restating some stuff from private mail)

Daniel Berlin <dan@cgsoftware wrote:
>Umm, actually, are you sure you applied the patch?
>
>The abort location should be moved down a few lines, yet it's claiming
>an ICE at the exact same location it did before (there is no other
>abort() in that routine).

Yup, I did apply the patch; I can confirm with this patch in head
I can build libstdc++-v3 OK; but it still fails for me on the
3.0 branch in the same place.

Bill

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Daniel Berlin]

Bill Nottingham <notting@redhat.com> writes:

> (restating some stuff from private mail)
> 
> Daniel Berlin <dan@cgsoftware wrote:
> >Umm, actually, are you sure you applied the patch?
> >
> >The abort location should be moved down a few lines, yet it's claiming
> >an ICE at the exact same location it did before (there is no other
> >abort() in that routine).
> 
> Yup, I did apply the patch; I can confirm with this patch in head
> I can build libstdc++-v3 OK; but it still fails for me on the
> 3.0 branch in the same place.

Hmmmm.

Odd.

Can you capture all the output of a gdb session ("script", for instance,
would be fine for this kind of capturing) that just loads cc1,
runs it on the preprocessed file till the abort, goes up to the
add_abstract_origin frame, runs info locals, and
send it to me?

I should be able to determine what's up from that.

The only thought that comes to me is that either the context is wrong
on the generated die (which i know, is the part i need to fix), and
for some reason it can find it on the branch, but not the head, or
that decl_ultimate_origin is giving us a NULL decl, screwing us since
we'll just not generate a die, even if we tell it to.


> 
> Bill

-- 
I can levitate birds.  No one cares.

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

Daniel Berlin <dan@cgsoftware.com> writes:

|> The attached patch should actually fix it, even though i haven't been able to
|> reproduce it on my platforms.

It does not change anything.  lookup_decl_die still returns NULL after
gen_decl_die has been called.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Daniel Berlin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1764 bytes --]

Andreas Schwab <schwab@suse.de> writes:

> Daniel Berlin <dan@cgsoftware.com> writes:
> 
> |> The attached patch should actually fix it, even though i haven't been able to
> |> reproduce it on my platforms.
> 
> It does not change anything.  lookup_decl_die still returns NULL after
> gen_decl_die has been called.

It does work on the HEAD, probably due to another bugfix somewhere else.  The likely cause for not working on the
branch is that gen_decl_die isn't doing anything.

This happens if the DECL is marked to be ignored, or it's an ERROR_MARK,
or it's a CONST_DECL (an enum), etc.

In fact, diffing the HEAD dwarf2out against the branch shows me there
are only two changes in the way we generate dies, neither of which
would have any affect whatsoever on this bug.

Looking at the changelogs between the head and the branch, and based
on timing,  A random guess as to what made this start working on the
head, is a 2001-03-21 change by Jason (look at the head cp/ChangeLog) that involved changing a few
things about templates.

I can guarantee you the real bug isn't in dwarf2out (once you have the
patch installed), because if we aren't generating the decl die,
something is set wrong, somewhere.

Can you see why gen_decl_die isn't generating the die? (IE what case
it's breaking/returning on)  This should give you a large clue as to
what is wrong.

--Dan




> 
> Andreas.
> 
> -- 
> Andreas Schwab                                  "And now for something
> SuSE Labs                                        completely different."
> Andreas.Schwab@suse.de
> SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
> Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

-- 
Factorials were someone's attempt to make math *look* exciting.

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1735 bytes --]

Daniel Berlin <dan@cgsoftware.com> writes:

|> Can you see why gen_decl_die isn't generating the die? (IE what case
|> it's breaking/returning on)  This should give you a large clue as to
|> what is wrong.

The condition `(class_scope_p (context_die) || DECL_ABSTRACT (decl))' in
gen_variable_die is false (context_die.die_tag == DW_TAG_subprogram).
This is the value of decl:

 <var_decl 0x2000000000b07d80 __exception_info
    type <pointer_type 0x2000000000529740
        type <record_type 0x2000000000529680 cp_eh_info asm_written type_5 BLK
            size <integer_cst 0x20000000004d6a00 constant 512>
            unit size <integer_cst 0x2000000000456ac0 constant 64>
            user align 64 symtab 2411472 alias set -1 fields <field_decl 0x2000000000529800 eh_info>
            n_parents 0 use_template=0 interface-unknown
            pointer_to_this <pointer_type 0x2000000000529740> chain <type_decl 0x2000000000529e00 cp_eh_info>>
        unsigned asm_written DI
        size <integer_cst 0x2000000000305a40 constant 64>
        unit size <integer_cst 0x2000000000305a70 constant 8>
        align 64 symtab 2416272 alias set -1>
    unsigned used DI file /cvs/snapshot/gcc/libstdc++-v3/include/bits/basic_string.h line 189 size <integer_cst 0x2000000000305a40 64> unit size <integer_cst 0x2000000000305a70 8>
    align 64 context <function_decl 0x2000000000c22f40 _M_refcopy> initial <call_expr 0x2000000000b01500>>


Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Daniel Berlin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]

Andreas Schwab <schwab@suse.de> writes:

> Daniel Berlin <dan@cgsoftware.com> writes:
> 
> |> Can you see why gen_decl_die isn't generating the die? (IE what case
> |> it's breaking/returning on)  This should give you a large clue as to
> |> what is wrong.
> 
> The condition `(class_scope_p (context_die) || DECL_ABSTRACT (decl))' in
> gen_variable_die is false (context_die.die_tag == DW_TAG_subprogram).
> This is the value of decl:

Oh, then this is because it's putting the die in the wrong context,
which is the thing i said was wrong with the patch.

Doh.

Change the gen_decl_die (origin, die->die_parent) to dwarf2out_decl
(origin), and see if it goes away.

> 
> Andreas.
> 
> -- 
> Andreas Schwab                                  "And now for something
> SuSE Labs                                        completely different."
> Andreas.Schwab@suse.de
> SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
> Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

-- 
I went to the hardware store and bought some used paint.  It was
in the shape of a house.  I also bought some batteries, but they
weren't included.  So I had to buy them again.

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 561 bytes --]

Daniel Berlin <dan@cgsoftware.com> writes:

|> Change the gen_decl_die (origin, die->die_parent) to dwarf2out_decl
|> (origin), and see if it goes away.

That didn't help either.  context_die.die_tag is now DW_TAG_compile_unit,
but no difference otherwise.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Daniel Berlin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]

Andreas Schwab <schwab@suse.de> writes:

> Daniel Berlin <dan@cgsoftware.com> writes:
> 
> |> Change the gen_decl_die (origin, die->die_parent) to dwarf2out_decl
> |> (origin), and see if it goes away.
> 
> That didn't help either.  context_die.die_tag is now DW_TAG_compile_unit,
> but no difference otherwise.

Darn it, this sucks.
It thinks it's not a declaration, so it never equates the number.

I'm curious, in gen_variable_die, is the local "declaration" getting
set to 1?
If so, modify the class_scope_p test that before
equate_decl_number_with_die to 
if (declaration || DECL_ABSTRACT (decl)) 
        equate_decl_number_to_die (decl, var_die);


At least we know why it doesn't happen in the head, however.
It's because the exception handling stuff changed, so we don't hit
this particular type anymore.

        
> 
> Andreas.
> 
> -- 
> Andreas Schwab                                  "And now for something
> SuSE Labs                                        completely different."
> Andreas.Schwab@suse.de
> SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
> Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

-- 
I went to the cinema, and the prices were:  Adults $5.00,
children $2.50.  So I said, "Give me two boys and a girl."

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

Daniel Berlin <dan@cgsoftware.com> writes:

|> I'm curious, in gen_variable_die, is the local "declaration" getting
|> set to 1?

No.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Jim Wilson]

My work on the IA-64 port has been hampered lately because I've been running
into too many different regressions all at the same time.  I found four
serious regressions all at about the same time.  Disentagling all of the
problems has been hard.
1) The trunk was broken by Richard's large C++ EH/Unwind API patch which went
   in without any IA-64 support.  This caused builds to break early, during
   the stage1 gcc build.  This patch did not go on the branch.  This was fixed
   by hacking the trunk to use setjmp/longjmp EH for IA-64, which is something
   that still needs to be fixed.  Hopefully the same breakage won't go on the
   branch when this patch gets moved to the branch.  If so, that will make
   use of the gcc3 branch undesirable for IA-64 C++ code.
2) The branch was broken by your patch to throttle C++ inlining.  This patch
   went on both the trunk and the branch.  This caused builds to fail late,
   during the target libstdc++ build.  At the time, I assumed both the branch
   and trunk were broken because of this patch, but that I couldn't see the
   problem on the trunk because of the large C++ EH patch.  That seems to be
   mistaken as I haven't been able to reproduce the problem on the trunk.
3) I discovered that debugging binaries built by gcc no longer worked right.
   If I use the assembler that comes with my OS release, gdb reports the right
   line number but the wrong filename when debugging a stage2 cc1plus on the
   trunk.  This makes debugging difficult, but still possible.  If I try the
   binutils 2.11 assembler, I get gdb segfaults debugging a stage2 cc1plus on
   the trunk.  This make debugging impossible.  This has forced me to build
   stage1 cc1plus binaries to be able to debug C++ testcases.  I suspect this
   is related to the dwarf2out.c file table changes in gcc and binutils by
   Richard et al.  I also see similar problems on the gcc3 branch.
4) An IA-64 backend patch I wrote to fix a linux kernel miscompilation problem
   triggered a latent assembler problem.  This was discovered after binutils
   2.11. has been released.  This forces me to use an up-to-date assembler for
   gcc builds now.  Unfortunately, using an up-to-date assembler exacerbates
   the above problem #3.

It will take some time for me to get all of these problems resolved.

For the moment, just concentrating on the one problem that you are asking
about, problem #2...

The problem is easy to reproduce on the branch.  We get the dwarf2out.c
abort when compiling libstdc++.  I can reproduce this with a native ia64-linux
compiler, and with a cross from x86-linux to ia64-linux.  I haven't been able
to reproduce the problem on the trunk.  I checked out a copy of the trunk
using -D"March 27, 2001", which includes your C++ throttling patch, but none
of Richard's C++ EH/Unwind API patch.  The problem does not show up there.
So my earlier comment about Dan's patch working on the trunk should be
disregarded.

Curiously, the testcase does not fail with a native x86-linux compiler.
That may be because of the IA-64 built-in function used by the testcase, or
it may be because an optimization pass (like reorder-blocks) is changing
the decls in a machine dependent way that only causes the problem to show
up for some targets.

The testcase fails on the branch because of the __exception_info symbol.
This disappears with Richard's patch, thus there is a chance that the problem
will go away when Richard's patch goes on the branch.  Interestingly, this
symbol is still present on the trunk in the March 27 tree I checked out, but
the problem does not show up there.  Hence I suspect that it is just an
accident that the problem is showing up with this symbol on the branch, and
that Richard's patch won't actually make the problem go away, but rather will
just make it a latent problem.  The real problem is probably elsewhere, though
it could be in any of the C++ front end, the dwarf2out.c file, the IA-64
back-end, or in the optimizer.

At the moment, I haven't spent any significant time debugging dwarf2out
to see if I can identify the problem.  I'm very close to finishing problem
#4, the linux kernel miscompilation and latent assembler bug.  After I resolve
these problems, I will spend some more time looking into the dwarf2out.c
abort.  I will also have to look at the dwarf2 file table problem sometime
soon.  Not being able to debug stage2/stage3 gcc binaries makes it hard to
work on build failures, so this is also a serious problem even though it
doesn't cause an obvious build failure.

I did spend some time creating a smaller testcase to make the problem easier
to debug.  The following testcase is 86 lines, and aborts in dwarf2out.c
for an ia64-linux target when compiled with -O2 -S -g.   This testcase can
probably be reduced even further, but I was at the point of diminishing
returns, plus I have limited C++ knowledge and wasn't sure how to simplify
some parts of the testcase.

template<class _CharT>
struct char_traits;

template<typename _Alloc>
class allocator;

template<typename _CharT, typename _Traits = char_traits<_CharT>,
  typename _Alloc = allocator<_CharT> >
class basic_string;

template <class _Tp>
class allocator {
public:
  ~allocator() throw() {}
};

static inline void
__attribute__ ((__unused__))
__atomic_add (int* __mem, int __val)
{
  __sync_fetch_and_add_si (__mem, __val);
}

template<typename _CharT, typename _Traits, typename _Alloc>
class basic_string
{
public:
  typedef _Alloc allocator_type;

private:
  struct _Rep
  {
    int _M_references;

    bool
    _M_is_leaked() const
    { return _M_references < 0; }

    _CharT*
    _M_refdata() throw()
    { return reinterpret_cast<_CharT*> (this + 1); }

    _CharT*
    _M_grab(const _Alloc& __alloc1, const _Alloc& __alloc2)
    { return (!_M_is_leaked()) ? _M_refcopy() : _M_clone(__alloc1); }

    _CharT*
    _M_refcopy() throw()
    {
      __atomic_add(&_M_references, 1);
      return _M_refdata();
    }

    _CharT*
    _M_clone(const _Alloc&);
  };

  struct _Alloc_hider : _Alloc
  {
    _Alloc_hider(_CharT* __dat, const _Alloc& __a)
      : _Alloc(__a), _M_p(__dat) { }

    _CharT* _M_p;
  };

  mutable _Alloc_hider _M_dataplus;

  _CharT*
  _M_data() const
  { return _M_dataplus._M_p; }

  _Rep*
  _M_rep() const
  { return &((reinterpret_cast<_Rep*> (_M_data()))[-1]); }

public:
  basic_string(const basic_string& __str);
};

template<typename _CharT, typename _Traits, typename _Alloc>
basic_string<_CharT, _Traits, _Alloc>::
basic_string(const basic_string& __str)
  : _M_dataplus(__str._M_rep()->_M_grab(_Alloc(), _Alloc ()), _Alloc ())
{ }

template class basic_string<char>;

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Jim Wilson]

It appears that entropy still has the upper hand.  I have to add another item
to the list

5) libffi fails to build.  It seems that this has been broken for a while,
   but did not show up because libffi wasn't getting configured.  Now that it
   gets configured, it causes obvious build failures.  However, it isn't
   obvious why it is getting configured now when it didn't use to be.

Jim

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Jim Wilson]

My libffi problems are because it has been too long since I last did a cvs co
on my main gcc tree.  I normally just do a cvs update, but that doesn't give
you new directories.  After doing a cvs co to get new directories, libffi now
configures and builds as it should.  There are two libffi build problems, but
both are trivial to fix.  I have patches for both, but have not tested them
yet.

Meanwhile, I've spent about 4 hours looking at the dwarf2out.c abort.
Mostly all I accomplished was to remember how it works, but I did learn a
few things.

The problem is with <var_decl 0x401f4ea0 __exception_info> which is nested
inside a base_ctor function.  This var_decl has an abstract origin of
<var_decl 0x401d5f08 __exception_info> which has a context of
<function_decl 0x401b8ea0 _M_refcopy>.  When we try to add an abtract_origin
attribute pointing at the 0x401d5f08 decl, we first call dwarf2out_abstract_
function on _M_refcopy.  Unfortunately, there is no __execption_info var_decl
inside the _M_refcopy block tree, and thus we still have no origin_die, and
we hit the abort.  This is definitely fishy.  We have a decl that claims to
be inside a function, but the function claims to not know anything about the
decl.  I will have to investigate this further.

I can throw out a few wild guesses though, based on the fact that the problem
goes away when -freorder-blocks is turned off.
a) We generate a M_refcopy function that contains a __exception_info variable.
   We inline this into another function, generating an exception_info var
   with an abstract origin pointing back to us.  We then optimize and emit
   M_refcopy, and in the process of doing so, the block tree is modified such
   that the exception_info variable no longer exists.  We then later try to
   emit debug info for the inlinee, and we find a decl whose abstract origin
   no longer exists.  This problem does not exist with the RTL inliner, because
   we make a copy of the inline function before optimizing and emitting it,
   and hence all abstract origin pointers back to us remain valid.
b) We generate a M_refcopy function that does not contain a __exception_info
   variable.  We inline this into another function that does contain an
   _exception_info variable in other blocks.  We then optimize and emit the
   inlinee, and in the process of doing so we modify the block tree in such
   a way that we now have an exception_info variable inside the inlined
   M_refcopy function.  We we try to look for it inside the M_refcopy function
   we can't find it, and we end up aborting.

'b' seems pretty unlikely, as that would require that a DECL_CONTEXT field
get clobbered, and I don't think that -freorder-blocks can do that.  'a' seems
plausible though.

By the way, -freorder-blocks is known to have at least one other seriously
bad interaction with dwarf2out.c.  See 
	http://gcc.gnu.org/ml/gcc-bugs/2001-03/msg00434.html
This problem causes ia64-linux glibc build failures unless either -g or
-freorder-blocks is turned off.  This same problem has also been reported for
other linux systems, see the links at the bottom of the above message.

If the current problem is also a -freorder-blocks/dwarf2 interaction problem,
then perhaps -freorder-blocks shouldn't be on by default.

Jim

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Sam TH]

On Sat, Apr 14, 2001 at 02:01:13AM -0700, Jim Wilson wrote:
> My libffi problems are because it has been too long since I last did a cvs co
> on my main gcc tree.  I normally just do a cvs update, but that doesn't give
> you new directories.  After doing a cvs co to get new directories, libffi now

You do know about cvs update -P, right?  That gives you new
directories too.  
           
sam th --- sam@uchicago.edu --- http://www.abisource.com/~sam/
OpenPGP Key: CABD33FC --- http://samth.dyndns.org/key
DeCSS: http://samth.dyndns.org/decss

-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE62DI8t+kM0Mq9M/wRAgAxAKCySRe9WopP1hrPNAN9Thh6JHiwLwCgpXGb
M3Z+pHM91WnwlyJRRmm0T2o=
=lBk7
-----END PGP SIGNATURE-----

cvs (was: Bootstrap failure of gcc-ss-20010409 in ia64)

[Fergus Henderson]

On 14-Apr-2001, Sam TH <sam@uchicago.edu> wrote:
> On Sat, Apr 14, 2001 at 02:01:13AM -0700, Jim Wilson wrote:
> > My libffi problems are because it has been too long since I last did a cvs co
> > on my main gcc tree.  I normally just do a cvs update, but that doesn't give
> > you new directories.  After doing a cvs co to get new directories, libffi now
> 
> You do know about cvs update -P, right?  That gives you new
> directories too.  

I think you mean `-d'.  `-P' is for pruning empty directories.
But yes, generally it's a very good idea to put 

	update -d -P

in your ~/.cvsrc, so that you use `-d' and `-P' by default.
The defaults that cvs uses for many commands are not ideal, and in my
experience it's usually best to use a .cvsrc such as the one attached
to override them.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: cvs (was: Bootstrap failure of gcc-ss-20010409 in ia64)

[Sam TH]

On Sun, Apr 15, 2001 at 01:27:49AM +1000, Fergus Henderson wrote:
> On 14-Apr-2001, Sam TH <sam@uchicago.edu> wrote:
> > On Sat, Apr 14, 2001 at 02:01:13AM -0700, Jim Wilson wrote:
> > > My libffi problems are because it has been too long since I last did a cvs co
> > > on my main gcc tree.  I normally just do a cvs update, but that doesn't give
> > > you new directories.  After doing a cvs co to get new directories, libffi now
> > 
> > You do know about cvs update -P, right?  That gives you new
> > directories too.  
> 
> I think you mean `-d'.  `-P' is for pruning empty directories.

Doh.  But yeah, put both in your .cvsrc, and forget about it.  

           
sam th --- sam@uchicago.edu --- http://www.abisource.com/~sam/
OpenPGP Key: CABD33FC --- http://samth.dyndns.org/key
DeCSS: http://samth.dyndns.org/decss

-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE62Jl2t+kM0Mq9M/wRAhWKAJ9/w7VozGoOk2lDgaHT/NP6VPnbJQCfWETR
DxvOpLH1AjFnX1ocfOVAZUU=
=7H2t
-----END PGP SIGNATURE-----

Re: cvs (was: Bootstrap failure of gcc-ss-20010409 in ia64)

[Jim Wilson]

> 	update -d -P

I'm aware of -d, but it isn't appropriate for all cases.  

If you used a module to check out a subset of a repository, then using update
-d will give you files that were not part of the module that you checked out.
This isn't really a problem with the FSF gcc repository, since the gcc module
is the entire repository.  It is a problem for other repositories that I use,
for instance the combined gdb/binutils repository on sources.redhat.com.  If
I check out the binutils module, and then update it, I don't want update to
check out gdb files.  Thus I can't use -d.

Also, -d gives you new directories, but it doesn't give you new files.
This matters if you checked out a module that includes specific filenames
in addition to directory names.  If someone later modifies the module to
include additional filenames, then update -d will not give you those additional
filenames.  This isn't a problem for the FSF gcc repository, since we aren't
using modules that way, but it is a problem for other repositories that I use.

Neither problem exists if you use co instead of update.  Thus it is always
better to use co instead of update -d.  However, this does require you to
remember to do a co occasionally.  For people that don't use as many CVS
features I do, which is probably most people, update -d will work fine.

Jim

Re: cvs (was: Bootstrap failure of gcc-ss-20010409 in ia64)

[Russ Allbery]

Jim Wilson <wilson@cygnus.com> writes:

> Neither problem exists if you use co instead of update.  Thus it is
> always better to use co instead of update -d.

Last time I tried this, cvs co always sent the entire file across the
connection, while cvs update knew how to generate a patch and send that
instead if the changes were small or the file large.  Thus there was an
advantage to using update instead of co if update wouldn't cause problems.

I don't know if this is still the case, though.  I'd need to experiment
further.

-- 
Russ Allbery (rra@stanford.edu)             < http://www.eyrie.org/~eagle/ >

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Jim Wilson]

>a) We generate a M_refcopy function that contains a __exception_info variable.
>   We inline this into another function, generating an exception_info var
>   with an abstract origin pointing back to us.  We then optimize and emit
>   M_refcopy, and in the process of doing so, the block tree is modified such
>   that the exception_info variable no longer exists.  We then later try to
>   emit debug info for the inlinee, and we find a decl whose abstract origin
>   no longer exists.  This problem does not exist with the RTL inliner, because
>   we make a copy of the inline function before optimizing and emitting it,
>   and hence all abstract origin pointers back to us remain valid.

I have now verified that this is true.

When we get to M_refcopy, the C++ front end generates an AST which is saved
in DECL_SAVED_TREE.  This contains an __exception_info variable.  We then
generate BLOCK trees and RTL from the AST, putting the block trees in
DECL_INITIAL.  At this point, the block trees contain an __exception_info
variable.  We then optimize and emit the M_refcopy function.  The optimizer
function reorder_basic_blocks massages the RTL and block tree.  At this
point, there is no longer any __exception_info variable.  We then emit
assembly language and debug info for M_refcopy.

Later, we inline the M_refcopy function into the M_grab function.  The
tree inliner in the C++ front end uses the DECL_SAVED_TREE for this.
The DECL_SAVED_TREE still contains references to an __exception_info
variable, so we end up with one inlined into M_grab, whose abstract origin
points back to M_refcopy.  When we later emit debug info for M_grab (actually
in my case, another function that M_grab was inlined into), we follow the
abstract origin pointer back to M_refcopy, but there is no __exception_info
variable in M_refcopy, and we abort.

So the problem here is that a function only has one block tree, but we
really need two, one for the abstract instance, and one for the concrete
out-of-line instance (to use dwarf2 terminology).

This wasn't a problem with the older RTL inliner for a couple of reasons
that I can see.  Firstly, we only had one representation for a function,
the block trees and the RTL.  If we optimized a function, and then later
used the optimized block tree/RTL for inlining, then everything remains
consistent.  Now however we have two representations for a function, the
AST in DECL_SAVED_TREE, and the block tree/RTL.  After optimization, these
are no longer consistent with each other.  Secondly, the RTL inliner would
make copies of the block tree before optimizing a function in some instance,
and this ensured that the original abstract instance block trees survived
for use by the debug output routines.

I see of couple of different ways to fix this.  We could try to make the
dwarf2out.c file use the DECL_SAVED_TREE instead of the block tree when
emitting debug info for an abstract instance.  This info is not in the
form that we want it, and hence this will require writing a bit of code.
Another possible solution is to modify the FUNCTION_DECL tree to have
two block trees, the original one created by the front ends, and an optimized
one.  When emitting debug info for an abstract instance, we use the original
block tree.  When emitting debug info for a concrete out-of-line instance,
we use the optimized block tree.  Both of these solutions will require
writing some non-trivial code and then debugging and testing it.

Possible simpler solutions, which may not be desirable, are turning the
RTL inliner back on, and disabling optimization passes that can delete blocks
from the block tree (e.g. -freorder-blocks).

Jim

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Mark Mitchell]

>>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:

    Jim> Possible simpler solutions, which may not be desirable, are
    Jim> turning the RTL inliner back on, and disabling optimization
    Jim> passes that can delete blocks from the block tree
    Jim> (e.g. -freorder-blocks).

Would omitting debugging information for these variables be another
short-term solution?

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

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Jim Wilson]

>Would omitting debugging information for these variables be another
>short-term solution?

Not emitting the abstract origin attribute would be easy.  This will give a
die with no type or size info, which is pretty useless.  I suspect gdb will
give a reasonable error message instead of failing, but haven't tried it yet.

For a slightly more complicated change, we could check to see if the abstract
origin attribute was emitted, and if not, then treat it like a non-inlined
local variable.  This would allow the user to still be able to look at the
variable, but the output would be a little confusing since the debugger
would claim that we have a variable that doesn't exist in the source code.

My IA-64 machine is tied up with patch testing at the moment, so I can't do
much more with this until tomorrow.

Jim

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Mark Mitchell]

>>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:

    Jim> Not emitting the abstract origin attribute would be easy.
    Jim> This will give a die with no type or size info, which is
    Jim> pretty useless.  I suspect gdb will give a reasonable error
    Jim> message instead of failing, but haven't tried it yet.

    Jim> For a slightly more complicated change, we could check to see
    Jim> if the abstract origin attribute was emitted, and if not,
    Jim> then treat it like a non-inlined local variable.  This would
    Jim> allow the user to still be able to look at the variable, but
    Jim> the output would be a little confusing since the debugger
    Jim> would claim that we have a variable that doesn't exist in the
    Jim> source code.

I think either of these two alternatives would be fine.

In my experience, using GDB to debug optimized, heavily inlined code
really has never worked.  You tend not to be able to see variables,
you tend to find that step/next work oddly, and often you end up
jumping entirely out of the function spontaneously.

So, I guess I don't think this will be a major inconvenience to
anyone, relative to the current state.

In the long run, we should do better, but it sounds like these changes
would do the trick for GCC 3.0.  At this point, we have to be looking
for minimalist solutions.

Thanks,

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

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Daniel Berlin]

On Tue, 17 Apr 2001, Mark Mitchell wrote:

> >>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:
>
>     Jim> Not emitting the abstract origin attribute would be easy.
>     Jim> This will give a die with no type or size info, which is
>     Jim> pretty useless.  I suspect gdb will give a reasonable error
>     Jim> message instead of failing, but haven't tried it yet.
>
>     Jim> For a slightly more complicated change, we could check to see
>     Jim> if the abstract origin attribute was emitted, and if not,
>     Jim> then treat it like a non-inlined local variable.  This would
>     Jim> allow the user to still be able to look at the variable, but
>     Jim> the output would be a little confusing since the debugger
>     Jim> would claim that we have a variable that doesn't exist in the
>     Jim> source code.
>
> I think either of these two alternatives would be fine.
>
> In my experience, using GDB to debug optimized, heavily inlined code
> really has never worked.  You tend not to be able to see variables,
> you tend to find that step/next work oddly, and often you end up
> jumping entirely out of the function spontaneously.

Just a note, for the "long run".

This is something i'm seriously working on currently. It's why I sent
patches to support location lists for dwarf2 (well, one of the reasons,
anyway).
I already have modified loop unrolling to keep track of the approriate
things so that when combined with a patch to start using location lists
for my modified range rtlin dwarf2out.c (I removed some useless things
from the range info,
since we no longer need to be tracking state for the register allocator,
just knowing  enough to produce the debug info), and can successfully
handle location  lists, and evaluation of them at runtiome, in gdb. So
when the IV gets split into 4, we still can print the right value at the
right place, although step and next are still a little confusing.

I'm working on that too, but it's a little trickier of a change (I can
already read and do some stuff with the call frame info, which is
basically necessary to be able to treat inline functions as if they had
their own frame), so it's taking time.

Obviously, i'm not shooting for the 3.0 timeframe, i just wanted to make
sure nobody thought the "long run" was 5 years from now, when it's
probably 7 or 8 months.



 > > So, I guess I don't
think this  will be a major inconvenience to > anyone, relative to the
current state.
>
> In the long run, we should do better, but it sounds like these changes
> would do the trick for GCC 3.0.  At this point, we have to be looking
> for minimalist solutions.
>
> Thanks,
>
> --
> Mark Mitchell                   mark@codesourcery.com
> CodeSourcery, LLC               http://www.codesourcery.com
>

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Jim Wilson]

How about hacking the gcc3 branch and leaving the trunk broken?  That way we
have a chance of getting the trunk fixed correctly in the long term.  It
would be a shame to deliberately modify the trunk to emit incorrect debug
info.

Jim

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Mark Mitchell]

>>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:

    Jim> How about hacking the gcc3 branch and leaving the trunk
    Jim> broken?  That way we have a chance of getting the trunk fixed

If you like; that's OK with me.

    Jim> correctly in the long term.  It would be a shame to
    Jim> deliberately modify the trunk to emit incorrect debug info.

Well, sort-of.

We're talking about a case where optimization is involved, and as
laudable a goal as making debugging work well with optimizatio is,
it's unattainable, in general.  The debugger can't really be expected
to print out information about the values of variables that were
optimized away, for example.

The solution you proposed (replicating the BLOCK tree) might be
expensive, and I'm not convinced that's worth the trouble.  It would
be better if the optimizers did not mess up the tree structure; they
are supposed to be working on RTL, not trees.  Perhaps the RTL could
contain the declarations explicitly (via a NOTE_DECL_START_SCOPE
NOTE_DECL_END_SCOPE or some such); that would make it easier to keep
things in a consistent state.

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

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Daniel Berlin]

Mark Mitchell <mark@codesourcery.com> writes:

> >>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:
> 
>     Jim> How about hacking the gcc3 branch and leaving the trunk
>     Jim> broken?  That way we have a chance of getting the trunk fixed
> 
> If you like; that's OK with me.
> 
>     Jim> correctly in the long term.  It would be a shame to
>     Jim> deliberately modify the trunk to emit incorrect debug info.
> 
> Well, sort-of.
> 
> We're talking about a case where optimization is involved, and as
> laudable a goal as making debugging work well with optimizatio is,
> it's unattainable, in general.  The debugger can't really be expected
> to print out information about the values of variables that were
> optimized away, for example.
This is the only case that is "unattainable".
You can track values over their lifetime, even if they are split into
several pieces, first 2bytes in a register, next two in memory, etc,
over a specific range.
We can make it so inlined functions look just like the normal function
call to users in the debugger. We can deal with the absence of frames,
with multiple prologues and epilogues, with scheduled prologues and
epilogues, you name it.
In fact, the only optimization we actually can't handle yet (DWARF 2.1
introduces support for it), is interprocedural optimizations that
cause parts of a variable or function to be in different text sections
at once.  Past that, it's certainly attainable.
And i'm working on it quite hard.

In fact, the reason discontiguous scope support and whatnot is going
into DWARF2 2.1 is because their are compilers and debuggers that can
do everything else, and this is one of the last things they need to be
able to support.
To quote a proposal from the dwarf2 committe
"
In general, you can provide a highly useful level of debugging
optimized programs with the following:

Representing split lifetimes for variables
Representing subprogram inlining
Representing discontiguous scopes
Representing semantic breakpoint locations.

DWARF2 supports the first two, this proposal handles the third. The
fourth will be the subject of an upcoming proposal"

Please, don't claim something is unattainable when i've *seen* it
done with my own eyes.
I've used debuggers and compilers that support optimized debugging,
using dwarf2, to a point that except for variables that were optimized
out, i couldn't tell the difference between the optimized version, and
the non-optimized one, for debugging.

I'd like GDB and GCC to be able to do this too.

> 
> The solution you proposed (replicating the BLOCK tree) might be
> expensive, and I'm not convinced that's worth the trouble.  It would
> be better if the optimizers did not mess up the tree structure; they
> are supposed to be working on RTL, not trees.  Perhaps the RTL could
> contain the declarations explicitly (via a NOTE_DECL_START_SCOPE
> NOTE_DECL_END_SCOPE or some such); that would make it easier to keep
> things in a consistent state.
> 
> --
> Mark Mitchell                   mark@codesourcery.com
> CodeSourcery, LLC               http://www.codesourcery.com

-- 
I saw a subliminal advertising executive, but only for a second.

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Mark Mitchell]

>>>>> "Daniel" == Daniel Berlin <dan@cgsoftware.com> writes:

    Daniel> This is the only case that is "unattainable".  You can

I'm all for all the fancy DWARF2 stuff; I'd love to have it, and I'm
glad you're working on it.  (I was actually an advocate of getting rid
of stabs, in favor of DWARF, a couple of years ago on these lists).

But, there are other things that are very hard to do, often because
something is just not there in the compiler output.  Like instantiate
a class that the compiler didn't see a use of, and therefore didn't
emit debugging information for.  Or set a breakpoint at a line that
has been optimized away.  Or call an inlined function from the
debugger if no out-of-line instance was emitted by the compiler.  Or
making it easy for a programmer to follow the control flow with `step'
in the debugger when the compiler has reordered the code.

Some of these things might be important; some might not.  Some, you
could simulate.  But, there are problems that are hard.

Bottom line: a statement like this

  Please, don't claim something is unattainable when i've *seen* it
  done with my own eyes.

is more inflammatory than it needs to be, and suggests that I don't
know about these things.

The point is that debugging optimized code will always be harder thatn
debugging unoptimized code.  It would be good if are debug information
was perfect for optimized code.  But, it's more important that it be
perfect for unoptimized code (and I bet it's not!), and it's even more
important that we generate correct code (which I know we don't
always).  Not to mention improving GDB to have a better user
interface, better stability, etc.  (Thanks to you for working on
this!)

It's a question of priorities, cost-benefit analysis, etc.  Is it
worth the effort (both programmer-time and compiler-time) to do what
Jim suggested, or is better just to punt?  I think we all agree
punting is OK for the 3.0 branch.  

The question is whether to punt on the 3.1 mainline, or not.  If we
do, then some people argue that we are less likely to fix the bug.  On
the other hand, if we do not punt, then if we don't fix the bug, we
must remember to insall the punt again on the 3.1 release branch, when
we get there.  And meanwhile some programs will crash on the mainline.

Personally, I would prefer that we file a bug in GNATS (debugging info
wrong; here's a test-case) and install the punt on both the mainline
and the branch.  That adheres to the principle of trying to keep
things working as much as possible so that a) it's easier to do
releases, and b) it's easier for everyone to test the compiler and
work to improve it.  A broken compiler may serve as a good reminder,
but it also makes life difficult for people working on unrelated
tasks.

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

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Jim Wilson]

Just a few more comments on what you and other people have said...

This particular problem with the debug info did not exist until you checked in
a patch that turned off the RTL inliner.  As such, it represents a regression,
and regressions should be fixed.

I see this as another part of the tree inliner that isn't finished yet.  The
RTL inliner handled this correctly.  It is easy for the tree inliner to handle
this correctly too, we just haven't written the code for it yet.  This should
be done before the tree inliner permanently replaces the RTL inliner.

It is easy to disregard debug info related problems because they don't
interfere with bootstraps.  However, debug info support is important for
maintaining gcc and other programs, and a lot of people have put a lot of
hard work into making the debug info useful.  We should not lightly abandon
that effort.

The breakage here is not as serious as it might seem.  Remember, the trunk
is not broken because of this bug, only the branch.  This is because the
bug goes away with Richard's large C++ EH/Unwind API patch.  The only testcase
we have for this problem fails because of fake variables inserted by the C++
front end for EH purposes.  It is unclear if this bug will be triggered by
any other testcases.  Richard will be checking his patch onto the branch before
long, so the problem will go away even if we don't do anything to dwarf2out.c.

I'm still working on java related build failures on the trunk that appeared
recently.  I expect that I will get to this problem today.  I will check in
a patch to punt on the branch, and then document the correct fix in dwarf2out.c
on the trunk, or if it isn't too hard, I may just write the damn code myself.

Jim

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Mark Mitchell]

>>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:

    Jim> This particular problem with the debug info did not exist
    Jim> until you checked in a patch that turned off the RTL inliner.
    Jim> As such, it represents a regression, and regressions should
    Jim> be fixed.

That's fair.

    Jim> I see this as another part of the tree inliner that isn't
    Jim> finished yet.  The RTL inliner handled this correctly.  It is
    Jim> easy for the tree inliner to handle this correctly too, we
    Jim> just haven't written the code for it yet.  This should be
    Jim> done before the tree inliner permanently replaces the RTL
    Jim> inliner.

I guess I'm still not sure exactly what needs to be done.  Is all that
needs to be done:

 If the function for which we are about to generate code is 
 inline, then:

 - Copy the BLOCK tree.

 - Generate code.   

 - Restore the original BLOCK tree, throwing away the copy.

?

If so, you're correct that that isn't a particularly difficult task.
I can certainly code that up, given a test-case, and such.

I don't know if it's really that simple, or not.

    Jim> they don't interfere with bootstraps.  However, debug info
    Jim> support is important for maintaining gcc and other programs,
    Jim> and a lot of people have put a lot of hard work into making
    Jim> the debug info useful.  We should not lightly abandon that
    Jim> effort.

I agree completely.  

    Jim> large C++ EH/Unwind API patch.  The only testcase we have for
    Jim> this problem fails because of fake variables inserted by the
    Jim> C++ front end for EH purposes.  It is unclear if this bug
    Jim> will be triggered by any other testcases.

Interesting point.  It is likely that it could be -- the front-end
doesn't really do anything special with those variables -- but your
point that we don't know how often the bug will come up is
interesting.

    Jim> problem today.  I will check in a patch to punt on the
    Jim> branch, and then document the correct fix in dwarf2out.c on
    Jim> the trunk, or if it isn't too hard, I may just write the damn
    Jim> code myself.

Thank you, for the analysis, the commentary, and the fix.

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

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Jim Wilson]

> - Copy the BLOCK tree.
> - Generate code.   
> - Restore the original BLOCK tree, throwing away the copy.

That is one solution.  Another solution is to modify dwarf2out.c to use the
DECL_SAVED_TREE instead of the BLOCK tree for abstract instances.  Neither
one should be particularly hard.

Jim

debugging optimized programs (Was: Re: Bootstrap failure of gcc-ss-20010409 in ia64)

[Joern Rennecke]

> I've used debuggers and compilers that support optimized debugging,
> using dwarf2, to a point that except for variables that were optimized
> out, i couldn't tell the difference between the optimized version, and
> the non-optimized one, for debugging.

So what does the debugger do when you ask it to step one source level line
forward (gdb 'n' command) when code from different lines is heavily
intermingled by scheduling?

Re: debugging optimized programs (Was: Re: Bootstrap failure of gcc-ss-20010409 in ia64)

[Daniel Berlin]

Joern Rennecke <amylaar@cambridge.redhat.com> writes:

> > I've used debuggers and compilers that support optimized debugging,
> > using dwarf2, to a point that except for variables that were optimized
> > out, i couldn't tell the difference between the optimized version, and
> > the non-optimized one, for debugging.
> 
> So what does the debugger do when you ask it to step one source level line
> forward (gdb 'n' command) when code from different lines is heavily
> intermingled by scheduling?
The line number information will tell it when it's actually advanced
one source line.

is_stmt will tell you when you hit the first thing that actually
belongs to that particularl line.

In the case of heavily intermingled code, the line number info may
look like (i've omitted is_stmt, basic_block, and other registers, for
simplicity):

Line advance            Address advance
0                       1
-1                      1
2                       1
-1                      1
etc



-- 
"I'm writing a book.  I've got the page numbers done, so now I
just have to fill in the rest.
"-Steven Wright

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Mark Mitchell]

>>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:

    >> - Copy the BLOCK tree.  - Generate code.  - Restore the
    >> original BLOCK tree, throwing away the copy.

    Jim> That is one solution.  Another solution is to modify
    Jim> dwarf2out.c to use the DECL_SAVED_TREE instead of the BLOCK
    Jim> tree for abstract instances.  Neither one should be
    Jim> particularly hard.

The DECL_SAVED_TREE approach is probably harder because the block tree
is not so clearly encoded there.

Is note_outlining_of_inline_function being called?  It looks like:

  void
  note_outlining_of_inline_function (fndecl)
       tree fndecl;
  {
  #ifdef DWARF2_DEBUGGING_INFO
    /* The DWARF 2 backend tries to reduce debugging bloat by not emitting
       the abstract description of inline functions until something tries to
       reference them.  Force it out now, before optimizations mangle the
       block tree.  */
    if (write_symbols == DWARF2_DEBUG)
      dwarf2out_abstract_function (fndecl);
  #endif
  }

From the comment, it sounds like this code should be dealing with this
problem.  If this function isn't being called, then that's a front-end
bug -- but probably one that can be easily fixed.

Thanks,

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

Re: debugging optimized programs (Was: Re: Bootstrap failure of gcc-ss-20010409 in ia64)

[Joern Rennecke]

> In the case of heavily intermingled code, the line number info may
> look like (i've omitted is_stmt, basic_block, and other registers, for
> simplicity):
> 
> Line advance            Address advance
> 0                       1
> -1                      1
> 2                       1
> -1                      1
> etc

So that's the way gdb handles it right now.  Which can mean that
optimized code is so tedious to debug for some applications and targets
that you try to avoid it at all costs.  Not what I'd call 'not being able
to tell the difference'.

Re: debugging optimized programs (Was: Re: Bootstrap failure of gcc-ss-20010409 in ia64)

[Daniel Berlin]

Joern Rennecke <amylaar@cambridge.redhat.com> writes:

> > In the case of heavily intermingled code, the line number info may
> > look like (i've omitted is_stmt, basic_block, and other registers, for
> > simplicity):
> > 
> > Line advance            Address advance
> > 0                       1
> > -1                      1
> > 2                       1
> > -1                      1
> > etc
> 
> So that's the way gdb handles it right now.  Which can mean that
> optimized code is so tedious to debug for some applications and targets
> that you try to avoid it at all costs.  Not what I'd call 'not being able
> to tell the difference'.

Err, what are you talking about?
I mean this is what the debug info says, not what gdb *does* (or will
do).


-- 
"I put a new engine in my car, but forgot to take the old one
out.  Now my car goes 500 miles per hour.  The harmonica sounds
*amazing*.
"-Steven Wright

Re: debugging optimized programs (Was: Re: Bootstrap failure of gcc-ss-20010409 in ia64)

[Daniel Berlin]

Daniel Berlin <dan@cgsoftware.com> writes:

> Joern Rennecke <amylaar@cambridge.redhat.com> writes:
> 
> > > In the case of heavily intermingled code, the line number info may
> > > look like (i've omitted is_stmt, basic_block, and other registers, for
> > > simplicity):
> > > 
> > > Line advance            Address advance
> > > 0                       1
> > > -1                      1
> > > 2                       1
> > > -1                      1
> > > etc
> > 
> > So that's the way gdb handles it right now.  Which can mean that
> > optimized code is so tedious to debug for some applications and targets
> > that you try to avoid it at all costs.  Not what I'd call 'not being able
> > to tell the difference'.
> 
> Err, what are you talking about?
> I mean this is what the debug info says, not what gdb *does* (or will
> do).

Let me expand.

What GDB does is take this, and throw it all away.
It says a line can have a pc range, but it can't be discontiguous.
So we can't actually follow what really happens, we just go to the
source line past the end of the range for that line, etc.
If we did something like the above, we'd at least always be on the
right line when you type step or next (step would skip around as the
line we are on decrements or advances, but it'd be correct. next would
do what it says, and go to the next source line. In other words, next
just wouldn't follow negative line advances).

--Dan

-- 
"I saw a bank that said "24 Hour Banking", but I don't have that
much time.
"-Steven Wright

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Daniel Berlin]

Joe Buck <jbuck@racerx.synopsys.com> writes:

> > > > The debugger can't really be expected to print out information
> > > > about the values of variables that were optimized away, for
> > > > example.
> > > This is the only case that is "unattainable".
> 
> Mike Stump writes:
> > Actually, if you can make it spit out 5, when a user says p i, when
> > the software has a { const int i = 5; } then I don't see why you can't
> > mostly solve the last as well.  In fact, I thought dwarf 2 had enough
> > guts to do this.
> 
> I suppose we could give the debugger a formula for re-generating things
> like loop induction variables that get optimized away.
Or, it can say "variable doesn't exist during this range".
DWARF2 lets you do either.
>  Kind of like a
> spreadsheet, defining no longer existing variables in terms of existing
> objects, perhaps different for each location.

This is actually pretty easy to do, given the opcodes available in
dwarf2 locexpr's.


> 
> But there also can be variables that are neither used nor set, so their
> value is indeterminate.  Or because a variable is not used, the compiler
> throws away a lot of code that computes it, and it might be tricky to
> include all needed formulas to compute it.
If it's been optimized away for a givne range, we can express
this to the debugger, with location lists.
Any range of pc's for which you have no location means the variable
doesn't exist during that range.
Any range of pc's that overlap means you have a variable that exists
in two places simultaneously.

> 
> 

-- 
Last night, I walked up to this beautiful woman in a bar and
asked her, "Do you live around here often?"  She said, "You're
wearing two different colored socks."  I said, "Yes, but to me
they're the same because I go by thickness."  Then she asked,
"How do you feel?"  and I said, "Well, you know when you're
sitting on a chair and you lean back so you're just on two legs
then you lean too far and you almost fall over but at the last
second you catch yourself?  I feel like that all the time."

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Joe Buck]

> > > The debugger can't really be expected to print out information
> > > about the values of variables that were optimized away, for
> > > example.
> > This is the only case that is "unattainable".

Mike Stump writes:
> Actually, if you can make it spit out 5, when a user says p i, when
> the software has a { const int i = 5; } then I don't see why you can't
> mostly solve the last as well.  In fact, I thought dwarf 2 had enough
> guts to do this.

I suppose we could give the debugger a formula for re-generating things
like loop induction variables that get optimized away.  Kind of like a
spreadsheet, defining no longer existing variables in terms of existing
objects, perhaps different for each location.

But there also can be variables that are neither used nor set, so their
value is indeterminate.  Or because a variable is not used, the compiler
throws away a lot of code that computes it, and it might be tricky to
include all needed formulas to compute it.

Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Mike Stump]

> To: Mark Mitchell <mark@codesourcery.com>
> Cc: wilson@cygnus.com, gcc@gcc.gnu.org
> From: Daniel Berlin <dan@cgsoftware.com>
> Date: 17 Apr 2001 19:16:23 -0400

> > The debugger can't really be expected to print out information
> > about the values of variables that were optimized away, for
> > example.
> This is the only case that is "unattainable".

Actually, if you can make it spit out 5, when a user says p i, when
the software has a { const int i = 5; } then I don't see why you can't
mostly solve the last as well.  In fact, I thought dwarf 2 had enough
guts to do this.

If not that, maybe p i with { enum { i = 5 }; }?