Re: [RFC] combine: Improve change_zero_ext, call simplify_set afterwards.

[Dominik Vogt]

On Sat, Dec 10, 2016 at 10:37:38AM -0600, Segher Boessenkool wrote:
> On Fri, Dec 09, 2016 at 04:23:44PM +0100, Dominik Vogt wrote:
> > 0001-*
> > 
> >   Deal with mode expanding zero_extracts in change_zero_ext.  The
> >   patch looks good to me, but not sure whether endianness is
> >   handled properly.  Is the second argument of gen_rtx_SUBREG
> >   correct?
> 
> > >From 600ed3dadd5bc2568ab53be8466686abaf27ff3f Mon Sep 17 00:00:00 2001
> > From: Dominik Vogt 
> > Date: Fri, 9 Dec 2016 02:48:30 +0100
> > Subject: [PATCH 1/2] combine: Handle mode expanding zero_extracts in
> >  change_zero_ext.
> > 
> > Example:
> > 
> >   (zero_extract:DI (reg:SI)
> >(const_int 24)
> >(const_int 0))
> > 
> > -->
> > 
> >   (and:DI (subreg:DI (lshiftrt:SI (reg:SI) (const_int 8))
> >  0)
> >   (const_int 16777215))
> > ---
> >  gcc/combine.c | 12 +---
> >  1 file changed, 9 insertions(+), 3 deletions(-)
> > 
> > diff --git a/gcc/combine.c b/gcc/combine.c
> > index b429453..e14a08f 100644
> > --- a/gcc/combine.c
> > +++ b/gcc/combine.c
> > @@ -11237,18 +11237,24 @@ change_zero_ext (rtx pat)
> >if (GET_CODE (x) == ZERO_EXTRACT
> >   && CONST_INT_P (XEXP (x, 1))
> >   && CONST_INT_P (XEXP (x, 2))
> > - && GET_MODE (XEXP (x, 0)) == mode)
> > + && (GET_MODE (XEXP (x, 0)) == mode
> > + || GET_MODE_PRECISION (GET_MODE (XEXP (x, 0)))
> > +< GET_MODE_PRECISION (mode)))
> 
> If you make this <= you can collapse the two cases into one.
> 
> > {
> > + machine_mode inner_mode = GET_MODE (XEXP (x, 0));
> > +
> >   size = INTVAL (XEXP (x, 1));
> >  
> >   int start = INTVAL (XEXP (x, 2));
> >   if (BITS_BIG_ENDIAN)
> > -   start = GET_MODE_PRECISION (mode) - size - start;
> > +   start = GET_MODE_PRECISION (inner_mode) - size - start;
> >  
> >   if (start)
> > -   x = gen_rtx_LSHIFTRT (mode, XEXP (x, 0), GEN_INT (start));
> > +   x = gen_rtx_LSHIFTRT (inner_mode, XEXP (x, 0), GEN_INT (start));
> >   else
> > x = XEXP (x, 0);
> > + if (mode != inner_mode)
> > +   x = gen_rtx_SUBREG (mode, x, 0);
> 
> gen_lowpart_SUBREG instead?  It's easier to read, and code a little
> further down does the same thing.

Thanks for taking a look.

> Okay for trunk with those changes (did you bootstrap+regcheck this
> already?)

The patch hasn't got any real testing yet.  I'll try to do that
today or tomorrow.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: [PATCH] PR78255: Make postreload aware of NO_FUNCTION_CSE

[Christophe Lyon]

Hi Andre,

On 9 December 2016 at 17:16, Andre Vieira (lists)
 wrote:
> On 09/12/16 16:02, Ramana Radhakrishnan wrote:
>> On Fri, Dec 9, 2016 at 3:58 PM, Bernd Schmidt  wrote:
>>> On 12/09/2016 04:34 PM, Andre Vieira (lists) wrote:
>>>
 Regardless, the other testcases I add in this patch show a sub-optimal
 transformation done by postreload, turning direct calls into indirect
 calls, for targets which have specifically pointed out that no CSE
 should be done on functions through 'NO_FUNCTION_CSE'.
>>>
>>>
>>> What I'm wondering about is whether the patch wouldn't also prevent the
>>> opposite transformation. Is there a reason not to do that one? Can the
>>> problem be modeled by tweaking costs?
>>
>> I really don't think we should have a solution that relies on costs
>> for correctness .
>>
>> regards
>> Ramana
>>
>
> Regardless, 'reload_cse_simplify' would never perform the opposite
> transformation.  It checks whether it can replace anything within the
> first argument INSN, with the second argument TESTREG. As the name
> implies this will always be a register. I double checked, the function
> is only called in 'reload_cse_regs' and 'testreg' is created using
> 'gen_rtx_REG'.
>

The new test (gcc.target/arm/pr78255-2.c scan-assembler b\\s+bar)
added at r243494 fails on old arm architectures, such as:
* arm-none-linux-gnueabi, forcing -march=armv5t in runtestflags
* arm-none-eabi with default cpu/fpu/mode

Christophe


> Cheers,
> Andre

[ping] 3 aarch64/arm/rs6000 patches

[Eric Botcazou]

aarch64 (Enable descriptors for nested functions in Ada):
  https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01253.html

arm (Enable descriptors for nested functions in Ada):
  https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01254.html

rs6000 (Fix reload failures in 64-bit mode):
  https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00568.html

Thanks in advance.

-- 
Eric Botcazou

Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers in GIMPLE.

[Tamar Christina]

Ping


From: Tamar Christina
Sent: Friday, December 2, 2016 4:20:42 PM
To: Joseph Myers
Cc: GCC Patches; Wilco Dijkstra; rguent...@suse.de; l...@redhat.com; Michael 
Meissner; nd
Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers 
in GIMPLE.

Ping?

Is there anything else I need to do for the patch or is it OK for trunk?

Thanks,
Tamar


From: Tamar Christina
Sent: Friday, November 25, 2016 12:18:52 PM
To: Joseph Myers
Cc: GCC Patches; Wilco Dijkstra; rguent...@suse.de; l...@redhat.com; Michael 
Meissner; nd
Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers 
in GIMPLE.

Hi Joseph,

I have updated the patch with the changes,
w.r.t to the formatting, there are tabs there that seem to be rendered
at 4 spaces wide. In my editor setup at 8 spaces they are correct.

Kind Regards,
Tamar

From: Joseph Myers 
Sent: Thursday, November 24, 2016 6:28:18 PM
To: Tamar Christina
Cc: GCC Patches; Wilco Dijkstra; rguent...@suse.de; l...@redhat.com; Michael 
Meissner; nd
Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers 
in GIMPLE.

On Thu, 24 Nov 2016, Tamar Christina wrote:

> @@ -11499,6 +11503,53 @@ to classify.  GCC treats the last argument as 
> type-generic, which
>  means it does not do default promotion from float to double.
>  @end deftypefn
>
> +@deftypefn {Built-in Function} int __builtin_isnan (...)
> +This built-in implements the C99 isnan functionality which checks if
> +the given argument represents a NaN.  The return value of the
> +function will either be a 0 (false) or a 1 (true).
> +On most systems, when an IEEE 754 floating point is used this
> +built-in does not produce a signal when a signaling NaN is used.

"an IEEE 754 floating point" should probably be "an IEEE 754
floating-point type" or similar.

> +GCC treats the argument as type-generic, which means it does
> +not do default promotion from float to double.

I think type names such as float and double should use @code{} in the
manual.

> +the given argument represents an Infinite number.  The return

Infinite should not have a capital letter there.

> +@deftypefn {Built-in Function} int __builtin_iszero (...)
> +This built-in implements the C99 iszero functionality which checks if

This isn't C99, it's TS 18661-1:2014.

> +the given argument represents the number 0.  The return

0 or -0.

> +@deftypefn {Built-in Function} int __builtin_issubnormal (...)
> +This built-in implements the C99 issubnormal functionality which checks if

Again, TS 18661-1.

> +the given argument represents a sub-normal number.  The return

Do not hyphenate subnormal.

> + switch (DECL_FUNCTION_CODE (decl))
> + {
> + case BUILT_IN_SETJMP:
> + lower_builtin_setjmp (gsi);
> + data->cannot_fallthru = false;
> + return;

The indentation in this whole block of code (not all quoted) is wrong.

> +real_inf(&rinf);

Missing space before '('.

> +  emit_tree_cond (&body, dest, done_label,
> +   is_normal(&body, arg, loc), fp_normal);
> +  emit_tree_cond (&body, dest, done_label,
> +   is_zero(&body, arg, loc), fp_zero);
> +  emit_tree_cond (&body, dest, done_label,
> +   is_nan(&body, arg, loc), fp_nan);
> +  emit_tree_cond (&body, dest, done_label,
> +   is_infinity(&body, arg, loc), fp_infinite);

Likewise.

> +   fndecl(&body, arg, loc), t_true);

Likewise.

--
Joseph S. Myers
jos...@codesourcery.com

[PATCH] PR 78534 Change character length from int to size_t

[Janne Blomqvist]

In order to handle large character lengths on (L)LP64 targets, switch
the GFortran character length from an int to a size_t.

This is an ABI change, as procedures with character arguments take
hidden arguments with the character length.

I also changed the _size member in vtables from int to size_t, as
there were some cases where character lengths and sizes were
apparently mixed up and caused regressions otherwise. Although I
haven't tested, this might enable very large derived types as well.

Also, as there are some places in the frontend were negative character
lengths are used as special flag values, in the frontend the character
length is handled as a signed variable of the same size as a size_t,
although in the runtime library it really is size_t.

I haven't changed the character length variables for the co-array
intrinsics, as this is something that may need to be synchronized with
OpenCoarrays.

A caveat here is the testcase char_result_8.f90, which I changed
slightly to work around PR 78757. It's a somewhat obscure corner case,
and while this patch admittedly makes it more likely to trigger this
bug, it's, well, still a corner case.

Regtested on x86_64-pc-linux-gnu, Ok for trunk?

frontend:

2016-12-12  Janne Blomqvist  

PR fortran/78534
PR fortran/66310
* arith.c (gfc_check_charlen_range): New function.
(gfc_range_check): Use gfc_check_charlen_range.
* class.c (gfc_find_derived_vtab): Use gfc_size_kind instead of
hardcoded kind.
(find_intrinsic_vtab): Likewise.
* expr.c (gfc_get_character_expr): Length parameter of type
gfc_charlen_t.
(gfc_get_int_expr): Value argument of type long.
(gfc_extract_long): New function.
* gfortran.h (gfc_typespec): New member is_charlen.
(gfc_charlen_t): New typedef.
(gfc_expr): Use gfc_charlen_t for character lengths.
(gfc_size_kind): New extern variable.
(gfc_extract_long): New prototype.
(gfc_get_character_expr): Use gfc_charlen_t for character length.
(gfc_get_int_expr): Use long type for value argument.
* iresolve.c (gfc_resolve_repeat): Use gfc_charlen_t,
gfc_charlen_int_kind, set is_charlen.
* match.c (select_intrinsic_set_tmp): Use long for charlen.
* module.c (atom_int): Change type from int to HOST_WIDE_INT.
(parse_integer): Don't complain about large integers.
(write_atom): Use HOST_WIDE_INT for integers.
(mio_integer): Handle integer type mismatch.
(mio_hwi): New function.
(mio_intrinsic_op): Use HOST_WIDE_INT.
(mio_array_ref): Likewise.
(mio_expr): Likewise.
* resolve.c (resolve_substring): Use get_type_static_bounds.
(resolve_select_type): Use long for charlen.
(resolve_charlen): Use long for charlen, get_type_static_bounds.
* simplify.c (gfc_simplify_repeat): Likewise.
* target-memory.c (gfc_interpret_character): Use gfc_charlen_t.
* trans-array.c (get_array_ctor_var_strlen): Use
gfc_conv_mpz_to_tree_type.
* trans-const.c (gfc_conv_mpz_to_tree_type): New function.
* trans-const.h (gfc_conv_mpz_to_tree_type): New prototype.
* trans-decl.c (create_function_arglist): Assert that length is
not NULL_TREE.
* trans-expr.c (gfc_class_len_or_zero_get): Build const of type
gfc_charlen_type_node.
(gfc_conv_intrinsic_to_class): Use gfc_charlen_int_kind instead of
4, fold_convert to correct type.
(gfc_conv_class_to_class): Build const of type size_type_node for
size.
(gfc_copy_class_to_class): Likewise.
(gfc_conv_string_length): Use same type in expression.
(gfc_conv_substring): Likewise, use long for charlen.
(gfc_conv_string_tmp): Make sure len is of the right type.
(gfc_conv_concat_op): Use same type in expression.
(gfc_conv_procedure_call): Likewise.
(alloc_scalar_allocatable_for_subcomponent_assignment):
fold_convert to right type.
(gfc_trans_subcomponent_assign): Likewise.
(trans_class_vptr_len_assignment): Build const of correct type.
(gfc_trans_pointer_assignment): Likewise.
(alloc_scalar_allocatable_for_assignment): fold_convert to right
type in expr.
(trans_class_assignment): Build const of correct type.
* trans-intrinsic.c (gfc_conv_associated): Likewise.
(gfc_conv_intrinsic_repeat): Do calculation in sizetype.
* trans-io.c (gfc_build_io_library_fndecls): Use
gfc_charlen_type_node for character lengths.
* trans-stmt.c (gfc_trans_label_assign): Build const of
gfc_charlen_type_node.
(gfc_trans_character_select): Likewise.
(gfc_trans_allocate): Likewise, don't typecast strlen result.
(gfc_trans_deallocate): Don't typecast strlen result.
* trans-types.c (gfc_size_kind): New variable.
(gfc_init_types)

Re: Fix ICE with __builtin_va_list on i?86 (PR middle-end/78716)

[Tom de Vries]

On 08/12/16 22:07, Marek Polacek wrote:

This test ICEs since r240072 where Tom disallowed using va_list * as a first
argument to va_arg.  I think the problem is in the ADDR_EXPR check in
gimplify_va_arg_expr.  It's meant to handle Case 1, but the valist doesn't
always have to be ADDR_EXPR.  E.g. for this testcase build_va_arg creates
VA_ARG_EXPR <&*s>
but during clone_body this is transformed into
VA_ARG_EXPR 
so we have a valid valist, but it's not an ADDR_EXPR, so we don't call
targetm.canonical_va_list_type and crash on the subsequent assert.

Tom, does this make sense to you?


Hi,

duing the compilation resulting in the ICE, the "Case 1" is triggered in 
build_va_arg, so we need the targetm.canonical_va_list_type retry in 
gimplify_va_arg_expr. Hence, the patch looks good to me.


[ FTR, it would be cleaner to add an encoding of the case to VA_ARG_EXPR 
and call either:

...
have_va_type
  = targetm.canonical_va_list_type (TREE_TYPE (TREE_TYPE (valist)));
...

or:
...
have_va_type
  = targetm.canonical_va_list_type (TREE_TYPE (valist));
...
in gimplify_va_arg_expr based on that encoding, but that's probably 
overkill. ]


Thanks,
- Tom

Re: [PATCH] PR 78534 Change character length from int to size_t

[FX]

Hi Janne,

This is an ABI change, so it is serious… it will require people to recompile 
older code and libraries with the new compiler. Do we already plan to break the 
ABI in this cycle, or is this the first ABI-breaking patch of the cycle? And do 
we have real-life examples of character strings larger than 2 GB?

> Also, as there are some places in the frontend were negative character
> lengths are used as special flag values, in the frontend the character
> length is handled as a signed variable of the same size as a size_t,
> although in the runtime library it really is size_t.

First, I thought: we should really make it size_t, and have the negative values 
be well-defined constants, e.g. (size_t) -1

On the other hand, there is the problem of the case where the front-end has 
different size_t than the target: think 32-bit on 64-bit i386 (front-end size_t 
larger than target size_t), or cross-compiling for 64-bit on a 32-bit machine 
(front-end size_t smaller than target size_t). So the charlen type bounds need 
to be determined when the front-end runs, not when it is compiled (i.e. it is 
not a fixed type).

In iresolve.c, the "Why is this fixup needed?” comment is kinda scary.


> I haven't changed the character length variables for the co-array
> intrinsics, as this is something that may need to be synchronized with
> OpenCoarrays.

Won’t that mean that coarray programs will fail due to ABI mismatch?


FX

Re: [PATCH] PR 78534 Change character length from int to size_t

[Andre Vehreschild]

Hi FX,

there is already an ABI change. DTIO needed it.

I will take on the coarray ABI changes in the next days and also emit a
pull-request to the opencoarrays to get them to sync. Janne, please wait until
I have added those changes to prevent people from having to re-compile multiple
times.

- Andre

On Mon, 12 Dec 2016 11:20:06 +0100
FX  wrote:

> Hi Janne,
> 
> This is an ABI change, so it is serious… it will require people to recompile
> older code and libraries with the new compiler. Do we already plan to break
> the ABI in this cycle, or is this the first ABI-breaking patch of the cycle?
> And do we have real-life examples of character strings larger than 2 GB?
> 
> > Also, as there are some places in the frontend were negative character
> > lengths are used as special flag values, in the frontend the character
> > length is handled as a signed variable of the same size as a size_t,
> > although in the runtime library it really is size_t.  
> 
> First, I thought: we should really make it size_t, and have the negative
> values be well-defined constants, e.g. (size_t) -1
> 
> On the other hand, there is the problem of the case where the front-end has
> different size_t than the target: think 32-bit on 64-bit i386 (front-end
> size_t larger than target size_t), or cross-compiling for 64-bit on a 32-bit
> machine (front-end size_t smaller than target size_t). So the charlen type
> bounds need to be determined when the front-end runs, not when it is compiled
> (i.e. it is not a fixed type).
> 
> In iresolve.c, the "Why is this fixup needed?” comment is kinda scary.
> 
> 
> > I haven't changed the character length variables for the co-array
> > intrinsics, as this is something that may need to be synchronized with
> > OpenCoarrays.  
> 
> Won’t that mean that coarray programs will fail due to ABI mismatch?
> 
> 
> FX

-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Gitmirror lacking?

[Andre Vehreschild]

Hi all,

I perceive that the git-mirror is lacking the commits of the last two days.
What did I miss? I have searched the gcc.gnu.org site already, but did not find
any reports.

- Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Re: Gitmirror lacking?

[Marek Polacek]

On Mon, Dec 12, 2016 at 11:32:06AM +0100, Andre Vehreschild wrote:
> Hi all,
> 
> I perceive that the git-mirror is lacking the commits of the last two days.
> What did I miss? I have searched the gcc.gnu.org site already, but did not 
> find
> any reports.

https://gcc.gnu.org/ml/gcc/2016-12/msg00047.html

Marek

Re: [PATCH, GCC/ARM, gcc-5/6-branch, ping] Fix PR77904: callee-saved register trashed when clobbering sp

[Thomas Preudhomme]

Same as for PR77933, I'm trying to get this in for the next GCC 6 release.

I've successfully done a Thumb-1 bootstrap of the backport and testsuite shows 
no regression when run with an arm-none-eabi GCC cross-compiler targeting ARM 
Cortex-M0.


Is this ok for gcc-6-branch?

Best regards,

Thomas

On 06/12/16 11:38, Thomas Preudhomme wrote:

Ping?

Best regards,

Thomas

On 30/11/16 10:44, Thomas Preudhomme wrote:

Sorry, the bug cannot be reproduced on gcc-5-branch so it's probably better to
only do a backport to gcc-6-branch.

Ok for a backport to gcc-6-branch?

Best regards,

Thomas

On 30/11/16 10:42, Thomas Preudhomme wrote:

Hi,

Is this ok to backport to gcc-5-branch and gcc-6-branch? Patch applies cleanly
(patches attached for reference).


2016-11-30 Thomas Preud'homme 

Backport from mainline
2016-11-22  Thomas Preud'homme  

gcc/
PR target/77904
* config/arm/arm.c (thumb1_compute_save_reg_mask): Mark frame pointer
in save register mask if it is needed.

gcc/testsuite/
PR target/77904
* gcc.target/arm/pr77904.c: New test.


Best regards,

Thomas


On 22/11/16 10:45, Thomas Preudhomme wrote:

On 17/11/16 09:11, Kyrill Tkachov wrote:


On 17/11/16 08:56, Thomas Preudhomme wrote:

On 16/11/16 10:30, Kyrill Tkachov wrote:

Hi Thomas,

On 03/11/16 16:52, Thomas Preudhomme wrote:

Hi,

When using a callee-saved register to save the frame pointer the Thumb-1
prologue fails to save the callee-saved register before that. For ARM and
Thumb-2 targets the frame pointer is handled as a special case but
nothing is
done for Thumb-1 targets. This patch adds the same logic for Thumb-1
targets.

ChangeLog entries are as follow:

*** gcc/ChangeLog ***

2016-11-02  Thomas Preud'homme 

PR target/77904
* config/arm/arm.c (thumb1_compute_save_reg_mask): mark frame
pointer
in save register mask if it is needed.



s/mark/Mark/



*** gcc/testsuite/ChangeLog ***

2016-11-02  Thomas Preud'homme 

PR target/77904
* gcc.target/arm/pr77904.c: New test.


Testing: Testsuite shows no regression when run with arm-none-eabi GCC
cross-compiler for Cortex-M0 target.

Is this ok for trunk?



I'd ask for a bootstrap, but this code is Thumb-1 only so it wouldn't affect
anything.


I can bootstrap for armv4t with --with-mode=thumb which would at least
exercise the path. I'll try such a bootstrap on qemu.



If you can get it to work, then yes please.


Bootstrap came back clean so I've committed the patch (r242693). Thanks!

Best regards,

Thomas
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 83cb13d1195beb19d6301f5c83a7eb544a91d877..ae479a43fe8514f2eacb7d56f89916b48f720768 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -19390,6 +19390,10 @@ thumb1_compute_save_reg_mask (void)
 if (df_regs_ever_live_p (reg) && callee_saved_reg_p (reg))
   mask |= 1 << reg;
 
+  /* Handle the frame pointer as a special case.  */
+  if (frame_pointer_needed)
+mask |= 1 << HARD_FRAME_POINTER_REGNUM;
+
   if (flag_pic
   && !TARGET_SINGLE_PIC_BASE
   && arm_pic_register != INVALID_REGNUM
diff --git a/gcc/testsuite/gcc.target/arm/pr77904.c b/gcc/testsuite/gcc.target/arm/pr77904.c
new file mode 100644
index ..76728c07e73350ce44160cabff3dd2fa7a6ef021
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/pr77904.c
@@ -0,0 +1,45 @@
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+__attribute__ ((noinline, noclone)) void
+clobber_sp (void)
+{
+  __asm volatile ("" : : : "sp");
+}
+
+int
+main (void)
+{
+  int ret;
+
+  __asm volatile ("mov\tr4, #0xf4\n\t"
+		  "mov\tr5, #0xf5\n\t"
+		  "mov\tr6, #0xf6\n\t"
+		  "mov\tr7, #0xf7\n\t"
+		  "mov\tr0, #0xf8\n\t"
+		  "mov\tr8, r0\n\t"
+		  "mov\tr0, #0xfa\n\t"
+		  "mov\tr10, r0"
+		  : : : "r0", "r4", "r5", "r6", "r7", "r8", "r10");
+  clobber_sp ();
+
+  __asm volatile ("cmp\tr4, #0xf4\n\t"
+		  "bne\tfail\n\t"
+		  "cmp\tr5, #0xf5\n\t"
+		  "bne\tfail\n\t"
+		  "cmp\tr6, #0xf6\n\t"
+		  "bne\tfail\n\t"
+		  "cmp\tr7, #0xf7\n\t"
+		  "bne\tfail\n\t"
+		  "mov\tr0, r8\n\t"
+		  "cmp\tr0, #0xf8\n\t"
+		  "bne\tfail\n\t"
+		  "mov\tr0, r10\n\t"
+		  "cmp\tr0, #0xfa\n\t"
+		  "bne\tfail\n\t"
+		  "mov\t%0, #1\n"
+		  "fail:\n\t"
+		  "sub\tr0, #1"
+		  : "=r" (ret) : :);
+  return ret;
+}

Re: [PATCH, GCC/ARM, gcc-5/6-branch, ping] Fix PR77904: callee-saved register trashed when clobbering sp

[Kyrill Tkachov]

On 12/12/16 10:44, Thomas Preudhomme wrote:

Same as for PR77933, I'm trying to get this in for the next GCC 6 release.

I've successfully done a Thumb-1 bootstrap of the backport and testsuite shows 
no regression when run with an arm-none-eabi GCC cross-compiler targeting ARM 
Cortex-M0.

Is this ok for gcc-6-branch?



Given this has been in trunk for some time, is specific to Thumb-1 and fixes a 
wrong-code issue this is ok.
Thanks,
Kyrill


Best regards,

Thomas

On 06/12/16 11:38, Thomas Preudhomme wrote:

Ping?

Best regards,

Thomas

On 30/11/16 10:44, Thomas Preudhomme wrote:

Sorry, the bug cannot be reproduced on gcc-5-branch so it's probably better to
only do a backport to gcc-6-branch.

Ok for a backport to gcc-6-branch?

Best regards,

Thomas

On 30/11/16 10:42, Thomas Preudhomme wrote:

Hi,

Is this ok to backport to gcc-5-branch and gcc-6-branch? Patch applies cleanly
(patches attached for reference).


2016-11-30 Thomas Preud'homme 

Backport from mainline
2016-11-22  Thomas Preud'homme 

gcc/
PR target/77904
* config/arm/arm.c (thumb1_compute_save_reg_mask): Mark frame pointer
in save register mask if it is needed.

gcc/testsuite/
PR target/77904
* gcc.target/arm/pr77904.c: New test.


Best regards,

Thomas


On 22/11/16 10:45, Thomas Preudhomme wrote:

On 17/11/16 09:11, Kyrill Tkachov wrote:


On 17/11/16 08:56, Thomas Preudhomme wrote:

On 16/11/16 10:30, Kyrill Tkachov wrote:

Hi Thomas,

On 03/11/16 16:52, Thomas Preudhomme wrote:

Hi,

When using a callee-saved register to save the frame pointer the Thumb-1
prologue fails to save the callee-saved register before that. For ARM and
Thumb-2 targets the frame pointer is handled as a special case but
nothing is
done for Thumb-1 targets. This patch adds the same logic for Thumb-1
targets.

ChangeLog entries are as follow:

*** gcc/ChangeLog ***

2016-11-02  Thomas Preud'homme 

PR target/77904
* config/arm/arm.c (thumb1_compute_save_reg_mask): mark frame
pointer
in save register mask if it is needed.



s/mark/Mark/



*** gcc/testsuite/ChangeLog ***

2016-11-02  Thomas Preud'homme 

PR target/77904
* gcc.target/arm/pr77904.c: New test.


Testing: Testsuite shows no regression when run with arm-none-eabi GCC
cross-compiler for Cortex-M0 target.

Is this ok for trunk?



I'd ask for a bootstrap, but this code is Thumb-1 only so it wouldn't affect
anything.


I can bootstrap for armv4t with --with-mode=thumb which would at least
exercise the path. I'll try such a bootstrap on qemu.



If you can get it to work, then yes please.


Bootstrap came back clean so I've committed the patch (r242693). Thanks!

Best regards,

Thomas

Re: [PATCH] [AArch64] Implement popcount pattern

[Kyrill Tkachov]

Hi Naveen,

On 12/12/16 03:16, Hurugalawadi, Naveen wrote:

Hi,

Please find attached the patch that implements the support for popcount
patterns in AArch64.

The implementation improves OVS-DPDK on ThunderX by 3%. It would have a
similar effect on other AArch64 targets.

Please review the patch and let us know if its okay?


Besides a few comments below this looks good to me if it has gone through
the normal required bootstrap and testing, but I can't approve.
It's at the discretion of the target maintainers/reviewers if they want to
accept it at this stage.


2016-12-12  Andrew Pinski  

gcc
* config/aarch64/aarch64.md (popcount2): New pattern.

gcc/testsuite
* gcc.target/aarch64/popcount.c : New Testcase.


diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 65eb326..c688ddc 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -3785,6 +3785,39 @@
   }
 )
 
+/* Pop count be done via the pop count instruction in NEON. */


The rest of the MD file uses the term AdvSIMD. Also, the instrurction
is CNT rather than "pop count".

+/*
+  mov v.1d, x0
+  Cnt v1.8b, v.8b
+  Addv b2, v1.8b
+  Mov w0, v2.b[0]
+*/

Minor nit, but please use semicolons for MD file comments. The convention (at 
least in the aarch64 md files)
is to use ";;" at the beginning of the line. Also, please use uppercase letters 
for the assembly instructions
in the comment.

+(define_expand "popcount2"
+  [(match_operand:GPI 0 "register_operand")
+   (match_operand:GPI 1 "register_operand")]
+  "TARGET_SIMD"
+{
+  rtx v = gen_reg_rtx (V8QImode);
+  rtx v1 = gen_reg_rtx (V8QImode);
+  rtx r = gen_reg_rtx (QImode);
+  rtx in = operands[1];
+  rtx out = operands[0];
+  if(mode == SImode)
+{
+  rtx tmp;
+  tmp = gen_reg_rtx (DImode);
+  /* If we have SImode, zero extend to DImode, pop count does
+ not change if we have extra zeros. */
+  emit_insn (gen_zero_extendsidi2 (tmp, in));
+  in = tmp;
+}
+  emit_move_insn (v, gen_lowpart (V8QImode, in));
+  emit_insn (gen_popcountv8qi2 (v1, v));
+  emit_insn (gen_reduc_plus_scal_v8qi (r, v1));
+  emit_insn (gen_zero_extendqi2 (out, r));
+  DONE;
+})
+
 (define_insn "clrsb2"
   [(set (match_operand:GPI 0 "register_operand" "=r")
 (clrsb:GPI (match_operand:GPI 1 "register_operand" "r")))]
diff --git a/gcc/testsuite/gcc.target/aarch64/popcount.c 
b/gcc/testsuite/gcc.target/aarch64/popcount.c
new file mode 100644
index 000..2d71168
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/popcount.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+int foo(int x)
+{
+  return __builtin_popcount(x);
+}
+
+/* { dg-final { scan-assembler-not "popcountdi2" } } */

__builtin_popcount takes an unsigned int, so this should be scanning for 
absence of popcountsi2 instead?
I suggest you also add a test for popcountdi2 using__builtin_popcountll.
Thanks,
Kyrill

+/* { dg-final { scan-assembler "cnt\t" } } */

Re: Fix ICE with __builtin_va_list on i?86 (PR middle-end/78716)

[Marek Polacek]

On Mon, Dec 12, 2016 at 11:10:31AM +0100, Tom de Vries wrote:
> On 08/12/16 22:07, Marek Polacek wrote:
> > This test ICEs since r240072 where Tom disallowed using va_list * as a first
> > argument to va_arg.  I think the problem is in the ADDR_EXPR check in
> > gimplify_va_arg_expr.  It's meant to handle Case 1, but the valist doesn't
> > always have to be ADDR_EXPR.  E.g. for this testcase build_va_arg creates
> > VA_ARG_EXPR <&*s>
> > but during clone_body this is transformed into
> > VA_ARG_EXPR 
> > so we have a valid valist, but it's not an ADDR_EXPR, so we don't call
> > targetm.canonical_va_list_type and crash on the subsequent assert.
> > 
> > Tom, does this make sense to you?
> 
> Hi,
> 
> duing the compilation resulting in the ICE, the "Case 1" is triggered in
> build_va_arg, so we need the targetm.canonical_va_list_type retry in
> gimplify_va_arg_expr. Hence, the patch looks good to me.

Thanks.

Ok to commit, then?
 
> [ FTR, it would be cleaner to add an encoding of the case to VA_ARG_EXPR and
> call either:
> ...
> have_va_type
>   = targetm.canonical_va_list_type (TREE_TYPE (TREE_TYPE (valist)));
> ...
> 
> or:
> ...
> have_va_type
>   = targetm.canonical_va_list_type (TREE_TYPE (valist));
> ...
> in gimplify_va_arg_expr based on that encoding, but that's probably
> overkill. ]

Marek

Re: Fix ICE with __builtin_va_list on i?86 (PR middle-end/78716)

[Jakub Jelinek]

On Thu, Dec 08, 2016 at 10:07:59PM +0100, Marek Polacek wrote:
> 2016-12-08  Marek Polacek  
> 
>   PR middle-end/78716
>   * gimplify.c (gimplify_va_arg_expr): Don't require ADDR_EXPR for
>   Case 1.
> 
>   * g++.dg/other/vararg-5.C: New.
> 
> diff --git gcc/gimplify.c gcc/gimplify.c
> index 8611060..08c4faa 100644
> --- gcc/gimplify.c
> +++ gcc/gimplify.c
> @@ -12642,8 +12642,7 @@ gimplify_va_arg_expr (tree *expr_p, gimple_seq *pre_p,
>if (have_va_type == error_mark_node)
>  return GS_ERROR;
>have_va_type = targetm.canonical_va_list_type (have_va_type);
> -  if (have_va_type == NULL_TREE
> -  && TREE_CODE (valist) == ADDR_EXPR)
> +  if (have_va_type == NULL_TREE)
>  /* Handle 'Case 1: Not an array type' from c-common.c/build_va_arg.  */
>  have_va_type
>= targetm.canonical_va_list_type (TREE_TYPE (TREE_TYPE (valist)));

This assumes that TREE_TYPE (TREE_TYPE (valist)) is meaningful, which
isn't always the case.  So, shall it check instead that
POINTER_TYPE_P (TREE_TYPE (valist))
instead, or do we have any guarantees valist must be a pointer at this
point?

> diff --git gcc/testsuite/g++.dg/other/vararg-5.C 
> gcc/testsuite/g++.dg/other/vararg-5.C
> index e69de29..9327bd6 100644
> --- gcc/testsuite/g++.dg/other/vararg-5.C
> +++ gcc/testsuite/g++.dg/other/vararg-5.C
> @@ -0,0 +1,24 @@
> +// PR middle-end/78716
> +// { dg-do compile }
> +
> +template  +typename = int>
> +struct a;
> +template  struct b;
> +template  class e : 
> b::c {
> +  public:
> +  typedef e f;
> +typedef typename b::c g;
> +  e(__builtin_va_list *s) : g(__builtin_va_arg(*s, 
> int)) {}
> +};
> +template <> struct b { typedef e<> c; };
> +template <> struct e<> { template  e(h); };
> +template  class a : public e {};
> +template 
> +class a : e::f> {
> +  public:
> +  template 
> +   a(a) : a::f(0) {}
> +};
> +template  a<> r(i, j, k, l);
> +void q() { a(r(4, 6, 9, 7)); }
> 
>   Marek

Jakub

Re: [PATCH] Fill bitregion_{start,end} in store_constructor (PR, tree-optimization/78428).

[Eric Botcazou]

> Ok. I'm sending a patch that put gcc_unreachable to places where either size
> or (and) offset is a non-constant. This survives regression tests
> (including ada) on x86_64-linux-gnu. Apart from that normal bootstrap +
> regression tests works fine on ppc64le-redhat-linux.

I didn't manage to break it so it is OK by me.

-- 
Eric Botcazou

Re: [Patch doc] Document _Float16 availability on ARM/AArch64

[James Greenhalgh]

On Wed, Nov 30, 2016 at 02:36:28PM +, James Greenhalgh wrote:
> 
> Hi,
> 
> As subject - update extend.texi to mention availability of _Float16 types
> on ARM and AArch64.
> 
> OK?

*ping*

Thanks,
James

> 2016-11-30  James Greenhalgh  
> 
>   * doc/extend.texi (Floating Types): Document availability of
>   _Float16 on ARM/AArch64.
> 

> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index d873403..7d3d17a 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -997,8 +997,10 @@ IEEE binary128 format.  The @code{_Float64x} type is 
> supported on all
>  systems where @code{__float128} is supported.  The @code{_Float32}
>  type is supported on all systems supporting IEEE binary32; the
>  @code{_Float64} and @code{Float32x} types are supported on all systems
> -supporting IEEE binary64.  GCC does not currently support
> -@code{_Float16} or @code{_Float128x} on any systems.
> +supporting IEEE binary64.  The @code{_Float16} type is supported on AArch64
> +systems by default, and on ARM systems when the IEEE format for 16-bit
> +floating point types is selected with @option{-mfp16-format=ieee}.
> +GCC does not currently support @code{_Float128x} on any systems.
>  
>  On the PowerPC, @code{__ibm128} provides access to the IBM extended
>  double format, and it is intended to be used by the library functions

Re: [Patch Doc] Update documentation for __fp16 type

[James Greenhalgh]

On Thu, Dec 01, 2016 at 11:09:07AM +, James Greenhalgh wrote:
> 
> On Wed, Nov 30, 2016 at 05:58:13PM +, Joseph Myers wrote:
> > On Wed, 30 Nov 2016, James Greenhalgh wrote:
> >
> > > +@code{_Float16} type defined by ISO/IEC TS18661:3-2005
> >
> > Add a space after "TS", and it's -3:2015 not :3-2005.
> 
> You would think that after 2 months of having the specification sitting
> on my desk I'd have got that right... Fixed in this revision.

*ping*

Thanks,
James

> 
> > I think the -mfp16-format documentation in invoke.texi should also be
> > updated to reflect that it affects availability of _Float16.
> 
> I'm working on something larger for -mfp16-format, I'll update invoke.texi
> at that point (or otherwise before GCC 7 releases).
> 
> Thanks,
> James
> 
> ---
> 
> 2016-12-01  James Greenhalgh  
> 
>   * doc/extend.texi (Half-Precision): Update to document current
>   compiler behaviour.
> 

> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index 7d3d17a..23d03bd 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -1012,11 +1012,12 @@ that handle conversions if/when long double is 
> changed to be IEEE
>  @cindex half-precision floating point
>  @cindex @code{__fp16} data type
>  
> -On ARM targets, GCC supports half-precision (16-bit) floating point via
> -the @code{__fp16} type.  You must enable this type explicitly
> -with the @option{-mfp16-format} command-line option in order to use it.
> +On ARM and AArch64 targets, GCC supports half-precision (16-bit) floating
> +point via the @code{__fp16} type defined in the ARM C Language Extensions.
> +On ARM systems, you must enable this type explicitly with the
> +@option{-mfp16-format} command-line option in order to use it.
>  
> -ARM supports two incompatible representations for half-precision
> +ARM targets support two incompatible representations for half-precision
>  floating-point values.  You must choose one of the representations and
>  use it consistently in your program.
>  
> @@ -1031,22 +1032,20 @@ format, but does not support infinities or NaNs.  
> Instead, the range
>  of exponents is extended, so that this format can represent normalized
>  values in the range of @math{2^{-14}} to 131008.
>  
> -The @code{__fp16} type is a storage format only.  For purposes
> -of arithmetic and other operations, @code{__fp16} values in C or C++
> -expressions are automatically promoted to @code{float}.  In addition,
> -you cannot declare a function with a return value or parameters
> -of type @code{__fp16}.
> +The GCC port for AArch64 only supports the IEEE 754-2008 format, and does
> +not require use of the @option{-mfp16-format} command-line option.
>  
> -Note that conversions from @code{double} to @code{__fp16}
> -involve an intermediate conversion to @code{float}.  Because
> -of rounding, this can sometimes produce a different result than a
> -direct conversion.
> +The @code{__fp16} type may only be used as an argument to intrinsics defined
> +in @code{}, or as a storage format.  For purposes of
> +arithmetic and other operations, @code{__fp16} values in C or C++
> +expressions are automatically promoted to @code{float}.
>  
> -ARM provides hardware support for conversions between
> +The ARM target provides hardware support for conversions between
>  @code{__fp16} and @code{float} values
> -as an extension to VFP and NEON (Advanced SIMD).  GCC generates
> -code using these hardware instructions if you compile with
> -options to select an FPU that provides them;
> +as an extension to VFP and NEON (Advanced SIMD), and from ARMv8 provides
> +hardware support for conversions between @code{__fp16} and @code{double}
> +values.  GCC generates code using these hardware instructions if you
> +compile with options to select an FPU that provides them;
>  for example, @option{-mfpu=neon-fp16 -mfloat-abi=softfp},
>  in addition to the @option{-mfp16-format} option to select
>  a half-precision format.
> @@ -1054,8 +1053,12 @@ a half-precision format.
>  Language-level support for the @code{__fp16} data type is
>  independent of whether GCC generates code using hardware floating-point
>  instructions.  In cases where hardware support is not specified, GCC
> -implements conversions between @code{__fp16} and @code{float} values
> -as library calls.
> +implements conversions between @code{__fp16} and other types as library
> +calls.
> +
> +It is recommended that code which is intended to be portable use the
> +@code{_Float16} type defined by ISO/IEC TS 18661-3:2015
> +(@xref{Floating Types}).
>  
>  @node Decimal Float
>  @section Decimal Floating Types

Unreviewed patch

[Rainer Orth]

The following patch has remained unreviewed for a week:

[build] Disable hwcaps on libgfortran
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00336.html

It is required to unbreak bootstrap on Solaris/x86 and, though touching
both libgfortran and libitm, probably needs primarily a build
maintainer or global reviewer.

Besides, it's a prerequisite to fix a similar breakage in libgo:

https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00726.html

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [AArch64][ARM][GCC][PATCHv2 3/3] Add tests for missing Poly64_t intrinsics to GCC

[Tamar Christina]

Hi Andrew,

These should be fixed now.

Thanks,
Tamar


From: Andrew Pinski 
Sent: Wednesday, December 7, 2016 4:33:51 AM
To: Christophe Lyon
Cc: Tamar Christina; Kyrill Tkachov; James Greenhalgh; GCC Patches; 
christophe.l...@st.com; Marcus Shawcroft; Richard Earnshaw; nd
Subject: Re: [AArch64][ARM][GCC][PATCHv2 3/3] Add tests for missing Poly64_t 
intrinsics to GCC

On Wed, Nov 30, 2016 at 1:04 AM, Christophe Lyon
 wrote:
> Hi Tamar,
>
>
> On 29 November 2016 at 14:54, James Greenhalgh  
> wrote:
>> On Tue, Nov 29, 2016 at 01:48:22PM +, Kyrill Tkachov wrote:
>>>
>>> On 29/11/16 09:50, Tamar Christina wrote:
>>> >Hi All,
>>> >
>>> >The new patch contains the proper types for the intrinsics that should be 
>>> >returning uint64x1
>>> >and has the rest of the comments by Christophe in them.
>>>
>>> Ok with an appropriate ChangeLog entry.
>>
>> Also OK from an AArch64 persepctive based on the detailed review from
>> Christophe.
>>
>> Thanks,
>> James
>>
>
> After you committed this patch (r242962), I've noticed some
> regressions as follows:
> * on aarch64, vreinterpret_p128 and vreinterpret_p64 fail to compile
> with errors like
> warning: implicit declaration of function 'vreinterpretq_p64_p128
> warning: implicit declaration of function 'vreinterpretq_p128_s8
> error: incompatible types when assigning to type 'poly64x2_t' from type 'int'
> etc...
>
> * on arm configured for armv8-a, several tests fail to link or compile:
> vbsl.c:(.text+0x24f0): undefined reference to `expected_poly64x1'
> vdup-vmov.c:227:38: error: 'expected0_poly64x1' undeclared
> vdup_lane.c:(.text+0x1584): undefined reference to `expected_poly64x1'
>
> You can have more details at
> http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/242962/report-build-info.html

I see the expected_poly64x1 failures also for aarch64:
https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg00738.html

FAIL: gcc.target/aarch64/advsimd-intrinsics/vbsl.c   -O0  (test for
excess errors)
Excess errors:
vbsl.c:(.text+0x1dec): undefined reference to `expected_poly64x1'
vbsl.c:(.text+0x1df0): undefined reference to `expected_poly64x1'
vbsl.c:(.text+0x1e20): undefined reference to `expected_poly64x1'
vbsl.c:(.text+0x1e24): undefined reference to `expected_poly64x1'
vbsl.c:(.text+0x2a74): undefined reference to `expected_poly64x2'
vbsl.c:(.text+0x2a78): undefined reference to `expected_poly64x2'
vbsl.c:(.text+0x2aa8): undefined reference to `expected_poly64x2'
vbsl.c:(.text+0x2aac): undefined reference to `expected_poly64x2'


FAIL: gcc.target/aarch64/advsimd-intrinsics/vld1_dup.c   -O0  (test
for excess errors)
Excess errors:
/home/jenkins/workspace/BuildThunderX_native_gcc_upstream/gcc/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1_dup.c:175:38:
error: 'expected0_poly64x1' undeclared (first use in this function);
did you mean 'expected_poly64x1'?
/home/jenkins/workspace/BuildThunderX_native_gcc_upstream/gcc/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1_dup.c:175:38:
error: 'expected0_poly64x2' undeclared (first use in this function);
did you mean 'expected0_poly64x1'?
/home/jenkins/workspace/BuildThunderX_native_gcc_upstream/gcc/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1_dup.c:178:38:
error: 'expected1_poly64x1' undeclared (first use in this function);
did you mean 'expected0_poly64x1'?
/home/jenkins/workspace/BuildThunderX_native_gcc_upstream/gcc/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1_dup.c:178:38:
error: 'expected1_poly64x2' undeclared (first use in this function);
did you mean 'expected1_poly64x1'?
/home/jenkins/workspace/BuildThunderX_native_gcc_upstream/gcc/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1_dup.c:181:38:
error: 'expected2_poly64x1' undeclared (first use in this function);
did you mean 'expected1_poly64x1'?
/home/jenkins/workspace/BuildThunderX_native_gcc_upstream/gcc/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1_dup.c:181:38:
error: 'expected2_poly64x2' undeclared (first use in this function);
did you mean 'expected2_poly64x1'?


etc.

>
>
> Christophe

[patch,avr,committed] Minor tweak for 64-bit shifts.

[Georg-Johann Lay]

https://gcc.gnu.org/r243545

Applied this obvious tweak to trunk.

Johann


libgcc/
* config/avr/lib1funcs.S (__ashldi3): Use __tmp_reg__ to restore
R16 instead of push + pop.
(__ashrdi3, __lshrdi3): Same. And use __zero_reg__ for signs.

Index: config/avr/lib1funcs.S
===
--- config/avr/lib1funcs.S	(revision 243542)
+++ config/avr/lib1funcs.S	(working copy)
@@ -3113,20 +3113,22 @@ ENDF __bswapdi2
  **/
 
 #if defined (L_ashrdi3)
+
+#define SS __zero_reg__
+
 ;; Arithmetic shift right
 ;; r25:r18 = ashr64 (r25:r18, r17:r16)
 DEFUN __ashrdi3
-bst r25, 7
-bld __zero_reg__, 0
+sbrcr25, 7
+neg SS
 ;; FALLTHRU
 ENDF  __ashrdi3
 
 ;; Logic shift right
 ;; r25:r18 = lshr64 (r25:r18, r17:r16)
 DEFUN __lshrdi3
-lsr __zero_reg__
-sbc __tmp_reg__, __tmp_reg__
-pushr16
+;; Signs are in SS (zero_reg)
+mov __tmp_reg__, r16
 0:  cpi r16, 8
 brlo 2f
 subir16, 8
@@ -3137,9 +3139,9 @@ DEFUN __lshrdi3
 mov r22, r23
 mov r23, r24
 mov r24, r25
-mov r25, __tmp_reg__
+mov r25, SS
 rjmp 0b
-1:  asr __tmp_reg__
+1:  asr SS
 ror r25
 ror r24
 ror r23
@@ -3150,16 +3152,21 @@ DEFUN __lshrdi3
 ror r18
 2:  dec r16
 brpl 1b
-pop r16
+clr __zero_reg__
+mov r16, __tmp_reg__
 ret
 ENDF __lshrdi3
+
+#undef SS
+
 #endif /* defined (L_ashrdi3) */
 
 #if defined (L_ashldi3)
 ;; Shift left
 ;; r25:r18 = ashl64 (r25:r18, r17:r16)
+;; This function does not clobber T.
 DEFUN __ashldi3
-pushr16
+mov __tmp_reg__, r16
 0:  cpi r16, 8
 brlo 2f
 mov r25, r24
@@ -3182,13 +3189,13 @@ DEFUN __ashldi3
 rol r25
 2:  dec r16
 brpl 1b
-pop r16
+mov r16, __tmp_reg__
 ret
 ENDF __ashldi3
 #endif /* defined (L_ashldi3) */
 
 #if defined (L_rotldi3)
-;; Shift left
+;; Rotate left
 ;; r25:r18 = rotl64 (r25:r18, r17:r16)
 DEFUN __rotldi3
 pushr16

[PATCH, fortran, pr77785, v2] [Coarray] ICE in gfc_get_caf_token_offset, at fortran/trans-expr.c:1990

[Andre Vehreschild]

Hi all,

the attached patch corrects reporting of "Sorry, unimplemented yet" for
allocatable and pointer components in polymorphic objects (BT_CLASS) thus
fixing two ICEs reported in the PR.

The next chunk fixes an ICE when the declaration containing the token
information is of type POINTER or REFERENCE.

Bootstraps and regtests ok on x86_64-linux/f23. Ok for trunk?

- Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
gcc/fortran/ChangeLog:

2016-12-12  Andre Vehreschild  

PR fortran/77785
* resolve.c (resolve_symbol): Correct attr lookup to the _data
component.
* trans-array.c (gfc_alloc_allocatable_for_assignment): Indirect ref
pointers and references before retrieving the caf-token.

gcc/testsuite/ChangeLog:

2016-12-12  Andre Vehreschild  

PR fortran/77785
* gfortran.dg/coarray_38.f90: Added expecting error message.
* gfortran.dg/coarray_class_2.f90: New test.


diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 2093de91..a967bfd 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -14067,8 +14067,8 @@ resolve_symbol (gfc_symbol *sym)
   if (flag_coarray == GFC_FCOARRAY_LIB && sym->ts.type == BT_CLASS
   && sym->ts.u.derived && CLASS_DATA (sym)
   && CLASS_DATA (sym)->attr.codimension
-  && (sym->ts.u.derived->attr.alloc_comp
-	  || sym->ts.u.derived->attr.pointer_comp))
+  && (CLASS_DATA (sym)->ts.u.derived->attr.alloc_comp
+	  || CLASS_DATA (sym)->ts.u.derived->attr.pointer_comp))
 {
   gfc_error ("Sorry, allocatable/pointer components in polymorphic (CLASS) "
 		 "type coarrays at %L are unsupported", &sym->declared_at);
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 8753cbf..0cd83f4 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -9337,6 +9337,8 @@ gfc_alloc_allocatable_for_assignment (gfc_loopinfo *loop,
   if (token == NULL_TREE)
 	{
 	  tmp = gfc_get_tree_for_caf_expr (expr1);
+	  if (POINTER_TYPE_P (TREE_TYPE (tmp)))
+	tmp = build_fold_indirect_ref (tmp);
 	  gfc_get_caf_token_offset (&caf_se, &token, NULL, tmp, NULL_TREE,
 expr1);
 	  token = gfc_build_addr_expr (NULL_TREE, token);
diff --git a/gcc/testsuite/gfortran.dg/coarray_38.f90 b/gcc/testsuite/gfortran.dg/coarray_38.f90
index c8011d4..04ef742 100644
--- a/gcc/testsuite/gfortran.dg/coarray_38.f90
+++ b/gcc/testsuite/gfortran.dg/coarray_38.f90
@@ -92,7 +92,7 @@ end type t
 type t2
   class(t), allocatable :: caf2[:]
 end type t2
-class(t), save, allocatable :: caf[:]
+class(t), save, allocatable :: caf[:] ! { dg-error "Sorry, allocatable/pointer components in polymorphic" }
 type(t) :: x
 type(t2) :: y
 
diff --git a/gcc/testsuite/gfortran.dg/coarray_class_2.f90 b/gcc/testsuite/gfortran.dg/coarray_class_2.f90
new file mode 100644
index 000..58dce1a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray_class_2.f90
@@ -0,0 +1,45 @@
+! { dg-do compile }
+! { dg-options "-fcoarray=lib" }
+! Check that error message is presented as long as polymorphic coarrays are
+! not implemented.
+
+module maccscal
+   type t
+  real, allocatable :: a
+   end type
+contains
+   subroutine s(x) ! { dg-error "Sorry, allocatable/pointer components in polymorphic \\(CLASS\\)" }
+  class(t) :: x[*]
+  allocate (x%a)
+   end
+end
+module mptrscal
+   type t
+  real, pointer :: a
+   end type
+contains
+   subroutine s(x) ! { dg-error "Sorry, allocatable/pointer components in polymorphic \\(CLASS\\)" }
+  class(t) :: x[*]
+  allocate (x%a)
+   end
+end
+module mallarr
+   type t
+  real, allocatable :: a(:)
+   end type
+contains
+   subroutine s(x) ! { dg-error "Sorry, allocatable/pointer components in polymorphic \\(CLASS\\)" }
+  class(t) :: x[*]
+  allocate (x%a(2))
+   end
+end
+module mptrarr
+   type t
+  real, pointer :: a(:)
+   end type
+contains
+   subroutine s(x) ! { dg-error "Sorry, allocatable/pointer components in polymorphic \\(CLASS\\)" }
+  class(t) :: x[*]
+  allocate (x%a(2))
+   end
+end

Re: [PATCH] Add ISA 3.0 PowerPC support for VEXTU{B,H,W}{L,R}X instructions

[Segher Boessenkool]

Hi Mike,

On Fri, Dec 09, 2016 at 03:48:10PM -0500, Michael Meissner wrote:
> @@ -7528,6 +7528,49 @@ rs6000_split_vec_extract_var (rtx dest, 

> +  if (TARGET_P9_VECTOR
> +   && (mode == V16QImode || mode == V8HImode || mode == V4SImode)
> +   && INT_REGNO_P (dest_regno)
> +   && ALTIVEC_REGNO_P (src_regno)
> +   && INT_REGNO_P (element_regno))
> + {
> +   rtx insn = NULL_RTX;

You don't need this initialisation (which just works around a warning) if
you do the emit_insn directly for all cases.

> +   else if (mode == V8HImode)
> + {
> +   emit_insn (gen_ashlsi3 (dest_si, element_si, const1_rtx));
> +   insn = (VECTOR_ELT_ORDER_BIG
> +   ? gen_vextuhlx (dest_si, dest_si, src)
> +   : gen_vextuhrx (dest_si, dest_si, src));
> + }

If you use a separate temporary reg (instead of reusing dest_si) GCC
has a better chance at optimising this (also in the next case).

> @@ -2535,36 +2547,63 @@ (define_expand  "vsx_extract_"
>  })
>  
>  (define_insn "vsx_extract__p9"
> -  [(set (match_operand: 0 "gpc_reg_operand" "=")
> +  [(set (match_operand: 0 "gpc_reg_operand" "=r,")
>   (vec_select:
> -  (match_operand:VSX_EXTRACT_I 1 "gpc_reg_operand" "")
> -  (parallel [(match_operand:QI 2 "" "n")])))]
> +  (match_operand:VSX_EXTRACT_I 1 "gpc_reg_operand" "wK,")
> +  (parallel [(match_operand:QI 2 "" "n,n")])))]
>"VECTOR_MEM_VSX_P (mode) && TARGET_VEXTRACTUB
> && TARGET_VSX_SMALL_INTEGER"
>  {
> -  HOST_WIDE_INT elt = INTVAL (operands[2]);
> -  HOST_WIDE_INT elt_adj = (!VECTOR_ELT_ORDER_BIG
> -? GET_MODE_NUNITS (mode) - 1 - elt
> -: elt);
> -
> -  HOST_WIDE_INT unit_size = GET_MODE_UNIT_SIZE (mode);
> -  HOST_WIDE_INT offset = unit_size * elt_adj;
> -
> -  operands[2] = GEN_INT (offset);
> -  if (unit_size == 4)
> -return "xxextractuw %x0,%x1,%2";
> +  if (which_alternative == 0)
> +return "#";
> +
>else

Without else-after-return the code as well as the patch become more readable.

> -return "vextractu %0,%1,%2";
> +{
> +  HOST_WIDE_INT elt = INTVAL (operands[2]);
> +  HOST_WIDE_INT elt_adj = (!VECTOR_ELT_ORDER_BIG
> +? GET_MODE_NUNITS (mode) - 1 - elt
> +: elt);
> +
> +  HOST_WIDE_INT unit_size = GET_MODE_UNIT_SIZE (mode);
> +  HOST_WIDE_INT offset = unit_size * elt_adj;
> +
> +  operands[2] = GEN_INT (offset);
> +  if (unit_size == 4)
> + return "xxextractuw %x0,%x1,%2";
> +  else
> + return "vextractu %0,%1,%2";
> +}
>  }
>[(set_attr "type" "vecsimple")])


> +(define_split
> +  [(set (match_operand: 0 "int_reg_operand" "")
> + (vec_select:
> +  (match_operand:VSX_EXTRACT_I 1 "altivec_register_operand" "")
> +  (parallel [(match_operand:QI 2 "" "")])))]
> +  "VECTOR_MEM_VSX_P (mode) && TARGET_VEXTRACTUB
> +   && TARGET_VSX_SMALL_INTEGER && reload_completed"
> +  [(const_int 0)]

Please lose the default args ("").

Why only do the split when reload_completed?

> +(define_insn_and_split "*vsx_extract___var"
> +  [(set (match_operand:SDI 0 "gpc_reg_operand" "=r,r,r")
> + (zero_extend:SDI
> +  (unspec:
> +   [(match_operand:VSX_EXTRACT_I 1 "input_operand" "wK,v,m")
> +(match_operand:DI 2 "gpc_reg_operand" "r,r,r")]
> +   UNSPEC_VSX_EXTRACT)))
> +   (clobber (match_scratch:DI 3 "=X,r,&b"))
> +   (clobber (match_scratch:V2DI 4 "=X,&v,X"))]
> +  "VECTOR_MEM_VSX_P (mode) && TARGET_DIRECT_MOVE_64BIT"
> +  "#"
> +  "&& reload_completed"

And here.  And everything following.

> +  [(const_int 0)]
> +{
> +  machine_mode smode = mode;
> +  rs6000_split_vec_extract_var (gen_rtx_REG (smode, REGNO (operands[0])),
> + operands[1], operands[2],
> + operands[3], operands[4]);
> +  DONE;
> +})

Please write the gen_rtx_REG on its own line (but you can eliminate smode
then).

> --- gcc/testsuite/gcc.target/powerpc/vec-extract-v4si-df.c
> (.../svn+ssh://meiss...@gcc.gnu.org/svn/gcc/trunk/gcc/testsuite/gcc.target/powerpc)
>  (revision 0)
> +++ gcc/testsuite/gcc.target/powerpc/vec-extract-v4si-df.c
> (.../gcc/testsuite/gcc.target/powerpc)  (revision 243492)
> @@ -0,0 +1,12 @@
> +/* { dg-do run { target { powerpc*-*-linux* } } } */
> +/* { dg-require-effective-target vsx_hw } */
> +/* { dg-options "-O2 -mvsx" } */

Why limit to linux?  In most other testcases we explicitly disallow most
other targets (also not ideal at all, no, but consistency helps here).
Same for the other new files.

> +/* { dg-final { scan-assembler "vextub\[lr\]x" } } */
> +/* { dg-final { scan-assembler "vextuh\[lr\]x" } } */
> +/* { dg-final { scan-assembler "vextuw\[lr\]x" } } */
> +/* { dg-final { scan-assembler "extsb" } } */
> +/* { dg-final { scan-assembler "extsh" } } */
> +/* { dg-final { scan-assembler "extsw" } } */
> +/* { dg

Re: [Darwin,PPC] Remove use of LR in restore_world.

[Segher Boessenkool]

Hi Iain,

On Sun, Dec 11, 2016 at 08:00:02PM +, Iain Sandoe wrote:
>  r239866 removed most of the uses of LR in returns and sibcalls
> 
> Darwin had an additional use of LR in the restore_world machinery.  This 
> patch removes it
> from the pattern in altivec.md and the relevant predicate.
> 
> OK / Comments?

Okay for trunk.  Sorry I missed this one.  It is a big splatter of ICEs
without the patch, I guess?


Segher

Re: [PATCH] gcc: config: tilegx: Reserve prev insn when delete useless insn

[chengang]

From: Chen Gang 

On Sat, Dec 10, 2016 at 03:38:10PM +, Bernd Edlinger wrote:
> On 12/10/16 12:23, cheng...@emindsoft.com.cn wrote:
> > From: Chen Gang 
> >
> > When check bundle, gcc may still need modify the prev insn. Original
> > implementation will lose the prev insn.
> >
> > Also correct the coding styles of relate code.
> >
> > 2016-12-10  Chen Gang 
> >
> > gcc/
> > PR target/78222
> > * tilegx.c (tilegx_gen_bundle): Reserve prev insn when delete
> > useless insn.
> 
> I think this was already fixed by Walt:
> 
> 
> r242617 | walt | 2016-11-19 03:34:17 +0100 (Sat, 19 Nov 2016) | 5 lines
> Changed paths:
> M /trunk/gcc/ChangeLog
> M /trunk/gcc/config/tilegx/tilegx.c
> 
> TILE-Gx: Fix bundling when encountering consecutive barriers.
> 
>  * config/tilegx/tilegx.c (tilegx_gen_bundles): Preserve
>end-of-bundle marker for consecutive barriers.
> 

Oh, yes, Good news to me.

> 
> But the formatting here is still odd, and should be fixed:
> TAB usage, single statements in braces, { not in a line of its own.
> 

Yes.

> I am however not sure about this statement:
> 
>/* Never wrap {} around inline asm.  */
>if (GET_CODE (PATTERN (insn)) != ASM_INPUT)
> 
> ... because this does only exclude asm(""); that is basic asm with
> empty assembler string.  To exclude all other forms of asm statements
> that are hidden in PARALLEL constructs we would need:
> 
>/* Never wrap {} around inline asm.  */
>if (GET_CODE (PATTERN (insn)) != ASM_INPUT
>&& asm_noperands (PATTERN (insn)) < 0)
> 
> 
> I think this if-condition is probably unnecessary, because it does
> apparently not create any problems although it is completely broken.
> 

For me, we need not touch it, since we are not quite sure about it. And
welcome any other related members' idea for it.


All together, I guess, I can leave this patch and continue to find and
send another patches about tilegx. If I should still do somthing about
this patch, please let me know.

Thanks.

>From cheng...@emindsoft.com.cn Mon Dec 12 19:23:58 2016
Date: Mon, 12 Dec 2016 19:23:58 +0800
From: Chen Gang 
To: Bernd Edlinger 
Cc: "cheng...@emindsoft.com.cn" ,
"l...@redhat.com" ,
"r...@redhat.com" ,
"mikest...@comcast.net" ,
"w...@tilera.com" ,
"gcc-patches@gcc.gnu.org" ,
"peter.mayd...@linaro.com" ,
"cmetc...@mellanox.com" 
Subject: Re: [PATCH] gcc: config: tilegx: Reserve prev insn when delete
 useless insn
Message-ID: <20161212112320.GA22787@localhost.localdomain>
References: <1481369032-26571-1-git-send-email-cheng...@emindsoft.com.cn>
 

MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

User-Agent: Mutt/1.7.1 (2016-10-04)
Status: RO
Content-Length: 2159
Lines: 66

On Sat, Dec 10, 2016 at 03:38:10PM +, Bernd Edlinger wrote:
> On 12/10/16 12:23, cheng...@emindsoft.com.cn wrote:
> > From: Chen Gang 
> >
> > When check bundle, gcc may still need modify the prev insn. Original
> > implementation will lose the prev insn.
> >
> > Also correct the coding styles of relate code.
> >
> > 2016-12-10  Chen Gang 
> >
> > gcc/
> > PR target/78222
> > * tilegx.c (tilegx_gen_bundle): Reserve prev insn when delete
> > useless insn.
> 
> I think this was already fixed by Walt:
> 
> 
> r242617 | walt | 2016-11-19 03:34:17 +0100 (Sat, 19 Nov 2016) | 5 lines
> Changed paths:
> M /trunk/gcc/ChangeLog
> M /trunk/gcc/config/tilegx/tilegx.c
> 
> TILE-Gx: Fix bundling when encountering consecutive barriers.
> 
>  * config/tilegx/tilegx.c (tilegx_gen_bundles): Preserve
>end-of-bundle marker for consecutive barriers.
> 

Oh, yes, Good news to me.

> 
> But the formatting here is still odd, and should be fixed:
> TAB usage, single statements in braces, { not in a line of its own.
> 

Yes.

> I am however not sure about this statement:
> 
>/* Never wrap {} around inline asm.  */
>if (GET_CODE (PATTERN (insn)) != ASM_INPUT)
> 
> ... because this does only exclude asm(""); that is basic asm with
> empty assembler string.  To exclude all other forms of asm statements
> that are hidden in PARALLEL constructs we would need:
> 
>/* Never wrap {} around inline asm.  */
>if (GET_CODE (PATTERN (insn)) != ASM_INPUT
>&& asm_noperands (PATTERN (insn)) < 0)
> 
> 
> I think this if-condition is probably unnecessary, because it does
> apparently not create any problems although it is completely broken.
> 

For me, we need not touch it, since we are not quite sure about it. And
welcome any other related members' idea for it.


All together, I guess, I can leave this patch and continue to find and
send another patches about tilegx. If I should still do somth

Re: Fix ICE with __builtin_va_list on i?86 (PR middle-end/78716)

[Marek Polacek]

On Mon, Dec 12, 2016 at 12:03:16PM +0100, Jakub Jelinek wrote:
> On Thu, Dec 08, 2016 at 10:07:59PM +0100, Marek Polacek wrote:
> > 2016-12-08  Marek Polacek  
> > 
> > PR middle-end/78716
> > * gimplify.c (gimplify_va_arg_expr): Don't require ADDR_EXPR for
> > Case 1.
> > 
> > * g++.dg/other/vararg-5.C: New.
> > 
> > diff --git gcc/gimplify.c gcc/gimplify.c
> > index 8611060..08c4faa 100644
> > --- gcc/gimplify.c
> > +++ gcc/gimplify.c
> > @@ -12642,8 +12642,7 @@ gimplify_va_arg_expr (tree *expr_p, gimple_seq 
> > *pre_p,
> >if (have_va_type == error_mark_node)
> >  return GS_ERROR;
> >have_va_type = targetm.canonical_va_list_type (have_va_type);
> > -  if (have_va_type == NULL_TREE
> > -  && TREE_CODE (valist) == ADDR_EXPR)
> > +  if (have_va_type == NULL_TREE)
> >  /* Handle 'Case 1: Not an array type' from c-common.c/build_va_arg.  */
> >  have_va_type
> >= targetm.canonical_va_list_type (TREE_TYPE (TREE_TYPE (valist)));
> 
> This assumes that TREE_TYPE (TREE_TYPE (valist)) is meaningful, which
> isn't always the case.  So, shall it check instead that
> POINTER_TYPE_P (TREE_TYPE (valist))
> instead, or do we have any guarantees valist must be a pointer at this
> point?

Yeah, given
expr = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (expr)), expr);
in build_va_arg it seems it'll always be a pointer, so the following is
probably safer.

Bootstrap/regtest running on x86_64-linux, ok for trunk if it passes?

2016-12-12  Marek Polacek  

PR middle-end/78716
* gimplify.c (gimplify_va_arg_expr): Don't require ADDR_EXPR for
Case 1; check POINTER_TYPE_P instead.

* g++.dg/other/vararg-5.C: New.

diff --git gcc/gimplify.c gcc/gimplify.c
index 8611060..b738855 100644
--- gcc/gimplify.c
+++ gcc/gimplify.c
@@ -12643,7 +12643,7 @@ gimplify_va_arg_expr (tree *expr_p, gimple_seq *pre_p,
 return GS_ERROR;
   have_va_type = targetm.canonical_va_list_type (have_va_type);
   if (have_va_type == NULL_TREE
-  && TREE_CODE (valist) == ADDR_EXPR)
+  && POINTER_TYPE_P (TREE_TYPE (valist)))
 /* Handle 'Case 1: Not an array type' from c-common.c/build_va_arg.  */
 have_va_type
   = targetm.canonical_va_list_type (TREE_TYPE (TREE_TYPE (valist)));
diff --git gcc/testsuite/g++.dg/other/vararg-5.C 
gcc/testsuite/g++.dg/other/vararg-5.C
index e69de29..9327bd6 100644
--- gcc/testsuite/g++.dg/other/vararg-5.C
+++ gcc/testsuite/g++.dg/other/vararg-5.C
@@ -0,0 +1,24 @@
+// PR middle-end/78716
+// { dg-do compile }
+
+template 
+  struct a;
+  template  struct b;
+  template  class e : 
b::c {
+public:
+typedef e f;
+  typedef typename b::c g;
+e(__builtin_va_list *s) : g(__builtin_va_arg(*s, 
int)) {}
+  };
+template <> struct b { typedef e<> c; };
+template <> struct e<> { template  e(h); };
+template  class a : public e {};
+template 
+class a : e::f> {
+  public:
+  template 
+ a(a) : a::f(0) {}
+};
+template  a<> r(i, j, k, l);
+void q() { a(r(4, 6, 9, 7)); }

Marek

Re: Fix ICE with __builtin_va_list on i?86 (PR middle-end/78716)

[Jakub Jelinek]

On Mon, Dec 12, 2016 at 01:09:16PM +0100, Marek Polacek wrote:
> Yeah, given
> expr = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (expr)), expr);
> in build_va_arg it seems it'll always be a pointer, so the following is

Well, if you think it is guaranteed it always is a pointer, then you could
just gcc_{,checking_}assert it there.
The code will fail an assertion anyway if it is not a pointer type, because
then have_va_type will be still NULL and thus
  gcc_assert (have_va_type != NULL_TREE);
will ICE, so I bet it really doesn't matter if you write it as:
  if (have_va_type == NULL_TREE)
{
  gcc_assert (POINTER_TYPE_P (TREE_TYPE (valist)));
  have_va_type
= targetm.canonical_va_list_type (TREE_TYPE (TREE_TYPE (valist)));
}
  gcc_assert (have_va_type != NULL_TREE);
or as you wrote it.

So your patch LGTM.

> Bootstrap/regtest running on x86_64-linux, ok for trunk if it passes?
> 
> 2016-12-12  Marek Polacek  
> 
>   PR middle-end/78716
>   * gimplify.c (gimplify_va_arg_expr): Don't require ADDR_EXPR for
>   Case 1; check POINTER_TYPE_P instead.
> 
>   * g++.dg/other/vararg-5.C: New.

Jakub

Re: [PATCH, fortran, pr77785, v2] [Coarray] ICE in gfc_get_caf_token_offset, at fortran/trans-expr.c:1990

[Janus Weil]

Hi Andre,

> the attached patch corrects reporting of "Sorry, unimplemented yet" for
> allocatable and pointer components in polymorphic objects (BT_CLASS) thus
> fixing two ICEs reported in the PR.
>
> The next chunk fixes an ICE when the declaration containing the token
> information is of type POINTER or REFERENCE.
>
> Bootstraps and regtests ok on x86_64-linux/f23. Ok for trunk?

the resolve.c hunk is certainly ok. The trans-array.c part looks
reasonable as well, but I wonder if it is actually covered by any of
your test cases? Since they are all compile-only, with errors being
thrown at resolution stage, do they even get to the translation stage?

Cheers,
Janus

Re: Fix ICE with __builtin_va_list on i?86 (PR middle-end/78716)

[Richard Biener]

On December 12, 2016 11:56:36 AM GMT+01:00, Marek Polacek  
wrote:
>On Mon, Dec 12, 2016 at 11:10:31AM +0100, Tom de Vries wrote:
>> On 08/12/16 22:07, Marek Polacek wrote:
>> > This test ICEs since r240072 where Tom disallowed using va_list *
>as a first
>> > argument to va_arg.  I think the problem is in the ADDR_EXPR check
>in
>> > gimplify_va_arg_expr.  It's meant to handle Case 1, but the valist
>doesn't
>> > always have to be ADDR_EXPR.  E.g. for this testcase build_va_arg
>creates
>> > VA_ARG_EXPR <&*s>
>> > but during clone_body this is transformed into
>> > VA_ARG_EXPR 
>> > so we have a valid valist, but it's not an ADDR_EXPR, so we don't
>call
>> > targetm.canonical_va_list_type and crash on the subsequent assert.
>> > 
>> > Tom, does this make sense to you?
>> 
>> Hi,
>> 
>> duing the compilation resulting in the ICE, the "Case 1" is triggered
>in
>> build_va_arg, so we need the targetm.canonical_va_list_type retry in
>> gimplify_va_arg_expr. Hence, the patch looks good to me.
>
>Thanks.
>
>Ok to commit, then?
>
OK.

Richard.

>> [ FTR, it would be cleaner to add an encoding of the case to
>VA_ARG_EXPR and
>> call either:
>> ...
>> have_va_type
>>   = targetm.canonical_va_list_type (TREE_TYPE (TREE_TYPE
>(valist)));
>> ...
>> 
>> or:
>> ...
>> have_va_type
>>   = targetm.canonical_va_list_type (TREE_TYPE (valist));
>> ...
>> in gimplify_va_arg_expr based on that encoding, but that's probably
>> overkill. ]
>
>   Marek

[PATCH] Remove stray character at end of dg-do directive

[Jonathan Wakely]

* testsuite/experimental/filesystem/operations/temp_directory_path.cc:
Remove stray character at end of dg-do directive.

Tested x86_64-linux, committed to trunk.

commit 290f8727a83d8f94404fe254bc9334c870f23eca
Author: Jonathan Wakely 
Date:   Mon Dec 12 12:41:17 2016 +

Remove stray character at end of dg-do directive

* testsuite/experimental/filesystem/operations/temp_directory_path.cc:
Remove stray character at end of dg-do directive.

diff --git 
a/libstdc++-v3/testsuite/experimental/filesystem/operations/temp_directory_path.cc
 
b/libstdc++-v3/testsuite/experimental/filesystem/operations/temp_directory_path.cc
index 7f7e9fd..f043195 100644
--- 
a/libstdc++-v3/testsuite/experimental/filesystem/operations/temp_directory_path.cc
+++ 
b/libstdc++-v3/testsuite/experimental/filesystem/operations/temp_directory_path.cc
@@ -16,7 +16,7 @@
 // .
 
 // { dg-options "-lstdc++fs" }
-// { dg-do run { target c++11 } }E
+// { dg-do run { target c++11 } }
 // { dg-require-filesystem-ts "" }
 
 #include 

Re: Unreviewed patch

[FX]

> The following patch has remained unreviewed for a week:
> 
>   [build] Disable hwcaps on libgfortran
>https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00336.html
> 
> It is required to unbreak bootstrap on Solaris/x86 and, though touching
> both libgfortran and libitm, probably needs primarily a build
> maintainer or global reviewer.

The Fortran part is OK, but I can’t approve the libitm part.

FX

Re: [PATCH] PR 78534 Change character length from int to size_t

[Janne Blomqvist]

On Mon, Dec 12, 2016 at 12:20 PM, FX  wrote:
> Hi Janne,
>
> This is an ABI change, so it is serious… it will require people to recompile 
> older code and libraries with the new compiler. Do we already plan to break 
> the ABI in this cycle, or is this the first ABI-breaking patch of the cycle?

As Andre mentioned, the ABI has already been broken, Gfortran 7 will
have libgfortran.so.4.

However, this will also affect people doing C->Fortran calls the
old-fashioned way without ISO_C_BINDING, as they will have to change
the string length argument from int to size_t in their prototypes.
Then again, Intel Fortran did this some years ago so I guess at least
people who care about portability to several compilers are aware.

> And do we have real-life examples of character strings larger than 2 GB?

Well, people who have needed such will have figured out some
work-around since we haven't supported it, so how would we know? :) It
could be splitting the data into several strings, or switching to
ifort, using C instead of Fortran, or something else.

In any case, I don't expect characters larger than 2 GB to be common
(particularly with the Fortran standard-mandated behaviour of
space-padding to the end in many cases), but as the ABI has been
broken anyways, we might as well fix it.

IIRC at some point there was some discussion of this on
comp.lang.fortran, and somebody mentioned analysis of genomic data as
a use case where large characters can be useful. I don't have any
personal usecase though, at least at the moment.

>> Also, as there are some places in the frontend were negative character
>> lengths are used as special flag values, in the frontend the character
>> length is handled as a signed variable of the same size as a size_t,
>> although in the runtime library it really is size_t.
>
> First, I thought: we should really make it size_t, and have the negative 
> values be well-defined constants, e.g. (size_t) -1

I tried it, but in addition to the issue with negative characters used
as flag values, there's issues like we have stuff such as
gfc_get_int_expr() that take a kind value, and an integer constant,
and produces a gfc_expr. But that doesn't understand stuff like
unsigned types. So in the end I decided it's better to get this patch
in working shape and merged with the ABI changes, then one can fix the
unsigned-ness later (in the end it's just a factor of two in sizes we
can handle, so not a huge deal).

> On the other hand, there is the problem of the case where the front-end has 
> different size_t than the target: think 32-bit on 64-bit i386 (front-end 
> size_t larger than target size_t), or cross-compiling for 64-bit on a 32-bit 
> machine (front-end size_t smaller than target size_t). So the charlen type 
> bounds need to be determined when the front-end runs, not when it is compiled 
> (i.e. it is not a fixed type).

True. Although things like gfc_charlen_type_node should be correct for
the target, the type gfc_charlen_t that I introduced in the frontend
might be too small if one is doing a 32->64 bit cross-compile. So that
should be changed from a typedef of ptrdiff_t to a typedef of
HOST_WIDE_INT which AFAIK is guaranteed to be 64-bit everywhere.

> In iresolve.c, the "Why is this fixup needed?” comment is kinda scary.

Hmm, I think it's a leftover from some earlier experimentation, should
be removed.

>> I haven't changed the character length variables for the co-array
>> intrinsics, as this is something that may need to be synchronized with
>> OpenCoarrays.
>
> Won’t that mean that coarray programs will fail due to ABI mismatch?

No, the co-array intrinsics are, well, intrinsics, so they're handled
specially in the frontend and don't need to follow the normal
argument-passing conventions. But I think it'd be easier if they did,
and might prevent some obscure corner-case bugs. Say, create a
character variable with length 2**31+9, then typecasting to plain int
when calling the intrinsic would wrap around and the library would see
a negative length.



-- 
Janne Blomqvist

Re: [PATCH] PR 78534 Change character length from int to size_t

[Janne Blomqvist]

On Mon, Dec 12, 2016 at 12:29 PM, Andre Vehreschild  wrote:
> I will take on the coarray ABI changes in the next days and also emit a
> pull-request to the opencoarrays to get them to sync. Janne, please wait until
> I have added those changes to prevent people from having to re-compile 
> multiple
> times.

Ok, thanks for taking care of this!


-- 
Janne Blomqvist

Re: Unreviewed patch

[Jakub Jelinek]

On Mon, Dec 12, 2016 at 01:54:41PM +0100, FX wrote:
> > The following patch has remained unreviewed for a week:
> > 
> > [build] Disable hwcaps on libgfortran
> >https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00336.html
> > 
> > It is required to unbreak bootstrap on Solaris/x86 and, though touching
> > both libgfortran and libitm, probably needs primarily a build
> > maintainer or global reviewer.
> 
> The Fortran part is OK, but I can’t approve the libitm part.

The libitm change is ok too.

Jakub

Re: [PATCH] PR 78534 Change character length from int to size_t

[Janus Weil]

Hi guys,

> there is already an ABI change. DTIO needed it.

maybe it would be a good idea to document this in places like:
* https://gcc.gnu.org/wiki/GFortran/News
* https://gcc.gnu.org/gcc-7/changes.html

On the first page there are "Compatibility notices" for several
earlier versions which mention stuff like this ...

Cheers,
Janus



> On Mon, 12 Dec 2016 11:20:06 +0100
> FX  wrote:
>
>> Hi Janne,
>>
>> This is an ABI change, so it is serious… it will require people to recompile
>> older code and libraries with the new compiler. Do we already plan to break
>> the ABI in this cycle, or is this the first ABI-breaking patch of the cycle?
>> And do we have real-life examples of character strings larger than 2 GB?
>>
>> > Also, as there are some places in the frontend were negative character
>> > lengths are used as special flag values, in the frontend the character
>> > length is handled as a signed variable of the same size as a size_t,
>> > although in the runtime library it really is size_t.
>>
>> First, I thought: we should really make it size_t, and have the negative
>> values be well-defined constants, e.g. (size_t) -1
>>
>> On the other hand, there is the problem of the case where the front-end has
>> different size_t than the target: think 32-bit on 64-bit i386 (front-end
>> size_t larger than target size_t), or cross-compiling for 64-bit on a 32-bit
>> machine (front-end size_t smaller than target size_t). So the charlen type
>> bounds need to be determined when the front-end runs, not when it is compiled
>> (i.e. it is not a fixed type).
>>
>> In iresolve.c, the "Why is this fixup needed?” comment is kinda scary.
>>
>>
>> > I haven't changed the character length variables for the co-array
>> > intrinsics, as this is something that may need to be synchronized with
>> > OpenCoarrays.
>>
>> Won’t that mean that coarray programs will fail due to ABI mismatch?
>>
>>
>> FX
>
> --
> Andre Vehreschild * Email: vehre ad gmx dot de

Re: [Ping] [C++ Patch] PR 78637 ("ICE on invalid C++ code (internal compiler error: in pop_namespace, at cp/name-lookup.c:3826)")

[Nathan Sidwell]

On 12/09/2016 11:33 AM, Paolo Carlini wrote:


this regression is caused by my fix for c++/60385, where I changed
push_namespace to early return (a bool) when pushdecl fails. In the
present testcase, a different push_namespace call in
cp_parser_namespace_definition, for nested namespace definitions,
fails, thus returns early, and that is inconsistent with the final
loop (pop_namespace ICEs):

  /* Finish the nested namespace definitions.  */
  while (nested_definition_count--)
pop_namespace ();

To fix this problem, I think we can simply increment
nested_definition_count only when push_namespace succeeds. Tested
x86_64-linux.


Ok.  (Looks sufficiently obvious to me.)

nathan

--
Nathan Sidwell

Re: [Ping~][1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space

[Jiong Wang]

Jiong Wang writes:

> On 16/11/16 14:02, Jakub Jelinek wrote:
>> On Wed, Nov 16, 2016 at 02:54:56PM +0100, Mark Wielaard wrote:
>>> On Wed, 2016-11-16 at 10:00 +, Jiong Wang wrote:
   The two operations DW_OP_AARCH64_paciasp and DW_OP_AARCH64_paciasp_deref 
 were
 designed as shortcut operations when LR is signed with A key and using
 function's CFA as salt.  This is the default behaviour of return address
 signing so is expected to be used for most of the time.  
 DW_OP_AARCH64_pauth
 is designed as a generic operation that allow describing pointer signing on
 any value using any salt and key in case we can't use the shortcut 
 operations
 we can use this.
>>>
>>> I admit to not fully understand the salting/keying involved. But given
>>> that the DW_OP space is really tiny, so we would like to not eat up too
>>> many of them for new opcodes. And given that introducing any new DW_OPs
>>> using for CFI unwinding will break any unwinder anyway causing us to
>>> update them all for this new feature. Have you thought about using a new
>>> CIE augmentation string character for describing that the return
>>> address/link register used by a function/frame is salted/keyed?
>>>
>>> This seems a good description of CIE records and augmentation
>>> characters:http://www.airs.com/blog/archives/460
>>>
>>> It obviously also involves updating all unwinders to understand the new
>>> augmentation character (and possible arguments). But it might be more
>>> generic and saves us from using up too many DW_OPs.
>>
>> From what I understood, the return address is not always scrambled, so
>> it doesn't apply to the whole function, just to most of it (except for
>> an insn in the prologue and some in the epilogue).  So I think one op is
>> needed.  But can't it be just a toggable flag whether the return address
>> is scrambled + some arguments to it?
>> Thus DW_OP_AARCH64_scramble .uleb128 0 would mean that the default
>> way of scrambling starts here (if not already active) or any kind of
>> scrambling ends here (if already active), and
>> DW_OP_AARCH64_scramble .uleb128 non-zero would be whatever encoding you need
>> to represent details of the less common variants with details what to do.
>> Then you'd just hook through some MD_* macro in the unwinder the
>> descrambling operation if the scrambling is active at the insns you unwind
>> on.
>>
>>   Jakub
>
> Hi Mark, Jakub:
>
>Thanks very much for the suggestions.
>
>I have done some experiments on your ideas and am thinking it's good to
>combine them together.  The use of DW_CFA instead of DW_OP can avoid 
> building
>all information from scratch at each unwind location, while we can indicate
>the signing key index through new AArch64 CIE augmentation 'B'. This new
>approach reduce the unwind table size overhead from ~25% to ~5% when return
>address signing enabled, it also largely simplified dwarf generation code 
> for
>return address signing.
>
>As one new DWARF call frame instruction is needed for AArch64, I want to 
> reuse
>DW_CFA_GNU_window_save to save the space.  It is in vendor extension space 
> and
>used for Sparc only, I think it make sense to reuse it for AArch64. On
>AArch64, DW_CFA_GNU_window_save toggle return address sign status which 
> kept
>in a new boolean type column in DWARF table,  so DW_CFA_GNU_window_save 
> takes
>no argument on AArch64, the same as on Sparc, this makes no difference to 
> those
>existed encoding, length calculation code.
>
>Meanwhile one new DWARF expression operation number is still needed for
>AArch64, it's useful for describing those complex pointer signing scenarios
>and it will be used to multiplex some further extensions on AArch64.
>
>OK on this proposal and to install this patch to gcc trunk?
>
> Hi GDB, Binutils maintainer:
>
>OK on this proposal and install this patch to binutils-gdb master?
>
> include/
> 2016-11-29   Richard Earnshaw  
>   Jiong Wang  
>
>  * dwarf2.def (DW_OP_AARCH64_operation): Reserve the number 0xea.

Ping~

Thanks.

-- 
Regards,
Jiong

Re: [PATCH] PR 78534 Change character length from int to size_t

[Janne Blomqvist]

On Mon, Dec 12, 2016 at 3:35 PM, Janus Weil  wrote:
> Hi guys,
>
>> there is already an ABI change. DTIO needed it.
>
> maybe it would be a good idea to document this in places like:
> * https://gcc.gnu.org/wiki/GFortran/News
> * https://gcc.gnu.org/gcc-7/changes.html
>
> On the first page there are "Compatibility notices" for several
> earlier versions which mention stuff like this ...

Yes, absolutely. I was planning to do it when/if the patch is accepted
and merged.

-- 
Janne Blomqvist

RE: [PATCH, testsuite] MIPS: Upgrade to R2 for -mnan=2008 and -mabs=2008.

[Toma Tabacu]

> > The -mnan=2008 and -mabs=2008 options are not supported on pre-R2
> targets.
> > This results in failures for tests which use these options, such as 
> > nan-2008.c,
> > fabs-2008.c etc.
> >
> > This patch makes the testsuite upgrade to R2 if -mnan=2008 and -mabs=2008
> are
> > used as test options.
> >
> > Tested with mips-mti-elf.
> >
> > Regards,
> > Toma Tabacu
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/mips/mips.exp (mips-dg-options): Upgrade to R2 for
> > -mnan=2008 and -mabs=2008.
> 
> OK, thanks.
> 
> Matthew

Committed as r243542.

Regards,
Toma

RE: [PATCH, testsuite] MIPS: Skip msa-builtins-err.c if there is no assembly output.

[Toma Tabacu]

> 
> It's a shame this is the only way to deal with this but I see aarch64 have
> to resort to the same thing for error checking tests.
> 

I have looked into this some more and I 've found that the solution I proposed
is incomplete.

The problem is that if no linker plugin is found, -fno-fat-lto-objects is not
passed on, so the test isn't skipped and it will fail because -flto doesn't do
assembly generation by default and the errors will not be triggered.

This can be fixed by adding -ffat-lto-objects as a test option for error tests,
as shown in the patch below.

The thing is, this already happens for scan-assembler & friends
behind-the-scenes, but not for dg-error, because the former are run through
force_conventional_output, while the latter is not.

A nicer solution would be to have a new directive which would do nothing except
for the force_conventional_output part, thus forcing assembly generation,
but this may be overkill.

Regards,
Toma

gcc/testsuite/ChangeLog:

* gcc.target/mips/msa-builtins-err.c (dg-options): Use
 -ffat-lto-objects to guarantee assembly generation.

diff --git a/gcc/testsuite/gcc.target/mips/msa-builtins-err.c 
b/gcc/testsuite/gcc.target/mips/msa-builtins-err.c
index 041b7f5..68244d6 100644
--- a/gcc/testsuite/gcc.target/mips/msa-builtins-err.c
+++ b/gcc/testsuite/gcc.target/mips/msa-builtins-err.c
@@ -1,6 +1,8 @@
 /* Test builtins for MIPS MSA ASE instructions */
 /* { dg-do compile } */
-/* { dg-options "-mfp64 -mhard-float -mmsa" } */
+/* { dg-options "-mfp64 -mhard-float -mmsa -ffat-lto-objects" } */
+/* Because this test only uses dg-error, we need to guarantee assembly
+   generation ourselves by using -ffat-lto-objects. */
 
 #include 

Re: [C++/78252] libiberty demangler crash with lambda (auto)

[Nathan Sidwell]

following discussion on the ABI list, here's an update to the generic 
lambda demangler patch.


The guts of the patch are the same as before -- note when we're printing 
a generic lambda's parms and interpret template type parm references 
differently.  however:

1) don't refer to this as a mangling bug, because it isn't
2) add a ':$n' suffix to each generic parm, as that's how g++ itself 
shows them in diagnostics and the like.


I'll mark 78621 as not a bug too.

ok?

nathan

--
Nathan Sidwell
2016-12-12  Nathan Sidwell  

	libiberty/
	PR c++/78252
	* cp-demangle.c (struct d_print_info): Add is_lambda_arg field.
	(d_print_init): Initialize it.
	(d_print_comp_inner) : Check
	is_lambda_arg for auto.
	: Skip smashing check when
	is_lambda_arg.
	: Increment is_lambda_arg around arg
	printing.
	* testsuite/demangle-expected: Add lambda auto mangling cases. 

	gcc/testsuite/
	PR c++/78252
	* g++.dg/cpp1y/lambda-mangle-1.C: New.

Index: libiberty/cp-demangle.c
===
--- libiberty/cp-demangle.c	(revision 243546)
+++ libiberty/cp-demangle.c	(working copy)
@@ -343,6 +343,9 @@ struct d_print_info
   struct d_print_mod *modifiers;
   /* Set to 1 if we saw a demangling error.  */
   int demangle_failure;
+  /* Non-zero if we're printing a lambda argument.  A template
+ parameter reference actually means 'auto'.  */
+  int is_lambda_arg;
   /* The current index into any template argument packs we are using
  for printing, or -1 to print the whole pack.  */
   int pack_index;
@@ -4126,6 +4129,7 @@ d_print_init (struct d_print_info *dpi,
   dpi->opaque = opaque;
 
   dpi->demangle_failure = 0;
+  dpi->is_lambda_arg = 0;
 
   dpi->component_stack = NULL;
 
@@ -4783,33 +4787,41 @@ d_print_comp_inner (struct d_print_info
   }
 
 case DEMANGLE_COMPONENT_TEMPLATE_PARAM:
-  {
-	struct d_print_template *hold_dpt;
-	struct demangle_component *a = d_lookup_template_argument (dpi, dc);
-
-	if (a && a->type == DEMANGLE_COMPONENT_TEMPLATE_ARGLIST)
-	  a = d_index_template_argument (a, dpi->pack_index);
+  if (dpi->is_lambda_arg)
+	{
+	  /* Show the template parm index, as that's how g++ displays
+	 these, and future proofs us against potential
+	 '[] (T *a, T *b) {...}'.  */
+	  d_append_buffer (dpi, "auto:", 5);
+	  d_append_num (dpi, dc->u.s_number.number + 1);
+	}
+  else
+	{
+	  struct d_print_template *hold_dpt;
+	  struct demangle_component *a = d_lookup_template_argument (dpi, dc);
 
-	if (a == NULL)
-	  {
-	d_print_error (dpi);
-	return;
-	  }
+	  if (a && a->type == DEMANGLE_COMPONENT_TEMPLATE_ARGLIST)
+	a = d_index_template_argument (a, dpi->pack_index);
 
-	/* While processing this parameter, we need to pop the list of
-	   templates.  This is because the template parameter may
-	   itself be a reference to a parameter of an outer
-	   template.  */
+	  if (a == NULL)
+	{
+	  d_print_error (dpi);
+	  return;
+	}
 
-	hold_dpt = dpi->templates;
-	dpi->templates = hold_dpt->next;
+	  /* While processing this parameter, we need to pop the list
+	 of templates.  This is because the template parameter may
+	 itself be a reference to a parameter of an outer
+	 template.  */
 
-	d_print_comp (dpi, options, a);
+	  hold_dpt = dpi->templates;
+	  dpi->templates = hold_dpt->next;
 
-	dpi->templates = hold_dpt;
+	  d_print_comp (dpi, options, a);
 
-	return;
-  }
+	  dpi->templates = hold_dpt;
+	}
+  return;
 
 case DEMANGLE_COMPONENT_CTOR:
   d_print_comp (dpi, options, dc->u.s_ctor.name);
@@ -4946,7 +4958,8 @@ d_print_comp_inner (struct d_print_info
   {
 	/* Handle reference smashing: & + && = &.  */
 	const struct demangle_component *sub = d_left (dc);
-	if (sub->type == DEMANGLE_COMPONENT_TEMPLATE_PARAM)
+	if (!dpi->is_lambda_arg
+	&& sub->type == DEMANGLE_COMPONENT_TEMPLATE_PARAM)
 	  {
 	struct d_saved_scope *scope = d_get_saved_scope (dpi, sub);
 	struct demangle_component *a;
@@ -5616,7 +5629,11 @@ d_print_comp_inner (struct d_print_info
 
 case DEMANGLE_COMPONENT_LAMBDA:
   d_append_string (dpi, "{lambda(");
+  /* Generic lambda auto parms are mangled as the template type
+	 parm they are.  */
+  dpi->is_lambda_arg++;
   d_print_comp (dpi, options, dc->u.s_unary_num.sub);
+  dpi->is_lambda_arg--;
   d_append_string (dpi, ")#");
   d_append_num (dpi, dc->u.s_unary_num.num + 1);
   d_append_char (dpi, '}');
Index: libiberty/testsuite/demangle-expected
===
--- libiberty/testsuite/demangle-expected	(revision 243546)
+++ libiberty/testsuite/demangle-expected	(working copy)
@@ -4634,3 +4634,32 @@ _Z12binary_rightIJLi1ELi2ELi3EEEv1AIXfRp
 # ?: expression with missing third component could crash.
 AquT_quT_4mxautouT_4mxxx
 AquT_quT_4mxautouT_4mxxx
+
+# pr c++/78252 generic lambda mangling uses template parms, and leads
+# to unbounded recursion if not dealt with pr

[PATCH][libstdc++][testsuite] XFAIL tests relying on long double-to-string conversions on broken newlib

[Kyrill Tkachov]

Hi all,

I've been investigating the execution failures of:
21_strings/basic_string/numeric_conversions/char/stod.cc
21_strings/basic_string/numeric_conversions/wchar_t/stod.cc
21_strings/basic_string/numeric_conversions/wchar_t/stold.cc
27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc

on aarch64-none-elf, a newlib target.
The reason they are failing is because they are converting a long double to a 
string using to_string
before trying to convert it back into a number.
to_string ends up calling a vsnprintf from the C library (newlib in this case) 
with the %Lf format
to convert from long double.
Unfortunately the %Lf format is broken in newlib for platforms where long 
double is not the same as double.
It gives bogus results because newlib doesn't implement the long double variant 
of frexp (frexpl) which is needed
to implement printf properly. So it ends up using frexp even on long doubles. 
This gives wrong results which causes
these tests to fail.

So this patch marks them as XFAIL and adds an effective target check for broken 
newlib versions.

With this patch these tests appear as XFAIL on aarch64-none-elf.

Ok for trunk?

Thanks,
Kyrill

2016-12-12  Kyrylo Tkachov  

* lib/target-supports.exp
(check_effective_target_newlib_broken_long_double_io): New check.
(check_effective_target_frexpl): Likewise.

2016-12-12  Kyrylo Tkachov  

* testsuite/21_strings/basic_string/numeric_conversions/char/stod.cc:
XFAIL run if newlib_broken_long_double_io.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stod.cc:
Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stold.cc:
Likewise.
* testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:
Likewise.
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index bce181fd87b32d51edb9b62fef81ad4314f0d222..d6229392b1414a26fe000dd61cc75ec112453b5f 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -6765,6 +6765,17 @@ proc check_effective_target_newlib {} {
 }]
 }
 
+# Some newlib versions don't provide a frexpl and instead depend
+# on frexp to implement long double conversions in their printf-like
+# functions.  This leads to broken results.  Detect such versions here.
+
+proc check_effective_target_newlib_broken_long_double_io {} {
+  if { [is-effective-target newlib] && ![is-effective-target frexpl] } {
+	return 1
+  }
+  return 0
+}
+
 # Return true if this is NOT a Bionic target.
 
 proc check_effective_target_non_bionic {} {
@@ -7380,6 +7391,21 @@ proc check_effective_target_pow10 { } {
 } "-lm" ]
 }
 
+# Return 1 if frexpl function exists.
+
+proc check_effective_target_frexpl { } {
+return [check_runtime frexpl {
+	#include 
+	int main () {
+	long double x;
+	int y;
+	x = frexpl (5.0, &y);
+	return 0;
+	}
+} "-lm" ]
+}
+
+
 # Return 1 if issignaling function exists.
 proc check_effective_target_issignaling {} {
 return [check_runtime issignaling {
diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stod.cc b/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stod.cc
index 7e7c1347eab51abef73865073dbb4129db71af48..088641130075add8346948f286cfc63de6637721 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stod.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stod.cc
@@ -1,5 +1,6 @@
 // { dg-do run { target c++11 } }
 // { dg-require-string-conversions "" }
+// { dg-xfail-run-if "broken long double IO" { newlib_broken_long_double_io  }  "*" "" }
 
 // 2008-06-15  Paolo Carlini  
 
diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stold.cc b/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stold.cc
index 15a4dcaddb46dc62df9f7c51c3c07c73823fccff..df39a50b9c8964f70db17a07caaf0f8a48eddbcf 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stold.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stold.cc
@@ -1,5 +1,6 @@
 // { dg-do run { target c++11 } }
 // { dg-require-string-conversions "" }
+// { dg-xfail-run-if "broken long double IO" { newlib_broken_long_double_io  }  "*" "" }
 
 // 2008-06-15  Paolo Carlini  
 
diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stod.cc b/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stod.cc
index 81735dd186617c0fe96c2334e5fab2cef6a07d4e..259dc65024833af576b5cba44942e996c41c1b0d 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stod.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stod.cc
@@ -1,5 +1,7 @@
 // { dg-do run { target c++11 } }
 // { dg-require-string-conversions "" }
+// { dg-xfail-run-if "broken long double IO" { newlib_broken_long_double_io

[PATCH] Backport all Filesystem library fixes from trunk

[Jonathan Wakely]

This syncs the std::experimental::filesystem code on gcc-6-branch to
match what's on trunk, except that the C++17 std::string_view type
doesn't exist on the branch, so the filesystem::path type only
supports experimental::string_view.

I'm doing it as one big patch, rather than backporting 26 individual
patches.

This implements the following LWG DRs:
2681 2682 2683 2706 2707 2712 2720 2723

Backport from mainline
PR libstdc++/70975
PR libstdc++/71337
PR libstdc++/78111
* include/experimental/bits/fs_dir.h (recursive_directory_iterator):
Overload pop (LWG 2706).
* include/experimental/bits/fs_fwd.h (perms::resolve_symlinks):
Replace with symlink_nofollow (LWG 2720).
* include/experimental/bits/fs_ops.h
(exists(const path&, error_code&)): Clear error if status is known
(LWG 2725).
* include/experimental/bits/fs_path.h (__is_path_src)
(_S_range_begin, _S_range_end): Overload to treat string_view as a
Source object.
(path::operator+=, path::compare): Overload for basic_string_view.
(path::path(string_type&&))
(path::operator=(string&&), path::assign(string_type&&)): Define
construction and assignment from string_type rvalues (LWG 2707).
(path::_S_convert<_Iter>(_Iter, _Iter)): Remove cv-qualifiers from
iterator's value_type.
(path::_S_convert<_Iter>(_Iter __first, __null_terminated)): Likewise.
Do not use operation not supported by input iterators.
(path::__is_path_iter_src): Add partial specialization for const
encoded character types.
* src/filesystem/dir.cc (open_dir): Return same value for errors
whether ignored or not.
(_Dir::advance(error_code*, directory_options)): Return false on
error.
(directory_iterator(const path&, directory_options, error_code*)):
Create end iterator on error (LWG 2723).
(recursive_directory_iterator(const path&, directory_options,
error_code*)): Likewise.
(recursive_directory_iterator::increment): Reset state on error.
(recursive_directory_iterator::pop): Define new overload.
* src/filesystem/ops.cc (canonical): Set error for non-existent path.
(file_time): Take error_code parameter and check for overflow.
(close_fd): Remove.
(do_copy_file): Report an error if source or destination is not a
regular file (LWG 2712). Pass error_code in file_time calls.  Just
use close(3) instead of close_fd, to prevent retrying on error.
Check if _GLIBCXX_USE_FCHMODAT is defined.
[_GLIBCXX_USE_SENDFILE]: Fallback to read/write operations in case
sendfile fails with ENOSYS or EINVAL. Pass non-null pointer to
sendfile for offset argument.
(copy): Update comment to refer to LWG 2681. Implement 2682 and 2683
resolutions.
(equivalent): Fix error handling and result when only one file exists.
(is_empty): Fix error handling.
(last_write_time(const path&, error_code&)): Pass error_code in
file_time calls.
(last_write_time(const path&, file_time_type, error_code&)): Handle
negative times correctly.
(permissions(const path&, perms, error_code&)): Handle
symlink_nofollow.
(read_symlink): Add missing ec.clear().
(status(const path&, error_code&)): Handle EOVERFLOW.
(temp_directory_path): Pass error_code argument to other filesystem
operations.
* testsuite/experimental/filesystem/iterators/directory_iterator.cc:
Update expected behaviour on error.
* testsuite/experimental/filesystem/iterators/pop.cc: New.
* testsuite/experimental/filesystem/iterators/
recursive_directory_iterator.cc: Update expected behaviour on error.
* testsuite/experimental/filesystem/operations/copy.cc: Update
expected behaviour for copying directories with create_symlinks.
Verify that error_code arguments are cleared if there's no error.
Remove files created by tests. Test copying directories.
* testsuite/experimental/filesystem/operations/copy_file.cc: Remove
files created by tests.
* testsuite/experimental/filesystem/operations/create_symlink.cc: New.
* testsuite/experimental/filesystem/operations/equivalent.cc: New.
* testsuite/experimental/filesystem/operations/exists.cc: Test
overload taking an error_code.
* testsuite/experimental/filesystem/operations/is_empty.cc: New.
* testsuite/experimental/filesystem/operations/last_write_time.cc:
New.
* testsuite/experimental/filesystem/operations/permissions.cc: Test
overload taking error_code. Test symlink_nofollow on non-symlinks.
* testsuite/experimental/filesystem/operations/read_symlink.cc: New.
* testsuite/experimental/filesystem/operations/remove_all.cc: New

[Ping][PATCH][ARM] Updating testcase unsigned-extend-2.c

[Andre Vieira (lists)]

On 21/06/16 15:16, Andre Vieira (lists) wrote:
> Hello,
> 
> After some changes to GCC this test no longer tests the desired code
> generation behavior. The generated assembly is better than it used to
> be, but it has become too smart. I add an extra parameter to make sure
> GCC can't optimize away the loop.
> 
> Tested for arm-none-eabi-gcc with a Cortex-M3 target.
> 
> Is this OK?
> 
> Cheers,
> Andre
> 
> gcc/ChangeLog
> 2016-06-21  Andre Vieira  
> 
> * gcc.target/arm/unsigned-extend-2.c: Update testcase.
> 

Ping.

Re: cprop fix for PR78626

[Bernd Schmidt]

On 12/10/2016 08:58 PM, Segher Boessenkool wrote:

On Thu, Dec 08, 2016 at 01:21:04PM +0100, Bernd Schmidt wrote:

This is another case where an optimization turns a trap_if
unconditional. We have to defer changing the CFG, since the rest of
cprop seems to blow up when we modify things while scanning.



The problem for PR78727 is that we also need to do this for insns that
already are the last insn in the block:


+  while (!uncond_traps.is_empty ())
+   {
+ rtx_insn *insn = uncond_traps.pop ();
+ basic_block to_split = BLOCK_FOR_INSN (insn);
+ remove_edge (split_block (to_split, insn));
+ emit_barrier_after_bb (to_split);
+   }


We need that barrier, and we also need the successor edges removed
(which split_block+remove_edge does).

(PR78727 works fine with just that BB_END test deleted).


Ah, ok. In that case I'll probably also add a test to make sure this is 
only done for insns that weren't an unconditional trap before. Retesting...



Bernd

Re: [PATCH] Remove stray character at end of dg-do directive

[Jonathan Wakely]

On 12/12/16 12:44 +, Jonathan Wakely wrote:

* testsuite/experimental/filesystem/operations/temp_directory_path.cc:
Remove stray character at end of dg-do directive.


And another one with the same problem.

Tested x86_64-linux, committed to trunk.


commit c3aaa2055071251d29fd233c3dc83fc6516c4e2d
Author: Jonathan Wakely 
Date:   Mon Dec 12 14:31:48 2016 +

Remove stray character at end of dg-do directive

	* testsuite/experimental/filesystem/operations/is_empty.cc:
	Remove stray character at end of dg-do directive.

diff --git a/libstdc++-v3/testsuite/experimental/filesystem/operations/is_empty.cc b/libstdc++-v3/testsuite/experimental/filesystem/operations/is_empty.cc
index d35967a..5a66637 100644
--- a/libstdc++-v3/testsuite/experimental/filesystem/operations/is_empty.cc
+++ b/libstdc++-v3/testsuite/experimental/filesystem/operations/is_empty.cc
@@ -16,7 +16,7 @@
 // .
 
 // { dg-options "-lstdc++fs" }
-// { dg-do run { target c++11 } }E
+// { dg-do run { target c++11 } }
 // { dg-require-filesystem-ts "" }
 
 #include 

[PATCH] PR target/78748: S/390: Fix ICE with ANDC splitter.

[Dominik Vogt]

The attached patch fixes PR/78748.  Bootstrapped and regression
tested on s390 and s390x.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78748

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany
gcc/ChangeLog-pr78748

PR target/78748
* config/s390/s390.md ("*andc_split_"): Allow memory destination
only if it coincides with operand 2.
gcc/testsuite/ChangeLog-pr78748

PR target/78748
* gcc.c-torture/compile/pr78748.c: New test.
>From b48da97e3b2f5b0b49543ed35d8c667a607067cf Mon Sep 17 00:00:00 2001
From: Dominik Vogt 
Date: Mon, 12 Dec 2016 10:35:21 +0100
Subject: [PATCH] PR target/78748: S/390: Fix ICE with ANDC splitter.

---
 gcc/config/s390/s390.md   |  6 +-
 gcc/testsuite/gcc.c-torture/compile/pr78748.c | 16 
 2 files changed, 21 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr78748.c

diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index 4f2effd..9d8e6b6 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -7420,7 +7420,11 @@
(and:GPR (not:GPR (match_operand:GPR 1 "nonimmediate_operand" ""))
 (match_operand:GPR 2 "general_operand" "")))
(clobber (reg:CC CC_REGNUM))]
-  "! reload_completed && s390_logical_operator_ok_p (operands)"
+  "! reload_completed
+   && (GET_CODE (operands[0]) != MEM
+  /* Ensure that s390_logical_operator_ok_p will succeed even
+on the split xor if (b & a) is stored into a pseudo.  */
+   || rtx_equal_p (operands[0], operands[2]))"
   "#"
   "&& 1"
   [
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr78748.c 
b/gcc/testsuite/gcc.c-torture/compile/pr78748.c
new file mode 100644
index 000..d24a334
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr78748.c
@@ -0,0 +1,16 @@
+/* PR target/78748 */
+/* { dg-options "-march=zEC12" { target { s390*-*-* } } } */
+
+void
+foo (int *p, int *q)
+{
+  *q = *p & ~*q;
+}
+
+#if 0 /*!!!*/
+void
+bar (int *p, int *q)
+{
+  *q = ~*p & *q;
+}
+#endif
-- 
2.3.0

Re: [PATCH] PR target/78748: S/390: Fix ICE with ANDC splitter.

[Jakub Jelinek]

On Mon, Dec 12, 2016 at 03:36:01PM +0100, Dominik Vogt wrote:
> diff --git a/gcc/testsuite/gcc.c-torture/compile/pr78748.c 
> b/gcc/testsuite/gcc.c-torture/compile/pr78748.c
> new file mode 100644
> index 000..d24a334
> --- /dev/null
> +++ b/gcc/testsuite/gcc.c-torture/compile/pr78748.c
> @@ -0,0 +1,16 @@
> +/* PR target/78748 */
> +/* { dg-options "-march=zEC12" { target { s390*-*-* } } } */
> +
> +void
> +foo (int *p, int *q)
> +{
> +  *q = *p & ~*q;
> +}
> +
> +#if 0 /*!!!*/
> +void
> +bar (int *p, int *q)
> +{
> +  *q = ~*p & *q;
> +}
> +#endif

Why the #if 0 /*!!!*/?  The test just verifies the compiler doesn't ICE
and stuff assembles, I'd hope bar also compiles and assembles.

Jakub

Re: Fix PR78725 (v2)

[Michael Matz]

Hi,

On Fri, 9 Dec 2016, Richard Biener wrote:

> On December 9, 2016 4:29:04 PM GMT+01:00, Michael Matz  wrote:
> >Hi,
> >
> >if the induction variable on which we want to partition the loop 
> >iterations for loop splitting might overflow we would either need
> >runtime 
> >tests checking if an overflow in fact does happen, or we can simply not
> >
> >split loops on such ones.  I chose the latter.
> >
> >Fixes the testcase, and regstrapped without regressions on x86-64-linux
> >
> >(all languages+Ada).  Okay for trunk?
> 
> OK

Actually there came another report in the same bug, which has a different 
but related cause.  In the testcase the potential split-point is

  if (outer >= inner)

where the final value of 'inner' is known constant in the _outer_ loop.  
But of course we have to consider the actual place of the use: the 
comparison statement which is inside the inner loop, not merely in the 
outer loop.  Fixed with the amended patch.

Regstrapping on x86-64-linux in progress (all langs+ada), but I know that 
it fixes both testcases and doesn't regress in gcc.dg.  Okay for trunk if 
regstrapping succeeds?


Ciao,
Michael.
PR tree-optimization/78725
* tree-ssa-loop-split.c (split_at_bb_p): Check for overflow and
at correct use point.

testsuite/
PR tree-optimization/78725
* gcc.dg/pr78725.c: New test.
* gcc.dg/pr78725-2.c: New test.

diff --git a/gcc/testsuite/gcc.dg/pr78725-2.c b/gcc/testsuite/gcc.dg/pr78725-2.c
new file mode 100644
index 000..9de489e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr78725-2.c
@@ -0,0 +1,19 @@
+/* { dg-do run } */
+/* { dg-options "-O3 -fsplit-loops" } */
+
+int a, b, c;
+
+int main ()
+{
+  int d;
+  for (; c < 1; c++)
+for (d = 0; d < 3; d++)
+  for (b = 0; b < 1; b++)
+   if (c >= d)
+ a = 1;
+
+  if (a != 1)
+__builtin_abort ();
+
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/pr78725.c b/gcc/testsuite/gcc.dg/pr78725.c
new file mode 100644
index 000..ed95790
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr78725.c
@@ -0,0 +1,19 @@
+/* { dg-do run } */
+/* { dg-options "-O3 -fsplit-loops" } */
+
+int fn1 (int b, int c)
+{
+return c < 0 || c > 31 ? 0 : b >> c;
+}
+
+unsigned char d = 255; 
+int e, f;
+
+int main ()
+{
+  for (; f < 2; f++)
+e = fn1 (1, d++);
+  if (e != 1)
+__builtin_abort ();
+  return 0; 
+}
diff --git a/gcc/tree-ssa-loop-split.c b/gcc/tree-ssa-loop-split.c
index dac68e6..84c0627 100644
--- a/gcc/tree-ssa-loop-split.c
+++ b/gcc/tree-ssa-loop-split.c
@@ -102,10 +102,11 @@ split_at_bb_p (struct loop *loop, basic_block bb, tree 
*border, affine_iv *iv)
 
   tree op0 = gimple_cond_lhs (stmt);
   tree op1 = gimple_cond_rhs (stmt);
+  struct loop *useloop = loop_containing_stmt (stmt);
 
-  if (!simple_iv (loop, loop, op0, iv, false))
+  if (!simple_iv (loop, useloop, op0, iv, false))
 return NULL_TREE;
-  if (!simple_iv (loop, loop, op1, &iv2, false))
+  if (!simple_iv (loop, useloop, op1, &iv2, false))
 return NULL_TREE;
 
   /* Make it so that the first argument of the condition is
@@ -122,6 +123,8 @@ split_at_bb_p (struct loop *loop, basic_block bb, tree 
*border, affine_iv *iv)
 return NULL_TREE;
   if (!integer_zerop (iv2.step))
 return NULL_TREE;
+  if (!iv->no_overflow)
+return NULL_TREE;
 
   if (dump_file && (dump_flags & TDF_DETAILS))
 {

Re: [PATCH][libstdc++][testsuite] XFAIL tests relying on long double-to-string conversions on broken newlib

[Jonathan Wakely]

On 12/12/16 13:55 +, Kyrill Tkachov wrote:

Hi all,

I've been investigating the execution failures of:
21_strings/basic_string/numeric_conversions/char/stod.cc
21_strings/basic_string/numeric_conversions/wchar_t/stod.cc
21_strings/basic_string/numeric_conversions/wchar_t/stold.cc
27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc

on aarch64-none-elf, a newlib target.
The reason they are failing is because they are converting a long double to a 
string using to_string
before trying to convert it back into a number.
to_string ends up calling a vsnprintf from the C library (newlib in this case) 
with the %Lf format
to convert from long double.
Unfortunately the %Lf format is broken in newlib for platforms where long 
double is not the same as double.
It gives bogus results because newlib doesn't implement the long double variant 
of frexp (frexpl) which is needed
to implement printf properly. So it ends up using frexp even on long doubles. 
This gives wrong results which causes
these tests to fail.

So this patch marks them as XFAIL and adds an effective target check for broken 
newlib versions.

With this patch these tests appear as XFAIL on aarch64-none-elf.

Ok for trunk?


Yes OK, thanks.

Re: Help debugging middle-end crash (SSA inlining)

[Janne Blomqvist]

On Sun, Dec 4, 2016 at 11:38 PM, Janne Blomqvist
 wrote:
> Hi,
>
> I'm working on a patch to change the type that GFortran uses for
> string lengths from a C int to a C size_t. I'm at a point where it
> does regtest successfully, with the exception of
> gfortran.dg/char_result_8.f90 with -O1 where it ICE's. Unfortunately
> I'm a bit stuck here, and haven't been able to figure out what causes
> the error.
>
> The latest version of the patch is attached to PR 78534.
>
> It does work with -O0, -O2, -O3, -Og, -Ofast as well as "-O1
> -fno-inline-functions-called-once". Which suggests that the problem is
> in the inliner (why it doesn't trigger with higher optimization level,
> I don't know).
>
> The backtrace of the crash is
>
> char_result_8.f90:14:0:
>
>call indirect (100)
>
> internal compiler error: Segmentation fault
> 0xcda61e crash_signal
> ../../trunk-git/gcc/toplev.c:333
> 0xfa99e4 make_ssa_name_fn(function*, tree_node*, gimple*, unsigned int)
> ../../trunk-git/gcc/tree-ssanames.c:265
> 0xd7e26a make_ssa_name
> ../../trunk-git/gcc/tree-ssanames.h:113
> 0xd7e26a remap_ssa_name
> ../../trunk-git/gcc/tree-inline.c:238
> 0xd84ee2 copy_tree_body_r(tree_node**, int*, void*)
> ../../trunk-git/gcc/tree-inline.c:1082
> 0x108c7a4 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*,
> void*), void*, hash_set
>>*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**,
> int*, void*), void*, hash_set default_hash_traits >*))
> ../../trunk-git/gcc/tree.c:11795
> 0x108da12 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*,
> void*), void*, hash_set
>>*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**,
> int*, void*), void*, hash_set default_hash_traits >*))
> ../../trunk-git/gcc/tree.c:12112
> 0xd7c41a remap_type_1
> ../../trunk-git/gcc/tree-inline.c:493
> 0xd7d2cc remap_type(tree_node*, copy_body_data*)
> ../../trunk-git/gcc/tree-inline.c:593
> 0xd7cbc5 remap_type_1
> ../../trunk-git/gcc/tree-inline.c:523
> 0xd7d2cc remap_type(tree_node*, copy_body_data*)
> ../../trunk-git/gcc/tree-inline.c:593
> 0xd7b721 remap_type_1
> ../../trunk-git/gcc/tree-inline.c:418
> 0xd7d2cc remap_type(tree_node*, copy_body_data*)
> ../../trunk-git/gcc/tree-inline.c:593
> 0xd7b1c9 remap_decl(tree_node*, copy_body_data*)
> ../../trunk-git/gcc/tree-inline.c:370
> 0xd7d849 add_local_variables
> ../../trunk-git/gcc/tree-inline.c:4321
> 0xd8973a expand_call_inline
> ../../trunk-git/gcc/tree-inline.c:4733
> 0xd8a4b8 gimple_expand_calls_inline
> ../../trunk-git/gcc/tree-inline.c:4896
> 0xd8a6cf optimize_inline_calls(tree_node*)
> ../../trunk-git/gcc/tree-inline.c:5036
> 0x164c339 inline_transform(cgraph_node*)
> ../../trunk-git/gcc/ipa-inline-transform.c:655
> 0xbe121c execute_one_ipa_transform_pass
> ../../trunk-git/gcc/passes.c:2206
>
>
> Where it crashes is the assertion "VAR_P (var)", because var is a null
> pointer. Running this via gdb I have found that in this case "var" is
> the type node for one of the variables that it apparently is copying
> from the callee into the caller during the inlining.
>
> So I guess I'm asking how can it happen that the type node of a
> variable disappears?
>
> I have compared the -fdump-tree original dumps of trunk and
> trunk+patch, and they look perfectly Ok; except for character length
> types being different and a few typecasts in some appropriate places,
> they are identical.
>
> Can anybody offer some clues?

Dear all,

I figured out that this problem wasn't per se caused by my patch, but
it existed on trunk previously and was just triggered by my patch. I
was able to reproduce it on a pristine trunk and filed it as PR 78757.
Subsequently Martin Liška was able to point to r235817
(http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=235817 ) as the
culprit.

Thanks to Martin and all others who spent time on this so far!

-- 
Janne Blomqvist

Re: [Patch, Fortran] PR 78392: ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979

[Janus Weil]

Hi all,

I hate to ping this patch once more, but somehow we need to come to a
conclusion here.

The issue boils down to the fact that there is a piece of code in the
gfortran code which claims that specification functions are
'constant', but I doubt that this is true. To my understanding the
concept of specification expressions and specification functions (see
section 7.1.6 in the F03 standard) was introduced essentially to refer
to side-effect-free expressions that can be used e.g. in a
type-specification context (array bounds, char-length parameters etc).

However I think 'specification functions' do not necessarily need to
be 'constants', in the sense that subsequent invocations give always
the same (constant) result and their value can be determined at
compile time.

My patch is at: https://gcc.gnu.org/ml/fortran/2016-11/msg00188.html
Further discussion at: https://gcc.gnu.org/ml/fortran/2016-11/msg00243.html

Any comments, please!?!

Cheers,
Janus



2016-12-03 8:05 GMT+01:00 Janus Weil :
> double-ping!
>
>
> 2016-11-26 10:45 GMT+01:00 Janus Weil :
>> ping!
>>
>>
>> 2016-11-19 10:12 GMT+01:00 Janus Weil :
>>> Hi all,
>>>
 I previously assumed that the test case for this PR would be legal,
 but by now I think that's wrong. The test case should be rejected, and
 we already have checking mechanisms for this (see
 resolve_fl_variable), but apparently they are not working.

 My current suspicion is that 'gfc_is_constant_expr' has a bug, because
 it claims the call to the function 'get_i' to be a constant
 expression. This is not true, because get_i() can not be reduced to a
 compile-time constant.
>>>
>>> some more reading in the standard confirms this suspicion: In
>>> gfc_is_constant_expr there is a piece of code which claims that
>>> specification functions are constant. That is certainly not true, and
>>> so what I'm doing in the attached fix is to remove that code and add
>>> some references to the standard to make things clearer.
>>>
>>> The code that I'm removing has last been touched in this commit by
>>> Jerry six years ago:
>>>
>>> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=166520
>>>
>>> However, this did not introduce the bug in the first place (not sure
>>> when that happened).
>>>
>>> In any case the new patch in the attachment regtests cleanly and
>>> correctly rejects the original test case as well as one of the cases
>>> mentioned by Dominique. Ok for trunk?
>>>
>>> Cheers,
>>> Janus
>>>
>>>
>>>
>>> 2016-11-19  Janus Weil  
>>>
>>> PR fortran/78392
>>> * expr.c (gfc_is_constant_expr): Specification functions are not
>>> compile-time constants. Update documentation (add reference to F08
>>> standard), add a FIXME.
>>> (external_spec_function): Add reference to F08 standard.
>>> * resolve.c (resolve_fl_variable): Ditto.
>>>
>>> 2016-11-19  Janus Weil  
>>>
>>> PR fortran/78392
>>> * gfortran.dg/constant_shape.f90: New test case.

Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers in GIMPLE.

[Jeff Law]

On 12/12/2016 02:19 AM, Tamar Christina wrote:

Ping


From: Tamar Christina
Sent: Friday, December 2, 2016 4:20:42 PM
To: Joseph Myers
Cc: GCC Patches; Wilco Dijkstra; rguent...@suse.de; l...@redhat.com; Michael 
Meissner; nd
Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers 
in GIMPLE.

Ping?

Is there anything else I need to do for the patch or is it OK for trunk?
Just a note, it is in my queue of things to look at.   GIven it was 
posted well before stage1 close I think it deserves the opportunity to 
move forward (even if we need another iteration) even though we're well 
into stage3.


Jeff

[Patch][ARM,AArch64] more poly64 intrinsics and tests

[Christophe Lyon]

Hi,

After the recent update from Tamar, I noticed a few discrepancies
between ARM and AArch64 regarding a few poly64 intrinsics.

This patch:
- adds vtst_p64 and vtstq_p64 to AArch64's arm_neon.h
- adds vgetq_lane_p64, vset_lane_p64 and vsetq_lane_p64 to ARM's arm_neon.h
( vget_lane_p64 was already there)
- adds the corresponding tests, and moves the vget_lane_p64 ones out
of the #ifdef __aarch64__ zone.

Cross-tested on arm* and aarch64* targets.

OK?

Christophe
gcc/ChangeLog:

2016-12-12  Christophe Lyon  

* config/aarch64/arm_neon.h (vtst_p64): New.
(vtstq_p64): New.
* config/arm/arm_neon.h (vgetq_lane_p64): New.
(vset_lane_p64): New.
(vsetq_lane_p64): New.

gcc/testsuite/ChangeLog:

2016-12-12  Christophe Lyon  

* gcc.target/aarch64/advsimd-intrinsics/p64_p128.c
(vget_lane_expected, vset_lane_expected, vtst_expected_poly64x1):
New.
(vmov_n_expected0, vmov_n_expected1, vmov_n_expected2)
(expected_vld_st2_0, expected_vld_st2_1, expected_vld_st3_0)
(expected_vld_st3_1, expected_vld_st3_2, expected_vld_st4_0)
(expected_vld_st4_1, expected_vld_st4_2, expected_vld_st4_3)
(vtst_expected_poly64x2): Move to aarch64-only section.
(vget_lane_p64, vgetq_lane_p64, vset_lane_p64, vsetq_lane_p64)
(vtst_p64, vtstq_p64): New tests.

diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
index b846644..74d163e 100644
--- a/gcc/config/aarch64/arm_neon.h
+++ b/gcc/config/aarch64/arm_neon.h
@@ -10882,6 +10882,13 @@ vtst_p16 (poly16x4_t a, poly16x4_t b)
   return result;
 }
 
+__extension__ extern __inline uint64x1_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vtst_p64 (poly64x1_t a, poly64x1_t b)
+{
+  return (uint64x1_t) ((a & b) != __AARCH64_INT64_C (0));
+}
+
 __extension__ extern __inline uint8x16_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 vtstq_p8 (poly8x16_t a, poly8x16_t b)
@@ -10906,6 +10913,18 @@ vtstq_p16 (poly16x8_t a, poly16x8_t b)
   return result;
 }
 
+__extension__ extern __inline uint64x2_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vtstq_p64 (poly64x2_t a, poly64x2_t b)
+{
+  uint64x2_t result;
+  __asm__ ("cmtst %0.2d, %1.2d, %2.2d"
+   : "=w"(result)
+   : "w"(a), "w"(b)
+   : /* No clobbers */);
+  return result;
+}
+
 /* End of temporary inline asm implementations.  */
 
 /* Start of temporary inline asm for vldn, vstn and friends.  */
diff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h
index ab29da7..d199b41 100644
--- a/gcc/config/arm/arm_neon.h
+++ b/gcc/config/arm/arm_neon.h
@@ -5497,6 +5497,15 @@ vgetq_lane_s64 (int64x2_t __a, const int __b)
   return (int64_t)__builtin_neon_vget_lanev2di (__a, __b);
 }
 
+#pragma GCC push_options
+#pragma GCC target ("fpu=crypto-neon-fp-armv8")
+__extension__ static __inline poly64_t __attribute__ ((__always_inline__))
+vgetq_lane_p64 (poly64x2_t __a, const int __b)
+{
+  return (poly64_t)__builtin_neon_vget_lanev2di ((int64x2_t) __a, __b);
+}
+
+#pragma GCC pop_options
 __extension__ static __inline uint64_t __attribute__ ((__always_inline__))
 vgetq_lane_u64 (uint64x2_t __a, const int __b)
 {
@@ -5581,6 +5590,15 @@ vset_lane_u64 (uint64_t __a, uint64x1_t __b, const int 
__c)
   return (uint64x1_t)__builtin_neon_vset_lanedi ((__builtin_neon_di) __a, 
(int64x1_t) __b, __c);
 }
 
+#pragma GCC push_options
+#pragma GCC target ("fpu=crypto-neon-fp-armv8")
+__extension__ static __inline poly64x1_t __attribute__ ((__always_inline__))
+vset_lane_p64 (poly64_t __a, poly64x1_t __b, const int __c)
+{
+  return (poly64x1_t)__builtin_neon_vset_lanedi ((__builtin_neon_di) __a, 
(int64x1_t) __b, __c);
+}
+
+#pragma GCC pop_options
 __extension__ static __inline int8x16_t __attribute__ ((__always_inline__))
 vsetq_lane_s8 (int8_t __a, int8x16_t __b, const int __c)
 {
@@ -5661,6 +5679,12 @@ vsetq_lane_u64 (uint64_t __a, uint64x2_t __b, const int 
__c)
 
 #pragma GCC push_options
 #pragma GCC target ("fpu=crypto-neon-fp-armv8")
+__extension__ static __inline poly64x2_t __attribute__ ((__always_inline__))
+vsetq_lane_p64 (poly64_t __a, poly64x2_t __b, const int __c)
+{
+  return (poly64x2_t)__builtin_neon_vset_lanev2di ((__builtin_neon_di) __a, 
(int64x2_t) __b, __c);
+}
+
 __extension__ static __inline poly64x1_t __attribute__ ((__always_inline__))
 vcreate_p64 (uint64_t __a)
 {
diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/p64_p128.c 
b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/p64_p128.c
index 8907b38..ba8fbeb 100644
--- a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/p64_p128.c
+++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/p64_p128.c
@@ -39,17 +39,6 @@ VECT_VAR_DECL(vdup_n_expected2,poly,64,1) [] = { 
0xfff2 };
 VECT_VAR_DECL(vdup_n_expected2,poly,64,2) [] = { 0xfff2,
 0xfff2 };
 
-/* E

Re: Fix PR78725 (v2)

[Richard Biener]

On December 12, 2016 4:29:24 PM GMT+01:00, Michael Matz  wrote:
>Hi,
>
>On Fri, 9 Dec 2016, Richard Biener wrote:
>
>> On December 9, 2016 4:29:04 PM GMT+01:00, Michael Matz 
>wrote:
>> >Hi,
>> >
>> >if the induction variable on which we want to partition the loop 
>> >iterations for loop splitting might overflow we would either need
>> >runtime 
>> >tests checking if an overflow in fact does happen, or we can simply
>not
>> >
>> >split loops on such ones.  I chose the latter.
>> >
>> >Fixes the testcase, and regstrapped without regressions on
>x86-64-linux
>> >
>> >(all languages+Ada).  Okay for trunk?
>> 
>> OK
>
>Actually there came another report in the same bug, which has a
>different 
>but related cause.  In the testcase the potential split-point is
>
>  if (outer >= inner)
>
>where the final value of 'inner' is known constant in the _outer_ loop.
> 
>But of course we have to consider the actual place of the use: the 
>comparison statement which is inside the inner loop, not merely in the 
>outer loop.  Fixed with the amended patch.
>
>Regstrapping on x86-64-linux in progress (all langs+ada), but I know
>that 
>it fixes both testcases and doesn't regress in gcc.dg.  Okay for trunk
>if 
>regstrapping succeeds?

OK.

Richard.

>
>Ciao,
>Michael.
>   PR tree-optimization/78725
>   * tree-ssa-loop-split.c (split_at_bb_p): Check for overflow and
>   at correct use point.
>
>testsuite/
>   PR tree-optimization/78725
>   * gcc.dg/pr78725.c: New test.
>   * gcc.dg/pr78725-2.c: New test.
>
>diff --git a/gcc/testsuite/gcc.dg/pr78725-2.c
>b/gcc/testsuite/gcc.dg/pr78725-2.c
>new file mode 100644
>index 000..9de489e
>--- /dev/null
>+++ b/gcc/testsuite/gcc.dg/pr78725-2.c
>@@ -0,0 +1,19 @@
>+/* { dg-do run } */
>+/* { dg-options "-O3 -fsplit-loops" } */
>+
>+int a, b, c;
>+
>+int main ()
>+{
>+  int d;
>+  for (; c < 1; c++)
>+for (d = 0; d < 3; d++)
>+  for (b = 0; b < 1; b++)
>+  if (c >= d)
>+a = 1;
>+
>+  if (a != 1)
>+__builtin_abort ();
>+
>+  return 0;
>+}
>diff --git a/gcc/testsuite/gcc.dg/pr78725.c
>b/gcc/testsuite/gcc.dg/pr78725.c
>new file mode 100644
>index 000..ed95790
>--- /dev/null
>+++ b/gcc/testsuite/gcc.dg/pr78725.c
>@@ -0,0 +1,19 @@
>+/* { dg-do run } */
>+/* { dg-options "-O3 -fsplit-loops" } */
>+
>+int fn1 (int b, int c)
>+{
>+return c < 0 || c > 31 ? 0 : b >> c;
>+}
>+
>+unsigned char d = 255; 
>+int e, f;
>+
>+int main ()
>+{
>+  for (; f < 2; f++)
>+e = fn1 (1, d++);
>+  if (e != 1)
>+__builtin_abort ();
>+  return 0; 
>+}
>diff --git a/gcc/tree-ssa-loop-split.c b/gcc/tree-ssa-loop-split.c
>index dac68e6..84c0627 100644
>--- a/gcc/tree-ssa-loop-split.c
>+++ b/gcc/tree-ssa-loop-split.c
>@@ -102,10 +102,11 @@ split_at_bb_p (struct loop *loop, basic_block bb,
>tree *border, affine_iv *iv)
> 
>   tree op0 = gimple_cond_lhs (stmt);
>   tree op1 = gimple_cond_rhs (stmt);
>+  struct loop *useloop = loop_containing_stmt (stmt);
> 
>-  if (!simple_iv (loop, loop, op0, iv, false))
>+  if (!simple_iv (loop, useloop, op0, iv, false))
> return NULL_TREE;
>-  if (!simple_iv (loop, loop, op1, &iv2, false))
>+  if (!simple_iv (loop, useloop, op1, &iv2, false))
> return NULL_TREE;
> 
>   /* Make it so that the first argument of the condition is
>@@ -122,6 +123,8 @@ split_at_bb_p (struct loop *loop, basic_block bb,
>tree *border, affine_iv *iv)
> return NULL_TREE;
>   if (!integer_zerop (iv2.step))
> return NULL_TREE;
>+  if (!iv->no_overflow)
>+return NULL_TREE;
> 
>   if (dump_file && (dump_flags & TDF_DETAILS))
> {

[PATCH v2, i386]: Fix PR78738, unrecognized insn with -ffast-math

[Uros Bizjak]

Hello!

Attached patch fixes PR78738 in a different way. The patch enables
X87_ENABLE_ARITH and X87_ENABLE_FLOAT also for
flag_unsafe_math_optimizations.

2016-12-12  Uros Bizjak  

PR target/78738
* config/i386/i386.h (X87_ENABLE_ARITH): Also enable for
flag_unsafe_math_optimizations.
(X87_ENABLE_FLOAT): Ditto.

testsuite/ChangeLog:

2016-12-12  Uros Bizjak  

PR target/78738
* gcc.target/i386/pr78738.c: New test.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainline SVN.

Uros.
Index: config/i386/i386.h
===
--- config/i386/i386.h  (revision 243558)
+++ config/i386/i386.h  (working copy)
@@ -693,13 +693,16 @@
 /* Whether to allow x87 floating-point arithmetic on MODE (one of
SFmode, DFmode and XFmode) in the current excess precision
configuration.  */
-#define X87_ENABLE_ARITH(MODE) \
-  (flag_excess_precision == EXCESS_PRECISION_FAST || (MODE) == XFmode)
+#define X87_ENABLE_ARITH(MODE) \
+  (flag_unsafe_math_optimizations  \
+   || flag_excess_precision == EXCESS_PRECISION_FAST   \
+   || (MODE) == XFmode)
 
 /* Likewise, whether to allow direct conversions from integer mode
IMODE (HImode, SImode or DImode) to MODE.  */
 #define X87_ENABLE_FLOAT(MODE, IMODE)  \
-  (flag_excess_precision == EXCESS_PRECISION_FAST  \
+  (flag_unsafe_math_optimizations  \
+   || flag_excess_precision == EXCESS_PRECISION_FAST   \
|| (MODE) == XFmode \
|| ((MODE) == DFmode && (IMODE) == SImode)  \
|| (IMODE) == HImode)
Index: testsuite/gcc.target/i386/pr78738.c
===
--- testsuite/gcc.target/i386/pr78738.c (nonexistent)
+++ testsuite/gcc.target/i386/pr78738.c (working copy)
@@ -0,0 +1,10 @@
+/* PR middle-end/78738 */
+/* { dg-do compile } */
+/* { dg-options "-O -std=c99 -ffast-math -mfpmath=387" } */
+
+double round (double);
+
+int foo (double a)
+{
+  return round (a);
+}

Re: [PATCH] Make std::enable_shared_from_this cope with ambiguity

[Jonathan Wakely]

On 19/10/16 21:13 +0100, Jonathan Wakely wrote:

This patch does three things:

1. Refactor std::enable_shared_from_this support code.

Instead of several overloads of __enable_shared_from_this_helper
that contain the same code but operating on slightly different types
I've split it into two parts. Upcasting to an accessible+unambiguous
enable_shared_from_this base class is done by new functions found by
ADL, __enable_shared_from_this_base. That is called by a new
template function __shared_ptr::_M_enable_shared_from_this_with()
which actually does the enabling by calling _M_weak_assign.

Calls to _M_enable_shared_from_this_with(p) closely match the
wording from my https://wg21.link/p0033r1 paper ("enables
shared_from_this with p") and are constrained so they don't give an
error if the __enable_shared_from_this_base() call is ambiguous. We
already gracefully handled ambiguous std::enable_shared_from_this
bases (PR56383) but failed noisily if a type had a combination of
std::enable_shared_from_this, std::__enable_shared_from_this and
std::experimental::enable_shared_from_this bases. Now we treat those
combinations gracefully.

2. Change std::experimental::enable_shared_from_this bases to be
initialized independently of std::enable_shared_from_this bases.
It's now possible to have both, and for both to be enabled. See
enable_shared_from_this.cc which tests this.

The standard says we have to enable shared_from_this for types with
an accessible and unambiguous std::enable_shared_from_this base
class, and we should be able to do that even if the class also has
an experimental::enable_shared_from_this base class. Now we can.

Potentially we could do the same for std::__enable_shared_from_this,
but I'm happy for those bases to be considered ambiguous with
std::enable_shared_from_this.

3. Don't enable shared_from_this for arrays stored in
experimental::shared_ptr.  This matches the boost::shared_ptr
semantics, and I intend to propose this as a fix for C++17 too. It
doesn't make sense to treat the first element of an array specially
and enable shared_from_this for the first element only.


I forgot to say that 2. and 3. are appropriate for gcc-6-branch too,
as they only touch the experimental TS code.


This adds only that part to gcc-6-branch, so that we don't get
ambiguities between std::enable_shared_from_this base-classes and
experimental::enable_shared_from_this base-class

Tested x86_64-linux, committed to gcc-6-branch.

commit 8aee705324a8a5463a89a6cab0d77c20ae99ee41
Author: Jonathan Wakely 
Date:   Mon Dec 12 15:25:14 2016 +

Enable experimental::enable_shared_from_this explicitly

Backport from mainline
2016-10-19  Jonathan Wakely  

	* include/experimental/bits/shared_ptr.h (experimental::shared_ptr):
	Change relevant constructors to call _M_enable_shared_from_this_with.
	(experimental::shared_ptr::__efst_base_t)
	(experimental::shared_ptr::__has_efst_base): Helpers to detect
	accessible and unambiguous enable_shared_from_this bases.
	(experimental::shared_ptr::_M_enable_shared_from_this_with): Define.
	(experimental::__enable_shared_from_this_helper): Remove overload for
	std::experimental::enable_shared_from_this.
	(experimental::__expt_enable_shared_from_this_base): Define friend
	function to select a std::experimental::enable_shared_from_this base.
	* testsuite/experimental/memory/shared_ptr/cons/
	enable_shared_from_this.cc: New test.
	* testsuite/experimental/memory/shared_ptr/cons/unique_ptr_ctor.cc:
	Adjust expected behaviour for shared_ptr.

diff --git a/libstdc++-v3/include/experimental/bits/shared_ptr.h b/libstdc++-v3/include/experimental/bits/shared_ptr.h
index 2e3da62..e8c533e 100644
--- a/libstdc++-v3/include/experimental/bits/shared_ptr.h
+++ b/libstdc++-v3/include/experimental/bits/shared_ptr.h
@@ -259,7 +259,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   //	{
   //	  void* __p = _M_refcount._M_get_deleter(typeid(__tag));
   //	  _M_ptr = static_cast<_Tp*>(__p);
-  //	  __enable_shared_from_this_helper(_M_refcount, _M_ptr, _M_ptr);
   //	}
 
   // __weak_ptr::lock()
@@ -557,7 +556,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   //	{
   //	  void* __p = _M_refcount._M_get_deleter(typeid(__tag));
   //	  _M_ptr = static_cast<_Tp*>(__p);
-  //	  __enable_shared_from_this_helper(_M_refcount, _M_ptr, _M_ptr);
   //	}
 
   // __weak_ptr::lock()
@@ -740,16 +738,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   template>
 	explicit
-	shared_ptr(_Tp1* __p) : _Base_type(__p) { }
+	shared_ptr(_Tp1* __p) : _Base_type(__p)
+	{ _M_enable_shared_from_this_with(__p); }
 
   template>
 	shared_ptr(_Tp1* __p, _Deleter __d)
-	: _Base_type(__p, __d) { }
+	: _Base_type(__p, __d)
+	{ _M_enable_shared_from_this_with(__p); }
 
   template>
 	shared_ptr(_Tp1* __p, _Deleter __d, _Alloc __a)
-	: _Base_type(__p, __d, __a) { }
+	: _Base_type(__p, __d, __a)
+	{ _M_enable_shared_from_this_with(__p)

Re: [PATCH] Fix PR78027

[Jeff Law]

On 12/09/2016 07:05 AM, Cesar Philippidis wrote:

On 12/08/2016 04:37 PM, Jeff Law wrote:

On 12/08/2016 04:05 PM, Cesar Philippidis wrote:

PR78027 was classified as a fortran bug, but the underlying problem
turned out to be more generic. Basically, the IPA-ICF pass usually
ignores functions with omp decl attributes as candidates for aliasing.
Usually that works for OpenACC, because offloaded functions generated by
OpenACC PARALLEL or KERNELS regions usually have an 'omp target
entrypoint' attribute. However that is not the case in two situations:

1. ACC ROUTINES do not have an 'omp target entrypoint' attribute.

2. Nested offloaded regions inside 'omp declare target' functions do not
have 'omp target entrypoint' attributes either.

The solution I chose for this problem is to teach the IPA-ICF pass to
ignore function with 'oacc *' decl attributes. Arguably 2) should be a
parser error when an OpenACC offloaded region is embedded within an
OpenMP offloaded function. The LTO linker does report an error for nvptx
targets, but not the host. With that in mind, this patch is still
necessary for case 1.

Is this OK for trunk?

Cesar


trunk-pr78027.diff


2016-12-08  Cesar Philippidis  

PR fortran/78027

gcc/
* ipa-icf.c (sem_function::parse): Don't process functions with
oacc decl attributes, as they may be OpenACC routines.

gcc/testsuite/
* c-c++-common/goacc/acc-icf.c: New test.
* gfortran.dg/goacc/pr78027.f90: New test.

This follows the same approach as we do for openmp.  This is fine for
the trunk.


Is this also OK for gcc-6?
Your call -- I don't think folks are really using OpenACC much in gcc-6, 
but if you think it's worth the time, go ahead.


jeff

Re: [PATCH TEST]Add test for PR78652

[Jeff Law]

On 12/09/2016 03:20 AM, Bin Cheng wrote:

Hi,
PR78652 was fixed by patch for PR77856, this patch adds a test for it.  Test 
result checked, is it OK?

Thanks,
bin

gcc/testsuite/ChangeLog
2016-12-07  Bin Cheng  

PR rtl-optimization/78652
* gcc.c-torture/execute/pr78652.c: New test.

You need to restrict it to targets with named section support -- or -- 
remove the attribute section from main.


/* { dg-require-effective-target named_sections } */

Jeff

Re: [PATCH TEST]Add test for PR78652

[Jakub Jelinek]

On Mon, Dec 12, 2016 at 09:32:30AM -0700, Jeff Law wrote:
> On 12/09/2016 03:20 AM, Bin Cheng wrote:
> >Hi,
> >PR78652 was fixed by patch for PR77856, this patch adds a test for it.  Test 
> >result checked, is it OK?
> >
> >Thanks,
> >bin
> >
> >gcc/testsuite/ChangeLog
> >2016-12-07  Bin Cheng  
> >
> > PR rtl-optimization/78652
> > * gcc.c-torture/execute/pr78652.c: New test.
> >
> You need to restrict it to targets with named section support -- or --
> remove the attribute section from main.
> 
> /* { dg-require-effective-target named_sections } */

If the testcase fails before r243038 without the attribute and succeeds
with it, I'd strongly prefer the latter option - remove the attribute.

Jakub

Re: [PATCH] Improve tests for contents of header

[Jonathan Wakely]

On 07/12/16 15:22 +, Jonathan Wakely wrote:

This test for the contents of the  header doesn't get run for
C++98 mode and doesn't include the C++14 and C++17 additions. I've
split the C++98-only test into a separate file, and added the new
parts so they're tested conditionally depending on how the test is
run.

* testsuite/18_support/headers/new/synopsis.cc: Add C++14 and C++17
declarations.
* testsuite/18_support/headers/new/synopsis_cxx98.cc: New test.

Tested powerpc64le-linux, committed to trunk.


Here's the equivalent for the branches, which doesn't test the C++17
over-aligned allocation functions that are only on trunk.

Tested x86_64-linux, committed to gcc-5-branch and gcc-6-branch.

commit c6f51ca519e03b12d28be4f81b91bec5514f
Author: redi 
Date:   Wed Dec 7 15:22:24 2016 +

Improve tests for contents of  header

	Backport from mainline
	2016-12-07  Jonathan Wakely  

	* testsuite/18_support/headers/new/synopsis.cc: Add C++14 declarations
	and use effective-target to do test for C++11 and later.
	* testsuite/18_support/headers/new/synopsis_cxx98.cc: New test.

diff --git a/libstdc++-v3/testsuite/18_support/headers/new/synopsis.cc b/libstdc++-v3/testsuite/18_support/headers/new/synopsis.cc
index f3ed727..63d913b 100644
--- a/libstdc++-v3/testsuite/18_support/headers/new/synopsis.cc
+++ b/libstdc++-v3/testsuite/18_support/headers/new/synopsis.cc
@@ -1,5 +1,4 @@
-// { dg-do compile }
-// { dg-options "-std=gnu++11" }
+// { dg-do compile { target c++11 } }
 
 // Copyright (C) 2007-2016 Free Software Foundation, Inc.
 //
@@ -22,18 +21,19 @@
 
 namespace std {
   class bad_alloc;
+  class bad_array_new_length;
   struct nothrow_t;
   extern const nothrow_t nothrow;
   typedef void (*new_handler)();
-  new_handler set_new_handler(new_handler new_p) throw();
   new_handler get_new_handler() noexcept;
+  new_handler set_new_handler(new_handler new_p) noexcept;
 }
 
-void* operator new(std::size_t size) throw(std::bad_alloc);
-void* operator new(std::size_t size, const std::nothrow_t&) throw();
+void* operator new(std::size_t size);
+void* operator new(std::size_t size, const std::nothrow_t&) noexcept;
 void  operator delete(void* ptr) throw();
 void  operator delete(void* ptr, const std::nothrow_t&) throw();
-void* operator new[](std::size_t size) throw(std::bad_alloc);
+void* operator new[](std::size_t size);
 void* operator new[](std::size_t size, const std::nothrow_t&) throw();
 void  operator delete[](void* ptr) throw();
 void  operator delete[](void* ptr, const std::nothrow_t&) throw();
@@ -42,3 +42,13 @@ void* operator new  (std::size_t size, void* ptr) throw();
 void* operator new[](std::size_t size, void* ptr) throw();
 void  operator delete  (void* ptr, void*) throw();
 void  operator delete[](void* ptr, void*) throw();
+
+#if __cplusplus >= 201402L
+// C++14 sized deallocation functions
+void  operator delete(void* ptr, std::size_t size) noexcept;
+void  operator delete(void* ptr, std::size_t size,
+  const std::nothrow_t&) noexcept;
+void  operator delete[](void* ptr, std::size_t size) noexcept;
+void  operator delete[](void* ptr, std::size_t size,
+const std::nothrow_t&) noexcept;
+#endif
diff --git a/libstdc++-v3/testsuite/18_support/headers/new/synopsis_cxx98.cc b/libstdc++-v3/testsuite/18_support/headers/new/synopsis_cxx98.cc
new file mode 100644
index 000..2b2abd2
--- /dev/null
+++ b/libstdc++-v3/testsuite/18_support/headers/new/synopsis_cxx98.cc
@@ -0,0 +1,43 @@
+// { dg-options "-std=gnu++98" }
+// { dg-do compile }
+
+// Copyright (C) 2007-2016 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+#include 
+
+namespace std {
+  class bad_alloc;
+  struct nothrow_t;
+  extern const nothrow_t nothrow;
+  typedef void (*new_handler)();
+  new_handler set_new_handler(new_handler new_p) throw();
+}
+
+void* operator new(std::size_t size) throw(std::bad_alloc);
+void* operator new(std::size_t size, const std::nothrow_t&) throw();
+void  operator delete(void* ptr) throw();
+void  operator delete(void* ptr, const std::nothrow_t&) throw();
+void* operator new[](std::size_t size) throw(std::bad_alloc);
+void* operator new[](std::size_t size, const std::nothrow_t&) throw();
+void  operator delete

Re: [tree-tailcall] Check if function returns it's argument

[Jeff Law]

On 12/09/2016 01:10 AM, Richard Biener wrote:


Yea.  Not sure how often something like that would happen in practice, but
using the equivalence to simplify rather than for propagation seems like the
way to go.

I keep thinking about doing some similar in DOM, but haven't gotten around to
seeing what the fallout would be.


Shouldn't be too bad (it would require to keep an additional
what-to-substitute-for-value-X lattice during the DOM walk).  But it
will still require some "magic" to decide about those conditional
equivalences... (I think).

Separating "values" from what we substitute during elimination is a good
thing in general, so we can be more aggressive with the value parts.
I think we'd just need to change SSA_NAME_VALUE from a vector of trees 
to a pair representation or to have an on-the-side bitmap to indicate 
values that can be used for simplification but not for propagation.


It shouldn't be terrible.
jeff

Re: [PATCH v2] PR target/78748: S/390: Fix ICE with ANDC splitter.

[Dominik Vogt]

On Mon, Dec 12, 2016 at 03:50:14PM +0100, Jakub Jelinek wrote:
> On Mon, Dec 12, 2016 at 03:36:01PM +0100, Dominik Vogt wrote:
> > diff --git a/gcc/testsuite/gcc.c-torture/compile/pr78748.c 
> > b/gcc/testsuite/gcc.c-torture/compile/pr78748.c
> > new file mode 100644
> > index 000..d24a334
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.c-torture/compile/pr78748.c
> > @@ -0,0 +1,16 @@
> > +/* PR target/78748 */
> > +/* { dg-options "-march=zEC12" { target { s390*-*-* } } } */
> > +
> > +void
> > +foo (int *p, int *q)
> > +{
> > +  *q = *p & ~*q;
> > +}
> > +
> > +#if 0 /*!!!*/
> > +void
> > +bar (int *p, int *q)
> > +{
> > +  *q = ~*p & *q;
> > +}
> > +#endif
> 
> Why the #if 0 /*!!!*/?

The "!!!" is a to-do-marker.  When doing too many things in
parallel I sometimes forget removing them.  Sorry for that.  Patch
without the marker attached.

> The test just verifies the compiler doesn't ICE
> and stuff assembles,

> I'd hope bar also compiles and assembles.

It does, with and without the patch.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany
gcc/ChangeLog-pr78748

PR target/78748
* config/s390/s390.md ("*andc_split_"): Allow memory destination
only if it coincides with operand 2.
gcc/testsuite/ChangeLog-pr78748

PR target/78748
* gcc.c-torture/compile/pr78748.c: New test.
>From 02cd9f64bb62c26248d013261ea0e037e60ed2a4 Mon Sep 17 00:00:00 2001
From: Dominik Vogt 
Date: Mon, 12 Dec 2016 10:35:21 +0100
Subject: [PATCH] PR target/78748: S/390: Fix ICE with ANDC splitter.

---
 gcc/config/s390/s390.md   |  6 +-
 gcc/testsuite/gcc.c-torture/compile/pr78748.c | 14 ++
 2 files changed, 19 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr78748.c

diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index 4f2effd..9d8e6b6 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -7420,7 +7420,11 @@
(and:GPR (not:GPR (match_operand:GPR 1 "nonimmediate_operand" ""))
 (match_operand:GPR 2 "general_operand" "")))
(clobber (reg:CC CC_REGNUM))]
-  "! reload_completed && s390_logical_operator_ok_p (operands)"
+  "! reload_completed
+   && (GET_CODE (operands[0]) != MEM
+  /* Ensure that s390_logical_operator_ok_p will succeed even
+on the split xor if (b & a) is stored into a pseudo.  */
+   || rtx_equal_p (operands[0], operands[2]))"
   "#"
   "&& 1"
   [
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr78748.c 
b/gcc/testsuite/gcc.c-torture/compile/pr78748.c
new file mode 100644
index 000..032e78d
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr78748.c
@@ -0,0 +1,14 @@
+/* PR target/78748 */
+/* { dg-options "-march=zEC12" { target { s390*-*-* } } } */
+
+void
+foo (int *p, int *q)
+{
+  *q = *p & ~*q;
+}
+
+void
+bar (int *p, int *q)
+{
+  *q = ~*p & *q;
+}
-- 
2.3.0

Re: [PATCH] Fix PR78027

[Jakub Jelinek]

On Mon, Dec 12, 2016 at 09:29:44AM -0700, Jeff Law wrote:
> >>>2016-12-08  Cesar Philippidis  
> >>>
> >>>PR fortran/78027
> >>>
> >>>gcc/
> >>>* ipa-icf.c (sem_function::parse): Don't process functions with
> >>>oacc decl attributes, as they may be OpenACC routines.
> >>>
> >>>gcc/testsuite/
> >>>* c-c++-common/goacc/acc-icf.c: New test.
> >>>* gfortran.dg/goacc/pr78027.f90: New test.
> >>This follows the same approach as we do for openmp.  This is fine for
> >>the trunk.
> >
> >Is this also OK for gcc-6?
> Your call -- I don't think folks are really using OpenACC much in gcc-6, but
> if you think it's worth the time, go ahead.

As Alex noted, the patch looks wrong, there should be "omp declare target"
attribute, which isn't specific to OpenMP only, but covers all the
offloading fns.  I have on my todo list to look at it.

Jakub

Re: [PATCH] Fix PR78027

[Jeff Law]

On 12/12/2016 09:37 AM, Jakub Jelinek wrote:

On Mon, Dec 12, 2016 at 09:29:44AM -0700, Jeff Law wrote:

2016-12-08  Cesar Philippidis  

   PR fortran/78027

   gcc/
   * ipa-icf.c (sem_function::parse): Don't process functions with
   oacc decl attributes, as they may be OpenACC routines.

   gcc/testsuite/
   * c-c++-common/goacc/acc-icf.c: New test.
   * gfortran.dg/goacc/pr78027.f90: New test.

This follows the same approach as we do for openmp.  This is fine for
the trunk.


Is this also OK for gcc-6?

Your call -- I don't think folks are really using OpenACC much in gcc-6, but
if you think it's worth the time, go ahead.


As Alex noted, the patch looks wrong, there should be "omp declare target"
attribute, which isn't specific to OpenMP only, but covers all the
offloading fns.  I have on my todo list to look at it.
I thought the final resolution of that thread was a misunderstanding 
from Alex as to how this stuff worked.  If I'm wrong, then obviously we 
shouldn't apply the patch to the trunk or branch.


jeff

Re: [PATCH v2] combine: Improve change_zero_ext, call simplify_set afterwards.

[Dominik Vogt]

On Sat, Dec 10, 2016 at 10:37:38AM -0600, Segher Boessenkool wrote:
> On Fri, Dec 09, 2016 at 04:23:44PM +0100, Dominik Vogt wrote:
> > 0001-*
> > 
> >   Deal with mode expanding zero_extracts in change_zero_ext.  The
> >   patch looks good to me, but not sure whether endianness is
> >   handled properly.  Is the second argument of gen_rtx_SUBREG
> >   correct?
> 
> > >From 600ed3dadd5bc2568ab53be8466686abaf27ff3f Mon Sep 17 00:00:00 2001
> > From: Dominik Vogt 
> > Date: Fri, 9 Dec 2016 02:48:30 +0100
> > Subject: [PATCH 1/2] combine: Handle mode expanding zero_extracts in
> >  change_zero_ext.
> > 
> > Example:
> > 
> >   (zero_extract:DI (reg:SI)
> >(const_int 24)
> >(const_int 0))
> > 
> > -->
> > 
> >   (and:DI (subreg:DI (lshiftrt:SI (reg:SI) (const_int 8))
> >  0)
> >   (const_int 16777215))
> > ---
> >  gcc/combine.c | 12 +---
> >  1 file changed, 9 insertions(+), 3 deletions(-)
> > 
> > diff --git a/gcc/combine.c b/gcc/combine.c
> > index b429453..e14a08f 100644
> > --- a/gcc/combine.c
> > +++ b/gcc/combine.c
> > @@ -11237,18 +11237,24 @@ change_zero_ext (rtx pat)
> >if (GET_CODE (x) == ZERO_EXTRACT
> >   && CONST_INT_P (XEXP (x, 1))
> >   && CONST_INT_P (XEXP (x, 2))
> > - && GET_MODE (XEXP (x, 0)) == mode)
> > + && (GET_MODE (XEXP (x, 0)) == mode
> > + || GET_MODE_PRECISION (GET_MODE (XEXP (x, 0)))
> > +< GET_MODE_PRECISION (mode)))
> 
> If you make this <= you can collapse the two cases into one.
> 
> > {
> > + machine_mode inner_mode = GET_MODE (XEXP (x, 0));
> > +
> >   size = INTVAL (XEXP (x, 1));
> >  
> >   int start = INTVAL (XEXP (x, 2));
> >   if (BITS_BIG_ENDIAN)
> > -   start = GET_MODE_PRECISION (mode) - size - start;
> > +   start = GET_MODE_PRECISION (inner_mode) - size - start;
> >  
> >   if (start)
> > -   x = gen_rtx_LSHIFTRT (mode, XEXP (x, 0), GEN_INT (start));
> > +   x = gen_rtx_LSHIFTRT (inner_mode, XEXP (x, 0), GEN_INT (start));
> >   else
> > x = XEXP (x, 0);
> > + if (mode != inner_mode)
> > +   x = gen_rtx_SUBREG (mode, x, 0);
> 
> gen_lowpart_SUBREG instead?  It's easier to read, and code a little
> further down does the same thing.
> 
> Okay for trunk with those changes (did you bootstrap+regcheck this
> already?)  Thanks,

Patch with these changes and a fix because of not handling
VOIDmode attached.  Bootstrapped and regression tested on s390 and
s390x.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany
gcc/ChangeLog-change_zero_ext-1

* combine.c (change_zero_ext): Handle mode expanding zero_extracts.
>From 0c23906cb81c745571903799a00338fe974303da Mon Sep 17 00:00:00 2001
From: Dominik Vogt 
Date: Fri, 9 Dec 2016 02:48:30 +0100
Subject: [PATCH] combine: Handle mode expanding zero_extracts in
 change_zero_ext.

Example:

  (zero_extract:DI (reg:SI)
   (const_int 24)
   (const_int 0))

-->

  (and:DI (subreg:DI (lshiftrt:SI (reg:SI) (const_int 8))
 0)
  (const_int 16777215))
---
 gcc/combine.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/gcc/combine.c b/gcc/combine.c
index b429453..19851a2 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -11237,18 +11237,24 @@ change_zero_ext (rtx pat)
   if (GET_CODE (x) == ZERO_EXTRACT
  && CONST_INT_P (XEXP (x, 1))
  && CONST_INT_P (XEXP (x, 2))
- && GET_MODE (XEXP (x, 0)) == mode)
+ && GET_MODE (XEXP (x, 0)) != VOIDmode
+ && GET_MODE_PRECISION (GET_MODE (XEXP (x, 0)))
+ <= GET_MODE_PRECISION (mode))
{
+ machine_mode inner_mode = GET_MODE (XEXP (x, 0));
+
  size = INTVAL (XEXP (x, 1));
 
  int start = INTVAL (XEXP (x, 2));
  if (BITS_BIG_ENDIAN)
-   start = GET_MODE_PRECISION (mode) - size - start;
+   start = GET_MODE_PRECISION (inner_mode) - size - start;
 
  if (start)
-   x = gen_rtx_LSHIFTRT (mode, XEXP (x, 0), GEN_INT (start));
+   x = gen_rtx_LSHIFTRT (inner_mode, XEXP (x, 0), GEN_INT (start));
  else
x = XEXP (x, 0);
+ if (mode != inner_mode)
+   x = gen_lowpart_SUBREG (mode, x);
}
   else if (GET_CODE (x) == ZERO_EXTEND
   && SCALAR_INT_MODE_P (mode)
-- 
2.3.0

[PATCH] c++/78774 - [6/7 Regression] ICE in constexpr string literals and templates

[Martin Sebor]

The attached patch removes the unsafe assumption behind the ICE.
Is this okay for both trunk and GCC 6?

Thanks
Martin
PR c++/78774 - [6/7 Regression] ICE in constexpr string literals and templates

gcc/cp/ChangeLog:

	PR c++/78774
	* pt.c (convert_template_argument): Avoid assuming operand type
	is non-null since that of SCOPE_REF is not.

gcc/testsuite/ChangeLog:

	PR c++/78774
	* g++.dg/cpp1y/pr78774.C: New test.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 97d0b48..1d68fcc 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -7375,9 +7375,11 @@ convert_template_argument (tree parm,
   /* Reject template arguments that are references to built-in
  functions with no library fallbacks.  */
   const_tree inner = TREE_OPERAND (val, 0);
-  if (TREE_CODE (TREE_TYPE (inner)) == REFERENCE_TYPE
-  && TREE_CODE (TREE_TYPE (TREE_TYPE (inner))) == FUNCTION_TYPE
-  && TREE_CODE (TREE_TYPE (inner)) == REFERENCE_TYPE
+	  const_tree innertype = TREE_TYPE (inner);
+  if (innertype
+	  && TREE_CODE (innertype) == REFERENCE_TYPE
+  && TREE_CODE (TREE_TYPE (innertype)) == FUNCTION_TYPE
+  && TREE_CODE (innertype) == REFERENCE_TYPE
   && 0 < TREE_OPERAND_LENGTH (inner)
   && reject_gcc_builtin (TREE_OPERAND (inner, 0)))
   return error_mark_node;
diff --git a/gcc/testsuite/g++.dg/cpp1y/pr78774.C b/gcc/testsuite/g++.dg/cpp1y/pr78774.C
new file mode 100644
index 000..c77032d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/pr78774.C
@@ -0,0 +1,9 @@
+// PR c++/78774 - [6/7 Regression] ICE in constexpr string literals and
+// templates
+// { dg-do compile { target c++14 } }
+
+template  struct ops {
+  template  struct A;
+  template  using explode = typename A<*Ptr>::join;
+};
+template  typename ops<'\0'>::explode::type a;

Re: [C++/78252] libiberty demangler crash with lambda (auto)

[Jason Merrill]

OK.

On Mon, Dec 12, 2016 at 8:53 AM, Nathan Sidwell  wrote:
> following discussion on the ABI list, here's an update to the generic lambda
> demangler patch.
>
> The guts of the patch are the same as before -- note when we're printing a
> generic lambda's parms and interpret template type parm references
> differently.  however:
> 1) don't refer to this as a mangling bug, because it isn't
> 2) add a ':$n' suffix to each generic parm, as that's how g++ itself shows
> them in diagnostics and the like.
>
> I'll mark 78621 as not a bug too.
>
> ok?
>
> nathan
>
> --
> Nathan Sidwell

Re: [PATCH v2] combine: Improve change_zero_ext, call simplify_set afterwards.

[Segher Boessenkool]

On Mon, Dec 12, 2016 at 05:46:02PM +0100, Dominik Vogt wrote:
> Patch with these changes and a fix because of not handling
> VOIDmode attached.  Bootstrapped and regression tested on s390 and
> s390x.

Okay for trunk.

When did you see VOIDmode, btw?  It wasn't on a const_int I hope?


Segher


>   * combine.c (change_zero_ext): Handle mode expanding zero_extracts.

Re: [PATCH v2] combine: Improve change_zero_ext, call simplify_set afterwards.

[Dominik Vogt]

On Mon, Dec 12, 2016 at 10:54:12AM -0600, Segher Boessenkool wrote:
> On Mon, Dec 12, 2016 at 05:46:02PM +0100, Dominik Vogt wrote:
> > Patch with these changes and a fix because of not handling
> > VOIDmode attached.  Bootstrapped and regression tested on s390 and
> > s390x.
> 
> Okay for trunk.
> 
> When did you see VOIDmode, btw?  It wasn't on a const_int I hope?

That was triggered by several regression test cases, e.g.
/gcc.c-torture/compile/pr57108.c.  The LSHIFTRT had VOIDmode.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: [Patch, Fortran] PR 78392: ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979

[Paul Richard Thomas]

Hi Janus,

The patch is good - OK for trunk.

Thanks

Paul

On 12 December 2016 at 16:52, Janus Weil  wrote:
> Hi all,
>
> I hate to ping this patch once more, but somehow we need to come to a
> conclusion here.
>
> The issue boils down to the fact that there is a piece of code in the
> gfortran code which claims that specification functions are
> 'constant', but I doubt that this is true. To my understanding the
> concept of specification expressions and specification functions (see
> section 7.1.6 in the F03 standard) was introduced essentially to refer
> to side-effect-free expressions that can be used e.g. in a
> type-specification context (array bounds, char-length parameters etc).
>
> However I think 'specification functions' do not necessarily need to
> be 'constants', in the sense that subsequent invocations give always
> the same (constant) result and their value can be determined at
> compile time.
>
> My patch is at: https://gcc.gnu.org/ml/fortran/2016-11/msg00188.html
> Further discussion at: https://gcc.gnu.org/ml/fortran/2016-11/msg00243.html
>
> Any comments, please!?!
>
> Cheers,
> Janus
>
>
>
> 2016-12-03 8:05 GMT+01:00 Janus Weil :
>> double-ping!
>>
>>
>> 2016-11-26 10:45 GMT+01:00 Janus Weil :
>>> ping!
>>>
>>>
>>> 2016-11-19 10:12 GMT+01:00 Janus Weil :
 Hi all,

> I previously assumed that the test case for this PR would be legal,
> but by now I think that's wrong. The test case should be rejected, and
> we already have checking mechanisms for this (see
> resolve_fl_variable), but apparently they are not working.
>
> My current suspicion is that 'gfc_is_constant_expr' has a bug, because
> it claims the call to the function 'get_i' to be a constant
> expression. This is not true, because get_i() can not be reduced to a
> compile-time constant.

 some more reading in the standard confirms this suspicion: In
 gfc_is_constant_expr there is a piece of code which claims that
 specification functions are constant. That is certainly not true, and
 so what I'm doing in the attached fix is to remove that code and add
 some references to the standard to make things clearer.

 The code that I'm removing has last been touched in this commit by
 Jerry six years ago:

 https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=166520

 However, this did not introduce the bug in the first place (not sure
 when that happened).

 In any case the new patch in the attachment regtests cleanly and
 correctly rejects the original test case as well as one of the cases
 mentioned by Dominique. Ok for trunk?

 Cheers,
 Janus



 2016-11-19  Janus Weil  

 PR fortran/78392
 * expr.c (gfc_is_constant_expr): Specification functions are not
 compile-time constants. Update documentation (add reference to F08
 standard), add a FIXME.
 (external_spec_function): Add reference to F08 standard.
 * resolve.c (resolve_fl_variable): Ditto.

 2016-11-19  Janus Weil  

 PR fortran/78392
 * gfortran.dg/constant_shape.f90: New test case.



-- 
If you're walking down the right path and you're willing to keep
walking, eventually you'll make progress.

Barack Obama

Re: [PATCH] PR 78534 Change character length from int to size_t

[Andre Vehreschild]

Hi Janne,

I found that you are favoring build_int_cst (size_type_node, 0) over
size_zero_node. Is there a reason to this?

Furthermore did I have to patch this:

diff --git a/gcc/fortran/dump-parse-tree.c b/gcc/fortran/dump-parse-tree.c
index 585f25d..f374558 100644
--- a/gcc/fortran/dump-parse-tree.c
+++ b/gcc/fortran/dump-parse-tree.c
@@ -465,7 +465,7 @@ show_expr (gfc_expr *p)
  break;
 
case BT_HOLLERITH:
- fprintf (dumpfile, "%dH", p->representation.length);
+ fprintf (dumpfile, "%zdH", p->representation.length);
  c = p->representation.string;
  for (i = 0; i < p->representation.length; i++, c++)
{

to bootstrap on x86_64-linux/f23.

And I have this regression:

FAIL: gfortran.dg/allocate_deferred_char_scalar_1.f03   -O1  (test for excess
errors)

allocate_deferred_char_scalar_1.f03:184:0:

 p = '12345679'
 
Warning: '__builtin_memcpy' writing 8 bytes into a region of size 5 overflows
 the destination [-Wstringop-overflow=]
 allocate_deferred_char_scalar_1.f03:242:0:

 p = 4_'12345679'
 
Warning: '__builtin_memcpy' writing 32 bytes into a region of size 20 overflows
the destination [-Wstringop-overflow=]

I also tried with a sanitized gfortran and am seeing some issues there. I have
to sort through these, but thought to let you know about the above already.

Btw, the patch for changing the ABI of the coarray-libs is already nearly done.
I just need to figure that what the state of regressions is with and without my
change.

- Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

[committed] Fix for PR preprocessor/78680

[David Malcolm]

PR preprocessor/78680 identifies a crash when attempting to issue
a -Wformat warning, where the format string includes a string token
split across multiple physical source lines via backslash-continued
lines.

The issue is that libcpp is generating bogus range information for
such tokens.

For example, in:

void fn1() {
  __builtin_printf("\
 %ld.\n\
2\n"); };

the range of the string token is printed as:

   __builtin_printf("\
^~

whereas the range ought to be:

  __builtin_printf("\
   ^~
 %ld.\n\
 ~~~
2\n"); };


The root cause is that the line notes expressing the update
of the buffer in lex.c aren't yet updated when the end-point of
the token is computed

3095tok_range.m_finish
3096  = linemap_position_for_column (pfile->line_table,
3097 CPP_BUF_COLUMN (buffer, 
buffer->cur));

so that the physical line is still regarded as that of the start
of the token, and, where CPP_BUF_COLUMN uses (BUF)->line_base,
line_base is still the location of the first physical line in the
and hence the column information is too large (as if it were the
offset in the *logical* line).

(the printed range is somewhat misleading; the actual buggy range
extends beyond the "\ in the line, but within diagnostic-show-locus.c
layout::print_annotation_line only prints up to the xbound set by
layout::print_source_line and so truncates most of the buggy range).

The fix is to ensure that line notes are handled before calculating
the end-point of the token range.

This leads to the range for the string token being correctly
computed, as:

  __builtin_printf("\
   ^~
 %ld.\n\
 ~~~
2\n"); };


and this leads to get_substring_ranges_for_loc failing gracefully,
rather than crashing.

Successfully bootstrapped®rtested on x86_64-pc-linux-gnu; adds
10 PASS results to gcc.sum.

Committed to trunk as r243567.

gcc/testsuite/ChangeLog:
PR preprocessor/78680
* gcc.dg/format/pr78680.c: New test case.
* gcc.dg/plugin/diagnostic-test-expressions-1.c
(test_multiline_token): New function.
* gcc.dg/plugin/diagnostic-test-string-literals-1.c
(test_backslash_continued_logical_lines): New function.

libcpp/ChangeLog:
PR preprocessor/78680
* lex.c (_cpp_lex_direct): Ensure line notes are processed before
computing the end-point of the token.
---
 gcc/testsuite/gcc.dg/format/pr78680.c| 16 
 .../gcc.dg/plugin/diagnostic-test-expressions-1.c| 19 +++
 .../plugin/diagnostic-test-string-literals-1.c   | 20 
 libcpp/lex.c |  7 +++
 4 files changed, 62 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/format/pr78680.c

diff --git a/gcc/testsuite/gcc.dg/format/pr78680.c 
b/gcc/testsuite/gcc.dg/format/pr78680.c
new file mode 100644
index 000..0c599f3
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/format/pr78680.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -Wall -Wextra -fdiagnostics-show-caret" } */
+
+void fn1() {
+  __builtin_printf("\
+ %ld.\n\
+2\n"); };
+/* { dg-warning "expects a matching" "" { target *-*-* } .-3 } */
+/* { dg-begin-multiline-output "" }
+   __builtin_printf("\
+^~
+  %ld.\n\
+  ~~~
+ 2\n"); };
+ 
+   { dg-end-multiline-output "" } */
diff --git a/gcc/testsuite/gcc.dg/plugin/diagnostic-test-expressions-1.c 
b/gcc/testsuite/gcc.dg/plugin/diagnostic-test-expressions-1.c
index 9372936..afbe0f7 100644
--- a/gcc/testsuite/gcc.dg/plugin/diagnostic-test-expressions-1.c
+++ b/gcc/testsuite/gcc.dg/plugin/diagnostic-test-expressions-1.c
@@ -689,3 +689,22 @@ void test_multiple_ordinary_maps (void)
 ~~  
{ dg-end-multiline-output "" } */
 }
+
+/* Verify that we correctly handle a token that spans multiple
+   physical lines.  */
+
+const char *test_multiline_token (void)
+{
+  __emit_expression_range (0, "foo\
+bar\
+baz");
+/* { dg-warning "range" "" { target *-*-* } .-3 } */
+/* { dg-begin-multiline-output "" }
+   __emit_expression_range (0, "foo\
+   ^
+ bar\
+    
+ baz");
+    
+   { dg-end-multiline-output "" } */
+}
diff --git a/gcc/testsuite/gcc.dg/plugin/diagnostic-test-string-literals-1.c 
b/gcc/testsuite/gcc.dg/plugin/diagnostic-test-string-literals-1.c
index 76a085e..03f042a 100644
--- a/gcc/testsuite/gcc.dg/plugin/diagnostic-test-string-literals-1.c
+++ b/gcc/testsuite/gcc.dg/plugin/diagnostic-test-string-literals-1.c
@@ -272,3 +272,23 @@ test_terminator_location (void)
^
{ dg-end-multiline-output "" } */
 }
+
+/* Verify that we fail gracefully when a string literal token is split
+   across multiple phy

Re: C++ PATCH for c++/78647 (ICE-on-invalid with attribute_fallthrough_p)

[Marek Polacek]

Ping.

On Mon, Dec 05, 2016 at 09:37:30PM +0100, Marek Polacek wrote:
> We were crashing on this invalid test because cp_parser_std_attribute_spec_seq
> in cp_parser_statement returned error_mark_node, but the subsequent
> attribute_fallthrough_p wasn't prepared for that.
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
> 
> 2016-12-05  Marek Polacek  
> 
>   PR c++/78647
>   * c-family/c-common.c (attribute_fallthrough_p): Return false for
>   error_mark_node.
> 
>   * g++.dg/parse/error58.C: New.
> 
> diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
> index 0749361..c8e1f0d 100644
> --- gcc/c-family/c-common.c
> +++ gcc/c-family/c-common.c
> @@ -5558,6 +5558,8 @@ parse_optimize_options (tree args, bool attr_p)
>  bool
>  attribute_fallthrough_p (tree attr)
>  {
> +  if (attr == error_mark_node)
> +   return false;
>tree t = lookup_attribute ("fallthrough", attr);
>if (t == NULL_TREE)
>  return false;
> diff --git gcc/testsuite/g++.dg/parse/error58.C 
> gcc/testsuite/g++.dg/parse/error58.C
> index e69de29..5ed6e1e 100644
> --- gcc/testsuite/g++.dg/parse/error58.C
> +++ gcc/testsuite/g++.dg/parse/error58.C
> @@ -0,0 +1,7 @@
> +// PR c++/78647
> +// { dg-do compile { target c++11 } }
> +// { dg-options "-w" }
> +
> +struct A;
> +void foo ();
> +void f() { alignas (foo (A)); } // { dg-error "expected" "" }
> 
>   Marek

Marek

Re: [PATCH, fortran, pr77785, v2] [Coarray] ICE in gfc_get_caf_token_offset, at fortran/trans-expr.c:1990

[Andre Vehreschild]

Hi Janus,

all the sanitizer issues I fixed occur during compiling the testsuite. So I
would say, that when with the patch these errors do not occur anymore while
processing the testsuite, then those are tested for, right?

- Andre
On Mon, 12 Dec 2016 13:37:43 +0100
Janus Weil  wrote:

> Hi Andre,
> 
> > the attached patch corrects reporting of "Sorry, unimplemented yet" for
> > allocatable and pointer components in polymorphic objects (BT_CLASS) thus
> > fixing two ICEs reported in the PR.
> >
> > The next chunk fixes an ICE when the declaration containing the token
> > information is of type POINTER or REFERENCE.
> >
> > Bootstraps and regtests ok on x86_64-linux/f23. Ok for trunk?  
> 
> the resolve.c hunk is certainly ok. The trans-array.c part looks
> reasonable as well, but I wonder if it is actually covered by any of
> your test cases? Since they are all compile-only, with errors being
> thrown at resolution stage, do they even get to the translation stage?
> 
> Cheers,
> Janus


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Re: C++ PATCH for c++/78647 (ICE-on-invalid with attribute_fallthrough_p)

[Jakub Jelinek]

On Mon, Dec 12, 2016 at 06:44:19PM +0100, Marek Polacek wrote:
> Ping.
> 
> On Mon, Dec 05, 2016 at 09:37:30PM +0100, Marek Polacek wrote:
> > We were crashing on this invalid test because 
> > cp_parser_std_attribute_spec_seq
> > in cp_parser_statement returned error_mark_node, but the subsequent
> > attribute_fallthrough_p wasn't prepared for that.
> > 
> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> > 
> > 2016-12-05  Marek Polacek  
> > 
> > PR c++/78647
> > * c-family/c-common.c (attribute_fallthrough_p): Return false for

No c-family/ prefix in c-family/ChangeLog.

> > error_mark_node.
> > 
> > * g++.dg/parse/error58.C: New.

Otherwise LGTM.

Jakub

[PATCH, GCC/testsuite/ARM] Skip optional_mthumb tests if GCC has a default mode

[Thomas Preudhomme]

Hi,

The logic to make -mthumb optional for Thumb-only devices is only executed when 
no -marm or -mthumb is given on the command-line. This includes configuring GCC 
with --with-mode= because this makes the option to be passed before any others. 
The optional_mthumb-* testcases are skipped when -marm or -mthumb is passed on 
the command line but not when GCC was configured with --with-mode. Not only are 
the tests meaningless in these configurations, they also spuriously FAIL if 
--with-mode=arm was used since the test are built for Thumb-only devices, as 
reported by Christophe Lyon in [1].


[1] https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02082.html

This patch adds logic to target-support.exp to check how was GCC configured and 
changes the optional_mthumb testcases to be skipped if there is a default mode 
(--with-mode=). It also fixes a couple of typo on the selectors.


ChangeLog entry is as follows:


*** gcc/testsuite/ChangeLog ***

2016-12-09  Thomas Preud'homme  

* lib/target-supports.exp (check_configured_with): New procedure.
(check_effective_target_default_mode): new effective target.
* gcc.target/arm/optional_thumb-1.c: Skip if GCC was configured with a
default mode.  Fix dg-skip-if target selector syntax.
* gcc.target/arm/optional_thumb-2.c: Likewise.
* gcc.target/arm/optional_thumb-3.c: Fix dg-skip-if target selector
syntax.


Is this ok for stage3?

Best regards,

Thomas
diff --git a/gcc/testsuite/gcc.target/arm/optional_thumb-1.c b/gcc/testsuite/gcc.target/arm/optional_thumb-1.c
index 23df62887ba4aaa1d8717a34ecda9a40246f0552..99cb0c3f33b601fff4493feef72765f7590e18f6 100644
--- a/gcc/testsuite/gcc.target/arm/optional_thumb-1.c
+++ b/gcc/testsuite/gcc.target/arm/optional_thumb-1.c
@@ -1,5 +1,5 @@
-/* { dg-do compile } */
-/* { dg-skip-if "-marm/-mthumb/-march/-mcpu given" { *-*-*} { "-marm" "-mthumb" "-march=*" "-mcpu=*" } } */
+/* { dg-do compile { target { ! default_mode } } } */
+/* { dg-skip-if "-marm/-mthumb/-march/-mcpu given" { *-*-* } { "-marm" "-mthumb" "-march=*" "-mcpu=*" } } */
 /* { dg-options "-march=armv6-m" } */
 
 /* Check that -mthumb is not needed when compiling for a Thumb-only target.  */
diff --git a/gcc/testsuite/gcc.target/arm/optional_thumb-2.c b/gcc/testsuite/gcc.target/arm/optional_thumb-2.c
index 4bd53a45eca97e62dd3b86d5a1a66c5ca21e7aad..280dfb3fec55570b6cfe934303c9bd3d50322b86 100644
--- a/gcc/testsuite/gcc.target/arm/optional_thumb-2.c
+++ b/gcc/testsuite/gcc.target/arm/optional_thumb-2.c
@@ -1,5 +1,5 @@
-/* { dg-do compile } */
-/* { dg-skip-if "-marm/-mthumb/-march/-mcpu given" { *-*-*} { "-marm" "-mthumb" "-march=*" "-mcpu=*" } } */
+/* { dg-do compile { target { ! default_mode } } } */
+/* { dg-skip-if "-marm/-mthumb/-march/-mcpu given" { *-*-* } { "-marm" "-mthumb" "-march=*" "-mcpu=*" } } */
 /* { dg-options "-mcpu=cortex-m4" } */
 
 /* Check that -mthumb is not needed when compiling for a Thumb-only target.  */
diff --git a/gcc/testsuite/gcc.target/arm/optional_thumb-3.c b/gcc/testsuite/gcc.target/arm/optional_thumb-3.c
index f1fd5c8840b191e600c20a7817c611bb9bb645df..d9150e09e475dfbeb7b0b0c153c913b1ad6f0777 100644
--- a/gcc/testsuite/gcc.target/arm/optional_thumb-3.c
+++ b/gcc/testsuite/gcc.target/arm/optional_thumb-3.c
@@ -1,8 +1,8 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target arm_cortex_m } */
-/* { dg-skip-if "-mthumb given" { *-*-*} { "-mthumb" } } */
+/* { dg-skip-if "-mthumb given" { *-*-* } { "-mthumb" } } */
 /* { dg-options "-marm" } */
-/* { dg-error "target CPU does not support ARM mode" "missing error with -marm on Thumb-only targets" { target *-*-*} 0 } */
+/* { dg-error "target CPU does not support ARM mode" "missing error with -marm on Thumb-only targets" { target *-*-* } 0 } */
 
 /* Check that -marm gives an error when compiling for a Thumb-only target.  */
 
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 0fc0bafa67d8d34ec74ce2d1d7a2323a375615cc..f7511ef3aebca72c798496fb95ce43fcbbc08ed1 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -252,6 +252,20 @@ proc check_runtime {prop args} {
 }]
 }
 
+# Return 1 if GCC was configured with $pattern.
+proc check_configured_with { pattern } {
+global tool
+
+set gcc_output [${tool}_target_compile "-v" "" "none" ""]
+if { [ regexp "Configured with: \[^\n\]*$pattern" $gcc_output ] } {
+verbose "Matched: $pattern" 2
+return 1
+}
+
+verbose "Failed to match: $pattern" 2
+return 0
+}
+
 ###
 # proc check_weak_available { }
 ###
@@ -3797,6 +3811,12 @@ proc add_options_for_arm_arch_v7ve { flags } {
 return "$flags -march=armv7ve"
 }
 
+# Return 1 if GCC was configured with --with-mode=
+proc check_effective_target_default_mode { } {
+
+return [check_configured_with "with-mode="]
+}
+
 # Return 1 if this is an ARM target where

Re: [PATCH] Backport all Filesystem library fixes from trunk

[Jonathan Wakely]

On 12/12/16 14:09 +, Jonathan Wakely wrote:

This syncs the std::experimental::filesystem code on gcc-6-branch to
match what's on trunk, except that the C++17 std::string_view type
doesn't exist on the branch, so the filesystem::path type only
supports experimental::string_view.

I'm doing it as one big patch, rather than backporting 26 individual
patches.


[snip]


Tested x86_64-linux, committed to gcc-6-branch.

I'll backport most of this to gcc-5-branch too, I think the gcc-6
patch should apply cleanly, but I'll need to adjust the tests to not
use { dg-do action { target c++11 } } as that's only on trunk and
gcc-6-branch.


I missed these two fixes for the configure tests for Filesystem.

Committed to gcc-6-branch, will commit to 5 once testing completes.

Somehow I managed to commit a load of duplicate ChangeLog entries in
the commits from r243569 to r243574. Git-svn went crazy. I've cleaned
that up now.


commit 00c16d2d9e7e985ca3d43e19ae78e6613588fa4a
Author: Jonathan Wakely 
Date:   Mon Dec 12 16:46:49 2016 +

Add missing header in Filesystem TS configure tests

Backport from mainline
2016-10-26  Uros Bizjak  

	* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Include 
	for PATH_MAX in realpath test.
	* configure: Regenerate.

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 4b951d8..ce44a6a 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -4343,6 +4343,7 @@ dnl
   AC_CACHE_VAL(glibcxx_cv_realpath, [dnl
 GCC_TRY_COMPILE_OR_LINK(
   [
+   #include 
#include 
#include 
   ],

commit dbe360643e28f6efe2f5d296784fee9eab849b54
Author: redi 
Date:   Wed May 25 16:13:52 2016 +

Fix configure test for sendfile()

	Backport from mainline
	2016-05-25  Jonathan Wakely  

	* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Fix test for sendfile.
	* configure: Regenerate.
	* config.h.in: Regenerate.

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index c453145..4b951d8 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -4433,7 +4433,7 @@ dnl
   gnu* | linux* | solaris*)
 GCC_TRY_COMPILE_OR_LINK(
   [#include ],
-  [sendfile(1, 2, (off_t*)NULL, sizeof 1);],
+  [sendfile(1, 2, (off_t*)0, sizeof 1);],
   [glibcxx_cv_sendfile=yes],
   [glibcxx_cv_sendfile=no])
 ;;
@@ -4443,7 +4443,7 @@ dnl
 esac
   ])
   if test $glibcxx_cv_sendfile = yes; then
-AC_DEFINE(_GLIBCXX_USE_SENDFILE, 1, [Define if sendfile is available in .])
+AC_DEFINE(_GLIBCXX_USE_SENDFILE, 1, [Define if sendfile is available in .])
   fi
   AC_MSG_RESULT($glibcxx_cv_sendfile)
 dnl

Re: [PATCH] handle integer overflow/wrapping in printf directives (PR 78622)

[Jeff Law]

On 12/07/2016 12:17 PM, Martin Sebor wrote:

OK.  So is the hangup really a problem in how the return type is
documented?  I parsed the comment as essentially saying we return true
if the range gets adjusted in any way -- thus a sign change in the first
block would qualify, but we returned false which seemed inconsistent.

Looking at it again, what I think it's saying is we're returning true
only for a subset of adjustments to the range, ie, those cases where the
postcondition does not hold.  Correct?


Correct.  Would changing the description of the return value to
this make it clearer?

   Return true when the range has been adjusted to the full unsigned
   range of DIRTYPE, [0, DIRTYPE_MAX], false otherwise.
Yea, that does help.  I see you've got an updated version posted.  Let 
me take a final (?) looksie now that I have a better understanding of 
the return value.  I think that was the biggest stumbling block on my side.


Jeff

Re: [PATCH] PR 78534 Change character length from int to size_t

[Bob Deen]

> However, this will also affect people doing C->Fortran calls the
> old-fashioned way without ISO_C_BINDING, as they will have to change
> the string length argument from int to size_t in their prototypes.
> Then again, Intel Fortran did this some years ago so I guess at least
> people who care about portability to several compilers are aware.

We do a ton of this (old fashioned c-fortran binding) and changing the string 
length argument size will have a big impact on us.  We don't use the Intel 
compiler so we never noticed a change there.

Is there really a use case for strings > 2 GB that justifies the breakage?  I 
certainly understand wanting to do it "right" but I'm probably not the only one 
with practical considerations that argue against it if there are no compelling 
use cases.

Thanks...

-Bob

Bob Deen @ NASA-JPL Multimission Image Processing Lab
bob.d...@jpl.nasa.gov

[Patch, fortran] PR78737 - [OOP] linking error with deferred, undefined user-defined derived-type I/O

[Paul Richard Thomas]

Dear All,

The original testcase appears here as dtio_19.f90. I gather that some
vendors accept this, while fort does not. IMHO ifort is correct here
since there is no specific DTIO procedure present. However, it could
be that a more helpful error message to the effect that this is an
abstract type and so "do not expect to do DTIO with it" is more
appropriate. If this is desired, I can make it so.

dtio_20.f90 checks that correct code works.

Bootstraps and regtests on FC21/x86_64 - OK for trunk?

Paul

2016-12-12  Paul Thomas  

PR fortran/78737
* interface.c (gfc_compare_interfaces): Whitespace.
(gfc_find_specific_dtio_proc): Return NULL if dtio_sub is an
abstract interface.
* resolve.c (resolve_transfer): Formatting.
(resolve_typebound_procedure): Ditto.

2016-12-12  Paul Thomas  

PR fortran/78737
* gfortran.dg/dtio_19: New test.
* gfortran.dg/dtio_20: New test.
Index: gcc/fortran/interface.c
===
*** gcc/fortran/interface.c (revision 243516)
--- gcc/fortran/interface.c (working copy)
*** gfc_compare_interfaces (gfc_symbol *s1,
*** 1712,1719 
return 0;
  
/* Special case: alternate returns.  If both f1->sym and f2->sym are
!NULL, then the leading formal arguments are alternate returns.  
!The previous conditional should catch argument lists with 
 different number of argument.  */
if (f1 && f1->sym == NULL && f2 && f2->sym == NULL)
return 1;
--- 1712,1719 
return 0;
  
/* Special case: alternate returns.  If both f1->sym and f2->sym are
!NULL, then the leading formal arguments are alternate returns.
!The previous conditional should catch argument lists with
 different number of argument.  */
if (f1 && f1->sym == NULL && f2 && f2->sym == NULL)
return 1;
*** gfc_find_specific_dtio_proc (gfc_symbol
*** 4893,4898 
--- 4893,4901 
dtio_sub = st->n.tb->u.specific->n.sym;
else
dtio_sub = specific_proc->u.specific->n.sym;
+ 
+   if (dtio_sub->attr.abstract && dtio_sub->attr.if_source == IFSRC_IFBODY)
+   return NULL;
  }
  
if (tb_io_st != NULL)
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c   (revision 243517)
--- gcc/fortran/resolve.c   (working copy)
*** resolve_transfer (gfc_code *code)
*** 8982,8993 
  }
  
if (ts->type == BT_CLASS && dtio_sub == NULL)
! {
!   gfc_error ("Data transfer element at %L cannot be polymorphic unless "
! "it is processed by a defined input/output procedure",
! &code->loc);
!   return;
! }
  
if (ts->type == BT_DERIVED)
  {
--- 8982,8990 
  }
  
if (ts->type == BT_CLASS && dtio_sub == NULL)
! gfc_error ("Data transfer element at %L cannot be polymorphic unless "
!  "it is processed by a defined input/output procedure",
!  &code->loc);
  
if (ts->type == BT_DERIVED)
  {
*** resolve_typebound_procedure (gfc_symtree
*** 13002,13009 
  goto error;
}
  
!   if (CLASS_DATA (me_arg)->ts.u.derived
! != resolve_bindings_derived)
{
  gfc_error ("Argument %qs of %qs with PASS(%s) at %L must be of"
 " the derived-type %qs", me_arg->name, proc->name,
--- 12999,13005 
  goto error;
}
  
!   if (CLASS_DATA (me_arg)->ts.u.derived != resolve_bindings_derived)
{
  gfc_error ("Argument %qs of %qs with PASS(%s) at %L must be of"
 " the derived-type %qs", me_arg->name, proc->name,
Index: gcc/testsuite/gfortran.dg/dtio_19.f90
===
*** gcc/testsuite/gfortran.dg/dtio_19.f90   (revision 0)
--- gcc/testsuite/gfortran.dg/dtio_19.f90   (working copy)
***
*** 0 
--- 1,31 
+ ! { dg-do compile }
+ !
+ ! Test the fix for PR78737.
+ !
+ ! Contributed by Damian Rouson  
+ !
+ module object_interface
+   type, abstract :: object
+   contains
+ procedure(write_formatted_interface), deferred ::write_formatted
+ generic :: write(formatted)=>write_formatted
+   end type
+   abstract interface
+ subroutine write_formatted_interface(this,unit,iotype,vlist,iostat,iomsg)
+   import object
+   class(object), intent(in) :: this
+   integer, intent(in) :: unit
+   character (len=*), intent(in) :: iotype
+   integer, intent(in) :: vlist(:)
+   integer, intent(out) :: iostat
+   character (len=*), intent(inout) :: iomsg
+ end subroutine
+   end interface
+ contains
+   subroutine assert(a)
+ class(object):: a
+ write(*,*) a ! { dg-error "cannot be polymorphic" }
+   end subroutine
+ end module
+ 
+ end
Index: gcc/testsuite/gfortran.dg/dtio_20.f90
=

Re: [Patch, Fortran] PR 78392: ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979

[Janus Weil]

2016-12-12 18:37 GMT+01:00 Paul Richard Thomas :
> Hi Janus,
>
> The patch is good - OK for trunk.

Thanks, Paul. Committed as r243580.

Cheers,
Janus



> On 12 December 2016 at 16:52, Janus Weil  wrote:
>> Hi all,
>>
>> I hate to ping this patch once more, but somehow we need to come to a
>> conclusion here.
>>
>> The issue boils down to the fact that there is a piece of code in the
>> gfortran code which claims that specification functions are
>> 'constant', but I doubt that this is true. To my understanding the
>> concept of specification expressions and specification functions (see
>> section 7.1.6 in the F03 standard) was introduced essentially to refer
>> to side-effect-free expressions that can be used e.g. in a
>> type-specification context (array bounds, char-length parameters etc).
>>
>> However I think 'specification functions' do not necessarily need to
>> be 'constants', in the sense that subsequent invocations give always
>> the same (constant) result and their value can be determined at
>> compile time.
>>
>> My patch is at: https://gcc.gnu.org/ml/fortran/2016-11/msg00188.html
>> Further discussion at: https://gcc.gnu.org/ml/fortran/2016-11/msg00243.html
>>
>> Any comments, please!?!
>>
>> Cheers,
>> Janus
>>
>>
>>
>> 2016-12-03 8:05 GMT+01:00 Janus Weil :
>>> double-ping!
>>>
>>>
>>> 2016-11-26 10:45 GMT+01:00 Janus Weil :
 ping!


 2016-11-19 10:12 GMT+01:00 Janus Weil :
> Hi all,
>
>> I previously assumed that the test case for this PR would be legal,
>> but by now I think that's wrong. The test case should be rejected, and
>> we already have checking mechanisms for this (see
>> resolve_fl_variable), but apparently they are not working.
>>
>> My current suspicion is that 'gfc_is_constant_expr' has a bug, because
>> it claims the call to the function 'get_i' to be a constant
>> expression. This is not true, because get_i() can not be reduced to a
>> compile-time constant.
>
> some more reading in the standard confirms this suspicion: In
> gfc_is_constant_expr there is a piece of code which claims that
> specification functions are constant. That is certainly not true, and
> so what I'm doing in the attached fix is to remove that code and add
> some references to the standard to make things clearer.
>
> The code that I'm removing has last been touched in this commit by
> Jerry six years ago:
>
> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=166520
>
> However, this did not introduce the bug in the first place (not sure
> when that happened).
>
> In any case the new patch in the attachment regtests cleanly and
> correctly rejects the original test case as well as one of the cases
> mentioned by Dominique. Ok for trunk?
>
> Cheers,
> Janus
>
>
>
> 2016-11-19  Janus Weil  
>
> PR fortran/78392
> * expr.c (gfc_is_constant_expr): Specification functions are not
> compile-time constants. Update documentation (add reference to F08
> standard), add a FIXME.
> (external_spec_function): Add reference to F08 standard.
> * resolve.c (resolve_fl_variable): Ditto.
>
> 2016-11-19  Janus Weil  
>
> PR fortran/78392
> * gfortran.dg/constant_shape.f90: New test case.
>
>
>
> --
> If you're walking down the right path and you're willing to keep
> walking, eventually you'll make progress.
>
> Barack Obama

[PATCH] Use arclinux_nps linker emulation for nps400

[Graham Markall]

This proposed binutils patch adds an arclinux_nps linker emulation:

https://sourceware.org/ml/binutils/2016-12/msg00172.html

The arclinux_nps emulation provides some additional symbols in the
linker script, which are specific to the Mellanox NPS-400. The patch in
this message modifies the arc LINK_SPEC so that when mcpu=nps400, the
arclinux_nps emulation is used by default.

The indentation of LINK_SPEC also seemed to be out of keeping with the
indentation in the rest of arc.h, so it is modified in this patch.

This is my first contribution to GCC, but I believe Embecosm has a
copyright assignment on file. As I don't have write access to GCC, if
this patch is approved, could someone apply it please (once the
corresponding binutils patch is approved and applied)?


Many thanks,
Graham Markall.


2016-12-12  Graham Markall  

* config/arc/arc.h (LINK_SPEC): Use arclinux_nps emulation when
mcpu=nps400.

---
 gcc/ChangeLog|  5 +
 gcc/config/arc/arc.h | 21 +++--
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/gcc/config/arc/arc.h b/gcc/config/arc/arc.h
index f9512c4..188249a 100644
--- a/gcc/config/arc/arc.h
+++ b/gcc/config/arc/arc.h
@@ -114,16 +114,17 @@ extern const char *arc_cpu_to_as (int argc, const char 
**argv);
 /* Note that the default is to link against dynamic libraries, if they are
available.  Override with -static.  */
 #define LINK_SPEC "%{h*} \
-  %{static:-Bstatic} \
-  %{symbolic:-Bsymbolic} \
-  %{rdynamic:-export-dynamic}\
-  -dynamic-linker /lib/ld-uClibc.so.0 \
-  -X %{mbig-endian:-EB} \
-  %{EB} %{EL} \
-  %{marclinux*} \
-  %{!marclinux*: %{pg|p|profile:-marclinux_prof;: -marclinux}} 
\
-  %{!z:-z max-page-size=0x2000 -z common-page-size=0x2000} \
-  %{shared:-shared}"
+   %{static:-Bstatic} \
+   %{symbolic:-Bsymbolic} \
+   %{rdynamic:-export-dynamic}\
+   -dynamic-linker /lib/ld-uClibc.so.0 \
+   -X %{mbig-endian:-EB} \
+   %{EB} %{EL} \
+   %{marclinux*} \
+   %{!marclinux*: %{pg|p|profile:-marclinux_prof; mcpu=nps400:-marclinux_nps; \
+   :-marclinux}} \
+   %{!z:-z max-page-size=0x2000 -z common-page-size=0x2000} \
+   %{shared:-shared}"
 #else
 #define LINK_SPEC "%{mbig-endian:-EB} %{EB} %{EL}\
   %{pg|p:-marcelf_prof;mA7|mARC700|mcpu=arc700|mcpu=ARC700: -marcelf}"
-- 
2.7.4

[C++ PATCH] c++/78776 fix alias template ICE

[Nathan Sidwell]

This patch fixes an ICE in a checking build where structural_comptypes 
disagrees with TYPE_CANONICAL.


An (implicit) template alias has a different TYPE_TI_TEMPLATE to the 
thing its aliasing.  That make structural comparison think it's 
different.  In the testcase we end up thinking 'Loc' refers to a 
different template than 'Traits'


Solved by breaking TYPE_TEMPLATE_INFO into an underlying helper that 
doesn't deal with type aliases.  While there, I noticed 
TYPE_TEMPLATE_INFO was doing more work than necessary because it checked 
twice whether DECL_LANG_SPECIFIC (TYPE_NAME (NODE)) was non-null. 
There's no need to check it again in the branch we can only get to when 
it's non-null.  I also removed some unnecessary parens.


ok?

nathan
--
Nathan Sidwell
2016-12-12  Nathan Sidwell  

	PR c++/78776
	* cp-tree.h (TYPE_TEMPLATE_INFO_RAW): New, broken out of ...
	(TYPE_TEMPLATE_INFO): ... here. Use it.
	* typeck.c (structural_comptypes): Adjust record/union check to
	avoid alias template confusion.

	PR c++/78776
	* g++.dg/cpp0x/pr78776.C: New.

Index: cp/cp-tree.h
===
--- cp/cp-tree.h	(revision 243554)
+++ cp/cp-tree.h	(working copy)
@@ -3038,22 +3038,25 @@ extern void decl_shadowed_for_var_insert
->template_info)
 
 /* Template information for an ENUMERAL_, RECORD_, UNION_TYPE, or
-   BOUND_TEMPLATE_TEMPLATE_PARM type.  Note that if NODE is a
-   specialization of an alias template, this accessor returns the
-   template info for the alias template, not the one (if any) for the
-   template of the underlying type.  */
+   BOUND_TEMPLATE_TEMPLATE_PARM type.  This ignores any alias
+   templateness of NODE.  */
+
+#define TYPE_TEMPLATE_INFO_RAW(NODE)	\
+  (TREE_CODE (NODE) == ENUMERAL_TYPE	\
+   ? ENUM_TEMPLATE_INFO (NODE)		\
+   : (TREE_CODE (NODE) == BOUND_TEMPLATE_TEMPLATE_PARM			\
+  ? TEMPLATE_TEMPLATE_PARM_TEMPLATE_INFO (NODE)			\
+  : (CLASS_TYPE_P (NODE)		\
+	 ? CLASSTYPE_TEMPLATE_INFO (NODE)\
+	 : NULL_TREE)))
+
+/* If NODE is a specialization of an alias template, this accessor
+   returns the template info for the alias template.  Otherwise behave
+   as TYPE_TEMPLATE_INFO_RAW.  */
 #define TYPE_TEMPLATE_INFO(NODE)	\
-  ((TYPE_ALIAS_P (NODE) && DECL_LANG_SPECIFIC (TYPE_NAME (NODE)))	\
-   ? (DECL_LANG_SPECIFIC (TYPE_NAME (NODE))\
-  ? DECL_TEMPLATE_INFO (TYPE_NAME (NODE))\
-  : NULL_TREE)			\
-   : ((TREE_CODE (NODE) == ENUMERAL_TYPE)\
-  ? ENUM_TEMPLATE_INFO (NODE)	\
-  : ((TREE_CODE (NODE) == BOUND_TEMPLATE_TEMPLATE_PARM)		\
-	 ? TEMPLATE_TEMPLATE_PARM_TEMPLATE_INFO (NODE)			\
-	 : (CLASS_TYPE_P (NODE)		\
-	? CLASSTYPE_TEMPLATE_INFO (NODE)\
-	: NULL_TREE
+  (TYPE_ALIAS_P (NODE) && DECL_LANG_SPECIFIC (TYPE_NAME (NODE))		\
+   ? DECL_TEMPLATE_INFO (TYPE_NAME (NODE))\
+   : TYPE_TEMPLATE_INFO_RAW (NODE))
 
 
 /* Set the template information for an ENUMERAL_, RECORD_, or
Index: cp/typeck.c
===
--- cp/typeck.c	(revision 243554)
+++ cp/typeck.c	(working copy)
@@ -1284,18 +1284,23 @@ structural_comptypes (tree t1, tree t2,
 
 case RECORD_TYPE:
 case UNION_TYPE:
-  if (TYPE_TEMPLATE_INFO (t1) && TYPE_TEMPLATE_INFO (t2)
-	  && (TYPE_TI_TEMPLATE (t1) == TYPE_TI_TEMPLATE (t2)
-	  || TREE_CODE (t1) == BOUND_TEMPLATE_TEMPLATE_PARM)
-	  && comp_template_args (TYPE_TI_ARGS (t1), TYPE_TI_ARGS (t2)))
-	break;
+  {
+	/* Ignore any alias templateness.  */
+	tree ti1 = TYPE_TEMPLATE_INFO_RAW (t1);
+	tree ti2 = TYPE_TEMPLATE_INFO_RAW (t2);
 
-  if ((strict & COMPARE_BASE) && DERIVED_FROM_P (t1, t2))
-	break;
-  else if ((strict & COMPARE_DERIVED) && DERIVED_FROM_P (t2, t1))
-	break;
+	if (ti1 && ti2
+	&& (TI_TEMPLATE (ti1) == TI_TEMPLATE (ti2)
+		|| TREE_CODE (t1) == BOUND_TEMPLATE_TEMPLATE_PARM)
+	&& comp_template_args (TI_ARGS (ti1), TI_ARGS (ti2)))
+	  break;
+	if ((strict & COMPARE_BASE) && DERIVED_FROM_P (t1, t2))
+	  break;
+	else if ((strict & COMPARE_DERIVED) && DERIVED_FROM_P (t2, t1))
+	  break;
 
-  return false;
+	return false;
+  }
 
 case OFFSET_TYPE:
   if (!comptypes (TYPE_OFFSET_BASETYPE (t1), TYPE_OFFSET_BASETYPE (t2),
Index: testsuite/g++.dg/cpp0x/pr78776.C
===
--- testsuite/g++.dg/cpp0x/pr78776.C	(revision 0)
+++ testsuite/g++.dg/cpp0x/pr78776.C	(working copy)
@@ -0,0 +1,15 @@
+// PR c++/78776
+// { dg-do compile { target c++11 } }
+
+// ICE with canonical type verification
+
+template  struct Traits;
+
+template 
+struct Bob {
+  using Loc = Traits;
+  using typename Loc::Thing;
+
+  Thing Foo (); 
+};
+

[PATCH] Fix opt-functions.awk in POSIXLY_CORRECT mode (PR other/78766)

[Jakub Jelinek]

Hi!

{ is a special character in ERE, so gawk rightfully complains in
POSIXLY_CORRECT mode.  The regex is meant to look for { at the beginning
of line.  Neither "^\{" nor "^\\{" works though, but "^[{]" does.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2016-12-12  Jakub Jelinek  

PR other/78766
* opt-functions.awk (opt_args): Use [{] instead of { in regexps.

--- gcc/opt-functions.awk.jj2016-01-04 14:55:50.0 +0100
+++ gcc/opt-functions.awk   2016-12-12 09:38:02.229155459 +0100
@@ -61,10 +61,10 @@ function opt_args(name, flags)
if (flags !~ " " name "\\(")
return ""
sub(".* " name "\\(", "", flags)
-   if (flags ~ "^{")
+   if (flags ~ "^[{]")
{
-   sub ("^{", "", flags)
-   sub("}\\).*", "", flags)
+   sub ("^[{]", "", flags)
+   sub ("}\\).*", "", flags)
}
else
sub("\\).*", "", flags)

Jakub

[PATCH] Fix ipa-pure-const.c bug (PR ipa/77905)

[Jakub Jelinek]

Hi!

The local pure const pass notices the static ctor is looping const,
so sets TREE_READONLY and DECL_LOOPING_CONST_OR_PURE_P and does not
clear DECL_STATIC_CONSTRUCTOR bit because it is looping.
Then the ipa pure const pass notices the static ctor is non-looping const,
clears DECL_LOOPING_CONST_OR_PURE_P and DECL_STATIC_CONSTRUCTOR bit,
but because it has been TREE_READONLY already, it doesn't set
TODO_remove_functions from the pass and ipa-comdat pass assumes that
unreachable cgraph nodes have been pruned.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2016-12-12  Jakub Jelinek  

PR ipa/77905
* ipa-pure-const.c (cdtor_p): Return true for
DECL_STATIC_{CON,DE}STRUCTOR even when it is
DECL_LOOPING_CONST_OR_PURE_P.

* g++.dg/ipa/pr77905.C: New test.

--- gcc/ipa-pure-const.c.jj 2016-09-02 19:09:33.0 +0200
+++ gcc/ipa-pure-const.c2016-12-12 11:51:24.808518093 +0100
@@ -1195,7 +1195,8 @@ static bool
 cdtor_p (cgraph_node *n, void *)
 {
   if (DECL_STATIC_CONSTRUCTOR (n->decl) || DECL_STATIC_DESTRUCTOR (n->decl))
-return !TREE_READONLY (n->decl) && !DECL_PURE_P (n->decl);
+return ((!TREE_READONLY (n->decl) && !DECL_PURE_P (n->decl))
+   || DECL_LOOPING_CONST_OR_PURE_P (n->decl));
   return false;
 }
 
--- gcc/testsuite/g++.dg/ipa/pr77905.C.jj   2016-12-12 11:53:42.645770248 
+0100
+++ gcc/testsuite/g++.dg/ipa/pr77905.C  2016-12-12 11:53:35.0 +0100
@@ -0,0 +1,21 @@
+// PR ipa/77905
+// { dg-do compile }
+// { dg-options "-O2" }
+
+struct A {
+  A(int);
+};
+struct B : A {
+  B();
+} A;
+struct C : virtual A {
+  C(int);
+};
+A::A(int x) {
+  if (x)
+A(0);
+}
+
+B::B() : A(1) {}
+
+C::C(int) : A(1) {}

Jakub

RE: [PATCH] Use arclinux_nps linker emulation for nps400

[Claudiu Zissulescu]

It looks sane to me, please apply (ask Andrew to do it for you)

//Claudiu

From: Graham Markall [graham.mark...@embecosm.com]
Sent: Monday, December 12, 2016 8:11 PM
To: gcc-patches@gcc.gnu.org
Cc: claudiu.zissule...@synopsys.com; andrew.burg...@embecosm.com; Graham Markall
Subject: [PATCH] Use arclinux_nps linker emulation for nps400

This proposed binutils patch adds an arclinux_nps linker emulation:

https://sourceware.org/ml/binutils/2016-12/msg00172.html

The arclinux_nps emulation provides some additional symbols in the
linker script, which are specific to the Mellanox NPS-400. The patch in
this message modifies the arc LINK_SPEC so that when mcpu=nps400, the
arclinux_nps emulation is used by default.

The indentation of LINK_SPEC also seemed to be out of keeping with the
indentation in the rest of arc.h, so it is modified in this patch.

This is my first contribution to GCC, but I believe Embecosm has a
copyright assignment on file. As I don't have write access to GCC, if
this patch is approved, could someone apply it please (once the
corresponding binutils patch is approved and applied)?


Many thanks,
Graham Markall.


2016-12-12  Graham Markall  

* config/arc/arc.h (LINK_SPEC): Use arclinux_nps emulation when
mcpu=nps400.

---
 gcc/ChangeLog|  5 +
 gcc/config/arc/arc.h | 21 +++--
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/gcc/config/arc/arc.h b/gcc/config/arc/arc.h
index f9512c4..188249a 100644
--- a/gcc/config/arc/arc.h
+++ b/gcc/config/arc/arc.h
@@ -114,16 +114,17 @@ extern const char *arc_cpu_to_as (int argc, const char 
**argv);
 /* Note that the default is to link against dynamic libraries, if they are
available.  Override with -static.  */
 #define LINK_SPEC "%{h*} \
-  %{static:-Bstatic} \
-  %{symbolic:-Bsymbolic} \
-  %{rdynamic:-export-dynamic}\
-  -dynamic-linker /lib/ld-uClibc.so.0 \
-  -X %{mbig-endian:-EB} \
-  %{EB} %{EL} \
-  %{marclinux*} \
-  %{!marclinux*: %{pg|p|profile:-marclinux_prof;: -marclinux}} 
\
-  %{!z:-z max-page-size=0x2000 -z common-page-size=0x2000} \
-  %{shared:-shared}"
+   %{static:-Bstatic} \
+   %{symbolic:-Bsymbolic} \
+   %{rdynamic:-export-dynamic}\
+   -dynamic-linker /lib/ld-uClibc.so.0 \
+   -X %{mbig-endian:-EB} \
+   %{EB} %{EL} \
+   %{marclinux*} \
+   %{!marclinux*: %{pg|p|profile:-marclinux_prof; mcpu=nps400:-marclinux_nps; \
+   :-marclinux}} \
+   %{!z:-z max-page-size=0x2000 -z common-page-size=0x2000} \
+   %{shared:-shared}"
 #else
 #define LINK_SPEC "%{mbig-endian:-EB} %{EB} %{EL}\
   %{pg|p:-marcelf_prof;mA7|mARC700|mcpu=arc700|mcpu=ARC700: -marcelf}"
--
2.7.4

[PATCH] Fix gimple slsr throwing call handling (PR tree-optimization/78777)

[Jakub Jelinek]

Hi!

The strength reduction has code to emit stuff before or after the last insn
in a bb, but uses a wrong predicate to decide where to put it, is_ctrl_stmt
covers only a subset of statements that must end a bb.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2016-12-12  Jakub Jelinek  

PR tree-optimization/78777
* gimple-ssa-strength-reduction.c (create_add_on_incoming_edge,
insert_initializers): Use stmt_ends_bb_p instead of is_ctrl_stmt.

* g++.dg/torture/pr78777.C: New test.

--- gcc/gimple-ssa-strength-reduction.c.jj  2016-12-06 10:16:39.0 
+0100
+++ gcc/gimple-ssa-strength-reduction.c 2016-12-12 16:50:24.729489536 +0100
@@ -2253,7 +2253,7 @@ create_add_on_incoming_edge (slsr_cand_t
   insert_bb = single_succ_p (e->src) ? e->src : split_edge (e);
   gsi = gsi_last_bb (insert_bb);
 
-  if (!gsi_end_p (gsi) && is_ctrl_stmt (gsi_stmt (gsi)))
+  if (!gsi_end_p (gsi) && stmt_ends_bb_p (gsi_stmt (gsi)))
 {
   gsi_insert_before (&gsi, new_stmt, GSI_SAME_STMT);
   if (cast_stmt)
@@ -3243,7 +3243,7 @@ insert_initializers (slsr_cand_t c)
  gimple *basis_stmt = lookup_cand (c->basis)->cand_stmt;
  location_t loc = gimple_location (basis_stmt);
 
- if (!gsi_end_p (gsi) && is_ctrl_stmt (gsi_stmt (gsi)))
+ if (!gsi_end_p (gsi) && stmt_ends_bb_p (gsi_stmt (gsi)))
{
  if (cast_stmt)
{
--- gcc/testsuite/g++.dg/torture/pr78777.C.jj   2016-12-12 17:21:00.864314692 
+0100
+++ gcc/testsuite/g++.dg/torture/pr78777.C  2016-12-12 17:20:35.0 
+0100
@@ -0,0 +1,29 @@
+// PR tree-optimization/78777
+
+void bar (char);
+struct C { char b; };
+struct H { char d[5]; int e; C *f[4]; int g[10]; };
+void baz (C *, unsigned char *, int);
+unsigned char j[10];
+
+void
+foo (H *o, int p, unsigned char *q, int r, char n, H *b)
+{
+  for (int m = 0; m < o->e; m++)
+{
+  if (o->f[m] || o->g[m])
+   continue;
+  try
+   {
+ baz (o->f[m], j, 5);
+ if (p)
+   baz (o->f[m], q, r);
+   }
+  catch (int)
+   {
+ C a = *o->f[m];
+ if (b)
+   bar (n & a.b);
+   }
+}
+}

Jakub

[PATCH] Avoid creating unbounded complexity debug insns in valtrack (PR debug/77844)

[Jakub Jelinek]

Hi!

On the following testcase (where I've failed to reduce it without the
header, got to over 70KB with both delta and creduce) we end up with huge
RTL expressions in debug insns that just slow down combiner as well as
var-tracking etc. too much.
Generally, at GIMPLE level we try to keep the debug stmts using debug
temporaries very simple, then during expansion we have a function that uses
debug temporaries in case TER creates larger expressions, and finally during
var-tracking we also punt on too large expressions.  But valtrack APIs,
used e.g. by the combiner, when substituting lots of pseudos for expressions
that e.g. contain each two other pseudos, is able to create many KB sized
expressions.

The following patch just throws away expressions that have 32 register
references in there, I think that is so huge that it will be really very
unlikely to be beneficial in the debug info and var-tracking would likely
throw it away anyway.  Or shall I use some --param instead of the constant
(any suggestions on how to call it)?  Another option (with or without param)
is to create debug temporaries in those cases and split the expression into
smaller expressions.  Not sure if it is worth it though.

Bootstrapped/regtested on x86_64-linux and i686-linux.

2016-12-12  Jakub Jelinek  

PR debug/77844
* valtrack.c: Include rtl-iter.h.
(propagate_for_debug): Reset debug insns which after simplification
contain more than 32 regs.

* g++.dg/opt/pr77844.C: New test.

--- gcc/valtrack.c.jj   2016-12-02 16:41:05.0 +0100
+++ gcc/valtrack.c  2016-12-12 15:12:39.637451127 +0100
@@ -29,6 +29,7 @@ along with GCC; see the file COPYING3.
 #include "regs.h"
 #include "memmodel.h"
 #include "emit-rtl.h"
+#include "rtl-iter.h"
 
 /* gen_lowpart_no_emit hook implementation for DEBUG_INSNs.  In DEBUG_INSNs,
all lowpart SUBREGs are valid, despite what the machine requires for
@@ -197,6 +198,16 @@ propagate_for_debug (rtx_insn *insn, rtx
 dest, propagate_for_debug_subst, &p);
  if (loc == INSN_VAR_LOCATION_LOC (insn))
continue;
+ /* Avoid propagation from growing DEBUG_INSN expressions
+too much.  */
+ int cnt = 0;
+ subrtx_iterator::array_type array;
+ FOR_EACH_SUBRTX (iter, array, loc, ALL)
+   if (REG_P (*iter) && ++cnt > 32)
+ {
+   loc = gen_rtx_UNKNOWN_VAR_LOC ();
+   break;
+ }
  INSN_VAR_LOCATION_LOC (insn) = loc;
  df_insn_rescan (insn);
}
--- gcc/testsuite/g++.dg/opt/pr77844.C.jj   2016-12-12 17:28:25.146711803 
+0100
+++ gcc/testsuite/g++.dg/opt/pr77844.C  2016-12-12 17:27:43.0 +0100
@@ -0,0 +1,32 @@
+// PR debug/77844
+// { dg-do compile }
+// { dg-options "-O3 -g" }
+
+#include 
+
+void
+foo (std::vector& v, int i, int j)
+{
+  for (int k = 0; k < 5; ++k)
+v[5 * i + k] = v[5 * i + k] | v[5 * j + k];
+}
+
+void
+bar (std::vector& v, int i, int j)
+{
+  for (int k = 0; k < 5; ++k)
+v[5 * i + k] = v[5 * i + k] ^ v[5 * j + k];
+}
+
+void
+baz (std::vector& v)
+{
+  foo (v, 4, 1);
+  foo (v, 4, 2);
+  foo (v, 4, 3);
+  foo (v, 4, 4);
+  bar (v, 4, 1);
+  bar (v, 4, 2);
+  bar (v, 4, 3);
+  bar (v, 4, 4);
+}

Jakub

Re: [PATCH] PR 78534 Change character length from int to size_t

[Janne Blomqvist]

On Mon, Dec 12, 2016 at 7:39 PM, Andre Vehreschild  wrote:
> Hi Janne,
>
> I found that you are favoring build_int_cst (size_type_node, 0) over
> size_zero_node. Is there a reason to this?

Yes. AFAIU size_zero_node is a zero constant for sizetype which is not
the same as size_type_node.

AFAIK the difference is that size_type_node is the C size_t type,
whereas sizetype is a GCC internal type used for address expressions.
On a "normal" target I understand that they are the same size, but
there are some slight differences in semantics, e.g. size_type_node
like C unsigned integer types is defined to wrap around on overflow
whereas sizetype is undefined on overflow.

I don't know if GCC supports some strange targets with some kind of
segmented memory where the size of sizetype would be different from
size_type_node, but I guess it's possible in theory at least.

That being said, now that you mention in I should be using
build_zero_cst (some_type_node) instead of
build_int_cst(some_type_node, 0). There's also build_one_cst that I
should use.

> Furthermore did I have to patch this:
>
> diff --git a/gcc/fortran/dump-parse-tree.c b/gcc/fortran/dump-parse-tree.c
> index 585f25d..f374558 100644
> --- a/gcc/fortran/dump-parse-tree.c
> +++ b/gcc/fortran/dump-parse-tree.c
> @@ -465,7 +465,7 @@ show_expr (gfc_expr *p)
>   break;
>
> case BT_HOLLERITH:
> - fprintf (dumpfile, "%dH", p->representation.length);
> + fprintf (dumpfile, "%zdH", p->representation.length);
>   c = p->representation.string;
>   for (i = 0; i < p->representation.length; i++, c++)
> {
>
> to bootstrap on x86_64-linux/f23.

Ah, thanks for the catch. I'll fix it by using HOST_WIDE_INT_PRINT_DEC
since I'll have to change gfc_charlen_t to be a typedef form
HOST_WIDE_INT (see my answer to FX).

> And I have this regression:
>
> FAIL: gfortran.dg/allocate_deferred_char_scalar_1.f03   -O1  (test for excess
> errors)
>
> allocate_deferred_char_scalar_1.f03:184:0:
>
>  p = '12345679'
>
> Warning: '__builtin_memcpy' writing 8 bytes into a region of size 5 overflows
>  the destination [-Wstringop-overflow=]
>  allocate_deferred_char_scalar_1.f03:242:0:
>
>  p = 4_'12345679'
>
> Warning: '__builtin_memcpy' writing 32 bytes into a region of size 20 
> overflows
> the destination [-Wstringop-overflow=]

I'm seeing that too, but I assumed they would be fixed by Paul's
recent patch which I don't yet have in my tree yet due to the git
mirror being stuck..

> Btw, the patch for changing the ABI of the coarray-libs is already nearly 
> done.
> I just need to figure that what the state of regressions is with and without 
> my
> change.

Thanks.

I'll produce an updated patch with the changes discussed so far.


-- 
Janne Blomqvist

Re: [Patch, fortran] PR78737 - [OOP] linking error with deferred, undefined user-defined derived-type I/O

[Janus Weil]

Hi Paul,

> The original testcase appears here as dtio_19.f90. I gather that some
> vendors accept this, while fort does not. IMHO ifort is correct here
> since there is no specific DTIO procedure present.

to be honest, I kind of disagree with ifort here (wouldn't be the
first time ;) ...

dtio_19.f90 looks like perfectly valid Fortran 2003 code to me. You
are right that there is no specific DTIO in the module at hand, but
certainly any variable that you could possibly pass to the 'assert'
routine must be a non-abstract extension of the abstract basetype
'object' and therefore must implement the deferred TBP
'write_formatted' that acts as a DTIO output procedure. So, at worst
the test case is incomplete, but not invalid IMHO. In ifort's view of
things, would the invalidity at least disappear if one adds another
module which implements an extended type (similar to what you do in
the second test case, but using two separate modules)?

Moreover I think your patch still mishandles my example in comment 18.

As commented several times in bugzilla, my feeling is that the
solution for this PR would be to utilize the vtable machinery, in
order to generate a truly polymorphic call to the DTIO procedure.
However, it might well be that I'm missing some central point of DTIO
which forbids this or makes it unnecessary. In that case I hope that
you can enlighten me :)

Cheers,
Janus



> 2016-12-12  Paul Thomas  
>
> PR fortran/78737
> * interface.c (gfc_compare_interfaces): Whitespace.
> (gfc_find_specific_dtio_proc): Return NULL if dtio_sub is an
> abstract interface.
> * resolve.c (resolve_transfer): Formatting.
> (resolve_typebound_procedure): Ditto.
>
> 2016-12-12  Paul Thomas  
>
> PR fortran/78737
> * gfortran.dg/dtio_19: New test.
> * gfortran.dg/dtio_20: New test.

Re: [PATCH] PR 78534 Change character length from int to size_t

[Andre Vehreschild]

Hi Janne,

How about adding charlen_zero_node and one_node like the others have it to 
prevent repeating ourselves?

- Andre

Am 12. Dezember 2016 20:39:38 MEZ, schrieb Janne Blomqvist 
:
>On Mon, Dec 12, 2016 at 7:39 PM, Andre Vehreschild 
>wrote:
>> Hi Janne,
>>
>> I found that you are favoring build_int_cst (size_type_node, 0) over
>> size_zero_node. Is there a reason to this?
>
>Yes. AFAIU size_zero_node is a zero constant for sizetype which is not
>the same as size_type_node.
>
>AFAIK the difference is that size_type_node is the C size_t type,
>whereas sizetype is a GCC internal type used for address expressions.
>On a "normal" target I understand that they are the same size, but
>there are some slight differences in semantics, e.g. size_type_node
>like C unsigned integer types is defined to wrap around on overflow
>whereas sizetype is undefined on overflow.
>
>I don't know if GCC supports some strange targets with some kind of
>segmented memory where the size of sizetype would be different from
>size_type_node, but I guess it's possible in theory at least.
>
>That being said, now that you mention in I should be using
>build_zero_cst (some_type_node) instead of
>build_int_cst(some_type_node, 0). There's also build_one_cst that I
>should use.
>
>> Furthermore did I have to patch this:
>>
>> diff --git a/gcc/fortran/dump-parse-tree.c
>b/gcc/fortran/dump-parse-tree.c
>> index 585f25d..f374558 100644
>> --- a/gcc/fortran/dump-parse-tree.c
>> +++ b/gcc/fortran/dump-parse-tree.c
>> @@ -465,7 +465,7 @@ show_expr (gfc_expr *p)
>>   break;
>>
>> case BT_HOLLERITH:
>> - fprintf (dumpfile, "%dH", p->representation.length);
>> + fprintf (dumpfile, "%zdH", p->representation.length);
>>   c = p->representation.string;
>>   for (i = 0; i < p->representation.length; i++, c++)
>> {
>>
>> to bootstrap on x86_64-linux/f23.
>
>Ah, thanks for the catch. I'll fix it by using HOST_WIDE_INT_PRINT_DEC
>since I'll have to change gfc_charlen_t to be a typedef form
>HOST_WIDE_INT (see my answer to FX).
>
>> And I have this regression:
>>
>> FAIL: gfortran.dg/allocate_deferred_char_scalar_1.f03   -O1  (test
>for excess
>> errors)
>>
>> allocate_deferred_char_scalar_1.f03:184:0:
>>
>>  p = '12345679'
>>
>> Warning: '__builtin_memcpy' writing 8 bytes into a region of size 5
>overflows
>>  the destination [-Wstringop-overflow=]
>>  allocate_deferred_char_scalar_1.f03:242:0:
>>
>>  p = 4_'12345679'
>>
>> Warning: '__builtin_memcpy' writing 32 bytes into a region of size 20
>overflows
>> the destination [-Wstringop-overflow=]
>
>I'm seeing that too, but I assumed they would be fixed by Paul's
>recent patch which I don't yet have in my tree yet due to the git
>mirror being stuck..
>
>> Btw, the patch for changing the ABI of the coarray-libs is already
>nearly done.
>> I just need to figure that what the state of regressions is with and
>without my
>> change.
>
>Thanks.
>
>I'll produce an updated patch with the changes discussed so far.

-- 
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 241 929 10 18 * ve...@gmx.de

Re: [PATCH] handle integer overflow/wrapping in printf directives (PR 78622)

[Jeff Law]

On 12/11/2016 05:21 PM, Martin Sebor wrote:

So I think the return value needs a bit of clarification here.  Take
guidance from our discussion on this thread.

OK with that fixed.

jeff


The "strange test failures​" that I wrote about in a separate thread
late last week prompted me to re-review the patch and add more test
cases.  Those in turn exposed a bug in the adjust_range_for_overflow
function involving types of the same precision but different sign
where converting an unsigned range with an upper bound in excess of
the directive's TYPE_MAX would incorrectly accept the converted range
even though the new upper bound was less than the lower bound.

The updated  patch corrects this oversight.  In addition, it adjusts
the handling of the obscure corner case of zero precision and zero
argument which results in zero bytes (except in some even more
obscure cases involving some flags for some conversions).  For
instance:

  printf ("%.0i", 0);

results in zero bytes, but

  printf ("%+.0i", 0);

results in 1 byte (and prints '+').  This is tracked in bug 78606.

Although the differences between the approved patch and the update
are very small I repost it in case one of you would like to double
check them.  If not I'll commit the updated patch later in the week.

Martin

gcc-78622.diff


PR middle-end/78622 - -Wformat-length/-fprintf-return-value incorrect with 
overflow/wrapping
PR middle-end78606 - -Wformat-length/-fprintf-return-value incorrect for %+.0i 
and %.0o with zero value

gcc/ChangeLog:

PR middle-end/78622
* gimple-ssa-sprintf.c (min_bytes_remaining): Use res.knownrange
rather than res.bounded.
(get_width_and_precision): Set precision to -1 when negative.
(adjust_range_for_overflow): New function.
(format_integer): Correct the handling of the space, plus, and pound
flags, and the special case of zero precision.
Always set res.bounded to true unless either precision or width
is specified and unknown.
Call adjust_range_for_overflow.
Avoid use zero as the shortest value when precision is specified
but unknown.
(format_directive): Remove vestigial quoting.  Always inform of
argument value or range when it's available.
(add_bytes): Correct the computation of boundrange used to
decide whether a warning is of a "maybe" or "defnitely" kind.

gcc/testsuite/ChangeLog:

PR middle-end/78622
* gcc.c-torture/execute/pr78622.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-2.c: Remove "benign" undefined
behavior inadvertently introduced in a previous commit.  Tighten
up final checking.
* gcc.dg/tree-ssa/builtin-sprintf-5.c: Rename macros for clarity.
Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-6.c: Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-2.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-5.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-6.c: Remove xfails and
add a final optimization check.
* gcc.dg/tree-ssa/builtin-sprintf.c: Add test cases.
* gcc.dg/tree-ssa/pr78622.c: New test.


OK.

jeff

Re: [PATCH] Use arclinux_nps linker emulation for nps400

[Graham Markall]

Hi Claudiu,

On 12/12/16 19:18, Claudiu Zissulescu wrote:
> It looks sane to me, please apply (ask Andrew to do it for you)
> 
> //Claudiu

Many thanks for the quick review. I'll ask Andrew to do it once the
binutils patch is approved and applied.


Best regards,
Graham.



signature.asc
Description: OpenPGP digital signature

[PATCH] Trivial cleanup for tree-data-ref.c

[Marek Polacek]

At least these should be HOST_WIDE_INTs rather than ints.  There might be
more opportunities than this.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2016-12-12  Marek Polacek  

* tree-data-ref.c (compute_overlap_steps_for_affine_univar): Change
parameters' type from int to HOST_WIDE_INT.
(compute_overlap_steps_for_affine_1_2): Change parameters' type from
int to HOST_WIDE_INT.
(build_classic_dist_vector_1): Likewise.
(add_multivariate_self_dist): Likewise.

diff --git gcc/tree-data-ref.c gcc/tree-data-ref.c
index 8152da3..d4e4866 100644
--- gcc/tree-data-ref.c
+++ gcc/tree-data-ref.c
@@ -2166,7 +2166,9 @@ initialize_matrix_A (lambda_matrix A, tree chrec, 
unsigned index, int mult)
constructed as evolutions in dimension DIM.  */
 
 static void
-compute_overlap_steps_for_affine_univar (int niter, int step_a, int step_b,
+compute_overlap_steps_for_affine_univar (HOST_WIDE_INT niter,
+HOST_WIDE_INT step_a,
+HOST_WIDE_INT step_b,
 affine_fn *overlaps_a,
 affine_fn *overlaps_b,
 tree *last_conflicts, int dim)
@@ -2174,8 +2176,8 @@ compute_overlap_steps_for_affine_univar (int niter, int 
step_a, int step_b,
   if (((step_a > 0 && step_b > 0)
|| (step_a < 0 && step_b < 0)))
 {
-  int step_overlaps_a, step_overlaps_b;
-  int gcd_steps_a_b, last_conflict, tau2;
+  HOST_WIDE_INT step_overlaps_a, step_overlaps_b;
+  HOST_WIDE_INT gcd_steps_a_b, last_conflict, tau2;
 
   gcd_steps_a_b = gcd (step_a, step_b);
   step_overlaps_a = step_b / gcd_steps_a_b;
@@ -2229,7 +2231,7 @@ compute_overlap_steps_for_affine_1_2 (tree chrec_a, tree 
chrec_b,
  tree *last_conflicts)
 {
   bool xz_p, yz_p, xyz_p;
-  int step_x, step_y, step_z;
+  HOST_WIDE_INT step_x, step_y, step_z;
   HOST_WIDE_INT niter_x, niter_y, niter_z, niter;
   affine_fn overlaps_a_xz, overlaps_b_xz;
   affine_fn overlaps_a_yz, overlaps_b_yz;
@@ -3194,7 +3196,8 @@ build_classic_dist_vector_1 (struct 
data_dependence_relation *ddr,
   if (TREE_CODE (access_fn_a) == POLYNOMIAL_CHREC
  && TREE_CODE (access_fn_b) == POLYNOMIAL_CHREC)
{
- int dist, index;
+ HOST_WIDE_INT dist;
+ int index;
  int var_a = CHREC_VARIABLE (access_fn_a);
  int var_b = CHREC_VARIABLE (access_fn_b);
 
@@ -3268,7 +3271,7 @@ add_multivariate_self_dist (struct 
data_dependence_relation *ddr, tree c_2)
   tree c_1 = CHREC_LEFT (c_2);
   tree c_0 = CHREC_LEFT (c_1);
   lambda_vector dist_v;
-  int v1, v2, cd;
+  HOST_WIDE_INT v1, v2, cd;
 
   /* Polynomials with more than 2 variables are not handled yet.  When
  the evolution steps are parameters, it is not possible to

Marek

Re: RFC: Warnings silenced when macros from system headers are used (PR c/78000, c/71613)

[Marek Polacek]

So I'm wondering how/if should we proceed with this.  Seems that if we'll
go with my patch, we might have to add a bunch of sentinels (it seemed that
it's mostly warnings about GNU extensions that we want to silence for
system headers), but it's hard to gauge the overall effect.

On Thu, Nov 03, 2016 at 11:26:04AM +0100, Marek Polacek wrote:
> On Wed, Nov 02, 2016 at 01:39:22PM -0400, Jason Merrill wrote:
> > On Wed, Nov 2, 2016 at 12:37 PM, Joseph Myers  
> > wrote:
> > > On Wed, 2 Nov 2016, Jason Merrill wrote:
> > >
> > >> It seems to me that the general principle is that we should consider
> > >> the location where the thing we're warning about is happening.  In
> > >>
> > >>float_var = LLONG_MIN;
> > >>
> > >> The relevant location is that of the assignment, not the constant on
> > >> the RHS.  In your ?: example, a simple answer would be to warn based
> > >
> > > I'm not sure we track locations well enough to handle that yet.
> > >
> > > Say you have an implicit conversion of a function argument to the type
> > > from the prototype and something about that conversion should be warned
> > > about.  Then you should obviously warn if the argument is a macro from a
> > > system header but the call is outside a system header.  But say the
> > > function call itself comes from a macro defined in a system header - you
> > > should still warn if the user passed an argument of the wrong type, even
> > > if that argument is a macro from a system header.
> > >
> > > That is:
> > >
> > > /* System header.  */
> > > int __foo (int);
> > > /* This sort of macro to avoid accidental interposition issues has been
> > >discussed lately on libc-alpha, so it's a realistic example.  */
> > > #define foo(x) (0 + __foo (x))
> > > /* User code.  */
> > > v = foo (NULL);
> > >
> > > should warn because the call to __foo logically results from user code
> > > even though both NULL and foo are macros defined in system headers.  I'm
> > > not sure what the locations look like here.
> > 
> > Sure, the problem here comes from the user combining the two macros.
> > I suppose in this case you could notice that the macro expansions of
> > 'foo' and 'NULL' are not nested.
> 
> That testcase is handled ok even without the patch:
> x.c: In function ‘f’:
> x.c:7:7: warning: passing argument 1 of ‘__foo’ makes integer from pointer 
> without a cast [-Wint-conversion]
>v = foo (NULL);
>^~~
> In file included from x.c:1:0:
> x.h:2:5: note: expected ‘int’ but argument is of type ‘void *’
>  int __foo (int);
>  ^
> 
> because convert_for_assignment already has the call to
> expansion_point_location_if_in_system_header.
> 
> I will add that testcase to my patch.

Marek

Re: [PATCH] correct %g handling with unknown arguments in -fprintf-return-value (PR 78696)

[Jeff Law]

On 12/09/2016 11:07 AM, Martin Sebor wrote:

Bug 78696 points out a bug in the handling of the %g directive in
the gimple-ssa-sprintf pass where precision wasn't being correctly
handled.  In the process of developing and testing a fix for it
I noticed a few other subtle problems in the floating point handling
of unknown values.  The attached patch corrects them and adds test
cases to better exercise this area.

In the same bug, Jakub also pointed out that the -fprintf-retrun-value
optimization isn't correct in locales where the floating point radix
character (normally the decimal point, '.') is a multibyte character
longer than 1 byte.  Since that's unrelated to this report I raised
bug 78703 and will fix it in a subsequent patch.

Definitely address in a subsequent patch.



Martin


gcc-78696.diff


PR tree-optimization/78696 - [7 Regression] -fprintf-return-value misoptimizes 
%.Ng where N is greater than 10

gcc/ChangeLog:

PR tree-optimization/78696
* gimple-ssa-sprintf.c (format_floating): Correct handling of
precision.  Use MPFR for %f for greater fidelity.  Correct handling
of %g.
(pass_sprintf_length::compute_format_length): Set width and precision
specified by asrerisk to void_node for vararg functions.
(try_substitute_return_value): Adjust dump output.

gcc/testsuite/ChangeLog:

PR tree-optimization/78696
* gcc.dg/tree-ssa/builtin-sprintf-5.c: Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-warn-7.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf.c (checkv): Add test cases.

[ snip ]



+   /* The lower bound when precision isn't specified is 8 bytes
+  ("1.23456" since precision is taken to be 6).  When precision
+  is zero, the lower bound is 1 byte (e.g., "1").  Otherwise,
+  when precision is greater than zero, then the lower bound
+  is 2 plus precision (plus flags).  */
+   res.range.min = (flagmin
++ (prec != INT_MIN)   /* for decimal point */
++ (prec == INT_MIN
+   ? 0 : prec < 0 ? 6 : prec ? prec : -1));
Note for the future, nest/chained ternary operators can sometimes just 
be hard to visually parse when they're squashed on a single line. 
Formatting like this has often been used in the past to help clarify the 
intent:


(flagmin
 + (prec != INT_MIN)
 + (prec == INT_MIN ? 0
: prec < 0 ? 6
: prec ? prec
: -1)

If we ignore the flagmin component, I get the following evaluations for 
PREC.


PREC   RESULT
INTMIN 0
0  0
negative (but not INTMIN)  7
positive   prec + 1

That doesn't seem in-line with the comment.


Jeff

Re: [PATCH] Fix opt-functions.awk in POSIXLY_CORRECT mode (PR other/78766)

[Jeff Law]

On 12/12/2016 12:14 PM, Jakub Jelinek wrote:

Hi!

{ is a special character in ERE, so gawk rightfully complains in
POSIXLY_CORRECT mode.  The regex is meant to look for { at the beginning
of line.  Neither "^\{" nor "^\\{" works though, but "^[{]" does.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2016-12-12  Jakub Jelinek  

PR other/78766
* opt-functions.awk (opt_args): Use [{] instead of { in regexps.
OK.  Though it looks like you fix both { and }, which I assume was 
intentional and the ChangeLog is just incomplete.


jeff

Re: [PATCH] Trivial cleanup for tree-data-ref.c

[Jeff Law]

On 12/12/2016 02:03 PM, Marek Polacek wrote:

At least these should be HOST_WIDE_INTs rather than ints.  There might be
more opportunities than this.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2016-12-12  Marek Polacek  

* tree-data-ref.c (compute_overlap_steps_for_affine_univar): Change
parameters' type from int to HOST_WIDE_INT.
(compute_overlap_steps_for_affine_1_2): Change parameters' type from
int to HOST_WIDE_INT.
(build_classic_dist_vector_1): Likewise.
(add_multivariate_self_dist): Likewise.

OK.
jeff

Re: [PATCH, GCC/testsuite/ARM] Skip optional_mthumb tests if GCC has a default mode

[Christophe Lyon]

Hi Thomas,

Thanks for working on this,


On 12 December 2016 at 18:52, Thomas Preudhomme
 wrote:
> Hi,
>
> The logic to make -mthumb optional for Thumb-only devices is only executed
> when no -marm or -mthumb is given on the command-line. This includes
> configuring GCC with --with-mode= because this makes the option to be passed
> before any others. The optional_mthumb-* testcases are skipped when -marm or
> -mthumb is passed on the command line but not when GCC was configured with
> --with-mode. Not only are the tests meaningless in these configurations,
> they also spuriously FAIL if --with-mode=arm was used since the test are
> built for Thumb-only devices, as reported by Christophe Lyon in [1].
>
> [1] https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02082.html
>
> This patch adds logic to target-support.exp to check how was GCC configured
> and changes the optional_mthumb testcases to be skipped if there is a
> default mode (--with-mode=). It also fixes a couple of typo on the
> selectors.
>

How hard would it be to skip these tests only if --with-mode=arm,
such that they would still pass in configurations --with-mode=thumb?

It seems easy to extend what you propose here, doesn't it?

Christophe

> ChangeLog entry is as follows:
>
>
> *** gcc/testsuite/ChangeLog ***
>
> 2016-12-09  Thomas Preud'homme  
>
> * lib/target-supports.exp (check_configured_with): New procedure.
> (check_effective_target_default_mode): new effective target.
> * gcc.target/arm/optional_thumb-1.c: Skip if GCC was configured with
> a
> default mode.  Fix dg-skip-if target selector syntax.
> * gcc.target/arm/optional_thumb-2.c: Likewise.
> * gcc.target/arm/optional_thumb-3.c: Fix dg-skip-if target selector
> syntax.
>
>
> Is this ok for stage3?
>
> Best regards,
>
> Thomas