------- Comment #33 from rakdver at kam dot mff dot cuni dot cz 2007-11-27 19:42 ------- Subject: Re: [4.3 regression] udivdi3 counterproductive, unwarranted use
> > ------- Comment #29 from rguenth at gcc dot gnu dot org 2007-11-27 09:43 > > ------- > > This is IMHO at most a QOI issue - at Novell we mark timespec_add_ns's u64 > > parameter as volatile to work around this issue. I expect upstream to adopt > > a workaround as well. Note that some targets in the kernel have parts of > > libgcc implemented, but i?86 misses at least __udivdi3. > > I am not a kernel developer, but my feeling as a GCC developer is that > you must provide the entry points in libgcc whenever you are linking > code compiled with GCC. In other words, that GCC should be free to use > functions from libgcc as it pleases. I would agree with this. Even if we somehow prevent gcc from using __udivdi3 in this particular case, there is no guarantee that gcc will not decide to use this or some other function from the libgcc runtime at some other place (unless we decide to have some kind of -dont-use-libgcc flag, which would however be a bit difficult to implement, and it would make us fail to compile some valid codes). > Of course, it might be a GCC optimization bug to call __udivdi3; perhaps > it could generate more efficient code that doesn't call that function. Definitely. It is particularly annoying that this is the case where the programmer went through the pain of avoiding the usage of division, just to have it "optimized" back in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
