To look at this more closely I tried:

my $a = -95.3009707988281 ; show($a) ;
my $b = -95.1877600585938 ; show($b) ;
my $x = ($a + $b) / 2 ;     show($x) ;
printf "%20.16f\n", $x ;

sub show {
  my ($f) = @_ ;
  printf "%-18s 0x%04X_%04X_%04X_%04X\n", $f, unpack("n4", pack("d>", 
+$f)) ;
} ;
[download]

this gave:

Windows, perl 5.10.0, 32-bit               Linux, perl 5.10.0, 64-bit
-95.3009707988281  0xC057_D343_1B06_8122   -95.3009707988281  0xC057_D343_1B06_8122
-95.1877600585938  0xC057_CC04_42C3_C9F2   -95.1877600585938  0xC057_CC04_42C3_C9F2
-95.244365428711   0xC057_CFA3_AEE5_258A   -95.2443654287109  0xC057_CFA3_AEE5_258A
-95.2443654287109500                       -95.2443654287109496

which shows that the decimal to binary conversion is giving the same result, as is the arithmetic. What is different is the binary to decimal conversion. It would appear that Perl is stringifying to 15 significant decimal digits, discarding any trailing zeros. Other experiments suggest that the library under Windows is returning 17 significant decimal digits, but the library under Linux is returning rather more -- giving a different result when rounded to 15 decimal digits.

Binary/Decimal conversion is a whole lot trickier than it looks. Producing no more than 17 decimal digits is not unreasonable for IEEE 754 double precision floats. On the face of it, however, what we have here is a double rounding under Windows, which I think is incorrect.

Nevertheless, it is "ambitious" to expect any two floating point values to be exactly equal !