[Bug bootstrap/66022] 4.8.4 build fails with stage 2 and 3 comparison error

2015-12-01 Thread norm.jacobs at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66022

Norm Jacobs  changed:

   What|Removed |Added

 CC||norm.jacobs at oracle dot com

--- Comment #2 from Norm Jacobs  ---
I have run into something similar building GCC 4.8.2 on a Solaris 12
development build.

silence-ld04% uname -a
SunOS silence-ld04 5.12 s12_87 sun4v sparc sun4v

I have a Sparc Solaris 12 system with Binutils 2.25.1.  When I try to build GCC
4.8.2 (yes, I know it's old) I get failures in the stage2/stage3 comparison.

[snip]
libiberty/strsignal.o differs
libiberty/dwarfnames.o differs
libiberty/physmem.o differs
libiberty/obstack.o differs
libiberty/choose-temp.o differs
libiberty/strerror.o differs
libiberty/safe-ctype.o differs
zlib/libz_a-uncompr.o differs
zlib/libz_a-gzwrite.o differs
zlib/libz_a-inffast.o differs
zlib/libz_a-compress.o differs
zlib/libz_a-zutil.o differs
make[3]: *** [compare] Error 1

It seems to build fine with Binutils 2.23.1 installed and seems to build fine
on x86.  A little digging and I found that configure is deciding set
BUILD_CONFIG to bootstrap-debug with Binutils 2.25.1 installed on SPARC, but
not otherwise.  Doing this adds "-gtoggle" to the compilation line in stage2,
which wouldn't be a problem since the comparison should have switched to
contrib/compare-debug which strips out unwanted ELF sections prior to
comparison.  In my case, the problem seems to be that the ELF sections are
re-ordered as a result of adding '-gtoggle' to the compilation.  Since the
sections are re-ordered, the comparison fails even after being stripped.

silence-ld04% /usr/gnu/bin/objdump --headers libz_a-zutil.o*

libz_a-zutil.o: file format elf32-sparc-sol2

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .text 0114      0120  2**2
  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .rodata   00c6      0238  2**3
  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
  2 .debug_frame  009c      0300  2**2
  CONTENTS, RELOC, READONLY, DEBUGGING
  3 .debug_info   02aa      039c  2**0
  CONTENTS, RELOC, READONLY, DEBUGGING
  4 .debug_abbrev 00fd      0646  2**0
  CONTENTS, READONLY, DEBUGGING
  5 .debug_loc00a0      0743  2**0
  CONTENTS, READONLY, DEBUGGING
  6 .debug_aranges 0020      07e3  2**0
  CONTENTS, RELOC, READONLY, DEBUGGING
  7 .debug_line   0122      0803  2**0
  CONTENTS, RELOC, READONLY, DEBUGGING
  8 .debug_str      0925  2**0
  CONTENTS, READONLY, DEBUGGING
  9 .comment  004e      0e00  2**0
  CONTENTS, READONLY

libz_a-zutil.o.gtoggle: file format elf32-sparc-sol2

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .rodata   00c6      0080  2**3
  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
  1 .text 0114      0148  2**2
  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  2 .comment  004e      0430  2**0
  CONTENTS, READONLY
silence-ld04%

Note that the ordering of .rodata and .text differ.  I can workaround this for
now using "--with-build-config=no" when I configure, but it seems odd that my
ELF sections are getting re-ordered.  I haven't yet tried to build the trunk on
this system.

[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library

2016-07-21 Thread norm.jacobs at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411

Norm Jacobs  changed:

   What|Removed |Added

 CC||norm.jacobs at oracle dot com

--- Comment #29 from Norm Jacobs  ---
Created attachment 38948
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38948&action=edit
proposed fix to link values-*.o

Unfortunately, due to the way support for behavioral differences in conflicting
standards interfaces is implemented in Solaris libc and libm, there really
isn't a perfect answer here.  An offline discussion of this led to the
conclusion that "the application dictates the xpg'ness and any library that
thinks it has control from the compilation options it uses, is fooling itself."

The current builds of GCC that are delivered with Solaris 11 and later include
a patch very similar to the one that I have attached.  The one that I have
attached should only link in appropriate values-*.o files when GCC calls the
linker to generate an executable program.  This seems consistent with what the
Studio compilers do.