Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[David Kastrup]

Federico Bruni  writes:

> Il giorno mer 5 feb 2020 alle 10:20, Thomas Morley
>  ha scritto:
>> FWIW,
>> cd gub
>> make LILYPOND_BRANCH=stable/2.20 lilypond
>> succeeded now on my machine, Ubuntu 18.04 64-bit
>
> I've run the same command in LilyDev, but the files generated are for
> 2.19.84. Is it normal?

Yes.  2.19.84 is a prerelease to 2.20.0 made from the stable branch.  It
is miles behind the unstable branch that is going to see its first
release of 2.21.0 comparatively soonish after 2.20.0 (which will not be
significantly different from 2.19.84) has been released.

-- 
David Kastrup

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Federico Bruni]

Il giorno mer 5 feb 2020 alle 10:20, Thomas Morley 
 ha scritto:

FWIW,
cd gub
make LILYPOND_BRANCH=stable/2.20 lilypond
succeeded now on my machine, Ubuntu 18.04 64-bit


I've run the same command in LilyDev, but the files generated are for 
2.19.84. Is it normal?


Here's the tail of the terminal output:

 print-success rule
python2 test-lily/upload.py --branch=stable/2.20 --url 


binary does not exist uploads/lilypond-2.19.84-2.linux-x86.sh
test result does not exist for lilypond-2.19.84-2.linux-x86.sh
binary does not exist uploads/lilypond-2.19.84-2.linux-64.sh
test result does not exist for lilypond-2.19.84-2.linux-64.sh
binary does not exist uploads/lilypond-2.19.84-2.linux-ppc.sh
test result does not exist for lilypond-2.19.84-2.linux-ppc.sh
binary does not exist uploads/lilypond-2.19.84-2.darwin-ppc.tar.bz2
test result does not exist for lilypond-2.19.84-2.darwin-ppc.tar.bz2
binary does not exist uploads/lilypond-2.19.84-2.darwin-x86.tar.bz2
test result does not exist for lilypond-2.19.84-2.darwin-x86.tar.bz2
binary does not exist uploads/lilypond-2.19.84-2.documentation.tar.bz2
binary does not exist uploads/lilypond-2.19.84-2.test-output.tar.bz2
binary does not exist uploads/lilypond-2.19.84-2.freebsd-x86.sh
test result does not exist for lilypond-2.19.84-2.freebsd-x86.sh
binary does not exist uploads/lilypond-2.19.84-2.freebsd-64.sh
test result does not exist for lilypond-2.19.84-2.freebsd-64.sh
binary does not exist uploads/lilypond-2.19.84-2.mingw.exe
test result does not exist for lilypond-2.19.84-2.mingw.exe



chgrp -R lilypond uploads/lilypond*
chmod -R g+rw uploads/lilypond*
python test-lily/test-binary.py 
/home/dev/gub/uploads/lilypond-2.19.84-2.linux-x86.sh
python test-lily/test-binary.py 
/home/dev/gub/uploads/lilypond-2.19.84-2.linux-64.sh
python test-lily/test-binary.py 
/home/dev/gub/uploads/lilypond-2.19.84-2.linux-ppc.sh
python test-lily/test-binary.py 
/home/dev/gub/uploads/lilypond-2.19.84-2.darwin-ppc.tar.bz2
python test-lily/test-binary.py 
/home/dev/gub/uploads/lilypond-2.19.84-2.darwin-x86.tar.bz2
python test-lily/test-binary.py 
/home/dev/gub/uploads/lilypond-2.19.84-2.freebsd-x86.sh
python test-lily/test-binary.py 
/home/dev/gub/uploads/lilypond-2.19.84-2.freebsd-64.sh
python test-lily/test-binary.py 
/home/dev/gub/uploads/lilypond-2.19.84-2.mingw.exe

python /home/dev/gub/test-lily/rsync-lily-doc.py \
 --upload gra...@lilypond.org:/var/www/lilypond/doc \
 --version-file 
/home/dev/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/out/VERSION 
\
 
/home/dev/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/out-www/online-root/

python /home/dev/gub/test-lily/rsync-test.py \
 --upload gra...@lilypond.org:/var/www/lilypond/test \
 --version-file 
/home/dev/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/out/VERSION 
\
 
/home/dev/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/out-www/online-root/
rsync --delay-updates --progress 
/home/dev/gub/uploads/lilypond-2.19.84.tar.gz 
gra...@lilypond.org:/var/www/lilypond/downloads/sources/v2.19
git --git-dir downloads/lilypond/git tag -m "" -a release/2.19.84-2 
git.sv.gnu.org/lilypond.git/stable/2.20
git --git-dir downloads/lilypond/git push 
ssh+ 
refs/tags/release/2.19.84-2:refs/tags/release/2.19.84-2
git tag -m "release of lilypond release/2.19.84-1 (2.19.84-2)"  
"gub-release-lilypond-2.19.84-2"

make -f lilypond.make update-versions




To upload, run:

   make lilypond-upload LILYPOND_BRANCH=stable/2.20 
LILYPOND_REPO_URL=


 nsis rule
python2 bin/gub tools::nsis
*** environment changed

   #new# 
PATH=/home/dev/gub/target/tools/root/usr/bin:/root/git-cl:/scripts/auxiliar:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
   
PATH=/home/dev/gub/target/tools/root/usr/bin:/home/dev/gub/target/tools/root/usr/bin:/root/git-cl:/scripts/auxiliar:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin


*** press ^C in 10s or suffer a full rebuild..calculating 
dependencies

Checking for iconv ... /usr/bin/iconv
Checking for g++ ... /usr/bin/g++
Checking for gcc ... /usr/bin/gcc
must rebuild[tools]: system::gcc system::g++ system::iconv
*** Stage: pkg_install (cross/gcc-core, linux-x86)
 cross/gcc conflicts with cross/gcc-core
   non-core cross/gcc already installed
 skipping request to install cross/gcc-core
 cross/gcc-doc conflicts with cross/gcc-core
   non-core cross/gcc already installed
 skipping request to install cross/gcc-core
 cross/gcc-runtime conflicts with cross/gcc-core
   non-core cross/gcc already installed
 skipping request to install cross/gcc-core

*** Stage: pkg_install (glibc-core, linux-x86)
 glibc conflicts with glibc-core
   non-core glibc already installed
 skipping request to install glibc-core
 glibc-doc conflicts with glibc-core
   non-core glibc already installed
 skipping request to install glibc-core

done
 rest rule
 all rule
 

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[David Kastrup]

Thomas Morley  writes:

> Am Di., 4. Feb. 2020 um 18:34 Uhr schrieb David Kastrup :
>>
>> "Phil Holmes"  writes:
>>
>> > - Original Message - From: "David Kastrup" 
>> >> Wow.  Ok, maybe I'll just apply this patch then (though I'll at
>> >> least
>> >> remove the conditioning on Apple here as the problem is rather likely
>> >> platform independent) and Phil may have another round.
>> >> --
>> >> David Kastrup
>> >
>> >
>> > Will kick this off again tomorrow.
>>
>> Thanks!
>>
>> --
>> David Kastrup
>>
>
> FWIW,
> cd gub
> make LILYPOND_BRANCH=stable/2.20 lilypond
> succeeded now on my machine, Ubuntu 18.04 64-bit

Again, I am impressed that this rather basic deal-breaker code
apparently occured only once in our code base.

-- 
David Kastrup

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Thomas Morley]

Am Di., 4. Feb. 2020 um 18:34 Uhr schrieb David Kastrup :
>
> "Phil Holmes"  writes:
>
> > - Original Message - From: "David Kastrup" 
> >> Wow.  Ok, maybe I'll just apply this patch then (though I'll at
> >> least
> >> remove the conditioning on Apple here as the problem is rather likely
> >> platform independent) and Phil may have another round.
> >> --
> >> David Kastrup
> >
> >
> > Will kick this off again tomorrow.
>
> Thanks!
>
> --
> David Kastrup
>

FWIW,
cd gub
make LILYPOND_BRANCH=stable/2.20 lilypond
succeeded now on my machine, Ubuntu 18.04 64-bit

Cheers,
  Harm

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[David Kastrup]

"Phil Holmes"  writes:

> - Original Message - From: "David Kastrup" 
>> Wow.  Ok, maybe I'll just apply this patch then (though I'll at
>> least
>> remove the conditioning on Apple here as the problem is rather likely
>> platform independent) and Phil may have another round.
>> -- 
>> David Kastrup
>
>
> Will kick this off again tomorrow.

Thanks!

-- 
David Kastrup

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 


Wow.  Ok, maybe I'll just apply this patch then (though I'll at least
remove the conditioning on Apple here as the problem is rather likely
platform independent) and Phil may have another round.

--
David Kastrup



Will kick this off again tomorrow.

--
Phil Holmes

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[David Kastrup]

David Kastrup  writes:

> Halving the useful range before overflows is a problem, so I'll stick
> with most of the guards.  Though I am skeptical that stuff exceeding I64
> has much of a chance of working well, anyway.

I have pushed a slightly modified version of the patch (removing the
__APPLE__ guard since that problem is likely only dependent on GCC
version) to stable-2.20.  Let's see where this gets us.

Thanks particularly to Masamichi Hosoda for some really impressive bug
hunt and fast proposing of solutions.

-- 
David Kastrup

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Jonas Hahnfeld]

Am Dienstag, den 04.02.2020, 11:08 -0500 schrieb Dan Eble:
> On Feb 4, 2020, at 11:02, Jonas Hahnfeld <
> hah...@hahnjo.de
> > wrote:
> > > That would be my impulse as well.  It is not like this code appears to
> > > have notable drawbacks for the unafflicted platforms.
> > 
> > Except for very funny overflows and negative signs if the value is too
> > large to fit into I64 ;-P
> > 
> > unsigned long long a = 0xC000;
> > signed long long b = a;
> > printf("%d\n", b);
> > -> -1073741824
> 
> That's already an ingredient of this recipe.
> 
>class Rational
>{
>  ...
>  U64 num_, den_;
>  ...
>  I64 numerator () const { return sign_ * num_; }
> 
> Yum!

Oh wow... I withdraw all my objections, it's already broken if we ever
reach that case.

Jonas


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

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Dan Eble]

On Feb 4, 2020, at 11:02, Jonas Hahnfeld  wrote:
>> That would be my impulse as well.  It is not like this code appears to
>> have notable drawbacks for the unafflicted platforms.
> 
> Except for very funny overflows and negative signs if the value is too
> large to fit into I64 ;-P
> 
> unsigned long long a = 0xC000;
> signed long long b = a;
> printf("%d\n", b);
> -> -1073741824

That's already an ingredient of this recipe.

   class Rational
   {
 ...
 U64 num_, den_;
 ...
 I64 numerator () const { return sign_ * num_; }

Yum!
— 
Dan

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[David Kastrup]

Jonas Hahnfeld  writes:

> Am Dienstag, den 04.02.2020, 16:57 +0100 schrieb David Kastrup:
>> Dan Eble <
>> d...@faithful.be
>> > writes:
>> 
>> > On Feb 4, 2020, at 09:44, Masamichi Hosoda <
>> > truer...@trueroad.jp
>> > > wrote:
>> > > +// FIXME: workaround: In GUB, g++ 4.9.4 for darwin-x86,
>> > > +// it seems that static cast from `unsigned long long` to `double`
>> > > +// by x86 SSE2 raises an internal compile error.
>> > > +// However, static cast from `signed long long` to `double`
>> > > +// does not raise the error.
>> > > +// So we use it for a workaround.
>> > > +#if defined (__i386__) && defined (__APPLE__) && \
>> > > +  defined (__SSE2_MATH__) && __GNUC__ < 5
>> > > +{
>> > > +  I64 inum = num_;
>> > > +  I64 iden = den_;
>> > > +  return static_cast (sign_) *
>> > > +static_cast (inum) / static_cast (iden);
>> > > +}
>> > > +#else
>> > > return (double)sign_ * (double)num_ / (double)den_;
>> > > +#endif
>> > 
>> > Is the conditional code really necessary?  Why not boil it down to the
>> > working code and a comment explaining the extra conversion to signed
>> > numbers?
>> 
>> That would be my impulse as well.  It is not like this code appears to
>> have notable drawbacks for the unafflicted platforms.
>
> Except for very funny overflows and negative signs if the value is too
> large to fit into I64 ;-P
>
> unsigned long long a = 0xC000;
> signed long long b = a;
> printf("%d\n", b);
> -> -1073741824

Halving the useful range before overflows is a problem, so I'll stick
with most of the guards.  Though I am skeptical that stuff exceeding I64
has much of a chance of working well, anyway.

-- 
David Kastrup

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Jonas Hahnfeld]

Am Dienstag, den 04.02.2020, 17:03 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> hah...@hahnjo.de
> > writes:
> 
> > Am Dienstag, den 04.02.2020, 10:38 -0500 schrieb Dan Eble:
> > > > On Feb 4, 2020, at 10:32, Jonas Hahnfeld <
> > > > hah...@hahnjo.de
> > > > 
> > > > > wrote:
> > > > 
> > > > Am Mittwoch, den 05.02.2020, 00:24 +0900 schrieb Masamichi Hosoda:
> > > > > > > $
> > > > > > > ~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.
> > > > > 
> > > > > 
> > > > > I didn't test full compiler works.
> > > > > However, If I understand correctly,
> > > > > it seems that static cast from `unsigned long long` to `double`
> > > > > is only in rational.cc.
> > > > 
> > > > What makes you think so? I think you're right it's the only place with
> > > > (double) casting, but I see a few with double (...) and some more with
> > > > Real (...).
> > > > In particular, flower/cpu-timer.cc casts variables of type clock_t -
> > > > I've yet to hunt down which type of integer this actually is.
> > > > 
> > > > Jonas
> > > 
> > > And what about size_t to Real?  There's some of that in the queue:
> > > https://codereview.appspot.com/563460043
> > > 
> > 
> > Apparently the build goes through. If I see this correctly, both
> > clock_t and size_t are "unsigned long".
> 
> Wow.  Ok, maybe I'll just apply this patch then (though I'll at least
> remove the conditioning on Apple here as the problem is rather likely
> platform independent) and Phil may have another round.

Do we have a guarantee that we never overflow with this cast?

Jonas


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

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[David Kastrup]

Jonas Hahnfeld  writes:

> Am Dienstag, den 04.02.2020, 10:38 -0500 schrieb Dan Eble:
>> > On Feb 4, 2020, at 10:32, Jonas Hahnfeld <
>> > hah...@hahnjo.de
>> > > wrote:
>> > 
>> > Am Mittwoch, den 05.02.2020, 00:24 +0900 schrieb Masamichi Hosoda:
>> > > > > $
>> > > > > ~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.
>> > > 
>> > > 
>> > > I didn't test full compiler works.
>> > > However, If I understand correctly,
>> > > it seems that static cast from `unsigned long long` to `double`
>> > > is only in rational.cc.
>> > 
>> > What makes you think so? I think you're right it's the only place with
>> > (double) casting, but I see a few with double (...) and some more with
>> > Real (...).
>> > In particular, flower/cpu-timer.cc casts variables of type clock_t -
>> > I've yet to hunt down which type of integer this actually is.
>> > 
>> > Jonas
>> 
>> And what about size_t to Real?  There's some of that in the queue:
>> https://codereview.appspot.com/563460043
>
> Apparently the build goes through. If I see this correctly, both
> clock_t and size_t are "unsigned long".

Wow.  Ok, maybe I'll just apply this patch then (though I'll at least
remove the conditioning on Apple here as the problem is rather likely
platform independent) and Phil may have another round.

-- 
David Kastrup

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Jonas Hahnfeld]

Am Dienstag, den 04.02.2020, 16:57 +0100 schrieb David Kastrup:
> Dan Eble <
> d...@faithful.be
> > writes:
> 
> > On Feb 4, 2020, at 09:44, Masamichi Hosoda <
> > truer...@trueroad.jp
> > > wrote:
> > > +// FIXME: workaround: In GUB, g++ 4.9.4 for darwin-x86,
> > > +// it seems that static cast from `unsigned long long` to `double`
> > > +// by x86 SSE2 raises an internal compile error.
> > > +// However, static cast from `signed long long` to `double`
> > > +// does not raise the error.
> > > +// So we use it for a workaround.
> > > +#if defined (__i386__) && defined (__APPLE__) && \
> > > +  defined (__SSE2_MATH__) && __GNUC__ < 5
> > > +{
> > > +  I64 inum = num_;
> > > +  I64 iden = den_;
> > > +  return static_cast (sign_) *
> > > +static_cast (inum) / static_cast (iden);
> > > +}
> > > +#else
> > > return (double)sign_ * (double)num_ / (double)den_;
> > > +#endif
> > 
> > Is the conditional code really necessary?  Why not boil it down to the
> > working code and a comment explaining the extra conversion to signed
> > numbers?
> 
> That would be my impulse as well.  It is not like this code appears to
> have notable drawbacks for the unafflicted platforms.

Except for very funny overflows and negative signs if the value is too
large to fit into I64 ;-P

unsigned long long a = 0xC000;
signed long long b = a;
printf("%d\n", b);
-> -1073741824

Jonas


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

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Jonas Hahnfeld]

Am Dienstag, den 04.02.2020, 10:38 -0500 schrieb Dan Eble:
> > On Feb 4, 2020, at 10:32, Jonas Hahnfeld <
> > hah...@hahnjo.de
> > > wrote:
> > 
> > Am Mittwoch, den 05.02.2020, 00:24 +0900 schrieb Masamichi Hosoda:
> > > > > $ ~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.
> > > 
> > > 
> > > I didn't test full compiler works.
> > > However, If I understand correctly,
> > > it seems that static cast from `unsigned long long` to `double`
> > > is only in rational.cc.
> > 
> > What makes you think so? I think you're right it's the only place with
> > (double) casting, but I see a few with double (...) and some more with
> > Real (...).
> > In particular, flower/cpu-timer.cc casts variables of type clock_t -
> > I've yet to hunt down which type of integer this actually is.
> > 
> > Jonas
> 
> And what about size_t to Real?  There's some of that in the queue:
> https://codereview.appspot.com/563460043

Apparently the build goes through. If I see this correctly, both
clock_t and size_t are "unsigned long".

Jonas


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

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[David Kastrup]

Dan Eble  writes:

> On Feb 4, 2020, at 09:44, Masamichi Hosoda  wrote:
>> 
>> +// FIXME: workaround: In GUB, g++ 4.9.4 for darwin-x86,
>> +// it seems that static cast from `unsigned long long` to `double`
>> +// by x86 SSE2 raises an internal compile error.
>> +// However, static cast from `signed long long` to `double`
>> +// does not raise the error.
>> +// So we use it for a workaround.
>> +#if defined (__i386__) && defined (__APPLE__) && \
>> +  defined (__SSE2_MATH__) && __GNUC__ < 5
>> +{
>> +  I64 inum = num_;
>> +  I64 iden = den_;
>> +  return static_cast (sign_) *
>> +static_cast (inum) / static_cast (iden);
>> +}
>> +#else
>> return (double)sign_ * (double)num_ / (double)den_;
>> +#endif
>
> Is the conditional code really necessary?  Why not boil it down to the
> working code and a comment explaining the extra conversion to signed
> numbers?

That would be my impulse as well.  It is not like this code appears to
have notable drawbacks for the unafflicted platforms.

-- 
David Kastrup

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Dan Eble]

> On Feb 4, 2020, at 10:32, Jonas Hahnfeld  wrote:
> 
> Am Mittwoch, den 05.02.2020, 00:24 +0900 schrieb Masamichi Hosoda:
 $ ~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.
>> 
>> 
>> I didn't test full compiler works.
>> However, If I understand correctly,
>> it seems that static cast from `unsigned long long` to `double`
>> is only in rational.cc.
> 
> What makes you think so? I think you're right it's the only place with
> (double) casting, but I see a few with double (...) and some more with
> Real (...).
> In particular, flower/cpu-timer.cc casts variables of type clock_t -
> I've yet to hunt down which type of integer this actually is.
> 
> Jonas

And what about size_t to Real?  There's some of that in the queue:
https://codereview.appspot.com/563460043
— 
Dan

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Dan Eble]

On Feb 4, 2020, at 09:44, Masamichi Hosoda  wrote:
> 
> +// FIXME: workaround: In GUB, g++ 4.9.4 for darwin-x86,
> +// it seems that static cast from `unsigned long long` to `double`
> +// by x86 SSE2 raises an internal compile error.
> +// However, static cast from `signed long long` to `double`
> +// does not raise the error.
> +// So we use it for a workaround.
> +#if defined (__i386__) && defined (__APPLE__) && \
> +  defined (__SSE2_MATH__) && __GNUC__ < 5
> +{
> +  I64 inum = num_;
> +  I64 iden = den_;
> +  return static_cast (sign_) *
> +static_cast (inum) / static_cast (iden);
> +}
> +#else
> return (double)sign_ * (double)num_ / (double)den_;
> +#endif

Is the conditional code really necessary?  Why not boil it down to the working 
code and a comment explaining the extra conversion to signed numbers?
— 
Dan

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Jonas Hahnfeld]

Am Mittwoch, den 05.02.2020, 00:24 +0900 schrieb Masamichi Hosoda:
> >> $ ~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.
> 
> 
> I didn't test full compiler works.
> However, If I understand correctly,
> it seems that static cast from `unsigned long long` to `double`
> is only in rational.cc.

What makes you think so? I think you're right it's the only place with
(double) casting, but I see a few with double (...) and some more with
Real (...).
In particular, flower/cpu-timer.cc casts variables of type clock_t -
I've yet to hunt down which type of integer this actually is.

Jonas


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

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Masamichi Hosoda]

>> $ ~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.

I didn't test full compiler works.
However, If I understand correctly,
it seems that static cast from `unsigned long long` to `double`
is only in rational.cc.

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: "Masamichi Hosoda" 
Cc: ; 
Sent: Tuesday, February 04, 2020 2:56 PM
Subject: Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW 
libraries (issue 577450043 by thomasmorle...@gmail.com)




Wouldn't the same problem occur on Windows?  We have 32bit executables
there as well.  Or is the compiler version we use there not afflicted?

--
David Kastrup


I'd suggest applying Hosoda-san's patch to stable/2.20 and I'll run Gub 
again.  If it runs OK, we're good.  If not, we can revert and rethink?


--
Phil Holmes 

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[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.
> 
> 
>>>From 2a3816e49067e026c7180dc6a3b2d5614d9c20d6 Mon Sep 17 00:00:00 2001
>> From: Masamichi Hosoda 
>> Date: Tue, 4 Feb 2020 23:30:29 +0900
>> Subject: [PATCH] Add workaround for avoiding GUB darwin-x86 error
>>
>> In GUB, g++ 4.9.4 for darwin-x86 (macOS x86),
>> it seems that static cast from  `unsigned long long` to `double`
>> by x86 SSE2 raises an internal compile error.
>> However, static cast from `signed long long` to `double`
>> does not raise the error.
>> So we use it for a workaround.
>>
>> i.e.
>> First, static cast from `unsigned long long` to `signed long long`.
>> Then, static cast from `singed long long` to `double`.
>> ---
>>  flower/rational.cc | 16 
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/flower/rational.cc b/flower/rational.cc
>> index 559e1646a0..9435edbb8f 100644
>> --- a/flower/rational.cc
>> +++ b/flower/rational.cc
>> @@ -31,7 +31,23 @@ double
>>  Rational::to_double () const
>>  {
>>if (sign_ == -1 || sign_ == 1 || sign_ == 0)
>> +// FIXME: workaround: In GUB, g++ 4.9.4 for darwin-x86,
>> +// it seems that static cast from `unsigned long long` to `double`
>> +// by x86 SSE2 raises an internal compile error.
>> +// However, static cast from `signed long long` to `double`
>> +// does not raise the error.
>> +// So we use it for a workaround.
>> +#if defined (__i386__) && defined (__APPLE__) && \
>> +  defined (__SSE2_MATH__) && __GNUC__ < 5
> 
> Wouldn't the same problem occur on Windows?  We have 32bit executables
> there as well.  Or is the compiler version we use there not afflicted?

Sorry, I forgot MinGW.
The internal compiler error seems to raise only in darwin-x86.
I don't have newer g++ for darwin-x86, so I'm not sure
if it was fixed in the newer g++.

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:36:5: warning: floating constant exceeds range of 'double' 
[-Woverflow]
 return -HUGE_VAL;
 ^
rational.cc:38:5: warning: floating constant exceeds range of 'double' 
[-Woverflow]
 return HUGE_VAL;
 ^
rational.cc: In member function 'double Rational::to_double() const':
rational.cc:43: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  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
$ ~gub/gub/target/mingw/root/usr/cross/bin/i686-mingw32-g++ -c -msse2 

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[David Kastrup]

Masamichi Hosoda  writes:

 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.


>>From 2a3816e49067e026c7180dc6a3b2d5614d9c20d6 Mon Sep 17 00:00:00 2001
> From: Masamichi Hosoda 
> Date: Tue, 4 Feb 2020 23:30:29 +0900
> Subject: [PATCH] Add workaround for avoiding GUB darwin-x86 error
>
> In GUB, g++ 4.9.4 for darwin-x86 (macOS x86),
> it seems that static cast from  `unsigned long long` to `double`
> by x86 SSE2 raises an internal compile error.
> However, static cast from `signed long long` to `double`
> does not raise the error.
> So we use it for a workaround.
>
> i.e.
> First, static cast from `unsigned long long` to `signed long long`.
> Then, static cast from `singed long long` to `double`.
> ---
>  flower/rational.cc | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/flower/rational.cc b/flower/rational.cc
> index 559e1646a0..9435edbb8f 100644
> --- a/flower/rational.cc
> +++ b/flower/rational.cc
> @@ -31,7 +31,23 @@ double
>  Rational::to_double () const
>  {
>if (sign_ == -1 || sign_ == 1 || sign_ == 0)
> +// FIXME: workaround: In GUB, g++ 4.9.4 for darwin-x86,
> +// it seems that static cast from `unsigned long long` to `double`
> +// by x86 SSE2 raises an internal compile error.
> +// However, static cast from `signed long long` to `double`
> +// does not raise the error.
> +// So we use it for a workaround.
> +#if defined (__i386__) && defined (__APPLE__) && \
> +  defined (__SSE2_MATH__) && __GNUC__ < 5

Wouldn't the same problem occur on Windows?  We have 32bit executables
there as well.  Or is the compiler version we use there not afflicted?

-- 
David Kastrup

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Jonas Hahnfeld]

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
> $
> ```
> 


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

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[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  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
$
```

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
$
```
>From 2a3816e49067e026c7180dc6a3b2d5614d9c20d6 Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda 
Date: Tue, 4 Feb 2020 23:30:29 +0900
Subject: [PATCH] Add workaround for avoiding GUB darwin-x86 error

In GUB, g++ 4.9.4 for darwin-x86 (macOS x86),
it seems that static cast from  `unsigned long long` to `double`
by x86 SSE2 raises an internal compile error.
However, static cast from `signed long long` to `double`
does not raise the error.
So we use it for a workaround.

i.e.
First, static cast from `unsigned long long` to `signed long long`.
Then, static cast from `singed long long` to `double`.
---
 flower/rational.cc | 16 
 1 file changed, 16 insertions(+)

diff --git a/flower/rational.cc b/flower/rational.cc
index 559e1646a0..9435edbb8f 100644
--- a/flower/rational.cc
+++ b/flower/rational.cc
@@ -31,7 +31,23 @@ double
 Rational::to_double () const
 {
   if (sign_ == -1 || sign_ == 1 || sign_ == 0)
+// FIXME: workaround: In GUB, g++ 4.9.4 for darwin-x86,
+// it seems that static cast from `unsigned long long` to `double`
+// by x86 SSE2 raises an internal compile error.
+// However, static cast from `signed long long` to `double`
+// does not raise the error.
+// So we use it for a workaround.
+#if defined (__i386__) && defined (__APPLE__) && \
+  defined (__SSE2_MATH__) && __GNUC__ < 5
+{
+  I64 inum = num_;
+  I64 iden = den_;
+

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[David Kastrup]

Masamichi Hosoda  writes:

>> 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.

-- 
David Kastrup

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[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`

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[David Kastrup]

ArnoldTheresius  writes:

> Thomas Morley-2 wrote
>> Am Sa., 1. Feb. 2020 um 16:49 Uhr schrieb David Kastrup 
>
>> dak@
>
>> :
>> ...
>> 
>> Ok, thanks for the explanation.
>> 
>> Iiuc, this would make this patch superfluous and it should be abandoned.
>> As I'm only shepherding it, I'll wait for Arnold.
>> For now I'll set the issue to 'waiting' to get it out of Jame's hairs for
>> now.
>> 
>> Tbh, I have no clue how to implement a -mfpmath=sse -msse2 option myself.
>> 
>> Thanks,
>>   Harm
>> 
>> P.S.
>> Just seen the patch at
>> https://codereview.appspot.com/565600045/
>
> Hello,
>
> check (examination routine) with the other command line options all work
> fine:
> a) -mfpmath=sse -msse2

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.

> b) -march=pentium4 -mfpmath=sse -msse2
> c) -march=pentium4 -mfpmath=sse -msse2 -Wl,--large-address-aware
>
> But, if no one can tell, how to set this command line option for compilation
> in GUB,
> I vote to continue this patch, and add a TODO comment next to the inline
> assembler call.
>
> ArnoldTheresius

To quote from Phil's report (from which one can also glean the current
version in use, at least in the file paths)

I would expect flower/rational.cc to be one of the earliest files GUB
tries to compile, so this might not be a rare occurence but a principal
problem with this compiler version and those options.

/home/gub/NewGub/gub/target/darwin-x86/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/flower/rational.cc:43:1:
internal compiler error: in gen_reg_rtx, at emit-rtl.c:838
}
^
librestrict:error:/home/gub/NewGub/gub/target/darwin-x86/root/usr/cross/libexec/gcc/i686-apple-darwin8/4.9.4/cc1plus:
tried to open () file 
/home/gub/NewGub/gub/target/tools/root/usr/lib/librestrict.so
librestrict:allowed:
/home/gub/NewGub/gub/target/darwin-x86
/tmp
/dev/null
/dev/urandom
/proc/self

/home/gub/NewGub/gub/target/darwin-x86/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/flower/rational.cc:43:1:
internal compiler error: Aborted
librestrict:error:/home/gub/NewGub/gub/target/darwin-x86/root/usr/cross/libexec/gcc/i686-apple-darwin8/4.9.4/cc1plus:
tried to open () file 
/home/gub/NewGub/gub/target/tools/root/usr/lib/librestrict.so
librestrict:allowed:
/home/gub/NewGub/gub/target/darwin-x86
/tmp
/dev/null
/dev/urandom
/proc/self
{standard input}:unknown:Undefined local symbol
L__ZNSs4_Rep10_M_destroyERKSaIcE$stub
i686-apple-darwin8-g++: internal compiler error: Aborted (program cc1plus)
librestrict:error:/home/gub/NewGub/gub/target/darwin-x86/root/usr/cross/bin/i686-apple-darwin8-g++:
tried to open () file 
/home/gub/NewGub/gub/target/tools/root/usr/lib/librestrict.so
librestrict:allowed:
/home/gub/NewGub/gub/target/darwin-x86
/tmp
/dev/null
/dev/urandom
/proc/self
Aborted (core dumped)
make[1]: *** [out/rational.o] Error 134
make[1]: Leaving directory
`/home/gub/NewGub/gub/target/darwin-x86/build/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/flower'
make: *** [all] Error 2
Command barfed: cd
/home/gub/NewGub/gub/target/darwin-x86/build/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20
&& make -j16 TARGET_PYTHON="/usr/bin/env python"


-- 
David Kastrup

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[ArnoldTheresius]

Thomas Morley-2 wrote
> Am Sa., 1. Feb. 2020 um 16:49 Uhr schrieb David Kastrup 

> dak@

> :
> ...
> 
> Ok, thanks for the explanation.
> 
> Iiuc, this would make this patch superfluous and it should be abandoned.
> As I'm only shepherding it, I'll wait for Arnold.
> For now I'll set the issue to 'waiting' to get it out of Jame's hairs for
> now.
> 
> Tbh, I have no clue how to implement a -mfpmath=sse -msse2 option myself.
> 
> Thanks,
>   Harm
> 
> P.S.
> Just seen the patch at
> https://codereview.appspot.com/565600045/

Hello,

check (examination routine) with the other command line options all work
fine:
a) -mfpmath=sse -msse2
b) -march=pentium4 -mfpmath=sse -msse2
c) -march=pentium4 -mfpmath=sse -msse2 -Wl,--large-address-aware

But, if no one can tell, how to set this command line option for compilation
in GUB,
I vote to continue this patch, and add a TODO comment next to the inline
assembler call.

ArnoldTheresius



--
Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[ArnoldTheresius]

Thomas Morley-2 wrote
> Am Sa., 1. Feb. 2020 um 16:49 Uhr schrieb David Kastrup 

> dak@

> :
> ...
> 
> Ok, thanks for the explanation.
> 
> Iiuc, this would make this patch superfluous and it should be abandoned.
> As I'm only shepherding it, I'll wait for Arnold.
> For now I'll set the issue to 'waiting' to get it out of Jame's hairs for
> now.
> 
> Tbh, I have no clue how to implement a -mfpmath=sse -msse2 option myself.
> 
> Thanks,
>   Harm
> 
> P.S.
> Just seen the patch at
> https://codereview.appspot.com/565600045/

I also do not know where to specify additional command line options
(specific to a program).
In GUB?
In a special config file in the LILYPOND source tree?

I do not see much trouble, if support for processors before pentuim4 on
Windows is dropped.
I would have no problem.

When working on the command line options for 32 bit Windows compilation,
you may consider the LARGEADDRESSAWARE problem, too:
Unitl now the memory usage of lilypond.exe is limited to 2 GB.
I mutally modified this flag in the EXE file and became able to compile my
most huge scores (more than 200 pages) - thus lilypond.exe is
LARGEADDRESSAWARE today, but it is not declared to be so.
MINGW only offers a linker option to set this flag, but no tool to modify it
after linking.

Command line option for SSE2 usage, as far as I configured it out:
  -march=pentium4 -mfpmath=sse -msse2
Command line option for gcc to set LARGEADDRESSAWARE during linking:
  -Wl,--large-address-aware

ArnoldTheresius



--
Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[ArnoldTheresius]

David Kastrup wrote
> Dan Eble 

> dan@

>  writes:
> 
> ...
> Hm.  Maybe
> 
> -mfpmath=sse
> 
> instead?  The problem with switching the whole FPU to reduced precision
> is that some library functions might not expect that, so it is making me
> queasy.  On the other hand, using SSE might have a negative performance?
> I just don't have a good idea what we are dealing with here.
> 
> -- 
> David Kastrup

At least SSE2 (supports double, not only single precision),
and minimal achritecture is 'pentium4' (may also need to be specified in the
command line options - found this information in some gcc handbook)

ArnoldTheresius



--
Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[ArnoldTheresius]

David Kastrup wrote
> ArnoldTheresius 

> Arnold.Wendl@

>  writes:
> 
> ...
> None of the following GCC options would help?
> ...
>-ffloat-store
> ...
>-fexcess-precision=style
> ...
>-ffast-math
> ...
> -- 
> David Kastrup

Only -ffloat-store did show the desired effect in a C program with typical
situations.
I did not check speed effect.

>float_opts_test-0.exe
Compilation configuration was default.
  as compiled:
Var - (1.0 / 7.0) = -7.928228386e-018
Var - OneSeventh() = -7.928228386e-018
X = 1.; z = X / 100.0; Y = 0.0; 100 times Y += z;
 X - Y = 6.938893904e-017
  i.e. 0 step(s) of IEEE-double difference
  after X87 config change:
Var - (1.0 / 7.0) = 0
Var - OneSeventh() = 0
X = 1.; z = X / 100.0; Y = 0.0; 100 times Y += z;
 X - Y = -4.440892099e-015
  i.e. -20 step(s) of IEEE-double difference

>float_opts_test-1.exe
Compilation configuration: -fexcess-precision=fast
  as compiled:
Var - (1.0 / 7.0) = -7.928228386e-018
Var - OneSeventh() = -7.928228386e-018
X = 1.; z = X / 100.0; Y = 0.0; 100 times Y += z;
 X - Y = 6.938893904e-017
  i.e. 0 step(s) of IEEE-double difference
  after X87 config change:
...

>float_opts_test-2.exe
Compilation configuration: -fexcess-precision=standard
  as compiled:
Var - (1.0 / 7.0) = -7.928228386e-018
Var - OneSeventh() = 0
X = 1.; z = X / 100.0; Y = 0.0; 100 times Y += z;
 X - Y = -4.440892099e-015
  i.e. -20 step(s) of IEEE-double difference
  after X87 config change:
...

>float_opts_test-3.exe
Compilation configuration: -ffast-math
  as compiled:
Var - (1.0 / 7.0) = -7.928228386e-018
Var - OneSeventh() = -7.928228386e-018
X = 1.; z = X / 100.0; Y = 0.0; 100 times Y += z;
 X - Y = 6.938893904e-017
  i.e. 0 step(s) of IEEE-double difference
  after X87 config change:
...

>float_opts_test-4.exe
Compilation configuration: -ffloat-store
  as compiled:
Var - (1.0 / 7.0) = 0
Var - OneSeventh() = 0
X = 1.; z = X / 100.0; Y = 0.0; 100 times Y += z;
 X - Y = -4.440892099e-015
  i.e. -20 step(s) of IEEE-double difference
  after X87 config change:
...

>float_opts_test-5.exe
Compilation configuration: -ffloat-store -O3
  as compiled:
Var - (1.0 / 7.0) = 0
Var - OneSeventh() = 0
X = 1.; z = X / 100.0; Y = 0.0; 100 times Y += z;
 X - Y = -4.440892099e-015
  i.e. -20 step(s) of IEEE-double difference
  after X87 config change:
...



Source code:

/* FILE: float_opts_test.c
 * compile for windows with several options
 * with MINGW installed in LILYDEV:
 *
 *  #!/bin/sh
 *  CNT=1
 *  CC=i686-w64-mingw32-gcc
 *  echo $CC $opt -ofloat_opts_test-0.exe float_opts_test.c
 *  $CC $opt -ofloat_opts_test-0.exe float_opts_test.c
 *  
 *  for opt in "-fexcess-precision=fast" "-fexcess-precision=standard"
"-ffast-math" \
 * "-ffloat-store" "-ffloat-store -O3"
 *   do
 *echo $CC $opt -DCOMPCONFIG='"'"$opt"'"' -ofloat_opts_test-$CNT.exe
float_opts_test.c
 *$CC $opt -DCOMPCONFIG='"'"$opt"'"' -ofloat_opts_test-$CNT.exe
float_opts_test.c
 *CNT=`expr $CNT + 1`
 *   done
 *
 */

#include 

void X87mantissa53(void)
{
  asm(
  " push %ebp"
"\n mov  $0x027f, %eax"
"\n push %eax"
"\n mov  %esp, %ebp"
"\n fldcw (%ebp)"
"\n pop %eax"
"\n pop %ebp"
  );
}

volatile double MyFraction;
volatile double X;

double OneSeventh(void)
{ double One = 1.0;
  double Seven = 7.0;
  return (One / Seven);
}

void TestSuite(void)
{
  union {
double d;
long long int i;
  } u1, u2;
  double One = 1.0;
  double Seven = 7.0;

  // first typical situation: compare stored value with recalculated value
  MyFraction = One / Seven;
  printf("Var - (1.0 / 7.0) = %.10lg\n", MyFraction - (One / Seven));

  // second typical situation: compare stored value with recalculated
function return value
  MyFraction = OneSeventh();
  printf("Var - OneSeventh() = %.10lg\n", MyFraction - OneSeventh());
 
  { // Don't use loops controlled by inexact floating point increment!
int cnt;
register double y; 
X = ((double) 1.0) / ((double) 1.0);
y = 100.0;
MyFraction = X / y;
y = 0.0;
for (cnt = 0; cnt < 100; cnt++) y += MyFraction;
MyFraction = y;

printf("X = 1.; z = X / 100.0; Y = 0.0; 100 times Y += z;\n
X - Y = %.10lg\n", X - y);
u1.d = X; u2.d = MyFraction;
printf("  i.e. %ld step(s) of IEEE-double difference\n", (long)
(u1.i - u2.i));
  }

}

int main(int argc, char *argv[])
{
#ifdef COMPCONFIG
  printf("Compilation configuration: %s\n", COMPCONFIG);
#else
  printf("Compilation configuration was default.\n");
#endif

  printf("  as compiled:\n");
  TestSuite();

  X87mantissa53();

  printf("  after X87 config change:\n");
  TestSuite();

  return 0;
}

ArnoldTheresius



--
Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Thomas Morley]

Am Sa., 1. Feb. 2020 um 16:49 Uhr schrieb David Kastrup :
>
> Thomas Morley  writes:
>
> > Am Sa., 1. Feb. 2020 um 12:39 Uhr schrieb David Kastrup :
> >>
> >> Dan Eble  writes:
> >>
> >> > On Feb 1, 2020, at 05:05, David Kastrup  wrote:
> >> >>
> >> >> Frankly, I think that it would be better if our Windows executables just
> >> >> moved to 64bit but that seems like the more complicated option yet. And
> >> >> 32bit systems kept around a whole lot longer even after processors
> >> >> became 64bit-capable because they tended to require less memory.
> >> >
> >> > You provided a lot of good information in your post, but the
> >> > conclusion was not entirely clear.
> >> > Are you suggesting requiring SSE2 at this time?
> >>
> >> Yes.  It appears to get used anyway for 64bit executables, and it seems
> >> safe enough to demand it for 32bit executables.
> >>
> >> For SSE there would be the danger of libraries stomping over the
> >> registers that share memory with the FPU stack, but I think that SSE2 is
> >> not affected.
> >>
> >> --
> >> David Kastrup
> >>
> >
> > Well, Arnold encountered the problem (iirc he will not be online
> > during the weekend) and there may several other older 32-bit OS
> > around.
> > What shoud those people do?
>
> Nothing?  I am currently proposing that we compile with
>
> -mfpmath=sse -msse2
>
> as options which should shift arithmetic off to the SSE2 instruction set
> which doesn't work with 80-bit arithmetic.  That would be a default way
> of compilation.
>
> --
> David Kastrup

Ok, thanks for the explanation.

Iiuc, this would make this patch superfluous and it should be abandoned.
As I'm only shepherding it, I'll wait for Arnold.
For now I'll set the issue to 'waiting' to get it out of Jame's hairs for now.

Tbh, I have no clue how to implement a -mfpmath=sse -msse2 option myself.

Thanks,
  Harm

P.S.
Just seen the patch at
https://codereview.appspot.com/565600045/

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Masamichi Hosoda]

> Nothing?  I am currently proposing that we compile with
> 
> -mfpmath=sse -msse2
> 
> as options which should shift arithmetic off to the SSE2 instruction set
> which doesn't work with 80-bit arithmetic.  That would be a default way
> of compilation.

I've created a patch for master.

https://sourceforge.net/p/testlilyissues/issues/5725/
https://codereview.appspot.com/565600045/

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[David Kastrup]

Thomas Morley  writes:

> Am Sa., 1. Feb. 2020 um 12:39 Uhr schrieb David Kastrup :
>>
>> Dan Eble  writes:
>>
>> > On Feb 1, 2020, at 05:05, David Kastrup  wrote:
>> >>
>> >> Frankly, I think that it would be better if our Windows executables just
>> >> moved to 64bit but that seems like the more complicated option yet. And
>> >> 32bit systems kept around a whole lot longer even after processors
>> >> became 64bit-capable because they tended to require less memory.
>> >
>> > You provided a lot of good information in your post, but the
>> > conclusion was not entirely clear.
>> > Are you suggesting requiring SSE2 at this time?
>>
>> Yes.  It appears to get used anyway for 64bit executables, and it seems
>> safe enough to demand it for 32bit executables.
>>
>> For SSE there would be the danger of libraries stomping over the
>> registers that share memory with the FPU stack, but I think that SSE2 is
>> not affected.
>>
>> --
>> David Kastrup
>>
>
> Well, Arnold encountered the problem (iirc he will not be online
> during the weekend) and there may several other older 32-bit OS
> around.
> What shoud those people do?

Nothing?  I am currently proposing that we compile with

-mfpmath=sse -msse2

as options which should shift arithmetic off to the SSE2 instruction set
which doesn't work with 80-bit arithmetic.  That would be a default way
of compilation.

-- 
David Kastrup

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Thomas Morley]

Am Sa., 1. Feb. 2020 um 12:39 Uhr schrieb David Kastrup :
>
> Dan Eble  writes:
>
> > On Feb 1, 2020, at 05:05, David Kastrup  wrote:
> >>
> >> Frankly, I think that it would be better if our Windows executables just
> >> moved to 64bit but that seems like the more complicated option yet. And
> >> 32bit systems kept around a whole lot longer even after processors
> >> became 64bit-capable because they tended to require less memory.
> >
> > You provided a lot of good information in your post, but the
> > conclusion was not entirely clear.
> > Are you suggesting requiring SSE2 at this time?
>
> Yes.  It appears to get used anyway for 64bit executables, and it seems
> safe enough to demand it for 32bit executables.
>
> For SSE there would be the danger of libraries stomping over the
> registers that share memory with the FPU stack, but I think that SSE2 is
> not affected.
>
> --
> David Kastrup
>

Well, Arnold encountered the problem (iirc he will not be online
during the weekend) and there may several other older 32-bit OS
around.
What shoud those people do?

Cheers,
  Harm

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[David Kastrup]

Masamichi Hosoda  writes:

 You provided a lot of good information in your post, but the
 conclusion was not entirely clear.
 Are you suggesting requiring SSE2 at this time?
>>> 
>>> Yes.  It appears to get used anyway for 64bit executables, and it seems
>>> safe enough to demand it for 32bit executables.
>> 
>> +1
>> far better than inline asm poking control registers
>
> The cause of the issues is that
> the unexpected precision conversions raises small difference
> in floating-point calculation.
>
> If libguile uses x87 FPU, high-precision calculation
> and low-precision calculation coexist inside GUILE,
> and precision conversion occurs between them.
>
> Even if C++ uses SSE2,
> libguile and other shared libraries still may use x87 FPU.
>
> I wonder this may cause problems.

As I said: we go through the same code paths in Guile every time (and
floating point numbers are passed on the stack in double size, not
extended double), so as opposed to compilation to assembly language, the
results should be the same for multiple invocations of the same formula.

So I don't think we'd trigger the problems we see now.  And math
routines in libguile might not expect the FPU to be in an unconventional
mode.

-- 
David Kastrup

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Masamichi Hosoda]

>>> You provided a lot of good information in your post, but the
>>> conclusion was not entirely clear.
>>> Are you suggesting requiring SSE2 at this time?
>> 
>> Yes.  It appears to get used anyway for 64bit executables, and it seems
>> safe enough to demand it for 32bit executables.
> 
> +1
> far better than inline asm poking control registers

The cause of the issues is that
the unexpected precision conversions raises small difference
in floating-point calculation.

If libguile uses x87 FPU, high-precision calculation
and low-precision calculation coexist inside GUILE,
and precision conversion occurs between them.

Even if C++ uses SSE2,
libguile and other shared libraries still may use x87 FPU.

I wonder this may cause problems.

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Dan Eble]

On Feb 1, 2020, at 06:39, David Kastrup  wrote:
> 
>> You provided a lot of good information in your post, but the
>> conclusion was not entirely clear.
>> Are you suggesting requiring SSE2 at this time?
> 
> Yes.  It appears to get used anyway for 64bit executables, and it seems
> safe enough to demand it for 32bit executables.

+1
far better than inline asm poking control registers
— 
Dan

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[David Kastrup]

Dan Eble  writes:

> On Feb 1, 2020, at 05:05, David Kastrup  wrote:
>> 
>> Frankly, I think that it would be better if our Windows executables just
>> moved to 64bit but that seems like the more complicated option yet. And
>> 32bit systems kept around a whole lot longer even after processors
>> became 64bit-capable because they tended to require less memory.
>
> You provided a lot of good information in your post, but the
> conclusion was not entirely clear.
> Are you suggesting requiring SSE2 at this time?

Yes.  It appears to get used anyway for 64bit executables, and it seems
safe enough to demand it for 32bit executables.

For SSE there would be the danger of libraries stomping over the
registers that share memory with the FPU stack, but I think that SSE2 is
not affected.

-- 
David Kastrup

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Dan Eble]

On Feb 1, 2020, at 05:05, David Kastrup  wrote:
> 
> Frankly, I think that it would be better if our Windows executables just
> moved to 64bit but that seems like the more complicated option yet. And
> 32bit systems kept around a whole lot longer even after processors
> became 64bit-capable because they tended to require less memory.

You provided a lot of good information in your post, but the conclusion was not 
entirely clear.
Are you suggesting requiring SSE2 at this time?
— 
Dan

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[David Kastrup]

Masamichi Hosoda  writes:

>> Hm.  Maybe
>> 
>> -mfpmath=sse
>> 
>> instead?  The problem with switching the whole FPU to reduced precision
>> is that some library functions might not expect that, so it is making me
>> queasy.  On the other hand, using SSE might have a negative performance?
>> I just don't have a good idea what we are dealing with here.
>
> In my experiment, `-fexcess-precision=standard` cannot be used for C++.
>
> ```
> $ g++ -fexcess-precision=standard test.cc
> cc1plus: sorry, unimplemented: -fexcess-precision=standard for C++
>
> $ g++ --version
> g++ (GCC) 7.4.0
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
>
> $
> ```
>
> On the other hand, `-msse -mfpmath=sse` uses SSE,
> which can only perform single-precision floating-point calculation.
> SSE is too low precision.
>
> `-msse2 -mfpmath=sse` uses SSE2,
> which can perform double-precision floating-point calculation.
> Precision is sufficient, but older 32-bit x86 CPUs do not have SSE2.

According to https://en.wikipedia.org/wiki/SSE2 , SSE2 was implemented
by Intel in 2000 and then by AMD in 2003.

All 64bit-mode capable CPUs support it, and for better or worse, that's
very likely what we are catering for today even if our Windows
executables are still 32bit.  For the 32bit-only processors, I quote
from Wikipedia:

The following IA-32 CPUs support SSE2:

Intel NetBurst-based CPUs (Pentium 4, Xeon, Celeron, Pentium D, Celeron D)
Intel Pentium M and Celeron M
Intel Atom
AMD Athlon 64
Transmeta Efficeon
VIA C7

The following IA-32 CPUs were released after SSE2 was developed, but did not 
implement it:

AMD CPUs prior to Athlon 64, such as Athlon XP
VIA C3
Transmeta Crusoe
Intel Quark

So basically we'd be leaving Athlon XP in the cold (all other processors
seem even less relevant).

We also have:

SSE2 is also a requirement for installing Windows 8[3] (and later)
or Microsoft Office 2013 (and later) "to enhance the reliability of
third-party apps and drivers running in Windows 8".[4]

Frankly, I think that it would be better if our Windows executables just
moved to 64bit but that seems like the more complicated option yet.  And
32bit systems kept around a whole lot longer even after processors
became 64bit-capable because they tended to require less memory.

-- 
David Kastrup

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Masamichi Hosoda]

>> This sounds promising.
>>
>>>   -fexcess-precision=standard is not implemented for languages
>>>   other than C.
>>
>> Never mind.
> 
> Hm.  Maybe
> 
> -mfpmath=sse
> 
> instead?  The problem with switching the whole FPU to reduced precision
> is that some library functions might not expect that, so it is making me
> queasy.  On the other hand, using SSE might have a negative performance?
> I just don't have a good idea what we are dealing with here.

In my experiment, `-fexcess-precision=standard` cannot be used for C++.

```
$ g++ -fexcess-precision=standard test.cc
cc1plus: sorry, unimplemented: -fexcess-precision=standard for C++

$ g++ --version
g++ (GCC) 7.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$
```

On the other hand, `-msse -mfpmath=sse` uses SSE,
which can only perform single-precision floating-point calculation.
SSE is too low precision.

`-msse2 -mfpmath=sse` uses SSE2,
which can perform double-precision floating-point calculation.
Precision is sufficient, but older 32-bit x86 CPUs do not have SSE2.

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[thomasmorley65]

On 2020/01/31 10:45:42, trueroad wrote:
> Hello Arnold.
> Thank you for your patch.
> 
> If I understand correctly, we only need check the definitions of
`__x86__` and
> `__i386__` check.
> 
> In x86_64 environment, neither `__x86__` nor `__i386__` are defined.
> 
> ```
> $ echo | x86_64-w64-mingw32-gcc -dM -E - | grep "__x86__"
> 
> $ echo | x86_64-w64-mingw32-gcc -dM -E - | grep "__i386__"
> 
> $ echo | i686-w64-mingw32-gcc -dM -E - | grep "__x86__"
> 
> $ echo | i686-w64-mingw32-gcc -dM -E - | grep "__i386__"
> #define __i386__ 1
> 
> $
> ```
> 
> Therefore, `defined (__code_model_32__)`  is not necessary.
> 
> If `__SSE2_MATH__` is defined, it only indicates that main.cc is
compiled with
> SSE2 math enabled.
> Shared libraries such as libguile may still use x86 FPU.
> If the floating point calculation inside GUILE uses x86 FPU, we need
to set the
> precision even if C++ uses SSE2.
> 
> Therefore, `defined (__SSE2_MATH__)`  is not necessary.
> 
> Furthermore, if the floating-point operations of all modules use SSE2,
setting
> the x86 FPU precision has no effect because it is not used.
> In other words, there is no problem even if the precision is set on a
platform
> that does not need to set.
> 
> Therefore, environment definitions such as `defined (__MINGW32__)`  is
not
> necessary.

Per accident I've done a new Rietveld issue while updating current patch
witch Masamichi-san's suggestions (Hopefully without mistakes).
Please look here:
https://codereview.appspot.com/575600043/


https://codereview.appspot.com/577450043/

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[David Kastrup]

Dan Eble  writes:

> On Jan 31, 2020, at 08:31, David Kastrup  wrote:
>>   -fexcess-precision=style
>>   This option allows further control over excess precision on
>>   machines where floating-point operations occur in a format
>>   with more precision or range than the IEEE standard and
>>   interchange floating-point types.  By default,
>>   -fexcess-precision=fast is in effect; this means that
>>   operations may be carried out in a wider precision than the
>>   types specified in the source if that would result in faster
>>   code, and it is unpredictable when rounding to the types
>>   specified in the source code takes place.
>
> This sounds promising.
>
>>   -fexcess-precision=standard is not implemented for languages
>>   other than C.
>
> Never mind.

Hm.  Maybe

-mfpmath=sse

instead?  The problem with switching the whole FPU to reduced precision
is that some library functions might not expect that, so it is making me
queasy.  On the other hand, using SSE might have a negative performance?
I just don't have a good idea what we are dealing with here.

-- 
David Kastrup

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[David Kastrup]

Masamichi Hosoda  writes:

>>>   -fexcess-precision=style
>>>   This option allows further control over excess precision on
>>>   machines where floating-point operations occur in a format
>>>   with more precision or range than the IEEE standard and
>>>   interchange floating-point types.  By default,
>>>   -fexcess-precision=fast is in effect; this means that
>>>   operations may be carried out in a wider precision than the
>>>   types specified in the source if that would result in faster
>>>   code, and it is unpredictable when rounding to the types
>>>   specified in the source code takes place.
>> 
>> This sounds promising.
>
> If I understand correctly, such compiler options are not promising.
>
> Even if LilyPond C++ source codes are compiled with such option,
> libguile without the option may calculate in a wider precision.
> In this case, the floating point calculation
> inside GUILE causes these issues.

The problem as far as I can see are non-reproducible results, and the
Guile code paths do not change from one call to the next.  So unless
just-in-time compilation comes into play, I don't think that Guile
behavior should be a problem concerning our non-reproducibility problem.

-- 
David Kastrup

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Masamichi Hosoda]

>>   -fexcess-precision=style
>>   This option allows further control over excess precision on
>>   machines where floating-point operations occur in a format
>>   with more precision or range than the IEEE standard and
>>   interchange floating-point types.  By default,
>>   -fexcess-precision=fast is in effect; this means that
>>   operations may be carried out in a wider precision than the
>>   types specified in the source if that would result in faster
>>   code, and it is unpredictable when rounding to the types
>>   specified in the source code takes place.
> 
> This sounds promising.

If I understand correctly, such compiler options are not promising.

Even if LilyPond C++ source codes are compiled with such option,
libguile without the option may calculate in a wider precision.
In this case, the floating point calculation
inside GUILE causes these issues.

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Dan Eble]

On Jan 31, 2020, at 08:31, David Kastrup  wrote:
>   -fexcess-precision=style
>   This option allows further control over excess precision on
>   machines where floating-point operations occur in a format
>   with more precision or range than the IEEE standard and
>   interchange floating-point types.  By default,
>   -fexcess-precision=fast is in effect; this means that
>   operations may be carried out in a wider precision than the
>   types specified in the source if that would result in faster
>   code, and it is unpredictable when rounding to the types
>   specified in the source code takes place.

This sounds promising.

>   -fexcess-precision=standard is not implemented for languages
>   other than C.

Never mind.
— 
Dan

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[David Kastrup]

ArnoldTheresius  writes:

> trueroad wrote
>> Hello Arnold.
>> Thank you for your patch.
>> 
>> If I understand correctly, we only need check the definitions of
>> `__x86__` and `__i386__` check.
>> 
>> In x86_64 environment, neither `__x86__` nor `__i386__` are defined.
>> 
>> ```
>> $ echo | x86_64-w64-mingw32-gcc -dM -E - | grep "__x86__"
>> 
>> $ echo | x86_64-w64-mingw32-gcc -dM -E - | grep "__i386__"
>> 
>> $ echo | i686-w64-mingw32-gcc -dM -E - | grep "__x86__"
>> 
>> $ echo | i686-w64-mingw32-gcc -dM -E - | grep "__i386__"
>> #define __i386__ 1
>> 
>> $
>> ```
>> 
>> Therefore, `defined (__code_model_32__)`  is not necessary.
>> 
>> If `__SSE2_MATH__` is defined, it only indicates that main.cc is
>> compiled with SSE2 math enabled.
>> Shared libraries such as libguile may still use x86 FPU.
>> If the floating point calculation inside GUILE uses x86 FPU, we need to
>> set the precision even if C++ uses SSE2.
>> 
>> Therefore, `defined (__SSE2_MATH__)`  is not necessary.
>> 
>> Furthermore, if the floating-point operations of all modules use SSE2,
>> setting the x86 FPU precision has no effect because it is not used.
>> In other words, there is no problem even if the precision is set on a
>> platform that does not need to set.
>> 
>> Therefore, environment definitions such as `defined (__MINGW32__)`  is
>> not necessary.
>> 
>> 
>> https://codereview.appspot.com/577450043/
>
> Thank you for the clear answer.
>
> Therfore, do it as suggested [move asm() call closer to _FPU_SETCW() call]
>
> ArnoldTheresius.
>
>
>
>
> --
> Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html

None of the following GCC options would help?

   The following options control compiler behavior regarding
   floating-point arithmetic.  These options trade off between speed
   and correctness.  All must be specifically enabled.

   -ffloat-store
   Do not store floating-point variables in registers, and
   inhibit other options that might change whether a floating-
   point value is taken from a register or memory.

   This option prevents undesirable excess precision on machines
   such as the 68000 where the floating registers (of the 68881)
   keep more precision than a "double" is supposed to have.
   Similarly for the x86 architecture.  For most programs, the
   excess precision does only good, but a few programs rely on
   the precise definition of IEEE floating point.  Use
   -ffloat-store for such programs, after modifying them to store
   all pertinent intermediate computations into variables.

   -fexcess-precision=style
   This option allows further control over excess precision on
   machines where floating-point operations occur in a format
   with more precision or range than the IEEE standard and
   interchange floating-point types.  By default,
   -fexcess-precision=fast is in effect; this means that
   operations may be carried out in a wider precision than the
   types specified in the source if that would result in faster
   code, and it is unpredictable when rounding to the types
   specified in the source code takes place.  When compiling C,
   if -fexcess-precision=standard is specified then excess
   precision follows the rules specified in ISO C99; in
   particular, both casts and assignments cause values to be
   rounded to their semantic types (whereas -ffloat-store only
   affects assignments).  This option is enabled by default for C
   if a strict conformance option such as -std=c99 is used.
   -ffast-math enables -fexcess-precision=fast by default
   regardless of whether a strict conformance option is used.

   -fexcess-precision=standard is not implemented for languages
   other than C.  On the x86, it has no effect if -mfpmath=sse or
   -mfpmath=sse+387 is specified; in the former case, IEEE
   semantics apply without excess precision, and in the latter,
   rounding is unpredictable.

   -ffast-math
   Sets the options -fno-math-errno, -funsafe-math-optimizations,
   -ffinite-math-only, -fno-rounding-math, -fno-signaling-nans,
   -fcx-limited-range and -fexcess-precision=fast.

   This option causes the preprocessor macro "__FAST_MATH__" to
   be defined.

   This option is not turned on by any -O option besides -Ofast
   since it can result in incorrect output for programs that
   depend on an exact implementation of IEEE or ISO
   rules/specifications for math functions. It may, however,
   yield faster code for programs that do not require the
   guarantees of these specifications.

-- 
David Kastrup

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[ArnoldTheresius]

trueroad wrote
> Hello Arnold.
> Thank you for your patch.
> 
> If I understand correctly, we only need check the definitions of
> `__x86__` and `__i386__` check.
> 
> In x86_64 environment, neither `__x86__` nor `__i386__` are defined.
> 
> ```
> $ echo | x86_64-w64-mingw32-gcc -dM -E - | grep "__x86__"
> 
> $ echo | x86_64-w64-mingw32-gcc -dM -E - | grep "__i386__"
> 
> $ echo | i686-w64-mingw32-gcc -dM -E - | grep "__x86__"
> 
> $ echo | i686-w64-mingw32-gcc -dM -E - | grep "__i386__"
> #define __i386__ 1
> 
> $
> ```
> 
> Therefore, `defined (__code_model_32__)`  is not necessary.
> 
> If `__SSE2_MATH__` is defined, it only indicates that main.cc is
> compiled with SSE2 math enabled.
> Shared libraries such as libguile may still use x86 FPU.
> If the floating point calculation inside GUILE uses x86 FPU, we need to
> set the precision even if C++ uses SSE2.
> 
> Therefore, `defined (__SSE2_MATH__)`  is not necessary.
> 
> Furthermore, if the floating-point operations of all modules use SSE2,
> setting the x86 FPU precision has no effect because it is not used.
> In other words, there is no problem even if the precision is set on a
> platform that does not need to set.
> 
> Therefore, environment definitions such as `defined (__MINGW32__)`  is
> not necessary.
> 
> 
> https://codereview.appspot.com/577450043/

Thank you for the clear answer.

Therfore, do it as suggested [move asm() call closer to _FPU_SETCW() call]

ArnoldTheresius.




--
Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[trueroad]

Hello Arnold.
Thank you for your patch.

If I understand correctly, we only need check the definitions of
`__x86__` and `__i386__` check.

In x86_64 environment, neither `__x86__` nor `__i386__` are defined.

```
$ echo | x86_64-w64-mingw32-gcc -dM -E - | grep "__x86__"

$ echo | x86_64-w64-mingw32-gcc -dM -E - | grep "__i386__"

$ echo | i686-w64-mingw32-gcc -dM -E - | grep "__x86__"

$ echo | i686-w64-mingw32-gcc -dM -E - | grep "__i386__"
#define __i386__ 1

$
```

Therefore, `defined (__code_model_32__)`  is not necessary.

If `__SSE2_MATH__` is defined, it only indicates that main.cc is
compiled with SSE2 math enabled.
Shared libraries such as libguile may still use x86 FPU.
If the floating point calculation inside GUILE uses x86 FPU, we need to
set the precision even if C++ uses SSE2.

Therefore, `defined (__SSE2_MATH__)`  is not necessary.

Furthermore, if the floating-point operations of all modules use SSE2,
setting the x86 FPU precision has no effect because it is not used.
In other words, there is no problem even if the precision is set on a
platform that does not need to set.

Therefore, environment definitions such as `defined (__MINGW32__)`  is
not necessary.


https://codereview.appspot.com/577450043/

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[ArnoldTheresius]

Dan Eble wrote
> On Jan 30, 2020, at 05:17, 

> trueroad@

>  wrote:
>> 
>> How about this patch?
>> Sorry, not tested.
> 
> Bringing the _FPU_SETCW() branch and the asm() branch closer together is
> an improvement.
> (I don't have the resources to test this patch.)

Yes,
bringing _FPU_SETCW() and asm() closer together is a good idea.

I added some fprintf output around this asm() just in case I did catch an
architecure where this assembler call would cause a 'premature exit'.

I think, we need some additional checks of preprocessor defines, when NOT to
execute the inline assembler!
Originally I did only compare the preprocessor defines for
* mingw 32-bit x87 - needs SETCW
* mingw 32-bit sse2 - does not need SETCW - I do not know if SETCW will
harm!
* mingw 64-bit - does not neet SETCW - I do not know if SETCW will harm!

On my LILYDEV I added mingw, but I have no idea how to add all the other
target compilers GUB uses.
Especially I did not find, which package form the debian DVDs to install to
get the two DARWIN targets.
So I have a problem to check, which preprocessor checks to include - I could
just restrict it to MINGW until now

Can anyone create the lists of the preprocessor defines for (some of) the
other gcc targets?
I just looked up, it should be the command line »*gcc -dM -E« (prepend the
target name before gcc) to output this predefines to standard output (where
it can be directed into a file).

ArnoldTheresius,
   the initiator of this patch.
('Arnold' on the German Lilypond Forum)



--
Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[trueroad]

How about this patch?
Sorry, not tested.

If I understand correctly,
this patch solves not only Issue 4943 but also Issue 4975.
These issues do not only occur on Windows, but on all x86 platforms
except Linux.
`defined (__MINGW32__)` is not necessary.

For Linux-x86, it uses the original precision setting. i.e. _FPU_SETCW
().
For other x86 platforms, it uses Arnold's inline asm for setting
precision.

```
diff --git a/lily/main.cc b/lily/main.cc
index 9145345fff..cba6856159 100644
--- a/lily/main.cc
+++ b/lily/main.cc
@@ -209,19 +209,40 @@ char const *LILYPOND_DATADIR = PACKAGE_DATADIR "/"
TOPLEVEL_VERSION;
unpredictable places. To get around this, we tell the x87 FPU to use
only
double precision. Note that this is not needed for x86_64 because
that uses
the SSE unit by default instead of the x87 FPU. */
-#if ((defined (__x86__) || defined (__i386__)) \
-  && defined (HAVE_FPU_CONTROL_H) && (HAVE_FPU_CONTROL_H == 1))
+#if defined (__x86__) || defined (__i386__)
+// This environment is x86.
+// It is necessary that setting precision by setting x87 FPU control
word.
 
+#if defined (HAVE_FPU_CONTROL_H) && (HAVE_FPU_CONTROL_H == 1)
 #include 
+#endif
+
 static void
 configure_fpu ()
 {
+#if defined (HAVE_FPU_CONTROL_H) && (HAVE_FPU_CONTROL_H == 1)
+  // This environment has fpu_control.h. (e.g. Linux glibc)
+  // We use _FPU_SETCW () to set x87 FPU control word.
   fpu_control_t fpu_control = 0x027f;
   _FPU_SETCW (fpu_control);
+#else
+  // This environment doesn't have fpu_control.h. (e.g. MinGW)
+  // We use inline asm to set x87 FPU control word.
+  asm(
+  " push %ebp"
+"\n mov  $0x027f, %eax"
+"\n push %eax"
+"\n mov  %esp, %ebp"
+"\n fldcw (%ebp)"
+"\n pop %eax"
+"\n pop %ebp"
+  );
+#endif
 }
 
 #else
-
+// This environment isn't x86. (e.g. x86_64)
+// It is unnecessary that setting precision.
 static void
 configure_fpu ()
 {
-- 
```



https://codereview.appspot.com/577450043/

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[thomasmorley65]

https://codereview.appspot.com/577450043/diff/579260043/lily/main.cc
File lily/main.cc (right):

https://codereview.appspot.com/577450043/diff/579260043/lily/main.cc#newcode174
lily/main.cc:174: /* x86 defaults to using 80-bit extended precision
arithmetic. This can cause
On 2020/01/29 23:54:27, Dan Eble wrote:
> I missed this comment the first time around because Rietveld hid it. 
This
> explains the situation well.

Well, this comment was not part of current patch

https://codereview.appspot.com/577450043/

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[nine . fierce . ballads]

https://codereview.appspot.com/577450043/diff/579260043/lily/main.cc
File lily/main.cc (right):

https://codereview.appspot.com/577450043/diff/579260043/lily/main.cc#newcode174
lily/main.cc:174: /* x86 defaults to using 80-bit extended precision
arithmetic. This can cause
I missed this comment the first time around because Rietveld hid it. 
This explains the situation well.

https://codereview.appspot.com/577450043/diff/579260043/lily/main.cc#newcode210
lily/main.cc:210: "\n mov  $0x027f, %eax"
It would be very nice if this magic number and the one in line 186 were
not separately defined.

https://codereview.appspot.com/577450043/

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[thomasmorley65]

On 2020/01/29 22:36:03, Carl wrote:
> While this answer is specific, it could be clearer, IMO:
> 
> Reviewing the Intel Manuals at 
>
https://software.intel.com/sites/default/files/managed/a4/60/253665-sdm-vol-1.pdf
> Section 4.2.2.
> 
> We can see that the 64 bit significand of Double Extended Precision
refers to an
> 80-bit floating point representation, and the 53-bit significand of
Double
> Precision refers to a 64-bit floating point representation.
> 
> I think if we just leave the 64/53 bit numbers in the comment, the
reader might
> think we are not using 64-bit floating-point representations.

Carl, I'm shepherding this patch for Arnold.
I'll point him to the review-comments, can't say anything about it
myself.

https://codereview.appspot.com/577450043/

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Carl . D . Sorensen]

While this answer is specific, it could be clearer, IMO:

Reviewing the Intel Manuals at 
https://software.intel.com/sites/default/files/managed/a4/60/253665-sdm-vol-1.pdf
Section 4.2.2.

We can see that the 64 bit significand of Double Extended Precision
refers to an 80-bit floating point representation, and the 53-bit
significand of Double Precision refers to a 64-bit floating point
representation.

I think if we just leave the 64/53 bit numbers in the comment, the
reader might think we are not using 64-bit floating-point
representations.


https://codereview.appspot.com/577450043/

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[nine . fierce . ballads]

The comment could be more helpful.  Explaining what this code does is
more important than explaining that it replaces something that no longer
exists.

I've found this documentation on the x87 FPU Control Word:
http://home.agh.edu.pl/~amrozek/x87.pdf
Section 8.1.4.

It looks like the value 0x027f changes the Precision Control (PC) field
from the default of "Double Extended Precision (64 bits)" (value 3) to
"Double Precision (53 bits)" (value 2).

https://codereview.appspot.com/577450043/

Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[thomasmorley65]

Reviewers: ,

Description:
Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries

Issue 4943
As Issue 4943 on Windows compilation was triggered by
missing _FPU_SETCW() in the MINGW libraries, an alternate call to
initiate the X87 FPU setup as an inline-assembler command is added
- for MINGW 32 Bit compilation only.

Please review this at https://codereview.appspot.com/577450043/

Affected files (+24, -0 lines):
  M lily/main.cc


Index: lily/main.cc
diff --git a/lily/main.cc b/lily/main.cc
index 
4834ff82aa9b6bb649bfe8fbe863877b56c819d1..cfb04d86f8d0b200c3a6e15ae8a36960b31570fa
 100644
--- a/lily/main.cc
+++ b/lily/main.cc
@@ -192,6 +192,30 @@ configure_fpu ()
 static void
 configure_fpu ()
 {
+#if ((defined (__x86__) || defined (__i386__)) \
+  && defined (__MINGW32__) && defined (__code_model_32__) && 
!defined(__SSE2_MATH__))
+  /* If this is a MINGW compilation (for Windows),
+   * but not using SSE2 arithmetic unit nor is a 64 bit compilation (which 
uses SSE2 by default)
+   * _FPU_SETCW() got lost in the MINGW libraries!
+   * Here is an inline assembler call to execute the same task for the X87 
arithmetic unit.
+   *
+   * TODO: output a message what we're going to do here, _only_ if DEBUG level 
is selected,
+   *   but configure_fpu() is called before the commandline options get 
evaluated.
+   *   At the moment the info message will be blanked on the console, but 
if output is
+   *   directed into a file, most editors will show it.
+   */
+  fprintf(stderr, " X87 FPU setup via asm() ... ");
+  asm(
+  " push %ebp"
+"\n mov  $0x027f, %eax"
+"\n push %eax"
+"\n mov  %esp, %ebp"
+"\n fldcw (%ebp)"
+"\n pop %eax"
+"\n pop %ebp"
+  );
+  fprintf(stderr, "done.\r \r");
+#endif /* (defined(__x86__) || defined(__i386__)) && defined (__MINGW32__) && 
defined (__code_model_32__) && !defined(__SSE2_MATH__) */
 }
 
 #endif /* defined(__x86__) || defined(__i386__) */