search for: dumpmachin

...and implement a new target in glibc based on that machine string. So I propose that llvm-gcc not consider itself any type of x86-linux (or what ever it platform it was compiled on), but rather create a new architecture, say llvm (or perhaps 2, one for each bit and little endian). Thuse llvm-gcc -dumpmachine would return llvm-os. This would make system library (and OS kernel!) ports easier to maintain since arch llvm would be supported by adding stuff rather than changing stuff, and all the inline asm for known archs would go away and the C version would be used. In most cases the config scripts sho...

...eaving directory `/home/wferi/syslinux/syslinux/efi32/efi' >> make[2]: *** [efi] Error 2 >> [...] > > This is a build-system bug in mk/efi.mk. I'm looking at adding a > condition to prevent this. Would you perhaps be building on an x86_64 OS (as shown by 'gcc -dumpmachine') but not have gcc-multilib installed? -- -Gene

...7: Error: suffix or operands invalid for `push' /tmp/ccuWW3r0.s:37: Error: suffix or operands invalid for `call' /tmp/ccuWW3r0.s:55: Error: suffix or operands invalid for `push' /tmp/ccuWW3r0.s:65: Error: suffix or operands invalid for `call' make: *** [crtbegin.o] Error 1 ./xgcc -dumpmachine gives i686-pc-linux-gnu so this is OK. The reported lines are: 27 pushl %ebp 37 call *%edx 55 pushl %ebp 65 call *%eax What's wrong? Regards, Jo P.S.: I'm running with a freshly compiled and PATH-installed llvm package with...

On Thu, 16 Sep 2004, Andrew Lenharth wrote: > So I propose that llvm-gcc not consider itself any type of x86-linux (or > what ever it platform it was compiled on), but rather create a new > architecture, say llvm (or perhaps 2, one for each bit and little > endian). Thuse llvm-gcc -dumpmachine would return llvm-os. Hrm, I would much rather just have LLVM be a drop in replacement for a C compiler. As such, it should expose identical #defines to GCC. > This would make system library (and OS kernel!) ports easier to maintain > since arch llvm would be supported by adding stuff rat...

...or `push' > /tmp/ccuWW3r0.s:37: Error: suffix or operands invalid for `call' > /tmp/ccuWW3r0.s:55: Error: suffix or operands invalid for `push' > /tmp/ccuWW3r0.s:65: Error: suffix or operands invalid for `call' > make: *** [crtbegin.o] Error 1 > > > ./xgcc -dumpmachine gives > i686-pc-linux-gnu > so this is OK. > > The reported lines are: > 27 pushl %ebp > 37 call *%edx > 55 pushl %ebp > 65 call *%eax > > What's wrong? > > Regards, > Jo > > P.S.:...

...re a number of postings in March. The issue seemed to not have been fully resolved but I added "i686-pc-linux-gnu" to the end of my command line and now the whole thing compiles. I cannot find a llvm-gcc binary in my install directory, all I have is gcc which reports: ../export/bin/gcc -dumpmachine i686-pc-linux-gnu It turns out I can generate llvm assembler output using "-S -emit-llvm" but using just -emit-llvm does not work ./gcc -emit-llvm /home/robertm/hello.c /tmp/cc3X2m5t.o: file not recognized: File format not recognized collect2: ld returned 1 exit status Is this expect...

...-w64 with the following invocation: make -f Makefile.lite libFLAC libFLAC++ flac metaflac test_libs_common test_libFLAC test_libFLAC++ test_grabbag test_seeking test_streams utils examples This patch addresses eight points: 1. `uname -p` in MSYS returns "unknown" so we must use `gcc -dumpmachine` to gain information about the target, 32-bit or 64-bit. 2. MinGW-w64 does not ship with a working iconv.h, so we must disable it under this specific compiler. 3. The code requires <inttypes.h> in a handful of C files, but config.mk did not contain -DHAVE_INTTYPES_H, which under the full b...

Hi - attached is a patch to enable building DragonEgg (x86_64) for LLVM3.3 and LLVM3.4. That is, add these changes to the 3.3 release, and it becomes possible to build DragonEgg against a llvm3.4 compiler. Regards, Richard Gorton Cognitive Electronics rcgorton at cog-e.com ---------- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name:

...error? > Thanks a lot for your time and help. The backend is designed for SparcV9 and uses inline assembly, some of which may be V9-only. Your error indicates that your GCC was configured for SparcV8 instead. One way to check what your GCC thinks it's compiling for is as follows: % gcc -dumpmachine sparcv9-sun-solaris2.8 If your output is "sparcv8-...", then you may need to build a new version of GCC. -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu

On Thu, Oct 07, 2004 at 06:46:18PM -0400, Shukang Zhou wrote: > Thanks Misha. I tried the "gcc -dM -E /tmp/file.c | grep __sparcv9" > but there was no output. Maybe this is the probelm, I do have > > CXX = g++ -mcpu=v9 > CC := gcc -mcpu=v9 > > in the Makefile.config. Do I need to add -m64 as well? Thanks. Just run the test that I mentioned before: > On Thu, 7

...define __sparcv9 1 If the above command gives no output, then try again, specifying -m64. The key is to get __sparcv9 #defined, because there is code in the SparcV9 JIT that is conditionally compiled based on it. If none of the above define __sparcv9, what is the output of the following? % gcc -dumpmachine -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu

Thanks Misha. I tried the "gcc -dM -E /tmp/file.c | grep __sparcv9" but there was no output. Maybe this is the probelm, I do have CXX = g++ -mcpu=v9 CC := gcc -mcpu=v9 in the Makefile.config. Do I need to add -m64 as well? Thanks. Shukang On Thu, 7 Oct 2004, Misha Brukman wrote: > Is your compiler configured to define __sparcv9 when it compiles? > The following should tell

...-w64 with the following invocation: make -f Makefile.lite libFLAC libFLAC++ flac metaflac test_libs_common test_libFLAC test_libFLAC++ test_grabbag test_seeking test_streams utils examples This patch addresses eight points: 1. `uname -p` in MSYS returns "unknown" so we must use `gcc -dumpmachine` to gain information about the target, 32-bit or 64-bit. 2. MinGW-w64 does not ship with a working iconv.h, so we must disable it under this specific compiler. 3. The code requires <inttypes.h> in a handful of C files, but config.mk did not contain -DHAVE_INTTYPES_H, which under the full b...

...inux/syslinux/efi32/efi' >>> make[2]: *** [efi] Error 2 >>> [...] >> >> This is a build-system bug in mk/efi.mk. I'm looking at adding a >> condition to prevent this. > > Would you perhaps be building on an x86_64 OS (as shown by 'gcc > -dumpmachine') but not have gcc-multilib installed? Absolutely! Now I installed gcc-multilib, and make still fails with: make[3]: Leaving directory `/home/wferi/syslinux/syslinux-multilib/efi32/sample' make -r -C efi SRC="/home/wferi/syslinux/syslinux-multilib/efi" OBJ="/home/wferi/sy...

Hi, I met some errors when I tried to build LLVM. The tar file is llvm-1.3.tar.gz. I am using a sparc machine with gcc 3.2.2. ------------- Compiling SparcV9CodeEmitter.cpp /uf24/zhou/research/llvm/src/lib/Target/SparcV9/SparcV9CodeEmitter.cpp: In static member function `static void llvm::<unnamed>::JITResolver::CompilationCallback()':

...37: Error: suffix or operands invalid for `call' > > /tmp/ccuWW3r0.s:55: Error: suffix or operands invalid for `push' > > /tmp/ccuWW3r0.s:65: Error: suffix or operands invalid for `call' > > make: *** [crtbegin.o] Error 1 > > > > > > ./xgcc -dumpmachine gives > > i686-pc-linux-gnu > > so this is OK. > > > > The reported lines are: > > 27 pushl %ebp > > 37 call *%edx > > 55 pushl %ebp > > 65 call *%eax > > > > Wha...

...004, Andrew Lenharth wrote: > > So I propose that llvm-gcc not consider itself any type of x86-linux (or > > what ever it platform it was compiled on), but rather create a new > > architecture, say llvm (or perhaps 2, one for each bit and little > > endian). Thuse llvm-gcc -dumpmachine would return llvm-os. > > Hrm, I would much rather just have LLVM be a drop in replacement for a C > compiler. As such, it should expose identical #defines to GCC. A drop in replacement for "a C compiler" is rather a different requirement than a drop in replacement for GCC....

On May 28, 2008, at 5:22 PM, robert muth wrote: > I have problem compiling the gcc frontend. > Almost everything seems to compile but at the very end > when crt startup files are compiled, the assembler complains > about bad registers. > Any idea what I am doing wrong? > Thanks, > Robert It looks like your assembler is being invoked in 32-bit mode. Other people have had

Reid Spencer wrote: > In order to get to the next stage with LLVM (like compiling a kernel) we > need to allow "pass through" of inline assembly so things like device > drivers, interrupt vectors, etc. can be written. While this feature > breaks the "pure" LLVM IR, I don't see any way around it. <shameless plug> Actually, there should be a way around it.

I have problem compiling the gcc frontend. Almost everything seems to compile but at the very end when crt startup files are compiled, the assembler complains about bad registers. Any idea what I am doing wrong? Thanks, Robert HOST: os: ubuntu 2.6.18 kernel x86_64 GNU/Linux compiler: gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) SOURCE: svn trunk gcc4.2 CONFIGURE: