[PATCH, libphobos] Committed add missing PWD_COMMAND to Makefile.

[Iain Buclaw]

Hi,

This patch adds PWD_COMMAND to libphobos/testsuite/Makefile.am, which
is used by the parallelized testing machinery.  Noticed by some errors
when compiling from a newly set-up build server.

touch: cannot touch '/libphobos-parallel/finished': No such file or directory
make[3]: *** [check-DEJAGNUlibphobos7] Error 1
make[3]: Leaving directory
`/home/runner/gcc/build/x86_64-linux-gnu/libphobos/testsuite'
mv: cannot stat 'libphobos9/libphobos.sum': No such file or directory
mv: cannot stat 'libphobos9/libphobos.log': No such file or directory
mv: cannot stat 'libphobos10/libphobos.sum': No such file or directory
mv: cannot stat 'libphobos10/libphobos.log': No such file or directory

Committed to trunk as r270566.

-- 
Iain
---
libphobos/ChangeLog:

2019-04-25  Iain Buclaw  

* testsuite/Makefile.am: Set PWD_COMMAND.
* testsuite/Makefile.in: Regenerate.
---
diff --git a/libphobos/testsuite/Makefile.am b/libphobos/testsuite/Makefile.am
index 55b2ba42640..70b105d4014 100644
--- a/libphobos/testsuite/Makefile.am
+++ b/libphobos/testsuite/Makefile.am
@@ -27,6 +27,8 @@ _RUNTEST = $(shell if test -f $(top_srcdir)/../dejagnu/runtest; then \
 	 echo $(top_srcdir)/../dejagnu/runtest; else echo runtest; fi)
 RUNTESTDEFAULTFLAGS = --tool $$tool --srcdir $$srcdir
 
+PWD_COMMAND = $${PWDCMD-pwd}
+
 check_p_subno=$(word 2,$(subst _, ,$*))
 check_p_numbers0:=1 2 3 4 5 6 7 8 9
 check_p_numbers1:=0 $(check_p_numbers0)
diff --git a/libphobos/testsuite/Makefile.in b/libphobos/testsuite/Makefile.in
index 26ed875d964..efbd884d7ae 100644
--- a/libphobos/testsuite/Makefile.in
+++ b/libphobos/testsuite/Makefile.in
@@ -289,6 +289,7 @@ _RUNTEST = $(shell if test -f $(top_srcdir)/../dejagnu/runtest; then \
 	 echo $(top_srcdir)/../dejagnu/runtest; else echo runtest; fi)
 
 RUNTESTDEFAULTFLAGS = --tool $$tool --srcdir $$srcdir
+PWD_COMMAND = $${PWDCMD-pwd}
 check_p_subno = $(word 2,$(subst _, ,$*))
 check_p_numbers0 := 1 2 3 4 5 6 7 8 9
 check_p_numbers1 := 0 $(check_p_numbers0)

Re: [PATCH v2] Add error message for target_clones and AVX512 ISAs (PR target/89929).

[Martin Liška]

On 4/23/19 10:29 AM, Martin Liška wrote:
> On 4/18/19 7:44 PM, H.J. Lu wrote:
>> On Thu, Apr 18, 2019 at 4:07 AM Martin Liška  wrote:
>>>
>>> Hi.
>>>
>>> I'm sending updated version of that patch. The patch rejects usage of 
>>> AVX512 ISAs (except AVX512F)
>>> for target attribute for C++ multiversioning and for target_clone attribute.
>>>
>>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>>
>>> Ready to be installed?
>>> Thanks,
>>> Martin
>>
>> Your patch doesn't handle cmov nor gfni properly, which aren't AVX512.
>> I prefer this patch.
>>
> 
> I like the patch. Thanks for working on that.
> 
> Martin
> 
> 

Btw. can we get that patch into GCC 9.1?

Adding port maintainers to CC.

Martin

Re: [PATCH v2] Add error message for target_clones and AVX512 ISAs (PR target/89929).

[Uros Bizjak]

On Thu, Apr 25, 2019 at 9:51 AM Martin Liška  wrote:

> On 4/23/19 10:29 AM, Martin Liška wrote:
> > On 4/18/19 7:44 PM, H.J. Lu wrote:
> >> On Thu, Apr 18, 2019 at 4:07 AM Martin Liška  wrote:
> >>>
> >>> Hi.
> >>>
> >>> I'm sending updated version of that patch. The patch rejects usage of
> AVX512 ISAs (except AVX512F)
> >>> for target attribute for C++ multiversioning and for target_clone
> attribute.
> >>>
> >>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >>>
> >>> Ready to be installed?
> >>> Thanks,
> >>> Martin
> >>
> >> Your patch doesn't handle cmov nor gfni properly, which aren't AVX512.
> >> I prefer this patch.
> >>
> >
> > I like the patch. Thanks for working on that.
> >
> > Martin
> >
> >
>
> Btw. can we get that patch into GCC 9.1?
>
> Adding port maintainers to CC.
>

HJ knows ISA interdependencies, and the benefit of the patch outweights the
(small) risk, so from the maintaner PoV, OK for the mainline unless RM
vetoes the decision soon. HJ, please double check the patch for eventual
inconsistencies or possible regressions before committing.

Thanks,
Uros.

[C PATCH] Fix up C loop construct debug info without -gno-statement-frontiers (PR debug/90197)

[Jakub Jelinek]

Hi!

The introduction of -gstatement-frontiers (and making it the default)
regressed debug info experience on the attached testcases (not including
in the testsuite, as not sure how to model that in the guality testsuite).
The current behavior is that
b test
r
n
n
n
shows the first iteration and then executes the rest of the loop iteration
in one go and breaks next time on __libc_start_main.

The following patch fixes that by adding DEBUG_BEGIN_STMTs not just at the
start of the loop, but also at the start of the incr-expr and cond-expr;
the DWARF standard says that is_stmt 1 is a recommended breakpoint location,
doesn't necessarily mean full statement, but also a part of it if it is a
recommended breakpoint location there.  And the loop expressions clearly
must be recommended breakpoint locations.

The difference in *.gimple dumps on the 3 testcases is:
--- pr90197-1.c.005t.gimple_2019-04-25 10:55:55.087978371 +0200
+++ pr90197-1.c.005t.gimple 2019-04-25 10:56:08.845759542 +0200
@@ -7,23 +7,25 @@ test (unsigned int * dst, unsigned int b
 
 # DEBUG BEGIN_STMT
 i = 0;
 goto ;
 :
 # DEBUG BEGIN_STMT
 _1 = (long unsigned int) i;
 _2 = _1 * 4;
 _3 = dst + _2;
 *_3 = base;
+# DEBUG BEGIN_STMT
 i = i + 1;
 base = base + 15;
 :
+# DEBUG BEGIN_STMT
 if (i < count) goto ; else goto ;
 :
   }
 }
 
 
 main ()
 {
   int D.1919;
 
--- pr90197-2.c.005t.gimple_2019-04-25 10:55:55.192976701 +0200
+++ pr90197-2.c.005t.gimple 2019-04-25 10:56:08.925758270 +0200
@@ -10,20 +10,21 @@ test (unsigned int * dst, unsigned int b
   :
   # DEBUG BEGIN_STMT
   base = base + 15;
   i.0_1 = i;
   i = i.0_1 + 1;
   _2 = (long unsigned int) i.0_1;
   _3 = _2 * 4;
   _4 = dst + _3;
   *_4 = base;
   :
+  # DEBUG BEGIN_STMT
   if (i < count) goto ; else goto ;
   :
 }
 
 
 main ()
 {
   int D.1919;
 
   {
--- pr90197-3.c.005t.gimple_2019-04-25 10:55:55.298975015 +0200
+++ pr90197-3.c.005t.gimple 2019-04-25 10:56:09.000757077 +0200
@@ -8,20 +8,21 @@ test (unsigned int * dst, unsigned int b
   # DEBUG BEGIN_STMT
   :
   # DEBUG BEGIN_STMT
   base = base + 15;
   i.0_1 = i;
   i = i.0_1 + 1;
   _2 = (long unsigned int) i.0_1;
   _3 = _2 * 4;
   _4 = dst + _3;
   *_4 = base;
+  # DEBUG BEGIN_STMT
   if (i < count) goto ; else goto ;
   :
 }
 
 
 main ()
 {
   int D.1918;
 
   {
so it basically adds a DEBUG_BEGIN_STMT for the increment expression
in for (if not empty) and for the condition in all kinds of loop (both if it
is empty and if it is not).

The assembly changes are:
--- pr90197-1.s12019-04-25 11:09:54.749622921 +0200
+++ pr90197-1.s22019-04-25 11:09:46.569753036 +0200
@@ -13,6 +13,7 @@ test:
.loc 1 5 3
 .LBB2:
.loc 1 5 8
+   .loc 1 5 19
.loc 1 5 3 is_stmt 0
testl   %edx, %edx
jle .L1
@@ -27,11 +28,13 @@ test:
.loc 1 6 5 is_stmt 1 discriminator 3
.loc 1 6 12 is_stmt 0 discriminator 3
movl%esi, (%rdi)
-   .loc 1 5 40 discriminator 3
+   .loc 1 5 30 is_stmt 1 discriminator 3
+   .loc 1 5 40 is_stmt 0 discriminator 3
addl$15, %esi
 .LVL2:
+   .loc 1 5 19 is_stmt 1 discriminator 3
addq$4, %rdi
-   .loc 1 5 3 discriminator 3
+   .loc 1 5 3 is_stmt 0 discriminator 3
cmpl%eax, %esi
jne .L3
 .L1:
--- pr90197-2.s12019-04-25 11:09:54.791622253 +0200
+++ pr90197-2.s22019-04-25 11:09:46.611752367 +0200
@@ -12,7 +12,7 @@ test:
 .LVL0:
.loc 1 5 3
.loc 1 6 3
-   .loc 1 6 9 is_stmt 0
+   .loc 1 6 9
testl   %edx, %edx
jle .L1
movl%edx, %eax
@@ -23,18 +23,18 @@ test:
.p2align 4,,10
.p2align 3
 .L3:
-   .loc 1 7 5 is_stmt 1
+   .loc 1 7 5
.loc 1 7 22 is_stmt 0
addl$15, %esi
 .LVL2:
addq$4, %rdi
.loc 1 7 14
movl%esi, -4(%rdi)
-   .loc 1 6 9
+   .loc 1 6 9 is_stmt 1
cmpl%eax, %esi
jne .L3
 .L1:
-   .loc 1 8 1
+   .loc 1 8 1 is_stmt 0
ret
.cfi_endproc
 .LFE0:
--- pr90197-3.s12019-04-25 11:09:54.828621665 +0200
+++ pr90197-3.s22019-04-25 11:09:46.647751794 +0200
@@ -24,9 +24,10 @@ test:
 .LVL2:
.loc 1 7 14 discriminator 1
movl%esi, (%rdi,%rax,4)
+   .loc 1 8 9 is_stmt 1 discriminator 1
addq$1, %rax
 .LVL3:
-   .loc 1 8 3 discriminator 1
+   .loc 1 8 3 is_stmt 0 discriminator 1
cmpl%eax, %edx
jg  .L2
.loc 1 9 1

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

I'll work on a C++ FE version of this next (needed as well).

2019-04-25  Jakub Jelinek  

PR debug/90197
* c-tree.h (c_finish_loop): Add 2 further location_t arguments.
* c-parser.c (c_parser_while_statement): Adjust c_finish_loop caller.
(c_parser_do_statement): Likewise.
(c_parser_for_statement): Likewi

Re: [PATCH, netbsd] Define TARGET_D_CRITSEC_SIZE for D language

[Iain Buclaw]

On Wed, 24 Apr 2019 at 15:28, Kamil Rytarowski  wrote:
>
> On 24.04.2019 13:25, Iain Buclaw wrote:
> > On Wed, 24 Apr 2019 at 13:03, Kamil Rytarowski  wrote:
> >>
> >> On 24.04.2019 03:30, Iain Buclaw wrote:
> >>> On Wed, 24 Apr 2019 at 01:56, Kamil Rytarowski  wrote:
> 
>  On 24.04.2019 01:13, Iain Buclaw wrote:
> >>> https://explore.dgnu.org/z/U29cni
> >>>
> >>> I'll add special handling for them, but otherwise 48/28 looks like the
> >>> reasonable default.
> >>>
> >>
>
> OK, so please go for this.
>

On inspection, it looks like there's no current configuration handling
of aarch64-netbsd, hppa-netbsd, nor hppa64-netbsd.

I've updated the patch to add them, and I've tested with
config-list.mk LIST="aarch64-netbsd hppa-netbsd hppa64-netbsd",
however I don't think that the changes to config.gcc should be
included unless it has been ported proper.

-- 
Iain
---
gcc/ChangeLog:

2019-04-25  Iain Buclaw  

* config.gcc (aarch64*-*-netbsd*, hppa*64*-*-netbsd*,
hppa*-*-netbsd*): Add configurations.
* config/aarch64/aarch64-netbsd.h: New file.
* config/netbsd-d.c (netbsd_d_critsec_size): New function.
(TARGET_D_CRITSEC_SIZE): Define as netbsd_d_critsec_size.
* config/pa/pa-netbsd.h: New file.

---
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 09fb9ecd2cd..c2d77d60efc 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1050,6 +1050,10 @@ aarch64*-*-linux*)
 	done
 	TM_MULTILIB_CONFIG=`echo $TM_MULTILIB_CONFIG | sed 's/^,//'`
 	;;
+aarch64*-*-netbsd*)
+	tm_file="${tm_file} elfos.h aarch64/aarch64-elf.h aarch64/aarch64-netbsd.h"
+	tmake_file="${tmake_file} aarch64/t-aarch64"
+	;;
 alpha*-*-linux*)
 	tm_file="elfos.h ${tm_file} alpha/elf.h alpha/linux.h alpha/linux-elf.h glibc-stdint.h"
 	tmake_file="${tmake_file} alpha/t-linux alpha/t-alpha"
@@ -1476,6 +1480,16 @@ hppa*-*-linux*)
 	tmake_file="${tmake_file} pa/t-pa pa/t-linux"
 	d_target_objs="${d_target_objs} pa-d.o"
 	;;
+hppa*64*-*-netbsd*)
+	tm_file="pa/pa64-start.h ${tm_file} elfos.h pa/pa-netbsd.h pa/pa32-regs.h"
+	tmake_file="${tmake_file} pa/t-pa"
+	d_target_objs="${d_target_objs} pa-d.o"
+	;;
+hppa*-*-netbsd*)
+	tm_file="${tm_file} elfos.h pa/pa-netbsd.h pa/pa32-regs.h"
+	tmake_file="${tmake_file} pa/t-pa"
+	d_target_objs="${d_target_objs} pa-d.o"
+	;;
 hppa*-*-openbsd*)
 	target_cpu_default="MASK_PA_11"
 	tm_file="${tm_file} dbxelf.h elfos.h openbsd.h openbsd-stdint.h openbsd-libpthread.h \
diff --git a/gcc/config/aarch64/aarch64-netbsd.h b/gcc/config/aarch64/aarch64-netbsd.h
new file mode 100644
index 000..749dadaddec
--- /dev/null
+++ b/gcc/config/aarch64/aarch64-netbsd.h
@@ -0,0 +1,25 @@
+/* Definitions for AArch64 running NetBSD
+   Copyright (C) 2019 Free Software Foundation, Inc.
+
+   This file is part of GCC.
+
+   GCC 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.
+
+   GCC 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 GCC; see the file COPYING3.  If not see
+   .  */
+
+#ifndef GCC_AARCH64_NETBSD_H
+#define GCC_AARCH64_NETBSD_H
+
+#define NETBSD_TARGET_D_CRITSEC_SIZE 40
+
+#endif  /* GCC_AARCH64_NETBSD_H */
diff --git a/gcc/config/netbsd-d.c b/gcc/config/netbsd-d.c
index 76342aacae3..90e87d04012 100644
--- a/gcc/config/netbsd-d.c
+++ b/gcc/config/netbsd-d.c
@@ -28,6 +28,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "d/d-target.h"
 #include "d/d-target-def.h"
 
+/* Implement TARGET_D_OS_VERSIONS for NetBSD targets.  */
+
 static void
 netbsd_d_os_builtins (void)
 {
@@ -35,7 +37,23 @@ netbsd_d_os_builtins (void)
   d_add_builtin_version ("NetBSD");
 }
 
+/* Implement TARGET_D_CRITSEC_SIZE for NetBSD targets.  */
+
+static unsigned
+netbsd_d_critsec_size (void)
+{
+  /* This is the sizeof pthread_mutex_t.  */
+#ifdef NETBSD_TARGET_D_CRITSEC_SIZE
+  return NETBSD_TARGET_D_CRITSEC_SIZE;
+#else
+  return (POINTER_SIZE == 64) ? 48 : 28;
+#endif
+}
+
 #undef TARGET_D_OS_VERSIONS
 #define TARGET_D_OS_VERSIONS netbsd_d_os_builtins
 
+#undef TARGET_D_CRITSEC_SIZE
+#define TARGET_D_CRITSEC_SIZE netbsd_d_critsec_size
+
 struct gcc_targetdm targetdm = TARGETDM_INITIALIZER;
diff --git a/gcc/config/pa/pa-netbsd.h b/gcc/config/pa/pa-netbsd.h
new file mode 100644
index 000..11de05452d9
--- /dev/null
+++ b/gcc/config/pa/pa-netbsd.h
@@ -0,0 +1,25 @@
+/* Definitions for PA_RISC running NetBSD
+   Copyright (C) 2019 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as publish

Re: [C PATCH] Fix up C loop construct debug info without -gno-statement-frontiers (PR debug/90197)

[Richard Biener]

On April 25, 2019 11:13:34 AM GMT+02:00, Jakub Jelinek  wrote:
>Hi!
>
>The introduction of -gstatement-frontiers (and making it the default)
>regressed debug info experience on the attached testcases (not
>including
>in the testsuite, as not sure how to model that in the guality
>testsuite).
>The current behavior is that
>b test
>r
>n
>n
>n
>shows the first iteration and then executes the rest of the loop
>iteration
>in one go and breaks next time on __libc_start_main.
>
>The following patch fixes that by adding DEBUG_BEGIN_STMTs not just at
>the
>start of the loop, but also at the start of the incr-expr and
>cond-expr;
>the DWARF standard says that is_stmt 1 is a recommended breakpoint
>location,
>doesn't necessarily mean full statement, but also a part of it if it is
>a
>recommended breakpoint location there.  And the loop expressions
>clearly
>must be recommended breakpoint locations.
>
>The difference in *.gimple dumps on the 3 testcases is:
>--- pr90197-1.c.005t.gimple_   2019-04-25 10:55:55.087978371 +0200
>+++ pr90197-1.c.005t.gimple2019-04-25 10:56:08.845759542 +0200
>@@ -7,23 +7,25 @@ test (unsigned int * dst, unsigned int b
> 
> # DEBUG BEGIN_STMT
> i = 0;
> goto ;
> :
> # DEBUG BEGIN_STMT
> _1 = (long unsigned int) i;
> _2 = _1 * 4;
> _3 = dst + _2;
> *_3 = base;
>+# DEBUG BEGIN_STMT
> i = i + 1;
> base = base + 15;
> :
>+# DEBUG BEGIN_STMT
> if (i < count) goto ; else goto ;
> :
>   }
> }
> 
> 
> main ()
> {
>   int D.1919;
> 
>--- pr90197-2.c.005t.gimple_   2019-04-25 10:55:55.192976701 +0200
>+++ pr90197-2.c.005t.gimple2019-04-25 10:56:08.925758270 +0200
>@@ -10,20 +10,21 @@ test (unsigned int * dst, unsigned int b
>   :
>   # DEBUG BEGIN_STMT
>   base = base + 15;
>   i.0_1 = i;
>   i = i.0_1 + 1;
>   _2 = (long unsigned int) i.0_1;
>   _3 = _2 * 4;
>   _4 = dst + _3;
>   *_4 = base;
>   :
>+  # DEBUG BEGIN_STMT
>   if (i < count) goto ; else goto ;
>   :
> }
> 
> 
> main ()
> {
>   int D.1919;
> 
>   {
>--- pr90197-3.c.005t.gimple_   2019-04-25 10:55:55.298975015 +0200
>+++ pr90197-3.c.005t.gimple2019-04-25 10:56:09.000757077 +0200
>@@ -8,20 +8,21 @@ test (unsigned int * dst, unsigned int b
>   # DEBUG BEGIN_STMT
>   :
>   # DEBUG BEGIN_STMT
>   base = base + 15;
>   i.0_1 = i;
>   i = i.0_1 + 1;
>   _2 = (long unsigned int) i.0_1;
>   _3 = _2 * 4;
>   _4 = dst + _3;
>   *_4 = base;
>+  # DEBUG BEGIN_STMT
>   if (i < count) goto ; else goto ;
>   :
> }
> 
> 
> main ()
> {
>   int D.1918;
> 
>   {
>so it basically adds a DEBUG_BEGIN_STMT for the increment expression
>in for (if not empty) and for the condition in all kinds of loop (both
>if it
>is empty and if it is not).
>
>The assembly changes are:
>--- pr90197-1.s1   2019-04-25 11:09:54.749622921 +0200
>+++ pr90197-1.s2   2019-04-25 11:09:46.569753036 +0200
>@@ -13,6 +13,7 @@ test:
>   .loc 1 5 3
> .LBB2:
>   .loc 1 5 8
>+  .loc 1 5 19
>   .loc 1 5 3 is_stmt 0
>   testl   %edx, %edx
>   jle .L1
>@@ -27,11 +28,13 @@ test:
>   .loc 1 6 5 is_stmt 1 discriminator 3
>   .loc 1 6 12 is_stmt 0 discriminator 3
>   movl%esi, (%rdi)
>-  .loc 1 5 40 discriminator 3
>+  .loc 1 5 30 is_stmt 1 discriminator 3
>+  .loc 1 5 40 is_stmt 0 discriminator 3
>   addl$15, %esi
> .LVL2:
>+  .loc 1 5 19 is_stmt 1 discriminator 3
>   addq$4, %rdi
>-  .loc 1 5 3 discriminator 3
>+  .loc 1 5 3 is_stmt 0 discriminator 3
>   cmpl%eax, %esi
>   jne .L3
> .L1:
>--- pr90197-2.s1   2019-04-25 11:09:54.791622253 +0200
>+++ pr90197-2.s2   2019-04-25 11:09:46.611752367 +0200
>@@ -12,7 +12,7 @@ test:
> .LVL0:
>   .loc 1 5 3
>   .loc 1 6 3
>-  .loc 1 6 9 is_stmt 0
>+  .loc 1 6 9
>   testl   %edx, %edx
>   jle .L1
>   movl%edx, %eax
>@@ -23,18 +23,18 @@ test:
>   .p2align 4,,10
>   .p2align 3
> .L3:
>-  .loc 1 7 5 is_stmt 1
>+  .loc 1 7 5
>   .loc 1 7 22 is_stmt 0
>   addl$15, %esi
> .LVL2:
>   addq$4, %rdi
>   .loc 1 7 14
>   movl%esi, -4(%rdi)
>-  .loc 1 6 9
>+  .loc 1 6 9 is_stmt 1
>   cmpl%eax, %esi
>   jne .L3
> .L1:
>-  .loc 1 8 1
>+  .loc 1 8 1 is_stmt 0
>   ret
>   .cfi_endproc
> .LFE0:
>--- pr90197-3.s1   2019-04-25 11:09:54.828621665 +0200
>+++ pr90197-3.s2   2019-04-25 11:09:46.647751794 +0200
>@@ -24,9 +24,10 @@ test:
> .LVL2:
>   .loc 1 7 14 discriminator 1
>   movl%esi, (%rdi,%rax,4)
>+  .loc 1 8 9 is_stmt 1 discriminator 1
>   addq$1, %rax
> .LVL3:
>-  .loc 1 8 3 discriminator 1
>+  .loc 1 8 3 is_stmt 0 discriminator 1
>   cmpl%eax, %edx
>   jg  .L2
>   .loc 1 9 1
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

So if you put a breakpoint on the for line is the behavior after the patch now 
the same as before stmt frontiers if you do 'continue' repeatedly? 

Richard. 

>

[PATCH, libphobos] Implement GCC emutls in druntime

[Johannes Pfau]

This adds emulated TLS support to druntime.
The main problem here is that the D garbage collector needs
to be able to scan the TLS memory for pointers, which is not
possible with the current libgcc implementation.

This therefore reimplements the libgcc emutls
support (__emutls_get_address, ...) in druntime, taking
care to expose an interface for the GC to scan memory
(_d_emutls_scan). Due to the library link order, in most
cases D code will corrently call the implementation in
druntime. Where this does not work is if a C program
loads a D library, then the D library will continue to
use the libgcc implementation. This can be fixed in
GCC 10 in various ways, but for now this patch
will allow most use cases for MinGW, OSX and other
emutls targets to work.

In section code, the  _d_emutls_scan function and
_d_emutls_destroy functions need to be called. This
patch implements this for the elf_shared sections code.

Bootstrapped on x86_64 linux with --disable-tls, checked
testsuite with --disable-tls and without. Initial review
on https://github.com/D-Programming-GDC/gcc/pull/13


libphobos/ChangeLog:

2019-04-25  Johannes Pfau  

* libdruntime/Makefile.am: Add emutls and gthread files.
* libdruntime/Makefile.in: Regenerate.
* libdruntime/gcc/emutls.d: New file. Implement GC-compatible emutls.
* libdruntime/gcc/gthread.d: New file.
* libdruntime/gcc/sections/elf_shared.d: Integrate emutls support.
* testsuite/libphobos.allocations/tls_gc_integration.d: New test for 
TLS.

---
 libphobos/libdruntime/Makefile.am |   3 +-
 libphobos/libdruntime/Makefile.in |  13 +-
 libphobos/libdruntime/gcc/emutls.d| 316 ++
 libphobos/libdruntime/gcc/gthread.d   | 127 +++
 .../libdruntime/gcc/sections/elf_shared.d |  89 +++--
 .../tls_gc_integration.d  |  50 +++
 6 files changed, 561 insertions(+), 37 deletions(-)
 create mode 100644 libphobos/libdruntime/gcc/emutls.d
 create mode 100644 libphobos/libdruntime/gcc/gthread.d
 create mode 100644 
libphobos/testsuite/libphobos.allocations/tls_gc_integration.d

diff --git a/libphobos/libdruntime/Makefile.am 
b/libphobos/libdruntime/Makefile.am
index b981f233d71..bf9bff095ca 100644
--- a/libphobos/libdruntime/Makefile.am
+++ b/libphobos/libdruntime/Makefile.am
@@ -161,7 +161,8 @@ DRUNTIME_DSOURCES = core/atomic.d core/attribute.d 
core/bitop.d \
core/sync/config.d core/sync/exception.d core/sync/mutex.d \
core/sync/rwmutex.d core/sync/semaphore.d core/thread.d core/time.d \
core/vararg.d gcc/attribute.d gcc/backtrace.d gcc/builtins.d gcc/deh.d \
-   gcc/sections/android.d gcc/sections/elf_shared.d gcc/sections/osx.d \
+   gcc/emutls.d gcc/gthread.d gcc/sections/android.d \
+   gcc/sections/elf_shared.d gcc/sections/osx.d \
gcc/sections/package.d gcc/sections/win32.d gcc/sections/win64.d \
gcc/unwind/arm.d gcc/unwind/arm_common.d gcc/unwind/c6x.d \
gcc/unwind/generic.d gcc/unwind/package.d gcc/unwind/pe.d object.d \
diff --git a/libphobos/libdruntime/Makefile.in 
b/libphobos/libdruntime/Makefile.in
index eb290b6a14f..19ee94fc370 100644
--- a/libphobos/libdruntime/Makefile.in
+++ b/libphobos/libdruntime/Makefile.in
@@ -203,10 +203,10 @@ am__objects_1 = core/atomic.lo core/attribute.lo 
core/bitop.lo \
core/sync/exception.lo core/sync/mutex.lo core/sync/rwmutex.lo \
core/sync/semaphore.lo core/thread.lo core/time.lo \
core/vararg.lo gcc/attribute.lo gcc/backtrace.lo \
-   gcc/builtins.lo gcc/deh.lo gcc/sections/android.lo \
-   gcc/sections/elf_shared.lo gcc/sections/osx.lo \
-   gcc/sections/package.lo gcc/sections/win32.lo \
-   gcc/sections/win64.lo gcc/unwind/arm.lo \
+   gcc/builtins.lo gcc/deh.lo gcc/emutls.lo gcc/gthread.lo \
+   gcc/sections/android.lo gcc/sections/elf_shared.lo \
+   gcc/sections/osx.lo gcc/sections/package.lo \
+   gcc/sections/win32.lo gcc/sections/win64.lo gcc/unwind/arm.lo \
gcc/unwind/arm_common.lo gcc/unwind/c6x.lo \
gcc/unwind/generic.lo gcc/unwind/package.lo gcc/unwind/pe.lo \
object.lo rt/aApply.lo rt/aApplyR.lo rt/aaA.lo rt/adi.lo \
@@ -757,7 +757,8 @@ DRUNTIME_DSOURCES = core/atomic.d core/attribute.d 
core/bitop.d \
core/sync/config.d core/sync/exception.d core/sync/mutex.d \
core/sync/rwmutex.d core/sync/semaphore.d core/thread.d core/time.d \
core/vararg.d gcc/attribute.d gcc/backtrace.d gcc/builtins.d gcc/deh.d \
-   gcc/sections/android.d gcc/sections/elf_shared.d gcc/sections/osx.d \
+   gcc/emutls.d gcc/gthread.d gcc/sections/android.d \
+   gcc/sections/elf_shared.d gcc/sections/osx.d \
gcc/sections/package.d gcc/sections/win32.d gcc/sections/win64.d \
gcc/unwind/arm.d gcc/unwind/arm_common.d gcc/unwind/c6x.d \
gcc/unwind/generic.d gcc/unwind/package.d gcc/unwind/pe.d object.d \
@@ -1104,6 +1105,8 @@ gcc/attribute.

Re: [C PATCH] Fix up C loop construct debug info without -gno-statement-frontiers (PR debug/90197)

[Jakub Jelinek]

On Thu, Apr 25, 2019 at 12:04:24PM +0200, Richard Biener wrote:
> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> So if you put a breakpoint on the for line is the behavior after the patch
> now the same as before stmt frontiers if you do 'continue' repeatedly?

The cc1 behavior before the patch with -g -O2 -gno-statement-frontiers
is the same as patched cc1 with -g -O2 in both the
b test; r; n; n; n; n; n; n
behavior as well as in
// line number depending on the test - -1, -2, -3
b {5,6,8}; r; c
The latter in the for and while loops it breaks just once and continue runs
till end of program; I think the behavior of gdb here is that only the very
first breakpoint on that particular line counts, not the others.
For do while loop where the break is on the condition line, both unpatched
-gno-statement-frontiers and patched without that break on every iteration
on the condition.
Now, if the for statement has the condition and increment on separate lines,
then again both unpatched -gno-statement-frontiers and patched without
if the breakpoint is put on the condition or increment lines rather than the
first one will break on every iteration.

Jakub

[PR90247] Reconsider OpenACC implicit data attributes for pointers (was: [og7] Enable 0-length array data mappings for implicit data clauses)

[Thomas Schwinge]

Hi!

On Wed, 11 Oct 2017 07:31:04 -0700, Cesar Philippidis  
wrote:
> I've pushed this patch to openacc-gcc-7-branch which teaches the
> gimplifier how to create 0-length arrays mappings for certain pointer
> and reference typed variables. This is necessary to satisfy the implicit
> expectation in OpenACC where the user considers pointer variables used
> like arrays as having array types.
> 
> In OpenACC, pointers variables officially classified as scalar values,
> which requires the content of the scalar to be mapped verbatim onto the
> accelerator (i.e., the host pointer doesn't get remapped to a device
> address on the accelerator). However, as mentioned above, a lot of users
> think that pointers used like arrays are arrays and therefore expect
> things such as
> 
>   int *p = ...
> 
>   #pragma acc enter data copyin (p[0:100])
> 
>   #pragma acc parallel loop
>   for (i = ...)
>   {
> ... p[i] ...
>   }
> 
> to work as if 'p' were an array.

So you're proposing to change GCC's implementation to deviate from (at
least our current reading of) the OpenACC specification.  I filed
 "Reconsider OpenACC implicit data
attributes for pointers".


> Note that this patch does not do
> anything special with dynamic arrays. E.g.
> 
>   int *p = (int *) malloc ...
> 
>   #pragma acc parallel loop
>   for (i = ...)
>   {
> ... p[i] ...
>   }
> 
> In this case, by virtue of being a 0-length array mapping, p will be
> transferred to the accelerator with the host value of &p[0].

(Shouldn't this be translated into 'NULL' then, according to the OpenMP
"zero-length array section" rules?)

> I've seen
> another compiler which goes through the trouble of mapping the dynamic
> array to the accelerator automatically, but that's beyond the scope of
> this patch.

ACK.


Some quick patch review:

> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c
> @@ -6994,7 +6994,12 @@ oacc_default_clause (struct gimplify_omp_ctx *ctx, 
> tree decl, unsigned flags)
>  case ORT_ACC_PARALLEL:
>rkind = "parallel";

Why would this apply only for the OpenACC 'parallel' construct, but not
for other OpenACC compute constructs?  (This seems inconsistent, just
plain wrong.)

>  
> -  if (is_private)
> +  if (TREE_CODE (type) == REFERENCE_TYPE
> +   && TREE_CODE (TREE_TYPE (type)) == POINTER_TYPE)
> + flags |= GOVD_MAP | GOVD_MAP_0LEN_ARRAY;
> +  else if (!lang_GNU_Fortran () && TREE_CODE (type) == POINTER_TYPE)
> + flags |= GOVD_MAP | GOVD_MAP_0LEN_ARRAY;
> +  else if (is_private)
>   flags |= GOVD_FIRSTPRIVATE;
>else if (on_device || declared)
>   flags |= GOVD_MAP;

The casual reader has no chance to understand that logic, what these two
'if' conditions actually mean.  There are no comments added to the source
code describing what this is about, why these 'if' cases are handled
specially.  There is nothing added to the documentation about the
non-standard behavior (implementation-defined difference from the
official OpenACC specification).

> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/fp-dyn-arrays.c

This is just one basic execution test case (basically, "my test program X
now works"), which is insufficient for such a change.

> @@ -0,0 +1,42 @@
> +/* Expect dynamic arrays to be mapped on the accelerator via
> +   GOMP_MAP_0LEN_ARRAY.  */
> +
> +#include 
> +#include 
> +#include 
> +
> +int
> +main ()
> +{
> +  const int n = 1000;
> +  int *a, *b, *c, *d, i;
> +
> +  d = (int *) 12345;
> +  a = (int *) malloc (sizeof (int) * n);
> +  b = (int *) malloc (sizeof (int) * n);
> +  c = (int *) malloc (sizeof (int) * n);
> +
> +  for (i = 0; i < n; i++)
> +{
> +  a[i] = -1;
> +  b[i] = i+1;
> +  c[i] = 2*(i+1);
> +}
> +
> +#pragma acc enter data create(a[0:n]) copyin(b[:n], c[:n])
> +#pragma acc parallel loop
> +  for (i = 0; i < n; ++i)
> +{
> +  a[i] = b[i] + c[i] + *((int *)&d);
> +}
> +#pragma acc exit data copyout(a[0:n]) delete(b[0:n], c[0:n])
> +
> +  for (i = 0; i < n; i++)
> +assert (a[i] == 3*(i+1) + 12345);
> +
> +  free (a);
> +  free (b);
> +  free (c);
> +
> +  return 0;
> +}


I'm rejecting this, suspending such a change until we get clarification
about the (at least future) intention of the OpenACC specification.

And once we've got that clarified, the patch needs to be re-worked as
indicated.


Grüße
 Thomas


signature.asc
Description: PGP signature

Re: [PATCH, d] Do not add any target_libs dependencies if not using libphobos

[Iain Buclaw]

On Sun, 14 Apr 2019 at 18:40, Johannes Pfau  wrote:
>
> Even if we disable libphobos (as unsupported in libphobos/configure.tgt
> or using --disable-libphobos), config-lang.in still adds target-libbacktrace
> to the target_libs. This means target-zlib and target-libbacktrace still end 
> up
> being configured. On some embedded toolchains, libbacktrace however fails to 
> configure
> properly. This breaks the GCC build if d is added to --enabled-languages, 
> even if
> phobos is properly marked as unsupported.
>
> As we ideally want --enable-languages=d to work everywhere where
> --enable-languages=c works, this patch makes sure not to modify the 
> target_libs
> in any way if phobos is disabled. Due to the way this is implemented in
> configure.ac (default: configure all target libs, disable those only needed by
> disabled targets) we can not simply conditionally set target_libs. If we do 
> not
> set target_libs, we have to adjust disabled_target_libs instead for this to
> work properly.
>
> noconfigdirs without this patch if phobos is disabled:
> --enable-languages=c: gotools target-libgo target-libphobos target-zlib 
> target-libbacktrace
> --enable-languages=d: gotools target-libgo target-libphobos
> --enable-languages=d,go:
>
> noconfigdirs with this patch if phobos is disabled:
> --enable-languages=c: gotools target-libgo target-libphobos target-zlib 
> target-libbacktrace
> --enable-languages=d: gotools target-libgo target-libphobos target-zlib 
> target-libbacktrace
> --enable-languages=d,go: target-libphobos target-zlib
>
> Originally reviewed and tested here: 
> https://github.com/D-Programming-GDC/gcc/pull/11
>

OK, but for want of a better way to do this.  However I think its
right to have better support for targets without libphobos.

I've attached a couple knit changes.

-- 
Iain
---
diff --git a/gcc/d/config-lang.in b/gcc/d/config-lang.in
index 3fe1ac42f92..a3f78c7e6f9 100644
--- a/gcc/d/config-lang.in
+++ b/gcc/d/config-lang.in
@@ -25,7 +25,25 @@ language="d"
 
 compilers="d21\$(exeext)"
 
-target_libs="target-libphobos target-zlib target-libbacktrace"
+phobos_target_deps="target-zlib target-libbacktrace"
+phobos_target_libs="target-libphobos $phobos_target_deps"
+
+case "${noconfigdirs}" in
+  # Check if phobos was disabled as unsupported
+  *target-libphobos*)
+disabled_target_libs="$disabled_target_libs $phobos_target_deps"
+;;
+  *)
+# The --disable- handler in configure.ac is called after
+# config-lang.in. So when using --disable-libphobos, it has not been
+# added to noconfigdirs here yet
+if test x${enable_libphobos} != xno; then
+  target_libs="$phobos_target_libs"
+else
+  disabled_target_libs="$disabled_target_libs $phobos_target_libs"
+fi
+;;
+esac
 
 gtfiles="\$(srcdir)/d/d-tree.h \$(srcdir)/d/d-builtins.cc \$(srcdir)/d/d-lang.cc \$(srcdir)/d/modules.cc \$(srcdir)/d/typeinfo.cc"
 

Re: [PATCH, libphobos] Implement GCC emutls in druntime

[Iain Buclaw]

On Thu, 25 Apr 2019 at 12:25, Johannes Pfau  wrote:
>
> This adds emulated TLS support to druntime.
> The main problem here is that the D garbage collector needs
> to be able to scan the TLS memory for pointers, which is not
> possible with the current libgcc implementation.
>
> This therefore reimplements the libgcc emutls
> support (__emutls_get_address, ...) in druntime, taking
> care to expose an interface for the GC to scan memory
> (_d_emutls_scan). Due to the library link order, in most
> cases D code will corrently call the implementation in
> druntime. Where this does not work is if a C program
> loads a D library, then the D library will continue to
> use the libgcc implementation. This can be fixed in
> GCC 10 in various ways, but for now this patch
> will allow most use cases for MinGW, OSX and other
> emutls targets to work.
>
> In section code, the  _d_emutls_scan function and
> _d_emutls_destroy functions need to be called. This
> patch implements this for the elf_shared sections code.
>
> Bootstrapped on x86_64 linux with --disable-tls, checked
> testsuite with --disable-tls and without. Initial review
> on https://github.com/D-Programming-GDC/gcc/pull/13
>

OK, as it unblocks getting libphobos support for OSX and other emutls targets.

--
Iain.

Re: [PATCH][C++] Improve compile-time by ordering expensive checks last

[Rainer Orth]

Hi Richard,

> On Tue, 16 Apr 2019, Richard Biener wrote:
>
>> 
>> Two cases from a -fsynax-only tramp3d callgrind profile.
>
> Amended by two others.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> OK?
>
> Thanks,
> Richard.
>
> 2019-04-17  Richard Biener  
>
>   cp/
>   * call.c (null_ptr_cst_p): Order checks according to expensiveness.
>   (conversion_null_warnings): Likewise.
>   * typeck.c (same_type_ignoring_top_level_qualifiers_p): Return
>   early if type1 == type2.

this patch caused

+XPASS: g++.dg/warn/Wunused-var-35.C  -std=gnu++98 bug (test for warnings, line 
14)

First seen on i386-pc-solaris2.11 and sparc-sun-solaris2.11, according
to gcc-testresults everywhere.  Confirmed by reverting the patch locally
and re-testing the affected testcase.

Rainer

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

[PATCH] Fix -Wunused-var-35.C (was Re: [PATCH][C++] Improve compile-time by ordering expensive checks last)

[Jakub Jelinek]

On Thu, Apr 25, 2019 at 01:09:00PM +0200, Rainer Orth wrote:
> > cp/
> > * call.c (null_ptr_cst_p): Order checks according to expensiveness.
> > (conversion_null_warnings): Likewise.
> > * typeck.c (same_type_ignoring_top_level_qualifiers_p): Return
> > early if type1 == type2.
> 
> this patch caused
> 
> +XPASS: g++.dg/warn/Wunused-var-35.C  -std=gnu++98 bug (test for warnings, 
> line 14)
> 
> First seen on i386-pc-solaris2.11 and sparc-sun-solaris2.11, according
> to gcc-testresults everywhere.  Confirmed by reverting the patch locally
> and re-testing the affected testcase.

I can reproduce that too, seems to be the
@@ -6896,8 +6897,8 @@
 }
   /* Handle zero as null pointer warnings for cases other
  than EQ_EXPR and NE_EXPR */
-  else if (null_ptr_cst_p (expr) &&
-  (TYPE_PTR_OR_PTRMEM_P (totype) || NULLPTR_TYPE_P (totype)))
+  else if ((TYPE_PTR_OR_PTRMEM_P (totype) || NULLPTR_TYPE_P (totype))
+  && null_ptr_cst_p (expr))
 {
   location_t loc = get_location_for_expr_unwinding_for_system_header 
(expr);
   maybe_warn_zero_as_null_pointer_constant (expr, loc);
hunk.  The Wunused-var-35.C patch hasn't been posted to gcc-patches, but
judging from the corresponding PR, I'd say the right thing is below.

Regtested on x86_64-linux and i686-linux, ok for trunk?

2019-04-25  Jakub Jelinek  

PR c++/44648
* g++.dg/warn/Wunused-var-35.C: Remove xfail.

--- gcc/testsuite/g++.dg/warn/Wunused-var-35.C.jj   2019-02-04 
09:44:31.365413407 +0100
+++ gcc/testsuite/g++.dg/warn/Wunused-var-35.C  2019-04-25 13:24:49.717065815 
+0200
@@ -11,9 +11,8 @@ int main()
   else
 return 1;
 
-  if (const bool b2 = 1) // { dg-warning "\\\[-Wunused-variable\\\]" "bug" { 
xfail c++98_only } }
+  if (const bool b2 = 1) // { dg-warning "\\\[-Wunused-variable\\\]" }
 return 0;
   else
 return 1;
 }
-


Jakub

Re: [PATCH, d] Do not add any target_libs dependencies if not using libphobos

[Johannes Pfau]

Am 25.04.19 um 12:57 schrieb Iain Buclaw:

Originally reviewed and tested here: 
https://github.com/D-Programming-GDC/gcc/pull/11



OK, but for want of a better way to do this.  However I think its
right to have better support for targets without libphobos.

I've attached a couple knit changes.



Thanks, committed as r270571.
For GCC 10 we should try to implement some kind of dependency system for 
target libraries to have a cleaner solution.

Re: [PATCH] Fix -Wunused-var-35.C (was Re: [PATCH][C++] Improve compile-time by ordering expensive checks last)

[Richard Biener]

On Thu, 25 Apr 2019, Jakub Jelinek wrote:

> On Thu, Apr 25, 2019 at 01:09:00PM +0200, Rainer Orth wrote:
> > >   cp/
> > >   * call.c (null_ptr_cst_p): Order checks according to expensiveness.
> > >   (conversion_null_warnings): Likewise.
> > >   * typeck.c (same_type_ignoring_top_level_qualifiers_p): Return
> > >   early if type1 == type2.
> > 
> > this patch caused
> > 
> > +XPASS: g++.dg/warn/Wunused-var-35.C  -std=gnu++98 bug (test for warnings, 
> > line 14)
> > 
> > First seen on i386-pc-solaris2.11 and sparc-sun-solaris2.11, according
> > to gcc-testresults everywhere.  Confirmed by reverting the patch locally
> > and re-testing the affected testcase.
> 
> I can reproduce that too, seems to be the
> @@ -6896,8 +6897,8 @@
>  }
>/* Handle zero as null pointer warnings for cases other
>   than EQ_EXPR and NE_EXPR */
> -  else if (null_ptr_cst_p (expr) &&
> -(TYPE_PTR_OR_PTRMEM_P (totype) || NULLPTR_TYPE_P (totype)))
> +  else if ((TYPE_PTR_OR_PTRMEM_P (totype) || NULLPTR_TYPE_P (totype))
> +&& null_ptr_cst_p (expr))
>  {
>location_t loc = get_location_for_expr_unwinding_for_system_header 
> (expr);
>maybe_warn_zero_as_null_pointer_constant (expr, loc);
> hunk.  The Wunused-var-35.C patch hasn't been posted to gcc-patches, but
> judging from the corresponding PR, I'd say the right thing is below.
> 
> Regtested on x86_64-linux and i686-linux, ok for trunk?

The patch would be obvious but I wonder how the above can change 
anything...  (but I can reproduce with even only that change)

Richard.

> 2019-04-25  Jakub Jelinek  
> 
>   PR c++/44648
>   * g++.dg/warn/Wunused-var-35.C: Remove xfail.
> 
> --- gcc/testsuite/g++.dg/warn/Wunused-var-35.C.jj 2019-02-04 
> 09:44:31.365413407 +0100
> +++ gcc/testsuite/g++.dg/warn/Wunused-var-35.C2019-04-25 
> 13:24:49.717065815 +0200
> @@ -11,9 +11,8 @@ int main()
>else
>  return 1;
>  
> -  if (const bool b2 = 1) // { dg-warning "\\\[-Wunused-variable\\\]" "bug" { 
> xfail c++98_only } }
> +  if (const bool b2 = 1) // { dg-warning "\\\[-Wunused-variable\\\]" }
>  return 0;
>else
>  return 1;
>  }
> -
> 
> 
>   Jakub
> 

-- 
Richard Biener 
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany;
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah; HRB 21284 (AG Nürnberg)

Re: [PATCH] Fix -Wunused-var-35.C (was Re: [PATCH][C++] Improve compile-time by ordering expensive checks last)

[Jakub Jelinek]

On Thu, Apr 25, 2019 at 01:39:02PM +0200, Richard Biener wrote:
> > Regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> The patch would be obvious but I wonder how the above can change 
> anything...  (but I can reproduce with even only that change)

Haven't stepped through it in a debugger, but I bet it is the
fold_non_dependent_expr call in null_ptr_cst_p which is done for C++98 only.
That will mark it as TREE_USED in the end most likely and the
earlier fix for the PR44648 issues, r249083, was also about not trying to
fold the stuff early.

> > 2019-04-25  Jakub Jelinek  
> > 
> > PR c++/44648
> > * g++.dg/warn/Wunused-var-35.C: Remove xfail.
> > 
> > --- gcc/testsuite/g++.dg/warn/Wunused-var-35.C.jj   2019-02-04 
> > 09:44:31.365413407 +0100
> > +++ gcc/testsuite/g++.dg/warn/Wunused-var-35.C  2019-04-25 
> > 13:24:49.717065815 +0200
> > @@ -11,9 +11,8 @@ int main()
> >else
> >  return 1;
> >  
> > -  if (const bool b2 = 1) // { dg-warning "\\\[-Wunused-variable\\\]" "bug" 
> > { xfail c++98_only } }
> > +  if (const bool b2 = 1) // { dg-warning "\\\[-Wunused-variable\\\]" }
> >  return 0;
> >else
> >  return 1;
> >  }
> > -

Jakub

Re: [PATCH] Fix -Wunused-var-35.C (was Re: [PATCH][C++] Improve compile-time by ordering expensive checks last)

[Richard Biener]

On Thu, 25 Apr 2019, Jakub Jelinek wrote:

> On Thu, Apr 25, 2019 at 01:39:02PM +0200, Richard Biener wrote:
> > > Regtested on x86_64-linux and i686-linux, ok for trunk?
> > 
> > The patch would be obvious but I wonder how the above can change 
> > anything...  (but I can reproduce with even only that change)
> 
> Haven't stepped through it in a debugger, but I bet it is the
> fold_non_dependent_expr call in null_ptr_cst_p which is done for C++98 only.
> That will mark it as TREE_USED in the end most likely and the
> earlier fix for the PR44648 issues, r249083, was also about not trying to
> fold the stuff early.

Ah, OK, that makes "sense" (well, it doesn't really make sense for
a function called null_ptr_cst_p to behave this way...)

Richard.

> > > 2019-04-25  Jakub Jelinek  
> > > 
> > >   PR c++/44648
> > >   * g++.dg/warn/Wunused-var-35.C: Remove xfail.
> > > 
> > > --- gcc/testsuite/g++.dg/warn/Wunused-var-35.C.jj 2019-02-04 
> > > 09:44:31.365413407 +0100
> > > +++ gcc/testsuite/g++.dg/warn/Wunused-var-35.C2019-04-25 
> > > 13:24:49.717065815 +0200
> > > @@ -11,9 +11,8 @@ int main()
> > >else
> > >  return 1;
> > >  
> > > -  if (const bool b2 = 1) // { dg-warning "\\\[-Wunused-variable\\\]" 
> > > "bug" { xfail c++98_only } }
> > > +  if (const bool b2 = 1) // { dg-warning "\\\[-Wunused-variable\\\]" }
> > >  return 0;
> > >else
> > >  return 1;
> > >  }
> > > -
> 
>   Jakub
> 

-- 
Richard Biener 
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany;
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah; HRB 21284 (AG Nürnberg)

Re: [PATCH, RFC, rs6000] PR80791 Consider doloop in ivopts

[Segher Boessenkool]

Hi Kewen,

Cool stuff.

On Wed, Apr 24, 2019 at 04:41:01PM +0800, Kewen.Lin wrote:
> One failure was found in regression testing, which is:
>   gcc.target/powerpc/20050830-1.c
> 
> I did some investigation and found: with this patch, one new iv cand
> is chosen for exit condition, which is used to rewrite the compare
> type use.  Later loop iv analysis in RTL can NOT determine the loop
> iteration number is finite, which causes doloop_optimize not transform
> the loop.  The check doesn't find the expected pattern.

Does it create worse code now?  What we have before your patch isn't
so super either (it has an sldi in the loop, it has two mtctr too).
Maybe you can show the generated code?

> Btw, this is for GCC10.

*Phew* ;-)


Some trivial comments:

> +static bool
> +invalid_insn_for_doloop_p (struct loop *loop)
> +{
> +  basic_block *body = get_loop_body (loop);
> +  unsigned num_nodes = loop->num_nodes;
> +  gimple_stmt_iterator gsi;
> +  unsigned i;
> +
> +  for (i = 0; i < num_nodes; i++)

  for (unsigned i = 0; i < num_nodes; i++)

(and maybe you can just say loop->num_nodes here; I don't know if that
generates worse code, or if that even matters).

> + if (dump_file && (dump_flags & TDF_DETAILS))
> +   fprintf (
> + dump_file,
> + "predict doloop failure due to finding computed jump.\n");

We don't normally end lines in (.  There are other solutions to why you
did that here; you can use string pasting, to break the string into two,
or factor out (some part of) the loop body to reduce indentation.


Segher

Re: [PATCH, PR d/90086] Fix linker warning and SEGV in core.thread tests

[Rainer Orth]

Hi Iain,

> This patch removes the monolithic and cumbersome to maintain
> core/threadasm.S, and splitted it into multiple parts, one for each
> intended target cpu/os.
>
> Added .type and .size directives for all asm implementations of
> fiber_switchContent and callWithStackShell where they were missing,
> fixing the last remaining failing test on -m32 that I can reproduce
> locally.
>
> Bootstrapped and regression tested on x86_64-linux-gnu with multilibs
> -m32, -mx32, and -m64.
>
> Committed to trunk as r270560.

this patch badly broke x86 libphobos testing, as noticed during a
i386-pc-solaris2.11 build.  All link tests FAIL like this:

FAIL: libphobos.cycles/mod1.d --DRT-oncycle=print (test for excess errors)
Excess errors:
Undefined   first referenced
 symbol in file
fiber_switchContext     
/var/gcc/gcc-9.0.1-20190425/11.5-gcc-gas-libphobos/i386-pc-solaris2.11/libphobos/libdruntime/.libs/libgdruntime.a(thread.o)
ld: fatal: symbol referencing errors
collect2: error: ld returned 1 exit status

UNRESOLVED: libphobos.cycles/mod1.d --DRT-oncycle=print compilation failed to 
produce executable

You need to quote brackets to get them from m4/autoconf macros into
configure.  Fixed as follows, tested on i386-pc-solaris2.11, installed
as obvious.

Rainer

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


2019-04-25  Rainer Orth  

* m4/druntime/cpu.m4 (DRUNTIME_CPU_SOURCES): Quote brackets.
* configure: Regenerate.

# HG changeset patch
# Parent  a7a44865fd130abcbd002e700515b1b113704d0c
Fix typo in m4/druntime/cpu.m4

diff --git a/libphobos/configure b/libphobos/configure
--- a/libphobos/configure
+++ b/libphobos/configure
@@ -14050,7 +14050,7 @@ fi
   powerpc64)
druntime_target_cpu_parsed="powerpc64"
;;
-  i3456786|x86_64)
+  i[34567]86|x86_64)
druntime_target_cpu_parsed="x86"
;;
   esac
diff --git a/libphobos/m4/druntime/cpu.m4 b/libphobos/m4/druntime/cpu.m4
--- a/libphobos/m4/druntime/cpu.m4
+++ b/libphobos/m4/druntime/cpu.m4
@@ -22,7 +22,7 @@ AC_DEFUN([DRUNTIME_CPU_SOURCES],
   powerpc64)
druntime_target_cpu_parsed="powerpc64"
;;
-  i[34567]86|x86_64)
+  i[[34567]]86|x86_64)
druntime_target_cpu_parsed="x86"
;;
   esac

Re: [aarch64][RFA][rtl-optimization/87763] Fix insv_1 and insv_2 for aarch64

[Segher Boessenkool]

On Wed, Apr 24, 2019 at 12:16:39PM -0600, Jeff Law wrote:
> On 4/24/19 7:05 AM, Segher Boessenkool wrote:
> > On Mon, Apr 22, 2019 at 09:09:12AM -0600, Jeff Law wrote:
> >> First, it re-uses combine's make_field_assignment in the aarch64
> >> backend.
> > 
> > That's not really acceptable.  make_field_assignment depends intimately
> > on make_extraction, which is very much combine-specific (and wrong in so
> > many ways it's hard to tell).
> I think the structure of the pattern and its condition avoid the most
> problematic issues.  But yea, it's not ideal.

Oh, I'm not saying it does not work, I trust you tested it well.  But there
are so many ways this can completely break (with ICEs and everything), this
really isn't good.

You say all the problematic cases cannot happen...  So make a clone of this
function without any of those cases?  :-)

> > But it _is_ a big problem in other contexts: you should not create
> > non-canonical RTL.  In your specific case, where you want to run this
> > from a splitter, you have to make sure you get only correct, recognised
> > patterns for your machine.  make_field_extraction cannot guarantee you
> > that.
> Even in the case where the form and operands are limited to what's in
> the new pattern?  My worry with make_extraction is those cases where it
> gets too smart for its own good and returns something even simpler than
> extraction.  I'm not sure that can happen in this case or not.
> 
> I'm not keen on duplicating the logic from make_field_assignment and
> make_extraction.  Though again, given the limited forms we accept it may
> not be too bad.

Just praying that the RTL it creates is the RTL you prefer to see, or even
just RTL the backend can handle, doesn't sound too great.

(And any time this breaks it is a target bug, not combine).

> > You also have an insn condition that can become invalid by the time the
> > pattern is split (the !reload_complted part), which means the pattern
> > will then *not* be split, which won't work here (the template is "#").
> The pattern is split by the splitting pass before register allocation
> and reload.  It's never supposed to exist beyond that splitting pass.
> I'm pretty sure we've done this kind of thing regularly in the past.

Are you sure this code can never be created between the split pass and
when reload is finished?  Like maybe during LRA itself.  It's hard to
convince myself of this.

> >> +(define_insn_and_split ""
> > 
> > Give this a name?  Starting with * if you don't want a gen_* for it.
> Didn't figure it was worth the trouble.  But it's easy enough to do.

It helps debugging (and it helps naming stuff in the changelog :-) )

> >> +  [(set (match_operand:GPI 0 "register_operand" "=r")
> >> +  (ior:GPI (and:GPI (match_operand:GPI 1 "register_operand" "0")
> >> +(match_operand:GPI 2 "const_int_operand" "n"))
> >> +   (match_operand:GPI 3 "const_int_operand" "n")))]
> >> +  "(!reload_completed
> >> +/* make_field_assignment doesn't handle subregs well.  */
> >> +&& REG_P (operands[0])
> > 
> > Another reason to not use make_field_assignment, I'm afraid :-(
> Perhaps.  I'd probably want to avoid SUBREGs here regardless :-)

You get a subreg for using a 64-bit pseudo as 32-bit (a pseudo has only
one mode).  This happens a lot for insert insns, from what I see.


Segher

Re: Default compute dimensions (runtime)

[Thomas Schwinge]

Hi!

On Fri, 5 Oct 2018 21:03:36 +0100, Julian Brown  wrote:
> Continuing the thread from here:
> 
> https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00198.html
> 
> On Wed, 3 Feb 2016 19:52:09 +0300
> Alexander Monakov  wrote:
> 
> > On Wed, 3 Feb 2016, Nathan Sidwell wrote:
> > > You can only override at runtime those dimensions that you said
> > > you'd override at runtime when you compiled your program.  
> > 
> > Ah, I see.  That's not obvious to me, so perhaps added documentation
> > can be expanded to explain that?  (I now see that the plugin silently
> > drops user-provided dimensions where a value recorded at compile time
> > is present; not sure if that'd be worth a runtime diagnostic, could
> > be very noisy) 
> 
> This version of the patch has slightly-expanded documentation.

Thanks!

> While the runtime part of the patch already appears to have been
> committed as part of the following patch:
> 
> https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01589.html

(Not really as part of that one, but as part of other commits.)

> The compile-time part of the patch has not made it upstream yet. Thus,
> this rebased and retested patch consists of the parsing changes (for
> -fopenacc-dim=X:Y:Z, allowing '-')

That seems reasonable for next GCC development stage 1, with changes as
per below.  But please make sure that adequate testsuite coverage is
present for this functionality.

> and warning changes (for strange
> partitioning choices), plus associated testsuite adjustments.

These changes I'd like to defer, that's a separate topic.  The general
intention is good, but I've seen cases where I considered these
diagnostics to be too noisy.  See also the several 'dg-bogus' with XFAIL
that you're proposing to add?  We should think about that some more.


So, the following is relevant right now:

> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -2167,8 +2167,12 @@ have support for @option{-pthread}.
>  @cindex OpenACC accelerator programming
>  Specify default compute dimensions for parallel offload regions that do
>  not explicitly specify.  The @var{geom} value is a triple of
> -':'-separated sizes, in order 'gang', 'worker' and, 'vector'.  A size
> -can be omitted, to use a target-specific default value.
> +':'-separated sizes, in order 'gang', 'worker' and, 'vector'.  If a size
> +is to be deferred until execution '-' can be used, alternatively a size
> +can be omitted to use a target-specific default value.  When deferring
> +to runtime, the environment variable @var{GOMP_OPENACC_DIM} can be set.
> +It has the same format as the option value, except that '-' is not
> +permitted.

ACK.

I re-discovered that 'GOMP_OPENACC_DIM' is not currently documented in
the libgomp manual (also referring back to the compile-time flag).  That
can be fixed incrementally, later on; that's PR85129 "[openacc] Document
GOMP_OPENACC_DIM".

> --- a/gcc/omp-offload.c
> +++ b/gcc/omp-offload.c
> @@ -574,8 +574,9 @@ static int oacc_default_dims[GOMP_DIM_MAX];
>  static int oacc_min_dims[GOMP_DIM_MAX];
>  
>  /* Parse the default dimension parameter.  This is a set of
> -   :-separated optional compute dimensions.  Each specified dimension
> -   is a positive integer.  When device type support is added, it is
> +   :-separated optional compute dimensions.  Each dimension is either
> +   a positive integer, or '-' for a dynamic value computed at
> +   runtime.  When device type support is added, it is
> planned to be a comma separated list of such compute dimensions,
> with all but the first prefixed by the colon-terminated device
> type.  */
> @@ -610,14 +611,20 @@ oacc_parse_default_dims (const char *dims)
>  
> if (*pos != ':')
>   {
> -   long val;
> -   const char *eptr;
> +   long val = 0;

Don't set "val = 0" here, but instead...

>  
> -   errno = 0;
> -   val = strtol (pos, CONST_CAST (char **, &eptr), 10);
> -   if (errno || val <= 0 || (int) val != val)
> - goto malformed;
> -   pos = eptr;
> +   if (*pos == '-')

... do that here, so that it's clear that this is how the '-' case gets
encoded.

> + pos++;
> +   else
> + {
> +   const char *eptr;
> +
> +   errno = 0;
> +   val = strtol (pos, CONST_CAST (char **, &eptr), 10);
> +   if (errno || val <= 0 || (int) val != val)
> + goto malformed;
> +   pos = eptr;
> + }
> oacc_default_dims[ix] = (int) val;
>   }
>   }

> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-default-compile.c
> @@ -0,0 +1,13 @@
> +/* { dg-additional-options "-fopenacc-dim=16:16" } */
> +/* This code uses nvptx inline assembly guarded with acc_on_device, which is
> +   not optimized away at -O0, and then confuses the target assembler.
> +   { dg-skip-if "" { *-*-* } { "-O0" } { "" } } */

You no longer need to skip for '-O0'.

Re: [PATCH, libphobos] Committed added AArch64 Linux as a supported target.

[Richard Earnshaw (lists)]

On 24/04/2019 12:10, Iain Buclaw wrote:
> On Wed, 24 Apr 2019 at 09:33, Andreas Schwab  wrote:
>>
>> On Apr 24 2019, Iain Buclaw  wrote:
>>
>>> This patch adds arch64*-*-linux* as a supported libphobos target,
>>> something that has been passing the testsuite for a while now.
>>>
>>> Committed to trunk as r270524.
>>
>> That breaks -mabi=ilp32:
>>
>> /opt/gcc/gcc-20190424/libphobos/libdruntime/core/sys/posix/sys/stat.d:713:13:
>>  error: static assert  (104u == 128u) is false
>>   713 | static assert(stat_t.sizeof == 128);
>>   | ^
>> make[8]: *** [Makefile:2047: core/sys/posix/fcntl.lo] Error 1
>>
> 
> Confirmed, I've sent fix to upstream and committed as r270541.
> 
> Tested this on aarch64-linux-gnu, though as I don't have ilp32
> libraries on my arm64 phone, I can only see that all modules compile
> down to object code.
> 
> 
> druntime51365217.patch
> 
> diff --git a/libphobos/libdruntime/MERGE b/libphobos/libdruntime/MERGE
> index 27dfc5fc1d9..9fe51fd5ae9 100644
> --- a/libphobos/libdruntime/MERGE
> +++ b/libphobos/libdruntime/MERGE
> @@ -1,4 +1,4 @@
> -b43203a134fb5e259ffc1711cc061c6e869b56f6
> +513652173d6f02206be3ddaa2b6ed0b191ea4e3d
>  
>  The first line of this file holds the git revision number of the last
>  merge done from the dlang/druntime repository.
> diff --git a/libphobos/libdruntime/core/sys/posix/sys/stat.d 
> b/libphobos/libdruntime/core/sys/posix/sys/stat.d
> index ab1fcd7b164..963a241f076 100644
> --- a/libphobos/libdruntime/core/sys/posix/sys/stat.d
> +++ b/libphobos/libdruntime/core/sys/posix/sys/stat.d
> @@ -709,10 +709,10 @@ version (CRuntime_Glibc)
>  }
>  int[2] __unused;
>  }
> -static if (__USE_FILE_OFFSET64)
> +version (D_LP64)
>  static assert(stat_t.sizeof == 128);
>  else
> -static assert(stat_t.sizeof == 128);
> +static assert(stat_t.sizeof == 104);

I can't be sure just from the context, but 104 looks suspicious.  Maybe
that should be 64?

R.

>  }
>  else version (SPARC64)
>  {
> 

[PATCH] Remove phi-only-cprop leftovers

[Richard Biener]

Committed as obvious.

Richard.

2019-04-25  Richard Biener  

* tree-pass.h (make_pass_phi_only_cprop): Remove.
* timevar.def (TV_TREE_PHI_CPROP): Likewise.

Index: gcc/tree-pass.h
===
--- gcc/tree-pass.h (revision 270574)
+++ gcc/tree-pass.h (working copy)
@@ -389,7 +389,6 @@ extern gimple_opt_pass *make_pass_ch (gc
 extern gimple_opt_pass *make_pass_ch_vect (gcc::context *ctxt);
 extern gimple_opt_pass *make_pass_ccp (gcc::context *ctxt);
 extern gimple_opt_pass *make_pass_split_paths (gcc::context *ctxt);
-extern gimple_opt_pass *make_pass_phi_only_cprop (gcc::context *ctxt);
 extern gimple_opt_pass *make_pass_build_ssa (gcc::context *ctxt);
 extern gimple_opt_pass *make_pass_build_alias (gcc::context *ctxt);
 extern gimple_opt_pass *make_pass_build_ealias (gcc::context *ctxt);
Index: gcc/timevar.def
===
--- gcc/timevar.def (revision 270574)
+++ gcc/timevar.def (working copy)
@@ -165,7 +165,6 @@ DEFTIMEVAR (TV_TREE_SSA_THREAD_JUMPS , "
 DEFTIMEVAR (TV_TREE_SRA  , "tree SRA")
 DEFTIMEVAR (TV_ISOLATE_ERRONEOUS_PATHS, "isolate eroneous paths")
 DEFTIMEVAR (TV_TREE_CCP , "tree CCP")
-DEFTIMEVAR (TV_TREE_PHI_CPROP   , "tree PHI const/copy prop")
 DEFTIMEVAR (TV_TREE_SPLIT_EDGES  , "tree split crit edges")
 DEFTIMEVAR (TV_TREE_REASSOC  , "tree reassociation")
 DEFTIMEVAR (TV_TREE_PRE , "tree PRE")

Re: [PATCH, libphobos] Committed added AArch64 Linux as a supported target.

[Iain Buclaw]

On Thu, 25 Apr 2019 at 16:32, Richard Earnshaw (lists)
 wrote:
>
> On 24/04/2019 12:10, Iain Buclaw wrote:
> > On Wed, 24 Apr 2019 at 09:33, Andreas Schwab  wrote:
> >>
> >> On Apr 24 2019, Iain Buclaw  wrote:
> >>
> >>> This patch adds arch64*-*-linux* as a supported libphobos target,
> >>> something that has been passing the testsuite for a while now.
> >>>
> >>> Committed to trunk as r270524.
> >>
> >> That breaks -mabi=ilp32:
> >>
> >> /opt/gcc/gcc-20190424/libphobos/libdruntime/core/sys/posix/sys/stat.d:713:13:
> >>  error: static assert  (104u == 128u) is false
> >>   713 | static assert(stat_t.sizeof == 128);
> >>   | ^
> >> make[8]: *** [Makefile:2047: core/sys/posix/fcntl.lo] Error 1
> >>
> >
> > Confirmed, I've sent fix to upstream and committed as r270541.
> >
> > Tested this on aarch64-linux-gnu, though as I don't have ilp32
> > libraries on my arm64 phone, I can only see that all modules compile
> > down to object code.
> >
> >
> > druntime51365217.patch
> >
> > diff --git a/libphobos/libdruntime/MERGE b/libphobos/libdruntime/MERGE
> > index 27dfc5fc1d9..9fe51fd5ae9 100644
> > --- a/libphobos/libdruntime/MERGE
> > +++ b/libphobos/libdruntime/MERGE
> > @@ -1,4 +1,4 @@
> > -b43203a134fb5e259ffc1711cc061c6e869b56f6
> > +513652173d6f02206be3ddaa2b6ed0b191ea4e3d
> >
> >  The first line of this file holds the git revision number of the last
> >  merge done from the dlang/druntime repository.
> > diff --git a/libphobos/libdruntime/core/sys/posix/sys/stat.d 
> > b/libphobos/libdruntime/core/sys/posix/sys/stat.d
> > index ab1fcd7b164..963a241f076 100644
> > --- a/libphobos/libdruntime/core/sys/posix/sys/stat.d
> > +++ b/libphobos/libdruntime/core/sys/posix/sys/stat.d
> > @@ -709,10 +709,10 @@ version (CRuntime_Glibc)
> >  }
> >  int[2] __unused;
> >  }
> > -static if (__USE_FILE_OFFSET64)
> > +version (D_LP64)
> >  static assert(stat_t.sizeof == 128);
> >  else
> > -static assert(stat_t.sizeof == 128);
> > +static assert(stat_t.sizeof == 104);
>
> I can't be sure just from the context, but 104 looks suspicious.  Maybe
> that should be 64?
>

Don't think so.  GCC is agreeing with GDC at least on my aarch64-linux
phone, the `sizeof (struct stat)` does genuinely appear to be 104 when
-mabi=ilp32.

-- 
Iain

[RFA] Fix minor pass ordering problem

[Jeff Law]

In the discussion for pr90037 Richi noticed that we had a cprop pass
after the restrict warning pass.  Those should be swapped.  This patch
swaps them.

Bootstrapped and regression tested on x86_64.

I wouldn't lose sleep if we decided to defer this to gcc-10.  But given
Richi and I both think it's the right thing to do I figured it was worth
consideration for gcc-9.

OK for the trunk, or defer to gcc-10?

Jeff
* passes.def: Move -Wrestrict pass after copy propagation.

diff --git a/gcc/passes.def b/gcc/passes.def
index bc147cd..99640d50091 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -315,10 +315,10 @@ along with GCC; see the file COPYING3.  If not see
   NEXT_PASS (pass_strlen);
   NEXT_PASS (pass_thread_jumps);
   NEXT_PASS (pass_vrp, false /* warn_array_bounds_p */);
-  NEXT_PASS (pass_warn_restrict);
   /* Threading can leave many const/copy propagations in the IL.
 Clean them up.  */
   NEXT_PASS (pass_copy_prop);
+  NEXT_PASS (pass_warn_restrict);
   NEXT_PASS (pass_dse);
   NEXT_PASS (pass_cd_dce);
   NEXT_PASS (pass_forwprop);

[PATCH] Fix PR89765

[Richard Biener]

This fixes the ICE seen by the ppc testcase in the PR.  The gimplifier
was blindly turning a VIEW_CONVERT_EXPR into an rvalue even if that
isn't allowed.

Bootstrap / regtest running on x86_64-unknown-linux-gnu, OK?

Can ppc folks add the testcase (maybe once they figure out the
remaining wrong-code issue)?

Thanks,
Richard.

2019-04-25  Richard Biener  

PR middle-end/89765
* gimplify.c (gimplify_expr): Avoid turning a lvalue
VIEW_CONVERT_EXPR into one operating on an rvalue.

Index: gcc/gimplify.c
===
--- gcc/gimplify.c  (revision 270574)
+++ gcc/gimplify.c  (working copy)
@@ -12397,7 +12397,8 @@ gimplify_expr (tree *expr_p, gimple_seq
  break;
 
case VIEW_CONVERT_EXPR:
- if (is_gimple_reg_type (TREE_TYPE (*expr_p))
+ if ((fallback & fb_rvalue)
+ && is_gimple_reg_type (TREE_TYPE (*expr_p))
  && is_gimple_reg_type (TREE_TYPE (TREE_OPERAND (*expr_p, 0
{
  ret = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p,

Re: [RFA] Fix minor pass ordering problem

[Richard Biener]

On Thu, Apr 25, 2019 at 4:46 PM Jeff Law  wrote:
>
>
> In the discussion for pr90037 Richi noticed that we had a cprop pass
> after the restrict warning pass.  Those should be swapped.  This patch
> swaps them.
>
> Bootstrapped and regression tested on x86_64.
>
> I wouldn't lose sleep if we decided to defer this to gcc-10.  But given
> Richi and I both think it's the right thing to do I figured it was worth
> consideration for gcc-9.
>
> OK for the trunk, or defer to gcc-10?

OK for GCC 10.

Richard.

>
> Jeff

Merge from trunk to gccgo branch

[Ian Lance Taylor]

I merged trunk revision 270573 to the gccgo branch.

Ian

Re: [PATCH, libphobos] Committed added AArch64 Linux as a supported target.

[Jakub Jelinek]

On Thu, Apr 25, 2019 at 03:32:41PM +0100, Richard Earnshaw (lists) wrote:
> > --- a/libphobos/libdruntime/core/sys/posix/sys/stat.d
> > +++ b/libphobos/libdruntime/core/sys/posix/sys/stat.d
> > @@ -709,10 +709,10 @@ version (CRuntime_Glibc)
> >  }
> >  int[2] __unused;
> >  }
> > -static if (__USE_FILE_OFFSET64)
> > +version (D_LP64)
> >  static assert(stat_t.sizeof == 128);
> >  else
> > -static assert(stat_t.sizeof == 128);
> > +static assert(stat_t.sizeof == 104);
> 
> I can't be sure just from the context, but 104 looks suspicious.  Maybe
> that should be 64?

Why?  Not all struct stat fields are pointers or longs that double for -m64
vs. -m32.

Jakub

[PATCH, PR d/90250] Committed fix segfault in runtime caused by unexpected GC of TLS data.

[Iain Buclaw]

Hi,

Patch fixes a tlsgc bug on non-glibc targets.

As explained in the bug report, glibc puts the TLS area for each new
thread at the beginning of the newly created stack. Due to the way
libdruntime detects the stack bottom, we end up marking all TLS data
along with what we think is the stack.

On other platforms, this is not the case, so memory referenced by
thread-local data will get unexpectedly freed, making the use of
threads and TLS unworkable.

Regression tested on x86_64-linux-gnu and x86_64-freebsd.

Committed to trunk as r270576.

-- 
Iain
---
libphobos/ChangeLog:

2019-04-25  Iain Buclaw  

* libdruntime/gcc/sections/elf_shared.d (initTLSRanges): Populate
_tlsRanges in every startup thread.
* testsuite/libphobos.thread/thread.exp: Load libphobos-dg.exp.
* testsuite/libphobos.thread/tlsgc_sections.d: New test.

---
diff --git a/libphobos/libdruntime/gcc/sections/elf_shared.d b/libphobos/libdruntime/gcc/sections/elf_shared.d
index 3a2c85cba64..1eafecdd322 100644
--- a/libphobos/libdruntime/gcc/sections/elf_shared.d
+++ b/libphobos/libdruntime/gcc/sections/elf_shared.d
@@ -308,7 +308,13 @@ else
  */
 Array!(void[])* initTLSRanges() nothrow @nogc
 {
-return &_tlsRanges();
+auto rngs = &_tlsRanges();
+if (rngs.empty)
+{
+foreach (ref pdso; _loadedDSOs)
+rngs.insertBack(pdso.tlsRange());
+}
+return rngs;
 }
 
 void finiTLSRanges(Array!(void[])* rngs) nothrow @nogc
diff --git a/libphobos/testsuite/libphobos.thread/thread.exp b/libphobos/testsuite/libphobos.thread/thread.exp
index d35df567ab3..3e760d3e370 100644
--- a/libphobos/testsuite/libphobos.thread/thread.exp
+++ b/libphobos/testsuite/libphobos.thread/thread.exp
@@ -14,6 +14,8 @@
 # along with GCC; see the file COPYING3.  If not see
 # .
 
+load_lib libphobos-dg.exp
+
 # Initialize dg.
 dg-init
 
diff --git a/libphobos/testsuite/libphobos.thread/tlsgc_sections.d b/libphobos/testsuite/libphobos.thread/tlsgc_sections.d
new file mode 100644
index 000..1421d926a38
--- /dev/null
+++ b/libphobos/testsuite/libphobos.thread/tlsgc_sections.d
@@ -0,0 +1,39 @@
+final class Class
+{
+// This gets triggered although the instance always stays referenced.
+~this()
+{
+import core.stdc.stdlib;
+abort();
+}
+}
+
+Class obj;
+
+static this()
+{
+obj = new Class;
+}
+
+static ~this()
+{
+// Free without destruction to avoid triggering abort()
+import core.memory;
+GC.free(cast(void*)obj);
+}
+
+void doit()
+{
+foreach (i; 0 .. 10_000)
+new ubyte[](100_000);
+}
+
+void main()
+{
+import core.thread;
+auto t = new Thread(&doit);
+t.start();
+
+// This triggers the GC that frees the still referenced Class instance.
+doit();
+}

[PATCH, rs6000] PR89424: __builtin_vec_ext_v1ti (v, i) results in ICE with variable i (RS6000)

[Kelvin Nilsen]

The attached patch resolves the issue described in this problem report.  The 
patch has been bootstrapped and tested without regressions on 
powerpc64le-unknown-linux-gnu (both P8 and P9) and on powerpc64-linux (P7 and 
P8, both -m32 and -m64).

Is this ok for trunk and backports?


Thanks.

gcc/ChangeLog:

2019-04-25  Kelvin Nilsen  

PR target/89424
* config/rs6000/rs6000.c (rs6000_expand_vector_extract): Add
handling of V1TImode.

gcc/testsuite/ChangeLog:

2019-04-25  Kelvin Nilsen  

PR target/89424
* gcc.target/powerpc/pr89424-0.c: New test.
* gcc.target/powerpc/vsx-builtin-13a.c: Define macro PR89424 to
enable testing of newly patched capability.
* gcc.target/powerpc/vsx-builtin-13b.c: Likewise.
* gcc.target/powerpc/vsx-builtin-20a.c: Likewise.
* gcc.target/powerpc/vsx-builtin-20b.c: Likewise.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 270513)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -6944,6 +6944,10 @@ rs6000_expand_vector_extract (rtx target, rtx vec,
 
   switch (mode)
{
+   case E_V1TImode:
+ emit_move_insn (target, gen_lowpart (TImode, vec));
+ return;
+
case E_V2DFmode:
  emit_insn (gen_vsx_extract_v2df_var (target, vec, elt));
  return;
Index: gcc/testsuite/gcc.target/powerpc/pr89424-0.c
===
--- gcc/testsuite/gcc.target/powerpc/pr89424-0.c(nonexistent)
+++ gcc/testsuite/gcc.target/powerpc/pr89424-0.c(working copy)
@@ -0,0 +1,78 @@
+/* { dg-do run { target { powerpc*-*-* && lp64 } } } */
+/* { dg-skip-if "" { powerpc*-*-darwin* } } */
+/* { dg-require-effective-target vsx_hw } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { } } */
+/* { dg-options "-mvsx" } */
+
+/* This test should run the same on any target that supports vsx
+   instructions.  Intentionally not specifying cpu in order to test
+   all code generation paths.  */
+
+#include 
+
+extern void abort (void);
+
+/* Define PR89626 after that pr is addressed.  */
+#ifdef PR89626
+#define SIGNED
+#else
+#define SIGNED signed
+#endif
+
+#define CONST0 (((__int128) 31415926539) << 60)
+
+/* Test that indices > length of vector are applied modulo the vector
+   length.  */
+
+
+/* Test for variable selector and vector residing in register.  */
+__attribute__((noinline))
+__int128 ei (vector SIGNED __int128 v, int i)
+{
+  return __builtin_vec_ext_v1ti (v, i);
+}
+
+/* Test for variable selector and vector residing in memory.  */
+__int128 mei (vector SIGNED __int128 *vp, int i)
+{
+  return __builtin_vec_ext_v1ti (*vp, i);
+}
+
+int main (int argc, char *argv[]) {
+  vector SIGNED __int128 dv = { CONST0 };
+  __int128 d;
+
+  d = ei (dv, 0);
+  if (d != CONST0)
+abort ();
+
+  d = ei (dv, 1);
+  if (d != CONST0)
+abort ();
+
+  d = ei (dv, 2);
+  if (d != CONST0)
+abort ();
+
+  d = ei (dv, 3);
+  if (d != CONST0)
+abort ();
+
+  d = mei (&dv, 0);
+  if (d != CONST0)
+abort ();
+
+  d = mei (&dv, 1);
+  if (d != CONST0)
+abort ();
+
+  d = mei (&dv, 2);
+  if (d != CONST0)
+abort ();
+
+  d = mei (&dv, 3);
+  if (d != CONST0)
+abort ();
+
+  return 0;
+}
Index: gcc/testsuite/gcc.target/powerpc/vsx-builtin-13a.c
===
--- gcc/testsuite/gcc.target/powerpc/vsx-builtin-13a.c  (revision 270513)
+++ gcc/testsuite/gcc.target/powerpc/vsx-builtin-13a.c  (working copy)
@@ -9,7 +9,7 @@
 #include 
 
 /* Define this after PR89424 is addressed.  */
-#undef PR89424
+#define PR89424
 
 /* Define this after PR89626 is addressed.  */
 #undef PR89626
Index: gcc/testsuite/gcc.target/powerpc/vsx-builtin-13b.c
===
--- gcc/testsuite/gcc.target/powerpc/vsx-builtin-13b.c  (revision 270513)
+++ gcc/testsuite/gcc.target/powerpc/vsx-builtin-13b.c  (working copy)
@@ -9,7 +9,7 @@
 #include 
 
 /* Define this after PR89424 is addressed.  */
-#undef PR89424
+#define PR89424
 
 /* Define this after PR89626 is addressed.  */
 #undef PR89626
Index: gcc/testsuite/gcc.target/powerpc/vsx-builtin-20a.c
===
--- gcc/testsuite/gcc.target/powerpc/vsx-builtin-20a.c  (revision 270513)
+++ gcc/testsuite/gcc.target/powerpc/vsx-builtin-20a.c  (working copy)
@@ -9,7 +9,7 @@
 #include 
 
 /* Define this after PR89424 is addressed.  */
-#undef PR89424
+#define PR89424
 
 extern void abort (void);
 
Index: gcc/testsuite/gcc.target/powerpc/vsx-builtin-20b.c
===
--- gcc/testsuite/gcc.target/powerpc/vsx-builtin-20b.c  (revision 270513)
+++ gcc/testsuite/gcc.target/powerpc/vsx-builtin-20b.c  (working copy)
@@ -9,7 +9,7 @@
 #include 
 
 /* Define this after 

Re: [PATCH, libphobos] Committed added AArch64 Linux as a supported target.

[Richard Earnshaw (lists)]

On 25/04/2019 16:45, Jakub Jelinek wrote:
> On Thu, Apr 25, 2019 at 03:32:41PM +0100, Richard Earnshaw (lists) wrote:
>>> --- a/libphobos/libdruntime/core/sys/posix/sys/stat.d
>>> +++ b/libphobos/libdruntime/core/sys/posix/sys/stat.d
>>> @@ -709,10 +709,10 @@ version (CRuntime_Glibc)
>>>  }
>>>  int[2] __unused;
>>>  }
>>> -static if (__USE_FILE_OFFSET64)
>>> +version (D_LP64)
>>>  static assert(stat_t.sizeof == 128);
>>>  else
>>> -static assert(stat_t.sizeof == 128);
>>> +static assert(stat_t.sizeof == 104);
>>
>> I can't be sure just from the context, but 104 looks suspicious.  Maybe
>> that should be 64?
> 
> Why?  Not all struct stat fields are pointers or longs that double for -m64
> vs. -m32.
> 
>   Jakub
> 

I was forgetting that these were byte counts, not bit counts.  Makes
more sense when you realize that...

R.

[PATCH, rs6000] PR89424: __builtin_vec_ext_v1ti (v, i) results in ICE with variable i (RS6000)

[Kelvin Nilsen]

The attached patch resolves the issue described in this problem report.  The 
patch has been bootstrapped and tested without regressions on 
powerpc64le-unknown-linux-gnu (both P8 and P9) and on 
powerpc64-unknown-linux-gnu (P7 and P8, both -m32 and -m64).

Is this ok for trunk and backports?


Thanks.

gcc/ChangeLog:

2019-04-25  Kelvin Nilsen  

PR target/89424
* config/rs6000/rs6000.c (rs6000_expand_vector_extract): Add
handling of V1TImode.

gcc/testsuite/ChangeLog:

2019-04-25  Kelvin Nilsen  

PR target/89424
* gcc.target/powerpc/pr89424-0.c: New test.
* gcc.target/powerpc/vsx-builtin-13a.c: Define macro PR89424 to
enable testing of newly patched capability.
* gcc.target/powerpc/vsx-builtin-13b.c: Likewise.
* gcc.target/powerpc/vsx-builtin-20a.c: Likewise.
* gcc.target/powerpc/vsx-builtin-20b.c: Likewise.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 270513)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -6944,6 +6944,10 @@ rs6000_expand_vector_extract (rtx target, rtx vec,
 
   switch (mode)
{
+   case E_V1TImode:
+ emit_move_insn (target, gen_lowpart (TImode, vec));
+ return;
+
case E_V2DFmode:
  emit_insn (gen_vsx_extract_v2df_var (target, vec, elt));
  return;
Index: gcc/testsuite/gcc.target/powerpc/pr89424-0.c
===
--- gcc/testsuite/gcc.target/powerpc/pr89424-0.c(nonexistent)
+++ gcc/testsuite/gcc.target/powerpc/pr89424-0.c(working copy)
@@ -0,0 +1,78 @@
+/* { dg-do run { target { powerpc*-*-* && lp64 } } } */
+/* { dg-skip-if "" { powerpc*-*-darwin* } } */
+/* { dg-require-effective-target vsx_hw } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { } } */
+/* { dg-options "-mvsx" } */
+
+/* This test should run the same on any target that supports vsx
+   instructions.  Intentionally not specifying cpu in order to test
+   all code generation paths.  */
+
+#include 
+
+extern void abort (void);
+
+/* Define PR89626 after that pr is addressed.  */
+#ifdef PR89626
+#define SIGNED
+#else
+#define SIGNED signed
+#endif
+
+#define CONST0 (((__int128) 31415926539) << 60)
+
+/* Test that indices > length of vector are applied modulo the vector
+   length.  */
+
+
+/* Test for variable selector and vector residing in register.  */
+__attribute__((noinline))
+__int128 ei (vector SIGNED __int128 v, int i)
+{
+  return __builtin_vec_ext_v1ti (v, i);
+}
+
+/* Test for variable selector and vector residing in memory.  */
+__int128 mei (vector SIGNED __int128 *vp, int i)
+{
+  return __builtin_vec_ext_v1ti (*vp, i);
+}
+
+int main (int argc, char *argv[]) {
+  vector SIGNED __int128 dv = { CONST0 };
+  __int128 d;
+
+  d = ei (dv, 0);
+  if (d != CONST0)
+abort ();
+
+  d = ei (dv, 1);
+  if (d != CONST0)
+abort ();
+
+  d = ei (dv, 2);
+  if (d != CONST0)
+abort ();
+
+  d = ei (dv, 3);
+  if (d != CONST0)
+abort ();
+
+  d = mei (&dv, 0);
+  if (d != CONST0)
+abort ();
+
+  d = mei (&dv, 1);
+  if (d != CONST0)
+abort ();
+
+  d = mei (&dv, 2);
+  if (d != CONST0)
+abort ();
+
+  d = mei (&dv, 3);
+  if (d != CONST0)
+abort ();
+
+  return 0;
+}
Index: gcc/testsuite/gcc.target/powerpc/vsx-builtin-13a.c
===
--- gcc/testsuite/gcc.target/powerpc/vsx-builtin-13a.c  (revision 270513)
+++ gcc/testsuite/gcc.target/powerpc/vsx-builtin-13a.c  (working copy)
@@ -9,7 +9,7 @@
 #include 
 
 /* Define this after PR89424 is addressed.  */
-#undef PR89424
+#define PR89424
 
 /* Define this after PR89626 is addressed.  */
 #undef PR89626
Index: gcc/testsuite/gcc.target/powerpc/vsx-builtin-13b.c
===
--- gcc/testsuite/gcc.target/powerpc/vsx-builtin-13b.c  (revision 270513)
+++ gcc/testsuite/gcc.target/powerpc/vsx-builtin-13b.c  (working copy)
@@ -9,7 +9,7 @@
 #include 
 
 /* Define this after PR89424 is addressed.  */
-#undef PR89424
+#define PR89424
 
 /* Define this after PR89626 is addressed.  */
 #undef PR89626
Index: gcc/testsuite/gcc.target/powerpc/vsx-builtin-20a.c
===
--- gcc/testsuite/gcc.target/powerpc/vsx-builtin-20a.c  (revision 270513)
+++ gcc/testsuite/gcc.target/powerpc/vsx-builtin-20a.c  (working copy)
@@ -9,7 +9,7 @@
 #include 
 
 /* Define this after PR89424 is addressed.  */
-#undef PR89424
+#define PR89424
 
 extern void abort (void);
 
Index: gcc/testsuite/gcc.target/powerpc/vsx-builtin-20b.c
===
--- gcc/testsuite/gcc.target/powerpc/vsx-builtin-20b.c  (revision 270513)
+++ gcc/testsuite/gcc.target/powerpc/vsx-builtin-20b.c  (working copy)
@@ -9,7 +9,7 @@
 #include 
 
 /* Def

Re: [PATCH v2] Add error message for target_clones and AVX512 ISAs (PR target/89929).

[H.J. Lu]

On Thu, Apr 25, 2019 at 1:03 AM Uros Bizjak  wrote:
>
>
>
> On Thu, Apr 25, 2019 at 9:51 AM Martin Liška  wrote:
>>
>> On 4/23/19 10:29 AM, Martin Liška wrote:
>> > On 4/18/19 7:44 PM, H.J. Lu wrote:
>> >> On Thu, Apr 18, 2019 at 4:07 AM Martin Liška  wrote:
>> >>>
>> >>> Hi.
>> >>>
>> >>> I'm sending updated version of that patch. The patch rejects usage of 
>> >>> AVX512 ISAs (except AVX512F)
>> >>> for target attribute for C++ multiversioning and for target_clone 
>> >>> attribute.
>> >>>
>> >>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>> >>>
>> >>> Ready to be installed?
>> >>> Thanks,
>> >>> Martin
>> >>
>> >> Your patch doesn't handle cmov nor gfni properly, which aren't AVX512.
>> >> I prefer this patch.
>> >>
>> >
>> > I like the patch. Thanks for working on that.
>> >
>> > Martin
>> >
>> >
>>
>> Btw. can we get that patch into GCC 9.1?
>>
>> Adding port maintainers to CC.
>
>
> HJ knows ISA interdependencies, and the benefit of the patch outweights the 
> (small) risk, so from the maintaner PoV, OK for the mainline unless RM vetoes 
> the decision soon. HJ, please double check the patch for eventual 
> inconsistencies or possible regressions before committing.
>
> Thanks,
> Uros.

Tested on x86-64.  I am checking in this updated patch with:

diff --git a/gcc/testsuite/g++.target/i386/pr57362.C b/gcc/testsuite/g++.target/
i386/pr57362.C
index 5e612130357..ced5e518cfe 100644
--- a/gcc/testsuite/g++.target/i386/pr57362.C
+++ b/gcc/testsuite/g++.target/i386/pr57362.C
@@ -199,4 +199,4 @@ int foo(void) { return 1; }
 /* { dg-prune-output "attribute.* is unknown" } */
 /* { dg-prune-output "missing 'target' attribute*" } */
 /* { dg-prune-output "redefinition of 'int foo" } */
-/* { dg-prune-output "no dispatcher found for" } */
+/* { dg-prune-output "ISA '.*' is not supported in 'target' attribute" } */


-- 
H.J.
From 79013fe56d7ca7588dc9dbebdeb64f869e15e278 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Thu, 18 Apr 2019 09:49:58 -0700
Subject: [PATCH] x86: Update message for target_clones and unsupported ISAs

Before AVX512F, processors with the newer ISAs also support the older
ISAs, i.e., AVX2 processors also support AVX and SSE4, SSE4 processors
also support SSSE3, ...   After AVX512F, an AVX512XX processor may not
support AVX512YY.  It means AVX512XX features, except for AVX512F, can't
be used to decide priority in target_clones.

This patch updates error message for ISAs with P_ZERO priority.  It also
merges _feature_list into _isa_names_table and marks ISAs, which have
unknown priority, with P_ZERO so that we only need to update one place
to add a new ISA feature.

gcc/

2019-04-25  H.J. Lu  

	PR target/89929
	* config/i386/i386.c (feature_priority): Moved to file scope.
	(processor_features): Likewise.
	(processor_model): Likewise.
	(_arch_names_table): Likewise.
	(arch_names_table): Likewise.
	(_feature_list): Removed.
	(feature_list): Likewise.
	(_isa_names_table): Moved to file scope.  Add priority.
	(isa_names_table): Likewise.
	(get_builtin_code_for_version): Replace feature_list with
	isa_names_table.  Update error message for P_ZERO priority.

gcc/testsuite/

2019-04-25  Martin Liska  
	H.J. Lu  

	PR target/89929
	* g++.target/i386/mv28.C: New test.
	* gcc.target/i386/mvc14.c: Likewise.
	* g++.target/i386/pr57362.C: Updated.
---
 gcc/config/i386/i386.c  | 490 +++-
 gcc/testsuite/g++.target/i386/mv28.C|  26 ++
 gcc/testsuite/g++.target/i386/pr57362.C |   2 +-
 gcc/testsuite/gcc.target/i386/mvc14.c   |  16 +
 4 files changed, 275 insertions(+), 259 deletions(-)
 create mode 100644 gcc/testsuite/g++.target/i386/mv28.C
 create mode 100644 gcc/testsuite/gcc.target/i386/mvc14.c

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 191f570455b..8a1ffd3769f 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -31834,6 +31834,229 @@ add_condition_to_bb (tree function_decl, tree version_decl,
   return bb3;
 }
 
+/* Priority of i386 features, greater value is higher priority.   This is
+   used to decide the order in which function dispatch must happen.  For
+   instance, a version specialized for SSE4.2 should be checked for dispatch
+   before a version for SSE3, as SSE4.2 implies SSE3.  */
+enum feature_priority
+{
+  P_ZERO = 0,
+  P_MMX,
+  P_SSE,
+  P_SSE2,
+  P_SSE3,
+  P_SSSE3,
+  P_PROC_SSSE3,
+  P_SSE4_A,
+  P_PROC_SSE4_A,
+  P_SSE4_1,
+  P_SSE4_2,
+  P_PROC_SSE4_2,
+  P_POPCNT,
+  P_AES,
+  P_PCLMUL,
+  P_AVX,
+  P_PROC_AVX,
+  P_BMI,
+  P_PROC_BMI,
+  P_FMA4,
+  P_XOP,
+  P_PROC_XOP,
+  P_FMA,
+  P_PROC_FMA,
+  P_BMI2,
+  P_AVX2,
+  P_PROC_AVX2,
+  P_AVX512F,
+  P_PROC_AVX512F
+};
+
+/* This is the order of bit-fields in __processor_features in cpuinfo.c */
+enum processor_features
+{
+  F_CMOV = 0,
+  F_MMX,
+  F_POPCNT,
+  F_SSE,
+  F_SSE2,
+  F_SSE3,
+  F_SSSE3,
+  F_SSE4_1,
+  F_SSE4_2,
+  F_AVX,
+  F_AVX2,
+  F_SSE4_A,
+  F_FMA4,
+  F_XOP,
+  F_FMA,
+  F_AVX512F,
+  F_BMI,
+  

Ping: [PATCH] PR88395 Fix Nullptr when compiling with -fconcepts

[nick]

I'm pinging this patch as it's old now and should be applied to fix the bug.

Nick

On 2019-04-08 7:20 p.m., Nicholas Krause wrote:
> This fixes the caller in tsubst_requires_expr to
> tsubst_constraint_variables to wrap their respective
> trees in PARM_CONSTR_PARMS. This is to get the correct
> parmeter constraints from the tree before calling
> tsubst_constraint_variables like other callers
> in constraint.cc and to fix the bug id, 88395 on
> the gcc bugzilla. OK for merge?
> 
> Signed-off-by: Nicholas Krause 
> ---
>  gcc/cp/constraint.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
> index 9884eb0db50..a78d0a9a49b 100644
> --- a/gcc/cp/constraint.cc
> +++ b/gcc/cp/constraint.cc
> @@ -1882,7 +1882,7 @@ tsubst_requires_expr (tree t, tree args,
>tree parms = TREE_OPERAND (t, 0);
>if (parms)
>  {
> -  parms = tsubst_constraint_variables (parms, args, complain, in_decl);
> +  parms = tsubst_constraint_variables (PARM_CONSTR_PARMS (parms), args, 
> complain, in_decl);
>if (parms == error_mark_node)
>  return error_mark_node;
>  }
> 

Replacement for diagnostics linter

[Roland Illig]

There's a linter in contrib/check-internal-format-escaping.py that
checks whether the base file for translations (such as French or German)
conform to some basic style rules. This mostly affects the diagnostics
emitted by GCC.

As the German translation I have added several checks to the linter and
added rationales to most of the checks.

Since I completely rewrote the linter, it's more convenient to not look
at the patch but only the rewritten code. Therefore I've provided both
of them.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90117.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90119.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90176.

Thoughts?
diff --git a/contrib/check-internal-format-escaping.py 
b/contrib/check-internal-format-escaping.py
index 9c625868012..e06752666b8 100755
--- a/contrib/check-internal-format-escaping.py
+++ b/contrib/check-internal-format-escaping.py
@@ -1,7 +1,8 @@
 #!/usr/bin/env python3
 #
-# Check gcc.pot file for gcc-internal-format and print all strings
-# that contain an option that is not wrapped by %<-option_name%>.
+# Check gcc.pot file for stylistic issues as described in
+# https://gcc.gnu.org/onlinedocs/gccint/Guidelines-for-Diagnostics.html,
+# especially in gcc-internal-format messages.
 #
 # This file is part of GCC.
 #
@@ -17,52 +18,249 @@
 #
 # You should have received a copy of the GNU General Public License
 # along with GCC; see the file COPYING3.  If not see
-# .  */
-#
-#
-#
+# .
 
 import argparse
 import re
+from collections import Counter
+from typing import Dict, Match
+
+import polib
+
+seen_warnings = Counter()
+
+
+def location(msg: polib.POEntry):
+if msg.occurrences:
+occ = msg.occurrences[0]
+return f'{occ[0]}:{occ[1]}'
+return ''
+
+
+def warn(msg: polib.POEntry,
+ diagnostic_id: str, diagnostic: str, include_msgid=True):
+"""
+To suppress a warning for a particular message,
+add a line "#, gcclint:ignore:{diagnostic_id}" to the message.
+"""
+
+if f'gcclint:ignore:{diagnostic_id}' in msg.flags:
+return
+
+seen_warnings[diagnostic] += 1
+
+if include_msgid:
+print(f'{location(msg)}: {diagnostic} in {repr(msg.msgid)}')
+else:
+print(f'{location(msg)}: {diagnostic}')
+
+
+def lint_gcc_internal_format(msg: polib.POEntry):
+"""
+Checks a single message that has the gcc-internal-format. These
+messages use a variety of placeholders like %qs, % and
+%q#E.
+"""
+
+msgid: str = msg.msgid
+
+def outside_quotes(m: Match[str]):
+before = msgid[:m.start(0)]
+return before.count("%<") == before.count("%>")
+
+def lint_matching_placeholders():
+"""
+Warns when literal values in placeholders are not exactly equal
+in the translation. This can happen when doing copy-and-paste
+translations of similar messages.
+
+To avoid these mismatches in the first place,
+structurally equal messages are found by
+lint_diagnostics_differing_only_in_placeholders.
+
+This check only applies when checking a finished translation
+such as de.po, not gcc.pot.
+"""
+
+if not msg.translated():
+return
+
+in_msgid = re.findall('%<[^%]+%>', msgid)
+in_msgstr = re.findall('%<[^%]+%>', msg.msgstr)
+
+if set(in_msgid) != set(in_msgstr):
+warn(msg,
+ 'placeholder-mismatch',
+ f'placeholder mismatch: msgid has {in_msgid}, '
+ f'msgstr has {in_msgstr}',
+ include_msgid=False)
+
+def lint_option_outside_quotes():
+for match in re.finditer(r'\S+', msgid):
+part = match.group()
+if not outside_quotes(match):
+continue
+
+if part.startswith('-'):
+if len(part) >= 2 and part[1].isalpha():
+if part == '-INF':
+continue
+
+warn(msg,
+ 'option-outside-quotes',
+ 'command line option outside %')
+
+if part.startswith('__builtin_'):
+warn(msg,
+ 'builtin-outside-quotes',
+ 'builtin function outside %')
+
+def lint_plain_apostrophe():
+for match in re.finditer("[^%]'", msgid):
+if outside_quotes(match):
+warn(msg, 'apostrophe', 'apostrophe without leading %')
+
+def lint_space_before_quote():
+"""
+A space before %< is often the result of string literals that
+are joined by the C compiler and neither literal has a space
+to separate the words.
+"""
+
+for match in re.finditer("(.?[a-zA-Z0-9])%<", msgid):
+if match.group(1) != '%s':
+warn(msg,
+ 'no-space-before-quote',
+ '%< directly f

[PATCH] PR bootstrap/87338: Fix ia64 bootstrap comparison regression in r257511

[James Clarke]

By using ASM_OUTPUT_LABEL, r257511 forced the assembler to start a new
bundle when emitting an inline entry label on. Instead, use
ASM_OUTPUT_DEBUG_LABEL like for the block begin and end labels so tags are
emitted rather than labels.

gcc/
PR bootstrap/87338
* dwarf2out.c (dwarf2out_inline_entry): Use ASM_OUTPUT_DEBUG_LABEL
instead of ASM_GENERATE_INTERNAL_LABEL and ASM_OUTPUT_LABEL.
---
 gcc/dwarf2out.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index b9a624e..c348692 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -27670,11 +27670,8 @@ dwarf2out_inline_entry (tree block)
   if (cur_line_info_table)
 ied->view = cur_line_info_table->view;
 
-  char label[MAX_ARTIFICIAL_LABEL_BYTES];
-
-  ASM_GENERATE_INTERNAL_LABEL (label, BLOCK_INLINE_ENTRY_LABEL,
-  BLOCK_NUMBER (block));
-  ASM_OUTPUT_LABEL (asm_out_file, label);
+  ASM_OUTPUT_DEBUG_LABEL (asm_out_file, BLOCK_INLINE_ENTRY_LABEL,
+ BLOCK_NUMBER (block));
 }
 
 /* Called from finalize_size_functions for size functions so that their body
-- 
1.8.5.3

Re: [PATCH] Fix PR89765

[Jakub Jelinek]

On Thu, Apr 25, 2019 at 04:58:57PM +0200, Richard Biener wrote:
> 2019-04-25  Richard Biener  
> 
>   PR middle-end/89765
>   * gimplify.c (gimplify_expr): Avoid turning a lvalue
>   VIEW_CONVERT_EXPR into one operating on an rvalue.

Successfully bootstrapped/regtested on {powerpc64{,le},x86_64,i686}-linux.

> --- gcc/gimplify.c(revision 270574)
> +++ gcc/gimplify.c(working copy)
> @@ -12397,7 +12397,8 @@ gimplify_expr (tree *expr_p, gimple_seq
> break;
>  
>   case VIEW_CONVERT_EXPR:
> -   if (is_gimple_reg_type (TREE_TYPE (*expr_p))
> +   if ((fallback & fb_rvalue)
> +   && is_gimple_reg_type (TREE_TYPE (*expr_p))
> && is_gimple_reg_type (TREE_TYPE (TREE_OPERAND (*expr_p, 0
>   {
> ret = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p,

Jakub

Re: [PATCH] Implement LWG 3062, Unnecessary decay_t in is_execution_policy_v

[Thomas Rodgers]

Revised patch.

>From 074685cf74b48604244c0c6f1d8cba63ff8915e5 Mon Sep 17 00:00:00 2001
From: Thomas Rodgers 
Date: Wed, 24 Apr 2019 15:53:45 -0700
Subject: [PATCH] Implement LWG 3062, Unnecessary decay_t in
 is_execution_policy_v

	should be remove_cvref_t
	* include/pstl/execution_defs.h (__enable_if_execution_policy):
Use std::__remove_cv_ref_t when building with GCC.
---
 libstdc++-v3/include/pstl/execution_defs.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libstdc++-v3/include/pstl/execution_defs.h b/libstdc++-v3/include/pstl/execution_defs.h
index 86c7a5a770d..0ed4cc30914 100644
--- a/libstdc++-v3/include/pstl/execution_defs.h
+++ b/libstdc++-v3/include/pstl/execution_defs.h
@@ -152,9 +152,15 @@ constexpr bool is_execution_policy_v = __pstl::execution::is_execution_policy<_T
 namespace __internal
 {
 template 
+#if _GLIBCXX_RELEASE >= 9
+using __enable_if_execution_policy =
+typename std::enable_if<__pstl::execution::is_execution_policy>::value,
+_T>::type;
+#else
 using __enable_if_execution_policy =
 typename std::enable_if<__pstl::execution::is_execution_policy::type>::value,
 _T>::type;
+#endif
 } // namespace __internal
 
 } // namespace __pstl
-- 
2.20.1


Jonathan Wakely writes:

> On 24/04/19 16:01 -0700, Thomas Rodgers wrote:
>>
>>  should be remove_cvref_t
>>  * include/pstl/execution_defs.h (__enable_if_execution_policy):
>>Use std::__remove_cv_ref_t when building with GCC
>>
>
>>From cb7bd9a39acacbf81df0d03da8714fa463057cc5 Mon Sep 17 00:00:00 2001
>>From: Thomas Rodgers 
>>Date: Wed, 24 Apr 2019 15:53:45 -0700
>>Subject: [PATCH] Implement LWG 3062, Unnecessary decay_t in
>> is_execution_policy_v
>>
>>  should be remove_cvref_t
>>  * include/pstl/execution_defs.h (__enable_if_execution_policy):
>>Use std::__remove_cv_ref_t when building with GCC.
>>---
>> libstdc++-v3/include/pstl/execution_defs.h | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>>diff --git a/libstdc++-v3/include/pstl/execution_defs.h 
>>b/libstdc++-v3/include/pstl/execution_defs.h
>>index 86c7a5a770d..9b9b212b1bd 100644
>>--- a/libstdc++-v3/include/pstl/execution_defs.h
>>+++ b/libstdc++-v3/include/pstl/execution_defs.h
>>@@ -152,9 +152,15 @@ constexpr bool is_execution_policy_v = 
>>__pstl::execution::is_execution_policy<_T
>> namespace __internal
>> {
>> template 
>>+#if __GNUC__
>
> Clang and Intel both define that macro, but that doesn't mean
> __remove_cvref_t is available. I think you want __GLIBCXX__ to tell
> that libstdc++ is in use, or better still:
>
> #if _GLIBCXX_RELEASE >= 9
>
>>+using __enable_if_execution_policy =
>>+typename std::enable_if<__pstl::execution::is_execution_policy>std::__remove_cvref_t<_ExecPolicy>>::value,
>
> The typename before std::__remove_cvref_t shouldn't be there.
>
>>+_T>::type;
>>+#else
>> using __enable_if_execution_policy =
>> typename std::enable_if<__pstl::execution::is_execution_policy> std::decay<_ExecPolicy>::type>::value,
>> _T>::type;
>>+#endif
>> } // namespace __internal
>>
>> } // namespace __pstl
>> -- 
>>2.20.1
>>

Re: [PATCH] Implement LWG 3062, Unnecessary decay_t in is_execution_policy_v

[Jonathan Wakely]

On 25/04/19 11:51 -0700, Thomas Rodgers wrote:

Revised patch.




From 074685cf74b48604244c0c6f1d8cba63ff8915e5 Mon Sep 17 00:00:00 2001
From: Thomas Rodgers 
Date: Wed, 24 Apr 2019 15:53:45 -0700
Subject: [PATCH] Implement LWG 3062, Unnecessary decay_t in
is_execution_policy_v

should be remove_cvref_t
* include/pstl/execution_defs.h (__enable_if_execution_policy):
   Use std::__remove_cv_ref_t when building with GCC.


OK for trunk (but not for gcc-9-branch). Thanks.

Re: [PATCH, rs6000] PR89424: __builtin_vec_ext_v1ti (v, i) results in ICE with variable i (RS6000)

[Segher Boessenkool]

On Thu, Apr 25, 2019 at 11:02:09AM -0500, Kelvin Nilsen wrote:
> The attached patch resolves the issue described in this problem report.  The 
> patch has been bootstrapped and tested without regressions on 
> powerpc64le-unknown-linux-gnu (both P8 and P9) and on powerpc64-linux (P7 and 
> P8, both -m32 and -m64).
> 
> Is this ok for trunk and backports?

It is okay for trunk and backports, but you may want to hold off until
after the GCC 9 release.  For the gcc-9 branch you need the RMs' approval.

A few testcase comments:

> --- gcc/testsuite/gcc.target/powerpc/pr89424-0.c  (nonexistent)
> +++ gcc/testsuite/gcc.target/powerpc/pr89424-0.c  (working copy)
> @@ -0,0 +1,78 @@
> +/* { dg-do run { target { powerpc*-*-* && lp64 } } } */
> +/* { dg-skip-if "" { powerpc*-*-darwin* } } */
> +/* { dg-require-effective-target vsx_hw } */

I think such "darwin" lines are useless; vsx_hw will not be true on Darwin.

> +/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { } } 
> */

We do not need this anymore either (and this test never needed it).

> +/* { dg-options "-mvsx" } */


Thanks,


Segher

[PATCH, doc]: Add missing comma after @xref.

[Uros Bizjak]

2019-04-25  Uroš Bizjak  

* doc/extend.texi (vector_size): Add missing comma after @xref.

Bootstrapped on x86_64-linux-gnu, committed to mainline SVN.

Uros.
Index: extend.texi
===
--- extend.texi (revision 270583)
+++ extend.texi (working copy)
@@ -7094,7 +7094,7 @@
 divided into @code{int} sized units.  Assuming a 32-bit @code{int},
 @code{foo}'s type is a vector of four units of four bytes each, and
 the corresponding mode of @code{foo} is @code{V4SI}.
-@xref{Vector Extensions} for details of manipulating vector variables.
+@xref{Vector Extensions}, for details of manipulating vector variables.
 
 This attribute is only applicable to integral and floating scalars,
 although arrays, pointers, and function return values are allowed in
@@ -8178,7 +8178,7 @@
 a vector of eight units, four bytes each.  The mode of variables of type
 @code{int_vec32_t} is @code{V8SI}.  @code{int_vec32_ptr_t} is then defined
 to be a pointer to such a vector type, and @code{int_vec32_arr3_t} to be
-an array of three such vectors.  @xref{Vector Extensions} for details of
+an array of three such vectors.  @xref{Vector Extensions}, for details of
 manipulating objects of vector types.
 
 This attribute is only applicable to integral and floating scalar types.

Re: C++ PATCH to add test for c++/90236

[Jason Merrill]

On Wed, Apr 24, 2019 at 5:26 PM Marek Polacek  wrote:
>
> This valid test started to be accepted with r265789, which removed the
> following checks.

It didn't remove them, it moved them into invalid_tparm_referent_p.
And changed the tests for C++17.

> I wonder if we want to remove them in gcc 8, or just leave them in place.

I wouldn't mess with GCC 8; that's a big patch, and it's not a
regression, it's a C++17 change we didn't implement before.

Jason

Re: [patch] Multilib support for amd64 FreeBSD

[Andreas Tobler]

On 18.03.19 22:28, Andreas Tobler wrote:

On 18.03.19 22:22, Jeff Law wrote:

On 3/17/19 2:40 PM, Andreas Tobler wrote:

Hi all,

this patch adds support for multilib on x86_64-unknown-freebsd*
The multilibs are 32-bit.

This patch is functionality tested on gcc8 and gcc9. Test suite testing
is a bit tricky since the FreeBSD dynamic linker handles both, the
32-bit and the 64-bit binaries. So, if I have a 64-bit libgcc in the
LD_LIBRARY_PATH the test fails.
I tweaked the build tree and removed the 64-bit libgcc to test the
32-bit binaries built. So far it looks good. Need to find a way to
extend the testsuite to handle this situation.

Any comments about it are welcome.

Also, when would be the best time to commit this patch? Afair trunk is
in stage4, right?
The patch itself only affects x86_64-unknown-freebsd.

TIA,
Andreas

2019-03-17  Andreas Tobler  

  * config/i386/freebsd64.h: Add bits for 32-bit multilib support.
  * config/i386/t-freebsd64: New file.
  * config.gcc: Add the t-freebsd64 for multilib support.



stage4 is supposed to be regression fixes only, so it's difficult to
make a case for this patch to get into gcc-9.

I'd say defer to gcc-10.


Ok, fine with me.
Once gcc-10 opens, I will commit this patch also to all open and active
branches.


Pushed to trunk, branches will follow.

Andreas

Re: C++ PATCH to add test for c++/90236

[Marek Polacek]

On Thu, Apr 25, 2019 at 03:56:40PM -0400, Jason Merrill wrote:
> On Wed, Apr 24, 2019 at 5:26 PM Marek Polacek  wrote:
> >
> > This valid test started to be accepted with r265789, which removed the
> > following checks.
> 
> It didn't remove them, it moved them into invalid_tparm_referent_p.
> And changed the tests for C++17.

Hmm, I didn't see that.

> > I wonder if we want to remove them in gcc 8, or just leave them in place.
> 
> I wouldn't mess with GCC 8; that's a big patch, and it's not a
> regression, it's a C++17 change we didn't implement before.

Makes sense; I closed the BZ.  Thanks,

Marek

[PATCH] PR c++/90243 - orphaned note in uninstantiated constexpr function

[Jonathan Wakely]

gcc/cp:

PR c++/90243 - orphaned note in uninstantiated constexpr function
* decl.c (check_for_uninitialized_const_var): Suppress notes if no
error was shown.

gcc/testsuite:

PR c++/90243
* g++.dg/diagnostic/pr90243.C: New test.

Tested powerpc64le-linux, OK for trunk?


commit 5c7cb4d6d48be1d6c8609ba691b7b279b97c46c9
Author: Jonathan Wakely 
Date:   Thu Apr 25 09:25:55 2019 +0100

PR c++/90243 - orphaned note in uninstantiated constexpr function

gcc/cp:

PR c++/90243 - orphaned note in uninstantiated constexpr function
* decl.c (check_for_uninitialized_const_var): Suppress notes if no
error was shown.

gcc/testsuite:

PR c++/90243
* g++.dg/diagnostic/pr90243.C: New test.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 01c89cd572d..b91cdb6d26b 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -5691,13 +5691,15 @@ check_for_uninitialized_const_var (tree decl, bool 
constexpr_context_p,
   if (!field)
return true;
 
+  bool show_notes = true;
+
   if (!constexpr_context_p)
{
  if (CP_TYPE_CONST_P (type))
{
  if (complain & tf_error)
-   permerror (DECL_SOURCE_LOCATION (decl),
-  "uninitialized const %qD", decl);
+   show_notes = permerror (DECL_SOURCE_LOCATION (decl),
+   "uninitialized const %qD", decl);
}
  else
{
@@ -5706,6 +5708,8 @@ check_for_uninitialized_const_var (tree decl, bool 
constexpr_context_p,
error_at (DECL_SOURCE_LOCATION (decl),
  "uninitialized variable %qD in % "
  "function", decl);
+ else
+   show_notes = false;
  cp_function_chain->invalid_constexpr = true;
}
}
@@ -5714,7 +5718,7 @@ check_for_uninitialized_const_var (tree decl, bool 
constexpr_context_p,
  "uninitialized variable %qD in % context",
  decl);
 
-  if (CLASS_TYPE_P (type) && (complain & tf_error))
+  if (show_notes && CLASS_TYPE_P (type) && (complain & tf_error))
{
  tree defaulted_ctor;
 
diff --git a/gcc/testsuite/g++.dg/diagnostic/pr90243.C 
b/gcc/testsuite/g++.dg/diagnostic/pr90243.C
new file mode 100644
index 000..3f5d915affc
--- /dev/null
+++ b/gcc/testsuite/g++.dg/diagnostic/pr90243.C
@@ -0,0 +1,13 @@
+// { dg-do compile { target c++14 } }
+struct Z { // { dg-bogus "default constructor" }
+  int y;   // { dg-bogus "initialize" }
+};
+
+template 
+constexpr Z f(const T *data) {
+  Z z;
+  __builtin_memcpy(&z, data, sizeof(z));
+  return z;
+}
+
+constexpr Z g(const char *data) { return f(data); }

Re: [PATCH] PR c++/90243 - orphaned note in uninstantiated constexpr function

[Jason Merrill]

Perhaps initialize show_notes to (complain & tf_error), so you only
need to update it from permerror.


On Thu, Apr 25, 2019 at 4:31 PM Jonathan Wakely  wrote:
>
> gcc/cp:
>
> PR c++/90243 - orphaned note in uninstantiated constexpr function
> * decl.c (check_for_uninitialized_const_var): Suppress notes if no
> error was shown.
>
> gcc/testsuite:
>
> PR c++/90243
> * g++.dg/diagnostic/pr90243.C: New test.
>
> Tested powerpc64le-linux, OK for trunk?
>
>

Re: [PATCH] Fix -Wunused-var-35.C (was Re: [PATCH][C++] Improve compile-time by ordering expensive checks last)

[Jason Merrill]

OK.

On Thu, Apr 25, 2019 at 7:27 AM Jakub Jelinek  wrote:
>
> On Thu, Apr 25, 2019 at 01:09:00PM +0200, Rainer Orth wrote:
> > > cp/
> > > * call.c (null_ptr_cst_p): Order checks according to expensiveness.
> > > (conversion_null_warnings): Likewise.
> > > * typeck.c (same_type_ignoring_top_level_qualifiers_p): Return
> > > early if type1 == type2.
> >
> > this patch caused
> >
> > +XPASS: g++.dg/warn/Wunused-var-35.C  -std=gnu++98 bug (test for warnings, 
> > line 14)
> >
> > First seen on i386-pc-solaris2.11 and sparc-sun-solaris2.11, according
> > to gcc-testresults everywhere.  Confirmed by reverting the patch locally
> > and re-testing the affected testcase.
>
> I can reproduce that too, seems to be the
> @@ -6896,8 +6897,8 @@
>  }
>/* Handle zero as null pointer warnings for cases other
>   than EQ_EXPR and NE_EXPR */
> -  else if (null_ptr_cst_p (expr) &&
> -  (TYPE_PTR_OR_PTRMEM_P (totype) || NULLPTR_TYPE_P (totype)))
> +  else if ((TYPE_PTR_OR_PTRMEM_P (totype) || NULLPTR_TYPE_P (totype))
> +  && null_ptr_cst_p (expr))
>  {
>location_t loc = get_location_for_expr_unwinding_for_system_header 
> (expr);
>maybe_warn_zero_as_null_pointer_constant (expr, loc);
> hunk.  The Wunused-var-35.C patch hasn't been posted to gcc-patches, but
> judging from the corresponding PR, I'd say the right thing is below.
>
> Regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2019-04-25  Jakub Jelinek  
>
> PR c++/44648
> * g++.dg/warn/Wunused-var-35.C: Remove xfail.
>
> --- gcc/testsuite/g++.dg/warn/Wunused-var-35.C.jj   2019-02-04 
> 09:44:31.365413407 +0100
> +++ gcc/testsuite/g++.dg/warn/Wunused-var-35.C  2019-04-25 13:24:49.717065815 
> +0200
> @@ -11,9 +11,8 @@ int main()
>else
>  return 1;
>
> -  if (const bool b2 = 1) // { dg-warning "\\\[-Wunused-variable\\\]" "bug" { 
> xfail c++98_only } }
> +  if (const bool b2 = 1) // { dg-warning "\\\[-Wunused-variable\\\]" }
>  return 0;
>else
>  return 1;
>  }
> -
>
>
> Jakub

Re: [C++ Patch] PR 90173 ("[9 Regression] ICE: Segmentation fault (in strip_declarator_types)")

[Jason Merrill]

On Tue, Apr 23, 2019 at 11:26 AM Paolo Carlini  wrote:
>
> I tried a few different things to avoid this simple error-recovery
> regression but, all in all, I think it makes sense to simply bail out
> early from grokdeclarator upon the first error. Tested x86_64-linux.

"type = error_mark_node" doesn't work?

Jason

[PATCH] PR libstdc++/90239 Fix status of P0591R4 in C++2a support table

[Jonathan Wakely]

PR libstdc++/90239
* doc/xml/manual/status_cxx2020.xml: Correct status of P0591R4.
* doc/html/*: Regenerate.

This corrects the docs to reflect the real status in gcc-9-branch.
I'll fix it properly on trunk (and later backport it to 9.2).


commit 4ca0b71dbd9355c73f2137390154c5a28d6a189c
Author: Jonathan Wakely 
Date:   Thu Apr 25 21:49:37 2019 +0100

PR libstdc++/90239 Fix status of P0591R4 in C++2a support table

PR libstdc++/90239
* doc/xml/manual/status_cxx2020.xml: Correct status of P0591R4.
* doc/html/*: Regenerate.

diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml 
b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
index cedb3d03066..c84cd86c4ee 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
@@ -667,6 +667,7 @@ Feature-testing recommendations for C++.
 
 
 
+  
 Utility functions to implement uses-allocator construction 

   
 http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0591r4.pdf";>
@@ -674,7 +675,7 @@ Feature-testing recommendations for C++.

   
9.1 
-  
+  Missing changes to 
std::scoped_allocator_adaptor
 
 
 

Re: [PATCH] PR libstdc++/90239 Fix status of P0591R4 in C++2a support table

[Jakub Jelinek]

On Thu, Apr 25, 2019 at 10:31:36PM +0100, Jonathan Wakely wrote:
>   PR libstdc++/90239
>   * doc/xml/manual/status_cxx2020.xml: Correct status of P0591R4.
>   * doc/html/*: Regenerate.
> 
> This corrects the docs to reflect the real status in gcc-9-branch.
> I'll fix it properly on trunk (and later backport it to 9.2).
> 
> 

> commit 4ca0b71dbd9355c73f2137390154c5a28d6a189c
> Author: Jonathan Wakely 
> Date:   Thu Apr 25 21:49:37 2019 +0100
> 
> PR libstdc++/90239 Fix status of P0591R4 in C++2a support table
> 
> PR libstdc++/90239
> * doc/xml/manual/status_cxx2020.xml: Correct status of P0591R4.
> * doc/html/*: Regenerate.

Ok.

> diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml 
> b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
> index cedb3d03066..c84cd86c4ee 100644
> --- a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
> +++ b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
> @@ -667,6 +667,7 @@ Feature-testing recommendations for C++.
>  
>  
>  
> +  
>  Utility functions to implement uses-allocator construction 
> 
>
>  http://www.w3.org/1999/xlink"; 
> xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0591r4.pdf";>
> @@ -674,7 +675,7 @@ Feature-testing recommendations for C++.
>   
>
> 9.1 
> -  
> +  Missing changes to 
> std::scoped_allocator_adaptor
>  
>  
>  


Jakub

[PATCH] PR libstdc++/90239 use uses_allocator_construction_args in

[Jonathan Wakely]

PR libstdc++/90239
* doc/xml/manual/status_cxx2020.xml: Amend P0591R4 status.
* include/std/scoped_allocator [__cplusplus > 201703L]
(scoped_allocator_adaptor::construct): Define in terms of
uses_allocator_construction_args, as per P0591R4.
* testsuite/20_util/scoped_allocator/construct_pair_c++2a.cc: New test.
* testsuite/util/testsuite_allocator.h: Remove name of unused
parameter.

Tested powerpc64le-linux, committed to trunk.

I'll backport this to gcc-9-branch after the 9.1.0 release.

commit 334fd4749cb72fa39413639d2db6718f1b411527
Author: Jonathan Wakely 
Date:   Thu Apr 25 20:37:58 2019 +0100

PR libstdc++/90239 use uses_allocator_construction_args in 


PR libstdc++/90239
* doc/xml/manual/status_cxx2020.xml: Amend P0591R4 status.
* include/std/scoped_allocator [__cplusplus > 201703L]
(scoped_allocator_adaptor::construct): Define in terms of
uses_allocator_construction_args, as per P0591R4.
* testsuite/20_util/scoped_allocator/construct_pair_c++2a.cc: New 
test.
* testsuite/util/testsuite_allocator.h: Remove name of unused
parameter.

diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml 
b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
index cedb3d03066..a075103ea4a 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
@@ -674,7 +674,9 @@ Feature-testing recommendations for C++.

   
9.1 
-  
+  
+std::scoped_allocator_adaptor changes missing in 9.1.0
+  
 
 
 
diff --git a/libstdc++-v3/include/std/scoped_allocator 
b/libstdc++-v3/include/std/scoped_allocator
index 335df483f69..2c7ad8e94d7 100644
--- a/libstdc++-v3/include/std/scoped_allocator
+++ b/libstdc++-v3/include/std/scoped_allocator
@@ -35,6 +35,7 @@
 # include 
 #else
 
+#include 
 #include 
 #include 
 #include 
@@ -187,6 +188,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
using __outermost_alloc_traits
  = allocator_traits::type>;
 
+#if __cplusplus <= 201703
   template
 void
 _M_construct(__uses_alloc0, _Tp* __p, _Args&&... __args)
@@ -218,6 +220,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   std::forward<_Args>(__args)...,
   inner_allocator());
 }
+#endif // C++17
 
   template
 static _Alloc
@@ -355,6 +358,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   size_type max_size() const
   { return __traits::max_size(outer_allocator()); }
 
+#if __cplusplus <= 201703
   template
typename __not_pair<_Tp>::type
construct(_Tp* __p, _Args&&... __args)
@@ -417,6 +421,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
std::forward_as_tuple(std::forward<_Up>(__x.first)),
std::forward_as_tuple(std::forward<_Vp>(__x.second)));
}
+#else // C++2a
+  template
+   __attribute__((__nonnull__))
+   void
+   construct(_Tp* __p, _Args&&... __args)
+   {
+ typedef __outermost_alloc_traits _O_traits;
+ std::apply([__p, this](auto&&... __newargs) {
+ _O_traits::construct(__outermost(*this), __p,
+ std::forward(__newargs)...);
+ },
+ uses_allocator_construction_args<_Tp>(inner_allocator(),
+   std::forward<_Args>(__args)...));
+   }
+#endif // C++2a
 
   template
 void destroy(_Tp* __p)
@@ -439,6 +458,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  const scoped_allocator_adaptor<_OutA2, _InA...>& __b) 
noexcept;
 
 private:
+#if __cplusplus <= 201703L
   template
tuple<_Args&&...>
_M_construct_p(__uses_alloc0, _Ind, tuple<_Args...>& __t)
@@ -461,6 +481,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
  return { std::get<_Ind>(std::move(__t))..., inner_allocator() };
}
+#endif // C++17
 };
 
   template 
diff --git 
a/libstdc++-v3/testsuite/20_util/scoped_allocator/construct_pair_c++2a.cc 
b/libstdc++-v3/testsuite/20_util/scoped_allocator/construct_pair_c++2a.cc
new file mode 100644
index 000..1630f2a4d09
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/scoped_allocator/construct_pair_c++2a.cc
@@ -0,0 +1,97 @@
+// Copyright (C) 2019 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 

Re: [PATCH] PR c++/90243 - orphaned note in uninstantiated constexpr function

[Jonathan Wakely]

On 25/04/19 17:02 -0400, Jason Merrill wrote:

Perhaps initialize show_notes to (complain & tf_error), so you only
need to update it from permerror.


But doesn't fix the bug, because the error is only printed for
!is_instantiation_of_constexpr (current_function_decl) 
so we need to suppress the notes otherwise.



On Thu, Apr 25, 2019 at 4:31 PM Jonathan Wakely  wrote:


gcc/cp:

PR c++/90243 - orphaned note in uninstantiated constexpr function
* decl.c (check_for_uninitialized_const_var): Suppress notes if no
error was shown.

gcc/testsuite:

PR c++/90243
* g++.dg/diagnostic/pr90243.C: New test.

Tested powerpc64le-linux, OK for trunk?

[PATCH] tbb-backend effective target should check ability to link TBB

[Thomas Rodgers]

PR libstdc++/90252
* testsuite/lib/libstdc++.exp (check_effective_target_tbb-backend):
Changed v3_target_compile check from preprocess to executable.
---
 libstdc++-v3/testsuite/lib/libstdc++.exp | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
b/libstdc++-v3/testsuite/lib/libstdc++.exp
index c48b4d78bbb..fa61bccc9f6 100644
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -1612,15 +1612,20 @@ proc check_effective_target_tbb-backend { } {
 # Set up and preprocess a C++ test program that depends
 # on tbb
 set src tbb_backend[pid].cc
-
+set exe tbb_backend[pid].x
+
 set f [open $src "w"]
 puts $f "#include "
 puts $f "#if TBB_INTERFACE_VERSION < 1"
 puts $f "#  error Intel(R) Threading Building Blocks 2018 is required; 
older versions are not supported."
 puts $f "#endif"
+puts $f "int main ()"
+puts $f "{"
+puts $f "  return 0;"
+puts $f "}"
 close $f
 
-set lines [v3_target_compile $src /dev/null preprocess ""]
+set lines [v3_target_compile $src $exe executable ""]
 file delete $src
 
 if [string match "" $lines] {
-- 
2.20.1

Re: [C++ Patch] PR 90173 ("[9 Regression] ICE: Segmentation fault (in strip_declarator_types)")

[Paolo Carlini]

Hi,

On 25/04/19 23:14, Jason Merrill wrote:

On Tue, Apr 23, 2019 at 11:26 AM Paolo Carlini  wrote:

I tried a few different things to avoid this simple error-recovery
regression but, all in all, I think it makes sense to simply bail out
early from grokdeclarator upon the first error. Tested x86_64-linux.

"type = error_mark_node" doesn't work?


Yes, it passes testing and appears to work fine: in practice for the new 
testcase grokdeclarator doesn't issue any further diagnostic and returns 
error_mark_node a few lines below, around line # 11256. Shall we apply 
this version to gcc-9-branch too?


Thanks! Paolo.

Re: [PATCH, RFC, rs6000] PR80791 Consider doloop in ivopts

[Kewen.Lin]

Hi Segher,

Thanks a lot for your comments!

on 2019/4/25 下午8:16, Segher Boessenkool wrote:
 
> Does it create worse code now?  What we have before your patch isn't
> so super either (it has an sldi in the loop, it has two mtctr too).
> Maybe you can show the generated code?

It's a good question! From the generated codes for the core loop, the 
code after my patch doesn't have bdnz to leverage hardware CTR, it has
extra cmpld and branch instead, looks worse.  But I wrote a tiny case
to invoke the foo and evaluated the running time, they are equal.

* Measured time:
  After:
real 199.47
user 198.35
sys 1.11
  Before:
real 199.19
user 198.56
sys 0.62

* Command I used to compile:
${local_gcc} ${case_src}/20050830-1.c  -fno-diagnostics-show-caret 
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never  -O2 
-ffat-lto-objects -fno-ident -c

* main file (main.c):
extern void foo();
#define LOOPNUM 1
#define N 100*256
int a[N];
int main() {
  for(int i = 0; i < LOOPNUM; i++) {
foo(N);
  }
}


* Generated code sequence:

Before my patch:

cmpwi 0,3,511
blelr 0
addi 10,3,-256
addi 9,3,-512
addis 8,2,.LC0@toc@ha
ld 8,.LC0@toc@l(8)
cmpwi 0,10,256
rldicl 9,9,56,40
sldi 3,3,2
addi 9,9,1
mtctr 9
add 8,3,8
li 10,42
blt 0,.L7 # jump to L7 it's less than 256
.L3:  # core loop
stw 10,0(8)   
addi 8,8,-1024
bdnz .L3
blr
.L7:
li 9,1# special case, iteration only 1
mtctr 9
b .L3

After my patch:

cmpwi 0,3,511
blelr 0
addis 7,2,.LC0@toc@ha
ld 7,.LC0@toc@l(7)
addi 10,3,-512
sldi 9,3,2
rlwinm 10,10,0,0,23
li 8,42
subf 10,10,3
sldi 10,10,2
addi 6,7,-1024
add 9,9,7
add 10,10,6
.p2align 4,,15
.L3:  # core loop
stw 8,0(9)
addi 9,9,-1024
cmpld 0,9,10  # cmp 
beqlr 0   # if eq, return
stw 8,0(9) 
addi 9,9,-1024   
cmpld 0,9,10  # cmp again 
bne 0,.L3 # if ne, jump to L3.
blr



I practiced whether we can adjust the decision made in ivopts.
For one compare iv use with zero cost, if one iv cand whose base
is from memory has costly elim_cost before adjust_setup_cost,
it's possible to make later analysis unable to find it's finite,
then we try to avoid it.

The diff looks like:

--- a/gcc/tree-ssa-loop-ivopts.c
+++ b/gcc/tree-ssa-loop-ivopts.c
@@ -5126,6 +5126,7 @@ determine_group_iv_cost_cond (struct ivopts_data *data,
   tree *control_var, *bound_cst;
   enum tree_code comp = ERROR_MARK;
   struct iv_use *use = group->vuses[0];
+  bool dont_elim_p = false;

   /* Extract condition operands.  */
   rewrite_type = extract_cond_operands (data, use->stmt, &control_var,
@@ -5152,6 +5153,16 @@ determine_group_iv_cost_cond (struct ivopts_data *data,
  inv_expr_elim = get_loop_invariant_expr (data, bound);
  bitmap_clear (inv_vars_elim);
}
+
+  /* zero cost use makes it easier to select memory based iv cand
+ for replacement of non memory based iv and its use.   But if
+ the setup sequence are too costly, loop iv analysis can NOT
+ easily figure out it's finite, it's possible to stop the
+ low-overhead loop transformation and get unexpected code.  */
+  if (use->zero_cost_p && cand->iv->base_object && !use->iv->base_object
+ && elim_cost.cost >= 30)
+   dont_elim_p = true;
+
   /* The bound is a loop invariant, so it will be only computed
 once.  */
   elim_cost.cost = adjust_setup_cost (data, elim_cost.cost);
@@ -5184,7 +5195,7 @@ determine_group_iv_cost_cond (struct ivopts_data *data,
   express_cost += bound_cost;

   /* Choose the better approach, preferring the eliminated IV. */
-  if (elim_cost <= express_cost)
+  if (elim_cost <= express_cost && !dont_elim_p)
 {


I was thinking whether this zero cost change just exposed
an existing problem, then this kind of check should be for all 
cases not only for zero cost use, similar to 
expression_expensive_p?  But why doesn't it happen before?
Need more investigation.

> 
>> Btw, this is for GCC10.
> 
> *Phew* ;-)
> 
> 
> Some trivial comments:
> 
>> +static bool
>> +invalid_insn_for_doloop_p (struct loop *loop)
>> +{
>> +  basic_block *body = get_loop_body (loop);
>> +  unsigned num_nodes = loop->num_nodes;
>> +  gimple_stmt_iterator gsi;
>> +  unsigned i;
>> +
>> +  for (i = 0; i < num_nodes; i++)
> 
>   for (unsigned i = 0; i < num_nodes; i++)
> 
> (and maybe you can just say loop->num_nodes here; I don't know if that
> generates worse code, or if that even matters).

Good idea, will fix it.

> 
>> +if (dump_file && (dump_flags & TDF_DETAILS))
>> +  fprintf (
>> +dump_file,
>> + 

Re: [PATCH] PR bootstrap/87338: Fix ia64 bootstrap comparison regression in r257511

[Richard Biener]

On Thu, Apr 25, 2019 at 7:52 PM James Clarke  wrote:
>
> By using ASM_OUTPUT_LABEL, r257511 forced the assembler to start a new
> bundle when emitting an inline entry label on. Instead, use
> ASM_OUTPUT_DEBUG_LABEL like for the block begin and end labels so tags are
> emitted rather than labels.

Looks sensible.  mips is the other port defining ASM_OUTPUT_DEBUG_LABEL,
so either you can do a bootstrap/test on mips as well or I'm asking Matthew
for approval here.

I'd say OK for trunk (GCC 10) and if things look good backport later to active
branches.

Thanks,
Richard.

> gcc/
> PR bootstrap/87338
> * dwarf2out.c (dwarf2out_inline_entry): Use ASM_OUTPUT_DEBUG_LABEL
> instead of ASM_GENERATE_INTERNAL_LABEL and ASM_OUTPUT_LABEL.
> ---
>  gcc/dwarf2out.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
> index b9a624e..c348692 100644
> --- a/gcc/dwarf2out.c
> +++ b/gcc/dwarf2out.c
> @@ -27670,11 +27670,8 @@ dwarf2out_inline_entry (tree block)
>if (cur_line_info_table)
>  ied->view = cur_line_info_table->view;
>
> -  char label[MAX_ARTIFICIAL_LABEL_BYTES];
> -
> -  ASM_GENERATE_INTERNAL_LABEL (label, BLOCK_INLINE_ENTRY_LABEL,
> -  BLOCK_NUMBER (block));
> -  ASM_OUTPUT_LABEL (asm_out_file, label);
> +  ASM_OUTPUT_DEBUG_LABEL (asm_out_file, BLOCK_INLINE_ENTRY_LABEL,
> + BLOCK_NUMBER (block));
>  }
>
>  /* Called from finalize_size_functions for size functions so that their body
> --
> 1.8.5.3
>