[Bug c++/40036] New: Initializer incorrectly reordering arguments

[Bug c++/40036] New: Initializer incorrectly reordering arguments

[jwbates at mac dot com]

This bug was found with the following command-line option:

g++ -I ../../Headers -g -o Runtime0 Runtime0.cpp

It has appeared with all variations of the command-line that I have tried.

I'm building a fairly complex (all right, maybe a little insane) c++
template metaprogram to do efficient probabilistic inference. As a
part of that program, I am building expression classes to represent
intermediate calculations, preventing the overhead and extra
computation associated with temporary variables. So, for example,
multiplying three probabilistic potentials Pa, Pb, Pc is done by
creating an Expression<Expression<Pa, Multiply, Pb>, Multiply, Pc>.

The expression syntax that I have, while not robust enough to be a
general solution, correctly handles the cases that I need it to, as
verified by my unit tests. pabc = pa*pb*pc evaluates correctly when
written into a unit test.

But in order for this to be useful, I need the metaprogram to generate
the multiplication expression, and when I do so, I do *not* get the
correct results. I have run this code against gcc401, gcc43, and the
intel compiler, and only the intel compiler gets it right.

I have traced the incorrect results to one line of my code. At some
point, I have the constructor:

Expression(const Lhs & lhs, const Rhs & rhs) : _potentials(rhs,
lhs._potentials) {}

Notice that I swap rhs and lhs in the _potentials() initiator, for
proper evaluation ordering. When I look at this line in the debugger,
I see the correct types. 

But when I step into the _potentials constructor:

PotentialContainer(const ThisPotential & p, const ImportBase & others)
        : Base(others), _potential(p) {}

the argument "p" has the address of the "lhs" variable from the
preceding constructor, and "others" has the address of the "rhs"
variable. Furthermore, the types of the arguments are correct,
resulting in the "lhs" argument being treated as if it was a
ThisPotential type, and "rhs" being treated as an ImportBase, which
results in data being overwritten.

As per the gcc bug reporting instructions, I've included an
intermediate file (Runtime0.ii) for a debug build (or rather, I intend to...
where is the upload option in bugzilla?). I've tested on multiple
platforms and with several different argument lists, including fully
optimized, and no version of gcc/g++ that I have tried has handled this case
correctly. (Again, the intel compiler *does* work.)

The Expression() constructor in question is on line 20555 of the
Runtime0.ii file that I have enclosed.

Sadly, I haven't been able to find a simpler test case. Nor have I
found any workarounds.


-- 
           Summary: Initializer incorrectly reordering arguments
           Product: gcc
           Version: 4.3.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jwbates at mac dot com
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40036

[Bug c++/40036] Initializer incorrectly reordering arguments

[jwbates at mac dot com]

------- Comment #1 from jwbates at mac dot com  2009-05-06 04:09 -------
Created an attachment (id=17806)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17806&action=view)
output of g++ -save-temps


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40036

[Bug c++/40036] Initializer incorrectly reordering arguments

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2009-05-06 05:02 -------
Are you sure you are not running into unspecified behavior dealing with
subexpression is computed without a sequence point?  Because from your
description you are running into that issue.  As you mentioned you swapped
around lhs and rhs and get the results you expect.  And ICC produces a
different result than GCC too.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40036

[Bug c++/40036] Initializer incorrectly reordering arguments

[jwbates at mac dot com]

------- Comment #3 from jwbates at mac dot com  2009-05-06 05:25 -------
Not sure at all, as I have very little experience dealing with this kind of
issue. To clarify one point of ambiguity: when I mentioned swapping the order
of the arguments to match the correct evaluation behaviour. So, my constructor
Expression(lhs, rhs) calls the initializer _potential(rhs, lhs), which is
correct for my math. However, that's not the problem that I'm seeing.

When I set the breakpoint at Expression(lhs, rhs) and check the locations, lhs
is at 0x######6c, and rhs is at 0x######00 (or some such). When I step into
_potential(p, other), I should expect p to be rhs and other to be lhs, so
_potential(0x######00, 0x######6c), but what I see is _potential(0x######6c,
0x######00), which is pretty unambiguously incorrect. 

I'm perfectly willing to believe that my code is wrong, but I don't understand
what kind of code I could write (or fail to write) that could lead to a direct
call to an initializer with the argument addresses (but not the argument types)
swapped. If there's any place else that I can look, or any potential
workarounds I can try, I'll be happy to. It just looks, feels, and quacks like
a bug to me.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40036

[Bug c++/40036] Initializer incorrectly reordering arguments

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2009-05-06 06:08 -------
hmm, valgrind says there are some uninitiated memory.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40036

[Bug c++/40036] Initializer incorrectly reordering arguments

[jwbates at mac dot com]

------- Comment #5 from jwbates at mac dot com  2009-05-06 06:39 -------
All of the uninitialized memory errors in valgrind appear to occur after I do
the computation, when I'm just trying to print the results. 

I can convince myself that there's a good chance that the address swap is
leaving big chunks of my real data out in the cold, beyond my control. I mean,
if all of my data is sitting in my lhs, and that's being used as the rhs, then
it won't get touched. 

And for what it's worth, when I run valgrind on a version compiled with icc, I
get no memory errors.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40036

[Bug c++/40036] Initializer incorrectly reordering arguments

[jwbates at mac dot com]

------- Comment #6 from jwbates at mac dot com  2009-05-26 05:26 -------
Update: after some restructuring, the problem still occurs when using the -g
flag, but does not occur when the -O flag is used.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40036