emerge of dev-libs/nss-3.21 fails with gcc 5.2 with a warning. Disabling -Werror solves this problem. Reproducible: Always Steps to Reproduce: 1. emerge dev-libs/nss-3.21 with gcc 5.2
Created attachment 418192 [details, diff] Disable use of -Werror This patch disables the use of -Werror unconditionally.
Excerpt from build.log qg.c: In function 'PQG_VerifyParams': pqg.c:1773:27: error: 'type' may be used uninitialized in this function [-Werror=maybe-uninitialized] if ((vfy->h.len == 1) && (type != FIPS186_1_TYPE)) { ^ In file included from pqg.c:21:0: secmpi.h:7:31: error: 'hashtype' may be used uninitialized in this function [-Werror=maybe-uninitialized] #define CHECK_SEC_OK(func) if (SECSuccess != (rv = func)) goto cleanup ^ pqg.c:1592:19: note: 'hashtype' was declared here HASH_HashType hashtype; ^ cc1: all warnings being treated as errors
I can confirm this with GCC 4.9.3 as well.
Created attachment 418238 [details] build log, gcc 5.1.0 nss-3.21
hippopopus ~ # emerge -pqv '=dev-libs/nss-3.21::gentoo' [ebuild U ] dev-libs/nss-3.21 [3.20.1] USE="cacert nss-pem -utils" ABI_X86="(64) -32 (-x32)" hippopopus ~ # emerge --info '=dev-libs/nss-3.21::gentoo' Portage 2.2.26 (python 3.4.3-final-0, default/linux/amd64/13.0/desktop/kde, gcc-5.1.0, glibc-2.22-r1, 4.3.0-gentoo x86_64) ================================================================= System Settings ================================================================= System uname: Linux-4.3.0-gentoo-x86_64-Intel-R-_Core-TM-_i7-3770_CPU_@_3.40GHz-with-gentoo-2.2 KiB Mem: 16412496 total, 318132 free KiB Swap: 0 total, 0 free Timestamp of repository gentoo: Mon, 30 Nov 2015 18:30:01 +0000 sh bash 4.3_p42 ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1 distcc 3.2rc1 x86_64-pc-linux-gnu [disabled] app-shells/bash: 4.3_p42::gentoo dev-java/java-config: 2.2.0::gentoo dev-lang/perl: 5.22.0::gentoo dev-lang/python: 2.7.10-r3::gentoo, 3.4.3-r2::gentoo dev-util/cmake: 3.4.0-r1::gentoo dev-util/pkgconfig: 0.29::gentoo sys-apps/baselayout: 2.2::gentoo sys-apps/openrc: 0.18.3::gentoo sys-apps/sandbox: 2.9::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69-r1::gentoo sys-devel/automake: 1.11.6-r1::gentoo, 1.13.4::gentoo, 1.14.1::gentoo, 1.15::gentoo sys-devel/binutils: 2.25.1-r1::gentoo sys-devel/gcc: 4.8.5::gentoo, 4.9.3::gentoo, 5.1.0::gentoo sys-devel/gcc-config: 1.8::gentoo sys-devel/libtool: 2.4.6-r1::gentoo sys-devel/make: 4.1-r1::gentoo sys-kernel/linux-headers: 4.3::gentoo (virtual/os-headers) sys-libs/glibc: 2.22-r1::gentoo Repositories: gentoo location: /home/gentoo/portage sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 hippopopus-jbowler-com location: /home/gentoo/overlay masters: gentoo priority: 0 ACCEPT_KEYWORDS="amd64 ~amd64 ~x86" ACCEPT_LICENSE="* -@EULA @BINARY-REDISTRIBUTABLE" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-Os -g -march=native -pipe -fexceptions" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-Os -g -march=native -pipe" DISTDIR="/home/gentoo/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs compressdebug config-protect-if-modified distlocks ebuild-locks fixlafiles installsources merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://lug.mtu.edu/gentoo/ ftp://lug.mtu.edu/gentoo/ ftp://gentoo.llarian.net/pub/gentoo http://gentoo.llarian.net/" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="--jobs=8 --load-average=5.5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/home/gentoo/build" USE="X a52 aac acl acpi aes alsa amd64 avx berkdb bluetooth branding bzip2 cairo cdda cdr cli consolekit cracklib crypt cups cxx dbus declarative dri dts dvd dvdr emboss encode exif fam firefox flac fortran gdbm gif glamor gpm gtk iconv ipv6 jack jpeg kde kipi lcms ldap libnotify mad mmx mmxext mng modules mp3 mp4 mpeg multilib ncurses nls nptl ogg opengl openmp pam pango pcre pdf phonon plasma png policykit popcnt ppds qt3support qt4 readline sdl seccomp session spell sse sse2 sse3 sse4_1 sse4_2 ssl ssse3 startup-notification svg tcpd threads tiff truetype udev udisks unicode upower usb vorbis wxwidgets x264 xattr xcb xcomposite xinerama xml xscreensaver xv xvid zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4" RUBY_TARGETS="ruby20 ruby21" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Happens with gcc-5.1.0 too. Disabling -Werror is clearly wrong; the maybe-unitialized variable needs to be fixed, though it looks like a gcc bug to me. Here is the relevant stuff from build.log, with the command line truncated to make it readable: x86_64-pc-linux-gnu-gcc [stuff] pqg.c pqg.c: In function ‘PQG_VerifyParams’: pqg.c:1773:27: error: ‘type’ may be used uninitialized in this function [-Werror=maybe-uninitialized] if ((vfy->h.len == 1) && (type != FIPS186_1_TYPE)) { ^ In file included from pqg.c:21:0: secmpi.h:7:31: error: ‘hashtype’ may be used uninitialized in this function [-Werror=maybe-uninitialized] #define CHECK_SEC_OK(func) if (SECSuccess != (rv = func)) goto cleanup ^ pqg.c:1592:19: note: ‘hashtype’ was declared here HASH_HashType hashtype; ^ cc1: all warnings being treated as errors ../../coreconf/rules.mk:388: recipe for target 'Linux2.6_x86_64_x86_64-pc-linux-gnu-gcc_glibc_PTH_64_OPT.OBJ/Linux_SINGLE_SHLIB/pqg.o' failed make[3]: *** [Linux2.6_x86_64_x86_64-pc-linux-gnu-gcc_glibc_PTH_64_OPT.OBJ/Linux_SINGLE_SHLIB/pqg.o] Error 1 make[3]: Leaving directory '/home/gentoo/build/portage/dev-libs/nss-3.21/work/nss-3.21/nss-abi_x86_64.amd64/lib/freebl' So I assume it is 'nss-3.21/nss-abi_x86_64.amd64/lib/freebl/pqg.c', however both instances of the file are the same. I can't see any way that 'type' can be uninitialized.
(In reply to Austin S. Hemmelgarn from comment #3) > I can confirm this with GCC 4.9.3 as well. Huh, sorry for the noise concerning gcc 5.
(In reply to John Bowler from comment #6) > Happens with gcc-5.1.0 too. Disabling -Werror is clearly wrong; the > maybe-unitialized variable needs to be fixed, though it looks like a gcc bug > to me. Here is the relevant stuff from build.log, with the command line > truncated to make it readable: I am not the professional to judge, but I have seen -Werror going boink at several occasions when the compiler is updated, sometimes minor issues -- therefore I personally think it misdirected in release builds.
John your issue is most likely caused by MAKEOPTS="-j8" with distcc disabled. Jan as far as yours go please post the entire build.log so I can review. I am unable to duplicate using gcc-5.2.0
Created attachment 418258 [details] full build with gcc-5.2.0 with out issue I am just posting to show that I need more info to duplicate the issue. I been requested by upstream not to drop werror due to how we add pem support. Soon as I have more info I will be able to dig into this issue and get you all a solution.
Created attachment 418282 [details] Build log with GCC 4.9.3 with MAKEOPTS='-j1' I've attached a log of a build showing the issue with GCC 4.9.3, with MAKEOPTS set to '-j1'. This is from one of my systems that I saw this issue on, which usually runs with MAKEOPTS='-j4'. Interestingly, it hit this noticeably sooner than with a parallel build.
(In reply to Jory A. Pratt from comment #10) > Created attachment 418258 [details] > full build with gcc-5.2.0 with out issue > > I am just posting to show that I need more info to duplicate the issue. I > been requested by upstream not to drop werror due to how we add pem support. > Soon as I have more info I will be able to dig into this issue and get you > all a solution. I'm curious. Is -Werror needed to make PEM support actually work (in which case the code is itself inherently broken and should be fixed), or is it just needed for proper verification that it meets certifications (in which case it should be enabled for the builds used for certification, and during development, but really shouldn't be enabled for release builds unless explicitly requested)?
(In reply to Austin S. Hemmelgarn from comment #11) > Created attachment 418282 [details] > Build log with GCC 4.9.3 with MAKEOPTS='-j1' > > I've attached a log of a build showing the issue with GCC 4.9.3, with > MAKEOPTS set to '-j1'. This is from one of my systems that I saw this issue > on, which usually runs with MAKEOPTS='-j4'. Interestingly, it hit this > noticeably sooner than with a parallel build. I've done the same (MAKEOPTS="-j1" and "-j4" , ABI_X86="64" and "32 64") with gcc-4.9.3, and I cannot produce with my regular flags. Note that on my tests, I do not have any "'type' may be used uninitialized in this function" warning on pqg.c:1773:27 either, and that is the key here rather than the -Werror flag making it fatal. The only difference in the compiler commandline between your run and mine is that you're running -Os instead of -O2 , and you've got -fstack-protector-strong. After setting -Os in my flags, I am able to reproduce this error reliably.
Hmm, that's interesting. This is starting to sound more and more like it's an issue with GCC than with NSS. -Os has been known to break things in the past in odd ways (for example, trying to compile certain versions of Tor with certain versions of GCC with -Os enabled could cause an infinite loop). However, there is still the fact that the check for uninitialized variables is supposed to happen before the optimization passes, which leads to the question of why this only shows up with specific optimization levels (especially considering that -Os is mostly a subset of -O2).
(In reply to Austin S. Hemmelgarn from comment #14) > Hmm, that's interesting. > > This is starting to sound more and more like it's an issue with GCC than > with NSS. -Os has been known to break things in the past in odd ways (for > example, trying to compile certain versions of Tor with certain versions of > GCC with -Os enabled could cause an infinite loop). > > However, there is still the fact that the check for uninitialized variables > is supposed to happen before the optimization passes, which leads to the > question of why this only shows up with specific optimization levels > (especially considering that -Os is mostly a subset of -O2). To be honest the warning doesn't even make sense, where it is. 'type != [stuff]' is tested at least three times earlier on in this particular function; if the issue was -really- that it may be uninitialized, then would't it have triggered on earlier codelines? it seems that the value of type is set via: findQfromSeed(L, N, g, &vfy->seed, &Q, &Q_, &qseed_len, &hashtype, &type) ..which in and of itself is wrapped by the CHECKPARAM() macro, which essentially causes a failure-and-exit if findQfromSeed() != SECSuccess ... I wouldn't think that -Os would cause any codepaths here to optimize-out the setting of 'type', but maybe there is...? Either way, it seems the most correct solution here right now is to disallow -Os until this can be sorted out.
While I dislike the prospect of disabling -Os, I would tend to agree that until this gets fixed, it's the right thing to do. What has me really confused though is that somehow specifying an optimization level is impacting things that should be happening long before the compiler even considers optimization. This sounds like _really_ poor coding on the part of GCC.
(In reply to Austin S. Hemmelgarn from comment #16) > While I dislike the prospect of disabling -Os, I would tend to agree that > until this gets fixed, it's the right thing to do. > > What has me really confused though is that somehow specifying an > optimization level is impacting things that should be happening long before > the compiler even considers optimization. This sounds like _really_ poor > coding on the part of GCC. So, i just checked the optimization comparison between -Os and -O2 on my system, (gcc-4.9.3) and i think it's worth noting that -Os enables -finline-functions which is generally an -O3 optimization according to man gcc. Unfortunately, haking the nss ebuild to force -fno-inline-functions didn't achieve the desired results; and the only other difference between -Os and -O2 (-foptimize-strlen) i don't think would have any effect here.
(In reply to Ian Stakenvicius from comment #17) > So, i just checked the optimization comparison between -Os and -O2 on my > system, (gcc-4.9.3) and i think it's worth noting that -Os enables > -finline-functions which is generally an -O3 optimization according to man > gcc. Unfortunately, haking the nss ebuild to force -fno-inline-functions > didn't achieve the desired results; and the only other difference between > -Os and -O2 (-foptimize-strlen) i don't think would have any effect here. My guess would be that something outside of the optimizer is looking at the optimization level, and that is in turn somehow confusing some other bit of internal state, IOW, I don't think it's something directly enabled by -Os, but some unintentional side-effect of that particular switch being on the command line. I think there are some other things that get enabled by -Os that aren't in -O2, and I think there are also some that are in -O2 but not -Os. It might be instructive to see if -O3 produces the same results as -Os. However, that's all beside the most important point, which is that the variable check that is triggering this warning should be happening before the optimization pass, which means that either the check is getting reordered for some stupid reason, or that there is some significant cross-talk between the passes that shouldn't be happening.
Hmm, the ebuild overrides -O3 to -O2, so that's less than trivial to check. I just checked the GCC docs, -Os also disables the following options: -falign-functions -falign-jumps -falign-loops -falign-labels -freorder-blocks -freorder-blocks-and-partition -fprefetch-loop-arrays Personally, I doubt that turning off optimizations would directly impact this warning, but it might be worth a try.
(In reply to Austin S. Hemmelgarn from comment #19) > Hmm, the ebuild overrides -O3 to -O2, so that's less than trivial to check. > > I just checked the GCC docs, -Os also disables the following options: > -falign-functions > -falign-jumps > -falign-loops > -falign-labels > -freorder-blocks > -freorder-blocks-and-partition > -fprefetch-loop-arrays > > Personally, I doubt that turning off optimizations would directly impact > this warning, but it might be worth a try. GCC docs may say that, but my actual gcc config didn't match the docs. Do this to confirm: gcc -Os -Q --help=optimizers >/tmp/gcc-Os gcc -O2 -Q --help=optimizers >/tmp/gcc-O2 diff -u /tmp/gcc-O{s,2} I found with 4.9.3 there's only two differences, in the actual optimization features. Other internal operational differences of course can't be determined this way.
hmm, looks like I have another bug to file with GCC then.
=dev-libs/nss-3.21-r1 is still affected by this, verified with both GCC 4.93 and GCC 5.3.0.
-Werror is no longer used: http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9e67ae12a57068bd6ce8a455e6602b67b51206c7 this is standard Gentoo policy -- packages should not use -Werror
