Re: replacing hardware?
On 4/13/23 9:43 AM, Steve Kargl via Fortran wrote: All, The systems that I've used while hacking on gfortran bugs and features are starting to show their age. I'm in the early stage of put together the wishlist for a budget friendly replacement. While I'll likely go with a Ryzen7 cpu, NVME M2 drives, and as much memory as I can afford, I'm looking for recommendations for a budget friendly video/gpu card that will allow me to take a deeper dive into openacc/openmp and offloading. Anyone have a suggestion? Note, I've mostly used FreeBSD over the last 25+ years. I suspect that pursuing offloading may be easier with a flavor linux. Any recommendation would also be appreciated. Hi Steve, If you are into building your own, I am using: https://www.gigabyte.com/Motherboard/X570-AORUS-ELITE-rev-10#kf It has plenty of sata ports and I am using a 1TB pci4 m2 drive. It supports two m2's so no problems on storage. Do get a pci4 drive, rather fast. This motherboard will support the Ryzen 5000 series chips which are rather impressive. I have a Ryzen 3600 which for me is adequate, however I have an upgrade path. I use Fedora which has all the standard tools well supported. Ubuntu is as useful, with some differences in the package manager and looks of the Gnome Desktop. (All very configurable. I just bought a cheap video card as I am not exploring the offloading. Cheers, Jerry
Re: [PATCH] Fortran: fix compile-time simplification of SET_EXPONENT [PR109511]
On Fri, Apr 14, 2023 at 09:49:22PM +0200, Harald Anlauf wrote: > > On 4/14/23 21:33, Steve Kargl via Gcc-patches wrote: > > I was wondering about the difference between set_exponent() > > and scale(), and found that set_exponent() talks about IEEE > > values while scale() doesn't. I'm wondering if we should > > add the IEEE special cases to the testsuite. Of particular > > note, I doubt that this is true: > > > > If X is an IEEE NaN, the result is the same NaN. > > > > program foo > > real x, y > > x = 1 > > y = x - x > > x = (x - x) / y > > print '(F4.0,1X,Z8.8)', x, x > > y = set_exponent(x,1) > > print '(F4.0,1X,Z8.8)', y, y > > end program foo > > > > gfcx -o z a.f90 && ./z > > NaN FFC0 > > NaN 7FC0 > > > > Those are not the same NaN. The second is a qNaN. > > The first looks like a qNaN with the sign bit set. > > Until now there was no testing at all of SET_EXPONENT in the testsuite. > It would be really good to have better coverage of compile-time and > runtime behavior of the intrinsics and checking consistency ... ;-) > > I think you have much more experience in that area. (Hint!) > I might have some experience. :-) Unfortunately, I have no time (for at least 4-5 years) to jump down that rabbit hole (as I would try to fix things ;-). However, writing testcases to exercise the intrinsic subprograms is something that the LURKERS here in the mailing list might comtemplate. Any takers? Note returning the 'same Nan" is not special to set_exponent(). At least, fraction() and rrspacing() have "If X is an IEEE NaN, the result is that NaN." Oh, and thanks for your relentless assault on bugs. -- Steve
Re: [PATCH] Fortran: fix compile-time simplification of SET_EXPONENT [PR109511]
Hi Steve, On 4/14/23 21:33, Steve Kargl via Gcc-patches wrote: On Fri, Apr 14, 2023 at 08:59:24PM +0200, Harald Anlauf via Fortran wrote: the compile-time simplification of intrinsic SET_EXPONENT was broken since the early days of gfortran for argument X < 1 (including negative X) and for I < 0. I identified and fixed several issues in the implementation. The testcase explores argument space comparing compile-time and runtime results and is checked against Intel. Regtested on x86_64-pc-linux-gnu. OK for mainline? Yes, it is certainly better than the current situation. This is not a regression, but can lead to wrong code. Would it be OK to backport to open branches? Sure. Looks simply and fairly specific. OK, thanks, will proceed. I was wondering about the difference between set_exponent() and scale(), and found that set_exponent() talks about IEEE values while scale() doesn't. I'm wondering if we should add the IEEE special cases to the testsuite. Of particular note, I doubt that this is true: If X is an IEEE NaN, the result is the same NaN. program foo real x, y x = 1 y = x - x x = (x - x) / y print '(F4.0,1X,Z8.8)', x, x y = set_exponent(x,1) print '(F4.0,1X,Z8.8)', y, y end program foo gfcx -o z a.f90 && ./z NaN FFC0 NaN 7FC0 Those are not the same NaN. The second is a qNaN. The first looks like a qNaN with the sign bit set. Until now there was no testing at all of SET_EXPONENT in the testsuite. It would be really good to have better coverage of compile-time and runtime behavior of the intrinsics and checking consistency ... ;-) I think you have much more experience in that area. (Hint!) Cheers, Harald
Re: [PATCH] Fortran: fix compile-time simplification of SET_EXPONENT [PR109511]
On Fri, Apr 14, 2023 at 12:33:18PM -0700, Steve Kargl via Fortran wrote: > >If X is an IEEE NaN, the result is the same NaN. > A better testcase as gfortran will quiet a NaN on assignment. program foo integer i equivalence(i,y) i = int(z'7FC0BEEF',4) ! Add payload to NaN. print '(F4.0,2(1X,Z8.8))', y, y, set_exponent(y,1) end program foo gfortran -o z a.f90 && ./z N 7FC0BEEF 7FC0 -- Steve
Re: [PATCH] Fortran: fix compile-time simplification of SET_EXPONENT [PR109511]
On Fri, Apr 14, 2023 at 08:59:24PM +0200, Harald Anlauf via Fortran wrote: > > the compile-time simplification of intrinsic SET_EXPONENT was > broken since the early days of gfortran for argument X < 1 > (including negative X) and for I < 0. I identified and fixed > several issues in the implementation. The testcase explores > argument space comparing compile-time and runtime results and > is checked against Intel. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Yes, it is certainly better than the current situation. > This is not a regression, but can lead to wrong code. > Would it be OK to backport to open branches? Sure. Looks simply and fairly specific. I was wondering about the difference between set_exponent() and scale(), and found that set_exponent() talks about IEEE values while scale() doesn't. I'm wondering if we should add the IEEE special cases to the testsuite. Of particular note, I doubt that this is true: If X is an IEEE NaN, the result is the same NaN. program foo real x, y x = 1 y = x - x x = (x - x) / y print '(F4.0,1X,Z8.8)', x, x y = set_exponent(x,1) print '(F4.0,1X,Z8.8)', y, y end program foo gfcx -o z a.f90 && ./z NaN FFC0 NaN 7FC0 Those are not the same NaN. The second is a qNaN. The first looks like a qNaN with the sign bit set. -- Steve
[PATCH] Fortran: fix compile-time simplification of SET_EXPONENT [PR109511]
[Now with subject added...]
Dear all,
the compile-time simplification of intrinsic SET_EXPONENT was
broken since the early days of gfortran for argument X < 1
(including negative X) and for I < 0. I identified and fixed
several issues in the implementation. The testcase explores
argument space comparing compile-time and runtime results and
is checked against Intel.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
This is not a regression, but can lead to wrong code.
Would it be OK to backport to open branches?
Thanks,
Harald
From fa4cb42870df60debdbd51e2ddc6d6ab9e6a Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 14 Apr 2023 20:45:19 +0200
Subject: [PATCH] Fortran: fix compile-time simplification of SET_EXPONENT
[PR109511]
gcc/fortran/ChangeLog:
PR fortran/109511
* simplify.cc (gfc_simplify_set_exponent): Fix implementation of
compile-time simplification of intrinsic SET_EXPONENT for argument
X < 1 and for I < 0.
gcc/testsuite/ChangeLog:
PR fortran/109511
* gfortran.dg/set_exponent_1.f90: New test.
---
gcc/fortran/simplify.cc | 12 +++
gcc/testsuite/gfortran.dg/set_exponent_1.f90 | 36
2 files changed, 42 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/set_exponent_1.f90
diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index ecf0e3558df..b65854c1021 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -7364,7 +7364,7 @@ gfc_simplify_set_exponent (gfc_expr *x, gfc_expr *i)
{
gfc_expr *result;
mpfr_t exp, absv, log2, pow2, frac;
- unsigned long exp2;
+ long exp2;
if (x->expr_type != EXPR_CONSTANT || i->expr_type != EXPR_CONSTANT)
return NULL;
@@ -7396,19 +7396,19 @@ gfc_simplify_set_exponent (gfc_expr *x, gfc_expr *i)
mpfr_abs (absv, x->value.real, GFC_RND_MODE);
mpfr_log2 (log2, absv, GFC_RND_MODE);
- mpfr_trunc (log2, log2);
+ mpfr_floor (log2, log2);
mpfr_add_ui (exp, log2, 1, GFC_RND_MODE);
/* Old exponent value, and fraction. */
mpfr_ui_pow (pow2, 2, exp, GFC_RND_MODE);
- mpfr_div (frac, absv, pow2, GFC_RND_MODE);
+ mpfr_div (frac, x->value.real, pow2, GFC_RND_MODE);
/* New exponent. */
- exp2 = (unsigned long) mpz_get_d (i->value.integer);
- mpfr_mul_2exp (result->value.real, frac, exp2, GFC_RND_MODE);
+ exp2 = mpz_get_si (i->value.integer);
+ mpfr_mul_2si (result->value.real, frac, exp2, GFC_RND_MODE);
- mpfr_clears (absv, log2, pow2, frac, NULL);
+ mpfr_clears (absv, log2, exp, pow2, frac, NULL);
return range_check (result, "SET_EXPONENT");
}
diff --git a/gcc/testsuite/gfortran.dg/set_exponent_1.f90 b/gcc/testsuite/gfortran.dg/set_exponent_1.f90
new file mode 100644
index 000..4c063e8330b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/set_exponent_1.f90
@@ -0,0 +1,36 @@
+! { dg-do run }
+! PR fortran/109511
+! Check compile-time simplification of SET_EXPONENT against runtime
+
+program exponent
+ implicit none
+ integer :: i
+ i = 0
+ print *, i, set_exponent(1., 0), set_exponent(1., i)
+ if (set_exponent(1., 0) /= set_exponent(1., i)) stop 1
+ i = 1
+ print *, i, set_exponent(1., 1), set_exponent(1., i)
+ if (set_exponent(1., 1) /= set_exponent(1., i)) stop 2
+ i = 2
+ print *, i, set_exponent(-1.75, 2), set_exponent(-1.75, i)
+ if (set_exponent(-1.75, 2) /= set_exponent(-1.75, i)) stop 3
+ print *, i, set_exponent(0.1875, 2), set_exponent(0.1875, i)
+ if (set_exponent(0.1875, 2) /= set_exponent(0.1875, i)) stop 4
+ i = 3
+ print *, i, set_exponent(0.75, 3), set_exponent(0.75, i)
+ if (set_exponent(0.75, 3) /= set_exponent(0.75, i)) stop 5
+ i = 4
+ print *, i, set_exponent(-2.5, 4), set_exponent(-2.5, i)
+ if (set_exponent(-2.5, 4) /= set_exponent(-2.5, i)) stop 6
+ i = -1
+ print *, i, set_exponent(1., -1), set_exponent(1., i)
+ if (set_exponent(1., -1) /= set_exponent(1., i)) stop 7
+ i = -2
+ print *, i, set_exponent(1.125, -2), set_exponent(1.125, i)
+ if (set_exponent(1.125, -2) /= set_exponent(1.125, i)) stop 8
+ print *, i, set_exponent(-0.25, -2), set_exponent(-0.25, i)
+ if (set_exponent(-0.25, -2) /= set_exponent(-0.25, i)) stop 9
+ i = -3
+ print *, i, set_exponent(0.75, -3), set_exponent(0.75, i)
+ if (set_exponent(0.75, -3) /= set_exponent(0.75, i)) stop 10
+end program exponent
--
2.35.3
[no subject]
Dear all,
the compile-time simplification of intrinsic SET_EXPONENT was
broken since the early days of gfortran for argument X < 1
(including negative X) and for I < 0. I identified and fixed
several issues in the implementation. The testcase explores
argument space comparing compile-time and runtime results and
is checked against Intel.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
This is not a regression, but can lead to wrong code.
Would it be OK to backport to open branches?
Thanks,
Harald
From fa4cb42870df60debdbd51e2ddc6d6ab9e6a Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 14 Apr 2023 20:45:19 +0200
Subject: [PATCH] Fortran: fix compile-time simplification of SET_EXPONENT
[PR109511]
gcc/fortran/ChangeLog:
PR fortran/109511
* simplify.cc (gfc_simplify_set_exponent): Fix implementation of
compile-time simplification of intrinsic SET_EXPONENT for argument
X < 1 and for I < 0.
gcc/testsuite/ChangeLog:
PR fortran/109511
* gfortran.dg/set_exponent_1.f90: New test.
---
gcc/fortran/simplify.cc | 12 +++
gcc/testsuite/gfortran.dg/set_exponent_1.f90 | 36
2 files changed, 42 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/set_exponent_1.f90
diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index ecf0e3558df..b65854c1021 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -7364,7 +7364,7 @@ gfc_simplify_set_exponent (gfc_expr *x, gfc_expr *i)
{
gfc_expr *result;
mpfr_t exp, absv, log2, pow2, frac;
- unsigned long exp2;
+ long exp2;
if (x->expr_type != EXPR_CONSTANT || i->expr_type != EXPR_CONSTANT)
return NULL;
@@ -7396,19 +7396,19 @@ gfc_simplify_set_exponent (gfc_expr *x, gfc_expr *i)
mpfr_abs (absv, x->value.real, GFC_RND_MODE);
mpfr_log2 (log2, absv, GFC_RND_MODE);
- mpfr_trunc (log2, log2);
+ mpfr_floor (log2, log2);
mpfr_add_ui (exp, log2, 1, GFC_RND_MODE);
/* Old exponent value, and fraction. */
mpfr_ui_pow (pow2, 2, exp, GFC_RND_MODE);
- mpfr_div (frac, absv, pow2, GFC_RND_MODE);
+ mpfr_div (frac, x->value.real, pow2, GFC_RND_MODE);
/* New exponent. */
- exp2 = (unsigned long) mpz_get_d (i->value.integer);
- mpfr_mul_2exp (result->value.real, frac, exp2, GFC_RND_MODE);
+ exp2 = mpz_get_si (i->value.integer);
+ mpfr_mul_2si (result->value.real, frac, exp2, GFC_RND_MODE);
- mpfr_clears (absv, log2, pow2, frac, NULL);
+ mpfr_clears (absv, log2, exp, pow2, frac, NULL);
return range_check (result, "SET_EXPONENT");
}
diff --git a/gcc/testsuite/gfortran.dg/set_exponent_1.f90 b/gcc/testsuite/gfortran.dg/set_exponent_1.f90
new file mode 100644
index 000..4c063e8330b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/set_exponent_1.f90
@@ -0,0 +1,36 @@
+! { dg-do run }
+! PR fortran/109511
+! Check compile-time simplification of SET_EXPONENT against runtime
+
+program exponent
+ implicit none
+ integer :: i
+ i = 0
+ print *, i, set_exponent(1., 0), set_exponent(1., i)
+ if (set_exponent(1., 0) /= set_exponent(1., i)) stop 1
+ i = 1
+ print *, i, set_exponent(1., 1), set_exponent(1., i)
+ if (set_exponent(1., 1) /= set_exponent(1., i)) stop 2
+ i = 2
+ print *, i, set_exponent(-1.75, 2), set_exponent(-1.75, i)
+ if (set_exponent(-1.75, 2) /= set_exponent(-1.75, i)) stop 3
+ print *, i, set_exponent(0.1875, 2), set_exponent(0.1875, i)
+ if (set_exponent(0.1875, 2) /= set_exponent(0.1875, i)) stop 4
+ i = 3
+ print *, i, set_exponent(0.75, 3), set_exponent(0.75, i)
+ if (set_exponent(0.75, 3) /= set_exponent(0.75, i)) stop 5
+ i = 4
+ print *, i, set_exponent(-2.5, 4), set_exponent(-2.5, i)
+ if (set_exponent(-2.5, 4) /= set_exponent(-2.5, i)) stop 6
+ i = -1
+ print *, i, set_exponent(1., -1), set_exponent(1., i)
+ if (set_exponent(1., -1) /= set_exponent(1., i)) stop 7
+ i = -2
+ print *, i, set_exponent(1.125, -2), set_exponent(1.125, i)
+ if (set_exponent(1.125, -2) /= set_exponent(1.125, i)) stop 8
+ print *, i, set_exponent(-0.25, -2), set_exponent(-0.25, i)
+ if (set_exponent(-0.25, -2) /= set_exponent(-0.25, i)) stop 9
+ i = -3
+ print *, i, set_exponent(0.75, -3), set_exponent(0.75, i)
+ if (set_exponent(0.75, -3) /= set_exponent(0.75, i)) stop 10
+end program exponent
--
2.35.3
Re: [Patch, fortran] PR109451 - ICE in gfc_conv_expr_descriptor with ASSOCIATE and substrings
Hi Paul, On 4/14/23 10:18, Paul Richard Thomas via Gcc-patches wrote: Hi Harald, The fix was trivial. An updated patch and testcase are attached. great, this works, and I couldn't break it again this time ... Looks good! Thanks, Harald Thanks Paul Fortran: Fix some deferred character problems in associate [PR109451] 2023-04-14 Paul Thomas gcc/fortran PR fortran/109451 * trans-array.cc (gfc_conv_expr_descriptor): Guard expression character length backend decl before using it. Suppress the assignment if lhs equals rhs. * trans-io.cc (gfc_trans_transfer): Scalarize transfer of associate variables pointing to a variable. Add comment. * trans-stmt.cc (trans_associate_var): Remove requirement that the character length be deferred before assigning the value returned by gfc_conv_expr_descriptor. Also, guard the backend decl before testing with VAR_P. gcc/testsuite/ PR fortran/109451 * gfortran.dg/associate_61.f90 : New test On Thu, 13 Apr 2023 at 07:18, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: Hi Harald, That's interesting - the string length '.q' is not set for either of the associate blocks. I'm onto it. Thanks Paul On Wed, 12 Apr 2023 at 20:26, Harald Anlauf wrote: Hi Paul, On 4/12/23 17:25, Paul Richard Thomas via Gcc-patches wrote: Hi All, I think that the changelog says it all. OK for mainline? this looks almost fine, but still fails if one directly uses the dummy argument as the ASSOCIATE target, as in: program p implicit none character(4) :: c(2) = ["abcd","efgh"] call dcs0 (c) ! call dcs0 (["abcd","efgh"]) contains subroutine dcs0(a) character(len=*), intent(in) :: a(:) print *, size(a),len(a) associate (q => a(:)) print *, size(q),len(q) end associate associate (q => a(:)(:)) print *, size(q),len(q) end associate return end subroutine dcs0 end This prints e.g. 2 4 2 0 2 0 (sometimes I also get junk values for the character length). Can you please have another look? Thanks, Harald Paul Fortran: Fix some deferred character problems in associate [PR109451] 2023-04-07 Paul Thomas gcc/fortran PR fortran/109451 * trans-array.cc (gfc_conv_expr_descriptor): Guard expression character length backend decl before using it. Suppress the assignment if lhs equals rhs. * trans-io.cc (gfc_trans_transfer): Scalarize transfer of associate variables pointing to a variable. Add comment. gcc/testsuite/ PR fortran/109451 * gfortran.dg/associate_61.f90 : New test -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: replacing hardware?
If you wan raw horsepower on a "working man's" wage, get one of these. https://www.ebay.com/itm/383809689955?hash=item595cd71963:g:6NAAAOSwg4JhCKuJ=enc%3AAQAIwOngs27VAqvfureMtmK3O3TxUN8Opb7KbjeXhpl96DaDi%2BpSMCspc40m34f7wzlxF%2BX45dfQ8gIXlzjf6fMo7fQ%2Bd%2FLFVgwFRORxnAcRFKjjheHahPafOROUjs7yGNHpAM2hsg5JH6vcvU9mA9yyIoBFMIlEZELhAZ34xCCpMCvsEgzA73XBFddWtfV7FqHGXWrOsvP0B5WmRmCrODzhkH0msX1XB%2FXxf3fDYIxPcDITg7colOPlaNo93ATw2VhZYA%3D%3D%7Ctkp%3ABk9SR9TglPvvYQ They are mighty slow from a cold boot verifying all of their firmware, but they scream. Put at least a 6TB WD Black for your "work" drive, use SSD only for boot. I have one of these I use for Yocto builds. I can give a Ubuntu VM 16-core and 90GB of RAM. With the virtual drive on the WD Black, a complete Linux from scratch build for an embedded system is under 3.5 hours. If you only need a few core CUDA core, a pair of these will cost you well under $50 https://www.ebay.com/itm/364218004301?_trkparms=amclksrc%3DITM%26aid%3D1110006%26algo%3DHOMESPLICE.SIM%26ao%3D1%26asc%3D20220920135554%26meid%3D490d57d5aabe4457afe337f1c6aa1605%26pid%3D101197%26rk%3D4%26rkt%3D12%26sd%3D295380047025%26itm%3D364218004301%26pmt%3D1%26noa%3D0%26pg%3D2047675%26algv%3DSimplAMLv9PairwiseWebMskuAspectsV202110NoVariantSeedKnnRecallV1%26brand%3DNVIDIA&_trksid=p2047675.c101197.m1850=cksum%3A364218004301490d57d5aabe4457afe337f1c6aa1605%7Cenc%3AAQAIAAABIJiyRA3UZOlY17tF8AfiSuRQhHC9c8zdhSad9rXZnwgXvfF0F0w2wQB9U6A4KFPHsgpqramMJ0IucFGCD0JT%252BF35flAQd1p2pgAxUhPkACs7fyGCi2Kmkbkap7sEf29z4T1tcYqHIgSzdNOG1MOYulEWTDyKPdEGX1ZD3Y5YmtSvdJWTbnODktzI%252FOxgP1OvnvyjHiiOxLs6eKwjAxkQlGxpfmagbcVGZqZakRV0q7if3tQ8o2Skrg7JazTvTE3pSz2LVaj28KYa5f2U46xzSarOdrR6T8k2GFHYUX8gtiy6cvg2qUOCFtImZL%252FTu24tLizEjk2gDzTx%252BTZIhA9hD%252BDk0OhzGYqFhPpHyO7ZiHjjCzmifYiIFcAFCdQoLVrL%252Fw%253D%253D%7Campid%3APL_CLK%7Cclp%3A2047675 I stuck a P600 in mine to get 384 CUDA core for well under $100 https://www.ebay.com/itm/255787052523 If that class of machine is too far past "hobby" for you, (can there really be such a thing???) then I recommend one of these. https://www.ebay.com/itm/125606569756 Again, get yourself a WD Black spinning disk of at least 4TB to be your "work" disk. Use your M2 only for the boot OS. I loaded Manjaro on mine with an M2 black 1TB drive and a WD Black 6TB spinning disk. I also installed an NVS 310 and the slim DVD RW. For around $600 you can have a machine that boots instantly and runs great. On the Z820 I run Windows 10 and lots of different Linux distros in VMs. On the z2 G4, I run Manjaro Cinnamon Linux. That's an Arch based Linux, but an almost user friendly one. For those just getting their feet wet with a desktop Linux I recommend the current Ubuntu LTS release, not because it is good, but because when you search on the Internet the first help pages for how to do something will invariably use Ubuntu. Arch doesn't use Debian packaging. Beginners should avoid RPM based distros at all costs. Waaay too many "We do it this way and don't care what the known universe has chosen to do" situations for a beginner. Just my 0.002 cents. On 4/14/2023 3:18 AM, fortran-requ...@gcc.gnu.org wrote: replacing hardware? (Steve Kargl) -- Roland Hughes, President Logikal Solutions (630)-205-1593 (cell) http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com
[Bug fortran/104272] finalizer gets called during allocate
Hi Harald, Committed with the coding error that you spotted put right. commit r13-7181-gb0e85485fbf042abccee5c0a9eb499da386c8db3 I will build up a composite finalization patch for 12-branch in the coming days. However, I still have one of Andrew Benson's bugs to put right before I do that. Regards Paul
Re: replacing hardware?
On Fri, Apr 14, 2023 at 1:40 AM Richard Biener via Fortran wrote: > > On Thu, Apr 13, 2023 at 6:43 PM Steve Kargl via Fortran > wrote: > > > > All, > > > > The systems that I've used while hacking on gfortran > > bugs and features are starting to show their age. I'm > > in the early stage of put together the wishlist for > > a budget friendly replacement. While I'll likely go > > with a Ryzen7 cpu, NVME M2 drives, and as much memory > > as I can afford, I'm looking for recommendations for > > a budget friendly video/gpu card that will allow me to > > take a deeper dive into openacc/openmp and offloading. > > Anyone have a suggestion? > > I am sofar doing "functional level" testing of offloading with > a GTX 1650 which is I think the most affordable thing you > can still get. Not sure how future proof this will be though > with future support from NVIDIA (you still need CUDA for > offloading). I have not yet had success with any consumer > AMD graphics product, the gcn backend requires > the radeon instinct compute cards. > > So I suppose any "cheap" nvidia will do, of course > performance wise it will suck (esp. when doing FP64 - also > watch out if they eventually disable that completely on > some consumer card generations) > > That's problematic as Nvidia's support for open source is at best spotty and if you're doing something a tiny bit out of 'usual' - - - - terrible. My previous system I started using 3 - 570 nvidia gpus and when 2 failed some 8 years i I replaced them using only 1 - 1650 Ti. My issue was that I wanted to using a HDMI monitor as part of my group - - - - - the results were a system that would need a restart every 2 weeks and it was a royal PITA with the nuisance. My present system is quite more reliable but today's browsers are now also increasing the issues - - - - argh! HTH
Re: [Patch, fortran] PR109451 - ICE in gfc_conv_expr_descriptor with ASSOCIATE and substrings
Hi Harald,
The fix was trivial. An updated patch and testcase are attached.
Thanks
Paul
Fortran: Fix some deferred character problems in associate [PR109451]
2023-04-14 Paul Thomas
gcc/fortran
PR fortran/109451
* trans-array.cc (gfc_conv_expr_descriptor): Guard expression
character length backend decl before using it. Suppress the
assignment if lhs equals rhs.
* trans-io.cc (gfc_trans_transfer): Scalarize transfer of
associate variables pointing to a variable. Add comment.
* trans-stmt.cc (trans_associate_var): Remove requirement that
the character length be deferred before assigning the value
returned by gfc_conv_expr_descriptor. Also, guard the backend
decl before testing with VAR_P.
gcc/testsuite/
PR fortran/109451
* gfortran.dg/associate_61.f90 : New test
On Thu, 13 Apr 2023 at 07:18, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Harald,
>
> That's interesting - the string length '.q' is not set for either of the
> associate blocks. I'm onto it.
>
> Thanks
>
> Paul
>
>
> On Wed, 12 Apr 2023 at 20:26, Harald Anlauf wrote:
>
>> Hi Paul,
>>
>> On 4/12/23 17:25, Paul Richard Thomas via Gcc-patches wrote:
>> > Hi All,
>> >
>> > I think that the changelog says it all. OK for mainline?
>>
>> this looks almost fine, but still fails if one directly uses the
>> dummy argument as the ASSOCIATE target, as in:
>>
>> program p
>>implicit none
>>character(4) :: c(2) = ["abcd","efgh"]
>>call dcs0 (c)
>> ! call dcs0 (["abcd","efgh"])
>> contains
>>subroutine dcs0(a)
>> character(len=*), intent(in) :: a(:)
>> print *, size(a),len(a)
>> associate (q => a(:))
>>print *, size(q),len(q)
>> end associate
>> associate (q => a(:)(:))
>>print *, size(q),len(q)
>> end associate
>> return
>>end subroutine dcs0
>> end
>>
>> This prints e.g.
>>
>> 2 4
>> 2 0
>> 2 0
>>
>> (sometimes I also get junk values for the character length).
>>
>> Can you please have another look?
>>
>> Thanks,
>> Harald
>>
>>
>> > Paul
>> >
>> > Fortran: Fix some deferred character problems in associate [PR109451]
>> >
>> > 2023-04-07 Paul Thomas
>> >
>> > gcc/fortran
>> > PR fortran/109451
>> > * trans-array.cc (gfc_conv_expr_descriptor): Guard expression
>> > character length backend decl before using it. Suppress the
>> > assignment if lhs equals rhs.
>> > * trans-io.cc (gfc_trans_transfer): Scalarize transfer of
>> > associate variables pointing to a variable. Add comment.
>> >
>> >
>> > gcc/testsuite/
>> > PR fortran/109451
>> > * gfortran.dg/associate_61.f90 : New test
>>
>>
>
> --
> "If you can't explain it simply, you don't understand it well enough" -
> Albert Einstein
>
--
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index e1725808033..7c0bcfe5cbb 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -7934,8 +7934,12 @@ gfc_conv_expr_descriptor (gfc_se *se, gfc_expr *expr)
else
tmp = se->string_length;
- if (expr->ts.deferred && VAR_P (expr->ts.u.cl->backend_decl))
- gfc_add_modify (>pre, expr->ts.u.cl->backend_decl, tmp);
+ if (expr->ts.deferred && expr->ts.u.cl->backend_decl
+ && VAR_P (expr->ts.u.cl->backend_decl))
+ {
+ if (expr->ts.u.cl->backend_decl != tmp)
+ gfc_add_modify (>pre, expr->ts.u.cl->backend_decl, tmp);
+ }
else
expr->ts.u.cl->backend_decl = tmp;
}
@@ -7998,7 +8002,13 @@ gfc_conv_expr_descriptor (gfc_se *se, gfc_expr *expr)
}
}
}
-
+ if (expr->ts.type == BT_CHARACTER
+ && VAR_P (TYPE_SIZE_UNIT (gfc_get_element_type (TREE_TYPE (parm)
+ {
+ tree elem_len = TYPE_SIZE_UNIT (gfc_get_element_type (TREE_TYPE (parm)));
+ gfc_add_modify (, elem_len,
+ fold_convert (TREE_TYPE (elem_len), gfc_get_array_span (desc, expr)));
+ }
/* Set the span field. */
tmp = NULL_TREE;
if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (desc)))
diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc
index 9b54d2f0d31..67658769b9e 100644
--- a/gcc/fortran/trans-io.cc
+++ b/gcc/fortran/trans-io.cc
@@ -2620,9 +2620,13 @@ gfc_trans_transfer (gfc_code * code)
gcc_assert (ref && ref->type == REF_ARRAY);
}
+ /* These expressions don't always have the dtype element length set
+ correctly, rendering them useless for array transfer. */
if (expr->ts.type != BT_CLASS
&& expr->expr_type == EXPR_VARIABLE
&& ((expr->symtree->n.sym->ts.type == BT_DERIVED && expr->ts.deferred)
+ || (expr->symtree->n.sym->assoc
+ && expr->symtree->n.sym->assoc->variable)
|| gfc_expr_attr (expr).pointer))
goto scalarize;
diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
index f78875455a5..a1d8a26f64f 100644
--- a/gcc/fortran/trans-stmt.cc
+++ b/gcc/fortran/trans-stmt.cc
@@ -1930,15 +1930,13 @@ trans_associate_var
Re: replacing hardware?
On Thu, Apr 13, 2023 at 6:43 PM Steve Kargl via Fortran wrote: > > All, > > The systems that I've used while hacking on gfortran > bugs and features are starting to show their age. I'm > in the early stage of put together the wishlist for > a budget friendly replacement. While I'll likely go > with a Ryzen7 cpu, NVME M2 drives, and as much memory > as I can afford, I'm looking for recommendations for > a budget friendly video/gpu card that will allow me to > take a deeper dive into openacc/openmp and offloading. > Anyone have a suggestion? I am sofar doing "functional level" testing of offloading with a GTX 1650 which is I think the most affordable thing you can still get. Not sure how future proof this will be though with future support from NVIDIA (you still need CUDA for offloading). I have not yet had success with any consumer AMD graphics product, the gcn backend requires the radeon instinct compute cards. So I suppose any "cheap" nvidia will do, of course performance wise it will suck (esp. when doing FP64 - also watch out if they eventually disable that completely on some consumer card generations) Richard. > Note, I've mostly used FreeBSD over the last 25+ years. > I suspect that pursuing offloading may be easier with > a flavor linux. Any recommendation would also be > appreciated. > > -- > Steve
