Re: GCC 8 vs. GCC 9 speed and size comparison
On 4/15/19 5:07 PM, Michael Matz wrote:
> Hi,
>
> On Mon, 15 Apr 2019, Jakub Jelinek wrote:
>
>>> It seems the C++ parser got quite a bit slower with gcc 9 :-( Most
>>> visible in the compile time for tramp-3d (24%) and kdecore.cc (18%
>>> slower with just PGO); it seems that the other .ii files are C-like
>>> enough to not
>>
>> Is that with the same libstdc++ headers (i.e. identical *.ii files) or
>> with the corresponding libstdc++ headers? Those do change a lot every
>> release as well.
>
> The tramp3d and kdecore testcases are preprocessed files from a
> collection of benchmark sources we use, i.e. the same
> input for all compilers. I think the {gimple,generic}-match.ii are in the
> same league.
Yes, except kdecore.cc I used in all cases .ii pre-processed files. I'm going
to start using kdecore.ii as well.
As Honza pointed out in the email that hasn't reached this mailing list
due to file size, there's a significant change in inline-unit-growth. The param
has changed from 20 to 40 for GCC 9. Using --param inline-unit-growth=20 for all
benchmarks, I see green numbres for GCC 9!
Martin
>
>
> Ciao,
> Michael.
>
gcc8-gcc9-comparison.ods
Description: application/vnd.oasis.opendocument.spreadsheet
Re: GCC 8 vs. GCC 9 speed and size comparison
On 4/16/19 9:48 AM, Martin Liška wrote:
> On 4/15/19 5:07 PM, Michael Matz wrote:
>> Hi,
>>
>> On Mon, 15 Apr 2019, Jakub Jelinek wrote:
>>
It seems the C++ parser got quite a bit slower with gcc 9 :-( Most
visible in the compile time for tramp-3d (24%) and kdecore.cc (18%
slower with just PGO); it seems that the other .ii files are C-like
enough to not
>>>
>>> Is that with the same libstdc++ headers (i.e. identical *.ii files) or
>>> with the corresponding libstdc++ headers? Those do change a lot every
>>> release as well.
>>
>> The tramp3d and kdecore testcases are preprocessed files from a
>> collection of benchmark sources we use, i.e. the same
>> input for all compilers. I think the {gimple,generic}-match.ii are in the
>> same league.
>
> Yes, except kdecore.cc I used in all cases .ii pre-processed files. I'm going
> to start using kdecore.ii as well.
>
> As Honza pointed out in the email that hasn't reached this mailing list
> due to file size, there's a significant change in inline-unit-growth. The
> param
> has changed from 20 to 40 for GCC 9. Using --param inline-unit-growth=20 for
> all
> benchmarks, I see green numbres for GCC 9!
>
> Martin
>
>>
>>
>> Ciao,
>> Michael.
>>
>
Sending updated cell conditional formatting.
Martin
gcc8-gcc9-comparison.ods
Description: application/vnd.oasis.opendocument.spreadsheet
Re: GCC 8 vs. GCC 9 speed and size comparison
Hello Martin, On Tue, 16 Apr 2019, Martin Liška wrote: > Yes, except kdecore.cc I used in all cases .ii pre-processed files. I'm > going to start using kdecore.ii as well. If the kdecore.cc is the one from me it's also preprocessed and doesn't contain any #include directives, I just edited it somewhat to be compilable for different architecture. Ciao, Michael. > > As Honza pointed out in the email that hasn't reached this mailing list > due to file size, there's a significant change in inline-unit-growth. The > param > has changed from 20 to 40 for GCC 9. Using --param inline-unit-growth=20 for > all > benchmarks, I see green numbres for GCC 9! > > Martin > > > > > > > Ciao, > > Michael. > > > >
Re: GCC 8 vs. GCC 9 speed and size comparison
On Tue, Apr 16, 2019 at 10:53 AM Michael Matz wrote: > > Hello Martin, > > On Tue, 16 Apr 2019, Martin Liška wrote: > > > Yes, except kdecore.cc I used in all cases .ii pre-processed files. I'm > > going to start using kdecore.ii as well. > > If the kdecore.cc is the one from me it's also preprocessed and doesn't > contain any #include directives, I just edited it somewhat to be > compilable for different architecture. Btw, the tramp3d sources on our testers _do_ contain #include directives. Richard. > > Ciao, > Michael. > > > > > As Honza pointed out in the email that hasn't reached this mailing list > > due to file size, there's a significant change in inline-unit-growth. The > > param > > has changed from 20 to 40 for GCC 9. Using --param inline-unit-growth=20 > > for all > > benchmarks, I see green numbres for GCC 9! > > > > Martin > > > > > > > > > > > Ciao, > > > Michael. > > > > > > >
Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32
Am 15.04.2019 um 20:12 schrieb Rainer Emrich:
> Am 15.04.2019 um 17:43 schrieb Rainer Emrich:
>> Am 15.04.2019 um 17:38 schrieb Jakub Jelinek:
>>> On Mon, Apr 15, 2019 at 05:30:14PM +0200, Rainer Emrich wrote:
There seems to be a generic issue with the tests in gcc/testsuite. The
log files do not contain the logs.
>>>
>>> Perhaps contrib/dg-extract-results* misbehaved?
>>> Can you look for the testsuite/g++*/g++.log.sep files? Do they contain
>>> everything?
> The *.log.sep files seem to be ok.
>
>>> If yes, can you try to say
>>> mv contrib/dg-extract-results.py{,.bad}
>>> and retry, to see if there isn't a problem with the python version thereof?
> I will try this over the night.
The shell version of dg-extract-results does not work either.
AFAIS, there were changes to the dg-extract-results script 5th of March.
Looks like these changes are causing the issue, but I'm not sure.
What I can say, my setup works at least for the gcc-8 branch and used to
work in the past.
signature.asc
Description: OpenPGP digital signature
dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32
Am 16.04.2019 um 11:59 schrieb Rainer Emrich:
> Am 15.04.2019 um 20:12 schrieb Rainer Emrich:
>> Am 15.04.2019 um 17:43 schrieb Rainer Emrich:
>>> Am 15.04.2019 um 17:38 schrieb Jakub Jelinek:
On Mon, Apr 15, 2019 at 05:30:14PM +0200, Rainer Emrich wrote:
> There seems to be a generic issue with the tests in gcc/testsuite. The
> log files do not contain the logs.
Perhaps contrib/dg-extract-results* misbehaved?
Can you look for the testsuite/g++*/g++.log.sep files? Do they contain
everything?
>> The *.log.sep files seem to be ok.
>>
If yes, can you try to say
mv contrib/dg-extract-results.py{,.bad}
and retry, to see if there isn't a problem with the python version thereof?
>> I will try this over the night.
> The shell version of dg-extract-results does not work either.
>
> AFAIS, there were changes to the dg-extract-results script 5th of March.
> Looks like these changes are causing the issue, but I'm not sure.
>
> What I can say, my setup works at least for the gcc-8 branch and used to
> work in the past.
I tested dg-extractresults.sh manually and found that the change from
4th of February, revision 268411 broke the log extraction. Easy to test
with version from 23rd of September last year which works.
I don't have the time to analyze the python version, but my bet, it's
the same issue.
signature.asc
Description: OpenPGP digital signature
Re: Feature request: Don't warn for specified "unknown" attribute
On Tue, 16 Apr 2019 at 04:06, Justin Bassett wrote: > > The following code will emit a warning with -Wattributes: > > [[some_ns::some_attribute]] > void call_me(); > > :2:14: warning: 'some_ns::some_attribute' scoped attribute > directive ignored [-Wattributes] > 2 | void call_me(); > | ^ > > I want to disable the warning for third party attributes, but this warning > is very useful for detecting typos of standard attributes, so I want to > keep it for all other attributes. AFAIK, there's no way to turn off the > warning just for one attribute, just all of them (-Wno-attributes). > > To solve this, I propose that we add the ability to specify attributes to > ignore if they are unknown. In other words, something like this: > '-Wignore-unknown-attribute=some_ns::some_attribute'. > > There are some alternatives, such as only warning if the edit distance is > close to a known attribute, but I think that specifying the known attribute > in the build system like this is better, as it will also catch > misspellings of [[some_ns::some_attribute]]. An option like that has been discussed before. I thought it was in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368 but I don't see it there, so feel free to add a comment about it there. I still like my suggestion at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368#c2
Re: GCC 8 vs. GCC 9 speed and size comparison
On Tue, Apr 16, 2019 at 11:56 AM Richard Biener
wrote:
>
> On Tue, Apr 16, 2019 at 10:53 AM Michael Matz wrote:
> >
> > Hello Martin,
> >
> > On Tue, 16 Apr 2019, Martin Liška wrote:
> >
> > > Yes, except kdecore.cc I used in all cases .ii pre-processed files. I'm
> > > going to start using kdecore.ii as well.
> >
> > If the kdecore.cc is the one from me it's also preprocessed and doesn't
> > contain any #include directives, I just edited it somewhat to be
> > compilable for different architecture.
>
> Btw, the tramp3d sources on our testers _do_ contain #include directives.
So for the parser it's small differences that accumulate, for example
a lot more comptype calls via null_ptr_cst_p (via char_type_p) via the new
conversion_null_warnings which is called even without any warning option.
Possible speedup to null_ptr_cst_p is to avoid the expensive char_type_p
(called 5 times in GCC 9 vs. only 2000 times in GCC 8):
Index: gcc/cp/call.c
===
--- gcc/cp/call.c (revision 270387)
+++ gcc/cp/call.c (working copy)
@@ -541,11 +541,11 @@ null_ptr_cst_p (tree t)
STRIP_ANY_LOCATION_WRAPPER (t);
/* Core issue 903 says only literal 0 is a null pointer constant. */
- if (TREE_CODE (type) == INTEGER_TYPE
- && !char_type_p (type)
- && TREE_CODE (t) == INTEGER_CST
+ if (TREE_CODE (t) == INTEGER_CST
+ && !TREE_OVERFLOW (t)
+ && TREE_CODE (type) == INTEGER_TYPE
&& integer_zerop (t)
- && !TREE_OVERFLOW (t))
+ && !char_type_p (type))
return true;
}
else if (CP_INTEGRAL_TYPE_P (type))
brings down the number of char_type_p calls to ~5000. Still null_ptr_cst_p
calls are 15 vs. 17000, caused by the conversion_null_warnings code
doing
/* Handle zero as null pointer warnings for cases other
than EQ_EXPR and NE_EXPR */
else if (null_ptr_cst_p (expr) &&
(TYPE_PTR_OR_PTRMEM_P (totype) || NULLPTR_TYPE_P (totype)))
{
similarly "easy" to short-cut most of them:
@@ -6882,8 +6882,8 @@ conversion_null_warnings (tree totype, t
}
/* Handle zero as null pointer warnings for cases other
than EQ_EXPR and NE_EXPR */
- else if (null_ptr_cst_p (expr) &&
- (TYPE_PTR_OR_PTRMEM_P (totype) || NULLPTR_TYPE_P (totype)))
+ else if ((TYPE_PTR_OR_PTRMEM_P (totype) || NULLPTR_TYPE_P (totype))
+ && null_ptr_cst_p (expr))
{
location_t loc =
get_location_for_expr_unwinding_for_system_header (expr);
maybe_warn_zero_as_null_pointer_constant (expr, loc);
brings them down to 25000.
All this looks like there's plenty of low-hanging micro-optimization possible in
the C++ frontend.
I'm going to test the above two hunks, the overall savings are of course
small (and possibly applicable to branches as well).
Richard.
> Richard.
>
> >
> > Ciao,
> > Michael.
> >
> > >
> > > As Honza pointed out in the email that hasn't reached this mailing list
> > > due to file size, there's a significant change in inline-unit-growth. The
> > > param
> > > has changed from 20 to 40 for GCC 9. Using --param inline-unit-growth=20
> > > for all
> > > benchmarks, I see green numbres for GCC 9!
> > >
> > > Martin
> > >
> > > >
> > > >
> > > > Ciao,
> > > > Michael.
> > > >
> > >
> > >
Re: GCC 8 vs. GCC 9 speed and size comparison
On Tue, Apr 16, 2019 at 01:25:38PM +0200, Richard Biener wrote:
> So for the parser it's small differences that accumulate, for example
> a lot more comptype calls via null_ptr_cst_p (via char_type_p) via the new
> conversion_null_warnings which is called even without any warning option.
>
> Possible speedup to null_ptr_cst_p is to avoid the expensive char_type_p
> (called 5 times in GCC 9 vs. only 2000 times in GCC 8):
If we do this (looks like a good idea to me), perhaps we should do also
following (first part just doing what you've done in yet another spot,
moving the less expensive checks first, because null_node_p strips location
wrappers etc.) and the second not to call conversion_null_warnings at all
if we don't want to warn (though, admittedly while
warn_zero_as_null_pointer_constant defaults to 0, warn_conversion_null
defaults to 1).
--- gcc/cp/call.c 2019-04-12 21:47:06.301924378 +0200
+++ gcc/cp/call.c 2019-04-16 13:35:59.779977641 +0200
@@ -6844,8 +6844,9 @@ static void
conversion_null_warnings (tree totype, tree expr, tree fn, int argnum)
{
/* Issue warnings about peculiar, but valid, uses of NULL. */
- if (null_node_p (expr) && TREE_CODE (totype) != BOOLEAN_TYPE
- && ARITHMETIC_TYPE_P (totype))
+ if (TREE_CODE (totype) != BOOLEAN_TYPE
+ && ARITHMETIC_TYPE_P (totype)
+ && null_node_p (expr))
{
location_t loc = get_location_for_expr_unwinding_for_system_header
(expr);
if (fn)
@@ -7059,7 +7060,9 @@ convert_like_real (conversion *convs, tr
return cp_convert (totype, expr, complain);
}
- if (issue_conversion_warnings && (complain & tf_warning))
+ if (issue_conversion_warnings
+ && (complain & tf_warning)
+ && (warn_conversion_null || warn_zero_as_null_pointer_constant))
conversion_null_warnings (totype, expr, fn, argnum);
switch (convs->kind)
Jakub
[0/4] Addressing modulo-scheduling bugs
Last few days I’ve added my comments/patches into almost all modulo-scheduler PRs appeared in the last two years. Here I want to discuss five PRs. First of all, I have four patches which fix regressions, so technically I can ask about applying them right now on stage4. But we don’t have a maintainer in modulo-sched pass, so not sure about their fast approval. Last one PR90040 is meta-bug I’ve created. It consolidates 5-6 other bugzilla PRs, which really are about the same issue. Unfortunately, I can’t solve that myself. Jakub, Honza, would you kindly help me and take a look at that PR to provide any suggestions you might have. All my patches were successfully bootstrapped and regtested on x86_64. Also I’ve checked that in cross-compiler mode to s390, spu, aarch64, arm, ia64, ppc and ppc64 regtest shows no new regressions. The same testing was done with -fmodulo-sched enabled. Also the same testing was done with -fmodulo-sched -fmodulo-sched-allow-regmoves enabled. Moreover, all that was also done on 8 branch. No new issues introduced. So, since I’ve made really heavy testing, IMO all 4 fixes can go into trunk and even 8 branch. When development goes into stage1 and after somehow fixing PR90040 issue I will introduce updated patchset described here: https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01647.html (the set is supported locally on all branches since 4.9 with making a lot of regtesting). Regarding the modulo scheduling maintainership, if my patches look good, I'm happy to volunteer to maintain the code as I looked at the code a lot during recent years. Please let me know the steps I should do to make that happen. Roman
Re: GCC 8 vs. GCC 9 speed and size comparison
On Tue, Apr 16, 2019 at 1:39 PM Jakub Jelinek wrote:
>
> On Tue, Apr 16, 2019 at 01:25:38PM +0200, Richard Biener wrote:
> > So for the parser it's small differences that accumulate, for example
> > a lot more comptype calls via null_ptr_cst_p (via char_type_p) via the new
> > conversion_null_warnings which is called even without any warning option.
> >
> > Possible speedup to null_ptr_cst_p is to avoid the expensive char_type_p
> > (called 5 times in GCC 9 vs. only 2000 times in GCC 8):
>
> If we do this (looks like a good idea to me), perhaps we should do also
> following (first part just doing what you've done in yet another spot,
> moving the less expensive checks first, because null_node_p strips location
> wrappers etc.) and the second not to call conversion_null_warnings at all
> if we don't want to warn (though, admittedly while
> warn_zero_as_null_pointer_constant defaults to 0, warn_conversion_null
> defaults to 1).
>
> --- gcc/cp/call.c 2019-04-12 21:47:06.301924378 +0200
> +++ gcc/cp/call.c 2019-04-16 13:35:59.779977641 +0200
> @@ -6844,8 +6844,9 @@ static void
> conversion_null_warnings (tree totype, tree expr, tree fn, int argnum)
> {
>/* Issue warnings about peculiar, but valid, uses of NULL. */
> - if (null_node_p (expr) && TREE_CODE (totype) != BOOLEAN_TYPE
> - && ARITHMETIC_TYPE_P (totype))
> + if (TREE_CODE (totype) != BOOLEAN_TYPE
> + && ARITHMETIC_TYPE_P (totype)
> + && null_node_p (expr))
> {
>location_t loc = get_location_for_expr_unwinding_for_system_header
> (expr);
>if (fn)
> @@ -7059,7 +7060,9 @@ convert_like_real (conversion *convs, tr
>return cp_convert (totype, expr, complain);
> }
>
> - if (issue_conversion_warnings && (complain & tf_warning))
> + if (issue_conversion_warnings
> + && (complain & tf_warning)
> + && (warn_conversion_null || warn_zero_as_null_pointer_constant))
> conversion_null_warnings (totype, expr, fn, argnum);
>
>switch (convs->kind)
Yes, that looks good to me as well.
Btw, I noticed the C++ FE calls build_qualified_type a _lot_, in 99% picking
up an existing variant from the list and those list walks visit ~20 types
_on average_! A simple LRU cache (just put the found variant first) manages
to improve compile-time to be even better than GCC 8 (~1% improvement).
It improves the number of types checked to ~2.5 (from those 20). Also
-fsynax-only compile-time from 2.9s to 2.75s (consistently).
Index: gcc/tree.c
===
--- gcc/tree.c (revision 270387)
+++ gcc/tree.c (working copy)
@@ -6459,9 +6459,22 @@ get_qualified_type (tree type, int type_
/* Search the chain of variants to see if there is already one there just
like the one we need to have. If so, use that existing one. We must
preserve the TYPE_NAME, since there is code that depends on this. */
- for (t = TYPE_MAIN_VARIANT (type); t; t = TYPE_NEXT_VARIANT (t))
-if (check_qualified_type (t, type, type_quals))
- return t;
+ for (tree *t = &TYPE_MAIN_VARIANT (type); *t; t = &TYPE_NEXT_VARIANT (*t))
+{
+ if (check_qualified_type (*t, type, type_quals))
+ {
+ tree mv = TYPE_MAIN_VARAINT (type);
+ tree x = *t;
+ if (x != mv)
+ {
+ /* LRU. */
+ *t = TYPE_NEXT_VARIANT (*t);
+ TYPE_NEXT_VARIANT (x) = TYPE_NEXT_VARIANT (mv);
+ TYPE_NEXT_VARIANT (mv) = x;
+ }
+ return x;
+ }
+}
return NULL_TREE;
}
peeling the main-variant case above might make the code a little bit prettier.
Richard.
>
> Jakub
Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32
On Tue, 16 Apr 2019 at 13:04, Rainer Emrich wrote:
>
> Am 16.04.2019 um 11:59 schrieb Rainer Emrich:
> > Am 15.04.2019 um 20:12 schrieb Rainer Emrich:
> >> Am 15.04.2019 um 17:43 schrieb Rainer Emrich:
> >>> Am 15.04.2019 um 17:38 schrieb Jakub Jelinek:
> On Mon, Apr 15, 2019 at 05:30:14PM +0200, Rainer Emrich wrote:
> > There seems to be a generic issue with the tests in gcc/testsuite. The
> > log files do not contain the logs.
>
> Perhaps contrib/dg-extract-results* misbehaved?
> Can you look for the testsuite/g++*/g++.log.sep files? Do they contain
> everything?
> >> The *.log.sep files seem to be ok.
> >>
> If yes, can you try to say
> mv contrib/dg-extract-results.py{,.bad}
> and retry, to see if there isn't a problem with the python version
> thereof?
> >> I will try this over the night.
> > The shell version of dg-extract-results does not work either.
> >
> > AFAIS, there were changes to the dg-extract-results script 5th of March.
> > Looks like these changes are causing the issue, but I'm not sure.
> >
> > What I can say, my setup works at least for the gcc-8 branch and used to
> > work in the past.
> I tested dg-extractresults.sh manually and found that the change from
> 4th of February, revision 268411 broke the log extraction. Easy to test
> with version from 23rd of September last year which works.
>
> I don't have the time to analyze the python version, but my bet, it's
> the same issue.
>
Hi,
Sorry for the breakage, I really wanted to improve those scripts.
Could you give me a reproducer, since we didn't notice problems in our
validations?
Thanks,
Christophe
Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32
Am 16.04.2019 um 14:10 schrieb Christophe Lyon:
> On Tue, 16 Apr 2019 at 13:04, Rainer Emrich
> wrote:
>>
>> Am 16.04.2019 um 11:59 schrieb Rainer Emrich:
>>> Am 15.04.2019 um 20:12 schrieb Rainer Emrich:
Am 15.04.2019 um 17:43 schrieb Rainer Emrich:
> Am 15.04.2019 um 17:38 schrieb Jakub Jelinek:
>> On Mon, Apr 15, 2019 at 05:30:14PM +0200, Rainer Emrich wrote:
>>> There seems to be a generic issue with the tests in gcc/testsuite. The
>>> log files do not contain the logs.
>>
>> Perhaps contrib/dg-extract-results* misbehaved?
>> Can you look for the testsuite/g++*/g++.log.sep files? Do they contain
>> everything?
The *.log.sep files seem to be ok.
>> If yes, can you try to say
>> mv contrib/dg-extract-results.py{,.bad}
>> and retry, to see if there isn't a problem with the python version
>> thereof?
I will try this over the night.
>>> The shell version of dg-extract-results does not work either.
>>>
>>> AFAIS, there were changes to the dg-extract-results script 5th of March.
>>> Looks like these changes are causing the issue, but I'm not sure.
>>>
>>> What I can say, my setup works at least for the gcc-8 branch and used to
>>> work in the past.
>> I tested dg-extractresults.sh manually and found that the change from
>> 4th of February, revision 268411 broke the log extraction. Easy to test
>> with version from 23rd of September last year which works.
>>
>> I don't have the time to analyze the python version, but my bet, it's
>> the same issue.
>>
> Hi,
>
> Sorry for the breakage, I really wanted to improve those scripts.
> Could you give me a reproducer, since we didn't notice problems in our
> validations?
Hi Christope,
I executed the dg-extract-results.sh manually in the gcc/testsuite
directory after a complete testsuite run which didn't give the correct
results. Rev. 240429 gives the expected results, where rev 268511 fails.
I'm on windows using msys2 with bash 4.4.23.
I'm bootsrapping at the moment but that's really slow on windows. When
the testsuite run is finished I try to assemble a reproducer. This will
take a while.
Thanks,
Rainer
signature.asc
Description: OpenPGP digital signature
Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32
On Tue, 16 Apr 2019 at 14:34, Rainer Emrich wrote:
>
> Am 16.04.2019 um 14:10 schrieb Christophe Lyon:
> > On Tue, 16 Apr 2019 at 13:04, Rainer Emrich
> > wrote:
> >>
> >> Am 16.04.2019 um 11:59 schrieb Rainer Emrich:
> >>> Am 15.04.2019 um 20:12 schrieb Rainer Emrich:
> Am 15.04.2019 um 17:43 schrieb Rainer Emrich:
> > Am 15.04.2019 um 17:38 schrieb Jakub Jelinek:
> >> On Mon, Apr 15, 2019 at 05:30:14PM +0200, Rainer Emrich wrote:
> >>> There seems to be a generic issue with the tests in gcc/testsuite. The
> >>> log files do not contain the logs.
> >>
> >> Perhaps contrib/dg-extract-results* misbehaved?
> >> Can you look for the testsuite/g++*/g++.log.sep files? Do they contain
> >> everything?
> The *.log.sep files seem to be ok.
>
> >> If yes, can you try to say
> >> mv contrib/dg-extract-results.py{,.bad}
> >> and retry, to see if there isn't a problem with the python version
> >> thereof?
> I will try this over the night.
> >>> The shell version of dg-extract-results does not work either.
> >>>
> >>> AFAIS, there were changes to the dg-extract-results script 5th of March.
> >>> Looks like these changes are causing the issue, but I'm not sure.
> >>>
> >>> What I can say, my setup works at least for the gcc-8 branch and used to
> >>> work in the past.
> >> I tested dg-extractresults.sh manually and found that the change from
> >> 4th of February, revision 268411 broke the log extraction. Easy to test
> >> with version from 23rd of September last year which works.
> >>
> >> I don't have the time to analyze the python version, but my bet, it's
> >> the same issue.
> >>
> > Hi,
> >
> > Sorry for the breakage, I really wanted to improve those scripts.
> > Could you give me a reproducer, since we didn't notice problems in our
> > validations?
> Hi Christope,
>
> I executed the dg-extract-results.sh manually in the gcc/testsuite
> directory after a complete testsuite run which didn't give the correct
> results. Rev. 240429 gives the expected results, where rev 268511 fails.
> I'm on windows using msys2 with bash 4.4.23.
>
> I'm bootsrapping at the moment but that's really slow on windows. When
> the testsuite run is finished I try to assemble a reproducer. This will
> take a while.
>
OK, thanks! Do you mean the problem happens on Windows only?
> Thanks,
>
> Rainer
>
Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32
Am 16.04.2019 um 14:49 schrieb Christophe Lyon:
> On Tue, 16 Apr 2019 at 14:34, Rainer Emrich
> wrote:
>>
>> Am 16.04.2019 um 14:10 schrieb Christophe Lyon:
>>> On Tue, 16 Apr 2019 at 13:04, Rainer Emrich
>>> wrote:
Am 16.04.2019 um 11:59 schrieb Rainer Emrich:
> Am 15.04.2019 um 20:12 schrieb Rainer Emrich:
>> Am 15.04.2019 um 17:43 schrieb Rainer Emrich:
>>> Am 15.04.2019 um 17:38 schrieb Jakub Jelinek:
On Mon, Apr 15, 2019 at 05:30:14PM +0200, Rainer Emrich wrote:
> There seems to be a generic issue with the tests in gcc/testsuite. The
> log files do not contain the logs.
Perhaps contrib/dg-extract-results* misbehaved?
Can you look for the testsuite/g++*/g++.log.sep files? Do they contain
everything?
>> The *.log.sep files seem to be ok.
>>
If yes, can you try to say
mv contrib/dg-extract-results.py{,.bad}
and retry, to see if there isn't a problem with the python version
thereof?
>> I will try this over the night.
> The shell version of dg-extract-results does not work either.
>
> AFAIS, there were changes to the dg-extract-results script 5th of March.
> Looks like these changes are causing the issue, but I'm not sure.
>
> What I can say, my setup works at least for the gcc-8 branch and used to
> work in the past.
I tested dg-extractresults.sh manually and found that the change from
4th of February, revision 268411 broke the log extraction. Easy to test
with version from 23rd of September last year which works.
I don't have the time to analyze the python version, but my bet, it's
the same issue.
>>> Hi,
>>>
>>> Sorry for the breakage, I really wanted to improve those scripts.
>>> Could you give me a reproducer, since we didn't notice problems in our
>>> validations?
>> Hi Christope,
>>
>> I executed the dg-extract-results.sh manually in the gcc/testsuite
>> directory after a complete testsuite run which didn't give the correct
>> results. Rev. 240429 gives the expected results, where rev 268511 fails.
>> I'm on windows using msys2 with bash 4.4.23.
>>
>> I'm bootsrapping at the moment but that's really slow on windows. When
>> the testsuite run is finished I try to assemble a reproducer. This will
>> take a while.
>>
>
> OK, thanks! Do you mean the problem happens on Windows only?
I don't know at the moment, because im only bootstrapping and testing on
windows on a semi regular basis. AFAIK I'm the only person which is
doing semi regular testsuite runs on windows and pushing the results to
gcc-testresults mailing list.
I doubt that I will find the time for bootstrapping and running the
testsuite on linux in the next few days.
signature.asc
Description: OpenPGP digital signature
Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32
On Tue, Apr 16, 2019 at 02:49:13PM +0200, Christophe Lyon wrote: > > I executed the dg-extract-results.sh manually in the gcc/testsuite > > directory after a complete testsuite run which didn't give the correct > > results. Rev. 240429 gives the expected results, where rev 268511 fails. > > I'm on windows using msys2 with bash 4.4.23. > > > > I'm bootsrapping at the moment but that's really slow on windows. When > > the testsuite run is finished I try to assemble a reproducer. This will > > take a while. > > > > OK, thanks! Do you mean the problem happens on Windows only? It is not on Windows only, I e.g. see the same problem on Linux too, unfortunately only when doing package builds. E.g. https://kojipkgs.fedoraproject.org//work/tasks/3883/34193883/build.log In the ===TESTING=== section where it emits result of contrib/test_summary the results look reasonable (though, the ordering looks random-ish even when it is always LC_ALL=C, so if there are multiple FAILs, diffing them from one build to another has -FAIL and +FAIL lines for the same tests), but if you uudecode the file (with more recent uudecode one needs to extract the begin ... end part manually, what a progress :( ) in the tarball any *.log files changed with dg-extract-results.py contain just Running lines and no further details. Others like libgomp.log are complete, but those are not merged. I get those almost empty *.log files even after rm -f contrib/dg-extract-results.py (which should force the *.sh version). I can't reproduce this on my Fedora 29 x86_64-linux bootstrap box though, the *.log files are complete there. And I have no idea if it was introduced with your change or earlier. Jakub
Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32
On Tue, Apr 16, 2019 at 03:44:44PM +0200, Jakub Jelinek wrote:
> I can't reproduce this on my Fedora 29 x86_64-linux bootstrap box though,
> the *.log files are complete there.
>
> And I have no idea if it was introduced with your change or earlier.
Actually, I managed to reproduce in a Fedora 31 chroot, in which I don't
have /usr/bin/python installed (I think in Fedora 30+ there is
/usr/bin/python2 and /usr/bin/python3 but not /usr/bin/python, at least not
in the default buildroot).
The changes to contrib/dg-extract-results.sh look wrong to me:
--- contrib/dg-extract-results.sh 2018-04-25 09:40:40.139659386 +0200
+++ contrib/dg-extract-results.sh 2019-03-05 21:49:34.471573434 +0100
@@ -298,6 +298,8 @@ BEGIN {
cnt=0
print_using=0
need_close=0
+ has_timeout=0
+ timeout_cnt=0
}
/^EXPFILE: / {
expfiles[expfileno] = \$2
@@ -329,16 +331,37 @@ BEGIN {
# Ugly hack for gfortran.dg/dg.exp
if ("$TOOL" == "gfortran" && testname ~ /^gfortran.dg\/g77\//)
testname="h"testname
+ if (\$1 == "WARNING:" && \$2 == "program" && \$3 == "timed" && (\$4 == "out"
|| \$4 == "out.")) {
+has_timeout=1
+timeout_cnt=cnt
+ } else {
+ # Prepare timeout replacement message in case it's needed
+timeout_msg=\$0
+sub(\$1, "WARNING:", timeout_msg)
+ }
}
/^$/ { if ("$MODE" == "sum") next }
{ if (variant == curvar && curfile) {
if ("$MODE" == "sum") {
- printf "%s %08d|", testname, cnt >> curfile
- cnt = cnt + 1
+ # Do not print anything if the current line is a timeout
+ if (has_timeout == 0) {
+# If the previous line was a timeout,
+# insert the full current message without keyword
+if (timeout_cnt != 0) {
+ printf "%s %08d|%s program timed out.\n", testname, timeout_cnt,
timeout_msg >> curfile
+ timeout_cnt = 0
+ cnt = cnt + 1
+}
+printf "%s %08d|", testname, cnt >> curfile
+cnt = cnt + 1
+filewritten[curfile]=1
+need_close=1
+if (timeout_cnt == 0)
+ print >> curfile
+ }
+
+ has_timeout=0
}
-filewritten[curfile]=1
-need_close=1
-print >> curfile
} else
next
}
First of all, I don't see why the WARNING: program timed out
stuff should be handled in any way specially in -L mode, there is no sorting
at all and all the lines go together. But more importantly, the above
changes broke completely the -L mode, previously the filewritten, need_close
and print lines were done for both sum and log modes, but now they are done
only in the sum mode (and in that case only if has_timeout is 0, which is
desirable).
I believe the following patch should fix it, but I don't actually have any
WARNING: program timed out
lines in my *.sep files in any of the last 12 bootstraps I have around.
Additionally, perhaps we should change dg-extract-results.sh, so that it
doesn't try just python, but also python3? I think in some distros
/usr/bin/python even warns users that they should decide if they mean
python2 or python3.
2019-04-16 Jakub Jelinek
* dg-extract-results.sh: Only handle WARNING: program timed out
lines specially in "$MODE" == "sum". Restore previous behavior
for "$MODE" != "sum". Clear has_timeout and timeout_cnt if in
a different variant or curfile is empty.
* dg-extract-results.py: Fix a typo.
--- contrib/dg-extract-results.sh.jj2019-03-05 21:49:34.471573434 +0100
+++ contrib/dg-extract-results.sh 2019-04-16 17:09:02.710004553 +0200
@@ -331,13 +331,15 @@ BEGIN {
# Ugly hack for gfortran.dg/dg.exp
if ("$TOOL" == "gfortran" && testname ~ /^gfortran.dg\/g77\//)
testname="h"testname
- if (\$1 == "WARNING:" && \$2 == "program" && \$3 == "timed" && (\$4 == "out"
|| \$4 == "out.")) {
-has_timeout=1
-timeout_cnt=cnt
- } else {
- # Prepare timeout replacement message in case it's needed
-timeout_msg=\$0
-sub(\$1, "WARNING:", timeout_msg)
+ if ("$MODE" == "sum") {
+if (\$0 ^ /^WARNING: program timed out/) {
+ has_timeout=1
+ timeout_cnt=cnt
+} else {
+ # Prepare timeout replacement message in case it's needed
+ timeout_msg=\$0
+ sub(\$1, "WARNING:", timeout_msg)
+}
}
}
/^$/ { if ("$MODE" == "sum") next }
@@ -345,25 +347,30 @@ BEGIN {
if ("$MODE" == "sum") {
# Do not print anything if the current line is a timeout
if (has_timeout == 0) {
-# If the previous line was a timeout,
-# insert the full current message without keyword
-if (timeout_cnt != 0) {
- printf "%s %08d|%s program timed out.\n", testname, timeout_cnt,
timeout_msg >> curfile
- timeout_cnt = 0
- cnt = cnt + 1
-}
-printf "%s %08d|", testname, cnt >> curfile
-cnt = cnt + 1
-filewritten[curfile]=1
-need_close=1
-if (timeout_cnt == 0)
- print >> curfile
+ # If the previous line was a timeout,
+
Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32
Hi, On Tue, Apr 16 2019, Jakub Jelinek wrote: > On Tue, Apr 16, 2019 at 02:49:13PM +0200, Christophe Lyon wrote: >> > I executed the dg-extract-results.sh manually in the gcc/testsuite >> > directory after a complete testsuite run which didn't give the correct >> > results. Rev. 240429 gives the expected results, where rev 268511 fails. >> > I'm on windows using msys2 with bash 4.4.23. >> > >> > I'm bootsrapping at the moment but that's really slow on windows. When >> > the testsuite run is finished I try to assemble a reproducer. This will >> > take a while. >> > >> >> OK, thanks! Do you mean the problem happens on Windows only? > > It is not on Windows only, I e.g. see the same problem on Linux too, > unfortunately only when doing package builds. > > E.g. > https://kojipkgs.fedoraproject.org//work/tasks/3883/34193883/build.log > In the ===TESTING=== section where it emits result of contrib/test_summary > the results look reasonable (though, the ordering looks random-ish even > when it is always LC_ALL=C, so if there are multiple FAILs, diffing them > from one build to another has -FAIL and +FAIL lines for the same tests), > but if you uudecode the file (with more recent uudecode one needs to extract > the begin ... end part manually, what a progress :( ) in the tarball any > *.log files changed with dg-extract-results.py contain just Running lines > and no further details. Others like libgomp.log are complete, but those are > not merged. I get those almost empty *.log files even after > rm -f contrib/dg-extract-results.py > (which should force the *.sh version). > > I can't reproduce this on my Fedora 29 x86_64-linux bootstrap box though, > the *.log files are complete there. > My experience might be completely unrelated, but I was getting empty *.sum files (the big merged ones) - and I believe also empty .log files but I am not longer sure - on a big Linux machine where a lot people build stuff and the reason was that I was hitting some maximum cgroup PID number limit that SUSE systemd invented for me/us in: /sys/fs/cgroup/pids/user.slice/user-$UID.slice/pids.max After setting that to "max" the problems never again materialized. In any event, it is worth checking whether some system limits do not prevent spawning new processes, I believe there were messages about it extractable from logs (or rather journalctl). Martin
Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32
Am 16.04.2019 um 17:36 schrieb Jakub Jelinek:
> On Tue, Apr 16, 2019 at 03:44:44PM +0200, Jakub Jelinek wrote:
>> I can't reproduce this on my Fedora 29 x86_64-linux bootstrap box though,
>> the *.log files are complete there.
>>
>> And I have no idea if it was introduced with your change or earlier.
>
> Actually, I managed to reproduce in a Fedora 31 chroot, in which I don't
> have /usr/bin/python installed (I think in Fedora 30+ there is
> /usr/bin/python2 and /usr/bin/python3 but not /usr/bin/python, at least not
> in the default buildroot).
On msys2 there is no python executable but /usr/bin/python2.
Optionally you may install python3.
>
> The changes to contrib/dg-extract-results.sh look wrong to me:
> --- contrib/dg-extract-results.sh 2018-04-25 09:40:40.139659386 +0200
> +++ contrib/dg-extract-results.sh 2019-03-05 21:49:34.471573434 +0100
> @@ -298,6 +298,8 @@ BEGIN {
>cnt=0
>print_using=0
>need_close=0
> + has_timeout=0
> + timeout_cnt=0
> }
> /^EXPFILE: / {
>expfiles[expfileno] = \$2
> @@ -329,16 +331,37 @@ BEGIN {
># Ugly hack for gfortran.dg/dg.exp
>if ("$TOOL" == "gfortran" && testname ~ /^gfortran.dg\/g77\//)
> testname="h"testname
> + if (\$1 == "WARNING:" && \$2 == "program" && \$3 == "timed" && (\$4 ==
> "out" || \$4 == "out.")) {
> +has_timeout=1
> +timeout_cnt=cnt
> + } else {
> + # Prepare timeout replacement message in case it's needed
> +timeout_msg=\$0
> +sub(\$1, "WARNING:", timeout_msg)
> + }
> }
> /^$/ { if ("$MODE" == "sum") next }
> { if (variant == curvar && curfile) {
> if ("$MODE" == "sum") {
> - printf "%s %08d|", testname, cnt >> curfile
> - cnt = cnt + 1
> + # Do not print anything if the current line is a timeout
> + if (has_timeout == 0) {
> +# If the previous line was a timeout,
> +# insert the full current message without keyword
> +if (timeout_cnt != 0) {
> + printf "%s %08d|%s program timed out.\n", testname, timeout_cnt,
> timeout_msg >> curfile
> + timeout_cnt = 0
> + cnt = cnt + 1
> +}
> +printf "%s %08d|", testname, cnt >> curfile
> +cnt = cnt + 1
> +filewritten[curfile]=1
> +need_close=1
> +if (timeout_cnt == 0)
> + print >> curfile
> + }
> +
> + has_timeout=0
> }
> -filewritten[curfile]=1
> -need_close=1
> -print >> curfile
>} else
> next
> }
> First of all, I don't see why the WARNING: program timed out
> stuff should be handled in any way specially in -L mode, there is no sorting
> at all and all the lines go together. But more importantly, the above
> changes broke completely the -L mode, previously the filewritten, need_close
> and print lines were done for both sum and log modes, but now they are done
> only in the sum mode (and in that case only if has_timeout is 0, which is
> desirable).
>
> I believe the following patch should fix it, but I don't actually have any
> WARNING: program timed out
> lines in my *.sep files in any of the last 12 bootstraps I have around.
I do have several "program timed out" in libgomp, so I may test this.
>
> Additionally, perhaps we should change dg-extract-results.sh, so that it
> doesn't try just python, but also python3? I think in some distros
> /usr/bin/python even warns users that they should decide if they mean
> python2 or python3.
As explained above I vote for this change.
signature.asc
Description: OpenPGP digital signature
Google Season of Docs: GIMPLE Documentation request for mentors
Google is offering to pair and sponsor documentation writers for topics in Open Source projects. A number of new developers have requested better documentation of GIMPLE and I would like to submit a proposal, but we need mentors for the documentation writer. Google Season of Docs is scheduled for Fall, after GSoC, but the deadline to nominate a project is soon. Is anyone with GIMPLE knowedge and experience willing to volunteer to mentor a documentation writer so that we can improve the GCC documentation and make it easier for developers to participate in GCC? Thanks, David
Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32
On Tue, 16 Apr 2019 at 17:36, Jakub Jelinek wrote:
>
> On Tue, Apr 16, 2019 at 03:44:44PM +0200, Jakub Jelinek wrote:
> > I can't reproduce this on my Fedora 29 x86_64-linux bootstrap box though,
> > the *.log files are complete there.
> >
> > And I have no idea if it was introduced with your change or earlier.
>
> Actually, I managed to reproduce in a Fedora 31 chroot, in which I don't
> have /usr/bin/python installed (I think in Fedora 30+ there is
> /usr/bin/python2 and /usr/bin/python3 but not /usr/bin/python, at least not
> in the default buildroot).
>
> The changes to contrib/dg-extract-results.sh look wrong to me:
> --- contrib/dg-extract-results.sh 2018-04-25 09:40:40.139659386 +0200
> +++ contrib/dg-extract-results.sh 2019-03-05 21:49:34.471573434 +0100
> @@ -298,6 +298,8 @@ BEGIN {
>cnt=0
>print_using=0
>need_close=0
> + has_timeout=0
> + timeout_cnt=0
> }
> /^EXPFILE: / {
>expfiles[expfileno] = \$2
> @@ -329,16 +331,37 @@ BEGIN {
># Ugly hack for gfortran.dg/dg.exp
>if ("$TOOL" == "gfortran" && testname ~ /^gfortran.dg\/g77\//)
> testname="h"testname
> + if (\$1 == "WARNING:" && \$2 == "program" && \$3 == "timed" && (\$4 ==
> "out" || \$4 == "out.")) {
> +has_timeout=1
> +timeout_cnt=cnt
> + } else {
> + # Prepare timeout replacement message in case it's needed
> +timeout_msg=\$0
> +sub(\$1, "WARNING:", timeout_msg)
> + }
> }
> /^$/ { if ("$MODE" == "sum") next }
> { if (variant == curvar && curfile) {
> if ("$MODE" == "sum") {
> - printf "%s %08d|", testname, cnt >> curfile
> - cnt = cnt + 1
> + # Do not print anything if the current line is a timeout
> + if (has_timeout == 0) {
> +# If the previous line was a timeout,
> +# insert the full current message without keyword
> +if (timeout_cnt != 0) {
> + printf "%s %08d|%s program timed out.\n", testname, timeout_cnt,
> timeout_msg >> curfile
> + timeout_cnt = 0
> + cnt = cnt + 1
> +}
> +printf "%s %08d|", testname, cnt >> curfile
> +cnt = cnt + 1
> +filewritten[curfile]=1
> +need_close=1
> +if (timeout_cnt == 0)
> + print >> curfile
> + }
> +
> + has_timeout=0
> }
> -filewritten[curfile]=1
> -need_close=1
> -print >> curfile
>} else
> next
> }
> First of all, I don't see why the WARNING: program timed out
> stuff should be handled in any way specially in -L mode, there is no sorting
> at all and all the lines go together. But more importantly, the above
The "WARNING: program timed out" stuff needs to be handled specially
in non-L mode (when handling .sum), because in that case we are using
"sort", which used to put all "WARNING:" lines together before most of
the report.
> changes broke completely the -L mode, previously the filewritten, need_close
> and print lines were done for both sum and log modes, but now they are done
> only in the sum mode (and in that case only if has_timeout is 0, which is
> desirable).
>
I did check my patch against .sum and .log files, but it looks like my
tests were incomplete, sorry for that.
> I believe the following patch should fix it, but I don't actually have any
> WARNING: program timed out
> lines in my *.sep files in any of the last 12 bootstraps I have around.
You can just insert one such line in your .sum/.log manually, and
possibly replace a PASS with a FAIL to check that the WARNING and FAIL
are kept next to each other in the .sum (that was my original
intention).
Christophe
>
> Additionally, perhaps we should change dg-extract-results.sh, so that it
> doesn't try just python, but also python3? I think in some distros
> /usr/bin/python even warns users that they should decide if they mean
> python2 or python3.
>
> 2019-04-16 Jakub Jelinek
>
> * dg-extract-results.sh: Only handle WARNING: program timed out
> lines specially in "$MODE" == "sum". Restore previous behavior
> for "$MODE" != "sum". Clear has_timeout and timeout_cnt if in
> a different variant or curfile is empty.
> * dg-extract-results.py: Fix a typo.
>
> --- contrib/dg-extract-results.sh.jj2019-03-05 21:49:34.471573434 +0100
> +++ contrib/dg-extract-results.sh 2019-04-16 17:09:02.710004553 +0200
> @@ -331,13 +331,15 @@ BEGIN {
># Ugly hack for gfortran.dg/dg.exp
>if ("$TOOL" == "gfortran" && testname ~ /^gfortran.dg\/g77\//)
> testname="h"testname
> - if (\$1 == "WARNING:" && \$2 == "program" && \$3 == "timed" && (\$4 ==
> "out" || \$4 == "out.")) {
> -has_timeout=1
> -timeout_cnt=cnt
> - } else {
> - # Prepare timeout replacement message in case it's needed
> -timeout_msg=\$0
> -sub(\$1, "WARNING:", timeout_msg)
> + if ("$MODE" == "sum") {
> +if (\$0 ^ /^WARNING: program timed out/) {
> + has_timeout=1
> + timeout_cnt=cnt
> +} else {
> + # Prepare timeout replacement mess
