similar to: [LLVMdev] FYI: IA-32 psABI draft version 0.1

On Thu, 22 Jan 2015, H.J. Lu wrote: > Here is the link: > > https://groups.google.com/forum/#!topic/ia32-abi/nq6cvH_VVV4 I sent the following reply to the ia32-abi list but haven't yet received it back from the list - you might want to check if it's stuck in moderation somewhere: I would suggest that rather than using old terms such as "single", "double"

On Thu, Jan 22, 2015 at 11:54 AM, Richard Smith <richard at metafoo.co.uk> wrote: > On Thu, Jan 22, 2015 at 4:35 AM, H.J. Lu <hjl.tools at gmail.com> wrote: >> Here is the link: >> >> https://groups.google.com/forum/#!topic/ia32-abi/nq6cvH_VVV4 > > The document contains this claim (as do many other psABI documents): > > "Bit-fields that are neither

If you are interesting to play around X32, you may refer to http://sourceware.org/glibc/wiki/x32 to bootstrap a local environment on Linux. Yours - Michael -----Original Message----- From: cfe-commits-bounces at cs.uiuc.edu [mailto:cfe-commits-bounces at cs.uiuc.edu] On Behalf Of Liao, Michael Sent: Monday, June 04, 2012 5:09 PM To: llvm-commits at cs.uiuc.edu; cfe-commits at cs.uiuc.edu

Hi Arsen, On Oct 9, 2013, at 4:53 AM, Arsen Hakobyan <artinetstudio at gmail.com> wrote: > Hi all, > > I have the following test case: > #define FLT_EPSILON 1.19209290E-7 > > int err = -1; > int main() > { > float a = 8.1; > if (((a - 8.1) >= FLT_EPSILON) || ((a - 8.1) <= -FLT_EPSILON)) { //I am > using FLT_EPSILON to check whether (a != 2.0).

Hi Folks, Anyone got chance to review the patch adding X32 psABI support? Yours - Michael -----Original Message----- From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Liao, Michael Sent: Tuesday, June 05, 2012 11:18 AM To: llvm-commits at cs.uiuc.edu; cfe-commits at cs.uiuc.edu; llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu Subject: Re:

Hi, I've tracked down what I believe is a bug in lld's relocation processing for R_X86_64_PC32 REL relocations. I'm producing the object file in a slightly unusual way: I'm using objcopy on a relocatable i386 ELF object file to convert it to x86_64 which transforms a R_386_PC32 into a R_X86_64_PC32. Steps to reproduce: 1. Assemble the attached bug.asm using nasm and note the

Hi all, I have the following test case: #define FLT_EPSILON 1.19209290E-7 int err = -1; int main() { float a = 8.1; if (((a - 8.1) >= FLT_EPSILON) || ((a - 8.1) <= -FLT_EPSILON)) { //I am using FLT_EPSILON to check whether (a != 2.0). err = 1; } else { err = 0; } return 0; } with -O3 optimization level clang generates already incorrect LLVM IR: ; Function Attrs:

Linux GABI [1] introduced new .note.gnu.property section which contains a program property note which describes special handling requirements for linker and run-time loader. LLD does not support .note.gnu.property yet. GABI specifies 2 types of entries: GNU_PROPERTY_STACK_SIZE and GNU_PROPERTY_NO_COPY_ON_PROTECTED: * GNU_PROPERTY_STACK_SIZE: Its pr_data field contains an integer in the format

I think we should wait until there is someone wanting to use these features with lld. Cheers, Rafael ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On March 20, 2018 6:59 AM, George Rimar <grimar at accesssoftek.com> wrote: > Linux GABI [1] introduced new .note.gnu.property section which contains a program > property note which describes special handling requirements for linker and run-time

> I am not entirely sure this is safe. Transforming this to an fsub could change the value stored on platforms that implement negates using arithmetic instead of with bitmath (such as ours) I think it's probably safe for IEEE754-2008 conformant platforms because negation was clarified to be a non-arithmetic bit flip that cannot cause exceptions in that specification. However, I'm sure

Hi Devs, since risc-v has a register $tp which is thread pointer. is it possible to have __builtin_thread_pointer for RISC-V? I am not sure what could be corresponding instructions? ./kamlesh

I'd like to convert the following call A at GDPLT //R_HEX_GD_PLT_B22_PCREL to call __tls_get_addr //R_HEX_B22_PCREL "A" is a TLS variable and preceding code has prepared for the call. When the R_HEX_GD_PLT_B22_PCREL is found it will initially point to the TLS variable so at that point I'd like to define a __tls_get_addr symbol and update the relocation's type and symbol

Hi, Sam. I think that it's a fair comparison. Keep in mind that the GP is only used to reach global variables of local scope and the GOT, where the address of global variables of global scope reside. This model assumes that the distance between the GP and the global data area, GOT and local scope variables is defined at link time. __ Evandro Menezes ◊ SiFive ◊ Austin, TX > On Mar

Most Linux distributions still compile against the original x86-64 baseline that was based on the AMD K8 (minus the 3DNow! parts, for Intel EM64T compatibility). There has been an attempt to use the existing AT_PLATFORM-based loading mechanism in the glibc dynamic linker to enable a selection of optimized libraries. But the general selection mechanism in glibc is problematic: hwcaps

For background on these calls, see <http://lists.llvm.org/pipermail/llvm-dev/2019-September/135087.html>. Reminder: the purpose is to co-ordinate between active contributors. If you have support questions etc then it's best to post to llvm-dev. We have a call each Thursday at 4pm GMT, via <https://meet.google.com/ske-zcog-spp>. I've created a shared calendar which may help

* Premachandra Mallappa: > [AMD Public Use] > > Hi Floarian, > >> I'm including a proposal for the levels below. I use single letters for them, but I expect that the concrete implementation of this proposal will use >> names like “x86-100”, “x86-101”, like in the glibc patch referenced above. (But we can discuss other approaches.) > > Personally I am not a big

Hi all, Recently, Reid Kleckner found an ABI incompatibility between clang and GCC in the way vector parameters are passed on 32-bit x86. (This is documented in PR21510.) Specifically, GCC uses XMM0-XMM2 to pass the first 3 __m128 parameters, and the rest are passed on the stack. Clang passes an additional parameter by register, using XMM0-XMM3. The same applies to __m256 with YMM0-2 vs. YMM0-3.

For background on these calls, see <http://lists.llvm.org/pipermail/llvm-dev/2019-September/135087.html>. Reminder: the purpose is to co-ordinate between active contributors. If you have support questions etc then it's best to post to llvm-dev. We have a call every alternate Thursday at 4pm GMT, via <https://meet.google.com/ske-zcog-spp>. We have a shared calendar which may help

On Fri, Jul 10, 2020 at 11:45 PM H.J. Lu via Gcc <gcc at gcc.gnu.org> wrote: > > On Fri, Jul 10, 2020 at 10:30 AM Florian Weimer <fweimer at redhat.com> wrote: > > > > Most Linux distributions still compile against the original x86-64 > > baseline that was based on the AMD K8 (minus the 3DNow! parts, for Intel > > EM64T compatibility). > > > >

It seems that there are several issues here: 1. Should the front end be concerned with whether or not the IR that it is emitting can be translated into a well-defined IR? 2. How should the selection DAG handle data types whose representation isn't defined by the ABI we're targeting? 3. What should the ABI do with half-precision floats? Working backward... The third question here is