gm2
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gm2] gcc-5.2.0 and gm2 (still fails on Solaris/Sparc)


From: Gaius Mulley
Subject: Re: [Gm2] gcc-5.2.0 and gm2 (still fails on Solaris/Sparc)
Date: Sat, 18 Mar 2017 10:24:53 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

john o goyo <address@hidden> writes:

> Gaius:
>
> On 15/03/2017 04:55, Gaius Mulley wrote:
>> Hello,
>>
>> gm2 now builds cleanly when grafted onto gcc-5.2.0.
> The problem persists (this with the tarball of 2017-03-14:
>
> In function 'ShiftLeft':
> cc1gm2: internal compiler error: Illegal Instruction
> 0x7879b7 crash_signal
>         ../../../src/gcc-5.2.0+gm2-20170314/gm2/gcc-versionno/gcc/toplev.c:383
> 0x182023 m2expr_BuildBinarySetDo
>         
> ../../../src/gcc-5.2.0+gm2-20170314/gm2/gcc-versionno/gcc/gm2/gm2-gcc/m2expr.c:650
> [...]
>
>
> As you have no Solaris/Sparc box to work on, is there something that I
> can do on my end?
>

Hi John,

yes I think it might be interesting if you could add the following lines
inside m2expr_BuildBinarySetDo:

void
m2expr_BuildBinarySetDo (location_t location, tree settype, tree op1, tree op2, 
tree op3,
                         void (*binop)(location_t, tree, tree, tree, tree, int),
                         int is_op1lvalue, int is_op2lvalue, int is_op3lvalue,
                         tree nBits,
                         tree unbounded,
                         tree varproc, tree leftproc, tree rightproc)
{
  tree size     = m2expr_GetSizeOf (location, settype);
  int  is_const = FALSE;
  int  is_left  = FALSE;

  m2assert_AssertLocation (location);

  ASSERT_BOOL (is_op1lvalue);
  ASSERT_BOOL (is_op2lvalue);
  ASSERT_BOOL (is_op3lvalue);

  pe (op1);   /* six new lines.  */
  pe (op2);
  pe (op3);
  debug_tree (op1);
  debug_tree (op2);
  debug_tree (op3);

and then manually run the compiler on the particular file causing the
crash.  Thereafter it might also be great to run it under the debugger
(gdb) and set a breakpoint on m2expr_BuildBinarySetDo and run it.
Assuming that there are not millions of calls to m2expr_BuildBinarySetDo
then single stepping until the line of failure would be very useful.

You can call debug_tree to print out trees interactively in gdb via:

print debug_tree(op1)

or

print pe(op1)

which is useful as you approach the line of code which causes the crash.
debug_tree dumps the tree to stdout in a lispish like syntax.  Whereas
pe prints the expression in Modula-2.  Be careful with 'pe' as it must be
an expression, if in doubt use 'pf', print function, which is alot more
robust in detecting the kind of tree.  It will print functions, types
and expressions in Modula-2.  debug_tree gives much more detail but
sometimes the synopsis of 'pf' allows one to see the wood from the
trees.  There is also 'pt' print the type of tree in Modula-2 syntax

regards,
Gaius





reply via email to

[Prev in Thread] Current Thread [Next in Thread]