[PATCH] Add a 'no-asserts' requirement option to LIT.

[Mehdi Amini]

> On Feb 3, 2015, at 12:32 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Tue, Feb 3, 2015 at 12:19 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
> Hi David,
> 
>> On Feb 3, 2015, at 11:15 AM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote:
>> On Tue, Feb 3, 2015 at 11:03 AM, Owen Anderson <resistor at mac.com <mailto:resistor at mac.com>> wrote:
>> Hi chandlerc, joker.eph,
>> 
>> This is useful when checking diagnostics and annotations that are only enabled in asserts mode. 
>> 
>> Not sure I quite follow - "REQUIRES: Asserts" would be used for any test case that's verifying a failure that's only enabled in asserts mode. "REQUIRES: no-asserts" would be for testing the absence of that same failure in a no-asserts build?
>> 
>> That seems like a thing I wouldn't want to test for. The idea is that the program has undefined behavior if it would assert but you're in a non-asserts build. That's not a thing to test for - there's no specific/guaranteed behavior in that case.
> 
> To provide you with more context: I am expecting some optional metadata from the front-end, but in case they are malformed for any reason I want to be bullet proof and handle this case gracefully (i.e. undefined behavior / crashing is not acceptable). So I’d like my assert build to verify the validity of the metadata but my release build to ignore it and set a suitable default value that I know allows recovery most of the time.
> 
> I can’t add a test to check if we recover correctly from an invalid metadata without this.
> 
> This is valid in general for the category of assertions we put to enforce some invariant/properties that are important for optimization purposes but does not prevent us from generating a correct code if they are broken.
> 
> Does it make sense?
> 
> Not sure how everyone else feels, but I'd rather classify something like that that has well-defined recovery semantics, as something other than 'validity’. 

To be sure I understand correctly: do you mean an assertions is not welcome on the normal path if we have a well-defined recovery path?

Thanks,

— 
Mehdi


> 
> When/where/how do you expect invalid metadata to come into your system?
>  
> 
> Thanks.
> 
> Mehdi
> 
> 
> 
>>  
>> Today we can only test the positive case (when asserts are enabled) but not the negative case.
>> 
>> REPOSITORY
>>   rL LLVM
>> 
>> http://reviews.llvm.org/D7383 <http://reviews.llvm.org/D7383>
>> 
>> Files:
>>   test/lit.cfg
>> 
>> Index: test/lit.cfg
>> ===================================================================
>> --- test/lit.cfg
>> +++ test/lit.cfg
>> @@ -370,6 +370,8 @@
>> 
>>  if re.search(r'ON', llvm_config_cmd.stdout.read().decode('ascii')):
>>      config.available_features.add('asserts')
>> +else:
>> +    config.available_features.add('no-asserts')
>>  llvm_config_cmd.wait()
>> 
>>  if 'darwin' == sys.platform:
>> 
>> EMAIL PREFERENCES
>>   http://reviews.llvm.org/settings/panel/emailpreferences/ <http://reviews.llvm.org/settings/panel/emailpreferences/>
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150203/abb9c6e3/attachment.html>