On 09/06/18 17:43, Jeff Law wrote: > On 09/06/2018 05:05 AM, Bernd Edlinger wrote: >> On 09/04/18 16:30, Jeff Law wrote: >>> On 09/03/2018 06:35 AM, Bernd Edlinger wrote: >>> [ Big snip, dropping lots of context ] >>> >>>>>> No I don't think so, because at that time BRACE_ENCLOSED_INITIALIZER_P >>>>>> property does no longer work, as I explained in the previous mail. >>>>>> >>>>>> And cp_complete_array_type does use that property: >>>>> [ ... ] >>>>> Jason's the expert here. I'll defer to his expertise. It just seemed >>>>> a bit odd to me that we have a routine to "complete" an array that does >>>>> any special C++ handling (cp_complete_array_type) and we're not using it. >>>>> >>>> Agreed, I have posted an update which uses cp_complete_array_type, since >>>> Jason raised the same point. >>>> >>>> But since C++ does not need the recursion here, things are a lot more easy. >>>> The patch still completes the array type _after_ the FE is completely done >>>> with the >>>> parsing, since I want to avoid to destroy the information too early, since >>>> the FE is looking >>>> at the TYPE_DOMAIN==NULL at various places. >>> FYI, I don't see a follow-up for this patch? Did I miss it? Or is it >>> under a different subject line? >>> >>> jeff >>> >> Yes, thanks for reminding me. >> I had forgotten to post the updated patch. >> >> So here is my latest version of the flexible array patch. >> >> Bootstrapped and reg-tested on x86_64-pc-linux-gnu (together with the other >> STRING_CST-v2 patches). >> Is it OK for trunk? >> >> >> Thanks >> Bernd. >> >> >> patch-flexarray.diff >> >> >> gcc: >> 2018-08-30 Bernd Edlinger <bernd.edlin...@hotmail.de> >> >> * varasm.c (output_constructor_regular_field): Check TYPE_SIZE_UNIT of >> the init value. >> >> c-family: >> 2018-08-30 Bernd Edlinger <bernd.edlin...@hotmail.de> >> >> * c-common.c (complete_flexible_array_elts): New helper function. >> * c-common.h (complete_flexible_array_elts): Declare. >> >> c: >> 2018-08-30 Bernd Edlinger <bernd.edlin...@hotmail.de> >> >> * c-decl.c (finish_decl): Call complete_flexible_array_elts. >> >> cp: >> 2018-08-30 Bernd Edlinger <bernd.edlin...@hotmail.de> >> >> * decl.c (check_initializer): Call complete_flexible_array_elts. > Thanks. I fixed up the ChangeLog entry for the cp/ change and installed > this patch. > > As you've probably noted, I'm taking care of the installs on this stuff. > I'm doing additional testing and as a result I've got a tree with your > proposed patch "push ready". It'd be silly to not go ahead with the > push :-) >
Ah, thanks a lot. Okay, this is the status of the STRING-CST semantic-v2 patches: [PATCH] Check the STRING_CSTs in varasm.c https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01569.html => Unfortunately I forgot to change the Title to [PATCHv2] or so. Should I send a ping for this one? [PATCHv2] Handle overlength strings in the C FE https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01566.html => Should I send a ping for this one? [PATCHv2] Handle overlength strings in C++ FE https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01567.html => Apporoved, without the part in vtable-class-hierarchy.c (!) [PATCHv2] Handle overlength string literals in the fortan FE https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01568.html => Approved. Additional patches in the same area: [PATCH] Fix not properly nul-terminated string constants in JIT https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00370.html => This triggered an assertion in the V1-patch only, but is no pre-condition in the V2-semantic patch. Anyway would be good to get it in, since strings longer than 200 bytes will not be zero-terminated. I have a nice follow-up patch that allows non-zero terminated strings (mostly found in Ada and GO) to go into the string merge section. I did not post it yet to avoid confusion, but if you are interested to see it, I'll go ahead and post it. Regarding the nonstr parameter in string_constant, I still do have the impression that it would be more natural for string_constant _not_ to care about zero-termination, but instead move that check to c_strlen and c_getstr or similar high level functions, where for instance also a location value would be available. I could imagine something like an optional out-parameter with detailed error info struct nonstr { enum { no_error, char_type_mismatch, missing_zero_termination } err; tree str; location_t loc; nonstr(): err(no_error), str(NULL_TREE), loc(UNKNOWN_LOCATION) {} }; This information would be available in c_strlen here: if (eltsize != tree_to_uhwi (TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (src))))) return NULL_TREE; and here: /* Don't know what to return if there was no zero termination. Ideally this would turn into a gcc_checking_assert over time. */ if (len > maxelts - eltoff) return NULL_TREE; Thanks Bernd.
