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.
