similar to: [LLVMdev] amd x86_64: fixunsdfti

This is not yet supported by the llvm x86 backend. Perhaps there is a configuration option (or you may have to hack up some files in config/ i386) to disable gcc long double support? Evan On Oct 9, 2006, at 11:50 AM, Scott Michel wrote: > Anyone run across __fixunsdfti relocation problems while building the > llvm gcc frontend on an AMD-64 box under linux? For some reason, > TImode

> See ix86_return_in_memory. (In 4.3 this is renamed to > return_in_memory_32.) > i128==TImode. But TImode should be used for __m128 stuff only there, not for integers. I'm looking into gfortran now. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

I read the README and I think I noted all the relevant pitfalls, but something still goes wrong. I didn't see anything similar in this months list archives either. On the other hand, I see the release notes do not list linux x86_64 as a known good architecture - only linux IA32 (though MacOS X is said to be supported on x86 in 64 bit mode). Am I trying to do the impossible? $ tar xvf

Maybe it's because I've got a lot of two machine operand instructions and have to rely on the tied-to constraint, but I'm seeing a lot of dead reg-to-reg copy instructions, e.g.: ori $3, $3, 0 (Cell SPU's version of reg-to-reg copy, looks a lot like PPC, no?) Is there any way I can detect when this occurs, or is there code where this detection takes place in the target to which

Reid Spencer wrote: > This is an libpath problem. When xgcc runs it wants to dynamically linkthe libgcc.so. > When you run it from the command line it will find yoursystem libgcc.so (which works) Not really. For systems that have gcc 4.2 natively installed, like the current Debian testing, the compiler gets GCC_4.2.0 version errors. It isn't easy to work around b/c xgcc wants to link

On 1/18/07, Scott Michel <scottm at rushg.aero.org> wrote: > Is there any way I can detect when this occurs, or is there code > where this detection takes place in the target to which I can > refer? have you implemented InstInfo::isMoveInstr to recognize those? The register allocator uses that to find copies it can remove. Andrew

Hi Bill, this might be a latent bug related to PPC. I have no such machine to access atm., but I shall be able to reproduce the problem when back at home. (In about 4 hours). I keep you informed. Cheers, Gabor On Mar 4, 7:57 pm, Bill Wendling <wendl... at apple.com> wrote: > Something last night broke the build on Darwin PPC. Possible Gabor's   > check-in? > > -bw

Something last night broke the build on Darwin PPC. Possible Gabor's check-in? -bw Begin forwarded message: > From: admin at spang.apple.com (admin) > Date: March 4, 2009 3:56:10 AM PST > To: wendling at apple.com > Subject: PPC Nightly Build Result > > /Volumes/SandBox/NightlyTest/llvmgcc42.roots/llvmgcc42~obj/obj- > powerpc-powerpc/./prev-gcc/xgcc

Hi Jack, > Actually, shouldn't this be just an error in the Makefile.in or > Makefile.am? Why should a link line like... ... > ..even require c++ instead of xgcc? because xgcc may not support c++. I'm not saying that it can't be done, just that it has not been done. Like anything, someone has to sit down and do it, and nobody has done so yet. Ciao, Duncan.

Am Sonntag, den 22.06.2008, 15:19 +0100 schrieb Alan Jenkins: > config.log: > > configure:2119: checking for C compiler default output file name > configure:2122: /home/alan/pkg/llvm/obj/./prev-gcc/xgcc > -B/home/alan/pkg/llvm/obj/./prev-gcc/ > -B/usr/local/x86_64-unknown-linux-gnu/bin/ -g -O2 conftest.c >&5 > configure:2125: $? = 0 > configure:2171: result:

I'm on Debian Etch and re-compile llvm/llvm-gcc-4.2 from scratch. I'm on svn revision 46813. I'm using the following commands for the compilation: ---------------------------------- # Get the sources mkdir /s/llvm cd /s/llvm svn co http://llvm.org/svn/llvm-project/llvm/trunk /s/llvm/svn.llvm svn co http://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk /s/llvm/svn.gcc42 # Compile llvm

On Jan 10, 2008, at 12:52 PM, Thomas Jablin wrote: >> > Based on your response I've removed the #undef DBX_DEBUGGING_INFO in > gcc/config/ia64/sysv4.h. I don't need stabs debugging so if it is > broken > in my final build, I won't care. After doing so, my llvm-gcc build > runs > for a much longer time before finally dying while running xgcc. Here > is

The machine is a Dell workstation with xeon processors. The OS is RHEL 4 AS x86_64 gcc version is 3.4.6 I checked out the llvm-gcc from svn, configured with ../llvm-gcc/configure --prefix=$HOME/llvm-gcc-install --enable-llvm=$HOME/llvmobj/ --enable-languages=c,c++ --enable-checking --disable-shared --disable-multilib and get the following error message: make

On 11/27/06, Scott Michel <scottm at rushg.aero.org> wrote: > Anton Korobeynikov wrote: > >>the official cutover. Granted, you might need darcs to pull the current > >>version out of its repo, since it was originally designed with darcs in > >>mind. > > > > I can confirm, that tailor converts LLVM CVS with all history preserved > > to mercurial

gcc 3.4.x builds LLVM incorrectly on x86_64. gcc 4.0 will get you much farther, but the llvm-test regression tests still have massive problems. Zhongxing Xu wrote: > The machine is a Dell workstation with xeon processors. The OS is RHEL > 4 AS x86_64 > gcc version is 3.4.6 > > I checked out the llvm-gcc from svn, configured with > ../llvm-gcc/configure

This is an libpath problem. When xgcc runs it wants to dynamically link the libgcc.so. When you run it from the command line it will find your system libgcc.so (which works) and so you don't see the segfault. When you run xgcc from the Makefile, it will have set LD_LIBRARY_PATH to get your <cfebuilddir>/gcc directory which will find the libgcc.so that it just built, which is the one

Hello, Aaron. > This is still at the stage of using xgcc.exe AFAICT before any LLVM bytecode > generation. Yep. But xgcc generates code via LLVM! So, you can just copy command line from your terminal, add -emit-llvm, run it and you'll see, that resulting .o will be LLVM bytecode (or won't if FE will crash). > __eprintf is a very simple function so I do not know what could be

Dale Johannesen wrote: > > That's an LLVM bug. Inline assembly is known to have some problems. > I'm not sure how robust the ia64 implementation is. > > Configuring with > BOOTSTRAP= > should stop it from trying to bootstrap. However, it's still likely > to try to build the file that's causing trouble. > Is there any reason why I can't use xgcc

Hi Guys I'm trying to port and build the GCC Front End to the Interix environment. I've succeded until the xgcc program executes: /usr/local/src/cfrontend/build/gcc/xgcc -B/usr/local/src/cfrontend/build/gcc/ -B/usr/local/src/cfrontend/install//i586-pc-interix3/bin/ -B/usr/local/src/cfrontend/install//i586-pc-interix3/lib/ -isystem

I know that Al Stone has compiled llvm-gcc4 successfully and I can report the same. The problem I consistently run into is that llvm-gcc ends up producing native format output; it does not produce bytecode, nor does it invoke gccas or gccld. I'm using the latest svn, and my configure args are: --prefix=/work/scottm/llvm-cfrontend/obj/../i686-pc-linux-gnu \