top button
Flag Notify
    Connect to us
      Facebook Login
      Site Registration Why to Join

Facebook Login
Site Registration
Print Preview

gcc svn build fails due to -Werror

+1 vote

In attempts to build the gomp_4.0 branch from svn (on CentOS 6.2), I find that I must remove the -Werror option in STRICT_WARN. I don't find documented how this should be done (in configure ?). I can get past it by repeatedly modifying gcc/Makefile, but this seems wrong.
I have little interest at this stage in finding out why it triggers -Werror=maybe-uninitialized in typeck.c; I'd only like to build the gcc to see if it does anything interesting with OpenMP 4.

posted Aug 31, 2013 by Bob Wise

Share this question
Facebook Share Button Twitter Share Button Google+ Share Button LinkedIn Share Button Multiple Social Share Button

1 Answer

+1 vote

Try passing --disable-werror when you run configure.

answer Aug 31, 2013 by anonymous
Similar Questions
+2 votes

While merging branch back to trunk I constantly get the error in the subject. Note that x/y/z has svn:mergeinfo property. The property was not added on the branch, but it was already there when the branch was created. Subsequently x/y/z is deleted on branch.

The error is generated when running: "svn merge ^/branches/mybranch" on a trunk working copy.

Sounds to me like a bug, svn tries to update the mergeinfo on the deleted path. Is that so ?

+1 vote

We have a custom tunnel protocol with repository URLs of the form:


After upgrading from svn 1.7.x to 1.8.1, these URLs are considered invalid, giving an error of:

svn: E170000: Illegal repository URL

This occurs on an 'svn up' or an 'svn checkout'. Changing the tunnel protocol name to 'foobar' (i.e. drop the underscore) appears to work properly, both 'svn up' and 'svn checkout' work fine.

0 votes

I have ported the GCC (v4.5.3) to a new target (32-bit RISC processor). So far everything went fine. I wrote my own little C-Lib with basic input output and tested it worked. Until today I never actually tried optimization passes (maybe that was the mistake that lead to this)
During porting and building Newlib I ran into an error that I tracked down to the following code:

unsigned char hexdig[256];

static void htinit ( unsigned char *h , unsigned char *s , int inc)
 int i, j;
 for(i = 0; (j = s[i]) !=0; i++)
 h[j] = i + inc;

hexdig_init ()
 htinit(hexdig, (unsigned char *) "0123456789", 0x10);
 htinit(hexdig, (unsigned char *) "abcdef", 0x10 + 10);
 htinit(hexdig, (unsigned char *) "ABCDEF", 0x10 + 10);

Compiling this code without optimization works like a charm, however compiling it with -O2 leads to the following error:
test1.c: In function 'hexdig_init':
test1.c:11:1: internal compiler error: in gen_lowpart_general, at rtlhooks.c:59

Tried with:
eco32-gcc -O2 -S test1.c

My question in short is:
Could this be a targe- backend-error or just some configuration I have missed while building GCC?
Any pointers into the right direction are welcome.

+3 votes

I am following instructions from

I'm using the configure line for Nvidia ptx. The build stops in configuring nvptx-none/libgfortran with error:

checking whether symbol versioning is supported... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.

My host OS is CentOS 6.5. I'm using gcc 4.7 (built with system gcc 4.4) to build gcc 5.1

Can someone give me hint to look where the problem could come from ?

+2 votes

I am building gcc 4.8.1 in a Red Hat 6.4 64 bit machine. I am building gnat first and it is build as 32 bit i686 architecture. I used gnat-gpl-2013-i686-pc-linux-gnu-bin for gnat and it created a 32 bit gcc in the directory, I set the path to that so, gcc is now gcc 4.7.4 from /gnat/bin/gcc. When I checked that is 32 bit gcc.

I used this configuration

./gcc-4.8.1/configure --disable-multilib --disable-bootstrap
--disable-install-libiberty --with-system-zlib --enable-clocale=gnu
--enable-shared --enable-lto --enable-threads=posix --enable-__cxa_atexit
--enable-languages=c,c++,fortran,java,ada --prefix=/usr/local/ CFLAGS="-pipe
-march=native -mtune=native -g -O2" CXXFLAGS="-pipe -march=native
-mtune=native -g -O2"

I was able to build the compiler with this configuration and arch is x86_64.

when I tried to compile a file with -m32 option it didn't work and got the error message

crtbegin.o: could not read symbols: File in wrong format.
Collect2: kd returned 1 exit status

Useful Links with Similar Problem
Contact Us
+91 9880187415
#470/147, 3rd Floor, 5th Main,
HSR Layout Sector 7,
Bangalore - 560102,
Karnataka INDIA.