| Message ID | dea09c3d-d5e6-9879-bc9e-6eeeb92a91f9@suse.cz |
|---|---|
| State | New |
| Headers | show |
| Series | Deduce automatically number of cores for -flto option. | expand |
On 7/23/19 4:15 AM, Martin Liška wrote: > On 7/23/19 11:20 AM, Jan Hubicka wrote: >> Hi, >> great you found time to make this. It should become the default for >> -flto IMO. > > Works for me. Then I'm suggesting to not come up with -flto=auto and > only document that -flto passed during linking will automatically detect > number of cores. It's the same what clang does. This variant is fine too. Same caveats apply with the non-linux hosts. jeff
Hi. I'm sending v2 of the patch that can newly auto-detect make jobserver and use it. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed? Thanks, Martin
On 7/29/19 3:35 PM, Martin Liška wrote: > Hi. > > I'm sending v2 of the patch that can newly auto-detect make > jobserver and use it. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? > Thanks, > Martin > Ok, I've discussed the latest version also with Honza and he's fine. So I'm going to install the patch. Thanks, Martin
On Mon, Jul 29, 2019 at 03:35:08PM +0200, Martin Liška wrote: > I'm sending v2 of the patch that can newly auto-detect make > jobserver and use it. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? > Thanks, > Martin > >From df747a46241dcdb8ad055071f9e0605c9f469268 Mon Sep 17 00:00:00 2001 > From: Martin Liska <mliska@suse.cz> > Date: Tue, 23 Jul 2019 10:14:31 +0200 > Subject: [PATCH 1/2] Deduce automatically number of cores for -flto option. > > gcc/ChangeLog: > > 2019-07-23 Martin Liska <mliska@suse.cz> > > * doc/invoke.texi: Document new behavior. > * lto-wrapper.c (cpuset_popcount): New function > is a copy of libgomp/config/linux/proc.c. > (init_num_threads): Likewise. > (run_gcc): Automatically detect core count for -flto. > (jobserver_active_p): New function. This broke a lot of tests. The logs show spawn -ignore SIGHUP /home/jakub/src/gcc/obj31/gcc/xgcc -B/home/jakub/src/gcc/obj31/gcc/ c_lto_pr83954_0.o c_lto_pr83954_1.o -fno-diagnostics-show- caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2 -flto -flto-partition=1to1 -o gcc-dg-lto-pr83954-31.exe make[4]: *** write jobserver: Bad file descriptor. Stop. make[4]: *** Waiting for unfinished jobs.... make[4]: *** write jobserver: Bad file descriptor. Stop. lto-wrapper: fatal error: make returned 2 exit status compilation terminated. collect2: fatal error: lto-wrapper returned 1 exit status compilation terminated. compiler exited with status 1 FAIL: gcc.dg/lto/pr83954 c_lto_pr83954_0.o-c_lto_pr83954_1.o link, -O2 -flto -flto-partition=1to1 and similar, e.g. for x86_64-linux it was following regressions, on i686-linux also some tests in libgomp etc. Is -flto now really using all available CPUs for each compilation? Without jobserver that would like a fork-bomb, say if I have a CPU with 32 threads and do make check -j32, does that mean there are 1024 lto1s? Judging from http://gcc.gnu.org/ml/gcc-testresults/2019-07/msg03610.html I'm not alone. +FAIL: gcc.dg/lto/20081111 c_lto_20081111_0.o-c_lto_20081111_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20081111 c_lto_20081111_0.o-c_lto_20081111_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20081112 c_lto_20081112_0.o-c_lto_20081112_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20081112 c_lto_20081112_0.o-c_lto_20081112_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20081125 c_lto_20081125_0.o-c_lto_20081125_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20081125 c_lto_20081125_0.o-c_lto_20081125_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20081222 c_lto_20081222_0.o-c_lto_20081222_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20081222 c_lto_20081222_0.o-c_lto_20081222_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20090213 c_lto_20090213_0.o-c_lto_20090213_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20090213 c_lto_20090213_0.o-c_lto_20090213_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20090218 c_lto_20090218_0.o-c_lto_20090218_3.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20090218 c_lto_20090218_0.o-c_lto_20090218_3.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20090218-1 c_lto_20090218-1_0.o-c_lto_20090218-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20090218-1 c_lto_20090218-1_0.o-c_lto_20090218-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20090218-2 c_lto_20090218-2_0.o-c_lto_20090218-2_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20090218-2 c_lto_20090218-2_0.o-c_lto_20090218-2_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20090312 c_lto_20090312_0.o-c_lto_20090312_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20090312 c_lto_20090312_0.o-c_lto_20090312_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20090717 c_lto_20090717_0.o-c_lto_20090717_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20090717 c_lto_20090717_0.o-c_lto_20090717_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20090812 c_lto_20090812_0.o-c_lto_20090812_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20090812 c_lto_20090812_0.o-c_lto_20090812_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20091005-1 c_lto_20091005-1_0.o-c_lto_20091005-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20091005-1 c_lto_20091005-1_0.o-c_lto_20091005-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20091006-1 c_lto_20091006-1_0.o-c_lto_20091006-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20091006-1 c_lto_20091006-1_0.o-c_lto_20091006-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20091006-2 c_lto_20091006-2_0.o-c_lto_20091006-2_2.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20091006-2 c_lto_20091006-2_0.o-c_lto_20091006-2_2.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20091017-1 c_lto_20091017-1_0.o-c_lto_20091017-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20091017-1 c_lto_20091017-1_0.o-c_lto_20091017-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20091027-1 c_lto_20091027-1_0.o-c_lto_20091027-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20091027-1 c_lto_20091027-1_0.o-c_lto_20091027-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20100227-1 c_lto_20100227-1_0.o-c_lto_20100227-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20100227-1 c_lto_20100227-1_0.o-c_lto_20100227-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20100423-1 c_lto_20100423-1_0.o-c_lto_20100423-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20100423-1 c_lto_20100423-1_0.o-c_lto_20100423-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20100709-1 c_lto_20100709-1_0.o-c_lto_20100709-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20100709-1 c_lto_20100709-1_0.o-c_lto_20100709-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20100720-1 c_lto_20100720-1_0.o-c_lto_20100720-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20100720-1 c_lto_20100720-1_0.o-c_lto_20100720-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20100720-2 c_lto_20100720-2_0.o-c_lto_20100720-2_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20100720-2 c_lto_20100720-2_0.o-c_lto_20100720-2_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20100720-3 c_lto_20100720-3_0.o-c_lto_20100720-3_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20100720-3 c_lto_20100720-3_0.o-c_lto_20100720-3_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20100724-1 c_lto_20100724-1_0.o-c_lto_20100724-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20100724-1 c_lto_20100724-1_0.o-c_lto_20100724-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20101009-2 c_lto_20101009-2_0.o-c_lto_20101009-2_2.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20101009-2 c_lto_20101009-2_0.o-c_lto_20101009-2_2.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20101125-1 c_lto_20101125-1_0.o-c_lto_20101125-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/20101125-1 c_lto_20101125-1_0.o-c_lto_20101125-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/attr-weakref-1 c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/attr-weakref-1 c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/pr34989-1 c_lto_pr34989-1_0.o-c_lto_pr34989-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/pr34989-1 c_lto_pr34989-1_0.o-c_lto_pr34989-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/pr55660 c_lto_pr55660_0.o-c_lto_pr55660_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/pr55660 c_lto_pr55660_0.o-c_lto_pr55660_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/pr59626 c_lto_pr59626_0.o-c_lto_pr59626_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/pr59626 c_lto_pr59626_0.o-c_lto_pr59626_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/pr60449 c_lto_pr60449_0.o-c_lto_pr60449_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/pr60449 c_lto_pr60449_0.o-c_lto_pr60449_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/pr60720 c_lto_pr60720_0.o-c_lto_pr60720_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/pr60720 c_lto_pr60720_0.o-c_lto_pr60720_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/pr70955 c_lto_pr70955_0.o-c_lto_pr70955_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/pr70955 c_lto_pr70955_0.o-c_lto_pr70955_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/pr81440 c_lto_pr81440_0.o-c_lto_pr81440_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/pr81440 c_lto_pr81440_0.o-c_lto_pr81440_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/pr83954 c_lto_pr83954_0.o-c_lto_pr83954_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/pr83954 c_lto_pr83954_0.o-c_lto_pr83954_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/pr88077 c_lto_pr88077_0.o-c_lto_pr88077_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gcc.dg/lto/pr88077 c_lto_pr88077_0.o-c_lto_pr88077_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gfortran.dg/lto/20091015-1 f_lto_20091015-1_0.o-f_lto_20091015-1_2.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gfortran.dg/lto/20091015-1 f_lto_20091015-1_0.o-f_lto_20091015-1_2.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gfortran.dg/lto/20091028-1 f_lto_20091028-1_0.o-f_lto_20091028-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gfortran.dg/lto/20091028-1 f_lto_20091028-1_0.o-f_lto_20091028-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gfortran.dg/lto/20091028-2 f_lto_20091028-2_0.o-f_lto_20091028-2_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gfortran.dg/lto/20091028-2 f_lto_20091028-2_0.o-f_lto_20091028-2_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gfortran.dg/lto/20100222-1 f_lto_20100222-1_0.o-f_lto_20100222-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gfortran.dg/lto/20100222-1 f_lto_20100222-1_0.o-f_lto_20100222-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gfortran.dg/lto/pr40724 f_lto_pr40724_0.o-f_lto_pr40724_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gfortran.dg/lto/pr40724 f_lto_pr40724_0.o-f_lto_pr40724_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gfortran.dg/lto/pr40725 f_lto_pr40725_0.o-f_lto_pr40725_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gfortran.dg/lto/pr40725 f_lto_pr40725_0.o-f_lto_pr40725_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gfortran.dg/lto/pr41069 f_lto_pr41069_0.o-f_lto_pr41069_2.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gfortran.dg/lto/pr41069 f_lto_pr41069_0.o-f_lto_pr41069_2.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gfortran.dg/lto/pr87689 f_lto_pr87689_0.o-f_lto_pr87689_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: gfortran.dg/lto/pr87689 f_lto_pr87689_0.o-f_lto_pr87689_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20081022 cp_lto_20081022_0.o-cp_lto_20081022_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20081022 cp_lto_20081022_0.o-cp_lto_20081022_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20081119 cp_lto_20081119_0.o-cp_lto_20081119_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20081119 cp_lto_20081119_0.o-cp_lto_20081119_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20081127 cp_lto_20081127_0.o-cp_lto_20081127_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20081203 cp_lto_20081203_0.o-cp_lto_20081203_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20081203 cp_lto_20081203_0.o-cp_lto_20081203_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20081209 cp_lto_20081209_0.o-cp_lto_20081209_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20081209 cp_lto_20081209_0.o-cp_lto_20081209_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20081211-1 cp_lto_20081211-1_0.o-cp_lto_20081211-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20081211-1 cp_lto_20081211-1_0.o-cp_lto_20081211-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20090311-1 cp_lto_20090311-1_0.o-cp_lto_20090311-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20090311-1 cp_lto_20090311-1_0.o-cp_lto_20090311-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20090312 cp_lto_20090312_0.o-cp_lto_20090312_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20090312 cp_lto_20090312_0.o-cp_lto_20090312_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20090315 cp_lto_20090315_0.o-cp_lto_20090315_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20090315 cp_lto_20090315_0.o-cp_lto_20090315_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20091026-1 cp_lto_20091026-1_0.o-cp_lto_20091026-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20091026-1 cp_lto_20091026-1_0.o-cp_lto_20091026-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20091210-1 cp_lto_20091210-1_0.o-cp_lto_20091210-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20091210-1 cp_lto_20091210-1_0.o-cp_lto_20091210-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20100603-1 cp_lto_20100603-1_0.o-cp_lto_20100603-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20100603-1 cp_lto_20100603-1_0.o-cp_lto_20100603-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20101020-1 cp_lto_20101020-1_0.o-cp_lto_20101020-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20101020-1 cp_lto_20101020-1_0.o-cp_lto_20101020-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20101126-1 cp_lto_20101126-1_0.o-cp_lto_20101126-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/20101126-1 cp_lto_20101126-1_0.o-cp_lto_20101126-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/odr-1 cp_lto_odr-1_0.o-cp_lto_odr-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/odr-1 cp_lto_odr-1_0.o-cp_lto_odr-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/odr-2 cp_lto_odr-2_0.o-cp_lto_odr-2_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/odr-2 cp_lto_odr-2_0.o-cp_lto_odr-2_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/odr-3 cp_lto_odr-3_0.o-cp_lto_odr-3_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/odr-3 cp_lto_odr-3_0.o-cp_lto_odr-3_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/odr-5 cp_lto_odr-5_0.o-cp_lto_odr-5_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/odr-5 cp_lto_odr-5_0.o-cp_lto_odr-5_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/pr78472 cp_lto_pr78472_0.o-cp_lto_pr78472_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/pr78472 cp_lto_pr78472_0.o-cp_lto_pr78472_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/pr79671 cp_lto_pr79671_0.o-cp_lto_pr79671_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/pr79671 cp_lto_pr79671_0.o-cp_lto_pr79671_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/pr87089 cp_lto_pr87089_0.o-cp_lto_pr87089_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin +FAIL: g++.dg/lto/pr87089 cp_lto_pr87089_0.o-cp_lto_pr87089_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin Jakub
On 7/31/19 1:32 AM, Jakub Jelinek wrote: > This broke a lot of tests. Whoops. > The logs show > spawn -ignore SIGHUP /home/jakub/src/gcc/obj31/gcc/xgcc -B/home/jakub/src/gcc/obj31/gcc/ c_lto_pr83954_0.o c_lto_pr83954_1.o -fno-diagnostics-show- > caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2 -flto -flto-partition=1to1 -o gcc-dg-lto-pr83954-31.exe > make[4]: *** write jobserver: Bad file descriptor. Stop. > make[4]: *** Waiting for unfinished jobs.... > make[4]: *** write jobserver: Bad file descriptor. Stop. > lto-wrapper: fatal error: make returned 2 exit status > compilation terminated. > collect2: fatal error: lto-wrapper returned 1 exit status > compilation terminated. > compiler exited with status 1 > FAIL: gcc.dg/lto/pr83954 c_lto_pr83954_0.o-c_lto_pr83954_1.o link, -O2 -flto -flto-partition=1to1 > and similar, e.g. for x86_64-linux it was following regressions, on > i686-linux also some tests in libgomp etc. > Is -flto now really using all available CPUs for each compilation? Yes, I can confirm that linking happens in N processed for each LTO test now. It's caused by fact that current Dejagnu machinery does not pass a make jobserver to gcc command invocations. On the other hand, our LTO tests are so tiny that we should have always very low number of partitions. > Without > jobserver that would like a fork-bomb, say if I have a CPU with 32 threads > and do make check -j32, does that mean there are 1024 lto1s? > Judging from http://gcc.gnu.org/ml/gcc-testresults/2019-07/msg03610.html > I'm not alone. One possible solution will be to adjust lto.exp: set LTO_OPTIONS [list \ {-O0 -flto -flto-partition=none -fuse-linker-plugin} \ {-O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects } \ {-O0 -flto -flto-partition=1to1 -fno-use-linker-plugin } \ {-O2 -flto -flto-partition=1to1 -fno-use-linker-plugin } \ and replace all -flto with -flto=1. But still, many individual tests set -flto by themselves. Another solution would be to disable the auto-detection with an environment variable: diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c index 353187c6043..bb6fb2b53ff 100644 --- a/gcc/lto-wrapper.c +++ b/gcc/lto-wrapper.c @@ -1423,7 +1423,7 @@ run_gcc (unsigned argc, char *argv[]) auto_parallel = 0; parallel = 0; } - else if (!jobserver && parallel) + else if (!jobserver && parallel && !getenv ("LTO_NO_AUTO_PARALLEL")) { /* If there's no explicit usage of jobserver and parallel is enabled, then automatically detect diff --git a/gcc/testsuite/lib/lto.exp b/gcc/testsuite/lib/lto.exp index 25c934731df..e303894e0b0 100644 --- a/gcc/testsuite/lib/lto.exp +++ b/gcc/testsuite/lib/lto.exp @@ -209,6 +209,8 @@ proc lto_init { args } { ] } } + + setenv LTO_NO_AUTO_PARALLEL 1 } # Can you Jakub test the patch or the s/-flto/-flto=1 solutions please? Thanks, Martin
On Wed, Jul 31, 2019 at 09:20:40AM +0200, Martin Liška wrote: > One possible solution will be to adjust lto.exp: > > set LTO_OPTIONS [list \ > {-O0 -flto -flto-partition=none -fuse-linker-plugin} \ > {-O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects } \ > {-O0 -flto -flto-partition=1to1 -fno-use-linker-plugin } \ > {-O2 -flto -flto-partition=1to1 -fno-use-linker-plugin } \ > > and replace all -flto with -flto=1. But still, many individual tests set -flto by themselves. > Another solution would be to disable the auto-detection with an environment variable: > > diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c > index 353187c6043..bb6fb2b53ff 100644 > --- a/gcc/lto-wrapper.c > +++ b/gcc/lto-wrapper.c > @@ -1423,7 +1423,7 @@ run_gcc (unsigned argc, char *argv[]) > auto_parallel = 0; > parallel = 0; > } > - else if (!jobserver && parallel) > + else if (!jobserver && parallel && !getenv ("LTO_NO_AUTO_PARALLEL")) > { > /* If there's no explicit usage of jobserver and > parallel is enabled, then automatically detect > diff --git a/gcc/testsuite/lib/lto.exp b/gcc/testsuite/lib/lto.exp > index 25c934731df..e303894e0b0 100644 > --- a/gcc/testsuite/lib/lto.exp > +++ b/gcc/testsuite/lib/lto.exp > @@ -209,6 +209,8 @@ proc lto_init { args } { > ] > } > } > + > + setenv LTO_NO_AUTO_PARALLEL 1 > } > > # > > Can you Jakub test the patch or the s/-flto/-flto=1 solutions please? Neither will work very well, we have thousands of -flto tests outside of lto.exp, e.g. dg-torture.exp (or libgomp and others) cycle through various options including -flto etc. Some env var would be useful I guess, though shouldn't it have GCC in the name? I mean, if we run into these fork-bomb problems in gcc, won't other projects run into those as well? Why doesn't the jobserver work in the tests? Is that because of missing + somewhere in the Makefiles or is something unsetting MFLAGS or MAKEFLAGS env vars? Though, as I said on IRC, I think we might run out of filedescriptors when using jobserver too, say if on 64 thread machine one does make -j64 -k check and each test simultaneously tries to create 64 partitions, that would be 4096 connections to the jobserver, right? Jakub
> Neither will work very well, we have thousands of -flto tests outside of > lto.exp, e.g. dg-torture.exp (or libgomp and others) cycle through various > options including -flto etc. > > Some env var would be useful I guess, though shouldn't it have GCC in the > name? I mean, if we run into these fork-bomb problems in gcc, won't other > projects run into those as well? > > Why doesn't the jobserver work in the tests? Is that because of missing + > somewhere in the Makefiles or is something unsetting MFLAGS or MAKEFLAGS > env vars? Main trouble with make's jobserver is that it works by 1) defining environment variable saying which file descriptior to connect to 2) keeping the file descriptor open upon invoking "+" prefixed lines Adding "+" to GCC invocation is wrong since it breaks dry run (we do not want to link at that time) but it is only way to access the jobserver. If "+" is not present, make will keep the environment vairable but will close file descriptors prior exec. Make developers said that this is because some old prorams misbehave when you exec them with more than 3 file descriptors open. I tried to negotiate for named pipe which would solve this and it would make it easy to connect to outermost jobserver from anything invoked form toplevel make, but they was worried about systems w/o named pipes. I wonder why we do not detect jobserv as unavailable in this case and do not default to -flto=<numthreads>? Is it because dejagnu machinery actually opens some other file descriptor that gets same ID and executes us with it? Or does LTO wrapper open something prior accessing jobserver? > > Though, as I said on IRC, I think we might run out of filedescriptors when > using jobserver too, say if on 64 thread machine one does make -j64 -k check > and each test simultaneously tries to create 64 partitions, that would be > 4096 connections to the jobserver, right? Only WPA process connects to jobserver (which is 1 per linker invokation), so I think this should be safe. Honza > > Jakub
On 7/31/19 9:40 AM, Jan Hubicka wrote: >> Neither will work very well, we have thousands of -flto tests outside of >> lto.exp, e.g. dg-torture.exp (or libgomp and others) cycle through various >> options including -flto etc. >> >> Some env var would be useful I guess, though shouldn't it have GCC in the >> name? I mean, if we run into these fork-bomb problems in gcc, won't other >> projects run into those as well? >> >> Why doesn't the jobserver work in the tests? Is that because of missing + >> somewhere in the Makefiles or is something unsetting MFLAGS or MAKEFLAGS >> env vars? > > Main trouble with make's jobserver is that it works by > 1) defining environment variable saying which file descriptior to > connect to > 2) keeping the file descriptor open upon invoking "+" prefixed lines > > Adding "+" to GCC invocation is wrong since it breaks dry run (we do not > want to link at that time) but it is only way to access the jobserver. > If "+" is not present, make will keep the environment vairable but will > close file descriptors prior exec. > > Make developers said that this is because some old prorams misbehave > when you exec them with more than 3 file descriptors open. I tried to > negotiate for named pipe which would solve this and it would make it > easy to connect to outermost jobserver from anything invoked form > toplevel make, but they was worried about systems w/o named pipes. Yes a more generic approach would be welcome as other build systems would also be able to utilize it. > > I wonder why we do not detect jobserv as unavailable in this case and do > not default to -flto=<numthreads>? We do not detect jobserver because of Dejagnu is not using it. And yes, we default to -flto=<numthreads> in LTO tests now. That's what is causing issues right now. > Is it because dejagnu machinery actually opens some other file > descriptor that gets same ID and executes us with it? > > Or does LTO wrapper open something prior accessing jobserver? > >> >> Though, as I said on IRC, I think we might run out of filedescriptors when >> using jobserver too, say if on 64 thread machine one does make -j64 -k check >> and each test simultaneously tries to create 64 partitions, that would be >> 4096 connections to the jobserver, right? > > Only WPA process connects to jobserver (which is 1 per linker > invokation), so I think this should be safe. Yes and it's only about a quick fcntl. But as mentioned, Dejagnu is not passing us jobserver, so we don't do it right now. Martin > > Honza >> >> Jakub
On 7/31/19 9:34 AM, Jakub Jelinek wrote: > On Wed, Jul 31, 2019 at 09:20:40AM +0200, Martin Liška wrote: >> One possible solution will be to adjust lto.exp: >> >> set LTO_OPTIONS [list \ >> {-O0 -flto -flto-partition=none -fuse-linker-plugin} \ >> {-O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects } \ >> {-O0 -flto -flto-partition=1to1 -fno-use-linker-plugin } \ >> {-O2 -flto -flto-partition=1to1 -fno-use-linker-plugin } \ >> >> and replace all -flto with -flto=1. But still, many individual tests set -flto by themselves. >> Another solution would be to disable the auto-detection with an environment variable: >> >> diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c >> index 353187c6043..bb6fb2b53ff 100644 >> --- a/gcc/lto-wrapper.c >> +++ b/gcc/lto-wrapper.c >> @@ -1423,7 +1423,7 @@ run_gcc (unsigned argc, char *argv[]) >> auto_parallel = 0; >> parallel = 0; >> } >> - else if (!jobserver && parallel) >> + else if (!jobserver && parallel && !getenv ("LTO_NO_AUTO_PARALLEL")) >> { >> /* If there's no explicit usage of jobserver and >> parallel is enabled, then automatically detect >> diff --git a/gcc/testsuite/lib/lto.exp b/gcc/testsuite/lib/lto.exp >> index 25c934731df..e303894e0b0 100644 >> --- a/gcc/testsuite/lib/lto.exp >> +++ b/gcc/testsuite/lib/lto.exp >> @@ -209,6 +209,8 @@ proc lto_init { args } { >> ] >> } >> } >> + >> + setenv LTO_NO_AUTO_PARALLEL 1 >> } >> >> # >> >> Can you Jakub test the patch or the s/-flto/-flto=1 solutions please? > > Neither will work very well, we have thousands of -flto tests outside of > lto.exp, e.g. dg-torture.exp (or libgomp and others) cycle through various > options including -flto etc. > > Some env var would be useful I guess, though shouldn't it have GCC in the > name? Works for me. > I mean, if we run into these fork-bomb problems in gcc, won't other > projects run into those as well? Right now, we build whole openSUSE distribution with -flto=N (N based on # of threads) and we haven't seen issues related to fork-bomb. > > Why doesn't the jobserver work in the tests? Is that because of missing + > somewhere in the Makefiles or is something unsetting MFLAGS or MAKEFLAGS > env vars? Is Dejagnu using make internally to invoke individual tests? > > Though, as I said on IRC, I think we might run out of filedescriptors when > using jobserver too, say if on 64 thread machine one does make -j64 -k check > and each test simultaneously tries to create 64 partitions, that would be > 4096 connections to the jobserver, right? > > Jakub >
On Wed, Jul 31, 2019 at 09:50:47AM +0200, Martin Liška wrote: > > Why doesn't the jobserver work in the tests? Is that because of missing + > > somewhere in the Makefiles or is something unsetting MFLAGS or MAKEFLAGS > > env vars? > > Is Dejagnu using make internally to invoke individual tests? No. But as I said, the same check-gcc causes many make goals running simultaneously, as you can see in the testsuite/gcc{,1,2,3,...} directories, where each runtest invoked by those goals uses gcc_parallel_test_run_p and O_EXCL files to decide which of the runtests will perform each test. Jakub
Hi, > We do not detect jobserver because of Dejagnu is not using it. > And yes, we default to -flto=<numthreads> in LTO tests now. That's > what is causing issues right now. Why the error messages are make[4]: *** write jobserver: Bad file descriptor. Stop. make[4]: *** Waiting for unfinished jobs.... make[4]: *** write jobserver: Bad file descriptor. Stop. It seems to me that it is internal make from lto-wrapper trying to get jobserver access? > Works for me. We probably also can give it a meaning controlling the default parameter of -flto. I.e. setenv GCC_LTO_PARALLELISM <numthreads/auto/jobserv> which we will default to in case only -flto is passed to command line. Make's jobserver is quite nice and easy to use. If it supported named pipe and there was a small library which allowed to initialize jobserver and connect to it, perhaps other tools needing parallelism during build (GCC, ninja, llvm, ...) would be able to use common protocol. Honza
On 7/31/19 10:08 AM, Jan Hubicka wrote: > Hi, > >> We do not detect jobserver because of Dejagnu is not using it. >> And yes, we default to -flto=<numthreads> in LTO tests now. That's >> what is causing issues right now. > > Why the error messages are > make[4]: *** write jobserver: Bad file descriptor. Stop. > make[4]: *** Waiting for unfinished jobs.... > make[4]: *** write jobserver: Bad file descriptor. Stop. > It seems to me that it is internal make from lto-wrapper trying to get > jobserver access? Hard to guess. Can you Jakub debug that? I don't see the error message. > >> Works for me. > > We probably also can give it a meaning controlling the default parameter > of -flto. > I.e. setenv GCC_LTO_PARALLELISM <numthreads/auto/jobserv> > which we will default to in case only -flto is passed to command line. Interesting idea, I like it, but: - if we detect that jobserver will not work, GCC_LTO_PARALLELISM=jobserver is useless - auto equals now to 'unset GCC_LTO_PARALLELISM' So the only interesting value is numthreads. Then I would recommend to use GCC_LTO_MAX_AUTO_THREADS? > > Make's jobserver is quite nice and easy to use. If it supported named > pipe and there was a small library which allowed to initialize jobserver > and connect to it, perhaps other tools needing parallelism during build > (GCC, ninja, llvm, ...) would be able to use common protocol. Can be a nice GSoC project for next year? Martin > > Honza >
On Wed, Jul 31, 2019 at 10:21:16AM +0200, Martin Liška wrote: > On 7/31/19 10:08 AM, Jan Hubicka wrote: > > Hi, > > > >> We do not detect jobserver because of Dejagnu is not using it. > >> And yes, we default to -flto=<numthreads> in LTO tests now. That's > >> what is causing issues right now. > > > > Why the error messages are > > make[4]: *** write jobserver: Bad file descriptor. Stop. > > make[4]: *** Waiting for unfinished jobs.... > > make[4]: *** write jobserver: Bad file descriptor. Stop. > > It seems to me that it is internal make from lto-wrapper trying to get > > jobserver access? > > Hard to guess. Can you Jakub debug that? I don't see the error message. I can easily reproduce even with make -j2 -k check-gcc RUNTESTFLAGS=lto.exp=*20081125* I've added a hack: --- lto-wrapper.c.jj 2019-07-31 09:46:39.361331843 +0200 +++ lto-wrapper.c 2019-07-31 10:40:57.970302110 +0200 @@ -1430,6 +1430,12 @@ run_gcc (unsigned argc, char *argv[]) jobserver or number of cores. */ auto_parallel = 1; jobserver = jobserver_active_p (); +FILE *f = fopen ("/tmp/111x", "a"); +fprintf (f, "%d %s\n", jobserver, getenv ("MAKEFLAGS")); +fclose (f); +char buf[1024]; +sprintf (buf, "ls -l /proc/%d/fd >> /tmp/111x", getpid ()); +system (buf); } if (linker_output) and see that in some cases jobserver is 0 and in other cases jobserver is 1. Examples of both: 0 kw -j2 --jobserver-auth=3,6 -- total 0 lrwx------. 1 jakub jakub 64 Jul 31 10:41 0 -> /dev/pts/4 l-wx------. 1 jakub jakub 64 Jul 31 10:41 1 -> pipe:[75026106] lr-x------. 1 jakub jakub 64 Jul 31 10:41 10 -> /usr/src/gcc/obj/gcc/libgcc_s.so lr-x------. 1 jakub jakub 64 Jul 31 10:41 13 -> /usr/lib64/libc.so lr-x------. 1 jakub jakub 64 Jul 31 10:41 18 -> /usr/src/gcc/obj/gcc/libgcc_s.so l-wx------. 1 jakub jakub 64 Jul 31 10:41 2 -> /tmp/ccX4y4r3.le l-wx------. 1 jakub jakub 64 Jul 31 10:41 9 -> pipe:[46167136] 1 kw -j2 --jobserver-auth=3,6 -- total 0 lrwx------. 1 jakub jakub 64 Jul 31 10:41 0 -> /dev/pts/4 l-wx------. 1 jakub jakub 64 Jul 31 10:41 1 -> /tmp/cchSvmBt lr-x------. 1 jakub jakub 64 Jul 31 10:41 10 -> /usr/lib64/crtn.o lrwx------. 1 jakub jakub 64 Jul 31 10:41 2 -> /dev/pts/4 lr-x------. 1 jakub jakub 64 Jul 31 10:41 3 -> /usr/lib64/crt1.o lr-x------. 1 jakub jakub 64 Jul 31 10:41 4 -> /usr/lib64/crti.o lr-x------. 1 jakub jakub 64 Jul 31 10:41 5 -> /usr/src/gcc/obj/gcc/crtbegin.o lr-x------. 1 jakub jakub 64 Jul 31 10:41 6 -> /usr/src/gcc/obj/gcc/testsuite/gcc/c_lto_20081125_0.o lr-x------. 1 jakub jakub 64 Jul 31 10:41 7 -> /usr/src/gcc/obj/gcc/testsuite/gcc/c_lto_20081125_1.o lr-x------. 1 jakub jakub 64 Jul 31 10:41 8 -> /usr/src/gcc/obj/gcc/crtend.o l-wx------. 1 jakub jakub 64 Jul 31 10:41 9 -> pipe:[46167136] so, if one is lucky enough and at least one of the two file descriptors in MAKEFLAGS --jobserver-auth= is closed, it will work fine, but if they are open, even when they have nothing to do with make, it will fail miserably. As a partial workaround, I wonder if jobserver_active_p couldn't check (with fstat/fstat64) if the file descriptors are pipes. It will still not be 100% reliable, as when you are unlucky the file descriptor could be some completely unrelated pipe, but at least better than the current state. Jakub
> and see that in some cases jobserver is 0 and in other cases jobserver is 1. > Examples of both: > 0 kw -j2 --jobserver-auth=3,6 -- > total 0 > lrwx------. 1 jakub jakub 64 Jul 31 10:41 0 -> /dev/pts/4 > l-wx------. 1 jakub jakub 64 Jul 31 10:41 1 -> pipe:[75026106] > lr-x------. 1 jakub jakub 64 Jul 31 10:41 10 -> /usr/src/gcc/obj/gcc/libgcc_s.so > lr-x------. 1 jakub jakub 64 Jul 31 10:41 13 -> /usr/lib64/libc.so > lr-x------. 1 jakub jakub 64 Jul 31 10:41 18 -> /usr/src/gcc/obj/gcc/libgcc_s.so > l-wx------. 1 jakub jakub 64 Jul 31 10:41 2 -> /tmp/ccX4y4r3.le > l-wx------. 1 jakub jakub 64 Jul 31 10:41 9 -> pipe:[46167136] > 1 kw -j2 --jobserver-auth=3,6 -- > total 0 > lrwx------. 1 jakub jakub 64 Jul 31 10:41 0 -> /dev/pts/4 > l-wx------. 1 jakub jakub 64 Jul 31 10:41 1 -> /tmp/cchSvmBt > lr-x------. 1 jakub jakub 64 Jul 31 10:41 10 -> /usr/lib64/crtn.o > lrwx------. 1 jakub jakub 64 Jul 31 10:41 2 -> /dev/pts/4 > lr-x------. 1 jakub jakub 64 Jul 31 10:41 3 -> /usr/lib64/crt1.o > lr-x------. 1 jakub jakub 64 Jul 31 10:41 4 -> /usr/lib64/crti.o > lr-x------. 1 jakub jakub 64 Jul 31 10:41 5 -> /usr/src/gcc/obj/gcc/crtbegin.o > lr-x------. 1 jakub jakub 64 Jul 31 10:41 6 -> /usr/src/gcc/obj/gcc/testsuite/gcc/c_lto_20081125_0.o > lr-x------. 1 jakub jakub 64 Jul 31 10:41 7 -> /usr/src/gcc/obj/gcc/testsuite/gcc/c_lto_20081125_1.o > lr-x------. 1 jakub jakub 64 Jul 31 10:41 8 -> /usr/src/gcc/obj/gcc/crtend.o > l-wx------. 1 jakub jakub 64 Jul 31 10:41 9 -> pipe:[46167136] > > so, if one is lucky enough and at least one of the two file descriptors in > MAKEFLAGS --jobserver-auth= is closed, it will work fine, but if they are > open, even when they have nothing to do with make, it will fail miserably. I see, so the problem is that lto-wrapper is executed via plugin from gold which already used the file descriptors for something else? This seems a bit of problem since gold opens it before we get to lto-plugin (most probably) so i do not see how to reliably detect presence of make server. I think the gcc binary can look for jobserv environment, detect jobserv and if it is not available remove jobserver option from it prior going to ld. I think this works since I think link-time gcc can only be executed via gcc/g++/gfortran... wrappers. (unlike lto plugin invoked implicitly for ar/nm etc). Honza > > As a partial workaround, I wonder if jobserver_active_p couldn't check (with > fstat/fstat64) if the file descriptors are pipes. It will still not be 100% > reliable, as when you are unlucky the file descriptor could be some > completely unrelated pipe, but at least better than the current state. > > Jakub
On Wed, Jul 31, 2019 at 11:12:15AM +0200, Jan Hubicka wrote: > > so, if one is lucky enough and at least one of the two file descriptors in > > MAKEFLAGS --jobserver-auth= is closed, it will work fine, but if they are > > open, even when they have nothing to do with make, it will fail miserably. > > I see, so the problem is that lto-wrapper is executed via plugin from > gold which already used the file descriptors for something else? I don't think I'm using gold, I have it installed, but /usr/bin/ld points to ld.bfd. Jakub
> On Wed, Jul 31, 2019 at 11:12:15AM +0200, Jan Hubicka wrote: > > > so, if one is lucky enough and at least one of the two file descriptors in > > > MAKEFLAGS --jobserver-auth= is closed, it will work fine, but if they are > > > open, even when they have nothing to do with make, it will fail miserably. > > > > I see, so the problem is that lto-wrapper is executed via plugin from > > gold which already used the file descriptors for something else? > > I don't think I'm using gold, I have it installed, but /usr/bin/ld points to > ld.bfd. Particular linker implementation probably does not make much pracitcal difference. It seems natural that linker opens couple files prior asking plugin doing its job. Honza
On 7/31/19 11:12 AM, Jan Hubicka wrote: >> and see that in some cases jobserver is 0 and in other cases jobserver is 1. >> Examples of both: >> 0 kw -j2 --jobserver-auth=3,6 -- >> total 0 >> lrwx------. 1 jakub jakub 64 Jul 31 10:41 0 -> /dev/pts/4 >> l-wx------. 1 jakub jakub 64 Jul 31 10:41 1 -> pipe:[75026106] >> lr-x------. 1 jakub jakub 64 Jul 31 10:41 10 -> /usr/src/gcc/obj/gcc/libgcc_s.so >> lr-x------. 1 jakub jakub 64 Jul 31 10:41 13 -> /usr/lib64/libc.so >> lr-x------. 1 jakub jakub 64 Jul 31 10:41 18 -> /usr/src/gcc/obj/gcc/libgcc_s.so >> l-wx------. 1 jakub jakub 64 Jul 31 10:41 2 -> /tmp/ccX4y4r3.le >> l-wx------. 1 jakub jakub 64 Jul 31 10:41 9 -> pipe:[46167136] >> 1 kw -j2 --jobserver-auth=3,6 -- >> total 0 >> lrwx------. 1 jakub jakub 64 Jul 31 10:41 0 -> /dev/pts/4 >> l-wx------. 1 jakub jakub 64 Jul 31 10:41 1 -> /tmp/cchSvmBt >> lr-x------. 1 jakub jakub 64 Jul 31 10:41 10 -> /usr/lib64/crtn.o >> lrwx------. 1 jakub jakub 64 Jul 31 10:41 2 -> /dev/pts/4 >> lr-x------. 1 jakub jakub 64 Jul 31 10:41 3 -> /usr/lib64/crt1.o >> lr-x------. 1 jakub jakub 64 Jul 31 10:41 4 -> /usr/lib64/crti.o >> lr-x------. 1 jakub jakub 64 Jul 31 10:41 5 -> /usr/src/gcc/obj/gcc/crtbegin.o >> lr-x------. 1 jakub jakub 64 Jul 31 10:41 6 -> /usr/src/gcc/obj/gcc/testsuite/gcc/c_lto_20081125_0.o >> lr-x------. 1 jakub jakub 64 Jul 31 10:41 7 -> /usr/src/gcc/obj/gcc/testsuite/gcc/c_lto_20081125_1.o >> lr-x------. 1 jakub jakub 64 Jul 31 10:41 8 -> /usr/src/gcc/obj/gcc/crtend.o >> l-wx------. 1 jakub jakub 64 Jul 31 10:41 9 -> pipe:[46167136] >> >> so, if one is lucky enough and at least one of the two file descriptors in >> MAKEFLAGS --jobserver-auth= is closed, it will work fine, but if they are >> open, even when they have nothing to do with make, it will fail miserably. > > I see, so the problem is that lto-wrapper is executed via plugin from > gold which already used the file descriptors for something else? > > This seems a bit of problem since gold opens it before we get to > lto-plugin (most probably) so i do not see how to reliably detect > presence of make server. Thank you Jakub for debugging! > > I think the gcc binary can look for jobserv environment, detect jobserv > and if it is not available remove jobserver option from it prior going > to ld. I think this works since I think link-time gcc can only be > executed via gcc/g++/gfortran... wrappers. Do you mean something like what I'm attaching? Anyway, the auto-detection of jobserver seems very ugly to me :/ I tend to remove the support and start working on a proper implementation that can be used not only by make build system. Martin > > (unlike lto plugin invoked implicitly for ar/nm etc). > > Honza >> >> As a partial workaround, I wonder if jobserver_active_p couldn't check (with >> fstat/fstat64) if the file descriptors are pipes. It will still not be 100% >> reliable, as when you are unlucky the file descriptor could be some >> completely unrelated pipe, but at least better than the current state. >> >> Jakub
> diff --git a/gcc/gcc.c b/gcc/gcc.c > index a4323eb146e..e43f46246ad 100644 > --- a/gcc/gcc.c > +++ b/gcc/gcc.c > @@ -8268,6 +8268,44 @@ driver::maybe_run_linker (const char *argv0) const > { > int tmp = execution_count; > > + /* Detect jobserver and drop it if it's not working. */ > + const char *makeflags = env.get ("MAKEFLAGS"); > + if (makeflags != NULL) > + { > + const char *needle = "--jobserver-auth="; > + const char *n = strstr (makeflags, needle); > + if (n != NULL) > + { > + int rfd = -1; > + int wfd = -1; > + > + bool jobserver > + = ((sscanf(n, "--jobserver-auth=%d,%d", &rfd, &wfd) == 2) > + && rfd > 0 > + && wfd > 0 > + && fcntl (rfd, F_GETFD) >= 0 > + && fcntl (wfd, F_GETFD) >= 0); Yes, I suppose this is the test whether file descriptors are open that should work in our context. Honza > + > + /* Drop the jobserver if it's not working now. */ > + if (!jobserver) > + { > + unsigned offset = n - makeflags; > + char *dup = xstrdup (makeflags); > + dup[offset] = '\0'; > + > + const char *space = strchr (makeflags + offset, ' '); > + if (space != NULL) > + strcpy (dup + offset, space); > + xputenv (concat ("MAKEFLAGS=", dup, NULL)); > + > + // TODO: remove > + FILE *f = fopen ("/tmp/111x", "a"); > + fprintf (f, "dropping MAKEFLAGS\n"); > + fclose (f); > + } > + } > + } > + > if (! have_c) > { > #if HAVE_LTO_PLUGIN > 0 > diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c > index 353187c6043..10b74d84af7 100644 > --- a/gcc/lto-wrapper.c > +++ b/gcc/lto-wrapper.c > @@ -1430,6 +1430,13 @@ run_gcc (unsigned argc, char *argv[]) > jobserver or number of cores. */ > auto_parallel = 1; > jobserver = jobserver_active_p (); > + > +FILE *f = fopen ("/tmp/111x", "a"); > +fprintf (f, "%d %s\n", jobserver, getenv ("MAKEFLAGS")); > +fclose (f); > +char buf[1024]; > +sprintf (buf, "ls -l /proc/%d/fd >> /tmp/111x", getpid ()); > +system (buf); > } > > if (linker_output)
On 7/31/19 12:01 PM, Martin Liška wrote: > Anyway, the auto-detection of jobserver seems very ugly to me :/ > I tend to remove the support and start working on a proper implementation > that can be used not only by make build system. Can you Jakub test the attached patch please? Do it reach a ulimit limit on your testing environment? Thanks, Martin
On Wed, Jul 31, 2019 at 05:00:37PM +0200, Martin Liška wrote: > On 7/31/19 12:01 PM, Martin Liška wrote: > > Anyway, the auto-detection of jobserver seems very ugly to me :/ > > I tend to remove the support and start working on a proper implementation > > that can be used not only by make build system. > > Can you Jakub test the attached patch please? That works. I guess it didn't actually act as a fork-bomb because most of our lto tests are small and there aren't enough functions to create so many partitions. Jakub
From 72489809a50a52f37748fe9ca4e7382ef2faa00c Mon Sep 17 00:00:00 2001 From: Martin Liska <mliska@suse.cz> Date: Tue, 23 Jul 2019 10:14:31 +0200 Subject: [PATCH] Deduce automatically number of cores for -flto option. gcc/ChangeLog: 2019-07-23 Martin Liska <mliska@suse.cz> * doc/invoke.texi: Document new behavior. * lto-wrapper.c (cpuset_popcount): New function is a copy of libgomp/config/linux/proc.c. (init_num_threads): Likewise. (run_gcc): Automatically detect core count for -flto. --- gcc/doc/invoke.texi | 3 +- gcc/lto-wrapper.c | 121 +++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 122 insertions(+), 2 deletions(-) diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 77a2d561e38..f5bfea3f003 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -10396,7 +10396,8 @@ If you specify the optional @var{n}, the optimization and code generation done at link time is executed in parallel using @var{n} parallel jobs by utilizing an installed @command{make} program. The environment variable @env{MAKE} may be used to override the program -used. The default value for @var{n} is 1. +used. The default value for @var{n} is automatically detected based +on number of cores. You can also specify @option{-flto=jobserver} to use GNU make's job server mode to determine the number of parallel jobs. This diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c index 946897726d0..7e29ecb3618 100644 --- a/gcc/lto-wrapper.c +++ b/gcc/lto-wrapper.c @@ -1110,6 +1110,110 @@ cmp_priority (const void *a, const void *b) return *((const int *)b)-*((const int *)a); } +/* Number of CPUs that can be used for parallel LTRANS phase. */ + +static unsigned long nthreads_var = 0; + +#ifdef HAVE_PTHREAD_AFFINITY_NP +unsigned long cpuset_size; +static unsigned long get_cpuset_size; +cpu_set_t *cpusetp; + +unsigned long +static cpuset_popcount (unsigned long cpusetsize, cpu_set_t *cpusetp) +{ +#ifdef CPU_COUNT_S + /* glibc 2.7 and above provide a macro for this. */ + return CPU_COUNT_S (cpusetsize, cpusetp); +#else +#ifdef CPU_COUNT + if (cpusetsize == sizeof (cpu_set_t)) + /* glibc 2.6 and above provide a macro for this. */ + return CPU_COUNT (cpusetp); +#endif + size_t i; + unsigned long ret = 0; + STATIC_ASSERT (sizeof (cpusetp->__bits[0]) == sizeof (unsigned long int)); + for (i = 0; i < cpusetsize / sizeof (cpusetp->__bits[0]); i++) + { + unsigned long int mask = cpusetp->__bits[i]; + if (mask == 0) + continue; + ret += __builtin_popcountl (mask); + } + return ret; +#endif +} +#endif + +/* At startup, determine the default number of threads. It would seem + this should be related to the number of cpus online. */ + +static void +init_num_threads (void) +{ +#ifdef HAVE_PTHREAD_AFFINITY_NP +#if defined (_SC_NPROCESSORS_CONF) && defined (CPU_ALLOC_SIZE) + cpuset_size = sysconf (_SC_NPROCESSORS_CONF); + cpuset_size = CPU_ALLOC_SIZE (cpuset_size); +#else + cpuset_size = sizeof (cpu_set_t); +#endif + + cpusetp = (cpu_set_t *) xmalloc (gomp_cpuset_size); + do + { + int ret = pthread_getaffinity_np (pthread_self (), gomp_cpuset_size, + cpusetp); + if (ret == 0) + { + /* Count only the CPUs this process can use. */ + nthreads_var = cpuset_popcount (cpuset_size, cpusetp); + if (nthreads_var == 0) + break; + get_cpuset_size = cpuset_size; +#ifdef CPU_ALLOC_SIZE + unsigned long i; + for (i = cpuset_size * 8; i; i--) + if (CPU_ISSET_S (i - 1, cpuset_size, cpusetp)) + break; + cpuset_size = CPU_ALLOC_SIZE (i); +#endif + return; + } + if (ret != EINVAL) + break; +#ifdef CPU_ALLOC_SIZE + if (cpuset_size < sizeof (cpu_set_t)) + cpuset_size = sizeof (cpu_set_t); + else + cpuset_size = cpuset_size * 2; + if (cpuset_size < 8 * sizeof (cpu_set_t)) + cpusetp + = (cpu_set_t *) realloc (cpusetp, cpuset_size); + else + { + /* Avoid fatal if too large memory allocation would be + requested, e.g. kernel returning EINVAL all the time. */ + void *p = realloc (cpusetp, cpuset_size); + if (p == NULL) + break; + cpusetp = (cpu_set_t *) p; + } +#else + break; +#endif + } + while (1); + cpuset_size = 0; + nthreads_var = 1; + free (cpusetp); + cpusetp = NULL; +#endif +#ifdef _SC_NPROCESSORS_ONLN + nthreads_var = sysconf (_SC_NPROCESSORS_ONLN); +#endif +} /* Execute gcc. ARGC is the number of arguments. ARGV contains the arguments. */ @@ -1124,6 +1228,7 @@ run_gcc (unsigned argc, char *argv[]) const char *collect_gcc, *collect_gcc_options; int parallel = 0; int jobserver = 0; + int auto_parallel = 0; bool no_partition = false; struct cl_decoded_option *fdecoded_options = NULL; struct cl_decoded_option *offload_fdecoded_options = NULL; @@ -1260,6 +1365,8 @@ run_gcc (unsigned argc, char *argv[]) /* Fallthru. */ case OPT_flto: + auto_parallel = 1; + parallel = 1; lto_mode = LTO_MODE_WHOPR; break; @@ -1291,6 +1398,7 @@ run_gcc (unsigned argc, char *argv[]) { lto_mode = LTO_MODE_LTO; jobserver = 0; + auto_parallel = 0; parallel = 0; } @@ -1485,6 +1593,16 @@ cont1: if (jobserver) obstack_ptr_grow (&argv_obstack, xstrdup ("-fwpa=jobserver")); + else if (auto_parallel) + { + char buf[256]; + init_num_threads (); + if (verbose) + fprintf (stderr, "LTO parallelism level set to %ld\n", + nthreads_var); + sprintf (buf, "-fwpa=%ld", nthreads_var); + obstack_ptr_grow (&argv_obstack, xstrdup (buf)); + } else if (parallel > 1) { char buf[256]; @@ -1692,7 +1810,8 @@ cont: i = 3; if (!jobserver) { - snprintf (jobs, 31, "-j%d", parallel); + snprintf (jobs, 31, "-j%ld", + auto_parallel ? nthreads_var : parallel); new_argv[i++] = jobs; } new_argv[i++] = "all"; -- 2.22.0