This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] S/390: Hardware transactional memory support
- From: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- To: Peter Bergner <bergner at vnet dot ibm dot com>
- Cc: Torvald Riegel <triegel at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 02 Aug 2013 16:45:51 +0200
- Subject: Re: [PATCH] S/390: Hardware transactional memory support
- References: <20130621102314 dot GA753 at bart> <1375443114 dot 9970 dot 187 dot camel at triegel dot csb> <51FBB13E dot 9080403 at linux dot vnet dot ibm dot com> <1375453429 dot 5240 dot 6 dot camel at otta> <51FBC1A8 dot 1010307 at linux dot vnet dot ibm dot com> <1375454206 dot 5240 dot 12 dot camel at otta>
On 02/08/13 16:36, Peter Bergner wrote:
> On Fri, 2013-08-02 at 16:26 +0200, Andreas Krebbel wrote:
>> On 02/08/13 16:23, Peter Bergner wrote:
>> As long as libitm does not use FPRs itself this should be safe without
>> having tbegin clobbering FPRs.
>
> Is it a given that s390 doesn't use FPRs without explicit use of
> floating point types? I ask, because on POWER, we can and do
> generate floating point code without explicit use of double,
> float, etc. Maybe s390 is safe in that respect.
S/390 used to be on the safe side regarding this but with mainline we started using FPRs as GPR save
slots. As Richard suggested we should build libitm with -msoft-float in order to prevent this within
libitm. Unfortunately I forgot about this in my S/390 libitm patch. So I'll commit the following:
Index: libitm/configure.tgt
===================================================================
*** libitm/configure.tgt.orig 2013-07-30 07:42:29.000000000 +0000
--- libitm/configure.tgt 2013-08-02 14:43:18.641206151 +0000
*************** case "${target_cpu}" in
*** 109,115 ****
ARCH=x86
;;
s390|s390x)
! XCFLAGS="${XCFLAGS} -mzarch -mhtm"
ARCH=s390
;;
--- 109,115 ----
ARCH=x86
;;
s390|s390x)
! XCFLAGS="${XCFLAGS} -mzarch -mhtm -msoft-float"
ARCH=s390
;;