Re: [PATCH] Deduce automatically number of cores for -flto option.

[Jan Hubicka <hubicka@ucw.cz>]

> 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