Date: Sat, 21 Sep 2019 14:35:09 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 240629] [exp-run] Against projects/clang900-import branch Message-ID: <bug-240629-7788-y9FackhNxL@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-240629-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-240629-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240629 --- Comment #6 from Dimitry Andric <dim@FreeBSD.org> --- Ok, at least I have been able to reproduce the gcc failures on a cleanly installed VM. It looks like in such an environment, the gencondmd.c tool is compiled with= out any optimization, causing the references to e.g. ix86_isa_flags and similar variables, which are declared in gcc's options.h, but do not seem to be actually *defined* anywhere. For some reason, on my own machine, gencondmd.c is compiled with -O2 -pipe,= and that causes all the references to disappear, hence there are no linking err= ors. As to *why* that is, I'm still in the dark. Gcc's build system is notoriou= sly muddy, so it is hard to see where the options are coming from, and what is supposed to happen. In short: 1) For the initial generator tools such as 'gencondmd' the flag -DGENERATOR_FILE is used, causing option flags such as ix86_isa_flags to be declared as global extern variables. 2) However, there is no clear location where these global variables are *defined*, as options.c only has them as members of a gcc_option struct. 3) By accident, the references to these non-existing symbols can get optimi= zed out, since they are all in unused inline functions. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-240629-7788-y9FackhNxL>