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
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
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
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
"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.
>> --
>>
- 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
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__
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
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
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,
>>
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:
> > > >
> > > >
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:
>> > > > > $
>> > > > >
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
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
> > >
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
> 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
>>
$
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`
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
>> $ ~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
- 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
> 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
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
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
>>> 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.
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
> 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
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
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
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
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
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
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
> 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.
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
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
> >>
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
>>> 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
>
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
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
>>
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
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
>> 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
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 |
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
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
>>>
>> -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
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
>
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 |
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
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 |
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
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
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,
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
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
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
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
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
-
58 matches
Mail list logo
