=?utf-8?q?Félix?= Cloutier <[email protected]>,
=?utf-8?q?Félix?= Cloutier <[email protected]>,
=?utf-8?q?Félix?= Cloutier <[email protected]>,
=?utf-8?q?Félix?= Cloutier <[email protected]>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/[email protected]>


AaronBallman wrote:

> @AaronBallman, I'll have a change ready addressing all of the outstanding 
> feedback, but I wanted to pre-check this with you:
> 
>     * Currently, `clang -O0` and `clang -O1` and above have incompatible 
> representations of `bool` (-O0 behaves as if using -fno-strict-bool=truncate, 
> -O1 and above as if using -fstrict-bool).
> 
>     * If we change the -fno-strict-bool default to be 
> -fno-strict-bool=nonzero, I assume I should also change the -O0 behavior to 
> match (or else -O0 will be incompatible with both -fstrict-bool and 
> -fno-strict-bool, which seems unnecessary).
> 
>     * Changing the -O0 behavior is, trivially, a break over existing -O0 
> behavior.
> 
>     * If we decide that the `-fno-strict-bool` default is `truncate`, then 
> there is no reason to change the -O0 behavior.
> 
> 
> I think this is new information around whether to prefer truncate or nonzero 
> by default, so I wanted to see if you have a new preference among these 3 
> options:
> 
>     1. -fno-strict-bool defaults to truncate, which matches the current -O0 
> behavior
> 
>     2. -fno-strict-bool defaults to nonzero, and we update the -O0 behavior
> 
>     3. -fno-strict-bool defaults to nonzero, and we do not update the -O0 
> behavior
> 
> 
> Up until now, I think that we were considering option 3.

I think my preference is for option 2. I don't think a lot of folks deploy 
`-O0` code in ways that would be problematic if the behavior changes (but we 
should call it out explicitly as a potentially breaking change in the release 
notes), but I do think a lot of folks expect `-O0` to not change the behavior 
to be more performant. WDYT?

https://github.com/llvm/llvm-project/pull/160790
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to