------- 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
