search for: x86_64h

I'm working on LLDB and we have a bunch of code that is manually manipulating triples and doing a bunch of nasty stuff to account for the fact that llvm::Triple doesn't currently have a way to detect x86_64h. Is this something that llvm::Triple could be modified to support? Either as a new ArchType, or a new SubArchType? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140819/4e3f3ff1/attachment.html>

Hi, I'm building LLVM on Mac OS 10.10 and I'm having trouble making LTO work. The system linker dumps the following information when I executed "ld -v" @(#)PROGRAM:ld PROJECT:ld64-241.9 configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7m armv7em LTO support using: LLVM version 3.4.2 which tells me that it is correctly pointing to the LLVM that I have built. However, when I pass any LTO command line arguments like "disable-inling" it complains. I was previously working on Linux and the gold plugin makes it...

...9;m building LLVM on Mac OS 10.10 and I'm having trouble making LTO work. >> The system linker dumps the following information when I executed "ld -v" >> >> @(#)PROGRAM:ld PROJECT:ld64-241.9 >> configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h >> armv6m armv7m armv7em >> LTO support using: LLVM version 3.4.2 >> >> which tells me that it is correctly pointing to the LLVM that I have built. >> However, when I pass any LTO command line arguments like "disable-inling" it >> complains. >>...

...one please provide some input about how to tackle this issue? On my other machine, I followed the same guide[1] (without the --enable-optimized option), and everything built successfully. [1] http://clang.llvm.org/get_started.html ==================== warning: clang_darwin.mk: dropping arch 'x86_64h' from lib 'ubsan_osx' (ld does not support it) make[5]: Entering directory `/home/sandeep/llvm_clang/llvm/projects/compiler-rt' COMPILE: clang_linux/san-i386/i386: /home/sandeep/llvm_clang/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc /home/sandeep/llvm_clang...

...2:44 PM, Zachary Turner <zturner at google.com> wrote: > > > > I'm working on LLDB and we have a bunch of code that is manually > manipulating triples and doing a bunch of nasty stuff to account for the > fact that llvm::Triple doesn't currently have a way to detect x86_64h. > > > > Is this something that llvm::Triple could be modified to support? > Either as a new ArchType, or a new SubArchType? > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.e...

Hi Dean, For me the build is still broken: -- Builtin supported architectures: i386;x86_64;x86_64h CMake Error at projects/compiler-rt/lib/xray/tests/CMakeLists.txt:21 (add_library): add_library cannot create target "RTXRay.test.osx" because another target with the same name already exists. The existing target is a static library created in source directory "/Volumes/Tran...

...a sane way (via a default attribute sets or something), but I haven't had time yet to go back to my original proposal and refine it :(. > > That said I was actually envisioning something like: > > clang -emit-llvm foo.c -o foo.bc > ... > > clang -O3 -flto all.bc -arch x86_64h -o haswell_slice > clang -O3 -flto all.bc -arch x86_64 -o x86_64_slice > > for the same set of bitcode files. But given the front end language restrictions on doing anything actually interesting there it's not too much of a constraint. Many of the differences between architectures CP...

...dCompilerRT.cmake? They were written exactly to avoid such errors. Regards, George > On Apr 11, 2018, at 10:50 AM, George Karpenkov <ekarpenkov at apple.com> wrote: > > Hi Dean, > > For me the build is still broken: > > -- Builtin supported architectures: i386;x86_64;x86_64h > CMake Error at projects/compiler-rt/lib/xray/tests/CMakeLists.txt:21 (add_library): > add_library cannot create target "RTXRay.test.osx" because another target > with the same name already exists. The existing target is a static library > created in source directory >...

...as you say, remove the uncertainty and have the default always be the same from one run to the next even (especially) when those runs are on different machines. For X86, there’s two options, the “generic” target that backend already supports or “core2” which is what clang typically defaults to for x86_64h. I lean towards the former for simplicity. We also don’t have to change all three of the ports. I’m personally motivated primarily by x86, and was intending to leave it to the maintainers of the other two targets to decide what they want to do here, perhaps with some strong encouragement. It’s ver...

>From PR18808 I said a few things and that I was going to redirect to the mailing list for further discussion. So here we are, go. 1) Whether or not to allow changing of target-cpu/target-feature/triple at link time code generation. - Not convinced here of the facility to do so. Could just recompile the individual bitcode files to get what you want, but there are some users that are trying to

On Tue, Aug 19, 2014 at 5:05 PM, Jim Grosbach <grosbach at apple.com> wrote: > Note that it’s not exactly equivalent to enabling -march=core-avx2. It’s > really close, but not 100% the same. What is the difference? and why? It seems really confusing to have this divergence, or to be unable to replicate the *exact* behavior of this (very weird, and IMO *bad* triple) with the standard

...ing <https://drive.google.com/file/d/11Ngst9FOnVL4fWYlKalzoFXL--B1SaOb/view?usp=sharing> > > My ld version is: > > ➜ ld -v > @(#)PROGRAM:ld PROJECT:ld64-530 > BUILD 18:57:17 Dec 13 2019 > configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em > LTO support using: LLVM version 11.0.0, (clang-1100.0.33.17) (static support for 23, runtime is 23) > TAPI support using: Apple TAPI version 11.0.0 (tapi-1100.0.11) > > Since that said it was using LTO from Xcode I thought that might be the problem - but...

Hello all, I am having trouble running only a single lit-based test of compiler-rt. My folder structure is: inside the llvm monorepo checkout, I have a dir "build" with subdir "buildtrunk". I ran cmake inside "buildtrunk" and also run ninja from there. For LLVM I can do the following: > cd build/buildtrunk/test > ../bin/llvm-lit --show-tests . And it shows

This is usually a problem that is not using llvm-ar. I cannot reproduce this problem with either llvm 10.0 or TOT version. Which linker version are you using? You can also try pass "-Wl,-debug_snapshot" to the command where the error produces and then locate the "*.ld-snapshot" in /tmp directory and attach that as a reproducer. Steven > On Jul 22, 2020, at 8:41 AM, Teresa

...llvm::Triple::UnknownOS && + (Triple.getOS() == llvm::Triple::NoneOS && Triple.getObjectFormat() == llvm::Triple::MachO) || StringRef(CPUName).startswith("cortex-m")) { ABIName = "aapcs"; @@ -5128,7 +5128,7 @@ if (Str == "x86_64h") T.setArchName(Str); else if (Str == "armv6m" || Str == "armv7m" || Str == "armv7em") { - T.setOS(llvm::Triple::UnknownOS); + T.setOS(llvm::Triple::NoneOS); T.setObjectFormat(llvm::Triple::MachO); } } Index: test/Driver/macho-embedded.c ===...

....com/file/d/11Ngst9FOnVL4fWYlKalzoFXL--B1SaOb/view?usp=sharing> >> >> My ld version is: >> >> ➜ ld -v >> @(#)PROGRAM:ld PROJECT:ld64-530 >> BUILD 18:57:17 Dec 13 2019 >> configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em >> LTO support using: LLVM version 11.0.0, (clang-1100.0.33.17) (static support for 23, runtime is 23) >> TAPI support using: Apple TAPI version 11.0.0 (tapi-1100.0.11) >> >> Since that said it was using LTO from Xcode I thought that might be th...

All, Currently the X86 backend does CPU auto-detection and subtarget feature detection when the TargetMachine is created if no explicit CPU was specified. It's counterintuitive for low level tools like ‘llc’ to do this, as it means the same .ll file compiled on heterogenous machines generates different results from the same ‘llc’ command line. It is still useful to be able to opt-in to such

Hi: I'm in the middle of recoverying from a tactical error copying around an Mac OS X 10.10.5 Time Machine backup (turns out Apple's instructions aren't great...), and I had rsync running for the past 6 hours repairing permissions/acls on 1.5 TB of data (not copying the data), and then it just died in the middle with: .L....og.... 2015-03-11-094807/platinum-bar2/usr/local/mysql

[+llvmdev, -llvm-dev] (Oopsies, llvmdev doesn't have a hyphen in it like all the others do) On 6/17/14, 10:45 AM, Jonathan Roelofs wrote: > [+llvm-dev, cfe-dev] > > Was "Re: [PATCH] ARM: allow inline atomics on Cortex M" > > On 6/17/14, 10:42 AM, Jonathan Roelofs wrote: >> >> >> On 6/17/14, 9:35 AM, Renato Golin wrote: >>> On 17 June 2014

...vm__safestack diff --git a/make/platform/clang_darwin.mk b/make/platform/clang_darwin.mk index 8b5f848..7908b77 100644 --- a/make/platform/clang_darwin.mk +++ b/make/platform/clang_darwin.mk @@ -106,6 +106,10 @@ endif Configs += ubsan_osx UniversalArchs.ubsan_osx := $(call CheckArches,i386 x86_64 x86_64h,ubsan_osx) +# Configurations which define the safestack support functions. +Configs += safestack_osx +UniversalArchs.safestack_osx = $(call CheckArches,i386 x86_64 x86_64h,safestack_osx) + # Darwin 10.6 has a bug in cctools that makes it unable to use ranlib on our ARM # object files. If we are...