Summary: | unexpected address variation when taking address of reference, const reference, etc. | ||
---|---|---|---|
Product: | gcc | Reporter: | Parke <parke.nexus> |
Component: | other | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | P3 | ||
Version: | 4.8.2 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Known to work: | ||
Known to fail: | Last reconfirmed: |
Description
Parke
2014-04-07 20:32:35 UTC
I don't see why this is a bug, g and h should be different. Here is the reason, const int* const & cannot lvalue bind to int *, it can lvalue bind to const int* or int* const. So there is a lvalue to rvalue and then a conversion from int * to const int* and then a rvalue to const lvalue reference binding to const int* const &. This is true for i, j, and k. For l, int* const& can be lvalue bind to int*. (In reply to Parke from comment #0) > I in the output, I expect "e" through "l" to be identical. Your expectation is wrong. The functions that produce a different values from what you expect are binding a reference of some type X to an object that is not reference-compatible with X, which requires the creation of a temporary of type X. The temporary has a different address from the original object. Any conforming C++ compiler will produce similar results. Thanks, I thought it might be something like the creation of temporaries, but could not find it discussed anywhere, and was surprised that I got different behavior from 4.7.3 (many temporaries) and 4.8.2 (apparently only one temporary). (In reply to Parke from comment #3) > Thanks, I thought it might be something like the creation of temporaries, > but could not find it discussed anywhere, and was surprised that I got > different behavior from 4.7.3 (many temporaries) and 4.8.2 (apparently only > one temporary). Well 4.8 is better at coalescing the temporaries as there was a fix to the front-end to produce a CLOBBER after the statement has ended. |