[SERVER-36177] Evaluate feasibility and impact of adding _GLIBCXX_ASSERTIONS to our builds Created: 18/Jul/18  Updated: 06/Dec/22  Resolved: 25/Mar/21

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

Type: Improvement Priority: Major - P3
Reporter: Andrew Morrow (Inactive) Assignee: [DO NOT ASSIGN] Backlog - Server Development Platform Team (SDP) (Inactive)
Resolution: Won't Fix Votes: 0
Labels: former-toolchain-epic
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Assigned Teams:
Server Development Platform
Sprint: Dev Platform 2021-04-05
Participants:

 Description   

Per SERVER-35935 and https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/, we should evaluate the cost and benefit of adding _GLIBCXX_ASSERTIONS to our builds when building with libstdc++.

If we find that the performance hit is not acceptable, we may still be able to apply it in our DEBUG builders.



 Comments   
Comment by Andrew Morrow (Inactive) [ 25/Mar/21 ]

Having taken a slightly closer look at this flag, it appears to amount to enabling bounds checking for things like std::vector. In essence, it would turn std::vector::operator[] into std::vector::at. I don't think that is something we would want to do in our production code. There might be value to doing it in our DEBUG builds, but in that case we really want _GLIBCXX_DEBUG.

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