Re: ICE building a libsupc++ file, pdp11 target

[Richard Biener]

On Tue, Oct 9, 2018 at 11:39 PM Paul Koning  wrote:
>
>
>
> > On Jul 17, 2018, at 9:36 AM, Richard Biener  
> > wrote:
> >
> > On Tue, Jul 17, 2018 at 3:08 PM Paul Koning  wrote:
> >>
> >>
> >>> On Jul 17, 2018, at 5:46 AM, Richard Biener  
> >>> wrote:
> >>>
>  ...
> >>>
> >>> There is not enough information for anyone to help you without
> >>> reproducing the issue which is maybe too much to ask for ;)
> >>>
> >>> Can you debug_tree () the offending decl in gdb?
> >>
> >> Yes, here it is.  I don't know anything about debugging in this area, so 
> >> tools like debug_tree are good to learn about.  How would I interpret its 
> >> output?
> >>
> >> pkoning:gcc pkoning$ lldb ./cc1plus -- new_opa.ii -fno-implicit-templates 
> >> -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi 
> >> -fdiagnostics-show-location=once -frandom-seed=new_opa.lo -g -O2 
> >> -std=gnu++1z
> >> (lldb) target create "./cc1plus"
> >> Current executable set to './cc1plus' (x86_64).
> >> ...
> >> Process 10880 stopped
> >> * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
> >>frame #0: 0x000100c21378 cc1plus`internal_error(gmsgid="in %s, at 
> >> %s:%d") at diagnostic.c:1441 [opt]
> >>   1438 internal_error (const char *gmsgid, ...)
> >>   1439 {
> >>   1440   va_list ap;
> >> -> 1441   va_start (ap, gmsgid);
> >>   1442   rich_location richloc (line_table, input_location);
> >>   1443   diagnostic_impl (, -1, gmsgid, , DK_ICE);
> >>   1444   va_end (ap);
> >> Target 0: (cc1plus) stopped.
> >> (lldb) frame sel 2
> >> frame #2: 0x000100074b36 
> >> cc1plus`import_export_decl(decl=0x00014269c750) at decl2.c:2877 [opt]
> >>   2874   gcc_assert (VAR_OR_FUNCTION_DECL_P (decl));
> >>   2875   /* Any code that creates entities with TREE_PUBLIC cleared should
> >>   2876  also set DECL_INTERFACE_KNOWN.  */
> >> -> 2877   gcc_assert (TREE_PUBLIC (decl));
> >>   2878   if (TREE_CODE (decl) == FUNCTION_DECL)
> >>   2879 gcc_assert (DECL_IMPLICIT_INSTANTIATION (decl)
> >>   2880 || DECL_FRIEND_PSEUDO_TEMPLATE_INSTANTIATION (decl)
> >> (lldb) call debug_tree(decl)
> >>  >>type  >>size 
> >>unit-size 
> >>align:8 warn_if_not_align:0 symtab:150 alias-set -1 canonical-type 
> >> 0x1426aa5e8 precision:1 min  max  >> 0x142502a08 1>>
> >>readonly constant used static tree_1 tree_2 tree_3 unsigned nonlocal 
> >> in_system_header read decl_1 QI 
> >> /Users/pkoning/Documents/svn/buildpdp/pdp11-aout/libstdc++-v3/include/type_traits:59:28
> >>  size  unit-size 
> >>align:8 warn_if_not_align:0 context  >> integral_constant> initial 
> >>template-info 0x1426a64e0 chain >
> >> (lldb)
> >
> > lldb? eh ... ;)
> >
> > anyhow, this is
> >
> > namespace std
> > {
> >
> > # 56 
> > "/Users/pkoning/Documents/svn/buildpdp/pdp11-aout/libstdc++-v3/include/type_traits"
> > 3
> >  template
> >struct integral_constant
> >{
> >  static constexpr _Tp value = __v;
> > ^^^
> >
> > which should have TREE_PUBLIC set.  My next step would be to watch how
> > this flag changes (if it does...)
> >
> > break at ggc-page.c:1442 (the return stmt of ggc_internal_alloc)
> > conditional on result == 0x14269c750
> > and then watch *>base.public_flag printing said flag when
> > the watchpoint hits
> > (because you're watching the whole integer containing the bitfield bit).
> >
> > If that doesn't go anywhere try reducing the source file using creduce
> > or by other means.
> >
> > Maybe look at reset_decl_linkage () and visibility support in general.
>
> I trimmed the file a bit.
>
> Managed to find where public_flag is cleared.  It is in cp/expr.c 
> maybe_commonize_var, line 5619, here:
>
>   else
> {
>   /* While for initialized variables, we must use internal
>  linkage -- which means that multiple copies will not
>  be merged.  */
>   TREE_PUBLIC (decl) = 0;
>   DECL_COMMON (decl) = 0;
>
> Could it be related to the fact that I have an a.out (rather than ELF) target?

I guess a.out is bitrotten (or too incapable) for C++ here.  I see the
code above emits warnings about this
being unhandled as well, it possibly should simply sorry() when it can
figure out it
will run into the import_export_decl ICE later...

Richard.

> paul
>

Re: ICE building a libsupc++ file, pdp11 target

[Paul Koning]

> On Jul 17, 2018, at 9:36 AM, Richard Biener  
> wrote:
> 
> On Tue, Jul 17, 2018 at 3:08 PM Paul Koning  wrote:
>> 
>> 
>>> On Jul 17, 2018, at 5:46 AM, Richard Biener  
>>> wrote:
>>> 
 ...
>>> 
>>> There is not enough information for anyone to help you without
>>> reproducing the issue which is maybe too much to ask for ;)
>>> 
>>> Can you debug_tree () the offending decl in gdb?
>> 
>> Yes, here it is.  I don't know anything about debugging in this area, so 
>> tools like debug_tree are good to learn about.  How would I interpret its 
>> output?
>> 
>> pkoning:gcc pkoning$ lldb ./cc1plus -- new_opa.ii -fno-implicit-templates 
>> -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi 
>> -fdiagnostics-show-location=once -frandom-seed=new_opa.lo -g -O2 -std=gnu++1z
>> (lldb) target create "./cc1plus"
>> Current executable set to './cc1plus' (x86_64).
>> ...
>> Process 10880 stopped
>> * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
>>frame #0: 0x000100c21378 cc1plus`internal_error(gmsgid="in %s, at 
>> %s:%d") at diagnostic.c:1441 [opt]
>>   1438 internal_error (const char *gmsgid, ...)
>>   1439 {
>>   1440   va_list ap;
>> -> 1441   va_start (ap, gmsgid);
>>   1442   rich_location richloc (line_table, input_location);
>>   1443   diagnostic_impl (, -1, gmsgid, , DK_ICE);
>>   1444   va_end (ap);
>> Target 0: (cc1plus) stopped.
>> (lldb) frame sel 2
>> frame #2: 0x000100074b36 
>> cc1plus`import_export_decl(decl=0x00014269c750) at decl2.c:2877 [opt]
>>   2874   gcc_assert (VAR_OR_FUNCTION_DECL_P (decl));
>>   2875   /* Any code that creates entities with TREE_PUBLIC cleared should
>>   2876  also set DECL_INTERFACE_KNOWN.  */
>> -> 2877   gcc_assert (TREE_PUBLIC (decl));
>>   2878   if (TREE_CODE (decl) == FUNCTION_DECL)
>>   2879 gcc_assert (DECL_IMPLICIT_INSTANTIATION (decl)
>>   2880 || DECL_FRIEND_PSEUDO_TEMPLATE_INSTANTIATION (decl)
>> (lldb) call debug_tree(decl)
>> >type >size 
>>unit-size 
>>align:8 warn_if_not_align:0 symtab:150 alias-set -1 canonical-type 
>> 0x1426aa5e8 precision:1 min  max > 0x142502a08 1>>
>>readonly constant used static tree_1 tree_2 tree_3 unsigned nonlocal 
>> in_system_header read decl_1 QI 
>> /Users/pkoning/Documents/svn/buildpdp/pdp11-aout/libstdc++-v3/include/type_traits:59:28
>>  size  unit-size 
>>align:8 warn_if_not_align:0 context > integral_constant> initial 
>>template-info 0x1426a64e0 chain >
>> (lldb)
> 
> lldb? eh ... ;)
> 
> anyhow, this is
> 
> namespace std
> {
> 
> # 56 
> "/Users/pkoning/Documents/svn/buildpdp/pdp11-aout/libstdc++-v3/include/type_traits"
> 3
>  template
>struct integral_constant
>{
>  static constexpr _Tp value = __v;
> ^^^
> 
> which should have TREE_PUBLIC set.  My next step would be to watch how
> this flag changes (if it does...)
> 
> break at ggc-page.c:1442 (the return stmt of ggc_internal_alloc)
> conditional on result == 0x14269c750
> and then watch *>base.public_flag printing said flag when
> the watchpoint hits
> (because you're watching the whole integer containing the bitfield bit).
> 
> If that doesn't go anywhere try reducing the source file using creduce
> or by other means.
> 
> Maybe look at reset_decl_linkage () and visibility support in general.

I trimmed the file a bit.

Managed to find where public_flag is cleared.  It is in cp/expr.c 
maybe_commonize_var, line 5619, here:

  else
{
  /* While for initialized variables, we must use internal
 linkage -- which means that multiple copies will not
 be merged.  */
  TREE_PUBLIC (decl) = 0;
  DECL_COMMON (decl) = 0;

Could it be related to the fact that I have an a.out (rather than ELF) target?

paul

Re: ICE building a libsupc++ file, pdp11 target

[Paul Koning]

> On Jul 23, 2018, at 10:21 AM, Joseph Myers  wrote:
> 
> On Tue, 17 Jul 2018, Paul Koning wrote:
> 
>> That reveals some things but nothing jumps out at me.  However... pdp11 
>> is an a.out target, not an ELF target.  Would that explain the problem?  
>> If yes, is there a workaround (short of implementing ELF)?
> 
> As there are hardly any targets left without named section support, using 
> ELF might be a good idea so you don't have to deal with the 
> no-named-sections issues.
> 
> The ELF e_machine value EM_PDP11 was assigned to Lars Brinkoff, 
> l...@nocrew.org, 30 May 2002, according to the comments in 
> ch4.eheader.html.  I don't know if an actual ELF ABI has been defined.

I don't know of pdp11 ELF code in binutils.  

The named-section stuff itself doesn't seem to be directly related.  If I run 
the test with the target flag -mdec-asm, it still fails.  That mode does 
support named sections.

I can easily see the issue with the debugger and compare with a target that 
works (vax).  So I should be able to find this, at least once I figure out how 
to turn off address space randomization on my host.

paul

Re: ICE building a libsupc++ file, pdp11 target

[Joseph Myers]

On Tue, 17 Jul 2018, Paul Koning wrote:

> That reveals some things but nothing jumps out at me.  However... pdp11 
> is an a.out target, not an ELF target.  Would that explain the problem?  
> If yes, is there a workaround (short of implementing ELF)?

As there are hardly any targets left without named section support, using 
ELF might be a good idea so you don't have to deal with the 
no-named-sections issues.

The ELF e_machine value EM_PDP11 was assigned to Lars Brinkoff, 
l...@nocrew.org, 30 May 2002, according to the comments in 
ch4.eheader.html.  I don't know if an actual ELF ABI has been defined.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: ICE building a libsupc++ file, pdp11 target

[Paul Koning]

> On Jul 17, 2018, at 9:38 AM, Richard Biener  
> wrote:
> 
>> ...
>> lldb? eh ... ;)

Yes, gdb is hard to make work on Mac OS.

>> anyhow, this is
>> 
>> namespace std
>> {
>> 
>> # 56 
>> "/Users/pkoning/Documents/svn/buildpdp/pdp11-aout/libstdc++-v3/include/type_traits"
>> 3
>>  template
>>struct integral_constant
>>{
>>  static constexpr _Tp value = __v;
>> ^^^
>> 
>> which should have TREE_PUBLIC set.  My next step would be to watch how
>> this flag changes (if it does...)
>> 
>> break at ggc-page.c:1442 (the return stmt of ggc_internal_alloc)
>> conditional on result == 0x14269c750
>> and then watch *>base.public_flag printing said flag when
>> the watchpoint hits
>> (because you're watching the whole integer containing the bitfield bit).
>> 
>> If that doesn't go anywhere try reducing the source file using creduce
>> or by other means.
>> 
>> Maybe look at reset_decl_linkage () and visibility support in general.
> 
> Oh, and generally a grep for 'targetm' in cp/ might reveal bits that sound
> interesting.

That reveals some things but nothing jumps out at me.  However... pdp11 is an 
a.out target, not an ELF target.  Would that explain the problem?  If yes, is 
there a workaround (short of implementing ELF)?

paul

Re: ICE building a libsupc++ file, pdp11 target

[Richard Biener]

On Tue, Jul 17, 2018 at 3:36 PM Richard Biener
 wrote:
>
> On Tue, Jul 17, 2018 at 3:08 PM Paul Koning  wrote:
> >
> >
> > > On Jul 17, 2018, at 5:46 AM, Richard Biener  
> > > wrote:
> > >
> > >> ...
> > >
> > > There is not enough information for anyone to help you without
> > > reproducing the issue which is maybe too much to ask for ;)
> > >
> > > Can you debug_tree () the offending decl in gdb?
> >
> > Yes, here it is.  I don't know anything about debugging in this area, so 
> > tools like debug_tree are good to learn about.  How would I interpret its 
> > output?
> >
> > pkoning:gcc pkoning$ lldb ./cc1plus -- new_opa.ii -fno-implicit-templates 
> > -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi 
> > -fdiagnostics-show-location=once -frandom-seed=new_opa.lo -g -O2 
> > -std=gnu++1z
> > (lldb) target create "./cc1plus"
> > Current executable set to './cc1plus' (x86_64).
> > (lldb) settings set -- target.run-args  "new_opa.ii" 
> > "-fno-implicit-templates" "-Wall" "-Wextra" "-Wwrite-strings" "-Wcast-qual" 
> > "-Wabi" "-fdiagnostics-show-location=once" "-frandom-seed=new_opa.lo" "-g" 
> > "-O2" "-std=gnu++1z"
> > (lldb) b internal_error
> > Breakpoint 1: where = cc1plus`internal_error(char const*, ...) + 104 at 
> > diagnostic.c:1441, address = 0x000100c21378
> > (lldb) run
> > Process 10880 launched: './cc1plus' (x86_64)
> > cc1plus: warning: -Wabi won't warn about anything [-Wabi]
> > cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, 
> > which is also used by default
> > cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7
> >  long int std::abs(long int) long long int std::abs(long long int) 
> > constexpr double std::abs(double) constexpr float std::abs(float) constexpr 
> > long double std::abs(long double) ldiv_t std::div(long int, long int) 
> > std::exception::exception() std::exception::exception() 
> > std::exception::exception() std::bad_exception::bad_exception() 
> > std::bad_exception::bad_exception() std::bad_exception::bad_exception() 
> > const char* std::type_info::name() const bool 
> > std::type_info::operator!=(const std::type_info&) const std::size_t 
> > std::type_info::hash_code() const std::type_info::type_info(const char*) 
> > std::type_info::type_info(const char*) std::type_info::type_info(const 
> > char*) std::bad_cast::bad_cast() std::bad_cast::bad_cast() 
> > std::bad_cast::bad_cast() std::bad_typeid::bad_typeid() 
> > std::bad_typeid::bad_typeid() std::bad_typeid::bad_typeid() 
> > std::__exception_ptr::exception_ptr::exception_ptr(std::nullptr_t) 
> > std::__exception_ptr::exception_ptr::exception_ptr(std::nullptr_t) 
> > std::__exception_ptr::exception_ptr::exception_ptr(std::nullptr_t) 
> > std::__exception_ptr::exception_ptr::exception_ptr(std::__exception_ptr::exception_ptr&&)
> >  
> > std::__exception_ptr::exception_ptr::exception_ptr(std::__exception_ptr::exception_ptr&&)
> >  
> > std::__exception_ptr::exception_ptr::exception_ptr(std::__exception_ptr::exception_ptr&&)
> >  std::__exception_ptr::exception_ptr& 
> > std::__exception_ptr::exception_ptr::operator=(std::__exception_ptr::exception_ptr&&)
> >  std::__exception_ptr::exception_ptr::operator bool() const void 
> > std::__exception_ptr::swap(std::__exception_ptr::exception_ptr&, 
> > std::__exception_ptr::exception_ptr&) void 
> > std::__exception_ptr::__dest_thunk(void*) 
> > std::__exception_ptr::exception_ptr std::make_exception_ptr(_Ex) constexpr 
> > _Tp* std::__addressof(_Tp&) constexpr std::integral_constant<_Tp, 
> > __v>::operator std::integral_constant<_Tp, __v>::value_type() const 
> > constexpr std::integral_constant<_Tp, __v>::value_type 
> > std::integral_constant<_Tp, __v>::operator()() const 
> > std::integral_constant constexpr const bool 
> > std::integral_constant::value constexpr const bool 
> > std::integral_constant::value std::integral_constant > true> constexpr const bool std::integral_constant::value 
> > constexpr const bool std::integral_constant::value 
> > std::integral_constant constexpr const short 
> > unsigned int std::integral_constant::value constexpr 
> > const short unsigned int std::integral_constant > 0>::value std::__make_unsigned_selector_base::_List > unsigned int, unsigned int, long unsigned int, long long unsigned int> 
> > std::__make_unsigned_selector_base::_List > long unsigned int, long long unsigned int> 
> > std::__make_unsigned_selector_base::_List > long long unsigned int> std::__make_unsigned_selector_base::_List > unsigned int, long long unsigned int> 
> > std::__make_unsigned_selector_base::_List 
> > std::__make_unsigned_selector_base::_List<> constexpr const size_t 
> > std::__make_unsigned_selector_base::_List::__size 
> > constexpr const size_t std::__make_unsigned_selector_base::_List > unsigned int>::__size constexpr const size_t 
> > std::__make_unsigned_selector_base::_List > unsigned int>::__size constexpr const size_t 
> > std::__make_unsigned_selector_base::_List > unsigned int>::__size 

Re: ICE building a libsupc++ file, pdp11 target

[Richard Biener]

On Tue, Jul 17, 2018 at 3:08 PM Paul Koning  wrote:
>
>
> > On Jul 17, 2018, at 5:46 AM, Richard Biener  
> > wrote:
> >
> >> ...
> >
> > There is not enough information for anyone to help you without
> > reproducing the issue which is maybe too much to ask for ;)
> >
> > Can you debug_tree () the offending decl in gdb?
>
> Yes, here it is.  I don't know anything about debugging in this area, so 
> tools like debug_tree are good to learn about.  How would I interpret its 
> output?
>
> pkoning:gcc pkoning$ lldb ./cc1plus -- new_opa.ii -fno-implicit-templates 
> -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi 
> -fdiagnostics-show-location=once -frandom-seed=new_opa.lo -g -O2 -std=gnu++1z
> (lldb) target create "./cc1plus"
> Current executable set to './cc1plus' (x86_64).
> (lldb) settings set -- target.run-args  "new_opa.ii" 
> "-fno-implicit-templates" "-Wall" "-Wextra" "-Wwrite-strings" "-Wcast-qual" 
> "-Wabi" "-fdiagnostics-show-location=once" "-frandom-seed=new_opa.lo" "-g" 
> "-O2" "-std=gnu++1z"
> (lldb) b internal_error
> Breakpoint 1: where = cc1plus`internal_error(char const*, ...) + 104 at 
> diagnostic.c:1441, address = 0x000100c21378
> (lldb) run
> Process 10880 launched: './cc1plus' (x86_64)
> cc1plus: warning: -Wabi won't warn about anything [-Wabi]
> cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, 
> which is also used by default
> cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7
>  long int std::abs(long int) long long int std::abs(long long int) constexpr 
> double std::abs(double) constexpr float std::abs(float) constexpr long double 
> std::abs(long double) ldiv_t std::div(long int, long int) 
> std::exception::exception() std::exception::exception() 
> std::exception::exception() std::bad_exception::bad_exception() 
> std::bad_exception::bad_exception() std::bad_exception::bad_exception() const 
> char* std::type_info::name() const bool std::type_info::operator!=(const 
> std::type_info&) const std::size_t std::type_info::hash_code() const 
> std::type_info::type_info(const char*) std::type_info::type_info(const char*) 
> std::type_info::type_info(const char*) std::bad_cast::bad_cast() 
> std::bad_cast::bad_cast() std::bad_cast::bad_cast() 
> std::bad_typeid::bad_typeid() std::bad_typeid::bad_typeid() 
> std::bad_typeid::bad_typeid() 
> std::__exception_ptr::exception_ptr::exception_ptr(std::nullptr_t) 
> std::__exception_ptr::exception_ptr::exception_ptr(std::nullptr_t) 
> std::__exception_ptr::exception_ptr::exception_ptr(std::nullptr_t) 
> std::__exception_ptr::exception_ptr::exception_ptr(std::__exception_ptr::exception_ptr&&)
>  
> std::__exception_ptr::exception_ptr::exception_ptr(std::__exception_ptr::exception_ptr&&)
>  
> std::__exception_ptr::exception_ptr::exception_ptr(std::__exception_ptr::exception_ptr&&)
>  std::__exception_ptr::exception_ptr& 
> std::__exception_ptr::exception_ptr::operator=(std::__exception_ptr::exception_ptr&&)
>  std::__exception_ptr::exception_ptr::operator bool() const void 
> std::__exception_ptr::swap(std::__exception_ptr::exception_ptr&, 
> std::__exception_ptr::exception_ptr&) void 
> std::__exception_ptr::__dest_thunk(void*) std::__exception_ptr::exception_ptr 
> std::make_exception_ptr(_Ex) constexpr _Tp* std::__addressof(_Tp&) constexpr 
> std::integral_constant<_Tp, __v>::operator std::integral_constant<_Tp, 
> __v>::value_type() const constexpr std::integral_constant<_Tp, 
> __v>::value_type std::integral_constant<_Tp, __v>::operator()() const 
> std::integral_constant constexpr const bool 
> std::integral_constant::value constexpr const bool 
> std::integral_constant::value std::integral_constant 
> constexpr const bool std::integral_constant::value constexpr 
> const bool std::integral_constant::value 
> std::integral_constant constexpr const short unsigned 
> int std::integral_constant::value constexpr const 
> short unsigned int std::integral_constant::value 
> std::__make_unsigned_selector_base::_List unsigned int, long unsigned int, long long unsigned int> 
> std::__make_unsigned_selector_base::_List long unsigned int, long long unsigned int> 
> std::__make_unsigned_selector_base::_List long long unsigned int> std::__make_unsigned_selector_base::_List unsigned int, long long unsigned int> 
> std::__make_unsigned_selector_base::_List 
> std::__make_unsigned_selector_base::_List<> constexpr const size_t 
> std::__make_unsigned_selector_base::_List::__size 
> constexpr const size_t std::__make_unsigned_selector_base::_List unsigned int>::__size constexpr const size_t 
> std::__make_unsigned_selector_base::_List unsigned int>::__size constexpr const size_t 
> std::__make_unsigned_selector_base::_List unsigned int>::__size constexpr const size_t 
> std::__make_unsigned_selector_base::_List long long unsigned int>::__size constexpr const size_t 
> std::__make_unsigned_selector_base::_List long long unsigned int>::__size constexpr const size_t 
> std::__make_unsigned_selector_base::_List long 

Re: ICE building a libsupc++ file, pdp11 target

[Richard Biener]

On Mon, Jul 16, 2018 at 11:30 PM Paul Koning  wrote:
>
>
>
> > On Jul 13, 2018, at 3:12 PM, U.Mutlu  wrote:
> >
> > Paul Koning wrote on 07/13/2018 08:56 PM:
> >>
> >>
> >>> On Jul 13, 2018, at 2:52 PM, U.Mutlu  wrote:
> >>>
> >>> Paul Koning wrote on 07/13/2018 08:27 PM:
>  I'm trying to see if I can build the pdp11 target for languages other 
>  than just C, and the answer is for the most part yes.  But I' running 
>  into an ICE I can't figure out.  It's way before the back end comes into 
>  the picture as far as I can see, and there's nothing particularly 
>  strange looking in the input file that suggests anything.
> 
>  Any suggestions on where to look?  The failure is:
> 
>  libtool: compile:  /Users/pkoning/Documents/svn/buildpdp+/./gcc/xgcc 
>  -shared-libgcc -B/Users/pkoning/Documents/svn/buildpdp+/./gcc 
>  -nostdinc++ 
>  -L/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/src 
>  -L/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/src/.libs
>   
>  -L/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/libsupc++/.libs
>   -B/usr/local/pdp11-aout/pdp11-aout/bin/ 
>  -B/usr/local/pdp11-aout/pdp11-aout/lib/ -isystem 
>  /usr/local/pdp11-aout/pdp11-aout/include -isystem 
>  /usr/local/pdp11-aout/pdp11-aout/sys-include 
>  -I/Users/pkoning/Documents/svn/gcc/libstdc++-v3/../libgcc 
>  -I/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/include/pdp11-aout
>   
>  -I/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/include 
>  -I/Users/pkoning/Documents/svn/gcc/libstdc++-v3/libsupc++ 
>  -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi 
>  -fdiagnostics-show-location=once -frandom-seed=new_opa.lo -g -O2 
>  -std=gnu++1z -c ../../../../gcc/l
> > ib
> >>> stdc++-v3/libsupc++/new_opa.cc -o new_opa.o
>  cc1plus: warning: -Wabi won't warn about anything [-Wabi]
>  cc1plus: note: -Wabi warns about differences from the most up-to-date 
>  ABI, which is also used by default
>  cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7
>  ../../../../gcc/libstdc++-v3/libsupc++/new_opa.cc:112:1: internal 
>  compiler error: in import_export_decl, at cp/decl2.c:2877
>   }
>   ^
>  libbacktrace could not find executable to open
>  Please submit a full bug report,
>  with preprocessed source if appropriate.
>  See  for instructions.
>  make[3]: *** [new_opa.lo] Error 1
> >>>
> >>>
> >>> It's failing at the last gcc_assert() below (file 
> >>> ../gcc_src/gcc/cp/decl2.c:2877 ):
> >>
> >> Sorry, I should have been more explicit.  I saw that, but my question is: 
> >> what is the underlying problem that triggers the assert?  The comment is 
> >> not much help to me.  And more specifically: what could a target be doing 
> >> wrong that would make an early stage of the compiler fail like this on 
> >> what seems like a pretty straightforward source file?
> >>
> >> Many of the other libstdc++ bits compile just fine, as do plenty of 
> >> testsuite cases and some test files of my own.
> >>
> >
> > /* In a VAR_DECL, FUNCTION_DECL, NAMESPACE_DECL or TYPE_DECL,
> >   nonzero means name is to be accessible from outside this translation unit.
> >   In an IDENTIFIER_NODE, nonzero means an external declaration
> >   accessible from outside this translation unit was previously seen
> >   for this name in an inner scope.  */
> > #define TREE_PUBLIC(NODE) ((NODE)->base.public_flag)
> >
> >
> > Ie. it has todo with the value of the member var public_flag of the tree 
> > decl.
>
> I'm still on the same question as before.  Why do I get an ICE in the tree 
> phase of the compiler, complaining about flags of a declaration, based on 
> something I apparently have wrong in my target description?  I can build C++ 
> for other targets, so this isn't a general bug.  But I'm not used to target 
> (back end) stuff affecting the compiler before I even get to the RTL part.  
> And in this case, looking at the failing code gives me no clue at all.  I 
> can't do anything with the "tree" object to find out what it describes; it's 
> a VAR_DECL but I don't know what to look at. I tried turning on tree dump 
> files, those gave no clue either.  And there is nothing in the manuals.

There is not enough information for anyone to help you without
reproducing the issue which is maybe too much to ask for ;)

Can you debug_tree () the offending decl in gdb?

> paul
>

Re: ICE building a libsupc++ file, pdp11 target

[Paul Koning]

> On Jul 13, 2018, at 3:12 PM, U.Mutlu  wrote:
> 
> Paul Koning wrote on 07/13/2018 08:56 PM:
>> 
>> 
>>> On Jul 13, 2018, at 2:52 PM, U.Mutlu  wrote:
>>> 
>>> Paul Koning wrote on 07/13/2018 08:27 PM:
 I'm trying to see if I can build the pdp11 target for languages other than 
 just C, and the answer is for the most part yes.  But I' running into an 
 ICE I can't figure out.  It's way before the back end comes into the 
 picture as far as I can see, and there's nothing particularly strange 
 looking in the input file that suggests anything.
 
 Any suggestions on where to look?  The failure is:
 
 libtool: compile:  /Users/pkoning/Documents/svn/buildpdp+/./gcc/xgcc 
 -shared-libgcc -B/Users/pkoning/Documents/svn/buildpdp+/./gcc -nostdinc++ 
 -L/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/src 
 -L/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/src/.libs 
 -L/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/libsupc++/.libs
  -B/usr/local/pdp11-aout/pdp11-aout/bin/ 
 -B/usr/local/pdp11-aout/pdp11-aout/lib/ -isystem 
 /usr/local/pdp11-aout/pdp11-aout/include -isystem 
 /usr/local/pdp11-aout/pdp11-aout/sys-include 
 -I/Users/pkoning/Documents/svn/gcc/libstdc++-v3/../libgcc 
 -I/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/include/pdp11-aout
  -I/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/include 
 -I/Users/pkoning/Documents/svn/gcc/libstdc++-v3/libsupc++ 
 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi 
 -fdiagnostics-show-location=once -frandom-seed=new_opa.lo -g -O2 
 -std=gnu++1z -c ../../../../gcc/l
> ib
>>> stdc++-v3/libsupc++/new_opa.cc -o new_opa.o
 cc1plus: warning: -Wabi won't warn about anything [-Wabi]
 cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, 
 which is also used by default
 cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7
 ../../../../gcc/libstdc++-v3/libsupc++/new_opa.cc:112:1: internal compiler 
 error: in import_export_decl, at cp/decl2.c:2877
  }
  ^
 libbacktrace could not find executable to open
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See  for instructions.
 make[3]: *** [new_opa.lo] Error 1
>>> 
>>> 
>>> It's failing at the last gcc_assert() below (file 
>>> ../gcc_src/gcc/cp/decl2.c:2877 ):
>> 
>> Sorry, I should have been more explicit.  I saw that, but my question is: 
>> what is the underlying problem that triggers the assert?  The comment is not 
>> much help to me.  And more specifically: what could a target be doing wrong 
>> that would make an early stage of the compiler fail like this on what seems 
>> like a pretty straightforward source file?
>> 
>> Many of the other libstdc++ bits compile just fine, as do plenty of 
>> testsuite cases and some test files of my own.
>> 
> 
> /* In a VAR_DECL, FUNCTION_DECL, NAMESPACE_DECL or TYPE_DECL,
>   nonzero means name is to be accessible from outside this translation unit.
>   In an IDENTIFIER_NODE, nonzero means an external declaration
>   accessible from outside this translation unit was previously seen
>   for this name in an inner scope.  */
> #define TREE_PUBLIC(NODE) ((NODE)->base.public_flag)
> 
> 
> Ie. it has todo with the value of the member var public_flag of the tree decl.

I'm still on the same question as before.  Why do I get an ICE in the tree 
phase of the compiler, complaining about flags of a declaration, based on 
something I apparently have wrong in my target description?  I can build C++ 
for other targets, so this isn't a general bug.  But I'm not used to target 
(back end) stuff affecting the compiler before I even get to the RTL part.  And 
in this case, looking at the failing code gives me no clue at all.  I can't do 
anything with the "tree" object to find out what it describes; it's a VAR_DECL 
but I don't know what to look at. I tried turning on tree dump files, those 
gave no clue either.  And there is nothing in the manuals.

paul

Re: ICE building a libsupc++ file, pdp11 target

[Paul Koning]

> On Jul 13, 2018, at 2:52 PM, U.Mutlu  wrote:
> 
> Paul Koning wrote on 07/13/2018 08:27 PM:
>> I'm trying to see if I can build the pdp11 target for languages other than 
>> just C, and the answer is for the most part yes.  But I' running into an ICE 
>> I can't figure out.  It's way before the back end comes into the picture as 
>> far as I can see, and there's nothing particularly strange looking in the 
>> input file that suggests anything.
>> 
>> Any suggestions on where to look?  The failure is:
>> 
>> libtool: compile:  /Users/pkoning/Documents/svn/buildpdp+/./gcc/xgcc 
>> -shared-libgcc -B/Users/pkoning/Documents/svn/buildpdp+/./gcc -nostdinc++ 
>> -L/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/src 
>> -L/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/src/.libs 
>> -L/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/libsupc++/.libs
>>  -B/usr/local/pdp11-aout/pdp11-aout/bin/ 
>> -B/usr/local/pdp11-aout/pdp11-aout/lib/ -isystem 
>> /usr/local/pdp11-aout/pdp11-aout/include -isystem 
>> /usr/local/pdp11-aout/pdp11-aout/sys-include 
>> -I/Users/pkoning/Documents/svn/gcc/libstdc++-v3/../libgcc 
>> -I/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/include/pdp11-aout
>>  -I/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/include 
>> -I/Users/pkoning/Documents/svn/gcc/libstdc++-v3/libsupc++ 
>> -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi 
>> -fdiagnostics-show-location=once -frandom-seed=new_opa.lo -g -O2 
>> -std=gnu++1z -c ../../../../gcc/lib
> stdc++-v3/libsupc++/new_opa.cc -o new_opa.o
>> cc1plus: warning: -Wabi won't warn about anything [-Wabi]
>> cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, 
>> which is also used by default
>> cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7
>> ../../../../gcc/libstdc++-v3/libsupc++/new_opa.cc:112:1: internal compiler 
>> error: in import_export_decl, at cp/decl2.c:2877
>>  }
>>  ^
>> libbacktrace could not find executable to open
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See  for instructions.
>> make[3]: *** [new_opa.lo] Error 1
> 
> 
> It's failing at the last gcc_assert() below (file 
> ../gcc_src/gcc/cp/decl2.c:2877 ):

Sorry, I should have been more explicit.  I saw that, but my question is: what 
is the underlying problem that triggers the assert?  The comment is not much 
help to me.  And more specifically: what could a target be doing wrong that 
would make an early stage of the compiler fail like this on what seems like a 
pretty straightforward source file?

Many of the other libstdc++ bits compile just fine, as do plenty of testsuite 
cases and some test files of my own.

paul

ICE building a libsupc++ file, pdp11 target

[Paul Koning]

I'm trying to see if I can build the pdp11 target for languages other than just 
C, and the answer is for the most part yes.  But I' running into an ICE I can't 
figure out.  It's way before the back end comes into the picture as far as I 
can see, and there's nothing particularly strange looking in the input file 
that suggests anything.

Any suggestions on where to look?  The failure is:

libtool: compile:  /Users/pkoning/Documents/svn/buildpdp+/./gcc/xgcc 
-shared-libgcc -B/Users/pkoning/Documents/svn/buildpdp+/./gcc -nostdinc++ 
-L/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/src 
-L/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/src/.libs 
-L/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/libsupc++/.libs
 -B/usr/local/pdp11-aout/pdp11-aout/bin/ 
-B/usr/local/pdp11-aout/pdp11-aout/lib/ -isystem 
/usr/local/pdp11-aout/pdp11-aout/include -isystem 
/usr/local/pdp11-aout/pdp11-aout/sys-include 
-I/Users/pkoning/Documents/svn/gcc/libstdc++-v3/../libgcc 
-I/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/include/pdp11-aout
 -I/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/include 
-I/Users/pkoning/Documents/svn/gcc/libstdc++-v3/libsupc++ 
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi 
-fdiagnostics-show-location=once -frandom-seed=new_opa.lo -g -O2 -std=gnu++1z 
-c ../../../../gcc/libstdc++-v3/libsupc++/new_opa.cc -o new_opa.o
cc1plus: warning: -Wabi won't warn about anything [-Wabi]
cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, 
which is also used by default
cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7
../../../../gcc/libstdc++-v3/libsupc++/new_opa.cc:112:1: internal compiler 
error: in import_export_decl, at cp/decl2.c:2877
 }
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [new_opa.lo] Error 1

paul