Re: [lmi] "Implicit int" vs. '-fms-extensions'

[Vadim Zeitlin]

On Tue, 11 Jun 2019 22:39:19 +0000 Greg Chicares <address@hidden> wrote:

GC> I figured we should use the same flags for everything we build, viz.
GC>   {lmi, wx, wxpdf, libxml2, libxslt, libexslt}
GC> but just adding '-fno-omit-frame-pointer' for the xmlsoft.org libraries
GC> led to an ICE with MinGW-w64 gcc-8:
GC> 
GC> <ICE>
GC> 
GC> during RTL pass: final
GC> hash.c: In function ???stubHashScannerFull???:
GC> hash.c:834:1: internal compiler error: in based_loc_descr, at 
dwarf2out.c:14330
GC>  }
GC> + ^
GC> Please submit a full bug report,
GC> with preprocessed source if appropriate.
GC> See <https://gcc.gnu.org/bugs/> for instructions.
GC> make[3]: *** [Makefile:1252: hash.lo] Error 1
GC> 
GC> and similar 'dwarf2out.c:14330' errors for other '.lo' files.
GC> 
GC> Searching online leads to this 2019-05-11 error report:
GC>   https://sourceforge.net/p/mingw-w64/bugs/802/
GC> which specifies '-fno-omit-frame-pointer'; it has received no reply.
GC> 
GC> This ICE somewhat resembles the one reported here:
GC> 
GC>   https://lists.nongnu.org/archive/html/lmi/2019-03/msg00026.html
GC> | internal compiler error: in 
GC> | based_loc_descr, at dwarf2out.c:14318
GC> |      {return;}
GC> |              ^
GC> 
GC> in that both fail in the same function, but at different lines:
GC>   in based_loc_descr, at dwarf2out.c:14330 [32-bit msw, today]
GC>   in based_loc_descr, at dwarf2out.c:14318 [64-bit msw, 2019-03-23]
GC> and the solution for both is not to use '-fno-omit-frame-pointer'.

 Yes, it definitely looks like another manifestation of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86593 to me. Unfortunately it
seems like the fix for it didn't make it into 8.3 release neither, so we
can only wait for gcc-9.

GC> </ICE>
GC> 
GC> Anyway, commit a9bcf09ec414 turns off 'fms-extensions' for everything
GC> except the xml and xslt libraries, and it does work with MinGW-w64 gcc-8.
GC> I'm dissatisfied with the changes to 'install_wx*.sh' for reasons that
GC> will be obvious. Vadim, is there a clean way to write this? We had all
GC> 'configure' options neatly arranged in one double-quoted multiline
GC> variable, but I couldn't figure out how to make an assignment with spaces
GC> like:
GC>   wx_cxx_flags='-fno-ms-extensions -fno-omit-frame-pointer -frounding-math'
GC> work inside that variable.

 The only way to make it work that I see is to set IFS to newline which has
to be done using a literal newline to be portable, I think, i.e.

---------------------------------- >8 --------------------------------------
IFS='
'
---------------------------------- >8 --------------------------------------

If we do it like this, shell will only split config_options between the
lines but not on the spaces appearing inside each line (nor tabs, but we
don't use them anyhow), which is exactly what we want here. Changing IFS is
not that unusual, and so I think it's a decent workaround. Moreover, for
once, it doesn't even provoke any shellcheck warnings (other than the
already disabled SC2086, of course).

 To be complete, I'm quite certain that it's impossible to do what you want
without changing IFS: as long as it contains space, we can't use (double)
quotes around "$config_options" because this would prevent word-splitting
completely and we do need it to pass separate arguments to configure
instead of one huge one. But if we don't use quotes, the string is split on
any spaces, including the ones appearing inside $wx_cc_flags embedded into
it.


GC> Furthermore, I'm somewhat confused because 'install_wx.sh' prints this:
GC> 
GC> "$proxy_wx_dir"/configure $config_options CFLAGS="$wx_cc_flags" 
CXXFLAGS="$wx_cxx_flags"
GC> 
GC> + /cache_for_lmi/vcs/wxWidgets/configure --prefix=/opt/lmi/local 
--exec-prefix=/opt/lmi/local/gcc_x
GC> 86_64-w64-mingw32 --build=x86_64-pc-linux-gnu --host=x86_64-w64-mingw32 
--disable-apple_ieee --disa
GC> ble-aui --disable-compat30 --disable-dependency-tracking 
--disable-fswatcher --disable-gif --disabl
GC> e-mediactrl --disable-precomp-headers --disable-propgrid --disable-ribbon 
--disable-richtext --disa
GC> ble-stc --disable-webview --enable-monolithic --enable-option-checking 
--enable-shared --enable-stl
GC>  
--enable-vendor=x86_64-w64-mingw32-8.3-win32-f741031e69de73d5816cc56e99c9beba3ac820de
 --with-cxx=1
GC> 1 --with-expat=builtin --with-libpng=builtin --with-zlib=builtin 
--without-opengl --without-subdirs
GC>  CPPFLAGS=-I/opt/lmi/local/include 
LDFLAGS=-L/opt/lmi/local/gcc_x86_64-w64-mingw32/lib CFLAGS=-fno-
GC> ms-extensions -fno-omit-frame-pointer -frounding-math 
CXXFLAGS=-fno-ms-extensions -fno-omit-frame-p
GC> ointer -frounding-math
GC> 
GC> without any apparent quotes around the CFLAGS and CXXFLAGS options, which
GC> looks wrong.

 I think that this is just how shell tracing works in dash: it doesn't show
the original input and it's not supposed to be used as input. E.g. even
this simple example shows it:

        % sh -xc 'foo="bar baz"'
        + foo=bar baz

Interestingly, bash does show the quotes, but of a different kind:

        % bash -xc 'foo="bar baz"'
        + foo='bar baz'

FWIW, this is almost surely explained by the fact that it does expansion
before tracing.

GC> I.e., the output for wx itself lacks quotes, but the output
GC> for the libtiff and expat submodules is single-quoted:
GC> 
GC>   'CXXFLAGS=-fno-ms-extensions -fno-omit-frame-pointer -frounding-math'
GC> 
GC> but all seems well because the intended options are used, e.g.:
GC> 
GC>   x86_64-w64-mingw32-g++ -c -o monodll_any.o
GC>   ... -I/opt/lmi/local/include -O2 -fno-ms-extensions 
-fno-omit-frame-pointer -frounding-math
GC>   /cache_for_lmi/vcs/wxWidgets/src/common/any.cpp

 Yes, I do think it works correctly and it's just the shell output which is
confusing.

GC> Finally, 'gui_test.sh' and 'nychthemeral_test.sh' both succeed,
GC> including (proprietary) system testing, so this commit is good
GC> except for the ugly quoting in 'install_wx*.sh'.

 I think setting IFS would be less ugly but, to be honest, I don't feel
very strongly about it one way or the other, and it could be argued that
not fiddling with IFS is simpler and more clear.

 Regards,
VZ

pgprFFonzDV_x.pgp
Description: PGP signature