All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ftp.linux.org.uk>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-sparse@vger.kernel.org
Subject: Re: [PATCH 16/16] fix handling of integer constant expressions
Date: Sun, 24 Jun 2007 21:38:37 +0100	[thread overview]
Message-ID: <20070624203837.GE21478@ftp.linux.org.uk> (raw)
In-Reply-To: <1a25667a20e43a072f733a3ec2b8e79d@kernel.crashing.org>

On Sun, Jun 24, 2007 at 09:40:06PM +0200, Segher Boessenkool wrote:
> >>Why?  I'd say it's not better than BUILD_BUG_ON_ZERO() use
> >>instead of that ?:
> >
> >Oh, _that_ part I have no problem with. It's more that it seems that 
> >the
> >gcc optimization is ok at least as an extension.
> 
> Sure, but it's not an extension (yet), but an implementation
> side-effect; it would have to be (semi-formally) defined in
> the manual to be an extension.  Until that happens, anyone
> using this "feature" risks haven his code broken at any time
> (or, rather, his code already was broken but he didn't know
> it).
> 
> See gcc.gnu.org/PR456 for more discussion.  Yes it's an old
> bug...

Humm...  Right, so __builtin_offsetof() needs special treatment too.
Oh, bugger.  Is
	offsetof(struct foo, a.x[n])
a documented extension?  I _know_ that it's not promised by 7.17,
but gcc eats it (and obviously that sucker requires extra treatment
in that case).

Parsing __builtin_offsetof() arguments is going to be fun ;-/  Right
now sparse has it as a predefined macro, but if we want to do that
kind of analysis, we need to really parse it.  OTOH, that's not
such a big deal...  Parser would need to accept
	ident ( \[ expr \] | . ident )*
there, typecheck would walk down, check types and find offsets of
struct members on the way down and build expression on the way
back (e.g. in form of constant + sum of stuff from [...]), doing
evaluate_expression() on each index and slapping Int_const_expr
on created nodes accordingly.  In the end, slap the Int_const_expr
on resulting expression in obvious way.  expand would work as usual,
no interesting nodes surviving by that point...

OK, that's doable and probably should be split into implementation
of __builtin_offsetof() (sans Int_const_expr logics) and Int_const_expr
parts merged into the patch that does all handling of integer constant
expressions.

Joy.  OK, folks, disregard 16/16 in the current form; everything prior
to it stands on its own.

  reply	other threads:[~2007-06-24 20:38 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-24  8:05 [PATCH 16/16] fix handling of integer constant expressions Al Viro
2007-06-24 17:47 ` Al Viro
2007-06-24 18:04   ` Linus Torvalds
2007-06-24 18:35     ` Al Viro
2007-06-24 19:04       ` Linus Torvalds
2007-06-24 19:40         ` Segher Boessenkool
2007-06-24 20:38           ` Al Viro [this message]
2007-06-24 21:42             ` Neil Booth
2007-06-24 23:07               ` Al Viro
2007-06-25  6:16               ` Segher Boessenkool
2007-06-25  5:31             ` Josh Triplett
2007-06-25 19:55               ` Al Viro
2007-06-26  3:12                 ` Josh Triplett
2007-06-26 22:10               ` Al Viro
2007-06-26 22:10                 ` Al Viro
2007-06-26 22:11                 ` Al Viro
2007-06-26 22:11                   ` Al Viro
2007-06-26 23:32                   ` Neil Booth
2007-06-27  0:18                     ` Al Viro
2007-06-27  0:25                       ` Linus Torvalds
2007-06-27  0:37                         ` Al Viro
2007-06-27  0:29                       ` Derek M Jones
2007-06-27  0:41                         ` Al Viro
2007-06-27 11:52                       ` Neil Booth
2007-06-27 12:19                         ` Al Viro
2007-06-27 12:26                           ` Neil Booth
2007-06-27 12:37                             ` Al Viro
2007-06-27 12:10                   ` Neil Booth
2007-06-27 12:30                     ` Al Viro
2007-06-27 12:59                       ` Neil Booth
2007-06-27 13:18                         ` Al Viro
2007-06-27 13:35                           ` Neil Booth
2007-06-27 14:06                             ` Al Viro
2007-06-27 15:54                               ` Al Viro
2007-06-27 14:50                           ` Josh Triplett
2007-06-27 14:59                             ` Al Viro
2007-06-27 16:19                     ` Linus Torvalds
2007-06-27 16:34                       ` Josh Triplett
2007-06-27 17:25                         ` Al Viro
2007-06-27 17:29                       ` Al Viro
2007-06-27 17:45                         ` Linus Torvalds
2007-06-27 18:04                           ` Al Viro
2007-06-27 22:50                       ` Neil Booth
2007-06-28  9:08                       ` Segher Boessenkool
2007-06-26 22:49                 ` Josh Triplett
2007-06-25  6:13             ` Segher Boessenkool
2007-06-24 19:59         ` Al Viro
2007-06-24 18:07   ` Arnd Bergmann
2007-06-24 19:10     ` Al Viro
2007-06-24 18:18   ` Segher Boessenkool
2007-06-24 18:44     ` Al Viro
2007-06-24 19:09       ` Segher Boessenkool

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=20070624203837.GE21478@ftp.linux.org.uk \
    --to=viro@ftp.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sparse@vger.kernel.org \
    --cc=segher@kernel.crashing.org \
    --cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.