search for: llvm_hosttripl

...t came across a problem related to this change and was hoping to enquire as to the rationale here. > > It is possible to provide a target triple to lli via the '-mtriple' command line option. However, as a result of the change below, the user specified triple gets ignored in favor of LLVM_HOSTTRIPLE. This seems wrong. > > I recognize that problems can arise if you try to use a target other than the default host triple with JIT or MCJIT. However, with MCJIT it may be desirable to provide an environment string via the triple to generate MachO or ELF objects on platforms that wouldn'...

...- cfe/trunk/Driver/clang.cpp (original) > +++ cfe/trunk/Driver/clang.cpp Tue Jan 27 20:43:35 2009 > @@ -1620,6 +1620,10 @@ > } > } > > + if (Verbose) > + fprintf(stderr, "clang version 1.0 based upon " PACKAGE_STRING > + " hosted on " LLVM_HOSTTRIPLE "\n"); > + > if (unsigned NumDiagnostics = Diags.getNumDiagnostics()) > fprintf(stderr, "%d diagnostic%s generated.\n", NumDiagnostics, > (NumDiagnostics == 1 ? "" : "s")); > > > ________________________________________...

...t came across a problem related to this change and was hoping to enquire as to the rationale here. > > It is possible to provide a target triple to lli via the '-mtriple' command line option. However, as a result of the change below, the user specified triple gets ignored in favor of LLVM_HOSTTRIPLE. This seems wrong. > > I recognize that problems can arise if you try to use a target other than the default host triple with JIT or MCJIT. However, with MCJIT it may be desirable to provide an environment string via the triple to generate MachO or ELF objects on platforms that wouldn'...

I was wondering if would be possible to get the host's triple captured as a string in include/llvm/Config/config.h. Autoconf currently generates this file, and capturing the host triple would be extremely useful for use in the new C frontend. I am not an autoconf expert. Does anyone have any pointers on how this could be added to the LLVM configuration scripts? Thanks. Ted

...file, and capturing the host triple would be extremely > useful for use in the new C frontend. > > I am not an autoconf expert. Does anyone have any pointers on how > this could be added to the LLVM configuration scripts? Thanks. Here you go, it will output something like: #define LLVM_HOSTTRIPLE "i686-apple-darwin9.1.0" Anyone care if this is checked in or not? -eric -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: configure.ac.diff.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071130/996c2f27/attachm...

...original) >> +++ cfe/trunk/Driver/clang.cpp Tue Jan 27 20:43:35 2009 >> @@ -1620,6 +1620,10 @@ >> } >> } >> >> + if (Verbose) >> + fprintf(stderr, "clang version 1.0 based upon " PACKAGE_STRING >> + " hosted on " LLVM_HOSTTRIPLE "\n"); >> + >> if (unsigned NumDiagnostics = Diags.getNumDiagnostics()) >> fprintf(stderr, "%d diagnostic%s generated.\n", NumDiagnostics, >> (NumDiagnostics == 1 ? "" : "s")); >> >> >> _______________...

...would be great if somebody could tell me whether the problem is on my end. What I did was, ~/llvm$ svn up ~/llvm$ mkdir cmakebuild ~/llvm$ cd cmakebuild ~/llvm/cmakebuild$ cmake -DCMAKE_BUILD_TYPE:STRING="Release" -DLLVM_TARGETS_TO_BUILD:STRING="X86" .. -- Target triple: -- LLVM_HOSTTRIPLE: i686-pc-linux-gnu -- Threads enabled. -- Targeting X86 -- Target triple: -- Configuring done -- Generating done -- Build files have been written to: /home/selee/llvm/cmakebuild ~/llvm/cmakebuild$ make After awhile, I got the following error message and couldn't complete the build. ../../li...

...coding I you don't mind. > Changes to the Triple have pretty wide-reaching implications. Chris, what do you think? -Jim > I have one more question. Triples are specified in both modules and TargetMachine. In 3.1 triple from module was used by default. In trunk it has been changed, and LLVM_HOSTTRIPLE is used by default. Do we have any rules in case module triple conflicts with TargetMachine triple? > > - Paweł > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/ma...

...> > -Andy > Hi Andy, That sounds great. Do we need any approval for this change? I can do the coding I you don't mind. I have one more question. Triples are specified in both modules and TargetMachine. In 3.1 triple from module was used by default. In trunk it has been changed, and LLVM_HOSTTRIPLE is used by default. Do we have any rules in case module triple conflicts with TargetMachine triple? - Paweł -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120817/9be1d735/attachment.html>

...an do the coding I you don't mind. Changes to the Triple have pretty wide-reaching implications. Chris, what do you think? -Jim I have one more question. Triples are specified in both modules and TargetMachine. In 3.1 triple from module was used by default. In trunk it has been changed, and LLVM_HOSTTRIPLE is used by default. Do we have any rules in case module triple conflicts with TargetMachine triple? - Paweł _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu http://lists.cs.uiuc...

...n do the coding I you don't mind. Changes to the Triple have pretty wide-reaching implications. Chris, what do you think? -Jim I have one more question. Triples are specified in both modules and TargetMachine. In 3.1 triple from module was used by default. In trunk it has been changed, and LLVM_HOSTTRIPLE is used by default. Do we have any rules in case module triple conflicts with TargetMachine triple? - Paweł _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu http://lists.cs.uiuc...

...to figure it out from here - thanks again. ...which I did - though I had to ensure I had the target triple set in the module just right: "x86_64-apple-darwin" Originally I tried "i686-apple-darwin9" as this is what gcc reports, and what gets burnt into config.h as: #define LLVM_HOSTTRIPLE "i686-apple-darwin9.6.0" However, it dawned on me that I should really be asserting x86_64, and indeed this works nicely if it is also asserted on the ld command line. -- lwe

...> > Changes to the Triple have pretty wide-reaching implications. Chris, what do you think? > > -Jim > > > I have one more question. Triples are specified in both modules and TargetMachine. In 3.1 triple from module was used by default. In trunk it has been changed, and LLVM_HOSTTRIPLE is used by default. Do we have any rules in case module triple conflicts with TargetMachine triple? > > - Paweł > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/m...

Hi Paweł, Thanks for continuing this discussion. I like the simplicity of your suggestion. My only concern involves the ambiguity of what is meant by “environment”. Presently there are functions in the llvm::Triple class to access the environment as an enumeration of a fixed set of values. It seems that some non-enumerated values are already in use, but introducing possible combinations of

...to the Triple have pretty wide-reaching implications. Chris, what do you think? >> >> -Jim >> >> >> I have one more question. Triples are specified in both modules and TargetMachine. In 3.1 triple from module was used by default. In trunk it has been changed, and LLVM_HOSTTRIPLE is used by default. Do we have any rules in case module triple conflicts with TargetMachine triple? >> >> - Paweł >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> ht...

2012/9/13 Kaylor, Andrew <andrew.kaylor at intel.com>: > I'm a bit confused as to what is supposed to happen in the cross building scenarios. For instance, if host=x86_64-linux and target=i686-mingw32, what should the MCJIT tests do? Should they be suppressed because the architectures don't match? If so, what about the case where host=x86_64-linux and target=x86_64-mingw32?

This is a small bug fix for the ocaml build system that allows for dependencies to be generated for ocaml interface files. --- bindings/ocaml/Makefile.ocaml | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 7c62c2cd93a6402e5f6ebd600e9e3ac7851b4d29.diff Type: text/x-patch Size: 994 bytes Desc: not

> It is simpler. There is not any Mach-O envelope. The platform linker > can directly read Mach-O files as well as llvm bit-code file (using > llvm bit-code file reader). > > > Not sure if/where the exact form of the Mach-O file that carries bit > > code is documented. Thanks for that. Yes, I see what you mean (no Mach-O envelope), yet there seems to be something

...an do the coding I you don't mind. Changes to the Triple have pretty wide-reaching implications. Chris, what do you think? -Jim I have one more question. Triples are specified in both modules and TargetMachine. In 3.1 triple from module was used by default. In trunk it has been changed, and LLVM_HOSTTRIPLE is used by default. Do we have any rules in case module triple conflicts with TargetMachine triple? - Paweł _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu<http://llvm.cs.ui...

Hi, all It seems that rev. 131463 [1] makes LLVM failed to recognize ARM correctly. My best guess is the variable LLVM_HOSTTRIPLE got something like "armv7l-unknown-linux-gnueabi" when LLVM compiled natively on ARM. Then the Arch (armv7l) is not recognized by LLVM. As you can see from attach (llvm-131463-gcc-4.4.1-native-arm2.log), there are a lot failure while running test cases under ExecutionEngine/. Those fa...