This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ICE building a libsupc++ file, pdp11 target
> On Jul 13, 2018, at 3:12 PM, U.Mutlu <um@mutluit.com> wrote:
>
> Paul Koning wrote on 07/13/2018 08:56 PM:
>>
>>
>>> On Jul 13, 2018, at 2:52 PM, U.Mutlu <um@mutluit.com> 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 <https://gcc.gnu.org/bugs/> 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