Re: GCC GSoC 2024: Call for project ideas and mentors
Hi Martin, On 1/15/24 18:48, Martin Jambor wrote: Hello, another year has passed, Google has announced there will be again Google Summer of Code (GsoC) in 2024 and the deadline for organizations to apply is already approaching (February 6th). I'd like to volunteer to be the main org-admin for GCC again but let me know if you think I shouldn't or that someone else should or if you want to do it instead. Otherwise I'll assume that I will and I hope that I can continue to rely on David Edelsohn and Thomas Schwinge to back me up and help me with some decision making along the way as my co-org-admins. I think that'd be good :) we've really appreciated all the work you've done for the past editions. We'll be discussing project ideas with the rest of the gccrs team and will update the page shortly. We'd love to mentor again this year. Thanks for getting in touch, Best, Arthur The most important bit: I would like to ask all (moderately) seasoned GCC contributors to consider mentoring a contributor this year and ideally also come up with a project that they would like to lead. I'm collecting proposal on our wiki page https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours to the top list there. Or, if you are unsure, post your offer and project idea as a reply here to the mailing list. Additionally, if you have added an idea to the list in the recent years, please review it whether it is still up-to-date or needs adjusting or should be removed altogether. = At this point, we need to collect list of project ideas. Eventually, each listed project idea should have: a) a project title, b) more detailed description of the project (2-5 sentences), c) expected outcomes (we do have a catch-almost-all formulation that outcome is generally patches at the bottom of the list on the wiki), d) skills required/preferred, e) project size - whether it is expected to take approximately 350, 175 or just 90 hours (the last option in new in 2024, see below), f) difficulty (easy, hard or medium, but we don't really have easy projects), and g) expected mentors. Project ideas that come without an offer to also mentor them are always fun to discuss, by all means feel free to reply to this email with yours and I will attempt to find a mentor, but please be aware that we can only use the suggestion it if we actually find one or ideally two. Everybody in the GCC community is invited to go over https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or otherwise bad project suggestions and help improve viable ones. Finally, please continue helping (prospective) students figure stuff out about GCC like you have always done in the past. As far as I know, GSoC 2024 should be quite similar to the last year, the most important parameters probably are these: - Contributors (formerly students) must either be full-time students or be "beginners to open source." - There are now three project sizes: roughly 90 hors (small), roughly 175 hours (medium-sized) and roughly 350 hours (large) of work in total. The small option is new this year but because our projects usually have a lengthy learning period, I think we will usually want to stick to the medium and large variants. - Timing should be pretty much as flexible as last year. The recommended "standard" duration is 12 weeks but depending on contributor's and mentor's needs and circumstances, projects can take anywhere between 10 and 22 weeks. There will be one mid-term and one final evaluation. For further details you can see: - The announcement of GSoC 2024: https://opensource.googleblog.com/2023/11/google-summer-of-code-2024-celebrating-20th-year.html - GSoC rules: https://summerofcode.withgoogle.com/rules - The detailed GSoC 2024 timeline: https://developers.google.com/open-source/gsoc/timeline - Elaborate project idea guidelines: https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list Thank you very much for your participation and help. Let's hope we attract some great contributors again this year. Martin -- Arthur Cohen Toolchain Engineer Embecosm GmbH Geschäftsführer: Jeremy Bennett Niederlassung: Nürnberg Handelsregister: HR-B 36368 www.embecosm.de Fürther Str. 27 90429 Nürnberg Tel.: 091 - 128 707 040 Fax: 091 - 128 707 077 OpenPGP_0x1B3465B044AD9C65.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
[PATCH] fortran: Restore current interface info on error [PR111291]
Hello,
I tested this on x86_64-pc-linux-gnu without regression.
There is no new test, as the problem is visible on an
existing test with valgrind or an asan-instrumented compiler.
OK for master?
-- >8 --
This change is a followup to the fix for PR48776 (namely
r14-3572-gd58150452976c4ca65ddc811fac78ef956fa96b0 AKA
fortran: Restore interface to its previous state on error [PR48776]),
which cleaned up new changes from interfaces upon error.
Unfortunately, there is one case in that fix that is mishandled, visible
on unexpected_interface.f90 with valgrind or an asan-instrumented gfortran.
when an interface statement is found while parsing an interface body (which
is invalid), the current interface is replaced by the one from the new
statement, and as parsing continues, new procedures are added
to the new interface, which has been rejected and freed, instead of the
original one.
This change restores the current interface pointer to its previous value
on each rejected statement.
PR fortran/48776
PR fortran/111291
gcc/fortran/ChangeLog:
* parse.cc: Restore current interface to its previous value on error.
---
gcc/fortran/parse.cc | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index abd3a424f38..51e89e10e2d 100644
--- a/gcc/fortran/parse.cc
+++ b/gcc/fortran/parse.cc
@@ -4033,6 +4033,7 @@ loop:
default:
gfc_error ("Unexpected %s statement in INTERFACE block at %C",
gfc_ascii_statement (st));
+ current_interface = save;
reject_statement ();
gfc_free_namespace (gfc_current_ns);
goto loop;
--
2.43.0
Re: [PATCH] fortran: Restore current interface info on error [PR111291]
On Fri, Jan 19, 2024 at 06:47:36PM +0100, Mikael Morin wrote: > > I tested this on x86_64-pc-linux-gnu without regression. > There is no new test, as the problem is visible on an > existing test with valgrind or an asan-instrumented compiler. > OK for master? > Yes. After your explanation, the patch looks trivially obvious! :-) Thanks for the patch. -- Steve
[PATCH, committed] Fortran: fix wrong array bounds check [PR113471]
Dear all,
I've pushed the attached obvious patch for a regression due to a
wrong array bounds check after regtesting on x86_64-pc-linux-gnu
and verification of the fix by the reporter in the PR.
https://gcc.gnu.org/g:94b2e6cb1cc4feb122bf77f19a657c97bffa9b42
Thanks,
Harald
From 94b2e6cb1cc4feb122bf77f19a657c97bffa9b42 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 19 Jan 2024 21:20:44 +0100
Subject: [PATCH] Fortran: fix wrong array bounds check [PR113471]
gcc/fortran/ChangeLog:
PR fortran/113471
* trans-array.cc (array_bound_check_elemental): Array bounds check
shall apply here to elemental dimensions of an array section only.
gcc/testsuite/ChangeLog:
PR fortran/113471
* gfortran.dg/bounds_check_24.f90: New test.
---
gcc/fortran/trans-array.cc| 2 +-
gcc/testsuite/gfortran.dg/bounds_check_24.f90 | 28 +++
2 files changed, 29 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/bounds_check_24.f90
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 26e7adaa03f..878a92aff18 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -3600,7 +3600,7 @@ array_bound_check_elemental (gfc_se * se, gfc_ss * ss, gfc_expr * expr)
continue;
}
- if (ref->type == REF_ARRAY && ref->u.ar.dimen > 0)
+ if (ref->type == REF_ARRAY && ref->u.ar.type == AR_SECTION)
{
ar = &ref->u.ar;
for (dim = 0; dim < ar->dimen; dim++)
diff --git a/gcc/testsuite/gfortran.dg/bounds_check_24.f90 b/gcc/testsuite/gfortran.dg/bounds_check_24.f90
new file mode 100644
index 000..d0251e8455b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/bounds_check_24.f90
@@ -0,0 +1,28 @@
+! { dg-do compile }
+! { dg-additional-options "-fcheck=bounds -fdump-tree-original" }
+!
+! PR fortran/113471 - wrong array bounds check
+
+program pr113471
+ implicit none
+ type t
+ integer, dimension(2) :: c1 = 0
+ end type t
+ type(t) :: cc(7), bb(7)
+ integer :: kk = 1
+
+ ! no bounds check (can be determined at compile time):
+ call foo (cc(7)% c1)
+
+ ! bounds check involving kk, but no "outside of expected range"
+ call foo (bb(kk)% c1)
+
+contains
+ subroutine foo (c)
+integer, intent(in) :: c(:)
+ end
+end
+
+! { dg-final { scan-tree-dump-times "below lower bound" 2 "original" } }
+! { dg-final { scan-tree-dump-times "above upper bound" 2 "original" } }
+! { dg-final { scan-tree-dump-not "outside of expected range" "original" } }
--
2.35.3
