[Bug target/60817] gcc configure script misdetects TLS support on x86_64-pc-solaris* with gnu as

[redlizard at redlizard dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60817

--- Comment #2 from Ruud Koolen redlizard at redlizard dot nl ---
I generated the patch cleanly against trunk. What's wrong with it?

[Bug target/60817] New: gcc configure script misdetects TLS support on x86_64-pc-solaris* with gnu as

[redlizard at redlizard dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60817

Bug ID: 60817
   Summary: gcc configure script misdetects TLS support on
x86_64-pc-solaris* with gnu as
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redlizard at redlizard dot nl

Created attachment 32584
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32584action=edit
Proposed patch.

When building gcc = 4.7 on x86_64-pc-solaris2.11 --with-gnu-as, the
gcc/configure script incorrectly decides that gnu as does not support real TLS,
and so unnecessarily decides to activate emutls instead.

The solaris-specific test checks this support by trying to assemble a piece of
TLS-using assembly code, and it uses the same 32-bit code for this test both on
32-bit and 64-bit platforms. The solaris assembler will accept this, but gnu as
fails on the 32 bit code when targeting x86_64-pc-solaris*, thus causing the
detection to fail.

Attached patch for 4.9 fixes the problem, and is trivially backported to 4.8
and 4.7.

[Bug middle-end/60221] [4.7/4.8 Regression] gcc -fexceptions generates unnecessary cleanup code

[redlizard at redlizard dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60221

--- Comment #6 from Ruud Koolen redlizard at redlizard dot nl ---
This fix solves my original problem. Resolved, as far as I'm concerned.

Will this fix also be applied to 4.7 and 4.8?

[Bug c/60221] New: gcc -fexceptions generates unnecessary cleanup code

[redlizard at redlizard dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60221

Bug ID: 60221
   Summary: gcc -fexceptions generates unnecessary cleanup code
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redlizard at redlizard dot nl

 gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/tmp/gcc-4.8.2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8.2/configure --prefix=/tmp/gcc-4.8.2
--enable-languages=c,c++
Thread model: posix
gcc version 4.8.2 (GCC)


 cat test.c
void bar(void);
void foo(void)
{
  struct { int x; } y;
  bar();
}


When compiled with `gcc -fexceptions -O0 -c test.c`, the above code generates
cleanup code for stack unwinding purposes, referencing __gcc_personality_v0;
this necessitates linking with shared-libgcc.

I am not sure this is really a bug, but versions of gcc older than 4.7 do not
generate cleanup code for this example; neither does gcc 4.8 when the local
variable is replaced by `int y;`. Moreover, according to the gcc documentation,
there are several situations (I have been unable to find more a detailed
specification) in which linking with shared-libgcc is necessary, which includes
code throwing or catching exceptions, but should -- as far as I can see --
*not* include c code just passing through exceptions.

Tested on x86_64-unknown-linux-gnu, x86_64-unknown-linux-gnu -m32, and
i386-pc-solaris2.11, using gcc 4.7.1, 4.7.3, and 4.8.2. gcc 4.6.4 and earlier
tested versions are not affected. I have been unable to test gcc 4.7.0.