search for: fpreprocess

...orm} %(cc1_options) %{J*} %{I*}\ + f951 %|.f %{!ffree-form:-ffixed-form} %(cc1_options) \ + %<Wformat %<Wformat-security %<Wno-format-extra-args %<Wno-format- zero-length %<Wno-nonull \ + %{J*} %{I*}\ "/* LLVM LOCAL */" \ %(llvm_options) \ -fpreprocessed %{!nostdinc:-I finclude%s} %{!fsyntax-only:% (invoke_as)}}}}", 0, 0, 0}, @@ -25,21 +27,27 @@ "cc1 -E -lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN % (cpp_options) \ %{E|M|MM:%(cpp_debug_options)}\ %{!M:%{!MM:%{!E: -o %|.f95 |\n\ - f951 %|.f95 %{!ffixed-form...

Hello I am trying to run following test case on Clang compiled output to compare the dwarf inline attributes in the resulting assembly output . /* Inlined inline function must have abstract DIE */ /* { dg-do compile } */ /* { dg-options "-O2 -gdwarf-2 -dA -fpreprocessed" } */ /* { dg-final { scan-assembler "3.*DW_AT_inline" } } */ #1 "test.h" inline int t() { } int q() { t(); } The testcase fails because, DW_AT_inline is not present in assembly output. Could anyone let me know why DW_AT_inline is not emitted with Clang compiled assemb...

On Oct 30, 2008, at 5:23 PM, Jack Howarth wrote: > ps We do have one oddity left in llvm-gfortran from current llvm > svn. I find everytime I compile something with llvm-gfortran that > I get a series of warning messages... > > f951: warning: command line option "-Wformat" is valid for C/C++/ > ObjC/ObjC++ but not for Fortran > f951: warning: command line option

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 llvm::Type* llvm_set_type(tree_node*, const llvm::Type*): Assertion `(!(__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != (...

Chris and Bill, I have tested the proposed patch from... http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016490.html under i686-apple-darwin9 and it solves the problems building gfortran from llvm svn. The resulting compiler works fine so can we get that patch in before 2.4 is release? Jack ps We do have one oddity left in llvm-gfortran from current llvm svn. I find

> Thanks for the reply. I have not specified optimization level explicitly > during compilation. For GCC default is O0 ie., no optimization. Do you mean > that clang uses other optimization level other than O0 ? No, here it's still -O0. However it makes no sense to compare the size of unoptimized code. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics,

Hello I am trying to run following dejaGNU testcases on Clang compiled output. /* Inlined inline function must have abstract DIE */ /* { dg-do compile } */ /* { dg-options "-O2 -gdwarf-2 -dA -fpreprocessed" } */ /* { dg-final { scan-assembler "3.*DW_AT_inline" } } */ #1 "test.h" inline int t() { } int q() { t(); } The testcase fails because, DW_AT_inline is not present in assembly output. Could anyone let me know why DW_AT_inline is not emitted ? I am aware that Clang us...

...mechanism of sprintf, and split it into sprintf.c and sprintf_generic.c - removed extra % from sprintf''s precision error message (updated tests/sprintf) - comtc''s second pass now invokes tcc with the -n option, because some versions of CPP don''t allow -include with -fpreprocessed - toys/comtc mis-converted stdin location tags when using cpp 2.96 (reported by Martin A. Brown) - tcsim executed original rtnl_close, closing an undefined file descriptor, which sometimes upset flex, causing it to fail with "input in flex scanner failed" (reported by "bauer&...

...ter removing this line and compiling by hand everything goes further > (generated .s file attached). Maybe X86AsmWriter should be modified? Probably. Patches welcome :) > 2. While compiling gthr-win32.c I've got the following exception > stopped all compilation: > > ./cc1.exe -fpreprocessed h:\WINNT\Temp/ccAnbaaa.i -quiet -dumpbase gthr-win32.c > -auxbase-strip libgcc/./gthr-win32.o -g -O2 -W -Wall -Wwrite-strings -Wstrict-p > rototypes -Wmissing-prototypes -Wold-style-definition -version -o gthr-win32.s > GNU C version 4.0.1 LLVM (Apple Computer, Inc. build 5400) (mingw32)...

Hello Anton, Thanks for the reply. I have not specified optimization level explicitly during compilation. For GCC default is O0 ie., no optimization. Do you mean that clang uses other optimization level other than O0 ? Could you please clarify ? On Thu, Feb 16, 2012 at 6:52 PM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > Hello > > > The prologue length in

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

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 l...

Hi, Here is the follow on patch for this problem. Please apply this from the top of the tree and rebuild. -------------- next part -------------- A non-text attachment was scrubbed... Name: op Type: application/octet-stream Size: 2548 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060315/eee8a766/attachment.obj> -------------- next part

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 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fPIC -fvisibility=hidden -o libgcc2.s ..... Segmentation fault Please submit a full bug report, with prep...

...__CUDA_PREC_DIV=1 -D__CUDA_PREC_SQRT=1 "-I/opt/cuda-8.0/bin/..//include" -m64 "/tmp/tmpxft_00007040_00000000-4_cuda_id_test.cudafe1.cpp" > "/tmp/tmpxft_00007040_00000000-15_cuda_id_test.ii" #$ gcc -std=c++11 -c -x c++ "-I/opt/cuda-8.0/bin/..//include" -fpreprocessed -m64 -o "/tmp/tmpxft_00007040_00000000-16_cuda_id_test.o" "/tmp/tmpxft_00007040_00000000-15_cuda_id_test.ii" #$ nvlink --arch=sm_35 --register-link-binaries="/tmp/tmpxft_00007040_00000000-7_id_test_dlink.reg.c" -m64 "-L/opt/cuda-8.0/bin/..//lib64/stubs" &...

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

On Wed, 15 Mar 2006, Vladimir Prus wrote: >> Please give it a try and let me know if it works any better for you! > > Here we go: Wow, you are good at finding problems! Thanks! > -fvisibility=hidden -DHIDE_EXPORTS > -c ../../2006-03-14-llvm-gcc-4/gcc/libgcc2.c -o libgcc/./_fixunsxfdi.o > cc1: /space/p2/ghost/build/llvm-cvs/include/llvm/Instructions.h:72: void >

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/