[COMMITTED] Use pragmas rather than makefiles for necessary options for unwind code.

  Verified on x86_64-linux-gnu that no generated code (including unwind info)
changes.  Also tested arm-linux-gnueabihf that no generated code changes;
there was one difference in the EABI unwind info for __unwind_freeres,
which I don't understand but also deem wholly unimportant.

Thanks,
Roland


2014-12-16  Roland McGrath  <roland@hack.frob.com>

	* nptl/unwind.c: Use pragma to turn on -fexceptions.
	* sysdeps/nptl/unwind-forcedunwind.c: Use pragma to turn on
	-fexceptions and -fasynchronous-unwind-tables.
	* sysdeps/unix/sysv/linux/arm/unwind-forcedunwind.c: Likewise.
	* sysdeps/gnu/unwind-resume.c: Likewise.
	* nptl/Makefile (CFLAGS-unwind.c, CFLAGS-unwind-forcedunwind.c):
	Variables removed.
	* sysdeps/gnu/Makefile
	[$(subdir) = csu] (CFLAGS-unwind-resume.c): Likewise.
	[$(subdir) = rt] (CFLAGS-rt-unwind-resume.c): Likewise.
  

On Tue, 16 Dec 2014, Roland McGrath wrote:

> Verified on x86_64-linux-gnu that no generated code (including unwind info)
> changes.  Also tested arm-linux-gnueabihf that no generated code changes;
> there was one difference in the EABI unwind info for __unwind_freeres,
> which I don't understand but also deem wholly unimportant.

I don't think this is safe.  The optimize pragma is documented as being 
for optimization options only; using it with other options such as 
-fexceptions is not a documented or supported GCC feature (actually, even 
using it for some optimization options can be very fragile; it's best to 
use it only for purely non-semantic options rather than those such as 
-ffast-math that affect semantics).  -fexceptions affects global state in 
GCC, including global choices made when the parser is initialized [*]; 
enabling it at any later point risks subtle problems from inconsistencies 
in GCC's internal datastructures; that it works with a particular version 
of GCC at a particular time means very little.  Enabling it after headers 
(probably including inline functions) have been parsed seems even riskier 
than enabling it at the start of a source file before any headers have 
been parsed (but I still don't think that would be safe).

[*] using_eh_for_cleanups - on that basis, it seems quite plausible that 
cleanup attributes (as used in various ways in glibc) will not reliably 
interact properly with exceptions if exceptions weren't enabled from the 
command line.
  

OK.  I've reverted it (including the ChangeLog and all, since there were no
later commits anyway).

I was eager to do this because I thought it was going to simplify some
other changes I'm working on.  But I changed tack on that work anyway
so I think this is now wholly orthogonal.


Thanks,
Roland