This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCHv2] Handle not explicitly zero terminated strings in merge sections


On 10/9/18 6:45 AM, Bernd Edlinger wrote:
> On 10/03/18 18:31, Jeff Law wrote:
>>> -      && (len = int_size_in_bytes (TREE_TYPE (decl))) > 0
>>> -      && TREE_STRING_LENGTH (decl) >= len)
>>> +      && (len = int_size_in_bytes (TREE_TYPE (decl))) >= 0
>>> +      && TREE_STRING_LENGTH (decl) == len)
>> Not sure why you want to test for >= 0 here.  > 0 seems sufficient,
>> though I guess there's no harm in the = 0 case.
>>
> 
> Aehm, cough...
> 
> Sorry Jeff, I need to change that back.  It turns out that
> completely empty strings don't work right, because of this
> check in output_constant:
> 
> output_constant (tree exp, unsigned HOST_WIDE_INT size, unsigned int align,
>                   bool reverse, bool merge_strings)
> {
>    enum tree_code code;
>    unsigned HOST_WIDE_INT thissize;
>    rtx cst;
> 
>    if (size == 0 || flag_syntax_only)
>      return size;
> 
> So while my intention was to add a null-termination for all strings, including empty ones,
> this does not work for empty strings, which was diagnosed by the solaris assembler/linker.
> 
> However since those empty strings do not use any space, there is no improvement
> by merging them in the first place.
> 
> 
> Rainer bootstrapped the attached patch successfully.
> Is it OK for trunk?
OK.  Funny I almost called out the zero size stuff as being pointless to
bother handling in the first place.  Oh well.

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]