- User Since
- Oct 10 2016, 10:44 AM (299 w, 1 d)
great addition. Missing a test case though, which would probably trigger @aaron.ballman scenario
Mon, Jul 4
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.
Fri, Jul 1
gentle ping o/
Thu, Jun 30
Update test case to take into accounts reviewers suggestions.
Wed, Jun 29
@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 :-/
Code updated to take into account two situations:
Tue, Jun 28
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).
Mon, Jun 27
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...
Fri, Jun 24
Thanks @MaskRay for the quick patch!
Take review into account : rework indentation, style cleaning and be more accurate about bounds reporting
Thu, Jun 23
Activate -Warray-parameter on -Wmost but disable it by default
Wed, Jun 22
Hey Sam, any update on this one? How can I help?
Tue, Jun 21
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
Mon, Jun 20
Sat, Jun 18
(rebased on main branch)
I"m not 100% sure of the fix but it fixes bug #55560 and does not introduce regression :-/
Thu, Jun 16
Update option and code to handle several level of conformance
Wed, Jun 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 does toward -fstrict-flex-arrays=<n> with
Tue, Jun 14
Take into account @aaron.ballman review
Mon, Jun 13
- 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 ;-)
Fri, Jun 10
Update changelog entry
Thu, Jun 9
Jun 3 2022
Thanks @thakis for the post-commit review. I'll give it another try next week.
Jun 2 2022
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.
Jun 1 2022
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
May 31 2022
Updating test case / sorry for the delay
Gentle ping :-)
May 25 2022
May 23 2022
May 19 2022
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.
May 16 2022
Update existing test case
Fix test case
+ test case
May 15 2022
May 13 2022
Update messed up format
May 12 2022
May 10 2022
Update GCC manual quote
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.