search for: c89

...be eliminated in future releases. Generally, I have found the SGI compilers very helpful in ferreting out portability problems, unused and/or obsolete variables, unexpected datatype coercions, etc., and they compile faster than any other compilers too. First, I configured like this: env CC='c89 -mips3 -O3' ./configure && make all This reports: R is now configured for mips-sgi-irix6.5 Source directory: . Installation directory: /usr/local C compiler: c89 -mips3 -O3 -OPT:IEEE_NaN_inf=ON -g C++ compiler: c++ -g -O2 FORT...

Quick results: [twang15 at c89 temp]$ clang -mllvm -help clang-5.0: error: no input files [twang15 at c89 temp]$ clang -mllvm -help-hidden clang-5.0: error: no input files [twang15 at c89 temp]$ clang -mllvm --help-hidden clang-5.0: error: no input files [twang15 at c89 temp]$ clang -mllvm --help clang-5.0: error: no input files...

...ren't aware of either) and strength '-disable-llvm-optzns' to do the same thing* Link: https://reviews.llvm.org/D28047 *-disable-llvm-optzns and -disable-llvm-passes are aliasing each other.* *1. Both can be passed to cc1 w/ -Xclang when compilation is run to finish.* E.g [twang15 at c89 temp]$ clang++ -O2 -Xclang -disable-llvm-optzns -save-temps LULESH.cc [twang15 at c89 temp]$ cp a.out a.out.1 [twang15 at c89 temp]$ clang++ -O2 -Xclang -disable-llvm-passes -save-temps LULESH.cc [twang15 at c89 temp]$ diff a.out a.out.1 [twang15 at c89 temp]$ *2. Both cannot be passed w/ -mllvm w...

clang -O3 -mllvm -help -c LULESH.cc succeeds. On Tue, Jan 9, 2018 at 2:05 AM, toddy wang <wenwangtoddy at gmail.com> wrote: > Quick results: > > [twang15 at c89 temp]$ clang -mllvm -help > clang-5.0: error: no input files > [twang15 at c89 temp]$ clang -mllvm -help-hidden > clang-5.0: error: no input files > [twang15 at c89 temp]$ clang -mllvm --help-hidden > clang-5.0: error: no input files > [twang15 at c89 temp]$ clang -mllvm --help &g...

...; '-disable-llvm-optzns' to do the same thing* > Link: https://reviews.llvm.org/D28047 > > *-disable-llvm-optzns and -disable-llvm-passes are aliasing each other.* > > *1. Both can be passed to cc1 w/ -Xclang when compilation is run to > finish.* > E.g > [twang15 at c89 temp]$ clang++ -O2 -Xclang -disable-llvm-optzns -save-temps > LULESH.cc > [twang15 at c89 temp]$ cp a.out a.out.1 > [twang15 at c89 temp]$ clang++ -O2 -Xclang -disable-llvm-passes -save-temps > LULESH.cc > [twang15 at c89 temp]$ diff a.out a.out.1 > [twang15 at c89 temp]$ > &gt...

...n # Fail On Tue, Jan 9, 2018 at 2:07 AM, toddy wang <wenwangtoddy at gmail.com> wrote: > clang -O3 -mllvm -help -c LULESH.cc succeeds. > > On Tue, Jan 9, 2018 at 2:05 AM, toddy wang <wenwangtoddy at gmail.com> wrote: > >> Quick results: >> >> [twang15 at c89 temp]$ clang -mllvm -help >> clang-5.0: error: no input files >> [twang15 at c89 temp]$ clang -mllvm -help-hidden >> clang-5.0: error: no input files >> [twang15 at c89 temp]$ clang -mllvm --help-hidden >> clang-5.0: error: no input files >> [twang15 at c89 temp]...

...-I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c getgroups.c -o getgroups.o getgroups.c: In function `main': getgroups.c:45: warning: unsigned int format, long unsigned int arg (arg 2) The SGI IRIX 6.5 C compiler, which is noted for its excellent diagnostics, had these additional comments: c89 -mips3 -O2 -I. -I. -g -DHAVE_CONFIG_H -I./popt -c options.c -o options.o cc-3303 c89: WARNING File = ./popt/popt.h, Line = 117 A type qualifier on a return type is meaningless. /*@observer@*/ const char *const poptStrerror(const int error); c89 -mips3 -O2 -I. -I. -g -DHAVE_CONFIG_H -I./po...

Hi folks, I have been stumped on a compilation problem when I tried to build 176.gcc of SPEC CPU2000 with clang v 2.8 (trunk 427) on Linux and intel. First, I tried to compile with 'clang -std=c89 *.c -o gcc.clang' since the default C standard of Clang is c99 while that of gcc is c89. It reported this error: ./c-gperf.h:14:1: error: unknown type name 'inline' inline ^ ./c-gperf.h:16:1: error: expected identifier or '(' static unsigned int ... This is the part of the so...

On 01/18/2011 06:38 PM, Bin Zeng wrote: > Hi folks, > > I have been stumped on a compilation problem when I tried to build > 176.gcc of SPEC CPU2000 with clang v 2.8 (trunk 427) on Linux and intel. > First, I tried to compile with 'clang -std=c89 *.c -o gcc.clang' since > the default C standard of Clang is c99 while that of gcc is c89. It > reported this error: > ./c-gperf.h:14:1: error: unknown type name 'inline' > inline > ^ > ./c-gperf.h:16:1: error: expected identifier or '(' > static unsigned in...

On IBM RS/6000 AIX 4.2, I built R-1.2.1 with % env CC=xlc CXX=xlC F77=f77 FC=f77 ./configure R is now configured for powerpc-ibm-aix4.2.1.0 Source directory: . Installation directory: /usr/local C compiler: c89 -g C++ compiler: xlC -g FORTRAN compiler: f77 -g X11 support: yes Gnome support: no Tcl/Tk support: yes R profiling support: yes R as a shared library: no However, the R-1.2.1 build fails in a number of places:...

...chmark, or any other) into a .bc file: specmake clean 2> make.clean.err | tee make.clean.out rm -rf bzip2 bzip2.exe *.o *.fppized.f* find . \( -name \*.o -o -name '*.fppized.f*' \) -print | xargs rm -rf rm -rf core specmake build 2> make.err | tee make.out clang -g -std=c89 -D_GNU_SOURCE -c -emit-llvm -c -o spec.o -DSPEC_CPU -DNDEBUG spec.c clang -g -std=c89 -D_GNU_SOURCE -c -emit-llvm -c -o blocksort.o -DSPEC_CPU -DNDEBUG blocksort.c clang -g -std=c89 -D_GNU_SOURCE -c -emit-llvm -c -o bzip2.o -DSPEC_CPU -DNDEBUG...

Hi, It was suggested that I post my question regarding a LLVM 3.4 performance regression to this mailing list, rather than stackoverflow. So here is the link: https://stackoverflow.com/questions/22902034/llvm-3-4-performance-regressed Thanks :) Jens -- Jens Tröger http://savage.light-speed.de/

...ed 1 exit status > clang: error: linker command failed with exit code 1 (use -v to see invocation) > I've recently been playing around with using Clang as the system compiler on a Gentoo system and found several packages that did something similar. The fix appears to be to add the -std=c89 option; from memory Clang defaults to c99 (while GCC defaults to c89) and there is a difference in the handling of inlining functions. One instance of this was also fixed by compiling Clang/LLVM from SVN, so if the c89 option doesn't fix it maybe give that a go (if you aren't already)....

My apologies to the list, as the last patch was not correct. It did no harm, but was to the trailing comma on the structure above the enum I was targeting. This patch is correct. Signed-off-by: Bruce Rogers brogers@novell.com - Bruce _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi, I've trouble compiling R-0.49 (with both patches applied) on a HP-UX sim B.10.20 A 9000/819 machine: ranlib ../lib/libappl.a cd regex; make c89 -Ae -g -I../include -DPOSIX_MISTAKE -c regcomp.c cc: warning 422: Unknown option "-Ae" ignored. cc: "../include/regex.h", line 50: error 1000: Unexpected symbol: "regoff_t". cc: "../include/regex.h", line 60: error 1000: Unexpected symbol: "regoff_t&quot...

When trying to link more than one object files compiled with clang, I run into errors of the following type: $ clang -fblocks -g -I$HOME/opt/include -L$HOME/opt/lib/ -o helloworld helloworld.c hello.o world.o -lBlocksRuntime world.o: In function `gnu_dev_major': /usr/include/sys/sysmacros.h:43: multiple definition of `gnu_dev_major' hello.o:/usr/include/sys/sysmacros.h:43: first defined

...lang¥include¥clang/Parse/Ownership.h(411) : see dec laration of 'clang::ASTOwningResult<Destroyer>::operator =' with [ Destroyer=::up▲ ] The problems comes with the following code: } else if (Tok.isNot(tok::r_square)) { // Note, in C89, this production uses the constant-expr production instead // of assignment-expr. The only difference is that assignment-expr allows // things like '=' and '*='. Sema rejects these in C89 mode because they // are not i-c-e's, so we don't need to distinguish...

...mpiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc -std=gnu99 accepts -g... yes checking for gcc -std=gnu99 option to accept ISO C89... none needed checking how to run the C preprocessor... gcc -std=gnu99 -E checking for gcc... (cached) gcc -std=gnu99 checking whether we are using the GNU C compiler... (cached) yes checking whether gcc -std=gnu99 accepts -g... (cached) yes checking for gcc -std=gnu99 option to accept ISO C89......

...gt;&2 ; } || { echo "$me: cannot create a temporary directory in $TMPDIR" >&2 ; exit 1 ; } ; dummy=$tmp/dummy ; tmpfiles="$dummy.c $dummy.o $dummy.rel $dummy" ; case $CC_FOR_BUILD,$HOST_CC,$CC in ,,) echo "int x;" > $dummy.c ; for c in cc gcc c89 c99 ; do if ($c -c -o $dummy.o $dummy.c) >/dev/null 2>&1 ; then CC_FOR_BUILD="$c"; break ; fi ; done ; if test x"$CC_FOR_BUILD" = x ; then CC_FOR_BUILD=no_compiler_found ; fi ;; ,,*) CC_FOR_BUILD=$CC ;; ,*,*) CC...

Below is some C code and its LLVM translation (using a recent rev). The compiler goes ahead and loads from x in main, but it seems clear that a constant propagation pass could have inferred that x is 0. In fact that is what happens if x is static, but in this case I cannot see how external linkage of x would invalidate that optimization. This is one of those optimizations that would not be