Re: Testsuite patch for Solaris 10

[Daniel Jacobowitz <drow at false dot org>]

On Fri, Nov 12, 2004 at 04:07:05PM -0800, Janis Johnson wrote:
> My needs are simple: logical and, logical or, and logical not, with the
> possibility of adding other logical operators later.  Operands are
> procedures in .exp files that return 1 or 0.  Much to my relief, I found
> that these procs:
> 
>     proc dg-and { op1 op2 } {
>         return [expr $op1 && $op2]
>     }
>     proc dg-or { op1 op2 } {
>         return [expr $op1 || $op2]
>     }
>     proc dg-not { op } {
>         return [expr ! $op]
>     }
> 
> are evaluated before entering the proc to which their results are
> passed as arguments, so I can do:
> 
>   { dg-do run [dg-target-list target
>        [dg-and [dg-or [istarget i?86-*-*] [istarget powerpc-*-linux]]
>                [is-effective-target ilp32]]] }
> 
> Would it be acceptable to do things like this within tests?

Just my two cents... If I'm reading what you're trying to accomplish in
that example correctly, I'd rather write it like this:

{ dg-do run { target i?86-*-* powerpc-*-linux } }
{ dg-require ilp32 }

Yes, it doesn't have half the expressive flexibility.  When we run into
this as a real problem, then we can define additional predicates which
do whatever; we have that option.  I don't think we need to have
boolean logic embedded in tests.

Also, without line breaks, that's _really_ hard to read!  Even with
line breaks it's pretty hard, courtesy of TCL's nasted braces fetish.

-- 
Daniel Jacobowitz