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.
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.
Created attachment 35760 [details] gcc/config.log generated against Xcode7
(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.
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) ….
Created attachment 35761 [details] gcc/config.log generated against Xcode7
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.
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.
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.
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 %
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.
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.
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.
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.
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.
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.
(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
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.
*** Bug 64540 has been marked as a duplicate of this bug. ***
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
Confirmed as fixed on x86_64-apple-darwin15.
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?
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.
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
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
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
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