similar to: [LLVMdev] Ada support for llvm-gcc4

I'm trying to get the Ada gcc front-end to work with LLVM. This series of patches gets things to the point where the Ada compiler builds, though it fails to build itself or the runtime. While I was there I resurrected fortran and java: as with Ada, the compilers build but not the runtimes. Also, I've replaced the gcc 4.0 Ada front-end with a back-port of the Ada front-end from FSF gcc

Hello, Trying to get my machine building up-to-date, and a nightly going, i ran into an assertion during the build of llvm-gcc 4.2: $ make -j2 <snip!> /home/chandlerc/code/compilers/build/llvm-gcc/./gcc/xgcc -B/home/chandlerc/code/compilers/build/llvm-gcc/./gcc/ -B/home/chandlerc/code/compilers/install/llvm-gcc/x86_64-pc-linux-gnu/bin/

Hi Chandler, This looks like a FE error, so you probably won't be able to get an LLVM bitcode file for us. You could help by whittling the test case down to something managable. First get a preprocessed file. Then I would suggest following the instructions on this page to reduce the testcase: http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction That will help us a lot with the bug

Hi Chandler, > void > foo () { > float x __attribute__ ((mode (XF))); > } nice reduction. I don't see any problem on x86-32, and I don't have access to an x86-64 box right now. Can you please open a PR for this, and also run in the debugger. When you hit the abort, use "up" to go up a stack frame or two or three, and print out the gcc types [use: call

On Wednesday 10 October 2007 12:53, Chris Lattner wrote: > On Mon, 8 Oct 2007, Evan Cheng wrote: > > I am turning 32-bit add into 32-bit LEA on x86-64 but that's > > perfectly legal. Both > > leal (%esi,%edi), %eax > > leal (%rsi,%rdi), %eax > > are legal assembly. It's just the former requires a 67H prefix due to > > the 32-bit address size. >

Bam. This is about as reduced as it gets. I think I can spot the problem point: chandlerc at osiris ~/code/compilers/build/llvm-gcc $ cat testcase.i void foo () { float x __attribute__ ((mode (XF))); } chandlerc at osiris ~/code/compilers/build/llvm-gcc $ ./gcc/cc1 -fpreprocessed -march=k8 testcase.i -o /dev/null foocc1: /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:81: const

On Mon, 8 Oct 2007, Evan Cheng wrote: > I am turning 32-bit add into 32-bit LEA on x86-64 but that's > perfectly legal. Both > leal (%esi,%edi), %eax > leal (%rsi,%rdi), %eax > are legal assembly. It's just the former requires a 67H prefix due to > the 32-bit address size. > > This does point to a performance problem in the 3 address conversion > code (which I

Duncan, It would be useful to know what motivated this work -- in particular, is some organization (company, open source project team, research group, any other kind) interested in having an Ada front-end? Thanks, --Vikram ---------------------------------------------------------------------- VIKRAM S. ADVE Associate Professor, Computer Science E-MAIL: vadve at cs.uiuc.edu Siebel

I routinely fetch the latest LLVM and LLVM-GCC4 and recompile, perhaps every few days or so. I've not had success in some cases building LLVM-GCC4 on a Gentoo Linux host, for perhaps the last week or so. My system compiler is GCC 4.1.1. >>> cc1: /usr/src/llvm/llvm/include/llvm/Target/TargetInstrInfo.h:151:const llvm::TargetInstrDescriptor&

Hi, in order to get a handle on the questions in Chris's previous email, I rebuilt LLVM with debugging info, and then rebuilt gcc4 with CHECKING_ENABLED. In the process, I ran into an assertion error when compiling the first part of libgfortran: ../../src/gcc/llvm-convert.cpp:3871: failed assertion `(TREE_CONSTANT(exp) || TREE_CODE(exp) == STRING_CST) && "Isn't a

Hi, I'm trying to get the llvm-test suite going on Fedora Core 5 and I have a number of failures with the current HEAD. The major one (see PR879) has a workaround. Now, I'm getting a conflict in the CBakcned while compiling siod (and others): gcc Output/siod.cbe.c -lm -ldl -fno-strict-aliasing -O2 -o Output/siod.cbe Output/siod.cbe.c:471: error: conflicting types for

Andrew Purtell wrote: > I routinely fetch the latest LLVM and LLVM-GCC4 and recompile, perhaps every few days or so. I've not had success in some cases building LLVM-GCC4 on a Gentoo Linux host, for perhaps the last week or so. My system compiler is GCC 4.1.1. > > > cc1: /usr/src/llvm/llvm/include/llvm/Target/TargetInstrInfo.h:151:const llvm::TargetInstrDescriptor&

Hello, I'm trying to write assembler code writer, and of course, have new questions. I'd like the structure my implementation like this: if (/*binary instruction*/) { // print destination O << " = "; // print first operand O << opcode; // print second operand. } if (/* unary instruction */ ) { .... } if (/*control instruction*/) { ....

Here you go: Starting program: /home/chandlerc/code/compilers/build/llvm-gcc/gcc/cc1 -fpreprocessed -march=k8 testcase.i -o /dev/null warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff0d5fe000 [Thread debugging using libthread_db enabled] foocc1: /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:81: const llvm::Type* llvm_set_type(tree_node*, const

On Wednesday 10 October 2007 17:12, David Greene wrote: > This particular problem is gone (thanks!) but I'm having other troubles. > I'm tracking those down now. This is the current problem: [x86_64-off-dbg]: ./xgcc -B./ -B/install.official.debug/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/bin/ -isystem

Chris Lattner wrote: > On Thu, 2 Mar 2006, Chris Lattner wrote: >>> Any ideas what could be wrong? >> >> Sorry for the delay, please try this tarball: >> http://nondot.org/sabre/2006-03-02-llvm-gcc-4.tar.gz > > Actually, do to a recent change in CVS, this tarball will probably not > work anymore. Please apply the attached (small) patch on top of it in >

Hi all, I'm hoping someone more knowledgeable in Fortran than I can chime in with opinion. I'm the maintainer of the flashClust package that implements fast hierarchical clustering. The fortran code fails when the number of clustered objects is larger than about 46300. My guess is that this is because the code uses the following construct: IOFFSET=J+(I-1)*N-(I*(I+1))/2 where N is the

Known problems with the X86 back-end - The X86 backend does not yet support all inline assembly that uses the X86 floating point stack <http://llvm.org/PR879>. It supports the 'f' and 't' constraints, but not 'u'. - The X86-64 backend does not yet support the LLVM IR instruction va_arg. Currently, front-ends support variadic argument constructs on

On Mon, 6 Mar 2006, Vladimir Prus wrote: > ../../2006-03-02-llvm-gcc-4/gcc/llvm-convert.cpp:1305: error: parse error > before `__attribute__' Can you send me the preprocessed .i file for this file? To work around the above error, just remove "ATTRIBUTE_UNUSED" from that line. > ../../2006-03-02-llvm-gcc-4/gcc/llvm-convert.cpp: In function `tree_node* >

LLVM 2.0 is done! Download it here: http://llvm.org/releases/ or view the release notes: http://llvm.org/releases/2.0/docs/ReleaseNotes.html LLVM 2.0 is a great release in many ways. It includes a wide range of new features, new optimizations, better codegen, and new targets. We were also able to signficantly revise several core aspects of the LLVM IR and design (such as the type system