On Mon, 2024-07-22 at 17:13 +0100, Joern Wolfgang Rennecke wrote:
>
>
> On 22/07/2024 16:44, David Malcolm wrote:
> > Does it help to hack this change into prune.exp:
> >
> > diff --git a/gcc/testsuite/lib/prune.exp
> > b/gcc/testsuite/lib/prune.exp
> > index d00d37f015f7..f467d1a97bc6 100644
> > --- a/gcc/testsuite/lib/prune.exp
> > +++ b/gcc/testsuite/lib/prune.exp
> > @@ -109,7 +109,7 @@ proc prune_gcc_output { text } {
> > # Many tests that use visibility will still pass on platforms
> > that don't support it.
> > regsub -all "(^|\n)\[^\n\]*lto1: warning: visibility
> > attribute not supported in this configuration; ignored\[^\n\]*"
> > $text "" text
> >
> > - #send_user "After:$text\n"
> > + send_user "After:$text\n"
> >
> > return $text
> > }
>
> I'm baffled. Isn't that statement there just to debug
> prune_gcc_output?
> I suppose we could prune the whitespace from the diagram, but
> prune_gcc_output does not know about types. If there's 'int, that
> could
> be int32_t, int16_t, int64_t, ptrdiff_t, or whatever. Unless you
> want
> to make all integer types be considered equivalent for dejagnu
> purposes
> if they appear somewhere between vertical bars.
I may have misunderstood your email; I got the impression that you
having trouble seeing what gcc was emitting for you on this case. If
there's a mismatch, then the output will survive pruning and get dumped
there. But it sounds like that's not at all what you were talking
about; sorry.
>
> > >
> > > Would it make sense to handle this with one multi-line pattern
> > > for
> > > newlib based toolchains, ending with
> > > { dg-end-multiline-output "" { target *-*-elf } } */
> > > and one for glibc based toolchain, ending in
> > > { dg-end-multiline-output "" { target !*-*-elf } } */
> > > ?
> >
> > Presumably the only difference is in the top-right hand box of the
> > diagram,
>
> Unfortunately, there's also a lot of white space change in the rest
> of
> the diagram.
> I have attached the patch I'm currently using for your perusal.
Thanks. Looks good to me, but...
>
> whereas my objective for those tests was more about the lower
> > part of the diagram - I wanted to verify how we handle symbolic
> > buffer
> > sizes (e.g. (size * 4) + 3, and other run-time-computer sizes).
> >
> > It's rather awkward to test the diagrams with DejaGnu, alas.
> >
> > Would it might make sense to split out that file into three
> > separate
> > tests -11a, -11b, and -11c, and be more aggressive about only
> > running
> > the 2nd test on targets that we know generate "int" in the top-
> > right
> > box?
>
> No, each dg-end-multiline-output stanza already can have its separate
> target selector, there is no point in putting them in separate files.
> I guess you could reduce the differences between platforms if you
> didn't
> use types as defined by headerfiles directly, as they might be
> #defines
> or typedefs or whatever, and instead used your own typedef or struct
> types.
...that might be a better idea. All I care about for the tests that
are failing are the sizes so maybe using a
struct foo { uint_32_t val; }
is the way to go here.
Dave
