C6000 C/C++ CODE GENERATION TOOLS
8.0.0B4 August 2014
Defect History

-------------------------------------------------------------------------------
Table of Contents
-------------------------------------------------------------------------------
1. Defects fixed in C6000 Code Generation Tools release 8.0.0B4
2. Defects fixed in C6000 Code Generation Tools release 8.0.0B3
3. Defects fixed in C6000 Code Generation Tools release 8.0.0B2
4. Defects fixed in C6000 Code Generation Tools release 8.0.0B1
5. Current Known Issues


===============================================================================
1. Defects fixed in C6000 Code Generation Tools release 8.0.0B4
===============================================================================

The following defect was fixed in C6000 Code Generation Tools release
8.0.0B4, released August 2014.

-------------------------------------------------------------------------------
FIXED SDSCM00050677
-------------------------------------------------------------------------------

Summary            : Using --opt_level=1 or higher causes compiler to fail
                     with INTERNAL ERROR: >>>Register allocation failed

Fixed in           : 8.0.0B4
Severity           : S2 - Major
Affected Component : Code Generator

Release Notes:
  Floating point registers are causing INTERNAL ERROR: register
  allocation failure.

Workaround:
  Use _itof and _ftoi intrinsics


===============================================================================
2. Defects fixed in C6000 Code Generation Tools release 8.0.0B3
===============================================================================

The following defect was fixed in C6000 Code Generation Tools release
8.0.0B3, released August 2014.

-------------------------------------------------------------------------------
FIXED SDSCM00050365
-------------------------------------------------------------------------------

Summary            : openMP parser emit error message for #pragma omp critial
                     (name)

Fixed in           : 8.0.0B3
Severity           : S2 - Major
Affected Component : Parser

Release Notes:
  Parser does not process OpenMP critical pragma properly.

Workaround:
  pragma critical with a name is generating an error message when the name was
  not a variable declared in the compilation unit. Remove the name or use the
  name of a variable that is declared in the compilation unit.


===============================================================================
3. Defects fixed in C6000 Code Generation Tools release 8.0.0B2
===============================================================================

The following 3 defects were fixed in C6000 Code Generation Tools release
8.0.0B2, released July 2014.

-------------------------------------------------------------------------------
FIXED SDSCM00050243
-------------------------------------------------------------------------------

Summary            : Scary but harmless warning:  FAILURE in
                     mark_use_of_function_local_static()

Fixed in           : 8.0.0B2
Severity           : S2 - Major
Affected Component : Optimizer

Release Notes:
  Compiling for C++ and using -pm or -o4 may produce a warning like
  
  FAILURE in mark_use_of_function_local_static()
  fname1: __sti
  fname2: __sti_
  symbol: _$P$T62$2$1
  
  This warning, despite its dramatic wording, is harmless. The compiler
  will build the program just as it should, and the warning does not
  indicate any change in behavior. It's a debugging message that should
  not have been visible outside the development team.
  
  Defect occurs in C6000 Compiler versions: 6.0.1B1 - 6.0.31, 6.1.0B1 - 6.1.23,
  7.0.0B1 - 7.0.5, 7.1.0B1 - 7.1.0B3, 6.1.10.100 - 6.1.10.101, 7.2.0B1 - 7.2.12,
  7.3.0B1 - 7.3.17, 7.4.0B1 - 7.4.8, 7.5.0B1, 7.6.0B1 - 7.6.0, 8.0.0B1

Workaround:
  Avoid -pm or -o4. But the warning doesn't indicate any change of the
  compiler's behavior, so you might as well ignore it.

-------------------------------------------------------------------------------
FIXED SDSCM00050520
-------------------------------------------------------------------------------

Summary            : strip crashes on files with more than 64k sections

Fixed in           : 8.0.0B2
Severity           : S2 - Major
Affected Component : Strip Utility

Release Notes:
  The strip utility will abnormally terminate if its input is an ELF
  file with more than 64k sections (actually exactly 0xff00), and its
  output would be less than 64k sections.
  
  Defect occurs in C6000 Compiler versions: 7.0.0B1 - 7.0.5, 7.1.0B1 -
  7.1.0B3, 7.2.0B1 - 7.2.12, 7.3.0B1 - 7.3.17, 7.4.0B1 - 7.4.8, 7.6.0B1 -
  7.6.0, 8.0.0B2 - 8.0.0B1

Workaround:
  Don't strip the file

-------------------------------------------------------------------------------
FIXED SDSCM00050554
-------------------------------------------------------------------------------

Summary            : cmp6x (compressor) fails with error message "Backtracked
                     too many times"

Fixed in           : 8.0.0B2
Severity           : S2 - Major
Affected Component : Compressor (cmp)

Release Notes:
  This update fixes an issue where the cmp6x executable was abnormally
  terminating with an error message "Backtracked too many times".

Workaround:
  Use the --no_compress option. Code size will likely be worse.


===============================================================================
4. Defects fixed in C6000 Code Generation Tools release 8.0.0B1
===============================================================================

The following 3 defects were fixed in C6000 Code Generation Tools release
8.0.0B1, released July 2014.

-------------------------------------------------------------------------------
FIXED SDSCM00047517
-------------------------------------------------------------------------------

Summary            : Complex math operations are inefficient

Fixed in           : 8.0.0B1
Severity           : S2 - Major
Classification     : Performance
Affected Component : C/C++ Compiler (cl)

Release Notes:
  Improvements to the speed of C99 float complex will be appearing in v8.0 of
  the C6000 compiler.

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00050405
-------------------------------------------------------------------------------

Summary            : Incorrect error message when combining #pragma
                     PERSISTENT and DATA_SECTION

Fixed in           : 8.0.0B1
Severity           : S3 - Minor
Affected Component : C/C++ Compiler (cl)

Release Notes:
  The error message mentions noinit when it should say persistent instead.

Workaround:
  None.

-------------------------------------------------------------------------------
FIXED SDSCM00050535
-------------------------------------------------------------------------------

Summary            : Compiler does not accept documented option --c++03

Fixed in           : 8.0.0B1
Severity           : S2 - Major
Affected Component : C/C++ Compiler (cl)

Release Notes:
  Compiler emits a fatal error when --c++03 option is encountered on the
  command line.
  
  The --c++03 option is deprecated and will be interpreted as an alias for the
  --c++ option.

Workaround:
  Use the --c++ option instead.


===============================================================================
5. Current Known Issues
===============================================================================

The following 21 known issues exist for C6000 Code Generation Tools release
8.0.0B4 as of August 2014.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00014430
-------------------------------------------------------------------------------

Summary            : calloc doesn't check arguments to make sure the
                     requested size is reasonable
Affected Component : Runtime Support Libraries (RTS)

Description:
  The function calloc() is required to return a pointer to memory representing
  "nelem" copies of "size" bytes, or NULL if the request cannot be satisfied.
  However, for some values of "nelem" and "size" (specifically when the result
  of nelem*size wraps around), calloc can return a pointer to an object that is
  not large enough, rather than NULL.
  
  For example, on a 32-bit target, if the user calls calloc(0x00010001,
  0x00010001), even though each argument by itself is reasonable, the request
  cannot be satisfied because the product is 0x000100020001, which exceeds
  size_t. (Note that we cannot check for overflow by checking if the product is
  less than either argument, which is commonly done for unsigned addition.)
  Arguably, we can try to claim that it is undefined behavior to make a call to
  calloc where the product would exceed size_t, but there doesn't seem to be
  anything in the standard which says so.
  
  The problem is worse on 16-bit targets, where calloc(0x0101, 0x0101) is enough
  to overflow size_t. It may not be obvious to the user that this overflows.
  
  Another concern is that it is hard to figure out whether a multiplication will
  overflow without having a double-width multiply available.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00023977
-------------------------------------------------------------------------------

Summary            : compiler is scheduling use of A8 too early causing an
                     incorrect branch
Affected Component : Code Generator
Duplicate Defects  : SDSCM00038899, SDSCM00033497, SDSCM00027812,
                     SDSCM00026420, SDSCM00025367, SDSCM00024562

Description:
  The below code is generated by the compiler. The MVKL of _sqrt into A8 does
  not occur correctly which results in an incorrect branch.
  MVKH .S2 0x2de00d1b,B16
  ||         OR .L2X A8,B7,B1
  ||         MVKL .S1 _sqrt,A8 ; |80|
  ||         STW .D2T2 B29,*+SP(144) ; |88|
  
  There appears to some type of dependency with what happens several
  instructions above in:
  SUBDP .L1X A7:A6,B11:B10,A5:A4 ; |88|
  ||         ADDDP .S1 A11:A10,A11:A10,A7:A6 ; |81|
  
  If the NOPS between the instructions are increased, the error goes away.
  
  Increasing the NOP 1 to NOP 3 in line following the parallel SUBDP||ADDDP and
  the load works correctly.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00036152
-------------------------------------------------------------------------------

Summary            : Compiler generates internal error from parser when
                     compiling a source file containing gcc "labels as
                     values" extension
Affected Component : Parser
Duplicate Defects  : SDSCM00036148

Description:
  Use of GCC extension "labels as values" in a source file causes the compiler
  to generate an internal error and abort.
  
  Compiler needs to either properly support labels as values extension, or
  diagnose attempted use of "labels as values" and reject it as an
  unsupported feature.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00037671
-------------------------------------------------------------------------------

Summary            : XML output needs encoding specification
Affected Component : Linker

Description:
  Any tool that emits XML output (OFD or linker with --xml_info_file) needs to
  specify the encoding (e.g. encoding="ISO-8859-1") and be sure to handle
  "extended" characters correctly.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00039264
-------------------------------------------------------------------------------

Summary            : When building with -o2, compiler sometimes fails to
                     complete compilation
Affected Component : Optimizer

Description:
  Compiler fails to complete compilation of user-provided test case and
  eventually crashes.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00040934
-------------------------------------------------------------------------------

Summary            : Structure is not initialized correctly when using -o2 or
                     -o3 optimization
Affected Component : Optimizer

Description:
  There is a problem with the initialization of a structure using symbols
  generated in the linker command file. We use symbols generated in the linker
  cmd file using the dot operator. These symbols are used as an initial value
  for a class/struct with a constructor. In our case we want the difference of
  two addresses that 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 addresses; instead it uses the first symbol.
  
  When turning off optimization or using lower level of opt than -o2, the
  constructor calls are generated and the struct is initialized correctly.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00042559
-------------------------------------------------------------------------------

Summary            : modf(-Inf, 1.0) with -mv6740 enters infinite loop
Affected Component : C/C++ Compiler (cl)

Description:
  Attempting to call modf(-Inf, 1.0) will result in an infinite loop. C6000
  doesn't guarantee to handle Inf values correctly, but this should at least not
  be an infinite loop.
  
  Also calling modf(x, NaN) where x is negative will also result in an infinite
  loop. Not sure if this is the same bug.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00043877
-------------------------------------------------------------------------------

Summary            : Emit warning message when objects of size 256MB or
                     larger truncated
Affected Component : C/C++ Compiler (cl)

Description:
  Data objects of size 256MB or larger are silently truncated to a much smaller
  size. This is most easily seen for an object of size 512MB. The compiler
  should emit a warning message that indicates we don't support objects of size
  256MB or larger.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00046391
-------------------------------------------------------------------------------

Summary            : When failing to place a section, include size of
                     trampolines in error message
Affected Component : Linker

Description:
  The C6000 linker generates a strange error:
  
  lnk6x -mv=6600 _tsk.obj debug\single\_linker.cmd
  
  
  "_linker.cmd", line 5: error: program will not fit into available memory.
  placement with alignment fails for section ".text" size 0x1220 .
  Available memory ranges:
  MEM_18 size: 0x1220 unused: 0x1220 max hole: 0x1220
  error: errors encountered during linking; "$kernel.out" not built
  
  The alignment of the .text section is 32 (from ofd6x):
  
        18 .text 0x00000000 0x00000000 0x1220 32 Y
  
  The relevant part of the command file is:
  
  MEMORY {
     MEM_18: o=0x00800420 l=0x00001220
  }
  SECTIONS {
     .text > MEM_18
  }
  
  The error indicates that the linker can't fit 0x1220 bytes into a properly-
  aligned hole at 0x00800420 that is 0x1220 bytes long!
  
  There are no other .text sections or subsections.
  
  [ response: The error message is a bit misleading about the size of .text. The
  reported size is the total size of the input sections named .text, but doesn't
  account for the trampolines that the linker had to add. If you look at the
  linker map file (the linker option --map_file), you'll see that the actual
  size of .text after trampolines are added is 0x14e0. Certainly that error
  message needs to be made clearer ]

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00046659
-------------------------------------------------------------------------------

Summary            : global labels defined in .cproc region are discarded
Affected Component : Code Generator

Description:
  The linear assembler accepts global label definitions inside a .cproc region,
  and even puts them in the I-file, but the codegen discards them.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00046690
-------------------------------------------------------------------------------

Summary            : pow(min, max) and pow(max, max) incorrect
Affected Component : Runtime Support Libraries (RTS)

Description:
  pow(DBL_MIN, DBL_MAX) should be 0, but RTS routine returns ???
  pow(DBL_MAX, DBL_MAX) should be +Inf, but RTS routine returns ???

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00046695
-------------------------------------------------------------------------------

Summary            : FP rounding error, 1 ULP makes P70590.c fail
Affected Component : Runtime Support Libraries (RTS)

Description:
  IEEE-754 requires exact rounding for float addition. The C6000 RTS function
  rounds differently than the hardware.
  
-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00046929
-------------------------------------------------------------------------------

Summary            : Hex converter fails to process RAM model .cinit records
                     for initialized sections
Affected Component : Hex Converter (hex)

Description:
  For a COFF RAM-model (-cr) program, hex converter fails to process the .cinit
  records for any initialized section. This is the same as SDSCM00036443, except
  that that covers the case when we are creating a boot table, and this request
  represents the case when we are not creating a boot table.
  
  Note that it's difficult to legitimately create an initialized section with
  .cinit records. The only way I was able to accomplish it was to create a
  distinct initialized section and combine them in the linker command file
  output section specification for .bss

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00046931
-------------------------------------------------------------------------------

Summary            : Hex converter map file does not list all sections for
                     RAM model program with initialized sections with .cinit
                     records
Affected Component : Hex Converter (hex)

Description:
  For a COFF RAM-model (-cr) program, when creating a boot table, the hex
  converter will process the .cinit records for any initialized section.
  
  However, the hex converter infrastructure gets confused because it keeps track
  of the end of a section's data in the boot table, and there might now be two
  parts: the initialized data and the converted .cinit records. This ultimately
  leads to almost no sections appearing in the hex converter map file.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00047243
-------------------------------------------------------------------------------

Summary            : isunordered not supported
Affected Component : Runtime Support Libraries (RTS)

Description:
  C6x does not support C99 function isunordered

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00047244
-------------------------------------------------------------------------------

Summary            : C99 header file fenv.h not supported
Affected Component : Runtime Support Libraries (RTS)

Description:
  C6x does not provide fenv.h

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00047245
-------------------------------------------------------------------------------

Summary            : C99 math.h macros not supported
Affected Component : Runtime Support Libraries (RTS)

Description:
  C99 math.h does not provide support for several macros (i.e. FLT_EVAL_METHOD,
  MATH_ERRNO, MATH_ERREXCEPT,
  FP_ILOGB0, FP_ILOGBNAN).

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00047568
-------------------------------------------------------------------------------

Summary            : Disassembler fails to disassemble DPINT DPTRUNC DPSP
Affected Component : Disassembler (dis)

Description:
  The disassembler disassembles valid DPINT, DPTRUNC, and DPSP
  instructions as .word

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00048083
-------------------------------------------------------------------------------

Summary            : %#x should not prefix 0x to a zero value
Affected Component : Runtime Support Libraries (RTS)

Description:
  C99 7.19.6.1 ("fprintf") says that with '#', "For x (or X) conversion, a
  nonzero result has 0x (or 0X) prefixed to it." However, we prefix the 0x even
  for zero values. Most other compilers do not prefix the 0x for a zero value.
  Strictly speaking, what we do could be argued to be conforming, but we really
  should just do what other compilers do.

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00048582
-------------------------------------------------------------------------------

Summary            : Use of short form of options in C_OPTION may cause
                     spurious warning
Affected Component : ELF Linker

Description:
  If the C_OPTION environment variable is set with the short form of an option,
  the compiler will sometimes emit a warning that the option is invalid for the
  linker and will be ignored.
  
  To recreate:
  setenv C_OPTION -pden
  bugslayer --t C6000 CQ10569
  
  You will see:
  cl6x -mv6400 --abi=coffabi ...
  <Linking>
  >> WARNING: invalid linker option -pden (ignored)

-------------------------------------------------------------------------------
KNOWN ISSUE SDSCM00050131
-------------------------------------------------------------------------------

Summary            : Local struct with non-constant initializer treated as
                     static scope variable
Affected Component : Parser

Description:
  We've discovered a problem where the C++ compiler places a local structure
  variable not on the stack but in the data segment, as if it was a static
  structure. The problem is especially insidious because the issue will only
  have an impact on re-entrance.
  
  The problem seems to occur only for C++ files, and only if the structure
  initializer list contains a variable. Constant initializer lists do not
  trigger the issue.
  
  The structure in the first function will be allocated on the stack, but the
  structure in the second will be compiled as if it was declared static.

