This is the mail archive of the 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: [PATCH] [Ada] Make middle-end string literals NUL terminated

Hi Bernd,

> On 07 Aug 2018, at 19:10, Bernd Edlinger <> wrote:
>>> procedure Array9 is

>>> I see that "1234" is put in the merge section,
>>> but V1 is not.  Maybe because of the alignment requirement?
>>> But it sould not be much different from the C test case,
>>> which is now able to merge the non-zero terminated strings.
>> I'm happy to have a look.

An effect of alignments and inlining I think.
I see expected behavior with calls to an external program
instead of the local one.

I tried the testcases we have here plus a couple
of variations, e.g. with strings explicitly terminated
by multiple ascii.nul, and they all seem to be working
fine :-)

Regarding Ada testcases for the dejagnu suite, I'm not
quite sure how to go about them.

For starters at least, we could for example contemplate
something like:

-- { dg-do compile }                                                            
-- { dg-options "-O1 -fmerge-all-constants" }                                   

procedure String_Merge1 is
   procedure Process (X : String);
   pragma Import (Ada, Process);
   Process ("1234");
   Process ("ABCD" & Ascii.NUL);

-- We expect something like:                                                    

-- .section  .rodata.str1.1,"aMS",@progbits,1                                   
-- .LC2:                                                                        
--     .string "1234"                                                           
-- .LC3:                                                                        
--     .string "ABCD"                                                           

-- Not clear how to match that generally enough.                                

-- { dg-final { scan-assembler ".rodata.str1.1,\"aMS\"\[^\n\r\]*\n\.LC.:\n\[^\n\
\r\]*\.string \"1234\"\n\.LC.:\n\[^\n\r\]*\.string \"ABCD\"\n"  } }             

As the comment suggests, I'm not clear if that's robust/general enough.
I suppose we probably can't always expect .string, for instance. I suppose
we could also have other bits between the .section and the literals.

Would be fine as long as it's not something like ".section  .rodata".


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