This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Experience with g++ 4.8 and -frepo?
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: David Kastrup <dak at gnu dot org>
- Cc: libstdc++ at gnu dot org
- Date: Wed, 27 Aug 2014 14:04:03 +0100
- Subject: Re: Experience with g++ 4.8 and -frepo?
- Authentication-results: sourceware.org; auth=none
- References: <87fvgi6xn5 dot fsf at fencepost dot gnu dot org> <20140827105915 dot GA22778 at redhat dot com> <87bnr66s7q dot fsf at fencepost dot gnu dot org> <20140827123351 dot GB22778 at redhat dot com> <877g1u6qjz dot fsf at fencepost dot gnu dot org>
On 27/08/14 14:54 +0200, David Kastrup wrote:
Ok. Once I get this thing through _without_ const, I'll try the version
_with_ const and see whether this indeed gets me rid of the optimization
problem too. After all, it's quite plausible that the optimizer might
confuse const on a generic definition with a promise that the value will
not get switched for a different constant by a specialization when the
actual specialization is only visible in a different compilation unit.
If the specialization is only visible in a different compilation unit
then any use of it is undefined behaviour, no diagnostic required, so
any result is plausible. The 'const' is irrelevant.
At any rate, g++ -frepo appears to get me rid of that inconsistent
specialization problem at the cost of tripping up libstdc++ usage
(which never was problematic without -frepo). Sometimes I wonder
whether I am the only one using some software... But maybe -frepo was
pretty new in g++-4.8.
No, -frepo is ancient and bit-rotted and noone uses it now.
Ah, good to know. So there is no point in working towards getting the
project codebase to work with -frepo. That's definitely useful
information that I was lacking before, and that was not to be gleaned
from the GCC info page.
The page is ancient and bit-rotted too. I'm going to rewrite it.