This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PING][RFC] Assertions as optimization hints


On 2016-11-28 18:49:55 +0000, Yuri Gribov wrote:
> On Mon, Nov 28, 2016 at 4:03 PM, Vincent Lefevre <vincent+gcc@vinc17.org> wrote:
> > Concerning the "per-project decision", I'm not sure that's a good
> > idea: as soon as one includes a header file, __ASSUME_ASSERTS__
> > could potentially break code.
> 
> Sorry, not sure I understood. __ASSUME_ASSERTS__ is supplied via
> cmdline when compiling project's shared libraries and executables to
> treat assertions as hints (effectively similar to MS __assume
> directives). It does not propagate to project's public header files.

What I was thinking of is that header files can contain calls to
assert(), e.g. via macros or inlined function (or classes in C++). For
instance, I can see the use of assert() in the following header files:

  /usr/include/ncursesw/cursesf.h
  /usr/include/ncursesw/cursesm.h

So, if the behavior of assert() is globally changed for a project that
uses ncursesw, this is bad as this would affect ncursesw too. Now, if
__ASSUME_ASSERTS__ does not propagate to "external" header files,
that's fine. But I wonder how this is implemented, i.e. to know which
header files should be affected which of them shouldn't, and how macro
definitions are affected, so that macros are expanded with the
expected behavior. This doesn't seem to be simple.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]