Hi Bernd,
> On 07 Aug 2018, at 19:10, Bernd Edlinger <[email protected]> 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);
begin
Process ("1234");
Process ("ABCD" & Ascii.NUL);
end;
-- 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".
Olivier
