On Thu, Nov 24, 2016 at 5:45 PM, Nicolai Stange <nicstange@xxxxxxxxx> wrote:
> As it stands, [09/21] ("evaluate: check static storage duration objects'
> intializers' constness"), introduces the opt-in -Wconstexpr-not-const.
> This affects only initializers for objects of static storage duration.
>
> So, there is currently no way to opt out from the stricter integer
> constant expression checks etc. introduced with this series.
>
> I ran sparse with this series applied on the kernel back then and if I
> remember correctly, there was no spectacular difference though.
>
> If these stricter semantics nevertheless became a problem, this would be
> easily "fixable" by further relaxing them at user option, I think.
That is fine for now. We can always add the option later.
> Alright. May I further ask whether you've got all these precious
> Reviewed-by tags from Luc carried over? He did a great amount of review
> work on this series and it would be quite sad if these got lost.
> I still have them, so just tell me if you need a list. If not:
> nevermind.
Luc's review tag should be apply when it is accepted.The script does
not add review tags by itself. I usually add it by hand.
If yo want to add the tags in the patch, you are welcome resend the patch
with the new review tags. I just said don't need to send they if they are
exactly the same.
In this case, it is likely to have new around of patches series. We can
hold it off a bit.
>
> Yes, yes got that. Don't get me wrong, I'm not defending my particular
> choice of flags. If yours leads to cleaner/less code, I will be very
> happy.
>
> That being said, here's the next "corner case":
>
> 0 + 'a'
>
> Which flags would be set for this binary expression? All of "composite
> op", "integer const", "char const"?
>
> That would work with your test for integer constant expressions.
Yes. That is right.
For binary op, most of the case it just need to do:
new flags = left flags | right flags;
Then check if the combined result has invalid result.
> I think, it wouldn't be enough to just set "composite op" flag w/o
> anything else since the above integer constant expression needs to get
> distinguished from
>
> 0 + 0.0
>
> which is an arithmetic constant expression only. Thus, considering your
> tests for integer vs. arithmetic constant expressions, this would need
> to have at least its "float constant" flag set?
Yes, it would need to have "float constant" set on the final flag.
First of all, I think sparse will do implicit cast operation which will
add the "float constant" flag. It is the case for non-constant operations.
I need to dig deeper for constant case.
Even if there is no implicit cast operations, on the left hand you have "Int",
on the right hand you have "Float". So the combination will have "Int", "Float",
"composite op".
Base on my previous define for the arithmetic constant expressions:
>>> Integer constant expression can be tested as:
>>>
>>> !(flags & ( Addr | Float) ) && flag
The result has "Float" so it is not a integer constant expression.
>>>
>>> Arithmetic constant expression can be tested as:
>>>
>>> !(flags & Addr) ) && flag
>>>
The result does not have "Addr" so it is an arithmetic constant
expression. Your example does not break my representation.
We can still adjust the final result as needed. For most of the case
it does not need to adjust.
Other creative corner case are very welcome.
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
