Problem with __gmp_expr
marc.glisse at inria.fr
Sat Jan 18 14:33:27 UTC 2014
On Sat, 18 Jan 2014, Niels Möller wrote:
> Marc Glisse <marc.glisse at inria.fr> writes:
>> I still believe it is too late for 5.2,
> Why? Are you afraid it breaks some user code, or that isn't well enough
Not well enough tested. It probably also breaks the ABI since it changes
the size of some objects. And it is an important enough change that I want
time to think about it, go through gmpxx.h and consider the implications.
And by more testing, I don't just mean: the results are correct in the
testsuite. I also want to look at the generated code with another compiler
and some different examples.
It isn't a regression and I am scared of rushing a patch I wrote in less
than a minute.
> I'm afraid I don't understand the meaning of the two very small changes.
The one in unary_expr is just for uniformity with binary_expr. Then the
main question is what an expression object looks like. The type gives the
operation. Currently, we store references (pointers) to the arguments
(except for builtin types like int or double), and in particular an
expression can hold a reference to another expression that holds
references to etc. This way each expression object is small. With the
change, instead of having a reference to another expression, we know embed
a copy of that other expression (only true GMP variables are not copied
and still held by reference). Expression objects can now be rather large,
and we copy them around quite a bit. On the other hand, there are fewer
indirections, which may be why my gcc liked it. Ideally, it shouldn't
matter, the compiler should optimize all that away. In practice, it may
not perfectly finish the job sometimes.
Normally, the whole expression gets evaluated as soon as it is
constructed, so the temporary expression objects are still alive and the
current technique works. Using bad code (which has become very easy to do
accidentally in C++11), it is possible to delay the evaluation of the
expression. The top-level expression object is still fine, but all the
temporary expression objects we were keeping references to died at the end
of the line where we created the expression. When we try to evaluate, we
refer to dead objects, anything can happen. If we have instead copied all
sub-expressions into the one big top expression, we don't have that
More information about the gmp-bugs