Created attachment 32776 [details] compressed build log Building an SH cross GCC on OSX with clang results in the following errors: ../../gcc-trunk/gcc/wide-int.cc:1269:23: error: invalid use of a cast in a inline asm context requiring an l-value: remove the cast or build with -fheinous-gnu-extensions umul_ppmm (val[1], val[0], op1.ulow (), op2.ulow ()); ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../../gcc-trunk/gcc/../include/longlong.h:505:24: note: expanded from macro 'umul_ppmm' : "=a" ((UDItype) (w0)), \ ^ ../../gcc-trunk/gcc/wide-int.cc:1269:15: error: invalid use of a cast in a inline asm context requiring an l-value: remove the cast or build with -fheinous-gnu-extensions umul_ppmm (val[1], val[0], op1.ulow (), op2.ulow ()); ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../../gcc-trunk/gcc/../include/longlong.h:506:24: note: expanded from macro 'umul_ppmm' "=d" ((UDItype) (w1)) \ ^ ../../gcc-trunk/gcc/wide-int.cc:1278:22: error: invalid use of a cast in a inline asm context requiring an l-value: remove the cast or build with -fheinous-gnu-extensions umul_ppmm (upper, val[0], op1.ulow (), op2.ulow ()); ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../../gcc-trunk/gcc/../include/longlong.h:505:24: note: expanded from macro 'umul_ppmm' : "=a" ((UDItype) (w0)), \ ^ ../../gcc-trunk/gcc/wide-int.cc:1278:15: error: invalid use of a cast in a inline asm context requiring an l-value: remove the cast or build with -fheinous-gnu-extensions umul_ppmm (upper, val[0], op1.ulow (), op2.ulow ()); ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../../gcc-trunk/gcc/../include/longlong.h:506:24: note: expanded from macro 'umul_ppmm' "=d" ((UDItype) (w1)) The full log is attached, which shows also other (spurious) warnings. The problem can be worked around by setting export CFLAGS="-fheinous-gnu-extensions" export CXXFLAGS="-fheinous-gnu-extensions" export CFLAGS_FOR_TARGET="-O2" export CXXFLAGS_FOR_TARGET="-O2" The *FLAGS_FOR_TARGET are required or else they will be set to *FLAGS, which will pass -fheinous-gnu-extensions to the SH xgcc when building libgcc etc. (PR 25672) The clang version on my OSX system: clang -v Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.1.0 Thread model: posix
The cast is useless so it is ignored by gcc. Anyways this inline-asm is a gcc extension so this is not a bug at all unless the inline-asm is not not bounded by a check for gnu c++. Clang should not be saying it supports gnu c++ unless it really supports it.
#if defined (__GNUC__) && !defined (NO_ASM) not a GCC source bug. Rather Clang should not define __GNUC__ at all. This is the same issue with ICC really we had declared that they both falsely define __GNUC__ when they don't implement the full GNU C/C++ extensions. Please file a bug report to clang to have them stop defining __GNUC__.
These casts still look like a bad idea to me. GMP's version of longlong.h removed the lvalue casts in 2005, and I don't see the point of keeping them here. Can we pretend the PR wasn't caused by using clang and consider it a cleanup?
(In reply to Oleg Endo from comment #0) > The *FLAGS_FOR_TARGET are required or else they will be set to *FLAGS, which > will pass -fheinous-gnu-extensions to the SH xgcc when building libgcc etc. > (PR 25672) It is funny that Clang has a flag called "heinous-gnu-extensions". I wonder what other things are enabled by that (what they think are heinous GNU extensions and why).
*** Bug 61315 has been marked as a duplicate of this bug. ***
Don't worry, gcc will build with clang.
Patch posted https://gcc.gnu.org/ml/gcc/2014-05/msg00316.html
Alternative patch committed to trunk. Fixed.
Thanks.
It is fixed, isn't it?
Yes, weird, thanks.
(In reply to mrs@gcc.gnu.org from comment #11) > Yes, weird, thanks. A find that gcc trunk at r211023 bootstrap fines against the clang 3.4svn-based compilers from Xcode 5.1.1. However I am still puzzled why, considering that it is agreed that the casts are useless and ignored by gcc, why they weren't just removed? I did find that freebsd has been doing this… http://svnweb.freebsd.org/base/head/contrib/gcc/longlong.h?view=patch&r1=211505&r2=211504&pathrev=211505
Because they are not ignored and are not useless.
> Because they are not ignored and are not useless. See https://gcc.gnu.org/ml/gcc/2014-05/msg00332.html.
Short answer, error checking. Remove them and one removes some error checking.
(In reply to Mike Stump from comment #15) > Short answer, error checking. Remove them and one removes some error > checking. Will the current fix have any impact on our having the complete wide-int functionality on darwin?
The changelog was wrong. This is why bugzilla didn't catch the commit. It should have said: PR bootstrap/61146 instead of PR bootstrap/PR61146 It would be nice to have a commit hook that catches this kind of thing.
Revision 211023 Author: fxcoudert Date: Wed May 28 15:17:29 2014 UTC (4 hours, 39 minutes ago) Log Message: PR bootstrap/PR61146 * wide-int.cc: Do not include longlong.h when compiling with clang.
Nope.