public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "xinliangli at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/23383] builtin array operator new is not marked with malloc attribute
Date: Thu, 05 Jan 2012 18:11:00 -0000	[thread overview]
Message-ID: <bug-23383-4-AOOlkQN8Ur@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-23383-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383

--- Comment #20 from davidxl <xinliangli at gmail dot com> 2012-01-05 18:11:18 UTC ---
(In reply to comment #19)
> On Wed, 4 Jan 2012, xinliangli at gmail dot com wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
> > 
> > --- Comment #18 from davidxl <xinliangli at gmail dot com> 2012-01-04 17:11:26 UTC ---
> > (In reply to comment #17)
> > > On Wed, 4 Jan 2012, xinliangli at gmail dot com wrote:
> > > 
> > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
> > > > 
> > > > --- Comment #16 from davidxl <xinliangli at gmail dot com> 2012-01-04 00:28:55 UTC ---
> > > > A related topic - aliasing property of realloc -- the malloc attribute is not
> > > > applied in the glibc header and the comment is like
> > > > 
> > > > /* __attribute_malloc__ is not used, because if realloc returns
> > > >    the same pointer that was passed to it, aliasing needs to be allowed
> > > >    between objects pointed by the old and new pointers.  *
> > > > 
> > > > 
> > > > It is true that the realloc can return an address is physically aliased with
> > > > the pointer passed to it -- but assuming no-alias by the compiler should cause
> > > > no harm -- as all code motions/CSEs across the realloc call will not be
> > > > possible because realloc may modify/use the memory location.
> > > > 
> > > > 
> > > > Any comment on this? 
> > > 
> > > The malloc attribute assumes that the contents of the memory pointed
> > > to by the return value is undefined, so the comment is inaccurate
> > > but the malloc attribute can indeed be not used.
> > 
> > Which part of the optimizer takes advantage of the 'undefinedness' of returned
> > memory?
> 
> points-to analysis.  It assumes that the returned blob of memory
> points to nothing (yet).  So for
> 
>  int i;
>  int **p = malloc (8);
>  *p = &i;
>  int **q = realloc (p, 8);
> 
> you'd get that *q points to nothing insteda of i.

The malloc attribute documentation is confusing:

malloc
The malloc attribute is used to tell the compiler that a function may be
treated as if any non-NULL pointer it returns cannot alias any other pointer
valid when the function returns. This will often improve optimization. Standard
functions with this property include malloc and calloc. realloc-like functions
have this property as long as the old pointer is never referred to (including
comparing it to the new pointer) after the function returns a non-NULL value. 


It does not mention the undefineness explicitly.

It might be better to fix the semantics of this attribute to only specify the
aliasing property so that it can also be applied to realloc. Points-to needs to
be fixed to special case realloc for the initialization.

David


> 
> > > We can explicitly handle REALLOC in the points-to code to honor the
> > > fact that it is not (we do not at the moment).
> > 
> > ok.
> 
> which needs to be fixed here.
> 
> Richard.


  parent reply	other threads:[~2012-01-05 18:11 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-23383-4@http.gcc.gnu.org/bugzilla/>
2012-01-04  0:29 ` xinliangli at gmail dot com
2012-01-04  9:44 ` rguenther at suse dot de
2012-01-04 17:12 ` xinliangli at gmail dot com
2012-01-05  8:40 ` rguenther at suse dot de
2012-01-05 18:11 ` xinliangli at gmail dot com [this message]
2012-01-05 18:27 ` jakub at gcc dot gnu.org
2012-01-05 18:55 ` xinliangli at gmail dot com
2012-01-09  8:39 ` rguenther at suse dot de
2012-01-09  8:40 ` rguenther at suse dot de
2013-07-08  4:54 ` pinskia at gcc dot gnu.org
     [not found] <bug-23383-6528@http.gcc.gnu.org/bugzilla/>
2008-03-05  7:48 ` pinskia at gcc dot gnu dot org
2008-03-12 20:30 ` pinskia at gcc dot gnu dot org
2008-06-04  3:22 ` sabre at nondot dot org
2008-06-04  4:16 ` xinliangli at gmail dot com
2008-06-04  4:33 ` sabre at nondot dot org
2008-06-04  4:33 ` sabre at nondot dot org
2008-06-04  4:47 ` xinliangli at gmail dot com
2008-06-04  4:48 ` sabre at nondot dot org
2008-06-04  5:24 ` xinliangli at gmail dot com
2008-06-04  5:35 ` sabre at nondot dot org
2008-06-04  7:58 ` rguenth at gcc dot gnu dot org
2008-06-04 16:48 ` davidxl at gcc dot gnu dot org
2008-06-04 17:04 ` rguenth at gcc dot gnu dot org
2008-06-04 17:35 ` davidxl at gcc dot gnu dot org
2005-08-14  5:39 [Bug c++/23383] New: " pinskia at gcc dot gnu dot org
2005-08-23 16:40 ` [Bug c++/23383] " pinskia at gcc dot gnu dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-23383-4-AOOlkQN8Ur@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).