[Bug middle-end/23369] [4.0/4.1 regression] build_range_check generates wrong code for funcptr comparison

[dave at hiauly1 dot hia dot nrc dot ca]

------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2005-08-15 17:24 -------
Subject: Re:  [4.0/4.1 regression] build_range_check generates wrong code for funcptr comparison

> Subject: Re:  [4.0/4.1 regression] build_range_check
>  generates wrong code for funcptr comparison
> 
> >>1) gcc should not be canonicalizing constants casted as function pointers
> > 
> > I think it has to.  GCC has no way of knowing whether the constant is
> > a "real" function pointer or not.
> 
> Doesn't this break __cffc completely? What if I really wanted to do "if 
> (fptr == (func_t)-2)" or "if (fptr == (func_t)5000)?

Why would you want to?  My opinion is that __cffc only has to deal
with the values traditionally used by "signal".  GCC doesn't know
whether (func_t)5000 needs to be canonicalized or not.  It will
happen anyway if (func_t)5000 is passed around.

The behavior of __cffc was more or less copied from the corresponding
HP routine.  __cffc expects to be passed a valid function pointer.
Currently, __cffc doesn't canonicalize small positive integers and -1
because they are used by signal and friends, and they can't be a valid
function pointer address.  I guess this might be extended somewhat but 
the point.  Nobody has defined what's ok.

When the plabel bit is set in the function pointer, __cffc has to
load data from the function descriptor and this can cause a segmentation
fault if the address isn't valid.  I don't think trying to avoid these
faults is worth the added complexity.  This will eventually go away when
Carlos' opd patch is installed.

I also think that the definitions of SIG_IGN, etc., are suspect.
These problems wouldn't occur if there were actual functions in the
C library for them.

There are also ways to avoid canonicalization in compares.  I recognize
that this problem is in generic code.  However, it might be possible
to replace the generic routine with a hppa specific routine that avoids
canonicalization when comparing a function pointer with a special value.
This would make the code more efficient.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23369