https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113454
Bug ID: 113454
Summary: [14 regression] "assignment of read-only member" error
with 483.xalancbmk from SPEC CPU 2006
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: macro at orcam dot me.uk
CC: ppalka at gcc dot gnu.org
Target Milestone: ---
Created attachment 57116
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57116&action=edit
Reduced reproducer
As from commit 6e92a6a2a72d ("c++: non-dependent assignment checking
[PR63198, PR18474]") I get a compilation error when building 483.xalancbmk
from the SPEC CPU 2006 benchmarks suite:
./xercesc/util/NameIdPool.c: In member function
'xercesc_2_5::NameIdPoolEnumerator<TElem>&
xercesc_2_5::NameIdPoolEnumerator<TElem>::operator=(const
xercesc_2_5::NameIdPoolEnumerator<TElem>&)':
./xercesc/util/NameIdPool.c:416:20: error: assignment of read-only member
'xercesc_2_5::NameIdPoolEnumerator<TElem>::fMemoryManager'
416 | fMemoryManager = toAssign.fMemoryManager;
| ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
For reference I have attached a reduced reproducer. By reverting the
gcc/cp/typeck.cc part of said commit I can make this piece compile.
Now this is somewhat old code, which however used to build for at least 17
years. Intuitively, given the `const' member annotation an assignment to
it outside a constructor is rightfully rejected, however my C++-fu is not
strong enough to back up such a claim and I can't find the relevant C++
language standard clause either way. For several error situations we used
to accept we now provide respective `-Wno-error=' options, however this
case is not one of them.
Filing this bug then for the C++ experts to decide, and if nothing else for
posterity, so that the next person who comes across this build failure can
find it and save themselves from repeating my investigation.
