Re: [PATCH 1/7] alpha: honor -frounding-math by selecting dynamic rounding

On 8/14/2026 1:29 PM, Matt Turner wrote:
> Alpha encodes the rounding mode in the instruction itself, so honoring a
> rounding mode chosen at run time requires the /d qualifier, which takes the
> mode from the FPCR.  alpha_fprm defaulted to ALPHA_FPRM_NORM and was only
> ever changed by an explicit -mfp-rounding-mode, so -frounding-math emitted
> statically rounded instructions and fesetround was silently ignored.
>
> Default alpha_fprm to ALPHA_FPRM_DYN when -frounding-math is in effect and
> -mfp-rounding-mode was not given, leaving both ordinary code generation and
> an explicit -mfp-rounding-mode unaffected.  The VAX floating-point
> instructions have no dynamic rounding qualifier, so -mfloat-vax keeps the
> static default.
>
> This fixes the execution failures of gcc.dg/torture/fp-uint64-convert-double-1.c,
> fp-uint64-convert-double-2.c and fp-double-convert-float-1.c.
>
> gcc/ChangeLog:
>
> 	* config/alpha/alpha.cc (alpha_option_override): Set alpha_fprm to
> 	ALPHA_FPRM_DYN when flag_rounding_math is set, -mfp-rounding-mode
> 	was not given explicitly and -mfloat-vax is not in effect.
> 	* doc/invoke.texi (Alpha Options): Document the default rounding
> 	mode and its interaction with -frounding-math.
THanks.  I've pushed this to the trunk as well.  My last alpha build 
didn't bootstrap, so something has gone weird, but I suspect it's 
generic and not anything you've done.

The last clean build I had was with:

7e0bb48cbb2654816ce2714de5b644f4d965d3db

The first failed build with:

df494ca28d75f80b4d0b4e0b93b5d23d2092131a

The failure mode is an ICE in the gimple threader:
during GIMPLE pass: thread
../../../gcc/libcpp/lex.cc: In function 'void _cpp_clean_line(cpp_reader*)':
../../../gcc/libcpp/lex.cc:970:1: internal compiler error: Segmentation fault
   970 | _cpp_clean_line (cpp_reader *pfile)
       | ^~~~~~~~~~~~~~~

I haven't tried to chase it down yet.  I usually let these things simmer 
a bit since testing/bisecting bootstraps of qemu emulated targets takes 
an absurdly long time.  But if you're interested in chasing another 
issue, this may be good to check.

jeff