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 Mon, Jul 16, 2018 at 11:30 PM Paul Koning <paulkoning@comcast.net> wrote:
>
>
>
> > 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.
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
>