Hi Tobias,
On Mon, Sep 8, 2025 at 10:54 PM Tobias Burnus wrote:
> * * *
>
> >>> + if (true_expr->rank != false_expr->rank)
> >>> +{
> >>> + gfc_error ("true_expr at %L and false_expr at %L in conditional "
> >>> +"expression must have the same rank",
> >>> +
Hi Tobias,
On Tue, Sep 16, 2025 at 5:11 PM Tobias Burnus wrote:
> PS: Already with the current code, we may run into the issue of passing
> an actual argument like '(cond ? "abc" : "cdfg")' to 'class(*)' – and I
> am not sure whether we handle this correctly or not.
That is a great test case, an
Hi Tobias,
On Wed, Sep 17, 2025 at 3:33 AM Tobias Burnus wrote:
>
> Hi Yuao,
>
> Yuao Ma wrote:
>
> On Tue, Sep 16, 2025 at 5:11 PM Tobias Burnus wrote:
>
> PS: Already with the current code, we may run into the issue of passing
> an actual argument like '(c
Hi all,
The first cond-expr patch has been committed as r16-3848-gaf53cfeb8352b1.
This patch inspired me to work on an even clearer feature: allowing
cond-expr to use characters. The change is small; we just need to
conditionally fill the string_length. I'd like to implement this
before moving on
Hi Tobias,
On Fri, Sep 12, 2025 at 9:08 PM Tobias Burnus wrote:
> I am unsure if this is the most appropriate place to simplify.
>
> I am very much in favor of deferring it. Plus: I am wondering
> whether it is generally okay to just simplify it here – or whether
> it has to be delayed to a later
Hi Tobias,
On Wed, Sep 10, 2025 at 5:48 PM Tobias Burnus wrote:
> * * *
>
> Regarding the patch:
>
> > This patch adds support for conditional expressions in Fortran 2023 for
> > limited
> > types (logical, numerical), and also includes limited support for
> > conditional
> > arguments without
Hi Tobias,
On Fri, Sep 5, 2025 at 11:57 PM Tobias Burnus wrote:
>
> Hi Yuao,
>
> Yuao Ma wrote:
> > This time I use git format-patch. Hopefully fix the issue.
>
> Seem so :-)
>
> Do I read you patch correctly that you still want to improve it
> before committi
Hi Tobias,
On Tue, Sep 2, 2025 at 4:57 PM Tobias Burnus wrote:
> BTW: I notice '(Stripping trailing CRs from patch; use --binary to disable.)'
> when applying the patch. - Spurious '\r' in committed patches should be
> avoided, albeit testcases with '\r\n' are fine as we also need to support
> th
On Mon, Sep 1, 2025 at 6:58 PM Tobias Burnus wrote:
>
> Yuao Ma wrote:
> > BTW, The current trunk seems to have some problems with diagnostic
> > location: https://godbolt.org/z/bcrvn9xo4
>
> In the last days, there were some diagnostic changes; possibly
> those c
On Sat, Aug 30, 2025 at 2:02 AM Yuao Ma wrote:
> 2. The diagnostic location appears to have an off-by-one error.
> Consider the diagnostic for conditional_4.f90. Ideally, I'd like
> points (1) and (2) to reference the true_expr and false_expr,
> respectively. However, the curr
Hi Tobias,
I have some updates about this patch.
First, some good news:
1. The patch has been bootstrapped and tested with no regressions.
This was achieved by limiting the type with only one 'sorry' case.
2. The frontend parsing now considers outer parentheses.
And we also have some unresolved
Hi Tobias,
I addressed some review comments and included additional feedback.
On 8/22/2025 11:22 PM, Tobias Burnus wrote:
Hi Yuao,
Yuao Ma wrote:
Hi Paul,
On 7/31/2025 6:02 AM, Paul Richard Thomas wrote:
That's exactly how I had a mind to do it. You beat me to it 🙁
Just get on, p
Hi Joseph,
On 7/31/2025 1:45 AM, Joseph Myers wrote:
On Sun, 6 Jul 2025, Yuao Ma wrote:
+#ifndef HAVE_COSPI
+#define HAVE_COSPI 1
+double cospi (double);
+
+double
+cospi (double x)
+{
+ return cos (x * pihi_d + x * pilo_d);
For reasonable results for large x you should first reduce mod 2
Hi Tobias,
I noticed that this patch was already committed as r16-3154-g587b8a62f50179!
Thanks,
Yuao
Hi Tobias,
On 8/7/2025 8:59 PM, Tobias Burnus wrote:
Yuao Ma wrote:
Given the "Fortran 2023:" prefix, I wonder whether the wording shouldn't
be tweaked:
+ call c_f_pointer(x, ptr_2d, shape=myshape_2d, lower=mylower_2d) !
{ dg-error "Fortran 2023: Unexpected LOWER a
Oops, looks like I mess up a testcase name. Fixed in this version.
On 8/6/2025 10:57 PM, Yuao Ma wrote:
Hi Tobias,
On 8/6/2025 4:32 PM, Tobias Burnus wrote:
Hi Yuao,
thanks for your patch. I have two nits:
* There is no diagnostic for -std=f2018 (or lower);
can you add the
wording is
at https://gcc.gnu.org/onlinedocs/gfortran/C_005fF_005fPOINTER.html
Namely, ...
Yuao Ma wrote:
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -3368,10 +3368,10 @@ Fortran 2003 and later
@table @asis
@item @emph{Synopsis}:
-@code{CALL C_F_POINTER(CPTR, FP
On 8/6/2025 5:20 PM, Tobias Burnus wrote:
Hi Yuao,
thanks for the patch. — I have one nit:
Yuao Ma wrote:
This patch cleans up a duplicate test driver.
Regression-tested. OK for trunk?
...
Subject: [PATCH] fortran: cleanup duplicate tests for
c_f_pointer_shape_driver; nfc
'
On 8/6/2025 5:05 AM, Joseph Myers wrote:
On Tue, 5 Aug 2025, Yuao Ma wrote:
On 8/5/2025 4:05 AM, Joseph Myers wrote:
On Sun, 3 Aug 2025, Yuao Ma wrote:
By the way, could you please take another look at the libquadmath update?
https://inbox.sourceware.org/fortran
oFrom 74eba4dbd7601ca4c854b0e6138b6bffc727222a Mon Sep 17 00:00:00 2001
From: Yuao Ma
Date: Tue, 5 Aug 2025 23:33:16 +0800
Subject: [PATCH] fortran: add optional lower arg to c_f_pointer
This patch adds support for the optional lower argument in intrinsic
c_f_pointer specified in Fortran 2023. Test case
On 8/5/2025 4:05 AM, Joseph Myers wrote:
On Sun, 3 Aug 2025, Yuao Ma wrote:
By the way, could you please take another look at the libquadmath update?
https://inbox.sourceware.org/fortran/kl1pr0601mb4291e1457dc09fe3aa6652c884...@kl1pr0601mb4291.apcprd06.prod.outlook.com/
Using the script
On 8/5/2025 3:05 AM, Jerry D wrote:
I think your test case should pass.
Thank you for explaining! That's exactly how my local patch works. I
believe I can refine the patch and have it ready for review ASAP.
Yuao
Hi all,
I am trying to understand the effect of the lower argument in the
c_f_pointer procedure. If I am correct, should the following test case pass?
! { dg-do run }
program lower
use iso_c_binding
type(c_ptr) :: x
integer, target :: array(12)
integer, pointer :: ptr(:, :)
integer :
Hi all,
This patch cleans up a duplicate test driver.
Regression-tested. OK for trunk?
Thanks,
YuaoFrom f4e821d346652ff4f9ac1a934a6afd019f13e026 Mon Sep 17 00:00:00 2001
From: Yuao Ma
Date: Mon, 4 Aug 2025 20:19:27 +0800
Subject: [PATCH] fortran: cleanup duplicate tests for
Hi Paul,
On 7/31/2025 6:02 AM, Paul Richard Thomas wrote:
That's exactly how I had a mind to do it. You beat me to it :-(
Just get on, polish the patch and add more tests.
I've updated the patch with improvements to both the functionality and
test cases. It should now work well for simple sc
On 7/31/2025 1:45 AM, Joseph Myers wrote:
On Sun, 6 Jul 2025, Yuao Ma wrote:
+#ifndef HAVE_COSPI
+#define HAVE_COSPI 1
+double cospi (double);
+
+double
+cospi (double x)
+{
+ return cos (x * pihi_d + x * pilo_d);
For reasonable results for large x you should first reduce mod 2 to the
. Please take a look when you
have a moment.
Thanks in advance,
YuaoFrom 8b0312442ade17f64ae7c8059daa3af46a0bceda Mon Sep 17 00:00:00 2001
From: Yuao Ma
Date: Wed, 30 Jul 2025 22:38:57 +0800
Subject: [PATCH] fortran: implement conditional expression for fortran 2023
TBD
gcc/fortran/ChangeLog:
On 7/27/2025 8:51 PM, Mikael Morin wrote:
Le 27/07/2025 à 13:46, Yuao Ma a écrit :
On 7/27/2025 7:14 PM, Mikael Morin wrote:
Le 27/07/2025 à 11:37, Yuao Ma a écrit :
On 7/27/2025 5:19 PM, Mikael Morin wrote:
+gfc_charlen_type
+string_split (gfc_charlen_type stringlen, const CHARTYPE
On 7/27/2025 8:51 PM, Mikael Morin wrote:
Le 27/07/2025 à 13:46, Yuao Ma a écrit :
On 7/27/2025 7:14 PM, Mikael Morin wrote:
Le 27/07/2025 à 11:37, Yuao Ma a écrit :
On 7/27/2025 5:19 PM, Mikael Morin wrote:
+gfc_charlen_type
+string_split (gfc_charlen_type stringlen, const CHARTYPE
Hi Steve,
On 7/27/2025 2:25 AM, Steve Kargl wrote:
Thanks for the review! If the new patch looks good for trunk and there are
no other objections, could you please help me merge it?
I haven't committed a patch since the transition from subversion
to git. I'm not paid to learn yet-another-SCCS
On 7/27/2025 7:14 PM, Mikael Morin wrote:
Le 27/07/2025 à 11:37, Yuao Ma a écrit :
On 7/27/2025 5:19 PM, Mikael Morin wrote:
+gfc_charlen_type
+string_split (gfc_charlen_type stringlen, const CHARTYPE *string,
+ gfc_charlen_type setlen, const CHARTYPE *set
);
+
can you provide the value of pos and stringlen in the error messages?
Done.From d1c8a89d49f9b66bb9a434f0058180b21061df42 Mon Sep 17 00:00:00 2001
From: Yuao Ma
Date: Sun, 27 Jul 2025 18:12:53 +0800
Subject: [PATCH] fortran: implment split for fortran 2023
This patch includes the implementatio
On 7/27/2025 5:19 PM, Mikael Morin wrote:
+gfc_charlen_type
+string_split (gfc_charlen_type stringlen, const CHARTYPE *string,
+ gfc_charlen_type setlen, const CHARTYPE *set,
+ gfc_charlen_type pos, GFC_LOGICAL_4 back)
+{
+ gfc_charlen_type i, j;
+
+ if (!back)
+ {
+ i
;);
+
+ for (i = pos - 1; i != 0; i--)
+ {
+ for (j = 0; j < setlen; j++)
+ {
+ if (string[i - 1] == set[j])
+ {
+ return i;
+ }
Same here.
Done.
Thanks,
YuaoFrom 06bd5eff1306a82f35e7a9f9ba0db7f1af415f98 Mon Sep 17 00:00:00 2001
From: Yuao
Hi Steve,
On 7/26/2025 11:25 PM, Steve Kargl wrote:
On Sat, Jul 26, 2025 at 09:14:43PM +0800, Yuao Ma wrote:
+ add_sym_4s ("split", GFC_ISYM_SPLIT, CLASS_IMPURE,
+ BT_UNKNOWN, 0, GFC_STD_F2023,
+ gfc_check_split, NULL, gfc_resolve_split,
+
e any issues. Users will still have the flexibility to choose their
preferred method.
Please take a look when you have a moment!
Thanks,
YuaoFrom 3fb261141dbc61296adb9c9361bafcd9922ad8bd Mon Sep 17 00:00:00 2001
From: Yuao Ma
Date: Sat, 26 Jul 2025 20:59:26 +0800
Subject: [PATCH] fortran: imp
Hi Steve,
On 7/20/2025 11:06 AM, Steve Kargl wrote:
On Sun, Jul 20, 2025 at 12:39:00AM +0800, Yuao Ma wrote:
On 7/18/2025 11:43 PM, Yuao Ma wrote:
I noticed that hex(16128084538487209988) evaluates to
0xdfd27774, and it looks like the higher bits weren't being
zeroed out as exp
On 7/18/2025 11:43 PM, Yuao Ma wrote:
I noticed that hex(16128084538487209988) evaluates to
0xdfd27774, and it looks like the higher bits weren't being
zeroed out as expected. After I explicitly added pos =
convert(gfc_charlen_type_node, pos); for type conversion, the test
Hi Tobias,
On 7/18/2025 3:16 PM, Tobias Burnus wrote:
I am wondering whether we should implement it – for kind=1 (and at
least for set len=1) by a call to BUILT_IN_MEMCHR / BUILT_IN_MEMRCHR.
For set len > 1, a loop around it has to be generated, and for kind=4,
it could be implemented manual
Hi Mikael,
On 7/18/2025 3:26 PM, Mikael Morin wrote:
Le 17/07/2025 à 15:58, Yuao Ma a écrit :
Hi Mikael,
On 7/17/2025 3:47 PM, Mikael Morin wrote:
How did you declare gfor_fndecl_string_split?
More exactly what is the declaration type for the POS argument?
For the POS argument type, I&#
Hi Mikael,
On 7/17/2025 3:47 PM, Mikael Morin wrote:
How did you declare gfor_fndecl_string_split?
More exactly what is the declaration type for the POS argument?
For the POS argument type, I'm using
build_pointer_type(gfc_charlen_type_node). I got this from
string_minmax, but I'm unsure if
On 7/8/2025 2:03 AM, Steve Kargl wrote:
On Sun, Jul 06, 2025 at 09:09:53PM +0800, Yuao Ma wrote:
Hi Tobias,
On 7/6/2025 6:34 PM, Tobias Burnus wrote:
As that commit is from 2020 and 2.69 in from 2012, it seems as if your
autoconf is too new. Can you re-check that the right version is at
rsion to create a new patch. Hope this looks good
to you.
YuaoFrom 2d62a2f707e43f37b4d886b7ed3aa40f2ab62437 Mon Sep 17 00:00:00 2001
From: Yuao Ma
Date: Sun, 6 Jul 2025 20:55:08 +0800
Subject: [PATCH] libgfortran: add fallback for trigonometric pi-based
functions
This patch introduces a fal
On 7/6/2025 12:49 PM, Steve Kargl wrote:
On Sun, Jul 06, 2025 at 08:43:06AM +0800, Yuao Ma wrote:
Hi Steve,
On 7/6/2025 12:25 AM, Steve Kargl wrote:
On Sat, Jul 05, 2025 at 05:20:02PM +0800, Yuao Ma wrote:
diff --git a/libgfortran/configure b/libgfortran/configure
index 9898a94a372
Hi Steve,
On 7/6/2025 12:25 AM, Steve Kargl wrote:
On Sat, Jul 05, 2025 at 05:20:02PM +0800, Yuao Ma wrote:
diff --git a/libgfortran/configure b/libgfortran/configure
index 9898a94a372..971f1e9df5e 100755
--- a/libgfortran/configure
+++ b/libgfortran/configure
@@ -16413,7 +16413,7 @@ else
this looks good, I will
address f128/r16 in a subsequent patch. (A related patch concerning
libquadmath is currently under review.)
Thanks,
YuaoFrom f8f2031e5e4bcd03e7382342907334cd33dd2ec6 Mon Sep 17 00:00:00 2001
From: Yuao Ma
Date: Sat, 5 Jul 2025 17:06:18 +0800
Subject: [PATCH] libgfortran
Hi all,
On 7/3/2025 9:21 PM, Jakub Jelinek wrote:
On Thu, Jul 03, 2025 at 02:43:43PM +0200, Michael Matz wrote:
Hello,
On Thu, 3 Jul 2025, Yuao Ma wrote:
This patch adds the required function for Fortran trigonometric functions to
work with glibc versions prior to 2.26. It's based on
ake a look when you have a moment.
Best regards,
YuaoFrom 46ed3a1817e87567a7510eb4ca918589afcc9c3c Mon Sep 17 00:00:00 2001
From: Yuao Ma
Date: Thu, 3 Jul 2025 00:40:58 +0800
Subject: [PATCH] libquadmath: add quad support for trig-pi functions
This function is required for Fortran trigonometric
Hi Jakub,
> signbit is documented to be a macro, so please don't declare
> int signbit (double);
> function in the testcase and instead of signbit use __builtin_signbit.
This is indeed my negligence. Done.
If everything looks good, could you please help me merge this patch? Thank you!
Yuao
0
Hi Jakub,
> Please don't include math.h here.
Done.
> And instead of this line use __builtin_acospi (0.5).
> and, in dejagnu for runtime tests we prefer __builtin_abort on failure, so
Done.
Yuao
0001-gcc-middle-end-opt-for-trigonometric-pi-based-functi.patch
Description: 0001-gcc-middle-en
Hi Jakub,
> I think the __builtin_constant_p(acospi(0.5)) approach is usable, but would
> be much better done on the lib/target-supports.exp side.
> So, have foldable_pi_based_trigonometry effective target, which would test
> if __builtin_constant_p(acospi(0.5)) is 1.
Thanks again for your helpfu
Hi Dave,
> but the testcases don't seem to be conditionalized on this. Would the
> new tests fail if gcc is built against an insufficiently recent version
> of mpfr, and is/should there be some kind of dg-requires for this, so
> that the new tests gracefully are "UNSUPPORTED" on such configuration
Hi all,
This patch, a follow-up to r16-1652-g0606d2b979f401, implements middle-end
optimizations (e.g., constant folding) for our trigonometric pi-based function
built-ins.
This patch is part of
https://gcc.gnu.org/pipermail/fortran/attachments/20250607/4a4a9cb6/attachment.obj
Please take a look
Hi all,
This patch, a follow-up to r16-1652-g0606d2b979f401, implements middle-end
optimizations (e.g., constant folding) for our trigonometric pi-based function
built-ins.
This patch is part of
https://gcc.gnu.org/pipermail/fortran/attachments/20250607/4a4a9cb6/attachment.obj
Please take a look
Hi Richard,
> OK.
>
> Thanks,
> Richard.
Thanks for the quick review! Could you please help me merge this patch? I'll
post the rest of the original patch soon.
Thanks,
Yuao
Hi all,
This patch addresses previous review feedback by splitting the atan handling
into a separate patch.
This patch is part of
https://gcc.gnu.org/pipermail/fortran/attachments/20250607/4a4a9cb6/attachment.obj
Please take a look when you are available. Thanks!
Best regards,
Yuao
0001-gcc-
Hi all,
This patch has been updated to conditionally fold the specified math functions
only when using MPFR version 4.2.0 or newer.
To accompany this change, the test case now utilizes `__builtin_constant_p` to
determine whether to execute the tests against the folded functions.
Let me know if t
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 Joseph,
> I don't see tests for the various special cases from Annex F (for example,
> "tanpi(n) returns +0, for positive even and negative odd integers n." and
> "tanpi(n) returns -0, for positive odd and negative even integers n.").
> In such cases the sign of zero would need to be checked sp
Hello world,
This patch partially handled PR118592.
This patch builds upon r16-710-g591d3d02664c7b and r16-711-g89935d56f768b4. It
introduces middle-end optimizations, such as constant folding, for our
trigonometric pi-based function built-ins.
For MPFR versions older than 4.2.0, we've included
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,
> 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
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
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 you're referring to.
If it's mathbuiltins.def, I'll need to add extra spa
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
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 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
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-patc...@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
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 +
, May 15, 2025 0:47
To: Yuao Ma
Cc: gcc-patc...@gcc.gnu.org ; fortran@gcc.gnu.org
; tbur...@baylibre.com
Subject: Re: [PATCH] gcc: add trigonometric pi-based functions as gcc builtins
On Wed, 14 May 2025, Yuao Ma wrote:
> Hi all,
>
> This patch adds trigonometric pi-based functio
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 implementations.
The patch includes two test cases to verify
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
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 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 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 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
Dear gfortran developers,
I have uploaded a draft proposal for the 'Fortran – 2018/202x' project to the
platform. You can also find a PDF version at this Google Drive link:
https://drive.google.com/file/d/1cSRPuWpXWHMwHdNItQluEYspLfylqZcU.
Could you please review the proposal and provide feedback
Hi GCC developers,
I'm sharing the draft proposal for my GSoC project titled "Fortran 2018/202x".
It has already been posted on the Fortran mailing list, where I received
valuable feedback from gfortran developers.
As mentioned on the GCC GSoC page, proposals should also be shared on the GCC
mail
Hi Steve,
Thank you for your prompt feedback on my initial proposal. I understand that it
lacked sufficient detail regarding the implementation approach. I have since
updated the proposal with a more comprehensive explanation. When you have a
moment, I would greatly appreciate it if you could take
Hi Steve,
Thank you sincerely for explaining the implementation and project details. I
will draft the proposal shortly and would appreciate discussing refinements
with you before the deadline.
Yuao
From: Steve Kargl
Sent: Friday, March 28, 2025 1:35
To: Yuao Ma
available to mentor this project?
Thanks!
Yuao
From: Steve Kargl
Sent: Thursday, March 27, 2025 2:15
To: Yuao Ma
Cc: fortran@gcc.gnu.org
Subject: Re: GSoC Fortran – 2018/202x – Inquiry About Project Scope
Yuao,
I do not intend to be a mentor. I will however answer
: Yuao Ma
Cc: fortran@gcc.gnu.org
Subject: Re: GSoC Fortran – 2018/202x – Inquiry About Project Scope
I've already written a prototype of the half-cycle trig
functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
There are two issues that need to be address. First, some
oper
Hello GCC Community,
I hope this message finds you well. My name is Yuao, and I’m excited to express
my interest in the "Fortran – 2018/202x" project for Google Summer of Code. I’m
writing to clarify the scope of this project and gather any recommendations you
may have.
>From the project document
Hello GCC Community,
My name is Yuao, and I’m excited to express my interest in the
“Fortran – 2018/202x” project for Google Summer of Code. I am majoring in Cyber
Science and Engineering, with a solid background in computer science that I
believe will help me contribute effectively to this projec
Hello GCC Community,
My name is Yuao, and I’m excited to express my interest in the “Fortran –
2018/202x” project for Google Summer of Code. I am majoring in Cyber Science
and Engineering, with a solid background in computer science that I believe
will help me contribute effectively to this pro
86 matches
Mail list logo
