[cfe-dev] Incorrect assumptions in MIPS backend

Matthew Fernandez via cfe-dev cfe-dev at lists.llvm.org
Sun Sep 20 20:36:45 PDT 2015


Thanks, Daniel. I guess calling llc in this way to probe the supported CPUs is not necessarily expected. The repeated help text seems to suggest this as well. I'll revert to probing support by calling Clang with my target CPU and checking the error code. Thanks for your explanation.

On 18 September 2015 01:55:52 GMT+10:00, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote:
>Hi Matthew,
>
>This assert is part of a long standing problem. In this case, the
>problem is that the ABI is unknown because (at the moment) the ABI is
>set as a side effect of selecting a CPU. Of course, no CPU has been
>selected because you requested the CPU help text. This works for me:
>       bin/llc -march=mipsel -target-abi=o32 -mcpu=help
>although it does print the help text seven times at the moment. I'm not
>sure why it prints it so many times but I expect it's once per
>MipsSubtarget instantiation.
>
>You may also encounter this problem when using a 32-bit CPU with
>-march=mips64el, or a 64-bit CPU with -march=mipsel since the backend
>conflates having a 64-bit CPU or not with wanting to use a 64-bit ABI
>or not.
>
>> -----Original Message-----
>> From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of
>> Matthew Fernandez via cfe-dev
>> Sent: 17 September 2015 10:42
>> To: cfe-dev at lists.llvm.org
>> Subject: [cfe-dev] Incorrect assumptions in MIPS backend
>>
>> Hi all,
>>
>> Running the following on an x86_64 Linux box triggers an assertion
>failure:
>>
>>      llc -march=mipsel -mcpu=help </dev/null
>>
>> The assertion in question is the following:
>>
>>      llvm/lib/Target/Mips/MipsSubtarget.cpp:92-95
>>
>>      // Check if Architecture and ABI are compatible.
>>      assert(((!isGP64bit() && (isABI_O32() || isABI_EABI())) ||
>>              (isGP64bit() && (isABI_N32() || isABI_N64()))) &&
>>             "Invalid  Arch & ABI pair.");
>>
>> It's possible my LLVM is not correctly configured to target MIPS, but
>it still
>> seems like this should not trigger an
>> assertion failure. Is the MIPS backend assuming something it
>shouldn't here?
>>
>> This is on a somewhat older revision, r218935. I tried to reproduce
>this on the
>> current tip, but had some difficulty
>> building it (missing __cxa_* symbols during link; missing a
>dependency?).
>> Apologies if this issue is not reproducible on
>> the tip.
>>
>> Thanks,
>> Matt
>>
>> ________________________________
>>
>> The information in this e-mail may be confidential and subject to
>legal
>> professional privilege and/or copyright. National ICT Australia
>Limited accepts
>> no liability for any damage caused by this email or its attachments.
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


________________________________

The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.



More information about the cfe-dev mailing list