This is an archive of the discontinued LLVM Phabricator instance.

[Clang] Propagate const context info when emitting compound literal
ClosedPublic

Authored by stuij on Aug 10 2022, 3:16 AM.

Details

Summary

This patch fixes a crash when trying to emit a constant compound literal.

For C++ Clang evaluates either casts or binary operations at translation time,
but doesn't pass on the InConstantContext information that was inferred when
parsing the statement. Because of this, strict FP evaluation (-ftrapping-math)
which shouldn't be in effect yet, then causes checkFloatingpointResult to return
false, which in tryEmitGlobalCompoundLiteral will trigger an assert that the
compound literal wasn't constant.

The discussion here around 'manifestly constant evaluated contexts' was very
helpful to me when trying to understand what LLVM's position is on what
evaluation context should be in effect, together with the explanatory text in
that patch itself:
https://reviews.llvm.org/D87528

Diff Detail

Event Timeline

stuij created this revision.Aug 10 2022, 3:16 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 10 2022, 3:16 AM
stuij requested review of this revision.Aug 10 2022, 3:16 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 10 2022, 3:16 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

The clang code change looks reasonable to me, but I'm not the most expert in that area.

The intended result certainly seems sensible, because the C90-compatible version of that code without a constant literal is happy to do double→float conversion at compile time without complaining about side effects:

static const float separate_array[1] = { 0.1, };
struct { const float *floats; } without_compound_literal = { separate_array };

and so it makes sense that the version with a compound literal should be treated no differently.

Nit in the commit message:

which should be in effect yet

Surely "which shouldn't be in effect yet"?

clang/test/CodeGen/const-init.c
1–3

I think some kind of a comment would be useful saying what this option is doing there -- at least, which one of the tests further down the file it's supposed to apply to. Otherwise I could easily imagine someone throwing it out again, and since the test would pass anyway, not noticing that it's no longer testing what it's meant to test.

stuij updated this revision to Diff 451781.Aug 11 2022, 2:29 AM

addressed review comments

stuij updated this revision to Diff 451783.Aug 11 2022, 2:35 AM
stuij marked an inline comment as done.

also added a comment above the runline. Initially thought it wouldn't be necessary as we're now doing a check, but I do agree that it's more clear to be specific about the cmdline arg.

vhscampos added inline comments.Aug 11 2022, 2:36 AM
clang/lib/CodeGen/CGExprConstant.cpp
2215–2216

This constructor has the second parameter optional anyway. I suggest you omit the nullptr here.

vhscampos added inline comments.Aug 11 2022, 2:37 AM
clang/lib/CodeGen/CGExprConstant.cpp
2215–2216

To clarify, when I say optional, I mean it has a default value with is already nullptr

stuij updated this revision to Diff 451794.Aug 11 2022, 3:21 AM

addressed review comment

stuij marked 2 inline comments as done.Aug 11 2022, 3:23 AM
stuij added inline comments.
clang/lib/CodeGen/CGExprConstant.cpp
2215–2216

done. thanks!

clang/test/CodeGen/const-init.c
1–3

thanks, yes is done. I also added a check on generation of the float value.

stuij edited the summary of this revision. (Show Details)Aug 11 2022, 3:25 AM
DavidSpickett added inline comments.
clang/test/CodeGen/const-init.c
2

Drive by comment, what is "the right thing" here? Without me having to git blame this file if I'm looking at this months from now.

You could add a comment down next to the test like "clang should evaluate this in a constant context, so floating point mode should have no effect". Which is still a bit vague but better than "clang should not crash if we do this".

Also are there any other floating point modes that have/had this same problem? They should be tested too if so.

rjmccall accepted this revision.Aug 17 2022, 9:41 AM

This seems reasonable.

This revision is now accepted and ready to land.Aug 17 2022, 9:41 AM
stuij updated this revision to Diff 453579.Aug 18 2022, 2:13 AM

addressed review comment

stuij marked an inline comment as done.Aug 18 2022, 2:26 AM
stuij added inline comments.
clang/test/CodeGen/const-init.c
2

Yea, that does make the intent clearer. Added.

DavidSpickett accepted this revision.Aug 18 2022, 2:39 AM

My comment was addressed, LGTM.

This revision was automatically updated to reflect the committed changes.
stuij marked an inline comment as done.