Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

2018-02-11 Thread Alexandre Oliva
On Feb 11, 2018, Andreas Schwab  wrote:

> On Feb 09 2018, Alexandre Oliva  wrote:

>> +  if (list_head->vl_symbol && dwarf2out_locviews_in_attribute ())
>> +{
>> +  ASM_OUTPUT_LABEL (asm_out_file, list_head->vl_symbol);

> That needs to use ASM_OUTPUT_DEBUG_LABEL.

Note this is always output in the .debug_loclist section, not in code
sections, so I don't get why it should matter.  Care to clarify, please?

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer


Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

2018-02-11 Thread Alexandre Oliva
On Feb 11, 2018, Andreas Schwab  wrote:

>> +  if (list_head->vl_symbol && dwarf2out_locviews_in_attribute ())
>> +{
>> +  ASM_OUTPUT_LABEL (asm_out_file, list_head->vl_symbol);

> That needs to use ASM_OUTPUT_DEBUG_LABEL.

There's another use of the same macro that was already there, right
before the locview block output:

  ASM_OUTPUT_LABEL (asm_out_file, list_head->ll_symbol);

Shouldn't it be ASM_OUTPUT_DEBUG_LABEL too?


is fixing these enough to address the problem you reported?

Thanks,

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer


Re: [PATCH][C++] Fix PR84281

2018-02-11 Thread Richard Biener
On Fri, 9 Feb 2018, Jason Merrill wrote:

> OK.

Failed to notice that vec_safe_reserve reserves additional space
so applied as follows restricting it to the very first iteration.

Richard.

2018-02-12  Richard Biener  

PR c++/84281
* constexpr.c (cxx_eval_vec_init_1): Use a RANGE_EXPR to compact
uniform constructors and delay allocating them fully.

Index: gcc/cp/constexpr.c
===
--- gcc/cp/constexpr.c  (revision 257525)
+++ gcc/cp/constexpr.c  (working copy)
@@ -2885,7 +2885,6 @@ cxx_eval_vec_init_1 (const constexpr_ctx
   unsigned HOST_WIDE_INT max = tree_to_uhwi (array_type_nelts_top (atype));
   verify_ctor_sanity (ctx, atype);
   vec **p = _ELTS (ctx->ctor);
-  vec_alloc (*p, max + 1);
   bool pre_init = false;
   unsigned HOST_WIDE_INT i;
 
@@ -2978,13 +2977,14 @@ cxx_eval_vec_init_1 (const constexpr_ctx
{
  if (new_ctx.ctor != ctx->ctor)
eltinit = new_ctx.ctor;
- for (i = 1; i < max; ++i)
-   {
- idx = build_int_cst (size_type_node, i);
- CONSTRUCTOR_APPEND_ELT (*p, idx, unshare_constructor (eltinit));
-   }
+ tree range = build2 (RANGE_EXPR, size_type_node,
+  build_int_cst (size_type_node, 1),
+  build_int_cst (size_type_node, max - 1));
+ CONSTRUCTOR_APPEND_ELT (*p, range, unshare_constructor (eltinit));
  break;
}
+  else if (i == 0)
+   vec_safe_reserve (*p, max);
 }
 
   if (!*non_constant_p)


Re: [Patch, Fortran] PR 84273: Reject allocatable passed-object dummy argument (proc_ptr_47.f90)

2018-02-11 Thread Richard Biener
On Sun, 11 Feb 2018, Janus Weil wrote:

> Dear release managers,
> 
> 2018-02-10 0:21 GMT+01:00 Steve Kargl :
> > On Fri, Feb 09, 2018 at 06:13:34PM +0100, Janus Weil wrote:
> >>
> >> the attached patch fixes some checking code for PASS arguments in
> >> procedure-pointer components, which does not properly account for the
> >> fact that the PASS argument needs to be polymorphic.
> >>
> >> [The reason for this issue is probably that PPCs were mostly
> >> implemented before polymorphism was available. The corresponding
> >> pass-arg checks for TBPs are ok.]
> >>
> >> The patch also fixes an invalid test case (which was detected thanks
> >> to Neil Carlson). It regtests cleanly on x86_64-linux-gnu. Ok for
> >> trunk?
> >
> > The patch looks ok to me.  Trunk is in regression and doc
> > fixes only mode, so you'll probably need to ping Jakub or
> > Richard (ie., release engineer) for an ok.
> 
> would you mind if I applied this patch to trunk at the current stage?
> It was approved by Steve and Paul, is rather simple and low-risk ...

Go ahead.

Richard.


Re: [x86,avx] Fix __builtin_cpu_supports for icelake and cannonlake isa

2018-02-11 Thread Kirill Yukhin
Hello Julia.

On 15 Jan 08:28, Koval, Julia wrote:
> Hi,
> This patch fixes subj. Ok for trunk?
> 
> gcc/
>   * config/i386/i386.c (F_AVX512VBMI2, F_GFNI, F_VPCLMULQDQ, F_AVX512VNNI,
>   F_AVX512BITALG): New.
> 
> gcc/testsuite/
>   * gcc.target/i386/builtin_target.c (check_intel_cpu_model): Add 
> cannonlake.
>   (check_features): Add avx512vbmi2, gfni, vpclmulqdq, avx512vnni,
>   avx512bitalg.
> 
> libgcc/
>   * config/i386/cpuinfo.c (get_available_features): Add 
> FEATURE_AVX512VBMI2,
>   FEATURE_GFNI, FEATURE_VPCLMULQDQ, FEATURE_AVX512VNNI, 
> FEATURE_AVX512BITALG.
>   * config/i386/cpuinfo.h (processor_features) Add FEATURE_AVX512VBMI2,
>   FEATURE_GFNI, FEATURE_VPCLMULQDQ, FEATURE_AVX512VNNI, 
> FEATURE_AVX512BITALG.

Could you pls mention, which problem does your patch fix?

--
Thanks, K


Re: [patch][i386] Fix for PR83828

2018-02-11 Thread Kirill Yukhin
Hello Olga,
On 06 Feb 08:13, Makhotina, Olga wrote:
> Hi,
> 
> This patch repairs vpopcnt tests.
> 
> 06.02.2018  Olga Makhotina  
> 
> gcc/testsuite/
>   PR target/83828
>   * gcc.target/i386/avx512bitalg-vpopcntb-1.c: Fix test.
>   * gcc.target/i386/avx512bitalg-vpopcntw-1.c: Ditto.
>   * gcc.target/i386/avx512bitalg-vpshufbitqmb-1.c: Ditto.
>   * gcc.target/i386/avx512vpopcntdq-vpopcntd-1.c: Ditto.
>   * gcc.target/i386/avx512vpopcntdq-vpopcntq-1.c: Ditto.
> 
> Is it ok for trunk?
Although, I wasn't able to reproduce fails mentioned by HJ on
Bugzilla, your patch looks reasonble. It is ok for main trunk.

I've checked it in.

--
Thanks, K

> 
> Thanks,
> Olga.
> 




Re: [patch][i386, AVX] Adding missing mask[z]_scalef_round_s[d,s] intrinsics

2018-02-11 Thread Kirill Yukhin
Hello Olga,

On 14 Nov 09:56, Makhotina, Olga wrote:
> Hi,
> 
> Attachment got lost by accident. Attaching it again.
> 
> Thanks,
> Olga
> 
> -Original Message-
> From: Makhotina, Olga 
> Sent: Tuesday, November 14, 2017 10:49 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Uros Bizjak ; Kirill Yukhin ; 
> Makhotina, Olga ; Peryt, Sebastian 
> 
> Subject: [patch][i386, AVX] Adding missing mask[z]_scalef_round_s[d,s] 
> intrinsics
> 
> Hi,
> 
> This patch adds missing intrinsics for _mm_mask[z]_scalef_round_[sd,ss].
> 
> 14.11.2017  Olga Makhotina  
> 
> gcc/
>   * config/i386/avx512fintrin.h (_mm_mask_scalef_round_sd,
>   _mm_maskz_scalef_round_sd, _mm_mask_scalef_round_ss, 
>   _mm_maskz_scalef_round_ss): New intrinsics.
>   (__builtin_ia32_scalefsd_round, __builtin_ia32_scalefss_round): Fix.
>   * config/i386/i386-builtin.def (__builtin_ia32_scalefsd_round,
>   __builtin_ia32_scalefss_round): Remove.
>   (__builtin_ia32_scalefsd_mask_round,
>   __builtin_ia32_scalefss_mask_round): New intrinsics.
>   * config/i386/sse.md (vmscalef): Renamed to ...
>   (vmscalef): ... this.
>   ((match_operand:VF_128 2 "" 
>   "")): Changed to ...
>   ((match_operand:VF_128 2 "" 
>   "")): ... this.
>   ("vscalef\t{%2, %1, %0|
>   %0, %1, %2}"): Changed to ...
>   ("vscalef\t{%2, %1, 
>   %0|%0, %1, 
>   %2}"): ... this.
>   * config/i386/subst.md (round_scalar_nimm_predicate): New.
> 
> 14.11.2017  Olga Makhotina  
> 
> gcc/testsuite/
>   * gcc.target/i386/avx512f-vscalefsd-1.c (_mm_mask_scalef_round_sd,
>   _mm_maskz_scalef_round_sd): Test new intrinsics.
>   * gcc.target/i386/avx512f-vscalefsd-2.c (_mm_scalef_round_sd,
>   _mm_mask_scalef_round_sd, _mm_maskz_scalef_round_sd): Test new 
> intrinsics.
>   * gcc.target/i386/avx512f-vscalefss-1.c (_mm_mask_scalef_round_ss,
>   _mm_maskz_scalef_round_ss): Test new intrinsics.
>   * gcc.target/i386/avx512f-vscalefss-2.c (_mm_scalef_round_ss,
>   _mm_mask_scalef_round_ss, _mm_maskz_scalef_round_ss): Test new 
> intrinsics.
>   * gcc.target/i386/avx-1.c (__builtin_ia32_scalefsd_round,
>   __builtin_ia32_scalefss_round): Remove builtin.
>   (__builtin_ia32_scalefsd_mask_round,
>   __builtin_ia32_scalefss_mask_round): Test new builtin.
>   * gcc.target/i386/sse-13.c: Ditto.
>   * gcc.target/i386/sse-23.c: Ditto.
> 
> Is it ok for trunk?
Your patch is OK for main trunk. I've checked it in.
(I've removed trailing spaces from CL entries and limited to 80 chars).

--
Thanks, K

>  
> Thanks,
> Olga




Re: [patch][i386, AVX] Adding missing mask[z]_sqrt_round_s[d,s] intrinsics

2018-02-11 Thread Kirill Yukhin
Hello Olga,

On 21 Nov 12:46, Makhotina, Olga wrote:
> Hi,
> 
> This patch adds missing intrinsics for _mm_mask[z]_sqrt_round_[sd,ss].
> 
> 21.11.2017 Olga Makhotina  
> 
> gcc/
>   * config/i386/avx512fintrin.h (_mm_mask_sqrt_round_sd,
>   _mm_maskz_sqrt_round_sd, _mm_mask_sqrt_round_ss,
>   _mm_maskz_sqrt_round_ss): New intrinsics.
>   (__builtin_ia32_sqrtsd_round, __builtin_ia32_sqrtss_round): 
> Remove.
>   (__builtin_ia32_sqrtsd_mask_round,
>   __builtin_ia32_sqrtss_mask_round): New builtins.
>   * config/i386/i386-builtin.def (__builtin_ia32_sqrtsd_round,
>   __builtin_ia32_sqrtss_round): Remove.
>   (__builtin_ia32_sqrtsd_mask_round,
>   __builtin_ia32_sqrtss_mask_round): New builtins.
>   * config/i386/sse.md (vmsqrt2): Renamed to ...
>   (vmsqrt2): ... this.
>   ((match_operand:VF_128 1 "vector_operand" 
>   "xBm,")): Changed to ...
>   ((match_operand:VF_128 1 "vector_operand" 
>   "xBm,")): ... this.
>   (vsqrt\t{%1, %2, %0|
>   %0, %2, %1}): Changed to ...
>   (vsqrt\t{%1, %2, 
>   %0|%0, %2, 
>   %1}): ... this.
>   ((set_attr "prefix" "")): Changed to ...
>   ((set_attr "prefix" "")): ... this.
> 
> 21.11.2017 Olga Makhotina  
> 
> gcc/testsuite/
>   * gcc.target/i386/avx512f-vsqrtsd-1.c (_mm_mask_sqrt_round_sd,
>   _mm_maskz_sqrt_round_sd): Test new intrinsics.
>   * gcc.target/i386/avx512f-vsqrtsd-2.c (_mm_sqrt_round_sd,
>   _mm_mask_sqrt_round_sd, _mm_maskz_sqrt_round_sd): Test new 
> intrinsics.
>   * gcc.target/i386/avx512f-vsqrtss-1.c (_mm_mask_sqrt_round_ss,
>   _mm_maskz_sqrt_round_ss): Test new intrinsics.
>   * gcc.target/i386/avx512f-vsqrtss-2.c (_mm_sqrt_round_ss,
>   _mm_mask_sqrt_round_ss,  _mm_maskz_sqrt_round_ss): Test new 
> intrinsics.
>   * gcc.target/i386/avx-1.c (__builtin_ia32_sqrtsd_round,
>   __builtin_ia32_sqrtss_round): Remove builtins.
>   (__builtin_ia32_sqrtsd_mask_round,
>   __builtin_ia32_sqrtss_mask_round): Test new builtins.
>   * gcc.target/i386/sse-13.c: Ditto.
>   * gcc.target/i386/sse-23.c: Ditto.
> 
> Is it ok for trunk?
The patch itself is OK for trunk. I've checked it in.

One nit: could you pls format ChangeLog entries more carefully:
80 chars in line max, tab instead of leading spaces.

--
Thanks, K

> 
> Thanks,
> Olga
> 




[PATCH 2/3] Add a pass to automatically add ptwrite instrumentation

2018-02-11 Thread Andi Kleen
From: Andi Kleen 

Add a new pass to automatically instrument changes to variables
with the new PTWRITE instruction on x86. PTWRITE writes a 4 or 8 byte
field into an external Processor Trace log.

This allows to reconstruct how values later, which can be useful for
debugging or other analysis of the program behavior. With the compiler
support this can be done with without having to manually add instrumentation
to the code.

Using dwarf information this can be later mapped back to the variables.

There are new options to enable instrumentation for different types,
and also a new attribute to control analysis fine grained per
function or variable level. The attributes can be set on both
the variable and the type level, and also on structure fields.
This allows to enable tracing only for specific code in large
programs.

The pass is generic, but only the x86 backend enables the necessary
hooks. When the backend enables the necessary hooks (with -mptwrite)
there is an additional pass that looks through the code for
attribute vartrace enabled functions or variables.

The -fvartrace-locals options is experimental: it works, but it
generates many redundant ptwrites because the pass doesn't use
the SSA information to minimize instrumentation. This could be optimized
later.

Currently the code can be tested with SDE, or on a Intel
Cherry Trail system with a new enough Linux kernel (v4.10+)
that supports PTWRITE for PT. Linux perf can be used to
record the values

perf record -e intel_pt/ptw=1,branch=0/ program
perf script --itrace=crw -F +synth ...

I have an experimential version of perf that can also use
dwarf information to symbolize many[1] values back to their variable
names. So far it is not in standard perf, but available at

https://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc.git/log/?h=perf/var-resolve-2

Longer term hopefully gdb will support this information too.

Passes bootstrap and test suite on x86_64-linux.

[1] Many: so far it only supports register variables that are not
arguments.

gcc/:

2018-02-10  Andi Kleen  

* Makefile.in: Add tree-vartrace.o.
* common.opt: Add -fvartrace, -fvartrace-returns,
-fvartrace-args, -fvartrace-reads, -fvartrace-writes,
-fvartrace-locals
* config/i386/i386.c (ix86_vartrace_func): Add.
(TARGET_VARTRACE_FUNC): Add.
* doc/extend.texi: Document vartrace/no_vartrace
attributes.
* doc/invoke.texi: Document -fvartrace, -fvartrace-returns,
-fvartrace-args, -fvartrace-reads, -fvartrace-writes,
-fvartrace-locals
* doc/tm.texi (TARGET_VARTRACE_FUNC): Add.
* passes.def: Add vartrace pass.
* target.def (vartrace_func): Add.
* tree-pass.h (make_pass_vartrace): Add.
* tree-vartrace.c: New file to implement vartrace pass.

gcc/c-family/:

2018-02-10  Andi Kleen  

* c-attribs.c (handle_vartrace_attribute): New function.
---
 gcc/Makefile.in  |   1 +
 gcc/c-family/c-attribs.c |  23 +++
 gcc/common.opt   |  24 +++
 gcc/config/i386/i386.c   |  16 ++
 gcc/doc/extend.texi  |  13 ++
 gcc/doc/invoke.texi  |  29 +++
 gcc/doc/tm.texi  |   4 +
 gcc/doc/tm.texi.in   |   2 +
 gcc/passes.def   |   1 +
 gcc/target.def   |   7 +
 gcc/tree-pass.h  |   1 +
 gcc/tree-vartrace.c  | 462 +++
 12 files changed, 583 insertions(+)
 create mode 100644 gcc/tree-vartrace.c

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 6c37e46f792..3bce0f21bb4 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1580,6 +1580,7 @@ OBJS = \
tree-vectorizer.o \
tree-vector-builder.o \
tree-vrp.o \
+   tree-vartrace.o \
tree.o \
typed-splay-tree.o \
unique-ptr-tests.o \
diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 0261a45ec98..0c6488e0912 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -104,6 +104,8 @@ static tree handle_tls_model_attribute (tree *, tree, tree, 
int,
bool *);
 static tree handle_no_instrument_function_attribute (tree *, tree,
 tree, int, bool *);
+static tree handle_vartrace_attribute (tree *, tree,
+tree, int, bool *);
 static tree handle_no_profile_instrument_function_attribute (tree *, tree,
 tree, int, bool *);
 static tree handle_malloc_attribute (tree *, tree, tree, int, bool *);
@@ -331,6 +333,12 @@ const struct attribute_spec c_common_attribute_table[] =
   { "no_instrument_function", 0, 0, true,  false, false, false,
  handle_no_instrument_function_attribute,
  NULL },
+  { "vartrace",  0, 0, false,  false, 

[PATCH 3/3] Add tests for the vartrace pass

2018-02-11 Thread Andi Kleen
From: Andi Kleen 

gcc/testsuite/:

2018-02-10  Andi Kleen  

* g++.dg/vartrace-3.C: New test.
* g++.dg/vartrace-ret.C: New test.
* g++.dg/vartrace-ret2.C: New test.
* gcc.target/i386/vartrace-1.c: New test.
* gcc.target/i386/vartrace-10.c: New test.
* gcc.target/i386/vartrace-11.c: New test.
* gcc.target/i386/vartrace-12.c: New test.
* gcc.target/i386/vartrace-13.c: New test.
* gcc.target/i386/vartrace-14.c: New test.
* gcc.target/i386/vartrace-15.c: New test.
* gcc.target/i386/vartrace-16.c: New test.
* gcc.target/i386/vartrace-2.c: New test.
* gcc.target/i386/vartrace-3.c: New test.
* gcc.target/i386/vartrace-4.c: New test.
* gcc.target/i386/vartrace-5.c: New test.
* gcc.target/i386/vartrace-6.c: New test.
* gcc.target/i386/vartrace-7.c: New test.
* gcc.target/i386/vartrace-8.c: New test.
* gcc.target/i386/vartrace-9.c: New test.
---
 gcc/testsuite/g++.dg/vartrace-3.C   | 14 ++
 gcc/testsuite/g++.dg/vartrace-ret.C | 17 
 gcc/testsuite/g++.dg/vartrace-ret2.C| 24 +
 gcc/testsuite/gcc.target/i386/vartrace-1.c  | 41 +
 gcc/testsuite/gcc.target/i386/vartrace-10.c | 13 +
 gcc/testsuite/gcc.target/i386/vartrace-11.c | 16 +++
 gcc/testsuite/gcc.target/i386/vartrace-12.c | 16 +++
 gcc/testsuite/gcc.target/i386/vartrace-13.c | 18 +
 gcc/testsuite/gcc.target/i386/vartrace-14.c | 17 
 gcc/testsuite/gcc.target/i386/vartrace-15.c | 12 +
 gcc/testsuite/gcc.target/i386/vartrace-16.c | 12 +
 gcc/testsuite/gcc.target/i386/vartrace-17.c | 23 
 gcc/testsuite/gcc.target/i386/vartrace-2.c  |  9 +++
 gcc/testsuite/gcc.target/i386/vartrace-3.c  |  9 +++
 gcc/testsuite/gcc.target/i386/vartrace-4.c  | 13 +
 gcc/testsuite/gcc.target/i386/vartrace-5.c  | 11 
 gcc/testsuite/gcc.target/i386/vartrace-6.c  | 13 +
 gcc/testsuite/gcc.target/i386/vartrace-7.c  | 11 
 gcc/testsuite/gcc.target/i386/vartrace-8.c  | 11 
 gcc/testsuite/gcc.target/i386/vartrace-9.c  | 11 
 gcc/tree-vartrace.c |  7 ++---
 21 files changed, 315 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/vartrace-3.C
 create mode 100644 gcc/testsuite/g++.dg/vartrace-ret.C
 create mode 100644 gcc/testsuite/g++.dg/vartrace-ret2.C
 create mode 100644 gcc/testsuite/gcc.target/i386/vartrace-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/vartrace-10.c
 create mode 100644 gcc/testsuite/gcc.target/i386/vartrace-11.c
 create mode 100644 gcc/testsuite/gcc.target/i386/vartrace-12.c
 create mode 100644 gcc/testsuite/gcc.target/i386/vartrace-13.c
 create mode 100644 gcc/testsuite/gcc.target/i386/vartrace-14.c
 create mode 100644 gcc/testsuite/gcc.target/i386/vartrace-15.c
 create mode 100644 gcc/testsuite/gcc.target/i386/vartrace-16.c
 create mode 100644 gcc/testsuite/gcc.target/i386/vartrace-17.c
 create mode 100644 gcc/testsuite/gcc.target/i386/vartrace-2.c
 create mode 100644 gcc/testsuite/gcc.target/i386/vartrace-3.c
 create mode 100644 gcc/testsuite/gcc.target/i386/vartrace-4.c
 create mode 100644 gcc/testsuite/gcc.target/i386/vartrace-5.c
 create mode 100644 gcc/testsuite/gcc.target/i386/vartrace-6.c
 create mode 100644 gcc/testsuite/gcc.target/i386/vartrace-7.c
 create mode 100644 gcc/testsuite/gcc.target/i386/vartrace-8.c
 create mode 100644 gcc/testsuite/gcc.target/i386/vartrace-9.c

diff --git a/gcc/testsuite/g++.dg/vartrace-3.C 
b/gcc/testsuite/g++.dg/vartrace-3.C
new file mode 100644
index 000..13f71cca6d8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/vartrace-3.C
@@ -0,0 +1,14 @@
+/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
+/* { dg-options "-O2 -mptwrite -fvartrace-args " } */
+/* { dg-final { scan-assembler "ptwrite" } } */
+
+int a;
+int b(int c) 
+{
+  if (a)
+c += 1;
+  else
+c += b(a);
+  b(c);
+  return 0;
+}
diff --git a/gcc/testsuite/g++.dg/vartrace-ret.C 
b/gcc/testsuite/g++.dg/vartrace-ret.C
new file mode 100644
index 000..2a8a6753bd3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/vartrace-ret.C
@@ -0,0 +1,17 @@
+/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
+/* { dg-options "-O2 -mptwrite -fvartrace-returns " } */
+/* { dg-final { scan-assembler-not "ptwrite" } } */
+
+class foo { 
+public:
+short a;
+short b;
+};
+
+foo f1()
+{
+foo x = { 1, 2 };
+return x;
+}
+
+
diff --git a/gcc/testsuite/g++.dg/vartrace-ret2.C 
b/gcc/testsuite/g++.dg/vartrace-ret2.C
new file mode 100644
index 000..56842d75fb6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/vartrace-ret2.C
@@ -0,0 +1,24 @@
+/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
+/* { dg-options "-O2 -mptwrite -fvartrace " } */
+/* { dg-final { scan-assembler "ptwrite" } } */
+
+typedef int a;

[PATCH 1/3] Add PTWRITE builtins for x86

2018-02-11 Thread Andi Kleen
From: Andi Kleen 

Add builtins/intrinsics for PTWRITE. PTWRITE is a new instruction on Intel 
Cherry Trail
that allows to write values into the Processor Trace log.

This is fairly straight forward, except I had to add isa2 support for variable 
number
of operands.

gcc/:

2018-02-10  Andi Kleen  

* common/config/i386/i386-common.c (OPTION_MASK_ISA_PTWRITE_SET):
(OPTION_MASK_ISA_PTWRITE_UNSET): New.
(ix86_handle_option): Handle OPT_mptwrite.
* config/i386/cpuid.h (bit_PTWRITE): Add.
* config/i386/driver-i386.c (host_detect_local_cpu): Detect
PTWRITE CPUID.
* config/i386/i386-builtin.def (PTWRITE): Add PTWRITE.
* config/i386/i386-c.c (ix86_target_macros_internal):
Support __PTWRITE__.
* config/i386/i386.c (ix86_target_string): Add -mptwrite.
(ix86_valid_target_attribute_inner_p): Support ptwrite.
(BDESC_VERIFYS): Verify SPECIAL_ARGS2.
(ix86_init_mmx_sse_builtins): Handle special args2.
* config/i386/i386.h (TARGET_PTWRITE): Add.
(TARGET_PTWRITE_P): Add.
* config/i386/i386.md: Add ptwrite.
* config/i386/i386.opt: Add -mptwrite.
* config/i386/immintrin.h (target):
(_ptwrite_u64): Add.
(_ptwrite_u32): Add.
* doc/extend.texi: Document ptwrite builtins.
* doc/invoke.texi: Document -mptwrite.

gcc/testsuite/:

2018-02-10  Andi Kleen  

* gcc.target/i386/ptwrite1.c: New test.
* gcc.target/i386/ptwrite2.c: New test.
---
 gcc/common/config/i386/i386-common.c | 15 +++
 gcc/config/i386/cpuid.h  |  4 +++
 gcc/config/i386/driver-i386.c| 13 +-
 gcc/config/i386/i386-builtin.def |  8 +-
 gcc/config/i386/i386-c.c |  2 ++
 gcc/config/i386/i386.c   | 50 +---
 gcc/config/i386/i386.h   |  2 ++
 gcc/config/i386/i386.md  | 10 
 gcc/config/i386/i386.opt |  4 +++
 gcc/config/i386/immintrin.h  | 24 +
 gcc/doc/extend.texi  |  9 +++
 gcc/doc/invoke.texi  |  5 +++-
 12 files changed, 140 insertions(+), 6 deletions(-)

diff --git a/gcc/common/config/i386/i386-common.c 
b/gcc/common/config/i386/i386-common.c
index 4fdd489b98e..7554dd4e85c 100644
--- a/gcc/common/config/i386/i386-common.c
+++ b/gcc/common/config/i386/i386-common.c
@@ -138,6 +138,7 @@ along with GCC; see the file COPYING3.  If not see
 
 #define OPTION_MASK_ISA_FSGSBASE_SET OPTION_MASK_ISA_FSGSBASE
 #define OPTION_MASK_ISA_RDRND_SET OPTION_MASK_ISA_RDRND
+#define OPTION_MASK_ISA_PTWRITE_SET OPTION_MASK_ISA_PTWRITE
 #define OPTION_MASK_ISA_F16C_SET \
   (OPTION_MASK_ISA_F16C | OPTION_MASK_ISA_AVX_SET)
 #define OPTION_MASK_ISA_MWAITX_SET OPTION_MASK_ISA_MWAITX
@@ -254,6 +255,7 @@ along with GCC; see the file COPYING3.  If not see
 
 #define OPTION_MASK_ISA_FSGSBASE_UNSET OPTION_MASK_ISA_FSGSBASE
 #define OPTION_MASK_ISA_RDRND_UNSET OPTION_MASK_ISA_RDRND
+#define OPTION_MASK_ISA_PTWRITE_UNSET OPTION_MASK_ISA_PTWRITE
 #define OPTION_MASK_ISA_F16C_UNSET OPTION_MASK_ISA_F16C
 
 #define OPTION_MASK_ISA_GENERAL_REGS_ONLY_UNSET \
@@ -1040,6 +1042,19 @@ ix86_handle_option (struct gcc_options *opts,
}
   return true;
 
+case OPT_mptwrite:
+  if (value)
+   {
+ opts->x_ix86_isa_flags2 |= OPTION_MASK_ISA_PTWRITE_SET;
+ opts->x_ix86_isa_flags2_explicit |= OPTION_MASK_ISA_PTWRITE_SET;
+   }
+  else
+   {
+ opts->x_ix86_isa_flags2 &= ~OPTION_MASK_ISA_PTWRITE_UNSET;
+ opts->x_ix86_isa_flags2_explicit |= OPTION_MASK_ISA_PTWRITE_UNSET;
+   }
+  return true;
+
 case OPT_mf16c:
   if (value)
{
diff --git a/gcc/config/i386/cpuid.h b/gcc/config/i386/cpuid.h
index aa903630c2c..6ec8cfe22e3 100644
--- a/gcc/config/i386/cpuid.h
+++ b/gcc/config/i386/cpuid.h
@@ -121,6 +121,10 @@
 #define bit_XSAVEC (1 << 1)
 #define bit_XSAVES (1 << 3)
 
+/* PT sub leaf (%eax == 14, %ecx == 0) */
+/* %ebx */
+#define bit_PTWRITE(1 << 4)
+
 /* Signatures for different CPU implementations as returned in uses
of cpuid with level 0.  */
 #define signature_AMD_ebx  0x68747541
diff --git a/gcc/config/i386/driver-i386.c b/gcc/config/i386/driver-i386.c
index ca1a2e0c37e..ebc9aa4608f 100644
--- a/gcc/config/i386/driver-i386.c
+++ b/gcc/config/i386/driver-i386.c
@@ -423,6 +423,8 @@ const char *host_detect_local_cpu (int argc, const char 
**argv)
   unsigned int has_avx512vnni = 0, has_vaes = 0;
   unsigned int has_vpclmulqdq = 0;
 
+  unsigned int has_ptwrite = 0;
+
   bool arch;
 
   unsigned int l2sizekb = 0;
@@ -534,6 +536,13 @@ const char *host_detect_local_cpu (int argc, const char 
**argv)
   has_xsaves = eax & bit_XSAVES;
 }
 
+  if (max_level >= 0x14)
+{
+  __cpuid_count (0x14, 0, eax, ebx, ecx, edx);
+
+  has_ptwrite = ebx & 

C++ PATCH for c++/84036, ICE with variadic lambda capture

2018-02-11 Thread Jason Merrill
The old lambda model handled variadic capture by focusing on the
FIELD_DECL rather than trying to map between capture proxies.  The new
model relies more on capture proxies, so it makes sense to use them
more for variadic capture as well.  So with this patch we treat a
variadic capture proxy as a pack, rather than the field.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit d6e4c6a3af04599f408b04e630b853d5a907beac
Author: Jason Merrill 
Date:   Thu Feb 8 16:18:33 2018 -0500

PR c++/84036 - ICE with variadic capture.

Handle variadic capture proxies more like non-variadic.
* lambda.c (build_capture_proxy): Remove workaround.
* pt.c (find_parameter_packs_r): The proxy is a pack.
(instantiate_class_template_1): Remove dead lambda code.
(extract_fnparm_pack): Don't make_pack_expansion.
(extract_locals_r): Don't strip a pack expansion.
(tsubst_pack_expansion): Handle proxy packs.  Use
PACK_EXPANSION_EXTRA_ARGS less.
(tsubst_decl) [FIELD_DECL]: Don't register_specialization.
(tsubst_copy) [FIELD_DECL]: Don't retrieve*_specialization.
[VAR_DECL]: Handle ARGUMENT_PACK_SELECT.
(tsubst_expr) [DECL_EXPR]: Handle proxy packs.
(tsubst_copy_and_build) [VAR_DECL]: Handle proxy packs normally.

diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c
index 2545eae9ce9..6b5bd800741 100644
--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -455,19 +455,11 @@ build_capture_proxy (tree member, tree init)
  STRIP_NOPS (init);
}
 
-  if (TREE_CODE (init) == COMPONENT_REF)
-   /* We're capturing a capture of a function parameter pack, and have
-  lost track of the original variable.  It's not important to have
-  DECL_CAPTURED_VARIABLE in this case, since a function parameter pack
-  isn't a constant variable, so don't bother trying to set it.  */;
-  else
-   {
- gcc_assert (VAR_P (init) || TREE_CODE (init) == PARM_DECL);
- while (is_normal_capture_proxy (init))
-   init = DECL_CAPTURED_VARIABLE (init);
- retrofit_lang_decl (var);
- DECL_CAPTURED_VARIABLE (var) = init;
-   }
+  gcc_assert (VAR_P (init) || TREE_CODE (init) == PARM_DECL);
+  while (is_normal_capture_proxy (init))
+   init = DECL_CAPTURED_VARIABLE (init);
+  retrofit_lang_decl (var);
+  DECL_CAPTURED_VARIABLE (var) = init;
 }
 
   if (name == this_identifier)
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 281604594ad..b58c60f0dcb 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -3561,14 +3561,13 @@ find_parameter_packs_r (tree *tp, int *walk_subtrees, 
void* data)
 
   /* Look through a lambda capture proxy to the field pack.  */
 case VAR_DECL:
-  if (DECL_HAS_VALUE_EXPR_P (t))
-   {
- tree v = DECL_VALUE_EXPR (t);
- cp_walk_tree (,
-   _parameter_packs_r,
-   ppd, ppd->visited);
- *walk_subtrees = 0;
-   }
+  if (DECL_PACK_P (t))
+{
+  /* We don't want to walk into the type of a variadic capture proxy,
+ because we don't want to see the type parameter pack.  */
+  *walk_subtrees = 0;
+ parameter_pack_p = true;
+}
   else if (variable_template_specialization_p (t))
{
  cp_walk_tree (_TI_ARGS (t),
@@ -10838,42 +10837,6 @@ instantiate_class_template_1 (tree type)
   c_inhibit_evaluation_warnings = saved_inhibit_evaluation_warnings;
 }
 
-  if (tree expr = CLASSTYPE_LAMBDA_EXPR (type))
-{
-  tree decl = lambda_function (type);
-  if (decl)
-   {
- if (cxx_dialect >= cxx17)
-   CLASSTYPE_LITERAL_P (type) = true;
-
- if (!DECL_TEMPLATE_INFO (decl)
- || DECL_TEMPLATE_RESULT (DECL_TI_TEMPLATE (decl)) != decl)
-   {
- /* Set function_depth to avoid garbage collection.  */
- ++function_depth;
- instantiate_decl (decl, /*defer_ok=*/false, false);
- --function_depth;
-   }
-
- /* We need to instantiate the capture list from the template
-after we've instantiated the closure members, but before we
-consider adding the conversion op.  Also keep any captures
-that may have been added during instantiation of the op().  */
- tree tmpl_expr = CLASSTYPE_LAMBDA_EXPR (pattern);
- tree tmpl_cap
-   = tsubst_copy_and_build (LAMBDA_EXPR_CAPTURE_LIST (tmpl_expr),
-args, tf_warning_or_error, NULL_TREE,
-false, false);
-
- LAMBDA_EXPR_CAPTURE_LIST (expr)
-   = chainon (tmpl_cap, nreverse (LAMBDA_EXPR_CAPTURE_LIST (expr)));
-
- maybe_add_lambda_conv_op (type);
-   }
-  else
-   gcc_assert (errorcount);
-}
-
   /* Set the file and line 

[PATCH] matcher-1.m: Change return type to int

2018-02-11 Thread H.J. Lu
my_exception_matcher must return int.  Otherwise, this test fails.

Tested on i686 and x86-64.  OK for trunk?

H.J.
---
PR testsuite/84324
* objc/execute/exceptions/matcher-1.m (my_exception_matcher):
Change return type to int.
---
 gcc/testsuite/objc/execute/exceptions/matcher-1.m | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/objc/execute/exceptions/matcher-1.m 
b/gcc/testsuite/objc/execute/exceptions/matcher-1.m
index cbe4365da90..25d6759cc9c 100644
--- a/gcc/testsuite/objc/execute/exceptions/matcher-1.m
+++ b/gcc/testsuite/objc/execute/exceptions/matcher-1.m
@@ -20,7 +20,7 @@ int main(void)
 
 static unsigned int handlerExpected = 0;
 
-void
+int
 my_exception_matcher(Class match_class, id exception)
 {
   /* Always matches.  */
-- 
2.14.3



Re: [Patch, Fortran] PR 84273: Reject allocatable passed-object dummy argument (proc_ptr_47.f90)

2018-02-11 Thread Janus Weil
Dear release managers,

2018-02-10 0:21 GMT+01:00 Steve Kargl :
> On Fri, Feb 09, 2018 at 06:13:34PM +0100, Janus Weil wrote:
>>
>> the attached patch fixes some checking code for PASS arguments in
>> procedure-pointer components, which does not properly account for the
>> fact that the PASS argument needs to be polymorphic.
>>
>> [The reason for this issue is probably that PPCs were mostly
>> implemented before polymorphism was available. The corresponding
>> pass-arg checks for TBPs are ok.]
>>
>> The patch also fixes an invalid test case (which was detected thanks
>> to Neil Carlson). It regtests cleanly on x86_64-linux-gnu. Ok for
>> trunk?
>
> The patch looks ok to me.  Trunk is in regression and doc
> fixes only mode, so you'll probably need to ping Jakub or
> Richard (ie., release engineer) for an ok.

would you mind if I applied this patch to trunk at the current stage?
It was approved by Steve and Paul, is rather simple and low-risk ...

Cheers,
Janus


Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

2018-02-11 Thread Andreas Schwab
On Feb 09 2018, Alexandre Oliva  wrote:

> @@ -9681,34 +9978,85 @@ gen_llsym (dw_loc_list_ref list)
>  static void
>  output_loc_list (dw_loc_list_ref list_head)
>  {
> +  int vcount = 0, lcount = 0;
> +
>if (list_head->emitted)
>  return;
>list_head->emitted = true;
>  
> +  if (list_head->vl_symbol && dwarf2out_locviews_in_attribute ())
> +{
> +  ASM_OUTPUT_LABEL (asm_out_file, list_head->vl_symbol);

That needs to use ASM_OUTPUT_DEBUG_LABEL.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


Re: [Fortran, patch, coarray, v1] Fix a coarray issue and some documentation

2018-02-11 Thread Andre Vehreschild
Er, the revision is 257567. Sorry pressed to quickly.

- Andre

On Sun, 11 Feb 2018 20:00:05 +0100
Andre Vehreschild  wrote:

> Hi all,
> 
> approved on IRC by Kargl. Thanks for the quick review. Committed as r
> 
> Regards,
>   Andre
> 
> On Sun, 11 Feb 2018 18:13:35 +0100
> Andre Vehreschild  wrote:
> 
> > Hi all,
> > 
> > attached patch fixes a small coarray issue on ultimate component coarrays.
> > The coarray was registered with the caf-library as if it were an allocatable
> > component in a derived type coarray, which is just wasting resources. An
> > ultimate component coarray has to be treated like a regular coarray. The
> > second chunk of the patch fixes that.
> > 
> > The first chunk of the attached patch just fixes some typos and style I
> > found while reading the help text for caf_register(). Those are so small
> > that I did not want to add another patch for this, given that both parts of
> > the patch are somehow related.
> > 
> > Bootstrapped and regtested on x86_64-linux-gnu/f27. Ok for trunk?
> > 
> > Regards,
> > Andre  
> 
> 


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


Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

2018-02-11 Thread Andreas Schwab
On Feb 09 2018, Alexandre Oliva <aol...@redhat.com> wrote:

> [LVU] Introduce location views
>
> This patch introduces an option to enable the generation of location
> views along with location lists.  The exact format depends on the
> DWARF version: it can be a separate attribute (DW_AT_GNU_locviews) or
> (DW_LLE_view_pair) entries in DWARF5+ loclists.

This breaks ia64 bootstrap.  While building the stage3 compiler I get
this error:

/usr/local/gcc/gcc-20180211/Build/./prev-gcc/xg++ 
-B/usr/local/gcc/gcc-20180211/Build/./prev-gcc/ -B/usr/ia64-suse-linux/bin/ 
-nostdinc++ 
-B/usr/local/gcc/gcc-20180211/Build/prev-ia64-suse-linux/libstdc++-v3/src/.libs 
-B/usr/local/gcc/gcc-20180211/Build/prev-ia64-suse-linux/libstdc++-v3/libsupc++/.libs
  
-I/usr/local/gcc/gcc-20180211/Build/prev-ia64-suse-linux/libstdc++-v3/include/ia64-suse-linux
  -I/usr/local/gcc/gcc-20180211/Build/prev-ia64-suse-linux/libstdc++-v3/include 
 -I/usr/local/gcc/gcc-20180211/libstdc++-v3/libsupc++ 
-L/usr/local/gcc/gcc-20180211/Build/prev-ia64-suse-linux/libstdc++-v3/src/.libs 
-L/usr/local/gcc/gcc-20180211/Build/prev-ia64-suse-linux/libstdc++-v3/libsupc++/.libs
 -fno-PIE -c  -DUSE_LIBUNWIND_EXCEPTIONS -DIN_GCC_FRONTEND -g -O2 -DIN_GCC 
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing 
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual 
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror 
-fno-common  -DHAVE_CONFIG_H -I. -Ilto -I../../gcc -I../../gcc/lto 
-I../../gcc/../include -I../../gcc/../libcpp/include  
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd -I../libdecnumber 
-I../../gcc/../libbacktrace   -o lto/lto-lang.o -MT lto/lto-lang.o -MMD -MP -MF 
lto/.deps/lto-lang.TPo ../../gcc/lto/lto-lang.c
/tmp/cccLpNWi.s: Assembler messages:
/tmp/cccLpNWi.s:1058101: Error: value of 89616 too large for field of 2 bytes 
at 502338
make[3]: *** [lto/lto-lang.o] Error 1
make[3]: Leaving directory `/usr/local/gcc/gcc-20180211/Build/gcc'
make[2]: *** [all-stage3-gcc] Error 2
make[2]: Leaving directory `/usr/local/gcc/gcc-20180211/Build'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/usr/local/gcc/gcc-20180211/Build'
make: *** [all] Error 2

The erroneous line has "data2.ua .LM78805-.LM78804", where .LM78805
points to the start of a function, and .LM78804 is the last of a long
list of labels (with consecutive numbers) all pointing to the same
address in the middle of an unrelated function.  Also, most of the .LM
labels point to insns in the middle of a bundle without using the
bracket notation.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


Re: [Fortran, patch, coarray, v1] Fix a coarray issue and some documentation

2018-02-11 Thread Andre Vehreschild
Hi all,

approved on IRC by Kargl. Thanks for the quick review. Committed as r

Regards,
Andre

On Sun, 11 Feb 2018 18:13:35 +0100
Andre Vehreschild  wrote:

> Hi all,
> 
> attached patch fixes a small coarray issue on ultimate component coarrays. The
> coarray was registered with the caf-library as if it were an allocatable
> component in a derived type coarray, which is just wasting resources. An
> ultimate component coarray has to be treated like a regular coarray. The
> second chunk of the patch fixes that.
> 
> The first chunk of the attached patch just fixes some typos and style I found
> while reading the help text for caf_register(). Those are so small that I did
> not want to add another patch for this, given that both parts of the patch are
> somehow related.
> 
> Bootstrapped and regtested on x86_64-linux-gnu/f27. Ok for trunk?
> 
> Regards,
>   Andre


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 257566)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,9 @@
+2018-02-11  Andre Vehreschild  
+
+	* gfortran.texi: Fix typos in documentation of caf_register ().
+	* trans-array.c (structure_alloc_comps): Only register a component of
+	a derived typed corray, not of an ultimate component coarray.
+
 2018-02-11  Steven G. Kargl  
 
 	PR fortran/54223
Index: gcc/fortran/gfortran.texi
===
--- gcc/fortran/gfortran.texi	(Revision 257566)
+++ gcc/fortran/gfortran.texi	(Arbeitskopie)
@@ -4453,8 +4453,8 @@
 @code{CAF_REGTYPE_COARRAY_ALLOC_ALLOCATE_ONLY} is specified, then the
 @var{token} needs to be registered by a previous call with regtype
 @code{CAF_REGTYPE_COARRAY_ALLOC_REGISTER_ONLY} and either the memory specified
-in the @var{desc}'s data-ptr is registered or allocate when the data-ptr is
-NULL.
+in the @var{DESC}'s data-ptr is registered or allocate when the data-ptr is
+@code{NULL}.
 
 @item @emph{Syntax}:
 @code{void caf_register (size_t size, caf_register_t type, caf_token_t *token,
@@ -4468,24 +4468,24 @@
 @item @var{token} @tab intent(out) An opaque pointer identifying the coarray.
 @item @var{desc} @tab intent(inout) The (pseudo) array descriptor.
 @item @var{stat} @tab intent(out) For allocatable coarrays, stores the STAT=;
-may be NULL
+may be @code{NULL}
 @item @var{errmsg} @tab intent(out) When an error occurs, this will be set to
-an error message; may be NULL
+an error message; may be @code{NULL}
 @item @var{errmsg_len} @tab the buffer size of errmsg.
 @end multitable
 
 @item @emph{NOTES}
-Nonalloatable coarrays have to be registered prior use from remote images.
+Nonallocatable coarrays have to be registered prior use from remote images.
 In order to guarantee this, they have to be registered before the main
 program. This can be achieved by creating constructor functions. That is what
-GCC does such that also nonallocatable coarrays the memory is allocated and no
-static memory is used.  The token permits to identify the coarray; to the
+GCC does such that also for nonallocatable coarrays the memory is allocated and
+no static memory is used.  The token permits to identify the coarray; to the
 processor, the token is a nonaliasing pointer. The library can, for instance,
 store the base address of the coarray in the token, some handle or a more
 complicated struct.  The library may also store the array descriptor
 @var{DESC} when its rank is non-zero.
 
-For lock types, the value shall only used for checking the allocation
+For lock types, the value shall only be used for checking the allocation
 status. Note that for critical blocks, the locking is only required on one
 image; in the locking statement, the processor shall always pass an
 image index of one for critical-block lock variables
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c	(Revision 257566)
+++ gcc/fortran/trans-array.c	(Arbeitskopie)
@@ -8747,15 +8747,17 @@
 	  cmp_has_alloc_comps = false;
 	}
 
-	  if (flag_coarray == GFC_FCOARRAY_LIB
-	  && (caf_in_coarray (caf_mode) || c->attr.codimension))
+	  if (flag_coarray == GFC_FCOARRAY_LIB && caf_in_coarray (caf_mode))
 	{
-	  /* Register the component with the coarray library.  */
+	  /* Register a component of a derived type coarray with the
+		 coarray library.  Do not register ultimate component
+		 coarrays here.  They are treated like regular coarrays and
+		 are either allocated on all images or on none.  */
 	  tree token;
 
 	  comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
   decl, cdecl, NULL_TREE);
-	  if (c->attr.dimension || c->attr.codimension)
+	  if (c->attr.dimension)
 		{
 		  /* Set the dtype, because caf_register needs it.  */
 		  gfc_add_modify 

Re: [Patch, fortran] PR84074 Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic

2018-02-11 Thread Paul Richard Thomas
Committed as revision 257564 with the comment reworded.

Thanks

Paul


On 11 February 2018 at 16:37, Steve Kargl
 wrote:
> On Sun, Feb 11, 2018 at 03:08:52PM +, Paul Richard Thomas wrote:
>>
>> PR fortran/84074
>> * trans-expr.c (gfc_conv_derived_to_class): Set the use_offset
>> flag. If the is a vector subscript or the expression is not a
>> variable, make the descriptor one-based.
>
>
> "If the is a" ?
>
>> +
>> +   /* Vector array references and non-variable expressions need be
>> +  coverted to one-based descriptors.  */
>
> s/coverted/converted
>
>
> OK with the above fixed.
>
> --
> steve



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein


Re: Merge from trunk to gccgo branch

2018-02-11 Thread Ian Lance Taylor
I merged trunk revision 257559 to the gccgo branch.

Ian


[Fortran, patch, coarray, v1] Fix a coarray issue and some documentation

2018-02-11 Thread Andre Vehreschild
Hi all,

attached patch fixes a small coarray issue on ultimate component coarrays. The
coarray was registered with the caf-library as if it were an allocatable
component in a derived type coarray, which is just wasting resources. An
ultimate component coarray has to be treated like a regular coarray. The second
chunk of the patch fixes that.

The first chunk of the attached patch just fixes some typos and style I found
while reading the help text for caf_register(). Those are so small that I did
not want to add another patch for this, given that both parts of the patch are
somehow related.

Bootstrapped and regtested on x86_64-linux-gnu/f27. Ok for trunk?

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


caf_nullify_and_doc_fix_v1.clog
Description: Binary data
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 11246696e18..9ffe6ade661 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -4453,8 +4453,8 @@ is not used then.  On the contrary when
 @code{CAF_REGTYPE_COARRAY_ALLOC_ALLOCATE_ONLY} is specified, then the
 @var{token} needs to be registered by a previous call with regtype
 @code{CAF_REGTYPE_COARRAY_ALLOC_REGISTER_ONLY} and either the memory specified
-in the @var{desc}'s data-ptr is registered or allocate when the data-ptr is
-NULL.
+in the @var{DESC}'s data-ptr is registered or allocate when the data-ptr is
+@code{NULL}.
 
 @item @emph{Syntax}:
 @code{void caf_register (size_t size, caf_register_t type, caf_token_t *token,
@@ -4468,24 +4468,24 @@ allocated; for lock types and event types, the number of elements.
 @item @var{token} @tab intent(out) An opaque pointer identifying the coarray.
 @item @var{desc} @tab intent(inout) The (pseudo) array descriptor.
 @item @var{stat} @tab intent(out) For allocatable coarrays, stores the STAT=;
-may be NULL
+may be @code{NULL}
 @item @var{errmsg} @tab intent(out) When an error occurs, this will be set to
-an error message; may be NULL
+an error message; may be @code{NULL}
 @item @var{errmsg_len} @tab the buffer size of errmsg.
 @end multitable
 
 @item @emph{NOTES}
-Nonalloatable coarrays have to be registered prior use from remote images.
+Nonallocatable coarrays have to be registered prior use from remote images.
 In order to guarantee this, they have to be registered before the main
 program. This can be achieved by creating constructor functions. That is what
-GCC does such that also nonallocatable coarrays the memory is allocated and no
-static memory is used.  The token permits to identify the coarray; to the
+GCC does such that also for nonallocatable coarrays the memory is allocated and
+no static memory is used.  The token permits to identify the coarray; to the
 processor, the token is a nonaliasing pointer. The library can, for instance,
 store the base address of the coarray in the token, some handle or a more
 complicated struct.  The library may also store the array descriptor
 @var{DESC} when its rank is non-zero.
 
-For lock types, the value shall only used for checking the allocation
+For lock types, the value shall only be used for checking the allocation
 status. Note that for critical blocks, the locking is only required on one
 image; in the locking statement, the processor shall always pass an
 image index of one for critical-block lock variables
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index d8b4381251e..4ffda26ca7d 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -8747,15 +8747,17 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
 	  cmp_has_alloc_comps = false;
 	}
 
-	  if (flag_coarray == GFC_FCOARRAY_LIB
-	  && (caf_in_coarray (caf_mode) || c->attr.codimension))
+	  if (flag_coarray == GFC_FCOARRAY_LIB && caf_in_coarray (caf_mode))
 	{
-	  /* Register the component with the coarray library.  */
+	  /* Register a component of a derived type coarray with the
+		 coarray library.  Do not register ultimate component
+		 coarrays here.  They are treated like regular coarrays and
+		 are either allocated on all images or on none.  */
 	  tree token;
 
 	  comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
   decl, cdecl, NULL_TREE);
-	  if (c->attr.dimension || c->attr.codimension)
+	  if (c->attr.dimension)
 		{
 		  /* Set the dtype, because caf_register needs it.  */
 		  gfc_add_modify (, gfc_conv_descriptor_dtype (comp),


Re: [PATCH] Fix handling of arguments in statement functions

2018-02-11 Thread Steve Kargl
On Sun, Feb 11, 2018 at 08:34:05AM -0800, Steve Kargl wrote:
> On Sun, Feb 11, 2018 at 01:48:10PM +0100, Dominique d'Humières wrote:
> > Hi Steve,
> > 
> > With your patch applied to revision r257559, I get the following failures
> > 
> > /opt/gcc/p_work/gcc/testsuite/gfortran.dg/statement_function_3.f:5:72: 
> > Warning: Obsolescent feature: Statement function at (1)
> > /opt/gcc/p_work/gcc/testsuite/gfortran.dg/statement_function_3.f:3:24: 
> > Error: Argument 'e' of statement function at (1) must be scalar
> > compiler exited with status 1
> > FAIL: gfortran.dg/statement_function_3.f   -O   (test for errors, line 5)
> > FAIL: gfortran.dg/statement_function_3.f   -O  (test for excess errors)
> > 
> 
> I may have posted the wrong patch or forgot to include the
> diff of the file that deals with this error.
> 

Yep, I forgot to include the diff for resolve.c.
See the new attachment for the complete patch.

-- 
Steve
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c	(revision 257464)
+++ gcc/fortran/interface.c	(working copy)
@@ -2835,7 +2835,8 @@ lookup_arg_fuzzy (const char *arg, gfc_formal_arglist 
 
 static bool
 compare_actual_formal (gfc_actual_arglist **ap, gfc_formal_arglist *formal,
-	 	   int ranks_must_agree, int is_elemental, locus *where)
+	 	   int ranks_must_agree, int is_elemental,
+		   bool in_statement_function, locus *where)
 {
   gfc_actual_arglist **new_arg, *a, *actual;
   gfc_formal_arglist *f;
@@ -3204,8 +3205,9 @@ compare_actual_formal (gfc_actual_arglist **ap, gfc_fo
 	}
 
   /* Check intent = OUT/INOUT for definable actual argument.  */
-  if ((f->sym->attr.intent == INTENT_OUT
-	  || f->sym->attr.intent == INTENT_INOUT))
+  if (!in_statement_function
+	  && (f->sym->attr.intent == INTENT_OUT
+	  || f->sym->attr.intent == INTENT_INOUT))
 	{
 	  const char* context = (where
  ? _("actual argument to INTENT = OUT/INOUT")
@@ -3310,7 +3312,8 @@ compare_actual_formal (gfc_actual_arglist **ap, gfc_fo
 		   "at %L", where);
 	  return false;
 	}
-  if (!f->sym->attr.optional)
+  if (!f->sym->attr.optional
+	  || (in_statement_function && f->sym->attr.optional))
 	{
 	  if (where)
 	gfc_error ("Missing actual argument for argument %qs at %L",
@@ -3598,6 +3601,7 @@ check_intents (gfc_formal_arglist *f, gfc_actual_argli
 bool
 gfc_procedure_use (gfc_symbol *sym, gfc_actual_arglist **ap, locus *where)
 {
+  gfc_actual_arglist *a;
   gfc_formal_arglist *dummy_args;
 
   /* Warn about calls with an implicit interface.  Special case
@@ -3631,8 +3635,6 @@ gfc_procedure_use (gfc_symbol *sym, gfc_actual_arglist
 
   if (sym->attr.if_source == IFSRC_UNKNOWN)
 {
-  gfc_actual_arglist *a;
-
   if (sym->attr.pointer)
 	{
 	  gfc_error ("The pointer object %qs at %L must have an explicit "
@@ -3724,9 +3726,12 @@ gfc_procedure_use (gfc_symbol *sym, gfc_actual_arglist
 
   dummy_args = gfc_sym_get_dummy_args (sym);
 
-  if (!compare_actual_formal (ap, dummy_args, 0, sym->attr.elemental, where))
+  /* For a statement function, check that types and type parameters of actual
+ arguments and dummy arguments match.  */
+  if (!compare_actual_formal (ap, dummy_args, 0, sym->attr.elemental,
+			  sym->attr.proc == PROC_ST_FUNCTION, where))
 return false;
-
+ 
   if (!check_intents (dummy_args, *ap))
 return false;
 
@@ -3773,7 +3778,7 @@ gfc_ppc_use (gfc_component *comp, gfc_actual_arglist *
 }
 
   if (!compare_actual_formal (ap, comp->ts.interface->formal, 0,
-			  comp->attr.elemental, where))
+			  comp->attr.elemental, false, where))
 return;
 
   check_intents (comp->ts.interface->formal, *ap);
@@ -3798,7 +3803,7 @@ gfc_arglist_matches_symbol (gfc_actual_arglist** args,
   dummy_args = gfc_sym_get_dummy_args (sym);
 
   r = !sym->attr.elemental;
-  if (compare_actual_formal (args, dummy_args, r, !r, NULL))
+  if (compare_actual_formal (args, dummy_args, r, !r, false, NULL))
 {
   check_intents (dummy_args, *args);
   if (warn_aliasing)
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c	(revision 257464)
+++ gcc/fortran/resolve.c	(working copy)
@@ -512,8 +512,11 @@ resolve_formal_arglist (gfc_symbol *proc)
 	{
 	  if (sym->as != NULL)
 	{
-	  gfc_error ("Argument %qs of statement function at %L must "
-			 "be scalar", sym->name, >declared_at);
+	  /* F03:C1263 (R1238) The function-name and each dummy-arg-name
+		 shall be specified, explicitly or implicitly, to be scalar.  */
+	  gfc_error ("Argument '%s' of statement function '%s' at %L "
+			 "must be scalar", sym->name, proc->name,
+			 >declared_at);
 	  continue;
 	}
 
Index: gcc/testsuite/gfortran.dg/statement_function_1.f90
===
--- gcc/testsuite/gfortran.dg/statement_function_1.f90	(nonexistent)
+++ 

Re: [Patch, fortran] PR84074 Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic

2018-02-11 Thread Steve Kargl
On Sun, Feb 11, 2018 at 03:08:52PM +, Paul Richard Thomas wrote:
> 
> PR fortran/84074
> * trans-expr.c (gfc_conv_derived_to_class): Set the use_offset
> flag. If the is a vector subscript or the expression is not a
> variable, make the descriptor one-based.


"If the is a" ?

> + 
> +   /* Vector array references and non-variable expressions need be
> +  coverted to one-based descriptors.  */

s/coverted/converted


OK with the above fixed.

-- 
steve


Re: [PATCH] Fix handling of arguments in statement functions

2018-02-11 Thread Steve Kargl
On Sun, Feb 11, 2018 at 01:48:10PM +0100, Dominique d'Humières wrote:
> Hi Steve,
> 
> With your patch applied to revision r257559, I get the following failures
> 
> /opt/gcc/p_work/gcc/testsuite/gfortran.dg/statement_function_3.f:5:72: 
> Warning: Obsolescent feature: Statement function at (1)
> /opt/gcc/p_work/gcc/testsuite/gfortran.dg/statement_function_3.f:3:24: Error: 
> Argument 'e' of statement function at (1) must be scalar
> compiler exited with status 1
> FAIL: gfortran.dg/statement_function_3.f   -O   (test for errors, line 5)
> FAIL: gfortran.dg/statement_function_3.f   -O  (test for excess errors)
> 

I may have posted the wrong patch or forgot to include the
diff of the file that deals with this error.

-- 
Steve


Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

2018-02-11 Thread Alexandre Oliva
On Feb 10, 2018, Jeff Law  wrote:

>> Ports call final_scan_insn with seen == NULL, and then
>> maybe_output_next_view crashes because it assumes it's
>> non-NULL.  Oops.  Fixed.
> A bit icky.  But OK.

Thanks.  Testing revealed some ports had already introduced their own
'seen' variables passed to final_scan_insn recursive calls, so I
adjusted them, and the comments to the wrapper to indicate ports should
not do that.  Here's what I checked in.


[LVU] deal with md final_scan_insn

Ports call final_scan_insn with seen == NULL, and then
maybe_output_next_view crashes because it assumes it's
non-NULL.  Oops.  Fixed.

for  gcc/ChangeLog

* final.c (final_scan_insn_1): Renamed from...
(final_scan_insn): ... this.  New wrapper, to recover
seen from the outermost call in recursive ones.
* config/sparc/sparc.c (output_return): Drop seen from call.
(output_sibcall): Likewise.
* config/visium/visium.c (output_branch): Likewise.
---
 gcc/config/sparc/sparc.c   |6 ++
 gcc/config/visium/visium.c |3 +--
 gcc/final.c|   36 +---
 3 files changed, 36 insertions(+), 9 deletions(-)

diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index 48669f177652..7126b57ba011 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -6422,7 +6422,6 @@ output_return (rtx_insn *insn)
{
  rtx_insn *delay;
  rtx pat;
- int seen;
 
  delay = NEXT_INSN (insn);
  gcc_assert (delay);
@@ -6442,7 +6441,7 @@ output_return (rtx_insn *insn)
 Make sure to output its source location first.  */
  PATTERN (delay) = gen_blockage ();
  INSN_CODE (delay) = -1;
- final_scan_insn (delay, asm_out_file, optimize, 0, );
+ final_scan_insn (delay, asm_out_file, optimize, 0, NULL);
  INSN_LOCATION (delay) = UNKNOWN_LOCATION;
 
  output_restore (pat);
@@ -6503,7 +6502,6 @@ output_sibcall (rtx_insn *insn, rtx call_operand)
{
  rtx_insn *delay;
  rtx pat;
- int seen;
 
  delay = NEXT_INSN (insn);
  gcc_assert (delay);
@@ -6514,7 +6512,7 @@ output_sibcall (rtx_insn *insn, rtx call_operand)
 Make sure to output its source location first.  */
  PATTERN (delay) = gen_blockage ();
  INSN_CODE (delay) = -1;
- final_scan_insn (delay, asm_out_file, optimize, 0, );
+ final_scan_insn (delay, asm_out_file, optimize, 0, NULL);
  INSN_LOCATION (delay) = UNKNOWN_LOCATION;
 
  output_restore (pat);
diff --git a/gcc/config/visium/visium.c b/gcc/config/visium/visium.c
index 8751156c4065..106cdaf9e3f9 100644
--- a/gcc/config/visium/visium.c
+++ b/gcc/config/visium/visium.c
@@ -3094,10 +3094,9 @@ output_branch (rtx label, const char *cond, rtx_insn 
*insn)
  if (final_sequence)
{
  rtx_insn *delay = NEXT_INSN (insn);
- int seen;
  gcc_assert (delay);
 
- final_scan_insn (delay, asm_out_file, optimize, 0, );
+ final_scan_insn (delay, asm_out_file, optimize, 0, NULL);
  PATTERN (delay) = gen_blockage ();
  INSN_CODE (delay) = -1;
}
diff --git a/gcc/final.c b/gcc/final.c
index 99a7cadd7c9f..cbebbfdf5b07 100644
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -2236,9 +2236,9 @@ asm_show_source (const char *filename, int linenum)
debug information.  We force the emission of a line note after
both NOTE_INSN_PROLOGUE_END and NOTE_INSN_FUNCTION_BEG.  */
 
-rtx_insn *
-final_scan_insn (rtx_insn *insn, FILE *file, int optimize_p ATTRIBUTE_UNUSED,
-int nopeepholes ATTRIBUTE_UNUSED, int *seen)
+static rtx_insn *
+final_scan_insn_1 (rtx_insn *insn, FILE *file, int optimize_p ATTRIBUTE_UNUSED,
+  int nopeepholes ATTRIBUTE_UNUSED, int *seen)
 {
 #if HAVE_cc0
   rtx set;
@@ -3189,6 +3189,36 @@ final_scan_insn (rtx_insn *insn, FILE *file, int 
optimize_p ATTRIBUTE_UNUSED,
 }
   return NEXT_INSN (insn);
 }
+
+/* This is a wrapper around final_scan_insn_1 that allows ports to
+   call it recursively without a known value for SEEN.  The value is
+   saved at the outermost call, and recovered for recursive calls.
+   Recursive calls MUST pass NULL, or the same pointer if they can
+   otherwise get to it.  */
+
+rtx_insn *
+final_scan_insn (rtx_insn *insn, FILE *file, int optimize_p,
+int nopeepholes, int *seen)
+{
+  static int *enclosing_seen;
+  static int recursion_counter;
+
+  gcc_assert (seen || recursion_counter);
+  gcc_assert (!recursion_counter || !seen || seen == enclosing_seen);
+
+  if (!recursion_counter++)
+enclosing_seen = seen;
+  else if (!seen)
+seen = enclosing_seen;
+
+  rtx_insn *ret = final_scan_insn_1 (insn, file, optimize_p, nopeepholes, 
seen);
+
+  if (!--recursion_counter)
+enclosing_seen = NULL;
+
+  return 

[Patch, fortran] PR84074 Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic

2018-02-11 Thread Paul Richard Thomas
Hi All,

This patch makes sure that offsets and bounds are correct in passing
derived types to class formal arrays. It is straightforward enough as
not to require explanation.

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

Paul

2018-02-11  Paul Thomas  

PR fortran/84074
* trans-expr.c (gfc_conv_derived_to_class): Set the use_offset
flag. If the is a vector subscript or the expression is not a
variable, make the descriptor one-based.

2018-02-11  Paul Thomas  

PR fortran/84074
* gfortran.dg/type_to_class_5.f03: New test.
Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c(revision 257549)
--- gcc/fortran/trans-expr.c(working copy)
*** gfc_conv_derived_to_class (gfc_se *parms
*** 547,552 
--- 547,553 
tree ctree;
tree var;
tree tmp;
+   int dim;
  
/* The derived type needs to be converted to a temporary
   CLASS object.  */
*** gfc_conv_derived_to_class (gfc_se *parms
*** 636,645 
--- 637,670 
{
  stmtblock_t block;
  gfc_init_block ();
+ gfc_ref *ref;
  
  parmse->ss = ss;
+ parmse->use_offset = 1;
  gfc_conv_expr_descriptor (parmse, e);
  
+ /* Detect any vector array references.  */
+ for (ref = e->ref; ref; ref = ref->next)
+   if (ref->type == REF_ARRAY
+   && ref->u.ar.type != AR_ELEMENT
+   && ref->u.ar.type != AR_FULL)
+ {
+   for (dim = 0; dim < ref->u.ar.dimen; dim++)
+ if (ref->u.ar.dimen_type[dim] == DIMEN_VECTOR)
+   break;
+   if (dim < ref->u.ar.dimen)
+ break;
+ }
+ 
+ /* Vector array references and non-variable expressions need be
+coverted to one-based descriptors.  */
+ if (ref || e->expr_type != EXPR_VARIABLE)
+   {
+ for (dim = 0; dim < e->rank; ++dim)
+   gfc_conv_shift_descriptor_lbound (, parmse->expr, dim,
+ gfc_index_one_node);
+   }
+ 
  if (e->rank != class_ts.u.derived->components->as->rank)
{
  gcc_assert (class_ts.u.derived->components->as->type
*** gfc_trans_assignment_1 (gfc_expr * expr1
*** 10105,10111 
   >where, msg);
}
  
!   /* Deallocate the lhs parameterized components if required.  */ 
if (dealloc && expr2->expr_type == EXPR_FUNCTION
  && !expr1->symtree->n.sym->attr.associate_var)
{
--- 10130,10136 
   >where, msg);
}
  
!   /* Deallocate the lhs parameterized components if required.  */
if (dealloc && expr2->expr_type == EXPR_FUNCTION
  && !expr1->symtree->n.sym->attr.associate_var)
{
Index: gcc/testsuite/gfortran.dg/type_to_class_5.f03
===
*** gcc/testsuite/gfortran.dg/type_to_class_5.f03   (nonexistent)
--- gcc/testsuite/gfortran.dg/type_to_class_5.f03   (working copy)
***
*** 0 
--- 1,29 
+ ! { dg-do run }
+ !
+ ! Test the fix for PR84074
+ !
+ ! Contributed by Vladimir Fuka  
+ !
+   type :: t
+   integer :: n
+   end type
+ 
+   type(t) :: array(4) = [t(1),t(2),t(3),t(4)]
+ 
+   call sub(array((/3,1/)), [3,1,0,0]) ! Does not increment any elements of 
'array'.
+   call sub(array(1:3:2), [1,3,0,0])
+   call sub(array(3:1:-2), [4,2,0,0])
+   call sub(array, [3,2,5,4])  ! Elements 1 and 3 should have been 
incremented twice.
+ 
+ contains
+ 
+   subroutine sub(a, iarray)
+ class(t) :: a(:)
+ integer :: iarray(4)
+ integer :: i
+ do i=1,size(a)
+ if (a(i)%n .ne. iarray(i)) call abort
+ a(i)%n = a(i)%n+1
+ enddo
+   end subroutine
+ end program


Re: [Patch, Fortran] PR 84273: Reject allocatable passed-object dummy argument (proc_ptr_47.f90)

2018-02-11 Thread Janus Weil
Hi guys,

2018-02-10 12:46 GMT+01:00 Paul Richard Thomas :
> As Steve said, welcome back!

thanks for the warm welcome :)


> I hope that you will post the news of this fix and the correction of
> the testcases on clf. Talking of which, have you posted the problems
> that others have found as PRs?

Well, I have opened PR 84094 as a collector for such things (and a few
dependencies). Neil Carson has put a great amount of work into
analyzing some of the issues that came up and compiled a very helpful
list at:

https://github.com/nncarlson/gfortran.dg/issues

I have not sifted through the extensive c.l.f. thread (which may
contain further possible issues posted by people who lack the skills
to use any kind of bug tracker), any I don't have the intention
(read:time) to do that.


> It was one of my long deferred tasks to make a start on validating the
> testsuite and to remove non-standard features.

The biggest issue in this respect is probably the frequent use of the
non-std "call abort". All of those could simply be replaced by "stop
1" AFAICS, and if there is consensus that this is a useful thing to
do, I'd be willing to take care of it. (Feedback welcome here).

Cheers,
Janus


Re: [PATCH] Fix handling of arguments in statement functions

2018-02-11 Thread Dominique d'Humières
Hi Steve,

With your patch applied to revision r257559, I get the following failures

/opt/gcc/p_work/gcc/testsuite/gfortran.dg/statement_function_3.f:5:72: Warning: 
Obsolescent feature: Statement function at (1)
/opt/gcc/p_work/gcc/testsuite/gfortran.dg/statement_function_3.f:3:24: Error: 
Argument 'e' of statement function at (1) must be scalar
compiler exited with status 1
FAIL: gfortran.dg/statement_function_3.f   -O   (test for errors, line 5)
FAIL: gfortran.dg/statement_function_3.f   -O  (test for excess errors)

The error still occurs at line 3

/opt/gcc/work/gcc/testsuite/gfortran.dg/statement_function_3.f:3:24:

   subroutine phtod(e,n,i,h)
1
Error: Argument 'e' of statement function at (1) must be scalar

and not at line 5.

IMO there should be no error with the test since e(i-1) is a scalar in 

h = hstar(e(i-1), a)

but 

h = hstar(e, a)

should give an error.

Thanks for working on this issue.

Dominique



New Swedish PO file for 'gcc' (version 8.1-b20180128)

2018-02-11 Thread Translation Project Robot
Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators.  The file is available at:

http://translationproject.org/latest/gcc/sv.po

(This file, 'gcc-8.1-b20180128.sv.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.