On 8/24/18 2:18 PM, Bernd Edlinger wrote:
> Hi!
>
>
> This is an alternative approach in making STRING_CST semantics
> consistent.
>
> This means it makes STRING_CST used for literals and for initializers
> use exactly the same semantics.
>
> It makes sure that all STRING_CST have a
On 9/13/18 1:41 PM, Bernd Edlinger wrote:
> On 09/13/18 20:44, Jeff Law wrote:
>> On 8/24/18 2:18 PM, Bernd Edlinger wrote:
>>> Hi!
>>>
>>>
>>> This is an alternative approach in making STRING_CST semantics
>>> consistent.
>>>
>>> This means it makes STRING_CST used for literals and for
On 09/13/18 20:44, Jeff Law wrote:
> On 8/24/18 2:18 PM, Bernd Edlinger wrote:
>> Hi!
>>
>>
>> This is an alternative approach in making STRING_CST semantics
>> consistent.
>>
>> This means it makes STRING_CST used for literals and for initializers
>> use exactly the same semantics.
>>
>> It makes
On 09/13/18 20:42, Jeff Law wrote:
> On 8/24/18 2:18 PM, Bernd Edlinger wrote:
>>
>> [PATCHv2] Handle overlength string literals in the fortan FE
>> https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01568.html
> I've committed this patch to the trunk.
>
Hi Jeff,
I fixed the ChangeLog entry,
and
On 8/24/18 2:18 PM, Bernd Edlinger wrote:
> Hi!
>
>
> This is an alternative approach in making STRING_CST semantics
> consistent.
>
> This means it makes STRING_CST used for literals and for initializers
> use exactly the same semantics.
>
> It makes sure that all STRING_CST have a
On 8/24/18 2:18 PM, Bernd Edlinger wrote:
>
> [PATCHv2] Handle overlength string literals in the fortan FE
> https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01568.html
I've committed this patch to the trunk.
jeff
Hi!
This is an alternative approach in making STRING_CST semantics
consistent.
This means it makes STRING_CST used for literals and for initializers
use exactly the same semantics.
It makes sure that all STRING_CST have a TYPE_SIZE_UNIT, and that it is
always larger than TREE_STRING_LENGTH,
On 08/22/18 22:54, Martin Sebor wrote:
> On 08/22/2018 08:27 AM, Bernd Edlinger wrote:
>> Hi,
>>
>>
>> this is an updated version of my STRING_CSTs checking in varasm.c
>> patch.
>>
>> It tries to answer the questions that were raised in th GO string literals
>> thread.
>>
>> The answers are:
>>
On 08/22/2018 08:27 AM, Bernd Edlinger wrote:
Hi,
this is an updated version of my STRING_CSTs checking in varasm.c
patch.
It tries to answer the questions that were raised in th GO string literals
thread.
The answers are:
a) strings with TYPE_SIZE_UNIT == NULL do exist, but only for
Hi,
this is an updated version of my STRING_CSTs checking in varasm.c
patch.
It tries to answer the questions that were raised in th GO string literals
thread.
The answers are:
a) strings with TYPE_SIZE_UNIT == NULL do exist, but only for STRING_CSTs
in constructors of flexible array struct
On 08/17/2018 07:53 AM, Bernd Edlinger wrote:
> On 08/17/18 15:38, Richard Biener wrote:
>> On Fri, 17 Aug 2018, Bernd Edlinger wrote:
>>
>>> On 08/17/18 14:19, Richard Biener wrote:
On Fri, 17 Aug 2018, Bernd Edlinger wrote:
> Richard Biener wrote:
>> +embedded @code{NUL}
On 08/17/2018 06:13 AM, Bernd Edlinger wrote:
>>
>
> Yes, there is a JIT code gen bug, that was caught by the assertion in my
> patch:
>
> [PATCH] Fix not properly nul-terminated string constants in JIT
> https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00370.html
THanks for the reference. I
On 08/17/18 15:38, Richard Biener wrote:
> On Fri, 17 Aug 2018, Bernd Edlinger wrote:
>
>> On 08/17/18 14:19, Richard Biener wrote:
>>> On Fri, 17 Aug 2018, Bernd Edlinger wrote:
>>>
Richard Biener wrote:
> +embedded @code{NUL} characters. However, the
> +@code{TREE_STRING_LENGTH}
On Fri, 17 Aug 2018, Bernd Edlinger wrote:
> On 08/17/18 14:19, Richard Biener wrote:
> > On Fri, 17 Aug 2018, Bernd Edlinger wrote:
> >
> >> Richard Biener wrote:
> >>> +embedded @code{NUL} characters. However, the
> >>> +@code{TREE_STRING_LENGTH} always includes a trailing @code{NUL} that
>
On 08/17/18 14:19, Richard Biener wrote:
> On Fri, 17 Aug 2018, Bernd Edlinger wrote:
>
>> Richard Biener wrote:
>>> +embedded @code{NUL} characters. However, the
>>> +@code{TREE_STRING_LENGTH} always includes a trailing @code{NUL} that
>>> +is not part of the language string literal but
On Fri, 17 Aug 2018, Bernd Edlinger wrote:
> Richard Biener wrote:
> > +embedded @code{NUL} characters. However, the
> > +@code{TREE_STRING_LENGTH} always includes a trailing @code{NUL} that
> > +is not part of the language string literal but appended by the front end.
> > +If the string shall
On Fri, 17 Aug 2018, Bernd Edlinger wrote:
> Richard Biener wrote:
>
> > Note that I'm a little bit confused here given build_string
> > already appends a '\0' after TREE_STRING_LENGTH. So it is safe
> > to call strlen() on all STRING_CSTs. I think I raised this in
> > the review of one of
On 08/17/18 06:46, Jeff Law wrote:
> On 08/05/2018 04:28 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> I would like to do a minor tweak to the patch.
>> While staring at the other patch I realized that I should
>> better pass size and not thissize to the check
>> function, instead of making use of how
Richard Biener wrote:
> +embedded @code{NUL} characters. However, the
> +@code{TREE_STRING_LENGTH} always includes a trailing @code{NUL} that
> +is not part of the language string literal but appended by the front end.
> +If the string shall not be @code{NUL}-terminated the @code{TREE_TYPE}
> +is
Richard Biener wrote:
> Note that I'm a little bit confused here given build_string
> already appends a '\0' after TREE_STRING_LENGTH. So it is safe
> to call strlen() on all STRING_CSTs. I think I raised this in
> the review of one of Bernds patches but to be honest all the
> various threads
On Sat, 4 Aug 2018, Bernd Edlinger wrote:
> On 08/03/18 23:36, Jeff Law wrote:
> > On 08/01/2018 05:35 AM, Bernd Edlinger wrote:
> >> Hi,
> >>
> >> this completes the previous patches, and adds a check in varasm.c
> >> that ensures that all string constants are NUL terminated,
> >> And that
On Fri, 3 Aug 2018, Jeff Law wrote:
> On 08/01/2018 05:35 AM, Bernd Edlinger wrote:
> > Hi,
> >
> > this completes the previous patches, and adds a check in varasm.c
> > that ensures that all string constants are NUL terminated,
> > And that varasm does not strip anything but _exactly_ one NUL
>
On 08/05/2018 04:28 AM, Bernd Edlinger wrote:
> Hi,
>
> I would like to do a minor tweak to the patch.
> While staring at the other patch I realized that I should
> better pass size and not thissize to the check
> function, instead of making use of how thissize is
> computed using MIN above.
Hi,
I would like to do a minor tweak to the patch.
While staring at the other patch I realized that I should
better pass size and not thissize to the check
function, instead of making use of how thissize is
computed using MIN above. This means that this condition
+ if ((unsigned)len != size &&
On 08/03/18 23:36, Jeff Law wrote:
> On 08/01/2018 05:35 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> this completes the previous patches, and adds a check in varasm.c
>> that ensures that all string constants are NUL terminated,
>> And that varasm does not strip anything but _exactly_ one NUL
>>
On 08/03/18 23:36, Jeff Law wrote:
> On 08/01/2018 05:35 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> this completes the previous patches, and adds a check in varasm.c
>> that ensures that all string constants are NUL terminated,
>> And that varasm does not strip anything but _exactly_ one NUL
>>
On 08/01/2018 05:35 AM, Bernd Edlinger wrote:
> Hi,
>
> this completes the previous patches, and adds a check in varasm.c
> that ensures that all string constants are NUL terminated,
> And that varasm does not strip anything but _exactly_ one NUL
> character.
>
> Bootstrapped and reg-tested on
Hi,
this completes the previous patches, and adds a check in varasm.c
that ensures that all string constants are NUL terminated,
And that varasm does not strip anything but _exactly_ one NUL
character.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
28 matches
Mail list logo
