Bug 61164 - GCC 4.9.0 fails to build libitm when fortification enabled
Summary: GCC 4.9.0 fails to build libitm when fortification enabled
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.9.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2014-05-13 04:44 UTC by Ryan Hill
Modified: 2018-11-06 18:31 UTC (History)
2 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Hill 2014-05-13 04:44:09 UTC
We enable -D_FORTIFY_SOURCE=2 by default, but with 4.9.0 we're encountering an error while building libitm.  It can be reproduced without modifying the compiler by configuring with:

CXXFLAGS="-O2 -g -D_FORTIFY_SOURCE=2" ../dist/gcc/gcc-4.9.0/configure --enable-languages=c,c++ --disable-werror --disable-bootstrap

The error is:

libtool: compile:  /home/dirtyepic/build/./gcc/xg++ -B/home/dirtyepic/build/./gcc/ -nostdinc++ -nostdinc++ -I/home/dirtyepic/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/dirtyepic/build/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/dirtyepic/dist/gcc/gcc-4.9.0/libstdc++-v3/libsupc++ -I/home/dirtyepic/dist/gcc/gcc-4.9.0/libstdc++-v3/include/backward -I/home/dirtyepic/dist/gcc/gcc-4.9.0/libstdc++-v3/testsuite/util -L/home/dirtyepic/build/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/home/dirtyepic/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/dirtyepic/build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../dist/gcc/gcc-4.9.0/libitm -I../../../dist/gcc/gcc-4.9.0/libitm/config/linux/x86 -I../../../dist/gcc/gcc-4.9.0/libitm/config/linux -I../../../dist/gcc/gcc-4.9.0/libitm/config/x86 -I../../../dist/gcc/gcc-4.9.0/libitm/config/posix -I../../../dist/gcc/gcc-4.9.0/libitm/config/generic -I../../../dist/gcc/gcc-4.9.0/libitm -mrtm -Wall -pthread -Werror -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -O2 -g -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -MT util.lo -MD -MP -MF .deps/util.Tpo -c ../../../dist/gcc/gcc-4.9.0/libitm/util.cc  -fPIC -DPIC -o .libs/util.o

In file included from /usr/include/stdio.h:937:0,
                 from ../../../dist/gcc/gcc-4.9.0/libitm/util.cc:27:
/usr/include/bits/stdio2.h: In function ‘void GTM::gtm_verror(const char*, __va_list_tag*)’:
/usr/include/bits/stdio2.h:124:1: error: inlining failed in call to always_inline ‘int vfprintf(FILE*, const char*, __va_list_tag*)’: function body can be overwritten at link time
 vfprintf (FILE *__restrict __stream,
../../../dist/gcc/gcc-4.9.0/libitm/util.cc:35:31: error: called from here
   vfprintf (stderr, fmt, list);

Comparing the preprocessor output for util.cc and a couple other C++ files that use vfprintf the most obvious difference is the declaration is missing __inline, ie.

extern __attribute__((always_inline)) __attribute__ ((__gnu_inline__)) __attribute__ ((__artificial__)) int vfprintf

instead of

extern __inline __attribute__ ((__always_inline__)) __attribute__ ((__gnu_inline__)) __attribute__ ((__artificial__)) int vfprintf
Comment 1 Ilya Palachev 2014-06-25 10:59:04 UTC
I have the same build error.

The build error is reproduced with Linaro GCC 4.9 2014.06 release.

Also switching off -D_FORTIFY_SOURCE=2 helps.
Comment 2 Gleb Fotengauer-Malinovskiy 2014-09-27 14:04:55 UTC
Patch: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02460.html
Comment 3 Gleb Fotengauer-Malinovskiy 2014-09-27 18:26:12 UTC

Sorry, previous patch is incomplete.
Comment 4 Gleb Fotengauer-Malinovskiy 2015-08-24 17:49:18 UTC
Seems to be fixed with:
Comment 5 Mike Frysinger 2016-01-12 16:02:17 UTC
assuming that fixes things (for gcc-6).  will re-open if it doesn't.
Comment 6 Romain Naour 2018-11-05 21:39:23 UTC

This issue has been reported recently on gcc 5.5.0 [1]
Is it safe to backport the patch to gcc 4.9 and 5.5.0?

Best regards,

[1] https://bugs.busybox.net/show_bug.cgi?id=11476
Comment 7 Martin Sebor 2018-11-06 18:31:26 UTC
(In reply to Romain Naour from comment #6)

GCC 4 and 5 (and even 6) branches are no longer being maintained so the changes cannot be backported to them.