llvm dev - Jun 2015 - [LLVMdev] fatal error: error in backend: 32-bit absolute addressing is not supported in 64-bit mode

While building FSF gcc 5.1 against Apple's public Xcode 7 beta's
new clang-based assembler, I ran into rejected assembly instructions
during the -m32 multilb build of libjava.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66509

With assembler errors of the form...

natArray.s:1110:2: error: ambiguous instructions require an explicit
suffix (could be 'filds', or 'fildl')
        fild    8(%esi,%edi,2)
        ^

The gcc/config.log shows that the configure test for the filds and
fists mnemonics fails with...

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

The same behavior is seen with in-line assembly in clang 3.7svn...

% 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

In both cases, the test only passes if it is compiled as -m32.

% clang-3.7 -m32 -c conftest.c
%

Is this strictness in the usage of filds and fists correct in the
clang built-in assembler and, if so, is there any permutation of the
configure test for the  filds and fists mnemonics which clang would
tolerate at -m64? Thanks in advance for any clarifications.
             Jack
ps This is also filed as radr://21326888, "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".

Hi Jack,

On 11 June 2015 at 08:21, Jack Howarth <howarth.mailing.lists at
gmail.com> wrote:
>    While building FSF gcc 5.1 against Apple's public Xcode 7 beta's
> new clang-based assembler, I ran into rejected assembly instructions
> during the -m32 multilb build of libjava.
The diagnostics here don't seem to have changed in Clang, going back
to even early Xcode 6.
> natArray.s:1110:2: error: ambiguous instructions require an explicit
> suffix (could be 'filds', or 'fildl')
>         fild    8(%esi,%edi,2)
This seems reasonable to me. It seems GCC arbitrarily chooses "filds",
but there's no grand logic behind that decision. I prefer requiring an
explicit disambiguator.
> clang -cc1as: fatal error: error in backend: 32-bit absolute
> addressing is not supported in 64-bit mode
Technically, I believe MachO could support such a relocation. But it's
never one you'd actually want to use because PAGEZERO occupies the low
32-bits of the address space as a guard against null pointer accesses.
So I think this is probably better than the alternative too.

I'd probably suggest making the test use "filds (%ebp)", which
should
assemble in both 32-bit and 64-bit modes and sidesteps the whole
relocation issue. "filds mem(%rip)" would be a sound 64-bit
instruction closer to the original, but wouldn't assemble on 32-bit.

Cheers.

Tim.

Tim,
      Thanks. The proposed change applied to the gcc/configure tests
for filds/fists/fildq/fistpq assembler support allows those
instructions to be properly recognized as available on both the
clang-based assembler in Xcode 7 and the legacy GNU assembler in Xcode
6.x and earlier.

https://gcc.gnu.org/bugzilla/attachment.cgi?id=35765

        Jack

On Thu, Jun 11, 2015 at 12:19 PM, Tim Northover <t.p.northover at
gmail.com> wrote:
> Hi Jack,
>
> On 11 June 2015 at 08:21, Jack Howarth <howarth.mailing.lists at
gmail.com> wrote:
>>    While building FSF gcc 5.1 against Apple's public Xcode 7
beta's
>> new clang-based assembler, I ran into rejected assembly instructions
>> during the -m32 multilb build of libjava.
>
> The diagnostics here don't seem to have changed in Clang, going back
> to even early Xcode 6.
>
>> natArray.s:1110:2: error: ambiguous instructions require an explicit
>> suffix (could be 'filds', or 'fildl')
>>         fild    8(%esi,%edi,2)
>
> This seems reasonable to me. It seems GCC arbitrarily chooses
"filds",
> but there's no grand logic behind that decision. I prefer requiring an
> explicit disambiguator.
>
>> clang -cc1as: fatal error: error in backend: 32-bit absolute
>> addressing is not supported in 64-bit mode
>
> Technically, I believe MachO could support such a relocation. But it's
> never one you'd actually want to use because PAGEZERO occupies the low
> 32-bits of the address space as a guard against null pointer accesses.
> So I think this is probably better than the alternative too.
>
> I'd probably suggest making the test use "filds (%ebp)",
which should
> assemble in both 32-bit and 64-bit modes and sidesteps the whole
> relocation issue. "filds mem(%rip)" would be a sound 64-bit
> instruction closer to the original, but wouldn't assemble on 32-bit.
>
> Cheers.
>
> Tim.