Re: [patch, changes.html] UNSIGNED, -fc-prototypes*, -Wexternal-interface-mismatch
Hi Thomas, It looks good to me. Thanks for the patch. Regards Paul On Sat, 15 Mar 2025 at 15:15, Thomas Koenig wrote: > Hello world, > > the attached patch, tested with "tidy -e", puts the two parts > mentioning UNSSIGNED into a single paragraph, mentions > extensions to -fc-prototypes and mentions -Wexternal-interface-mismatch. > > Comments, suggestions for better wording? > > If not, I'll probably commit tomorrow. > > Best regards > > Thomas >
Re: [patch, changes.html] UNSIGNED, -fc-prototypes*, -Wexternal-interface-mismatch
Hi Paul, It looks good to me. Thanks for the patch. Thanks! I just added one word, "modular", and committed it. Best regards Thomas
Re: gcc.gnu.org performance issues?
Am 16.03.25 um 22:37 schrieb Jonathan Wakely via Gcc: On Sun, 16 Mar 2025 at 21:30, Harald Anlauf via Gcc wrote: since I am experiencing extreme (temporary) performance problems again with a recently increased frequency and only during evening hours in Europe, I am asking if this is still the same cause. Today I've been waiting for hours for a git pull to succeed (i.e. to not timeout), not to mention a push. Bugzilla is slow again, but waiting hours for simple Git operations is not normal. If you're not doing anything crazy like pushing thousands of commits to a new branch, it should not take hours. (For pulls from trunk or release branches, you can always use the https://github.com/gcc-mirror/gcc repo mirror, which benefits for github's CDN and removes load from the gcc.gnu.org server). I am not aware of doing anything crazy: git pull / rebase / push for the present case, and a single, small commit. Do you use connection multiplexing with ssh, using the -O option or the ControlMaster ssh_config setting? If the connection hangs, then git operations over ssh will not complete. When that happens to me I do 'ssh -O exit gcc.gnu.org' to close the stalled multiplexed connection so that a new one can be created. 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. 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? Thanks, Harald
Re: [Patch] Fortran: Store OpenMP's 'declare variant' in module file [PR115271]
On Sat, Mar 15, 2025 at 3:46 AM Tobias Burnus wrote:
>
> I wonder why sometimes my line breaks are preserved and at other times all
> eaten.
>
> Next try ...
>
> Tobias Burnus wrote:
>
> Hi Thomas,
>
> Thomas Koenig wrote:
> > Just one question - as this will change the module file, will we still
> > be compatible with reading gfortran 8 to gfortran 14-written module
> > files?
>
> It shouldn't. On writing there is:
>
> * mio_omp_declare_simd [old function, additional condition]:
>
> if (*odsp == NULL)
>
>{
>
> if (ns->omp_declare_variant)
>
>{
>
> mio_lparen ();
>
> mio_rparen ();
>}
>
>return;
>
>
> Thus, on writing, it only writes '(' if there is
> a 'declare simd' (with its context, unchanged) - or (new) an empty '( )'
> if there is a 'declare variant'.
>
> * mio_omp_declare_variant itself has the code:
>
>
> if (iomode == IO_OUTPUT)
>
>{
>
> if (*odvp == NULL) return;
>
> Thus, if there is no 'declare variant', the output for 'declare simd'
> should the same as before - and the code is simple enough that I would
> even claim 'is' (unless the memory is corrupted).
>
>
> And as the output remains the same in that case, there should be also
> no problem reading both old .mod files with new compiler - and even
> the reverse, i.e. reading .mod files, written by after this patch, with
> an old GCC version. [The latter will fail due to the recent version bump, but
> that's unrelated to this patch.]
>
>
> The only potentially failing cases are:
>
> * Code that contains 'declare variant' that is written by a new
> compiler, but read by an old compiler (missing downward compatibility).
>
> But due to the version bump in GCC 15 (r15-6704-g21ee71afa72746;Jan
> 25, 2025), this only affects GCC 15 version between January and March -
> and only when the module contained 'declare variant'. [The mode-reading
> error is that the code stumbles over the '(' [ followed by some items
> and ')'] - while expecting the outer ')'.]
>
>
> * Some bug in the added code.
>
> This is very unlikely to hit code without 'declare variant', but there
> is some chance that I missed some corner case with 'declare variant'
> present - which might either cause missing data, wrong data (that might
> cause later fails [ICE, bogus diagnostic, wrong code]) or even a .mod
> reading issue. - While I ran into all those issues (with declare variant
> present) - fund in course of writing the test cases, I hope that I found
> most if not all such bugs.
>
>
> Thus, we should be all fine. I guess, we
> eventually will have some additions to the context selectors in the
> 'match' clauses, which will break downward (but not upward)
> compatibility. At least the TODO in openmp.cc implies that some work is
> needed and there is some chance that the current code will not handle
> it. (That's tracked as https://gcc.gnu.org/PR113067 )
>
> Cheers,
>
> Tobias
>
I got
gfortran: fatal error: cannot read spec file 'libgomp.spec': No such
file or directory
compilation terminated.
compiler exited with status 1
FAIL: gfortran.dg/gomp/declare-variant-mod-1.f90 -O (test for excess errors)
Excess errors:
--
H.J.
Re: gcc.gnu.org performance issues?
On Sun, 16 Mar 2025 at 21:30, Harald Anlauf via Gcc wrote: > since I am experiencing extreme (temporary) performance problems > again with a recently increased frequency and only during evening > hours in Europe, I am asking if this is still the same cause. > > Today I've been waiting for hours for a git pull to succeed (i.e. > to not timeout), not to mention a push. Bugzilla is slow again, but waiting hours for simple Git operations is not normal. If you're not doing anything crazy like pushing thousands of commits to a new branch, it should not take hours. (For pulls from trunk or release branches, you can always use the https://github.com/gcc-mirror/gcc repo mirror, which benefits for github's CDN and removes load from the gcc.gnu.org server). Do you use connection multiplexing with ssh, using the -O option or the ControlMaster ssh_config setting? If the connection hangs, then git operations over ssh will not complete. When that happens to me I do 'ssh -O exit gcc.gnu.org' to close the stalled multiplexed connection so that a new one can be created.
Re: gcc.gnu.org performance issues?
Hello all,
Am 15.08.24 um 21:31 schrieb Mark Wielaard:
Hi,
On Thu, Aug 15, 2024 at 10:31:12AM -0700, H.J. Lu via Gcc wrote:
On Thu, Aug 15, 2024 at 10:17 AM Harald Anlauf via Gcc wrote:
is it only me who is recently experiencing intermittent
but extreme slowness of "git pull"?
[...]
This was caused by agressive spiders that ignore robots.txt and
queried bugzilla over and over again. We have apache modqos and
fail2ban to capture so such spiders get banned after a short time,
till they get unbanned again and the whole circus starts over :{ We
should probably be more agressive, but we don't want to block regular
really active users or multiple users behind the same outgoing NAT ip.
The 16 most frequent fail2banners, those that just come back every
time after the ban times out, have been added to the permanent block
list. Hopefully that helps.
We have isolated the services so no service can overload the system
completely. But it can still slow down some others.
since I am experiencing extreme (temporary) performance problems
again with a recently increased frequency and only during evening
hours in Europe, I am asking if this is still the same cause.
Today I've been waiting for hours for a git pull to succeed (i.e.
to not timeout), not to mention a push.
Is there some throttling also affecting me? Or am I doing
anything wrong?
Thanks,
Harald
Cheers,
Mark
Re: gcc.gnu.org performance issues?
Hi Harald,
On Sun, Mar 16, 2025 at 10:29:13PM +0100, Harald Anlauf via Gcc wrote:
> Am 15.08.24 um 21:31 schrieb Mark Wielaard:
> >On Thu, Aug 15, 2024 at 10:31:12AM -0700, H.J. Lu via Gcc wrote:
> >>On Thu, Aug 15, 2024 at 10:17 AM Harald Anlauf via Gcc
> >>wrote:
> >>>is it only me who is recently experiencing intermittent
> >>>but extreme slowness of "git pull"?
> [...]
> >This was caused by agressive spiders that ignore robots.txt and
> >queried bugzilla over and over again. We have apache modqos and
> >fail2ban to capture so such spiders get banned after a short time,
> >till they get unbanned again and the whole circus starts over :{ We
> >should probably be more agressive, but we don't want to block regular
> >really active users or multiple users behind the same outgoing NAT ip.
> >
> >The 16 most frequent fail2banners, those that just come back every
> >time after the ban times out, have been added to the permanent block
> >list. Hopefully that helps.
> >
> >We have isolated the services so no service can overload the system
> >completely. But it can still slow down some others.
>
> since I am experiencing extreme (temporary) performance problems
> again with a recently increased frequency and only during evening
> hours in Europe, I am asking if this is still the same cause.
There is currently a botnet attacking lots of http git endpoints on
various systems including sourceware. We are trying to coordinate a
bit, but given that it seems a fairly large botnet with lots of ips
(which often only do one or two hits per day), it is hard to get a
good defense in place. We believe we have something now that at least
makes sure people can get at git (and bugzilla), although maybe a bit
slower than usual.
> Today I've been waiting for hours for a git pull to succeed (i.e.
> to not timeout), not to mention a push.
Hours however is really odd. Certainly for pushes which should go over
ssh and aren't throttled.
> Is there some throttling also affecting me? Or am I doing
> anything wrong?
Things can be slow with the botnet attacks going on, but shouldn't be
that slow. Feel free to reach out to overse...@sourceware.org or join
#overseers on irc.libera.chat if you need more help.
Cheers,
Mark
Re: gcc.gnu.org performance issues?
Am 16.03.25 um 22:59 schrieb Mark Wielaard: There is currently a botnet attacking lots of http git endpoints on various systems including sourceware. We are trying to coordinate a bit, but given that it seems a fairly large botnet with lots of ips (which often only do one or two hits per day), it is hard to get a good defense in place. We believe we have something now that at least makes sure people can get at git (and bugzilla), although maybe a bit slower than usual. Slow is OK for me, given these conditions... Today I've been waiting for hours for a git pull to succeed (i.e. to not timeout), not to mention a push. Hours however is really odd. Certainly for pushes which should go over ssh and aren't throttled. Is there some throttling also affecting me? Or am I doing anything wrong? Things can be slow with the botnet attacks going on, but shouldn't be that slow. Feel free to reach out to overse...@sourceware.org or join #overseers on irc.libera.chat if you need more help. I just tried again and pull/push went through fine. :-) If I get stuck again next time, I'll try your suggestions and ask off-list for help. Thanks, Harald Cheers, Mark
Re: gcc.gnu.org performance issues?
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. 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: fix bogus dependency check in ALLOCATE statement [PR60560]
Hi Thomas, Am 15.03.25 um 16:22 schrieb Thomas Koenig: Hi Harald, The solution is to use the auxiliary parameter of gfc_traverse_expr to control whether to descend into character length or not. Regtested on x86_64-pc-linux-gnu. OK for mainline? Looks good to me. pushed as r15-8079-gb2b139ddee763d. Thanks for the review! Harald Thanks for the patch! Best regards Thomas
[Patch, fortran] PR85836: Implement the F2018 reduce intrinsic
Hi All,
This version of the REDUCE intrinsic patch has evolved somewhat since the
posting on 2nd March. The most important changes are to the wrapper
function and the addition of two testsuite entries.
The wrapper function now effects:
subroutine wrapper (a, b, c)
type_of_ARRAY, intent(inout) :: a, c
type_of_ARRAY, intent(inout), optional :: b
if (present (b)) then
c = OPERATION (a,b )
else
c = a
end if
end subroutine
The reason for wrapping OPERATION in a subroutine is to allow pointer
arithmetic to be used throughout in the library function. The only thing
that needs to be known about the type and kind of ARRAY is the element
size. The second branch in the wrapper allows deep copies to be done in the
library function, such that derived types with allocatable components do
not leak memory. This is needed at the final step of the algorithm to copy
the result from each iteration to the result and then nullify it.
This is undoubtedly a bit heavy going for intrinsic types and so, one day
soon I will possibly do a bit of M4ery. That said, the present version
works for all types of ARRAY and I worry a bit about how much this
intrinsic will be used. Thoughts?
A slight niggle is the linker error that comes up if compiled without any
optimization:
/usr/bin/ld: warning: /tmp/cc9cx9Rw.o: requires executable stack (because
the .note.GNU-stack section is executable)
I think that this is unlikely to present a security issue, however, since
it disappears at -O1, I went through each of the options triggered by -O1
but couldn't make it go away. Does anybody know why this is?
Regtests OK with FC41/x86_64 - OK for mainline?
Regards
Paul
Change.Logs
Description: Binary data
diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 35458643835..0a5648a9d8f 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -2442,6 +2442,16 @@ gfc_check_co_broadcast (gfc_expr *a, gfc_expr *source_image, gfc_expr *stat,
}
+/* Helper function for character arguments in gfc_check_[co_]reduce. */
+
+static unsigned long
+get_ul_from_cst_cl (const gfc_charlen *cl)
+{
+ return cl && cl->length && cl->length->expr_type == EXPR_CONSTANT
+ ? mpz_get_ui (cl->length->value.integer) : 0;
+};
+
+
bool
gfc_check_co_reduce (gfc_expr *a, gfc_expr *op, gfc_expr *result_image,
gfc_expr *stat, gfc_expr *errmsg)
@@ -2567,24 +2577,12 @@ gfc_check_co_reduce (gfc_expr *a, gfc_expr *op, gfc_expr *result_image,
if (a->ts.type == BT_CHARACTER)
{
- gfc_charlen *cl;
unsigned long actual_size, formal_size1, formal_size2, result_size;
- cl = a->ts.u.cl;
- actual_size = cl && cl->length && cl->length->expr_type == EXPR_CONSTANT
- ? mpz_get_ui (cl->length->value.integer) : 0;
-
- cl = formal->sym->ts.u.cl;
- formal_size1 = cl && cl->length && cl->length->expr_type == EXPR_CONSTANT
- ? mpz_get_ui (cl->length->value.integer) : 0;
-
- cl = formal->next->sym->ts.u.cl;
- formal_size2 = cl && cl->length && cl->length->expr_type == EXPR_CONSTANT
- ? mpz_get_ui (cl->length->value.integer) : 0;
-
- cl = sym->ts.u.cl;
- result_size = cl && cl->length && cl->length->expr_type == EXPR_CONSTANT
- ? mpz_get_ui (cl->length->value.integer) : 0;
+ actual_size = get_ul_from_cst_cl (a->ts.u.cl);
+ formal_size1 = get_ul_from_cst_cl (formal->sym->ts.u.cl);
+ formal_size2 = get_ul_from_cst_cl (formal->next->sym->ts.u.cl);
+ result_size = get_ul_from_cst_cl (sym->ts.u.cl);
if (actual_size
&& ((formal_size1 && actual_size != formal_size1)
@@ -5135,6 +5133,207 @@ gfc_check_real (gfc_expr *a, gfc_expr *kind)
}
+bool
+gfc_check_reduce (gfc_expr *array, gfc_expr *operation, gfc_expr *dim,
+ gfc_expr *mask, gfc_expr *identity, gfc_expr *ordered)
+{
+ symbol_attribute attr;
+ gfc_formal_arglist *formal;
+ gfc_symbol *sym;
+
+ if (array->ts.type == BT_CLASS)
+{
+ gfc_error ("The ARRAY argument at %L of REDUCE shall not be polymorphic",
+ &array->where);
+ return false;
+}
+
+ if (!gfc_resolve_expr (operation))
+return false;
+
+ attr = gfc_expr_attr (operation);
+ if (!attr.pure || !attr.function)
+{
+ gfc_error ("OPERATION argument at %L must be a PURE function",
+ &operation->where);
+ return false;
+}
+
+ if (attr.dimension)
+{
+ gfc_error ("OPERATION argument at %L must be a SCALAR function",
+ &operation->where);
+ return false;
+}
+
+ if (attr.intrinsic)
+{
+ /* None of the intrinsics fulfills the criteria of taking two arguments,
+ returning the same type and kind as the arguments and being permitted
+ as actual argument. */
+ gfc_error ("Intrinsic function %s at %L is not permitted for REDUCE",
+ operation->symtree->n.sym->name, &operation->where);
+ return false;
+}
+
+ if (gfc_is_proc_ptr_comp (operation))
+{
+ gfc_component *comp = gfc_get
Re: [Patch, fortran] PR85836: Implement the F2018 reduce intrinsic
On 3/16/25 10:26 AM, Paul Richard Thomas wrote: --- snip --- A slight niggle is the linker error that comes up if compiled without any optimization: /usr/bin/ld: warning: /tmp/cc9cx9Rw.o: requires executable stack (because the .note.GNU-stack section is executable) I think that this is unlikely to present a security issue, however, since it disappears at -O1, I went through each of the options triggered by -O1 but couldn't make it go away. Does anybody know why this is? This niggle showed up a few months back and I filed a PR on it. See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455 Regards, Jerry
