Follow-up patch committed, after my use of the one-argument variant of
static_assert() broke bootstrap on Solaris (sorry Rainer!).
The one-arg form is new since C23, while Solaris only supports the
two-arg form (C11).
I have confirmed that other target libraries use the two-arg form, and
Hi FX,
(We could also do something like that for a 32-bit system, but
that is another kettle of fish).
We probably wouldn’t get a speed-up that big. Even on 32-bit targets
(at least common ones), the 64-bit type and its operations (notably
division) are implemented via CPU instructions, not
Hi,
> I tested this on x86_64-pc-linux-gnu with
> make -k -j8 check-fortran RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"
> and didn't see any problems.
Thanks Thomas! Pushed.
> (We could also do something like that for a 32-bit system, but
> that is another kettle of fish).
We probably
Hi fX,
right now I don’t have a Linux system with 32-bit support. I’ll see how I can
connect to gcc45, but if someone who is already set up to do can fire a quick
regtest, that would be great;)
I tested this on x86_64-pc-linux-gnu with
make -k -j8 check-fortran
Hi Thomas,
> There are two possibilities: Either use gcc45 on the compile farm, or
> run it with
> make -k -j8 check-fortran RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"
Thanks, right now I don’t have a Linux system with 32-bit support. I’ll see how
I can connect to gcc45, but if someone who
Hi FX,
The patch has been bootstrapped and regtested on two 64-bit targets:
aarch64-apple-darwin21 (development branch) and x86_64-pc-gnu-linux. I would
like it to be tested on a 32-bit target without 128-bit integer type. Does
someone have access to that?
There are two possibilities:
Hi,
Integer output in libgfortran is done by passing values as the largest integer
type available. This is what our gfc_itoa() function for conversion to decimal
form uses, as well, performing series of divisions by 10. On targets with a
128-bit integer type (which is most targets, really,
