This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] integer overflow checking builtins in constant expressions
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Martin Sebor <msebor at gmail dot com>
- Cc: Gcc Patch List <gcc-patches at gcc dot gnu dot org>, Jason Merrill <jason at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Fri, 3 Jun 2016 17:23:38 +0200
- Subject: Re: [PATCH] integer overflow checking builtins in constant expressions
- Authentication-results: sourceware.org; auth=none
- References: <57263154 dot 5080401 at gmail dot com> <20160531215025 dot GK28550 at tucnak dot redhat dot com> <574E13DD dot 9040401 at gmail dot com> <20160601075212 dot GL28550 at tucnak dot redhat dot com> <574EFC8F dot 2040400 at gmail dot com> <574FA3BC dot 8090603 at gmail dot com> <20160602072316 dot GY28550 at tucnak dot redhat dot com> <20160602073404 dot GZ28550 at tucnak dot redhat dot com> <57519D1D dot 4000208 at gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Jun 03, 2016 at 09:07:09AM -0600, Martin Sebor wrote:
> I'm not sure I understand your concern but at this point I would
> prefer to keep things as they are. I like that the functionality
My concern is that if you declare that NULL is valid third argument for e.g.
__builtin_add_overflow, then unless we add some complicated wording into the
docs, we have to penalize the code we emit for e.g.
bool
foo (int a, int b, int *p)
{
return __builtin_add_overflow (a, b, p);
}
While we could previously emit
addl %edi, %esi
movl %esi, (%rdx)
seto %al
retq
you suddenly have to emit (and your patch doesn't do that):
addl %edi, %esi
seto %al
testq %rdx, %rdx
je .L1
movl %esi, (%rdx)
.L1:
retq
because you can't at compile time prove if p is NULL (then you wouldn't
store the result) or not.
Trying to document that the third argument may be NULL, but only if it is
constant NULL pointer expression or something like that (what exactly?)
might not be very easily understandable and clear to users.
Which is why I've suggested just not allowing (like before) the third
argument to be NULL, and just add new 3 builtins for the test for overflow,
but don't store it anywhere. They would just be folded early to the same
internal function. And when adding the 3 new builtins, we can also choose
a different calling convention that would allow the C++98/C constant
expressions, by not having the third argument a pointer (we don't need to
dereference anything), but e.g. just any integer where we ignore the value
(well, evaluate for side-effects) and only care about the type.
Jakub