[GCC-XML] internal error with 0.9.0

[Steve Vinoski]

Right, debugging gccxml_cc1plus instead of gccxml let me hit the
breakpoint, but I didn't get very far after that. I'm not very
familiar with the innards of gcc, so debugging it is not easy.

But given that g++ 4.2 doesn't have any issues with that code, I
thought maybe I could look through recent gcc patches to find the fix.
I looked through a number of patches and also through the gcc sources
a fair bit, but so far, no luck.

So, back to your print statement suggestion: is there a way to tell
gcc to dump what it's parsing so that I could compare dumped output
from g++ 4.2 to dumped output from gccxml on that little test case, to
see where they diverge? That might help zero in on the problem.

thanks,
--steve

On 2/10/08, David Cole <david.cole at kitware.com> wrote:
> When you debug gccxml, it spawns another process to handle the actual
> compile step. You have to debug that spawned process. Use "--debug" (I
> think) to see the command line for the spawned process. Or look through the
> source code for gccxml's main to figure out how to grok the command line for
> the spawned process...
>
> Or, instead of debuggers/breakpoints, use good old-fashioned print
> statements to send some diagnostic output to stdout...
>
>
>
>
> On 2/10/08, Steve Vinoski <vinoski at ieee.org> wrote:
> > Great, thanks. The code causing the internal error actually comes from
> > the Boost library, file boost/pending/integer_log2.hpp from Boost
> > 1.34, and specifically this construct:
> >
> > template <int p, int n>
> > struct max_pow2_less {
> >       enum { c = 2*n < p };
> >       static const int value = c ? (max_pow2_less< c*p, 2*c*n>::value) :
> n;
> > };
> >
> > It's specifically the definition of the "value" static const int
> > variable that causes the problem. Here's one possible workaround:
> >
> > enum { c = 2*n < p, next_p = c*p, next_n = 2*c*n };
> > static const int value = c ? (max_pow2_less< next_p, next_n>::value) : n;
> >
> > I tried to put a breakpoint at tree.c:4582, indicated in the internal
> > compiler error message, but it never hit it.
> >
> > Any further suggestions for how to proceed with tracking this down and
> > fixing it?
> >
> > thanks,
> > --steve
> >
> > On 2/9/08, David Cole <david.cole at kitware.com> wrote:
> > > When configuring with CMake, set CMAKE_BUILD_TYPE to Debug for a
> makefile
> > > based build. (Or if building with Visual Studio or Xcode, just build the
> > > Debug configuration...)
> > >
> > >  HTH,
> > > Dave
> > >
> > >
> > >
> > > On 2/9/08, Steve Vinoski <vinoski at ieee.org> wrote:
> > > >
> > > > Apologies if this has already been covered; I just joined the list and
> > > > searched for this issue but didn't find anything.
> > > >
> > > > With gccxml 0.9.0 built against sources fresh out of cvs and running
> > > > against a gcc 4.2.2 compiler installation, I see this error with a
> > > > number of files that compile fine with straight g++ 4.2.2:
> > > >
> > > > internal compiler error: tree check: expected integer_cst, have
> > > > lt_expr in tree_int_cst_sgn, at tree.c:4582
> > > >
> > > > Has anyone else seen this? If not, any recommendations for debugging
> > > > it? Sending preprocessed output isn't possible. Are there instructions
> > > > available anywhere for building a debuggable gccxml?
> > > >
> > > > thanks,
> > > > --steve
> > > > _______________________________________________
> > > > gccxml mailing list
> > > > gccxml at gccxml.org
> > > > http://www.gccxml.org/mailman/listinfo/gccxml
> > > >
> > >
> > >
> >
>
>