Bug 66509 - the new clang-based assembler in Xcode 7 on 10.11 fails on the libjava/java/lang/reflect/natArray.cc file from FSF gcc 5.1 at -m32
Summary: the new clang-based assembler in Xcode 7 on 10.11 fails on the libjava/java/l...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 5.1.0
: P3 normal
Target Milestone: 6.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 64540 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-06-11 13:14 UTC by Jack Howarth
Modified: 2015-07-04 12:11 UTC (History)
6 users (show)

See Also:
Host: x86_64-apple-darwin1[4,5]
Target: x86_64-apple-darwin1[4,5]
Build: x86_64-apple-darwin1[4,5]
Known to work: 4.9.4, 5.1.1, 6.0
Known to fail: 5.1.0
Last reconfirmed:


Attachments
assembly for ibjava/java/lang/reflect/natArray.cc at -m32 on x86_64 darwin (35.22 KB, text/plain)
2015-06-11 13:14 UTC, Jack Howarth
Details
gcc/config.log generated against Xcode7 (3.20 KB, text/plain)
2015-06-11 13:28 UTC, Jack Howarth
Details
gcc/config.log generated against Xcode7 (30.09 KB, text/plain)
2015-06-11 13:36 UTC, Jack Howarth
Details
proposed fix for PR66509 (334 bytes, patch)
2015-06-11 20:08 UTC, Jack Howarth
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jack Howarth 2015-06-11 13:14:57 UTC
Created attachment 35759 [details]
assembly for ibjava/java/lang/reflect/natArray.cc at -m32 on x86_64 darwin

The public Xcode 7 beta and associated Command Line Tools (available on 10.10 from https://developer.apple.com/xcode/downloads/ and https://developer.apple.com/downloads/) replace the legacy GNU assembler with a clang-based assembler. The new clang-based assembler fails to compile libjava/java/lang/reflect/natArray.cc at -m32 in the multilib build of libjava due to the assembler errors...

natArray.s:1110:2: error: ambiguous instructions require an explicit suffix (could be 'filds', or 'fildl')
        fild    8(%esi,%edi,2)
        ^
natArray.s:1120:2: error: ambiguous instructions require an explicit suffix (could be 'filds', or 'fildl')
        fild    10(%esp)
        ^
natArray.s:1267:2: error: ambiguous instructions require an explicit suffix (could be 'filds', or 'fildl')
        fild    8(%esi,%edi,2)
        ^
natArray.s:1277:2: error: ambiguous instructions require an explicit suffix (could be 'filds', or 'fildl')
        fild    14(%esp)
        ^
natArray.s:1830:2: error: ambiguous instructions require an explicit suffix (could be 'filds', or 'fildl')
        fild    14(%esp)
        ^
natArray.s:1907:2: error: ambiguous instructions require an explicit suffix (could be 'filds', or 'fildl')
        fild    14(%esp)
        ^
natArray.s:1988:2: error: ambiguous instructions require an explicit suffix (could be 'filds', or 'fildl')
        fild    14(%esp)
        ^
natArray.s:2047:2: error: ambiguous instructions require an explicit suffix (could be 'filds', or 'fildl')
        fild    14(%esp)
        ^

This issue can be reproduced with the attached natArray.s assembly file using the command...

as -arch i386 -force_cpusubtype_ALL -o natArray.o natArray.s

against the new clang-based assembler. The same file is processed without errors using the legacy GNU-based assembler from Xcode 6.2 on 10.9 or Xcode 6.3 on 10.10.

Can the FSF gcc i386 maintainers comment on whether there is anything in the Intel/AMD instruction specifications that merits this strict behavior for the assembler with regard to ambiguous fild instructions?

Note that this compilation failure is limited to -m32 and that the -m64 build of libjava is processed without errors by the new clang-based assembler.
Comment 1 Andrew Pinski 2015-06-11 13:20:26 UTC
This is due to HAVE_AS_IX86_FILDS not being defined.  So basically they made the clang assembly not backwards compatible with the GNU one.

You can add a check to configure.ac if you want which does the same the check for the gnu assembly:
    gcc_GAS_CHECK_FEATURE([filds and fists mnemonics],
       gcc_cv_as_ix86_filds,,,
       [filds mem; fists mem],,
       [AC_DEFINE(HAVE_AS_IX86_FILDS, 1,
         [Define if your assembler uses filds and fists mnemonics.])])

Actually on second thought, this should be happening.  Can you attach config.log form gcc directory.
Comment 2 Jack Howarth 2015-06-11 13:28:46 UTC
Created attachment 35760 [details]
gcc/config.log generated against Xcode7
Comment 3 Andrew Pinski 2015-06-11 13:30:51 UTC
(In reply to Jack Howarth from comment #2)
> Created attachment 35760 [details]
> gcc/config.log generated against Xcode7

Wrong one.  This is the one for libevent.
Comment 4 Iain Sandoe 2015-06-11 13:34:01 UTC
could you please also list 
as -v
and 
as --version

it's possible that it no longer contains the string "GNU" which would actually help us distinguish moving forward (i have some patches in my Q to handle Darwin assemblers better and to support my prototype GAS port) ….
Comment 5 Jack Howarth 2015-06-11 13:36:35 UTC
Created attachment 35761 [details]
gcc/config.log generated against Xcode7
Comment 6 Jack Howarth 2015-06-11 13:38:08 UTC
A check of a recent build gcc trunk against the GNU assembler from Xcode 6.2 shows the same...

gcc_cv_as_ix86_fildq=no
gcc_cv_as_ix86_filds=no

as the build against Xcode 7's clang-based assembler.
Comment 7 Andrew Pinski 2015-06-11 13:40:12 UTC
The assembly test in configure failed:

configure:24880: checking assembler for filds and fists mnemonics
configure:24889: /usr/bin/as    -o conftest.o conftest.s >&5
clang -cc1as: fatal error: error in backend: 32-bit absolute addressing is not supported in 64-bit mode
configure:24892: $? = 1
configure: failed program was
filds mem; fists mem


So maybe it is just a matter of changing configure.ac to use a slightly different test on it.
Comment 8 Jack Howarth 2015-06-11 13:58:06 UTC
Note that configure test does succeed if the '-arch i386' option is also passed to the assembler. Perhaps the tests aren't fine-grained enough as they are only done for x86_64 in config.log.
Comment 9 Jack Howarth 2015-06-11 14:22:59 UTC
Also, testing with in-line assembly using clang 3.7svn, I get the same behavior for...

% cat conftest.c
asm("filds mem; fists mem");
% clang-3.7 -c conftest.c
fatal error: error in backend: 32-bit absolute addressing is not supported in 64-bit mode
% clang-3.7 -m32 -c conftest.c
%
Comment 10 Jack Howarth 2015-06-11 16:51:57 UTC
The clang developers suggest the test...

filds (%ebp)

which is compilable with the clang-based assembler at both -m32 and -m64.

http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-June/043463.html

fists (%ebp) 

also appears to work for the second part of the test.
Comment 11 Jack Howarth 2015-06-11 16:56:52 UTC
Also changing

fildq mem; fistpq mem

ro 

fildq (%ebp); fistpq (%ebp)

allows the fildq and fistpq mnemonics to pass at -m32/-m64 on the clang-based assembler.
Comment 12 Mike Stump 2015-06-11 17:15:21 UTC
Here is a case where we wish for actual feature testing of all the bits instead of the coarse grain, are we FSF gas 2.9 or later.  Default should be things work nicely, and the feature testing should be to identify incomplete or broken things.  Given the propensity for people to write a test, is this 2.x or later, that is a direct indication they wrote it wrong in the first place.  Tests should always be 2.x or earlier to identify broken.
Comment 13 Jack Howarth 2015-06-11 17:50:25 UTC
Also confirmed that using the modified tests of...

filds (%ebp); fists (%ebp)

and

fildq (%ebp); fistpq (%ebp)

allow the GNU legacy assembler from Xcode 6.2 (Apple Inc version cctools-862, GNU assembler version 1.38) to pass these two gcc/configure tests at both -m32/-m64.
Comment 14 Jack Howarth 2015-06-11 20:08:12 UTC
Created attachment 35765 [details]
proposed fix for PR66509

Confirmed to bootstrap the c,c++,fortran,lto,java on x86_64-apple-darwin15 against Xcode 7's clang-based assembler and c,c++,fortran,lto,objc,obj-c++,java on x86_64-apple-darwin14 against Xcode 6.2's legacy GNU assembler.
Comment 15 mrs@gcc.gnu.org 2015-06-11 20:53:43 UTC
The fix requires that binutils also support the () spelling as the test runs on all x86 systems.  Also, it will break systems older then when () was first introduced, if it was after filds itself was supported.  I don't know when each was new.
Comment 16 Jack Howarth 2015-06-11 21:24:15 UTC
(In reply to mrs@gcc.gnu.org from comment #15)
> The fix requires that binutils also support the () spelling as the test runs
> on all x86 systems.  Also, it will break systems older then when () was
> first introduced, if it was after filds itself was supported.  I don't know
> when each was new.

Seems like a question for H.J. Lu. Also, it looks like we already have a few instances of that syntax in current gcc trunk...

% grep " (%" gcc/configure
    $as_echo 'lock xacquire cmpxchg %esi, (%ecx)' > conftest.s
	 lock addl %edi, (%eax,%esi)
	 lock orl $0, (%esp)' > conftest.s
Comment 17 Jack Howarth 2015-06-11 23:32:37 UTC
Apple responded on radar as follows...

This issue behaves as intended based on the following:

I think the first diagnostic is reasonable: there's not particular reason to prefer filds over fildl (or even fildll) so some disambiguation is needed.

The second is debatable: MachO does seem to be able to represent it if we wanted, and ld64 seems to handle it correctly, but our execution model never puts any pointers at a location reachable by such a relocation (it's all PAGEZERO). So I think that one is probably best kept too.

I'd suggest that GCC use either "filds mem(%rip)" or possibly "filds (%ebp)" (to pick a random example) for something that should assemble in both 64-bit and 32-bit mode -- sidestepping the relocation issue entirely.
Comment 18 Andrew Pinski 2015-06-26 21:07:51 UTC
*** Bug 64540 has been marked as a duplicate of this bug. ***
Comment 19 mrs@gcc.gnu.org 2015-06-30 02:11:15 UTC
Author: mrs
Date: Tue Jun 30 02:10:43 2015
New Revision: 225158

URL: https://gcc.gnu.org/viewcvs?rev=225158&root=gcc&view=rev
Log:
	PR target/66509
	* configure.ac: Fix filds and fildq test for 64-bit.
	* configure: Regenerated.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/configure
    trunk/gcc/configure.ac
Comment 20 Jack Howarth 2015-07-01 14:01:08 UTC
Confirmed as fixed on x86_64-apple-darwin15.
Comment 21 Jack Howarth 2015-07-02 01:06:13 UTC
Should we back-port this fix for gcc 5.2.0 as its current gcc/configure errornously fails the filds and fildq test for 64-bit with both the legacy GNU assembler and the clang-based assembler?
Comment 22 mrs@gcc.gnu.org 2015-07-02 07:34:40 UTC
Yes.  It cleanly applies to the 5 branch and the 4.9 branch.  Let me know how a build and test cycle goes on both, and I propose to drop it into both.
Comment 23 Jack Howarth 2015-07-03 12:57:02 UTC
Mike, tested back port of...

Author: mrs
Date: Tue Jun 30 02:10:43 2015
New Revision: 225158

URL: https://gcc.gnu.org/viewcvs?rev=225158&root=gcc&view=rev
Log:
PR target/66509
* configure.ac: Fix filds and fildq test for 64-bit.
* configure: Regenerated.

to gcc-5-branch at r225316 with no obvious regression

https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg00300.html
Comment 24 mrs@gcc.gnu.org 2015-07-03 17:01:20 UTC
Author: mrs
Date: Fri Jul  3 17:00:49 2015
New Revision: 225386

URL: https://gcc.gnu.org/viewcvs?rev=225386&root=gcc&view=rev
Log:
2015-07-03  Jack Howarth  <howarth.at.gcc@gmail.com>

	PR target/66509
	* configure.ac: Fix filds and fildq test for 64-bit.
	* configure: Regenerated.

Modified:
    branches/gcc-5-branch/gcc/ChangeLog
    branches/gcc-5-branch/gcc/configure
    branches/gcc-5-branch/gcc/configure.ac
Comment 25 mrs@gcc.gnu.org 2015-07-03 17:51:20 UTC
Author: mrs
Date: Fri Jul  3 17:50:48 2015
New Revision: 225400

URL: https://gcc.gnu.org/viewcvs?rev=225400&root=gcc&view=rev
Log:
2015-07-03  Jack Howarth  <howarth.at.gcc@gmail.com>

	PR target/66509
	* configure.ac: Fix filds and fildq test for 64-bit.
	* configure: Regenerated.

Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/configure
    branches/gcc-4_9-branch/gcc/configure.ac
Comment 26 Jack Howarth 2015-07-04 12:11:03 UTC
FYI, test results for back port onto gcc-4_9-branch is posted at...

https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg00400.html