On 09/05/18 20:16, Janne Blomqvist wrote: > On Tue, Sep 4, 2018 at 10:05 AM Bernd Edlinger <bernd.edlin...@hotmail.de > <mailto:bernd.edlin...@hotmail.de>> wrote: > > On 03/09/2018, 21:25 Janne Blomqvist wrote: > > On Fri, Aug 24, 2018 at 11:06 PM Bernd Edlinger > <bernd.edlin...@hotmail.de <mailto:bernd.edlin...@hotmail.de>> > > wrote: > > > >> Hi! > >> > >> > >> This is an alternative approach to handle overlength strings in the > >> Fortran FE. > >> > > > > Hi, > > > > can you explain a little more what the problem that this patch tries to > > solve is? What is an "overlength" string? > > In the middle-end STRING_CST objects have a TYPE_DOMAIN > which specifies how much memory the string constant uses, > and what kind of characters the string constant consists of, > and a TREE_STRING_LENGTH which specifies how many > bytes the string value contains. > > Everything is fine, if both sizes agree, or the memory size > is larger than the string length, in which case the string is simply > padded with zero bytes to the full length. > > But things get unnecessarily complicated if the memory size > is smaller than the string length. > > In this situation we have two different use cases of STRING_CST > which have contradicting rules: > > For string literals and flexible arrays the memory size is ignored > and the TREE_STRING_LENGTH is used to specify both the > string length and the memory size. Fortran does not use those. > > For STRING_CST used in a CONSTRUCTOR of a string object > the TREE_STRING_LENGTH is ignored, and only the part of the > string value is used that fits into the memory size, the situation > is similar to excess precision floating point values. > > Now it happens that the middle-end sees a STRING_CST with > overlength and wants to know if the string constant is properly > zero-terminated, and it is impossible to tell, since any nul byte > at the end of the string value might be part of the ignored excess > precision, but this depends on where the string constant actually > came from. > > Therefore I started an effort to sanitize the STRING_CST via > an assertion in the varasm.c where most of the string constants > finally come along, and it triggered in two fortran test cases, > and a few other languages of course. > > This is what this patch tries to fix. > > Bernd. > > > I guess, I'm slightly confused why this mismatch happens in the first place > (does the Fortran frontend do something dumb wrt string declarations, or?), > but, Ok for trunk. > >
This is something that happens only on the test case that is mentioned in the comment. If I remember correctly the string constant is 3 characters long, as well as the type info on the STRING_CST itself, but the type of the object has only 2 byte space for the string. Therefore make the string shorter, and use the original type from the declaration. I am going to apply this together with the rest of the STRING_CST semantic patches, once those are approved. Thanks Bernd.
