Annoying error in pure C

[Andy_B_]

Hi,

The following code doesn't compile

keos.c

#include <stdio.h>

int main(void) {
 int dummy[] = {1, 2, 3, 4, 5};
 return 0;
}

The error I get makes no sense.

>icl keos.c

Intel(R) C++ Compiler XE for applications running on IA-32, Version 14.0.0.103 B
uild 20130728
Copyright (C) 1985-2013 Intel Corporation.  All rights reserved.

keos.c
keos.c(4): internal error: assertion failed at: "shared/cfe/edgcpfe/overload.c",
 line 21996

        int dummy[] = {1, 2, 3, 4, 5};
                                     ^

compilation aborted for keos.c (code 4)

Using VS 2013 with Composer XE 2013 SP1

[Andy_B_]

Oh I'd like to add. Changing the file extension keos.c --> keos.cpp fixes the problem. Problem is... I don't code in CPP for this project. Also, just a *side question* : is ICL compliant with C11/C1X. Thanks

[TimP]

An internal error would be a reportable problem, regardless of correctness of source code.  I don't see any such problem on my copy of the next update of the compiler.

I don't see anything about C11 in the release nodes .pdf.  Evidently, some of the features are available under non-standard names, not necessarily with easily accessible documentation.

Were you interested in http://software.intel.com/en-us/forums/topic/495022 ?

[Andy_B_]

The C11 std question was just a curiosity. The reason is I Wonder if Intel makes idiotic/dumb/stupid choices like Microsoft not to support C standards past C89. Personally, I'm interested in both languages, I work with both of them frequently, and I definitely can say *both* are important to maintain. This is a personal opinion of course, but I dislikes companies being one sided over a language, and I wondered if Intel plans to do the same!

Anyways... I don't get it exactly. Currectly I have the SP1 installed, 2013. We told me it was the latest, isn't it? Which version do you have...?

Thanks!

[TimP]

$ icl -V
Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Ve
rsion 14.0.1.139 Build 20131008

The initial 14.0.0 version is not one for which I personally would recommend continued use.

Microsoft is alone among maintained C compilers in declining to support recent standards.  There was a rumor that Microsoft might adopt C99 features which are already implemented in C++, but that seems to have been false.  Microsoft has documented the __restrict extension for years without implementing it.  A very few C99 features came in, such as long long int and <stdint.h> (after many customers implemented it themselves); as a result of Microsoft practice we have the unfortunate situation where long int is a 64-bit data type on linux in 64-bit mode, but not on Windows.

As a recent retiree with no ability to speak for Intel, according to my observation, past practice has been to accept feature requests or bug reports about current standard features which are supported by gcc and don't work in ICL. You may have noticed after some waiting that ICL did a fair job in the last 13.1 release and in 14.0.1 of catching up to gcc-4.7 as far as std C, C++, and OpenMP 3.1 are concerned, once it became established that "supported" linux distros (so far, not Red Hat or CentOS) would supply this level of gcc.  Quotation of compatibility of the linux icc with a given distro should raise the priority of compatibility with the gcc of that distro.  It's reasonably clear from past history that released versions of gcc (currently 4.8.2) will soon become important for compatibility.  On the other side, Intel is encouraging gcc 4.9 development, so there seems a good case to strive for future compatibility.

There is the added difficulty in some cases of reconciling with the underlying Microsoft CL implementation.  Sometimes, the gcc compatibility is implemented only on the linux side; then you have the possibility of filing a feature request to ask if it is feasible to carry over to Windows. I guess there is an attitude that compatibility is important only for dealing with software vendors who are supporting both linux or Mac and Windows.

I personally maintain some benchmarks which test several compilers in several programming languages, testing CL only in rudimentary C++, but testing Intel C and gcc both on Windows and linux.  I have quite a mess of ifdefs.  As I am compiling under OpenMP, I test whether OpenMP 3.1 support is claimed, as a way of dropping back to compatibility with Microsoft and Red Hat.

[SergeyKostrov]

Guys, I simply would like to inform you that almost 20-year old Borland C++ compiler 5.5.1 successfully compiled the test case! ... C:\WuTemp\Tests>bcc32 Test.cpp Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland Test.cpp: Warning W8004 Test.cpp 6: 'dummy' is assigned a value that is never used in function main() Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland ...

[bernaske]

Hi Andy B,

i have your keos sample source compile with the parallel studio xe 2013 sp1 for linux (64 Bit)

with the compiler version

icc (ICC) 14.0.1 20131008
Copyright (C) 1985-2013 Intel Corporation.  All rights reserved.

under openSUSE 12.3 , 13.1 and the openSUSE Factory Build ( future 13.2 ) all x86_64 versions and have now

problems to compile and execute

regards

Franz

[Andy_B_]

Thanks Tim for the precise answer.

Seems like SP1 Update 1 fixed my problem, at least on Windows. On Windows that is. I don't have a linux version, but Franz aroused my curiosity. Does the code compiles well on linux? ^_^

Oh @Tim. If you are still around. I would have another off-topic question. I wonder why, on Win, Intel dépends that much on Visual Studio, such a bloated product! Why not making your own IDE? Softwares like Inspector and Advisor, with very nice GUI interfaces, shows me Intel would be more than capable to do so. Just a thought! Is it because of header files/includes? If so, why not just depending on VS redistributable and still making your own IDE, or better, doing like PGI i.e. bundling them with the compiler installer, and putting a copyright notice there.

Thanks

[TimP]

I suppose PGI must pass a portion of their fee on to Microsoft, as Intel does with the Visual Fortran product, so as to include Microsoft components under license.  Intel has been successful with that Fortran product, partly on account of a big head start from its predecessors.  PGI and Intel negotiated with Microsoft for several years to reach the agreement for the current products.  Microsoft still has strong control of the commercial compiler market for Windows.

It will be interesting to see whether Lahey can make a success offering gnu compilers as a commercial product with a Windows IDE.  They appear to see more opportunity for Fortran than for C++, where Code::Blocks and others have more adherents.

The market for commercial C++ has always been limited and presumably unprofitable.  If the subject were interesting enough to research and discuss, someone could try to analyze the goals of Intel's software tools strategy (including entire platform promotion) and whether the strategy appears optimum.

[bernaske]

Hi Andy,

yes i have the keos.c compiled under linux as well, no problems.

i have it compile on three different linux releases openSUSE 12, 13.1 and the Factory ( next Version Number maybe 13.2 )

all 64 bit, as compiler i use the Intel Parallel Studio XE SP1 for Linux, no troubles on compile and execute the keos.c, i don't use

Windows :-)

happy new year Andy

regards

Franz

[JenniferJ]

Please download the update 1 of 14.0, it compiles ok.

C:\temp>icl /c /Od c_err.c
Intel(R) C++ Compiler XE for applications running on IA-32, Version 14.0.1.139 Build 20131008
Copyright (C) 1985-2013 Intel Corporation.  All rights reserved.

c_err.c

C:\temp>type c_err.c
#include <stdio.h>

int main(void) {
  int dummy[] = {1, 2, 3, 4, 5};
  return 0;
 }

C:\temp>