Problem with __gmp_expr

Marc Glisse marc.glisse at
Sat Jan 18 14:33:27 UTC 2014

On Sat, 18 Jan 2014, Niels Möller wrote:

> Marc Glisse <marc.glisse at> 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
> tested?

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 
problem anymore.

Marc Glisse

More information about the gmp-bugs mailing list