OK.
Jason
On Tue, Jun 07, 2016 at 03:56:43PM -0600, Martin Sebor wrote:
> >+The built-in functions promote the first two operands into infinite
> >precision signed type
> >+and perform addition on those promoted operands. The result is then
> >+cast to the type the third argument.
>
> The above is missing
+The built-in functions promote the first two operands into infinite precision
signed type
+and perform addition on those promoted operands. The result is then
+cast to the type the third argument.
The above is missing an "of" (it should read "type of the third
argument".)
Martin
On Tue, Jun 07, 2016 at 02:30:06PM -0600, Martin Sebor wrote:
> I've also since discovered that the handling of (at least)
> BUILTIN_LINE is important in C++ 98 mode and if I had run
> the c-c++-common tests instead of just the strict C++ subset
> I would have seen the c-c++-common/builtin_location
On 06/07/2016 01:42 PM, Jakub Jelinek wrote:
On Tue, Jun 07, 2016 at 03:35:28PM -0400, Jason Merrill wrote:
Indeed, confirming removal of the cp/tree.c hunk doesn't affect anything in
the testsuite, nor e.g.
enum A {
B = 1,
C = 2,
D = __builtin_add_overflow_p (B, C, C)
};
int e[__builtin_a
On Tue, Jun 07, 2016 at 03:35:28PM -0400, Jason Merrill wrote:
> >Indeed, confirming removal of the cp/tree.c hunk doesn't affect anything in
> >the testsuite, nor e.g.
> >enum A {
> > B = 1,
> > C = 2,
> > D = __builtin_add_overflow_p (B, C, C)
> >};
> >int e[__builtin_add_overflow_p (B, C, C)
On 06/07/2016 11:51 AM, Martin Sebor wrote:
Unless I hear otherwise I'll submit a separate patch removing
the BUILTIN_FILE, FUNCTION, and LINE labels (and adjust the
comment to more closely reflect the function's purpose).
Since Jakub pointed out that this function is used by the parser for
C+
On 06/07/2016 12:34 PM, Jakub Jelinek wrote:
On Tue, Jun 07, 2016 at 09:51:05AM -0600, Martin Sebor wrote:
On 06/07/2016 08:32 AM, Jason Merrill wrote:
On 06/06/2016 08:36 AM, Jakub Jelinek wrote:
@@ -352,6 +352,35 @@ builtin_valid_in_constant_expr_p (const_
case BUILT_IN_FUNCTION:
cas
On Tue, Jun 07, 2016 at 09:51:05AM -0600, Martin Sebor wrote:
> On 06/07/2016 08:32 AM, Jason Merrill wrote:
> >On 06/06/2016 08:36 AM, Jakub Jelinek wrote:
> >>@@ -352,6 +352,35 @@ builtin_valid_in_constant_expr_p (const_
> >> case BUILT_IN_FUNCTION:
> >> case BUILT_IN_LINE:
> >>
> >>+
On 06/07/2016 08:32 AM, Jason Merrill wrote:
On 06/06/2016 08:36 AM, Jakub Jelinek wrote:
@@ -352,6 +352,35 @@ builtin_valid_in_constant_expr_p (const_
case BUILT_IN_FUNCTION:
case BUILT_IN_LINE:
+ /* The following built-ins are valid in constant expressions
+ when their argu
On 06/06/2016 08:36 AM, Jakub Jelinek wrote:
@@ -352,6 +352,35 @@ builtin_valid_in_constant_expr_p (const_
case BUILT_IN_FUNCTION:
case BUILT_IN_LINE:
+ /* The following built-ins are valid in constant expressions
+when their arguments are. */
+case BUILT_IN_ADD_OVERF
On Mon, Jun 06, 2016 at 09:44:08PM +0200, Jakub Jelinek wrote:
> Hi!
>
> On Mon, Jun 06, 2016 at 02:36:17PM +0200, Jakub Jelinek wrote:
> > 2016-06-06 Martin Sebor
> > Jakub Jelinek
> >
> > PR c++/70507
> > PR c/68120
> > * builtins.def (BUILT_IN_ADD_OVERFLOW_P, BUILT_IN_
Hi!
On Mon, Jun 06, 2016 at 02:36:17PM +0200, Jakub Jelinek wrote:
> 2016-06-06 Martin Sebor
> Jakub Jelinek
>
> PR c++/70507
> PR c/68120
> * builtins.def (BUILT_IN_ADD_OVERFLOW_P, BUILT_IN_SUB_OVERFLOW_P,
> BUILT_IN_MUL_OVERFLOW_P): New builtins.
> *
On Fri, Jun 03, 2016 at 02:09:44PM -0600, Martin Sebor wrote:
> I see. I've made the change in the latest update to the patch
> but I wasn't able to create a test case to verify it. Maybe
> that's because this is constexpr the COMPLEX_EXPR doesn't make
> it far enough to trigger a problem. If th
On 06/03/2016 09:32 AM, Jakub Jelinek wrote:
On Fri, Jun 03, 2016 at 09:29:48AM -0600, Martin Sebor wrote:
+ {
+ tree type = TREE_TYPE (TREE_TYPE (t));
+ tree vflow = arith_overflowed_p (opcode, type, arg0, arg1)
+ ? integer_one_node : integer_zero_node
On 06/03/2016 09:23 AM, Jakub Jelinek wrote:
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 thi
On Fri, Jun 03, 2016 at 09:29:48AM -0600, Martin Sebor wrote:
> >>+ {
> >>+ tree type = TREE_TYPE (TREE_TYPE (t));
> >>+ tree vflow = arith_overflowed_p (opcode, type, arg0, arg1)
> >>+ ? integer_one_node : integer_zero_node;
> >
> >This looks incorrect, the return type i
+ {
+ tree type = TREE_TYPE (TREE_TYPE (t));
+ tree vflow = arith_overflowed_p (opcode, type, arg0, arg1)
+ ? integer_one_node : integer_zero_node;
This looks incorrect, the return type is TREE_TYPE (t), some complex integer
type, therefore vflow needs
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,
On 06/02/2016 01:34 AM, Jakub Jelinek wrote:
On Thu, Jun 02, 2016 at 09:23:16AM +0200, Jakub Jelinek wrote:
Also, perhaps just a documentation thing, it would be good to clarify the
NULL last argument. From the POV of generating efficient code, I think we
should say something that the last argu
Hi!
On Thu, Jun 02, 2016 at 06:28:21PM -0600, Martin Sebor wrote:
First of all, can you please respond to the mail I've sent about
NULL argument issues (and proposal for __builtin_*_overflow_p)?
This patch as well as the nonnull attribute patch then depends on that
decision...
> + {
> +
+{
+ /* Perform the computation in the target type and check for
overflow. */
+ arg0 = fold_convert (type, arg0);
+ arg1 = fold_convert (type, arg1);
+
+ if (tree result = size_binop_loc (loc, opcode, arg0, arg1))
+return TREE_OVERFLOW (result) ? build_one_cst (boolean
+ /* For the "generic" overloads, the first two arguments can have different
+ types and the last argument determines the target type to use to check
+ for overflow. The arguments of the other overloads all have the same
+ type. */
+ tree type = TREE_TYPE (TREE_TYPE (arg2));
+ boo
On Thu, Jun 02, 2016 at 09:23:16AM +0200, Jakub Jelinek wrote:
> Also, perhaps just a documentation thing, it would be good to clarify the
> NULL last argument. From the POV of generating efficient code, I think we
> should say something that the last argument (for the GNU builtins) must be
> eith
On Wed, Jun 01, 2016 at 09:10:52PM -0600, Martin Sebor wrote:
> @@ -7957,8 +7957,8 @@ fold_builtin_arith_overflow (location_t loc, enum
> built_in_function fcode,
>tree arg0, tree arg1, tree arg2)
> {
>enum internal_fn ifn = IFN_LAST;
> - tree type = TREE_TYPE (TR
Unless I hear otherwise, I'll go ahead and change the patch
to have only the type-generic built-ins accept a null pointer
as an argument.
Since Jason doesn't think making it work in C++ 98 is important
I modified the patch to keep the Clang-compatibility built-ins
unchanged and to remove the def
On 05/31/2016 06:44 PM, Martin Sebor wrote:
Without this change, C or C++ 98 users wouldn't be able to use the
built-ins in constant expressions (C++ 98 doesn't allow
casting a null pointer in those contexts).
I can't imagine that C++98 users care about using these built-ins in
constant expres
C++ 98. But those might be acceptable limitations (at least
in C there's a workaround).
__builtin_* is an extension. Perhaps for C (any) and C++ (< C++14)
you could require that in constant expressions the last argument
of the builtin has to be a NULL pointer cast to some pointer type
(not nec
On Wed, Jun 01, 2016 at 09:17:35AM -0600, Martin Sebor wrote:
> I see. You meant that only the clang compatibility built-ins
> (i.e. the typed ones like __builtin_uadd_overflow) shouldn't
> be allowed to take null pointer as the last argument, but the
> type-generic ones should. That would work
As I said in another mail, IMNSHO you don't want to change the clang
compatibility builtins, therefore arg2 should never be NULL.
Allowing the last argument to be null is the subject of
the enhancement request in c/68120 (one of the two PRs
driving this enhancement). The argument can only be nu
On Tue, May 31, 2016 at 04:44:45PM -0600, Martin Sebor wrote:
> >I fail to understand this. You set type to NULL_TREE, and then (not in any
> >kind of loop, nor any label you could goto to) do:
> > type = type ? type : xxx;
> >That is necessarily equal to type = xxx;, isn't it?
>
> Each label f
On 05/31/2016 03:50 PM, Jakub Jelinek wrote:
On Sun, May 01, 2016 at 10:39:48AM -0600, Martin Sebor wrote:
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -7878,50 +7878,101 @@ fold_builtin_unordered_cmp (location_t loc, tree
fndecl, tree arg0, tree arg1,
static tree
fold_builtin_arith_overfl
On Sun, May 01, 2016 at 10:39:48AM -0600, Martin Sebor wrote:
> --- a/gcc/builtins.c
> +++ b/gcc/builtins.c
> @@ -7878,50 +7878,101 @@ fold_builtin_unordered_cmp (location_t loc, tree
> fndecl, tree arg0, tree arg1,
>
> static tree
> fold_builtin_arith_overflow (location_t loc, enum built_in_f
On Tue, May 31, 2016 at 05:31:48PM -0400, Jason Merrill wrote:
> >I'm not quite sure where to move this hunk so that it could be
> >shared or with what.
> >
> >With the patch, fold_builtin_arith_overflow returns the overflow
> >bit alone when the last argument is null. Otherwise it returns
> >a co
On 05/31/2016 04:48 PM, Martin Sebor wrote:
On 05/17/2016 12:54 PM, Jason Merrill wrote:
On 05/01/2016 12:39 PM, Martin Sebor wrote:
+ if (TREE_CODE (arg0) == INTEGER_CST && TREE_CODE (arg1) ==
INTEGER_CST)
+{
+ if (tree result = size_binop_loc (EXPR_LOC_OR_LOC (t,
input_location),
+
On 05/17/2016 12:54 PM, Jason Merrill wrote:
On 05/01/2016 12:39 PM, Martin Sebor wrote:
+ if (TREE_CODE (arg0) == INTEGER_CST && TREE_CODE (arg1) ==
INTEGER_CST)
+{
+ if (tree result = size_binop_loc (EXPR_LOC_OR_LOC (t,
input_location),
+opcode, arg0, arg1))
+
On 05/01/2016 12:39 PM, Martin Sebor wrote:
+ if (TREE_CODE (arg0) == INTEGER_CST && TREE_CODE (arg1) == INTEGER_CST)
+{
+ if (tree result = size_binop_loc (EXPR_LOC_OR_LOC (t, input_location),
+ opcode, arg0, arg1))
+ {
+ if (TREE_OVE
Ping 2 of the following patch:
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00013.html
On 05/09/2016 10:38 AM, Martin Sebor wrote:
Pinging the following patch:
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00013.html
On 05/01/2016 10:39 AM, Martin Sebor wrote:
c/68120 - can't easily deal
Pinging the following patch:
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00013.html
On 05/01/2016 10:39 AM, Martin Sebor wrote:
c/68120 - can't easily deal with integer overflow at compile time,
is an enhancement request to make the integer overflow intrinsics
usable in constant expressions
c/68120 - can't easily deal with integer overflow at compile time,
is an enhancement request to make the integer overflow intrinsics
usable in constant expressions in C (in addition to letting them
be invoked with just two arguments).
The inability to use the built-ins in constant expressions als
40 matches
Mail list logo
