Bug 61026 - sh-rtems4.11 build of 4.9.0 fails on FreeBSD 10 c++ (clang).
Summary: sh-rtems4.11 build of 4.9.0 fails on FreeBSD 10 c++ (clang).
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.9.0
: P3 normal
Target Milestone: ---
Assignee: Oleg Endo
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-01 09:01 UTC by Chris Johns
Modified: 2014-05-07 19:00 UTC (History)
3 users (show)

See Also:
Host:
Target: sh*-*-*
Build:
Known to work:
Known to fail:
Last reconfirmed: 2014-05-03 00:00:00


Attachments
Fix for gcc 4.8.2 (381 bytes, patch)
2014-05-01 21:45 UTC, Joel Sherrill
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Johns 2014-05-01 09:01:34 UTC
Building gcc-4.9.0 and gcc-4.8.2 for the sh-rtems4.11 on FreeBSD 10 using the standard c++ compiler fails with ...

 [ Note config/sh/sh.c has a comment about this at the top ]

In file included from /usr/include/c++/v1/ostream:133:
/usr/include/c++/v1/locale:444:36: error: attempt to use a poisoned identifier
        __status = (unsigned char*)malloc(__nkw);
                                   ^
/usr/include/c++/v1/locale:1716:28: error: attempt to use a poisoned identifier
        __ob = (char_type*)malloc(2*static_cast<size_t>(__nc)*sizeof(char_type));
                           ^
/usr/include/c++/v1/locale:1785:28: error: attempt to use a poisoned identifier
        __ob = (char_type*)malloc(2*static_cast<size_t>(__nc)*sizeof(char_type));
                           ^
/usr/include/c++/v1/locale:2968:22: error: attempt to use a poisoned identifier
    _Tp* __t = (_Tp*)realloc(__owns ? __b.get() : 0, __new_cap);
                     ^
/usr/include/c++/v1/locale:3228:30: error: attempt to use a poisoned identifier
            __h.reset((char*)malloc(static_cast<size_t>(__wn - __wb.get() + 2)));
                             ^
/usr/include/c++/v1/locale:3527:32: error: attempt to use a poisoned identifier
        __hd.reset((char_type*)malloc(__n * sizeof(char_type)));
                               ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
14 warnings and 20 errors generated.

Configure ...

 ../gcc-4.9.0/configure --prefix=/home/chrisj/development/rtems/4.11 --bindir=/home/chrisj/development/rtems/4.11/bin --exec_prefix=/home/chrisj/development/rtems/4.11 --includedir=/home/chrisj/development/rtems/4.11/include --libdir=/home/chrisj/development/rtems/4.11/lib --libexecdir=/home/chrisj/development/rtems/4.11/libexec --mandir=/home/chrisj/development/rtems/4.11/share/man --infodir=/home/chrisj/development/rtems/4.11/share/info --datadir=/home/chrisj/development/rtems/4.11/share --build=x86_64-freebsd10.0 --host=x86_64-freebsd10.0 --target=sh-rtems4.11 --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose --with-newlib --with-system-zlib --disable-nls --without-included-gettext --disable-win32-registry --enable-version-specific-runtime-libs --disable-lto --enable-newlib-io-c99-formats --enable-newlib-iconv --enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258 --enable-threads --disable-plugin --enable-languages=c,c++

$ uname -a
FreeBSD sync.rtems.org 10.0-STABLE FreeBSD 10.0-STABLE #0 ed891fe(stable/10): Fri Apr 25 18:18:40 UTC 2014     amar@build1.rtems.org:/usr/obj/usr/src/sys/build1  amd64
Comment 1 Jonathan Wakely 2014-05-01 10:21:55 UTC
I think the C++ headers (<sstream>, <vector> and <algorithm>) need to be included before the GCC headers that poison malloc. The actual culprit is <sstream> but there's no guarantee the others don't use malloc.
Comment 2 Joel Sherrill 2014-05-01 21:45:21 UTC
Created attachment 32721 [details]
Fix for gcc 4.8.2
Comment 3 Oleg Endo 2014-05-03 07:51:34 UTC
Author: olegendo
Date: Sat May  3 07:51:02 2014
New Revision: 210028

URL: http://gcc.gnu.org/viewcvs?rev=210028&root=gcc&view=rev
Log:
	PR target/61026
	* config/sh/sh.c: Include stdlib headers before everything else.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/sh/sh.c
Comment 4 Oleg Endo 2014-05-03 08:18:14 UTC
Author: olegendo
Date: Sat May  3 08:17:43 2014
New Revision: 210029

URL: http://gcc.gnu.org/viewcvs?rev=210029&root=gcc&view=rev
Log:
	Back port from mainline
	PR target/61026
	* config/sh/sh.c: Include stdlib headers before everything else.


Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/config/sh/sh.c
Comment 5 Oleg Endo 2014-05-03 08:21:55 UTC
Author: olegendo
Date: Sat May  3 08:21:24 2014
New Revision: 210030

URL: http://gcc.gnu.org/viewcvs?rev=210030&root=gcc&view=rev
Log:
	Back port from mainline
	PR target/61026
	* config/sh/sh.c: Include stdlib headers before everything else.


Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/config/sh/sh.c
Comment 6 Oleg Endo 2014-05-03 08:25:21 UTC
Fixed on trunk, 4.9 and 4.8.
Comment 7 Jan-Benedict Glaw 2014-05-05 11:08:50 UTC
I'm not 100% sure, but I guess this fix breaks building GCC on gcc111.fsffrance.org .  All build details can be found here: http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=218196


The actual error message is:

g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc -I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include -I/home/jbglaw/repos/gcc/gcc/../libcpp/include -I/opt/cfarm/gmp-latest/include -I/opt/cfarm/mpfr-latest/include -I/opt/cfarm/mpc-latest/include  -I/home/jbglaw/repos/gcc/gcc/../libdecnumber -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/jbglaw/repos/gcc/gcc/../libbacktrace    -o sh.o -MT sh.o -MMD -MP -MF ./.deps/sh.TPo /home/jbglaw/repos/gcc/gcc/config/sh/sh.c
In file included from /home/jbglaw/repos/gcc/gcc/system.h:262:0,
                 from /home/jbglaw/repos/gcc/gcc/config/sh/sh.c:27:
/usr/include/unistd.h:201:41: error: declaration of C function 'off64_t lseek64(int, off64_t, int)' conflicts with
 extern off64_t lseek64(int, off64_t, int);
                                         ^
/usr/include/unistd.h:199:14: error: previous declaration 'off_t lseek64(int, off_t, int)' here
 extern off_t lseek(int, off_t, int);
              ^
In file included from /usr/include/unistd.h:844:0,
                 from /home/jbglaw/repos/gcc/gcc/system.h:262,
                 from /home/jbglaw/repos/gcc/gcc/config/sh/sh.c:27:
/usr/include/sys/lockf.h:64:39: error: declaration of C function 'int lockf64(int, int, off64_t)' conflicts with
  extern int lockf64 (int, int, off64_t);
                                       ^
/usr/include/sys/lockf.h:62:13: error: previous declaration 'int lockf64(int, int, off_t)' here
  extern int lockf (int, int, off_t);
             ^
In file included from /home/jbglaw/repos/gcc/gcc/system.h:262:0,
                 from /home/jbglaw/repos/gcc/gcc/config/sh/sh.c:27:
/usr/include/unistd.h:917:38: error: declaration of C function 'int ftruncate64(int, off64_t)' conflicts with
  extern int  ftruncate64(int, off64_t);
                                      ^
In file included from /home/jbglaw/repos/gcc/gcc/system.h:262:0,
                 from /home/jbglaw/repos/gcc/gcc/config/sh/sh.c:27:
/usr/include/unistd.h:915:14: error: previous declaration 'int ftruncate64(int, off_t)' here
  extern int  ftruncate(int, off_t);
              ^
In file included from /home/jbglaw/repos/gcc/gcc/system.h:262:0,
                 from /home/jbglaw/repos/gcc/gcc/config/sh/sh.c:27:
/usr/include/unistd.h:974:46: error: declaration of C function 'int truncate64(const char*, off64_t)' conflicts with
  extern int  truncate64(const char *, off64_t);
                                              ^
In file included from /home/jbglaw/repos/gcc/gcc/system.h:262:0,
                 from /home/jbglaw/repos/gcc/gcc/config/sh/sh.c:27:
/usr/include/unistd.h:972:14: error: previous declaration 'int truncate64(const char*, off_t)' here
  extern int  truncate(const char *, off_t);
              ^
In file included from /home/jbglaw/repos/gcc/gcc/system.h:262:0,
                 from /home/jbglaw/repos/gcc/gcc/config/sh/sh.c:27:
/usr/include/unistd.h:993:54: error: declaration of C function 'ssize_t pread64(int, void*, size_t, off64_t)' conflicts with
  extern ssize_t  pread64(int, void *, size_t, off64_t);
                                                      ^
/usr/include/unistd.h:990:18: error: previous declaration 'ssize_t pread64(int, void*, size_t, off_t)' here
  extern ssize_t  pread(int, void *, size_t, off_t);
                  ^
/usr/include/unistd.h:994:61: error: declaration of C function 'ssize_t pwrite64(int, const void*, size_t, off64_t)' conflicts with
  extern ssize_t  pwrite64(int, const void *, size_t, off64_t);
                                                             ^
/usr/include/unistd.h:991:18: error: previous declaration 'ssize_t pwrite64(int, const void*, size_t, off_t)' here
  extern ssize_t  pwrite(int, const void *, size_t, off_t);
                  ^
/usr/include/unistd.h:1079:38: error: declaration of C function 'off64_t fclear64(int, off64_t)' conflicts with
  extern off64_t fclear64(int, off64_t);
                                      ^
/usr/include/unistd.h:1076:15: error: previous declaration 'off_t fclear64(int, off_t)' here
  extern off_t fclear(int, off_t);
               ^
/usr/include/unistd.h:1080:53: error: declaration of C function 'int fsync_range64(int, int, off64_t, off64_t)' conflicts with
  extern int fsync_range64(int, int, off64_t, off64_t);
                                                     ^
/usr/include/unistd.h:1077:13: error: previous declaration 'int fsync_range64(int, int, off_t, off_t)' here
  extern int fsync_range(int, int, off_t, off_t);
             ^
In file included from /home/jbglaw/repos/gcc/gcc/system.h:389:0,
                 from /home/jbglaw/repos/gcc/gcc/config/sh/sh.c:27:
/usr/include/sys/mman.h:148:60: error: declaration of C function 'void* mmap64(void*, size_t, int, int, int, off64_t)' conflicts with
  extern void *mmap64(void *, size_t, int, int, int, off64_t);
                                                            ^
/usr/include/sys/mman.h:143:15: error: previous declaration 'void* mmap64(void*, size_t, int, int, int, off_t)' here
  extern void *mmap(void *, size_t, int, int, int, off_t);
               ^
make[1]: *** [sh.o] Error 1




However, looking at other recent builds (http://toolchain.lug-owl.de/buildbot/?limit=10000&target=sh-linux), it seems that eg. gcc110 happily builds this, so this might be a local installation issue.
Comment 8 Oleg Endo 2014-05-05 11:32:28 UTC
(In reply to Jan-Benedict Glaw from comment #7)
> I'm not 100% sure, but I guess this fix breaks building GCC on
> gcc111.fsffrance.org .  All build details can be found here:
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=218196


Looks like an include order problem of C system includes and C++ stdlib includes, probably caused by specific clib / C++ stdlib versions or combinations on the system.

Could you please try to add an

#include <unistd.h>

before the C++ includes and see if it resolves some of the errors/changes anything?  It's probably not going to be the final fix for the problem, but might give some clues.
Comment 9 Jan-Benedict Glaw 2014-05-05 11:47:42 UTC
> Could you please try to add an
> 
> #include <unistd.h>
> 
> before the C++ includes and see if it resolves some of the errors/changes
> anything?  It's probably not going to be the final fix for the problem, but
> might give some clues.

I've added it there, though it might take a while until that target is built again on that host. (Just for the notes: The host is AIX 7 on PPC, using GCC, thus it's not the somewhat more usual Linux-based building...)
Comment 10 Oleg Endo 2014-05-07 19:00:57 UTC
Sorry for the trouble, but Joseph has a point here ...
http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00414.html

Could you guys please try moving the problematic header includes in sh.c below the #include "config.h" and report your findings?  Thanks.