Bug 255760 - lang/gcc10: Work around bootstrap issues with llvm 12
Summary: lang/gcc10: Work around bootstrap issues with llvm 12
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-toolchain (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-05-10 21:14 UTC by Dimitry Andric
Modified: 2022-01-22 00:25 UTC (History)
4 users (show)

See Also:


Attachments
Add -O1 to configure's stage1_cflags (480 bytes, patch)
2021-05-10 21:14 UTC, Dimitry Andric
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitry Andric freebsd_committer freebsd_triage 2021-05-10 21:14:11 UTC
Created attachment 224818 [details]
Add -O1 to configure's stage1_cflags

As show in the exp-run for llvm 12 (see bug 255570), the gcc ports which default to a full bootstrap fail, because of some code in the generators (gencondmd, etc) which appears to depend on references to non-existing global variables (e.g. ix86_isa_flags and others) being optimized away:

http://package22.nyi.freebsd.org/data/mainamd64PR255570-default/2021-05-08_16h02m24s/logs/gcc10-10.3.0.log

c++ -std=gnu++98   -g -DIN_GCC    -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -DGENERATOR_FILE -fno-PIE -fstack-protector-strong  -no-pie -o build/gencondmd \
    build/gencondmd.o build/errors.o ../build-x86_64-portbld-freebsd14.0/libiberty/libiberty.a
c++: warning: argument unused during compilation: '-no-pie' [-Wunused-command-line-argument]
ld: error: undefined symbol: ix86_isa_flags
>>> referenced by subst.md:140 (/wrkdirs/usr/ports/lang/gcc10/work/gcc-10.3.0/gcc/config/i386/subst.md:140)
>>>               build/gencondmd.o:(__cxx_global_var_init.101)
>>> referenced by subst.md:71 (/wrkdirs/usr/ports/lang/gcc10/work/gcc-10.3.0/gcc/config/i386/subst.md:71)
>>>               build/gencondmd.o:(__cxx_global_var_init.101)
>>> referenced by sse.md:5429 (/wrkdirs/usr/ports/lang/gcc10/work/gcc-10.3.0/gcc/config/i386/sse.md:5429)
>>>               build/gencondmd.o:(__cxx_global_var_init.101)
>>> referenced 2268 more times

ld: error: undefined symbol: ix86_isa_flags2
>>> referenced by i386.md:21062 (/wrkdirs/usr/ports/lang/gcc10/work/gcc-10.3.0/gcc/config/i386/i386.md:21062)
>>>               build/gencondmd.o:(__cxx_global_var_init.101)
>>> referenced by sse.md:22985 (/wrkdirs/usr/ports/lang/gcc10/work/gcc-10.3.0/gcc/config/i386/sse.md:22985)
>>>               build/gencondmd.o:(__cxx_global_var_init.101)
>>> referenced by sse.md:23115 (/wrkdirs/usr/ports/lang/gcc10/work/gcc-10.3.0/gcc/config/i386/sse.md:23115)
>>>               build/gencondmd.o:(__cxx_global_var_init.101)
>>> referenced 26 more times

[...many more...]

While this problem is being looked at from a few angles, I did manage to come up with a workaround, which is to add -O1 to the stage1_cflags variable in the top-level configure script. This causes the generator programs to be compiled with at least *some* optimization, so the non-existing references are longer a problem.

If needed, this patch can also be be applied only in case the host compiler is clang *and* its version is 12.0.0 or later.

Note also that this patch does nothing if the bootstrap is disabled. In that case, gcc's build process simply uses the hosts's CFLAGS for compiling the generator tools, and the linking issues to no occur.
Comment 1 Gerald Pfeifer freebsd_committer freebsd_triage 2021-05-11 12:58:49 UTC
As usual - it's not the first time I'm seeing you in action - I am
impressed by your debugging and analytic skills, dim@. :-)

Thank you!

Can you give me a day or two? I have a vague memory of a potential
alternative approach that is GCC-specific (and that may or may not
work) and will update us all here.
Comment 2 Dimitry Andric freebsd_committer freebsd_triage 2021-05-11 16:25:28 UTC
I'm unblocking bug 255570 from this one, since I will commit the reversal of an upstream LLVM commit that works around the issue for now, so we can have another go at the exp-run.

Meanwhile, it is still interesting, I think, to attempt to get at the bottom of this. The global_options initializer got introduced back in 2010, here:

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e3339d0f3328e3bae21e460dde81ba4bdcfcd959

but I'm not sure how the mechanism to build genconmd and the other generator tools worked before that. It seems to have depended on __builtin_constant_p since ~2005:

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=7445392c29b2b16391e41bee61cfbe32d492ddf5#patch3
Comment 3 Ed Maste freebsd_committer freebsd_triage 2021-05-11 16:43:31 UTC
> I will commit the reversal of an upstream LLVM commit that works around
> the issue for now

Yes this makes sense to me, and we likely need to involve both LLVM and GCC developers/community in discussion of the right longer-term fix.
Comment 4 Gerald Pfeifer freebsd_committer freebsd_triage 2021-05-13 19:27:25 UTC
(In reply to Dimitry Andric from comment #2)
> I'm unblocking bug 255570 from this one, since I will commit the reversal
> of an upstream LLVM commit that works around the issue for now, so we can
> have another go at the exp-run.

Sounds good, thank you!

In the meantime I did some digging, and setting STAGE1_CFLAGS="-O1" 
and STAGE1_CXXFLAGS="-O1" might work instead of the patch, though I
believe Piotr tried this once and it did not solve the issue he was
looking into.

I also found the following in GCC's installation documentation, which may
provide some pointers?

  You can place non-default optimization flags into @code{BOOT_CFLAGS}; they
  are less well tested here than the default of @samp{-g -O2}, but should
  still work.  In a few cases, you may find that you need to specify special
  flags such as @option{-msoft-float} here to complete the bootstrap; or,
  if the native compiler miscompiles the stage1 compiler, you may need
  to work around this, by choosing @code{BOOT_CFLAGS} to avoid the parts
  of the stage1 compiler that were miscompiled, or by using @samp{make
  bootstrap4} to increase the number of stages of bootstrap.

  @code{BOOT_CFLAGS} does not apply to bootstrapped target libraries.
  Since these are always compiled with the compiler currently being
  bootstrapped, you can use @code{CFLAGS_FOR_TARGET} to modify their
  compilation flags, as for non-bootstrapped target libraries.
  Again, if the native compiler miscompiles the stage1 compiler, you may
  need to work around this by avoiding non-working parts of the stage1
  compiler.  Use @code{STAGE1_TFLAGS} to this end.

(In reply to Ed Maste from comment #3)
> Yes this makes sense to me, and we likely need to involve both LLVM and
> GCC developers/community in discussion of the right longer-term fix.

Dim had some more detailed observations in an e-mail. I hope sharing
those with gcc@gcc.gnu.org and the LLVM folks may lead to a resolution.

(What shall we do with this PR which is assigned to me right now? Reassign
to toolchain@?)
Comment 5 Gerald Pfeifer freebsd_committer freebsd_triage 2022-01-22 00:25:25 UTC
Let me close this since the LLVM change has been reverted. Should this
also be an issue with GCC 12 (and maybe GCC 11) I suggest raising this
with upstream GCC - the gcc@gcc.gnu.org list.