Compiler fails with access violation

Compiler fails with access violation

Hi everyone, just tried to build a project in VS13/ICC14 and here is the result

1>source.cpp(88): error : access violation
1>    vector<unaryFunction> unaryFunctions
1>                          ^
1>

Was just wondering what this could be. Oh, and the project builds just fine in MSVC and no I don't have locked files or readonly directories or anything like that.

19 posts / novo 0
Último post
Para obter mais informações sobre otimizações de compiladores, consulte Aviso sobre otimizações.

Repro case - this does not compile

#include <vector>
#include <functional>
using namespace std;

typedef function<int(int)> unaryFunction;
vector<unaryFunction> funcs{ [](int n) { return n/2; } };

int main()
{
  return 0;
}

imagem de iliyapolak

Can you post more details on access violation error?

There are no more details. It just fails on this particular code element. If there's some diagnostic mode in icl that can give more, let me know.

At any rate, this is happening on Windows, so you can try to repro it. It specifically fails on this C++11 construct (initializer list of functions).
 

>>... tried to build a project in VS13 / ICC14...

I don't think that many of us will be able to reproduce that problem. Personally, I don't have VS 2013 with integrated ICC vesion 14. Please wait for a response from Intel software engineers.

imagem de iliyapolak

>>> If there's some diagnostic mode in icl that can give more, let me know.>>>

I do not know any diagnostic modes in ICL.I thought that in case of access violation error some information will be collected by OS(minidump file).Actually you can set windbg to perform JIT postmortem debugging.But if the error is clasified as internal compiler error only Intel devs should be troubleshooting it.

Well, I've posted the issue here, so I hope the intel devs see it and do something about it.

>>...Actually you can set windbg to perform JIT postmortem debugging...

Unfortunately, it won't help to understand an exact reason of that interesting internal problem of Intel C++ compiler.

Yes I can reproduce the problem, and I've opened DPD200249985 to track the issue in our internal bugs database. Thanks for reporting the issue and the test case.

@Melanie Great! Will there be a hotfix or will one have to wait for the next service pack?

I can't answer schedule and release questions.  Incidentally, I tried your test case on Linux with gcc 481 compatibility, and it compiled fine.

imagem de iliyapolak

Postmortem debugging could help the developers to understand the origin of the exception or find the culprit of access violation.

imagem de iliyapolak

@dnestruk

What OS do you use?

>>...Will there be a hotfix or will one have to wait for the next service pack?..

Please take into account that it could take some time ( no any estimates (!) for when, etc ) before that problem is fixed. It means, that if your test case is based on some real production code than you will need to apply some workaround until an actual fix is released.

In case of a workaround this is how I usually isolate some issue specific to some release(s) of Intel C++ compiler:
...
#if __INTEL_COMPILER_BUILD_DATE == 20120731 // Intel C++ compiler v13.1.0
//...some functionality A...
#else
//...some functionality B...
#endif

#if __INTEL_COMPILER_BUILD_DATE == 20130118 // Intel C++ compiler v13.1.2
//...some functionality C...
#else
//...some functionality D...
#endif
...
and so on.

iliyapolak Wed, 11/20/2013 – 06:30
@dnestruk
What OS do you use?

Windows 8

In case of a workaround this is how I usually isolate some issue specific to some release(s) of Intel C++ compiler:

Issue is in 3rd-party code, ergo this approach will not work.

I’d expect this to be a hotfix considering this is a showstopper bug on an ordinary initializer list which works just fine in latest MSVC.

>>...I’d expect this to be a hotfix considering this is a showstopper bug on an ordinary initializer list which works just fine in latest MSVC...

Intel C++ compiler team uses a different approach, that is just a couple of major updates in a year ( I would do the same ). Compared to Intel VTune team which releases updates almost every month ( I talked with VTune guys about it ~2-3 months ago and I "complained" regarding too often updates ).

Bug fix for this problem will be shipped in a upcoming release of Compiler 14.0 .The natural of the problem is vector dtor is not getting selected and not generated during the lowering in Front-end.

 

Thank you.
--
QIAOMIN.Q
Intel Developer Support

User forums:                   http://software.intel.com/en-us/forums/

imagem de iliyapolak

@dnesteruk

do you have a dump file?

Faça login para deixar um comentário.