
Awful bug in Portland Group C ++ compiler
This publication is for those who are forced to use the pgcpp compiler or maintain code compatibility with this compiler.
The other day I received a bug report that my code does not work correctly if compiled with pgcpp.
Having started to understand, I found a place where an error occurs. It turned out that if the code compiles with O2 or O3 optimization, then std :: sort can start to duplicate part of the vector and replace other parts with these duplicates.
Here is simple C ++ code to help recreate this terrible behavior (note the number 3193 in the output):
I tested on Linux, but presumably an error also occurs on Windows.
I wrote in support and they replied that they were able to recreate "this behavior", so there is hope that the bug will be fixed soon. In the meantime, I recommend using either std :: stable_sort or (if you can choose) another compiler (the Portland Group also has an alternative compiler - pgc ++ - and this bug is not observed there).
Good debugging and fewer bugs in compilers.
The other day I received a bug report that my code does not work correctly if compiled with pgcpp.
Having started to understand, I found a place where an error occurs. It turned out that if the code compiles with O2 or O3 optimization, then std :: sort can start to duplicate part of the vector and replace other parts with these duplicates.
Here is simple C ++ code to help recreate this terrible behavior (note the number 3193 in the output):
#include
#include
#include
struct ID{
ID(){};
ID(unsigned id) : Id(id){};
unsigned Id;
bool operator < ( ID const &other ) const { return Id < other.Id; } };
main(){
std::vector ids;
for (unsigned i=0; i < 5; ++i)
for (unsigned id=0; id < 2000; ++id )
ids.push_back(ID(id*5+i));
std::sort(ids.begin(),ids.end());
// std::stable_sort(ids.begin(),ids.end());
for (std::vector::const_iterator it=ids.begin();it!=ids.end();++it)
std::cout << it->Id << std::endl;
}
I tested on Linux, but presumably an error also occurs on Windows.
I wrote in support and they replied that they were able to recreate "this behavior", so there is hope that the bug will be fixed soon. In the meantime, I recommend using either std :: stable_sort or (if you can choose) another compiler (the Portland Group also has an alternative compiler - pgc ++ - and this bug is not observed there).
Good debugging and fewer bugs in compilers.