Patchwork [RFC] PR c++/44188

login
register
mail settings
Submitter Dodji Seketeli
Date June 10, 2010, 12:57 p.m.
Message ID <m3mxv3f3jf.fsf@redhat.com>
Download mbox | patch
Permalink /patch/55216/
State New
Headers show

Comments

Dodji Seketeli - June 10, 2010, 12:57 p.m.
Richard Sandiford <rdsandiford@googlemail.com> writes:

> This breaks builds of libstdc++-v3 on mipsisa64-elf, where
> __builtin_va_list is a record type.  We end up trying to output a
> location for the definition of __builtin_va_list, which has location
> UNKNOWN_LOCATION.  We then segfault in lookup_filename because the
> filename associated with UNKNOWN_LOCATION is null.
>
> Testcase is:
>
>     typedef __builtin_va_list foo;
>
> compiled with "./cc1plus -g".
>
> A simple "fix" is attached, but many other built-in decls use
> UNKNOWN_LOCATION, so I suspect something more fundamental is wrong.
> Could you have a look?

Sure. I am building a cross compiler right now, as I don't have access
to this arch otherwise. It's taking time though.

If you can do a quick test, does the (untested) patch below fix the
issue for you?


Thanks.
Jason Merrill - June 10, 2010, 3:32 p.m.
On 06/10/2010 08:57 AM, Dodji Seketeli wrote:
> If you can do a quick test, does the (untested) patch below fix the
> issue for you?

The patch is OK if it passes testing.

Jason
Richard Sandiford - June 10, 2010, 8:36 p.m.
Dodji Seketeli <dodji@redhat.com> writes:
> Richard Sandiford <rdsandiford@googlemail.com> writes:
>> This breaks builds of libstdc++-v3 on mipsisa64-elf, where
>> __builtin_va_list is a record type.  We end up trying to output a
>> location for the definition of __builtin_va_list, which has location
>> UNKNOWN_LOCATION.  We then segfault in lookup_filename because the
>> filename associated with UNKNOWN_LOCATION is null.
>>
>> Testcase is:
>>
>>     typedef __builtin_va_list foo;
>>
>> compiled with "./cc1plus -g".
>>
>> A simple "fix" is attached, but many other built-in decls use
>> UNKNOWN_LOCATION, so I suspect something more fundamental is wrong.
>> Could you have a look?
>
> Sure. I am building a cross compiler right now, as I don't have access
> to this arch otherwise. It's taking time though.

For future reference, mipsisa64-elf is cross only.  You can't bootstrap
GCC on it.  Building a cross compiler is exactly the right thing to do.

I'm surprised that it took a long time though.  "make all-gcc" (to get
cc1plus) ought to complete very quickly, especially by normal bootstrap
standards. ;-) You also don't need access to an assembler or linker if
you're just doing "make all-gcc".

> If you can do a quick test, does the (untested) patch below fix the
> issue for you?

It certainly does.  Thanks a lot for the quick fix.

Richard

Patch

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 6cbe8dc..e35a780 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -19891,6 +19891,7 @@  is_naming_typedef_decl (const_tree decl)
   if (decl == NULL_TREE
       || TREE_CODE (decl) != TYPE_DECL
       || !is_tagged_type (TREE_TYPE (decl))
+      || DECL_IS_BUILTIN (decl)
       || is_redundant_typedef (decl)
       /* It looks like Ada produces TYPE_DECLs that are very similar
          to C++ naming typedefs but that have different