lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW librarie


From: Jonas Hahnfeld
Subject: Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by address@hidden)
Date: Tue, 04 Feb 2020 15:54:30 +0100
User-agent: Evolution 3.34.3

Am Dienstag, den 04.02.2020, 23:44 +0900 schrieb Masamichi Hosoda:
> >>> We currently have the problem that the compiler used in GUB for
> 
> >>> compiling 32bit binaries gets an internal compiler fault for those
> 
> >>> options.
> 
> >>> 
> 
> >>> We'll need to figure out whether a newer compiler does the trick, and if
> 
> >>> it does, update GUB.  Or find a different way of proceeding.
> 
> >>> 
> 
> >>> I'll see whether I can convince my current compilers to generate 32bit
> 
> >>> code and see whether those are currently up to using those options.  If
> 
> >>> current compilers don't want them, we'll need to revert to a different
> 
> >>> plan.
> 
> >>
> 
> >> It seems that static cast from `unsigned long long` to `double`
> 
> >> by x86 SSE2 raises the internal compile error.
> 
> >> However, static cast from `signed long long` to `double`
> 
> >> does not raise the errir.
> 
> >> I think it can be a workaround for rational.cc.
> 
> >>
> 
> >> i.e.
> 
> >> First, static cast from `unsigned long long` to `signed long long`
> 
> >> Then, static cast from `singed long long` to `double`
> 
> > 
> 
> > Oh wow.  I would never have thought one could identify something as
> 
> > specific.  I think I have convinced my system to build a 32bit Guile,
> 
> > but have problems convincing LilyPond to do the same.  So I cannot help
> 
> > with debugging this situation yet or even finding out whether it
> 
> > persists into newer compiler versions.
> 
> 
> I've attached the workaround patch for stable/2.20 branch.
> The results of my experiment is here.
> 
> Current stable/2.20 bcad34e31d7866eb126e73abc89eeeb01faf081f without the 
> patch:
> 
> ```
> $ ~gub/gub/target/darwin-x86/root/usr/cross/bin/i686-apple-darwin8-g++ -c 
> -msse2 -mfpmath=sse -I include -I .. rational.cc
> rational.cc: In member function 'double Rational::to_double() const':
> rational.cc:48:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:838
>  }
>  ^
> 0x773934 gen_reg_rtx(machine_mode)
>         /home/gub/gub/target/darwin-x86/src/cross/gcc-4.9.4/gcc/emit-rtl.c:838
> 0xc53c53 gen_split_4130(rtx_def*, rtx_def**)
>         
> /home/gub/gub/target/darwin-x86/src/cross/gcc-4.9.4/gcc/config/i386/sse.md:884
> 0x7772a7 try_split(rtx_def*, rtx_def*, int)
>         
> /home/gub/gub/target/darwin-x86/src/cross/gcc-4.9.4/gcc/emit-rtl.c:3444
> 0x8feb71 split_insn
>         /home/gub/gub/target/darwin-x86/src/cross/gcc-4.9.4/gcc/recog.c:2897
> 0x9034e4 split_all_insns()
>         /home/gub/gub/target/darwin-x86/src/cross/gcc-4.9.4/gcc/recog.c:2987
> 0x903578 rest_of_handle_split_after_reload
>         /home/gub/gub/target/darwin-x86/src/cross/gcc-4.9.4/gcc/recog.c:3938
> 0x903578 execute
>         /home/gub/gub/target/darwin-x86/src/cross/gcc-4.9.4/gcc/recog.c:3967
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <
> http://gcc.gnu.org/bugs.html
> > for instructions.
> $ ~gub/gub/target/linux-x86/root/usr/cross/bin/i686-linux-g++ -c -msse2 
> -mfpmath=sse -I include -I .. rational.cc
> $ ~gub/gub/target/freebsd-x86/root/usr/cross/bin/i686-freebsd6-g++ -c -msse2 
> -mfpmath=sse -I include -I .. rational.cc

So this only affects darwin-x86 which confirms my observation that
linux-x86 still works. AFAICS darwin-x86 never had a fpu_control.h, so
I'd propose to drop -msse2 -mfpmath=sse for i686-apple-darwin8.
This unblocks the release and the situation on darwin-x86 remains the
same as before, but we have the fix for linux-x86 and mingw.

My fear is that not only rational.cc is affected, but also many other
files. Did you test if a full compile works? If no, I'm against adding
workarounds for all files that suffer from the compiler error.

Regards,
Jonas

> $
> ```
> 
> Current stable/2.20 bcad34e31d7866eb126e73abc89eeeb01faf081f with the patch:
> 
> ```
> $ ~gub/gub/target/darwin-x86/root/usr/cross/bin/i686-apple-darwin8-g++ -c 
> -msse2 -mfpmath=sse -I include -I .. rational.cc
> rational.cc:52:5: warning: floating constant exceeds range of 'double' 
> [-Woverflow]
>      return -HUGE_VAL;
>      ^
> rational.cc:54:5: warning: floating constant exceeds range of 'double' 
> [-Woverflow]
>      return HUGE_VAL;
>      ^
> $ ~gub/gub/target/linux-x86/root/usr/cross/bin/i686-linux-g++ -c -msse2 
> -mfpmath=sse -I include -I .. rational.cc
> $ ~gub/gub/target/freebsd-x86/root/usr/cross/bin/i686-freebsd6-g++ -c -msse2 
> -mfpmath=sse -I include -I .. rational.cc
> $
> ```
> 

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]