Compiler/ARM-CGT: Information about known issues with ARM compiler

1138

Part Number: ARM-CGT

Tool/software: TI C/C++ Compiler

We would like more information about the following known issues with TI's ARM Optimizing C/C++ Compiler v18.1.4.LTS.

FYI, we are using the following arguments with the compiler:

"C:/ti/ccsv8/tools/compiler/ti-cgt-arm_18.1.4.LTS/bin/armcl" -mv7R5 --code_state=32 --float_support=VFPv3D16 --define=_TMS570LC43x_ -g --c99 --diag_warning=225 --diag_wrap=off --display_error_number --enum_type=packed --abi=eabi --asm_listing --preproc_with_compile". (Plus several --include_paths, --defines, and a --preproc_dependency.)

(Note that we have specified an optimization level of "off" in CCS, which I believe it is honoring by specifying the -g argument without specifying an --opt_level argument.)

CODEGEN-4304 "runtime failure on unaligned access (on some processor variants, not all)":

I see that this has a test case attached to it, but no further analysis. This does not seem to be a case where the user has done something wrong, leading to an unaligned access, but rather some kind of issue with the compiler or library. What are the scenarios that can trigger this problem?

SDSCM00051484 "Compiler does not respect partial overrides in C99 designated initializers":

We use C99 designated initializers in our code. What kind of designated initialize usage is vulnerable here?

SDSCM00047077 "Incorrectly reduced double constant to float when ultimate destination is short":

How big is this scope? Does it also happens when the "ultimate destination" is char? Are int/long or long long destinations safe? Is it always the case the double constants are reduced to float when "targeting" short, or just sometimes? Does optimization impact this? Are there any other situations where the compiler is reducing double-precision operations to single-precision (other than the normal ones required by the C standards)?

As an aside, we would like to see this issue addressed. We appreciate that it is reasonable to flag the severity as minor in terms of the probable impact on executing code, but it is a significant issue for us, process-wise, to track down and analyze code that might be vulnerable to this problem.

SDSCM00050131 "Local struct with non-constant initializer treated as static scope variable":

I appreciate that this is fixed in 18.1.5.LTS, but we have equipment compiled under 18.1.4.LTS. Is this issue impact by whether or not optimization was enabled?

My interpretation is that the following two issues are not a problem when optimization is disabled. Can you confirm?

CODEGEN-5527 "Local structure initialization is incorrectly optimized away"
CODEGEN-5032 "Loop over array, preceded by shuffle of the array using scalar temp repeatedly, may produce incorrect results"

--thx

over 6 years ago

0 George Mock over 6 years ago

TI__Guru**** 250440 points

1138 said:
we have specified an optimization level of "off" in CCS, which I believe it is honoring by specifying the -g argument without specifying an --opt_level argument.

That is correct.

1138 said:
My interpretation is that the following two issues are not a problem when optimization is disabled. Can you confirm?

That interpretation is correct.

As for the other issues, I have asked other experts to comment.

Thanks and regards,

-George

0 1138 over 6 years ago in reply to George Mock

Expert 1226 points

Hello George,

Thank you for the follow-up!

In additional to the remaining pending questions, I have an additional one:

CODEGEN-1445 "Compiler inserts unnecessary register copy":

I assume that this unnecessary register copy does not cause any negative functional issues; it really only impacts performance. (i.e. it doesn't potentially create any additional read from volatile memory or some such; it's literally just a copy from one core ARM CPU registers to another that wasn't strictly needed to perform.) Can you confirm?

--thx

0 George Mock over 6 years ago

TI__Guru**** 250440 points

1138 said:

CODEGEN-4304 "runtime failure on unaligned access (on some processor variants, not all)":

I see that this has a test case attached to it, but no further analysis. This does not seem to be a case where the user has done something wrong, leading to an unaligned access, but rather some kind of issue with the compiler or library. What are the scenarios that can trigger this problem?

This one has only been partially analyzed. No firm conclusions about the cause are available.

1138 said:

SDSCM00051484 "Compiler does not respect partial overrides in C99 designated initializers":

We use C99 designated initializers in our code. What kind of designated initialize usage is vulnerable here?

The code that fails uses designated initializers in a way that is far from typical. I think an example will help ...

typedef struct {
	int	k;
	int	l;
	int	a[2];
} T;

typedef struct {
	int	i;
	T	t;
} S;

T x = {.l = 43, .k = 42, .a[1] = 19, .a[0] = 18 };

S y;

void
f(void)
{
        /* PROBLEM HERE */
	S l = { 1, .t = x, .t.l = 41, .t.a[1] = 17};

	y = l;
}

Notice how all of .t is initialized, followed by other initializers that are only for parts of .t .

Regarding ...

1138 said:
SDSCM00047077 "Incorrectly reduced double constant to float when ultimate destination is short":

I can answer some of your questions. But there are others questions I still cannot answer.

1138 said:
Are int/long or long long destinations safe?

Yes

1138 said:
Does optimization impact this?

1138 said:

SDSCM00050131 "Local struct with non-constant initializer treated as static scope variable":

I appreciate that this is fixed in 18.1.5.LTS, but we have equipment compiled under 18.1.4.LTS. Is this issue impact by whether or not optimization was enabled?

No. This forum thread is about the same issue.

Thanks and regards,

-George

0 George Mock over 6 years ago in reply to 1138

TI__Guru**** 250440 points

1138 said:

CODEGEN-1445 "Compiler inserts unnecessary register copy":

I assume that this unnecessary register copy does not cause any negative functional issues; it really only impacts performance. (i.e. it doesn't potentially create any additional read from volatile memory or some such; it's literally just a copy from one core ARM CPU registers to another that wasn't strictly needed to perform.) Can you confirm?

Your assumption is correct.

Thanks and regards,

-George

0 George Mock over 6 years ago in reply to George Mock

TI__Guru**** 250440 points

Regarding ...

George Mock said:

Regarding ...

1138

SDSCM00047077 "Incorrectly reduced double constant to float when ultimate destination is short":

I can answer some of your questions. But there are others questions I still cannot answer.

Here is the forum thread which resulted in this issue being filed. The release notes for this issue were recently updated to the following.

The compiler tries to optimize double precision constants as single precision constants when legal. In this case, a double precision expression which happens not to round was converted to a float precision expression which does round, and this difference matters. This bug can happen when a double precision expression involving a double precision constant (that is exactly representable in single precision) plus some other single precision value which might not exactly represent the decimal value in the source code is converted (implicitly or explicitly) to an integer type smaller than int.

Consider the expression 0.4f * 1000.0; 0.4 is not exactly representable in binary floating-point, so the compiler represents this with a value that is slightly less than 0.4. The compiler assumed that because 1000 is exactly representable in single precision format, that it could safely change the expression to 0.4f * 1000.f, but 0.4f * 1000.0 < 0.4f * 1000.0f, and that made a difference to this algorithm.

Thanks and regards,

-George

Code Composer Studio™︎

Code Composer Studio forum

Compiler/ARM-CGT: Information about known issues with ARM compiler