Intel C++ 13.1 bugs

Intel C++ 13.1 bugs

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);
}

25 帖子 / 0 全新
最新文章
如需更全面地了解编译器优化,请参阅优化注意事项

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.

>>Does it make any sense to combine const and volatile?

No in a real life and Yes to test a C/C++ compiler.

>>If not, the compiler should issue a diagnostic message, not die with these signals.

I wonder what C or C++ languages specs do say about the declaration const volatile int a = 0? Is it really allowed?

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 (;;);
}

1. If a variable is declared as a const it is a constant at any time. Isn't that true?

2. If the same variable is declared with another specificator volatile it means that its value can change at any time. Isn't that true?

3. What are we going to have if const and volatile are combined? These are two absolutely contradicting specificators and TimP already asked a very right question.

>>However const volatile pointers do have practical applications for embedded programming (e.g. to access a status register
>>that is updated by the hardware).

Thanks for explanarions.

>>...Here's another testcase, with const volatile pointers, that fails at -O2 and above as well...

Sorry, I asked a question:

What C or C++ languages specs do say about the declaration const volatile int a = 0? Is it really allowed?

Please, give us a reference that explains it. Thanks in advance.

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.

>>...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...

Thank you and I'll do some verifications with different C++ compilers, including Intel C++ compiler version 8.1.38.

Sorry for a small deviation from the subject of the thread... That's becoming very interesting and I wonder how Turbo C++ v1.01 will compile the test case? It is a 23-year-old technology:
...
Turbo C++ Version 1.01 Copyright (c) 1990 Borland International
...
and I regret that now I don't have TopSpeed, Zortech, Watcom and Microsoft Quick C C++ compilers for verification of your test case.

>>...That's becoming very interesting and I wonder how Turbo C++ v1.01 will compile the test case?..

This is simply to inform that Turbo C++ v1.01 successfully compiled a test case with const volatile int iVar = 0; declaration. At least I proved that this is a part of C89 Standard.

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

Quote:

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

www.quickthreadprogramming.com

The compiler in Update 3 still fails with the const volatile test case.  I've reported this issue to engineering team.  FYI.

Feilong

Feilong,

>>>>...Here's another testcase, with const volatile pointers, that fails at -O2 and above as well...
>>
>>...Update 3 still fails with the const volatile test case...

What test case did you use? I verified one of the test cases posted in the thread with three versions of Intel C++ compilers and I don't see any problems:

/*
[ Version 8.1 Build 20060606Z Update 38 ]

C:\WuTemp\Test>icl.exe /MD /O2 Main.cpp
Intel(R) C++ Compiler for 32-bit applications, Version 8.1 Build 20060606Z Package ID: w_cc_pc_8.1.038
Copyright (C) 1985-2006 Intel Corporation. All rights reserved.

Main.cpp
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

-out:Main.exe
Main.obj

[ Version 12.1.7.371 Build 20120928 Update 7 ]

..\Test>icl.exe /MD /O2 Main.cpp
Intel(R) C++ Compiler XE for applications running on IA-32, Version 12.1.7.371 Build 20120928
Copyright (C) 1985-2012 Intel Corporation. All rights reserved.

Main.cpp
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.

-out:Main.exe
Main.obj

[ Version 13.1.0.149 Build 20130118 Update 2 ]

..\Test>icl.exe /MD /O2 Main.cpp
Intel(R) C++ Compiler XE for applications running on IA-32, Version 13.1.0.149 Build 20130118
Copyright (C) 1985-2013 Intel Corporation. All rights reserved.

Main.cpp
Microsoft (R) Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.

-out:Main.exe
Main.obj
*/

[ Test case ]

int a, d, e;
int b;
int * const volatile c = &b;

void fn1( void )
{
int **f = 0;
int ***g = &f;
e = a ? 1 : 0;
//fn2( c, d = 0 != *g );
for( ;; )
;
}

int main( void )
{
fn1();
return 0;
}

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 signals

compilation 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 signals

compilation 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

Hi Feilong, Thanks and I'll do another verification with the test case you've used.

Windows platforms and versions of Intel C++ compiler are as follows:

- Windows 2000 and ICC v8 Update 38
- Windows XP and ICC v12 Update 7
- Windows 7 and ICC v13 Update 2

I'll post results as soon as tests completed.

By the way, I didn't verify 64-bit version of Intel C++ compiler ( v13 Update 2 ). In my previous set of tests I used only 32-bit versions of Intel C++ compiler (!).

Here is summary for both tests:

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// Note: Windows XP platform & 32-bit Intel C++ compiler version 12.x ( Update 7 )

[ Test 1.1 - Failed ]
[ Test 1.2 - Failed ]

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// Note: Windows 7 platform & 32-bit Intel C++ compiler version 13.x ( Update 2 )

[ Test 1.1 - Failed ]
[ Test 1.2 - Passed ]

// Note: Windows 7 platform & 64-bit Intel C++ compiler version 13.x ( Update 2 )

[ Test 2.1 - Failed ]
[ Test 2.2 - Failed ]

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Please take a look at attachments.

PS: Intel C++ compiler version 8.1.038 ( 32-bit ) successfully compiled both tests (!).

附件: 

附件尺寸
下载 main1.cpp138 字节
下载 main2.cpp225 字节
下载 iccv12logs.txt773 字节
下载 iccv13logs.txt1.6 KB

Composer XE 2013 Update 4 contains the fix for the internal error. You may download it at <https://registrationcenter.intel.com>. Please let me know if you still see it in Update 4.

Thank you.
Feilong

Open Watcom 1.9  can compile the test code, with success, at any optimization level  (/od  to /otexan )

Let me quote from "The C Book", second edition by Mike Banahan, Declan Brady and Mark Doran, originally published by Addison Wesley in 1991 :

: ...Let us get one thing straight: the concepts of const and volatile are completely independent. A common misconception is to imagine that somehow const is the opposite of volatile and vice versa. They are unrelated and you should remember the fact....

...

 Remember that they could also be further complicated by introducing storage class specifications as well! In fact, the truly spectacular

extern const volatile unsigned long int rt_clk;

is a strong possibility in some real-time operating system kernels.

>>Remember that they could also be further complicated by introducing storage class specifications as well!
>>In fact, the truly spectacular
>>
>>extern const volatile unsigned long int rt_clk;
>>
>>is a strong possibility in some real-time operating system kernels.

I challenged Turbo C compiler version 1.01 and this is a 23-year-old technology since its last release:

[ Test case ]

extern const volatile unsigned long int rt_clk;

void main( void )
{
}

[ Compilation output ]

C:\WorkLib\TC101\Bin>TCC.EXE Test.c
Turbo C++ Version 1.01 Copyright (c) 1990 Borland International
test.c:
Turbo Link Version 3.01 Copyright (c) 1987, 1990 Borland International

Available memory 392464

[ Conclusion ]

I even don't know what to say... :)

PS:

Question: Do you know what is a biggest problem of a modern software industry?
Answer: Unjustified overcomplexity of source codes.

发表评论

登录添加评论。还不是成员?立即加入