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

Reply via email to