* [BUILDROBOT][PATCH] Fix mmix (unused variable) @ 2014-07-18 5:04 Jan-Benedict Glaw 2014-07-18 8:08 ` Hans-Peter Nilsson 0 siblings, 1 reply; 18+ messages in thread From: Jan-Benedict Glaw @ 2014-07-18 5:04 UTC (permalink / raw) To: gcc-patches; +Cc: Richard Biener, Hans-Peter Nilsson [-- Attachment #1: Type: text/plain, Size: 1867 bytes --] Hi! As a leftover of r210931, an unused variable resulted in: 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 -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace -o mmix.o -MT mmix.o -MMD -MP -MF ./.deps/mmix.TPo ../../../gcc/gcc/config/mmix/mmix.c ../../../gcc/gcc/config/mmix/mmix.c: In function ‘int64_t mmix_intval(const_rtx)’: ../../../gcc/gcc/config/mmix/mmix.c:2694:12: error: unused variable ‘retval’ [-Werror=unused-variable] uint64_t retval; ^ cc1plus: all warnings being treated as errors make[2]: *** [mmix.o] Error 1 (See eg. http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=305352) Committed as obvious, fixed like this: 2014-07-18 Jan-Benedict Glaw <jbglaw@lug-owl.de> * config/mmix/mmix.c (mmix_intval): Drop unused automatic variable. diff --git a/gcc/config/mmix/mmix.c b/gcc/config/mmix/mmix.c index e0b8ce7..b9edc3c 100644 --- a/gcc/config/mmix/mmix.c +++ b/gcc/config/mmix/mmix.c @@ -2691,8 +2691,6 @@ mmix_output_condition (FILE *stream, const_rtx x, int reversed) int64_t mmix_intval (const_rtx x) { - uint64_t retval; - if (GET_CODE (x) == CONST_INT) return INTVAL (x); -- Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481 Signature of: Zensur im Internet? Nein danke! the second : [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [BUILDROBOT][PATCH] Fix mmix (unused variable) 2014-07-18 5:04 [BUILDROBOT][PATCH] Fix mmix (unused variable) Jan-Benedict Glaw @ 2014-07-18 8:08 ` Hans-Peter Nilsson 2014-07-18 13:11 ` Jan-Benedict Glaw 0 siblings, 1 reply; 18+ messages in thread From: Hans-Peter Nilsson @ 2014-07-18 8:08 UTC (permalink / raw) To: Jan-Benedict Glaw; +Cc: gcc-patches, Richard Biener On Fri, 18 Jul 2014, Jan-Benedict Glaw wrote: > Hi! > > As a leftover of r210931, an unused variable resulted in: > > 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 -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace -o mmix.o -MT mmix.o -MMD -MP -MF ./.deps/mmix.TPo ../../../gcc/gcc/config/mmix/mmix.c > ../../../gcc/gcc/config/mmix/mmix.c: In function ?int64_t mmix_intval(const_rtx)?: > ../../../gcc/gcc/config/mmix/mmix.c:2694:12: error: unused variable ?retval? [-Werror=unused-variable] > uint64_t retval; > ^ > cc1plus: all warnings being treated as errors Weird that I haven't seen this with a host g++ >= 4.7 (4.7.2-2); I've certainly built post-r210931 (post-2014-05-26) for example r212486, but obviously so, thanks. I see the warning in my logs but -Werror wasn't isn't used and I didn't pay attention. Did something change more recently re: building with -Werror? brgds, H-P ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [BUILDROBOT][PATCH] Fix mmix (unused variable) 2014-07-18 8:08 ` Hans-Peter Nilsson @ 2014-07-18 13:11 ` Jan-Benedict Glaw 2014-07-19 6:42 ` Hans-Peter Nilsson 0 siblings, 1 reply; 18+ messages in thread From: Jan-Benedict Glaw @ 2014-07-18 13:11 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: gcc-patches, Richard Biener [-- Attachment #1: Type: text/plain, Size: 2250 bytes --] On Fri, 2014-07-18 03:10:09 -0400, Hans-Peter Nilsson <hp@bitrange.com> wrote: > On Fri, 18 Jul 2014, Jan-Benedict Glaw wrote: > > As a leftover of r210931, an unused variable resulted in: > > > > 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 -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace -o mmix.o -MT mmix.o -MMD -MP -MF ./.deps/mmix.TPo ../../../gcc/gcc/config/mmix/mmix.c > > ../../../gcc/gcc/config/mmix/mmix.c: In function ?int64_t mmix_intval(const_rtx)?: > > ../../../gcc/gcc/config/mmix/mmix.c:2694:12: error: unused variable ?retval? [-Werror=unused-variable] > > uint64_t retval; > > ^ > > cc1plus: all warnings being treated as errors > > Weird that I haven't seen this with a host g++ >= 4.7 (4.7.2-2); > I've certainly built post-r210931 (post-2014-05-26) for example > r212486, but obviously so, thanks. > > I see the warning in my logs but -Werror wasn't isn't used and I > didn't pay attention. Did something change more recently re: > building with -Werror? This was a build using GCC's ./contrib/config-list.mk to do the build. It passes --enable-werror-always to top-level `configure', this is where the -Werror comes from. MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481 Signature of: 17:45 <@Eimann> Hrm, das E90 hat keinen Lebenszeit Call-Time Counter mehr the second : 17:46 <@jbglaw> Eimann: Wofür braucht man das? 17:46 <@jbglaw> Eimann: Für mich ist an 'nem Handy wichtig, daß ich mein Gegeüber hören kann. Und daß mein Gegenüber mich versteht... 17:47 <@KrisK> jbglaw: was du meinst ist wodka. 17:47 <@KrisK> jbglaw: es klingelt und man hört stimmen [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [BUILDROBOT][PATCH] Fix mmix (unused variable) 2014-07-18 13:11 ` Jan-Benedict Glaw @ 2014-07-19 6:42 ` Hans-Peter Nilsson 2014-07-19 17:27 ` Jan-Benedict Glaw 2014-07-22 13:01 ` Richard Biener 0 siblings, 2 replies; 18+ messages in thread From: Hans-Peter Nilsson @ 2014-07-19 6:42 UTC (permalink / raw) To: Jan-Benedict Glaw; +Cc: gcc-patches, Richard Biener On Fri, 18 Jul 2014, Jan-Benedict Glaw wrote: > This was a build using GCC's ./contrib/config-list.mk to do the build. > It passes --enable-werror-always to top-level `configure', this is > where the -Werror comes from. Aha. Looks like it's of more use than theoretical pain; sounds like this should (effectively) be the default for *non-releases* when cross-compiling, with the possibility to override per-target. Agreement? Anyone against? 1/2 :) It should be per-target because there *may* be port-specific constructs warned about by buggy previous-but-not-ancient gcc-versions, where working around the warnings would cause unwanted obfuscation. (IIRC gdb does something like this.) Is that the reason it's not the default, that there are such constructs in the non-port-specific parts? But then that would have already been noticed through use of the config-list.mk, no? brgds, H-P ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [BUILDROBOT][PATCH] Fix mmix (unused variable) 2014-07-19 6:42 ` Hans-Peter Nilsson @ 2014-07-19 17:27 ` Jan-Benedict Glaw 2014-07-22 13:01 ` Richard Biener 1 sibling, 0 replies; 18+ messages in thread From: Jan-Benedict Glaw @ 2014-07-19 17:27 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: gcc-patches, Richard Biener [-- Attachment #1: Type: text/plain, Size: 2771 bytes --] On Fri, 2014-07-18 20:36:20 -0400, Hans-Peter Nilsson <hp@bitrange.com> wrote: > On Fri, 18 Jul 2014, Jan-Benedict Glaw wrote: > > This was a build using GCC's ./contrib/config-list.mk to do the build. > > It passes --enable-werror-always to top-level `configure', this is > > where the -Werror comes from. > > Aha. Looks like it's of more use than theoretical pain; sounds > like this should (effectively) be the default for *non-releases* > when cross-compiling, with the possibility to override > per-target. Agreement? Anyone against? 1/2 :) I'm all for it. > It should be per-target because there *may* be port-specific > constructs warned about by buggy previous-but-not-ancient > gcc-versions, where working around the warnings would cause > unwanted obfuscation. (IIRC gdb does something like this.) For example, the PDP11 target has an unresoved warning: http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=306062 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 -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace -o cfgexpand.o -MT cfgexpand.o -MMD -MP -MF ./.deps/cfgexpand.TPo ../../../gcc/gcc/cfgexpand.c ../../../gcc/gcc/cfgexpand.c: In function ‘basic_block_def* expand_gimple_cond(basic_block, gimple)’: ../../../gcc/gcc/cfgexpand.c:2100:65: error: comparison is always true due to limited range of data type [-Werror=type-limits] else if (BRANCH_COST (optimize_insn_for_speed_p (), false) < 4) ^ cc1plus: all warnings being treated as errors make[2]: *** [cfgexpand.o] Error 1 ISTR that I brought this up on the list, but there wasn't a final solution about how to "fix" that; the warning is kind of questionable in this context, but in itself is correct. > Is that the reason it's not the default, that there are such > constructs in the non-port-specific parts? But then that would > have already been noticed through use of the config-list.mk, no? Don't know :) MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481 Signature of: What we do for ourselves dies with us. What we do for the second : others and the world remains and is immortal. (Albert Pine) [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [BUILDROBOT][PATCH] Fix mmix (unused variable) 2014-07-19 6:42 ` Hans-Peter Nilsson 2014-07-19 17:27 ` Jan-Benedict Glaw @ 2014-07-22 13:01 ` Richard Biener 2014-07-22 20:49 ` werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)) Hans-Peter Nilsson 1 sibling, 1 reply; 18+ messages in thread From: Richard Biener @ 2014-07-22 13:01 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: Jan-Benedict Glaw, gcc-patches On Fri, 18 Jul 2014, Hans-Peter Nilsson wrote: > On Fri, 18 Jul 2014, Jan-Benedict Glaw wrote: > > This was a build using GCC's ./contrib/config-list.mk to do the build. > > It passes --enable-werror-always to top-level `configure', this is > > where the -Werror comes from. > > Aha. Looks like it's of more use than theoretical pain; sounds > like this should (effectively) be the default for *non-releases* > when cross-compiling, with the possibility to override > per-target. Agreement? Anyone against? 1/2 :) > > It should be per-target because there *may* be port-specific > constructs warned about by buggy previous-but-not-ancient > gcc-versions, where working around the warnings would cause > unwanted obfuscation. (IIRC gdb does something like this.) > > Is that the reason it's not the default, that there are such > constructs in the non-port-specific parts? But then that would > have already been noticed through use of the config-list.mk, no? The reason it's not the default is because the warnings are coming from the host compiler which may be fairly old or even broken. If we want it to make the default the we should restrict it based on the host compiler (version). Richard. ^ permalink raw reply [flat|nested] 18+ messages in thread
* werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)) 2014-07-22 13:01 ` Richard Biener @ 2014-07-22 20:49 ` Hans-Peter Nilsson 2014-07-22 22:12 ` werror fallout for cross-builds Andreas Schwab ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Hans-Peter Nilsson @ 2014-07-22 20:49 UTC (permalink / raw) To: Richard Biener; +Cc: Jan-Benedict Glaw, gcc-patches On Tue, 22 Jul 2014, Richard Biener wrote: > On Fri, 18 Jul 2014, Hans-Peter Nilsson wrote: > > > On Fri, 18 Jul 2014, Jan-Benedict Glaw wrote: > > It should be per-target because there *may* be port-specific > > constructs warned about by buggy previous-but-not-ancient > > gcc-versions, where working around the warnings would cause > > unwanted obfuscation. (IIRC gdb does something like this.) > > > > Is that the reason it's not the default, that there are such > > constructs in the non-port-specific parts? But then that would > > have already been noticed through use of the config-list.mk, no? > > The reason it's not the default is because the warnings are coming > from the host compiler which may be fairly old or even broken. But that's the *general* reason -Werror is not always on, so I'm inclined to think that reply implies "and no-one has bothered to look into making an exception for non-release cross-builds". *Developers* (or rather, people cross-building non-released gcc source in their usual setup) don't use the fairly old or even broken host gcc versions that can be expected in use in the general public (well, the users that still want to build gcc from releases and not use pre-built binaries). > If we want it to make the default the we should restrict it > based on the host compiler (version). My point is that it's unnecessary; we should just enable it always *for cross-builds only* (native cases will see it for stage 2 anyway) and deal with the fallout. Bringing the non-fatal errors out in the open has value above the trouble dealing with any breakage. Also, exceptions should be simple to do per-target for the reasons mentions. (Actually, I ended up enabling both as the version checking was already there.) But, the above was written under the assumption that most targets *do* build these days with --enable-werror-always for most non-ancient gcc (say, 4.4 and up), but I no longer think that's the case after testing the patch. In the name of "dealing with the fallout": with the patch below (don't forget to re-generate configure) I get build errors in generic code r212915 for *both* x86_64 "gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC)" for mmix-knuth-mmixware: 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 -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I/home/hp/gcctop/tmp/mbase13/gcc/gcc -I/home/hp/gcctop/tmp/mbase13/gcc/gcc/. -I/home/hp/gcctop/tmp/mbase13/gcc/gcc/../include -I/home/hp/gcctop/tmp/mbase13/gcc/gcc/../libcpp/include -I/home/hp/gcctop/tmp/mbase13/gcc/gcc/../libdecnumber -I/home/hp/gcctop/tmp/mbase13/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/hp/gcctop/tmp/mbase13/gcc/gcc/../libbacktrace -o dwarf2out.o -MT dwarf2out.o -MMD -MP -MF ./.deps/dwarf2out.TPo /home/hp/gcctop/tmp/mbase13/gcc/gcc/dwarf2out.c In file included from /home/hp/gcctop/tmp/mbase13/gcc/gcc/real.h:25:0, from /home/hp/gcctop/tmp/mbase13/gcc/gcc/rtl.h:27, from /home/hp/gcctop/tmp/mbase13/gcc/gcc/dwarf2out.c:62: /home/hp/gcctop/tmp/mbase13/gcc/gcc/wide-int.h: In function 'void insert_wide_int(const wide_int&, unsigned char*, int)': /home/hp/gcctop/tmp/mbase13/gcc/gcc/wide-int.h:800:57: error: array subscript is above array bounds [-Werror=array-bounds] cc1plus: all warnings being treated as errors make[2]: *** [dwarf2out.o] Error 1 *and* "gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC)" with cris-elf gets at the same revision: g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/tmp/werralw/gcc/gcc -I/tmp/werralw/gcc/gcc/build -I/tmp/werralw/gcc/gcc/../include -I/tmp/werralw/gcc/gcc/../libcpp/include \ -o build/genpreds.o /tmp/werralw/gcc/gcc/genpreds.c cc1plus: warnings being treated as errors In file included from /tmp/werralw/gcc/gcc/rtl.h:28, from /tmp/werralw/gcc/gcc/genpreds.c:27: /tmp/werralw/gcc/gcc/vec.h: In static member function 'static size_t vec<T, A, vl_embed>::embedded_size(unsigned int) [with T = std::pair<unsigned int, const char*>, A = va_heap]': /tmp/werralw/gcc/gcc/vec.h:308: instantiated from 'static void va_heap::reserve(vec<T, va_heap, vl_embed>*&, unsigned int, bool) [with T = std::pair<unsigned int, const char*>]' /tmp/werralw/gcc/gcc/vec.h:1428: instantiated from 'bool vec<T, va_heap, vl_ptr>::reserve(unsigned int, bool) [with T = std::pair<unsigned int, const char*>]' /tmp/werralw/gcc/gcc/vec.h:1537: instantiated from 'T* vec<T, va_heap, vl_ptr>::safe_push(const T&) [with T = std::pair<unsigned int, const char*>]' /tmp/werralw/gcc/gcc/genpreds.c:1383: instantiated from here /tmp/werralw/gcc/gcc/vec.h:1048: error: invalid access to non-static data member 'vec<std::pair<unsigned int, const char*>, va_heap, vl_embed>::m_vecdata' of NULL object /tmp/werralw/gcc/gcc/vec.h:1048: error: (perhaps the 'offsetof' macro was used incorrectly) make[2]: *** [build/genpreds.o] Error 1 I guess both of these can be attributed to "fairly old or even broken" host gcc if you want to stretch it... Jan-Benedict, which host gcc version do you use when getting most targets to build with config-list.mk? Maybe we can just set the initial version to that instead of 4.4.4. For reference, the patch, which works as intended (-Werror in the gcc build directory for cross-builds by default, not affecting native builds and not at all for gcc < 4.4.4). (Vax is excepted, see J-B's previous post.) I'd ask for approval except now the fallout seems excessive as both my common setups fail building, while having reasonable testsuite results, and I don't know my way around the erroring part of the code: config: * aclocal.m4 (ACX_PROG_CC_WARNINGS_ARE_ERRORS): Evaluate parameter 1 at configure-time, not at autoconf-time. gcc: * configure.ac: For cross-builds of non-releases with gcc 4.4.4 and newer, enable -Werror. Provide per-target exceptions, and do except vax-*. (is_release): Move before all other "warnings and checkings" code. * configure, aclocal.m4: Regenerate. Index: config/warnings.m4 =================================================================== --- config/warnings.m4 (revision 212909) +++ config/warnings.m4 (working copy) @@ -98,7 +98,7 @@ AC_ARG_ENABLE(werror-always, [], [enable_werror_always=no]) AS_IF([test $enable_werror_always = yes], [acx_Var="$acx_Var${acx_Var:+ }-Werror"]) - m4_if($1, [manual],, + AS_IF([test "x$1" != xmanual], [AS_VAR_PUSHDEF([acx_GCCvers], [acx_cv_prog_cc_gcc_$1_or_newer])dnl AC_CACHE_CHECK([whether $CC is GCC >=$1], acx_GCCvers, [set fnord `echo $1 | tr '.' ' '` Index: gcc/configure.ac =================================================================== --- gcc/configure.ac (revision 212909) +++ gcc/configure.ac (working copy) @@ -349,6 +349,11 @@ AC_LANG_POP(C++) # Warnings and checking # --------------------- +is_release= +if test x"`cat $srcdir/DEV-PHASE`" != xexperimental; then + is_release=yes +fi + # Check $CC warning features (if it's GCC). # We want to use -pedantic, but we don't want warnings about # * 'long long' @@ -377,7 +382,32 @@ ACX_PROG_CC_WARNING_OPTS( ACX_PROG_CC_WARNING_ALMOST_PEDANTIC( m4_quote(m4_do([-Wno-long-long -Wno-variadic-macros ], [-Wno-overlength-strings])), [strict_warn]) -ACX_PROG_CC_WARNINGS_ARE_ERRORS([manual], [strict_warn]) + + +werror_gcc_version=manual + +# For cross-building, we will not have a stage 2 (where build-time +# warnings-as-errors is default on for all targets), so make sure we +# error on warnings for sufficiently new gcc anyway. +# Some targets are excepted. +if test x$host != x$target && test x$is_release = x ; then + case $target in + # These targets have (bogus) warnings for some target-specific + # construct and some fairly recent gcc. Also, working around the + # warning would obfuscate the source, so just never enable -Werror + # by default. + vax-*-*) ;; + *) + # The version here is just a random sufficiently old version + # that someone has shown warning-free for some target. + # Changing it to a newer version is expected, when changes to + # generic code upsets this version, and a newer gcc version is + # happy. + werror_gcc_version=4.4.4 ;; + esac +fi + +ACX_PROG_CC_WARNINGS_ARE_ERRORS([$werror_gcc_version], [strict_warn]) # The above macros do nothing if the compiler is not GCC. However, the # Makefile has more goo to add other flags, so these variables are used @@ -397,11 +427,6 @@ ACX_PROG_CC_WARNING_OPTS( [noexception_flags]) # Enable expensive internal checks -is_release= -if test x"`cat $srcdir/DEV-PHASE`" != xexperimental; then - is_release=yes -fi - AC_ARG_ENABLE(checking, [AS_HELP_STRING([[--enable-checking[=LIST]]], [enable expensive run-time checks. With LIST, brgds, H-P ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: werror fallout for cross-builds 2014-07-22 20:49 ` werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)) Hans-Peter Nilsson @ 2014-07-22 22:12 ` Andreas Schwab 2014-07-23 0:09 ` werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)) Mike Stump 2014-07-24 0:42 ` Jan-Benedict Glaw 2 siblings, 0 replies; 18+ messages in thread From: Andreas Schwab @ 2014-07-22 22:12 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: Richard Biener, Jan-Benedict Glaw, gcc-patches Hans-Peter Nilsson <hp@bitrange.com> writes: > gcc: > * configure.ac: For cross-builds of non-releases with gcc 4.4.4 > and newer, enable -Werror. Provide per-target exceptions, and do > except vax-*. This will break when a new printf format is added. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)) 2014-07-22 20:49 ` werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)) Hans-Peter Nilsson 2014-07-22 22:12 ` werror fallout for cross-builds Andreas Schwab @ 2014-07-23 0:09 ` Mike Stump 2014-07-23 2:54 ` Hans-Peter Nilsson 2014-07-24 0:42 ` Jan-Benedict Glaw 2 siblings, 1 reply; 18+ messages in thread From: Mike Stump @ 2014-07-23 0:09 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: Richard Biener, Jan-Benedict Glaw, gcc-patches On Jul 22, 2014, at 1:40 PM, Hans-Peter Nilsson <hp@bitrange.com> wrote: > > *Developers* (or rather, people cross-building non-released gcc > source in their usual setup) don't use the fairly old or even > broken host gcc versions that can be expected in use in the > general public (well, the users that still want to build gcc > from releases and not use pre-built binaries). :-) Speak for yourself. I do cross, I deliver cross, and we just use the same old /bin/gcc that everyone else uses. And, we might well deliver on OSes other than the one released last week. In my case, /bin/gcc is 4.4.7. Though, I usually develop on 4.6.3 and 4.8.2. So, what I want is software that builds and works. I object to any patch that causes gcc to not build. Now, how do we ensure that gcc builds in the face of Werror? This is easy, that option can only be added when the host compiler and version is in a whitelist of known good versions. Why _must_ we do this? Because a newer gcc _will_ add new checking, that new checking will break the build. The only way to not break that build is to never ever add another warning to gcc, which, we are not going to sign up for, or, to have a white list that doesn’t include a version number of unreleased gccs. That’s it. If you are uninterested in testing if a particular host compiler works or not, then they by definition don’t want the build to fail. This is isn’t theoretic. I do cross builds on 4.4.7, I don’t want my builds to just break. I’ve seen builds break with Werror with newer compilers. To remain other than theoretic, I did a build of my tree with Werror. Two problems in my code, happy to fix, I’ve fixed them, but… then it when on to break with the vec and offsetof problem that you’ve previously seen. That’s not something I want to spend my days scratching my head at. And this _is_ why the person to do the fixing, is the person that _adds_ that exact version to the white list. Not some other random person. Once it is added to the white list, sure, problems might creep up, and those we can deal with, as you say, it. The obscure things, we should not build with Werror. My build is apparently obscure, as it doesn’t build. You want to add it to the white list for Werror, fix the build, _then_ add it to the list. >> If we want it to make the default the we should restrict it >> based on the host compiler (version). > > My point is that it's unnecessary; we should just enable it > always *for cross-builds only* (native cases will see it for > stage 2 anyway) and deal with the fallout. So, there are two schools of thought. One is I wanna break the build to force people to do work for me that I refuse to do myself, and the other is I don’t want to break the build. Which school do you come from? I’m from the later. I am unsympathetic to the first, as if they wanted to contribute patches to gcc to make it nicer, they could, at any time. If an older gcc generated nice warnings that a newer version doesn’t, they can compile with that version and contribute that work. If an older version of gcc spat out wrong warnings, there is no point in breaking that build. The warnings are wrong, they have been removed from gcc, and there is no reason to ask people to put crap into the source base to try and work around those warnings. The proper solution is to remove that compiler version from the list of versions to include -Werror with. You want to deal with the fallout, then build all the crosses on the host compiler you want to validate and then add that version to the whitelist after you have dealt with all the fall out… > Bringing the non-fatal errors out in the open has value But that isn’t overcome all the broken builds for all the people that experience all the broken builds. > above the trouble dealing with any breakage. To be very concrete, what you miss is that the people experiencing: g++ -c -g3 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc/gcc -I../../gcc/gcc/build -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include \ -o build/genpreds.o ../../gcc/gcc/genpreds.c cc1plus: warnings being treated as errors In file included from ../../gcc/gcc/rtl.h:28, from ../../gcc/gcc/genpreds.c:27: ../../gcc/gcc/vec.h: In static member function ‘static size_t vec<T, A, vl_embed>::embedded_size(unsigned int) [with T = std::pair<unsigned int, const char*>, A = va_heap]’: ../../gcc/gcc/vec.h:308: instantiated from ‘static void va_heap::reserve(vec<T, va_heap, vl_embed>*&, unsigned int, bool) [with T = std::pair<unsigned int, const char*>]’ ../../gcc/gcc/vec.h:1428: instantiated from ‘bool vec<T, va_heap, vl_ptr>::reserve(unsigned int, bool) [with T = std::pair<unsigned int, const char*>]’ ../../gcc/gcc/vec.h:1537: instantiated from ‘T* vec<T, va_heap, vl_ptr>::safe_push(const T&) [with T = std::pair<unsigned int, const char*>]’ ../../gcc/gcc/genpreds.c:1383: instantiated from here ../../gcc/gcc/vec.h:1048: error: invalid access to non-static data member ‘vec<std::pair<unsigned int, const char*>, va_heap, vl_embed>::m_vecdata’ of NULL object ../../gcc/gcc/vec.h:1048: error: (perhaps the ‘offsetof’ macro was used incorrectly) make: *** [build/genpreds.o] Error 1 g++ -c -g3 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc/gcc -I../../gcc/gcc/build -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include \ -o build/genopinit.o ../../gcc/gcc/genopinit.c cc1plus: warnings being treated as errors ../../gcc/gcc/genopinit.c: In function ‘int main(int, char**)’: ../../gcc/gcc/genopinit.c:516: error: comparison between signed and unsigned integer expressions make: *** [build/genopinit.o] Error 1 make: Target `all' not remade because of errors. want to spend their time trying to puzzle out what went wrong, and why and how to fix it, and that there are a ton of these people and then all will hit it and you will waste all their time with a broken build. You are not sensitive enough to this wastage. You want the reports, great, there it is. Now what? Causing 1 more person to waste their time on the issue now that I have (and apparently you have) doesn’t add value. All we will likely do is to google it, find a web page that says gcc sucks, it doesn’t build, and to make it build you have to go edit some cryptic file and change it is exceedingly cryptic ways. I don’t want that world. > Also, exceptions should be simple to > do per-target for the reasons mentions. (Actually, I ended up > enabling both as the version checking was already there.) Then remove 4.4 from the white list. It doesn’t appear to work. I can waste yet more time and try 4.6.3: make -k gcc -c -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wno-overlength-strings -pedantic -Wno-long-long -Werror -DHAVE_CONFIG_H -I. -I../../gcc/fixincludes -I../include -I../../gcc/fixincludes/../include ../../gcc/fixincludes/server.c ../../gcc/fixincludes/server.c: In function ‘server_setup’: ../../gcc/fixincludes/server.c:195:10: error: ignoring return value of ‘getcwd’, declared with attribute warn_unused_result [-Werror=unused-result] cc1: all warnings being treated as errors make[2]: *** [server.o] Error 1 make[2]: Target `all' not remade because of errors. gcc -c -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wno-overlength-strings -pedantic -Wno-long-long -Werror -DHAVE_CONFIG_H -I. -I../../../gcc/fixincludes -I../include -I../../../gcc/fixincludes/../include ../../../gcc/fixincludes/server.c ../../../gcc/fixincludes/server.c: In function ‘server_setup’: ../../../gcc/fixincludes/server.c:195:10: error: ignoring return value of ‘getcwd’, declared with attribute warn_unused_result [-Werror=unused-result] cc1: all warnings being treated as errors make[2]: *** [server.o] Error 1 g++ -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include -g -O2 -W -Wall -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -fno-exceptions -fno-rtti -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include -c -o directives.o -MT directives.o -MMD -MP -MF .deps/directives.Tpo ../../gcc/libcpp/directives.c ../../gcc/libcpp/directives.c: In function ‘void cpp_define_formatted(cpp_reader*, const char*, ...)’: ../../gcc/libcpp/directives.c:2380:28: error: ignoring return value of ‘int vasprintf(char**, const char*, __va_list_tag*)’, declared with attribute warn_unused_result [-Werror=unused-result] cc1plus: all warnings being treated as errors make[2]: *** [directives.o] Error 1 g++ -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include -g -O2 -W -Wall -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -fno-exceptions -fno-rtti -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include -c -o expr.o -MT expr.o -MMD -MP -MF .deps/expr.Tpo ../../gcc/libcpp/expr.c ../../gcc/libcpp/expr.c: In function ‘unsigned int cpp_classify_number(cpp_reader*, const cpp_token*, const char**, source_location)’: ../../gcc/libcpp/expr.c:672:18: error: format not a string literal and no format arguments [-Werror=format-security] ../../gcc/libcpp/expr.c:675:39: error: format not a string literal and no format arguments [-Werror=format-security] cc1plus: all warnings being treated as errors make[2]: *** [expr.o] Error 1 g++ -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include -g -O2 -W -Wall -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -fno-exceptions -fno-rtti -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include -c -o macro.o -MT macro.o -MMD -MP -MF .deps/macro.Tpo ../../gcc/libcpp/macro.c ../../gcc/libcpp/macro.c: In function ‘bool create_iso_definition(cpp_reader*, cpp_macro*)’: ../../gcc/libcpp/macro.c:2971:58: error: format not a string literal and no format arguments [-Werror=format-security] ../../gcc/libcpp/macro.c:2984:58: error: format not a string literal and no format arguments [-Werror=format-security] cc1plus: all warnings being treated as errors make[2]: *** [macro.o] Error 1 nope, doesn’t work either, you can remove it from the white list as well. Now, even if both of these issues I hit are fixed that just means that one can add those two versions to the white list. If 4.6.0 works and 4.6.3 works, I’m fine with adding all of 4.6.x on the assumption that the other versions won’t hit. > But, the above was written under the assumption that most > targets *do* build these days with --enable-werror-always for > most non-ancient gcc (say, 4.4 and up), but I no longer think > that's the case after testing the patch. Bingo. > In the name of "dealing with the fallout": with the patch below > (don't forget to re-generate configure) I get build errors in > generic code r212915 for *both* x86_64 "gcc version 4.7.2 > 20120921 (Red Hat 4.7.2-2) (GCC)" for mmix-knuth-mmixware: But that isn’t a fix. It is a mere report that doing the change isn’t desirable. The first person that hits a breakage should fix it and check it in, or, it harder, turn it off and file a bug report. The closer of that bug report can fix it, and readable it. So the question isn’t let’s imagine a world where 4.4 and later all work, let us ask instead on what version _is it known_ to work? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)) 2014-07-23 0:09 ` werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)) Mike Stump @ 2014-07-23 2:54 ` Hans-Peter Nilsson 2014-07-23 8:06 ` Mike Stump 0 siblings, 1 reply; 18+ messages in thread From: Hans-Peter Nilsson @ 2014-07-23 2:54 UTC (permalink / raw) To: Mike Stump; +Cc: Richard Biener, Jan-Benedict Glaw, gcc-patches On Tue, 22 Jul 2014, Mike Stump wrote: > On Jul 22, 2014, at 1:40 PM, Hans-Peter Nilsson <hp@bitrange.com> wrote: > > > > *Developers* (or rather, people cross-building non-released gcc > > source in their usual setup) don't use the fairly old or even > > broken host gcc versions that can be expected in use in the > > general public (well, the users that still want to build gcc > > from releases and not use pre-built binaries). (Hey, I proved that false myself and stated as much, see the "But, the above..." rebuttal half-way through my post!) > :-) Speak for yourself. I do cross, I deliver cross, and we > just use the same old /bin/gcc that everyone else uses. And, we > might well deliver on OSes other than the one released last > week. In my case, /bin/gcc is 4.4.7. Though, I usually develop > on 4.6.3 and 4.8.2. So, what I want is software that builds and > works. I object to any patch that causes gcc to not build. [etc] Mike, you miss the point of my post, and the patch too. Maybe I was unclear. There seems to be violent agreement... First, about the effect on the patch, regarding code deliveries like your case above, you don't deliver DEV-PHASE = experimental code (hopefully, with all the default redundant internal testing it does). More likely, you deliver releases, in which this developer-phase testing wouldn't be enabled. The intent of the patch was to help avoiding the *GCC developer* situation where a person patches a lot of targets but in his sanity-build misses out on introducing valid warnings about a typo-level warning, exactly like the commit from which this thread started. The patch worked as intended, but as I mentioned (apparently ambiguously enough), that intent was based on a false pretense that most targets *do* work with -Werror. The fallout is actually (still) overwhelming. You definitely wanted to make sure I didn't miss that last point. You don't have to worry about that, never needed. (I did mention breaking host gcc versions overlapping those you mention - including quotes of identical breakages!) I posted the patch on the off-chance that there actually *is* a later version in which all invalid warnings are gone. Note that I didn't actually ask for approval. I did ask for a host gcc version where builds with --enable-werror-always work! brgds, H-P ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)) 2014-07-23 2:54 ` Hans-Peter Nilsson @ 2014-07-23 8:06 ` Mike Stump 2014-07-24 11:13 ` Maciej W. Rozycki 0 siblings, 1 reply; 18+ messages in thread From: Mike Stump @ 2014-07-23 8:06 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: Richard Biener, Jan-Benedict Glaw, gcc-patches On Jul 22, 2014, at 6:22 PM, Hans-Peter Nilsson <hp@bitrange.com> wrote: > Note that I didn't actually ask for approval. Then I’m shadow boxing. I assumed that people wanted to turn it on by default. I’m all for that, I think it is a good idea and a fine direction. :-) The only limitation is whitelisting exactly when it pops on and preflighting those at least once to ensure they are clean. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)) 2014-07-23 8:06 ` Mike Stump @ 2014-07-24 11:13 ` Maciej W. Rozycki 0 siblings, 0 replies; 18+ messages in thread From: Maciej W. Rozycki @ 2014-07-24 11:13 UTC (permalink / raw) To: Mike Stump Cc: Hans-Peter Nilsson, Richard Biener, Jan-Benedict Glaw, gcc-patches On Tue, 22 Jul 2014, Mike Stump wrote: > Then IΒ’m shadow boxing. I assumed that people wanted to turn it on by > default. IΒ’m all for that, I think it is a good idea and a fine > direction. :-) The only limitation is whitelisting exactly when it > pops on and preflighting those at least once to ensure they are clean. I think at the very least the thing should be on whenever building with itself, that is the build compiler's version is the same as the version of the compiler being built. That can be probably reasonably broadened to any compiler bearing the same major.minor version (or just major if we switch to the two-part versioning scheme recently proposed). The thing is to bring the code base to always compile without warnings and then not to let it regress. Warnings are too easy to miss and sometimes are a symptom of actual breakage rather than just harmless noise, i.e. code builds and runs, but does something silly. I have wasted hours of debugging time already on chasing such problems. Maciej ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)) 2014-07-22 20:49 ` werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)) Hans-Peter Nilsson 2014-07-22 22:12 ` werror fallout for cross-builds Andreas Schwab 2014-07-23 0:09 ` werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)) Mike Stump @ 2014-07-24 0:42 ` Jan-Benedict Glaw 2014-07-24 20:56 ` Hans-Peter Nilsson 2 siblings, 1 reply; 18+ messages in thread From: Jan-Benedict Glaw @ 2014-07-24 0:42 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: Richard Biener, gcc-patches [-- Attachment #1: Type: text/plain, Size: 1714 bytes --] On Tue, 2014-07-22 16:40:31 -0400, Hans-Peter Nilsson <hp@bitrange.com> wrote: > In the name of "dealing with the fallout": with the patch below > (don't forget to re-generate configure) I get build errors in > generic code r212915 for *both* x86_64 "gcc version 4.7.2 > 20120921 (Red Hat 4.7.2-2) (GCC)" for mmix-knuth-mmixware: [...] > I guess both of these can be attributed to "fairly old or even > broken" host gcc if you want to stretch it... > > Jan-Benedict, which host gcc version do you use when getting > most targets to build with config-list.mk? Maybe we can just > set the initial version to that instead of 4.4.4. darkeye gcc (Debian 4.8.1-7) 4.8.1 gccbuild gcc (Debian 4.8.1-7) 4.8.1 pluto gcc (Debian 4.9.1-1) 4.9.1 gcc20 gcc (Debian 4.4.5-8) 4.4.5 gcc76 gcc (Debian 4.4.5-8) 4.4.5 gcc110 gcc (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8) gcc111 gcc (GCC) 4.8.1 XL 12.1.0.0 (if I ever get that properly working...) > For reference, the patch, which works as intended (-Werror in > the gcc build directory for cross-builds by default, not > affecting native builds and not at all for gcc < 4.4.4). (Vax > is excepted, see J-B's previous post.) I'd ask for approval VAX sould work, it's pdp11 that I said wouldn't. > except now the fallout seems excessive as both my common setups > fail building, while having reasonable testsuite results, and I > don't know my way around the erroring part of the code: MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481 Signature of: Fortschritt bedeutet, einen Schritt so zu machen, the second : daß man den nächsten auch noch machen kann. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)) 2014-07-24 0:42 ` Jan-Benedict Glaw @ 2014-07-24 20:56 ` Hans-Peter Nilsson 2014-07-25 9:58 ` Jan-Benedict Glaw 0 siblings, 1 reply; 18+ messages in thread From: Hans-Peter Nilsson @ 2014-07-24 20:56 UTC (permalink / raw) To: Jan-Benedict Glaw; +Cc: gcc-patches On Thu, 24 Jul 2014, Jan-Benedict Glaw wrote: > On Tue, 2014-07-22 16:40:31 -0400, Hans-Peter Nilsson <hp@bitrange.com> wrote: > > Jan-Benedict, which host gcc version do you use when getting > > most targets to build with config-list.mk? Maybe we can just > > set the initial version to that instead of 4.4.4. > > darkeye gcc (Debian 4.8.1-7) 4.8.1 > gccbuild gcc (Debian 4.8.1-7) 4.8.1 > pluto gcc (Debian 4.9.1-1) 4.9.1 > gcc20 gcc (Debian 4.4.5-8) 4.4.5 > gcc76 gcc (Debian 4.4.5-8) 4.4.5 > gcc110 gcc (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8) > gcc111 gcc (GCC) 4.8.1 > XL 12.1.0.0 (if I ever get that properly working...) I tried to repeat that, for the CFarm hosts. On gcc111 trying config-list.mk on the 0720 snapshot (and with mpc, mpfr and gmp in-tree) gives me: "configure: error: GNAT is required to build ada" already for aarch64-unknown-elf. Somewhat expected, as I don't think many of the targets in the config-list.mk LIST have Ada bits ported, but maybe there are no Ada specific bits needed to build the GNAT compiler proper, just a host GNAT. On gcc110 which *has* gnat, I get: /gcc/o/aarch64-elf/./mpfr -I/home/hp/gcc/gcc/mpfr -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace -o dwarf2out.o -MT dwarf2out.o -MMD -MP -MF ./.deps/dwarf2out.TPo ../../../gcc/gcc/dwarf2out.c In file included from ../../../gcc/gcc/real.h:25:0, from ../../../gcc/gcc/rtl.h:27, from ../../../gcc/gcc/dwarf2out.c:62: ../../../gcc/gcc/wide-int.h: In function 'void insert_wide_int(const wide_int&, unsigned char*, int)': ../../../gcc/gcc/wide-int.h:800:48: error: array subscript is above array bounds [-Werror=array-bounds] cc1plus: all warnings being treated as errors gmake[2]: *** [dwarf2out.o] Error 1 gmake[2]: Leaving directory `/home/hp/gcc/o/aarch64-elf/gcc' By that list, did you really mean that you got even 4.4.5 to work on an unmodified config-list.mk? Perhaps you have local patches or did you call config-list.mk with some kind of options? Maybe you didn't actually use config-list.mk? Or just looked to see whether the first failure for each target was on a target-specific file or the (same) middle-end bits? Ok, I'm out of guesses. :) > > For reference, the patch, which works as intended (-Werror in > > the gcc build directory for cross-builds by default, not > > affecting native builds and not at all for gcc < 4.4.4). (Vax > > is excepted, see J-B's previous post.) I'd ask for approval > > VAX sould work, it's pdp11 that I said wouldn't. Sorry I misremembered. brgds, H-P ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)) 2014-07-24 20:56 ` Hans-Peter Nilsson @ 2014-07-25 9:58 ` Jan-Benedict Glaw 2014-07-25 16:51 ` Hans-Peter Nilsson 0 siblings, 1 reply; 18+ messages in thread From: Jan-Benedict Glaw @ 2014-07-25 9:58 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: gcc-patches [-- Attachment #1: Type: text/plain, Size: 2635 bytes --] On Thu, 2014-07-24 16:30:13 -0400, Hans-Peter Nilsson <hp@bitrange.com> wrote: > On Thu, 24 Jul 2014, Jan-Benedict Glaw wrote: > > On Tue, 2014-07-22 16:40:31 -0400, Hans-Peter Nilsson <hp@bitrange.com> wrote: > > > Jan-Benedict, which host gcc version do you use when getting > > > most targets to build with config-list.mk? Maybe we can just > > > set the initial version to that instead of 4.4.4. > > > > darkeye gcc (Debian 4.8.1-7) 4.8.1 > > gccbuild gcc (Debian 4.8.1-7) 4.8.1 > > pluto gcc (Debian 4.9.1-1) 4.9.1 > > gcc20 gcc (Debian 4.4.5-8) 4.4.5 > > gcc76 gcc (Debian 4.4.5-8) 4.4.5 > > gcc110 gcc (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8) > > gcc111 gcc (GCC) 4.8.1 > > XL 12.1.0.0 (if I ever get that properly working...) > > I tried to repeat that, for the CFarm hosts. On gcc111 trying > config-list.mk on the 0720 snapshot (and with mpc, mpfr and gmp > in-tree) gives me: "configure: error: GNAT is required to build > ada" already for aarch64-unknown-elf. Somewhat expected, as I > don't think many of the targets in the config-list.mk LIST have > Ada bits ported, but maybe there are no Ada specific bits needed > to build the GNAT compiler proper, just a host GNAT. > > On gcc110 which *has* gnat, I get: > > /gcc/o/aarch64-elf/./mpfr -I/home/hp/gcc/gcc/mpfr -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace -o dwarf2out.o -MT dwarf2out.o -MMD -MP -MF ./.deps/dwarf2out.TPo ../../../gcc/gcc/dwarf2out.c [...] The config-list.mk builds are right now only scheduled on gcc20 and gcc76. Maybe I'd schedule them on gcc110 as well? > By that list, did you really mean that you got even 4.4.5 to > work on an unmodified config-list.mk? No, I just haven't scheduled config-list.mk based builds (you know, I right now have two different build backends, with possibly cbuild2 being integrated as a third one) on gcc110 at all. > Perhaps you have local patches or did you call config-list.mk > with some kind of options? Maybe you didn't actually use > config-list.mk? Or just looked to see whether the first failure > for each target was on a target-specific file or the (same) > middle-end bits? Ok, I'm out of guesses. :) ...and you just missed the most obvious one: It probably won't just work at all ;-) MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481 Signature of: Arroganz verkürzt fruchtlose Gespräche. the second : -- Jan-Benedict Glaw [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)) 2014-07-25 9:58 ` Jan-Benedict Glaw @ 2014-07-25 16:51 ` Hans-Peter Nilsson 2014-07-26 17:33 ` Hans-Peter Nilsson 0 siblings, 1 reply; 18+ messages in thread From: Hans-Peter Nilsson @ 2014-07-25 16:51 UTC (permalink / raw) To: Jan-Benedict Glaw; +Cc: gcc-patches On Fri, 25 Jul 2014, Jan-Benedict Glaw wrote: > On Thu, 2014-07-24 16:30:13 -0400, Hans-Peter Nilsson <hp@bitrange.com> wrote: > > On Thu, 24 Jul 2014, Jan-Benedict Glaw wrote: > > > On Tue, 2014-07-22 16:40:31 -0400, Hans-Peter Nilsson <hp@bitrange.com> wrote: > > > > Jan-Benedict, which host gcc version do you use when getting > > > > most targets to build with config-list.mk? Maybe we can just > > > > set the initial version to that instead of 4.4.4. > > > > > > darkeye gcc (Debian 4.8.1-7) 4.8.1 > > > gccbuild gcc (Debian 4.8.1-7) 4.8.1 > > > pluto gcc (Debian 4.9.1-1) 4.9.1 > > > gcc20 gcc (Debian 4.4.5-8) 4.4.5 > > > gcc76 gcc (Debian 4.4.5-8) 4.4.5 > > > gcc110 gcc (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8) > > > gcc111 gcc (GCC) 4.8.1 > > > XL 12.1.0.0 (if I ever get that properly working...) I think we have different definitions of "getting most targets to build". I guess a valid reply here would IMO have been an empty list. :( Does 4.9.1 work(*)? > > On gcc110 which *has* gnat, I get: > > /gcc/o/aarch64-elf/./mpfr -I/home/hp/gcc/gcc/mpfr -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace -o dwarf2out.o -MT dwarf2out.o -MMD -MP -MF ./.deps/dwarf2out.TPo ../../../gcc/gcc/dwarf2out.c > [...] > > The config-list.mk builds are right now only scheduled on gcc20 and > gcc76. Maybe I'd schedule them on gcc110 as well? I wouldn't bother, as I found most fail with the errored-warning I quoted, the rest on port warnings (c6x, mep, avr, bfin, so far) I'm guessing you don't get very far on gcc20 or gcc76 on each target. I think there's a miscommunication here. When you said you used config-list.mk and by reporting target-specific build errors, I misunderstood that as implying that most targets were then building with no errors using config-list.mk. > > Perhaps you have local patches or did you call config-list.mk > > with some kind of options? Maybe you didn't actually use > > config-list.mk? Or just looked to see whether the first failure > > for each target was on a target-specific file or the (same) > > middle-end bits? Ok, I'm out of guesses. :) > > ...and you just missed the most obvious one: It probably won't just > work at all ;-) (Not really, that's reporting the first failure for a target when being a target-specific error.) Anyway, on to the point of this message: by the quoted list it seems you have a local host called pluto using 4.9.1 as the host gcc for some build; does config-list.mk work for that? (* to wit, by "work" I mean "builds with no errors for at least one target actually using config-list.mk".) brgds, H-P ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)) 2014-07-25 16:51 ` Hans-Peter Nilsson @ 2014-07-26 17:33 ` Hans-Peter Nilsson 2014-08-22 11:55 ` Jan-Benedict Glaw 0 siblings, 1 reply; 18+ messages in thread From: Hans-Peter Nilsson @ 2014-07-26 17:33 UTC (permalink / raw) To: Jan-Benedict Glaw; +Cc: gcc-patches On Fri, 25 Jul 2014, Hans-Peter Nilsson wrote: > Anyway, on to the point of this message: by the quoted list it > seems you have a local host called pluto using 4.9.1 as the host > gcc for some build; does config-list.mk work for that? Never mind, I found a 4.9.1 installation on gcc110 and the answer seems to be "yes", but still investigating; I disabled Ada. It might be useful to run a modified config-list.mk using that version. BTW, I found the answer to be "no" for 4.8.1 as per gcc111 due to a common warning on a concat call. brgds, H-P ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)) 2014-07-26 17:33 ` Hans-Peter Nilsson @ 2014-08-22 11:55 ` Jan-Benedict Glaw 0 siblings, 0 replies; 18+ messages in thread From: Jan-Benedict Glaw @ 2014-08-22 11:55 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: gcc-patches [-- Attachment #1: Type: text/plain, Size: 1186 bytes --] On Sat, 2014-07-26 13:31:42 -0400, Hans-Peter Nilsson <hp@bitrange.com> wrote: > On Fri, 25 Jul 2014, Hans-Peter Nilsson wrote: > > Anyway, on to the point of this message: by the quoted list it > > seems you have a local host called pluto using 4.9.1 as the host > > gcc for some build; does config-list.mk work for that? > > Never mind, I found a 4.9.1 installation on gcc110 and the > answer seems to be "yes", but still investigating; I disabled > Ada. It might be useful to run a modified config-list.mk using > that version. > > BTW, I found the answer to be "no" for 4.8.1 as per gcc111 due > to a common warning on a concat call. As written elsewhere: I think I correctly reworked the config-list.mk building backend last night. It's running on gcc76 already (will put it on gcc20 as soon as I'm convinced it *really* works) and then we'll get the cross-compiler built with a GCC of the very same SCM revision. MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481 Signature of: If it doesn't work, force it. the second : If it breaks, it needed replacing anyway. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2014-08-22 11:55 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-07-18 5:04 [BUILDROBOT][PATCH] Fix mmix (unused variable) Jan-Benedict Glaw 2014-07-18 8:08 ` Hans-Peter Nilsson 2014-07-18 13:11 ` Jan-Benedict Glaw 2014-07-19 6:42 ` Hans-Peter Nilsson 2014-07-19 17:27 ` Jan-Benedict Glaw 2014-07-22 13:01 ` Richard Biener 2014-07-22 20:49 ` werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)) Hans-Peter Nilsson 2014-07-22 22:12 ` werror fallout for cross-builds Andreas Schwab 2014-07-23 0:09 ` werror fallout for cross-builds (was: Re: [BUILDROBOT][PATCH] Fix mmix (unused variable)) Mike Stump 2014-07-23 2:54 ` Hans-Peter Nilsson 2014-07-23 8:06 ` Mike Stump 2014-07-24 11:13 ` Maciej W. Rozycki 2014-07-24 0:42 ` Jan-Benedict Glaw 2014-07-24 20:56 ` Hans-Peter Nilsson 2014-07-25 9:58 ` Jan-Benedict Glaw 2014-07-25 16:51 ` Hans-Peter Nilsson 2014-07-26 17:33 ` Hans-Peter Nilsson 2014-08-22 11:55 ` Jan-Benedict Glaw
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).