[cfe-commits] r136998 - in /cfe/trunk: include/clang/Basic/IdentifierTable.h include/clang/Sema/Sema.h lib/Sema/SemaDeclObjC.cpp test/SemaObjC/class-protocol-method-match.m test/SemaObjC/qualified-protocol-method-conflicts.m

[Fariborz Jahanian]

On Aug 6, 2011, at 9:37 AM, Ted Kremenek wrote:

> On Aug 6, 2011, at 9:24 AM, Fariborz Jahanian wrote:
> 
>> 
>> On Aug 5, 2011, at 4:31 PM, Ted Kremenek wrote:
>> 
>>> Author: kremenek
>>> Date: Fri Aug  5 18:31:22 2011
>>> New Revision: 136998
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=136998&view=rev
>>> Log:
>>> Revert 136984 and 136927.
>>> 
>>> Removed:
>>>  cfe/trunk/test/SemaObjC/qualified-protocol-method-conflicts.m
>>> Modified:
>>>  cfe/trunk/include/clang/Basic/IdentifierTable.h
>>>  cfe/trunk/include/clang/Sema/Sema.h
>>>  cfe/trunk/lib/Sema/SemaDeclObjC.cpp
>>>  cfe/trunk/test/SemaObjC/class-protocol-method-match.m
>> 
>> Thanks for the reversion. I will take a look on Monday. I like to emphasize the correctness, but not the determinism.
> 
> By non-deterministic, I was speaking more to the output of your algorithm.  For example, while DenseMaps based on pointer types may introduce some "non-determinism" in the compiler's specific behavior (i.e., because pointer values may change), the algorithm which uses them should always produce deterministic results.  In this case, the output is non-deterministic, or at least is impacted by factors that should not change it's output (e.g., the endianess of the machine).

Yes. Actually, I have a trivial fix for non-determinsm as I was reading the emails.

- Fariborz