[gcc r14-9719] Fortran: Fix a gimplifier ICE/wrong result with finalization [PR36337]

2024-03-29 Thread Paul Thomas via Gcc-cvs
https://gcc.gnu.org/g:3c793f0361bc66d2a6bf0b3e1fb3234fc511e2a6

commit r14-9719-g3c793f0361bc66d2a6bf0b3e1fb3234fc511e2a6
Author: Paul Thomas 
Date:   Fri Mar 29 07:23:19 2024 +

Fortran: Fix a gimplifier ICE/wrong result with finalization [PR36337]

2024-03-29  Paul Thomas  

gcc/fortran
PR fortran/36337
PR fortran/110987
PR fortran/113885
* trans-expr.cc (gfc_trans_assignment_1): Place finalization
block before rhs post block for elemental rhs.
* trans.cc (gfc_finalize_tree_expr): Check directly if a type
has no components, rather than the zero components attribute.
Treat elemental zero component expressions in the same way as
scalars.

gcc/testsuite/
PR fortran/113885
* gfortran.dg/finalize_54.f90: New test.
* gfortran.dg/finalize_55.f90: New test.

gcc/testsuite/
PR fortran/110987
* gfortran.dg/finalize_56.f90: New test.

Diff:
---
 gcc/fortran/trans-expr.cc |   9 +-
 gcc/fortran/trans.cc  |   6 +-
 gcc/testsuite/gfortran.dg/finalize_54.f90 |  47 +
 gcc/testsuite/gfortran.dg/finalize_55.f90 |  89 
 gcc/testsuite/gfortran.dg/finalize_56.f90 | 168 ++
 5 files changed, 313 insertions(+), 6 deletions(-)

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 76bed9830c4..079ac93aa8a 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -12511,11 +12511,14 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * 
expr2, bool init_flag,
   gfc_add_block_to_block (&body, &lse.pre);
   gfc_add_expr_to_block (&body, tmp);
 
-  /* Add the post blocks to the body.  */
-  if (!l_is_temp)
+  /* Add the post blocks to the body.  Scalar finalization must appear before
+ the post block in case any dellocations are done.  */
+  if (rse.finalblock.head
+  && (!l_is_temp || (expr2->expr_type == EXPR_FUNCTION
+&& gfc_expr_attr (expr2).elemental)))
 {
-  gfc_add_block_to_block (&rse.finalblock, &rse.post);
   gfc_add_block_to_block (&body, &rse.finalblock);
+  gfc_add_block_to_block (&body, &rse.post);
 }
   else
 gfc_add_block_to_block (&body, &rse.post);
diff --git a/gcc/fortran/trans.cc b/gcc/fortran/trans.cc
index 7f50b16aee9..badad6ae892 100644
--- a/gcc/fortran/trans.cc
+++ b/gcc/fortran/trans.cc
@@ -1624,7 +1624,7 @@ gfc_finalize_tree_expr (gfc_se *se, gfc_symbol *derived,
 }
   else if (derived && gfc_is_finalizable (derived, NULL))
 {
-  if (derived->attr.zero_comp && !rank)
+  if (!derived->components && (!rank || attr.elemental))
{
  /* Any attempt to assign zero length entities, causes the gimplifier
 all manner of problems. Instead, a variable is created to act as
@@ -1675,7 +1675,7 @@ gfc_finalize_tree_expr (gfc_se *se, gfc_symbol *derived,
  final_fndecl);
   if (!GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (desc)))
 {
-  if (is_class)
+  if (is_class || attr.elemental)
desc = gfc_conv_scalar_to_descriptor (se, desc, attr);
   else
{
@@ -1685,7 +1685,7 @@ gfc_finalize_tree_expr (gfc_se *se, gfc_symbol *derived,
}
 }
 
-  if (derived && derived->attr.zero_comp)
+  if (derived && !derived->components)
 {
   /* All the conditions below break down for zero length derived types.  */
   tmp = build_call_expr_loc (input_location, final_fndecl, 3,
diff --git a/gcc/testsuite/gfortran.dg/finalize_54.f90 
b/gcc/testsuite/gfortran.dg/finalize_54.f90
new file mode 100644
index 000..73d32b1b333
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/finalize_54.f90
@@ -0,0 +1,47 @@
+! { dg-do compile }
+! Test the fix for PR113885, where not only was there a gimplifier ICE
+! for a derived type 't' with no components but, with a component, gfortran
+! gave wrong results.
+! Contributed by David Binderman  
+!
+module types
+  type t
+   contains
+ final :: finalize
+  end type t
+contains
+  pure subroutine finalize(x)
+type(t), intent(inout) :: x
+  end subroutine finalize
+end module types
+
+subroutine test1(x)
+  use types
+  interface
+ elemental function elem(x)
+   use types
+   type(t), intent(in) :: x
+   type(t) :: elem
+ end function elem
+  end interface
+  type(t) :: x(:)
+  x = elem(x)
+end subroutine test1
+
+subroutine test2(x)
+  use types
+  interface
+ elemental function elem(x)
+   use types
+   type(t), intent(in) :: x
+   type(t) :: elem
+ end function elem
+ elemental function elem2(x, y)
+   use types
+   type(t), intent(in) :: x, y
+   type(t) :: elem2
+ end function elem2
+  end interface
+  type(t) :: x(:)
+  x = elem2(elem(x), elem(x))
+end subroutine test2
diff --git a/gcc/testsuite/gfortran.dg/finalize_55.f90 
b/gcc

[gcc r14-9720] Fortran: fix NULL pointer dereference on overlapping initialization [PR50410]

2024-03-29 Thread Harald Anlauf via Gcc-cvs
https://gcc.gnu.org/g:6fb253a25dff13253d63553f02e0fe72c5e3ab4e

commit r14-9720-g6fb253a25dff13253d63553f02e0fe72c5e3ab4e
Author: Harald Anlauf 
Date:   Thu Mar 28 22:34:40 2024 +0100

Fortran: fix NULL pointer dereference on overlapping initialization 
[PR50410]

gcc/fortran/ChangeLog:

PR fortran/50410
* trans-expr.cc (gfc_conv_structure): Check for NULL pointer.

gcc/testsuite/ChangeLog:

PR fortran/50410
* gfortran.dg/data_initialized_4.f90: New test.

Diff:
---
 gcc/fortran/trans-expr.cc|  2 +-
 gcc/testsuite/gfortran.dg/data_initialized_4.f90 | 16 
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 079ac93aa8a..d21e3956d6e 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -9650,7 +9650,7 @@ gfc_conv_structure (gfc_se * se, gfc_expr * expr, int 
init)
   cm = expr->ts.u.derived->components;
 
   for (c = gfc_constructor_first (expr->value.constructor);
-   c; c = gfc_constructor_next (c), cm = cm->next)
+   c && cm; c = gfc_constructor_next (c), cm = cm->next)
 {
   /* Skip absent members in default initializers and allocatable
 components.  Although the latter have a default initializer
diff --git a/gcc/testsuite/gfortran.dg/data_initialized_4.f90 
b/gcc/testsuite/gfortran.dg/data_initialized_4.f90
new file mode 100644
index 000..156b6607edf
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/data_initialized_4.f90
@@ -0,0 +1,16 @@
+! { dg-do compile }
+! { dg-additional-options "-std=legacy" }
+!
+! PR fortran/50410
+!
+! Silently allow overlapping initialization in legacy mode (used to ICE)
+
+program p
+  implicit none
+  type t
+ integer :: g = 1
+  end type t
+  type(t) :: u = t(2)
+  data u%g /3/
+  print *, u! this might print "2"
+end


[gcc r14-9721] GCN: Enable effective-target 'vect_early_break', 'vect_early_break_hw'

2024-03-29 Thread Thomas Schwinge via Gcc-cvs
https://gcc.gnu.org/g:ec8e3dbdc3befa22b25da975b03d80443f5d938c

commit r14-9721-gec8e3dbdc3befa22b25da975b03d80443f5d938c
Author: Thomas Schwinge 
Date:   Tue Jan 9 10:25:48 2024 +0100

GCN: Enable effective-target 'vect_early_break', 'vect_early_break_hw'

Via XPASSing test cases after commit 
a657c7e3518fcfc796f223d47385cad5e97dc9a5
"testsuite: un-xfail TSVC loops that check for exit control flow 
vectorization":

PASS: gcc.dg/vect/tsvc/vect-tsvc-s332.c (test for excess errors)
PASS: gcc.dg/vect/tsvc/vect-tsvc-s332.c execution test
[-XFAIL:-]{+XPASS:+} gcc.dg/vect/tsvc/vect-tsvc-s332.c scan-tree-dump 
vect "vectorized 1 loops"

PASS: gcc.dg/vect/tsvc/vect-tsvc-s481.c (test for excess errors)
PASS: gcc.dg/vect/tsvc/vect-tsvc-s481.c execution test
[-XFAIL:-]{+XPASS:+} gcc.dg/vect/tsvc/vect-tsvc-s481.c scan-tree-dump 
vect "vectorized 1 loops"

PASS: gcc.dg/vect/tsvc/vect-tsvc-s482.c (test for excess errors)
PASS: gcc.dg/vect/tsvc/vect-tsvc-s482.c execution test
[-XFAIL:-]{+XPASS:+} gcc.dg/vect/tsvc/vect-tsvc-s482.c scan-tree-dump 
vect "vectorized 1 loops"

..., it became apparent that GCN, too, does support vectorization of loops 
with
early breaks.  The relevant test cases are all-PASS with just the following
exceptions, to be looked into individually, later on:

PASS: gcc.dg/vect/vect-early-break_25.c (test for excess errors)
PASS: gcc.dg/vect/vect-early-break_25.c scan-tree-dump-times vect 
"vectorized 1 loops" 1
FAIL: gcc.dg/vect/vect-early-break_25.c scan-tree-dump-times vect 
"Alignment of access forced using peeling" 1

PASS: gcc.dg/vect/vect-early-break_56.c (test for excess errors)
PASS: gcc.dg/vect/vect-early-break_56.c execution test
XPASS: gcc.dg/vect/vect-early-break_56.c scan-tree-dump-times vect 
"vectorized 2 loops" 2

gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_vect_early_break)
(check_effective_target_vect_early_break_hw): Enable for GCN.

Diff:
---
 gcc/testsuite/lib/target-supports.exp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 843515f69d7..9b3bf57d86d 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -4104,6 +4104,7 @@ proc check_effective_target_vect_early_break { } {
[istarget aarch64*-*-*]
|| [check_effective_target_arm_v8_neon_ok]
|| [check_effective_target_sse4]
+   || [istarget amdgcn-*-*]
}}]
 }
 
@@ -4118,6 +4119,7 @@ proc check_effective_target_vect_early_break_hw { } {
[istarget aarch64*-*-*]
|| [check_effective_target_arm_v8_neon_hw]
|| [check_sse4_hw_available]
+   || [istarget amdgcn-*-*]
}}]
 }


[gcc r14-9722] GCN: Enable effective-target 'vect_hw_misalign'

2024-03-29 Thread Thomas Schwinge via Gcc-cvs
https://gcc.gnu.org/g:7cc68c48633ea92fd294193fbc1f9c4fbf4a5c6f

commit r14-9722-g7cc68c48633ea92fd294193fbc1f9c4fbf4a5c6f
Author: Thomas Schwinge 
Date:   Wed Mar 20 23:52:26 2024 +0100

GCN: Enable effective-target 'vect_hw_misalign'

... as made apparent by commit 4e1fcf44bdc582e71408175d75e025f5be8b0e55
"testsuite: vect: Require vect_hw_misalign in 
gcc.dg/vect/vect-cost-model-1.c etc. [PR98238]"
causing:

 PASS: gcc.dg/vect/vect-cost-model-1.c (test for excess errors)
-PASS: gcc.dg/vect/vect-cost-model-1.c scan-tree-dump vect "LOOP 
VECTORIZED"

 PASS: gcc.dg/vect/vect-cost-model-3.c (test for excess errors)
-PASS: gcc.dg/vect/vect-cost-model-3.c scan-tree-dump vect "LOOP 
VECTORIZED"

 PASS: gcc.dg/vect/vect-cost-model-5.c (test for excess errors)
-PASS: gcc.dg/vect/vect-cost-model-5.c scan-tree-dump vect "LOOP 
VECTORIZED"

..., and similarly commit ffd47fb63ddc024db847daa07f8ae27fffdfcb28
"testsuite: Fix pr113431.c FAIL on sparc* [PR113431]" causing:

 PASS: gcc.dg/vect/pr113431.c (test for excess errors)
 PASS: gcc.dg/vect/pr113431.c execution test
-PASS: gcc.dg/vect/pr113431.c scan-tree-dump-times slp1 "optimized: 
basic block part vectorized" 2

..., which this commit all restores, and also enables a good number of 
further
FAIL -> PASS, UNSUPPORTED -> PASS, etc. progressions.  There are also a 
small
number of regressions, mostly in the SLP area apparently:

 PASS: gcc.dg/vect/bb-slp-layout-12.c (test for excess errors)
+XPASS: gcc.dg/vect/bb-slp-layout-12.c scan-tree-dump-not slp1 
"duplicating permutation node"
+XFAIL: gcc.dg/vect/bb-slp-layout-12.c scan-tree-dump-times slp1 "add 
new stmt: [^\\n\\r]* = VEC_PERM_EXPR" 3

 PASS: gcc.dg/vect/bb-slp-layout-6.c (test for excess errors)
+FAIL: gcc.dg/vect/bb-slp-layout-6.c scan-tree-dump slp2 "absorbing 
input layouts"

 PASS: gcc.dg/vect/pr97428.c (test for excess errors)
 PASS: gcc.dg/vect/pr97428.c scan-tree-dump vect "Detected interleaving 
load of size 8"
 PASS: gcc.dg/vect/pr97428.c scan-tree-dump vect "Detected interleaving 
store of size 16"
 PASS: gcc.dg/vect/pr97428.c scan-tree-dump-not vect "gap of 6 elements"
-XFAIL: gcc.dg/vect/pr97428.c scan-tree-dump-times vect "vectorizing 
stmts using SLP" 2
+FAIL: gcc.dg/vect/pr97428.c scan-tree-dump-times vect "vectorizing 
stmts using SLP" 2

 PASS: gcc.dg/vect/vect-33.c (test for excess errors)
+FAIL: gcc.dg/vect/vect-33.c scan-tree-dump vect "Vectorizing an 
unaligned access"
 PASS: gcc.dg/vect/vect-33.c scan-tree-dump-not optimized "Invalid sum"
 PASS: gcc.dg/vect/vect-33.c scan-tree-dump-times vect "vectorized 1 
loops" 1

..., so some further conditionalizing etc. seems necessary.  These seem to
mostly appear next to pre-existing similar FAILs in related test cases.
(Overall, way more PASS than FAIL.)

gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_vect_hw_misalign): Enable for GCN.
(check_effective_target_vect_element_align): Adjust.

Diff:
---
 gcc/testsuite/lib/target-supports.exp | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 9b3bf57d86d..ab60a2d8195 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -8312,7 +8312,8 @@ proc check_effective_target_vect_hw_misalign { } {
 || ([istarget s390*-*-*]
 && [check_effective_target_s390_vx])
 || ([istarget riscv*-*-*])
-|| ([istarget loongarch*-*-*]) } {
+|| ([istarget loongarch*-*-*])
+|| [istarget amdgcn*-*-*] } {
  return 1
}
if { [istarget arm*-*-*]
@@ -8876,8 +8877,7 @@ proc check_effective_target_vect_element_align { } {
 return [check_cached_effective_target_indexed vect_element_align {
   expr { ([istarget arm*-*-*]
  && ![check_effective_target_arm_vect_no_misalign])
-|| [check_effective_target_vect_hw_misalign]
-|| [istarget amdgcn-*-*] }}]
+|| [check_effective_target_vect_hw_misalign] }}]
 }
 
 # Return 1 if we expect to see unaligned accesses in at least some


[gcc r14-9723] GCN: Enable effective-target 'vect_long_mult'

2024-03-29 Thread Thomas Schwinge via Gcc-cvs
https://gcc.gnu.org/g:e162228e0baebc836c74c82521d1c7a3c46d9ab1

commit r14-9723-ge162228e0baebc836c74c82521d1c7a3c46d9ab1
Author: Thomas Schwinge 
Date:   Wed Mar 20 23:56:58 2024 +0100

GCN: Enable effective-target 'vect_long_mult'

... as made apparent by commit bfd6b36f08021f023e0e9223f5aea315b74a5c56
"testsuite/vect: Fix pr25413a.c expectations [PR109705]" causing:

 PASS: gcc.dg/vect/pr25413a.c (test for excess errors)
 PASS: gcc.dg/vect/pr25413a.c execution test
-PASS: gcc.dg/vect/pr25413a.c scan-tree-dump-times vect "vectorized 2 
loops" 1
+FAIL: gcc.dg/vect/pr25413a.c scan-tree-dump-times vect "vectorized 1 
loops" 1

..., which this commit resolves.

gcc/testsuite/
* lib/target-supports.exp (check_effective_target_vect_long_mult):
Enable for GCN.

Diff:
---
 gcc/testsuite/lib/target-supports.exp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index ab60a2d8195..45435586de2 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -9059,7 +9059,8 @@ proc check_effective_target_vect_long_mult { } {
 || ([istarget riscv*-*-*]
  && [check_effective_target_riscv_v])
 || ([istarget loongarch*-*-*]
- && [check_effective_target_loongarch_sx]) } {
+ && [check_effective_target_loongarch_sx])
+|| [istarget amdgcn-*-*] } {
set answer 1
 } else {
set answer 0


[gcc r14-9724] libstdc++-v3: drop GCC Runtime Library Exception from gen tests

2024-03-29 Thread Arsen Arsenović via Libstdc++-cvs
https://gcc.gnu.org/g:f15cea16cc98912bf0ed14d388510d6c2618ba90

commit r14-9724-gf15cea16cc98912bf0ed14d388510d6c2618ba90
Author: Arsen Arsenović 
Date:   Fri Mar 29 12:42:19 2024 +0100

libstdc++-v3: drop GCC Runtime Library Exception from gen tests

It was mistakenly added to these files.

libstdc++-v3/ChangeLog:

* testsuite/24_iterators/range_generators/01.cc: Drop GCC
Runtime Library Exception.
* testsuite/24_iterators/range_generators/02.cc: Drop GCC
Runtime Library Exception.
* testsuite/24_iterators/range_generators/copy.cc: Drop GCC
Runtime Library Exception.
* testsuite/24_iterators/range_generators/except.cc: Drop GCC
Runtime Library Exception.
* testsuite/24_iterators/range_generators/subrange.cc: Drop GCC
Runtime Library Exception.
* testsuite/24_iterators/range_generators/synopsis.cc: Drop GCC
Runtime Library Exception.
* testsuite/24_iterators/range_generators/iter_deref_return.cc:
Drop GCC Runtime Library Exception from the "You should have
received a copy" paragraph.

Diff:
---
 libstdc++-v3/testsuite/24_iterators/range_generators/01.cc   | 9 ++---
 libstdc++-v3/testsuite/24_iterators/range_generators/02.cc   | 9 ++---
 libstdc++-v3/testsuite/24_iterators/range_generators/copy.cc | 9 ++---
 libstdc++-v3/testsuite/24_iterators/range_generators/except.cc   | 9 ++---
 .../testsuite/24_iterators/range_generators/iter_deref_return.cc | 4 
 libstdc++-v3/testsuite/24_iterators/range_generators/subrange.cc | 9 ++---
 libstdc++-v3/testsuite/24_iterators/range_generators/synopsis.cc | 9 ++---
 7 files changed, 16 insertions(+), 42 deletions(-)

diff --git a/libstdc++-v3/testsuite/24_iterators/range_generators/01.cc 
b/libstdc++-v3/testsuite/24_iterators/range_generators/01.cc
index 2af5ed1895a..81837e156fe 100644
--- a/libstdc++-v3/testsuite/24_iterators/range_generators/01.cc
+++ b/libstdc++-v3/testsuite/24_iterators/range_generators/01.cc
@@ -12,13 +12,8 @@
 // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 // GNU General Public License for more details.
 
-// Under Section 7 of GPL version 3, you are granted additional
-// permissions described in the GCC Runtime Library Exception, version
-// 3.1, as published by the Free Software Foundation.
-
-// You should have received a copy of the GNU General Public License and
-// a copy of the GCC Runtime Library Exception along with this program;
-// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
 // .
 
 #include 
diff --git a/libstdc++-v3/testsuite/24_iterators/range_generators/02.cc 
b/libstdc++-v3/testsuite/24_iterators/range_generators/02.cc
index 8e23a9c4933..da2d2d42f04 100644
--- a/libstdc++-v3/testsuite/24_iterators/range_generators/02.cc
+++ b/libstdc++-v3/testsuite/24_iterators/range_generators/02.cc
@@ -12,13 +12,8 @@
 // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 // GNU General Public License for more details.
 
-// Under Section 7 of GPL version 3, you are granted additional
-// permissions described in the GCC Runtime Library Exception, version
-// 3.1, as published by the Free Software Foundation.
-
-// You should have received a copy of the GNU General Public License and
-// a copy of the GCC Runtime Library Exception along with this program;
-// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
 // .
 
 #include 
diff --git a/libstdc++-v3/testsuite/24_iterators/range_generators/copy.cc 
b/libstdc++-v3/testsuite/24_iterators/range_generators/copy.cc
index c74fb0cf09e..7ceec33dd78 100644
--- a/libstdc++-v3/testsuite/24_iterators/range_generators/copy.cc
+++ b/libstdc++-v3/testsuite/24_iterators/range_generators/copy.cc
@@ -12,13 +12,8 @@
 // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 // GNU General Public License for more details.
 
-// Under Section 7 of GPL version 3, you are granted additional
-// permissions described in the GCC Runtime Library Exception, version
-// 3.1, as published by the Free Software Foundation.
-
-// You should have received a copy of the GNU General Public License and
-// a copy of the GCC Runtime Library Exception along with this program;
-// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
 // .
 
 #include 
diff --git a/libstdc++-v3/testsuite/24_iterators/range_genera

[gcc r14-9725] Fix lrcpc3 testcase

2024-03-29 Thread Christophe Lyon via Gcc-cvs
https://gcc.gnu.org/g:28dca4be504dda29f55eafe958cdf299ec89b94e

commit r14-9725-g28dca4be504dda29f55eafe958cdf299ec89b94e
Author: Christophe Lyon 
Date:   Fri Mar 29 14:19:59 2024 +

Fix lrcpc3 testcase

There was a typo in the testcase, with GCC_CPUINFO pointing to the
wrong file.

2024-03-29  Christophe Lyon  

gcc/testsuite/
* gcc.target/aarch64/cpunative/native_cpu_24.c: Fix GCC_CPUINFO.

Diff:
---
 gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_24.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_24.c 
b/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_24.c
index 05dc870885f..3a720cc8552 100644
--- a/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_24.c
+++ b/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_24.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { { aarch64*-*-linux*} && native } } } */
-/* { dg-set-compiler-env-var GCC_CPUINFO 
"$srcdir/gcc.target/aarch64/cpunative/info_23" } */
+/* { dg-set-compiler-env-var GCC_CPUINFO 
"$srcdir/gcc.target/aarch64/cpunative/info_24" } */
 /* { dg-additional-options "-mcpu=native --save-temps " } */
 
 int main()


[gcc r13-8505] Fortran: fix NULL pointer dereference on overlapping initialization [PR50410]

2024-03-29 Thread Harald Anlauf via Gcc-cvs
https://gcc.gnu.org/g:250990298fb792635d9895e7642ccedbc2dd39d4

commit r13-8505-g250990298fb792635d9895e7642ccedbc2dd39d4
Author: Harald Anlauf 
Date:   Thu Mar 28 22:34:40 2024 +0100

Fortran: fix NULL pointer dereference on overlapping initialization 
[PR50410]

gcc/fortran/ChangeLog:

PR fortran/50410
* trans-expr.cc (gfc_conv_structure): Check for NULL pointer.

gcc/testsuite/ChangeLog:

PR fortran/50410
* gfortran.dg/data_initialized_4.f90: New test.

(cherry picked from commit 6fb253a25dff13253d63553f02e0fe72c5e3ab4e)

Diff:
---
 gcc/fortran/trans-expr.cc|  2 +-
 gcc/testsuite/gfortran.dg/data_initialized_4.f90 | 16 
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 3f3f0123dc3..d9de93260a6 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -9364,7 +9364,7 @@ gfc_conv_structure (gfc_se * se, gfc_expr * expr, int 
init)
   cm = expr->ts.u.derived->components;
 
   for (c = gfc_constructor_first (expr->value.constructor);
-   c; c = gfc_constructor_next (c), cm = cm->next)
+   c && cm; c = gfc_constructor_next (c), cm = cm->next)
 {
   /* Skip absent members in default initializers and allocatable
 components.  Although the latter have a default initializer
diff --git a/gcc/testsuite/gfortran.dg/data_initialized_4.f90 
b/gcc/testsuite/gfortran.dg/data_initialized_4.f90
new file mode 100644
index 000..156b6607edf
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/data_initialized_4.f90
@@ -0,0 +1,16 @@
+! { dg-do compile }
+! { dg-additional-options "-std=legacy" }
+!
+! PR fortran/50410
+!
+! Silently allow overlapping initialization in legacy mode (used to ICE)
+
+program p
+  implicit none
+  type t
+ integer :: g = 1
+  end type t
+  type(t) :: u = t(2)
+  data u%g /3/
+  print *, u! this might print "2"
+end


[gcc r13-8506] Fortran: fix passing of optional dummies to bind(c) procedures [PR113866]

2024-03-29 Thread Harald Anlauf via Gcc-cvs
https://gcc.gnu.org/g:5f9144021615f24d038890dab7db2a0b9e84f6d3

commit r13-8506-g5f9144021615f24d038890dab7db2a0b9e84f6d3
Author: Harald Anlauf 
Date:   Tue Feb 13 20:19:10 2024 +0100

Fortran: fix passing of optional dummies to bind(c) procedures [PR113866]

PR fortran/113866

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): When passing an optional
dummy argument to an optional dummy argument of a bind(c) procedure
and the dummy argument is passed via a CFI descriptor, no special
presence check and passing of a default NULL pointer is needed.

gcc/testsuite/ChangeLog:

* gfortran.dg/bind_c_optional-2.f90: New test.

(cherry picked from commit f4935df217ad89f884f908f39086b322e80123d0)

Diff:
---
 gcc/fortran/trans-expr.cc   |   6 +-
 gcc/testsuite/gfortran.dg/bind_c_optional-2.f90 | 105 
 2 files changed, 109 insertions(+), 2 deletions(-)

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index d9de93260a6..c3f02c83b3f 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -7052,8 +7052,10 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 with an interface indicating an optional argument.  When we call
 an intrinsic subroutine, however, fsym is NULL, but we might still
 have an optional argument, so we proceed to the substitution
-just in case.  */
-  if (e && (fsym == NULL || fsym->attr.optional))
+just in case.  Arguments passed to bind(c) procedures via CFI
+descriptors are handled elsewhere.  */
+  if (e && (fsym == NULL || fsym->attr.optional)
+ && !(sym->attr.is_bind_c && is_CFI_desc (fsym, NULL)))
{
  /* If an optional argument is itself an optional dummy argument,
 check its presence and substitute a null if absent.  This is
diff --git a/gcc/testsuite/gfortran.dg/bind_c_optional-2.f90 
b/gcc/testsuite/gfortran.dg/bind_c_optional-2.f90
new file mode 100644
index 000..ceedef7f006
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/bind_c_optional-2.f90
@@ -0,0 +1,105 @@
+! { dg-do run }
+! PR fortran/113866
+!
+! Check interoperability of assumed-length character (optional and
+! non-optional) dummies between bind(c) and non-bind(c) procedures
+
+module bindcchar
+  implicit none
+  integer, parameter :: n = 100, l = 10
+contains
+  subroutine bindc_optional (c2, c4) bind(c)
+character(*), optional :: c2, c4(n)
+!   print *, c2(1:3)
+!   print *, c4(5)(1:3) 
+if (.not. present (c2) .or. .not. present (c4)) stop 8
+if (len (c2) /= l .or. len (c4) /= l) stop 81
+if (c2(1:3)/= "a23") stop 1
+if (c4(5)(1:3) /= "bcd") stop 2
+  end
+
+  subroutine bindc (c2, c4) bind(c)
+character(*) :: c2, c4(n)
+if (len (c2) /= l .or. len (c4) /= l) stop 82
+if (c2(1:3)/= "a23") stop 3
+if (c4(5)(1:3) /= "bcd") stop 4
+call bindc_optional (c2, c4)
+  end
+
+  subroutine not_bindc_optional (c1, c3)
+character(*), optional :: c1, c3(n)
+if (.not. present (c1) .or. .not. present (c3)) stop 5
+if (len (c1) /= l .or. len (c3) /= l) stop 83
+call bindc_optional (c1, c3)
+call bindc  (c1, c3)
+  end
+
+  subroutine not_bindc_optional_deferred (c5, c6)
+character(:), allocatable, optional :: c5, c6(:)
+if (.not. present (c5) .or. .not. present (c6)) stop 6
+if (len (c5) /= l .or. len (c6) /= l) stop 84
+call not_bindc_optional (c5, c6)
+call bindc_optional (c5, c6)
+call bindc  (c5, c6)
+  end
+
+  subroutine not_bindc_optional2 (c7, c8)
+character(*), optional :: c7, c8(:)
+if (.not. present (c7) .or. .not. present (c8)) stop 7
+if (len (c7) /= l .or. len (c8) /= l) stop 85
+call bindc_optional (c7, c8)
+call bindc  (c7, c8)
+  end
+
+  subroutine bindc_optional2 (c2, c4) bind(c)
+character(*), optional :: c2, c4(n)
+if (.not. present (c2) .or. .not. present (c4)) stop 8
+if (len (c2) /= l .or. len (c4) /= l) stop 86
+if (c2(1:3)/= "a23") stop 9
+if (c4(5)(1:3) /= "bcd") stop 10
+call bindc_optional (c2, c4)
+call not_bindc_optional (c2, c4)
+  end
+
+  subroutine bindc_optional_missing (c1, c2, c3, c4, c5) bind(c)
+character(*), optional :: c1, c2(n), c3(:), c4(..), c5(*)
+if (present (c1)) stop 11
+if (present (c2)) stop 12
+if (present (c3)) stop 13
+if (present (c4)) stop 14
+if (present (c5)) stop 15
+  end
+
+  subroutine non_bindc_optional_missing (c1, c2, c3, c4, c5)
+character(*), optional :: c1, c2(n), c3(:), c4(..), c5(*)
+if (present (c1)) stop 21
+if (present (c2)) stop 22
+if (present (c3)) stop 23
+if (present (c4)) stop 24
+if (present (c5)) stop 25
+  end
+end module
+
+program p
+  use bindcchar
+  implicit none
+  character(l) :: a, b(n)
+  character(:), allocatable :: d, e(:

[gcc r12-10299] Fortran: fix NULL pointer dereference on overlapping initialization [PR50410]

2024-03-29 Thread Harald Anlauf via Gcc-cvs
https://gcc.gnu.org/g:cb72fbd49e1f0c1cbdf8a9e97860063b19b1f95e

commit r12-10299-gcb72fbd49e1f0c1cbdf8a9e97860063b19b1f95e
Author: Harald Anlauf 
Date:   Thu Mar 28 22:34:40 2024 +0100

Fortran: fix NULL pointer dereference on overlapping initialization 
[PR50410]

gcc/fortran/ChangeLog:

PR fortran/50410
* trans-expr.cc (gfc_conv_structure): Check for NULL pointer.

gcc/testsuite/ChangeLog:

PR fortran/50410
* gfortran.dg/data_initialized_4.f90: New test.

(cherry picked from commit 6fb253a25dff13253d63553f02e0fe72c5e3ab4e)

Diff:
---
 gcc/fortran/trans-expr.cc|  2 +-
 gcc/testsuite/gfortran.dg/data_initialized_4.f90 | 16 
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 27b34984705..11ee1931b8e 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -9298,7 +9298,7 @@ gfc_conv_structure (gfc_se * se, gfc_expr * expr, int 
init)
   cm = expr->ts.u.derived->components;
 
   for (c = gfc_constructor_first (expr->value.constructor);
-   c; c = gfc_constructor_next (c), cm = cm->next)
+   c && cm; c = gfc_constructor_next (c), cm = cm->next)
 {
   /* Skip absent members in default initializers and allocatable
 components.  Although the latter have a default initializer
diff --git a/gcc/testsuite/gfortran.dg/data_initialized_4.f90 
b/gcc/testsuite/gfortran.dg/data_initialized_4.f90
new file mode 100644
index 000..156b6607edf
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/data_initialized_4.f90
@@ -0,0 +1,16 @@
+! { dg-do compile }
+! { dg-additional-options "-std=legacy" }
+!
+! PR fortran/50410
+!
+! Silently allow overlapping initialization in legacy mode (used to ICE)
+
+program p
+  implicit none
+  type t
+ integer :: g = 1
+  end type t
+  type(t) :: u = t(2)
+  data u%g /3/
+  print *, u! this might print "2"
+end


[gcc r11-11299] Fortran: fix NULL pointer dereference on overlapping initialization [PR50410]

2024-03-29 Thread Harald Anlauf via Gcc-cvs
https://gcc.gnu.org/g:1611acc1f72cad30c7ecccb5c85246836c1d0299

commit r11-11299-g1611acc1f72cad30c7ecccb5c85246836c1d0299
Author: Harald Anlauf 
Date:   Thu Mar 28 22:34:40 2024 +0100

Fortran: fix NULL pointer dereference on overlapping initialization 
[PR50410]

gcc/fortran/ChangeLog:

PR fortran/50410
* trans-expr.c (gfc_conv_structure): Check for NULL pointer.

gcc/testsuite/ChangeLog:

PR fortran/50410
* gfortran.dg/data_initialized_4.f90: New test.

(cherry picked from commit 6fb253a25dff13253d63553f02e0fe72c5e3ab4e)

Diff:
---
 gcc/fortran/trans-expr.c |  2 +-
 gcc/testsuite/gfortran.dg/data_initialized_4.f90 | 16 
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 5adee114157..37f16f37e12 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -8879,7 +8879,7 @@ gfc_conv_structure (gfc_se * se, gfc_expr * expr, int 
init)
   cm = expr->ts.u.derived->components;
 
   for (c = gfc_constructor_first (expr->value.constructor);
-   c; c = gfc_constructor_next (c), cm = cm->next)
+   c && cm; c = gfc_constructor_next (c), cm = cm->next)
 {
   /* Skip absent members in default initializers and allocatable
 components.  Although the latter have a default initializer
diff --git a/gcc/testsuite/gfortran.dg/data_initialized_4.f90 
b/gcc/testsuite/gfortran.dg/data_initialized_4.f90
new file mode 100644
index 000..156b6607edf
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/data_initialized_4.f90
@@ -0,0 +1,16 @@
+! { dg-do compile }
+! { dg-additional-options "-std=legacy" }
+!
+! PR fortran/50410
+!
+! Silently allow overlapping initialization in legacy mode (used to ICE)
+
+program p
+  implicit none
+  type t
+ integer :: g = 1
+  end type t
+  type(t) :: u = t(2)
+  data u%g /3/
+  print *, u! this might print "2"
+end


[gcc r14-9726] [PATCH] Allow `gcc_jit_type_get_size` to work with pointers

2024-03-29 Thread Guillaume Gomez via Gcc-cvs
https://gcc.gnu.org/g:4c18ace1cb69a31af4ac719850a66de79ed12e93

commit r14-9726-g4c18ace1cb69a31af4ac719850a66de79ed12e93
Author: Guillaume Gomez 
Date:   Fri Mar 29 18:56:33 2024 +0100

[PATCH] Allow `gcc_jit_type_get_size` to work with pointers

gcc/jit/ChangeLog:

* libgccjit.cc (gcc_jit_type_get_size): Add pointer support

Diff:
---
 gcc/jit/libgccjit.cc |  4 ++--
 gcc/testsuite/jit.dg/test-pointer_size.c | 27 +++
 2 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
index f40a9781405..445c0d0e0e3 100644
--- a/gcc/jit/libgccjit.cc
+++ b/gcc/jit/libgccjit.cc
@@ -560,8 +560,8 @@ gcc_jit_type_get_size (gcc_jit_type *type)
 {
   RETURN_VAL_IF_FAIL (type, -1, NULL, NULL, "NULL type");
   RETURN_VAL_IF_FAIL
-(type->is_int () || type->is_float (), -1, NULL, NULL,
- "only getting the size of integer or floating-point types is supported 
for now");
+(type->is_int () || type->is_float () || type->is_pointer (), -1, NULL, 
NULL,
+ "only getting the size of integer or floating-point or pointer types is 
supported for now");
   return type->get_size ();
 }
 
diff --git a/gcc/testsuite/jit.dg/test-pointer_size.c 
b/gcc/testsuite/jit.dg/test-pointer_size.c
new file mode 100644
index 000..337796acc2a
--- /dev/null
+++ b/gcc/testsuite/jit.dg/test-pointer_size.c
@@ -0,0 +1,27 @@
+/* { dg-do compile { target x86_64-*-* } } */
+
+#include 
+#include "libgccjit.h"
+
+#include "harness.h"
+
+void
+create_code (gcc_jit_context *ctxt, void *user_data)
+{}
+
+void
+verify_code (gcc_jit_context *ctxt, gcc_jit_result *result)
+{
+  gcc_jit_type *int_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_INT);
+  gcc_jit_type *int_ptr_type = gcc_jit_type_get_pointer (int_type);
+
+  int int_ptr_size = gcc_jit_type_get_size (int_ptr_type);
+  CHECK_VALUE (int_ptr_size, 8);
+
+  gcc_jit_type *void_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_VOID);
+  gcc_jit_type *void_ptr_type = gcc_jit_type_get_pointer (void_type);
+
+  CHECK_VALUE (int_ptr_size, gcc_jit_type_get_size (void_ptr_type));
+}


[gcc r14-9728] mips: Fix C23 (...) functions returning large aggregates [PR114175]

2024-03-29 Thread Xi Ruoyao via Gcc-cvs
https://gcc.gnu.org/g:6fc84f680d098f82c1c43435fdb206099f0df4df

commit r14-9728-g6fc84f680d098f82c1c43435fdb206099f0df4df
Author: Xi Ruoyao 
Date:   Wed Mar 20 15:09:21 2024 +0800

mips: Fix C23 (...) functions returning large aggregates [PR114175]

We were assuming TYPE_NO_NAMED_ARGS_STDARG_P don't have any named
arguments and there is nothing to advance, but that is not the case
for (...) functions returning by hidden reference which have one such
artificial argument.  This is causing gcc.dg/c23-stdarg-{6,8,9}.c to
fail.

Fix the issue by checking if arg.type is NULL, as r14-9503 explains.

gcc/ChangeLog:

PR target/114175
* config/mips/mips.cc (mips_setup_incoming_varargs): Only skip
mips_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P
functions if arg.type is NULL.

Diff:
---
 gcc/config/mips/mips.cc | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
index 68e2ae8d8fa..ce764a5cb35 100644
--- a/gcc/config/mips/mips.cc
+++ b/gcc/config/mips/mips.cc
@@ -6834,7 +6834,13 @@ mips_setup_incoming_varargs (cumulative_args_t cum,
  argument.  Advance a local copy of CUM past the last "real" named
  argument, to find out how many registers are left over.  */
   local_cum = *get_cumulative_args (cum);
-  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl)))
+
+  /* For a C23 variadic function w/o any named argument, and w/o an
+ artifical argument for large return value, skip advancing args.
+ There is such an artifical argument iff. arg.type is non-NULL
+ (PR 114175).  */
+  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl))
+  || arg.type != NULL_TREE)
 mips_function_arg_advance (pack_cumulative_args (&local_cum), arg);
 
   /* Found out how many registers we need to save.  */


[gcc r13-8508] i386: Fix setup of incoming varargs for (...) functions which return large aggregates [PR114175]

2024-03-29 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:4e0a922db4dadaef704c68ed26693667903c5d0c

commit r13-8508-g4e0a922db4dadaef704c68ed26693667903c5d0c
Author: Jakub Jelinek 
Date:   Sat Mar 16 15:16:33 2024 +0100

i386: Fix setup of incoming varargs for (...) functions which return large 
aggregates [PR114175]

The c23-stdarg-6.c testcase I've added recently apparently works fine with
-O0 but aborts with -O1 and higher on x86_64-linux.
The problem is in setup of incoming varargs.

Like function.cc before r14-9249 even ix86_setup_incoming_varargs assumes
that TYPE_NO_NAMED_ARGS_STDARG_P don't have any named arguments and there
is nothing to advance, but that is not the case for (...) functions
returning by hidden reference which have one such artificial argument.
If the setup_incoming_varargs hook is called from the
  if (TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (fndecl))
  && fnargs.is_empty ())
{
  struct assign_parm_data_one data = {};
  assign_parms_setup_varargs (&all, &data, false);
}
spot, i.e. where there is no hidden return argument passed, arg.type
is always NULL, while when it is called in the
  if (cfun->stdarg && !DECL_CHAIN (parm))
assign_parms_setup_varargs (&all, &data, false);
spot, even when it is TYPE_NO_NAMED_ARGS_STDARG_P arg.type will be non-NULL.
The tree-stdarg.cc pass in f in c23-stdarg-6.cc at -O1 or higher determines
that va_arg is used on integral types at most twice (loads 2 words),
and because ix86_setup_incoming_varargs doesn't advance, the code saves
just the %rdi and %rsi registers to the save area.  But that isn't correct,
it should save %rsi and %rdx because %rdi is the hidden return argument.
With -O0 tree-stdarg.cc doesn't attempt to optimize and we save all the
registers, so it works fine in that case.

Now, I think we'll need the same fix also on
aarch64, alpha, arc, csky, ia64, loongarch, mips, mmix, nios2, riscv, visium
which have pretty much the similarly looking snippet in their hooks
changed by the r13-3549 commit.
Then arm, epiphany, fr30, frv, ft32, m32r, mcore, nds32, rs6000, sh
have different changes but most likely need something similar too.
I don't have access to most of those, could test aarch64 and rs6000 I guess.

2024-03-16  Jakub Jelinek  

PR target/114175
* config/i386/i386.cc (ix86_setup_incoming_varargs): Only skip
ix86_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.

* gcc.dg/c23-stdarg-7.c: New test.
* gcc.dg/c23-stdarg-8.c: New test.

(cherry picked from commit 218d17496122abe1fd831bd003f129310b32ca83)

Diff:
---
 gcc/config/i386/i386.cc | 3 ++-
 gcc/testsuite/gcc.dg/c23-stdarg-7.c | 6 ++
 gcc/testsuite/gcc.dg/c23-stdarg-8.c | 6 ++
 3 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index a3a295a303e..499184166ff 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -4564,7 +4564,8 @@ ix86_setup_incoming_varargs (cumulative_args_t cum_v,
   /* For varargs, we do not want to skip the dummy va_dcl argument.
  For stdargs, we do want to skip the last named argument.  */
   next_cum = *cum;
-  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl))
+  if ((!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl))
+   || arg.type != NULL_TREE)
   && stdarg_p (fntype))
 ix86_function_arg_advance (pack_cumulative_args (&next_cum), arg);
 
diff --git a/gcc/testsuite/gcc.dg/c23-stdarg-7.c 
b/gcc/testsuite/gcc.dg/c23-stdarg-7.c
new file mode 100644
index 000..0282eaa9889
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c23-stdarg-7.c
@@ -0,0 +1,6 @@
+/* Test C23 variadic functions with no named parameters, or last named
+   parameter with a declaration not allowed in C17.  Execution tests.  */
+/* { dg-do run } */
+/* { dg-options "-O2 -std=c2x -pedantic-errors" } */
+
+#include "c2x-stdarg-4.c"
diff --git a/gcc/testsuite/gcc.dg/c23-stdarg-8.c 
b/gcc/testsuite/gcc.dg/c23-stdarg-8.c
new file mode 100644
index 000..8df3dd7768c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c23-stdarg-8.c
@@ -0,0 +1,6 @@
+/* Test C23 variadic functions with no named parameters, or last named
+   parameter with a declaration not allowed in C17.  Execution tests.  */
+/* { dg-do run } */
+/* { dg-options "-O2 -std=c2x -pedantic-errors" } */
+
+#include "c23-stdarg-6.c"


[gcc r13-8509] rs6000: Fix up setup_incoming_varargs [PR114175]

2024-03-29 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:af189fa9c2c4a0c8230f308e1934f046df3e80f7

commit r13-8509-gaf189fa9c2c4a0c8230f308e1934f046df3e80f7
Author: Jakub Jelinek 
Date:   Tue Mar 19 09:13:32 2024 +0100

rs6000: Fix up setup_incoming_varargs [PR114175]

The c23-stdarg-8.c test (as well as the new test below added to cover even
more cases) FAIL on powerpc64le-linux and presumably other powerpc* targets
as well.
Like in the r14-9503-g218d174961 change on x86-64 we need to advance
next_cum after the hidden return pointer argument even in case where
there are no user arguments before ... in C23.
The following patch does that.

There is another TYPE_NO_NAMED_ARGS_STDARG_P use later on:
  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl))
  && targetm.calls.must_pass_in_stack (arg))
first_reg_offset += rs6000_arg_size (TYPE_MODE (arg.type), 
arg.type);
but I believe it was added there in r13-3549-g4fe34cdc unnecessarily,
when there is no hidden return pointer argument, arg.type is NULL and
must_pass_in_stack_var_size as well as must_pass_in_stack_var_size_or_pad
return false in that case, and for the TYPE_NO_NAMED_ARGS_STDARG_P
case with hidden return pointer argument that argument should have pointer
type and it is the first argument, so must_pass_in_stack shouldn't be true
for it either.

2024-03-19  Jakub Jelinek  

PR target/114175
* config/rs6000/rs6000-call.cc (setup_incoming_varargs): Only skip
rs6000_function_arg_advance_1 for TYPE_NO_NAMED_ARGS_STDARG_P 
functions
if arg.type is NULL.

* gcc.dg/c23-stdarg-9.c: New test.

(cherry picked from commit 8f85b46337f90c3126b9cefd72ffd29eb9a4ebf3)

Diff:
---
 gcc/config/rs6000/rs6000-call.cc|   3 +-
 gcc/testsuite/gcc.dg/c23-stdarg-9.c | 284 
 2 files changed, 286 insertions(+), 1 deletion(-)

diff --git a/gcc/config/rs6000/rs6000-call.cc b/gcc/config/rs6000/rs6000-call.cc
index 214613e083e..74ee908a1a8 100644
--- a/gcc/config/rs6000/rs6000-call.cc
+++ b/gcc/config/rs6000/rs6000-call.cc
@@ -2253,7 +2253,8 @@ setup_incoming_varargs (cumulative_args_t cum,
 
   /* Skip the last named argument.  */
   next_cum = *get_cumulative_args (cum);
-  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl)))
+  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl))
+  || arg.type != NULL_TREE)
 rs6000_function_arg_advance_1 (&next_cum, arg.mode, arg.type, arg.named,
   0);
 
diff --git a/gcc/testsuite/gcc.dg/c23-stdarg-9.c 
b/gcc/testsuite/gcc.dg/c23-stdarg-9.c
new file mode 100644
index 000..fe96fc7a864
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c23-stdarg-9.c
@@ -0,0 +1,284 @@
+/* Test C23 variadic functions with no named parameters, or last named
+   parameter with a declaration not allowed in C17.  Execution tests.  */
+/* { dg-do run } */
+/* { dg-options "-O2 -std=c2x -pedantic-errors" } */
+
+#include 
+
+struct S { int a[1024]; };
+
+int
+f1 (...)
+{
+  int r = 0;
+  va_list ap;
+  va_start (ap);
+  r += va_arg (ap, int);
+  va_end (ap);
+  return r;
+}
+
+int
+f2 (...)
+{
+  int r = 0;
+  va_list ap;
+  va_start (ap);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  va_end (ap);
+  return r;
+}
+
+int
+f3 (...)
+{
+  int r = 0;
+  va_list ap;
+  va_start (ap);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  va_end (ap);
+  return r;
+}
+
+int
+f4 (...)
+{
+  int r = 0;
+  va_list ap;
+  va_start (ap);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  va_end (ap);
+  return r;
+}
+
+int
+f5 (...)
+{
+  int r = 0;
+  va_list ap;
+  va_start (ap);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  va_end (ap);
+  return r;
+}
+
+int
+f6 (...)
+{
+  int r = 0;
+  va_list ap;
+  va_start (ap);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  va_end (ap);
+  return r;
+}
+
+int
+f7 (...)
+{
+  int r = 0;
+  va_list ap;
+  va_start (ap);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  va_end (ap);
+  return r;
+}
+
+int
+f8 (...)
+{
+  int r = 0;
+  va_list ap;
+  va_start (ap);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  r += va_arg (ap, int);
+  va_end (ap);
+  return r;
+}
+
+struct S
+s1 (...)
+{
+  int r = 0;
+  va_list ap;
+  va_start (ap);
+  r += va_arg (ap, int);
+  va_end (ap);
+  struct S s = {};
+  s.a[0] = r;
+

[gcc r13-8510] alpha: Fix alpha_setup_incoming_varargs [PR114175]

2024-03-29 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:d3faceaa7a18657cc73dff1405a54834e390624b

commit r13-8510-gd3faceaa7a18657cc73dff1405a54834e390624b
Author: Jakub Jelinek 
Date:   Tue Mar 19 09:14:11 2024 +0100

alpha: Fix alpha_setup_incoming_varargs [PR114175]

Like in the r14-9503 change on x86-64, I think Alpha also needs to
function_arg_advance after the hidden return pointer argument if
any.
At least, the following patch changes the assembly of s1-s6 functions
on the https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647956.html
c23-stdarg-9.c testcase, and eyeballing the assembly for int f8 (...)
the ... args are passed in 16..21 registers and then on the stack,
while for struct S s8 (...) have hidden return pointer passed in 16
register and ... args in 17..21 registers and then on the stack, and
seems without this patch the incoming varargs setup does the wrong thing
(but I can't test on alpha easily).

Many targets seem to be unaffected, e.g. aarch64, arm, s390*, so I'm not
trying to change all targets together because such a change clearly isn't
needed e.g. for targets which use special register for the hidden return
pointer.

2024-03-19  Jakub Jelinek  

PR target/114175
* config/alpha/alpha.cc (alpha_setup_incoming_varargs): Only skip
function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.

(cherry picked from commit a185d8aeeed7a25a01505565aa61ccf8a876c6ff)

Diff:
---
 gcc/config/alpha/alpha.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/alpha/alpha.cc b/gcc/config/alpha/alpha.cc
index bb41aeb6d54..7a12268abc7 100644
--- a/gcc/config/alpha/alpha.cc
+++ b/gcc/config/alpha/alpha.cc
@@ -6089,7 +6089,8 @@ alpha_setup_incoming_varargs (cumulative_args_t pcum,
 {
   CUMULATIVE_ARGS cum = *get_cumulative_args (pcum);
 
-  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl)))
+  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl))
+  || arg.type != NULL_TREE)
 /* Skip the current argument.  */
 targetm.calls.function_arg_advance (pack_cumulative_args (&cum), arg);


[gcc r13-8512] system.h: rename vec_step to workaround powerpc/clang bug [PR114369]

2024-03-29 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:8046a7e2aeeae80c15d99d55ae04755aedf46a2f

commit r13-8512-g8046a7e2aeeae80c15d99d55ae04755aedf46a2f
Author: Jakub Jelinek 
Date:   Wed Mar 20 10:34:51 2024 +0100

system.h: rename vec_step to workaround powerpc/clang bug [PR114369]

On Sat, Jul 20, 2019 at 05:26:57PM +0100, Richard Sandiford wrote:
> Gerald Pfeifer  writes:
> > I have seen an increasing number of reports of GCC failing to
> > build with clang on powerpc (on FreeBSD, though that's probably
> > immaterial).
> >
> > Turns out that clang has vec_step as a reserved word on powerpc
> > with AltiVec.
> >
> > We OTOH use vec_step s as a variable name in gcc/tree-vect-loop.c.
> >
> >
> > The best approach I can see is to rename vec_step.  Before I prepare
> > a patch: what alternate name/spelling would you prefer?
>
> Would it work to #define vec_step to vec_step_ or something on affected
> hosts, say in system.h?
>
> I'd prefer that to renmaing since "vec_step" does seem the most natural
> name for the variable.  The equivalent scalar variable is "step" and
> other vector values in the surrounding code also use the "vec_" prefix.

So like this?

If/when clang finally fixes 
https://github.com/llvm/llvm-project/issues/85579
on their side, we can then limit it to clang versions which still have the
bug.

I've git grepped for vec_set and appart from altivec.h it is just used in
tree-vect-loop.cc, some Ada files which aren't preprocessed, ChangeLogs,
rs6000-vecdefines.h (but that header is only included from altivec.h and
vec_step is then redefined to the function-like macro) and in 
rs6000-overload.def
but that file is processed with a generator, not included in C/C++ sources.

2024-03-20  Jakub Jelinek  

PR bootstrap/114369
* system.h (vec_step): Define to vec_step_ when compiling
with clang on PowerPC.

(cherry picked from commit 5e64228fe1f7ec536da314246eec968aea0d704d)

Diff:
---
 gcc/system.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gcc/system.h b/gcc/system.h
index cf45db3f97e..33e9d421115 100644
--- a/gcc/system.h
+++ b/gcc/system.h
@@ -1310,6 +1310,12 @@ void gcc_stablesort_r (void *, size_t, size_t, 
sort_r_cmp_fn *, void *data);
 #define NULL nullptr
 #endif
 
+/* Workaround clang on PowerPC which has vec_step as reserved keyword
+   rather than function-like macro defined in .  See PR114369.  */
+#if defined(__clang__) && defined(__powerpc__)
+#define vec_step vec_step_
+#endif
+
 /* Return true if STR string starts with PREFIX.  */
 
 inline bool


[gcc r13-8513] csky: Fix up csky_setup_incoming_varargs [PR114175]

2024-03-29 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:06f9476a60bcf2d206b7b86e68ea433954f91f20

commit r13-8513-g06f9476a60bcf2d206b7b86e68ea433954f91f20
Author: Jakub Jelinek 
Date:   Wed Mar 20 16:59:08 2024 +0100

csky: Fix up csky_setup_incoming_varargs [PR114175]

Like for x86-64, alpha or rs6000, csky seems to be affected too.

Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.

2024-03-20  Jakub Jelinek  

PR target/114175
* config/csky/csky.cc (csky_setup_incoming_varargs): Only skip
csky_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.

(cherry picked from commit 68eca9b6aefeb40bdd4c55e42528cb32d1e2935b)

Diff:
---
 gcc/config/csky/csky.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/csky/csky.cc b/gcc/config/csky/csky.cc
index ddc6954dad1..edd364c6654 100644
--- a/gcc/config/csky/csky.cc
+++ b/gcc/config/csky/csky.cc
@@ -2091,7 +2091,8 @@ csky_setup_incoming_varargs (cumulative_args_t pcum_v,
 
   cfun->machine->uses_anonymous_args = 1;
   local_cum = *pcum;
-  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl)))
+  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl))
+  || arg.type != NULL_TREE)
 csky_function_arg_advance (local_cum_v, arg);
   regs_to_push = CSKY_NPARM_REGS - local_cum.reg;
   if (regs_to_push)


[gcc r13-8511] arc: Fix up arc_setup_incoming_varargs [PR114175]

2024-03-29 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:097999338bc0e298290ec965c946f69f2237729a

commit r13-8511-g097999338bc0e298290ec965c946f69f2237729a
Author: Jakub Jelinek 
Date:   Tue Mar 19 09:49:59 2024 +0100

arc: Fix up arc_setup_incoming_varargs [PR114175]

Like for x86-64, alpha or rs6000, arc seems to be affected too.

2024-03-19  Jakub Jelinek  

PR target/114175
* config/arc/arc.cc (arc_setup_incoming_varargs): Only skip
arc_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.

(cherry picked from commit 1f257714674cd8fd69db7367aecdd09b672d1db7)

Diff:
---
 gcc/config/arc/arc.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/arc/arc.cc b/gcc/config/arc/arc.cc
index 22eb2e9cb45..50d89c24b5f 100644
--- a/gcc/config/arc/arc.cc
+++ b/gcc/config/arc/arc.cc
@@ -2450,7 +2450,8 @@ arc_setup_incoming_varargs (cumulative_args_t args_so_far,
   /* We must treat `__builtin_va_alist' as an anonymous arg.  */
 
   next_cum = *get_cumulative_args (args_so_far);
-  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl)))
+  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl))
+  || arg.type != NULL_TREE)
 arc_function_arg_advance (pack_cumulative_args (&next_cum), arg);
   first_anon_arg = next_cum;


[gcc r13-8515] ft32: Fix up ft32_setup_incoming_varargs [PR114175]

2024-03-29 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:a2565fbb722f9ea9a990286b72ae1a95145af910

commit r13-8515-ga2565fbb722f9ea9a990286b72ae1a95145af910
Author: Jakub Jelinek 
Date:   Wed Mar 20 16:59:32 2024 +0100

ft32: Fix up ft32_setup_incoming_varargs [PR114175]

Like for x86-64, alpha or rs6000, ft32 seems to be affected too.

Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.

2024-03-20  Jakub Jelinek  

PR target/114175
* config/ft32/ft32.cc (ft32_setup_incoming_varargs): Only skip
function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.

(cherry picked from commit 22612a8b5e0853c530f98fc7c0d6f6812b36518d)

Diff:
---
 gcc/config/ft32/ft32.cc | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gcc/config/ft32/ft32.cc b/gcc/config/ft32/ft32.cc
index 806ab769f79..ba92460f7be 100644
--- a/gcc/config/ft32/ft32.cc
+++ b/gcc/config/ft32/ft32.cc
@@ -635,9 +635,10 @@ ft32_setup_incoming_varargs (cumulative_args_t cum_v,
 {
   CUMULATIVE_ARGS *cum = get_cumulative_args (cum_v);
   int named_size = 0;
-  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl)))
-named_size =
-  GET_MODE_SIZE (SImode) * (*cum - FT32_R0) + GET_MODE_SIZE (arg.mode);
+  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl))
+  || arg.type != NULL_TREE)
+named_size
+  = GET_MODE_SIZE (SImode) * (*cum - FT32_R0) + GET_MODE_SIZE (arg.mode);
 
   if (named_size < 24)
 *pretend_size = 24 - named_size;


[gcc r13-8516] m32r: Fix up m32r_setup_incoming_varargs [PR114175]

2024-03-29 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:f3af5a241c820e564ef13614ae0ea7a57237bd50

commit r13-8516-gf3af5a241c820e564ef13614ae0ea7a57237bd50
Author: Jakub Jelinek 
Date:   Wed Mar 20 16:59:43 2024 +0100

m32r: Fix up m32r_setup_incoming_varargs [PR114175]

Like for x86-64, alpha or rs6000, m32r seems to be affected too.

Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.

2024-03-20  Jakub Jelinek  

PR target/114175
* config/m32r/m32r.cc (m32r_setup_incoming_varargs): Only skip
function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.

(cherry picked from commit 921eb457c5b105bcd84eaeac22067e9b03d5b9d1)

Diff:
---
 gcc/config/m32r/m32r.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/m32r/m32r.cc b/gcc/config/m32r/m32r.cc
index 5a788e29515..f4ef594499b 100644
--- a/gcc/config/m32r/m32r.cc
+++ b/gcc/config/m32r/m32r.cc
@@ -1290,7 +1290,8 @@ m32r_setup_incoming_varargs (cumulative_args_t cum,
   if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl)))
 gcc_assert (arg.mode != BLKmode);
 
-  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl)))
+  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl))
+  || arg.type != NULL_TREE)
 first_anon_arg = (ROUND_ADVANCE_CUM (*get_cumulative_args (cum),
 arg.mode, arg.type)
  + ROUND_ADVANCE_ARG (arg.mode, arg.type));


[gcc r13-8523] fold-const: Punt on MULT_EXPR in extract_muldiv MIN/MAX_EXPR case [PR111151]

2024-03-29 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:71a1ccc0378f18dfecb54bfa453c0334fbb76675

commit r13-8523-g71a1ccc0378f18dfecb54bfa453c0334fbb76675
Author: Jakub Jelinek 
Date:   Tue Mar 26 11:21:38 2024 +0100

fold-const: Punt on MULT_EXPR in extract_muldiv MIN/MAX_EXPR case [PR51]

As I've tried to explain in the comments, the extract_muldiv_1
MIN/MAX_EXPR optimization is wrong for code == MULT_EXPR.
If the multiplication is done in unsigned type or in signed
type with -fwrapv, it is fairly obvious that max (a, b) * c
in many cases isn't equivalent to max (a * c, b * c) (or min if c is
negative) due to overflows, but even for signed with undefined overflow,
the optimization could turn something without UB in it (where
say a * c invokes UB, but max (or min) picks the other operand where
b * c doesn't).
As for division/modulo, I think it is in most cases safe, except if
the problematic INT_MIN / -1 case could be triggered, but we can
just punt for MAX_EXPR because for MIN_EXPR if one operand is INT_MIN,
we'd pick that operand already.  It is just for completeness, match.pd
already has an optimization which turns x / -1 into -x, so the division
by zero is mostly theoretical.  That is also why in the testcase the
i case isn't actually miscompiled without the patch, while the c and f
cases are.

2024-03-26  Jakub Jelinek  

PR middle-end/51
* fold-const.cc (extract_muldiv_1) : Punt for
MULT_EXPR altogether, or for MAX_EXPR if c is -1.

* gcc.c-torture/execute/pr51.c: New test.

(cherry picked from commit c4f2c84e8fa369856aee76679590eb613724bfb0)

Diff:
---
 gcc/fold-const.cc  | 21 +
 gcc/testsuite/gcc.c-torture/execute/pr51.c | 21 +
 2 files changed, 42 insertions(+)

diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index a40b0d98ae7..31ae6cebbe6 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -6898,6 +6898,27 @@ extract_muldiv_1 (tree t, tree c, enum tree_code code, 
tree wide_type,
   if (TYPE_UNSIGNED (ctype) != TYPE_UNSIGNED (type))
break;
 
+  /* Punt for multiplication altogether.
+MAX (1U + INT_MAX, 1U) * 2U is not equivalent to
+MAX ((1U + INT_MAX) * 2U, 1U * 2U), the former is
+0U, the latter is 2U.
+MAX (INT_MIN / 2, 0) * -2 is not equivalent to
+MIN (INT_MIN / 2 * -2, 0 * -2), the former is
+well defined 0, the latter invokes UB.
+MAX (INT_MIN / 2, 5) * 5 is not equivalent to
+MAX (INT_MIN / 2 * 5, 5 * 5), the former is
+well defined 25, the latter invokes UB.  */
+  if (code == MULT_EXPR)
+   break;
+  /* For division/modulo, punt on c being -1 for MAX, as
+MAX (INT_MIN, 0) / -1 is not equivalent to
+MIN (INT_MIN / -1, 0 / -1), the former is well defined
+0, the latter invokes UB (or for -fwrapv is INT_MIN).
+MIN (INT_MIN, 0) / -1 already invokes UB, so the
+transformation won't make it worse.  */
+  else if (tcode == MAX_EXPR && integer_minus_onep (c))
+   break;
+
   /* MIN (a, b) / 5 -> MIN (a / 5, b / 5)  */
   sub_strict_overflow_p = false;
   if ((t1 = extract_muldiv (op0, c, code, wide_type,
diff --git a/gcc/testsuite/gcc.c-torture/execute/pr51.c 
b/gcc/testsuite/gcc.c-torture/execute/pr51.c
new file mode 100644
index 000..063617f5b9c
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr51.c
@@ -0,0 +1,21 @@
+/* PR middle-end/51 */
+
+int
+main ()
+{
+  unsigned a = (1U + __INT_MAX__) / 2U;
+  unsigned b = 1U;
+  unsigned c = (a * 2U > b * 2U ? a * 2U : b * 2U) * 2U;
+  if (c != 0U)
+__builtin_abort ();
+  int d = (-__INT_MAX__ - 1) / 2;
+  int e = 10;
+  int f = (d * 2 > e * 5 ? d * 2 : e * 5) * 6;
+  if (f != 300)
+__builtin_abort ();
+  int g = (-__INT_MAX__ - 1) / 2;
+  int h = 0;
+  int i = (g * 2 > h * 5 ? g * 2 : h * 5) / -1;
+  if (i != 0)
+__builtin_abort ();
+}


[gcc r13-8517] nds32: Fix up nds32_setup_incoming_varargs [PR114175]

2024-03-29 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:91092c30eda6777e33705a66a2c3049d4a18569d

commit r13-8517-g91092c30eda6777e33705a66a2c3049d4a18569d
Author: Jakub Jelinek 
Date:   Wed Mar 20 16:59:56 2024 +0100

nds32: Fix up nds32_setup_incoming_varargs [PR114175]

Like for x86-64, alpha or rs6000, nds32 seems to be affected too.

Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.

2024-03-20  Jakub Jelinek  

PR target/114175
* config/nds32/nds32.cc (nds32_setup_incoming_varargs): Only skip
function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.

(cherry picked from commit b22a9c7dd29a14a217de8b86d3e100e4e8b7785e)

Diff:
---
 gcc/config/nds32/nds32.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/nds32/nds32.cc b/gcc/config/nds32/nds32.cc
index 91ed91d914f..1f41bf81ad8 100644
--- a/gcc/config/nds32/nds32.cc
+++ b/gcc/config/nds32/nds32.cc
@@ -2377,7 +2377,8 @@ nds32_setup_incoming_varargs (cumulative_args_t ca,
  for varargs.  */
   total_args_regs
 = NDS32_MAX_GPR_REGS_FOR_ARGS + NDS32_GPR_ARG_FIRST_REGNUM;
-  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl)))
+  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl))
+  || arg.type != NULL_TREE)
 num_of_used_regs
   = NDS32_AVAILABLE_REGNUM_FOR_GPR_ARG (cum->gpr_offset, arg.mode, 
arg.type)
 + NDS32_NEED_N_REGS_FOR_ARG (arg.mode, arg.type);


[gcc r13-8521] predcom: Punt for steps which aren't multiples of access size [PR111683]

2024-03-29 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:4320e8483bb88b49bf251451307324c06d33c0a4

commit r13-8521-g4320e8483bb88b49bf251451307324c06d33c0a4
Author: Jakub Jelinek 
Date:   Sat Mar 23 11:17:44 2024 +0100

predcom: Punt for steps which aren't multiples of access size [PR111683]

On the following testcases, there is no overlap between data references
within a single iteration, but the data references have size which is twice
as large as the step, which means the data references overlap with the next
iteration which predcom doesn't take into account.
As discussed in the PR, even if the reference size is smaller than step,
if step isn't a multiple of the reference size, there could be overlaps with
some other iteration later on.
The initial version of the patch regressed (test still passed, but predcom
didn't optimize anymore) pr71083.c which has a packed char, short structure
and was reading/writing the short 2 bytes in there with step 3.
The following patch deals with that by retrying for COMPONENT_REFs also the
aggregate sizes etc., so that it then compares 3 bytes against step 3.
In make check-gcc/check-g++ this patch I believe affects code generation
for only the 2 new testcases according to statistics I've gathered.

2024-03-23  Jakub Jelinek  

PR middle-end/111683
* tree-predcom.cc (pcom_worker::suitable_component_p): If has_write
and comp_step is RS_NONZERO, return false if any reference in the
component doesn't have DR_STEP a multiple of access size.

* gcc.dg/pr111683-1.c: New test.
* gcc.dg/pr111683-2.c: New test.

(cherry picked from commit 8fc5593df8e0d36cc5bd8ea21097a491a634a866)

Diff:
---
 gcc/testsuite/gcc.dg/pr111683-1.c | 22 ++
 gcc/testsuite/gcc.dg/pr111683-2.c | 27 +++
 gcc/tree-predcom.cc   | 33 -
 3 files changed, 81 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/pr111683-1.c 
b/gcc/testsuite/gcc.dg/pr111683-1.c
new file mode 100644
index 000..e0dc189a91a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr111683-1.c
@@ -0,0 +1,22 @@
+/* PR middle-end/111683 */
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+long long b[6] = { 3, 4, 5, 6, 7, 8 }, c[16];
+long long d[9] = { 3, 7, 12, 18, 22, 26, 21, 15, 8 };
+typedef long long U __attribute__ ((vector_size(16), may_alias, aligned(1)));
+typedef long long V __attribute__ ((vector_size(16), may_alias));
+
+int
+main ()
+{
+  for (int f = 0; f < 6; f++)
+{
+  *(U *) &c[f] = *(U *) &c[f] + (V) { b[f], b[f] };
+  *(U *) &c[f + 2] = *(U *) &c[f + 2] + (V) { b[f], b[f] };
+}
+  for (int f = 0; f < 9; f++)
+if (c[f] != d[f])
+  __builtin_abort ();
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/pr111683-2.c 
b/gcc/testsuite/gcc.dg/pr111683-2.c
new file mode 100644
index 000..6861d157e55
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr111683-2.c
@@ -0,0 +1,27 @@
+/* PR middle-end/111683 */
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+int b[6] = { 3, 4, 5, 6, 7, 8 }, c[12];
+int d[16] = { 0, 1, 3, 6, 10, 14, 12, 9, 5, 0, 0, 0 };
+
+int
+main ()
+{
+  int i;
+  if (sizeof (int) * 2 != sizeof (long long))
+return 0;
+  for (i = 0; i < 6; i++)
+{
+  long long a;
+  __builtin_memcpy (&a, &c[i], sizeof (a));
+  a += (((long long) i) << (sizeof (int) * __CHAR_BIT__)) + i;
+  __builtin_memcpy (&c[i], &a, sizeof (a));
+  __builtin_memcpy (&a, &c[i + 2], sizeof (a));
+  a += (((long long) i) << (sizeof (int) * __CHAR_BIT__)) + i;
+  __builtin_memcpy (&c[i + 2], &a, sizeof (a));
+}
+  if (__builtin_memcmp (&c[0], &d[0], sizeof (c)))
+__builtin_abort ();
+  return 0;
+}
diff --git a/gcc/tree-predcom.cc b/gcc/tree-predcom.cc
index f85588c722f..78ff9fd0911 100644
--- a/gcc/tree-predcom.cc
+++ b/gcc/tree-predcom.cc
@@ -1102,8 +1102,39 @@ pcom_worker::suitable_component_p (struct component 
*comp)
   gcc_assert (ok);
   first->offset = 0;
 
-  for (i = 1; comp->refs.iterate (i, &a); i++)
+  FOR_EACH_VEC_ELT (comp->refs, i, a)
 {
+  if (has_write && comp->comp_step == RS_NONZERO)
+   {
+ /* Punt for non-invariant references where step isn't a multiple
+of reference size.  If step is smaller than reference size,
+it overlaps the access in next iteration, if step is larger,
+but not multiple of the access size, there could be overlap
+in some later iteration.  There might be more latent issues
+about this in predcom or data reference analysis.  If the
+reference is a COMPONENT_REF, also check if step isn't a
+multiple of the containg aggregate size.  See PR111683.  */
+ tree ref = DR_REF (a->ref);
+ tree step = DR_STEP (a->ref);
+ if (TREE_CODE (ref) == COMPONENT_REF
+ && DECL_BIT_FIELD (TREE_OPERAND (ref,

[gcc r13-8518] nios2: Fix up nios2_setup_incoming_varargs [PR114175]

2024-03-29 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:02f66c40fb626656b924c1c7af3b5ededf8963e5

commit r13-8518-g02f66c40fb626656b924c1c7af3b5ededf8963e5
Author: Jakub Jelinek 
Date:   Wed Mar 20 17:00:08 2024 +0100

nios2: Fix up nios2_setup_incoming_varargs [PR114175]

Like for x86-64, alpha or rs6000, nios2 seems to be affected too.

Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.

2024-03-20  Jakub Jelinek  

PR target/114175
* config/nios2/nios2.cc (nios2_setup_incoming_varargs): Only skip
nios2_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.

(cherry picked from commit 4c9d2810908004b7e04599b426aca5ee1bd16735)

Diff:
---
 gcc/config/nios2/nios2.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/nios2/nios2.cc b/gcc/config/nios2/nios2.cc
index 936eb34ace4..916324c019b 100644
--- a/gcc/config/nios2/nios2.cc
+++ b/gcc/config/nios2/nios2.cc
@@ -3524,7 +3524,8 @@ nios2_setup_incoming_varargs (cumulative_args_t cum_v,
 
   cfun->machine->uses_anonymous_args = 1;
   local_cum = *cum;
-  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl)))
+  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl))
+  || arg.type != NULL_TREE)
 nios2_function_arg_advance (local_cum_v, arg);
 
   regs_to_push = NUM_ARG_REGS - local_cum.regs_used;


[gcc r13-8522] tsan: Don't instrument non-generic AS accesses [PR111736]

2024-03-29 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:85b2b99e56b6f54b3feb530b2492955486e3d389

commit r13-8522-g85b2b99e56b6f54b3feb530b2492955486e3d389
Author: Jakub Jelinek 
Date:   Tue Mar 26 11:06:15 2024 +0100

tsan: Don't instrument non-generic AS accesses [PR111736]

Similar to the asan and ubsan changes, we shouldn't instrument non-generic
address space accesses with tsan, because we just have library functions
which take address of the objects as generic address space pointers, so they
can't handle anything else.

2024-03-26  Jakub Jelinek  

PR sanitizer/111736
* tsan.cc (instrument_expr): Punt on non-generic address space
accesses.

* gcc.dg/tsan/pr111736.c: New test.

(cherry picked from commit 471967ab8b4c49338ba77defbe24b06cc51c0093)

Diff:
---
 gcc/testsuite/gcc.dg/tsan/pr111736.c | 17 +
 gcc/tsan.cc  |  3 +++
 2 files changed, 20 insertions(+)

diff --git a/gcc/testsuite/gcc.dg/tsan/pr111736.c 
b/gcc/testsuite/gcc.dg/tsan/pr111736.c
new file mode 100644
index 000..34ab88b3d4f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tsan/pr111736.c
@@ -0,0 +1,17 @@
+/* PR sanitizer/111736 */
+/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
+/* { dg-options "-fsanitize=thread -fdump-tree-optimized -ffat-lto-objects" } 
*/
+/* { dg-final { scan-tree-dump-not "__tsan_read" "optimized" } } */
+/* { dg-final { scan-tree-dump-not "__tsan_write" "optimized" } } */
+
+#ifdef __x86_64__
+#define SEG __seg_fs
+#else
+#define SEG __seg_gs
+#endif
+
+void
+foo (int SEG *p, int SEG *q)
+{
+  *q = *p;
+}
diff --git a/gcc/tsan.cc b/gcc/tsan.cc
index 23f4d9e7655..0eab6c8a2dd 100644
--- a/gcc/tsan.cc
+++ b/gcc/tsan.cc
@@ -139,6 +139,9 @@ instrument_expr (gimple_stmt_iterator gsi, tree expr, bool 
is_write)
   if (TREE_READONLY (base) || (VAR_P (base) && DECL_HARD_REGISTER (base)))
 return false;
 
+  if (!ADDR_SPACE_GENERIC_P (TYPE_ADDR_SPACE (TREE_TYPE (base
+return false;
+
   stmt = gsi_stmt (gsi);
   loc = gimple_location (stmt);
   rhs = is_vptr_store (stmt, expr, is_write);


[gcc r13-8514] epiphany: Fix up epiphany_setup_incoming_varargs [PR114175]

2024-03-29 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:fce980ba3802e1adc68cb34ae81d17bc8c9d13b9

commit r13-8514-gfce980ba3802e1adc68cb34ae81d17bc8c9d13b9
Author: Jakub Jelinek 
Date:   Wed Mar 20 16:59:21 2024 +0100

epiphany: Fix up epiphany_setup_incoming_varargs [PR114175]

Like for x86-64, alpha or rs6000, epiphany seems to be affected too.

Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.

2024-03-20  Jakub Jelinek  

PR target/114175
* config/epiphany/epiphany.cc (epiphany_setup_incoming_varargs): 
Only
skip function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.

(cherry picked from commit b089ceb365e5132e4b2a8acfb18127bbee2d0d00)

Diff:
---
 gcc/config/epiphany/epiphany.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/epiphany/epiphany.cc b/gcc/config/epiphany/epiphany.cc
index fdd4df71456..ab707d9a9f7 100644
--- a/gcc/config/epiphany/epiphany.cc
+++ b/gcc/config/epiphany/epiphany.cc
@@ -731,7 +731,8 @@ epiphany_setup_incoming_varargs (cumulative_args_t cum,
 gcc_assert (arg.mode != BLKmode);
 
   next_cum = *get_cumulative_args (cum);
-  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl)))
+  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl))
+  || arg.type != NULL_TREE)
 next_cum = (ROUND_ADVANCE_CUM (next_cum, arg.mode, arg.type)
+ ROUND_ADVANCE_ARG (arg.mode, arg.type));
   first_anon_arg = next_cum;


[gcc r13-8524] testsuite: Add testcase for already fixed PR [PR109925]

2024-03-29 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:43022dd24e82a8625895e35da2b7e5a45f3b7483

commit r13-8524-g43022dd24e82a8625895e35da2b7e5a45f3b7483
Author: Jakub Jelinek 
Date:   Thu Mar 28 11:58:26 2024 +0100

testsuite: Add testcase for already fixed PR [PR109925]

This testcase was made latent by r14-4089 and got fixed both
on the trunk and 13 branch with PR113372 fix.

Adding testcase to the testsuite and will close the PR as a dup.

2024-03-28  Jakub Jelinek  

PR tree-optimization/109925
* gcc.c-torture/execute/pr109925.c: New test.

(cherry picked from commit 7942558f27038461f948ca10140a156ae678cdf8)

Diff:
---
 gcc/testsuite/gcc.c-torture/execute/pr109925.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/gcc/testsuite/gcc.c-torture/execute/pr109925.c 
b/gcc/testsuite/gcc.c-torture/execute/pr109925.c
new file mode 100644
index 000..929673b6b63
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr109925.c
@@ -0,0 +1,30 @@
+/* PR tree-optimization/109925 */
+
+int a, c, f;
+
+int
+main ()
+{
+  int g[2];
+  for (c = 0; c < 2; c++)
+{
+  {
+   char h[20], *b = h;
+   int d = 48, e = 0;
+   while (d && e < 5)
+ b[e++] = d /= 10;
+   f = e;
+  }
+  g[f - 2 + c] = 0;
+}
+  for (;;)
+{
+  for (; a <= 4; a++)
+   if (g[0])
+ break;
+  break;
+}
+  if (a != 5)
+__builtin_abort ();
+  return 0;
+}


[gcc r13-8525] profile-count: Avoid overflows into uninitialized [PR112303]

2024-03-29 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:b7b4ef2ff20c5023a41ed663dd8f4724b4ff0f9c

commit r13-8525-gb7b4ef2ff20c5023a41ed663dd8f4724b4ff0f9c
Author: Jakub Jelinek 
Date:   Thu Mar 28 15:00:44 2024 +0100

profile-count: Avoid overflows into uninitialized [PR112303]

The testcase in the patch ICEs with
--- gcc/tree-scalar-evolution.cc
+++ gcc/tree-scalar-evolution.cc
@@ -3881,7 +3881,7 @@ final_value_replacement_loop (class loop *loop)

   /* Propagate constants immediately, but leave an unused 
initialization
 around to avoid invalidating the SCEV cache.  */
-  if (CONSTANT_CLASS_P (def) && !SSA_NAME_OCCURS_IN_ABNORMAL_PHI 
(rslt))
+  if (0 && CONSTANT_CLASS_P (def) && !SSA_NAME_OCCURS_IN_ABNORMAL_PHI 
(rslt))
replace_uses_by (rslt, def);

   /* Create the replacement statements.  */
(the addition of the above made the ICE latent), because profile_count
addition doesn't check for overflows and if unlucky, we can even overflow
into the uninitialized value.
Getting really huge profile counts is very easy even when not using
recursive inlining in loops, e.g.
__attribute__((noipa)) void
bar (void)
{
  __builtin_exit (0);
}

__attribute__((noipa)) void
foo (void)
{
  for (int i = 0; i < 1000; ++i)
  for (int j = 0; j < 1000; ++j)
  for (int k = 0; k < 1000; ++k)
  for (int l = 0; l < 1000; ++l)
  for (int m = 0; m < 1000; ++m)
  for (int n = 0; n < 1000; ++n)
  for (int o = 0; o < 1000; ++o)
  for (int p = 0; p < 1000; ++p)
  for (int q = 0; q < 1000; ++q)
  for (int r = 0; r < 1000; ++r)
  for (int s = 0; s < 1000; ++s)
  for (int t = 0; t < 1000; ++t)
  for (int u = 0; u < 1000; ++u)
  for (int v = 0; v < 1000; ++v)
  for (int w = 0; w < 1000; ++w)
  for (int x = 0; x < 1000; ++x)
  for (int y = 0; y < 1000; ++y)
  for (int z = 0; z < 1000; ++z)
  for (int a = 0; a < 1000; ++a)
  for (int b = 0; b < 1000; ++b)
bar ();
}

int
main ()
{
  foo ();
}
reaches the maximum count already on the 11th loop.

Some other methods of profile_count like apply_scale already
do use MIN (val, max_count) before assignment to m_val, this patch
just extends that to operator{+,+=} methods.
Furthermore, one overload of apply_probability wasn't using
safe_scale_64bit and so could very easily overflow as well
- prob is required to be [0, 1] and if m_val is near the max_count,
it can overflow even with multiplications by 8.

2024-03-28  Jakub Jelinek  

PR tree-optimization/112303
* profile-count.h (profile_count::operator+): Perform
addition in uint64_t variable and set m_val to MIN of that
val and max_count.
(profile_count::operator+=): Likewise.
(profile_count::operator-=): Formatting fix.
(profile_count::apply_probability): Use safe_scale_64bit
even in the int overload.

* gcc.c-torture/compile/pr112303.c: New test.

(cherry picked from commit d5a3b4afcdf4d517334a2717dbb65ae0d2c26507)

Diff:
---
 gcc/profile-count.h| 12 
 gcc/testsuite/gcc.c-torture/compile/pr112303.c | 25 +
 2 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/gcc/profile-count.h b/gcc/profile-count.h
index 0739e26fe74..78185833723 100644
--- a/gcc/profile-count.h
+++ b/gcc/profile-count.h
@@ -876,7 +876,8 @@ public:
 
   profile_count ret;
   gcc_checking_assert (compatible_p (other));
-  ret.m_val = m_val + other.m_val;
+  uint64_t ret_val = m_val + other.m_val;
+  ret.m_val = MIN (ret_val, max_count);
   ret.m_quality = MIN (m_quality, other.m_quality);
   return ret;
 }
@@ -895,7 +896,8 @@ public:
   else
{
   gcc_checking_assert (compatible_p (other));
- m_val += other.m_val;
+ uint64_t ret_val = m_val + other.m_val;
+ m_val = MIN (ret_val, max_count);
  m_quality = MIN (m_quality, other.m_quality);
}
   return *this;
@@ -923,7 +925,7 @@ public:
   else
{
   gcc_checking_assert (compatible_p (other));
- m_val = m_val >= other.m_val ? m_val - other.m_val: 0;
+ m_val = m_val >= other.m_val ? m_val - other.m_val : 0;
  m_quality = MIN (m_quality, other.m_quality);
}
   return *this;
@@ -1093,7 +1095,9 @@ public:
   if (!initialized_p ())
return uninitialized ();
   profile_count ret;
-  ret.m_val = RDIV (m_val * prob, REG_BR_PROB_BASE);
+  uint64_t tmp;
+  safe_scale_64bit (m_val, prob, REG_BR_PROB_BASE, &tmp);
+  ret.m_val = tmp;
   ret.m_quality = MIN (m_quality, ADJUSTED);
   return ret;
 }
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr112303.c 
b/gcc/testsuite/gcc.c-torture/compile/

[gcc r13-8519] visium: Fix up visium_setup_incoming_varargs [PR114175]

2024-03-29 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:01397f789866198ad4fae3893d8f6b0a1d96cd96

commit r13-8519-g01397f789866198ad4fae3893d8f6b0a1d96cd96
Author: Jakub Jelinek 
Date:   Wed Mar 20 17:00:51 2024 +0100

visium: Fix up visium_setup_incoming_varargs [PR114175]

Like for x86-64, alpha or rs6000, visium seems to be affected too.

Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.

2024-03-20  Jakub Jelinek  

PR target/114175
* config/visium/visium.cc (visium_setup_incoming_varargs): Only skip
TARGET_FUNCTION_ARG_ADVANCE for TYPE_NO_NAMED_ARGS_STDARG_P 
functions
if arg.type is NULL.

(cherry picked from commit b05ee9b69e4644cefbb94a768c4ea302fd44b934)

Diff:
---
 gcc/config/visium/visium.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/visium/visium.cc b/gcc/config/visium/visium.cc
index ec4c2e9ae5c..1f9ce9b9fcd 100644
--- a/gcc/config/visium/visium.cc
+++ b/gcc/config/visium/visium.cc
@@ -1481,7 +1481,8 @@ visium_setup_incoming_varargs (cumulative_args_t pcum_v,
   /* The caller has advanced ARGS_SO_FAR up to, but not beyond, the last named
  argument.  Advance a local copy of ARGS_SO_FAR past the last "real" named
  argument, to find out how many registers are left over.  */
-  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl)))
+  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl))
+  || arg.type != NULL_TREE)
 TARGET_FUNCTION_ARG_ADVANCE (local_args_so_far, arg);
 
   /* Find how many registers we need to save.  */


[gcc r13-8520] ubsan: Don't -fsanitize=null instrument __seg_fs/gs pointers [PR111736]

2024-03-29 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:05de873353ab9e94cda2b9e9561a82ca4e061c3f

commit r13-8520-g05de873353ab9e94cda2b9e9561a82ca4e061c3f
Author: Jakub Jelinek 
Date:   Fri Mar 22 09:23:44 2024 +0100

ubsan: Don't -fsanitize=null instrument __seg_fs/gs pointers [PR111736]

On x86 and avr some address spaces allow 0 pointers (on avr actually
even generic as, but libsanitizer isn't ported to it and
I'm not convinced we should completely kill -fsanitize=null in that
case).
The following patch makes sure those aren't diagnosed for -fsanitize=null,
though they are still sanitized for -fsanitize=alignment.

2024-03-22  Jakub Jelinek  

PR sanitizer/111736
* ubsan.cc (ubsan_expand_null_ifn, instrument_mem_ref): Avoid
SANITIZE_NULL instrumentation for non-generic address spaces
for which targetm.addr_space.zero_address_valid (as) is true.

* gcc.dg/ubsan/pr111736.c: New test.

(cherry picked from commit ddd4a3ca87410886b039cc225907b4f6e650082e)

Diff:
---
 gcc/testsuite/gcc.dg/ubsan/pr111736.c | 23 +++
 gcc/ubsan.cc  | 19 +--
 2 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/ubsan/pr111736.c 
b/gcc/testsuite/gcc.dg/ubsan/pr111736.c
new file mode 100644
index 000..359b31828f0
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ubsan/pr111736.c
@@ -0,0 +1,23 @@
+/* PR sanitizer/111736 */
+/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
+/* { dg-options "-fsanitize=null,alignment -fdump-tree-optimized 
-ffat-lto-objects" } */
+/* { dg-final { scan-tree-dump-times "__ubsan_handle_type_mismatch" 1 
"optimized" } } */
+/* { dg-final { scan-tree-dump-not "p_\[0-9]*.D. \[=!]= 0" "optimized" } } */
+
+#ifdef __x86_64__
+#define SEG __seg_fs
+#else
+#define SEG __seg_gs
+#endif
+
+int
+foo (int SEG *p, int *q)
+{
+  return *p;
+}
+
+__attribute__((no_sanitize("alignment"))) int
+bar (int SEG *p, int *q)
+{
+  return *p;
+}
diff --git a/gcc/ubsan.cc b/gcc/ubsan.cc
index a4193450b4c..93475786c1e 100644
--- a/gcc/ubsan.cc
+++ b/gcc/ubsan.cc
@@ -49,6 +49,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-cfg.h"
 #include "gimple-fold.h"
 #include "varasm.h"
+#include "target.h"
 
 /* Map from a tree to a VAR_DECL tree.  */
 
@@ -801,6 +802,13 @@ ubsan_expand_null_ifn (gimple_stmt_iterator *gsip)
}
 }
   check_null = sanitize_flags_p (SANITIZE_NULL);
+  if (check_null && POINTER_TYPE_P (TREE_TYPE (ptr)))
+{
+  addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (ptr)));
+  if (!ADDR_SPACE_GENERIC_P (as)
+ && targetm.addr_space.zero_address_valid (as))
+   check_null = false;
+}
 
   if (check_align == NULL_TREE && !check_null)
 {
@@ -1390,8 +1398,15 @@ instrument_mem_ref (tree mem, tree base, 
gimple_stmt_iterator *iter,
   if (align <= 1)
align = 0;
 }
-  if (align == 0 && !sanitize_flags_p (SANITIZE_NULL))
-return;
+  if (align == 0)
+{
+  if (!sanitize_flags_p (SANITIZE_NULL))
+   return;
+  addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (base));
+  if (!ADDR_SPACE_GENERIC_P (as)
+ && targetm.addr_space.zero_address_valid (as))
+   return;
+}
   tree t = TREE_OPERAND (base, 0);
   if (!POINTER_TYPE_P (TREE_TYPE (t)))
 return;


[gcc r13-8526] LoongArch: Fix C23 (...) functions returning large aggregates [PR114175]

2024-03-29 Thread Xi Ruoyao via Gcc-cvs
https://gcc.gnu.org/g:b73a6a20113ca607cf3073c751698b12aa167881

commit r13-8526-gb73a6a20113ca607cf3073c751698b12aa167881
Author: Xi Ruoyao 
Date:   Mon Mar 18 17:18:34 2024 +0800

LoongArch: Fix C23 (...) functions returning large aggregates [PR114175]

We were assuming TYPE_NO_NAMED_ARGS_STDARG_P don't have any named
arguments and there is nothing to advance, but that is not the case
for (...) functions returning by hidden reference which have one such
artificial argument.  This is causing gcc.dg/c23-stdarg-6.c and
gcc.dg/c23-stdarg-8.c to fail.

Fix the issue by checking if arg.type is NULL, as r14-9503 explains.

gcc/ChangeLog:

PR target/114175
* config/loongarch/loongarch.cc
(loongarch_setup_incoming_varargs): Only skip
loongarch_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P
functions if arg.type is NULL.

(cherry picked from commit c1fd4589c2bf9fd8409d51b94df219cb75107762)

Diff:
---
 gcc/config/loongarch/loongarch.cc | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index e78b81cd8fc..d2c26407447 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -760,7 +760,13 @@ loongarch_setup_incoming_varargs (cumulative_args_t cum,
  argument.  Advance a local copy of CUM past the last "real" named
  argument, to find out how many registers are left over.  */
   local_cum = *get_cumulative_args (cum);
-  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl)))
+
+  /* For a C23 variadic function w/o any named argument, and w/o an
+ artifical argument for large return value, skip advancing args.
+ There is such an artifical argument iff. arg.type is non-NULL
+ (PR 114175).  */
+  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl))
+  || arg.type != NULL_TREE)
 loongarch_function_arg_advance (pack_cumulative_args (&local_cum), arg);
 
   /* Found out how many registers we need to save.  */


[gcc r13-8527] mips: Fix C23 (...) functions returning large aggregates [PR114175]

2024-03-29 Thread Xi Ruoyao via Gcc-cvs
https://gcc.gnu.org/g:1ab646f678a9d47b338424ed69e9ae5d774b06ae

commit r13-8527-g1ab646f678a9d47b338424ed69e9ae5d774b06ae
Author: Xi Ruoyao 
Date:   Wed Mar 20 15:09:21 2024 +0800

mips: Fix C23 (...) functions returning large aggregates [PR114175]

We were assuming TYPE_NO_NAMED_ARGS_STDARG_P don't have any named
arguments and there is nothing to advance, but that is not the case
for (...) functions returning by hidden reference which have one such
artificial argument.  This is causing gcc.dg/c23-stdarg-{6,8,9}.c to
fail.

Fix the issue by checking if arg.type is NULL, as r14-9503 explains.

gcc/ChangeLog:

PR target/114175
* config/mips/mips.cc (mips_setup_incoming_varargs): Only skip
mips_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P
functions if arg.type is NULL.

(cherry picked from commit 6fc84f680d098f82c1c43435fdb206099f0df4df)

Diff:
---
 gcc/config/mips/mips.cc | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
index ca822758b41..8e3dc313cb3 100644
--- a/gcc/config/mips/mips.cc
+++ b/gcc/config/mips/mips.cc
@@ -6684,7 +6684,13 @@ mips_setup_incoming_varargs (cumulative_args_t cum,
  argument.  Advance a local copy of CUM past the last "real" named
  argument, to find out how many registers are left over.  */
   local_cum = *get_cumulative_args (cum);
-  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl)))
+
+  /* For a C23 variadic function w/o any named argument, and w/o an
+ artifical argument for large return value, skip advancing args.
+ There is such an artifical argument iff. arg.type is non-NULL
+ (PR 114175).  */
+  if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl))
+  || arg.type != NULL_TREE)
 mips_function_arg_advance (pack_cumulative_args (&local_cum), arg);
 
   /* Found out how many registers we need to save.  */