C++11 in-class initialization lead to crash

C++11 in-class initialization lead to crash

#include <stdio.h>
static struct {
    const char *s = "abcd";
} a;
int main() {
    printf("%s", a.s);
}

GCC works correctly on it, when exe produced by icc crashes.

ICC 13.1 on win.

There is too many fails with ICC and today none of my bugreports was fixed, it has awful support of C++11 features, also no information about next release of ICC, so i'm moving to GCC.

39 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.

I did a quick verification ( on WIndows XP with Intel C++ compiler version 12 ) and I could not compile the test case. Here is an output of Intel C++ compiler:

..>icl.exe /Qstd=c++0x /MD 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
Main.cpp(5): error: data member initializer is not allowed
const char *s = "abcd";
^

compilation aborted for Main.cpp (code 2)

What compiler options did you use?

I written in title that it's C++11, so it's need to specify /Qstd=c++11.

>>...I written in title that it's C++11, so it's need to specify /Qstd=c++11

/Qstd=c++11 and /Qstd=c++0x options do the same.

Aslo, I see that you've changed the version of the compiler to 13.1 from 12.1 and it is a good thing to inform everybody about so important update in the inital post.

I know.

At first it was mistake(i'm sorry), i uses 13.1 compiler from the day when it was released.

hi Sergey, hi Bert

i have the sample code compile on openSUSE 12.3 Linux,

with icc

linux-cuda:/ibm_supercomputing/testprg # icc -std=c++11 c_11.c                                                                                               
icc: command line warning #10370: option '-std=c++11' is not valid for C compilations                                                                          
c_11.c(3): error: expected a ";"                                                                                                                               
      const char *s = "abcd";                                                                                                                                  
                    ^
this error output, then i have compile with following statement:

icpc -std=c++0x c_11.c -o c11
and the result , no compile errors,

i use the 64 Bit Parallel Studio XE for Linux, Compiler Versions icc and icpc 13.1.0.20130121

best regards

Franz

>>...GCC works correctly on it, when exe produced by icc crashes...

Thank you for the report! This is simply to confirm that the problem is reproduced with Intel C++ compiler version 13.1.0.149 ( Update 2 ) on Windows 7 Professional and let's see a response from Intel software engineers.

Technical details are as follows:

// ..>icl.exe /MD /Qstd=c++11 Main.cpp - Problem ( Crash ) reproduced
// ..>icl.exe /MD /Qstd=c++0x Main.cpp - Problem ( Crash ) reproduced

#include "stdio.h"

static struct
{
const char *s = "abcd";
} a;

int main( void )
{
printf("%s", a.s);
}

/*
[ Compiler Output with /Qstd=c++11 ]

..>icl.exe /MD /Qstd=c++11 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 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.

-out:Main.exe
Main.obj

[ Compiler Output with /Qstd=c++0x ]

..>icl.exe /MD /Qstd=c++0x 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 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.

-out:Main.exe
Main.obj
*/

>>...then i have compile with following statement:
>>
>>icpc -std=c++0x c_11.c -o c11
>>and the result , no compile errors

It is good to know that with -std=c++0x option on a Linux there are no compilation problems. Did you try to execute the test case?

Hi Sergey,

yes i have execute the testcase result is a segmentation fault , now i check it with debugger

best regards

Franz

Bild des Benutzers Jennifer J. (Intel)

Thanks all. 

I'll file a bug report for it. I checked with update3 on Windows, it still crash. 

Jennifer 

Hi Jennifer,

>>... I checked with update3 on Windows, it still crash...

Did Intel release Update 3 for C++ compiler? Thanks.

Hi Bert,

>>...it has awful support of C++11 features, also no information about next release of ICC, so i'm moving to GCC...

Look, just ~12 hours ago you've reported the problem and Jennifer already filed a bug report. So, it should be fixed in some update of Intel C++ compiler. Please try to consider a workaround, of course if it is possible. Do you need help?

PS: One more thing, did you try to report any issues / problems with another big software companies, like Microsoft? I've done a few in the past and every time it looked like I'm a developer who created all these bugs and it is my job to fix them...

Hi Sergey, Hi Bert

now i have compile the testcase with gcc/g++ 4.7.2 and 4.8.0 under openSUSE 12.3 64 Bit Linux no problems till compile but

the executable produce the same segmentation fault as the ICC/ICPC , now my opinon, nothing is perfect ,every software has bugs

but i have excelllent expierence with the INTEL, IBM and NVIDIA Developer support for performnce critical application on linux i allways use my

INTEL Parallel Studio XE 2013, i like it, on the most cases its the right solution under Linux

best Regards

Franz

Hi Sergey,

now the g++/gcc executable produce the SIGSEGV on folllow:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff72893a4 in __GI__IO_default_xsputn (f=0x7fffffffd260, data=<optimized out>, n=4)
    at genops.c:476
476                     *p++ = *s++;

the ICPC exec the SIGSEGV at:

Program received signal SIGSEGV, Segmentation fault.
strchrnul () at ../sysdeps/x86_64/strchrnul.S:33
33              movdqa  (%rdi), %xmm0
i'm not a assembler specialist, but i diassemble or generate an assembler listing and inspect it

best Regards

Franz

Bild des Benutzers iliyapolak

>>>33              movdqa  (%rdi), %xmm0>>>

It looks like a rdi is containing a invalid source pointer.Can you inspect the memory content of rdi register?

Bild des Benutzers iliyapolak

It looks like rdi register is containing a invalid source pointer.Can you inspect the content of rdi register?

Hi iliyapolak,

the content of the rdi register:

value          Description

0x4006f9    4196089

best regards

Franz

Hi iliyapolak, hi sergey

in the strchrnu.S  was the SIGSEGV produce

the statement on line 476

      *p++ = *s++; is the reason

Bild des Benutzers iliyapolak

Can you look in memory window to what values is this address 0x4006f9 initialized.

Hi iliyapolak, hi sergey

now the rdi register or the char pointer *p++ contents '/x' or '/d' depents on this for loop counter

for( i = count; --i >= 0; )

    *p++ = *s++;       this is the code sequence that crashed with SIGSEGV

before the char *p stores  _IO_write_ptr which contains the value 4196089 dec or 0x4006f9

the loop counter i has the value /x

you have right the source pointer contains a invalid value

best reagrds

Franz

Bild des Benutzers iliyapolak

>>>you have right the source pointer contains a invalid value>>>

It always pays off to learning some debugging magic:)

Hi iliyapolak,

<<< It always pays off to learning some debugging magic:) >>>

yes, shure , but its great i love debugging its the great part of programming :-)

best regards

Franz

Bild des Benutzers iliyapolak

>>>yes, shure , but its great i love debugging its the great part of programming :-)>>>

Completely agree with you.What debugger do you use?Is this gdb?

Bild des Benutzers iliyapolak

>>>yes, shure , but its great i love debugging its the great part of programming :-)>>>

Completely agree with you.What debugger do you use?Is this gdb?

>>now the g++/gcc executable produce the SIGSEGV on folllow:
>>
>>Program received signal SIGSEGV, Segmentation fault.
>>0x00007ffff72893a4 in __GI__IO_default_xsputn (f=0x7fffffffd260, data=, n=4)
>> at genops.c:476
>>476 *p++ = *s++;
>>...

What test case did you use? Could you post it? Sorry, I'm a little bit confused about that new problem and please provide the test case.

Hi Sergey, Hi iliyapolak,

yes as debugger i use gdb or DDD, also the IDB for Parallel Studio XE 2013,

Sergey as testcase i use the sample from the begin from Bert Jonson

best regards

Franz

Bild des Benutzers iliyapolak

>>>yes as debugger i use gdb or DDD, also the IDB for Parallel Studio XE 2013,>>>

Have you ever had any experience with windbg?

Bild des Benutzers Jennifer J. (Intel)

An update to this issue. 

The next major release of icl (tested on Windows) works with this test.  The beta is not started yet. But if you're interested in our beta program, let me know. 

Jennifer 

>>...testcase i use the sample from the begin from Bert Jonson...

I see.

>>...The next major release of icl (tested on Windows) works with this test...

Do you mean Update 3 or Update 4? Please clarify. Thanks.

Hi iliyapolak,

>>> Have you ever had any experience with windbg? <<<

no, we only works with Linux ( openSUSE 12.3, and SUSE SLES 11 SP2 Server )

best regards

Franz

Bild des Benutzers iliyapolak

>>>no, we only works with Linux ( openSUSE 12.3, and SUSE SLES 11 SP2 Server )>>>

I sometimes envy you because you are working with open source OS and have access to source code.

Hi iliyapolak,

i have compile the sample with icpc 13.1 and with gcc-7.2,  now then i debug with gdb, i think its maybe possible a bug in icpc 13.1

see debug output icpc exec:

gdb) s
1310      outstring ((const UCHAR_T *) format,
(gdb) s
1314      if (*f == L_('\0'))
(gdb) s
1318      if (__builtin_expect (__printf_function_table != NULL
(gdb) s
264       void *args_malloced = NULL;
(gdb) s
261       int readonly_format = 0;
(gdb) s
1295      nspecs_done = 0;
(gdb) s
1287      grouping = (const char *) -1;
(gdb) s
227       const char *thousands_sep = NULL;
(gdb) s
1366          JUMP (*++f, step0_jumps);
(gdb) s
1363          workend = &work_buffer[sizeof (work_buffer) / sizeof (CHAR_T)];
(gdb) s
1362          workstart = NULL;
(gdb) s
1345          int alt = 0;      /* Alternate format.  */
(gdb) s
1346          int space = 0;    /* Use space prefix if no sign is needed.  */
(gdb) s
1347          int left = 0;     /* Left-justify output.  */
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7057434 in _IO_vfprintf_internal (s=<optimized out>, format=<optimized out>, ap=ap@entry=0x7fffffffd368)
    at vfprintf.c:1629
1629              process_string_arg (((struct printf_spec *) NULL));
(gdb)

and now the gcc-4.7.2 exec:

       int main() {
8           printf("%s", a.s);
9       }
(gdb) b 8
Breakpoint 1 at 0x400620: file c_11.c, line 8.
(gdb) r
Starting program: /ibm_supercomputing/testprg/c_11_g

Breakpoint 1, main () at c_11.c:9
9       }
(gdb) s
__printf (format=0x4006e9 "%s") at printf.c:29
29      {
(gdb) s
33        va_start (arg, format);
(gdb) s
29      {
(gdb) s
34        done = vfprintf (stdout, format, arg);
(gdb) s
33        va_start (arg, format);
(gdb) s
34        done = vfprintf (stdout, format, arg);
(gdb) s
_IO_vfprintf_internal (s=0x7ffff75b9160 <_IO_2_1_stdout_>, format=0x4006e9 "%s", ap=ap@entry=0x7fffffffd378)
    at vfprintf.c:257
257       int save_errno = errno;
(gdb) s
222     {
(gdb) s
257       int save_errno = errno;
(gdb) c
Continuing.
abcd[Inferior 1 (process 4766) exited normally]
(gdb)

what think you about ?

best regards

Franz

Bild des Benutzers iliyapolak

Hi Franz,

It is very hard to read the code because of awful formatting.

Bild des Benutzers iliyapolak

>>>0x00007ffff7057434 in _IO_vfprintf_internal (s=<optimized out>, format=<optimized out>, ap=ap@entry=0x7fffffffd368)
    at vfprintf.c:1629
1629              process_string_arg (((struct printf_spec *) NULL));>>>

It looks like the routine above at line of code#1629 caused segmentation fault.It seems like null pointer is passed (cast) as a parameter to function call process_string_arg()

Bild des Benutzers iliyapolak

My last response trigerred anti-spam filter.

I think that the function call at code line 1629 is responsible for segmentation fault.The parameter is null pointer which is cast to some struct type pointer.

Hi Franz,

The problem was already reported by Jennifer and there is nothing else we could do here because Intel software engineers have plenty of information about the problem. Honestly, I consider all these debugging excersises as unnecessary ( What are you looking for? ). Of course, you could do whatever you want but unless sources of Intel C++ compiler are fixed only a workaround could help.

Thanks for your time.

Best regards,
Sergey

Bild des Benutzers iliyapolak

Hi Franz,

Is GDB also kernel mode debugger with the similar capabilities as windbg?I mean kernel debugging over serial port, usb and firewire.

Hi, Jennifer.

I'm intrested in yours beta program and sent a message to you, but there is no answer.

Maybe it's forum mistake. One way or another, please, let me know.

Regards.

Bild des Benutzers Jennifer J. (Intel)

Update to this issue. It is fixed in the 13.x branch, and the fix should be available in the next update.

About the Beta, please read this posting and join the beta, and submit issues.

Thank you!
Jennifer

Melden Sie sich an, um einen Kommentar zu hinterlassen.