Kai Henningsen wrote:
This is genopinit.c:92 (sdivv_optab) (in revision 127595).
I read this as "the next mode must be a full integer mode; add a v if it
is a float mode". Which is doubly strange as this is the only place
where $V is used.
Am I missing something here, or is this a bug?
It looks like a bug to me. The sdivv_optab rule should look like the
addv/subv/smulv optab rules. Probably an oversight because this code is
not immediately next to the rest of the code, and there is no target
using this optab, so it went unnoticed.
I also can't help but notice that none of the named patterns here are
documented. There is no mention of addv, subv, smulv, sdivv, negv, or
absv in doc/md.texi.
One more thing, there is no divvsi3/divvdi3 in libgcc, nor in
doc/libgcc.texi. This implies that if we fix the genopinit.c bug we may
end up exposing a latent bug in libgcc. Hmm, maybe there is no need for
sdivv as many targets already trap on divide overflow, or to say it
differently, most users accept the fact that integer divide might trap,
even without -ftrapv, and hence a target doesn't have to use sdivv for a
trapping integer divide. In fact, looking at optabs.c, I see that there
is no use of sdivv here, where as the others listed above are clearly
used with -ftrapv. I think we can just delete all sdivv optab support
from optabs.c, optabs.h, and genopinit.c, plus the $V operator from
genopinit.c.
The code was added here
http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00607.html
Another interesting point, the ChangeLog entry doesn't mention the
addition of $V.
You want to try writing a patch, or maybe just file a formal bug report?
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
