similar to: [LLVMdev] Cygwin llvm-gcc regression

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

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

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

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().

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* >

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

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

llvm itself compiles fine. gcc frontend has the error, see below. 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. FreeBSD -8.0-STABLE gcc-4.5.0 sunblade 100 Yuri gmake[2]: Leaving directory `/tmp/llvm-build/2.7/llvm-gcc-4.2-objects/libdecnumber'

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 =

I have started working on an implementation of atomic_ref. Implementing this requires performing atomic operations on arbitrary references. The behavior is undefined if a reference is provided that is not aligned per the public export required_alignment. What assumptions do the __c11_atomic builtins make about destination argument alignment, format, size etc.? Is it required that the destination

libswfdec/Makefile.am | 4 + libswfdec/swfdec_as_context.c | 10 +- libswfdec/swfdec_as_function.c | 130 +++------------------------------- libswfdec/swfdec_as_function.h | 28 +------ libswfdec/swfdec_as_interpret.c | 7 + libswfdec/swfdec_as_native_function.c | 113 +++++++++++++++++++++++++++++ libswfdec/swfdec_as_native_function.h | 68

Now that I'm working on codegen support for arbitrary precision integers (think i36 or i129), I've hit the problem of what getTypeSize and friends should return for such integers (the current implementations seem to me to be wrong). However it's not clear to me how getTypeSize and friends are defined. There seem to be several possible meanings for the size of a type (only talking

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.

Hi Daniel, 2009/7/26 Daniel Dunbar <daniel at zuster.org> > Hi Aaron, > > Which revision are you building? 77074 >Assuming TOT, it's possible this is a bug that I introduced/triggered >with the name changes. Yes I am now getting the following :- c++ -c -g -DIN_GCC -W -Wall -Wwrite-strings -pedantic -Wno-long-long -Wno-variad ic-macros -Wmissing-format-attribute

I am getting the following on 'make install' on Cygwin both on debug and release builds :- llvm[3]: Installing Release /home/ang/llvm-coff/bin/llvmc.exe make[3]: Leaving directory `/home/ang/build/llvm-coff/tools/llvmc/driver' make[2]: Leaving directory `/home/ang/build/llvm-coff/tools/llvmc' make[1]: Leaving directory `/home/ang/build/llvm-coff/tools' make[1]: Entering

Getting the following on Cygwin :- Running /home/ang/svn/llvm/test/Bindings/Ocaml/ocaml.exp ... FAIL: /home/ang/svn/llvm/test/Bindings/Ocaml/analysis.ml Failed with exit(2) at line 1 while running: /usr/bin/ocamlc -cc g++ -I /home/ang/build/llvm/Debug/lib/ocaml - warn-error A llvm.cma llvm_analysis.cma /home/ang/svn/llvm/test/Bindings/Ocaml/a nalysis.ml -o analysis.ml.tmp 2> /dev/null child

/home/ang/build/llvm-gcc-coff/./gcc/xgcc -B/home/ang/build/llvm-gcc-coff/./gcc/ -B/home/ang/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-cygwin/sys-include -O2 -I/home/ang/svn/llvm-gcc-coff/gcc/../winsup/w32 api/include -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings

Hi, I don't seem to be able to solve this regression with llvm-gcc-4.2 on Cygwin. It is weird as I thought I had checked SVN TOT and had a good build just before the branch was corrected, so am confused. If someone more experienced with debugging could have a look at this, its like a syntax error. I have tried whittling the error down but it just moves. Trying to bisect between r98185 and

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

Hi Aaron, Which revision are you building? Assuming TOT, it's possible this is a bug that I introduced/triggered with the name changes. I know nothing of the status of cygwin however, can you confirm that this used to work? If you use r77097, does it work? - Daniel On Sun, Jul 26, 2009 at 4:23 AM, Aaron Gray<aaronngray.lists at googlemail.com> wrote: > I am getting an error