Displaying 20 results from an estimated 400 matches similar to: "[LLVMdev] Failure to compile llvm-gcc-4.2-2.7 on FreeBSD on sparc machine"
2010 May 06
0
[LLVMdev] Failure to compile llvm-gcc-4.2-2.7 on FreeBSD on sparc machine
Hello
> I applied the attached patch, since the name of architecture on FreeBSD is
> sparc64, not sparc. There is also one more replacement sparc -> spaarc64 was
> made in gcc/Makefile in llvm-gcc.
The patch is incorrect and the problems you're seeing are caused by
your patch, since sparc != sparc64.
In LLVM sense "sparc" means "sparc with ILP32 architecture
2011 Apr 09
0
[LLVMdev] dragonegg/llvm-gfortran/gfortran benchmarks
On Sat, Apr 09, 2011 at 08:56:49AM -0600, Marcus G. Daniels wrote:
> On 4/9/2011 6:09 AM, Duncan Sands wrote:
> > Hi Jack, thanks for the numbers. Any chance of analysing why gcc does better on
> > those where it does much better than dragonegg?
> >
> > Ciao, Duncan.
> Also, does -fplugin-arg-dragonegg-enable-gcc-optzns get Dragonegg to
> match GCC performance
2010 Jan 10
0
[LLVMdev] Cygwin llvm-gcc regression
2010/1/10 Aaron Gray <aaronngray.lists at googlemail.com>
> 2010/1/10 Duncan Sands <baldrick at free.fr>
>
> Hi Aaron,
>>
>>
>> Thanks, okay heres the results :-
>>>
>>> LLVM type size doesn't match GCC type size!
>>>
>>> <real_type 0x7ff80b40 long double sizes-gimplified XF size <integer_cst
>>>
2008 Nov 02
1
[LLVMdev] llvm-2.4 prerelease gfortran results
Anton,
With regard to the gfortran test cases which don't fail
on x86_64 Linux, these are the exact gfortran.log entries for them
under i686 Darwin9...
> FAIL: gfortran.dg/array_constructor_12.f90 -O0 (internal compiler error)
> FAIL: gfortran.dg/array_constructor_12.f90 -O0 (test for excess errors)
Executing on host:
2008 Mar 27
2
[LLVMdev] llvm-gcc 4.2 assertion failed on linux x86_64
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
2010 Mar 09
0
[LLVMdev] Fwd: help with llvm-convert
On alpha, I am seeing a problem with Emiting va_copy. valists are
structs and allocated by alloca, unlike x86. EmitBuiltinVACopy is
therefore using the second branch of the if (~llvm-convert.cpp:6538)
to emit the second argument. The second argument is the result of an
alloca. TreeToLLVM::Emit is hitting the first assertion (~929).
The exp being passed is:
<var_decl 0x20000b44240 ap
2008 Mar 27
0
[LLVMdev] llvm-gcc 4.2 assertion failed on linux x86_64
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
2006 Sep 05
2
[LLVMdev] gfortran: array constructor problems
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
2011 Apr 09
3
[LLVMdev] dragonegg/llvm-gfortran/gfortran benchmarks
On 4/9/2011 6:09 AM, Duncan Sands wrote:
> Hi Jack, thanks for the numbers. Any chance of analysing why gcc does better on
> those where it does much better than dragonegg?
>
> Ciao, Duncan.
Also, does -fplugin-arg-dragonegg-enable-gcc-optzns get Dragonegg to
match GCC performance where GCC was faster?
Marcus
2010 Jan 08
3
[LLVMdev] Cygwin llvm-gcc regression
I am getting an assertion firing while building TOT llvm-gcc on Cygwin in
libgcc2.c :-
/home/ang/build/llvm-gcc/./gcc/xgcc -B/home/ang/build/llvm-gcc/./gcc/
-B/home/an
g/llvm-gcc/i686-pc-cygwin/bin/ -B/home/ang/llvm-gcc/i686-pc-cygwin/lib/
-isystem
/home/ang/llvm-gcc/i686-pc-cygwin/include -isystem
/home/ang/llvm-gcc/i686-pc-c
ygwin/sys-include -O2
2006 Mar 16
0
[LLVMdev] Re: Re: Re: Re: Re: New GCC4-based C/C++/ObjC front-end for LLVM
Vladimir Prus wrote:
> So, it looks either the snapshot is not in stable state, or there's
> something seriously wrong with type name handling. At this point I gave up
> on quickly fixing this, so I've applied the third attached patch to LLVM,
> which "fixes" this issue completely.
Ah, hell, as soon as I've send this email I've updated from CVS to find that
2006 Sep 11
0
[LLVMdev] trying to build llvm-gcc in linux/amd64
On Mon, 11 Sep 2006, [UTF-8] Rafael Esp?ndola wrote:
> I am trying to build llvm-gcc4 on a amd64. I had to add the attached
> patch to get the build system to select the correct library. Now the
Applied.
> build fails while compiling a code that has __builtin_va_copy. The
> attached test.i fails with:
>
> cc1: ../../trunk/gcc/llvm-convert.cpp:443: llvm::Value*
>
2006 Sep 11
5
[LLVMdev] trying to build llvm-gcc in linux/amd64
I am trying to build llvm-gcc4 on a amd64. I had to add the attached
patch to get the build system to select the correct library. Now the
build fails while compiling a code that has __builtin_va_copy. The
attached test.i fails with:
cc1: ../../trunk/gcc/llvm-convert.cpp:443: llvm::Value*
TreeToLLVM::Emit(tree_node*, llvm::Value*): Assertion
`(isAggregateType(((exp)->common.type)) == (DestLoc
2008 Mar 27
2
[LLVMdev] llvm-gcc 4.2 assertion failed on linux x86_64
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
2009 Jan 09
2
[LLVMdev] RFC: Store alignment should be LValue alignment, not source alignment
Hi all,
Please review this patch. It's fixing PR3232 comment #8. Function bar
from 2008-03-24-BitFiled-And-Alloca.c compiles to:
%struct.Key = type { { i32, i32 } }
...
define i32 @bar(i64 %key_token2) nounwind {
entry:
%key_token2_addr = alloca i64 ; <i64*> [#uses=2]
%retval = alloca i32 ; <i32*> [#uses=2]
%iospec =
2009 Jan 09
0
[LLVMdev] RFC: Store alignment should be LValue alignment, not source alignment
Hi Evan,
> LValue LV = EmitLV(lhs);
> bool isVolatile = TREE_THIS_VOLATILE(lhs);
> unsigned Alignment = expr_align(exp) / 8
>
> It's using the alignment of the expression, rather than the memory
> object of LValue.
can't you just use expr_align(lhs) instead?
> The patch saves the alignment of the memory object in LValue returned
> by EmitLV().
2006 Sep 02
0
[LLVMdev] gfortran calling convention
On Fri, 1 Sep 2006, Michael McCracken wrote:
> Here's what works now, and I have a separate test case for each of these:
>
> statement functions
> intrinsic functions (print, cos, etc)
> loops, goto statments
> scalarized array operations
> function calls with *no arguments*
> simple common blocks
Great!
> Function calls with more than one argument don't work.
2006 Sep 02
2
[LLVMdev] gfortran calling convention
The NIST F77 test suite doesn't seem to be compatible with gfortran at
all, so I had to work from my own sample codes, and generate test
cases from them.
Here's what works now, and I have a separate test case for each of these:
statement functions
intrinsic functions (print, cos, etc)
loops, goto statments
scalarized array operations
function calls with *no arguments*
simple common
2006 Mar 16
2
[LLVMdev] Re: Re: Re: Re: Re: New GCC4-based C/C++/ObjC front-end for LLVM
Evan Cheng wrote:
> Hi,
>
> Here is the follow on patch for this problem. Please apply this from
> the top of the tree and rebuild.
With the patch from Chris and then the patch from you combined, the previous
error disappeared, but I get another error, reduced to this:
./cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mtune=pentiumpro
-auxbase-strip libgcc/./_clz.o -g -O2
2008 Feb 16
3
[LLVMdev] linux/x86-64 codegen support
See the bug for a reduction and the gimple trees. validate_arglist
definately is rejecting the arglist in EmitBuiltinAlloca.
(try:
bool TreeToLLVM::EmitBuiltinAlloca(tree exp, Value *&Result) {
tree arglist = TREE_OPERAND(exp, 1);
if (!validate_arglist(arglist, INTEGER_TYPE, VOID_TYPE)) {
debug_tree(arglist);
return false;
}
Value *Amt = Emit(TREE_VALUE(arglist), 0);
Amt =