gcc-4.7.1 build system question : why is "make bootstrap" with configure option '--enable-languages=c' building the C++ compiler ?
Hi - I've been regularly building gcc for nearly two decades, and now attempting to build a bootstrap "C" only gcc-4.7.1 sufficient only to build binutils (my initial first step is always to rebuild binutils with the bootstrap "C" only compiler before doing a complete "make" with "--enable-languages=all" - a shame that support for configuring and building binutils along with gcc has been withdrawn , so now I attempt to rebuild binutils separately with the "C" only bootstrap compiler) . Now this doesn't work - building "C"-only ( --enable-languages=c ) bootstrap fails building "C++" : /mnt/sda3/gcc/./prev-gcc/g++ -B/mnt/sda3/gcc/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/usr/build2/gcc/gcc-4.7.1/libstdc++-v3/libsupc++ -L/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o cc1 c-lang.o c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o i386-c.o default-c.o \ cc1-checksum.o main.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lcloog -lppl_c -lppl -lpwl -lgmpxx -lmpc -lmpfr -lgmp -rdynamic -ldl -lz lto/lto.o: In function `lto_ft_typed(tree_node*)': lto.c:(.text+0x326): undefined reference to `tree_code_type' lto/lto.o: In function `lto_ft_common(tree_node*)': lto.c:(.text+0x38b): undefined reference to `tree_code_type' lto/lto.o: In function `lto_ft_decl_common(tree_node*)': lto.c:(.text+0x3fb): undefined reference to `tree_code_type' lto.c:(.text+0x432): undefined reference to `tree_code_type' lto.c:(.text+0x469): undefined reference to `tree_code_type' lto/lto.o:lto.c:(.text+0x49e): more undefined references to `tree_code_type' follow Boy, does it really mean it when it says "more undefined references to `tree_code_type' follow" : $ grep 'undefined reference' make.bootstrap-cntnd.log | wc -l 18127 My config.log command : generated by GNU Autoconf 2.64. Invocation command line was $ /usr/build2/gcc/gcc-4.7.1/configure --prefix=/usr --libdir=/usr/lib64 --with-cpu-32=i686 --with-cpu-64=k8 --enable-languages=c --enable-targets=all --enable-multi lib --enable-threads=posix --enable-tls --enable-lto --enable-shared --enable-checking=release --with-build-time-tools=/usr/bin --with-ld=/usr/bin/ld --with-gnu-ld -- with-as=/usr/bin/as --with-gnu-as --enable-version-specific-runtime-libs --with-system-zlib --without-included-gettext --enable-bootstrap --enable-serial-configure -- host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu ## - ## ## Platform. ## ## - ## hostname = jvdspc uname -m = x86_64 uname -r = 3.4.4-jvd+ uname -s = Linux uname -v = #4 SMP Fri Jul 6 20:19:44 GMT 2012 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = x86_64 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown I configured with above command and did: $ make -j2 bootstrap 2>&1 | tee make.bootstrap.log This built fine overnight , and when I woke up in the morning the machine was in a hard lock-up state (overheating - I'm also investigating a kernel bug on this issue). The build had created the "stage_final" file and a working prev-gcc/xgcc - Can anyone suggest why making a "bootstrap" "C" "--enable-languages=c" compiler should then go on to build "C++" ? I'm pretty sure the above error would not have occurred without the kernel lock-up and interruption, but nevertheless, I didn't ask the gcc build system to build C++ yet, so why did it do so ? Any ideas / comments would be much appreciated , Jason Vas Dias (a Software Engineer)
Re: gcc-4.7.1 build system question : why is "make bootstrap" with configure option '--enable-languages=c' building the C++ compiler ?
OK, so I'm reconfiguring with : --enable-languages=c --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-stage1-checking=all --enable-stage1-languages=c but why should I have to ? Shouldn't "--enable-languages=c" be enough to disable building the C++ compiler and libstdc++ ? Thanks & Regards, Jason On Sun, Jul 8, 2012 at 4:06 PM, Jason Vas Dias wrote: > Hi - I've been regularly building gcc for nearly two decades, and now > attempting to build a bootstrap > "C" only gcc-4.7.1 sufficient only to build binutils (my initial first > step is always to rebuild binutils > with the bootstrap "C" only compiler before doing a complete "make" > with "--enable-languages=all" - > a shame that support for configuring and building binutils along with > gcc has been withdrawn , > so now I attempt to rebuild binutils separately with the "C" only > bootstrap compiler) . > > Now this doesn't work - building "C"-only ( --enable-languages=c ) > bootstrap fails building "C++" : > > /mnt/sda3/gcc/./prev-gcc/g++ -B/mnt/sda3/gcc/./prev-gcc/ > -B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++ > -B/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs > -B/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs > -I/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu > -I/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/include > -I/usr/build2/gcc/gcc-4.7.1/libstdc++-v3/libsupc++ > -L/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs > -L/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs > -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -W -Wall > -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute > -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings > -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o cc1 c-lang.o > c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o > c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o > c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o > c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o > c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o > c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o > c-family/c-semantics.o c-family/c-ada-spec.o i386-c.o default-c.o \ > cc1-checksum.o main.o libbackend.a libcommon-target.a libcommon.a > ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a > ../libcpp/libcpp.a ../libiberty/libiberty.a > ../libdecnumber/libdecnumber.a -lcloog -lppl_c -lppl -lpwl -lgmpxx > -lmpc -lmpfr -lgmp -rdynamic -ldl -lz > lto/lto.o: In function `lto_ft_typed(tree_node*)': > lto.c:(.text+0x326): undefined reference to `tree_code_type' > lto/lto.o: In function `lto_ft_common(tree_node*)': > lto.c:(.text+0x38b): undefined reference to `tree_code_type' > lto/lto.o: In function `lto_ft_decl_common(tree_node*)': > lto.c:(.text+0x3fb): undefined reference to `tree_code_type' > lto.c:(.text+0x432): undefined reference to `tree_code_type' > lto.c:(.text+0x469): undefined reference to `tree_code_type' > lto/lto.o:lto.c:(.text+0x49e): more undefined references to > `tree_code_type' follow > > Boy, does it really mean it when it says "more undefined references to > `tree_code_type' follow" : > > $ grep 'undefined reference' make.bootstrap-cntnd.log | wc -l > 18127 > > My config.log command : > > > generated by GNU Autoconf 2.64. Invocation command line was > > $ /usr/build2/gcc/gcc-4.7.1/configure --prefix=/usr > --libdir=/usr/lib64 --with-cpu-32=i686 --with-cpu-64=k8 > --enable-languages=c --enable-targets=all --enable-multi > lib --enable-threads=posix --enable-tls --enable-lto --enable-shared > --enable-checking=release --with-build-time-tools=/usr/bin > --with-ld=/usr/bin/ld --with-gnu-ld -- > with-as=/usr/bin/as --with-gnu-as > --enable-version-specific-runtime-libs --with-system-zlib > --without-included-gettext --enable-bootstrap > --enable-serial-configure -- > host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu > > ## - ## > ## Platform. ## > ## - ## > > hostname = jvdspc > uname -m = x86_64 > uname -r = 3.4.4-jvd+ > uname -s = Linux > uname -v = #4 SMP Fri Jul 6 20:19:44 GMT 2012 > > /usr/bin/uname -p = unknown > /bin/uname -X = unknown > > /bin/arch = x86_64 > /usr/bin/arch -k = unknown > /usr/convex/getsysinfo = unknown > /usr/bin/hostinfo = unknown > /bin/machine = unknown > /usr/bin/oslevel = unknown > /bin/universe = unknown > > I config
bug ? : -Wpedantic -Wconversion 'short a=1; a-=1;' complaint
I really do not think a '-Wpedantic -Wconversion' warning should
be generated for the following code, but it is
(with GCC 6.4.1 and 7.3.1 on RHEL-7.5 Linux) :
$ echo '
typedef unsigned short U16_t;
static void f(void)
{ U16_t a = 1;
a-=1;
}' > t.C;
$ g++ -std=c++14 -Wall -Wextra -pedantic -Wc++11-compat \
-Wconversion -Wcast-align -Wcast-qual -Wfloat-equal \
-Wmissing-declarations -Wlogical-op -Wpacked -Wundef \
-Wuninitialized -Wvariadic-macros -Wwrite-strings \
-c t.C -o /dev/null
t.C:4:8: conversion to 'U16_t' {aka short unsigned int} from 'int' may \
alter its value.
I don't control the warning flags, as shown above,
that my code must compile against without warnings.
But I think the warning issued above is a GCC bug -
when I look at the code generated, (compile with -S -o t.S),
I see it actually does generate a 16-bit subtraction, which
is what I wanted:
.file "t.C"
.text
.globl _Z1fv
.type _Z1fv, @function
_Z1fv:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movw$1, -2(%rbp)
subw$1, -2(%rbp)
# this is a two-byte word subtract
nop
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size _Z1fv, .-_Z1fv
.ident "GCC: (GNU) 6.4.1 20180321"
.section.note.GNU-stack,"",@progbits
So why is it generating a warning about conversion from 'int' ?
I don't see any conversion going on in assembler output -
(cast 'a' to a temporary int, do 32-bit integer subtraction of '1'
from it, and store sign-extended low 16 bits in 'a' - this is NOT
what is going on here ) .
I'd like to remove either '-pedantic' or '-Wconversion' from the
warning flags, but this is not an option .
Please can GCC fix this warning bug eventually - I have to wade
through code that generates thousands of them per compilation.
Thanks & Best Regards,
Jason
Re: bug ? : -Wpedantic -Wconversion 'short a=1; a-=1;' complaint
Great thanks for your informative response, Jim! :
RE:
On 23/04/2018, Jim Wilson wrote:
> On 04/23/2018 07:11 AM, Jason Vas Dias wrote:
>>
>> I really do not think a '-Wpedantic -Wconversion' warning should
>> be generated for the following code, but it is
>> (with GCC 6.4.1 and 7.3.1 on RHEL-7.5 Linux) :
>>
>> $ echo '
>> typedef unsigned short U16_t;
>> static void f(void)
>> { U16_t a = 1;
>> a-=1;
>> }' > t.C;
>
> g...@gcc.gnu.org dropped as inappropriate. Note that gcc-bugs is output
> from our bugzilla. Sending email here isn't very useful. If you want a
> bug fixed, you have to open a bug report in bugzilla. You can ask gcc
> questions on gcc help.
>
> In the C language, operations on short and always performed as int, and
> then converted back to short. Subtracting one may generated a negative
> number, which converted to unsigned short will change its value. So the
> warning seems appropriate.
>
> Note that -Wconversion means different things in different gcc versions.
> It current meaning is to warn for any implicit cast that may change a
> value. This is not very useful in general, and is not an option that I
> would recommend using by default. In old gcc versions, -Wconversion
> warned for code that had different meaning in K&R C and ISO C. That was
> useful, and some people used that option by default, but the option no
> longer does that.
>
> You can silence the warning by adding an explicit cast.
> a = (U16_t) (a - 1);
>
> Jim
>
But I still think, in modern GCC, the behaviour of this warning option is a bug.
When I look at the code generated for the above example, I can see
the compiler is actually generating 16-bit operations:
$ gcc -std=c11 -Wall -Wextra -pedantic -Wconversion -S -o u16.s u16.c
u16.c: In function ‘f’:
u16.c:9:6: warning: conversion to ‘U16_t {aka short unsigned int}’
from ‘int’ may alter its value [-Wconversion]
v-=1;
^
But looking at the assembler generated :
movw$1, -2(%rbp)
subw$1, -2(%rbp)
we see that on x86_64 at least, the compiler is actually generating
16-bit operations on two-byte values.
I can understand that on architectures such as ARM , it might be
appropriate to generate the warning, because on that platform,
a 32-bit operation may actually be generated for the code.
But if no 32-bit operation is being generated, why issue the warning?
So it is not the case that
> In the C language, operations on short are always performed as int, and
> then converted back to short .
That may have been true with ANSI C90, but not with more recent versions
of the C language; surely GCC should know what standard & CPU it is generating
code for, and emit appropriate warnings for that standard and CPU ?
And your suggested fix illustrates my point about the warning encouraging
unnecessary casts:
> You can silence the warning by adding an explicit cast.
> a = (U16_t) (a - 1);
Actually, in this case, gcc is clever enough to realize that a cast is
not required,
and actually generates identical code with or without the cast:
movw$1, -2(%rbp)
subw$1, -2(%rbp)
But C++ programmers are encouraged to look at any C-style "(X)y" cast as
"Create an anonymous Temporary to hold y cast to type X " .
Even though that is not what is going on here, I think the warning does
not help programmers understand what code is being generated
(the 16-bit operations) and incorrectly makes them think a 32-bit
temporary is being generated.
So I think that '-Wconversion' should have no effect if '-pedantic'
is in effect,
because that combination produces erroneous and misleading warnings .
Thanks & Best Regards,
Jason
