[llvm-bugs] [Bug 28629] Clang generates calls to __mulodi4() for ARM even when not using compiler-rt

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=28629

Stephen Hines <srhines at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #4 from Stephen Hines <srhines at google.com> ---
(In reply to comment #3)
> (In reply to comment #2)
> > The default for Clang is to not use compiler-rt as its rtlib though.
> 
> This is not true in all platforms.
> 
> 
> > It also should be aware of what rtlib is requested at the point where it decides
> > that these functions are available.
> 
> This is an interesting proposition, but not always possible. The compiler
> doesn't have to know how the linker will behave and which libraries will be
> linked. If you compile to object than link it, but only use the -lgcc or
> -lcompiler-rt at link time, the compiler has *no way* to know which.

If the default for the platform is libgcc (i.e. !compiler-rt), and no -rtlib
option was passed, it seems like it would be nicer for Clang to not use
functions that might not be implemented. At the very least it could warn about
this problematic case.

> 
> Plus, the __has_builtin is really asking the *compiler* for support, not the
> linker nor the libraries. 
> 
> The user code is *clearly* abusing of compiler specific behaviour and not
> getting what they "wanted", but getting what they should have gotten.

I guess they misunderstood the use of __has_builtin, but I can't blame them. I
clearly didn't think that this was a user bug, and fully believed this was
entirely a compiler issue.

> 
> 
> > Essentially this makes using libgcc with Clang increasingly difficult and error-prone.
> 
> I agree with you 100%. But how many compilers out there are trying to use
> two run-time libraries?

I think Clang is in a unique situation here. How many of Clang's targets
actually use compiler-rt? How often is compiler-rt used in production software?
I don't have a great answer to those questions. I certainly would hope things
are heading towards using compiler-rt more often, but I don't have evidence of
that.

> 
> 
> > Workarounds are possible
> > (Android regularly bundles the compiler-rt extras beyond libgcc in their own
> > library), but they are ugly.
> 
> I'd say that code in Skia is ugly. I wouldn't work around in Android at all,
> just ask the developer to fix the code.

It is actually in yet another library that Skia is pulling in, so the path to
fix gets longer.

> 
> 
> > These users don't want to use compiler-rt,
> > mostly because we haven't finished validating/establishing it for the
> > Android platform/NDK yet.
> 
> Well, that's a hard sell. They ask for a compiler-rt specific function but
> don't want to link compiler-rt. I really don't know what to say...

They want to link compiler-rt. We just can't provide it in a working form
today, because it isn't ready yet for Android.

> 
> If this was Clang generating the builtin from C code, I'd agree with you
> that it was a bug and needed to be fixed. But the code is specifically
> asking for a compiler-rt builtin, via a compiler support flag.
> 
> I can't see how this is *not* user error.

I will communicate this to them, and hopefully get this fixed a different way.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160720/83606d50/attachment.html>