Re: gcc.gnu.org performance issues?
On Sun, 16 Mar 2025, 22:16 Mark Wielaard, wrote: > Hi Harald, > > On Sun, Mar 16, 2025 at 10:57:08PM +0100, Harald Anlauf wrote: > > I have never tried any complex setups besides simple ssh tunnels > > with git in the past, so believe this does not apply. > > > > Doing even a simple ssh -Tvv to gcc.gnu.org takes a very long time > > when trying in parallel to the git command. And empirically this > > seems to happen only during a certain time of the day. > > That is really odd. If you are using ssh then there shouldn't be any > throtteling and you shouldn't really be affected by current http based > ddos. It might be your local network? > > I just did a clean clone of the whole gcc.git which took ~8 minutes > over http and ~5 minutes over ssh. So cloning/pulling over https is > certainly slower, but you should get reasonable speeds over https. > > > Regarding your comment on using github for fetching (and keeping > > gcc.gnu.org for push), the gcc website does not give a recommendation > > on how to use that in practice. Could we update > > https://gcc.gnu.org/about.html#git > > and/or > > https://gcc.gnu.org/gitwrite.html > > with best practices? > > I don't think anybody wants to recommend github for these things. > Right, it's not "best practice", I was suggesting it as an alternative because fetching from gcc.gnu.org is taking *hours* for you. That isn't happening for anybody else, so it doesn't seem worth putting in the docs. https://giveupgithub.com Also those aren't under our control. If you > really need a mirror then try the ones at https://forge.sourceware.org/ > or https://git.sr.ht/~sourceware/ which we keep up to date. > > Cheers, > > Mark >
Re: [PATCH] Fortran: check type-spec in ALLOCATE of dummy with assumed length [PR119338]
On 3/17/25 2:47 PM, Harald Anlauf wrote: Dear all, F2003:C626 was only partly implemented: we missed the case of ALLOCATE of character dummy arguments with assumed length, where the type-spec must use asterisk, i.e. (*). Regtesting found one testcase that had a previously undetected error and needed adjustment, which I chose such that the original error was kept. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald Yes, OK and thanks for the fix. Jerry
[PATCH] Fortran: check type-spec in ALLOCATE of dummy with assumed length [PR119338]
Dear all,
F2003:C626 was only partly implemented: we missed the case of ALLOCATE
of character dummy arguments with assumed length, where the type-spec
must use asterisk, i.e. (*).
Regtesting found one testcase that had a previously undetected error
and needed adjustment, which I chose such that the original error
was kept.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From b17beebd9c7c6475d7f89eef99c0075a562df0b8 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 17 Mar 2025 22:34:19 +0100
Subject: [PATCH] Fortran: check type-spec in ALLOCATE of dummy with assumed
length [PR119338]
PR fortran/119338
gcc/fortran/ChangeLog:
* resolve.cc (resolve_allocate_expr): Check F2003:C626: Type-spec
in ALLOCATE of an assumed-length character dummy argument shall be
an asterisk.
gcc/testsuite/ChangeLog:
* gfortran.dg/deferred_character_18.f90: Adjust testcase.
* gfortran.dg/allocate_assumed_charlen_5.f90: New test.
---
gcc/fortran/resolve.cc | 16
.../gfortran.dg/allocate_assumed_charlen_5.f90 | 17 +
.../gfortran.dg/deferred_character_18.f90 | 3 ++-
3 files changed, 35 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/allocate_assumed_charlen_5.f90
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index d64edff8507..ddd98270230 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -8987,6 +8987,22 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code, bool *array_alloc_wo_spec)
goto failure;
}
+ /* F2003:C626 (R623) A type-param-value in a type-spec shall be an asterisk
+ if and only if each allocate-object is a dummy argument for which the
+ corresponding type parameter is assumed. */
+ if (code->ext.alloc.ts.type == BT_CHARACTER
+ && code->ext.alloc.ts.u.cl->length != NULL
+ && e->ts.type == BT_CHARACTER && !e->ts.deferred
+ && e->ts.u.cl->length == NULL
+ && e->symtree->n.sym->attr.dummy)
+{
+ gfc_error ("The type parameter in ALLOCATE statement with type-spec "
+ "shall be an asterisk as allocate object %qs at %L is a "
+ "dummy argument with assumed type parameter",
+ sym->name, &e->where);
+ goto failure;
+}
+
/* Check F08:C632. */
if (code->ext.alloc.ts.type == BT_CHARACTER && !e->ts.deferred
&& !UNLIMITED_POLY (e))
diff --git a/gcc/testsuite/gfortran.dg/allocate_assumed_charlen_5.f90 b/gcc/testsuite/gfortran.dg/allocate_assumed_charlen_5.f90
new file mode 100644
index 000..bc75dbe47ad
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/allocate_assumed_charlen_5.f90
@@ -0,0 +1,17 @@
+! { dg-do compile }
+! PR fortran/119338 - check F2003:C626
+
+module m
+ implicit none
+contains
+ subroutine sub (s, c)
+character(len=*), allocatable, intent(out) :: s(:)
+character(len=*), allocatable, intent(out) :: c
+allocate(s(5)) ! OK
+allocate(c) ! OK
+allocate(character(len=*) :: s(5)) ! OK
+allocate(character(len=*) :: c)! OK
+allocate(character(len=10) :: s(5)) ! { dg-error "shall be an asterisk" }
+allocate(character(len=10) :: c)! { dg-error "shall be an asterisk" }
+ end subroutine sub
+end module m
diff --git a/gcc/testsuite/gfortran.dg/deferred_character_18.f90 b/gcc/testsuite/gfortran.dg/deferred_character_18.f90
index 1b1457fa293..b1229c2485e 100644
--- a/gcc/testsuite/gfortran.dg/deferred_character_18.f90
+++ b/gcc/testsuite/gfortran.dg/deferred_character_18.f90
@@ -11,7 +11,8 @@ contains
character(*), allocatable, intent(out) :: str
! Note: Star ^ should have been a colon (:)
-allocate (character(n)::str)
+! allocate (character(n)::str) ! original invalid version from pr82367
+allocate (character(*)::str) ! corrected (see F2003:C626 and pr119338)
end subroutine
--
2.43.0
Re: [GSoC] Proposal Discussion:Fortran – run-time argument checking
Hello,
we are delighted you found contributing to GCC interesting.
On Mon, Mar 03 2025, Gwen Fu via Gcc wrote:
> Dear GCC Community:
> I hope this email finds you well. My name is Gwen Fu(or Pengrui Fu), and I
> am interested in participating in Google Summer of Code 2025 with GCC. I am
> writing to discuss THIS PROJECT("Fortran – run-time argument checking")
> idea and seek your feedback before submitting my formal proposal.
>
> [My Background]
>I am a computer science sophomore at Harbin Engineering University,
> with experience in C/C++ programming, GDB debugging experience and
> Experience in programming under the Linux environment. I have manually
> implemented an HTTP server based on the Reactor pattern from scratch under
> Linux. Additionally, I participated in a domestic open-source competition
> in China and contributed to a project by developing a data conversion
> feature (JSON to Excel).
> Howerver , I must admit that, due to my school curriculum, I have not yet
> studied compiler theory. However, with a light academic workload this
> semester and the wealth of online resources—such as numerous compiler
> principle videos—I am confident I can learn the necessary compiler
> fundamentals for this project within the next month.
Well, while C/C++ coding skills are very important and GDB experience is
also basically essential, most projects, including this one, do require
some rudimentary theoretical background in compilers. This is a fairly
large and complex computer science area, learning it in a month is
likely to be quite a challenge.
At the very least, you need to learn about the concept of Intermediate
Representation (IR), often also called Intermediate Language (IL) as that is
what most project, including this one, work with and end up modifying.
All good introductory compiler books and courses do at some point explain the
concept but and googling "Intermediate Representation" seems to return some
good looking stuff.
Since I am not a Fortran front-end developer myself, I do not know at
what level of IR this particular project would be implemented, my guess
it is either GENERIC or GIMPLE (both somewhat described in our internals
manual bit they are perhaps better understood from the respective
compiler dumps).
>
> [My understanding ]
> The project requires developing an independent module. During development,
> attention should be paid to decoupling it from the rest of the repository's
> code while maintaining consistency with the original codebase's programming
> style.
I a not sure why you think that or even what you mean by this. The
project description does mention modules, but those are Fortran modules,
not anything in the compiler implementation (the Fortran Front-end is
written in C++, not in Fortran).
Consistency with the GCC coding style is important, but that is always
so.
>
> [Questions or Request]
> -When studying compiler principles, which aspects should I focus on?
With the limited time, as I wrote above, IR and the specific IRs nedded
for the task.
> - Before beginning the project, I will need to review the repository’s
> source code. Could you please advise which sections are especially
> well-crafted and worth examining closely?
You need to focus on the bits that you want to modify because gcc is
just too big. The Fortran front-end is in the gcc/fortran/
subdirectory. I'm CCing the Fortrn development mailing list, people
there may be better able to point you to the bits where calls are
handled.
Good luck!
Martin
Bug 119349 [15 Regression] polymorphic array dummy argument with function result actual argument in elemental function
With gfortran 12.4.0, 13.3.0, and 14.2.0, the program below prints "T". With gfortran 15, the program crashes with an error message that indicates that a pointer is being freed that was not allocated. % cat all.f90 implicit none type string_t character(len=:), allocatable :: string_ end type print *, true([string()]) contains type(string_t) function string() string%string_ = "" end function logical elemental function true(rhs) class(string_t), intent(in) :: rhs true = .true. end function end % gfortran all.f90 % ./a.out a.out(28435,0x209bdc840) malloc: *** error for object 0x62f98060: pointer being freed was not allocated a.out(28435,0x209bdc840) malloc: *** set a breakpoint in malloc_error_break to debug Program received signal SIGABRT: Process abort signal. Backtrace for this error: #0 0x1028d2563 #1 0x1028d14e3 #2 0x1a02a2de3 #3 0x1a026bf6f #4 0x1a0178907 #5 0x1a0081e37 #6 0x1a00859bb #7 0x1a00a4143 #8 0x102583bdf #9 0x102583daf zsh: abort ./a.out % gfortran --version GNU Fortran (GCC) 15.0.1 20250315 (experimental)
Re: [GSoC][Fortran – DO CONCURRENT] Interest in 2025 GSoC – Fortran DO CONCURRENT Auto-Parallelization
Hello, On Mon, Mar 10 2025, Zhang lv via Gcc wrote: > Hi here, > > I'm a Master of Computer Science student at the University of Melbourne. > Previously, I worked on implementing a GCC optimization prefetching pass > (which involved loop unrolling) for an Alpha-like computer architecture. > I'm set to complete my research project in July and graduate soon. great, that sounds you are definitely qualified. Is this prefething project available anywhere? > > I'm very interested in applying for the 2025 GSoC project and discussing > potential ideas with the community. However, I'm still unfamiliar with the > best way to engage in these discussions and apply for the project, so this > is my first attempt at reaching out. I think emailing g...@gcc.gnu.org and fortran@gcc.gnu.org is exactly the right thing to do. > > My primary interest is in projects related to auto-parallelization, > particularly the Fortran *DO CONCURRENT* project. Below, I outline my > initial understanding of the project and would appreciate any feedback from > the community to ensure I'm on the right track: > I am not a Fortran front-end developer but... >1. The *front-end parser* processes the Fortran *DO CONCURRENT* syntax >and converts it into a language-independent IR—*GIMPLE*. This sounds correct. The important bit, AFAIU, is that the IR would utilize a gimple statement for parallel execution that is so far created for OpenMP input. >2. The *middle-end* then applies tree optimizations, utilizing SSA >passes to optimize the code for auto-parallelization. Not necessarily, some OpenMP bits are processed in gimple form that is not yet in SSA. I also don't think any auto-parallelization is involved, the whole point of the task is to implement manual parallelization, I believe? >3. This project will involve both *front-end* work (parser and >parameterized command-line flags) and *middle-end* optimizations >(optimization passes). Right, though the middle end bits might be mostly about proper "lowering" rather than optimization. > > Loop unrolling is influenced by multiple factors, such as loop nesting and > whether iteration counts are deterministic. A significant performance gain > comes from reducing array memory access delays, which techniques like > prefetching can help with. Since *DO CONCURRENT* assumes iteration > independence, we have more flexibility to unroll loops and implement > parallelization efficiently. Frankly, I don't quite understand the above. If anything, I'd expect iteration independence makes unrolling much harder. But I fail to see how unrolling is in any way relevant. Good luck! Martin > > One of the most exciting advantages of this project is that it enables > auto-parallelization for a broader range of code without requiring > developers to be an OpenMP expert. *DO CONCURRENT* in Fortran is much > easier to use, and previous auto-parallelization techniques have been quite > limited in their applicability, as only specific loop structures could > benefit from them. > > I look forward to engaging with the community and gaining insights on how > best to contribute to this project. > > Best regards, > > Chenlu Zhang
[Fortran, Patch, PR119272, v1] Fix handling of class' component call in associate
Hi all,
when Harald attached this PR to the associate meta-bug, I immediately thought:
"Oh, this another one of these missing branches on ts.type == BT_CLASS
thingies". Well, I was wrong.
The issue is that the tbp (the typebound proc info structure) is not resolved
completely when the associate tries to do an early resolve to determine the
rank of the associate variable. When the expression to be resolved for that
contains a compcall, the resolve branches into the incorrect case and emits the
error. My current fix is to wait with generating the error message until the
type has been resolved completely (aka. symbol's resolve_symbol_called is set).
I am not sure, if this is correct, therefore CC'ing Paul, who, to my
knowledge, has more experience in the associate area. But everyone please feel
free to step in!
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 97eb018d0bc6f86d039d05d9e5d6be114f784c6d Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Mon, 17 Mar 2025 08:24:04 +0100
Subject: [PATCH] Fortran: Fix comp call in associate [PR119272]
PR fortran/119272
gcc/fortran/ChangeLog:
* resolve.cc (resolve_compcall): Postpone error report when
symbol is not resolved yet for component call resolve.
gcc/testsuite/ChangeLog:
* gfortran.dg/associate_74.f90: New test.
---
gcc/fortran/resolve.cc | 5 ++-
gcc/testsuite/gfortran.dg/associate_74.f90 | 47 ++
2 files changed, 50 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/associate_74.f90
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 34c8210f66a..a8ac42bcd77 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -7351,8 +7351,9 @@ resolve_compcall (gfc_expr* e, const char **name)
/* Check that's really a FUNCTION. */
if (!e->value.compcall.tbp->function)
{
- gfc_error ("%qs at %L should be a FUNCTION",
- e->value.compcall.name, &e->where);
+ if (e->symtree && e->symtree->n.sym->resolve_symbol_called)
+ gfc_error ("%qs at %L should be a FUNCTION", e->value.compcall.name,
+ &e->where);
return false;
}
diff --git a/gcc/testsuite/gfortran.dg/associate_74.f90 b/gcc/testsuite/gfortran.dg/associate_74.f90
new file mode 100644
index 000..057d63534c1
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/associate_74.f90
@@ -0,0 +1,47 @@
+!{ dg-do run }
+
+! Check that PR119272 is fixed
+! Contributed by Xing Jing Wei
+
+module pr119272_module
+ type, public :: test_type
+ contains
+ procedure :: scal_function
+ procedure :: arr_function
+ end type test_type
+ contains
+ function scal_function(this) result(smth)
+ class(test_type) :: this
+ integer :: smth
+ smth = 2
+ end function
+ function arr_function(this) result(smth)
+ class(test_type) :: this
+ integer :: smth(9)
+ smth = (/(i, i=1, 9)/)
+ end function
+end module
+
+program pr119272
+ use pr119272_module
+ implicit none
+
+ type(test_type) :: a
+
+ call test_subroutine(a)
+ contains
+ subroutine test_subroutine(a)
+class(test_type) :: a
+integer :: i
+integer,parameter :: temp_int(3) = [ 1, 2, 3]
+integer,parameter :: identity(9) = (/(i* 5, i= 9, 1, -1)/)
+associate(temp => temp_int(a%scal_function()))
+if (temp /= 2) stop 1
+end associate
+
+associate(temparr => identity(a%arr_function()))
+if (any(temparr /= (/(i* 5, i= 9, 1, -1)/))) stop 2
+end associate
+ end subroutine
+end program
+
--
2.48.1
[committed] Move gfortran.dg/gomp/declare-variant-mod-1*.f90 to libgomp.fortran/ [PR115271] (was: [Patch] Fortran: Store OpenMP's 'declare variant' in module file [PR115271])
H.J. Lu wrote:
gfortran: fatal error: cannot read spec file 'libgomp.spec': No such
file or directory
...
FAIL: gfortran.dg/gomp/declare-variant-mod-1.f90 -O (test for excess errors)
The problem is that dg-additional-sources does not work with '-o' with
dg-compile ("-c") as more than one file is involved.
But while 'dg-do link' solves the '-c -o' issue, a testcase that is
supposed to compile successfully (no dg-error) will actually invoke the
linker, which has issues with -fopenmp (implies the attempt to link
libgomp).
(This issue does not manifest for in-tree testing when the system
provides what is needed.)
Committed as r15-8085-g2d5c1e5149809f.
Thanks for the report!
Tobias
commit 2d5c1e5149809f978ea2c07517de13fdbb925de6
Author: Tobias Burnus
Date: Mon Mar 17 10:12:44 2025 +0100
Move gfortran.dg/gomp/declare-variant-mod-1*.f90 to libgomp.fortran/ [PR115271]
The test is a supposed to be a compile-only test but as dg-additional-sources
does not work with dg-compile (due to compiling with '-o'), dg-link had to
be used; as the code actually compiles (no diagnostic error), the linker
is actually invoked, which fails unless the system compiler by chance
provides the required files. Solution: move the test to libgomp.
PR fortran/115271
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/declare-variant-mod-1-use.f90: Move to
libgomp/testsuite/libgomp.fortran/.
* gfortran.dg/gomp/declare-variant-mod-1.f90: Likewise.
libgomp/ChangeLog:
* testsuite/libgomp.fortran/declare-variant-mod-1-use.f90: Moved
from gcc/testsuite/gfortran.dg/gomp/.
* testsuite/libgomp.fortran/declare-variant-mod-1.f90: Likewise.
---
.../testsuite/libgomp.fortran}/declare-variant-mod-1-use.f90 | 0
.../gomp => libgomp/testsuite/libgomp.fortran}/declare-variant-mod-1.f90 | 0
2 files changed, 0 insertions(+), 0 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/gomp/declare-variant-mod-1-use.f90 b/libgomp/testsuite/libgomp.fortran/declare-variant-mod-1-use.f90
similarity index 100%
rename from gcc/testsuite/gfortran.dg/gomp/declare-variant-mod-1-use.f90
rename to libgomp/testsuite/libgomp.fortran/declare-variant-mod-1-use.f90
diff --git a/gcc/testsuite/gfortran.dg/gomp/declare-variant-mod-1.f90 b/libgomp/testsuite/libgomp.fortran/declare-variant-mod-1.f90
similarity index 100%
rename from gcc/testsuite/gfortran.dg/gomp/declare-variant-mod-1.f90
rename to libgomp/testsuite/libgomp.fortran/declare-variant-mod-1.f90
