Testcase crashes at -O1 and above on current Intel C++ 13.1. Perhaps array/pointer related?
$ uname -mo
x86_64 GNU/Linux
$ icc -v
icc version 13.1.0 (gcc version 4.6.0 compatibility)
$ icc -O0 -c array.c
$ icc -O1 -c array.c
": internal error: backend signals
compilation aborted for array.c (code 4)
$ cat array.c
static int *
fn1 (int *p1)
{
return p1;
}
void fn2 ()
{
int a[1];
int *b = &a[0];
fn1 (b);
}
Link Copied
Hi Dara,
I've reproduced this issue and entered it to our problem-tracking database. Will let you know when I have an update regarding it.
Thank you.
--
Feilong H.
Intel Developer Support
Tools Knowledge Base: http://software.intel.com/en-us/articles/tools
Thanks Feilong!
Here's a different testcase that crashes at -O2 or higher. Same environment as above. Seemingly related to the combination of const and volatile.
$ icc -O1 -c volatile.c
$ icc -O2 -c volatile.c
": internal error: backend signals
compilation aborted for volatile.c (code 4)
$ cat volatile.c
void fn2(int, int);
const volatile int a = 0;
int b;
void fn1 ()
{
fn2 (b-- && 0, a);
}
Does it make any sense to combine const and volatile? If not, the compiler should issue a diagnostic message, not die with these signals.
As written, it probably doesn't get much use. However const volatile pointers do have practical applications for embedded programming (e.g. to access a status register that is updated by the hardware). As to whether it's legal, both gcc and clang do accept it, without warning.
Here's another testcase, with const volatile pointers, that fails at -O2 and above as well:
int a, d, e;
int b;
int * const volatile c = &b;
void fn1 ()
{
int **f = 0;
int ***g = &f;
e = a ? : 0;
fn2 (c, d = 0 != *g);
for (;;);
}
C89 and C99 both allow you to combine the two qualifiers. I don't see any references restricting assignments in such cases, so I believe it is allowed. I see more than one C reference book include code samples of that form. Note that without the assignment, both snippets compile successfully.
Engineering team has implemented a fix for this internal error. I'll let you know when a compiler update that contains the fix is available for download.
Feilong
Hi,
Composer XE 2013 Update 3 contains a fix for this issue. It has been posted to Intel Registration Center. You may download it and give a try. Please do let me know in case that the problem still persists.
Feilong
Sergey Kostrov wrote:
1. If a variable is declared as a const it is a constant at any time. Isn't that true?
I think const means that the value cannot be changed with this access. It can change in other ways.
const requires the compiler to flag any visible point of modification in the compilation unit. Thus, the strength could vary with in-lining options. I have seen disagreements about extending its meaning beyond that.
>>const requires the compiler to flag any visible point of modification in the compilation unit.
Right, and volatile means value may be altered outside the compilation unit at any time.
A handy way to write protect a variable in the scope of a compilation unit while permitting changes from outside the compilation unit. In the case of an I/O register you may have no way of inhibiting modification and/or time of modification.
Jim Dempsey
The compiler in Update 3 still fails with the const volatile test case. I've reported this issue to engineering team. FYI.
Feilong
Hi Sergey,
I was using the test cases that Dara provided on 02/04/2013. Here is what I saw on Linux.
$ cat volatile.c
void fn2(int, int);
const volatile int a = 0;
int b;
void fn1 ()
{
fn2 (b-- && 0, a);
}
$ icc -O2 -c volatile.c
": internal error: backend signalscompilation aborted for volatile.c (code 4)
$
$ cat test2.c
int a, d, e;
int b;
int * const volatile c = &b;
void fn1 ()
{
int **f = 0;
int ***g = &f;
e = a ? : 0;
fn2 (c, d = 0 != *g);
for (;;);
}
$ icc -O2 -c test2.c
": internal error: backend signalscompilation aborted for test2.c (code 4)
$ icc -V
Intel(R) C Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.1.1.163 Build 20130313
Copyright (C) 1985-2013 Intel Corporation. All rights reserved.$
Feilong
For more complete information about compiler optimizations, see our Optimization Notice.