GCC GSoC 2022: Call for project ideas and mentors
Hello, another year is upon us and Google has announced there will be again Google Summer of Code 2022 (though AFAIK there is no specific timeline yet). I'd like to volunteer to be the main Org Admin for GCC again so let me know if you think I shouldn't or that someone else should, but otherwise I'll assume that I will. There will be a few important changes to the GSoC this year. The most important for us is that there will be two project sizes: medium-sized projects which are expected to take about 175 hours to complete and large projects expected to take approximately 350 hours (the size from 2020 and earlier). I expect that most of our projects will be large but I think we can offer one or two medium-sized ideas too. Google will also increase timing flexibility, so the projects can run for longer (up to 22 weeks) allowing mentors to go on vacation and students to pause and focus on exams. Talking about students, Google is going to open the program to all adults, so from now on, the participants working on the projects will be called GSoC contributors. Slightly more information about these changes can be found at https://opensource.googleblog.com/2021/11/expanding-google-summer-of-code-in-2022.html I am sure we will learn more when the actual timeline is announced too. The most important bit: Even before that happens, I would like to ask all (moderately) seasoned GCC contributors to consider mentoring a student 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. = Eventually, each listed project idea should have a) a project title/description, b) more detailed description of the project (2-5 sentences), c) expected outcomes, d) skills required/preferred, e) project size and difficulty and f) 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. 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 always do. So far I think all of them enjoyed working with us, even if many sometimes struggled with GCC's complexity. I will update you as more details about GSoC 2022 become available. Thank you, let's hope we attract some new talent again this year. Martin
Re: [PATCH] Fortran: Fix ICE in argument_rank_mismatch [PR103287]
Am 05.01.22 um 22:34 schrieb Sandra Loosemore: One of my previous TS29113-related patches from last fall introduced an ICE due to a bogus assertion. This is the fix Steve suggested in the issue, bundled with the test cases, regression-tested, etc. OK to check in? OK. -Sandra Thanks, Harald
Re: [PATCH] PR fortran/103777 - ICE in gfc_simplify_maskl, at fortran/simplify.c:4918
Hi Mikael, Am 21.12.21 um 13:38 schrieb Mikael Morin: Le 20/12/2021 à 23:05, Harald Anlauf via Fortran a écrit : Dear all, we need to check the arguments of the elemental MASKL and MASKR intrinsics also before simplifying. Testcase by Gerhard. The fix is almost obvious, but I'm happy to get feedback in case there is something I overlooked. (There is already a check on scalar arguments to MASKL/MASKR, which however misses the case of array arguments.) Regtested on x86_64-pc-linux-gnu. OK for mainline? Your patch looks reasonable and safe. However, I find it surprising that it’s actually needed, as gfc_check mask is already the check function associated to maskl and maskr in the definition of the symbols. The simplification function should be called only when the associated check function has returned successfully, so it shouldn’t be necessary to call it again at simplification time. Looking at the backtrace, it is the do_simplify call at the beginning of gfc_intrinsic_func_interface that seems dubious to me, as it comes before all the check further down in the function and it looks redundant with the other simplification code after the checks. So I’m inclined to test whether by any chance removing that call works, and if it doesn’t, let’s go with this patch. Did you find the time to try your version? Mikael Thanks, Harald
Re: [power-ieee128] RFH: LTO broken
On 06.01.22 06:00, Michael Meissner via Fortran wrote: I pushed the patch to the branch. Test results are looking quite good right now. What is still missing is the conversion for unformatted I/O, both ways. I'll start doing some stuff on it. Just one question: What are functions that I can use to convert from IBM long double to IEEE and long double and vice versa? It was in an e-mail somewhere, but I cannot find it at the moment. Best regards Thomas
Re: [power-ieee128] RFH: LTO broken
On Thu, Jan 06, 2022 at 09:01:54PM +0100, Thomas Koenig wrote:
> On 06.01.22 06:00, Michael Meissner via Fortran wrote:
> > I pushed the patch to the branch.
>
> Test results are looking quite good right now.
>
> What is still missing is the conversion for unformatted I/O, both
> ways. I'll start doing some stuff on it. Just one question:
> What are functions that I can use to convert from IBM long double
> to IEEE and long double and vice versa? It was in an e-mail somewhere,
> but I cannot find it at the moment.
Under the hood __extendkftf2 and __trunctfkf2, as can be seen on:
__ibm128 foo (__float128 x) { return x; }
__float128 bar (__ibm128 x) { return x; }
But, I really don't think libgfortran should call those by hand, just
use C casts, (GFC_REAL_17) var_with_GFC_REAL_16_type or
(GFC_REAL_16) var_with_GFC_REAL_17_type.
Jakub
[PATCH] Fortran: Fix handling of optional argument to SIZE intrinsic [PR103898]
This patch fixes an ICE introduced with the recent-ish rewrite to inline
the SIZE intrinsic, using a helper function to do the bulk of the work
in producing the expansion. It turns out to be a simple think-o type
mistake in the wrapper around the helper rather than anything deeply
wrong with the logic.
OK to check in?
-Sandra
commit 0e5b74440572f988dd96a6e9c33c11b59323d6cf
Author: Sandra Loosemore
Date: Thu Jan 6 11:23:18 2022 -0800
Fortran: Fix handling of optional argument to SIZE intrinsic [PR103898]
This patch fixes a think-o in the code that triggered an ICE
in the test case.
2021-01-06 Sandra Loosemore
gcc/fortran/
* trans-intrinsic.c (gfc_conv_intrinsic_size): Make size_var
actually be a variable and fix surrounding code.
gcc/testsuite/
* gfortran.dg/pr103898.f90: New test.
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 41252c9..aae34b0 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -8006,10 +8006,14 @@ gfc_conv_intrinsic_size (gfc_se * se, gfc_expr * expr)
cond = gfc_evaluate_now (cond, &se->pre);
/* 'block2' contains the arg2 absent case, 'block' the arg2 present
case; size_var can be used in both blocks. */
- tree size_var = gfc_tree_array_size (&block2, arg1, e, NULL_TREE);
+ tree size_var = gfc_create_var (TREE_TYPE (size), "size");
tmp = fold_build2_loc (input_location, MODIFY_EXPR,
TREE_TYPE (size_var), size_var, size);
gfc_add_expr_to_block (&block, tmp);
+ size = gfc_tree_array_size (&block2, arg1, e, NULL_TREE);
+ tmp = fold_build2_loc (input_location, MODIFY_EXPR,
+ TREE_TYPE (size_var), size_var, size);
+ gfc_add_expr_to_block (&block2, tmp);
tmp = build3_v (COND_EXPR, cond, gfc_finish_block (&block),
gfc_finish_block (&block2));
gfc_add_expr_to_block (&se->pre, tmp);
diff --git a/gcc/testsuite/gfortran.dg/pr103898.f90 b/gcc/testsuite/gfortran.dg/pr103898.f90
new file mode 100644
index 000..6b4bb30
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr103898.f90
@@ -0,0 +1,15 @@
+! { dg-do compile }
+
+! This test used to ICE during gimplification (PR103898).
+
+Module g
+contains
+ function mysize(array, dim)
+integer :: mysize
+integer, dimension(:), intent(in) :: array
+integer, optional, intent(in) :: dim
+if (present(dim)) then
+ mysize = size(array, dim=dim)
+endif
+ end function mysize
+end module
Re: [PATCH] Fortran: Fix handling of optional argument to SIZE intrinsic [PR103898]
Hi Sandra, Am 06.01.22 um 21:11 schrieb Sandra Loosemore: This patch fixes an ICE introduced with the recent-ish rewrite to inline the SIZE intrinsic, using a helper function to do the bulk of the work in producing the expansion. It turns out to be a simple think-o type mistake in the wrapper around the helper rather than anything deeply wrong with the logic. OK to check in? LGTM. -Sandra Thanks for addressing this swiftly!
Re: [PATCH] PR fortran/103777 - ICE in gfc_simplify_maskl, at fortran/simplify.c:4918
Le 06/01/2022 à 20:50, Harald Anlauf a écrit : Did you find the time to try your version? Not yet. But I have not (yet) forgotten about this.
