Re: GCC GSoC 2024: Call for project ideas and mentors
Hello, this is just a reminder that the organization application period of GSoC 2024 closes on Tuesday February 6th (6pm UTC). We have already applied but that is when we are expected to have our project idea list basically ready. So please review old ideas and if you have a new one and/or would like to be a mentor, please speak up. Thanks, Martin On Mon, Jan 15 2024, Martin Jambor wrote: [...] > 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
GPU offloading question
All, Suppose one is working in a funding-constrained environment such as an academician with limited grant funding. If one wanted to dabble in GPU offloading with gcc/gfortran, what recommendations would one have for minimum required hardware? In addition, are there any vendor software layers that are required (such as AMD ROCm with an AMD GPU)? -- Steve
Re: [patch, libgfortran] PR111022 ES0.0E0 format gave ES0.dE0 output with d too high.
On 1/30/24 12:36 PM, Harald Anlauf wrote:
Hi Jerry,
Am 30.01.24 um 19:15 schrieb Jerry D:
The attached patch attempts to fix the handling of the EN0.0E0 and
ES0.0E0 formatting by correctly calculating the number of digits needed
for the exponents and building those exponents into the float string.
while your patch addresses ENw.dE0 and ESw.dE0 formatting,
it does not fix Ew.dE0, which can be seen with the following test:
write(buffer,"(E0.3E0)") .6660_4
print *, buffer
write(buffer,"(E0.3)") .6660_4
print *, buffer
I get even with your patch:
0.666
0.666
but would have expected:
0.666E+0 ! F2018 & F2023, table 13.1
0.666E+0 ! F2023, table 13.1
Tha attached file shows the complete revised patch and git log generated
by using the 'git show' command. I only just discovered that one. (eye
roll).
Regressions tested on x86-64. OK for trunk?
Regards,
Jerry
commit 95c878a97944f952aef226ff0224b2198abfbe0f
Author: Jerry DeLisle
Date: Fri Feb 2 18:12:33 2024 -0800
libgfortran: EN0.0E0 and ES0.0E0 format editing.
PR libgfortran/111022
F2018 and F2023 standards added zero width exponents. This required
additional special handing in the process of building formatted
floating point strings.
G formatting uses either F or E formatting as documented in
write_float.def comments. This logic changes the format token from FMT_G
to FMT_F or FMT_E. The new formatting requirements interfere with this
process when a FMT_G float string is being built. To avoid this, a new
component called 'pushed' is added to the fnode structure to save this
condition. The 'pushed' condition is then used to bypass portions of
the new ES,E,EN, and D formatting, falling through to the existing
default formatting which is retained.
libgfortran/ChangeLog:
* io/format.c (get_fnode): Update initialization of fnode.
(parse_format_list): Initialization.
* io/format.h (struct fnode): Added the new 'pushed' component.
* io/write.c (select_buffer): Whitespace.
(write_real): Whitespace.
(write_real_w0): Adjust logic for the d == 0 condition.
* io/write_float.def (determine_precision): Whitespace.
(build_float_string): Calculate width of ..E0 exponents and
adjust logic accordingly.
(build_infnan_string): Whitespace.
(CALCULATE_EXP): Whitespace.
(quadmath_snprintf): Whitespace.
(determine_en_precision): Whitespace.
gcc/testsuite/ChangeLog:
* gfortran.dg/fmt_error_10.f: Show D+0 exponent.
* gfortran.dg/pr96436_4.f90: Show E+0 exponent.
* gfortran.dg/pr96436_5.f90: Show E+0 exponent.
* gfortran.dg/pr111022.f90: New test.
diff --git a/gcc/testsuite/gfortran.dg/fmt_error_10.f b/gcc/testsuite/gfortran.dg/fmt_error_10.f
index 6e1a5f60bea..fc6620a60a6 100644
--- a/gcc/testsuite/gfortran.dg/fmt_error_10.f
+++ b/gcc/testsuite/gfortran.dg/fmt_error_10.f
@@ -18,7 +18,7 @@
str = '(1pd0.15)'
write (line,str,iostat=istat, iomsg=msg) 1.0d0
- if (line.ne."1.000") STOP 5
+ if (line.ne."1.000D+0") STOP 5
read (*,str,iostat=istat, iomsg=msg) x
if (istat.ne.5006 .or. msg(1:10).ne."Zero width") STOP 6
if (x.ne.555.25) STOP 7
diff --git a/gcc/testsuite/gfortran.dg/pr111022.f90 b/gcc/testsuite/gfortran.dg/pr111022.f90
new file mode 100644
index 000..eef55ff5ce0
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr111022.f90
@@ -0,0 +1,72 @@
+! { dg-do run }
+program pr111022
+ character(20) :: buffer
+ write(buffer,"(EN0.3E0)") .6660_4
+ if (buffer.ne."666.000E-3") stop 1
+ write(buffer,"(EN0.3E0)") 6.660_4
+ if (buffer.ne."6.660E+0") stop 2
+ write(buffer,"(EN0.3E0)") 66.60_4
+ if (buffer.ne."66.600E+0") stop 3
+ write(buffer,"(EN0.3E0)") 666.0_4
+ if (buffer.ne."666.000E+0") stop 4
+ write(buffer,"(EN0.3E0)") 6660.0_4
+ if (buffer.ne."6.660E+3") stop 5
+ write(buffer,"(EN0.3E0)") 66600.0_4
+ if (buffer.ne."66.600E+3") stop 6
+
+ write(buffer,"(EN0.0E0)") 666.0_4
+ if (buffer.ne."666.E+0") stop 7
+ write(buffer,"(EN0.0E1)") 666.0_4
+ if (buffer.ne."666.E+0") stop 8
+ write(buffer,"(EN0.0E2)") 666.0_4
+ if (buffer.ne."666.E+00") stop 9
+ write(buffer,"(EN0.0E3)") 666.0_4
+ if (buffer.ne."666.E+000") stop 10
+ write(buffer,"(EN0.0E4)") 666.0_4
+ if (buffer.ne."666.E+") stop 11
+ write(buffer,"(EN0.0E5)") 666.0_4
+ if (buffer.ne."666.E+0") stop 12
+ write(buffer,"(EN0.0E6)") 666.0_4
+ if (buffer.ne."666.E+00") stop 13
+
+ write(buffer,"(ES0.3E0)") .6660_4
+ if (buffer.ne."6.660E-1") stop 14
+ write(buffer,"(ES0.3E0)") 6.660_4
+ if (buffer.ne."6.660E+0") stop 15
+ write(buffer,"(ES0.3E0)") 66.60_4
+ if (buffer.ne."6.660E+1") stop 16
+ write(buffer,"(ES0.3E0)") 666.0_4
+ if (buffer.ne."6.660E+2") stop 17
+ write(b
Re: [patch, libgfortran] PR111022 ES0.0E0 format gave ES0.dE0 output with d too high.
Jerry,
The patch looks good to me, but please give Harald a chance
to comment.
--
steve
On Fri, Feb 02, 2024 at 07:17:55PM -0800, Jerry D wrote:
> On 1/30/24 12:36 PM, Harald Anlauf wrote:
> > Hi Jerry,
> >
> > Am 30.01.24 um 19:15 schrieb Jerry D:
> > > The attached patch attempts to fix the handling of the EN0.0E0 and
> > > ES0.0E0 formatting by correctly calculating the number of digits needed
> > > for the exponents and building those exponents into the float string.
> >
> > while your patch addresses ENw.dE0 and ESw.dE0 formatting,
> > it does not fix Ew.dE0, which can be seen with the following test:
> >
> > write(buffer,"(E0.3E0)") .6660_4
> > print *, buffer
> > write(buffer,"(E0.3)") .6660_4
> > print *, buffer
> >
> > I get even with your patch:
> >
> > 0.666
> > 0.666
> >
> > but would have expected:
> >
> > 0.666E+0 ! F2018 & F2023, table 13.1
> > 0.666E+0 ! F2023, table 13.1
> >
>
> Tha attached file shows the complete revised patch and git log generated by
> using the 'git show' command. I only just discovered that one. (eye roll).
>
> Regressions tested on x86-64. OK for trunk?
>
> Regards,
>
> Jerry
> commit 95c878a97944f952aef226ff0224b2198abfbe0f
> Author: Jerry DeLisle
> Date: Fri Feb 2 18:12:33 2024 -0800
>
> libgfortran: EN0.0E0 and ES0.0E0 format editing.
>
> PR libgfortran/111022
>
> F2018 and F2023 standards added zero width exponents. This required
> additional special handing in the process of building formatted
> floating point strings.
>
> G formatting uses either F or E formatting as documented in
> write_float.def comments. This logic changes the format token from FMT_G
> to FMT_F or FMT_E. The new formatting requirements interfere with this
> process when a FMT_G float string is being built. To avoid this, a new
> component called 'pushed' is added to the fnode structure to save this
> condition. The 'pushed' condition is then used to bypass portions of
> the new ES,E,EN, and D formatting, falling through to the existing
> default formatting which is retained.
>
> libgfortran/ChangeLog:
>
> * io/format.c (get_fnode): Update initialization of fnode.
> (parse_format_list): Initialization.
> * io/format.h (struct fnode): Added the new 'pushed' component.
> * io/write.c (select_buffer): Whitespace.
> (write_real): Whitespace.
> (write_real_w0): Adjust logic for the d == 0 condition.
> * io/write_float.def (determine_precision): Whitespace.
> (build_float_string): Calculate width of ..E0 exponents and
> adjust logic accordingly.
> (build_infnan_string): Whitespace.
> (CALCULATE_EXP): Whitespace.
> (quadmath_snprintf): Whitespace.
> (determine_en_precision): Whitespace.
>
> gcc/testsuite/ChangeLog:
>
> * gfortran.dg/fmt_error_10.f: Show D+0 exponent.
> * gfortran.dg/pr96436_4.f90: Show E+0 exponent.
> * gfortran.dg/pr96436_5.f90: Show E+0 exponent.
> * gfortran.dg/pr111022.f90: New test.
>
> diff --git a/gcc/testsuite/gfortran.dg/fmt_error_10.f
> b/gcc/testsuite/gfortran.dg/fmt_error_10.f
> index 6e1a5f60bea..fc6620a60a6 100644
> --- a/gcc/testsuite/gfortran.dg/fmt_error_10.f
> +++ b/gcc/testsuite/gfortran.dg/fmt_error_10.f
> @@ -18,7 +18,7 @@
>
>str = '(1pd0.15)'
>write (line,str,iostat=istat, iomsg=msg) 1.0d0
> - if (line.ne."1.000") STOP 5
> + if (line.ne."1.000D+0") STOP 5
>read (*,str,iostat=istat, iomsg=msg) x
>if (istat.ne.5006 .or. msg(1:10).ne."Zero width") STOP 6
>if (x.ne.555.25) STOP 7
> diff --git a/gcc/testsuite/gfortran.dg/pr111022.f90
> b/gcc/testsuite/gfortran.dg/pr111022.f90
> new file mode 100644
> index 000..eef55ff5ce0
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/pr111022.f90
> @@ -0,0 +1,72 @@
> +! { dg-do run }
> +program pr111022
> + character(20) :: buffer
> + write(buffer,"(EN0.3E0)") .6660_4
> + if (buffer.ne."666.000E-3") stop 1
> + write(buffer,"(EN0.3E0)") 6.660_4
> + if (buffer.ne."6.660E+0") stop 2
> + write(buffer,"(EN0.3E0)") 66.60_4
> + if (buffer.ne."66.600E+0") stop 3
> + write(buffer,"(EN0.3E0)") 666.0_4
> + if (buffer.ne."666.000E+0") stop 4
> + write(buffer,"(EN0.3E0)") 6660.0_4
> + if (buffer.ne."6.660E+3") stop 5
> + write(buffer,"(EN0.3E0)") 66600.0_4
> + if (buffer.ne."66.600E+3") stop 6
> +
> + write(buffer,"(EN0.0E0)") 666.0_4
> + if (buffer.ne."666.E+0") stop 7
> + write(buffer,"(EN0.0E1)") 666.0_4
> + if (buffer.ne."666.E+0") stop 8
> + write(buffer,"(EN0.0E2)") 666.0_4
> + if (buffer.ne."666.E+00") stop 9
> + write(buffer,"(EN0.0E3)") 666.0_4
> + if (buffer.ne."666.E+000") stop 10
> + write(buffer,"(EN0.0E4)") 666.0_4
> + if (buffer.ne."666.E+") stop 11
> + write(bu
