Re: testsuite requires LTO?
On Tue, Apr 12, 2022 at 1:53 AM Steve Kargl via Gcc wrote:
>
> If I configure gcc with the following
>
> ../gccx/configure --prefix=$HOME/work/x --enable-languages=c,c++,fortran \
> --enable-bootstrap --disable-nls --enable-checking --disable-multilib \
> --disable-libsanitizer --disable-lto.
>
> then bootstrap gcc, why do I see 1000s of failures with
>
> % cd gcc
> % gmake -j7 check-c
> ...
> FAIL: gcc.dg/torture/pr64365.c -O2 -flto (test for excess errors)
> FAIL: gcc.dg/torture/pr61786.c -O2 -flto (test for excess errors)
> FAIL: gcc.dg/torture/pr63380-2.c -O2 -flto (test for excess errors)
> FAIL: gcc.dg/torture/pr65270-2.c -O2 -flto (test for excess errors)
>
> Should the testsuite recognize that gcc is built without LTO support?
Yes, it does, in testsuite/lib/gcc-dg.exp
if [info exists TORTURE_OPTIONS] {
set DG_TORTURE_OPTIONS $TORTURE_OPTIONS
} else {
# It is theoretically beneficial to group all of the O2/O3 options together,
# as in many cases the compiler will generate identical executables for
# all of them--and the c-torture testsuite will skip testing identical
# executables multiple times.
# Also note that -finline-functions is explicitly included in one of the
# items below, even though -O3 is also specified, because some ports may
# choose to disable inlining functions by default, even when optimizing.
set DG_TORTURE_OPTIONS [list \
{ -O0 } \
{ -O1 } \
{ -O2 } \
{ -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops
-ftracer -finline-functions } \
{ -O3 -g } \
{ -Os } ]
if [check_effective_target_lto] {
# When having plugin test both slim and fat LTO and plugin/nonplugin
# path.
if [check_linker_plugin_available] {
set LTO_TORTURE_OPTIONS [list \
{ -O2 -flto -fno-use-linker-plugin -flto-partition=none } \
{ -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects }
]
} else {
set LTO_TORTURE_OPTIONS [list \
{ -O2 -flto -flto-partition=none } \
{ -O2 -flto }
]
}
so either TORTURE_OPTIONS is set or check_effective_target_lto doesn't work.
The check does simply
return [check_no_compiler_messages lto object {
void foo (void) { }
} "-flto"]
so I wonder what your excess errors are? The check above should also
leave traces
in the testsuite log. It might be that --disable-lto doesn't disable
gcc -c -flto but just
disables lto1 building though.
>
> --
> Steve
Re: testsuite requires LTO?
On Tue, Apr 12, 2022 at 9:07 AM Richard Biener
wrote:
>
> On Tue, Apr 12, 2022 at 1:53 AM Steve Kargl via Gcc wrote:
> >
> > If I configure gcc with the following
> >
> > ../gccx/configure --prefix=$HOME/work/x --enable-languages=c,c++,fortran \
> > --enable-bootstrap --disable-nls --enable-checking --disable-multilib \
> > --disable-libsanitizer --disable-lto.
> >
> > then bootstrap gcc, why do I see 1000s of failures with
> >
> > % cd gcc
> > % gmake -j7 check-c
> > ...
> > FAIL: gcc.dg/torture/pr64365.c -O2 -flto (test for excess errors)
> > FAIL: gcc.dg/torture/pr61786.c -O2 -flto (test for excess errors)
> > FAIL: gcc.dg/torture/pr63380-2.c -O2 -flto (test for excess errors)
> > FAIL: gcc.dg/torture/pr65270-2.c -O2 -flto (test for excess errors)
> >
> > Should the testsuite recognize that gcc is built without LTO support?
>
> Yes, it does, in testsuite/lib/gcc-dg.exp
>
> if [info exists TORTURE_OPTIONS] {
> set DG_TORTURE_OPTIONS $TORTURE_OPTIONS
> } else {
> # It is theoretically beneficial to group all of the O2/O3 options
> together,
> # as in many cases the compiler will generate identical executables for
> # all of them--and the c-torture testsuite will skip testing identical
> # executables multiple times.
> # Also note that -finline-functions is explicitly included in one of the
> # items below, even though -O3 is also specified, because some ports may
> # choose to disable inlining functions by default, even when optimizing.
> set DG_TORTURE_OPTIONS [list \
> { -O0 } \
> { -O1 } \
> { -O2 } \
> { -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops
> -ftracer -finline-functions } \
> { -O3 -g } \
> { -Os } ]
>
> if [check_effective_target_lto] {
> # When having plugin test both slim and fat LTO and plugin/nonplugin
> # path.
> if [check_linker_plugin_available] {
>set LTO_TORTURE_OPTIONS [list \
> { -O2 -flto -fno-use-linker-plugin -flto-partition=none } \
> { -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects }
>]
> } else {
>set LTO_TORTURE_OPTIONS [list \
> { -O2 -flto -flto-partition=none } \
> { -O2 -flto }
>]
> }
>
> so either TORTURE_OPTIONS is set or check_effective_target_lto doesn't work.
> The check does simply
>
> return [check_no_compiler_messages lto object {
> void foo (void) { }
> } "-flto"]
>
> so I wonder what your excess errors are? The check above should also
> leave traces
> in the testsuite log. It might be that --disable-lto doesn't disable
> gcc -c -flto but just
> disables lto1 building though.
I checked and it works fine for me, --disable-lto disables LTO support
and there's
no extra FAILs in dg-torture.exp. The testsuite log has
Executing on host: /tmp/obj/gcc/xgcc -B/tmp/obj/gcc/
-fdiagnostics-plain-output -flto -c -o lto10207.o lto10207.c
(timeout = 300)
spawn -ignore SIGHUP /tmp/obj/gcc/xgcc -B/tmp/obj/gcc/
-fdiagnostics-plain-output -flto -c -o lto10207.o lto10207.c^M
cc1: error: LTO support has not been enabled in this configuration^M
compiler exited with status 1
which causes no -flto to be used.
Richard.
>
> >
> > --
> > Steve
Re: [CVE] zlib (< 1.2.12) memory corruption
Hi Nick, On 4/8/22 14:36, Nick Clifton wrote: Hi Luis, There is a CVE [1] for zlib < 1.2.12 (released march 27th). GCC currently uses zlib 1.2.11, and binutils-gdb imports the zlib directory from GCC. The recommendation is to get it updated to 1.2.12, which contains the proper fix [2]. I am all for updating the binutils-gdb copy of zlib. I will wait a couple of days to see if anyone else has any comments or concerns, but if not, then I will apply the patches myself. I did a quick check and there seems to be some differences between gcc's zlib subdir and binutils-gdb's zlib subdir. I think there has been some fixes that we may have to port over from our current zlib subdir. I tried simply replacing the subdir, but that didn't work right.
Re: testsuite requires LTO?
On Apr 11 2022, Steve Kargl via Gcc wrote: > Should the testsuite recognize that gcc is built without LTO support? Yes, we have check_effective_target_lto for that. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [GSoC]Bypass assembler when generating LTO object files
Hi, > > > > On 08-Apr-2022, at 6:32 PM, Jan Hubicka wrote: > > > > Ankur, > >> I was browsing the list of submitted GSoC projects this year and the > >> project regarding bypassing assembler when generating LTO object files > >> caught my eye. > > I apologize for late reply. I would be very happy to mentor this > > project. > > Thanks for the reply, but unfortunately, due to some reasons, I would not > be able to take part in GSoC this year. > But the project seems interesting and would be amazing opportunity to > learn a lot more things for me, so would it be okay if I try to give it a > go outside GSoC if no-one else picks it as their GSoC project this year ? I would be still very happy to help with that! However it would be also pity to not take part of GSoC, so if there is something I can help with on that let me know. > > >> > >> I already have a gcc built from source (sync-ed with trunk/master) and > >> launched the test-suite on it. > >> > >> I am currently in process of understanding the primilary patch > >> (https://gcc.gnu.org/legacy-ml/gcc/2014-09/msg00340.html), and > >> experimenting with it. > >> > >> are there any other things I should be aware of (useful Doc/blog or a > >> bug tracking the project) before proceeding further ? > > > > I think it is pretty much all that exists. Basically we will need to > > implement everything that is necessary to stream out valid object file > > directly from GCC rather than going through gas. The experimental > > prototype sort of worked but it was lacking few things. > > When I try to apply that patch on my local branch ( branched from trunk ), > it seem to be incompatible with the current working tree. Is there a > specific branch that I have to apply it to ? or is it due to the recent > file rename patch ( changing extensions from .c to .cc ) ? > > ``` > $ git apply --check bypass_asm_patch > > error: patch failed: Makefile.in:1300 > error: Makefile.in: patch does not apply > error: common.opt: No such file or directory > error: langhooks.c: No such file or directory > error: lto/Make-lang.in: No such file or directory > error: lto/lto-object.c: No such file or directory > error: lto/lto.c: No such file or directory > error: lto/lto.h: No such file or directory > error: lto-streamer.h: No such file or directory > error: toplev.c: No such file or directory > ``` I can try to update the patch, or it probably should apply to trunk checked out around the date I sent the patch. Indeed we need to change c to cc but there are likely more changes since then - most importnatly the early debug info. At I will see how easy/hard is to make the patch build with current trunk. Honza > > Thanks > - Ankur >
Re: [GSoC]Bypass assembler when generating LTO object files
On Tue, Apr 12, 2022 at 11:20 AM Jan Hubicka via Gcc wrote: > > Hi, > > > > > > > On 08-Apr-2022, at 6:32 PM, Jan Hubicka wrote: > > > > > > Ankur, > > >> I was browsing the list of submitted GSoC projects this year and the > > >> project regarding bypassing assembler when generating LTO object files > > >> caught my eye. > > > I apologize for late reply. I would be very happy to mentor this > > > project. > > > > Thanks for the reply, but unfortunately, due to some reasons, I would not > > be able to take part in GSoC this year. > > But the project seems interesting and would be amazing opportunity to > > learn a lot more things for me, so would it be okay if I try to give it a > > go outside GSoC if no-one else picks it as their GSoC project this year ? > > I would be still very happy to help with that! However it would be also > pity to not take part of GSoC, so if there is something I can help with > on that let me know. > > > > >> > > >> I already have a gcc built from source (sync-ed with trunk/master) and > > >> launched the test-suite on it. > > >> > > >> I am currently in process of understanding the primilary patch > > >> (https://gcc.gnu.org/legacy-ml/gcc/2014-09/msg00340.html), and > > >> experimenting with it. > > >> > > >> are there any other things I should be aware of (useful Doc/blog or a > > >> bug tracking the project) before proceeding further ? > > > > > > I think it is pretty much all that exists. Basically we will need to > > > implement everything that is necessary to stream out valid object file > > > directly from GCC rather than going through gas. The experimental > > > prototype sort of worked but it was lacking few things. > > > > When I try to apply that patch on my local branch ( branched from trunk ), > > it seem to be incompatible with the current working tree. Is there a > > specific branch that I have to apply it to ? or is it due to the recent > > file rename patch ( changing extensions from .c to .cc ) ? > > > > ``` > > $ git apply --check bypass_asm_patch > > > > error: patch failed: Makefile.in:1300 > > error: Makefile.in: patch does not apply > > error: common.opt: No such file or directory > > error: langhooks.c: No such file or directory > > error: lto/Make-lang.in: No such file or directory > > error: lto/lto-object.c: No such file or directory > > error: lto/lto.c: No such file or directory > > error: lto/lto.h: No such file or directory > > error: lto-streamer.h: No such file or directory > > error: toplev.c: No such file or directory > > ``` > > I can try to update the patch, or it probably should apply to trunk > checked out around the date I sent the patch. Indeed we need to change > c to cc but there are likely more changes since then - most importnatly > the early debug info. > At I will see how easy/hard is to make the patch build with current > trunk. We do have ideas for the early debug with the asm-out abstraction to also solve a different issue (missing simple-object support for mingw/darwin). Namely assemble the early debug in a different file and include the resulting native object in binary form in the compile output - not needing to write assembly .data for that would be a good way to make this more viable. You might want to talk to Martin Liska for this who I think had some prototype on this? Richard. > Honza > > > > Thanks > > - Ankur > >
Re: [GSoC]Bypass assembler when generating LTO object files
On 4/12/22 11:58, Richard Biener wrote: On Tue, Apr 12, 2022 at 11:20 AM Jan Hubicka via Gcc wrote: Hi, On 08-Apr-2022, at 6:32 PM, Jan Hubicka wrote: Ankur, I was browsing the list of submitted GSoC projects this year and the project regarding bypassing assembler when generating LTO object files caught my eye. I apologize for late reply. I would be very happy to mentor this project. Thanks for the reply, but unfortunately, due to some reasons, I would not be able to take part in GSoC this year. But the project seems interesting and would be amazing opportunity to learn a lot more things for me, so would it be okay if I try to give it a go outside GSoC if no-one else picks it as their GSoC project this year ? I would be still very happy to help with that! However it would be also pity to not take part of GSoC, so if there is something I can help with on that let me know. I already have a gcc built from source (sync-ed with trunk/master) and launched the test-suite on it. I am currently in process of understanding the primilary patch (https://gcc.gnu.org/legacy-ml/gcc/2014-09/msg00340.html), and experimenting with it. are there any other things I should be aware of (useful Doc/blog or a bug tracking the project) before proceeding further ? I think it is pretty much all that exists. Basically we will need to implement everything that is necessary to stream out valid object file directly from GCC rather than going through gas. The experimental prototype sort of worked but it was lacking few things. When I try to apply that patch on my local branch ( branched from trunk ), it seem to be incompatible with the current working tree. Is there a specific branch that I have to apply it to ? or is it due to the recent file rename patch ( changing extensions from .c to .cc ) ? ``` $ git apply --check bypass_asm_patch error: patch failed: Makefile.in:1300 error: Makefile.in: patch does not apply error: common.opt: No such file or directory error: langhooks.c: No such file or directory error: lto/Make-lang.in: No such file or directory error: lto/lto-object.c: No such file or directory error: lto/lto.c: No such file or directory error: lto/lto.h: No such file or directory error: lto-streamer.h: No such file or directory error: toplev.c: No such file or directory ``` I can try to update the patch, or it probably should apply to trunk checked out around the date I sent the patch. Indeed we need to change c to cc but there are likely more changes since then - most importnatly the early debug info. At I will see how easy/hard is to make the patch build with current trunk. We do have ideas for the early debug with the asm-out abstraction to also solve a different issue (missing simple-object support for mingw/darwin). Note the debug info will be stored to a different .s file, then the file will be converted .o by GAS and then the bytecode will be stored to an ELF section of a compiled object. I've got also binutils patch when we'll be able to directly use the embedded section with compile.o@offset. Namely assemble the early debug in a different file and include the resulting native object in binary form in the compile output - not needing to write assembly .data for that would be a good way to make this more viable. Btw. do you have any estimation how slow is GAS when we speak about debug info? How much time can we save since the latest speed-up achieved by GAS? You might want to talk to Martin Liska for this who I think had some prototype on this? I can provide a prototype if needed. Cheers, Martin Richard. Honza Thanks - Ankur
Re: [GSoC]Bypass assembler when generating LTO object files
> On 12 Apr 2022, at 13:31, Martin Liška wrote: > > On 4/12/22 11:58, Richard Biener wrote: >> On Tue, Apr 12, 2022 at 11:20 AM Jan Hubicka via Gcc wrote: >>> >>> Hi, > On 08-Apr-2022, at 6:32 PM, Jan Hubicka wrote: > > Ankur, >> I was browsing the list of submitted GSoC projects this year and the >> project regarding bypassing assembler when generating LTO object files >> caught my eye. > I apologize for late reply. I would be very happy to mentor this > project. Thanks for the reply, but unfortunately, due to some reasons, I would not be able to take part in GSoC this year. But the project seems interesting and would be amazing opportunity to learn a lot more things for me, so would it be okay if I try to give it a go outside GSoC if no-one else picks it as their GSoC project this year ? >>> >>> I would be still very happy to help with that! However it would be also >>> pity to not take part of GSoC, so if there is something I can help with >>> on that let me know. >> >> I already have a gcc built from source (sync-ed with trunk/master) and >> launched the test-suite on it. >> >> I am currently in process of understanding the primilary patch >> (https://gcc.gnu.org/legacy-ml/gcc/2014-09/msg00340.html), and >> experimenting with it. >> >> are there any other things I should be aware of (useful Doc/blog or a >> bug tracking the project) before proceeding further ? > > I think it is pretty much all that exists. Basically we will need to > implement everything that is necessary to stream out valid object file > directly from GCC rather than going through gas. The experimental > prototype sort of worked but it was lacking few things. When I try to apply that patch on my local branch ( branched from trunk ), it seem to be incompatible with the current working tree. Is there a specific branch that I have to apply it to ? or is it due to the recent file rename patch ( changing extensions from .c to .cc ) ? ``` $ git apply --check bypass_asm_patch error: patch failed: Makefile.in:1300 error: Makefile.in: patch does not apply error: common.opt: No such file or directory error: langhooks.c: No such file or directory error: lto/Make-lang.in: No such file or directory error: lto/lto-object.c: No such file or directory error: lto/lto.c: No such file or directory error: lto/lto.h: No such file or directory error: lto-streamer.h: No such file or directory error: toplev.c: No such file or directory ``` >>> >>> I can try to update the patch, or it probably should apply to trunk >>> checked out around the date I sent the patch. Indeed we need to change >>> c to cc but there are likely more changes since then - most importnatly >>> the early debug info. >>> At I will see how easy/hard is to make the patch build with current >>> trunk. >> We do have ideas for the early debug with the asm-out abstraction to >> also solve a different issue (missing simple-object support for >> mingw/darwin). > > Note the debug info will be stored to a different .s file, then the file > will be converted .o by GAS and then the bytecode will be stored to an ELF > section of a compiled object. I've got also binutils patch when we'll > be able to directly use the embedded section with compile.o@offset. Which will not work, as written, for Darwin since that is neither ELF nor does it use GAS - but hopefully, we can find some equivalent mechanism (there is already some support in the Darwin backend for switching asm context for LTO output). >> Namely assemble the early debug in a different file and include the resulting >> native object in binary form in the compile output - not needing to write >> assembly .data for that would be a good way to make this more viable. > > Btw. do you have any estimation how slow is GAS when we speak about debug > info? > How much time can we save since the latest speed-up achieved by GAS? > >> You might want to talk to Martin Liska for this who I think had some >> prototype on this? > > I can provide a prototype if needed. I’d like to be in to loop from the Darwin PoV.. thanks Iain > > Cheers, > Martin > >> Richard. >>> Honza Thanks - Ankur
Re: [GSoC]Bypass assembler when generating LTO object files
On Tue, Apr 12, 2022 at 2:53 PM Iain Sandoe wrote: > > > > > On 12 Apr 2022, at 13:31, Martin Liška wrote: > > > > On 4/12/22 11:58, Richard Biener wrote: > >> On Tue, Apr 12, 2022 at 11:20 AM Jan Hubicka via Gcc > >> wrote: > >>> > >>> Hi, > > > > On 08-Apr-2022, at 6:32 PM, Jan Hubicka wrote: > > > > Ankur, > >> I was browsing the list of submitted GSoC projects this year and the > >> project regarding bypassing assembler when generating LTO object files > >> caught my eye. > > I apologize for late reply. I would be very happy to mentor this > > project. > > Thanks for the reply, but unfortunately, due to some reasons, I would not > be able to take part in GSoC this year. > But the project seems interesting and would be amazing opportunity to > learn a lot more things for me, so would it be okay if I try to give it a > go outside GSoC if no-one else picks it as their GSoC project this year ? > >>> > >>> I would be still very happy to help with that! However it would be also > >>> pity to not take part of GSoC, so if there is something I can help with > >>> on that let me know. > > >> > >> I already have a gcc built from source (sync-ed with trunk/master) and > >> launched the test-suite on it. > >> > >> I am currently in process of understanding the primilary patch > >> (https://gcc.gnu.org/legacy-ml/gcc/2014-09/msg00340.html), and > >> experimenting with it. > >> > >> are there any other things I should be aware of (useful Doc/blog or a > >> bug tracking the project) before proceeding further ? > > > > I think it is pretty much all that exists. Basically we will need to > > implement everything that is necessary to stream out valid object file > > directly from GCC rather than going through gas. The experimental > > prototype sort of worked but it was lacking few things. > > When I try to apply that patch on my local branch ( branched from trunk > ), > it seem to be incompatible with the current working tree. Is there a > specific branch that I have to apply it to ? or is it due to the recent > file rename patch ( changing extensions from .c to .cc ) ? > > ``` > $ git apply --check bypass_asm_patch > > error: patch failed: Makefile.in:1300 > error: Makefile.in: patch does not apply > error: common.opt: No such file or directory > error: langhooks.c: No such file or directory > error: lto/Make-lang.in: No such file or directory > error: lto/lto-object.c: No such file or directory > error: lto/lto.c: No such file or directory > error: lto/lto.h: No such file or directory > error: lto-streamer.h: No such file or directory > error: toplev.c: No such file or directory > ``` > >>> > >>> I can try to update the patch, or it probably should apply to trunk > >>> checked out around the date I sent the patch. Indeed we need to change > >>> c to cc but there are likely more changes since then - most importnatly > >>> the early debug info. > >>> At I will see how easy/hard is to make the patch build with current > >>> trunk. > >> We do have ideas for the early debug with the asm-out abstraction to > >> also solve a different issue (missing simple-object support for > >> mingw/darwin). > > > > Note the debug info will be stored to a different .s file, then the file > > will be converted .o by GAS and then the bytecode will be stored to an ELF > > section of a compiled object. I've got also binutils patch when we'll > > be able to directly use the embedded section with compile.o@offset. > > Which will not work, as written, for Darwin since that is neither ELF nor > does it > use GAS - but hopefully, we can find some equivalent mechanism (there is > already > some support in the Darwin backend for switching asm context for LTO output). I think using compile.o@offset will be optional and the fallback is to extract the "file" back to a regular object file just containing debug info like we do currently but with the difference that we do not need to understand the object format since it is created "correctly" by the assembler during compile-time (and we just use the compile-object as a container to not confuse build systems). > >> Namely assemble the early debug in a different file and include the > >> resulting > >> native object in binary form in the compile output - not needing to write > >> assembly .data for that would be a good way to make this more viable. > > > > Btw. do you have any estimation how slow is GAS when we speak about debug > > info? > > How much time can we save since the latest speed-up achieved by GAS? > > > >> You might want to talk to Martin Liska for this who I think had some > >> prototype on this? > > > > I can provide a prototype if needed. > > I’d like to be in to loop from the Darwin PoV.. > thanks > Iain > > > > > Cheers, > > Martin > >
Re: [CVE] zlib (< 1.2.12) memory corruption
Hi Luis, There is a CVE [1] for zlib < 1.2.12 (released march 27th). GCC currently uses zlib 1.2.11, and binutils-gdb imports the zlib directory from GCC. The recommendation is to get it updated to 1.2.12, which contains the proper fix [2]. Right - I have now updated the binutils-gdb mainline sources with this release. Whilst it is true that the gcc version of zlib sources had diverged slightly from the 1.2.11 release sources, I think that it was just some changes cherry picked from the developments that went in to 1.2.12. So a simple rebase should be safe. Cheers Nick
Re: testsuite requires LTO?
On Tue, Apr 12, 2022 at 09:26:58AM +0200, Richard Biener wrote:
> On Tue, Apr 12, 2022 at 9:07 AM Richard Biener
> wrote:
> >
> > On Tue, Apr 12, 2022 at 1:53 AM Steve Kargl via Gcc wrote:
> > >
> > > If I configure gcc with the following
> > >
> > > ../gccx/configure --prefix=$HOME/work/x --enable-languages=c,c++,fortran \
> > > --enable-bootstrap --disable-nls --enable-checking --disable-multilib \
> > > --disable-libsanitizer --disable-lto.
> > >
> > > then bootstrap gcc, why do I see 1000s of failures with
> > >
> > > % cd gcc
> > > % gmake -j7 check-c
> > > ...
> > > FAIL: gcc.dg/torture/pr64365.c -O2 -flto (test for excess errors)
> > > FAIL: gcc.dg/torture/pr61786.c -O2 -flto (test for excess errors)
> > > FAIL: gcc.dg/torture/pr63380-2.c -O2 -flto (test for excess errors)
> > > FAIL: gcc.dg/torture/pr65270-2.c -O2 -flto (test for excess errors)
> > >
> > > Should the testsuite recognize that gcc is built without LTO support?
> >
> > Yes, it does, in testsuite/lib/gcc-dg.exp
> >
> > if [info exists TORTURE_OPTIONS] {
> > set DG_TORTURE_OPTIONS $TORTURE_OPTIONS
> > } else {
> > # It is theoretically beneficial to group all of the O2/O3 options
> > together,
> > # as in many cases the compiler will generate identical executables for
> > # all of them--and the c-torture testsuite will skip testing identical
> > # executables multiple times.
> > # Also note that -finline-functions is explicitly included in one of the
> > # items below, even though -O3 is also specified, because some ports may
> > # choose to disable inlining functions by default, even when optimizing.
> > set DG_TORTURE_OPTIONS [list \
> > { -O0 } \
> > { -O1 } \
> > { -O2 } \
> > { -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops
> > -ftracer -finline-functions } \
> > { -O3 -g } \
> > { -Os } ]
> >
> > if [check_effective_target_lto] {
> > # When having plugin test both slim and fat LTO and plugin/nonplugin
> > # path.
> > if [check_linker_plugin_available] {
> >set LTO_TORTURE_OPTIONS [list \
> > { -O2 -flto -fno-use-linker-plugin -flto-partition=none } \
> > { -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects }
> >]
> > } else {
> >set LTO_TORTURE_OPTIONS [list \
> > { -O2 -flto -flto-partition=none } \
> > { -O2 -flto }
> >]
> > }
> >
> > so either TORTURE_OPTIONS is set or check_effective_target_lto doesn't work.
> > The check does simply
> >
> > return [check_no_compiler_messages lto object {
> > void foo (void) { }
> > } "-flto"]
> >
> > so I wonder what your excess errors are? The check above should also
> > leave traces
> > in the testsuite log. It might be that --disable-lto doesn't disable
> > gcc -c -flto but just
> > disables lto1 building though.
>
> I checked and it works fine for me, --disable-lto disables LTO support
> and there's
> no extra FAILs in dg-torture.exp. The testsuite log has
>
> Executing on host: /tmp/obj/gcc/xgcc -B/tmp/obj/gcc/
> -fdiagnostics-plain-output -flto -c -o lto10207.o lto10207.c
> (timeout = 300)
> spawn -ignore SIGHUP /tmp/obj/gcc/xgcc -B/tmp/obj/gcc/
> -fdiagnostics-plain-output -flto -c -o lto10207.o lto10207.c^M
> cc1: error: LTO support has not been enabled in this configuration^M
> compiler exited with status 1
>
> which causes no -flto to be used.
>
Well, I determined what the problem is. On FreeBSD,
GNU make is gmake. make(1) on FreeBSD is BSD make.
% gmake -j7 check-c
Does not pass down the name of the invoking command
to sub-make jobs. 4000+ FAILs had the form
make[2]: illegal argument to -j -- must be positive integer!
FAIL ...
Well, that's an error message from BSD make. If I do
% setenv MAKE gmake
% gmake -j7 check-c
4000+ FAILS disappear, so it's good that he environmental
variable MAKE is honored. I know in the past I did not
need to sete MAKE.
With LTO disabled and MAKE set, I see
=== gcc Summary ===
# of expected passes175408
# of unexpected failures1078
# of unexpected successes 20
# of expected failures 1459
# of unresolved testcases 10
# of unsupported tests 3248
/usr/home/sgk/gcc/objx/gcc/xgcc version 12.0.1 20220411 (experimental) (GCC)
--
Steve
Re: testsuite requires LTO?
On Tue, 12 Apr 2022 at 18:32, Steve Kargl wrote: > Well, I determined what the problem is. On FreeBSD, > GNU make is gmake. make(1) on FreeBSD is BSD make. > > % gmake -j7 check-c > > Does not pass down the name of the invoking command > to sub-make jobs. That suggests some makefile is using 'make' directly, not using $(MAKE). But if that was the case, then setting MAKE in the environment wouldn't help either. What version of gmake do you have?
Re: testsuite requires LTO?
On Tue, Apr 12, 2022 at 06:42:20PM +0100, Jonathan Wakely wrote: > On Tue, 12 Apr 2022 at 18:32, Steve Kargl wrote: > > Well, I determined what the problem is. On FreeBSD, > > GNU make is gmake. make(1) on FreeBSD is BSD make. > > > > % gmake -j7 check-c > > > > Does not pass down the name of the invoking command > > to sub-make jobs. > > That suggests some makefile is using 'make' directly, not using > $(MAKE). But if that was the case, then setting MAKE in the > environment wouldn't help either. > > What version of gmake do you have? % gmake --version GNU Make 4.3 Built for amd64-portbld-freebsd13.0 It's the version from FreeBSD port collection. I just started a new bootstrap with LTO enabled without any patches in my gcc tree to try to get a baseline. It will take a bit. -- Steve
