> Am 15.05.2026 um 21:59 schrieb Harald Anlauf <[email protected]>:
>
> Dear all,
>
> when looking at this PR, I wondered if this issue should be reclassified
> from a gfortran one.
>
> Part of the problem is that the driver rewrites "-fcheck=bounds" to
> "-fbounds-check" *unconditionally*, which leads to the processing of
> this option along a different path as any other -fcheck=xxx option.
>
> As a consequence, -fcheck=bounds -fcheck=no-bounds is treated the
> same as -fbounds-check -fcheck=no-bounds, which currently ends up
> as -fcheck=no-bounds -fbounds-check.
>
> The rewriting is triggered by gcc/d/lang.opt, which has:
>
> fcheck=bounds
> D Alias(fbounds-check)
>
> Commenting this entry, the rewriting is not done.
>
> Unfortunately, the rewriting happens even if one does not have d
> enabled! I.e., an unused/disabled FE has effects on other languages!
>
> The PR explains that we are currently *not* able to disable bounds
> checking later on the command line (after the -fcheck=bounds),
> as the variable set by -fbounds-check is evaluated after the
> individual -fcheck= options. (There is a workaround, though.)
>
> I thought of modifying the option processing order in gfortran, but
> this does create just a variant problem, as the option rewriting
> in the driver basically prevents the option processing to see the
> true order of the options on the command line.
>
> Am I missing something obvious / not-so-obvious?
>
> Reclassify this to driver or d?
Conflicting options cannot exist, I guess if gfortran was first it’s a D bug.
OTOH the Alias is conditional on D, but maybe Alias processing isn’t properly
language specific or, the conflict isn’t reported by the gen script …
>
> Thanks,
> Harald
>
