Jeroen Demeyer wrote:
On 2013-01-06 06:23, leif wrote:
Unless one specifies '-O2' or higher ('-finline*' doesn't work either),
the GNU __inline__ function doesn't get inlined, which is in principle
ok, but Clang doesn't emit code for it either, hence the linker error.
(FWIW, '-std=gnu*' doesn't seem to make any difference.)
If clang:
* doesn't inline e(),
* references the function e() as a function call,
* but doesn't actually generates code for e(),
I'd say that's a bug in clang.
Well, if you expect Clang to be "fully" compatible with GCC, then yes.
(Note that this only applies to GNU __inline__ functions, not C/C++
inline functions.)
Nevertheless, MPIR's failing 'configure' tests aren't meant for Clang
(and try to trigger other bugs, in particular of broken *GCC* versions),
and pretty easy to fix. [I've so far successfully built 32-bit and
64-bit versions of MPIR 2.6.0 with Clang 3.1 (incidentally also with a
mixture of 'clang' and 'g++'), with '-O0' as well as (implicitly) '-O2';
'make check' passed in each case. That's still on Linux though; I'll
try what happens on MacOS X later.]
I'm [currently] not intending to make Sage fully build with Clang, but
IMHO bootstrapping our GCC should work with Clang as well (including the
case when SAGE_DEBUG happens to be set to "yes"). (Not yet sure about
Apple's /old/ Clang 1.7. On MacOS X systems with that version, we can
probably rely on -- or, more precisely, require -- [at least] Apple's
GCC 4.0.1 or 4.2.1.)
I think if MPIR 2.6.0 gets into Sage within reasonable time, we don't
need to fix our 2.4.0 spkg, although doing so is trivial (just a matter
of time...).
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
