Kind of undefined behavior (or bug?) with GCC 10.1

Kind of undefined behavior (or bug?) with GCC 10.1

[Roland Denis]

[-- 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;
}

Re: Kind of undefined behavior (or bug?) with GCC 10.1

[Jonathan Wakely]

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.

Re: Kind of undefined behavior (or bug?) with GCC 10.1

[Roland Denis]

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.