gcc 4.1.1 MIPS problem

Kaz Kylheku kaz@zeugmasystems.com
Sat Dec 1 03:01:00 GMT 2007


Hi Everyone,

I don't have a lot of detailed information about this bug; it comes to me 
second hand. I don't have a minimal test case to reproduce it (I eventually 
will). But I was wondering whether anyone has seen anything like this.

The generated code for a C++ class member function saves the gp register on 
the stack. Smack in the middle,  it suddenly decides to restore the value of 
that register from the stack. After that, a shared library call fails (gp is 
used to hold the base addresses of global offset tables). The gp points to 
the wrong GOT.

Making some trivial perturbation in the source code makes the problem go 
away. The change is alon the lines of uncommenting a function call like 
this:

void Foo::Bar()
{
  /* ... */

  // uncomment the following, problem goes away.
  // int notused = memberPointer->inlineFunction();

  if (somecondition() || memberPointer->inlineFunction() != FOO) ...

Very strange.

Sorry to post crap like this with no useful information, but it was reported 
to me late Friday evening just before going home. :)

My question is, under what conditions would the compiler ever want to 
restore the caller's value for the global offset pointer and actually use 
it, rather than just restore it before returning to the caller?








More information about the Gcc-help mailing list