Compiling code without inline assembly gives an error: libtool: compile: gcc -std=gnu99 -DPACKAGE_NAME=\"libblkmaker\" -DPACKAGE_TARNAME=\"libblkmaker\" -DPACKAGE_VERSION=\"0.1\" "-DPACKAGE_STRING=\"libblkmaker 0.1\"" -DPACKAGE_BUGREPORT=\"luke_libblkmaker@dashjr.org\" -DPACKAGE_URL=\"http://gitorious.org/bitcoin/libblkmaker\" -DPACKAGE=\"libblkmaker\" -DVERSION=\"0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I. -O3 -O3 -MT blkmaker.lo -MD -MP -MF .deps/blkmaker.Tpo -c blkmaker.c -fPIC -DPIC -o .libs/blkmaker.o /tmp/ccot8mMw.s: Assembler messages: /tmp/ccot8mMw.s:529: Error: expecting string instruction after `rep' However, disabling inline assembly "-fno-asm" only fixes the problem when "-O3" is not used. The error always occurs when not specifying "-fno-asm".
Can you attach the preprocessed source?
Created attachment 29907 [details] the preprocessed C source file
(In reply to comment #2) > Created attachment 29907 [details] > the preprocessed C source file This cannot be the preprocessed source as it still includes #include in it.
Created attachment 29925 [details] the REAL preprocessed source file sorry, I uploaded the wrong file; this is the preprocessed source file
What binutils version are you using? You can find out by doing "as --version". I think this is a bug in the version of binutils you are using the generated assembly is: " rep; ret " which is a valid assembly for x86_64.
Can't reproduce, perhaps misconfigured compiler? HAVE_AS_IX86_REP_LOCK_PREFIX test in particular. You haven't said what target it is and how you've configured the compiler...
(In reply to comment #5) > What binutils version are you using? You can find out by doing "as --version". > > I think this is a bug in the version of binutils you are using the generated > assembly is: > " rep; ret " which is a valid assembly for x86_64. GNU assembler (Linux/GNU Binutils) 2.22.52.0.2.20120424 (In reply to comment #6) > Can't reproduce, perhaps misconfigured compiler? > HAVE_AS_IX86_REP_LOCK_PREFIX test in particular. You haven't said what target > it is and how you've configured the compiler... ../gcc-4.8.0/configure --prefix=/usr --libdir=/usr/lib64 --mandir=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap --enable-languages=ada,c,c++,fortran,go,java,lto,objc --enable-threads=posix --enable-checking=release --enable-objc-gc --with-system-zlib --with-python-dir=/lib64/python2.7/site-packages --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --enable-lto --with-gnu-ld --verbose --enable-java-home --with-java-home=/usr/lib64/jvm/jre --with-jvm-root-dir=/usr/lib64/jvm --with-jvm-jar-dir=/usr/lib64/jvm/jvm-exports --with-arch-directory=amd64 --with-antlr-jar=/home/slackware/slackbuilds/gcc/antlr-runtime-3.4.jar --enable-multilib --target=x86_64-slackware-linux --build=x86_64-slackware-linux --host=x86_64-slackware-linux
I upgraded to binutils 2.23.52.0.1 and the problem went away.
Not a bug in gcc then.