Re: [PATCH] Fix LTO ICEs due to invalid self-referencing fortran character length VAR_DECL chains (PR fortran/88902)

[Tobias Burnus]

Hi Jakub,

Jakub Jelinek wrote:

As the testcase shows, gfc_get_symbol_decl can be called multiple times and
we can add the same length multiple times to current or parent function.
As addition of a VAR_DECL to those is done by chaining it into the
DECL_CHAIN linked list, adding the same VAR_DECL twice means a loop in the
chain (in this testcase DECL_CHAIN referencing the containing VAR_DECL, but
it could be longer loop).  Any such loop is a bug and e.g. LTO is very upset
about that.

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


OK – thanks for the patch.

Tobias



2019-01-18  Jakub Jelinek  

PR fortran/88902
* trans-decl.c (gfc_get_symbol_decl): Don't add length to function
or parent function if it has been added there already.

* gfortran.dg/pr88902.f90: New test.

--- gcc/fortran/trans-decl.c.jj 2019-01-16 09:35:08.0 +0100
+++ gcc/fortran/trans-decl.c2019-01-18 13:03:07.073419557 +0100
@@ -1572,13 +1572,17 @@ gfc_get_symbol_decl (gfc_symbol * sym)
  if (VAR_P (length) && DECL_FILE_SCOPE_P (length))
{
  /* Add the string length to the same context as the symbol.  */
- if (DECL_CONTEXT (sym->backend_decl) == current_function_decl)
-   gfc_add_decl_to_function (length);
- else
-   gfc_add_decl_to_parent_function (length);
+ if (DECL_CONTEXT (length) == NULL_TREE)
+   {
+ if (DECL_CONTEXT (sym->backend_decl)
+ == current_function_decl)
+   gfc_add_decl_to_function (length);
+ else
+   gfc_add_decl_to_parent_function (length);
+   }
  
-	  gcc_assert (DECL_CONTEXT (sym->backend_decl) ==

-   DECL_CONTEXT (length));
+ gcc_assert (DECL_CONTEXT (sym->backend_decl)
+ == DECL_CONTEXT (length));
  
  	  gfc_defer_symbol_init (sym);

}
--- gcc/testsuite/gfortran.dg/pr88902.f90.jj2019-01-18 12:58:03.738394429 
+0100
+++ gcc/testsuite/gfortran.dg/pr88902.f90   2019-01-18 12:59:06.971357361 
+0100
@@ -0,0 +1,6 @@
+! PR fortran/88902
+! { dg-do compile }
+! { dg-require-effective-target lto }
+! { dg-options "-flto --param ggc-min-heapsize=0" }
+
+include 'pr50069_2.f90'

Jakub

[PATCH] Fix -Wattribute-alias option

[Bernd Edlinger]

Hi,

the command line option -Wattribute-alias (w/o the "=1") is currently broken,
and only -Wno-attribute-alias is still working, but what is worse, is that
the #pragma GCC diagnostic fails to recognize the string "-Wattribute-alias",
as it used to do in gcc-8, which breaks the linux warning suppression macro
because it relies on a _Pragma to work.

Fixed by declaring -Wattribute-alias as an alias to -Wattribute-alias=1
and the negated form as an alias to -Wattribute-alias=0.

Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?

Additionally I looked into the linux 4.20 build, got a couple 
"-Wmissing-attributes"
which seem easy to fix (by adding the cold attribute) and quite a lot
"-Waddress-of-packed-member" warnings, which I don't know how to fix properly.


Thanks
Bernd.
2019-01-19  Bernd Edlinger  

	* common.opt (-Wattribute-alias): Remove "no-" from name.
	Make -Wattribute-alias command line option and
	#pragma GCC diagnostic ignore "-Wattribute-alias" work again.

testsuite:
2019-01-19  Bernd Edlinger  

	* gcc.dg/Wattribute-alias.c: Add test for #pragma GCC diagnostic ignore
	"-Wattribute-alias".

Index: gcc/common.opt
===
--- gcc/common.opt	(revision 268084)
+++ gcc/common.opt	(working copy)
@@ -550,14 +550,14 @@ Wattributes
 Common Var(warn_attributes) Init(1) Warning
 Warn about inappropriate attribute usage.
 
+Wattribute-alias
+Common Alias(Wattribute_alias=, 1, 0) Warning
+Warn about type safety and similar errors and mismatches in attribute alias and related.
+
 Wattribute-alias=
 Common Joined RejectNegative UInteger Var(warn_attribute_alias) Init(1) Warning IntegerRange(0, 2)
 Warn about type safety and similar errors and mismatches in attribute alias and related.
 
-Wno-attribute-alias
-Common Alias(Wattribute_alias=, 0, 0) Warning
-Disable -Wattribute-alias.
-
 Wcannot-profile
 Common Var(warn_cannot_profile) Init(1) Warning
 Warn when profiling instrumentation was requested, but could not be applied to
Index: gcc/testsuite/gcc.dg/Wattribute-alias.c
===
--- gcc/testsuite/gcc.dg/Wattribute-alias.c	(revision 268084)
+++ gcc/testsuite/gcc.dg/Wattribute-alias.c	(working copy)
@@ -14,6 +14,13 @@ ATTR (alias ("target_no_nothrow"), nothrow) void
 alias_nothrow (void);   /* { dg-warning ".alias_nothrow. specifies more restrictive attribute than its target .target_no_nothrow.: .nothrow." } */
 
 
+#pragma GCC diagnostic push "-Wattribute-alias"
+#pragma GCC diagnostic ignored "-Wattribute-alias"
+ATTR (alias ("target_no_nothrow"), nothrow) void
+alias_nothrow_ignored (void);
+#pragma GCC diagnostic pop "-Wattribute-alias"
+
+
 ATTR (pure) int
 alias_pure (void);
 

Re: [PATCH] String contents hash map key example

[Richard Sandiford]

Michael Ploujnikov  writes:
> I thought it would be useful to others who are new to the GCC codebase
> to have an example of how to hash keys based on string contents rather
> than pointer addresses (the fact that some hash maps key based on
> semi-reliable pointers (due to ggc_mark_stringpool) into the symtab
> gives a false sense of security).
>
>
> - Michael
>
> From 3433efe4ac558de05410a9b185f4ff0a01e7e5df Mon Sep 17 00:00:00 2001
> From: Michael Ploujnikov 
> Date: Fri, 11 Jan 2019 09:22:14 -0500
> Subject: [PATCH] Document how to hash based on key string contents.
>
> gcc:
>
> 2019-01-18  Michael Ploujnikov  
>
>   * hash-map-tests.c (test_map_of_strings_to_int): Document how
>   to hash based on key string contents.

OK, thanks.  Not sure whether this should really be treated as
documentation, but I can see how the current code could give a
misleading impression, and more testing is good either way.

Richard

Re: [wwwdocs] Mention AMD GCN on the website

[Gerald Pfeifer]

On Thu, 17 Jan 2019, Andrew Stubbs wrote:
> How's this?

Note the typo in the patch for the main page

  

[PATCH v2] rs6000: Add missing prototypes for vec_ld/vec_st

[Kewen.Lin]

Hi Jakub,

Thanks for catching!

Hi Segher,

Thanks for your suggestion, I just had a testing on BE machine and found the 
vector double related codes also need to be separated to vsx case. The case has 
been updated as below, is it OK for trunk? 

Thanks for your time in advance!


gcc/testsuite/ChangeLog:

2019-01-19  Kewen Lin  

* gcc.target/powerpc/altivec_vld_vst_addr.c: Remove.
* gcc.target/powerpc/altivec_vld_vst_addr-1.c: New test.
* gcc.target/powerpc/altivec_vld_vst_addr-2.c: Ditto.

---
 .../gcc.target/powerpc/altivec_vld_vst_addr-1.c| 184 +++
 .../gcc.target/powerpc/altivec_vld_vst_addr-2.c|  92 
 .../gcc.target/powerpc/altivec_vld_vst_addr.c  | 257 -
 3 files changed, 276 insertions(+), 257 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/altivec_vld_vst_addr-1.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/altivec_vld_vst_addr-2.c
 delete mode 100644 gcc/testsuite/gcc.target/powerpc/altivec_vld_vst_addr.c

diff --git a/gcc/testsuite/gcc.target/powerpc/altivec_vld_vst_addr-1.c 
b/gcc/testsuite/gcc.target/powerpc/altivec_vld_vst_addr-1.c
new file mode 100644
index 000..eb6d1eb
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/altivec_vld_vst_addr-1.c
@@ -0,0 +1,184 @@
+/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-options "-maltivec" } */
+
+/* Test vec_ld and vec_st can support both scalar and vector
+   type address points, the list is:
+ - address of unsigned char/short/int
+ - address of signed char/short/int
+ - address of float
+ - address of vector unsigned char/short/int
+ - address of vector signed char/short/int
+ - address of vector float */
+#include 
+
+/* Test vec_ld can allow scalar and vector type address. */
+vector unsigned char
+test_vld_scalar_uc (const unsigned char *address)
+{
+  return __builtin_vec_ld (0, address);
+}
+
+vector unsigned short
+test_vld_scalar_us (const unsigned short *address)
+{
+  return __builtin_vec_ld (0, address);
+}
+
+vector unsigned int
+test_vld_scalar_ui (const unsigned int *address)
+{
+  return __builtin_vec_ld (0, address);
+}
+
+vector signed char
+test_vld_scalar_sc (const signed char *address)
+{
+  return __builtin_vec_ld (0, address);
+}
+
+vector signed short
+test_vld_scalar_ss (const signed short *address)
+{
+  return __builtin_vec_ld (0, address);
+}
+
+vector signed int
+test_vld_scalar_si (const signed int *address)
+{
+  return __builtin_vec_ld (0, address);
+}
+
+vector float
+test_vld_scalar_f (const float *address)
+{
+  return __builtin_vec_ld (0, address);
+}
+
+vector unsigned char
+test_vld_vector_uc (const vector unsigned char *address)
+{
+  return __builtin_vec_ld (0, address);
+}
+
+vector unsigned short
+test_vld_vector_us (const vector unsigned short *address)
+{
+  return __builtin_vec_ld (0, address);
+}
+
+vector unsigned int
+test_vld_vector_ui (const vector unsigned int *address)
+{
+  return __builtin_vec_ld (0, address);
+}
+
+vector signed char
+test_vld_vector_sc (const vector signed char *address)
+{
+  return __builtin_vec_ld (0, address);
+}
+
+vector signed short
+test_vld_vector_ss (const vector signed short *address)
+{
+  return __builtin_vec_ld (0, address);
+}
+
+vector signed int
+test_vld_vector_si (const vector signed int *address)
+{
+  return __builtin_vec_ld (0, address);
+}
+
+vector float
+test_vld_vector_f (const vector float *address)
+{
+  return __builtin_vec_ld (0, address);
+}
+
+/* Test vec_st can allow scalar and vector type address. */
+
+void
+test_vst_scalar_uc (vector unsigned char v, unsigned char *address)
+{
+  __builtin_vec_st (v, 0, address);
+}
+
+void
+test_vst_scalar_us (vector unsigned short v, unsigned short *address)
+{
+  __builtin_vec_st (v, 0, address);
+}
+
+void
+test_vst_scalar_ui (vector unsigned int v, unsigned int *address)
+{
+  __builtin_vec_st (v, 0, address);
+}
+
+void
+test_vst_scalar_sc (vector signed char v, signed char *address)
+{
+  __builtin_vec_st (v, 0, address);
+}
+
+void
+test_vst_scalar_ss (vector signed short v, signed short *address)
+{
+  __builtin_vec_st (v, 0, address);
+}
+
+void
+test_vst_scalar_si (vector signed int v, signed int *address)
+{
+  __builtin_vec_st (v, 0, address);
+}
+
+void
+test_vst_scalar_f (vector float v, float *address)
+{
+  __builtin_vec_st (v, 0, address);
+}
+
+void
+test_vst_vector_uc (vector unsigned char v, vector unsigned char *address)
+{
+  __builtin_vec_st (v, 0, address);
+}
+
+void
+test_vst_vector_us (vector unsigned short v, vector unsigned short *address)
+{
+  __builtin_vec_st (v, 0, address);
+}
+
+void
+test_vst_vector_ui (vector unsigned int v, vector unsigned int *address)
+{
+  __builtin_vec_st (v, 0, address);
+}
+
+void
+test_vst_vector_sc (vector signed char v, vector signed char *address)
+{
+  __builtin_vec_st (v, 0, address);
+}
+
+void
+test_vst_vector_ss (vector signed short v, vector signed short *address)
+{
+  __builtin_vec_st (

[patch, fortran] Fix contiguous dummy arguments

[Thomas Koenig]

Hello world,

the attached patch fixes handling of contiguous dummy arguments when
the actual arguments are not contiguous.

The patch to trans-expr.c itself was written by Paul and attached to
the PR. I just added the test case.  Regression-testing revealed some
failing scan-tree tests due to different code being generated. I put
corresponding run time tests into the new test case to make sure that no
wrong code is being generated.

I have also tested the new test case and the compiler with valgrind.

OK for trunk?

Regards

Thomas

2018-01-19  Thomas Koenig  
Paul Thomas  

PR fortran/56789
* trans-expr.c (gfc_conv_procedure_call): Call
gfc_conv_subref_array_arg if the formal arg is contiguous
and the actual arg may not be.

2018-01-19  Thomas Koenig  
Paul Thomas  

PR fortran/56789
* gfortran.dg/contiguous_3.f90: Make code compilant.  Remove
scan-tree tests that fail with patch.
* gfortran.dg/contiguous_8.f90: New test.
Index: fortran/trans-expr.c
===
--- fortran/trans-expr.c	(Revision 267903)
+++ fortran/trans-expr.c	(Arbeitskopie)
@@ -5819,6 +5819,13 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *
 	 INTENT_IN,
 	 fsym && fsym->attr.pointer);
 		}
+	  else if (fsym && fsym->attr.contiguous
+		   && !gfc_is_simply_contiguous (e, false, true))
+		{
+		  gfc_conv_subref_array_arg (&parmse, e, nodesc_arg,
+fsym ? fsym->attr.intent : INTENT_INOUT,
+fsym && fsym->attr.pointer);
+		}
 	  else
 		gfc_conv_array_parameter (&parmse, e, nodesc_arg, fsym,
 	  sym->name, NULL);
Index: testsuite/gfortran.dg/contiguous_3.f90
===
--- testsuite/gfortran.dg/contiguous_3.f90	(Revision 267903)
+++ testsuite/gfortran.dg/contiguous_3.f90	(Arbeitskopie)
@@ -8,6 +8,8 @@
 
 subroutine test1(a,b)
   integer, pointer, contiguous :: test1_a(:)
+  integer, target, dimension(3) :: aa
+  test1_a => aa
   call foo(test1_a)
   call foo(test1_a(::1))
   call foo(test1_a(::2))
@@ -56,9 +58,3 @@ contains
   end subroutine bar
 end subroutine test3
 
-! Once for test1 (third call), once for test3 (second call)
-! { dg-final { scan-tree-dump-times "data = origptr" 1 "original" } }
-! { dg-final { scan-tree-dump-times "_gfortran_internal_pack .&parm" 2 "original" } }
-! { dg-final { scan-tree-dump-times "_gfortran_internal_unpack .&parm" 2 "original" } }
-
-
! { dg-do  run }
! PR 56789 - packing / unpacking of contiguous arguments
! did not happen.

module my_module
  implicit none
contains
  subroutine cont_arg(a)
real, contiguous :: a(:,:)
integer :: i,j
do j=1,size(a,2)
   do i=1,size(a,1)
  a(i,j) = i+10*j
   end do
end do
  end subroutine cont_arg
  subroutine cont_pointer_arg (a)
integer, pointer, contiguous :: a(:)
call assumed_size(a)
call assumed_size(a(::1))
call assumed_size_2(a(::2))
  end subroutine cont_pointer_arg

  subroutine assumed_size(y)
integer, dimension(*) :: y
if (y(2) /= 2 .or. y(3) /= 3 .or. y(4) /= 4 .or. y(5) /= 5 .or. y(6) /= 6) &
stop 2
  end subroutine assumed_size

  subroutine assumed_size_2(y)
integer, dimension(*) :: y
if (y(1) /= 1 .or. y(2) /= 3 .or. y(3) /= 5) stop 3
  end subroutine assumed_size_2

  subroutine cont_assumed_shape(x)
integer, dimension(:), contiguous :: x
if (size(x,1) == 8) then
   if (any(x /= [1,2,3,4,5,6,7,8])) stop 4
else
   if (any(x /= [1,3,5,7])) stop 5
end if
  end subroutine cont_assumed_shape
end module my_module

program main
  use my_module
  implicit none
  real, dimension(5,5) :: a
  real, dimension(5,5) :: res
  integer, dimension(8), target :: t
  integer, dimension(:), pointer, contiguous :: p
  res = reshape([11., 1.,12., 1.,13.,&
  1., 1., 1., 1., 1.,&
 21., 1.,22., 1.,23.,&
  1., 1., 1., 1., 1.,&
 31., 1.,32., 1., 33.], shape(res))
  a = 1.
  call cont_arg(a(1:5:2,1:5:2))
  if (any(a /= res)) stop 1
  t = [1,2,3,4,5,6,7,8]
  p => t
  call cont_pointer_arg(p)
  call cont_assumed_shape (t)
  call cont_assumed_shape (t(::2))
end program main

Re: [Patch, Fortran] PR 37835 -fno-automatic does not work for derived types with default initalizer

[Thomas Koenig]

Hi Dominique,


The patch for gcc/fortran/resolve.c is the modernized version of Paul’s patch 
in comment 4.
It causes some regressions due to "Duplicate SAVE » warnings.
They are silenced by the patch for gcc/fortran/symbol.c unless -pedantic is 
used as documented
in the change for gcc/fortran/invoke.texi.

Is it OK for trunk?


I assume you did a regression test. OK if this has passed.

Thanks for the patch!

Regards

Thomas

[PATCH] i386: Move Intel intrinsics head files to

[H.J. Lu]

According to Intel Intrinsics Guide:

https://software.intel.com/sites/landingpage/IntrinsicsGuide/

Intel intrinsics should be available by including .  This
patch moves remaining Intel intrinsics head files from  to
.

OK for trunk?

H.J.
---
PR target/71659
* config/i386/adxintrin.h: Just check _IMMINTRIN_H_INCLUDED.
* config/i386/clflushoptintrin.h: Check _IMMINTRIN_H_INCLUDED
instead of _X86INTRIN_H_INCLUDED.
* onfig/i386/clwbintrin.h: Likewise.
* config/i386/pkuintrin.h: Likewise.
* config/i386/prfchwintrin.h: Likewise.
* config/i386/rdseedintrin.h: Likewise.
* config/i386/wbnoinvdintrin.h: Likewise.
* config/i386/xsavecintrin.h: Likewise.
* config/i386/xsavesintrin.h: Likewise.
* config/i386/fxsrintrin.h: Enable _IMMINTRIN_H_INCLUDED check.
* config/i386/xsaveintrin.h: Likewise.
* config/i386/xsaveoptintrin.h: Likewise.
* config/i386/x86intrin.h: Move "#include" ,
, , ,
, , ,
, , ,
 and  to ...
* config/i386/immintrin.h: Here.
---
 gcc/config/i386/adxintrin.h|  4 ++--
 gcc/config/i386/clflushoptintrin.h |  4 ++--
 gcc/config/i386/clwbintrin.h   |  4 ++--
 gcc/config/i386/fxsrintrin.h   |  6 +++---
 gcc/config/i386/immintrin.h| 24 
 gcc/config/i386/pkuintrin.h|  4 ++--
 gcc/config/i386/prfchwintrin.h |  4 ++--
 gcc/config/i386/rdseedintrin.h |  4 ++--
 gcc/config/i386/wbnoinvdintrin.h   |  4 ++--
 gcc/config/i386/x86intrin.h| 28 
 gcc/config/i386/xsavecintrin.h |  4 ++--
 gcc/config/i386/xsaveintrin.h  |  6 +++---
 gcc/config/i386/xsaveoptintrin.h   |  6 +++---
 gcc/config/i386/xsavesintrin.h |  4 ++--
 14 files changed, 51 insertions(+), 55 deletions(-)

diff --git a/gcc/config/i386/adxintrin.h b/gcc/config/i386/adxintrin.h
index e01b77ddb4b..e8cb004390c 100644
--- a/gcc/config/i386/adxintrin.h
+++ b/gcc/config/i386/adxintrin.h
@@ -21,8 +21,8 @@
see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
.  */
 
-#if !defined _X86INTRIN_H_INCLUDED && !defined _IMMINTRIN_H_INCLUDED
-# error "Never use  directly; include  instead."
+#if !defined _IMMINTRIN_H_INCLUDED
+# error "Never use  directly; include  instead."
 #endif
 
 #ifndef _ADXINTRIN_H_INCLUDED
diff --git a/gcc/config/i386/clflushoptintrin.h 
b/gcc/config/i386/clflushoptintrin.h
index 1e720c2515c..89aa0f68fc2 100644
--- a/gcc/config/i386/clflushoptintrin.h
+++ b/gcc/config/i386/clflushoptintrin.h
@@ -21,8 +21,8 @@
see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
.  */
 
-#if !defined _X86INTRIN_H_INCLUDED
-# error "Never use  directly; include  
instead."
+#if !defined _IMMINTRIN_H_INCLUDED
+# error "Never use  directly; include  
instead."
 #endif
 
 #ifndef _CLFLUSHOPTINTRIN_H_INCLUDED
diff --git a/gcc/config/i386/clwbintrin.h b/gcc/config/i386/clwbintrin.h
index 217fb3babf2..68b20ea1635 100644
--- a/gcc/config/i386/clwbintrin.h
+++ b/gcc/config/i386/clwbintrin.h
@@ -21,8 +21,8 @@
see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
.  */
 
-#if !defined _X86INTRIN_H_INCLUDED
-# error "Never use  directly; include  instead."
+#if !defined _IMMINTRIN_H_INCLUDED
+# error "Never use  directly; include  instead."
 #endif
 
 #ifndef _CLWBINTRIN_H_INCLUDED
diff --git a/gcc/config/i386/fxsrintrin.h b/gcc/config/i386/fxsrintrin.h
index ff6c6f848eb..c4b12cf25f3 100644
--- a/gcc/config/i386/fxsrintrin.h
+++ b/gcc/config/i386/fxsrintrin.h
@@ -21,9 +21,9 @@
see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
.  */
 
-/* #if !defined _X86INTRIN_H_INCLUDED && !defined _IMMINTRIN_H_INCLUDED */
-/* # error "Never use  directly; include  instead." 
*/
-/* #endif */
+#if !defined _IMMINTRIN_H_INCLUDED
+# error "Never use  directly; include  instead."
+#endif
 
 #ifndef _FXSRINTRIN_H_INCLUDED
 #define _FXSRINTRIN_H_INCLUDED
diff --git a/gcc/config/i386/immintrin.h b/gcc/config/i386/immintrin.h
index 6ce00012b42..10e1f27c605 100644
--- a/gcc/config/i386/immintrin.h
+++ b/gcc/config/i386/immintrin.h
@@ -38,6 +38,16 @@
 
 #include 
 
+#include 
+
+#include 
+
+#include 
+
+#include 
+
+#include 
+
 #include 
 
 #include 
@@ -120,6 +130,20 @@
 
 #include 
 
+#include 
+
+#include 
+
+#include 
+
+#include 
+
+#include 
+
+#include 
+
+#include 
+
 extern __inline void
 __attribute__((__gnu_inline__, __always_inline__, __artificial__))
 _wbinvd (void)
diff --git a/gcc/config/i386/pkuintrin.h b/gcc/config/i386/pkuintrin.h
index 727bec5dda8..be46522f0c0 100644
--- a/gcc/config/i386/pkuintrin.h
+++ b/gcc/config/i386/pkuintrin.h
@@ -21,8 +21,8 @@
see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
.  */
 
-#if !defined _X86INTRIN

Re: [PATCH] avoid issuing -Warray-bounds during folding (PR 88800)

[Jeff Law]

On 1/18/19 4:43 PM, Martin Sebor wrote:
> On 1/18/19 2:35 AM, Christophe Lyon wrote:
>> Hi Martin,
>>
>>
>> On Thu, 17 Jan 2019 at 02:51, Martin Sebor  wrote:
>>>
>>> On 1/16/19 6:14 PM, Jeff Law wrote:
 On 1/15/19 8:21 AM, Martin Sebor wrote:
> On 1/15/19 4:07 AM, Richard Biener wrote:
>> On Tue, Jan 15, 2019 at 1:08 AM Martin Sebor 
>> wrote:
>>>
>>> The gimple_fold_builtin_memory_op() function folds calls to memcpy
>>> and similar to MEM_REF when the size of the copy is a small power
>>> of 2, but it does so without considering whether the copy might
>>> write (or read) past the end of one of the objects.  To detect
>>> these kinds of errors (and help distinguish them from -Westrict)
>>> the folder calls into the wrestrict pass and lets it diagnose them.
>>> Unfortunately, that can lead to false positives for even some fairly
>>> straightforward code that is ultimately found to be unreachable.
>>> PR 88800 is a report of one such problem.
>>>
>>> To avoid these false positives the attached patch adjusts
>>> the function to avoid issuing -Warray-bounds for out-of-bounds
>>> calls to memcpy et al.  Instead, the patch disables the folding
>>> of such invalid calls (and only those).  Those that are not
>>> eliminated during DCE or other subsequent passes are eventually
>>> diagnosed by the wrestrict pass.
>>>
>>> Since this change required removing the dependency of the detection
>>> on the warning options (originally done as a micro-optimization to
>>> avoid spending compile-time cycles on something that wasn't needed)
>>> the patch also adds tests to verify that code generation is not
>>> affected as a result of warnings being enabled or disabled.  With
>>> the patch as is, the invalid memcpy calls end up emitted (currently
>>> they are folded into equally invalid MEM_REFs).  At some point,
>>> I'd like us to consider whether they should be replaced with traps
>>> (possibly under the control of  as has been proposed a number of
>>> times in the past.  If/when that's done, these tests will need to
>>> be adjusted to look for traps instead.
>>>
>>> Tested on x86_64-linux.
>>
>> I've said in the past that I feel delaying of folding is wrong.
>>
>> To understand, the PR is about emitting a warning for out-of-bound
>> accesses in a dead code region?
>
> Yes.  I am keeping in my mind your preference of not delaying
> the folding of valid code.
>
>>
>> If we think delaying/disablign the folding is the way to go the
>> patch looks OK.
>
> I do, at least for now.  I'm taking this as your approval to commit
> the patch (please let me know if you didn't mean it that way).
 Note we are in stage4, so we're supposed to be addressing regression
 bugfixes and documentation issues.

 So  I think Richi needs to be explicit about whether or not he wants
 this in gcc-9 or if it should defer to gcc-10.

 I have no technical objections to the patch and would easily ack it in
 stage1 or stage3.
>>>
>>> The warning is a regression introduced in GCC 8.  I was just about
>>> to commit the fix so please let me know if I should hold off until
>>> stage 1.
>>>
>>
>> After your commit (r268037), I'm seeing excess errors on some arm
>> targets:
>> FAIL: c-c++-common/Wrestrict.c  -Wc++-compat  (test for excess errors)
>> Excess errors:
>> /gcc/testsuite/c-c++-common/Wrestrict.c:195:3: warning: 'memcpy'
>> accessing 4 bytes at offsets [2, 3] and 0 overlaps between 1 and 2
>> bytes at offset [2, 3] [-Wrestrict]
>> /gcc/testsuite/c-c++-common/Wrestrict.c:202:3: warning: 'memcpy'
>> accessing 4 bytes at offsets [2, 3] and 0 overlaps between 1 and 2
>> bytes at offset [2, 3] [-Wrestrict]
>> /gcc/testsuite/c-c++-common/Wrestrict.c:207:3: warning: 'memcpy'
>> accessing 4 bytes at offsets [2, 3] and 0 overlaps between 1 and 2
>> bytes at offset [2, 3] [-Wrestrict]
>>
>>
>> This is not true for all arm toolchains, so for instance if you want
>> to reproduce it, you can build for target arm-eabi and keep default
>> cpu/fpu/mode.
> 
> The warnings are valid, the test just hardcodes the wrong byte counts
> in the xfailed dg-warning directives.  I've fixed the byte counts so
> that the test just shows XPASSes.
> 
> The other issue here is that the -Wrestrict warning only triggers for
> built-ins and whether GCC keeps those around or folds them to MEM_REFs
> depends on the target.  On common targets, a memcpy (d, d + 2, 4) call,
> for instance, (i.e., one with a small power-of-2 size) is folded to
> MEM_REF, so there is no -Wrestrict warning despite the overlap.
> Strictly, it's a false negative, but in reality it's not a problem
> because GCC gives the MEM_REF copy the same safe semantics as with
> memmove, so the overlap is benign.
> 
> But on targets that optimize for space by default (like arm-eabi)
> the folding doesn

Re: [RFC][AArch64] Add support for system register based stack protector canary access

[Jakub Jelinek]

On Mon, Dec 03, 2018 at 09:55:36AM +, Ramana Radhakrishnan wrote:
> 2018-11-23  Ramana Radhakrishnan  
> 
>  * config/aarch64/aarch64-opts.h (enum stack_protector_guard): New
>  * config/aarch64/aarch64.c (aarch64_override_options_internal): 
> Handle
>  and put in error checks for stack protector guard options.
>  (aarch64_stack_protect_guard): New.
>  (TARGET_STACK_PROTECT_GUARD): Define.
>  * config/aarch64/aarch64.md (UNSPEC_SSP_SYSREG): New.
>  (reg_stack_protect_address): New.
>  (stack_protect_set): Adjust for SSP_GLOBAL.
>  (stack_protect_test): Likewise.
>  * config/aarch64/aarch64.opt (-mstack-protector-guard-reg): New.
>  (-mstack-protector-guard): Likewise.
>  (-mstack-protector-guard-offset): Likewise.
>  * doc/invoke.texi: Document new AArch64 options.

> @@ -17872,8 +17907,24 @@ aarch64_run_selftests (void)
>  
>  } // namespace selftest
>  
> +/* Implement TARGET_STACK_PROTECT_GUARD. In case of a
> +   global variable based guard use the default else
> +   return a null tree.  */
> +static tree
> +aarch64_stack_protect_guard (void)
> +{
> +  if (aarch64_stack_protector_guard == SSP_GLOBAL)
> +return default_stack_protect_guard ();
> +
> +  return NULL_TREE;
> +}
> +
> +
>  #endif /* #if CHECKING_P */
>  
> +#undef TARGET_STACK_PROTECT_GUARD
> +#define TARGET_STACK_PROTECT_GUARD aarch64_stack_protect_guard
> +

The above change broke aarch64 --enable-checking=release bootstrap.
I've committed as obvious following change to unbreak it:

2019-01-19  Jakub Jelinek  

* config/aarch64/aarch64.c (aarch64_stack_protect_guard): Move
outside of #if CHECKING_P code.

--- gcc/config/aarch64/aarch64.c.jj 2019-01-19 09:39:18.859831024 +0100
+++ gcc/config/aarch64/aarch64.c2019-01-19 18:25:18.037239167 +0100
@@ -18662,6 +18662,19 @@ aarch64_simd_clone_usable (struct cgraph
 }
 }
 
+/* Implement TARGET_STACK_PROTECT_GUARD. In case of a
+   global variable based guard use the default else
+   return a null tree.  */
+static tree
+aarch64_stack_protect_guard (void)
+{
+  if (aarch64_stack_protector_guard == SSP_GLOBAL)
+return default_stack_protect_guard ();
+
+  return NULL_TREE;
+}
+
+
 /* Target-specific selftests.  */
 
 #if CHECKING_P
@@ -18706,19 +18719,6 @@ aarch64_run_selftests (void)
 
 } // namespace selftest
 
-/* Implement TARGET_STACK_PROTECT_GUARD. In case of a
-   global variable based guard use the default else
-   return a null tree.  */
-static tree
-aarch64_stack_protect_guard (void)
-{
-  if (aarch64_stack_protector_guard == SSP_GLOBAL)
-return default_stack_protect_guard ();
-
-  return NULL_TREE;
-}
-
-
 #endif /* #if CHECKING_P */
 
 #undef TARGET_STACK_PROTECT_GUARD


Jakub

Re: [patch, fortran] Fix contiguous dummy arguments

[Jerry DeLisle]

On 1/19/19 7:05 AM, Thomas Koenig wrote:

Hello world,

the attached patch fixes handling of contiguous dummy arguments when
the actual arguments are not contiguous.

The patch to trans-expr.c itself was written by Paul and attached to
the PR. I just added the test case.  Regression-testing revealed some
failing scan-tree tests due to different code being generated. I put
corresponding run time tests into the new test case to make sure that no
wrong code is being generated.

I have also tested the new test case and the compiler with valgrind.

OK for trunk?



Looks OK

Jerry

[PATCH] PR fortran/77960 -- inpute-item can't be function

[Steve Kargl]

The attached patch has been tested on x86_64-*-freebsd.
PR fortran/77960 uses a procedure pointer to expose the
bug, but it applied to any external subprogram.  So, the
patch checks for the external attribute.  OK to commit?

2019-01-19  Steven G. Kargl  

PR fortran/77960
* io.c (match_io_element): input-item cannot be an external function.
 
2019-01-19  Steven G. Kargl  

PR fortran/77960
* gfortran.dg/pr77960.f90: New test.

-- 
Steve
Index: gcc/fortran/io.c
===
--- gcc/fortran/io.c	(revision 268095)
+++ gcc/fortran/io.c	(working copy)
@@ -3610,6 +3610,16 @@ match_io_element (io_kind k, gfc_code **cpp)
   m = gfc_match_variable (&expr, 0);
   if (m == MATCH_NO)
 	gfc_error ("Expected variable in READ statement at %C");
+
+  if (m == MATCH_YES
+	  && expr->expr_type == EXPR_VARIABLE
+	  && expr->symtree->n.sym->attr.external)
+	{
+	  gfc_error ("Expecting variable or io-implied-do at %L",
+		 &expr->where);
+	  m = MATCH_ERROR;
+	}
+
 }
   else
 {
Index: gcc/testsuite/gfortran.dg/pr77960.f90
===
--- gcc/testsuite/gfortran.dg/pr77960.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr77960.f90	(working copy)
@@ -0,0 +1,16 @@
+! { dg-do compile }
+! PR fortran/77960
+   procedure(g), pointer :: f
+   f => g
+   read(99) f ! { dg-error "Expecting variable" }
+contains
+   function g() result(z)
+  integer :: z(2)
+  z = 1
+   end
+end
+
+subroutine bar(x)
+   integer, external :: x
+   read(*,*) x! { dg-error "Expecting variable" }
+end subroutine

Re: [PATCH] PR fortran/77960 -- inpute-item can't be function

[Thomas Koenig]

Hi Steve,


The attached patch has been tested on x86_64-*-freebsd.
PR fortran/77960 uses a procedure pointer to expose the
bug, but it applied to any external subprogram.  So, the
patch checks for the external attribute.  OK to commit?


OK, and thanks.

Regards

Thomas

Re: [Patch, Fortran] PR 37835 -fno-automatic does not work for derived types with default initalizer

[Dominique d'Humières]

Thanks for the review, committed as r268098.

Dominique

> Le 19 janv. 2019 à 16:50, Thomas Koenig  a écrit :
> 
> Hi Dominique,
> 
>> The patch for gcc/fortran/resolve.c is the modernized version of Paul’s 
>> patch in comment 4.
>> It causes some regressions due to "Duplicate SAVE » warnings.
>> They are silenced by the patch for gcc/fortran/symbol.c unless -pedantic is 
>> used as documented
>> in the change for gcc/fortran/invoke.texi.
>> Is it OK for trunk?
> 
> I assume you did a regression test. OK if this has passed.

I have never submitted a patch without regtesting it!

> 
> Thanks for the patch!
> 
> Regards
> 
>   Thomas

Re: [PATCH v2] rs6000: Add missing prototypes for vec_ld/vec_st

[Segher Boessenkool]

Hi Kewen,

On Sat, Jan 19, 2019 at 09:27:38PM +0800, Kewen.Lin wrote:
> Thanks for your suggestion, I just had a testing on BE machine and found the 
> vector double related codes also need to be separated to vsx case. The case 
> has been updated as below, is it OK for trunk? 

Yes, this is fine.  Thanks!

A changelog suggestion:

> 2019-01-19  Kewen Lin  
> 
>   * gcc.target/powerpc/altivec_vld_vst_addr.c: Remove.
>   * gcc.target/powerpc/altivec_vld_vst_addr-1.c: New test.
>   * gcc.target/powerpc/altivec_vld_vst_addr-2.c: Ditto.

Maybe you can say this like

* gcc.target/powerpc/altivec_vld_vst_addr.c: Delete, split into ...
* gcc.target/powerpc/altivec_vld_vst_addr-1.c: ... this, new test ...
* gcc.target/powerpc/altivec_vld_vst_addr-2.c: ... and this.  New test.

It's fine with or without that.


Segher

Re: Patch ping (Re: [PATCH] Fortran include line fixes and -fdec-include support)

[Gerald Pfeifer]

Hej Jakub, hej Fortran hackers,

On Wed, 21 Nov 2018, Jakub Jelinek wrote:
> Like this?  Ok for trunk/wwwdocs?
> 
> 2018-11-21  Jakub Jelinek  
> 
>   * invoke.texi (-fdec-include): Document.

how about the refinement below?

Gerald

Index: gcc-9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
retrieving revision 1.33
diff -u -r1.33 changes.html
--- gcc-9/changes.html  11 Jan 2019 19:10:28 -  1.33
+++ gcc-9/changes.html  19 Jan 2019 22:48:22 -
@@ -170,12 +170,12 @@
   module IEEE_ARITHMETIC.
   
   
-A new command line option -fdec-include, set also
-by -fdec option, has been added for an extension
-for compatibility with legacy code.  With this option,
-INCLUDE directive is parsed also as a statement,
-which allows the directive to be written on multiple source lines
-with line continuations.
+A new command-line option -fdec-include, set also
+by the -fdec option, has been added to increase
+compatibility with legacy code.  With this option, an
+INCLUDE directive is also parsed as a statement,
+which allows the directive to be spread across multiple source
+lines with line continuations.
   
 
 

Re: Patch ping (Re: [PATCH] Fortran include line fixes and -fdec-include support)

[Jakub Jelinek]

On Sat, Jan 19, 2019 at 11:49:34PM +0100, Gerald Pfeifer wrote:
> Hej Jakub, hej Fortran hackers,
> 
> On Wed, 21 Nov 2018, Jakub Jelinek wrote:
> > Like this?  Ok for trunk/wwwdocs?
> > 
> > 2018-11-21  Jakub Jelinek  
> > 
> > * invoke.texi (-fdec-include): Document.
> 
> how about the refinement below?

LGTM.  Thanks.

> --- gcc-9/changes.html11 Jan 2019 19:10:28 -  1.33
> +++ gcc-9/changes.html19 Jan 2019 22:48:22 -
> @@ -170,12 +170,12 @@
>module IEEE_ARITHMETIC.
>
>
> -A new command line option -fdec-include, set also
> -by -fdec option, has been added for an extension
> -for compatibility with legacy code.  With this option,
> -INCLUDE directive is parsed also as a statement,
> -which allows the directive to be written on multiple source lines
> -with line continuations.
> +A new command-line option -fdec-include, set also
> +by the -fdec option, has been added to increase
> +compatibility with legacy code.  With this option, an
> +INCLUDE directive is also parsed as a statement,
> +which allows the directive to be spread across multiple source
> +lines with line continuations.
>
>  
>  

Jakub

[PATCH] Use __builtin_is_constant_evaluated some more (PR libstdc++/86590)

[Jakub Jelinek]

Hi!

The following patch uses __builtin_is_constant_evaluated for
__constant_string_p and __constant_char_array_p - in constexpr contexts,
all the strings or arrays should be constant, and by doing it this way the
compiler should be able to optimize better the callers of these inline
functions already shortly after early inlining rather than having to wait
until fold builtins pass much later.

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

2019-01-19  Jakub Jelinek  

PR libstdc++/86590
* include/bits/char_traits.h (__constant_string_p,
__constant_char_array_p): Use __builtin_is_constant_evaluated if
available.

--- libstdc++-v3/include/bits/char_traits.h.jj  2019-01-07 17:59:25.415908887 
+0100
+++ libstdc++-v3/include/bits/char_traits.h 2019-01-19 09:27:44.036336100 
+0100
@@ -230,9 +230,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 static _GLIBCXX_ALWAYS_INLINE constexpr bool
 __constant_string_p(const _CharT* __s)
 {
+#ifdef _GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED
+  (void) __s;
+  // In constexpr contexts all strings should be constant.
+  return __builtin_is_constant_evaluated();
+#else
   while (__builtin_constant_p(*__s) && *__s)
__s++;
   return __builtin_constant_p(*__s);
+#endif
 }
 
   /**
@@ -247,10 +253,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 static _GLIBCXX_ALWAYS_INLINE constexpr bool
 __constant_char_array_p(const _CharT* __a, size_t __n)
 {
+#ifdef _GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED
+  (void) __a;
+  (void) __n;
+  // In constexpr contexts all character arrays should be constant.
+  return __builtin_is_constant_evaluated();
+#else
   size_t __i = 0;
   while (__builtin_constant_p(__a[__i]) && __i < __n)
__i++;
   return __i == __n;
+#endif
 }
 #endif
 

Jakub

Re: [PATCH][GCC][DOC] Remove obsolete arm and aarch64 CPU names from invoke.texi

[Gerald Pfeifer]

On Thu, 10 Jan 2019, Sam Tebbs wrote:
>> I believe this should also be covered in the GCC 9 release notes
>> at https://gcc.gnu.org/gcc-9/changes.html ?
> Sorry for the late reply. My email filters seem to have stumbled a bit 
> so I didn't pick this up until now. Would you suggest adding something 
> along the lines of "Removed obsolete Arm CPU names from the option 
> documentation" (perhaps with a full list as in my original email)?

Yes, please.

Gerald (now needing to look at his filters)

Re: [PATCH] PR target/85596 Add --with-multilib-list doc for aarch64

[Gerald Pfeifer]

On Thu, 17 Jan 2019, Christophe Lyon wrote:
> Ping? I think that kind of patch is OK for stage4?

Yes, documentation patches are (essentially) always okay.

Gerald

Re: [committed] v2: Machine-readable diagnostic output (PR other/19165)

[Gerald Pfeifer]

On Thu, 15 Nov 2018, David Malcolm wrote:
> Changed in v2:
> * added test coverage
> * improved docs
> * pass orig_diag_kind to the finalizer callback
> 
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> Committed to trunk as r266186.

Mind adding something to the release notes at gcc-9/changes.html ,
David?  That would be nice.

(And thanks for adding extensive user documentation for this as 
you have done with this patch.)

Gerald