This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CGT6.1.19: using –o2 and –o3 compiler does not generate constructor calls (struct is not initialized correctly)

Hi,

 

One of my customer is reporting  following problem with CGT v 6.1.19 and C67xx.

[Problem:

we got problems with the initialization of a structure using symbols generated in the linker command file.
I think it is a bug in the code generation tools v6.1.19 for C67xx.

I've stripped down the code to a small testcase, which is attached (files testcase.cpp and testcase.cmd (.txt)).

Here a short description:
We use symbols generated in the linker cmd file using the special symbol '.'.
These symbols are used as an initial value for a class/struct with a constructor.
In our case we want the difference of two adresses the linker generates.

When using optimization -o2 or -o3, the compiler generates .cinit entries instead of the constructor call.
In those .init-entries it doesn't use the difference of the adresses, instead it uses the first symbol:

----- snip (from testcase.cpp) -----
// symbols from the linker
extern char _start_isr_stack[];
extern char _end_isr_stack[];
...
struct Info
{
   unsigned mSize;
   Info(unsigned size) : mSize(size) {}
};
...
Info Info2((unsigned)_end_isr_stack - (unsigned)_start_isr_stack);
----- snip -----


That's what is generated:

----- snip (from generated .asm file) -----
   .sect   ".cinit"
   .align   8
   .field     $C$IR_2,32
   .field     _Info2+0,32
   .field     __end_isr_stack,32      ; _Info2._mSize @ 0
----- snip -----

The last line should be something like:
    .field   __end_isr_stack-__start_isr_stack,32


When turning off optimization, the constructor calls are generated and the struct is initialized correctly.]

 

Is this a bug? Any comments would be appreciated?

 

Regards,

Majda

testcase.cpp
  • Missing cmd file is attached as well

  • Majda,

    I can reproduce this and it does look like a bug. I submitted this as bug# SDSCM00040934, which you can track using the SDOWP link in my signature.