great addition. Missing a test case though, which would probably trigger @aaron.ballman scenario

In D128715#3629253, @thakis wrote:

Looks like this breaks tests on windows: http://45.33.8.238/win/61559/step_8.txt

I'm fine with these tests has they reflect current implementation. But beware that ubsan and -Warray-bounds don't behave the same wrt. FAM, which I find disturbing. I'll discuss that in another review.

Fix handling of ConstantArrayType, thanks @aaron.ballman for the hint.

gentle ping o/

Extra test

Update test case to take into accounts reviewers suggestions.

@aaron.ballman : I agree with most of your suggestion except the one below that I annotated accordingly

And note that with current clang, the behavior I describe here is not uniform across clang code base :-/

In D128783#3617924, @MaskRay wrote:

Do we need a C test (just add a -x c RUN line)? @serge-sans-paille Do you think we may likely make C++ stricter than C?

Code updated to take into account two situations:

GCC and Clang don't have the same behavior wrt. macros-as-abound and standard-layout-requirement, see https://godbolt.org/z/3vc4TcTYz
I'm fine with keeping the CLang behavior, but do we want to keep it only for level=0, and drop it for higher level (this would look odd to me).

Take review into account + add C++ test file.

oh, and I landed that one while forgetting to link it to phabricator, this patch landed as 27fd01d3f88c1996fc000b6e139b50a600879fde

@RKSimon: I don't track the origin of the change, I can't tell...

Thanks @MaskRay for the quick patch!

Take review into account : rework indentation, style cleaning and be more accurate about bounds reporting

Activate -Warray-parameter on -Wmost but disable it by default

Hey Sam, any update on this one? How can I help?

Follow @nikic approach there, it's clean and simple. Just fix a little edge case in the finish routine. Note that I could have checked the size of the cleanup vector, but I felt like a more explicit approach would be better.

@kees does the new version looks good to you?

Address most reviewers comment:

• formatting style
• reduced memory consumption
• be clear about TR39 divergence
• class and option renaming
• getName() usage

This also seems to fix https://github.com/llvm/llvm-project/issues/37522 and https://github.com/llvm/llvm-project/issues/55315

(rebased on main branch)

I"m not 100% sure of the fix but it fixes bug #55560 and does not introduce regression :-/

Update option and code to handle several level of conformance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 does toward -fstrict-flex-arrays=<n> with

Take into account @aaron.ballman review

Address reviews

cc @thakis

• quiet output of the table conversion program when everything goes well
• cross-compilation support (untested)
• fix identifier retrieving

Blake3 adopted instead

Looks good on my side, waiting for feedback ;-)

Cleanup testcase

Update changelog entry

Take into account @efriedma and @kees review, plus adding a bunch of extra test case

Thanks @thakis for the post-commit review. I'll give it another try next week.

Fix typo

Address reviewer comment and add an extra test case to capture the issue.

Note: I named the option -fstrict-flex-arrays and not -fstrict-flex-array because we already have -fstrict-enums.

Sorry for the back and forth: I find the logic difficult to follow. What would you think of something along these lines (untested) https://godbolt.org/z/vh356fhaP

Updating test case / sorry for the delay

Gentle ping :-)

Gentle ping :-) I'm a little unsure on the value change upon error, but that's also a bit strange to issue an error but still generate some output.

Update existing test case

Fix test case

+ test case

In D125688#3515834, @nikic wrote:

Is it possible to add a test for this?

Update messed up format

Update GCC manual quote

In D124038#3504371, @efriedma wrote:

I think you're looking at old documentation? Here's what the current page (https://gcc.gnu.org/onlinedocs/gcc/Compound-Literals.html) has to say:

Looks good to me. Please wait for confirmation by @tstellar though.

Added reg to GCC info page to explain current behavior, and make the test more explicit with respect to that quote.