This is the mail archive of the
mailing list for the GCC project.
Re: GCC Common-Function-Attributes/const
- From: Martin Sebor <msebor at gmail dot com>
- To: cmdLP #CODE <mccmdlp at gmail dot com>, GCC Mailing List <gcc at gcc dot gnu dot org>
- Cc: Sandra Loosemore <sandra at codesourcery dot com>
- Date: Tue, 27 Nov 2018 09:26:13 -0700
- Subject: Re: GCC Common-Function-Attributes/const
- References: <CAN2=DZxMN_-A7egfHBDTQDDxAAanq=xK8mFW=YrJu_2EkvgkkQ@mail.gmail.com> <email@example.com> <CAN2=DZzrbqAoB1p21Za9NXo+qsVC7nFUxSyBgGHLmC1OnQAnOw@mail.gmail.com>
[CC gcc list and Sandra]
Thanks for the suggestions. I agree that the documentation
should make it possible to answer at least the basic questions
on your list. We'll see about incorporating them.
In general, attributes that affect optimization are implemented
at a level where higher-level distinctions like those between
pointers and references, or between classes with user-defined
ctors vs PODs, are immaterial. It's probably worth making that
clear in some preamble rather than for each individual attribute.
As far as requests for new attributes or features of existing
attributes I would suggest to raise those individually as
enhancements in Bugzilla where they can be appropriately
On 11/27/18 8:05 AM, cmdLP #CODE wrote:
Thank you for the reply.
*My suggestions for the documentation*
The documentation should inform if you can annotate c++ member functions
with these attributes (pure, const). (It would make sence to interpret
the whole object referenced by *this as a parameter)
The documentation should clarify how it handles structs/classes/unions
and references. Does it threat references like pointers? Does it only
allow PODs/trivial types to be returned, or does it invoke the copy
constructor, when it is used again? (Eg.(assume PODs/trivial types are
no problem) std::variant or std::optional with trivial types shouldn't
be a problem, but std::variant and std::optional are not trivial).
There should be a way to express, that a returnvalue of a function never
changes until another function is called. In my first e-mail I defined a
class map, which has a getter and setter method; it is obvious, that
calling get with the same key again yields the same value. It should be
optimized to just one call to get. But the value might change, if you
call set with the same key. The old returnvalue cannot be used anymore.
After that all calls to get can be merged again. This could improve the
performance of libraries using associative arrays.