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. Furthermore (Sorry, I inserted your w/o cite and

[Fortran, Patch, PR116292, v1] Fix 15-regression in move_alloc

Hi all, 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? Regards, Andre P

Re: [Fortran, Patch, PR116292, v1] Fix 15-regression in move_alloc

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 obviou

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

On Mon, Aug 5, 2024 at 6:25 PM Sergey Fedorov wrote: > > On Thu, Jul 25, 2024 at 4:47 PM FX Coudert wrote: > >> Can you post an updated version of the patch, following the first round >> of review? >> >> FX > > If you got some time, please review this. I will likely be away from my PowerPC har

[Fortran, Patch, PR102973, v1] Reset flag for parsing proc_ptrs in associate in error case

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

Re: [Fortran, Patch, PR102973, v1] Reset flag for parsing proc_ptrs in associate in error case

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

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

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

[PATCH] Fortran: reject array constructor value of abstract type [PR114308]

Dear all, the attached patch checks whether the declared type of an array constructor value is abstract, which is forbidden by the standard. Steve found the relevant constraint in F2023, but it exists already in F2018. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald From 9988

Re: [PATCH] Fortran: reject array constructor value of abstract type [PR114308]

Pushed after an OK by Steve in the PR as r15-2902-g9988d7e004796ab531df7bcda45788a7aa9276d7 Am 13.08.24 um 19:25 schrieb Harald Anlauf: Dear all, the attached patch checks whether the declared type of an array constructor value is abstract, which is forbidden by the standard. Steve found the r

[PATCH] Fortran: fix minor frontend GMP leaks

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 interm

Re: [PATCH] Fortran: fix minor frontend GMP leaks

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. - 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