On 6/15/25 1:22 PM, Harald Anlauf wrote:
Am 15.06.25 um 21:25 schrieb Harald Anlauf:
Dear all,
the attached patch fixes a rejects-valid: in an ALLOCATE statement with
MOLD= present, if the allocate-object has an explicit-shape-spec, the
compatibility of ranks is not required by the standard. (
ranch?
Thanks,
Harald
Harald
From 7194cdde73ed2b2c6ad6bc1a200a9f508c9659fa Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 15 Jun 2025 21:09:28 +0200
Subject: [PATCH] Fortran: fix checking of MOLD= in ALLOCATE statements
[PR51961]
In ALLOCATE statements where the MOLD= argument is presen
Dear all,
the attached patch fixes a rejects-valid: in an ALLOCATE statement with
MOLD= present, if the allocate-object has an explicit-shape-spec, the
compatibility of ranks is not required by the standard. (It is
explicitly required only for SOURCE=).
Since this could surprise users, we emit
Hi Yuao,
Yuao Ma wrote:
Fixed in this patch. Thinking about tex is always a pain...
> Additionally, I think all "half-revolutions" should be "half
revolutions"
Thanks! I have another nit:
* intrinsic.texi: Add new doc. Reorder doc for atand.
The first part is not really clear. I hav
Hi Yuao,
Yuao Ma wrote:
This patch is a follow-up to commit r16-938-ge8fdd55ec90749. In this
patch, we
add intrinsic documentation for the newly added trig functions with
half-revolutions. We also reorder the documentation for `atand` to
place it in
correct alphabetical order.
When I try to
Hi all,
This patch is a follow-up to commit r16-938-ge8fdd55ec90749. In this patch, we
add intrinsic documentation for the newly added trig functions with
half-revolutions. We also reorder the documentation for `atand` to place it in
correct alphabetical order.
BR,
Yuao
0001-fortran-add-intrin
Hi Harald,
Lgtm. That patch is nearly obvious. Ok for trunk and backport.
Thanks for the patch,
Andre
Andre Vehreschild * ve...@gmx.de
Am 3. Juni 2025 20:43:52 schrieb Harald Anlauf :
Dear all,
here's a fix for another one of Gerhard's "torture tests" that triggers
an ICE with -Warray-tempor
Hi Andre,
On 6/3/25 21:03, Andre Vehreschild wrote:
Hi Harald,
Lgtm. That patch is nearly obvious. Ok for trunk and backport.
Thanks for the patch,
Andre
thanks for the swift review!
Pushed as r16-1090-g0768ec0d32f570.
Thanks,
Harald
Andre Vehreschild * ve...@gmx.de
Am 3. Juni 2025 20:43
or generated for
the data values.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From b8c58ba3e8113cb05a45e8263dfd60726e173e68 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 3 Jun 2025 20:30:30 +0200
Subject: [PATCH] Fortran: ICE due to missing locus with data st
On 5/30/25 19:44, Steve Kargl wrote:
On Fri, May 30, 2025 at 07:37:49PM +0200, Harald Anlauf wrote:
here's a patch fixing the handling of parameter inquiries of
constant complex arrays. It profits from previous fixes for
inquiries of substrings and essentially adds only the simplification
of %
On Fri, May 30, 2025 at 07:37:49PM +0200, Harald Anlauf wrote:
>
> here's a patch fixing the handling of parameter inquiries of
> constant complex arrays. It profits from previous fixes for
> inquiries of substrings and essentially adds only the simplification
> of %re/%im applies to complex arra
to
15-branch with some delay.
Thanks,
Harald
From 1d7fcd242134b99eb1b2642d4aa87d5b95b49e94 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 30 May 2025 19:25:15 +0200
Subject: [PATCH] Fortran: parameter inquiries of constant complex arrays
[PR102599,PR114022]
PR fortran/102599
PR fo
Hello world,
I have just committed the attached patch as obvious and simple
after regression-testing. Will backport to gcc 15 soonish.
This fixes a 15/16 regression where the code was looking at
the typespec of the symbol which we don't set if there is
a RESULT clause.
Thanks to Harald for poin
Hi Tobias and Harald,
I sincerely apologize for the breakage! I did test both preprocessor branches,
but I tested against the same MPFR version (4.2.2, which is the latest on Arch
Linux). Going forward, I will test against versions both above and below 4.2.0
to ensure this type of breakage doesn't
Hi Tobias,
On 5/28/25 22:46, Tobias Burnus wrote:
Hi Harald,
Harald Anlauf wrote:
This breaks bootstrap here on openSUSE Leap 15.6 with mpfr-4.0.2:
../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr*
gfc_simplify_cospi(gfc_expr*)':
../../gcc-trunk/gcc/fortran/simplify.cc:2305:3:
Hi Harald,
Harald Anlauf wrote:
This breaks bootstrap here on openSUSE Leap 15.6 with mpfr-4.0.2:
../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr*
gfc_simplify_cospi(gfc_expr*)':
../../gcc-trunk/gcc/fortran/simplify.cc:2305:3: error: 'mpfr_fmod_ui'
was not declared in this scop
On 5/28/25 19:51, Tobias Burnus wrote:
Hi Yuao,
Yuao Ma wrote:
[…]
Done.
LGTM :-) I have now applied it as r16-938-ge8fdd55ec90749.
Thanks for the patch!
Tobias
This breaks bootstrap here on openSUSE Leap 15.6 with mpfr-4.0.2:
../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_e
On 5/28/25 10:09 AM, Steve Kargl wrote:
On Wed, May 28, 2025 at 08:11:05AM -0700, Jerry D wrote:
The attached patch is simple and self explanatory in the git log entry.
Regression tested on X86_64-linux-gnu.
OK for trunk?
Yes, with one question.
commit 845768cbead03f76265e491bcf5ea6de7020
Hi Yuao,
Yuao Ma wrote:
[…]
Done.
LGTM :-) I have now applied it as r16-938-ge8fdd55ec90749.
Thanks for the patch!
Tobias
Hi Jerry!
On 5/28/25 17:11, Jerry D wrote:
The attached patch is simple and self explanatory in the git log entry.
Regression tested on X86_64-linux-gnu.
OK for trunk?
This LGTM.
Thanks for the patch!
Harald
Regards,
Jerry
Yes, Steve I have it backward. I will fix it before commit.
On Wed, May 28, 2025, 10:15 AM Steve Kargl
wrote:
> On Wed, May 28, 2025 at 08:11:05AM -0700, Jerry D wrote:
> > The attached patch is simple and self explanatory in the git log entry.
> >
> > Regression tested on X86_64-linux-gnu.
> >
On Wed, May 28, 2025 at 08:11:05AM -0700, Jerry D wrote:
> The attached patch is simple and self explanatory in the git log entry.
>
> Regression tested on X86_64-linux-gnu.
>
> OK for trunk?
>
Yes, with one question.
> commit 845768cbead03f76265e491bcf5ea6de7020ff39
> Author: Jerry DeLisle
>
Hi Tobias,
> you will notice that the PR is not recognized. The format as mentioned before
> is "PR component/number". Namely:
Thanks for the reminder! I'll use `-p` to double-check PR numbers going
forward.
> The second part is not what you are doing, you are actually changing the
> call from
The attached patch is simple and self explanatory in the git log entry.
Regression tested on X86_64-linux-gnu.
OK for trunk?
Regards,
Jerrycommit 845768cbead03f76265e491bcf5ea6de7020ff39
Author: Jerry DeLisle
Date: Wed May 28 07:56:12 2025 -0700
Fortran: Adjust handling of optional com
Hi Jerry!
On 5/27/25 21:36, Jerry D wrote:
On 5/27/25 11:24 AM, Harald Anlauf wrote:
Dear all,
the attached patch fixes a variety of small issues with parsing of
inquiry references of substrings. The testcase exercises variations
of the examples in the PR and ensures that these are successful
On 5/27/25 12:39 PM, Harald Anlauf wrote:
Hi Jerry!
On 5/27/25 21:02, Jerry D wrote:
On 5/20/25 12:35 PM, Jerry D wrote:
On 5/20/25 12:01 PM, Harald Anlauf wrote:
Hi Jerry!
Am 20.05.25 um 05:23 schrieb Jerry D:
On 5/19/25 1:50 PM, Harald Anlauf wrote:
Hi Jerry,
so contrary to what the nam
Hi Jerry!
On 5/27/25 21:02, Jerry D wrote:
On 5/20/25 12:35 PM, Jerry D wrote:
On 5/20/25 12:01 PM, Harald Anlauf wrote:
Hi Jerry!
Am 20.05.25 um 05:23 schrieb Jerry D:
On 5/19/25 1:50 PM, Harald Anlauf wrote:
Hi Jerry,
so contrary to what the name of patch claims (pr120049-final.diff),
it
On 5/27/25 11:24 AM, Harald Anlauf wrote:
Dear all,
the attached patch fixes a variety of small issues with parsing of
inquiry references of substrings. The testcase exercises variations
of the examples in the PR and ensures that these are successfully
simplified.
Don't try it with other compi
On 5/20/25 12:35 PM, Jerry D wrote:
On 5/20/25 12:01 PM, Harald Anlauf wrote:
Hi Jerry!
Am 20.05.25 um 05:23 schrieb Jerry D:
On 5/19/25 1:50 PM, Harald Anlauf wrote:
Hi Jerry,
so contrary to what the name of patch claims (pr120049-final.diff),
it fixes only the case of direct use of iso_c_b
linux-gnu. OK for mainline?
I believe this is sufficiently safe that it can be backported
later to 15-branch, unless someone objects.
Thanks,
Harald
From 48a3bb2f5822b0e69211e89bd92fa3d497321f4c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 27 May 2025 19:23:16 +0200
Subject: [
Yuao Ma wrote:
PR113152
If you run your patch through
./contrib/gcc-changelog/git_email.py
0001-fortran-add-constant-input-support-for-trig-function.patch
you will notice that the PR is not recognized. The format as mentioned before is "PR
component/number". Namely:
"PR fortran/113
On Tue, May 27, 2025 at 02:17:46PM +, Yuao Ma wrote:
>
> I've reverted the recent format changes, as three reviewers indicated they
> caused more harm than good.
>
Thank you.
> Are there any functional problems I need to address?
I did not see any additional functional issues. Patch is
OK
Hi all,
I've reverted the recent format changes, as three reviewers indicated they
caused more harm than good.
Are there any functional problems I need to address?
Thanks,
Yuao
0001-fortran-add-constant-input-support-for-trig-function.patch
Description: 0001-fortran-add-constant-input-support
Am 26.05.25 um 18:36 schrieb Steve Kargl:
On Mon, May 26, 2025 at 09:30:59AM +, Yuao Ma wrote:
Hi Steve,
I looked at the patch in a bit more detail, and
I am not thrilled with large-scale whitespace
changes mingled with functional changes. It makes
the patch harder to read and review.
I'
On Mon, May 26, 2025 at 09:30:59AM +, Yuao Ma wrote:
> Hi Steve,
>
> > I looked at the patch in a bit more detail, and
> > I am not thrilled with large-scale whitespace
> > changes mingled with functional changes. It makes
> > the patch harder to read and review.
>
> I'm not sure which file y
On Sun, May 25, 2025 at 04:56:48AM +, Yuao Ma wrote:
>
> Thanks for your review! I've updated the patch.
>
> > this range_check() is unneeded.
>
> Done.
>
> > As a side note, the error message is slightly misleading
> > (although it will not be issued). Technically, x = -1 or 1
> > are all
Hi Steve,
Thanks for your review! I've updated the patch.
> this range_check() is unneeded.
Done.
> As a side note, the error message is slightly misleading
> (although it will not be issued). Technically, x = -1 or 1
> are allowed values, and neither is **between** -1 and 1.
You're right, th
Apologies for late a late reply. A quick skim of the code
suggests that you can eliminate some of the range_check()
calls in the simplifications. For example, you have
+gfc_expr *
+gfc_simplify_acospi (gfc_expr *x)
+{
+ gfc_expr *result;
+
+ if (x->expr_type != EXPR_CONSTANT)
+return NULL;
Hi Tobias,
The patch has been updated. Could you please take a look when you have a
chance?
> Can you add the PR number to the commit log ("PR fortran/113152")?
Done.
> Can you also update the documentation – as you already did for ATAND?
I think that's quite a lot of wording... Hoping to tack
Hi,
Yuao Ma wrote:
I'm pretty swamped for the next couple of days
Same issue here - hence, I haven't completed the review ...
You're absolutely right that the best way to keep changes minimal is to just
rename the `*resolve*` function.
I missed the
-gfc_resolve_trigd,
+gfc_resolve_trig,
c
Hi Tobias,
Thanks for the thorough code review! I'm pretty swamped for the next couple of
days, and I'll get the patch updated as you requested this weekend.
> I don't understand this change. First, I don't see any reason why this
> should get modified. And by modifying it, a simple "git blame" w
Hi Yuao,
first comments, I still need to look again at some changes, especially
at simplify.cc.
Yuao Ma wrote:
This patch introduces constant input support for trigonometric functions,
including those involving half-revolutions. Both valid and invalid
inputs have
been thoroughly tested, as
Hi Jerry!
Am 20.05.25 um 05:23 schrieb Jerry D:
On 5/19/25 1:50 PM, Harald Anlauf wrote:
Hi Jerry,
so contrary to what the name of patch claims (pr120049-final.diff),
it fixes only the case of direct use of iso_c_binding, but not the
indirect one thru the other module, which is the reason for
Sorry, the previous patch had some issues with the test case. Please refer to
the updated version, which resolves the problem.
From: Yuao Ma
Sent: Tuesday, May 20, 2025 23:54
To: gcc-patches@gcc.gnu.org ; GCC Fortran
; tbur...@baylibre.com
Subject: [PATCH
Hi all,
This patch introduces constant input support for trigonometric functions,
including those involving half-revolutions. Both valid and invalid inputs have
been thoroughly tested, as have mpfr versions greater than or equal to 4.2 and
less than 4.2.
Inspired by Steve's previous work, this pa
On 5/19/25 1:50 PM, Harald Anlauf wrote:
Hi Jerry,
so contrary to what the name of patch claims (pr120049-final.diff),
it fixes only the case of direct use of iso_c_binding, but not the
indirect one thru the other module, which is the reason for the
original ICE and the PR.
So if you want to pu
Hi Jerry,
so contrary to what the name of patch claims (pr120049-final.diff),
it fixes only the case of direct use of iso_c_binding, but not the
indirect one thru the other module, which is the reason for the
original ICE and the PR.
So if you want to push the incremental patch now, go ahead.
C
Pushed as r16-734-gbf98b735ae01c6 after an off-list OK by Jerry,
and no other responses to the opposite.
Harald
On 5/18/25 22:53, Harald Anlauf wrote:
Dear all,
the attached proposed patch fixes PR120099 by modifying
gfc_return_by_reference so that it returns true with -ff2c
also for intrinsic
On 5/18/25 2:34 PM, Jerry D wrote:
On 5/18/25 2:10 PM, Harald Anlauf wrote:
Hi Jerry,
I found 2 corner invalid cases which are silently accepted with
your patch when iso_c_binding is used indirectly:
print *, c_associated(c_loc(val), C_NULL_FUNPTR)
print *, c_associated(C_NULL_FUNPTR, c_
On 5/18/25 2:10 PM, Harald Anlauf wrote:
Hi Jerry,
I found 2 corner invalid cases which are silently accepted with
your patch when iso_c_binding is used indirectly:
print *, c_associated(c_loc(val), C_NULL_FUNPTR)
print *, c_associated(C_NULL_FUNPTR, c_loc(val))
These should get rejected
Hi Jerry,
I found 2 corner invalid cases which are silently accepted with
your patch when iso_c_binding is used indirectly:
print *, c_associated(c_loc(val), C_NULL_FUNPTR)
print *, c_associated(C_NULL_FUNPTR, c_loc(val))
These should get rejected, too. Can you see how to catch these, too?
65d7c6efe51371ba4d0681fc2fa0e732b70b70d7 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 18 May 2025 22:42:26 +0200
Subject: [PATCH] Fortran: fix FAIL of gfortran.dg/specifics_1.f90 after
r16-372 [PR120099]
After commit r16-372, testcase gfortran.dg/specifics_1.f90 started to
FAIL at -O2 and higher, as DCE lead to
Hello all,
The attached patch revises the logic of the checks in
gfc_check_c_associated to handle previous cases that ICE'ed as seen in
the PR. There are multiple gotchas in these cases, particularly with the
optional c_ptr_2 argument.
I factored the logic into two new helper functions. This
Hi Andre,
Am 15.05.25 um 22:13 schrieb Andre Vehreschild:
LGTM!
it's great that you reviewed the patch, as I was touching
original code next to yours... ;-)
Thanks for the Patch.
Pushed as r16-669-gd31ab498b12ebb.
Thanks,
Harald
- Andre
Andre Vehreschild * ve...@gmx.de
Am 15. Mai 2025
LGTM!
Thanks for the Patch.
- Andre
Andre Vehreschild * ve...@gmx.de
Am 15. Mai 2025 22:36:19 schrieb Harald Anlauf :
Dear all,
the attached patch fixes missing default-initialization of function
results of derived type that happens under some conditions, see PR.
The logic when default initia
further would need backporting of other
patches (e.g. to pr98454), so if someone pushes me, I can try.
Let me know what you think.
Cheers,
Harald
From 8a1f2ae8c0ea3a92d9b20f0e678b56583ca4a849 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 15 May 2025 21:07:07 +0200
Subject: [PATCH
Hi Paul,
Same remark as for PR120107! LGTM for both branches.
Committed both patches. Thanks for the reviews!
Best regards
Thomas
Am 14.05.25 um 08:42 schrieb FX Coudert:
[…] more trigonometric
functions changes are coming, I think it would be useful to agree
that this is a good approach.
Patch is OK to push.
Thanks for the review.
However, I messed up with 'git add' at some point and committed now a
version that didn't
Hi Tobias,
> Admittedly, this *PING* is rather early – but as more trigonometric
> functions changes are coming, I think it would be useful to agree
> that this is a good approach.
Patch is OK to push.
FX
Hi Thomas,
Same remark as for PR120107! LGTM for both branches.
Thanks
Paul
On Tue, 13 May 2025 at 21:30, Thomas Koenig wrote:
> Hello world,
>
> this fixes the other regression which crept in with gfortran.
> Again, regression-tested, plus the local testing script is
> attached.
>
> Ok for
Hi Thomas,
I don't think that anybody else has been up to the job of hacking dejagnu
to test patches to dump-parse-tree.cc :-)
I think that the patch verges on the 'obvious' and is good for both
15-branch and mainline.
Thanks for the patch.
Paul
On Tue, 13 May 2025 at 21:15, Thomas Koenig wr
Admittedly, this *PING* is rather early – but as more trigonometric
functions changes are coming, I think it would be useful to agree
that this is a good approach.
And the patch is simple.
BTW: For the infrastructure/download update,
I have filed https://gcc.gnu.org/PR120237
Next would be the s
Hi Yuao,
Yuao Ma wrote:
Following up on your review comments, I have updated the patch.
Thanks - LGTM.
Two minor comments, but I have already pushed the commit
as r16-602-gb239e9cf98ca92
First:
* gfortran.dg/dec_math.f90: Add atand(y, x) testcase.
Also for the documentation, the
Hello world,
this fixes the other regression which crept in with gfortran.
Again, regression-tested, plus the local testing script is
attached.
Ok for trunk and gcc-15?
Best regards
Thomas
Fix explicit arrays with non-constant size for -fc-prototypes.
gcc/fortran/ChangeLog:
Hello world,
the attached patch fixes a 15/16 regression and should be fairly
self-explanatory.
Regarding testing: I'm not sure I am up to the task of hacking
dejagnu to do this. I am now running local tests, which is
better than nothing (I guess).
Regression-testing: Passed, though this does n
Jakub Jelinek wrote:
Here is an updated patch including your incremental changes.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
LGTM. Thanks for the patch – and sorry for the delayed review.
Tobias
Trying to write a testcase I've run into further issues but seems they
Hi Tobias,
Following up on your review comments, I have updated the patch.
Specifically, I have:
* Added the PR number to the subject line.
* Used the -b and -p options when running git gcc-commit-mklog.
* Updated the intrinsic documentation as requested.
Could you please take another look when yo
On Mon, May 12, 2025 at 11:42 AM Tobias Burnus wrote:
>
> C23 added the sinpi, cospi, etc. functions. Therefore, MPFR in 4.2.0
> added the mpfr_ counter parts. I assume that those internally use the
> mpfr_sinu, mpfr_cosu, ... functions, which are also user accessible.
>
> In any case, MPFR makes
C23 added the sinpi, cospi, etc. functions. Therefore, MPFR in 4.2.0
added the mpfr_ counter parts. I assume that those internally use the
mpfr_sinu, mpfr_cosu, ... functions, which are also user accessible.
In any case, MPFR makes the ...u functions available and explicitly
documents that for u
On Sat, May 10, 2025 at 11:21:19AM +0200, Tobias Burnus wrote:
> Namely: Similar to above, we should be able to just do:
>
> if (dim_arg->expr)
>
> I think the comment should be also updated and we
> can also get rid of the 'actual' variable for cleanup.
>
> Namely, something like the followi
Hi all, hi Yuao,
first, thanks for your patch - you are awesome! I believe it fixes the
issue reported by Steven in problem report (PR) 113414,
https://gcc.gnu.org/PR113413
Thus:
* * *
[Linking PR numbers]
In order to correlate commits to issued (and get them automatically
linked), the commit
Hi all,
According to the Fortran standard, atand(y, x) is equivalent to atan2d(y, x).
However, the current atand(y, x) function produces an error. This patch
includes the necessary intrinsic mapping, related test, and intrinsic
documentation.
The minor comment change in intrinsic.cc is cherry-pick
Hi Jerry!
Am 10.05.25 um 21:53 schrieb Jerry D:
On 5/10/25 11:33 AM, Harald Anlauf wrote:
Early ping.
Am 06.05.25 um 21:06 schrieb Harald Anlauf:
Dear all,
here's another rather obvious case where a temporary is needed for
an inquiry reference of a complex array which is a component of a
der
On 5/10/25 11:33 AM, Harald Anlauf wrote:
Early ping.
Am 06.05.25 um 21:06 schrieb Harald Anlauf:
Dear all,
here's another rather obvious case where a temporary is needed for
an inquiry reference of a complex array which is a component of a
derived type. In contrast to PR119986, the argument
Early ping.
Am 06.05.25 um 21:06 schrieb Harald Anlauf:
Dear all,
here's another rather obvious case where a temporary is needed for
an inquiry reference of a complex array which is a component of a
derived type. In contrast to PR119986, the argument is handled
within the code for the intrinsi
,
your patch diff has:
--- a/libgfortran/io/read.c
+++ b/libgfortran/io/read.c
@@ -1375,7 +1375,7 @@ exponent:
* * *
I've manually added the function name to the ChangeLog for now
Thanks.
* * *
One very minor nit:
The email subject reads
"[PATCH, fortran] Fix simple typo in libgfort
Hi Tobias,
Thanks for your time and guidance on this GSOC project.
> * This is a trivial patch but for larger patches, you need
>grant the right to use your patch. There are two ways of doing so:
>(a) The simple one, called "Developer Certificate of Origin" (DCO).
>This requires a "Si
Hi Yuao,
Yuao Ma wrote:
I'm writing to express my sincere gratitude for the opportunity to
participate
in Google Summer of Code with GCC this year. I am very enthusiastic
about this
program and fully committed to making a valuable contribution and
fulfilling my
responsibilities.
Welcome an
Hi Thomas,
Thanks for your quick response.
> There should be a ChangeLog entry. You can generate a template by
> running your patch through contrib/mklog.py, which you can then fill
> out with the details.
I think the ChangeLog entry is already in the patch. I used
git gcc-commit-mklog, and it p
Hi Yuao,
first, good to have you on board!
As I am relatively new to submitting patches via mailing lists, I would
like to
send a very simple patch primarily to familiarize myself with the correct
procedure. I have reviewed the contribution guidelines on the GCC
website and
have tried to fol
Jakub Jelinek wrote:
This unfortunately only fixes some of the cases in the new testcase.
We indeed should drop the kind argument from what is passed to the
library, but need to do it not only when one uses the argument name
for it (so kind=4 etc.) but also when one passes all the arguments
to t
Hi GCC Maintainers,
I'm writing to express my sincere gratitude for the opportunity to participate
in Google Summer of Code with GCC this year. I am very enthusiastic about this
program and fully committed to making a valuable contribution and fulfilling my
responsibilities.
As I am relatively ne
Hi Jakub,
The following patch uses a variant of the character(kind=4) type
for unsigned(kind=4) and a distinct type based on character(kind=1)
type for unsigned(kind=1). The reason for the latter is that
unsigned_char_type_node has TYPE_STRING_FLAG set on it, so it has
DW_AT_encoding DW_ATE_uns
On Fri, May 09, 2025 at 06:18:40PM +0300, Daniil Kochergin wrote:
> PR fortran/120191
>
> * trans-intrinsic.cc (gfc_conv_intrinsic_minmaxloc):
>
> Call strip_kind_from_actual unconditionally.
>
>
> * gfortran.dg/pr120191.f90: New test.
This unfortunately only fixes some of the cases in the new
Hi!
As the following testcase shows, debug info for unsigned(kind=1)
and unsigned(kind=4) vars is wrong while unsigned(kind=2), unsigned(kind=8)
and unsigned(kind=16) look right.
Instead of objects having unsigned(kind=1) type they have character(kind=1)
and instead of unsigned(kind=4) they have c
h the present one.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
I'd also like to backport this one to 15-branch if this is ok.
Thanks,
Harald
From 981aa53bc258d3c3b75ecdcd33d993346db1fd12 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 6 May 2025 20:59:48 +0200
Subject: [PATC
Hi Harald,
It appears that something is not right and generates wrong code with
the check enabled. Can you have another look?
The problem was indeed that generating a formal from an actual
arglist is a bad idea when classes are involved. Fixed in the
attached patch. I think it still makes s
Hi Thomas,
Am 04.05.25 um 12:10 schrieb Thomas Koenig:
Hi Harald,
It appears that something is not right and generates wrong code with
the check enabled. Can you have another look?
The problem was indeed that generating a formal from an actual
arglist is a bad idea when classes are involved
Hi Paul,
Am 04.05.25 um 11:33 schrieb Paul Richard Thomas:
Hi Harald,
This looks good to me both for mainline and backporting as far back as you
wish.
thanks for the review!
Committed as r16-376-gfceb6022798b58 so far.
Will wait a week or so before starting a backport.
Cheers,
Harald
Than
Hi Harald,
It appears that something is not right and generates wrong code with
the check enabled. Can you have another look?
The problem was indeed that generating a formal from an actual
arglist is a bad idea when classes are involved. Fixed in the
attached patch. I think it still makes s
Hi Harald,
This looks good to me both for mainline and backporting as far back as you
wish.
Thanks
Paul
On Sat, 3 May 2025 at 19:51, Harald Anlauf wrote:
> Dear all,
>
> the attached, semi-obvious patch fixes bugging issues with passing of
> array subreferences when either an inquiry referen
least 15-branch, if this is ok.
Thanks,
Harald
From 8d49cd9e0fe76d2c45495017cb87588e9b9824cf Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 3 May 2025 20:35:57 +0200
Subject: [PATCH] Fortran: array subreferences and components of derived types
[PR119986]
PR fortran/119986
gcc/fo
Hi Thomas,
I haven't tested your patch very thorougly, but when manually
compiling
% gfc-16 gcc/testsuite/gfortran.dg/proc_ptr_52.f90
-Wexternal-argument-mismatch && ./a.out
STOP 1
It appears that something is not right and generates wrong code with
the check enabled. Can you have another lo
Hello world,
This patch fixes a case where too much was being checked with
-Wexternal-arguments-mismatch with a procedure pointer with an
unlimited polymorphic and an INTEGER argument which was inferred from
an actual argument.I also found some checks which can trigger false
positives, which this
Committed as r16-329-g0abc77da9d704bba55a376bb5c162a54826ab94a following OK
by Jerry on PR.
I am ready to backport in a few weeks time if that is wanted.
Regards
Paul
Fortran: Source allocation of pure function result rejected [PR119948]
2025-05-01 Paul Thomas
gcc/fortran
Hi Jerry,
Am 24.04.25 um 22:56 schrieb Jerry D:
On 4/24/25 12:59 PM, Harald Anlauf wrote:
Dear all,
the attached patch is the result of my attempts to fix an ICE when
compiling gfortran.dg/proc_ptr_52.f90 with -fcheck=all. While
trying to reduce this, I found several oddities with functions
r
On 4/24/25 12:59 PM, Harald Anlauf wrote:
Dear all,
the attached patch is the result of my attempts to fix an ICE when
compiling gfortran.dg/proc_ptr_52.f90 with -fcheck=all. While
trying to reduce this, I found several oddities with functions
returning class(*), pointer that ICE'd too.
The or
rs,
Harald
From a6ec26a7d7a92a5e2cefedf08a4616060783050e Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 24 Apr 2025 21:28:35 +0200
Subject: [PATCH] Fortran: fix procedure pointer handling with -fcheck=pointer
[PR102900]
PR fortran/102900
gcc/fortran/ChangeLog:
* tra
On Fri, Apr 18, 2025 at 05:48:46PM -0700, Jerry D wrote:
> I will be committing a fix for this to the 16 mainline tonight.
>
> I am requesting Release Manager approval to push to 15 release branch after
> full testing here.
>
> Regards,
>
> Jerry
>
> See attached diff.
>
> 2025-04-18 Steven G
Ping! Can we backport this to 15 please?
Regards,
Jerry
On 4/18/25 6:35 PM, Jerry D wrote:
On 4/18/25 5:48 PM, Jerry D wrote:
I will be committing a fix for this to the 16 mainline tonight.
I am requesting Release Manager approval to push to 15 release branch
after full testing here.
Rega
1 - 100 of 1758 matches
Mail list logo
