[SERVER-27542] Investigate the need for volatile in src/mongo/db/geo/shapes.cpp in 32-bit code Created: 29/Dec/16  Updated: 16/Jun/17  Resolved: 16/Jun/17

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 3.5.1
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Mark Benvenuto Assignee: DO NOT USE - Backlog - Platform Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

The code here:
https://github.com/mongodb/mongo/blob/241b64c7bffb9c8cadc9b1a01844833218b0c8f0/src/mongo/db/geo/shapes.cpp#L496-L505
uses volatile to work around a 32-bit gcc compiler bug. This change was originally added in SERVER-2940, but with the migration to GCC 5.4.0, this workaround needs to be evaluated if it it is still necessary, and can be removed.



 Comments   
Comment by Andrew Morrow (Inactive) [ 16/Jun/17 ]

We no longer offer 32-bit builds of MongoDB.

Comment by Geert Bosch [ 03/Jan/17 ]

There was no "gcc compiler bug". The (misguided) use of volatile was most likely added to avoid missing rounding due to the use of extended precision x87 registers for double precision values, trading a missing rounding for a double rounding. Anybody concerned with consistent rounding on 32-bit x86 should use an SSE2-capable processor (Intel Pentium-4 or later, or any 64-bit capable x86 CPU) and invoke GCC with the required options to allow it to compile SSE2-specific code (rather than generic 386 compatible IA32 code).

So, we should just remove the volatile here.

Comment by Andy Schwerin [ 29/Dec/16 ]

This is a super minor nit, but I'm not sure that the compiler behavior was technically a "bug". The compiler may be allowed by the C++ standard to do exactly what it did. However, I'm not sure whether the "volatile" keyword or just storing the intermediate result into a variable was the necessary step to avoid the behavior.

Generated at Thu Feb 08 04:15:27 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.