http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
--- Comment #15 from Ondrej Bilka <neleai at seznam dot cz> --- On Thu, Jul 04, 2013 at 07:46:07PM +0000, glisse at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776 > > --- Comment #14 from Marc Glisse <glisse at gcc dot gnu.org> --- > (In reply to Jakub Jelinek from comment #12) > > Not all CPUs that have defined behavior for 0 define it to the precision > > though, and even on i?86 it is undefined even when using lzcnt/tzcnt on > > older CPUs. > > Even the libgcc routines provide various return values for 0 depending on > > target (look for COUNT_LEADING_ZEROS_0). > > So it is not an option to redefine the builtins, they are undefined behavior > > for 0 and that can't change. > > I didn't mean to document the value for 0 or have other optimizations create > calls to this builtin relying on this property. I just meant that if we > already > have a call to clz and the argument happens to be 0 (which is undefined), we > could optimize based on the assumption that the result is the precision, that > may break less code than your current patch. Otherwise we might as well assert > (well, tell it to VRP) that the argument is non-zero. > > But you are probably right that trying to work around the undefined value for > 0 > is wrong, another builtin should be used instead. > Wait, when user triggers undefined behaviour anything is possible. So we can change return value and be still correct, rigth?
