Compilation fails after 15.0 update

[Dix_Lorenz]

After I updated to 15.0 on a very old MFC codebase on Windows I get a couple of these errors:

error : extra text after expected end of number

They are all in Message Maps for ON_NOTIFY_REFLECT or ON_NOTIFY_REFLECT_EX.

	ON_NOTIFY_REFLECT_EX(NM_KILLFOCUS, OnKillfocus)
	ON_NOTIFY_REFLECT_EX(NM_SETFOCUS, OnSetfocus)
	ON_NOTIFY_REFLECT_EX(LVN_BEGINLABELEDIT, OnBeginlabeledit)
	ON_NOTIFY_REFLECT_EX(LVN_ENDLABELEDIT, OnEndlabeledit)

or 

BEGIN_MESSAGE_MAP(CmM4_Footnotes_ExpandedTree, CmM4_TreeCtrl)
	//{{AFX_MSG_MAP(CmM4_Footnotes_ExpandedTree)
	ON_WM_CREATE()
	//}}AFX_MSG_MAP
	ON_NOTIFY_REFLECT_EX(LVN_INSERTITEM,OnUpdateTreeContents)
	ON_NOTIFY_REFLECT_EX(LVN_DELETEITEM,OnUpdateTreeContents)
	ON_NOTIFY_REFLECT_EX(LVN_DELETEALLITEMS,OnUpdateTreeContents)
END_MESSAGE_MAP()

All that is code that has been unchanged for ages, I have to assume there is some compiler bug at work; anybody can confirm that or maybe have a suggestion for a workaround?

[TimP]

I suppose you may need to make pre-processed file, compile that, and check the lines with the errors.  The compiler may have become pickier about "extra text."  You would need the pre-processed file anyway to file a report for investigation.

[Dix_Lorenz]

The preprocessed part comes down to: 

__pragma(warning( push )) __pragma(warning( disable : 4867 )) const AFX_MSGMAP* CmM4_ReportTreeControl::GetMessageMap() const { return GetThisMessageMap(); } const AFX_MSGMAP* __stdcall CmM4_ReportTreeControl::GetThisMessageMap() { typedef CmM4_ReportTreeControl ThisClass; typedef CmM4_TreeCtrl TheBaseClass; static const AFX_MSGMAP_ENTRY _messageEntries[] = {
	{ 0x004E+0xBC00, (WORD)(int)((0U-400U)-55), 0, 0, AfxSigNotify_b, (AFX_PMSG) (static_cast<BOOL (CCmdTarget::*)(NMHDR*, LRESULT*) > (OnItemExpanded)) },
{0, 0, 0, 0, AfxSig_end, (AFX_PMSG)0 } }; static const AFX_MSGMAP messageMap = { &TheBaseClass::GetThisMessageMap, &_messageEntries[0] }; return &messageMap; } __pragma(warning( pop ))

Since the error was something about extra text after a number I tried to compile

auto i = 0x004E+0xBC00;

and indeed the compiler really hates the "+" after "0x004E". Surprisingly (to me) that code snippet also doesn't compile on clang ("Invalid suffix '+0xBC00' on integer constant")...

After a bit of searching this is actually a valid complaint by the compiler and it's MS' overuse of macros that's to blame. Awesome :-(

It's still a problem with ICC for Windows, it needs to be able to compile this code for compatibility with VS 2012 (I don't know if later versions of VS changed the header).

[Amanda_S_Intel]

Can you attach the *.i file or some test case that is ready to compile so we can take a look? Can you tell me the last ICC version that is successfully compiled with?

[Dix_Lorenz]

I just created a brand new Win 32 Console Application in VS 2012, switched it to ICC 15.0, turned on C++11 (this is important), changed main to this: 

int _tmain(int argc, _TCHAR* argv[])
{
	auto i = 0x004E+0xBC00;

	return 0;
}

and I got the error.

The last one that worked for me I updated from from w_ccompxe_2013_sp1.4.237. 

[Jeff_Arnold]

Do these discussions shed any light on the issue?

• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3885
• https://gcc.gnu.org/ml/gcc/2014-09/msg00282.html

From the gcc bug report:

State-Changed-From-To: open->closed
State-Changed-Why: Strange as it may seem, the behavior is correct, and mandated by the C Standard.
0x00E-0x00A is a single preprocessor token, of type pp-number, and it must become a single compiler
token, but it can't.  The gotcha is the `E-' sequence, that makes it seem like the exponent notation
of floating-point constants.

This "bug" has been reported a number of times as you can see if you look at the history of gcc bug #44272.

[Dix_Lorenz]

I did find those links before and (once I found them) I absolutely agree, this is not a bug in the Intel Compiler per se. But it is a bug for a compiler that's supposed to be able to compile the MFC. This is "valid" MFC-Code:

BEGIN_MESSAGE_MAP(CmM4_ReportTreeControl, CmM4_TreeCtrl)
	ON_NOTIFY_REFLECT_EX(TVN_ITEMEXPANDED, OnItemExpanded)
END_MESSAGE_MAP()

Somewhere in the #define of ON_NOTIFY_REFLECT_EX this expression is used:

WM_NOTIFY+WM_REFLECT_BASE

WM_NOTIFY is #defined as 0x004E and WM_REFLECT_BASE is #defined as 0xBC00. Not my code, that is Microsofts code in afxmsg.h. Obviously there should be spaces around the "+", but Microsoft did not put them there so the Intel Compiler (rightly) fails. But no matter how correct ICC is, that makes it a defect for a Windows-Compiler that is supposed to be a drop-in replacement for the Visual C++-compiler. Blame Microsoft for bad code styles, a non-conforming compiler, overuse (even abuse) of macros but ICC for Windows has to be able to compile it.

[Dix_Lorenz]

Any updates on this? Is this a problem that Intel will resolve in the compiler?

[Bernard]

For me it looks like ICC classifies lack of space and interprets WM_NOTIFY macro as a floating point value(probably because of E hex value).So compiler cannot deduct type of variable i.

Did you try to put spaces in your test case?

[Dix_Lorenz]

I know it works if I put spaces in my test case. The problem is that the actual, real code is in afxmsg.h which I cannot change. It is Microsofts code and the Intel compiler needs to be able to compile it since it claims to be a drop-in replacement for the Visual Studio Compiler.

[Bernard]

Yes I know that, btw didn you try to compile the same header file with MSVC?

[Dix_Lorenz]

I am still on VS 2012 (some other bug in VS 2013 prevents me from upgrading there), that compiles it. ICC 14 also compiles it.

[Marián__VooDooMan__M]

Greetings,

IMO "

auto i = 0x004E+0xBC00;

" Could be mis-intrepreted as "4E0" or "4e+0" like floating-point, which is obviously an error, since it has "0x" prefix (hence it is hex syntax for int-typed number as default).

I had many issues with ICC 15.0.1 and 15.0.2 with floating point numbers, try to downgrade to ICC 15.0.0 (first release, no update number, it worked fine for me).

I you can't figure out where is the problem, you can catch the compiler bug into trap with using something like #pragma warning, at some points in the code, or even better preprocessed source file (*.i) for which you get compiler bug noticed.

best,

[Marián__VooDooMan__M]

Sorry, I obviously meant something like

...
#warning 1
...
#warning 2
...
#warning 3
...etc...

[Dix_Lorenz]

Again: I *KNOW* that the code is faulty. I *KNOW* that the Intel Compiler is actually correct to refuse the code. But official Microsoft Code will not compile with ICC 15 and that makes it unusable for me (or anybody else who uses ON_NOTIFY_REFLECT or ON_NOTIFY_REFLECT_EX). I *KNOW* how to fix the code, but dabbling in afxmsg.h is hardly a real solution. 

[Marián__VooDooMan__M]

I'm sorry, I have not read thoroughly the whole thread, since it is so large. And yes, ICC should process correctly even "crazy" code from MS, since it is kind of replacement for MS's one.

But the point was, when you generate preprocessed file, you can find where Intel Compiler has problem with MS code, and create reproducer easily and wait for Intel for to release new Update level.

Or have I missed something?

[Dix_Lorenz]

auto i = 0x004E+0xBC00;

*is* a reproducer and I *am* waiting for a release where this is fixed :-)

I am just wondering if Intel will actually fix this.

[Marián__VooDooMan__M]

Dix Lorenz wrote:

auto i = 0x004E+0xBC00;

*is* a reproducer and I *am* waiting for a release where this is fixed :-)

I am just wondering if Intel will actually fix this.

Yes, indeed it's strange to create bug and call it a "feature"... Even more, it might break bunch of other "non-crazy" code...

@Intel staff, hm?

I barely believe they'll do... :-\

[Marián__VooDooMan__M]

Ah, sorry, now I see you get error with ICC...

But the point of accepting malformed code to satisfy crazy MS code is still the challenge...

[Marián__VooDooMan__M]

AmandaS (Intel) wrote:

Can you attach the *.i file or some test case that is ready to compile so we can take a look? Can you tell me the last ICC version that is successfully compiled with?

IMO it would be best for @Intel staff if you could attach preprocessed *.i file, they will get the clue where they have broke MSVC compatibility, and they might file internal feature request, or even bug report to engineers/QA staff...

[Judith_W_Intel · Accepted solution]

Are you using the /Qstd=c++11 option?

I only see the problem when user defined literals are enabled (which only happens by default in MSVC++ 2015 compatibility mode).

If so you can disable them with the /Qoption,cpp,--no_user_defined_literals option.

!% icl -c /Qoption,cpp,--user_defined_literals t.cpp
Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Ve
rsion 15.0 Beta Build x
Built Jan 19 2015 12:59:50 by jward4 on JWARD4-DESK1 in D:/workspaces/15_0cfe/de
v
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

t.cpp
t.cpp(2): error: extra text after expected end of number
  int i = 0x004E+0xBC00;
                ^

compilation aborted for t.cpp (code 2)
!% icl -c /Qoption,cpp,--no_user_defined_literals t.cpp
Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Ve
rsion 15.0 Beta Build x
Built Jan 19 2015 12:59:50 by jward4 on JWARD4-DESK1 in D:/workspaces/15_0cfe/de
v
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

t.cpp
!% icl -c t.cpp
Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Ve
rsion 15.0 Beta Build x
Built Jan 19 2015 12:59:50 by jward4 on JWARD4-DESK1 in D:/workspaces/15_0cfe/de
v
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

t.cpp
!%

Judy