[PATCH] gas: range-check 3rd argument of .align et al

[Alan Modra]

On Wed, Apr 30, 2025 at 02:25:20PM +0200, Jan Beulich wrote:
> Negative values would have been silently converted to large positive
> ones, which may not be the user's intention. Similarly overly large
> values would have been silently truncated. Warn them instead, and zap
> such values.
> ---
> I've noticed this while pondering whether to assign meaning to negative
> values: Don't pad if fewer than the (negated) number would be inserted.
> Thoughts towards such an extension?
> 
> In !BFD64 configurations the "less than 0" check could in principle
> cause regressions, as large enough positive values would appear to be
> negative once returned from get_absolute_expression(). Such code would
> break anyway, however, once assembled with a BFD64 assembler (and that
> property may appear simply because of some secondary target that other
> binutils as a whole are configured to also support).

I like this warning, but gas/loongarch64/relax_align regresses after
this patch.  The test source even comments:
# If max < -0x80000000, max becomes a positive number because type conversion
# (bfd_signed_vma -> unsigned int).

Ideally the loongarch maintainers will fix the test..

> --- a/gas/read.c
> +++ b/gas/read.c
> @@ -1598,7 +1598,13 @@ s_align (signed int arg, int bytes_p)
>        else
>  	{
>  	  ++input_line_pointer;
> -	  max = get_absolute_expression ();
> +	  offsetT val = get_absolute_expression ();
> +	  max = val;
> +	  if (val < 0 || max != val)
> +	    {
> +	      as_warn (_("ignoring out of range alignment maximum"));
> +	      max = 0;
> +	    }
>  	}
>      }
>  

-- 
Alan Modra