Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic
Thank you for responding. I have added a changelog (is this a correct way?). Sergey On Wed, Aug 14, 2024 at 12:58 AM FX Coudert wrote: > Hi, > > > I dropped a change to the test file, since you have fixed it > appropriately, and switched to Apple libm convention for flags, as you have > suggested. > > Please let me know if I should do anything further to improve it and > make it acceptable for a merge. > > The patch itself is OK. Please add a ChangeLog entry fitting the GCC > format (see prior commits in libgfortran/ for examples). > > FX 0001-libgfortran-implement-fpu-macppc-for-Darwin-support-.patch Description: Binary data
Re: [Fortran, Patch, PR116292, v1] Fix 15-regression in move_alloc
Hi Thomas, thanks for the review. Committed as gcc-15-2910-gbb2324769c5 Thanks again, Andre On Tue, 13 Aug 2024 13:34:44 +0200 Thomas Koenig wrote: > Hi Andre, > > > attached patch fixes a regression introduced by my previous patch on > > handling _vptr's more consistently. The patch gets the _vptr only of a > > derived or class type now and not of every type. > > > > Regression tested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? > > OK (and looks obvious, too). > > Best regards > > Thomas > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Fortran, Patch, PR102973, v1] Reset flag for parsing proc_ptrs in associate in error case
Hi Harald, thanks for the review. Comitted as gcc-15-2911-g54be14bfd6e. Do you have time for reviewing the pr110033 fix? See here: https://gcc.gnu.org/pipermail/fortran/2024-August/060814.html Yes, it looks lengthy, but it is always the same propagation of the corank and bit of meat in the second part of the patch. This would then allow to get the dependencies of the ASSOCIATE-PR to zero. Thanks again and regards, Andre On Tue, 13 Aug 2024 18:29:31 +0200 Harald Anlauf wrote: > Hi Andre, > > Am 13.08.24 um 15:15 schrieb Andre Vehreschild: > > Hi all, > > > > attached patch is the last one the meta-bug 87477 ASSOCIATE depends on. The > > resolution was already given in the PR, so I just beautified it and made > > patch for it. I tried to come up with a testcase as well as Harald has, but > > had no luck with it. I see less harm in reseting the flag in the error case > > than not to do it. > > this is much simpler than Berhhard's patch while functionally equivalent > and good for mainline. > > Thanks for taking care of the issue! > > Harald > > > Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? > > > > Regards, > > Andre > > -- > > Andre Vehreschild * Email: vehre ad gmx dot de > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [patch, fortran] First part of Fortran's unsigned implementation
Hi Thomas, > > may I ask you to run contrib/check_GNU_style.py on your patch? At least on > > my system more than lines 50 are reported. I am drawn to this style issues > > and find it hard to digest the beef of the patch. That's my personal OCD > > unfortunately. > > I did so, and fixed most of what it complained about. Not all - I will > not "fix" Fortran code or things like UNSIGNED(4) in error messages :-) Well, in Fortran would be futile. No, I found some `a,a` in parameter lists on several occasions, e.g. in arith.cc function gfc_arith_init_1 (void) near the end of the function. I.e. no space after the comma. That was the background of my question. Thanks for the adaptions. - Andre -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Fortran, Patch, PR110033, v1] Fix associate for coarrays
Hi Andre, >From a very rapid scan(in the style of somebody on vacation :-) ) of the two patches, it all looks good to me. Adding the corank structure to gfc_expr is long overdue. Thanks also for rolling select type into the second patch. It would be good if you would check if PRs 46371 and 56496 are fixed by the patch. Regards Paul On Mon, 12 Aug 2024 at 13:11, Andre Vehreschild wrote: > Hi all, > > the attached two patches fix ASSOCIATE for coarrays, i.e. that a coarray > associated to a variable is also a coarray in the block of the ASSOCIATE > command. The patch has two parts: > > 1. pr110033p1_1.patch: Adds a corank member to the gfc_expr structure. I > decided to add it here and keep track of the corank of an expression, > because > calling gfc_get_corank was getting to expensive with the associate patch. > This > patch also improves the usage of coarrays in select type/rank constructs. > > 2. pr110033p2_1.patch: The changes and testcase for PR 110033. In essence > the > coarray is not detected correctly on the expression to associate to and > therefore not propagated correctly into the block of the ASSOCIATE > command. The > patch adds correct treatment for propagating the coarray token into the > block, > too. > > The costs of tracking the corank along side to the rank of an expression > are > about 30 seconds real user time (i.e. time's "real" row) on a rather old > Intel > i7-5775C@3.3GHz with 24G RAM that was used for work during the test. If > need be > I can tuned that more. > > Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? > > Regards, > Andre > -- > Andre Vehreschild * Email: vehre ad gmx dot de >
Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic
> Thank you for responding. > I have added a changelog (is this a correct way?). Content seems ok, lines are maybe too long. Check with contrib/gcc-changelog/git_check_commit.py before pushing. Once that is fine, OK to push. FX
Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic
On Wed, Aug 14, 2024 at 8:03 PM FX Coudert wrote: > > Thank you for responding. > > I have added a changelog (is this a correct way?). > > Content seems ok, lines are maybe too long. Check with > contrib/gcc-changelog/git_check_commit.py before pushing. > Once that is fine, OK to push. > Looks like the script is okay with formatting: 36-25% /opt/local/bin/python3.11 /Users/svacchanda/Github_barracuda156/gcc-git/contrib/gcc-changelog/git_check_commit.py Checking 16e8ea376ada59306583decf1a218b2281a48638: OK Sergey
Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic
> On 14 Aug 2024, at 13:17, Sergey Fedorov wrote: > > > > On Wed, Aug 14, 2024 at 8:03 PM FX Coudert wrote: > > Thank you for responding. > > I have added a changelog (is this a correct way?). > > Content seems ok, lines are maybe too long. Check with > contrib/gcc-changelog/git_check_commit.py before pushing. > Once that is fine, OK to push. > > Looks like the script is okay with formatting: > > 36-25% /opt/local/bin/python3.11 > /Users/svacchanda/Github_barracuda156/gcc-git/contrib/gcc-changelog/git_check_commit.py > > Checking 16e8ea376ada59306583decf1a218b2281a48638: OK * config/fpu-macppc.h (new file): initial support for powerpc-darwin. * configure.host: enable ieee_support for powerpc-darwin case, set fpu_host='fpu-macppc’. The description lines should begin with a capital letter and the lines should not exceed 80 chars (some people prefer if they do not exceed 76 chars so that “git show” output fits into 80 columns). hth Iain > > Sergey >
Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic
Thank you, Iain. I have adjusted a longer line and added an intro sentence before changelog record. On Wed, Aug 14, 2024 at 8:24 PM Iain Sandoe wrote: > > > > On 14 Aug 2024, at 13:17, Sergey Fedorov wrote: > > > > > > > > On Wed, Aug 14, 2024 at 8:03 PM FX Coudert wrote: > > > Thank you for responding. > > > I have added a changelog (is this a correct way?). > > > > Content seems ok, lines are maybe too long. Check with > contrib/gcc-changelog/git_check_commit.py before pushing. > > Once that is fine, OK to push. > > > > Looks like the script is okay with formatting: > > > > 36-25% /opt/local/bin/python3.11 > /Users/svacchanda/Github_barracuda156/gcc-git/contrib/gcc-changelog/git_check_commit.py > > > Checking 16e8ea376ada59306583decf1a218b2281a48638: OK > > * config/fpu-macppc.h (new file): initial support for > powerpc-darwin. > * configure.host: enable ieee_support for powerpc-darwin case, set > fpu_host='fpu-macppc’. > > The description lines should begin with a capital letter and the lines > should > not exceed 80 chars (some people prefer if they do not exceed 76 chars so > that “git show” output fits into 80 columns). > > hth > Iain > > > > > > Sergey > > > > 0001-libgfortran-implement-fpu-macppc-for-Darwin-support-.patch Description: Binary data
Re: [PATCH] Fortran: fix minor frontend GMP leaks
Hi Andre, Am 14.08.24 um 07:53 schrieb Andre Vehreschild: Hi Harald, I had a hard time to figure why this is correct, when gfc_array_size() returned false, but now I get it. Ok to commit. I know that reading code is always twice as hard as writing it... ;-) Thanks for checking. Pushed as r15-2917-ga82c4dfe52dac3 . Harald - Andre On Tue, 13 Aug 2024 21:25:31 +0200 Harald Anlauf wrote: Dear all, while running f951 under valgrind on testcase gfortran.dg/sizeof_6.f90 I found two minor memleaks with GMP variables that were not cleared. Regtested on x86_64-pc-linux-gnu. I intend to commit to mainline soon unless there are comments. (And no, this does not address the recent intermittent runtime failures reported in pr116261). Thanks, Harald -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Fortran, Patch, PR110033, v1] Fix associate for coarrays
Hi Andre, Am 12.08.24 um 14:11 schrieb Andre Vehreschild: Hi all, the attached two patches fix ASSOCIATE for coarrays, i.e. that a coarray associated to a variable is also a coarray in the block of the ASSOCIATE command. The patch has two parts: 1. pr110033p1_1.patch: Adds a corank member to the gfc_expr structure. I decided to add it here and keep track of the corank of an expression, because calling gfc_get_corank was getting to expensive with the associate patch. This patch also improves the usage of coarrays in select type/rank constructs. 2. pr110033p2_1.patch: The changes and testcase for PR 110033. In essence the coarray is not detected correctly on the expression to associate to and therefore not propagated correctly into the block of the ASSOCIATE command. The patch adds correct treatment for propagating the coarray token into the block, too. The costs of tracking the corank along side to the rank of an expression are about 30 seconds real user time (i.e. time's "real" row) on a rather old Intel i7-5775C@3.3GHz with 24G RAM that was used for work during the test. If need be I can tuned that more. Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? Paul already gave a basic OK, and I won't object. However, the testcase should be fixed. It is only correct for single-image runs! (Verified with Intel ifx). You have: associate (y => x) y = -1 y[1] = 35 end associate and check: if (x /= 35) stop 1 This should rather be if (x[1] /= 35) stop 1 or for number of images > 1: if (this_image() == 1) then if (x /= 35) stop 1 else if (x /= -1) stop 99 end if and similarly if (.NOT. c%l) stop 3 needs to be adjusted accordingly. Thanks, Harald Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de
