• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 53 subscribers
  • Views 1358 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

C2000 Compiler v16.6 STS : buffer_diagnostics deprecated warning

Bob Bacon
Genius 10815 points


Hello
I have recently come across an issue when using C2000 compiler v16.6 STS

It produces the remark

 

: --buffer_diagnostics is deprecated and will be removed in a subsequent

   release. The default behavior is to line buffer diagnostics.

 

On further investigation I checked the compiler readme that states

------------------------------------------------------------------------------

2    Option Cleanup

-------------------------------------------------------------------------------

In this release we removed several options that were either duplicates or

unnecessary. For an overview of the changes please see

http://processors.wiki.ti.com/index.php/Compiler_option_cleanup

 

This web page indicates that –buffer_diagnostics is enabled by default but I can’t find any info on what this option does or why this remark should occur, if this is a default setting.

 

I know this is only a remark, but could I check

What does this option actually do ?

Is there any potential problem here that we should be aware of ?

Is there anything we can do to remove this remark ?

 

 

Best Regards

Bob Bacon

 

 

  • 0
    TI__Guru**** 251200 points

    Here is the sequence of events which led things to this point.

    Original releases of the compiler did not buffer output of diagnostics.  This is typical handling of any write to the stderr stream.  The presumption is that, since something has gone wrong, the diagnostic needs to appear as quickly as possible.  Not buffering the output means each character is written all the way out.  At the time, this caused no problems.

    Then host systems started to have multiple CPU's on them.  When is the last time you saw a laptop with only one CPU?  To take advantage of these multiple CPU's, developers started using implementations of make that issue multiple invocations of the compiler in parallel.  Suppose two invocations of the compiler are running at once, and they each issue different unbuffered diagnostics.  What does that look like?  It's a mess.  These messages get combined together in random ways.  Here is one actual example from a customer ...

    "/build/ltesdkroot/Plat"for/mbuilsd//ClGtTe/sTIdk_rCoGoTt_/7P_3l_a8t_BfLo-rGmEsN/ECRGITC//TCI6_00CG0T/_cg7t_o3o_l8s_/BiLn-cGlEuNdEeR/InCe/wC6", line 1240: 00remark/: cgsupport for placement delete is disabledto

ols/include/exception", line 6: remark: zero used for undefined preprocessing identifier"

    To address this problem, the option --buffer_diagnostics was added to the compiler.

    After some time, it was decided that the behavior of --buffer_diagnostics was much better, and it was adopted as the default.

    Which brings us to the present time.  The option --buffer_diagnostics is no longer needed.  So we have begun the process of removing it.

    Thanks and regards,

    -George