[Bug target/85400] R_SPARC_TLS_*: invalid relocations generated for optimized builds on sparc

2018-04-16 Thread phantall at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85400

--- Comment #2 from Brian Vandenberg  ---
Sorry, I was hand-typing from an air-gapped network.  I left the type name
out; line 5 should read:

>  thread_local int mything = 3;

-brian

On Mon, Apr 16, 2018 at 2:52 AM, ebotcazou at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85400
>
> Eric Botcazou  changed:
>
>What|Removed |Added
> 
> 
>  Status|UNCONFIRMED |WAITING
>Last reconfirmed||2018-04-16
>  CC||ebotcazou at gcc dot
> gnu.org
>  Ever confirmed|0   |1
>
> --- Comment #1 from Eric Botcazou  ---
> > In Solaris 10 & 11 using GCC versions 4.8, 4.9.2, 7.2.0 I get relocation
> > errors when thread_local variables are used in a struct/class.  Example
> code
> > that reproduces the problem:
> >
> > > struct Test {
> > >   int blah( int y ) {
> > > thread_local mything = 3;
> > > mything = y > 0 ? y : mything;
> > > return mything;
> > >   }
> > > };
> > > int stuff( Test& test, int y ) {
> > >   return test.blah(y);
> > > }
>
> This doesn't compile for me:
>
> pr85400.C: In member function 'int Test::blah(int)':
> pr85400.C:5:18: error: 'mything' does not name a type
>  thread_local mything = 3;
>   ^~~
> pr85400.C:6:5: error: 'mything' was not declared in this scope
>  mything = y > 0 ? y : mything;
>  ^~~
>
> > * The compilers I built and those produced by OpenCSW use the Solaris
> > assembler (/usr/ccs/bin/as) instead of gas.
>
> Do you have local patches?  My compiler is the stock GCC 8.x:
>
> Using built-in specs.
> COLLECT_GCC=g++
> COLLECT_LTO_WRAPPER=/nfs/homes/homes/botcazou/gcc-head/
> install_sparc/bin/../libexec/gcc/sparc-sun-solaris2.10/8.0.1/lto-wrapper
> Target: sparc-sun-solaris2.10
> Configured with: /homes/botcazou/gcc-head/src/configure
> --build=sparc-sun-solaris2.10 --prefix=/homes/botcazou/gcc-
> head/install_sparc
> --with-as=/homes/botcazou/gcc-head/install_sparc/bin/as
> --with-gmp=/homes/botcazou/support/sparc
> --with-mpfr=/homes/botcazou/support/sparc
> --with-mpc=/homes/botcazou/support/sparc --enable-languages=all
> --disable-nls
> Thread model: posix
> gcc version 8.0.1 20180325 (experimental) (GCC)
>
> --
> You are receiving this mail because:
> You reported the bug.
>

[Bug c++/85400] New: R_SPARC_TLS_*: invalid relocations generated for optimized builds on sparc

2018-04-13 Thread phantall at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85400

Bug ID: 85400
   Summary: R_SPARC_TLS_*: invalid relocations generated for
optimized builds on sparc
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: phantall at gmail dot com
  Target Milestone: ---

In Solaris 10 & 11 using GCC versions 4.8, 4.9.2, 7.2.0 I get relocation errors
when thread_local variables are used in a struct/class.  Example code that
reproduces the problem:

> struct Test {
>   int blah( int y ) {
> thread_local mything = 3;
> mything = y > 0 ? y : mything;
> return mything;
>   }
> };
> int stuff( Test& test, int y ) {
>   return test.blah(y);
> }

When compiled:

> $ g++ -m32 -fPIC -std=gnu++14 blah.cc -c -o blah1.o
> $ g++ -m32 -fPIC -std=gnu++14 blah.cc -c -o blah2.o -O3
> $ objdump -xC blah1.o | grep mything
> (...)
> 0038 R_SPARC_TLS_GD_HI22  Test::blah(int)::mything
> 003c R_SPARC_TLS_GD_LO10  Test::blah(int)::mything
> (...)
> $ objdump -xC blah2.o | grep mything
> (...)
> 0014 R_SPARC_TLS_LDM_HI22  Test::blah(int)::mything
> 001c R_SPARC_TLS_LDO_HIX22  Test::blah(int)::mything
> 0020 R_SPARC_TLS_LDM_LO10  Test::blah(int)::mything
> 0024 R_SPARC_TLS_LDO_LOX10  Test::blah(int)::mything
> (...)
> $ g++ -m32 -fPIC -shared blah2.o -o libblah.so
> ld: fatal: relocation error: R_SPARC_TLS_LDM_HI22: file blah2.o: symbol: 
> _ZZN4Test4blahEiE7mything: bound to: blah.o: relocation illegal when not 
> bound to object being created
> ld: fatal: relocation error: R_SPARC_TLS_LDM_HIX22: file blah2.o: symbol: 
> _ZZN4Test4blahEiE7mything: bound to: blah.o: relocation illegal when not 
> bound to object being created
> ...


For reference:

* It happens at all optimization levels above -O0 and for all combinations of
-std={c,gnu}++{11,14}
* This was discovered while building boost 1.66.0 with -std=gnu++14.  The error
occurs while linking libboost_fiber.so and comes from work_stealing.cpp for
boost::fibers::detail::spinlock_ttas::lock()::generator ... where "generator"
in that code is a static thread_local at member-function scope.
* The compilers I built and those produced by OpenCSW use the Solaris assembler
(/usr/ccs/bin/as) instead of gas.

[Bug bootstrap/79076] bootstrap comparison failure with Sun tools

2017-01-13 Thread phantall at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79076

--- Comment #2 from Brian Vandenberg  ---
> Right, the 4.9.x series is not longer supported.

I forgot to mention that this was happening with 5.4.0 and 6.3.0 as well.

[Bug bootstrap/79076] New: [sparc/solaris] bootstrap comparison failure, in-tree binutils + --without-gnu-as

2017-01-12 Thread phantall at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79076

Bug ID: 79076
   Summary: [sparc/solaris] bootstrap comparison failure, in-tree
binutils + --without-gnu-as
   Product: gcc
   Version: 4.9.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: phantall at gmail dot com
  Target Milestone: ---

Details:
* solaris 10
* gcc 4.9.2 for the initial compiler
* Followed the general configure/build pattern used by OpenCSW with a few
differences in configure flags (eg, not as many languages)
* Unlike OpenCSW I did it with binutils/cloog/mpfr/mpc/isl in-tree

The only thing that seemed to resolve the problem was to force it to use the
GNU assembler.  When using /usr/ccs/bin/as it would fail on the bootstrap
comparison.

I'm more reporting this to help out anyone who may run into this in the future
than in any hopes a fix will be forthcoming.

Here's what I did to get it configured:

 export AS=/usr/ccs/bin/as
 export AR=/usr/ccs/bin/ar
 export NM=/usr/ccs/bin/nm
 export RANLIB=/usr/ccs/bin/ranlib
 export STRIP=/usr/ccs/bin/strip
 export OBJCOPY=/opt/csw/gnu/objcopy

 export OBJDUMP=/opt/csw/gnu/objdump
 export READELF=/opt/csw/gnu/readelf

 export SHELL=/opt/csw/bin/bash
 export BUILD_SHELL=${SHELL}
 export CONFIG_SHELL=${SHELL}

 export
PATH=/opt/csw/gnu:/opt/csw/bin:/bin:/usr/bin:/usr/local/bin:/usr/sbin
 export -n LD_LIBRARY_PATH=

 mkdir -p /tmp/gcc-4.9.4/{build,src}/gcc-4.9.4
 cd /tmp/gcc-4.9.4/src
 /opt/csw/gnu/tar xf ~/Downloads/gcc/gcc-4.9.4.tar.bz2
 /opt/csw/gnu/tar xf ~/Downloads/gcc/binutils-2.24.tar.bz2
 /opt/csw/gnu/tar xf ~/Downloads/gcc/cloog-0.18.1.tar.gz
 /opt/csw/gnu/tar xf ~/Downloads/gcc/gmp-5.1.3.tar.gz
 /opt/csw/gnu/tar xf ~/Downloads/gcc/isl-0.12.2.tar.bz2
 /opt/csw/gnu/tar xf ~/Downloads/gcc/mpc-0.8.2.tar.gz
 /opt/csw/gnu/tar xf ~/Downloads/gcc/mpfr-3.1.2.tar.gz

 # note: opencsw doesn't do the in-tree build and there's a
 # few configure options that differ, but nothing that should
 # influence things)
 cd gcc-4.9.4
 ln -s ../cloog-0.18.1 cloog
 ln -s ../gmp-5.1.3 gmp
 ln -s ../isl-0.16.1 isl
 ln -s ../mpfr-3.1.2 mpfr
 ln -s ../binutils-2.24/binutils
 # I was intentionally not building these in solaris
 #ln -s ../binutils-2.24/gas
 #ln -s ../binutils-2.24/gold
 #ln -s ../binutils-2.24/ld
 ln -s ../binutils-2.24/bfd
 ln -s ../binutils-2.24/cpu
 ln -s ../binutils-2.24/elfcpp
 ln -s ../binutils-2.24/etc
 ln -s ../binutils-2.24/gprof
 ln -s ../binutils-2.24/opcodes

 cd /tmp/gcc-4.9.4/build/gcc-4.9.4
 /tmp/gcc-4.9.4/src/gcc-4.9.4/configure \
   --prefix=/a/non-standard/location \
   --enable-languages=c,c++,go \
   --disable-werror \
   --without-gnu-ld \
   --without-gnu-as \
   --with-ld=/usr/ccs/bin/ld \
   --with-as=${AS} \
   --enable-lto \
   --enable-libssp \
   --disable-nls \
   --enable-threads=posix \
   --with-system-zlib=/opt/csw \
   AR=${AR} \
   NM=${NM} \
   RANLIB=${RANLIB} \
   STRIP=${STRIP} \
   OBJCOPY=${OBJCOPY} \
   OBJDUMP=${OBJDUMP} \
   READELF=${READELF}

[Bug other/45992] New: MULTIOSSUBDIR in Makefile for target/libgcc missing quotes on 'test'

2010-10-12 Thread phantall at gmail dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45992

   Summary: MULTIOSSUBDIR in Makefile for target/libgcc missing
quotes on 'test'
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: phant...@gmail.com


During a 'make clean' in this directory (eg, sparcv9-sun-solaris2.10/libgcc),
an error occurs:

/bin/bash: line 0: test: !=: unary operator expected

... where presumably the variable MULTIOSDIR is blank.  Adding double-quotes
around this variable in the script fixes it, eg:


MULTIOSSUBDIR := $(shell  if test $(MULTIOSDIR) != .; then echo /$(MULTIOSDIR);
fi)

... becomes:

MULTIOSSUBDIR := $(shell  if test $(MULTIOSDIR) != .; then echo
/$(MULTIOSDIR); fi)

-Brian

[Bug other/45994] New: During 'make clean', some variables not propagating properly

2010-10-12 Thread phantall at gmail dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45994

   Summary: During 'make clean', some variables not propagating
properly
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: phant...@gmail.com


During a make clean, when it attempts to execute 'make clean' for
target/libgcc, the 'CC' variable is populated with 'CC_FOR_TARGET' which may
not be populated during a 'clean'.  This cascades into another problem on a few
different lines in target/libgcc/Makefile.  For example, on (or about) gcc
build path/sparcv9-sun-solaris2.10/libgcc/Makefile:199, the following line is
present:


version := $(shell $(CC) -dumpversion)


$(CC) typically populates this line with something of the form:


gcc build path/./gcc/xgcc -Bsome path -Bsome other path (and so on)


... when this Makefile is used.  However, at the moment it's populating CC with
the empty string, which results in that 'version' line looking (in effect) like
this:


version := ($shell -Bsome path -Bsome other path etc -dumpversion)

... causing bash to exit with the error:

/bin/bash: -/: invalid option
(bash usage info below this line)

Temporary workaround is to enter the target/libgcc directory and manually
'make clean', or during 

-Brian

[Bug other/45920] New: Building gcc: flags passed during configure step not used everywhere

2010-10-06 Thread phantall at gmail dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45920

   Summary: Building gcc: flags passed during configure step not
used everywhere
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: phant...@gmail.com


I'm on a network with a hodgepodge of tools of varying versions, and I'm
attempting to remedy the problem, but I can only build from sources for this
particular environment.

The build target is sparcv9-sun-solaris2.10, and I configured with:

mkdir /usr1/tools/gcc-4.5.1-build
cd /usr1/tools/gcc-4.5.1-build
../gcc-4.5.1/configure --prefix=/usr1/local/gcc-4.5.1 \
  --with-gmp=/usr1/local/gmp-5.0.1 \
  --with-mpfr=/usr1/local/mpfr-3.0.0 \
  --with-mpc=/usr1/local/mpc-0.8.2 \
  --build=sparcv9-sun-solaris2.10 \
  --enable-languages='c,c++' \
  --with-stage1-ldflags='-O2 -m64 -mptr64 -mcpu=v9' \
  --with-boot-ldflags='-O2 -m64 -mptr64 -mcpu=v9' \
  CC=/opt/csw/gcc3/bin/gcc \
  CFLAGS='-O2 -m64 -mptr64 -mcpu=v9' \
  CPPFLAGS='-O2 -m64 -mptr64 -mcpu=v9' \
  BOOT_CFLAGS='-O2 -m64 -mptr64 -mcpu=v9' \
  LDFLAGS='-O2 -m64 -mptr64 -mcpu=v9'


The overload of flags is from me trying to find some way to get the portion I
encountered problems with to use the right flags.

During stage 1 (stage_last and stage_current both say stage 1 in them), it
enters the build/gcc directory and executes the Makefile there.  It fails
after building (gensupport?) and errors when it tries to link them.  The link
step has the appropriate flags to target a 64-bit platform, but the other two
object files target ELF32.

The error I was receiving was wrong ELF class, ELFCLASS32 during link.

On line 3675 or so of (...)/gcc/Makefile, it has the following line:


$(COMPILER_FOR_BUILD) -c $(BUILD_COMPILERFLAGS) $(BUILD_CPPFLAGS) \
  -o $@ $


Neither BUILD_COMPILERFLAGS or BUILD_CPPFLAGS contain the appropriate flags I
set during the configure step.  Furthermore, around line 136 the CFLAGS line is
empty -- which is probably the cause.

As a temporary workaround I added appropriate flags to line 136.

[Bug other/45920] Building gcc: flags passed during configure step not used everywhere

2010-10-06 Thread phantall at gmail dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45920

--- Comment #1 from Brian Vandenberg phantall at gmail dot com 2010-10-06 
23:23:54 UTC ---
This is more systemic than just (...)/gcc.  Other Makefiles have the same issue
(eg, libdecnumber, libcpp to name a few).

-Brian