Re: [patch, libfortran] PR114618 Format produces incorrect output when contains 1x, ok when uses " "

[Jerry D]

Follow-up:

On 1/28/25 1:33 PM, Harald Anlauf wrote:

Jerry,

while I haven't read your actual patch yet, I think the testcase
is slightly incorrect. In fact, Intel, NAG, Nvidia and AMD flang
disagree with it.

Adding the following lines before the check with the STOP statement:

write(*,'(a)') output1
write(*,'(a)') output2
write (*, fmt1) 'RADIX', radix(pi)
write (*, fmt2) 'RADIX', radix(pi)

I get (e.g. with NAG):

RADIX.. 2
RADIX . 2
RADIX.. 2
RADIX . 2
STOP: 1

After your patch I get with gfc-15:

RADIX . 2
RADIX . 2
RADIX . 2
RADIX . 2

So I think the treatment of 1x is wrong: it should skip one position,
not write a blank here.

 >>>

F2023 13.8.1.3   X editing

The nX edit descriptor indicates that the transmission of the next
character to or from a record is to occur at
the character position n characters forward from the current position.

NOTE
An nX edit descriptor has the same effect as a TRn edit descriptor.

<<<

Cheers,
Harald


The following adjustment to the patch puts this right.

case FMT_X:
case FMT_TR:
  consume_data_flag = 0;
  dtp->u.p.skips += f->u.n;
  tab_pos = bytes_used + dtp->u.p.skips - 1;
  dtp->u.p.pending_spaces = tab_pos - dtp->u.p.max_pos + 1;
  dtp->u.p.pending_spaces = dtp->u.p.pending_spaces < 0
? f->u.n : dtp->u.p.pending_spaces;

  //if (t == FMT_X && tab_pos < dtp->u.p.max_pos)
  //{
//write_x (dtp, dtp->u.p.skips, dtp->u.p.pending_spaces);
//dtp->u.p.skips = dtp->u.p.pending_spaces = 0;
  //}

Interestingly, it also fixes a floating point exception I ran into while 
setting up another test case for part 2 of this effort. I suspect this 
may be what was detected by the auto patch tester.


I will clean this up, adjust the test case for this part and re-submit.

Regards,

Jerry

GCC GSoC 2025: Call for project ideas and mentors

[Martin Jambor]

Hello,

another year has passed, Google has announced there will be again Google
Summer of Code (GsoC) in 2025 and the deadline for organizations to
apply is already approaching (February 11th).  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.

 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.  We are 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 (see below about the last option),
  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 2025 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 was introduced in 2024 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 2025:

https://opensource.googleblog.com/2025/01/google-summer-of-code-2025-is-here.html

  - GSoC rules:
https://summerofcode.withgoogle.com/rules

  - The detailed GSoC 2025 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