* Kind of undefined behavior (or bug?) with GCC 10.1
@ 2020-06-16 11:57 Roland Denis
2020-06-16 12:59 ` Jonathan Wakely
0 siblings, 1 reply; 3+ messages in thread
From: Roland Denis @ 2020-06-16 11:57 UTC (permalink / raw)
To: gcc-help
[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]
Hi,
I encounter a strange bug while compiling a project with GCC 10.1 and
-O3 that looks like an undefined behavior but I don't found where.
Result is correct with previous version of GCC, with LLVM & Intel.
I have attached a snippet (also on godbolt
https://gcc.godbolt.org/z/EC4WYZ) that I tried to minimize but remaining
lines seems to be important to reproduce the erroneous result.
Uncommenting any of the indicated lines solve the issue.
To explain the code a bit: from a 3D Point with integer coordinates, I
convert it into another coordinate system (using uSpel that returns a
Cell). I use a dimension iterator q (DirIterator, that doesn't look like
an iterator anymore) and the uIncident function to visit neighbors of
the cell. From the point (0, 0, 0), I should get the cell c=(1, 1, 1)
and the incident cell f1=(0, 1, 1). I additionally copy f1 into f2 (to
increase the weirdness of the bug).
Here are the result with and without -O3 flag:
$ g++ bug_minimal.cpp && ./a.out
q.dir = 0 ; f1 = 0 1 1 ; f2 = 0 1 1
$ g++ -O3 bug_minimal.cpp && ./a.out
q.dir = 0 ; f1 = 1 1 1 ; f2 = 0 1 1
The bug is in the first coordinate of f1 that should be 0.
As I explain above, slightly modifying the code implies the right
result, e.g.:
- declaring default copy or move constructor for Point
- using std::array in place of Point
- using Point in place of Cell
- passing Cell by reference instead of copy in uIncident
- constructing Cell without uSpel
- specifying the incidence direction by hand
Am I missing something important or does that look like a GCC bug ?
Regards,
PS: result is correct with trunk version of GCC in godbolt, does that
mean it is an already solved bug?
--
Roland DENIS
[-- Attachment #2: bug_minimal.cpp --]
[-- Type: text/x-c++src, Size: 2046 bytes --]
#include <array>
#include <iostream>
struct Point
{
std::array<int, 3> array;
Point(int x, int y, int z) : array{x, y, z} {}
Point(const Point & other) : array{other.array} {} // OK if commented
//Point(const Point &) = default; // OK
//Point(Point && other) = default; // OK
int operator[] (std::size_t i) const { return array[i]; }
int& operator[] (std::size_t i) { return array[i]; }
};
//using Point = std::array<int, 3>; // OK
struct Cell
{
Point point;
Cell(Point const& pt) : point(pt) {}
int operator[] (std::size_t i) const { return point[i]; }
int& operator[] (std::size_t i) { return point[i]; }
};
//using Cell = Point; // OK
std::ostream & operator<< (std::ostream & out, Cell const& object)
//std::ostream & operator<< (std::ostream & out, Cell object) // Fails with f2 too
{
for ( std::size_t i = 0; i < 3; ++i )
out << object[ i ] << " ";
return out;
}
struct DirIterator
{
std::size_t dir;
Cell cell;
DirIterator(Cell c)
: dir(0), cell(c)
{
find(); // OK if commented
}
void find()
{
//while (dir < 3) // Fails with f2 too
while (dir < 3 && (cell[dir] % 2) == 0)
++dir;
}
};
Cell uIncident(Cell c, std::size_t k)
//Cell uIncident(Cell& c, std::size_t k) // OK
{
--c[k];
return c;
}
Cell uSpel(Point p)
{
for (std::size_t i = 0; i < 3; ++i)
p[i] += p[i] + 1;
return Cell(p);
}
int main () {
Cell c = uSpel(Point{0, 0, 0}); // Fails
//Cell c( Point(1, 1, 1) ); // OK
auto q = DirIterator( c );
Cell f1 = uIncident( c, q.dir ); // Fails
//Cell f1 = uIncident( c, 0 ); // OK
Cell f2 = f1; // f2 is the right cell that f1 should be
std::cout << "q.dir = " << q.dir << " ; f1 = " << f1 << " ; f2 = " << f2 << std::endl;
//std::cout << "q.dir = " << q.dir << " ; f1 = " << f1[0] << " " << f1[1] << " " << f1[2] << " ; f2 = " << f2[0] << " " << f2[1] << " " << f2[2] << std::endl; // OK
return 0;
}
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Kind of undefined behavior (or bug?) with GCC 10.1
2020-06-16 11:57 Kind of undefined behavior (or bug?) with GCC 10.1 Roland Denis
@ 2020-06-16 12:59 ` Jonathan Wakely
2020-06-16 13:34 ` Roland Denis
0 siblings, 1 reply; 3+ messages in thread
From: Jonathan Wakely @ 2020-06-16 12:59 UTC (permalink / raw)
To: Roland Denis; +Cc: gcc-help
On Tue, 16 Jun 2020 at 12:58, Roland Denis wrote:
> Am I missing something important or does that look like a GCC bug ?
It's a bug. It started with https://gcc.gnu.org/r271510 and was fixed
in the master branch by https://gcc.gnu.org/r11-963 which was
addressing https://gcc.gnu.org/PR95493 which is a different bug.
> PS: result is correct with trunk version of GCC in godbolt, does that
> mean it is an already solved bug?
Looks like it, but I've added a comment to PR 95493 so that it can be
investigated and we can be sure your problem is really fixed.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Kind of undefined behavior (or bug?) with GCC 10.1
2020-06-16 12:59 ` Jonathan Wakely
@ 2020-06-16 13:34 ` Roland Denis
0 siblings, 0 replies; 3+ messages in thread
From: Roland Denis @ 2020-06-16 13:34 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: gcc-help
Thanks for your quick answer and the update on the bugtracker ! In a
way, I'm relieved it's not my code's fault ;)
I will keep an eye on this bug report.
Regards,
--
Roland DENIS
Le 16/06/2020 à 14:59, Jonathan Wakely a écrit :
> On Tue, 16 Jun 2020 at 12:58, Roland Denis wrote:
>> Am I missing something important or does that look like a GCC bug ?
> It's a bug. It started with https://gcc.gnu.org/r271510 and was fixed
> in the master branch by https://gcc.gnu.org/r11-963 which was
> addressing https://gcc.gnu.org/PR95493 which is a different bug.
>
>> PS: result is correct with trunk version of GCC in godbolt, does that
>> mean it is an already solved bug?
> Looks like it, but I've added a comment to PR 95493 so that it can be
> investigated and we can be sure your problem is really fixed.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-06-16 13:34 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-16 11:57 Kind of undefined behavior (or bug?) with GCC 10.1 Roland Denis
2020-06-16 12:59 ` Jonathan Wakely
2020-06-16 13:34 ` Roland Denis
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).