32/64 bit cc differences

[JohnF]

Shouldn't that be "-m32"?
http://gcc.gnu.org/onlinedocs/gcc-4.7.3/gcc/
i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options

Actually, I tried both, and neither was recognized by that
particular gcc. But what I particularly wanted was to compare
the behavior of 32-bit vs 64-bit float, regardless of other
architecture differences, and my reading was that -m32-bit
was the more relevant switch. But you're right that if both
worked, I'd have tried compiling all four possible ways,
seen what differences/samenesses in the output occurred,
and proceeded from there.

Just Google "man gcc"; that's available nearly everywhere. S

Sure, I looked on my own box, and elsewheres, too.
But that only showed both -m32's should have been recognized.
I'd hoped the man page on the box where they didn't work
would reveal why not.

 

[Kaz Kylheku]

If CGI imposes a requirement to write binary data to stdout,
then I'm sure there's a solution; I just have no idea what
it is.

The obvious solution (to that and any "host" of other problems, no pun
intended) is to use a Unix-like system for a webserver with CGI programs.

Which anyone who isn't out of their freaking mind generally does.

 

[Keith Thompson]

Actually, I tried both, and neither was recognized by that
particular gcc. But what I particularly wanted was to compare
the behavior of 32-bit vs 64-bit float, regardless of other
architecture differences, and my reading was that -m32-bit
was the more relevant switch. But you're right that if both
worked, I'd have tried compiling all four possible ways,
seen what differences/samenesses in the output occurred,
and proceeded from there.

I don't think you're encountering 32-bit vs. 64-bit float. Types
`float` and `double` are typically 32 and 64 bits, respectively,
on both 32-bit and 64-bit systems. There are differences in the
representation of `long double`, and in how intermediate results
are stored.

(I've worked on systems where `float` and `double` are both 64 bits,
but they were Cray vector machines.)

 

[Andrew Cooper]

I believe your "as gotten 10 mins ago" code is current.
But if the following remark seems wrong, maybe download again.
I agree that the float result called "temp" in ran1() won't
be portable. But it's not used anywhere, any more. Instead,
there's now that "static long iran;" near the top of the module
that's the only result actually used now. And that's a
completely integer calculation.
If you look real, real carefully, you'll see you can
invoke it as fm -r 0 -etc, which will revert to the original
rng usage. That's there just so stuff which was previously
encrypted can still be decrypted. And then, yeah, in that
case you better not try to decrypt with a 64-bit executable
if you encrypted with a 32-bit one. I guess that's what
all that gpl stuff about no "warranty of merchantability"
is all about

Apologies for being curt, but:

I really don't care what your C code says. It compiles differently
under 32bit and 64bit, using different floating point units in the x86
architecture. It will not generate the same stream of random numbers.
Your 32bit and 64bit binaries will not be capable of decrypting each
others outputs.

Looking at the thread so far, it is very likely that you have made your
"1 byte in 1000" problem substantially rarer, but you really have not
removed it entirely. You cannot use floating point numbers of any kind
and have any expectation of determinism.

~Andrew

 

[James Kuyper]

On 15/01/2014 09:47, JohnF wrote: .... ....
Apologies for being curt, but:

I really don't care what your C code says. It compiles differently
under 32bit and 64bit, using different floating point units in the x86
architecture.

Not caring about what his C code says seems rather odd, since that code
determines whether or not your assertions about the results of compiling
it are correct. He's asserted that the current version of his code
performs a "completely integer calculation". If that description is
correct (I haven't bothered to check), then why would it use the
floating point units at all, much less using different ones on the two
different machines?

If he's wrong, and it's not yet a "completely integer calculation", then
that's a different and very legitimate issue - but what his C code says
is very relevant to that issue.

 

[glen herrmannsfeldt]

(snip, someone wrote)

Surely that's a bit too strong a statement. Two compilers implement
strict IEEE FP semantics should produce programs generating the same
results. Of course that's rarely the default mode for compilers.

Hmmm. The extra precision used in the x87 is part of the IEEE
standard. In addition, IEEE 754 supports different rounding
modes, so you would also have to be sure that the same rounding
was done in all cases.

Also, while many systems support the IEEE floating point formats,
they may not necessarily claim everything else about the standard.

But you're right, one should generally avoid depending on the exact
results of FP operations, especially the corner cases.

I would have to read it more carefully to be sure, but I don't
believe that the intent of the standard was to generate bit exact
results, as this case requires.

-- glen

 

[JohnF]

Apologies for being curt, but:
I really don't care what your C code says. It compiles differently
under 32bit and 64bit, using different floating point units in the x86
architecture. It will not generate the same stream of random numbers.
Your 32bit and 64bit binaries will not be capable of decrypting each
others outputs.
Looking at the thread so far, it is very likely that you have made your
"1 byte in 1000" problem substantially rarer, but you really have not
removed it entirely. You cannot use floating point numbers of any kind
and have any expectation of determinism. ~Andrew

Okay, you don't care what the code says, but you seem to have
ignored what I said, too, which leaves you little to go on
I >>agreed with you<< the fp results won't be the same.
But I went on to say >>I'm not using the fp results<< any more,
thanks to all the comments and suggestions in this thread.
For example, as Ben pointed out, the Park&Miller algorithm used
by the ran1() function is a >>completely integer<< calculation,
generating a random integer intran=1...maxintran.
At the end, just before return;, it merely does an fp divide,
fpran = ((float)intran)/((float)(maxintran+1)). That's the only
fp calculation, period. I now ignore it, totally. And I just
use that intran.

 

[glen herrmannsfeldt]

(snip, I wrote)

While extended formats are allowed for by IEEE, it's *not* compliant
in general to do intermediate operations with extra precision. So
many compilers for x87 mode have a "strict" option which results in
storing the result of each intermediate operation to a correct sized
memory item, in order to get the exact rounding. Often there's an
option as well that uses the x87 precision control to achieve part of
that (while leaving oddness happing with the exponents).

Well, one problem with extra precision is double rounding.
If you round from extra to double, then to single, the result
can be different (wrong) from the correctly rounded extended
to single.

But consistent use of extended, unlike with the x87 with 8
registers, should give more accurate results.

The rounding mode has a defined default (round to even), and the
implementation should not be altering that (although providing a way
for the program to change that is common).
(snip)

The standard recommends that languages define a way of doing exactly
that (get the same results on all implementations). See the section
on reproducibility.

Well, in most cases what people want is the correct (closest)
printed decimal value. As the exponent shifts for binary are
different from decimal, you have to provide enough extra bits.

Or use the IEEE 754 decimal floating point.

Extra precision is most useful for sums, where cancelation and lost
precision can easily occur. There are some other cases where
the extra precision for intermediate values helps.

-- glen

 

[J. Clarke]

Not caring about what his C code says seems rather odd, since that code
determines whether or not your assertions about the results of compiling
it are correct. He's asserted that the current version of his code
performs a "completely integer calculation". If that description is
correct (I haven't bothered to check), then why would it use the
floating point units at all, much less using different ones on the two
different machines?

If he's wrong, and it's not yet a "completely integer calculation", then
that's a different and very legitimate issue - but what his C code says
is very relevant to that issue.

Intel hardware supports integer calcuations in the general purpose
registers, the 80x87 stack, and the SSE registers. So there is no
guarantee that an integer operation will be performed using the general-
purpose registers--this would be something that was determined by the
design of the compiler, the optimizations in force, and the specific
instruction sequence.

 

[James Kuyper]

Intel hardware supports integer calcuations in the general purpose
registers, the 80x87 stack, and the SSE registers. So there is no
guarantee that an integer operation will be performed using the general-
purpose registers--this would be something that was determined by the
design of the compiler, the optimizations in force, and the specific
instruction sequence.

That can't be problematic if we're talking about conforming
implementations of C. If there's any possibility that a purely integer
operation with defined behavior, will produce different results if it's
performed using the 80x87 stack or the SSE registers, then a conforming
implementation of C that chooses to use those things is pretty much
required to correct for that difference. There's no statement in the C
standard covering integer operations that gives implementations anything
like the same amount of freedom that 5.2.4.2.2p6 gives them for floating
point operations. Even implementations that pre-#define __STDC_IEC_559__
have less freedom in the evaluation of integer operations than floating
point ones.

 

[Rosario193]

Sorry for following myself up:
I should have mentioned that several "intended-to-be-portable"
fixes that I've tried, in particular freopen("CON","wb",stdout)
and stdout=fdopen(STDOUT_FILENO,"wb"), don't work or don't work

why not use windows OS sys api?