"debugging information corrupt" while trying OpenMP delegation on Intel

"debugging information corrupt" while trying OpenMP delegation on Intel

Hi all,

I have found out a bug in Intel compiler.

Background: We are trying to delegate OpenMP calls (so even in hybrid projects with Intel and Microsoft compiler used, we ensure only one OpenMP stack is loaded).

Compiler used: Intel(R) C++ Compiler XE 14.0.1.139 [IA-32], Multifile IPO, Optimize on, Generate PDB (it works in 64 or Single IPO or Optimize off or without PDB).
Out code works perfectly and as expected when one of the previous setting is changed (unfortunatelly we need them to work)...

It seems to occur with the "#pragma omp for" call only (#pragma omp parallel for does not crash).
Note that this example is made only for the purpose or reproducing the bug, so it's not suppose to do anything consistent (in our case the omp parallel call will also be "delegated" and the threading class would be instantiated in a different dynamic library).

The error while linking is (in verbose mode)

Starting pass 2
     ipo_20792obj3.obj
ipo_20792obj3.obj : fatal error LNK1103: debugging information corrupt; recompile module

Note with slight variations of the example I get:
fatal error LNK1318: Unexpected PDB error; RPC (23) '(0x000006BA)

Best regards,

PS: The code to reproduce the bug

#include <stdio.h>

void foo_bar(int i)
{
    printf("Processing task %d\n", i);
}

typedef void (* callback)(int);

struct ithreading
{
    virtual void For(callback fn) = 0;
};

class threading : public ithreading
{
public:
    inline void For(callback fn)
    {
#pragma omp for
        for (int i = 0; i < 50; i++)
            fn(i);
    }
};

int main(int argc, char ** argv)
{
    ithreading * t = new threading;

    //threading::omp_for(&foo_instance, &foo::bar);
#pragma omp parallel
    t->For(&foo_bar);

    delete t;
}

 

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I would like to add the fact that the crash does not occur when For is not a virtual function (probably because it's inlined).
Formatted code (without the useless inline):

#include <stdio.h>

void foo_bar(int i)
{
    printf("Processing task %d\n", i);
}

typedef void (* callback)(int);

struct ithreading
{
    virtual void For(callback fn) = 0;
};

class threading : public ithreading
{
public:
    void For(callback fn) 
    {
#pragma omp for
        for (int i = 0; i < 50; i++)
            fn(i);
    }
};

int main(int argc, char ** argv)
{
    ithreading * t = new threading;

    //threading::omp_for(&foo_instance, &foo::bar);
#pragma omp parallel
    t->For(&foo_bar);

    delete t;
}

 

A shorter example (crash if and only if threading::For is not inlined)
LINK : fatal error LNK1318: Unexpected PDB error; RPC (23) '(0x000006BA)'

I have also reproduced it with /O0 instead of /O2 (but still /Qipo)

Note that it successfully links 1 time out of 10...

class threading
{
public:
    __declspec(noinline) void For() 
    {
#pragma omp for
        for (int i = 0; i < 50; i++);
    }
};

int main(int argc, char ** argv)
{
#pragma omp parallel
    threading().For();
}

 

Georg Zitzlsberger (Intel)'s picture

Hello,

thank you for reporting! I was able to reproduce the same problem on my system and created a ticket for engineering: DPD200515746.
Once this is fixed, I'll update this thread.

Unfortunately, I cannot offer you any workaround other than you already mentioned. It might be possible, though, to disable /Zi when you build with IPO and vice versa.

Best regards,

Georg Zitzlsberger

Here is the workaround, that add some overhead ... again, the auxiliary function must not be inlined, so either a noinline directive, or pragma optimize off around it.

__declspec(noinline) void For2(threading * This)
{
#pragma omp for
        for (int i = 0; i < 50; i++);
}

class threading
{
public:
    __declspec(noinline) void For() 
    {
        For2(this);
    }
};

int main(int argc, char ** argv)
{
#pragma omp parallel
    threading().For();
}

 

Georg Zitzlsberger (Intel)'s picture

Hello,

This problem will be fixed with Intel(R) Composer XE 2015 Update 1 and Intel(R) Composer XE 2013 SP1 Update 4.

Best regards,

Georg Zitzlsberger

Login to leave a comment.