GCC 8 vs. GCC 9 speed and size comparison
Hi. There's a similar comparison that I did for the official openSUSE gcc packages. gcc8 is built with PGO, while the gcc9 package is built in 2 different configurations: PGO, LTO, PGO+LTO (LTO used for FE in stage4, for generators in stage3 as well). Please take a look at attached statistics. Martin gcc8-gcc9-comparison.ods Description: application/vnd.oasis.opendocument.spreadsheet
Re: GCC 8 vs. GCC 9 speed and size comparison
Hi, On Mon, 15 Apr 2019, Martin Liška wrote: > There's a similar comparison that I did for the official openSUSE gcc > packages. gcc8 is built with PGO, while the gcc9 package is built in 2 > different configurations: PGO, LTO, PGO+LTO (LTO used for FE in stage4, > for generators in stage3 as well). > > Please take a look at attached statistics. 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 trigger this behaviour, so it's probably something to do with templates and/or classes. Ciao, Michael.
Re: GCC 8 vs. GCC 9 speed and size comparison
> Hi, > > On Mon, 15 Apr 2019, Martin Liška wrote: > > > There's a similar comparison that I did for the official openSUSE gcc > > packages. gcc8 is built with PGO, while the gcc9 package is built in 2 > > different configurations: PGO, LTO, PGO+LTO (LTO used for FE in stage4, > > for generators in stage3 as well). > > > > Please take a look at attached statistics. > > 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 > trigger this behaviour, so it's probably something to do with templates > and/or classes. Would be possible to have -ftime-report for your tramp3d build with the four compilers? It may be a consequence of training changes and i.e. template instantiation code which is excercised by tramp3d a lot more than by GCC bootstrap. But it still seem bit too much for simple PGO divergence. It also may be caused by changes of inliner decisions or some other pass being overly active. Honza > > > Ciao, > Michael.
Re: GCC 8 vs. GCC 9 speed and size comparison
On Mon, Apr 15, 2019 at 12:12:13PM +, Michael Matz wrote: > Hi, > > On Mon, 15 Apr 2019, Martin Liška wrote: > > > There's a similar comparison that I did for the official openSUSE gcc > > packages. gcc8 is built with PGO, while the gcc9 package is built in 2 > > different configurations: PGO, LTO, PGO+LTO (LTO used for FE in stage4, > > for generators in stage3 as well). > > > > Please take a look at attached statistics. > > 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. Jakub
Re: GCC 8 vs. GCC 9 speed and size comparison
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.
Ciao,
Michael.
Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32
Today I had the chance to bootstrap and runthe testsuite for trunk on
x86_64-w64-mingw32. Bootstrap is done with all supported languages
enabled including "D".
Testsuite results can be found here:
https://gcc.gnu.org/ml/gcc-testresults/2019-04/msg01795.html
Complete logs here:
https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W
There's are two issues with the gdc testsuite.
1. The failed tests are printed twenty times to the test_summary.txt file.
2. couldn't open "gdc.test/compilable/99bottles.d"
ERROR: tcl error sourcing
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/gdc.test/gdc-test.exp.
ERROR: couldn't open "gdc.test/compilable/99bottles.d": no such file or
directory
while executing
"open $file r"
(procedure "grep" line 19)
invoked from within
"grep $prog "{\[ \t\]\+dg-\[-a-z\]\+\[ \t\]\+.*\[ \t\]\+}" line"
(procedure "dg-get-options" line 4)
invoked from within
"dg-get-options $prog"
(procedure "saved-dg-test" line 75)
invoked from within
"saved-dg-test gdc.test/compilable/99bottles.d { }
-I/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/gdc.test/compilable"
("eval" body line 1)
invoked from within
"eval saved-dg-test $args "
(procedure "dg-test" line 4)
invoked from within
"dg-test $test "$flags $flags_t" ${default-extra-flags}"
(procedure "gdc-dg-runtest" line 23)
invoked from within
"gdc-dg-runtest $filename $flags $imports"
(procedure "gdc-do-test" line 86)
invoked from within
"gdc-do-test"
(file
"/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/gdc.test/gdc-test.exp"
line 465)
invoked from within
"source
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/gdc.test/gdc-test.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/gdc.test/gdc-test.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
Hope this is of any help
signature.asc
Description: OpenPGP digital signature
Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32
Am 15.04.2019 um 17:22 schrieb Rainer Emrich:
> Today I had the chance to bootstrap and runthe testsuite for trunk on
> x86_64-w64-mingw32. Bootstrap is done with all supported languages
> enabled including "D".
>
> Testsuite results can be found here:
> https://gcc.gnu.org/ml/gcc-testresults/2019-04/msg01795.html
>
> Complete logs here:
> https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W
>
> There's are two issues with the gdc testsuite.
> 1. The failed tests are printed twenty times to the test_summary.txt file.
>
> 2. couldn't open "gdc.test/compilable/99bottles.d"
> ERROR: tcl error sourcing
> /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/gdc.test/gdc-test.exp.
> ERROR: couldn't open "gdc.test/compilable/99bottles.d": no such file or
> directory
> while executing
> "open $file r"
> (procedure "grep" line 19)
> invoked from within
> "grep $prog "{\[ \t\]\+dg-\[-a-z\]\+\[ \t\]\+.*\[ \t\]\+}" line"
> (procedure "dg-get-options" line 4)
> invoked from within
> "dg-get-options $prog"
> (procedure "saved-dg-test" line 75)
> invoked from within
> "saved-dg-test gdc.test/compilable/99bottles.d { }
> -I/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/gdc.test/compilable"
> ("eval" body line 1)
> invoked from within
> "eval saved-dg-test $args "
> (procedure "dg-test" line 4)
> invoked from within
> "dg-test $test "$flags $flags_t" ${default-extra-flags}"
> (procedure "gdc-dg-runtest" line 23)
> invoked from within
> "gdc-dg-runtest $filename $flags $imports"
> (procedure "gdc-do-test" line 86)
> invoked from within
> "gdc-do-test"
> (file
> "/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/gdc.test/gdc-test.exp"
> line 465)
> invoked from within
> "source
> /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/gdc.test/gdc-test.exp"
> ("uplevel" body line 1)
> invoked from within
> "uplevel #0 source
> /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/gdc.test/gdc-test.exp"
> invoked from within
> "catch "uplevel #0 source $test_file_name""
>
> Hope this is of any help
>
There seems to be a generic issue with the tests in gcc/testsuite. The
log files do not contain the logs.
g++.log contains the following for example:
Test run by rainer on Mon Apr 15 10:52:52 2019
Native configuration is x86_64-w64-mingw32
=== g++ tests ===
Schedule of variations:
unix
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file
for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for
target.
Using
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/config/default.exp
as tool-and-target-specific interface file.
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/asan/asan.exp
...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/bprob/bprob.exp
...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/charset/charset.exp
...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/compat/compat.exp
...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/compat/struct-layout-1.exp
...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/debug/debug.exp
...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/debug/dwarf2/dwarf2.exp
...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/dfp/dfp.exp
...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/dg.exp ...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/gcov/gcov.exp
...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/goacc-gomp/goacc-gomp.exp
...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/goacc/goacc.exp
...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/gomp/gomp.exp
...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/graphite/graphite.exp
...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/guality/guality.exp
...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/lto/lto.exp
...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/pch/pch.exp
...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/plugin/plugin.exp
...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/simulate-thread/simulate-thread.exp
...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/special/ecos.exp
...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/tls/tls.exp
...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/tm/tm.exp ...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/torture/dg-torture.exp
...
Running
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.1/gcc/testsuite/g++.dg/torture/stackali
Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32
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?
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?
Jakub
Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32
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?
> 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?
Unfortunately I already deleted the build directory.
So, I will run a new bootstrap an testsuite run reduced with reduced
languages. Will take some hours.
Rainer
signature.asc
Description: OpenPGP digital signature
Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32
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.
Rainer
signature.asc
Description: OpenPGP digital signature
New Documents For(gcc@gcc.gnu.org)Your Shipment **Shipping SF Electronic Invoice Notification.**
\0Ae6Cv84�7AN30�1F�D0[A2b37�1A `A8Y7D gcc@gcc.gnu.org
a1F�22`A8�09bE9�7AN30�1F�D0N3A`A8cD0O9Bv84e36m3Eg0DRA1002
`A8u33�F7v84u35[50SD1y68]F2b10R9F_00Q77�01SD1y68�E6`C5Y82N0B�1A
SD1y68NE3x01�1A019093877133873SD1y68SF7x01�1A5123338323SD1y68�D1�9D�1A6539.9Q43
S05T2Bv84�D0S55SF7�1A `A8SEFNE5pB9QFBNE5N0B�FEcA5N0B�7Du35[50SD1y68002
1001N0B�7DPDFh3C_0Fu35[50SD1y68 2001N0B�7DJPGh3C_0Fu35[50SD1y68
|FB~DF�AE{B1�0C�F7RFFVDEY0D002Y82g09�00l42�0C�F7�54|FBe36m3ET58b16[A2g0D�0C�22�22�
Feature request: Don't warn for specified "unknown" attribute
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]]. Thank you, Justin Bassett
11:27(烟.草/漏/税)*** 11:27
本批发*商*行专销由烟草漏税香烟！2019/4/16 中华（软329）￥380 （硬盒）￥280 : 芙蓉王（硬）￥160 黄鹤楼（1916）￥400 品种多多不一一介绍需要V信咨询； 李*经*理；134-1693-7477 V信同号 11:27 2019/4/16
