search for: main__

...lli hellof.bc ERROR : 'main' function not found in module. $ llc hellof.bc -o hellof.s $ gcc hellof.s -o hellof.native ERROR: /usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/crt1.o: In function `_start': (.text+0x18): undefined reference to `main' /tmp/cc4i3wD7.o: In function `MAIN__': (.text+0x1f): undefined reference to `_gfortran_set_std' /tmp/cc4i3wD7.o: In function `MAIN__': (.text+0x4b): undefined reference to `_gfortran_st_write' /tmp/cc4i3wD7.o: In function `MAIN__': (.text+0x63): undefined reference to `_gfortran_transfer_character' /tmp/cc4i3wD...

...used ignored asm-frame-size 0 DI file /sw/src/fink.build/llvm-gcc42-2.4-1/llvm-gcc4.2-2.4.source/gcc/testsuite/gfortran.dg/array_constructor_12.f90 line 11 size <integer_cst 0x41704930 64> unit size <integer_cst 0x41704960 8> align 64 context <function_decl 0x4175d400 MAIN__> LLVM: i64 %67 chain <var_decl 0x41774310 D.927 type <integer_type 0x4170a4d0 int8> used ignored asm-frame-size 0 DI file /sw/src/fink.build/llvm-gcc42-2.4-1/llvm-gcc4.2-2.4.source/gcc/testsuite/gfortran.dg/array_constructor_12.f90 line 11 size <integer_cs...

...naged to invoke the lli properly, but with llvm-gfortran compiled programs, it fails with the following message: philou at tleilax:~/gcc/llvm/install/bin$ lli ./main.bc 'main' function not found in module. I understand it does not find the entry point of the program ( gfortran creates a MAIN__ function to be linked with some other code ). What should I so to have the lli running fortran code ? Regards, Philippe _________________________________________________________________ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.a...

...../../bin/R CMD LINK gcc -o Rtest Rtest.o embeddedRCall.o -L/home/laurent/R-clean/lib -lR mkdir .libs gcc -o Rtest Rtest.o embeddedRCall.o -L/home/laurent/R-clean/lib -lR -R/home/laurent/R-clean/lib/R/lib Undefined first referenced symbol in file MAIN__ /home/laurent/R-clean/lib/libR.so ld: fatal: Symbol referencing errors. No output written to Rtest collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `Rtest' ----------------------- I have installed R from source using...

...m-gcc does? > It give following errors on both 32bit and 64bit Ubuntu. > $ llvm-gfortran -O3 -emit-llvm hello.f95 -c -o hellof.bc > $ lli hellof.bc > ERROR : 'main' function not found in module. The reason for this is that Fortran outputs the entry point into your program as MAIN__ not main. Instead "main" is defined in libgfortranbegin; it does some initialization (exception handling, command line arguments, others?) then calls MAIN__. I don't know much about lli, so hopefully someone else can explain how to handle this situation. > $ llc hellof.bc -o hel...

...-unknown-linux-gnu/libgfortran/.libs/libgfortran.a It's different to the system original libgfortran.a: -rw-r--r-- 1 root root 1854562 2008-10-25 01:40 /usr/lib/gcc/x86_64-linux-gnu/4.3/libgfortran.a If replace it by system 'libgfortran.a', the error became: hello.o: In function `MAIN__': (.text+0x1e): undefined reference to `_gfortran_set_std' collect2: ld returned 1 exit status Thanks, Jun -- View this message in context: http://www.nabble.com/llvm-gfortran-gives-errors-on-AMD64-Ubuntu-tp20280697p20373363.html Sent from the LLVM - Dev mailing list archive at Nabble...

...Error in dyn.load(x, as.logical(local), as.logical(now)) : unable to load shared library "/usr/lib/R/library/ctest/libs/ctest.so": ld.so.1: /usr/java1.2/bin/../jre/bin/../bin/sparc/native_threads/java: fatal: relocation error: file /usr/lib/R/library/ctest/libs/ctest.so: symbol MAIN__: referenced symbol not found [omegahat->R] SIGSEGV 11* segmentation violation I''ve been trying to figure this problem out for a while, but I haven''t had any luck yet. This occurs for any R-Java program I run.. i install it onto two different machines and they both yielde...

...funccall-1arg.exe ..../llvm/lib/VMCore/Instructions.cpp:209: failed assertion `(Params.size() == FTy->getNumParams() || (FTy->isVarArg() && Params.size() > FTy->getNumParams())) && "Calling a function with bad signature!"' funccall-1arg.f: In function 'MAIN__': funccall-1arg.f:5: internal compiler error: Abort trap Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://llvm.org/bugs> for instructions. make: *** [funccall-1arg.exe] Error 1 While I didn't entirely understand the cause from the backtraces a...

...++,fortran this looks ok to me. It's essentially the same as what I use. Try with 2.4 (about to be released). I'm not sure I ever tried to build the 2.3 version of llvm-gfortran on x86-64. > If replace it by system 'libgfortran.a', the error became: > hello.o: In function `MAIN__': > (.text+0x1e): undefined reference to `_gfortran_set_std' > collect2: ld returned 1 exit status Probably your system gcc version is different to 4.2. Like gcc 4.2, llvm-gcc generates a call to gfortran_set_std in MAIN__. This function is defined in the gcc 4.2 version of libgfor...

....../llvm/lib/VMCore/Instructions.cpp:209: failed assertion > `(Params.size() == FTy->getNumParams() || (FTy->isVarArg() && > Params.size() > FTy->getNumParams())) && "Calling a function with bad > signature!"' > funccall-1arg.f: In function 'MAIN__': > funccall-1arg.f:5: internal compiler error: Abort trap > Please submit a full bug report, > with preprocessed source if appropriate. > See <URL:http://llvm.org/bugs> for instructions. > make: *** [funccall-1arg.exe] Error 1 Okay, this is probably due to the fact that t...

...../../bin/R CMD LINK gcc -o Rtest Rtest.o embeddedRCall.o -L/home/laurent/R-clean/lib -lR mkdir .libs gcc -o Rtest Rtest.o embeddedRCall.o -L/home/laurent/R-clean/lib -lR -R/home/laurent/R-clean/lib/R/lib Undefined first referenced symbol in file MAIN__ /home/laurent/R-clean/lib/libR.so ld: fatal: Symbol referencing errors. No output written to Rtest collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `Rtest' ----------------------- I have installed R from source using...

...amples # perl test.pl 1..1 ok 1 Error in dyn.load(x, as.logical(local), as.logical(now)) : unable to load shared library "/tools/R/current/lib/R/library/stats/libs/stats.so": ld.so.1: perl: fatal: relocation error: file /tools/R/current/lib/R/library/stats/libs/stats.so: symbol MAIN__: referenced symbol not found Loaded RSPerl library objects $.PerlReference [.PerlArrayReference [.PerlHashReference [<-.PerlArrayReference [<-.PerlHashReference addConverter foreignReference getNumPerlConverters getPerlConverterDescriptions getPerlHandler getPerlScript names.PerlHashReference...

...ow f951 doesn't crash when compiling, but still can't compile the libgfortran files. It now finds some syntax errors in a generated file that's part of the intrinsics library. It does compile a very simple test program. It generates reasonable-looking LLVM code, except for using "MAIN__" instead of "main" for the main procedure. I suspect that may be solved by libgfortran once that's working. After editing that, the simple example runs in lli up to the linking errors where the libgfortran routines are called. I'm looking into the errors, and I'll update...

...lection of the gimple: the differences for the loop part come directly from differences in the gimple; (2) the optimizers do a better good when you have "compute" partly because you provided them with additional aliasing information; this better optimized version then gets inlined into MAIN__. (3) this leaves the question of whether in the bad version it is logically possible for the optimizers to deduce the same aliasing information as is handed to them for free in the good version. To work this out it would be nice to have a smaller testcase. Ciao, Duncan. PS: Gimple differences...

...ferences for the loop part come directly from > differences > in the gimple; > (2) the optimizers do a better good when you have "compute" partly > because you > provided them with additional aliasing information; this better optimized > version then gets inlined into MAIN__. > (3) this leaves the question of whether in the bad version it is > logically > possible for the optimizers to deduce the same aliasing information as is > handed to them for free in the good version. To work this out it would be > nice to have a smaller testcase. I would also...

...1>&AC_FD_CC 2>&AC_FD_CC - ${CC} ${LDFLAGS} -o conftest conftest.o ${FLIBS} \ - 1>&AC_FD_CC 2>&AC_FD_CC + case ${host} in + alpha*osf*) + if test -z "${G77}"; then + # DEC fortran "f77 -c" creates only a MAIN__ symbol and + # the "main" symbol is inserted by linking with "f77" + # (unless called with -nofor_main), so linking with + # cc would need /usr/lib/cmplrs/fort/for_main.o explicitely, + # but adding this to FLIBS would break...

...ctive plugins, do not report this as a bug unless you can reproduce it without enabling any plugins. Event | Plugins PLUGIN_FINISH_UNIT | dragonegg PLUGIN_FINISH | dragonegg PLUGIN_START_UNIT | dragonegg ac.f90: In function ‘MAIN__’: ac.f90:109:0: internal compiler error: Abort trap Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. This appears to be due to the -ftree-vectorize as -O3 --fno-tree-vectorize doesn't show this ICE but -O2 -ftr...

...rt come directly from >> differences >> in the gimple; >> (2) the optimizers do a better good when you have "compute" partly >> because you >> provided them with additional aliasing information; this better optimized >> version then gets inlined into MAIN__. >> (3) this leaves the question of whether in the bad version it is >> logically >> possible for the optimizers to deduce the same aliasing information as is >> handed to them for free in the good version. To work this out it would be >> nice to have a smaller tes...

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

On Fri, 1 Sep 2006, Michael McCracken wrote: > Hi, I have a first quick patch and a question. The patch links f951 > with g++ when LLVM is enabled. It's at the end of this email. Thanks, applied! > I wanted to know if I should submit patches with comments around them > like the "APPLE LOCAL LLVM" ones that mark the LLVM-only changes to > the tree. I'd like to