Thomas, Steve,
thanks for the swift feedback!
Am 10.01.25 um 23:57 schrieb Thomas Koenig:
Hello Harald,
Regtested on x86_64-pc-linux-gnu. OK for mainline?
I just started to run a bootstrap on cfarm120 (because it is
the only machine I can lay my hands on where I can run
"make -j128" withou
On Fri, Jan 10, 2025 at 05:19:34PM +, Paul Richard Thomas wrote:
>
> As of today, Gerhard Steinmetz has no fewer than 33 regressions to his name
> out of a total of 54 for fortran and libgfortran. It's time that some of
> these bugs are swatted, I think :-)
>
PR 70949 appears to have been fi
On Fri, Jan 10, 2025 at 05:19:34PM +, Paul Richard Thomas wrote:
>
> As of today, Gerhard Steinmetz has no fewer than 33 regressions to his name
> out of a total of 54 for fortran and libgfortran. It's time that some of
> these bugs are swatted, I think :-)
>
This patch fixes PR71844. As th
On Fri, Jan 10, 2025 at 09:41:13PM +, Harald Anlauf wrote:
>
> There is one question to the reviewer(s), or those knowing better
> than me how to handle IEEE infinity and NaN: with -Ofast, I needed
> to add "-fno-finite-math-only" to the new testcase
> gfortran.dg/ieee/out_of_range.f90, as the
Hello Harald,
Regtested on x86_64-pc-linux-gnu. OK for mainline?
I just started to run a bootstrap on cfarm120 (because it is
the only machine I can lay my hands on where I can run
"make -j128" without disturbing anybody :-) and I got
../../trunk/gcc/fortran/trans-intrinsic.cc: In function ‘
Dear all,
the attached patch is supposed to be a complete implementation of
the F2018 intrinsic OUT_OF_RANGE. This is mostly straightforward,
with runtime code fully expanded inline. It is also extended to
support the new UNSIGNED type of gfortran as of current 15-mainline.
The testcases are cr
On Fri, Jan 10, 2025 at 05:19:34PM +, Paul Richard Thomas wrote:
>
> As of today, Gerhard Steinmetz has no fewer than 33 regressions to his name
> out of a total of 54 for fortran and libgfortran. It's time that some of
> these bugs are swatted, I think :-)
>
When I was much more active in a
On 1/10/25 9:19 AM, Paul Richard Thomas wrote:
Hi Harald, hi all,
As of today, Gerhard Steinmetz has no fewer than 33 regressions to his
name out of a total of 54 for fortran and libgfortran. It's time that
some of these bugs are swatted, I think :-)
As well as this PR, 106946 seems to have
Hi Thomas,
Thomas Koenig wrote:
Comments, remarks, suggestions?
I assume you regression-tested (you didn't say).
Yes, it was build with a bootstrapping configuration (with a
non-offloading compiler, but it shouldn't matter here) on
x86_64-gnu-linux and I did run "make check-fortran" in the
m
Hi Harald, hi all,
As of today, Gerhard Steinmetz has no fewer than 33 regressions to his name
out of a total of 54 for fortran and libgfortran. It's time that some of
these bugs are swatted, I think :-)
As well as this PR, 106946 seems to have fixed itself and I have fixes for
102333 and 96087 w
Hi Tobias,
Comments, remarks, suggestions?
I assume you regression-tested (you didn't say).
Otherwise, I regard the common Fortran code as obvious - and
the OpenMP part covered by my (co)maintainership.
Regarding the Fortran part:
- fndecl = build_decl (input_location,
+ fndecl = build_
The first change is a simple, generic Fortran change.
Without it, external declarations have odd locations
(namely their input_location):
gcc/testsuite/gfortran.dg/gomp/dispatch-11.f90:67:46:
67 | !$omp dispatch interop(obj2, obj1) device(3)
|
12 matches
Mail list logo
