• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 728 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.

Compiler release defects document problems?

Karl Kalchgruber
Prodigy 20 points

The defect notes (open & closed) are the same for 18.1.0 and 18.1.1.
Is that a mistake, or what ever was fixed?

In the "open defect" html file some entries are curiously truncated. It looks like there were problems with special characters (e. g.' <') when the files were generated. Furthermore, there are no statements at all regarding workaround... (It is difficult to judge whether you are affected by the summary)

  • 0
    TI__Guru* 84285 points
    There was a internal problem with 18.1.0 which was immediately noticed and fixed. There is no other difference between 18.1.0 and 18.1.1
  • 0
    TI__Guru* 84285 points
    Could you please specify which fields for which defects look artificially truncated?

    Many of those defects don't have a known workaround, so many of them will be blank.
  • 0 in reply to Archaeologist
    Prodigy 20 points
    For example, CODEGEN-4277 in the summary column of the html file displays "assertion failure in", in ClearQuest "assertion failure in <unordered_multimap>".
    Although without further description, this description does not help much.
    Can/should I use the <unorderd_multimap> or not? With the workaround you could at least guess what it is about if you didn't have a detailed description.
    (that only as an example, I'm not interested in this point right now)
  • 0 in reply to Karl Kalchgruber
    TI__Guru* 84285 points

    CODEGEN-4277 has not been analyzed, so we don't even know the cause, let alone a workaround. The symptom is that a certain program with an certain instantiation of unordered_multimap fails to compile; the compiler emits a static assertion failure. More likely than not, this is because of some unusual situation in the program, but it's not immediately obvious to me. You can safely use unordered_multimap; if it successfully compiles, it should be fine.

    I'm sorry that there isn't a high-quality "Release Notes" field for this one, or indeed for many of the defects. We typically write the release notes when the defect is analyzed, so that we know how to correctly describe the problem, but there is typically a small window between when the bug is analyzed and fixed, in which case it won't show up in the open defects list... Nonetheless, there is room for improvement. I would add that a lot of these open defects were discovered during the implementation of C++11/14 support, and only affect C++11/14 features.