Problem updating 2yr old port

Problem updating 2yr old port

[Christian Grössler]

Hello,

I'm trying to make a port to a new architecture work on the current gcc. There hasn't been any work
done on this port since Nov-2008.

The compiler builds now, but I'm getting an ICE when I try to compile a program.

---------
X:
--
(mem/f/c/i:PSI (plus:PSI (reg/f:PSI 87 virtual-stack-vars)
         (const_int -12 [0xfffffff4])) [0 str+0 S4 A32])
Y:
--
(const_int 0 [0])
--

In file included from /cool/tmp/argz_add.c:7:0:
/cool/merge/cool-gcc/src/newlib/libc/include/argz.h: In function 'argz_add':
/cool/merge/cool-gcc/src/newlib/libc/include/argz.h:23:9: internal compiler error: in prepare_cmp_insn, at optabs.c:4159
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
----------

These "X" and "Y" messages are debug messages which I've added with print_inline_rtx().

The offending line in the source file is

   if (str == NULL)
     return 0;

str is a "const char *". Pointers are using PSI mode on this architecture, since they are only 20 bits wide.

The inputs x and y to prepare_cmp_insn are in PSImode and VOIDmode, and it seems
the compiler cannot compare these modes anymore.

The old version of prepare_cmp_insn() called can_compare_p() at this point which returned success and all was well.
Now can_compare_p() is only called for MODE_CC modes.

Looking at the history of optabs.c, the MODE_CC test was introduced when merging the cond-optab branch
to main. I didn't find a description of the cond-optab branch and what it was supposed to do.

Can anybody give me some hints how to continue from here? I'm rather new to gcc hacking and don't have
yet the big picture of a gcc backend. Not even the details. :-)

regards,
chris

Re: Problem updating 2yr old port

[Ian Lance Taylor]

Christian Grössler <chris@groessler.org> writes:

> Looking at the history of optabs.c, the MODE_CC test was introduced when merging the cond-optab branch
> to main. I didn't find a description of the cond-optab branch and what it was supposed to do.

This is the description of the now-merged cond-optab branch, from
http://gcc.gnu.org/ml/gcc/2009-04/msg00211.html :

    This branch is to clean up and simplify the implementation of
    conditional operations (branches, stores, moves, etc.) in expand and
    in the machine descriptions.  Patches should be marked with the tag
    [cond-optab] in the subject line.  The branch is maintained by Paolo
    Bonzini.  Pending further testing, the branch is ready to be merged
    into mainline and only bug and documentation fixes should be
    committed.

As I recall the basic idea was to generate all conditional branches via
the cbranchMODE4 pattern rather than using separate compare and branch
patterns.

I couldn't figure out which assertion you hit so I'm not sure what else
to say.  A const_int is always VOIDmode, and there should be no problem
comparing a value to a const_int.

Ian

Re: Problem updating 2yr old port

[Christian Grössler]

On 28.12.10 00:22, Ian Lance Taylor wrote:
> Christian Grössler<chris@groessler.org>  writes:
>
>> Looking at the history of optabs.c, the MODE_CC test was introduced when merging the cond-optab branch
>> to main. I didn't find a description of the cond-optab branch and what it was supposed to do.
>
> This is the description of the now-merged cond-optab branch, from
> http://gcc.gnu.org/ml/gcc/2009-04/msg00211.html :
>
>      This branch is to clean up and simplify the implementation of
>      conditional operations (branches, stores, moves, etc.) in expand and
>      in the machine descriptions.  Patches should be marked with the tag
>      [cond-optab] in the subject line.  The branch is maintained by Paolo
>      Bonzini.  Pending further testing, the branch is ready to be merged
>      into mainline and only bug and documentation fixes should be
>      committed.
>
> As I recall the basic idea was to generate all conditional branches via
> the cbranchMODE4 pattern rather than using separate compare and branch
> patterns.

Yeah, so I seem to need to add a cbranchMODE4 pattern. I tried it, but it didn't help.
Probably because I'm not fit enough yet to write a proper pattern (I copied one from
ia64 and modified it to see if it gets picked up, but it didn't happen).


> I couldn't figure out which assertion you hit so I'm not sure what else
> to say.  A const_int is always VOIDmode, and there should be no problem
> comparing a value to a const_int.

Sorry, the line numbers in the ICE are wrong, since I added some debug messages.
The abort happens here in prepare_cmp_insn():

       /* Handle a libcall just for the mode we are using.  */
       libfunc = optab_libfunc (cmp_optab, mode);
       gcc_assert (libfunc);    <------ HERE


regards,
chris

Re: Problem updating 2yr old port

[Ian Lance Taylor]

Christian Grössler <chris@groessler.org> writes:

> Sorry, the line numbers in the ICE are wrong, since I added some debug messages.
> The abort happens here in prepare_cmp_insn():
>
>       /* Handle a libcall just for the mode we are using.  */
>       libfunc = optab_libfunc (cmp_optab, mode);
>       gcc_assert (libfunc);    <------ HERE

Seems like you don't have a cbranchMODE4 insn in the required mode.
Double check that.  You should only get to that assert if there is no
cbranch pattern.  To assert is indicating that if there is no cbranch
pattern there has to be a cmp pattern.  gcc doesn't have any other
options for a compare-and-branch.

Ian

Re: Problem updating 2yr old port

[Christian Grössler]

Hello Ian,

On 28.12.10 06:37, Ian Lance Taylor wrote:
> Seems like you don't have a cbranchMODE4 insn in the required mode.
> Double check that.  You should only get to that assert if there is no
> cbranch pattern.  To assert is indicating that if there is no cbranch
> pattern there has to be a cmp pattern.  gcc doesn't have any other
> options for a compare-and-branch.

cbranchpsi4 was missing. Now I'm a step further. Thanks.

regards,
chris