Your message dated Mon, 1 Dec 2014 19:38:56 -0500
with message-id
<CANTw=MNhHUnHg0Yh8Z1=xnfi6ppzbatxzoqfwi++peh-u2b...@mail.gmail.com>
and subject line Re: Bug#769836: closed by Michael Gilbert
<mgilb...@debian.org> (Bug#769836: fixed in chromium-browser 39.0.2171.71-1)
has caused the Debian Bug report #769836,
regarding [chromium-browser] Please use -fexcess-precision=standard or
-ffloat-store instead of enabling sse2
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
769836: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769836
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: chromium-browser
Severity: serious
version: 38.0.2125.101-4
justification: i386 package must be compiled for i586
According to gcc documentation and my experience [1]:
>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 registers have more precision than the IEEE float and double
> types and the processor does not support operations rounding to those types.
> By default, -fexcess-precision=fast is in effect; this means that operations
> are carried out in the precision of the registers and that 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.
> -fexcess-precision=standard is not implemented for languages other than C,
> and has no effect if -funsafe-math-optimizations or -ffast-math is specified.
> On the x86, it also 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.
[1]
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Disappointments.html#Disappointments
signature.asc
Description: This is a digitally signed message part.
--- End Message ---
--- Begin Message ---
version: 39.0.2171.71-1
On Mon, Dec 1, 2014 at 11:03 AM, roucaries bastien:
> I am sorry but it work on sse but not on i387 is the sign of huge
> problem in the floating point computation.
Upsteam dropped support for < sse2. I do not have time to fight
against that. If someone is willing to step up with a patch set that
reverts that and can clearly continue to update those patches for the
entire jessie release cycle, I will consider it.
Until then, I consider detecting and documenting the situation as the
only sane solution.
Best wishes,
Mike
--- End Message ---
