Re: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)
Hi Steve, On Sun, 2023-01-29 at 22:27 -0800, Steve Kargl via Gcc wrote: > Please remove the skull and cross bones in the subject line. That is the default "hazard symbol" buildbot uses if a build turns from success to failure. If you have a better suggestion you might want to contact upstream https://buildbot.net/ We'll pick up the new default when we'll upgrade. Or if you think we should use a custom email template: https://docs.buildbot.net/latest/manual/configuration/report_generators/formatter.html You can provide a patch to build...@sourceware.org. The code for our instance can be found here: https://sourceware.org/git/builder.git Cheers, Mark
Re: Buildbot (Sourceware): gcc - failed configure (failure) (master)
On 30.01.23 14:52, Mark Wielaard wrote: Hi Steve, On Sun, 2023-01-29 at 22:27 -0800, Steve Kargl via Gcc wrote: Please remove the skull and cross bones in the subject line. That is the default "hazard symbol" buildbot uses if a build turns from success to failure. If you have a better suggestion you might want to contact upstream https://buildbot.net/ We'll pick up the new default when we'll upgrade. Or if you think we should use a custom email template: https://docs.buildbot.net/latest/manual/configuration/report_generators/formatter.html You can provide a patch to build...@sourceware.org. The code for our instance can be found here: https://sourceware.org/git/builder.git I usually put e-mails with such unicode characters into my spam folder automatically. If that's what you want, that is fine with me. Regards Thomas
Re: Buildbot (Sourceware): gcc - failed configure (failure) (master)
On Mon, Jan 30, 2023 at 03:46:30PM +0100, Thomas Koenig wrote: > On 30.01.23 14:52, Mark Wielaard wrote: > > Hi Steve, > > > > On Sun, 2023-01-29 at 22:27 -0800, Steve Kargl via Gcc wrote: > > > Please remove the skull and cross bones in the subject line. > > > > That is the default "hazard symbol" buildbot uses if a build turns from > > success to failure. If you have a better suggestion you might want to > > contact upstream https://buildbot.net/ We'll pick up the new default > > when we'll upgrade. > > > > Or if you think we should use a custom email template: > > https://docs.buildbot.net/latest/manual/configuration/report_generators/formatter.html > > You can provide a patch to build...@sourceware.org. > > The code for our instance can be found here: > > https://sourceware.org/git/builder.git > > I usually put e-mails with such unicode characters into my spam folder > automatically. > > If that's what you want, that is fine with me. > Bingo. In the case of non-[a-zA-Z] characters in the Subject (or Fromi or To) line, the spam folder is normally named /dev/null. -- Steve
Testsuite, dejagnu
Dear Hackers, is there a way to check that a particular warning is emitted only once for a source code line instead of multiple times? It appears that by default dg-warn matches one or more times. Thanks, Harald
Re: Testsuite, dejagnu
On Mon, Jan 30, 2023 at 12:27 PM Harald Anlauf via Fortran wrote: > > Dear Hackers, > > is there a way to check that a particular warning is emitted only > once for a source code line instead of multiple times? > > It appears that by default dg-warn matches one or more times. One example of how to do this is located in testsuite/g++.dg/lookup/duperr1.C . I don't know if this is the best way of doing it though. Basically it uses dg-bogus to match the multiple warnings (since it is a regex over all output lines and `.*` will even match new lines) so you get a failure if there was a duplicated one and then dg-message to match the original message just to make sure it is outputted once (dg-message was because it was originally a note: rather than a warning/error but similar thing can be done for dg-error/dg-warning). Thanks, Andrew Pinski > > Thanks, > Harald >
Aw: Re: Testsuite, dejagnu
Hi Andrew, > Gesendet: Montag, 30. Januar 2023 um 22:13 Uhr > Von: "Andrew Pinski" > An: "Harald Anlauf" > Cc: "fortran" > Betreff: Re: Testsuite, dejagnu > > On Mon, Jan 30, 2023 at 12:27 PM Harald Anlauf via Fortran > wrote: > > > > Dear Hackers, > > > > is there a way to check that a particular warning is emitted only > > once for a source code line instead of multiple times? > > > > It appears that by default dg-warn matches one or more times. > > One example of how to do this is located in testsuite/g++.dg/lookup/duperr1.C > . > I don't know if this is the best way of doing it though. > Basically it uses dg-bogus to match the multiple warnings (since it is > a regex over all output lines and `.*` will even match new lines) so > you get a failure if there was a duplicated one and then dg-message to > match the original message just to make sure it is outputted once > (dg-message was because it was originally a note: rather than a > warning/error but similar thing can be done for dg-error/dg-warning). yes, that can be used to make it work for the Fortran testcase at hand! Thanks, Harald > > Thanks, > Andrew Pinski > > > > > > Thanks, > > Harald > > >
[PATCH] Fortran: prevent redundant integer division truncation warnings [PR108592]
Dear Fortranners,
the subject says it all: in some cases we emit redundant integer division
truncation warnings (2 or 4), where just one would have been sufficient.
This is solved by using gfc_warning instead of gfc_warning_now.
The testcase uses a suggestion by Andrew to verify that we get the
desired warning exactly once.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 8340523c8df8edd008174d44e87c0fa54b58b2c7 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 30 Jan 2023 22:46:43 +0100
Subject: [PATCH] Fortran: prevent redundant integer division truncation
warnings [PR108592]
gcc/fortran/ChangeLog:
PR fortran/108592
* arith.cc (gfc_arith_divide): Emit integer division truncation
warnings using gfc_warning instead of gfc_warning_now to prevent
redundant messages.
gcc/testsuite/ChangeLog:
PR fortran/108592
* gfortran.dg/pr108592.f90: New test.
---
gcc/fortran/arith.cc | 2 +-
gcc/testsuite/gfortran.dg/pr108592.f90 | 8
2 files changed, 9 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr108592.f90
diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index 6de6d21c73d..d0d1c0b03d2 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -778,7 +778,7 @@ gfc_arith_divide (gfc_expr *op1, gfc_expr *op2, gfc_expr **resultp)
{
char *p;
p = mpz_get_str (NULL, 10, result->value.integer);
- gfc_warning_now (OPT_Winteger_division, "Integer division "
+ gfc_warning (OPT_Winteger_division, "Integer division "
"truncated to constant %qs at %L", p,
&op1->where);
free (p);
diff --git a/gcc/testsuite/gfortran.dg/pr108592.f90 b/gcc/testsuite/gfortran.dg/pr108592.f90
new file mode 100644
index 000..224b1d8d1fc
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr108592.f90
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! { dg-options "-Winteger-division" }
+! PR fortran/108592 - warn only once for truncation of integer division
+
+program foo
+ if (8 < (20/9)) stop 1 ! { dg-bogus "Integer division.*Integer division" }
+! { dg-message "Integer division truncated" "" { target *-*-* } .-1 }
+end program
--
2.35.3
Re: Buildbot (Sourceware): gcc - failed configure (failure) (master)
On Mon, 30 Jan 2023, Steve Kargl via Gcc wrote: > Bingo. In the case of non-[a-zA-Z] characters in the > Subject (or Fromi or To) line, the spam folder is normally > named /dev/null. Hmm, so any digit, parenthesis, or bracket in the Subject, and mails gets to /dev/null? Or having an umlaut or other special character in one's name - which is pretty common in parts of the world like Central Europe? "Be conservative in what you send, be liberal in what you accept." [Postel's Law] Gerald
Re: Buildbot (Sourceware): gcc - failed configure (failure) (master)
On Mon, Jan 30, 2023 at 11:07:46PM +0100, Gerald Pfeifer wrote: > On Mon, 30 Jan 2023, Steve Kargl via Gcc wrote: > > Bingo. In the case of non-[a-zA-Z] characters in the > > Subject (or Fromi or To) line, the spam folder is normally > > named /dev/null. > > Hmm, so any digit, parenthesis, or bracket in the Subject, and mails gets > to /dev/null? I suppose I should have just noted characters should be members of the Processor Character Set (18-007r1.pdf, Sec. 6.1), but I suspect some here have no idea what that means. > Or having an umlaut or other special character in one's name - which is > pretty common in parts of the world like Central Europe? umlaut and other special chars can trigger spam filters. Whitelisting is used for those that matter. Does the skull and crossbones convey anymore info than the rest of the subject line Buildbot (Sourceware): gcc - failed configure (failure) (master) -- Steve
