[LLVMdev] LLVM 2.4 problem? (resend)

[David Vandevoorde]

On Oct 15, 2008, at 6:29 PM, Mike Stump wrote:

> On Oct 15, 2008, at 1:09 PM, David Vandevoorde wrote:
>> On Oct 15, 2008, at 3:53 PM, Mike Stump wrote:
>> [...]
>>> Objects are defined like so:
>>>
>>> Two pointers of
>>> the same type compare equal if and only if they are  both  null,
>>> both
>>> point  to  the same object or function, or both point one past the
>>> end
>>> of the same array.
>>>
>>> This means they _must_ compare !=, if they are different objects.
>>
>>
>> Aha!  Thanks for quoting that: It's from an expired standard (1998,
>> presumably).  The 2003 standard has changed the words for that,  
>> taking
>> away the property under discussion (for a different reason -- see  
>> Core
>> Issue 73).
>
> A distinction without a difference.  They are trying to word smith
> this to get it right, however, the underlying semantics are trivial
> and not in dispute.

On the contrary: Active CWG members disagree on this topic.


>  The part you seem to be missing is kinda
> fundamental, unless there is linkage, there is no linkage.  What
> linkage means is exactly the notion of if two entities refer to the
> same object or not, or to put it another way, if two entities have the
> same address.


You're mixing your terms: Linkage is a property of names and types;  
not entities (and not objects).  Furthermore, linkage deals with cross- 
scope (mostly, cross-TU) correspondences.  The question here can arise  
within a scope.


>  Pointing off the end of an array doesn't necessarily
> yield a pointer to an object.  It represents a value that can be
> manipulated to refer to an object, say, with p-1.
>
> I can quote n2461 if you prefer:
>
> Two pointers of the same type compare equal if and only if they are  
> both
> null, both point to the same function, or both represent the same
> address (3.9.2).
>
> A valid value of an object pointer type represents either the address
> of a byte in memory (1.7) or a null pointer (4.10). If an object of
> type T is located at an address A, a pointer of type cv T* whose value
> is the address A is said to point to that object, regardless of how
> the value was obtained.
>
> Static and automatic storage durations are associated with objects
> introduced by declarations (3.1) and implicitly cre-
> ated by the implementation (12.2).
>
> A declaration (clause 7) introduces names into a translation unit or
> redeclares names introduced by previous declarations.
>
> An object is a region of storage.
>
> An object is created by  a  definition  (_basic.def_)

basic.def doesn't contain the word "create" nor words to that effect,  
AFAICT.  Furthermore, basic.life 3.8/7 makes it clear that an object  
may be created on top of another object, and the name of the first  
object will correctly evaluate to the new object.

So that reasoning doesn't hold.

> Each declaration _creates_ an object.  The word create means that each
> has a region of bytes, distinct from all others.

No.


>> The changes to address Core issue 73 invalidates your reasoning
>
> No, they don't.  I'm describing a fundamental feature of C and C++
> that cannot be disputed.


It sure can.  In fact it _is_ being disputed.


>  The most that can be done is to add a rule
> that says objects declared with a const type can be merged, meaning
> that objects with the same value may (implementation defined or
> unspecified) refer to the address of one of them.  A rule like this
> could be added to C or C++, but has not been to the best of my
> knowledge.


The current consensus among CoreWG experts is that the words in the  
current standard (and those in the current WP) do not require distinct  
variables and temporaries to have distinct addresses per se.  (In most  
cases, distinct addresses are the only possible implementation, but  
even without const qualification there are cases that could be  
implemented with overlapping storage within the standard's words.   
E.g., if variables are address-exposed but never value-exposed.)

There is currently _no_ CoreWG consensus about whether that situation  
is intended and/or desirable.  The resolution of that is what the new  
core issue is about.

(I'm not sure what sort of guidance this provides for LLVM behavior.)

	Daveed