um 20:37
> >> Von: "Jerry D"
> >> An: "Mikael Morin" , "Harald Anlauf" <
> anl...@gmx.de>, fortran@gcc.gnu.org
> >> Betreff: Re: Execution time for gfortran regression testing
> >>
> >> On 6/3/25 3:02 AM, Mikael Morin
On 6/10/25 1:55 PM, Harald Anlauf wrote:
Gesendet: Mittwoch, 4. Juni 2025 um 20:37
Von: "Jerry D"
An: "Mikael Morin" , "Harald Anlauf" ,
fortran@gcc.gnu.org
Betreff: Re: Execution time for gfortran regression testing
On 6/3/25 3:02 AM, Mikael Morin wrote:
The b
Hi Steve,
On 6/11/25 23:06, Steve Kargl wrote:
On Wed, Jun 11, 2025 at 10:18:37PM +0200, Harald Anlauf wrote:
- for the INTEGER(KIND=4) versions the STATUS returns ERANGE if
an overflow is encountered.
The latter is certainly debatable, as one of the existing testcases
stat_{1,2}.f90 may fa
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
On Wed, Jun 11, 2025 at 10:18:37PM +0200, Harald Anlauf wrote:
>
> the attached patch is a first attempt to fix some issues with the GNU
> intrinsics STAT/LSTAT/FSTAT which are g77 heritage. This patch is
> preparatory for dealing with the issue reported in PR82480 in that
> the default version o
> On 11 Jun 2025, at 15:17, FX Coudert wrote:
>
> Hi,
>
>> I am just wondering if the order in Makefile.am as it is now is needed. E.g.
>> pack_* follows pow_* and some other are not lexicographicaly ordered. Are
>> there
>> dependencies that necessitate this? Or could you just sort them, so
Hi,
> I am just wondering if the order in Makefile.am as it is now is needed. E.g.
> pack_* follows pow_* and some other are not lexicographicaly ordered. Are
> there
> dependencies that necessitate this? Or could you just sort them, so that
> looking up files is easier for humans?
I think they
Hi FX,
I am just wondering if the order in Makefile.am as it is now is needed. E.g.
pack_* follows pow_* and some other are not lexicographicaly ordered. Are there
dependencies that necessitate this? Or could you just sort them, so that
looking up files is easier for humans?
Besides the comment,
to "make pdf" your patch, I get the following error:
intrinsic.texi:1707: Use of @atan
doesn't match its definition.
-@pi /2 @leq @Re @atan (
x) @leq @pi /2
@finishmath #1->#1
$@endgroup
l.1707 @math{-\pi/2 \leq \Re \
> Gesendet: Mittwoch, 4. Juni 2025 um 20:37
> Von: "Jerry D"
> An: "Mikael Morin" , "Harald Anlauf" ,
> fortran@gcc.gnu.org
> Betreff: Re: Execution time for gfortran regression testing
>
> On 6/3/25 3:02 AM, Mikael Morin wrote:
> > The
Hi FX,
the patch looks good to me. I only have x86_64, too, therefore I haven't tested
it (again). There's a lot of repetition in the regenerate.sh file. I hope to
see this "simplified" or rather DRY'ed (Don't repeat yourself - principle) in
the future.
So looks good to me. Ok for mainline.
Rega
On 6/6/25 5:34 AM, FX Coudert wrote:
Hi,
In commit 5e918a4db9e4a5bdbeafec6881fa8b22a55d3789, regenerated files
were not included in the commit as they should have been. Therefore, a
whitespace fix was not propagated. Sync generated files now, as obtained
from a run with --enable-maintainer-mode.
On Fri, Jun 06, 2025 at 02:34:09PM +0200, FX Coudert wrote:
>
> In commit 5e918a4db9e4a5bdbeafec6881fa8b22a55d3789, regenerated files
> were not included in the commit as they should have been. Therefore, a
> whitespace fix was not propagated. Sync generated files now, as obtained
> from a run wit
On 6/3/25 3:02 AM, Mikael Morin wrote:
Le 30/05/2025 à 22:28, Harald Anlauf a écrit :
When I'm working on a particular area of gfortran, I tend
to use RUNTESTFLAGS to limit what is tested. For example,
I just fixed SPREAD() for scalar source and ncopies < 1.
I do
% cd obj
% gmake
% cd gcc
% gm
On Wed, 4 Jun 2025 at 16:43, Frank Ch. Eigler via Gcc wrote:
>
> Jerry D writes:
>
> > I am getting this tonight.
> > [...]
> > 257 | __gthread_cond_t _M_cond = __GTHREAD_COND_INIT;
>
> By the way, you can scan the sourceware.org buildbots, which include a
> broadish coverage of architectur
Jerry D writes:
> I am getting this tonight.
> [...]
> 257 | __gthread_cond_t _M_cond = __GTHREAD_COND_INIT;
By the way, you can scan the sourceware.org buildbots, which include a
broadish coverage of architectures and distros. Broken builds show up
pretty obviously both in the builds and
Hi Harald,
merged as gcc-16-1096-gafa2de8093a. Thanks again for the review.
Regards,
Andre
On Tue, 3 Jun 2025 21:59:52 +0200
Harald Anlauf wrote:
> Hi Andre,
>
> On 6/3/25 13:31, Andre Vehreschild wrote:
> > Hi all,
> >
> > thanks for the explanations, Christophe. This is very much a
Hi Harald,
I don't think it is necessarily the save attribute, but rather it's
representation in "assembler". To my understanding the type's size is
needed to allocate space in the .RSS or .data segment of the binary. To
manage this the size needs to be compile time computable, which it is not
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
Hi Andre,
On 6/3/25 13:31, Andre Vehreschild wrote:
Hi all,
thanks for the explanations, Christophe. This is very much appreciated. And
sorry, I can't follow all presentations, conferences and publications. There is
meanwhile way too much for me to process out there.
Anyway, the regression I p
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 all,
thanks for the explanations, Christophe. This is very much appreciated. And
sorry, I can't follow all presentations, conferences and publications. There is
meanwhile way too much for me to process out there.
Anyway, the regression I produced in gomp should be fixed by the new version of
p
Le 30/05/2025 à 22:28, Harald Anlauf a écrit :
When I'm working on a particular area of gfortran, I tend
to use RUNTESTFLAGS to limit what is tested. For example,
I just fixed SPREAD() for scalar source and ncopies < 1.
I do
% cd obj
% gmake
% cd gcc
% gmake check-fortran RUNTESTFLAGS="dg.exp=s
Hi!
On Mon, 2 Jun 2025 at 20:53, Andre Vehreschild wrote:
>
> Hi Thomas,
>
> thanks for the ok. Unfortunately does the patch regress in gomp (test case
> gomp/pr104382 when I am not mistaken ; the one with the lone 'save'
> statement). This was reported by the regression testing host at first
On Tue, 3 Jun 2025, 03:19 Jerry D via Gcc, wrote:
> I am getting this tonight.
>
This is a glibc change to the definition of PTHREAD_COND_INITIALIZER. It
looks like you updated glibc. A clean build should fix it.
> Jerry
>
> In file included from
>
> /home/jerry/dev/usr/include/c++/16.0.0/x8
Joseph Myers wrote:
On Sun, 1 Jun 2025, Yuao Ma wrote:
For MPFR versions older than 4.2.0, we've included our own folding functions.
I think the normal practice in GCC would be to avoid the optimizations
when the MPFR support is absent, instead of working around the absence
with possibly less a
Hi Thomas,
thanks for the ok. Unfortunately does the patch regress in gomp (test case
gomp/pr104382 when I am not mistaken ; the one with the lone 'save'
statement). This was reported by the regression testing host at first for
arm, but also occurs on x86_64. Since when are proposed patches ch
Hi Andre,
attached patch fixes a missing substring ref on a saved allocatable string.
The issue seems to be, that the variable is declared to be a character pointer
and not a character array. When using the latter (why not), it works as
expected and does not produce any regressions.
Regtests o
On Sun, 1 Jun 2025, Yuao Ma wrote:
> For MPFR versions older than 4.2.0, we've included our own folding functions.
I think the normal practice in GCC would be to avoid the optimizations
when the MPFR support is absent, instead of working around the absence
with possibly less accurate implementa
Hi Jerry,
On 5/31/25 19:38, Jerry D wrote:
Hi all,
The attached patch fixes a latent issue where we were saving a parsed
and checked format string that had a missing comma. This resulted in the
correct error on the first use of the string, but a missed error on
subsequent uses of the string.
Hi Jerry,
The attached patch fixes a latent issue where we were saving a parsed
and checked format string that had a missing comma. This resulted in the
correct error on the first use of the string, but a missed error on
subsequent uses of the string.
New test case provided.
Regression test
You could possibly modify the dg.exp file. These are basically scripts.
It's a bit of a pain.
On Fri, May 30, 2025, 1:29 PM Harald Anlauf wrote:
> > When I'm working on a particular area of gfortran, I tend
> > to use RUNTESTFLAGS to limit what is tested. For example,
> > I just fixed SPREAD()
When I'm working on a particular area of gfortran, I tend
to use RUNTESTFLAGS to limit what is tested. For example,
I just fixed SPREAD() for scalar source and ncopies < 1.
I do
% cd obj
% gmake
% cd gcc
% gmake check-fortran RUNTESTFLAGS="dg.exp=spread\*.f90"
This only runs 63 tests. Of cours
On Fri, May 30, 2025 at 09:03:27PM +0200, Harald Anlauf wrote:
>
> the time needed for running the gfortran testsuite has increased so
> much that I am looking for options to get this down to something
> that is more bearable when working on a Fortran-only patch.
>
> I am already building with --
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/%i
on
of %re/%im applies to complex arrays - and fixes a minor frontend
memleak encountered on the way.
The testcase verifies that all simplifications happen in the
frontend also at -O0 (and has been cross-checked with NAG,
being the only compiler I saw that gets it right).
Regression-tested on x86_
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:
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
>
On 5/27/25 2:19 PM, Harald Anlauf wrote:
Jerry, all,
that was entirely my fault - attempting a last-minute cleanup
that reordered code, trying to use a refactoring. I've put
on my brown bag and pushed a corrections as obvious as:
r16-921-g74a2281ae18c6d.
See attached.
Caveat: this was tested
Jerry, all,
that was entirely my fault - attempting a last-minute cleanup
that reordered code, trying to use a refactoring. I've put
on my brown bag and pushed a corrections as obvious as:
r16-921-g74a2281ae18c6d.
See attached.
Caveat: this was tested on top of r16-915, as I cannot compile
an
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
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
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
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;
On 5/21/25 6:46 PM, George Rinker wrote:
When I run gfortran (13.1.0 installed 2023/08/20.17:50) from cmd.exe on
a source.f that generates a compiler error, I get a message listing the
first error line and column in normal text, then subsequent messages in
a different color, and then it hangs a
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 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
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_binding, but not the
indirect one thru
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
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?
From: Jakub Jelinek
Sent: Saturday, May 17, 2025 22:11
To: Yuao Ma
Cc: gcc-patc...@gcc.gnu.org ; fortran@gcc.gnu.org
; tbur...@baylibre.com ;
j...@polyomino.org.uk
Subject: Re: [PATCH] gcc: add trigonometric pi-based functions as gcc builtins
On Wed, May 14, 2025 at 02:22:23PM +
On 5/17/25 10:22 AM, Jerry D wrote:
Hello all,
--- snip ---
PS
I managed to clean up the change log and add in Steve:
Author: Jerry DeLisle
Date: Sat May 17 09:45:14 2025 -0700
Fortran: Fix c_associated argument checks.
PR fortran/120049
gcc/fortran/ChangeLog:
On Wed, May 14, 2025 at 02:22:23PM +, Yuao Ma wrote:
> If approved, I suggest committing this foundational change first. Constant
> folding for these builtins will be addressed in subsequent patches.
Note, not just constant folding is needed, but I think the builtins should
be handled in
tree-
On 5/14/25 2:22 PM, Joseph Myers wrote:
On Wed, 14 May 2025, Yuao Ma wrote:
Hi Joseph,
I have updated the patch based on your review comments. I added the
newly introduced builtin to extend.texi and mentioned the PR in the
commit message. Could you please take another look when you have a
m
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
On Wed, 14 May 2025, Yuao Ma wrote:
> Hi Joseph,
>
> I have updated the patch based on your review comments. I added the
> newly introduced builtin to extend.texi and mentioned the PR in the
> commit message. Could you please take another look when you have a
> moment?
This version is OK in t
Hi Paul,
Same remark as for PR120107! LGTM for both branches.
Committed both patches. Thanks for the reviews!
Best regards
Thomas
On Wed, 14 May 2025, Yuao Ma wrote:
> Hi all,
>
> This patch adds trigonometric pi-based functions as gcc builtins: acospi,
> asinpi, atan2pi,
> atanpi, cospi, sinpi, and tanpi. Latest glibc already provides support for
> these functions, which we plan to leverage in future gfortran implementati
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
Jakub Jelinek wrote:
There is a bug in _gfortran_s{max,min}loc1_{4,8,16}_s{1,4} which the
following testcase shows.
The functions return but then crash in the caller.
Seems that is because buffer overflows, I believe those functions for
if (mask == NULL || *mask) condition being false are sup
First is slightly confusing as there are three patches for PR120191.
In particular, two which look almost identical - one for loc2 (this one)
and one for loc1 (the one sent one our later). Jakub pointed out that
the remarks after "ok for trunk?" for this patch are obsoleted by
the follow up patch
Hi Jakub,
Jakub Jelinek wrote:
As mentioned in the PR, _gfortran_{,m,s}findloc2_s{1,4} iterate too many
times in the back case if nothing is found.
For !back, the loops are for (i = 1; i <= extent; i++) so i is in the
body [1, extent] if nothing is found, but for back it is
for (i = extent; i >
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
On Mon, May 12, 2025 at 6:49 PM Iain Sandoe wrote:
>
> > On 12 May 2025, at 17:20, Allin Cottrell wrote:
> >
> > If gcc 15.1.0 is built as a cross compiler from Linux x86_64 to
> > aarch64-w64-mingw32, is it expected that gfortran will work? I doubt
> > it, since fortran support is not mentioned
> On 12 May 2025, at 17:20, Allin Cottrell wrote:
>
> If gcc 15.1.0 is built as a cross compiler from Linux x86_64 to
> aarch64-w64-mingw32, is it expected that gfortran will work? I doubt
> it, since fortran support is not mentioned in the context of the
> AArch64 MinGW target at https://gcc.
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
On Sun, May 11, 2025 at 8:38 PM Harald Anlauf wrote:
>
> Hi Thomas,
>
> Am 11.05.25 um 12:51 schrieb Thomas Koenig via Gcc:
> > Hi Harald,
> >
> >> Hi Thomas,
> >>
> >> On 5/11/25 10:34, Thomas Koenig via Gcc wrote:
> >>> As PR120139 has shown (again), it is too easy to create regressions
> >>> fo
On Sun, May 11, 2025 at 10:34:11 +0200, Thomas Koenig via Gcc wrote:
> 2) Dump to standard output and check for the presence of certain
> regexps, ignoring anything else. Again, this is something I don't
> know how to do.
This is…fraught with peril and fiddliness. If the test can stomach some
C++
Hi Thomas,
Am 11.05.25 um 12:51 schrieb Thomas Koenig via Gcc:
Hi Harald,
Hi Thomas,
On 5/11/25 10:34, Thomas Koenig via Gcc wrote:
As PR120139 has shown (again), it is too easy to create regressions
for dumping C prototypes from Fortran. The main problem
is that there is currently no test
esent,X shall be REAL" does no make sense as ATAND
(contrary to ATAN) does not permit complex values
* Something like "If Y is present, the result is identical to
ATAN2D(Y,X). Otherwise," is missing.
* "range -90 \leq \Re \atand(x) \leq 90": the 'Re' IMHO doesn&#
Hi Harald,
Hi Thomas,
On 5/11/25 10:34, Thomas Koenig via Gcc wrote:
As PR120139 has shown (again), it is too easy to create regressions
for dumping C prototypes from Fortran. The main problem
is that there is currently no test in the testsuite.
for something along this variant you can tr
Hi Thomas,
On 5/11/25 10:34, Thomas Koenig via Gcc wrote:
As PR120139 has shown (again), it is too easy to create regressions
for dumping C prototypes from Fortran. The main problem
is that there is currently no test in the testsuite.
So, what to do? I see several possibilities:
1a) Change t
Am 10.05.25 um 20:32 schrieb Harald Anlauf:
Hi Thomas!
Am 10.05.25 um 11:42 schrieb Thomas Koenig:
This bug was another case of generating a formal arglist from
an actual one where we should not have done so. The fix is
straightforward: If we have resolved the formal arglist, we should
not
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
Hi Thomas!
Am 10.05.25 um 11:42 schrieb Thomas Koenig:
This bug was another case of generating a formal arglist from
an actual one where we should not have done so. The fix is
straightforward: If we have resolved the formal arglist, we should
not generare a new one.
OK for trunk and backpor
Hi Yuao,
Yuao Ma wrote:
Thanks for the tip! I ran the git_check_commit.py script, and it
reported "OK."
However, when I regenerated the ChangeLog, the function name wasn't
included
automatically.
Usually 'git diff' shows the function name in the '@@' line, but that does
not always work – ei
1 - 100 of 3033 matches
Mail list logo
