search for: gnuabi64

...ABI's in the form of the Triple::GNUEABI, Triple::GNUEABIHF, and Triple::GNUX32 values of the environment component of the triple and it's up to the frontend and/or API-user to pass the right thing to the backend. For MIPS, I'm defining Triple::GNUABI32, Triple::GNUABIN32, and Triple::GNUABI64. All three of these are supported by tools like binutils (by virtue of a wildcard match '*linux-gnu*') and of these three, Triple::GNUABI32 is not in general use, Triple::GNUABIN32 will be used by Debian if/when we do an N32 port, and Triple::GNUABI64 is currently used by Debian for our N64...

...BI without also enabling it for the N32 ABI because this information is not reflected in the triple and that's the only information MipsMCAsmInfo has. What would it take to pass more information to MipsMCAsmInfo? > For MIPS, I'm defining Triple::GNUABI32, Triple::GNUABIN32, and Triple::GNUABI64. All three of these are supported by tools like binutils (by virtue of a wildcard match '*linux-gnu*') and of these three, Triple::GNUABI32 is not in general use, Triple::GNUABIN32 will be used by Debian if/when we do an N32 port, and Triple::GNUABI64 is currently used by Debian for our N64...

...ure-time options based on previous discussions. Has this changed? > ps. It also doesn't appear that Matthew (who took over my gcc responsibilities, thanks!) has added support for this in gcc yet either. > echristo at dzur ~/b/build-gcc-mips64abin64> .../configure --target=mips64-linux-gnuabi64 --enable-languages=c > echristo at dzur ~/tmp> ~/builds/build-gcc-mips64abin64/gcc/cc1 foo.c -o - > .file 1 "foo.c" > .section .mdebug.abiN32 It's true that upstream GCC doesn't know about this triple yet but that's because downstream users...

...ce writing that, I have added a facility to ObjectFile that allows llvm-objdump to detect the feature bits from the Object header. The same technique can be used for other tools that handle ObjectFiles. > > For MIPS, I'm defining Triple::GNUABI32, Triple::GNUABIN32, and > > Triple::GNUABI64. All three of these are supported by tools like binutils (by > > virtue of a wildcard match '*linux-gnu*') and of these three, > > Triple::GNUABI32 is not in general use, Triple::GNUABIN32 will be used by > > Debian if/when we do an N32 port, and Triple::GNUABI64 is curren...

...fail: fcntl pass i386/i686-linux-gnu: fail: build pass m68k/m68k-linux-gnu: pass pass mips/mips-linux-gnu: fail: build pass mips/mipsel-linux-gnu: fail: build pass mips64/mips64el-linux-gnuabi64: fail: build pass parisc/hppa-linux-gnu: fail: fcntl, vfork fail: fcntl, vfork ppc/powerpc-linux-gnu: pass pass ppc/powerpc-linux-gnuspe: fail: all tests fail: all tests ppc64/powerpc64-linux-gnu: fail: fcntl...

...fail: fcntl pass i386/i686-linux-gnu: fail: build pass m68k/m68k-linux-gnu: pass pass mips/mips-linux-gnu: fail: build pass mips/mipsel-linux-gnu: fail: build pass mips64/mips64el-linux-gnuabi64: fail: build pass parisc/hppa-linux-gnu: fail: fcntl, fail: fcntl, malloctest2*, malloctest2*, setjmptest*, vfork setjmptest*, vfork ppc/powerpc-linux-gnu: pass...

...pass i386/i686-linux-gnu: fail: build pass pass m68k/m68k-linux-gnu: pass pass pass mips/mips-linux-gnu: fail: build pass pass mips/mipsel-linux-gnu: fail: build pass pass mips64/mips64el-linux-gnuabi64: fail: build pass pass parisc/hppa-linux-gnu: fail: fcntl, fail: fcntl, pass vfork vfork ppc/powerpc-linux-gnu: pass pass pass ppc/powerpc-linux-gnuspe: fail: sigint, fail: sigint, fail: sigint,...

Hello, I'm trying to create a pure LLVM toolchain (that will not depend on GNU and produce GNU-free code too) on a musl based distribution. For now, I use gcc to bootstrap and build all LLVM components. I do it individually because I was running out of space and memory trying to build all using LLVM_ENABLE_PROJECTS. Also, I don't want to create a all-in-one package. Then, once

> > > The word 'all' is what still bothers me here. If any one piece of the information is derived from incorrect information in the triple, then the behaviour will likely be incorrect. > > > > If it's possible to be derived from the triple then it's going to be correct or the triple is incorrect. > > If it's something that's overridden later

Hello LLVM Developers, Within Google, we have a growing range of needs that existing libc implementations don't quite address. This is pushing us to start working on a new libc implementation. Informal conversations with others within the LLVM community has told us that a libc in LLVM is actually a broader need, and we are increasingly consolidating our toolchains around LLVM. Hence, we