[PATCH] Add a 'no-asserts' requirement option to LIT.
David Blaikie
dblaikie at gmail.com
Tue Feb 3 12:32:20 PST 2015
On Tue, Feb 3, 2015 at 12:19 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
> Hi David,
>
> On Feb 3, 2015, at 11:15 AM, David Blaikie <dblaikie at gmail.com> wrote:
> On Tue, Feb 3, 2015 at 11:03 AM, Owen Anderson <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'.
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
>>
>> 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/
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> 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/1f1e0fe1/attachment.html>
More information about the llvm-commits
mailing list