diff mbox

package/gcc: disable libitm for sparc <v9

Message ID 1421281784-5243-1-git-send-email-gustavo@zacarias.com.ar
State Accepted
Headers show

Commit Message

Gustavo Zacarias Jan. 15, 2015, 12:29 a.m. UTC
libitm (transactional memory) needs SPARC V9+ ISA, otherwise when
enabling C++ the toolchain fails to build:

/tmp/cclQ6hrD.s: Assembler messages:
/tmp/cclQ6hrD.s:1261: Error: Architecture mismatch on "rd".
/tmp/cclQ6hrD.s:1261:  (Requires v9|v9a|v9b; requested architecture is
v8.)
Makefile:517: recipe for target 'beginend.lo' failed
make[5]: *** [beginend.lo] Error 1

So disable it for our current (v8, leon3) support.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 package/gcc/gcc.mk | 5 +++++
 1 file changed, 5 insertions(+)

Comments

Thomas Petazzoni Jan. 15, 2015, 8:37 a.m. UTC | #1
Dear Gustavo Zacarias,

On Wed, 14 Jan 2015 21:29:44 -0300, Gustavo Zacarias wrote:
> libitm (transactional memory) needs SPARC V9+ ISA, otherwise when
> enabling C++ the toolchain fails to build:
> 
> /tmp/cclQ6hrD.s: Assembler messages:
> /tmp/cclQ6hrD.s:1261: Error: Architecture mismatch on "rd".
> /tmp/cclQ6hrD.s:1261:  (Requires v9|v9a|v9b; requested architecture is
> v8.)
> Makefile:517: recipe for target 'beginend.lo' failed
> make[5]: *** [beginend.lo] Error 1
> 
> So disable it for our current (v8, leon3) support.
> 
> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>

Applied, thanks. Is it only SPARCv8 that doesn't have libitm support,
or could other architectures be affected? If other architectures are
affected, we may want to introduce a BR2_ARCH_HAS_LIBITM or some other
similar thing.

Another weird thing: we're not enabling libitm, so why is gcc enabling
it by itself, if it knows that the architecture cannot support it?

Thanks,

Thomas
Gustavo Zacarias Jan. 15, 2015, 10:37 a.m. UTC | #2
On 01/15/2015 05:37 AM, Thomas Petazzoni wrote:

> Applied, thanks. Is it only SPARCv8 that doesn't have libitm support,
> or could other architectures be affected? If other architectures are
> affected, we may want to introduce a BR2_ARCH_HAS_LIBITM or some other
> similar thing.
> 
> Another weird thing: we're not enabling libitm, so why is gcc enabling
> it by itself, if it knows that the architecture cannot support it?

There are other architectures that could be affected, most notably old
processors/cores.
I don't think we need to do anything more special about it, most of the
time gcc will detect and enable it if the architecture supports it,
which basically boils down to your second question, it's failing to
realize sparc v8 can't handle it.
It probably has to do with the sparc tuple being used for sparc64 as
well (64 bit kernel 32 bit userland) and sparc v8 being terribly old and
hardly used outside of LEON (V9 dates from 1993!).
Regards.
diff mbox

Patch

diff --git a/package/gcc/gcc.mk b/package/gcc/gcc.mk
index cdd71aa..2e8b412 100644
--- a/package/gcc/gcc.mk
+++ b/package/gcc/gcc.mk
@@ -110,6 +110,11 @@  else
 HOST_GCC_COMMON_CONF_OPTS += --enable-target-optspace
 endif
 
+# libitm needs sparc V9+
+ifeq ($(BR2_sparc_v8)$(BR2_sparc_leon3),y)
+HOST_GCC_COMMON_CONF_OPTS += --disable-libitm
+endif
+
 # gcc 4.6.x quadmath requires wchar
 ifneq ($(BR2_TOOLCHAIN_BUILDROOT_WCHAR),y)
 HOST_GCC_COMMON_CONF_OPTS += --disable-libquadmath