This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gcc 4.1.1 MIPS problem


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?







Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]