top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

GCC fails with -O2 for own Target

0 votes
335 views

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)
Anyway:
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;
}

void
hexdig_init ()
{
 htinit(hexdig, (unsigned char *) "**********", 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.

posted Jul 25, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

0 votes

It is most likely an error in your backend. The first step is to break out the debugger and find out why that function is being called with something that is not a MEM. You may want to look at http://gcc.gnu.org/wiki/DebuggingGCC

answer Jul 25, 2013 by anonymous
Similar Questions
+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.

+1 vote

I need to access in-memory representation of both the source program(the program before compilation) and target program(the program after compilation) at the same time. If I add a plugin between two passes,say p1 and p2, I will be able to access the program produced by only p1 but I would neither be able to access the program which was before executing p1 nor the program after p2. I want to compare the programs before and after compilation. How to do that?

+3 votes

I am following instructions from
https://gcc.gnu.org/wiki/Offloading

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 ?

0 votes

When I was building GCC, I found out that stage1-gcc is not compiled with optimization (such as -O2). So the compilation of stage2 is very slow. Is this intended or not? If not, did I made some mistakes in configure options and caused this?

+3 votes

I've been using the profiling tool valgrind for a while now. It requires an executable to run, i.e.

$ valgrind ./a.out

I want to use it on a dynamically linked GCC plugin, and list the time taken and the number of calls by each function used in the plugin. I am running the GCC plugin as follows:

 $ gcc -fplugin=./plugin.so myfile.c

When I run the following command, valgrind reports the memory leaks for only gcc and not for plugin.so. I need a way to run valgrind exclusively on my plugin, which is a .so file.

 $ valgrind gcc -fplugin=./plugin.so myfile.c
 $ gcc -fplugin=./plugin.so myfile.c -wrapper valgrind

Is it even possible to do that? I've searched up on this a lot but haven't found any concrete answer on it.

...