This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]