RFC: Jump to const_int

RFC: Jump to const_int

[John David Anglin]

Flow aborts in make_edges if it finds a plain or unconditional jump that
isn't to a label:

          /* Otherwise, we have a plain conditional or unconditional jump.  */
	  else
	    {
	      if (! JUMP_LABEL (insn))
		abort ();
	      make_label_edge (edge_cache, bb, JUMP_LABEL (insn), 0);
	    }

In reviewing the testsuite failures on the vax reported here

< http://gcc.gnu.org/ml/gcc-testresults/2001-01/msg00080.html >,

I found the following testcase fails (991213-3.c) with the above abort:

int jump () { goto * (int (*) ()) 0xbabebec0; }

The rtl generated for jump () is:

;; Function jump

(note 2 0 3 NOTE_INSN_DELETED -1347440721)

(note 3 2 8 NOTE_INSN_FUNCTION_BEG -1347440721)

(jump_insn 8 3 9 (set (pc)
        (const_int -1161904448 [0xbabebec0])) -1 (nil)
    (nil))

(barrier 9 8 0)

This is not a computed jump because jmp_uses_reg_or_mem only accepts a
REG or MEM that is not in the constant pool.

Changing the predicate for the indirect_jump insn to register_operand
might hide the problem.  I think that this would make the jump look like
a computed jump.  However, this doesn't seem like the correct solution
since the above jump is effectively an exit.

Should make_edges be changed to recognize a jump to CONST_INT or are
there problems in doing this?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: RFC: Jump to const_int

[Fergus Henderson]

On 12-Jan-2001, John David Anglin <dave@hiauly1.hia.nrc.ca> wrote:
> > I found the following testcase fails (991213-3.c) with the above abort:
> > 
> > int jump () { goto * (int (*) ()) 0xbabebec0; }
> 
> One further thought.  The test looks bogus to me because the address
> clearly can't be in the current function.  Thus, the behavior of such
> a jump is totally unpredictable.
>
> Gcc allows as an extension goto's to any void * expression.  Thus, the
> above is accepted but it will clearly cause problems when edges are
> to be calculated.

The *runtime* behaviour of such a jump is unpredictable.
It should be a runtime error, and a compile-time warning might be nice,
but it should not be a compile-time error and nor should the compiler
get an internal compiler error.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: RFC: Jump to const_int

[John David Anglin]

> I found the following testcase fails (991213-3.c) with the above abort:
> 
> int jump () { goto * (int (*) ()) 0xbabebec0; }

One further thought.  The test looks bogus to me because the address
clearly can't be in the current function.  Thus, the behavior of such
a jump is totally unpredictable.

Gcc allows as an extension goto's to any void * expression.  Thus, the
above is accepted but it will clearly cause problems when edges are
to be calculated.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)