• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 55 subscribers
  • Views 8250 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CODECOMPOSER: CCS10.2.0 (20.2.2LTS) cannot compile HALCoGen 04.07.01 generated sources anymore

user6135372
Intellectual 720 points
Part Number: CODECOMPOSER
Other Parts Discussed in Thread: HALCOGEN

I was redirected here since my question can not be answer in the processor forum (link to original question CCSTUDIO: CCS10.2.0 (20.2.2LTS) cannot compile HALCoGen 04.07.01 generated sources anymore - Processors forum - Processors - TI E2E support forums)

Basically the problem is that with CCS 10.1.1 (ti-cgt-arm_20.2.1.LTS) the HALCoGen generated source compile fine with super strict settings (the relevant for this here are --strict_ansi, --diag_error=2142 and --emit_warnings_as_errors) and since CCS 10.2.0 (ti-cgt-arm_20.2.2.LTS) some files do no longer compile.

You can use the example QJ Wang posted in my original question and compile like this:

To get the error the compiler is now producing for ti-cgt-arm_20.2.2.LTS and ti-cgt-arm_20.2.4.LTS just run (#2142-D: comparison between signed and unsigned operands):

C:\ti\ccs1030\ccs\tools\compiler\ti-cgt-arm_20.2.4.LTS\bin\armcl.exe --silicon_version=7R5 --code_state=32 --float_support=VFPv3D16 -g --diag_wrap=off --display_error_number --enum_type=packed --abi=eabi --c99 --strict_ansi -O3 --diag_error=2142 --emit_warnings_as_errors --compile_only --include_path=include --include_path="C:\ti\Hercules\F021 Flash API\02.01.01\include" --include_path=C:\ti\ccs1030\ccs\tools\compiler\ti-cgt-arm_20.2.4.LTS\include source\HL_sys_dma.c --output_file=HL_sys_dma.obj

We suspect the the enum handling must have changed and a regression was introduced in the last update.

  • 0
    TI__Guru**** 232670 points

    I will work with QJ Wang on this issue.  At this point, it is too soon to say what might be done about it.  

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Guru**** 232670 points

    This appears to be a problem with the compiler.  I filed the entry EXT_EP-10334 to have it investigated.  You are welcome to follow it with that link.

    Thanks and regards,

    -George

  • 0
    TI__Guru* 84225 points

    Yes, the change was a fix for EXT_EP-9853, and the behavior change is deliberate; the earlier behavior was a bug.

    First, please note that in C, the 'u' suffix on those enumeration constant initializers doesn't impact the type of either the enumeration constants or the underlying type of the enum. 

    To make a very long story short, 20.2.1.LTS picked "plain char" for the enum type and 20.2.2.LTS and higher will pick "signed char," as they were expected to.  Note that the choice of type for the enum depends on strict ANSI mode, whether the file is C or C++, the value of the --enum_type command-line option, and the range of values of the enumeration constants.

    If you want the enum to be "unsigned char," add a dummy enumeration constant with the value UCHAR_MAX:

    #include <limits.h>
    enum e { a=1, b=2, c=3, dummy=UCHAR_MAX };
  • 0 in reply to Archaeologist
    Intellectual 720 points

    Thanks, for detailed information.

    Our problem is the following: We are generating the HAL on the fly with HALCoGen as first step in the build process and do not alter the output sources. After that the compilation starts.

    Our question is therefore: Shoulnd’t HALCoGen create valid sources for a setting that uses --strict_ansi, --diag_error=2142 and --emit_warnings_as_errors, i.e. should the HALCoGen create warning free code?

  • 0 in reply to user6135372
    TI__Guru* 84225 points

    Ideally yes, but the generated code ran afoul of a compiler bug that it wasn't prepared to deal with (EXT_EP-9853).  The generated code assumed that the old behavior was correct, created code that depended on that behavior to compile without warnings, and cranked up the severity level of that warning to an error.  In retrospect, that was the wrong thing to do; we should have noticed the problem with the enum type and fixed it in the compiler, and had HALCoGen generate enums which expected the intended enum type.  The warning in this case is spurious; the code behaves properly even though there is a warning, so it is pointless to crank up that warning to the level of an error, at least for this particular line of code.  The precise fix for this is to modify HALCoGen to emit code that works correctly with 20.2.2.LTS and later (and 20.2.1.LTS if possible), but I don't think there will be an update to HALCoGen anytime soon.  So, what is the workaround?  Using --emit_warnings_as_errors is handy to make sure you don't overlook potential problems, but in this case the potential problem is not an actual problem, and this should be relaxed.  Remove --emit_warnings_as_errors and --diag_error=2142.  If you don't want to do that, I'm afraid the only remedy is to modify the source code, and the smallest change would be to add the dummy variable, as above.

  • 0 in reply to Archaeologist
    TI__Guru**** 186196 points

    Thanks Archaeologist

    We don't have plan to update the HALCoGen. But I can add a workaround to the release note.

    Where to put the workaround mentioned in your previous post?

    I added enum e{..} to sys_dma.c, but I got the same compile error. I don't know what I missed.

  • 0 in reply to QJ Wang
    TI__Guru**** 232670 points

    Have you verified that the source lines which receive the diagnostic use the enumerated type highlighted in yellow?  I suspect they use a different enumerated type.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Guru**** 186196 points

    Hi George,

    I added a dummy const to dmaMPURegion based on the workaround Archaeologist suggested, the error is gone.

  • 0 in reply to Archaeologist
    Intellectual 720 points

    Thanks for that detailed answer. I think we remove  --emit_warnings_as_errors and --diag_error=2142 for these two files.

    Thanks again for looking into this!