Re: [PATCH] Add %[zt][diox] support to pretty-print

2024-05-22 Thread Jakub Jelinek
On Wed, May 22, 2024 at 05:05:30PM +0800, YunQiang Su wrote:
> > --- gcc/gcc.cc.jj   2024-02-09 14:54:09.141489744 +0100
> > +++ gcc/gcc.cc  2024-02-09 22:04:37.655678742 +0100
> > @@ -2410,8 +2410,7 @@ read_specs (const char *filename, bool m
> >   if (*p1++ != '<' || p[-2] != '>')
> > fatal_error (input_location,
> >  "specs %%include syntax malformed after "
> > -"%ld characters",
> > -(long) (p1 - buffer + 1));
> > +"%td characters", p1 - buffer + 1);
> >
> 
> Should we use %td later for gcc itself? Since we may use older
> compiler to build gcc.
> My major workstation is Debian Bookworm, which has GCC 12, and then I
> get some warnings:

That is fine and expected.  During stage1 such warnings are intentionally
not fatal, only in stage2+ when we know it is the same version of gcc
we want those can be fatal.
Otherwise we could never add any new modifies...

Jakub



Re: [PATCH] Don't simplify NAN/INF or out-of-range constant for FIX/UNSIGNED_FIX.

2024-05-22 Thread Jakub Jelinek
On Wed, May 22, 2024 at 09:46:41AM +0200, Richard Biener wrote:
> On Wed, May 22, 2024 at 3:58 AM liuhongt  wrote:
> >
> > According to IEEE standard, for conversions from floating point to
> > integer. When a NaN or infinite operand cannot be represented in the
> > destination format and this cannot otherwise be indicated, the invalid
> > operation exception shall be signaled. When a numeric operand would
> > convert to an integer outside the range of the destination format, the
> > invalid operation exception shall be signaled if this situation cannot
> > otherwise be indicated.
> >
> > The patch prevent simplication of the conversion from floating point
> > to integer for NAN/INF/out-of-range constant when flag_trapping_math.
> >
> > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}
> > Ok for trunk?
> 
> OK if there are no further comments today.

As I wrote in the PR, I don't think this is the right fix for the PR,
the simplify-rtx.cc change is the right thing to do, the C standard
in F.4 says that the out of range conversions to integers should raise
exceptions, but still says that the resulting value in those cases is
unspecified.
So, for the C part we should verify that with -ftrapping-math we don't
constant fold it and cover it both by pure C and perhaps backend specific
testcases which just search asm for the conversion instructions
or even runtime test which tests that the exceptions are triggered,
verify that we don't fold it either during GIMPLE opts or RTL opts
(dunno whether they can be folded in e.g. C constant initializers or not).

And then on the backend side, it should stop using FIX/UNSIGNED_FIX RTLs
in patterns which are used for the intrinsics (and keep using them in
patterns used for C scalar/vector conversions), because even with
-fno-trapping-math the intrinsics should have the documented behavior,
particular result value, while in C they are clearly unspecified and
FIX/UNSIGNED_FIX folding even with the patch chooses some particular values
which don't match those (sure, they are like that because of Java, but am
not sure it is the right time to change what we do in those cases say
by providing a target hook to pick a different value).

The provided testcase tests the values though, so I think is inappropriate
for this patch.

Jakub



[gcc r13-8791] ubsan: Use right address space for MEM_REF created for bool/enum sanitization [PR115172]

2024-05-22 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:35ac28b9c26debcc8ec8b247d75d4d271de72189

commit r13-8791-g35ac28b9c26debcc8ec8b247d75d4d271de72189
Author: Jakub Jelinek 
Date:   Wed May 22 09:12:28 2024 +0200

ubsan: Use right address space for MEM_REF created for bool/enum 
sanitization [PR115172]

The following testcase is miscompiled, because -fsanitize=bool,enum
creates a MEM_REF without propagating there address space qualifiers,
so what should be normally loaded using say %gs:/%fs: segment prefix
isn't.  Together with asan it then causes that load to be sanitized.

2024-05-22  Jakub Jelinek  

PR sanitizer/115172
* ubsan.cc (instrument_bool_enum_load): If rhs is not in generic
address space, use qualified version of utype with the right
address space.  Formatting fix.

* gcc.dg/asan/pr115172.c: New test.

(cherry picked from commit d3c506eff54fcbac389a529c2e98da108a410b7f)

Diff:
---
 gcc/testsuite/gcc.dg/asan/pr115172.c | 20 
 gcc/ubsan.cc |  6 +-
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/asan/pr115172.c 
b/gcc/testsuite/gcc.dg/asan/pr115172.c
new file mode 100644
index 000..8707e615733
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/asan/pr115172.c
@@ -0,0 +1,20 @@
+/* PR sanitizer/115172 */
+/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
+/* { dg-options "-O2 -fsanitize=address,bool -ffat-lto-objects 
-fdump-tree-asan1" } */
+/* { dg-final { scan-tree-dump-not "\.ASAN_CHECK " "asan1" } } */
+
+#ifdef __x86_64__
+#define SEG __seg_gs
+#else
+#define SEG __seg_fs
+#endif
+
+extern struct S { _Bool b; } s;
+void bar (void);
+
+void
+foo (void)
+{
+  if (*(volatile _Bool SEG *) (__UINTPTR_TYPE__) )
+bar ();
+}
diff --git a/gcc/ubsan.cc b/gcc/ubsan.cc
index 93475786c1e..22d3330ca41 100644
--- a/gcc/ubsan.cc
+++ b/gcc/ubsan.cc
@@ -1719,13 +1719,17 @@ instrument_bool_enum_load (gimple_stmt_iterator *gsi)
   || TREE_CODE (gimple_assign_lhs (stmt)) != SSA_NAME)
 return;
 
+  addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (rhs));
+  if (as != TYPE_ADDR_SPACE (utype))
+utype = build_qualified_type (utype, TYPE_QUALS (utype)
+| ENCODE_QUAL_ADDR_SPACE (as));
   bool ends_bb = stmt_ends_bb_p (stmt);
   location_t loc = gimple_location (stmt);
   tree lhs = gimple_assign_lhs (stmt);
   tree ptype = build_pointer_type (TREE_TYPE (rhs));
   tree atype = reference_alias_ptr_type (rhs);
   gimple *g = gimple_build_assign (make_ssa_name (ptype),
- build_fold_addr_expr (rhs));
+  build_fold_addr_expr (rhs));
   gimple_set_location (g, loc);
   gsi_insert_before (gsi, g, GSI_SAME_STMT);
   tree mem = build2 (MEM_REF, utype, gimple_assign_lhs (g),


[gcc r13-8792] strlen: Fix up !si->full_string_p handling in count_nonzero_bytes_addr [PR115152]

2024-05-22 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:53bc98f5355ada17d1629a2d0e96aebd397780c6

commit r13-8792-g53bc98f5355ada17d1629a2d0e96aebd397780c6
Author: Jakub Jelinek 
Date:   Wed May 22 09:13:50 2024 +0200

strlen: Fix up !si->full_string_p handling in count_nonzero_bytes_addr 
[PR115152]

The following testcase is miscompiled because
strlen_pass::count_nonzero_bytes_addr doesn't handle correctly
the !si->full_string_p case.
If si->full_string_p, it correctly computes minlen and maxlen as
minimum and maximum length of the '\0' terminated stgring and
clears *nulterm (ie. makes sure !full_string_p in the ultimate
caller) if minlen is equal or larger than nbytes and so
'\0' isn't guaranteed to be among those bytes.
But in the !si->full_string_p case, all we know is that there
are [minlen,maxlen] non-zero bytes followed by unknown bytes,
so effectively the maxlen is infinite (but caller cares about only
the first nbytes bytes) and furthermore, we never know if there is
any '\0' char among those, so *nulterm needs to be always cleared.

2024-05-22  Jakub Jelinek  

PR tree-optimization/115152
* tree-ssa-strlen.cc (strlen_pass::count_nonzero_bytes_addr): If
!si->full_string_p, clear *nulterm and set maxlen to nbytes.

* gcc.dg/pr115152.c: New test.

(cherry picked from commit dbc9b45a3c2468ad134b3a9bd4961f7ae6bc1e67)

Diff:
---
 gcc/testsuite/gcc.dg/pr115152.c | 17 +
 gcc/tree-ssa-strlen.cc  |  5 -
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/pr115152.c b/gcc/testsuite/gcc.dg/pr115152.c
new file mode 100644
index 000..a44654e2015
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr115152.c
@@ -0,0 +1,17 @@
+/* PR tree-optimization/115152 */
+/* { dg-do run } */
+/* { dg-options "-O3 -fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" 
} */
+
+int a, b, c, d;
+signed char e[1] = { 1 };
+
+int
+main ()
+{
+  for (a = 0; a < 3; a++)
+for (b = 0; b < 2; b++)
+  c = e[0] = e[0] ^ d;
+  if (!c)
+__builtin_abort ();
+  return 0;
+}
diff --git a/gcc/tree-ssa-strlen.cc b/gcc/tree-ssa-strlen.cc
index 3b10c7b4cb2..b911067d009 100644
--- a/gcc/tree-ssa-strlen.cc
+++ b/gcc/tree-ssa-strlen.cc
@@ -4836,7 +4836,7 @@ strlen_pass::count_nonzero_bytes_addr (tree exp, tree 
vuse, gimple *stmt,
   if (maxlen + 1 < nbytes)
return false;
 
-  if (nbytes <= minlen)
+  if (nbytes <= minlen || !si->full_string_p)
*nulterm = false;
 
   if (nbytes < minlen)
@@ -4846,6 +4846,9 @@ strlen_pass::count_nonzero_bytes_addr (tree exp, tree 
vuse, gimple *stmt,
maxlen = nbytes;
}
 
+  if (!si->full_string_p)
+   maxlen = nbytes;
+
   if (minlen < lenrange[0])
lenrange[0] = minlen;
   if (lenrange[1] < maxlen)


[gcc r14-10231] strlen: Fix up !si->full_string_p handling in count_nonzero_bytes_addr [PR115152]

2024-05-22 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:fc9fb69ad624fd4cc89ff31ad0a7b8d88481c1f7

commit r14-10231-gfc9fb69ad624fd4cc89ff31ad0a7b8d88481c1f7
Author: Jakub Jelinek 
Date:   Wed May 22 09:13:50 2024 +0200

strlen: Fix up !si->full_string_p handling in count_nonzero_bytes_addr 
[PR115152]

The following testcase is miscompiled because
strlen_pass::count_nonzero_bytes_addr doesn't handle correctly
the !si->full_string_p case.
If si->full_string_p, it correctly computes minlen and maxlen as
minimum and maximum length of the '\0' terminated stgring and
clears *nulterm (ie. makes sure !full_string_p in the ultimate
caller) if minlen is equal or larger than nbytes and so
'\0' isn't guaranteed to be among those bytes.
But in the !si->full_string_p case, all we know is that there
are [minlen,maxlen] non-zero bytes followed by unknown bytes,
so effectively the maxlen is infinite (but caller cares about only
the first nbytes bytes) and furthermore, we never know if there is
any '\0' char among those, so *nulterm needs to be always cleared.

2024-05-22  Jakub Jelinek  

PR tree-optimization/115152
* tree-ssa-strlen.cc (strlen_pass::count_nonzero_bytes_addr): If
!si->full_string_p, clear *nulterm and set maxlen to nbytes.

* gcc.dg/pr115152.c: New test.

(cherry picked from commit dbc9b45a3c2468ad134b3a9bd4961f7ae6bc1e67)

Diff:
---
 gcc/testsuite/gcc.dg/pr115152.c | 17 +
 gcc/tree-ssa-strlen.cc  |  5 -
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/pr115152.c b/gcc/testsuite/gcc.dg/pr115152.c
new file mode 100644
index 000..a44654e2015
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr115152.c
@@ -0,0 +1,17 @@
+/* PR tree-optimization/115152 */
+/* { dg-do run } */
+/* { dg-options "-O3 -fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" 
} */
+
+int a, b, c, d;
+signed char e[1] = { 1 };
+
+int
+main ()
+{
+  for (a = 0; a < 3; a++)
+for (b = 0; b < 2; b++)
+  c = e[0] = e[0] ^ d;
+  if (!c)
+__builtin_abort ();
+  return 0;
+}
diff --git a/gcc/tree-ssa-strlen.cc b/gcc/tree-ssa-strlen.cc
index e09c9cc081f..fcd40ded449 100644
--- a/gcc/tree-ssa-strlen.cc
+++ b/gcc/tree-ssa-strlen.cc
@@ -4829,7 +4829,7 @@ strlen_pass::count_nonzero_bytes_addr (tree exp, tree 
vuse, gimple *stmt,
   if (maxlen + 1 < nbytes)
return false;
 
-  if (nbytes <= minlen)
+  if (nbytes <= minlen || !si->full_string_p)
*nulterm = false;
 
   if (nbytes < minlen)
@@ -4839,6 +4839,9 @@ strlen_pass::count_nonzero_bytes_addr (tree exp, tree 
vuse, gimple *stmt,
maxlen = nbytes;
}
 
+  if (!si->full_string_p)
+   maxlen = nbytes;
+
   if (minlen < lenrange[0])
lenrange[0] = minlen;
   if (lenrange[1] < maxlen)


[gcc r14-10230] ubsan: Use right address space for MEM_REF created for bool/enum sanitization [PR115172]

2024-05-22 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:d224c7d8d8b49daab54a977a4f2217423d3d12a0

commit r14-10230-gd224c7d8d8b49daab54a977a4f2217423d3d12a0
Author: Jakub Jelinek 
Date:   Wed May 22 09:12:28 2024 +0200

ubsan: Use right address space for MEM_REF created for bool/enum 
sanitization [PR115172]

The following testcase is miscompiled, because -fsanitize=bool,enum
creates a MEM_REF without propagating there address space qualifiers,
so what should be normally loaded using say %gs:/%fs: segment prefix
isn't.  Together with asan it then causes that load to be sanitized.

2024-05-22  Jakub Jelinek  

PR sanitizer/115172
* ubsan.cc (instrument_bool_enum_load): If rhs is not in generic
address space, use qualified version of utype with the right
address space.  Formatting fix.

* gcc.dg/asan/pr115172.c: New test.

(cherry picked from commit d3c506eff54fcbac389a529c2e98da108a410b7f)

Diff:
---
 gcc/testsuite/gcc.dg/asan/pr115172.c | 20 
 gcc/ubsan.cc |  6 +-
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/asan/pr115172.c 
b/gcc/testsuite/gcc.dg/asan/pr115172.c
new file mode 100644
index 000..8707e615733
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/asan/pr115172.c
@@ -0,0 +1,20 @@
+/* PR sanitizer/115172 */
+/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
+/* { dg-options "-O2 -fsanitize=address,bool -ffat-lto-objects 
-fdump-tree-asan1" } */
+/* { dg-final { scan-tree-dump-not "\.ASAN_CHECK " "asan1" } } */
+
+#ifdef __x86_64__
+#define SEG __seg_gs
+#else
+#define SEG __seg_fs
+#endif
+
+extern struct S { _Bool b; } s;
+void bar (void);
+
+void
+foo (void)
+{
+  if (*(volatile _Bool SEG *) (__UINTPTR_TYPE__) )
+bar ();
+}
diff --git a/gcc/ubsan.cc b/gcc/ubsan.cc
index fb00dc24bf6..76ca7a04265 100644
--- a/gcc/ubsan.cc
+++ b/gcc/ubsan.cc
@@ -1776,13 +1776,17 @@ instrument_bool_enum_load (gimple_stmt_iterator *gsi)
   || TREE_CODE (gimple_assign_lhs (stmt)) != SSA_NAME)
 return;
 
+  addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (rhs));
+  if (as != TYPE_ADDR_SPACE (utype))
+utype = build_qualified_type (utype, TYPE_QUALS (utype)
+| ENCODE_QUAL_ADDR_SPACE (as));
   bool ends_bb = stmt_ends_bb_p (stmt);
   location_t loc = gimple_location (stmt);
   tree lhs = gimple_assign_lhs (stmt);
   tree ptype = build_pointer_type (TREE_TYPE (rhs));
   tree atype = reference_alias_ptr_type (rhs);
   gimple *g = gimple_build_assign (make_ssa_name (ptype),
- build_fold_addr_expr (rhs));
+  build_fold_addr_expr (rhs));
   gimple_set_location (g, loc);
   gsi_insert_before (gsi, g, GSI_SAME_STMT);
   tree mem = build2 (MEM_REF, utype, gimple_assign_lhs (g),


[gcc r15-766] strlen: Fix up !si->full_string_p handling in count_nonzero_bytes_addr [PR115152]

2024-05-22 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:dbc9b45a3c2468ad134b3a9bd4961f7ae6bc1e67

commit r15-766-gdbc9b45a3c2468ad134b3a9bd4961f7ae6bc1e67
Author: Jakub Jelinek 
Date:   Wed May 22 09:13:50 2024 +0200

strlen: Fix up !si->full_string_p handling in count_nonzero_bytes_addr 
[PR115152]

The following testcase is miscompiled because
strlen_pass::count_nonzero_bytes_addr doesn't handle correctly
the !si->full_string_p case.
If si->full_string_p, it correctly computes minlen and maxlen as
minimum and maximum length of the '\0' terminated stgring and
clears *nulterm (ie. makes sure !full_string_p in the ultimate
caller) if minlen is equal or larger than nbytes and so
'\0' isn't guaranteed to be among those bytes.
But in the !si->full_string_p case, all we know is that there
are [minlen,maxlen] non-zero bytes followed by unknown bytes,
so effectively the maxlen is infinite (but caller cares about only
the first nbytes bytes) and furthermore, we never know if there is
any '\0' char among those, so *nulterm needs to be always cleared.

2024-05-22  Jakub Jelinek  

PR tree-optimization/115152
* tree-ssa-strlen.cc (strlen_pass::count_nonzero_bytes_addr): If
!si->full_string_p, clear *nulterm and set maxlen to nbytes.

* gcc.dg/pr115152.c: New test.

Diff:
---
 gcc/testsuite/gcc.dg/pr115152.c | 17 +
 gcc/tree-ssa-strlen.cc  |  5 -
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/pr115152.c b/gcc/testsuite/gcc.dg/pr115152.c
new file mode 100644
index 000..a44654e2015
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr115152.c
@@ -0,0 +1,17 @@
+/* PR tree-optimization/115152 */
+/* { dg-do run } */
+/* { dg-options "-O3 -fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" 
} */
+
+int a, b, c, d;
+signed char e[1] = { 1 };
+
+int
+main ()
+{
+  for (a = 0; a < 3; a++)
+for (b = 0; b < 2; b++)
+  c = e[0] = e[0] ^ d;
+  if (!c)
+__builtin_abort ();
+  return 0;
+}
diff --git a/gcc/tree-ssa-strlen.cc b/gcc/tree-ssa-strlen.cc
index 61c3da22322..7596dd80942 100644
--- a/gcc/tree-ssa-strlen.cc
+++ b/gcc/tree-ssa-strlen.cc
@@ -4829,7 +4829,7 @@ strlen_pass::count_nonzero_bytes_addr (tree exp, tree 
vuse, gimple *stmt,
   if (maxlen + 1 < nbytes)
return false;
 
-  if (nbytes <= minlen)
+  if (nbytes <= minlen || !si->full_string_p)
*nulterm = false;
 
   if (nbytes < minlen)
@@ -4839,6 +4839,9 @@ strlen_pass::count_nonzero_bytes_addr (tree exp, tree 
vuse, gimple *stmt,
maxlen = nbytes;
}
 
+  if (!si->full_string_p)
+   maxlen = nbytes;
+
   if (minlen < lenrange[0])
lenrange[0] = minlen;
   if (lenrange[1] < maxlen)


[gcc r15-765] ubsan: Use right address space for MEM_REF created for bool/enum sanitization [PR115172]

2024-05-22 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:d3c506eff54fcbac389a529c2e98da108a410b7f

commit r15-765-gd3c506eff54fcbac389a529c2e98da108a410b7f
Author: Jakub Jelinek 
Date:   Wed May 22 09:12:28 2024 +0200

ubsan: Use right address space for MEM_REF created for bool/enum 
sanitization [PR115172]

The following testcase is miscompiled, because -fsanitize=bool,enum
creates a MEM_REF without propagating there address space qualifiers,
so what should be normally loaded using say %gs:/%fs: segment prefix
isn't.  Together with asan it then causes that load to be sanitized.

2024-05-22  Jakub Jelinek  

PR sanitizer/115172
* ubsan.cc (instrument_bool_enum_load): If rhs is not in generic
address space, use qualified version of utype with the right
address space.  Formatting fix.

* gcc.dg/asan/pr115172.c: New test.

Diff:
---
 gcc/testsuite/gcc.dg/asan/pr115172.c | 20 
 gcc/ubsan.cc |  6 +-
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/asan/pr115172.c 
b/gcc/testsuite/gcc.dg/asan/pr115172.c
new file mode 100644
index 000..8707e615733
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/asan/pr115172.c
@@ -0,0 +1,20 @@
+/* PR sanitizer/115172 */
+/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
+/* { dg-options "-O2 -fsanitize=address,bool -ffat-lto-objects 
-fdump-tree-asan1" } */
+/* { dg-final { scan-tree-dump-not "\.ASAN_CHECK " "asan1" } } */
+
+#ifdef __x86_64__
+#define SEG __seg_gs
+#else
+#define SEG __seg_fs
+#endif
+
+extern struct S { _Bool b; } s;
+void bar (void);
+
+void
+foo (void)
+{
+  if (*(volatile _Bool SEG *) (__UINTPTR_TYPE__) )
+bar ();
+}
diff --git a/gcc/ubsan.cc b/gcc/ubsan.cc
index fb00dc24bf6..76ca7a04265 100644
--- a/gcc/ubsan.cc
+++ b/gcc/ubsan.cc
@@ -1776,13 +1776,17 @@ instrument_bool_enum_load (gimple_stmt_iterator *gsi)
   || TREE_CODE (gimple_assign_lhs (stmt)) != SSA_NAME)
 return;
 
+  addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (rhs));
+  if (as != TYPE_ADDR_SPACE (utype))
+utype = build_qualified_type (utype, TYPE_QUALS (utype)
+| ENCODE_QUAL_ADDR_SPACE (as));
   bool ends_bb = stmt_ends_bb_p (stmt);
   location_t loc = gimple_location (stmt);
   tree lhs = gimple_assign_lhs (stmt);
   tree ptype = build_pointer_type (TREE_TYPE (rhs));
   tree atype = reference_alias_ptr_type (rhs);
   gimple *g = gimple_build_assign (make_ssa_name (ptype),
- build_fold_addr_expr (rhs));
+  build_fold_addr_expr (rhs));
   gimple_set_location (g, loc);
   gsi_insert_before (gsi, g, GSI_SAME_STMT);
   tree mem = build2 (MEM_REF, utype, gimple_assign_lhs (g),


[PATCH] strlen: Fix up !si->full_string_p handling in count_nonzero_bytes_addr [PR115152]

2024-05-21 Thread Jakub Jelinek
Hi!

The following testcase is miscompiled because
strlen_pass::count_nonzero_bytes_addr doesn't handle correctly
the !si->full_string_p case.
If si->full_string_p, it correctly computes minlen and maxlen as
minimum and maximum length of the '\0' terminated stgring and
clears *nulterm (ie. makes sure !full_string_p in the ultimate
caller) if minlen is equal or larger than nbytes and so
'\0' isn't guaranteed to be among those bytes.
But in the !si->full_string_p case, all we know is that there
are [minlen,maxlen] non-zero bytes followed by unknown bytes,
so effectively the maxlen is infinite (but caller cares about only
the first nbytes bytes) and furthermore, we never know if there is
any '\0' char among those, so *nulterm needs to be always cleared.

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

2024-05-21  Jakub Jelinek  

PR tree-optimization/115152
* tree-ssa-strlen.cc (strlen_pass::count_nonzero_bytes_addr): If
!si->full_string_p, clear *nulterm and set maxlen to nbytes.

* gcc.dg/pr115152.c: New test.

--- gcc/tree-ssa-strlen.cc.jj   2024-04-29 11:00:45.0 +0200
+++ gcc/tree-ssa-strlen.cc  2024-05-21 13:43:31.031208000 +0200
@@ -4829,7 +4829,7 @@ strlen_pass::count_nonzero_bytes_addr (t
   if (maxlen + 1 < nbytes)
return false;
 
-  if (nbytes <= minlen)
+  if (nbytes <= minlen || !si->full_string_p)
*nulterm = false;
 
   if (nbytes < minlen)
@@ -4839,6 +4839,9 @@ strlen_pass::count_nonzero_bytes_addr (t
maxlen = nbytes;
}
 
+  if (!si->full_string_p)
+   maxlen = nbytes;
+
   if (minlen < lenrange[0])
lenrange[0] = minlen;
   if (lenrange[1] < maxlen)
--- gcc/testsuite/gcc.dg/pr115152.c.jj  2024-05-21 13:46:02.793214348 +0200
+++ gcc/testsuite/gcc.dg/pr115152.c 2024-05-21 12:49:38.791626073 +0200
@@ -0,0 +1,17 @@
+/* PR tree-optimization/115152 */
+/* { dg-do run } */
+/* { dg-options "-O3 -fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" 
} */
+
+int a, b, c, d;
+signed char e[1] = { 1 };
+
+int
+main ()
+{
+  for (a = 0; a < 3; a++)
+for (b = 0; b < 2; b++)
+  c = e[0] = e[0] ^ d;
+  if (!c)
+__builtin_abort ();
+  return 0;
+}

Jakub



[PATCH] ubsan: Use right address space for MEM_REF created for bool/enum sanitization [PR115172]

2024-05-21 Thread Jakub Jelinek
Hi!

The following testcase is miscompiled, because -fsanitize=bool,enum
creates a MEM_REF without propagating there address space qualifiers,
so what should be normally loaded using say %gs:/%fs: segment prefix
isn't.  Together with asan it then causes that load to be sanitized.

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

2024-05-21  Jakub Jelinek  

PR sanitizer/115172
* ubsan.cc (instrument_bool_enum_load): If rhs is not in generic
address space, use qualified version of utype with the right
address space.  Formatting fix.

* gcc.dg/asan/pr115172.c: New test.

--- gcc/ubsan.cc.jj 2024-03-22 09:23:37.695296775 +0100
+++ gcc/ubsan.cc2024-05-21 12:10:24.261454107 +0200
@@ -1776,13 +1776,17 @@ instrument_bool_enum_load (gimple_stmt_i
   || TREE_CODE (gimple_assign_lhs (stmt)) != SSA_NAME)
 return;
 
+  addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (rhs));
+  if (as != TYPE_ADDR_SPACE (utype))
+utype = build_qualified_type (utype, TYPE_QUALS (utype)
+| ENCODE_QUAL_ADDR_SPACE (as));
   bool ends_bb = stmt_ends_bb_p (stmt);
   location_t loc = gimple_location (stmt);
   tree lhs = gimple_assign_lhs (stmt);
   tree ptype = build_pointer_type (TREE_TYPE (rhs));
   tree atype = reference_alias_ptr_type (rhs);
   gimple *g = gimple_build_assign (make_ssa_name (ptype),
- build_fold_addr_expr (rhs));
+  build_fold_addr_expr (rhs));
   gimple_set_location (g, loc);
   gsi_insert_before (gsi, g, GSI_SAME_STMT);
   tree mem = build2 (MEM_REF, utype, gimple_assign_lhs (g),
--- gcc/testsuite/gcc.dg/asan/pr115172.c.jj 2024-05-21 17:28:18.302815400 
+0200
+++ gcc/testsuite/gcc.dg/asan/pr115172.c2024-05-21 22:50:43.272753785 
+0200
@@ -0,0 +1,20 @@
+/* PR sanitizer/115172 */
+/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
+/* { dg-options "-O2 -fsanitize=address,bool -ffat-lto-objects 
-fdump-tree-asan1" } */
+/* { dg-final { scan-tree-dump-not "\.ASAN_CHECK " "asan1" } } */
+
+#ifdef __x86_64__
+#define SEG __seg_gs
+#else
+#define SEG __seg_fs
+#endif
+
+extern struct S { _Bool b; } s;
+void bar (void);
+
+void
+foo (void)
+{
+  if (*(volatile _Bool SEG *) (__UINTPTR_TYPE__) )
+bar ();
+}

Jakub



GCC 13.3 Released

2024-05-21 Thread Jakub Jelinek via gcc-announce
The GNU Compiler Collection version 13.3 has been released.

GCC 13.3 is a bug-fix release from the GCC 13 branch

  
containing important fixes for regressions and serious bugs in
GCC 13.2 with more than 173 bugs fixed since the previous release.  

  

This release is available from the FTP servers listed here:

  https://sourceware.org/pub/gcc/releases/gcc-13.3.0/
  https://gcc.gnu.org/mirrors.html

Please do not contact me directly regarding questions or comments
about this release.  Instead, use the resources available from
http://gcc.gnu.org.

As always, a vast number of people contributed to this GCC release
-- far too many to thank them individually!



GCC 13.3 Released

2024-05-21 Thread Jakub Jelinek via Gcc
The GNU Compiler Collection version 13.3 has been released.

GCC 13.3 is a bug-fix release from the GCC 13 branch

  
containing important fixes for regressions and serious bugs in
GCC 13.2 with more than 173 bugs fixed since the previous release.  

  

This release is available from the FTP servers listed here:

  https://sourceware.org/pub/gcc/releases/gcc-13.3.0/
  https://gcc.gnu.org/mirrors.html

Please do not contact me directly regarding questions or comments
about this release.  Instead, use the resources available from
http://gcc.gnu.org.

As always, a vast number of people contributed to this GCC release
-- far too many to thank them individually!



gcc-wwwdocs branch master updated. 9e79c5e411eb3236b481c6093fad4dc5ae5141c5

2024-05-21 Thread Jakub Jelinek via Gcc-cvs-wwwdocs
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gcc-wwwdocs".

The branch, master has been updated
   via  9e79c5e411eb3236b481c6093fad4dc5ae5141c5 (commit)
  from  c52ab7c1b318d66f45b372d50282c7052b59f677 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 9e79c5e411eb3236b481c6093fad4dc5ae5141c5
Author: Jakub Jelinek 
Date:   Tue May 21 11:05:04 2024 +0200

Releasing 13.3.0.

diff --git a/htdocs/develop.html b/htdocs/develop.html
index 40228f49..9145aceb 100644
--- a/htdocs/develop.html
+++ b/htdocs/develop.html
@@ -708,9 +708,9 @@ stages of development, branch points, and releases:
|   \
|v
|   GCC 13.2 release (2023-07-27)
-  GCC 14 Stage 3 (starts 2023-11-19)
-   |
-  GCC 14 Stage 4 (starts 2024-01-12)
+  GCC 14 Stage 3 (starts 2023-11-19) \
+   |  v
+  GCC 14 Stage 4 (starts 2024-01-12)   GCC 13.3 release (2024-05-21)
|
+-- GCC 14 branch created ---+
| \
diff --git a/htdocs/index.html b/htdocs/index.html
index c52bb30b..afc76800 100644
--- a/htdocs/index.html
+++ b/htdocs/index.html
@@ -54,6 +54,11 @@ mission statement.
 
 News
 
+
+GCC 13.3 released
+[2024-05-21]
+
+
 https://gcc.gnu.org/wiki/cauldron2024;>GNU Tools Cauldron 
2024
 [2024-05-07]
 Prague, Czech Republic, September 14-16 2024
@@ -153,28 +158,28 @@ More news? Let ger...@pfeifer.com know!
   (regression fixes  docs only).
   
   https://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advancedshort_desc_type=regexpshort_desc=%5C%5B(%5B%200-9.%2F%5D*%5B%20%2F%5D)*14%5B%20%2F%5D%5B%200-9.%2F%5D*%5BRr%5Degression%20*%5C%5Dtarget_milestone=11.5target_milestone=12.4target_milestone=13.3target_milestone=14.2known_to_fail_type=allwordssubstrknown_to_work_type=allwordssubstrlong_desc_type=allwordssubstrlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=gcchost_type=allwordssubstrgcchost=gcctarget_type=allwordssubstrgcctarget=gccbuild_type=allwordssubstrgccbuild=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=SUSPENDEDbug_status=WAITINGbug_status=REOPENEDpriority=P1priority=P2priority=P3emailtype1=substringemail1=emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldf
 
rom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0=">Serious
+  
href="https://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advancedshort_desc_type=regexpshort_desc=%5C%5B(%5B%200-9.%2F%5D*%5B%20%2F%5D)*14%5B%20%2F%5D%5B%200-9.%2F%5D*%5BRr%5Degression%20*%5C%5Dtarget_milestone=11.5target_milestone=12.4target_milestone=13.4target_milestone=14.2known_to_fail_type=allwordssubstrknown_to_work_type=allwordssubstrlong_desc_type=allwordssubstrlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=gcchost_type=allwordssubstrgcchost=gcctarget_type=allwordssubstrgcctarget=gccbuild_type=allwordssubstrgccbuild=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=SUSPENDEDbug_status=WAITINGbug_status=REOPENEDpriority=P1priority=P2priority=P3emailtype1=substringemail1=emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldf
 
rom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0=">Serious
   regressions.
   https://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advancedshort_desc_type=regexpshort_desc=%5C%5B(%5B%200-9.%2F%5D*%5B%20%2F%5D)*14%5B%20%2F%5D%5B%200-9.%2F%5D*%5BRr%5Degression%20*%5C%5Dtarget_milestone=11.5target_milestone=12.4target_milestone=13.3target_milestone=14.2known_to_fail_type=allwordssubstrknown_to_work_type=allwordssubstrlong_desc_type=allwordssubstrlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=gcchost_type=allwordssubstrgcchost=gcctarget_type=allwordssubstrgcctarget=gccbuild_type=allwordssubstrgccbuild=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=SUSPENDEDbug_status=WAITINGbug_status=REOPENEDemailtype1=substringemail1=emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmd
 
type=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0=">All
+  
href="https://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advancedshort_desc_type=regexpshort_desc=%5C%5B(%5B%200-9.%2F%5D*%5B%20%2F%5D)*14%5B%20%2F%5D%5B%200-9.%2F%5D*%5BRr%5Degression%20*%5C%5Dtarget_milestone=11.5target_milestone=12.4target_milest

[gcc r13-8782] Bump BASE-VER.

2024-05-21 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:bde589428198cd4a24fe6327a73a68c1a46e2a10

commit r13-8782-gbde589428198cd4a24fe6327a73a68c1a46e2a10
Author: Jakub Jelinek 
Date:   Tue May 21 10:56:25 2024 +0200

Bump BASE-VER.

2024-05-21  Jakub Jelinek  

* BASE-VER: Set to 13.3.1.

Diff:
---
 gcc/BASE-VER | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/BASE-VER b/gcc/BASE-VER
index ac565bc1cab..c3d10c59d83 100644
--- a/gcc/BASE-VER
+++ b/gcc/BASE-VER
@@ -1 +1 @@
-13.3.0
+13.3.1


Re: [Patch] contrib/gcc-changelog/git_update_version.py: Improve diagnostic

2024-05-21 Thread Jakub Jelinek
On Tue, May 21, 2024 at 09:36:05AM +0200, Tobias Burnus wrote:
> Jakub Jelinek wrote:
> > On Mon, May 20, 2024 at 08:31:02AM +0200, Tobias Burnus wrote:
> > > Hmm, there were now two daily bumps: [...] I really wonder why.
> > Because I've done it by hand.
> 
> Okay, that explains it.
> 
> I still do not understand why it slipped through at the first place; I tried
> old versions down to r12-709-g772e5e82e3114f and it still FAIL for the
> invalid commit ("ERR: cannot find a ChangeLog location in message").
> 
> Thus, I wonder whether the commit hook is active at all?!?

They are.  But
https://github.com/AdaCore/git-hooks/blob/master/hooks/updates/__init__.py#L836
with
https://github.com/AdaCore/git-hooks/blob/master/hooks/updates/commits.py#L230
bypasses all commits which contain just 3 magic words in a row.
And because that part is owned by AdaCore hooks, not the GCC customizations,
not sure what to do about that.

> > I have in ~gccadmin a gcc-changelog copy and adjusted update_version_git
> > script which doesn't use contrib/gcc-changelog subdirectory from the
> > checkout it makes but from the ~gccadmin directory,
> [...]
> > I'm already using something similar in
> > my hack (just was doing it for even successful commits, but I think your
> > patch is better).
> > And, I think best would be if update_version_git script simply
> > accepted a list of ignored commits from the command line too,
> > passed it to the git_update_version.py script and that one
> > added those to IGNORED_COMMITS.
> 
> Updated version:
> 
> * Uses my diagnostic
> 
> * Adds an -i/--ignore argument for commits. Permits to use '-i hash1  -i
> hash2' but also '-i hash1,hash2' or '-i "hash1 hash2'
> 
> * I changed the global variable to lower case as Python's style guide states
> that all uppercase variables is for constants.
> 
> * The '=None' matches one of the current usages (no argument passed); hence,
> it is now explicit and 'pylint' is happy.
> 
> OK for mainline?

Yes, thanks.

> PS: I have not updated the hashes. If needed/wanted, I leave that to you,
> Jakub.

Once some commit is ignored, we won't be processing it anymore, so I think
the -i option is all we need.

Jakub



gcc-wwwdocs branch master updated. c52ab7c1b318d66f45b372d50282c7052b59f677

2024-05-21 Thread Jakub Jelinek via Gcc-cvs-wwwdocs
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gcc-wwwdocs".

The branch, master has been updated
   via  c52ab7c1b318d66f45b372d50282c7052b59f677 (commit)
  from  c1594fa5dda412c98f3193ca8f993f6fc21e73c1 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit c52ab7c1b318d66f45b372d50282c7052b59f677
Author: Jakub Jelinek 
Date:   Tue May 21 09:21:20 2024 +0200

Releasing 13.3.

diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 3ab4a101..88b76c49 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -870,9 +870,6 @@ are not listed here).
 
 GCC 13.3
 
-Note: GCC 13.3 has not been released yet, so this section is a
-work-in-progress.
-
 This is the https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVEDresolution=FIXEDtarget_milestone=13.3;>list
 of problem reports (PRs) from GCC's bug tracking system that are
 known to be fixed in the 13.3 release. This list might not be
diff --git a/htdocs/gcc-13/index.html b/htdocs/gcc-13/index.html
index ed23d786..b04838db 100644
--- a/htdocs/gcc-13/index.html
+++ b/htdocs/gcc-13/index.html
@@ -11,17 +11,23 @@
 
 GCC 13 Release Series
 
-July 27, 2023
+May 21, 2024
 
-The GCC developers are pleased to announce the release of GCC 13.2.
+The GCC developers are pleased to announce the release of GCC 13.3.
 
 This release is a bug-fix release, containing fixes for regressions in
-GCC 13.1 relative to previous releases of GCC.
+GCC 13.2 relative to previous releases of GCC.
 
 Release History
 
 
 
+GCC 13.3
+May 21, 2024
+(changes,
+ http://gcc.gnu.org/onlinedocs/13.3.0/;>documentation)
+
+
 GCC 13.2
 July 27, 2023
 (changes,

---

Summary of changes:
 htdocs/gcc-13/changes.html |  3 ---
 htdocs/gcc-13/index.html   | 12 +---
 2 files changed, 9 insertions(+), 6 deletions(-)


hooks/post-receive
-- 
gcc-wwwdocs


[gcc r15-690] Manually add ChangeLog entry for r15-575-gda73261ce7731be7f2b164f1db796878cdc23365

2024-05-20 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:83d3a218dfb3b7730884ada7e607cf72891d4c11

commit r15-690-g83d3a218dfb3b7730884ada7e607cf72891d4c11
Author: Jakub Jelinek 
Date:   Mon May 20 09:48:27 2024 +0200

Manually add ChangeLog entry for 
r15-575-gda73261ce7731be7f2b164f1db796878cdc23365

Diff:
---
 gcc/ChangeLog | 29 +
 1 file changed, 29 insertions(+)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index bfd2d42e287d..07aad1886112 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -359,6 +359,35 @@
(math_opts_dom_walker::after_dom_children): Try match saturation
arith when IOR expr.
 
+2024-05-16  Aldy Hernandez  
+
+   Revert:
+   2024-05-10  Aldy Hernandez  
+
+   Revert:
+   2024-05-08  Aldy Hernandez  
+
+   * gimple-range-cache.cc (sbr_sparse_bitmap::sbr_sparse_bitmap):
+   Change irange to prange.
+   * gimple-range-fold.cc (fold_using_range::fold_stmt): Same.
+   (fold_using_range::range_of_address): Same.
+   * gimple-range-fold.h (range_of_address): Same.
+   * gimple-range-infer.cc (gimple_infer_range::add_nonzero): Same.
+   * gimple-range-op.cc (class cfn_strlen): Same.
+   * gimple-range-path.cc
+   (path_range_query::adjust_for_non_null_uses): Same.
+   * gimple-ssa-warn-access.cc (pass_waccess::check_pointer_uses): Same.
+   * tree-ssa-structalias.cc (find_what_p_points_to): Same.
+   * range-op-ptr.cc (range_op_table::initialize_pointer_ops): Remove
+   hybrid entries in table.
+   * range-op.cc (range_op_table::range_op_table): Add pointer
+   entries for bitwise and/or and min/max.
+   * value-range.cc (irange::verify_range): Add assert.
+   * value-range.h (irange::varying_compatible_p): Remove check for
+   error_mark_node.
+   (irange::supports_p): Remove pointer support.
+   * ipa-cp.h (ipa_supports_p): Add prange support.
+
 2024-05-16  Aldy Hernandez  
 
PR tree-optimization/114985


Re: [Patch] contrib/gcc-changelog/git_update_version.py: Improve diagnostic (was: [Patch] contrib/gcc-changelog/git_update_version.py: Add ignore commit, improve diagnostic)

2024-05-20 Thread Jakub Jelinek
On Mon, May 20, 2024 at 08:31:02AM +0200, Tobias Burnus wrote:
> Hmm, there were now two daily bumps:
> 
> Date:   Mon May 20 00:16:30 2024 +
> 
> Date:   Sun May 19 18:15:28 2024 +
> 
> I really wonder why.

Because I've done it by hand.
I have in ~gccadmin a gcc-changelog copy and adjusted update_version_git
script which doesn't use contrib/gcc-changelog subdirectory from the
checkout it makes but from the ~gccadmin directory, because I don't want to
constantly try to add some commit number to IGNORED_COMMITS, see that it
either works or doesn't (I think sometimes it needs the hash of the revert
commit, at other times the commit hash referenced in the revert commit)
or that further ones are needed.

> From f56b1764f2b5c2c83c6852607405e5be0a763a2c Mon Sep 17 00:00:00 2001
> From: Tobias Burnus 
> Date: Sun, 19 May 2024 08:17:42 +0200
> Subject: [PATCH] contrib/gcc-changelog/git_update_version.py: Improve 
> diagnostic
> 
> contrib/ChangeLog:
> 
> * gcc-changelog/git_update_version.py (prepend_to_changelog_files): 
> Output

8 spaces rather than tab

>   git hash in case errors occurred.
> 
> diff --git a/contrib/gcc-changelog/git_update_version.py 
> b/contrib/gcc-changelog/git_update_version.py
> index 24f6c43d0b2..ec0151b83fe 100755
> --- a/contrib/gcc-changelog/git_update_version.py
> +++ b/contrib/gcc-changelog/git_update_version.py
> @@ -58,6 +58,7 @@ def read_timestamp(path):
>  
>  def prepend_to_changelog_files(repo, folder, git_commit, add_to_git):
>  if not git_commit.success:
> +logging.info(f"While processing {git_commit.info.hexsha}:")
>  for error in git_commit.errors:
>  logging.info(error)
>  raise AssertionError()

So, your commit is useful part of it, I'm already using something similar in
my hack (just was doing it for even successful commits, but I think your
patch is better).
And, I think best would be if update_version_git script simply
accepted a list of ignored commits from the command line too,
passed it to the git_update_version.py script and that one
added those to IGNORED_COMMITS.
Because typically if the DATESTAMP/ChangeLog updates gets stuck,
one doesn't just adjust IGNORED_COMMITS and wait up to another
day to see if it worked, but runs the script by hand to make sure
it works.

--- gcc-checkout/contrib/gcc-changelog/git_update_version.py2024-05-13 
16:52:57.890151748 +
+++ gcc-changelog/git_update_version.py 2024-05-19 18:13:44.953648834 +
@@ -41,7 +41,21 @@ IGNORED_COMMITS = (
 '040e5b0edbca861196d9e2ea2af5e805769c8d5d',
 '8057f9aa1f7e70490064de796d7a8d42d446caf8',
 '109f1b28fc94c93096506e3df0c25e331cef19d0',
-'39f81924d88e3cc197fc3df74204c9b5e01e12f7')
+'39f81924d88e3cc197fc3df74204c9b5e01e12f7',
+'d7bb8eaade3cd3aa70715c8567b4d7b08098e699',
+'89feb3557a018893cfe50c2e07f91559bd3cde2b',
+'ccf8d3e3d26c6ba3d5e11fffeed8d64018e9c060',
+'e0c52905f666e3d23881f82dbf39466a24f009f4',
+'b38472ffc1e631bd357573b44d956ce16d94e666',
+'a0b13d0860848dd5f2876897ada1e22e4e681e91',
+'b8c772cae97b54386f7853edf0f9897012bfa90b',
+'810d35a7e054bcbb5b66d2e5924428e445f5fba9',
+'0df1ee083434ac00ecb19582b1e5b25e105981b2',
+'2c688f6afce4cbb414f5baab1199cd525f309fca',
+'60dcb710b6b4aa22ea96abc8df6dfe9067f3d7fe',
+'44968a0e00f656e9bb3e504bb2fa1a8282002015',
+'d7bb8eaade3cd3aa70715c8567b4d7b08098e699',
+'da73261ce7731be7f2b164f1db796878cdc23365')
 
 FORMAT = '%(asctime)s:%(levelname)s:%(name)s:%(message)s'
 logging.basicConfig(level=logging.INFO, format=FORMAT,
@@ -125,6 +139,7 @@ def update_current_branch(ref_name):
   % (commit.hexsha, head.hexsha), ref_name)
 commits = [c for c in commits if c.info.hexsha not in IGNORED_COMMITS]
 for git_commit in reversed(commits):
+logging.info('trying %s', git_commit.info.hexsha)
 prepend_to_changelog_files(repo, args.git_path, git_commit,
not args.dry_mode)
 if args.dry_mode:

Jakub



Re: [PATCH] libstdc++: increment *this instead of this

2024-05-18 Thread Jakub Jelinek
On Sat, May 18, 2024 at 02:53:20PM +0800, Kefu Chai wrote:
> libstdc++-v3/ChangeLog:
> 
> * include/bits/unicode.h (enable_borrowed_range): Call ++(*this)
> instead of ++this

This should be already fixed, see https://gcc.gnu.org/PR115119

Jakub



Re: [PATCH] Use DW_TAG_module for Ada

2024-05-17 Thread Jakub Jelinek
On Fri, May 03, 2024 at 11:08:04AM -0600, Tom Tromey wrote:
> DWARF is not especially clear on the distinction between
> DW_TAG_namespace and DW_TAG_module, but I think that DW_TAG_module is
> more appropriate for Ada.  This patch changes the compiler to do this.
> Note that the Ada compiler does not yet create NAMESPACE_DECLs.
> 
> gcc
> 
>   * dwarf2out.cc (gen_namespace_die): Use DW_TAG_module for Ada.

Ok, thanks.

> diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
> index 1b0e8b5a5b2..1e46c27cdf7 100644
> --- a/gcc/dwarf2out.cc
> +++ b/gcc/dwarf2out.cc
> @@ -26992,7 +26992,7 @@ gen_namespace_die (tree decl, dw_die_ref context_die)
>  {
>/* Output a real namespace or module.  */
>context_die = setup_namespace_context (decl, comp_unit_die ());
> -  namespace_die = new_die (is_fortran () || is_dlang ()
> +  namespace_die = new_die (is_fortran () || is_dlang () || is_ada ()
>  ? DW_TAG_module : DW_TAG_namespace,
>  context_die, decl);
>/* For Fortran modules defined in different CU don't add src coords.  
> */
> -- 
> 2.44.0

Jakub



C++ Patch ping - Re: [PATCH] c++: Fix parsing of abstract-declarator starting with ... followed by [ or ( [PR115012]

2024-05-16 Thread Jakub Jelinek
Hi!

I'd like to ping the 
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651199.html
patch.

Thanks.

On Thu, May 09, 2024 at 08:12:30PM +0200, Jakub Jelinek wrote:
> The C++26 P2662R3 Pack indexing paper mentions that both GCC
> and MSVC don't handle T...[10] parameter declaration when T
> is a pack.  While that will change meaning in C++26, in C++11 .. C++23
> this ought to be valid.  Also, T...(args) as well.
> 
> The following patch handles those in cp_parser_direct_declarator.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2024-05-09  Jakub Jelinek  
> 
>   PR c++/115012
>   * parser.cc (cp_parser_direct_declarator): Handle
>   abstract declarator starting with ... followed by [
>   or (.
> 
>   * g++.dg/cpp0x/variadic185.C: New test.
>   * g++.dg/cpp0x/variadic186.C: New test.

Jakub



Re: [COMMITTED] Revert "Revert: "Enable prange support.""

2024-05-16 Thread Jakub Jelinek
On Thu, May 16, 2024 at 12:14:09PM +0200, Aldy Hernandez wrote:
> Wait, what's the preferred way of reverting a patch?  I followed what I saw 
> in:

Reverting a patch (that isn't a reversion) just push git revert.
The important part is not to modify the This reverts commit line from what
git revert created.

> commit 04ee1f788ceaa4c7f777ff3b9441ae076191439c
> Author: Jeff Law 
> Date:   Mon May 13 21:42:38 2024 -0600
> 
> Revert "[PATCH v2 1/3] RISC-V: movmem for RISCV with V extension"
> 
> This reverts commit df15eb15b5f820321c81efc75f0af13ff8c0dd5b.

So, this is just fine.

> and here:
> 
> commit 0c6dd4b0973738ce43e76b468a002ab5eb58aaf4
> Author: YunQiang Su 
> Date:   Mon May 13 14:15:38 2024 +0800
> 
> Revert "MIPS: Support constraint 'w' for MSA instruction"
> 
> This reverts commit 9ba01240864ac446052d97692e2199539b7c76d8.

And this too.

What is not fine is hand edit the message:
This reverts commit 9ba01240864ac446052d97692e2199539b7c76d8 because
foo and bar.
You can do that separately, so
This reverts commit 9ba01240864ac446052d97692e2199539b7c76d8.
The reversion is because of foo and bar.
Or being further creative:
This reverts commit r13-8390-g9de6ff5ec9a46951d2.
etc.

> commit f6ce85502eb2e4e7bbd9b3c6c1c065a004f8f531
> Author: Hans-Peter Nilsson 
> Date:   Wed May 8 04:11:20 2024 +0200
> 
> Revert "Revert "testsuite/gcc.target/cris/pr93372-2.c: Handle
> xpass from combine improvement""
> 
> This reverts commit 39f81924d88e3cc197fc3df74204c9b5e01e12f7.

This one is not fine.  Our current infrastructure for ChangeLog
generation can't deal with that and there is no agreement what to
write in the ChangeLog for it anyway, whether 2 reversions turn it into
Reapply commit: or 2 Revert: lines?  What happens on 3rd reversion?
So, one needs to manually remove the
This reverts commit 39f81924d88e3cc197fc3df74204c9b5e01e12f7.
line and supply ChangeLog entry.

For cases like this or the ammended lines (or say if This reverts
commit or (cherry-picked from ) lines refer to invalid commit
the daily DATESTAMP update then fails, I need to add manually
all problematic commits to IGNORED_COMMITS, rerun it by hand and
then write the ChangeLog entries by hand.
See
https://gcc.gnu.org/r13-8764
https://gcc.gnu.org/r15-426
https://gcc.gnu.org/r15-345
https://gcc.gnu.org/r15-344
https://gcc.gnu.org/r15-341
https://gcc.gnu.org/r14-9832
https://gcc.gnu.org/r14-9830
for what I had to do only in April/May for this.

Jakub



Re: [COMMITTED] Revert "Revert: "Enable prange support.""

2024-05-16 Thread Jakub Jelinek
On Thu, May 16, 2024 at 12:01:01PM +0200, Aldy Hernandez wrote:
> This reverts commit d7bb8eaade3cd3aa70715c8567b4d7b08098e699 and enables 
> prange
> support again.

Please don't do this.
This breaks ChangeLog generation, will need to handle it tomorrow by hand again.
Both the ammendments to the git (cherry-pick -x or revert) added message
lines
This reverts commit COMMITHASH.
and
(cherry picked from commit COMMITHASH)
and revert of revert.

Jakub



[gcc r15-521] c++: Optimize in maybe_clone_body aliases even when not at_eof [PR113208]

2024-05-15 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:6ad7ca1bb905736c0f57688e93e9e77cbc71a325

commit r15-521-g6ad7ca1bb905736c0f57688e93e9e77cbc71a325
Author: Jakub Jelinek 
Date:   Wed May 15 18:50:11 2024 +0200

c++: Optimize in maybe_clone_body aliases even when not at_eof [PR113208]

This patch reworks the cdtor alias optimization, such that we can create
aliases even when maybe_clone_body is called not at at_eof time, without 
trying
to repeat it in maybe_optimize_cdtor.

2024-05-15  Jakub Jelinek  
Jason Merrill  

PR lto/113208
* cp-tree.h (maybe_optimize_cdtor): Remove.
* decl2.cc (tentative_decl_linkage): Call maybe_make_one_only
for implicit instantiations of maybe in charge ctors/dtors
declared inline.
(import_export_decl): Don't call maybe_optimize_cdtor.
(c_parse_final_cleanups): Formatting fixes.
* optimize.cc (can_alias_cdtor): Adjust condition, for
HAVE_COMDAT_GROUP && DECL_ONE_ONLY && DECL_WEAK return true even
if not DECL_INTERFACE_KNOWN.
(maybe_clone_body): Don't clear DECL_SAVED_TREE, instead set it
to void_node.
(maybe_clone_body): Remove.
* decl.cc (cxx_comdat_group): For DECL_CLONED_FUNCTION_P
functions if SUPPORTS_ONE_ONLY return DECL_COMDAT_GROUP if already
set.

* g++.dg/abi/comdat3.C: New test.
* g++.dg/abi/comdat4.C: New test.

Diff:
---
 gcc/cp/cp-tree.h   |  1 -
 gcc/cp/decl.cc |  7 +
 gcc/cp/decl2.cc| 32 ++-
 gcc/cp/optimize.cc | 63 ++
 gcc/testsuite/g++.dg/abi/comdat3.C | 22 +
 gcc/testsuite/g++.dg/abi/comdat4.C | 28 +
 6 files changed, 78 insertions(+), 75 deletions(-)

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 9a8c86591573..ba9e848c177f 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7453,7 +7453,6 @@ extern bool handle_module_option (unsigned opt, const 
char *arg, int value);
 /* In optimize.cc */
 extern tree clone_attrs(tree);
 extern bool maybe_clone_body   (tree);
-extern void maybe_optimize_cdtor   (tree);
 
 /* In parser.cc */
 extern tree cp_convert_range_for (tree, tree, tree, cp_decomp *, bool,
diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index a139b293e00c..6fcab615d55e 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -19287,6 +19287,13 @@ cxx_comdat_group (tree decl)
  else
break;
}
+  /* If a ctor/dtor has already set the comdat group by
+maybe_clone_body, don't override it.  */
+  if (SUPPORTS_ONE_ONLY
+ && TREE_CODE (decl) == FUNCTION_DECL
+ && DECL_CLONED_FUNCTION_P (decl))
+   if (tree comdat = DECL_COMDAT_GROUP (decl))
+ return comdat;
 }
 
   return decl;
diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
index 6913efa53552..7baff46a1921 100644
--- a/gcc/cp/decl2.cc
+++ b/gcc/cp/decl2.cc
@@ -3325,16 +3325,23 @@ tentative_decl_linkage (tree decl)
 linkage of all functions, and as that causes writes to
 the data mapped in from the PCH file, it's advantageous
 to mark the functions at this point.  */
- if (DECL_DECLARED_INLINE_P (decl)
- && (!DECL_IMPLICIT_INSTANTIATION (decl)
- || DECL_DEFAULTED_FN (decl)))
+ if (DECL_DECLARED_INLINE_P (decl))
{
- /* This function must have external linkage, as
-otherwise DECL_INTERFACE_KNOWN would have been
-set.  */
- gcc_assert (TREE_PUBLIC (decl));
- comdat_linkage (decl);
- DECL_INTERFACE_KNOWN (decl) = 1;
+ if (!DECL_IMPLICIT_INSTANTIATION (decl)
+ || DECL_DEFAULTED_FN (decl))
+   {
+ /* This function must have external linkage, as
+otherwise DECL_INTERFACE_KNOWN would have been
+set.  */
+ gcc_assert (TREE_PUBLIC (decl));
+ comdat_linkage (decl);
+ DECL_INTERFACE_KNOWN (decl) = 1;
+   }
+ else if (DECL_MAYBE_IN_CHARGE_CDTOR_P (decl))
+   /* For implicit instantiations of cdtors try to make
+  it comdat, so that maybe_clone_body can use aliases.
+  See PR113208.  */
+   maybe_make_one_only (decl);
}
}
   else if (VAR_P (decl))
@@ -3604,9 +3611,6 @@ import_export_decl (tree decl)
 }
 
   DECL_INTERFACE_KNOWN (decl) = 1;
-
-  if (DECL_CLONED_FUNCTION_P (decl))
-maybe_optimize_cdtor (decl);
 }
 
 /* Return an expression that performs the destruction of DECL, which
@@ -5331,7 +5335,7 @@ c_parse_final_cle

[committed] openmp: Diagnose using grainsize+num_tasks clauses together [PR115103]

2024-05-15 Thread Jakub Jelinek
Hi!

I've noticed that while we diagnose many other OpenMP exclusive clauses,
we don't diagnose grainsize together with num_tasks on taskloop construct
in all of C, C++ and Fortran (the implementation simply ignored grainsize
in that case) and for Fortran also don't diagnose mixing nogroup clause
with reduction clause(s).

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk.

2024-05-15  Jakub Jelinek  

PR c/115103
gcc/c/
* c-typeck.cc (c_finish_omp_clauses): Diagnose grainsize
used together with num_tasks.
gcc/cp/
* semantics.cc (finish_omp_clauses): Diagnose grainsize
used together with num_tasks.
gcc/fortran/
* openmp.cc (resolve_omp_clauses): Diagnose grainsize
used together with num_tasks or nogroup used together with
reduction.
gcc/testsuite/
* c-c++-common/gomp/clause-dups-1.c: Add 2 further expected errors.
* gfortran.dg/gomp/pr115103.f90: New test.

--- gcc/c/c-typeck.cc.jj2024-04-22 14:46:28.917086705 +0200
+++ gcc/c/c-typeck.cc   2024-05-15 15:43:23.117428045 +0200
@@ -14722,6 +14722,8 @@ c_finish_omp_clauses (tree clauses, enum
   tree *detach_seen = NULL;
   bool linear_variable_step_check = false;
   tree *nowait_clause = NULL;
+  tree *grainsize_seen = NULL;
+  bool num_tasks_seen = false;
   tree ordered_clause = NULL_TREE;
   tree schedule_clause = NULL_TREE;
   bool oacc_async = false;
@@ -16021,8 +16023,6 @@ c_finish_omp_clauses (tree clauses, enum
case OMP_CLAUSE_PROC_BIND:
case OMP_CLAUSE_DEVICE_TYPE:
case OMP_CLAUSE_PRIORITY:
-   case OMP_CLAUSE_GRAINSIZE:
-   case OMP_CLAUSE_NUM_TASKS:
case OMP_CLAUSE_THREADS:
case OMP_CLAUSE_SIMD:
case OMP_CLAUSE_HINT:
@@ -16048,6 +16048,16 @@ c_finish_omp_clauses (tree clauses, enum
  pc = _CLAUSE_CHAIN (c);
  continue;
 
+   case OMP_CLAUSE_GRAINSIZE:
+ grainsize_seen = pc;
+ pc = _CLAUSE_CHAIN (c);
+ continue;
+
+   case OMP_CLAUSE_NUM_TASKS:
+ num_tasks_seen = true;
+ pc = _CLAUSE_CHAIN (c);
+ continue;
+
case OMP_CLAUSE_MERGEABLE:
  mergeable_seen = true;
  pc = _CLAUSE_CHAIN (c);
@@ -16333,6 +16343,14 @@ c_finish_omp_clauses (tree clauses, enum
   *nogroup_seen = OMP_CLAUSE_CHAIN (*nogroup_seen);
 }
 
+  if (grainsize_seen && num_tasks_seen)
+{
+  error_at (OMP_CLAUSE_LOCATION (*grainsize_seen),
+   "% clause must not be used together with "
+   "% clause");
+  *grainsize_seen = OMP_CLAUSE_CHAIN (*grainsize_seen);
+}
+
   if (detach_seen)
 {
   if (mergeable_seen)
--- gcc/cp/semantics.cc.jj  2024-05-15 15:43:05.823657545 +0200
+++ gcc/cp/semantics.cc 2024-05-15 15:44:07.085844564 +0200
@@ -7098,6 +7098,7 @@ finish_omp_clauses (tree clauses, enum c
   bool mergeable_seen = false;
   bool implicit_moved = false;
   bool target_in_reduction_seen = false;
+  bool num_tasks_seen = false;
 
   bitmap_obstack_initialize (NULL);
   bitmap_initialize (_head, _default_obstack);
@@ -7656,6 +7657,10 @@ finish_omp_clauses (tree clauses, enum c
  /* FALLTHRU */
 
case OMP_CLAUSE_NUM_TASKS:
+ if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_NUM_TASKS)
+   num_tasks_seen = true;
+ /* FALLTHRU */
+
case OMP_CLAUSE_NUM_TEAMS:
case OMP_CLAUSE_NUM_THREADS:
case OMP_CLAUSE_NUM_GANGS:
@@ -9244,6 +9249,17 @@ finish_omp_clauses (tree clauses, enum c
  *pc = OMP_CLAUSE_CHAIN (c);
  continue;
}
+ pc = _CLAUSE_CHAIN (c);
+ continue;
+   case OMP_CLAUSE_GRAINSIZE:
+ if (num_tasks_seen)
+   {
+ error_at (OMP_CLAUSE_LOCATION (c),
+   "% clause must not be used together with "
+   "% clause");
+ *pc = OMP_CLAUSE_CHAIN (c);
+ continue;
+   }
  pc = _CLAUSE_CHAIN (c);
  continue;
case OMP_CLAUSE_ORDERED:
--- gcc/fortran/openmp.cc.jj2024-03-14 22:06:58.273669790 +0100
+++ gcc/fortran/openmp.cc   2024-05-15 15:43:23.122427979 +0200
@@ -9175,6 +9175,13 @@ resolve_omp_clauses (gfc_code *code, gfc
 resolve_positive_int_expr (omp_clauses->grainsize, "GRAINSIZE");
   if (omp_clauses->num_tasks)
 resolve_positive_int_expr (omp_clauses->num_tasks, "NUM_TASKS");
+  if (omp_clauses->grainsize && omp_clauses->num_tasks)
+gfc_error ("% clause at %L must not be used together with "
+  "% clause", _clauses->grainsize->where);
+  if (omp_clauses->lists[OMP_LIST_REDUCTION] && omp_clauses->nogroup)
+gfc_error ("% clause at %L must not be used together with "
+  "% clause",
+  _clauses->lists[OMP_LIST_REDUCTION]->

[committed] combine: Fix up simplify_compare_const [PR115092]

2024-05-15 Thread Jakub Jelinek
Hi!

The following testcases are miscompiled (with tons of GIMPLE
optimization disabled) because combine sees GE comparison of
1-bit sign_extract (i.e. something with [-1, 0] value range)
with (const_int -1) (which is always true) and optimizes it into
NE comparison of 1-bit zero_extract ([0, 1] value range) against
(const_int 0).
The reason is that simplify_compare_const first (correctly)
simplifies the comparison to
GE (ashift:SI something (const_int 31)) (const_int -2147483648)
and then an optimization for when the second operand is power of 2
triggers.  That optimization is fine for power of 2s which aren't
the signed minimum of the mode, or if it is NE, EQ, GEU or LTU
against the signed minimum of the mode, but for GE or LT optimizing
it into NE (or EQ) against const0_rtx is wrong, those cases
are always true or always false (but the function doesn't have
a standardized way to tell callers the comparison is now unconditional).

The following patch just disables the optimization in that case.

Bootstrapped/regtested on x86_64-linux and i686-linux, preapproved by
Segher in the PR, committed to trunk so far.

2024-05-15  Jakub Jelinek  

PR rtl-optimization/114902
PR rtl-optimization/115092
* combine.cc (simplify_compare_const): Don't optimize
GE op0 SIGNED_MIN or LT op0 SIGNED_MIN into NE op0 const0_rtx or
EQ op0 const0_rtx.

* gcc.dg/pr114902.c: New test.
* gcc.dg/pr115092.c: New test.

--- gcc/combine.cc.jj   2024-05-07 18:10:10.415874636 +0200
+++ gcc/combine.cc  2024-05-15 13:33:26.555081215 +0200
@@ -11852,8 +11852,10 @@ simplify_compare_const (enum rtx_code co
  `and'ed with that bit), we can replace this with a comparison
  with zero.  */
   if (const_op
-  && (code == EQ || code == NE || code == GE || code == GEU
- || code == LT || code == LTU)
+  && (code == EQ || code == NE || code == GEU || code == LTU
+ /* This optimization is incorrect for signed >= INT_MIN or
+< INT_MIN, those are always true or always false.  */
+ || ((code == GE || code == LT) && const_op > 0))
   && is_a  (mode, _mode)
   && GET_MODE_PRECISION (int_mode) - 1 < HOST_BITS_PER_WIDE_INT
   && pow2p_hwi (const_op & GET_MODE_MASK (int_mode))
--- gcc/testsuite/gcc.dg/pr114902.c.jj  2024-05-15 14:01:20.826717914 +0200
+++ gcc/testsuite/gcc.dg/pr114902.c 2024-05-15 14:00:39.603268571 +0200
@@ -0,0 +1,23 @@
+/* PR rtl-optimization/114902 */
+/* { dg-do run } */
+/* { dg-options "-O1 -fno-tree-fre -fno-tree-forwprop -fno-tree-ccp 
-fno-tree-dominator-opts" } */
+
+__attribute__((noipa))
+int foo (int x)
+{
+  int a = ~x;
+  int t = a & 1;
+  int e = -t;
+  int b = e >= -1;
+  if (b)
+return 0;
+  __builtin_trap ();
+}
+
+int
+main ()
+{
+  foo (-1);
+  foo (0);
+  foo (1);
+}
--- gcc/testsuite/gcc.dg/pr115092.c.jj  2024-05-15 13:46:27.634649150 +0200
+++ gcc/testsuite/gcc.dg/pr115092.c 2024-05-15 13:46:12.052857268 +0200
@@ -0,0 +1,16 @@
+/* PR rtl-optimization/115092 */
+/* { dg-do run } */
+/* { dg-options "-O1 -fgcse -ftree-pre -fno-tree-dominator-opts -fno-tree-fre 
-fno-guess-branch-probability" } */
+
+int a, b, c = 1, d, e;
+
+int
+main ()
+{
+  int f, g = a;
+  b = -2;
+  f = -(1 >> ((c && b) & ~a));
+  if (f <= b)
+d = g / e;
+  return 0;
+}

Jakub



[gcc r15-520] combine: Fix up simplify_compare_const [PR115092]

2024-05-15 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:0b93a0ae153ef70a82ff63e67926a01fdab9956b

commit r15-520-g0b93a0ae153ef70a82ff63e67926a01fdab9956b
Author: Jakub Jelinek 
Date:   Wed May 15 18:37:17 2024 +0200

combine: Fix up simplify_compare_const [PR115092]

The following testcases are miscompiled (with tons of GIMPLE
optimization disabled) because combine sees GE comparison of
1-bit sign_extract (i.e. something with [-1, 0] value range)
with (const_int -1) (which is always true) and optimizes it into
NE comparison of 1-bit zero_extract ([0, 1] value range) against
(const_int 0).
The reason is that simplify_compare_const first (correctly)
simplifies the comparison to
GE (ashift:SI something (const_int 31)) (const_int -2147483648)
and then an optimization for when the second operand is power of 2
triggers.  That optimization is fine for power of 2s which aren't
the signed minimum of the mode, or if it is NE, EQ, GEU or LTU
against the signed minimum of the mode, but for GE or LT optimizing
it into NE (or EQ) against const0_rtx is wrong, those cases
are always true or always false (but the function doesn't have
a standardized way to tell callers the comparison is now unconditional).

The following patch just disables the optimization in that case.

2024-05-15  Jakub Jelinek  

PR rtl-optimization/114902
PR rtl-optimization/115092
* combine.cc (simplify_compare_const): Don't optimize
GE op0 SIGNED_MIN or LT op0 SIGNED_MIN into NE op0 const0_rtx or
EQ op0 const0_rtx.

* gcc.dg/pr114902.c: New test.
* gcc.dg/pr115092.c: New test.

Diff:
---
 gcc/combine.cc  |  6 --
 gcc/testsuite/gcc.dg/pr114902.c | 23 +++
 gcc/testsuite/gcc.dg/pr115092.c | 16 
 3 files changed, 43 insertions(+), 2 deletions(-)

diff --git a/gcc/combine.cc b/gcc/combine.cc
index 71c9abc145c2..3b50bc3529c4 100644
--- a/gcc/combine.cc
+++ b/gcc/combine.cc
@@ -11852,8 +11852,10 @@ simplify_compare_const (enum rtx_code code, 
machine_mode mode,
  `and'ed with that bit), we can replace this with a comparison
  with zero.  */
   if (const_op
-  && (code == EQ || code == NE || code == GE || code == GEU
- || code == LT || code == LTU)
+  && (code == EQ || code == NE || code == GEU || code == LTU
+ /* This optimization is incorrect for signed >= INT_MIN or
+< INT_MIN, those are always true or always false.  */
+ || ((code == GE || code == LT) && const_op > 0))
   && is_a  (mode, _mode)
   && GET_MODE_PRECISION (int_mode) - 1 < HOST_BITS_PER_WIDE_INT
   && pow2p_hwi (const_op & GET_MODE_MASK (int_mode))
diff --git a/gcc/testsuite/gcc.dg/pr114902.c b/gcc/testsuite/gcc.dg/pr114902.c
new file mode 100644
index ..60684faa25d5
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr114902.c
@@ -0,0 +1,23 @@
+/* PR rtl-optimization/114902 */
+/* { dg-do run } */
+/* { dg-options "-O1 -fno-tree-fre -fno-tree-forwprop -fno-tree-ccp 
-fno-tree-dominator-opts" } */
+
+__attribute__((noipa))
+int foo (int x)
+{
+  int a = ~x;
+  int t = a & 1;
+  int e = -t;
+  int b = e >= -1;
+  if (b)
+return 0;
+  __builtin_trap ();
+}
+
+int
+main ()
+{
+  foo (-1);
+  foo (0);
+  foo (1);
+}
diff --git a/gcc/testsuite/gcc.dg/pr115092.c b/gcc/testsuite/gcc.dg/pr115092.c
new file mode 100644
index ..c9047f4d321a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr115092.c
@@ -0,0 +1,16 @@
+/* PR rtl-optimization/115092 */
+/* { dg-do run } */
+/* { dg-options "-O1 -fgcse -ftree-pre -fno-tree-dominator-opts -fno-tree-fre 
-fno-guess-branch-probability" } */
+
+int a, b, c = 1, d, e;
+
+int
+main ()
+{
+  int f, g = a;
+  b = -2;
+  f = -(1 >> ((c && b) & ~a));
+  if (f <= b)
+d = g / e;
+  return 0;
+}


[gcc r15-519] openmp: Diagnose using grainsize+num_tasks clauses together [PR115103]

2024-05-15 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:7fdbefc575c24881356b5f4091fa57b5f7166a90

commit r15-519-g7fdbefc575c24881356b5f4091fa57b5f7166a90
Author: Jakub Jelinek 
Date:   Wed May 15 18:34:44 2024 +0200

openmp: Diagnose using grainsize+num_tasks clauses together [PR115103]

I've noticed that while we diagnose many other OpenMP exclusive clauses,
we don't diagnose grainsize together with num_tasks on taskloop construct
in all of C, C++ and Fortran (the implementation simply ignored grainsize
in that case) and for Fortran also don't diagnose mixing nogroup clause
with reduction clause(s).

Fixed thusly.

2024-05-15  Jakub Jelinek  

PR c/115103
gcc/c/
* c-typeck.cc (c_finish_omp_clauses): Diagnose grainsize
used together with num_tasks.
gcc/cp/
* semantics.cc (finish_omp_clauses): Diagnose grainsize
used together with num_tasks.
gcc/fortran/
* openmp.cc (resolve_omp_clauses): Diagnose grainsize
used together with num_tasks or nogroup used together with
reduction.
gcc/testsuite/
* c-c++-common/gomp/clause-dups-1.c: Add 2 further expected errors.
* gfortran.dg/gomp/pr115103.f90: New test.

Diff:
---
 gcc/c/c-typeck.cc   | 22 --
 gcc/cp/semantics.cc | 16 
 gcc/fortran/openmp.cc   |  7 +++
 gcc/testsuite/c-c++-common/gomp/clause-dups-1.c |  4 ++--
 gcc/testsuite/gfortran.dg/gomp/pr115103.f90 | 14 ++
 5 files changed, 59 insertions(+), 4 deletions(-)

diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 4567b114734b..7ecca9f58c68 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -14722,6 +14722,8 @@ c_finish_omp_clauses (tree clauses, enum 
c_omp_region_type ort)
   tree *detach_seen = NULL;
   bool linear_variable_step_check = false;
   tree *nowait_clause = NULL;
+  tree *grainsize_seen = NULL;
+  bool num_tasks_seen = false;
   tree ordered_clause = NULL_TREE;
   tree schedule_clause = NULL_TREE;
   bool oacc_async = false;
@@ -16021,8 +16023,6 @@ c_finish_omp_clauses (tree clauses, enum 
c_omp_region_type ort)
case OMP_CLAUSE_PROC_BIND:
case OMP_CLAUSE_DEVICE_TYPE:
case OMP_CLAUSE_PRIORITY:
-   case OMP_CLAUSE_GRAINSIZE:
-   case OMP_CLAUSE_NUM_TASKS:
case OMP_CLAUSE_THREADS:
case OMP_CLAUSE_SIMD:
case OMP_CLAUSE_HINT:
@@ -16048,6 +16048,16 @@ c_finish_omp_clauses (tree clauses, enum 
c_omp_region_type ort)
  pc = _CLAUSE_CHAIN (c);
  continue;
 
+   case OMP_CLAUSE_GRAINSIZE:
+ grainsize_seen = pc;
+ pc = _CLAUSE_CHAIN (c);
+ continue;
+
+   case OMP_CLAUSE_NUM_TASKS:
+ num_tasks_seen = true;
+ pc = _CLAUSE_CHAIN (c);
+ continue;
+
case OMP_CLAUSE_MERGEABLE:
  mergeable_seen = true;
  pc = _CLAUSE_CHAIN (c);
@@ -16333,6 +16343,14 @@ c_finish_omp_clauses (tree clauses, enum 
c_omp_region_type ort)
   *nogroup_seen = OMP_CLAUSE_CHAIN (*nogroup_seen);
 }
 
+  if (grainsize_seen && num_tasks_seen)
+{
+  error_at (OMP_CLAUSE_LOCATION (*grainsize_seen),
+   "% clause must not be used together with "
+   "% clause");
+  *grainsize_seen = OMP_CLAUSE_CHAIN (*grainsize_seen);
+}
+
   if (detach_seen)
 {
   if (mergeable_seen)
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index df62e2d80dbd..f90c304a65b7 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -7098,6 +7098,7 @@ finish_omp_clauses (tree clauses, enum c_omp_region_type 
ort)
   bool mergeable_seen = false;
   bool implicit_moved = false;
   bool target_in_reduction_seen = false;
+  bool num_tasks_seen = false;
 
   bitmap_obstack_initialize (NULL);
   bitmap_initialize (_head, _default_obstack);
@@ -7656,6 +7657,10 @@ finish_omp_clauses (tree clauses, enum c_omp_region_type 
ort)
  /* FALLTHRU */
 
case OMP_CLAUSE_NUM_TASKS:
+ if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_NUM_TASKS)
+   num_tasks_seen = true;
+ /* FALLTHRU */
+
case OMP_CLAUSE_NUM_TEAMS:
case OMP_CLAUSE_NUM_THREADS:
case OMP_CLAUSE_NUM_GANGS:
@@ -9246,6 +9251,17 @@ finish_omp_clauses (tree clauses, enum c_omp_region_type 
ort)
}
  pc = _CLAUSE_CHAIN (c);
  continue;
+   case OMP_CLAUSE_GRAINSIZE:
+ if (num_tasks_seen)
+   {
+ error_at (OMP_CLAUSE_LOCATION (c),
+   "% clause must not be used together with "
+   "% clause");
+ *pc = OMP_CLAUSE_CHAIN (c);
+ continue;
+   }
+ pc = _CLAUSE_CHAIN (c);
+ continue;
case OMP_CLAUSE_ORDERED:
  if (reduction_seen == -2)
error_at (OMP_CLAUSE_LOCATI

Re: [PATCH] middle-end/111422 - wrong stack var coalescing, handle PHIs

2024-05-15 Thread Jakub Jelinek
On Wed, May 15, 2024 at 01:41:04PM +0200, Richard Biener wrote:
>   PR middle-end/111422
>   * cfgexpand.cc (add_scope_conflicts_2): Handle PHIs
>   by recursing to their arguments.
> ---
>  gcc/cfgexpand.cc | 21 +
>  1 file changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/gcc/cfgexpand.cc b/gcc/cfgexpand.cc
> index 557cb28733b..e4d763fa998 100644
> --- a/gcc/cfgexpand.cc
> +++ b/gcc/cfgexpand.cc
> @@ -584,10 +584,23 @@ add_scope_conflicts_2 (tree use, bitmap work,
> || INTEGRAL_TYPE_P (TREE_TYPE (use
>  {
>gimple *g = SSA_NAME_DEF_STMT (use);
> -  if (is_gimple_assign (g))
> - if (tree op = gimple_assign_rhs1 (g))
> -   if (TREE_CODE (op) == ADDR_EXPR)
> - visit (g, TREE_OPERAND (op, 0), op, work);
> +  if (gassign *a = dyn_cast  (g))
> + {
> +   if (tree op = gimple_assign_rhs1 (a))
> + if (TREE_CODE (op) == ADDR_EXPR)
> +   visit (a, TREE_OPERAND (op, 0), op, work);
> + }
> +  else if (gphi *p = dyn_cast  (g))
> + {
> +   for (unsigned i = 0; i < gimple_phi_num_args (p); ++i)
> + if (TREE_CODE (use = gimple_phi_arg_def (p, i)) == SSA_NAME)
> +   if (gassign *a = dyn_cast  (SSA_NAME_DEF_STMT (use)))
> + {
> +   if (tree op = gimple_assign_rhs1 (a))
> + if (TREE_CODE (op) == ADDR_EXPR)
> +   visit (a, TREE_OPERAND (op, 0), op, work);
> + }
> + }

Why the 2 {} pairs here?  Can't it be done without them (sure, before the
else if it is required)?

Otherwise LGTM.

Jakub



Re: GCC 13.3 Release Candidate available from gcc.gnu.org

2024-05-14 Thread Jakub Jelinek via Gcc
On Tue, May 14, 2024 at 06:31:19PM +0200, Jakub Jelinek via Gcc wrote:
> If all goes well, we'd like to release 13.3 on Thursday, May 21st.

Tuesday, May 21st.  Sorry for the pasto.

Jakub



gcc-wwwdocs branch master updated. 8f193930f0beb38d06b143bcc1d5632f457e0cdf

2024-05-14 Thread Jakub Jelinek via Gcc-cvs-wwwdocs
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gcc-wwwdocs".

The branch, master has been updated
   via  8f193930f0beb38d06b143bcc1d5632f457e0cdf (commit)
  from  ed2a7a47d4814413db7ac79068d7938c03ad639f (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 8f193930f0beb38d06b143bcc1d5632f457e0cdf
Author: Jakub Jelinek 
Date:   Tue May 14 18:33:07 2024 +0200

Mark 13.3 as frozen for release.

diff --git a/htdocs/index.html b/htdocs/index.html
index de5cca7b..63fbcdcd 100644
--- a/htdocs/index.html
+++ b/htdocs/index.html
@@ -168,7 +168,7 @@ More news? Let ger...@pfeifer.com know!
   
   https://gcc.gnu.org/pipermail/gcc/2024-April/243860.html;>2024-04-30
   
-  (regression fixes  docs only).
+  (frozen for release).
   
   https://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advancedshort_desc_type=regexpshort_desc=%5C%5B(%5B%200-9.%2F%5D*%5B%20%2F%5D)*13%5B%20%2F%5D%5B%200-9.%2F%5D*%5BRr%5Degression%20*%5C%5Dtarget_milestone=11.5target_milestone=12.4target_milestone=13.3known_to_fail_type=allwordssubstrknown_to_work_type=allwordssubstrlong_desc_type=allwordssubstrlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=gcchost_type=allwordssubstrgcchost=gcctarget_type=allwordssubstrgcctarget=gccbuild_type=allwordssubstrgccbuild=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=SUSPENDEDbug_status=WAITINGbug_status=REOPENEDpriority=P1priority=P2priority=P3emailtype1=substringemail1=emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Now
 
;chfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0=">Serious

---

Summary of changes:
 htdocs/index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
gcc-wwwdocs


GCC 13.3 Release Candidate available from gcc.gnu.org

2024-05-14 Thread Jakub Jelinek via Gcc
The first release candidate for GCC 13.3 is available from

 https://gcc.gnu.org/pub/gcc/snapshots/13.3.0-RC-20240514/
 ftp://gcc.gnu.org/pub/gcc/snapshots/13.3.0-RC-20240514/

and shortly its mirrors.  It has been generated from git commit
r13-8774-g1db45e83021a8a.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.
Please test it and report any issues to bugzilla.

If all goes well, we'd like to release 13.3 on Thursday, May 21st.



Re: [PATCHv2] Value range: Add range op for __builtin_isfinite

2024-05-14 Thread Jakub Jelinek
On Tue, May 07, 2024 at 10:37:55AM +0800, HAO CHEN GUI wrote:
>   The former patch adds isfinite optab for __builtin_isfinite.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649339.html
> 
>   Thus the builtin might not be folded at front end. The range op for
> isfinite is needed for value range analysis. This patch adds them.
> 
>   Compared to last version, this version fixes a typo.
> 
>   Bootstrapped and tested on x86 and powerpc64-linux BE and LE with no
> regressions. Is it OK for the trunk?
> 
> Thanks
> Gui Haochen
> 
> ChangeLog
> Value Range: Add range op for builtin isfinite
> 
> The former patch adds optab for builtin isfinite. Thus builtin isfinite might
> not be folded at front end.  So the range op for isfinite is needed for value
> range analysis.  This patch adds range op for builtin isfinite.
> 
> gcc/
>   * gimple-range-op.cc (class cfn_isfinite): New.
>   (op_cfn_finite): New variables.
>   (gimple_range_op_handler::maybe_builtin_call): Handle
>   CFN_BUILT_IN_ISFINITE.
> 
> gcc/testsuite/
>   * gcc/testsuite/gcc.dg/tree-ssa/range-isfinite.c: New test.

BUILT_IN_ISFINITE is just one of many BUILT_IN_IS... builtins,
would be nice to handle the others as well.

E.g. isnormal/isnan/isinf, fpclassify etc.

Note, the man page says for e.g. isnormal that it returns nonzero or zero,
but in reality I think we implement it always inline and can check if
it always returns [0,1].
Some others like isinf return [-1,1] though I think and fpclassify
returns union of all the passed int values.

Jakub



Re: [PATCH] [testsuite] Fix gcc.dg/pr115066.c fail on aarch64

2024-05-14 Thread Jakub Jelinek
On Tue, May 14, 2024 at 03:47:46PM +0200, Tom de Vries wrote:
> On aarch64, I get this failure:
> ...
> FAIL: gcc.dg/pr115066.c scan-assembler \\.byte\\t0xb\\t# Define macro strx
> ...
> 
> This happens because we expect to match:
> ...
> .byte   0xb # Define macro strx
> ...
> but instead we get:
> ...
> .byte   0xb // Define macro strx
> ...
> 
> Fix this by not explicitly matching the comment marker.
> 
> Tested on aarch64 and x86_64.
> 
> gcc/testsuite/ChangeLog:
> 
> 2024-05-14  Tom de Vries  
> 
> * gcc.dg/pr115066.c: Don't match comment marker.
> ---
>  gcc/testsuite/gcc.dg/pr115066.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.dg/pr115066.c b/gcc/testsuite/gcc.dg/pr115066.c
> index 645757df209..a7e98500160 100644
> --- a/gcc/testsuite/gcc.dg/pr115066.c
> +++ b/gcc/testsuite/gcc.dg/pr115066.c
> @@ -2,7 +2,7 @@
>  /* { dg-skip-if "split DWARF unsupported" { hppa*-*-hpux* powerpc*-ibm-aix* 
> *-*-darwin* } } */
>  /* { dg-options "-gsplit-dwarf -g3 -dA -gdwarf-4" } */
>  /* { dg-final { scan-assembler-times {\.section\t"?\.debug_macro} 1 } } */
> -/* { dg-final { scan-assembler-not {\.byte\t0x5\t# Define macro strp} } } */
> -/* { dg-final { scan-assembler {\.byte\t0xb\t# Define macro strx} } } */
> +/* { dg-final { scan-assembler-not {\.byte\t0x5\t.* Define macro strp} } } */
> +/* { dg-final { scan-assembler {\.byte\t0xb\t.* Define macro strx} } } */

Actually, perhaps better use [^\n\r]* instead of .*
You don't want to match the comment on a different line.

Jakub



Re: [PATCH] [testsuite] Fix gcc.dg/pr115066.c fail on aarch64

2024-05-14 Thread Jakub Jelinek
On Tue, May 14, 2024 at 03:47:46PM +0200, Tom de Vries wrote:
> On aarch64, I get this failure:
> ...
> FAIL: gcc.dg/pr115066.c scan-assembler \\.byte\\t0xb\\t# Define macro strx
> ...
> 
> This happens because we expect to match:
> ...
> .byte   0xb # Define macro strx
> ...
> but instead we get:
> ...
> .byte   0xb // Define macro strx
> ...
> 
> Fix this by not explicitly matching the comment marker.
> 
> Tested on aarch64 and x86_64.
> 
> gcc/testsuite/ChangeLog:
> 
> 2024-05-14  Tom de Vries  
> 
> * gcc.dg/pr115066.c: Don't match comment marker.
> ---
>  gcc/testsuite/gcc.dg/pr115066.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Ok.

Jakub



Re: [PATCH] [debug] Fix dwarf v4 .debug_macro.dwo

2024-05-14 Thread Jakub Jelinek
On Tue, May 14, 2024 at 01:35:30PM +0200, Tom de Vries wrote:
> Consider a hello world, compiled with -gsplit-dwarf and dwarf version 4, and 
> -g3:
> ...
> $ gcc -gdwarf-4 -gsplit-dwarf /data/vries/hello.c -g3 -save-temps -dA
> ...
> 
> In section .debug_macro.dwo, we have:
> ...
> .Ldebug_macro0:
> .value  0x4 # DWARF macro version number
> .byte   0x2 # Flags: 32-bit, lineptr present
> .long   .Lskeleton_debug_line0
> .byte   0x3 # Start new file
> .uleb128 0  # Included from line number 0
> .uleb128 0x1# file /data/vries/hello.c
> .byte   0x5 # Define macro strp
> .uleb128 0  # At line number 0
> .uleb128 0x1d0  # The macro: "__STDC__ 1"
> ...
> 
> Given that we use a DW_MACRO_define_strp, we'd expect 0x1d0 to be an
> offset into a .debug_str.dwo section.
> 
> But in fact, 0x1d0 is an index into the string offset table in
> .debug_str_offsets.dwo:
> ...
> .long   0x34f0  # indexed string 0x1d0: __STDC__ 1
> ...
> 
> Add asserts that catch this inconsistency, and fix this by using
> DW_MACRO_define_strx instead.
> 
> Tested on x86_64.
> 
> PR debug/115066

ChangeLog entry is missing.

Otherwise LGTM.

Jakub



[gcc r13-8764] Manually add ChangeLog entries for various commits from 2024-05-09.

2024-05-13 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:2e353c687dbd343ce592c5ec089774b2c699798a

commit r13-8764-g2e353c687dbd343ce592c5ec089774b2c699798a
Author: Jakub Jelinek 
Date:   Mon May 13 15:09:04 2024 +0200

Manually add ChangeLog entries for various commits from 2024-05-09.

Diff:
---
 gcc/analyzer/ChangeLog  | 84 +
 gcc/jit/ChangeLog   |  8 +
 gcc/testsuite/ChangeLog | 79 ++
 3 files changed, 171 insertions(+)

diff --git a/gcc/analyzer/ChangeLog b/gcc/analyzer/ChangeLog
index 5f1171c0da89..d3a520c19848 100644
--- a/gcc/analyzer/ChangeLog
+++ b/gcc/analyzer/ChangeLog
@@ -7,6 +7,19 @@
(register_sanitizer_builtins): New.
(register_known_functions): Call register_sanitizer_builtins.
 
+2024-05-09  David Malcolm 
+
+   Backported from master:
+   2024-03-27  David Malcolm  
+
+   PR analyzer/114473
+   * call-summary.cc
+   (call_summary_replay::convert_svalue_from_summary): Assert that
+   the types match.
+   (call_summary_replay::convert_region_from_summary): Likewise.
+   (call_summary_replay::convert_region_from_summary_1): Add missing
+   cast for the deref of RK_SYMBOLIC case.
+
 2024-05-09  David Malcolm  
 
PR analyzer/109251
@@ -23,6 +36,19 @@
(kf_va_arg::impl_call_pre): Pass arg_sval to
va_arg_compatible_types_p.
 
+2024-05-09  David Malcolm 
+
+   Backported from master:
+   2024-01-31  David Malcolm  
+   PR analyzer/113253
+   * region-model.cc (region_model::on_stmt_pre): Add gcc_unreachable
+   for debug statements.
+   * state-purge.cc
+   (state_purge_per_ssa_name::state_purge_per_ssa_name): Skip any
+   debug stmts in the FOR_EACH_IMM_USE_FAST list.
+   * supergraph.cc (supergraph::supergraph): Don't add debug stmts
+   to the supernodes.
+
 2024-05-09  David Malcolm  
 
PR analyzer/112969
@@ -58,6 +84,64 @@
(concrete_binding::is_deleted): Likewise.
(concrete_binding::is_empty): Likewise.
 
+2024-05-09  David Malcolm 
+
+   Backported from master:
+   2023-08-03  David Malcolm  
+
+   PR analyzer/110882
+   * region.cc (int_size_in_bits): Fail on zero-sized types.
+
+2024-05-09  David Malcolm 
+
+   Backported from master:
+   2023-07-19  David Malcolm  
+
+   PR analyzer/110700
+   * region-model-manager.cc
+   (region_model_manager::get_or_create_int_cst): Assert that we have
+   an integral or pointer type.
+   * sm-taint.cc (taint_state_machine::check_for_tainted_divisor):
+   Don't check non-integral types.
+
+2024-05-09  Tim Lange  
+
+   Backported from master:
+   2023-06-09  Tim Lange  
+
+   PR analyzer/109577
+   * constraint-manager.cc (class sval_finder): Visitor to find
+   childs in svalue trees.
+   (constraint_manager::sval_constrained_p): Add new function to
+   check whether a sval might be part of an constraint.
+   * constraint-manager.h: Add sval_constrained_p function.
+   * region-model.cc (class size_visitor): Reverse behavior to not
+   emit a warning on not explicitly considered cases.
+   (region_model::check_region_size):
+   Adapt to size_visitor changes.
+
+2024-05-09  David Malcolm 
+
+   Backported from master:
+   2023-06-09  David Malcolm  
+
+   PR analyzer/110112
+   * region-model.cc (region_model::get_initial_value_for_global):
+   Move code to region::calc_initial_value_at_main.
+   * region.cc (region::get_initial_value_at_main): New function.
+   (region::calc_initial_value_at_main): New function, based on code
+   in region_model::get_initial_value_for_global.
+   (region::region): Initialize m_cached_init_sval_at_main.
+   (decl_region::get_svalue_for_constructor): Add a cache, splitting
+   out body to...
+   (decl_region::calc_svalue_for_constructor): ...this new function.
+   * region.h (region::get_initial_value_at_main): New decl.
+   (region::calc_initial_value_at_main): New decl.
+   (region::m_cached_init_sval_at_main): New field.
+   (decl_region::decl_region): Initialize m_ctor_svalue.
+   (decl_region::calc_svalue_for_constructor): New decl.
+   (decl_region::m_ctor_svalue): New field.
+
 2023-07-27  Release Manager
 
* GCC 13.2.0 released.
diff --git a/gcc/jit/ChangeLog b/gcc/jit/ChangeLog
index 986c831a2729..07708072688f 100644
--- a/gcc/jit/ChangeLog
+++ b/gcc/jit/ChangeLog
@@ -1,3 +1,11 @@
+2024-05-09  Vibhav Pant  
+
+   Backported from master:
+   2023-10-25  Vibhav Pant  
+
+   * jit-recording.cc (recording::global::write_to_dump): Fix
+   dump of string literal initializers.
+
 2024-04-05  Iain Sandoe  
 
Backported from master:
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 23a89209aeb7..878fb8f22549 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -9,6 +9,14

Re: [PATCH] c++: Optimize in maybe_clone_body aliases even when not at_eof [PR113208]

2024-05-13 Thread Jakub Jelinek
On Fri, May 10, 2024 at 03:59:25PM -0400, Jason Merrill wrote:
> > 2024-05-09  Jakub Jelinek  
> > Jason Merrill  
> > 
> > PR lto/113208
> > * cp-tree.h (maybe_optimize_cdtor): Remove.
> > * decl2.cc (tentative_decl_linkage): Call maybe_make_one_only
> > for implicit instantiations of maybe in charge ctors/dtors
> > declared inline.
> > (import_export_decl): Don't call maybe_optimize_cdtor.
> > (c_parse_final_cleanups): Formatting fixes.
> > * optimize.cc (can_alias_cdtor): Adjust condition, for
> > HAVE_COMDAT_GROUP && DECL_ONE_ONLY && DECL_WEAK return true even
> > if not DECL_INTERFACE_KNOWN.
> 
> > --- gcc/cp/optimize.cc.jj   2024-04-25 20:33:30.771858912 +0200
> > +++ gcc/cp/optimize.cc  2024-05-09 17:10:23.920478922 +0200
> > @@ -220,10 +220,8 @@ can_alias_cdtor (tree fn)
> > gcc_assert (DECL_MAYBE_IN_CHARGE_CDTOR_P (fn));
> > /* Don't use aliases for weak/linkonce definitions unless we can put 
> > both
> >symbols in the same COMDAT group.  */
> > -  return (DECL_INTERFACE_KNOWN (fn)
> > - && (SUPPORTS_ONE_ONLY || !DECL_WEAK (fn))
> > - && (!DECL_ONE_ONLY (fn)
> > - || (HAVE_COMDAT_GROUP && DECL_WEAK (fn;
> > +  return (DECL_WEAK (fn) ? (HAVE_COMDAT_GROUP && DECL_ONE_ONLY (fn))
> > +: (DECL_INTERFACE_KNOWN (fn) && !DECL_ONE_ONLY (fn)));
> 
> Hmm, would
> 
> (DECL_ONE_ONLY (fn) ? HAVE_COMDAT_GROUP
>  : (DECL_INTERFACE_KNOWN (fn) && !DECL_WEAK (fn)))
> 
> make sense instead?  I don't think DECL_WEAK is necessary for COMDAT.

I think it isn't indeed necessary for COMDAT, although e.g. comdat_linkage
will not call make_decl_one_only if !flag_weak.

But I think it is absolutely required for the alias cdtor optimization
in question, because otherwise it would be an ABI change.
Consider older version of GCC or some other compiler emitting
_ZN6vectorI12QualityValueEC1ERKS1_
and
_ZN6vectorI12QualityValueEC2ERKS1_
symbols not as aliases, each in their own comdat groups, so
.text._ZN6vectorI12QualityValueEC1ERKS1_ in _ZN6vectorI12QualityValueEC1ERKS1_
comdat group and
.text._ZN6vectorI12QualityValueEC2ERKS1_ in _ZN6vectorI12QualityValueEC2ERKS1_
comdat group.  And then comes GCC with the above patch without the DECL_WEAK
check in there, and decides to use alias, so
_ZN6vectorI12QualityValueEC1ERKS1_ is an alias to
_ZN6vectorI12QualityValueEC2ERKS1_ and both live in
.text._ZN6vectorI12QualityValueEC2ERKS1_ section in
_ZN6vectorI12QualityValueEC5ERKS1_ comdat group.  If you mix TUs with this,
the linker can keep one of the section sets from the 
_ZN6vectorI12QualityValueEC1ERKS1_
and _ZN6vectorI12QualityValueEC2ERKS1_ and _ZN6vectorI12QualityValueEC5ERKS1_
comdat groups.  If there is no .weak for the symbols, this will fail to
link, one can emit it either the old way or the new way but never both, it
is part of an ABI.
While with .weak, mixing it is possible, worst case one gets some unused
code in the linked binary or shared library.  Of course the desirable case
is that there is no mixing and there is no unused code, but if it happens,
no big deal.  Without .weak it is a big deal.

Jakub



[gcc r15-427] tree-ssa-math-opts: Pattern recognize yet another .ADD_OVERFLOW pattern [PR113982]

2024-05-13 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:b621482296f6dec0abb22ed39cc4ce6811535d47

commit r15-427-gb621482296f6dec0abb22ed39cc4ce6811535d47
Author: Jakub Jelinek 
Date:   Mon May 13 11:15:27 2024 +0200

tree-ssa-math-opts: Pattern recognize yet another .ADD_OVERFLOW pattern 
[PR113982]

We pattern recognize already many different patterns, and closest to the
requested one also
   yc = (type) y;
   zc = (type) z;
   x = yc + zc;
   w = (typeof_y) x;
   if (x > max)
where y/z has the same unsigned type and type is a wider unsigned type
and max is maximum value of the narrower unsigned type.
But apparently people are creative in writing this in diffent ways,
this requests
   yc = (type) y;
   zc = (type) z;
   x = yc + zc;
   w = (typeof_y) x;
   if (x >> narrower_type_bits)

The following patch implements that.

2024-05-13  Jakub Jelinek  

PR middle-end/113982
* tree-ssa-math-opts.cc (arith_overflow_check_p): Also return 1
for RSHIFT_EXPR by precision of maxval if shift result is only
used in a cast or comparison against zero.
(match_arith_overflow): Handle the RSHIFT_EXPR use case.

* gcc.dg/pr113982.c: New test.

Diff:
---
 gcc/testsuite/gcc.dg/pr113982.c |  60 
 gcc/tree-ssa-math-opts.cc   | 121 ++--
 2 files changed, 177 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/pr113982.c b/gcc/testsuite/gcc.dg/pr113982.c
new file mode 100644
index ..4c5be6cc832e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr113982.c
@@ -0,0 +1,60 @@
+/* PR middle-end/113982 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-widening_mul" } */
+
+#if __SIZEOF_INT128__
+typedef __uint128_t W;
+typedef unsigned long long T;
+#else
+typedef unsigned long long W;
+typedef unsigned int T;
+#endif
+#define B __CHAR_BIT__ * sizeof (T)
+
+struct S { int p; T r; };
+
+struct S
+foo (T x, T y)
+{
+  W z = (W) x + y;
+  return (struct S) { z >> B, (T) z };
+}
+
+struct S
+bar (T x)
+{
+  W z = (W) x + 132;
+  return (struct S) { z >> B, (T) z };
+}
+
+struct S
+baz (T x, unsigned short y)
+{
+  W z = (W) x + y;
+  return (struct S) { z >> B, (T) z };
+}
+
+struct S
+qux (unsigned short x, T y)
+{
+  W z = (W) x + y;
+  return (struct S) { z >> B, (T) z };
+}
+
+struct S
+corge (T x, T y)
+{
+  T w = x + y;
+  W z = (W) x + y;
+  return (struct S) { z >> B, w };
+}
+
+struct S
+garple (T x, T y)
+{
+  W z = (W) x + y;
+  T w = x + y;
+  return (struct S) { z >> B, w };
+}
+
+/* { dg-final { scan-tree-dump-times "ADD_OVERFLOW" 6 "widening_mul" { target 
{ i?86-*-* x86_64-*-* } } } } */
diff --git a/gcc/tree-ssa-math-opts.cc b/gcc/tree-ssa-math-opts.cc
index 705f4a4695ac..e8c804f09b7f 100644
--- a/gcc/tree-ssa-math-opts.cc
+++ b/gcc/tree-ssa-math-opts.cc
@@ -3947,6 +3947,66 @@ arith_overflow_check_p (gimple *stmt, gimple *cast_stmt, 
gimple *_stmt,
   else
 return 0;
 
+  if (maxval
+  && ccode == RSHIFT_EXPR
+  && crhs1 == lhs
+  && TREE_CODE (crhs2) == INTEGER_CST
+  && wi::to_widest (crhs2) == TYPE_PRECISION (TREE_TYPE (maxval)))
+{
+  tree shiftlhs = gimple_assign_lhs (use_stmt);
+  if (!shiftlhs)
+   return 0;
+  use_operand_p use;
+  if (!single_imm_use (shiftlhs, , _use_stmt))
+   return 0;
+  if (gimple_code (cur_use_stmt) == GIMPLE_COND)
+   {
+ ccode = gimple_cond_code (cur_use_stmt);
+ crhs1 = gimple_cond_lhs (cur_use_stmt);
+ crhs2 = gimple_cond_rhs (cur_use_stmt);
+   }
+  else if (is_gimple_assign (cur_use_stmt))
+   {
+ if (gimple_assign_rhs_class (cur_use_stmt) == GIMPLE_BINARY_RHS)
+   {
+ ccode = gimple_assign_rhs_code (cur_use_stmt);
+ crhs1 = gimple_assign_rhs1 (cur_use_stmt);
+ crhs2 = gimple_assign_rhs2 (cur_use_stmt);
+   }
+ else if (gimple_assign_rhs_code (cur_use_stmt) == COND_EXPR)
+   {
+ tree cond = gimple_assign_rhs1 (cur_use_stmt);
+ if (COMPARISON_CLASS_P (cond))
+   {
+ ccode = TREE_CODE (cond);
+ crhs1 = TREE_OPERAND (cond, 0);
+ crhs2 = TREE_OPERAND (cond, 1);
+   }
+ else
+   return 0;
+   }
+ else
+   {
+ enum tree_code sc = gimple_assign_rhs_code (cur_use_stmt);
+ tree castlhs = gimple_assign_lhs (cur_use_stmt);
+ if (!CONVERT_EXPR_CODE_P (sc)
+ || !castlhs
+ || !INTEGRAL_TYPE_P (TREE_TYPE (castlhs))
+ || (TYPE_PRECISION (TREE_TYPE (castlhs))
+ > TYPE_PRECISION (TREE_TYPE (maxval
+   return 0;
+ return 1;
+   

[gcc r15-426] Manually add ChangeLog entry for r15-353-gd7bb8eaade3cd3aa70715c8567b4d7b08098e699

2024-05-13 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:f3f02a750c7b34b751fa809ab03d29b2ccf0785d

commit r15-426-gf3f02a750c7b34b751fa809ab03d29b2ccf0785d
Author: Jakub Jelinek 
Date:   Mon May 13 11:07:59 2024 +0200

Manually add ChangeLog entry for 
r15-353-gd7bb8eaade3cd3aa70715c8567b4d7b08098e699

Diff:
---
 gcc/ChangeLog | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 68c11340a9c6..5d57c861fb62 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -247,6 +247,32 @@
* config/riscv/bitmanip.md: Add splitter for shadd feeding another
add instruction.
 
+2024-05-10  Aldy Hernandez  
+
+   Revert:
+   2024-05-08  Aldy Hernandez  
+
+   * gimple-range-cache.cc (sbr_sparse_bitmap::sbr_sparse_bitmap):
+   Change irange to prange.
+   * gimple-range-fold.cc (fold_using_range::fold_stmt): Same.
+   (fold_using_range::range_of_address): Same.
+   * gimple-range-fold.h (range_of_address): Same.
+   * gimple-range-infer.cc (gimple_infer_range::add_nonzero): Same.
+   * gimple-range-op.cc (class cfn_strlen): Same.
+   * gimple-range-path.cc
+   (path_range_query::adjust_for_non_null_uses): Same.
+   * gimple-ssa-warn-access.cc (pass_waccess::check_pointer_uses): Same.
+   * tree-ssa-structalias.cc (find_what_p_points_to): Same.
+   * range-op-ptr.cc (range_op_table::initialize_pointer_ops): Remove
+   hybrid entries in table.
+   * range-op.cc (range_op_table::range_op_table): Add pointer
+   entries for bitwise and/or and min/max.
+   * value-range.cc (irange::verify_range): Add assert.
+   * value-range.h (irange::varying_compatible_p): Remove check for
+   error_mark_node.
+   (irange::supports_p): Remove pointer support.
+   * ipa-cp.h (ipa_supports_p): Add prange support.
+
 2024-05-09  Roger Sayle  
 
* simplify-rtx.cc (simplify_const_binary_operation): Constant


Re: [pushed 00/21] Various backports to gcc 13 (analyzer, jit, diagnostics)

2024-05-13 Thread Jakub Jelinek
On Thu, May 09, 2024 at 01:42:15PM -0400, David Malcolm wrote:
> I've pushed the following changes to releases/gcc-13
> as r13-8741-g89feb3557a0188 through r13-8761-gb7a2697733d19a.

Unfortunately many of the commits contained git commit message wording
that update_git_version can't cope with.
Wording like
(cherry picked from commit r14-1664-gfe9771b59f576f)
is wrong,
(cherry picked from commit .)
is reserved solely for what one gets from git cherry-pick -x
(i.e. the full commit hash without anything extra).

I had to ignore the following commits in the ChangeLog generation
because of this:

89feb3557a018893cfe50c2e07f91559bd3cde2b
ccf8d3e3d26c6ba3d5e11fffeed8d64018e9c060
e0c52905f666e3d23881f82dbf39466a24f009f4
b38472ffc1e631bd357573b44d956ce16d94e666
a0b13d0860848dd5f2876897ada1e22e4e681e91
b8c772cae97b54386f7853edf0f9897012bfa90b
810d35a7e054bcbb5b66d2e5924428e445f5fba9
0df1ee083434ac00ecb19582b1e5b25e105981b2
2c688f6afce4cbb414f5baab1199cd525f309fca
60dcb710b6b4aa22ea96abc8df6dfe9067f3d7fe
44968a0e00f656e9bb3e504bb2fa1a8282002015

Can you please add the ChangeLog entries for these by hand
(commits which only touch ChangeLog files are allowed and shouldn't
contain ChangeLog style entry in the commit message)?

Thanks.

Jakub



[PATCH] tree-ssa-math-opts: Pattern recognize yet another .ADD_OVERFLOW pattern [PR113982]

2024-05-13 Thread Jakub Jelinek
Hi!

We pattern recognize already many different patterns, and closest to the
requested one also
   yc = (type) y;
   zc = (type) z;
   x = yc + zc;
   w = (typeof_y) x;
   if (x > max)
where y/z has the same unsigned type and type is a wider unsigned type
and max is maximum value of the narrower unsigned type.
But apparently people are creative in writing this in diffent ways,
this requests
   yc = (type) y;
   zc = (type) z;
   x = yc + zc;
   w = (typeof_y) x;
   if (x >> narrower_type_bits)

The following patch implements that.

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

2024-05-13  Jakub Jelinek  

PR middle-end/113982
* tree-ssa-math-opts.cc (arith_overflow_check_p): Also return 1
for RSHIFT_EXPR by precision of maxval if shift result is only
used in a cast or comparison against zero.
(match_arith_overflow): Handle the RSHIFT_EXPR use case.

* gcc.dg/pr113982.c: New test.

--- gcc/tree-ssa-math-opts.cc.jj2024-04-11 09:26:36.318369218 +0200
+++ gcc/tree-ssa-math-opts.cc   2024-05-10 18:17:08.795744811 +0200
@@ -3947,6 +3947,66 @@ arith_overflow_check_p (gimple *stmt, gi
   else
 return 0;
 
+  if (maxval
+  && ccode == RSHIFT_EXPR
+  && crhs1 == lhs
+  && TREE_CODE (crhs2) == INTEGER_CST
+  && wi::to_widest (crhs2) == TYPE_PRECISION (TREE_TYPE (maxval)))
+{
+  tree shiftlhs = gimple_assign_lhs (use_stmt);
+  if (!shiftlhs)
+   return 0;
+  use_operand_p use;
+  if (!single_imm_use (shiftlhs, , _use_stmt))
+   return 0;
+  if (gimple_code (cur_use_stmt) == GIMPLE_COND)
+   {
+ ccode = gimple_cond_code (cur_use_stmt);
+ crhs1 = gimple_cond_lhs (cur_use_stmt);
+ crhs2 = gimple_cond_rhs (cur_use_stmt);
+   }
+  else if (is_gimple_assign (cur_use_stmt))
+   {
+ if (gimple_assign_rhs_class (cur_use_stmt) == GIMPLE_BINARY_RHS)
+   {
+ ccode = gimple_assign_rhs_code (cur_use_stmt);
+ crhs1 = gimple_assign_rhs1 (cur_use_stmt);
+ crhs2 = gimple_assign_rhs2 (cur_use_stmt);
+   }
+ else if (gimple_assign_rhs_code (cur_use_stmt) == COND_EXPR)
+   {
+ tree cond = gimple_assign_rhs1 (cur_use_stmt);
+ if (COMPARISON_CLASS_P (cond))
+   {
+ ccode = TREE_CODE (cond);
+ crhs1 = TREE_OPERAND (cond, 0);
+ crhs2 = TREE_OPERAND (cond, 1);
+   }
+ else
+   return 0;
+   }
+ else
+   {
+ enum tree_code sc = gimple_assign_rhs_code (cur_use_stmt);
+ tree castlhs = gimple_assign_lhs (cur_use_stmt);
+ if (!CONVERT_EXPR_CODE_P (sc)
+ || !castlhs
+ || !INTEGRAL_TYPE_P (TREE_TYPE (castlhs))
+ || (TYPE_PRECISION (TREE_TYPE (castlhs))
+ > TYPE_PRECISION (TREE_TYPE (maxval
+   return 0;
+ return 1;
+   }
+   }
+  else
+   return 0;
+  if ((ccode != EQ_EXPR && ccode != NE_EXPR)
+ || crhs1 != shiftlhs
+ || !integer_zerop (crhs2))
+   return 0;
+  return 1;
+}
+
   if (TREE_CODE_CLASS (ccode) != tcc_comparison)
 return 0;
 
@@ -4049,6 +4109,7 @@ arith_overflow_check_p (gimple *stmt, gi
_8 = IMAGPART_EXPR <_7>;
if (_8)
and replace (utype) x with _9.
+   Or with x >> popcount (max) instead of x > max.
 
Also recognize:
x = ~z;
@@ -4481,10 +4542,62 @@ match_arith_overflow (gimple_stmt_iterat
  gcc_checking_assert (is_gimple_assign (use_stmt));
  if (gimple_assign_rhs_class (use_stmt) == GIMPLE_BINARY_RHS)
{
- gimple_assign_set_rhs1 (use_stmt, ovf);
- gimple_assign_set_rhs2 (use_stmt, build_int_cst (type, 0));
- gimple_assign_set_rhs_code (use_stmt,
- ovf_use == 1 ? NE_EXPR : EQ_EXPR);
+ if (gimple_assign_rhs_code (use_stmt) == RSHIFT_EXPR)
+   {
+ g2 = gimple_build_assign (make_ssa_name (boolean_type_node),
+   ovf_use == 1 ? NE_EXPR : EQ_EXPR,
+   ovf, build_int_cst (type, 0));
+ gimple_stmt_iterator gsiu = gsi_for_stmt (use_stmt);
+ gsi_insert_before (, g2, GSI_SAME_STMT);
+ gimple_assign_set_rhs_with_ops (, NOP_EXPR,
+ gimple_assign_lhs (g2));
+ update_stmt (use_stmt);
+ use_operand_p use;
+ single_imm_use (gimple_assign_lhs (use_stmt), ,
+ _stmt);
+ if (gimple_code (use_stmt) == GIMPLE_COND)
+   {
+ gcond *cond_stmt = as_a  (u

[gcc r14-10193] c++, mingw: Fix up types of dtor hooks to __cxa_{, thread_}atexit/__cxa_throw on mingw ia32 [PR114968

2024-05-10 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:a805de33f7be4f6886906ca5f4da493f3b743c76

commit r14-10193-ga805de33f7be4f6886906ca5f4da493f3b743c76
Author: Jakub Jelinek 
Date:   Fri May 10 09:21:38 2024 +0200

c++, mingw: Fix up types of dtor hooks to 
__cxa_{,thread_}atexit/__cxa_throw on mingw ia32 [PR114968]

__cxa_atexit/__cxa_thread_atexit/__cxa_throw functions accept function
pointers to usually directly destructors rather than wrappers around
them.
Now, mingw ia32 uses implicitly __attribute__((thiscall)) calling
conventions for METHOD_TYPE (where the this pointer is passed in %ecx
register, the rest on the stack), so these functions use:
in config/os/mingw32/os_defines.h:
 #if defined (__i386__)
 #define _GLIBCXX_CDTOR_CALLABI __thiscall
 #endif
in libsupc++/cxxabi.h
__cxa_atexit(void (_GLIBCXX_CDTOR_CALLABI *)(void*), void*, void*) 
_GLIBCXX_NOTHROW;
__cxa_thread_atexit(void (_GLIBCXX_CDTOR_CALLABI *)(void*), void*, void *) 
_GLIBCXX_NOTHROW;
__cxa_throw(void*, std::type_info*, void (_GLIBCXX_CDTOR_CALLABI *) (void 
*))
__attribute__((__noreturn__));

Now, mingw for some weird reason uses
 #define TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT hook_bool_void_true
so it never actually uses __cxa_atexit, but does use __cxa_thread_atexit
and __cxa_throw.  Recent changes for modules result in more detailed
__cxa_*atexit/__cxa_throw prototypes precreated by the compiler, and if
that happens and one also includes , the compiler complains about
mismatches in the prototypes.

One thing is the missing thiscall attribute on the FUNCTION_TYPE, the
other problem is that all of atexit/__cxa_atexit/__cxa_thread_atexit
get function pointer types created by a single function,
get_atexit_fn_ptr_type (), which creates it depending on if atexit
or __cxa_atexit will be used as either void(*)(void) or void(*)(void *),
but when using atexit and __cxa_thread_atexit it uses the wrong function
type for __cxa_thread_atexit.

The following patch adds a target hook to add the thiscall attribute to the
function pointers, and splits the get_atexit_fn_ptr_type () function into
get_atexit_fn_ptr_type () and get_cxa_atexit_fn_ptr_type (), the former 
always
creates shared void(*)(void) type, the latter creates either
void(*)(void*) (on most targets) or void(__attribute__((thiscall))*)(void*)
(on mingw ia32).  So that we don't waiste another GTY global tree for it,
because cleanup_type used for the same purpose for __cxa_throw should be
the same, the code changes it to use that type too.

In register_dtor_fn then based on the decision whether to use atexit,
__cxa_atexit or __cxa_thread_atexit it picks the right function pointer
type, and also if it decides to emit a __tcf_* wrapper for the cleanup,
uses that type for that wrapper so that it agrees on calling convention.

2024-05-10  Jakub Jelinek  

PR target/114968
gcc/
* target.def (use_atexit_for_cxa_atexit): Remove spurious space
from comment.
(adjust_cdtor_callabi_fntype): New cxx target hook.
* targhooks.h (default_cxx_adjust_cdtor_callabi_fntype): Declare.
* targhooks.cc (default_cxx_adjust_cdtor_callabi_fntype): New
function.
* doc/tm.texi.in (TARGET_CXX_ADJUST_CDTOR_CALLABI_FNTYPE): Add.
* doc/tm.texi: Regenerate.
* config/i386/i386.cc (ix86_cxx_adjust_cdtor_callabi_fntype): New
function.
(TARGET_CXX_ADJUST_CDTOR_CALLABI_FNTYPE): Redefine.
gcc/cp/
* cp-tree.h (atexit_fn_ptr_type_node, cleanup_type): Adjust macro
comments.
(get_cxa_atexit_fn_ptr_type): Declare.
* decl.cc (get_atexit_fn_ptr_type): Adjust function comment, only
build type for atexit argument.
(get_cxa_atexit_fn_ptr_type): New function.
(get_atexit_node): Call get_cxa_atexit_fn_ptr_type rather than
get_atexit_fn_ptr_type when using __cxa_atexit.
(get_thread_atexit_node): Call get_cxa_atexit_fn_ptr_type
rather than get_atexit_fn_ptr_type.
(start_cleanup_fn): Add ob_parm argument, call
get_cxa_atexit_fn_ptr_type or get_atexit_fn_ptr_type depending
on it and create PARM_DECL also based on that argument.
(register_dtor_fn): Adjust start_cleanup_fn caller, use
get_cxa_atexit_fn_ptr_type rather than get_atexit_fn_ptr_type
for use_dtor casts.
* except.cc (build_throw): Use get_cxa_atexit_fn_ptr_type ().

(cherry picked from commit e5d8fd9ce05611093191d500ebc39f150d0ece2b)

Diff:
---
 gcc/config/i386/i386.cc | 16 ++
 gcc/cp/cp-tree.h|  7 +++---
 gcc/cp/decl.cc  | 59 +++--
 gcc/cp/except.cc|  6 +
 gcc/doc/tm.texi

[gcc r15-358] c++, mingw: Fix up types of dtor hooks to __cxa_{, thread_}atexit/__cxa_throw on mingw ia32 [PR114968

2024-05-10 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:e5d8fd9ce05611093191d500ebc39f150d0ece2b

commit r15-358-ge5d8fd9ce05611093191d500ebc39f150d0ece2b
Author: Jakub Jelinek 
Date:   Fri May 10 09:21:38 2024 +0200

c++, mingw: Fix up types of dtor hooks to 
__cxa_{,thread_}atexit/__cxa_throw on mingw ia32 [PR114968]

__cxa_atexit/__cxa_thread_atexit/__cxa_throw functions accept function
pointers to usually directly destructors rather than wrappers around
them.
Now, mingw ia32 uses implicitly __attribute__((thiscall)) calling
conventions for METHOD_TYPE (where the this pointer is passed in %ecx
register, the rest on the stack), so these functions use:
in config/os/mingw32/os_defines.h:
 #if defined (__i386__)
 #define _GLIBCXX_CDTOR_CALLABI __thiscall
 #endif
in libsupc++/cxxabi.h
__cxa_atexit(void (_GLIBCXX_CDTOR_CALLABI *)(void*), void*, void*) 
_GLIBCXX_NOTHROW;
__cxa_thread_atexit(void (_GLIBCXX_CDTOR_CALLABI *)(void*), void*, void *) 
_GLIBCXX_NOTHROW;
__cxa_throw(void*, std::type_info*, void (_GLIBCXX_CDTOR_CALLABI *) (void 
*))
__attribute__((__noreturn__));

Now, mingw for some weird reason uses
 #define TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT hook_bool_void_true
so it never actually uses __cxa_atexit, but does use __cxa_thread_atexit
and __cxa_throw.  Recent changes for modules result in more detailed
__cxa_*atexit/__cxa_throw prototypes precreated by the compiler, and if
that happens and one also includes , the compiler complains about
mismatches in the prototypes.

One thing is the missing thiscall attribute on the FUNCTION_TYPE, the
other problem is that all of atexit/__cxa_atexit/__cxa_thread_atexit
get function pointer types created by a single function,
get_atexit_fn_ptr_type (), which creates it depending on if atexit
or __cxa_atexit will be used as either void(*)(void) or void(*)(void *),
but when using atexit and __cxa_thread_atexit it uses the wrong function
type for __cxa_thread_atexit.

The following patch adds a target hook to add the thiscall attribute to the
function pointers, and splits the get_atexit_fn_ptr_type () function into
get_atexit_fn_ptr_type () and get_cxa_atexit_fn_ptr_type (), the former 
always
creates shared void(*)(void) type, the latter creates either
void(*)(void*) (on most targets) or void(__attribute__((thiscall))*)(void*)
(on mingw ia32).  So that we don't waiste another GTY global tree for it,
because cleanup_type used for the same purpose for __cxa_throw should be
the same, the code changes it to use that type too.

In register_dtor_fn then based on the decision whether to use atexit,
__cxa_atexit or __cxa_thread_atexit it picks the right function pointer
type, and also if it decides to emit a __tcf_* wrapper for the cleanup,
uses that type for that wrapper so that it agrees on calling convention.

2024-05-10  Jakub Jelinek  

PR target/114968
gcc/
* target.def (use_atexit_for_cxa_atexit): Remove spurious space
from comment.
(adjust_cdtor_callabi_fntype): New cxx target hook.
* targhooks.h (default_cxx_adjust_cdtor_callabi_fntype): Declare.
* targhooks.cc (default_cxx_adjust_cdtor_callabi_fntype): New
function.
* doc/tm.texi.in (TARGET_CXX_ADJUST_CDTOR_CALLABI_FNTYPE): Add.
* doc/tm.texi: Regenerate.
* config/i386/i386.cc (ix86_cxx_adjust_cdtor_callabi_fntype): New
function.
(TARGET_CXX_ADJUST_CDTOR_CALLABI_FNTYPE): Redefine.
gcc/cp/
* cp-tree.h (atexit_fn_ptr_type_node, cleanup_type): Adjust macro
comments.
(get_cxa_atexit_fn_ptr_type): Declare.
* decl.cc (get_atexit_fn_ptr_type): Adjust function comment, only
build type for atexit argument.
(get_cxa_atexit_fn_ptr_type): New function.
(get_atexit_node): Call get_cxa_atexit_fn_ptr_type rather than
get_atexit_fn_ptr_type when using __cxa_atexit.
(get_thread_atexit_node): Call get_cxa_atexit_fn_ptr_type
rather than get_atexit_fn_ptr_type.
(start_cleanup_fn): Add ob_parm argument, call
get_cxa_atexit_fn_ptr_type or get_atexit_fn_ptr_type depending
on it and create PARM_DECL also based on that argument.
(register_dtor_fn): Adjust start_cleanup_fn caller, use
get_cxa_atexit_fn_ptr_type rather than get_atexit_fn_ptr_type
for use_dtor casts.
* except.cc (build_throw): Use get_cxa_atexit_fn_ptr_type ().

Diff:
---
 gcc/config/i386/i386.cc | 16 ++
 gcc/cp/cp-tree.h|  7 +++---
 gcc/cp/decl.cc  | 59 +++--
 gcc/cp/except.cc|  6 +
 gcc/doc/tm.texi |  8 +++
 gcc/doc/tm.texi.in  |  2 ++
 gcc/target.def

Re: [PATCH] c++: Optimize in maybe_clone_body aliases even when not at_eof [PR113208]

2024-05-09 Thread Jakub Jelinek
On Thu, May 09, 2024 at 02:58:52PM -0400, Marek Polacek wrote:
> On Thu, May 09, 2024 at 08:20:00PM +0200, Jakub Jelinek wrote:
> > --- gcc/cp/decl.cc.jj   2024-05-09 10:30:54.804505130 +0200
> > +++ gcc/cp/decl.cc  2024-05-09 17:07:08.400110018 +0200
> > @@ -19280,6 +19280,14 @@ cxx_comdat_group (tree decl)
> >   else
> > break;
> > }
> > +  /* If a ctor/dtor has already set the comdat group by
> > +maybe_clone_body, don't override it.  */
> > +  if (SUPPORTS_ONE_ONLY
> > + && TREE_CODE (decl) == FUNCTION_DECL
> > + && DECL_CLONED_FUNCTION_P (decl)
> > + && SUPPORTS_ONE_ONLY)
> > +   if (tree comdat = DECL_COMDAT_GROUP (decl))
> > + return comdat;
> 
> This checks SUPPORTS_ONE_ONLY twice.

Oops, you're right, fixed in my copy.

Jakub



[committed] testsuite: Fix up pr84508* tests [PR84508]

2024-05-09 Thread Jakub Jelinek
On Thu, May 09, 2024 at 12:45:42PM +0800, Hongtao Liu wrote:
> > PR target/84508
> > * gcc.target/i386/pr84508-1.c: New test.
> > * gcc.target/i386/pr84508-2.c: Ditto.

The tests FAIL on x86_64-linux with
/usr/bin/ld: cannot find -lubsan
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: gcc.target/i386/pr84508-1.c (test for excess errors)
Excess errors:
/usr/bin/ld: cannot find -lubsan

The problem is that only *.dg/ubsan/ubsan.exp calls ubsan_init
which adds the needed search paths to libubsan library.
So, link/run tests for -fsanitize=undefined need to go into
gcc.dg/ubsan/ or g++.dg/ubsan/, even when they are target specific.

Tested on x86_64-linux with
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} i386.exp=pr84508* 
ubsan.exp=pr84508*'
and committed to trunk as obvious.

2024-05-09  Jakub Jelinek  

PR target/84508
* gcc.target/i386/pr84508-1.c: Move to ...
* gcc.dg/ubsan/pr84508-1.c: ... here.  Restrict to i?86/x86_64
non-ia32 targets.
* gcc.target/i386/pr84508-2.c: Move to ...
* gcc.dg/ubsan/pr84508-2.c: ... here.  Restrict to i?86/x86_64
non-ia32 targets.

diff --git a/gcc/testsuite/gcc.target/i386/pr84508-1.c 
b/gcc/testsuite/gcc.dg/ubsan/pr84508-1.c
similarity index 74%
rename from gcc/testsuite/gcc.target/i386/pr84508-1.c
rename to gcc/testsuite/gcc.dg/ubsan/pr84508-1.c
index bb3e28d017e..d781e01 100644
--- a/gcc/testsuite/gcc.target/i386/pr84508-1.c
+++ b/gcc/testsuite/gcc.dg/ubsan/pr84508-1.c
@@ -1,5 +1,6 @@
-/* { dg-do run { target { ! ia32 } } } */
+/* { dg-do run { target { { i?86-*-* x86_64-*-* } && { ! ia32 } } } } */
 /* { dg-options "-fsanitize=undefined" } */
+
 #include 
 
 int main()
diff --git a/gcc/testsuite/gcc.target/i386/pr84508-2.c 
b/gcc/testsuite/gcc.dg/ubsan/pr84508-2.c
similarity index 73%
rename from gcc/testsuite/gcc.target/i386/pr84508-2.c
rename to gcc/testsuite/gcc.dg/ubsan/pr84508-2.c
index 32a8f20a536..cf9c7db1d15 100644
--- a/gcc/testsuite/gcc.target/i386/pr84508-2.c
+++ b/gcc/testsuite/gcc.dg/ubsan/pr84508-2.c
@@ -1,5 +1,6 @@
-/* { dg-do run { target { ! ia32 } } } */
+/* { dg-do run { target { { i?86-*-* x86_64-*-* } && { ! ia32 } } } } */
 /* { dg-options "-fsanitize=undefined" } */
+
 #include 
 
 int main()

Jakub



[gcc r15-350] testsuite: Fix up pr84508* tests [PR84508]

2024-05-09 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:e02b5683e77c2b4317b23be72e43b6e6cc6c8e5b

commit r15-350-ge02b5683e77c2b4317b23be72e43b6e6cc6c8e5b
Author: Jakub Jelinek 
Date:   Thu May 9 20:59:05 2024 +0200

testsuite: Fix up pr84508* tests [PR84508]

The tests FAIL on x86_64-linux with
/usr/bin/ld: cannot find -lubsan
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: gcc.target/i386/pr84508-1.c (test for excess errors)
Excess errors:
/usr/bin/ld: cannot find -lubsan

The problem is that only *.dg/ubsan/ubsan.exp calls ubsan_init
which adds the needed search paths to libubsan library.
So, link/run tests for -fsanitize=undefined need to go into
gcc.dg/ubsan/ or g++.dg/ubsan/, even when they are target specific.

2024-05-09  Jakub Jelinek  

PR target/84508
* gcc.target/i386/pr84508-1.c: Move to ...
* gcc.dg/ubsan/pr84508-1.c: ... here.  Restrict to i?86/x86_64
non-ia32 targets.
* gcc.target/i386/pr84508-2.c: Move to ...
* gcc.dg/ubsan/pr84508-2.c: ... here.  Restrict to i?86/x86_64
non-ia32 targets.

Diff:
---
 gcc/testsuite/{gcc.target/i386 => gcc.dg/ubsan}/pr84508-1.c | 3 ++-
 gcc/testsuite/{gcc.target/i386 => gcc.dg/ubsan}/pr84508-2.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/i386/pr84508-1.c 
b/gcc/testsuite/gcc.dg/ubsan/pr84508-1.c
similarity index 74%
rename from gcc/testsuite/gcc.target/i386/pr84508-1.c
rename to gcc/testsuite/gcc.dg/ubsan/pr84508-1.c
index bb3e28d017e9..d781e01c 100644
--- a/gcc/testsuite/gcc.target/i386/pr84508-1.c
+++ b/gcc/testsuite/gcc.dg/ubsan/pr84508-1.c
@@ -1,5 +1,6 @@
-/* { dg-do run { target { ! ia32 } } } */
+/* { dg-do run { target { { i?86-*-* x86_64-*-* } && { ! ia32 } } } } */
 /* { dg-options "-fsanitize=undefined" } */
+
 #include 
 
 int main()
diff --git a/gcc/testsuite/gcc.target/i386/pr84508-2.c 
b/gcc/testsuite/gcc.dg/ubsan/pr84508-2.c
similarity index 73%
rename from gcc/testsuite/gcc.target/i386/pr84508-2.c
rename to gcc/testsuite/gcc.dg/ubsan/pr84508-2.c
index 32a8f20a5364..cf9c7db1d159 100644
--- a/gcc/testsuite/gcc.target/i386/pr84508-2.c
+++ b/gcc/testsuite/gcc.dg/ubsan/pr84508-2.c
@@ -1,5 +1,6 @@
-/* { dg-do run { target { ! ia32 } } } */
+/* { dg-do run { target { { i?86-*-* x86_64-*-* } && { ! ia32 } } } } */
 /* { dg-options "-fsanitize=undefined" } */
+
 #include 
 
 int main()


[PATCH] c++, mingw, v2: Fix up types of dtor hooks to __cxa_{,thread_}atexit/__cxa_throw on mingw ia32 [PR114968]

2024-05-09 Thread Jakub Jelinek
On Thu, May 09, 2024 at 01:05:59PM -0400, Jason Merrill wrote:
> I think I'd rather pass ob_parm to start_cleanup_fn, where it can also
> replace the flag_use_cxa_atexit check in that function.

Good idea, changed in the following patch.

> > @@ -9998,7 +10004,8 @@ register_dtor_fn (tree decl)
> >   {
> > /* We must convert CLEANUP to the type that "__cxa_atexit"
> >  expects.  */
> > -  cleanup = build_nop (get_atexit_fn_ptr_type (), cleanup);
> > +  cleanup = build_nop (ob_parm ? get_cxa_atexit_fn_ptr_type ()
> > +  : get_atexit_fn_ptr_type (), cleanup);
> 
> If we're (now) using the correct type to build the cleanup fn, this
> conversion should be unnecessary.

This is the use_dtor case, where cleanup will have METHOD_TYPE, so
I think we need to cast.  But, we can cast always to
get_cxa_atexit_fn_ptr_type () type, because this is in use_dtor guarded code
and use_dtor is ob_parm && CLASS_TYPE_P (type), so when use_dtor is true,
ob_parm is also true.

Ok for trunk if it passes another bootstrap/regtest?

2024-05-09  Jakub Jelinek  

PR target/114968
gcc/
* target.def (use_atexit_for_cxa_atexit): Remove spurious space
from comment.
(adjust_cdtor_callabi_fntype): New cxx target hook.
* targhooks.h (default_cxx_adjust_cdtor_callabi_fntype): Declare.
* targhooks.cc (default_cxx_adjust_cdtor_callabi_fntype): New
function.
* doc/tm.texi.in (TARGET_CXX_ADJUST_CDTOR_CALLABI_FNTYPE): Add.
* doc/tm.texi: Regenerate.
* config/i386/i386.cc (ix86_cxx_adjust_cdtor_callabi_fntype): New
function.
(TARGET_CXX_ADJUST_CDTOR_CALLABI_FNTYPE): Redefine.
gcc/cp/
* cp-tree.h (atexit_fn_ptr_type_node, cleanup_type): Adjust macro
comments.
(get_cxa_atexit_fn_ptr_type): Declare.
* decl.cc (get_atexit_fn_ptr_type): Adjust function comment, only
build type for atexit argument.
(get_cxa_atexit_fn_ptr_type): New function.
(get_atexit_node): Call get_cxa_atexit_fn_ptr_type rather than
get_atexit_fn_ptr_type when using __cxa_atexit.
(get_thread_atexit_node): Call get_cxa_atexit_fn_ptr_type
rather than get_atexit_fn_ptr_type.
(start_cleanup_fn): Add ob_parm argument, call
get_cxa_atexit_fn_ptr_type or get_atexit_fn_ptr_type depending
on it and create PARM_DECL also based on that argument.
(register_dtor_fn): Adjust start_cleanup_fn caller, use
get_cxa_atexit_fn_ptr_type rather than get_atexit_fn_ptr_type
for use_dtor casts.
* except.cc (build_throw): Use get_cxa_atexit_fn_ptr_type ().

--- gcc/target.def.jj   2024-05-09 10:30:54.926503473 +0200
+++ gcc/target.def  2024-05-09 20:27:16.294780780 +0200
@@ -6498,7 +6498,7 @@ is in effect.  The default is to return
  hook_bool_void_false)
 
 /* Returns true if target may use atexit in the same manner as
-   __cxa_atexit  to register static destructors.  */
+   __cxa_atexit to register static destructors.  */
 DEFHOOK
 (use_atexit_for_cxa_atexit,
  "This hook returns true if the target @code{atexit} function can be used\n\
@@ -6509,6 +6509,17 @@ unloaded. The default is to return false
  bool, (void),
  hook_bool_void_false)
 
+/* Returns modified FUNCTION_TYPE for cdtor callabi.  */
+DEFHOOK
+(adjust_cdtor_callabi_fntype,
+ "This hook returns a possibly modified @code{FUNCTION_TYPE} for arguments\n\
+to @code{__cxa_atexit}, @code{__cxa_thread_atexit} or @code{__cxa_throw}\n\
+function pointers.  ABIs like mingw32 require special attributes to be added\n\
+to function types pointed to by arguments of these functions.\n\
+The default is to return the passed argument unmodified.",
+ tree, (tree fntype),
+ default_cxx_adjust_cdtor_callabi_fntype)
+
 DEFHOOK
 (adjust_class_at_definition,
 "@var{type} is a C++ class (i.e., RECORD_TYPE or UNION_TYPE) that has just\n\
--- gcc/targhooks.h.jj  2024-05-09 10:30:54.941503269 +0200
+++ gcc/targhooks.h 2024-05-09 20:27:16.315780505 +0200
@@ -65,6 +65,7 @@ extern machine_mode default_mode_for_suf
 
 extern tree default_cxx_guard_type (void);
 extern tree default_cxx_get_cookie_size (tree);
+extern tree default_cxx_adjust_cdtor_callabi_fntype (tree);
 
 extern bool hook_pass_by_reference_must_pass_in_stack
   (cumulative_args_t, const function_arg_info &);
--- gcc/targhooks.cc.jj 2024-05-09 10:30:54.927503459 +0200
+++ gcc/targhooks.cc2024-05-09 20:27:16.338780204 +0200
@@ -329,6 +329,14 @@ default_cxx_get_cookie_size (tree type)
   return cookie_size;
 }
 
+/* Returns modified FUNCTION_TYPE for cdtor callabi.  */
+
+tree
+default_cxx_adjust_cdtor_callabi_fntype (tree fntype)
+{
+  return fntype;
+}
+
 /* Return true if a parameter must be passed by reference.  This version
of the TARGET_PASS_BY_REFERENCE hook uses just MUST_PASS_IN_STACK.  */
 
--- gcc/d

[PATCH] c++: Optimize in maybe_clone_body aliases even when not at_eof [PR113208]

2024-05-09 Thread Jakub Jelinek
On Thu, Apr 25, 2024 at 11:30:48AM -0400, Jason Merrill wrote:
> Hmm, maybe maybe_clone_body shouldn't clear DECL_SAVED_TREE for aliases, but
> rather set it to some stub like void_node?
> 
> Though with all these changes, it's probably better to go with your first
> patch for GCC 14 and delay this approach to 15.  Your v1 patch is OK for 14.

Ok, here is an updated patch, which sets DECL_SAVED_TREE to void_node for
the aliases together with reversion of the earlier committed patch.

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

2024-05-09  Jakub Jelinek  
Jason Merrill  

PR lto/113208
* cp-tree.h (maybe_optimize_cdtor): Remove.
* decl2.cc (tentative_decl_linkage): Call maybe_make_one_only
for implicit instantiations of maybe in charge ctors/dtors
declared inline.
(import_export_decl): Don't call maybe_optimize_cdtor.
(c_parse_final_cleanups): Formatting fixes.
* optimize.cc (can_alias_cdtor): Adjust condition, for
HAVE_COMDAT_GROUP && DECL_ONE_ONLY && DECL_WEAK return true even
if not DECL_INTERFACE_KNOWN.
(maybe_clone_body): Don't clear DECL_SAVED_TREE, instead set it
to void_node.
(maybe_clone_body): Remove.
* decl.cc (cxx_comdat_group): For DECL_CLONED_FUNCTION_P
functions if SUPPORTS_ONE_ONLY return DECL_COMDAT_GROUP if already
set.

* g++.dg/abi/comdat3.C: New test.
* g++.dg/abi/comdat4.C: New test.

--- gcc/cp/cp-tree.h.jj 2024-05-09 10:30:54.775505524 +0200
+++ gcc/cp/cp-tree.h2024-05-09 17:07:01.246206288 +0200
@@ -7451,7 +7451,6 @@ extern bool handle_module_option (unsign
 /* In optimize.cc */
 extern tree clone_attrs(tree);
 extern bool maybe_clone_body   (tree);
-extern void maybe_optimize_cdtor   (tree);
 
 /* In parser.cc */
 extern tree cp_convert_range_for (tree, tree, tree, cp_decomp *, bool,
--- gcc/cp/decl2.cc.jj  2024-05-02 09:31:17.753298180 +0200
+++ gcc/cp/decl2.cc 2024-05-09 17:11:11.676836268 +0200
@@ -3325,16 +3325,23 @@ tentative_decl_linkage (tree decl)
 linkage of all functions, and as that causes writes to
 the data mapped in from the PCH file, it's advantageous
 to mark the functions at this point.  */
- if (DECL_DECLARED_INLINE_P (decl)
- && (!DECL_IMPLICIT_INSTANTIATION (decl)
- || DECL_DEFAULTED_FN (decl)))
+ if (DECL_DECLARED_INLINE_P (decl))
{
- /* This function must have external linkage, as
-otherwise DECL_INTERFACE_KNOWN would have been
-set.  */
- gcc_assert (TREE_PUBLIC (decl));
- comdat_linkage (decl);
- DECL_INTERFACE_KNOWN (decl) = 1;
+ if (!DECL_IMPLICIT_INSTANTIATION (decl)
+ || DECL_DEFAULTED_FN (decl))
+   {
+ /* This function must have external linkage, as
+otherwise DECL_INTERFACE_KNOWN would have been
+set.  */
+ gcc_assert (TREE_PUBLIC (decl));
+ comdat_linkage (decl);
+ DECL_INTERFACE_KNOWN (decl) = 1;
+   }
+ else if (DECL_MAYBE_IN_CHARGE_CDTOR_P (decl))
+   /* For implicit instantiations of cdtors try to make
+  it comdat, so that maybe_clone_body can use aliases.
+  See PR113208.  */
+   maybe_make_one_only (decl);
}
}
   else if (VAR_P (decl))
@@ -3604,9 +3611,6 @@ import_export_decl (tree decl)
 }
 
   DECL_INTERFACE_KNOWN (decl) = 1;
-
-  if (DECL_CLONED_FUNCTION_P (decl))
-maybe_optimize_cdtor (decl);
 }
 
 /* Return an expression that performs the destruction of DECL, which
@@ -5331,7 +5335,7 @@ c_parse_final_cleanups (void)
node = node->get_alias_target ();
 
  node->call_for_symbol_thunks_and_aliases (clear_decl_external,
- NULL, true);
+   NULL, true);
  /* If we mark !DECL_EXTERNAL one of the symbols in some comdat
 group, we need to mark all symbols in the same comdat group
 that way.  */
@@ -5341,7 +5345,7 @@ c_parse_final_cleanups (void)
 next != node;
 next = dyn_cast (next->same_comdat_group))
  next->call_for_symbol_thunks_and_aliases (clear_decl_external,
- NULL, true);
+   NULL, true);
}
 
  /* If we're going to need to write this function out, and
--- gcc/cp/optimize.cc.jj   2024-04-25 20:33:30.771858912 +0200
+++ gcc/cp/optimize.cc  2024-05-09 17:10:23.9

[PATCH] c++: Fix parsing of abstract-declarator starting with ... followed by [ or ( [PR115012]

2024-05-09 Thread Jakub Jelinek
Hi!

The C++26 P2662R3 Pack indexing paper mentions that both GCC
and MSVC don't handle T...[10] parameter declaration when T
is a pack.  While that will change meaning in C++26, in C++11 .. C++23
this ought to be valid.  Also, T...(args) as well.

The following patch handles those in cp_parser_direct_declarator.

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

2024-05-09  Jakub Jelinek  

PR c++/115012
* parser.cc (cp_parser_direct_declarator): Handle
abstract declarator starting with ... followed by [
or (.

* g++.dg/cpp0x/variadic185.C: New test.
* g++.dg/cpp0x/variadic186.C: New test.

--- gcc/cp/parser.cc.jj 2024-05-09 10:30:58.0 +0200
+++ gcc/cp/parser.cc2024-05-09 16:44:01.250777325 +0200
@@ -23916,7 +23916,12 @@ cp_parser_direct_declarator (cp_parser*
 {
   /* Peek at the next token.  */
   token = cp_lexer_peek_token (parser->lexer);
-  if (token->type == CPP_OPEN_PAREN)
+  if (token->type == CPP_OPEN_PAREN
+ || (first
+ && dcl_kind != CP_PARSER_DECLARATOR_NAMED
+ && token->type == CPP_ELLIPSIS
+ && cxx_dialect > cxx98
+ && cp_lexer_nth_token_is (parser->lexer, 2, CPP_OPEN_PAREN)))
{
  /* This is either a parameter-declaration-clause, or a
 parenthesized declarator. When we know we are parsing a
@@ -23955,6 +23960,11 @@ cp_parser_direct_declarator (cp_parser*
 
 Thus again, we try a parameter-declaration-clause, and if
 that fails, we back out and return.  */
+ bool pack_expansion_p = token->type == CPP_ELLIPSIS;
+
+ if (pack_expansion_p)
+   /* Consume the `...' */
+   cp_lexer_consume_token (parser->lexer);
 
  if (!first || dcl_kind != CP_PARSER_DECLARATOR_NAMED)
{
@@ -24098,6 +24108,7 @@ cp_parser_direct_declarator (cp_parser*
 attrs,
 parens_loc);
  declarator->attributes = gnu_attrs;
+ declarator->parameter_pack_p |= pack_expansion_p;
  /* Any subsequent parameter lists are to do with
 return type, so are not those of the declared
 function.  */
@@ -24121,7 +24132,7 @@ cp_parser_direct_declarator (cp_parser*
 
  /* If this is the first, we can try a parenthesized
 declarator.  */
- if (first)
+ if (first && !pack_expansion_p)
{
  bool saved_in_type_id_in_expr_p;
 
@@ -24156,16 +24167,27 @@ cp_parser_direct_declarator (cp_parser*
  else
break;
}
-  else if ((!first || dcl_kind != CP_PARSER_DECLARATOR_NAMED)
-  && token->type == CPP_OPEN_SQUARE
-  && !cp_next_tokens_can_be_attribute_p (parser))
+  else if (((!first || dcl_kind != CP_PARSER_DECLARATOR_NAMED)
+   && token->type == CPP_OPEN_SQUARE
+   && !cp_next_tokens_can_be_attribute_p (parser))
+  || (first
+  && dcl_kind != CP_PARSER_DECLARATOR_NAMED
+  && token->type == CPP_ELLIPSIS
+  && cp_lexer_nth_token_is (parser->lexer, 2, CPP_OPEN_SQUARE)
+  && cxx_dialect > cxx98
+  && !cp_nth_tokens_can_be_std_attribute_p (parser, 2)))
{
  /* Parse an array-declarator.  */
  tree bounds, attrs;
+ bool pack_expansion_p = token->type == CPP_ELLIPSIS;
 
  if (ctor_dtor_or_conv_p)
*ctor_dtor_or_conv_p = 0;
 
+ if (pack_expansion_p)
+   /* Consume the `...' */
+   cp_lexer_consume_token (parser->lexer);
+
  open_paren = NULL;
  first = false;
  parser->default_arg_ok_p = false;
@@ -24220,6 +24242,7 @@ cp_parser_direct_declarator (cp_parser*
  attrs = cp_parser_std_attribute_spec_seq (parser);
  declarator = make_array_declarator (declarator, bounds);
  declarator->std_attributes = attrs;
+ declarator->parameter_pack_p |= pack_expansion_p;
}
   else if (first && dcl_kind != CP_PARSER_DECLARATOR_ABSTRACT)
{
--- gcc/testsuite/g++.dg/cpp0x/variadic185.C.jj 2024-05-09 15:08:49.070651189 
+0200
+++ gcc/testsuite/g++.dg/cpp0x/variadic185.C2024-05-09 15:07:40.045583153 
+0200
@@ -0,0 +1,39 @@
+// PR c++/115012
+// { dg-do compile { target { c++11 && c++23_down } } }
+// { dg-final { scan-assembler "_Z3fooILi10EJidEEvDpAT__T0_" } }
+// { dg-final { scan-assembler "_Z3barILi10EiEvPT0_" } }
+// { dg-final { scan-assembler "_Z3bazILi10EJidEEvDpAT__T0_" } }
+// { dg-final { scan-assembler "_Z3quxILi5EJifEEvDpAT__AT_

Re: gcc/DATESTAMP wasn't updated since 20240507

2024-05-09 Thread Jakub Jelinek
On Thu, May 09, 2024 at 12:14:43PM +0200, Jakub Jelinek wrote:
> On Thu, May 09, 2024 at 12:04:38PM +0200, Rainer Orth wrote:
> > I just noticed that gcc/DATESTAMP wasn't updated yesterday and today,
> > staying at 20240507.
> 
> I think it is because of the r15-268 commit, we do support
> This reverts commit ...
> when the referenced commit contains a ChangeLog message, but here
> it doesn't, as it is a revert commit.

Indeed and also the r15-311 commit.
Please don't Revert Revert, we don't really support that, had to fix it all
by hand.

Jakub



[gcc r15-345] Manually update entries for the Revert Revert commits.

2024-05-09 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:2790195500ec523cad9c7292816540e2fc19f456

commit r15-345-g2790195500ec523cad9c7292816540e2fc19f456
Author: Jakub Jelinek 
Date:   Thu May 9 13:09:06 2024 +0200

Manually update entries for the Revert Revert commits.

Diff:
---
 gcc/ChangeLog   | 12 
 gcc/testsuite/ChangeLog | 11 +++
 2 files changed, 23 insertions(+)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 12a7d754b232..fff1592f837f 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -477,6 +477,18 @@
(Specific, *-*-solaris2*): Document Solaris 11.3 removal.  Remove
11.3 references and caveats.  Update for 11.4.
 
+2024-05-07  Richard Biener  
+
+   Revert:
+   2024-04-10  Richard Biener  
+
+   Revert:
+   2024-03-27  Segher Boessenkool  
+
+   PR rtl-optimization/101523
+   * combine.cc (try_combine): Don't do a 2-insn combination if
+   it does not in fact change I2.
+
 2024-05-07  Andrew Pinski  
 
PR middle-end/97263
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index fa115f8fd425..9f87260fa17d 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -94,6 +94,17 @@
 
* gcc.target/i386/cmov6.c: Fixed.
 
+2024-05-08  Hans-Peter Nilsson  
+
+   Revert:
+   2024-04-10  Hans-Peter Nilsson  
+
+   Revert:
+   2024-04-05  Hans-Peter Nilsson  
+
+   * gcc.target/cris/pr93372-2.c: Tweak scan-assembler
+   checks to cover recent combine improvement.
+
 2024-05-07  Nathaniel Shead  
 
PR c++/114856


[gcc r15-344] contrib: Add 109f1b28fc94c93096506e3df0c25e331cef19d0 to ignored commits

2024-05-09 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:5fe40f2c651af84b1a4ff6527ef4307591228a1b

commit r15-344-g5fe40f2c651af84b1a4ff6527ef4307591228a1b
Author: Jakub Jelinek 
Date:   Thu May 9 13:01:31 2024 +0200

contrib: Add 109f1b28fc94c93096506e3df0c25e331cef19d0 to ignored commits

2024-05-09  Jakub Jelinek  

* gcc-changelog/git_update_version.py: Replace
9dbff9c05520a74e6cd337578f27b56c941f64f3 with
39f81924d88e3cc197fc3df74204c9b5e01e12f7 and
109f1b28fc94c93096506e3df0c25e331cef19d0 in IGNORED_COMMITS.

Diff:
---
 contrib/gcc-changelog/git_update_version.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/contrib/gcc-changelog/git_update_version.py 
b/contrib/gcc-changelog/git_update_version.py
index 3d9a28ccbdf3..24f6c43d0b25 100755
--- a/contrib/gcc-changelog/git_update_version.py
+++ b/contrib/gcc-changelog/git_update_version.py
@@ -40,7 +40,8 @@ IGNORED_COMMITS = (
 '1957bedf29a1b2cc231972aba680fe80199d5498',
 '040e5b0edbca861196d9e2ea2af5e805769c8d5d',
 '8057f9aa1f7e70490064de796d7a8d42d446caf8',
-'9dbff9c05520a74e6cd337578f27b56c941f64f3')
+'109f1b28fc94c93096506e3df0c25e331cef19d0',
+'39f81924d88e3cc197fc3df74204c9b5e01e12f7')
 
 FORMAT = '%(asctime)s:%(levelname)s:%(name)s:%(message)s'
 logging.basicConfig(level=logging.INFO, format=FORMAT,


[gcc r15-341] contrib: Add 9dbff9c05520a74e6cd337578f27b56c941f64f3 to ignored commits

2024-05-09 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:de0b40ac5be8977a6bee8860f67d45011642f1a2

commit r15-341-gde0b40ac5be8977a6bee8860f67d45011642f1a2
Author: Jakub Jelinek 
Date:   Thu May 9 12:15:51 2024 +0200

contrib: Add 9dbff9c05520a74e6cd337578f27b56c941f64f3 to ignored commits

2024-05-09  Jakub Jelinek  

* gcc-changelog/git_update_version.py: Add
9dbff9c05520a74e6cd337578f27b56c941f64f3 to IGNORED_COMMITS.

Diff:
---
 contrib/gcc-changelog/git_update_version.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/contrib/gcc-changelog/git_update_version.py 
b/contrib/gcc-changelog/git_update_version.py
index f194757b0cb7..3d9a28ccbdf3 100755
--- a/contrib/gcc-changelog/git_update_version.py
+++ b/contrib/gcc-changelog/git_update_version.py
@@ -39,7 +39,8 @@ IGNORED_COMMITS = (
 'e4cba49413ca429dc82f6aa2e88129ecb3fdd943',
 '1957bedf29a1b2cc231972aba680fe80199d5498',
 '040e5b0edbca861196d9e2ea2af5e805769c8d5d',
-'8057f9aa1f7e70490064de796d7a8d42d446caf8')
+'8057f9aa1f7e70490064de796d7a8d42d446caf8',
+'9dbff9c05520a74e6cd337578f27b56c941f64f3')
 
 FORMAT = '%(asctime)s:%(levelname)s:%(name)s:%(message)s'
 logging.basicConfig(level=logging.INFO, format=FORMAT,


Re: gcc/DATESTAMP wasn't updated since 20240507

2024-05-09 Thread Jakub Jelinek
On Thu, May 09, 2024 at 12:04:38PM +0200, Rainer Orth wrote:
> I just noticed that gcc/DATESTAMP wasn't updated yesterday and today,
> staying at 20240507.

I think it is because of the r15-268 commit, we do support
This reverts commit ...
when the referenced commit contains a ChangeLog message, but here
it doesn't, as it is a revert commit.

Jakub



[committed] testsuite: Fix up vector-subaccess-1.C test for ia32 [PR89224]

2024-05-09 Thread Jakub Jelinek
Hi!

The test FAILs on i686-linux due to
.../gcc/testsuite/g++.dg/torture/vector-subaccess-1.C:16:6: warning: SSE vector 
argument without SSE enabled changes the ABI [-Wpsabi]
excess warnings.

This fixes it by adding -Wno-psabi, like commonly done in other tests.

Committed to trunk as obvious after testing it on x86_64-linux with
make check-g++ RUNTESTFLAGS='--target_board=unix\{-m32/-mno-sse,-m32,-m64\} 
dg-torture.exp=vector-subaccess-1.C'
and backported all the way to 11 branch.

2024-05-09  Jakub Jelinek  

PR c++/89224
* g++.dg/torture/vector-subaccess-1.C: Add -Wno-psabi as additional
options.

--- gcc/testsuite/g++.dg/torture/vector-subaccess-1.C.jj2024-05-08 
10:16:54.045823642 +0200
+++ gcc/testsuite/g++.dg/torture/vector-subaccess-1.C   2024-05-09 
11:16:46.730114871 +0200
@@ -1,4 +1,5 @@
 /* PR c++/89224 */
+/* { dg-additional-options "-Wno-psabi" } */
 
 /* The access of `vector[i]` has the same qualifiers as the original
vector which was missing. */

Jakub



[gcc r11-11423] testsuite: Fix up vector-subaccess-1.C test for ia32 [PR89224]

2024-05-09 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:e6c869372f0ca8b28ac63c7eb26fde35b53aba37

commit r11-11423-ge6c869372f0ca8b28ac63c7eb26fde35b53aba37
Author: Jakub Jelinek 
Date:   Thu May 9 11:18:21 2024 +0200

testsuite: Fix up vector-subaccess-1.C test for ia32 [PR89224]

The test FAILs on i686-linux due to
.../gcc/testsuite/g++.dg/torture/vector-subaccess-1.C:16:6: warning: SSE 
vector argument without SSE enabled changes the ABI [-Wpsabi]
excess warnings.

This fixes it by adding -Wno-psabi, like commonly done in other tests.

2024-05-09  Jakub Jelinek  

PR c++/89224
* g++.dg/torture/vector-subaccess-1.C: Add -Wno-psabi as additional
options.

(cherry picked from commit 8fb65ec816ff8f0d529b6d30821abace4328c9a2)

Diff:
---
 gcc/testsuite/g++.dg/torture/vector-subaccess-1.C | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/g++.dg/torture/vector-subaccess-1.C 
b/gcc/testsuite/g++.dg/torture/vector-subaccess-1.C
index 0c8958a4e034..4b909dae4926 100644
--- a/gcc/testsuite/g++.dg/torture/vector-subaccess-1.C
+++ b/gcc/testsuite/g++.dg/torture/vector-subaccess-1.C
@@ -1,4 +1,5 @@
 /* PR c++/89224 */
+/* { dg-additional-options "-Wno-psabi" } */
 
 /* The access of `vector[i]` has the same qualifiers as the original
vector which was missing. */


[gcc r12-10435] testsuite: Fix up vector-subaccess-1.C test for ia32 [PR89224]

2024-05-09 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:ffa41c65a375746fd26c2d620e634fb162726dfc

commit r12-10435-gffa41c65a375746fd26c2d620e634fb162726dfc
Author: Jakub Jelinek 
Date:   Thu May 9 11:18:21 2024 +0200

testsuite: Fix up vector-subaccess-1.C test for ia32 [PR89224]

The test FAILs on i686-linux due to
.../gcc/testsuite/g++.dg/torture/vector-subaccess-1.C:16:6: warning: SSE 
vector argument without SSE enabled changes the ABI [-Wpsabi]
excess warnings.

This fixes it by adding -Wno-psabi, like commonly done in other tests.

2024-05-09  Jakub Jelinek  

PR c++/89224
* g++.dg/torture/vector-subaccess-1.C: Add -Wno-psabi as additional
options.

(cherry picked from commit 8fb65ec816ff8f0d529b6d30821abace4328c9a2)

Diff:
---
 gcc/testsuite/g++.dg/torture/vector-subaccess-1.C | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/g++.dg/torture/vector-subaccess-1.C 
b/gcc/testsuite/g++.dg/torture/vector-subaccess-1.C
index 0c8958a4e034..4b909dae4926 100644
--- a/gcc/testsuite/g++.dg/torture/vector-subaccess-1.C
+++ b/gcc/testsuite/g++.dg/torture/vector-subaccess-1.C
@@ -1,4 +1,5 @@
 /* PR c++/89224 */
+/* { dg-additional-options "-Wno-psabi" } */
 
 /* The access of `vector[i]` has the same qualifiers as the original
vector which was missing. */


[gcc r13-8737] testsuite: Fix up vector-subaccess-1.C test for ia32 [PR89224]

2024-05-09 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:6f7674a558aaa0c7b16657c35666ad9b12e1c219

commit r13-8737-g6f7674a558aaa0c7b16657c35666ad9b12e1c219
Author: Jakub Jelinek 
Date:   Thu May 9 11:18:21 2024 +0200

testsuite: Fix up vector-subaccess-1.C test for ia32 [PR89224]

The test FAILs on i686-linux due to
.../gcc/testsuite/g++.dg/torture/vector-subaccess-1.C:16:6: warning: SSE 
vector argument without SSE enabled changes the ABI [-Wpsabi]
excess warnings.

This fixes it by adding -Wno-psabi, like commonly done in other tests.

2024-05-09  Jakub Jelinek  

PR c++/89224
* g++.dg/torture/vector-subaccess-1.C: Add -Wno-psabi as additional
options.

(cherry picked from commit 8fb65ec816ff8f0d529b6d30821abace4328c9a2)

Diff:
---
 gcc/testsuite/g++.dg/torture/vector-subaccess-1.C | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/g++.dg/torture/vector-subaccess-1.C 
b/gcc/testsuite/g++.dg/torture/vector-subaccess-1.C
index 0c8958a4e034..4b909dae4926 100644
--- a/gcc/testsuite/g++.dg/torture/vector-subaccess-1.C
+++ b/gcc/testsuite/g++.dg/torture/vector-subaccess-1.C
@@ -1,4 +1,5 @@
 /* PR c++/89224 */
+/* { dg-additional-options "-Wno-psabi" } */
 
 /* The access of `vector[i]` has the same qualifiers as the original
vector which was missing. */


[gcc r14-10189] testsuite: Fix up vector-subaccess-1.C test for ia32 [PR89224]

2024-05-09 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:726e7a64edc22a33a5f495698722ba797793edca

commit r14-10189-g726e7a64edc22a33a5f495698722ba797793edca
Author: Jakub Jelinek 
Date:   Thu May 9 11:18:21 2024 +0200

testsuite: Fix up vector-subaccess-1.C test for ia32 [PR89224]

The test FAILs on i686-linux due to
.../gcc/testsuite/g++.dg/torture/vector-subaccess-1.C:16:6: warning: SSE 
vector argument without SSE enabled changes the ABI [-Wpsabi]
excess warnings.

This fixes it by adding -Wno-psabi, like commonly done in other tests.

2024-05-09  Jakub Jelinek  

PR c++/89224
* g++.dg/torture/vector-subaccess-1.C: Add -Wno-psabi as additional
options.

(cherry picked from commit 8fb65ec816ff8f0d529b6d30821abace4328c9a2)

Diff:
---
 gcc/testsuite/g++.dg/torture/vector-subaccess-1.C | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/g++.dg/torture/vector-subaccess-1.C 
b/gcc/testsuite/g++.dg/torture/vector-subaccess-1.C
index 0c8958a4e034..4b909dae4926 100644
--- a/gcc/testsuite/g++.dg/torture/vector-subaccess-1.C
+++ b/gcc/testsuite/g++.dg/torture/vector-subaccess-1.C
@@ -1,4 +1,5 @@
 /* PR c++/89224 */
+/* { dg-additional-options "-Wno-psabi" } */
 
 /* The access of `vector[i]` has the same qualifiers as the original
vector which was missing. */


[gcc r15-340] testsuite: Fix up vector-subaccess-1.C test for ia32 [PR89224]

2024-05-09 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:8fb65ec816ff8f0d529b6d30821abace4328c9a2

commit r15-340-g8fb65ec816ff8f0d529b6d30821abace4328c9a2
Author: Jakub Jelinek 
Date:   Thu May 9 11:18:21 2024 +0200

testsuite: Fix up vector-subaccess-1.C test for ia32 [PR89224]

The test FAILs on i686-linux due to
.../gcc/testsuite/g++.dg/torture/vector-subaccess-1.C:16:6: warning: SSE 
vector argument without SSE enabled changes the ABI [-Wpsabi]
excess warnings.

This fixes it by adding -Wno-psabi, like commonly done in other tests.

2024-05-09  Jakub Jelinek  

PR c++/89224
* g++.dg/torture/vector-subaccess-1.C: Add -Wno-psabi as additional
options.

Diff:
---
 gcc/testsuite/g++.dg/torture/vector-subaccess-1.C | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/g++.dg/torture/vector-subaccess-1.C 
b/gcc/testsuite/g++.dg/torture/vector-subaccess-1.C
index 0c8958a4e034..4b909dae4926 100644
--- a/gcc/testsuite/g++.dg/torture/vector-subaccess-1.C
+++ b/gcc/testsuite/g++.dg/torture/vector-subaccess-1.C
@@ -1,4 +1,5 @@
 /* PR c++/89224 */
+/* { dg-additional-options "-Wno-psabi" } */
 
 /* The access of `vector[i]` has the same qualifiers as the original
vector which was missing. */


[PATCH] c++, mingw: Fix up types of dtor hooks to __cxa_{,thread_}atexit/__cxa_throw on mingw ia32 [PR114968]

2024-05-09 Thread Jakub Jelinek
Hi!

__cxa_atexit/__cxa_thread_atexit/__cxa_throw functions accept function
pointers to usually directly destructors rather than wrappers around
them.
Now, mingw ia32 uses implicitly __attribute__((thiscall)) calling
conventions for METHOD_TYPE (where the this pointer is passed in %ecx
register, the rest on the stack), so these functions use:
in config/os/mingw32/os_defines.h:
 #if defined (__i386__)
 #define _GLIBCXX_CDTOR_CALLABI __thiscall
 #endif
in libsupc++/cxxabi.h
__cxa_atexit(void (_GLIBCXX_CDTOR_CALLABI *)(void*), void*, void*) 
_GLIBCXX_NOTHROW;
__cxa_thread_atexit(void (_GLIBCXX_CDTOR_CALLABI *)(void*), void*, void *) 
_GLIBCXX_NOTHROW;
__cxa_throw(void*, std::type_info*, void (_GLIBCXX_CDTOR_CALLABI *) (void *))
__attribute__((__noreturn__));

Now, mingw for some weird reason uses
 #define TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT hook_bool_void_true
so it never actually uses __cxa_atexit, but does use __cxa_thread_atexit
and __cxa_throw.  Recent changes for modules result in more detailed
__cxa_*atexit/__cxa_throw prototypes precreated by the compiler, and if
that happens and one also includes , the compiler complains about
mismatches in the prototypes.

One thing is the missing thiscall attribute on the FUNCTION_TYPE, the
other problem is that all of atexit/__cxa_atexit/__cxa_thread_atexit
get function pointer types gets created by a single function,
get_atexit_fn_ptr_type (), which creates it depending on if atexit
or __cxa_atexit will be used as either void(*)(void) or void(*)(void *),
but when using atexit and __cxa_thread_atexit it uses the wrong function
type for __cxa_thread_atexit.

The following patch adds a target hook to add the thiscall attribute to the
function pointers, and splits the get_atexit_fn_ptr_type () function into
get_atexit_fn_ptr_type () and get_cxa_atexit_fn_ptr_type (), the former always
creates shared void(*)(void) type, the latter creates either
void(*)(void*) (on most targets) or void(__attribute__((thiscall))*)(void*)
(on mingw ia32).  So that we don't waiste another GTY global tree for it,
because cleanup_type used for the same purpose for __cxa_throw should be
the same, the code changes it to use that type too.

In register_dtor_fn then based on the decision whether to use atexit,
__cxa_atexit or __cxa_thread_atexit it picks the right function pointer
type, and also if it decides to emit a __tcf_* wrapper for the cleanup,
uses that type for that wrapper so that it agrees on calling convention.

Bootstrapped/regtested on x86_64-linux and i686-linux and Liu Hao tested
it on mingw32, ok for trunk?

2024-05-09  Jakub Jelinek  

PR target/114968
gcc/
* target.def (use_atexit_for_cxa_atexit): Remove spurious space
from comment.
(adjust_cdtor_callabi_fntype): New cxx target hook.
* targhooks.h (default_cxx_adjust_cdtor_callabi_fntype): Declare.
* targhooks.cc (default_cxx_adjust_cdtor_callabi_fntype): New
function.
* doc/tm.texi.in (TARGET_CXX_ADJUST_CDTOR_CALLABI_FNTYPE): Add.
* doc/tm.texi: Regenerate.
* config/i386/i386.cc (ix86_cxx_adjust_cdtor_callabi_fntype): New
function.
(TARGET_CXX_ADJUST_CDTOR_CALLABI_FNTYPE): Redefine.
gcc/cp/
* cp-tree.h (atexit_fn_ptr_type_node, cleanup_type): Adjust macro
comments.
(get_cxa_atexit_fn_ptr_type): Declare.
* decl.cc (get_atexit_fn_ptr_type): Adjust function comment, only
build type for atexit argument.
(get_cxa_atexit_fn_ptr_type): New function.
(get_atexit_node): Call get_cxa_atexit_fn_ptr_type rather than
get_atexit_fn_ptr_type when using __cxa_atexit.
(get_thread_atexit_node): Call get_cxa_atexit_fn_ptr_type
rather than get_atexit_fn_ptr_type.
(start_cleanup_fn): Add fntype argument, don't call
get_atexit_fn_ptr_type for it.
(register_dtor_fn): Adjust start_cleanup_fn caller, use
get_cxa_atexit_fn_ptr_type rather than get_atexit_fn_ptr_type
when ob_parm is true.
* except.cc (build_throw): Use get_cxa_atexit_fn_ptr_type ().

--- gcc/target.def.jj   2024-05-07 21:28:46.554394913 +0200
+++ gcc/target.def  2024-05-08 11:19:39.290798568 +0200
@@ -6498,7 +6498,7 @@ is in effect.  The default is to return
  hook_bool_void_false)
 
 /* Returns true if target may use atexit in the same manner as
-   __cxa_atexit  to register static destructors.  */
+   __cxa_atexit to register static destructors.  */
 DEFHOOK
 (use_atexit_for_cxa_atexit,
  "This hook returns true if the target @code{atexit} function can be used\n\
@@ -6509,6 +6509,17 @@ unloaded. The default is to return false
  bool, (void),
  hook_bool_void_false)
 
+/* Returns modified FUNCTION_TYPE for cdtor callabi.  */
+DEFHOOK
+(adjust_cdtor_callabi_fntype,
+ "This hook returns a possibly modified @code{FUNCTION_TYPE} for arguments\n\
+to @code{__cxa_atexit}, @code{__cxa_thread_atexit} or @code{__cxa_throw}\n\
+function pointers.  ABIs li

[gcc r13-8734] expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907]

2024-05-08 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:cad27df08915ead8db3c7d512cfcc1866e7ece69

commit r13-8734-gcad27df08915ead8db3c7d512cfcc1866e7ece69
Author: Jakub Jelinek 
Date:   Tue May 7 21:30:21 2024 +0200

expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907]

The HF and BF modes have the same size/precision and neither is
a subset nor superset of the other.
So, using either __extendhfbf2 or __trunchfbf2 is weird.
The expansion apparently emits __extendhfbf2, but on the libgcc side
we apparently have __trunchfbf2 implemented.

I think it is easier to switch to using what is available rather than
adding new entrypoints to libgcc, even alias, because this is backportable.

2024-05-07  Jakub Jelinek  

PR middle-end/114907
* expr.cc (convert_mode_scalar): Use trunc_optab rather than
sext_optab for HF->BF conversions.
* optabs-libfuncs.cc (gen_trunc_conv_libfunc): Likewise.

* gcc.dg/pr114907.c: New test.

(cherry picked from commit 28ee13db2e9d995bd3728c4ff3a3545e24b39cd2)

Diff:
---
 gcc/expr.cc | 12 ++--
 gcc/optabs-libfuncs.cc  |  4 +++-
 gcc/testsuite/gcc.dg/pr114907.c | 27 +++
 3 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/gcc/expr.cc b/gcc/expr.cc
index 5dac06fa94b5..705d5b34eed6 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -351,8 +351,16 @@ convert_mode_scalar (rtx to, rtx from, int unsignedp)
  && REAL_MODE_FORMAT (from_mode) == _half_format));
 
   if (GET_MODE_PRECISION (from_mode) == GET_MODE_PRECISION (to_mode))
-   /* Conversion between decimal float and binary float, same size.  */
-   tab = DECIMAL_FLOAT_MODE_P (from_mode) ? trunc_optab : sext_optab;
+   {
+ if (REAL_MODE_FORMAT (to_mode) == _bfloat_half_format
+ && REAL_MODE_FORMAT (from_mode) == _half_format)
+   /* libgcc implements just __trunchfbf2, not __extendhfbf2.  */
+   tab = trunc_optab;
+ else
+   /* Conversion between decimal float and binary float, same
+  size.  */
+   tab = DECIMAL_FLOAT_MODE_P (from_mode) ? trunc_optab : sext_optab;
+   }
   else if (GET_MODE_PRECISION (from_mode) < GET_MODE_PRECISION (to_mode))
tab = sext_optab;
   else
diff --git a/gcc/optabs-libfuncs.cc b/gcc/optabs-libfuncs.cc
index f1abe6916d34..4eb98be794b7 100644
--- a/gcc/optabs-libfuncs.cc
+++ b/gcc/optabs-libfuncs.cc
@@ -589,7 +589,9 @@ gen_trunc_conv_libfunc (convert_optab tab,
   if (GET_MODE_CLASS (float_tmode) != GET_MODE_CLASS (float_fmode))
 gen_interclass_conv_libfunc (tab, opname, float_tmode, float_fmode);
 
-  if (GET_MODE_PRECISION (float_fmode) <= GET_MODE_PRECISION (float_tmode))
+  if (GET_MODE_PRECISION (float_fmode) <= GET_MODE_PRECISION (float_tmode)
+  && (REAL_MODE_FORMAT (float_tmode) != _bfloat_half_format
+ || REAL_MODE_FORMAT (float_fmode) != _half_format))
 return;
 
   if (GET_MODE_CLASS (float_tmode) == GET_MODE_CLASS (float_fmode))
diff --git a/gcc/testsuite/gcc.dg/pr114907.c b/gcc/testsuite/gcc.dg/pr114907.c
new file mode 100644
index ..628746e1f8c1
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr114907.c
@@ -0,0 +1,27 @@
+/* PR middle-end/114907 */
+/* { dg-do run } */
+/* { dg-options "" } */
+/* { dg-add-options float16 } */
+/* { dg-require-effective-target float16_runtime } */
+/* { dg-add-options bfloat16 } */
+/* { dg-require-effective-target bfloat16_runtime } */
+
+__attribute__((noipa)) _Float16
+foo (__bf16 x)
+{
+  return (_Float16) x;
+}
+
+__attribute__((noipa)) __bf16
+bar (_Float16 x)
+{
+  return (__bf16) x;
+}
+
+int
+main ()
+{
+  if (foo (11.125bf16) != 11.125f16
+  || bar (11.125f16) != 11.125bf16)
+__builtin_abort ();
+}


[gcc r13-8733] tree-inline: Remove .ASAN_MARK calls when inlining functions into no_sanitize callers [PR114956]

2024-05-08 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:d1ec7bc9cb0639a212422710ba647dc1aaea6eaa

commit r13-8733-gd1ec7bc9cb0639a212422710ba647dc1aaea6eaa
Author: Jakub Jelinek 
Date:   Tue May 7 21:29:14 2024 +0200

tree-inline: Remove .ASAN_MARK calls when inlining functions into 
no_sanitize callers [PR114956]

In r9-5742 we've started allowing to inline always_inline functions into
functions which have disabled e.g. address sanitization even when the
always_inline function is implicitly from command line options sanitized.

This mostly works fine because most of the asan instrumentation is done only
late after ipa, but as the following testcase the .ASAN_MARK ifn calls
gimplifier adds can result in ICEs.

Fixed by dropping those during inlining, similarly to how we drop
.TSAN_FUNC_EXIT calls.

2024-05-07  Jakub Jelinek  

PR sanitizer/114956
* tree-inline.cc: Include asan.h.
(copy_bb): Remove also .ASAN_MARK calls if id->dst_fn has 
asan/hwasan
sanitization disabled.

* gcc.dg/asan/pr114956.c: New test.

(cherry picked from commit d4e25cf4f7c1f51a8824cc62bbb85a81a41b829a)

Diff:
---
 gcc/testsuite/gcc.dg/asan/pr114956.c | 26 ++
 gcc/tree-inline.cc   | 28 +---
 2 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/asan/pr114956.c 
b/gcc/testsuite/gcc.dg/asan/pr114956.c
new file mode 100644
index ..fb87d514f255
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/asan/pr114956.c
@@ -0,0 +1,26 @@
+/* PR sanitizer/114956 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fsanitize=address,null" } */
+
+int **a;
+void qux (int *);
+
+__attribute__((always_inline)) static inline int *
+foo (void)
+{
+  int b[1];
+  qux (b);
+  return a[1];
+}
+
+__attribute__((no_sanitize_address)) void
+bar (void)
+{
+  *a = foo ();
+}
+
+void
+baz (void)
+{
+  bar ();
+}
diff --git a/gcc/tree-inline.cc b/gcc/tree-inline.cc
index 72a80c0c74da..73d5a9fadef3 100644
--- a/gcc/tree-inline.cc
+++ b/gcc/tree-inline.cc
@@ -65,6 +65,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "symbol-summary.h"
 #include "symtab-thunks.h"
 #include "symtab-clones.h"
+#include "asan.h"
 
 /* I'm not real happy about this, but we need to handle gimple and
non-gimple trees.  */
@@ -2198,13 +2199,26 @@ copy_bb (copy_body_data *id, basic_block bb,
}
  else if (call_stmt
   && id->call_stmt
-  && gimple_call_internal_p (stmt)
-  && gimple_call_internal_fn (stmt) == IFN_TSAN_FUNC_EXIT)
-   {
- /* Drop TSAN_FUNC_EXIT () internal calls during inlining.  */
- gsi_remove (_gsi, false);
- continue;
-   }
+  && gimple_call_internal_p (stmt))
+   switch (gimple_call_internal_fn (stmt))
+ {
+ case IFN_TSAN_FUNC_EXIT:
+   /* Drop .TSAN_FUNC_EXIT () internal calls during inlining.  */
+   gsi_remove (_gsi, false);
+   continue;
+ case IFN_ASAN_MARK:
+   /* Drop .ASAN_MARK internal calls during inlining into
+  no_sanitize functions.  */
+   if (!sanitize_flags_p (SANITIZE_ADDRESS, id->dst_fn)
+   && !sanitize_flags_p (SANITIZE_HWADDRESS, id->dst_fn))
+ {
+   gsi_remove (_gsi, false);
+   continue;
+ }
+   break;
+ default:
+   break;
+ }
 
  /* Statements produced by inlining can be unfolded, especially
 when we constant propagated some operands.  We can't fold


[gcc r13-8735] reassoc: Fix up optimize_range_tests_to_bit_test [PR114965]

2024-05-08 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:44d84db11ab724c34a8b1f8c0e06da1cc78439a2

commit r13-8735-g44d84db11ab724c34a8b1f8c0e06da1cc78439a2
Author: Jakub Jelinek 
Date:   Wed May 8 10:17:32 2024 +0200

reassoc: Fix up optimize_range_tests_to_bit_test [PR114965]

The optimize_range_tests_to_bit_test optimization normally emits a range
test first:
  if (entry_test_needed)
{
  tem = build_range_check (loc, optype, unshare_expr (exp),
   false, lowi, high);
  if (tem == NULL_TREE || is_gimple_val (tem))
continue;
}
so during the bit test we already know that exp is in the [lowi, high]
range, but skips it if we have range info which tells us this isn't
necessary.
Also, normally it emits shifts by exp - lowi counter, but has an
optimization to use just exp counter if the mask isn't a more expensive
constant in that case and lowi is > 0 and high is smaller than prec.

The following testcase is miscompiled because the two abnormal cases
are triggered.  The range of exp is [43, 43][48, 48][95, 95], so we on
64-bit arch decide we don't need the entry test, because 95 - 43 < 64.
And we also decide to use just exp as counter, because the range test
tests just for exp == 43 || exp == 48, so high is smaller than 64 too.
Because 95 is in the exp range, we can't do that, we'd either need to
do a range test first, i.e.
if (exp - 43U <= 48U - 43U) if ((1UL << exp) & mask1))
or need to subtract lowi from the shift counter, i.e.
if ((1UL << (exp - 43)) & mask2)
but can't do both unless r.upper_bound () is < prec.

The following patch ensures that.
    
2024-05-08  Jakub Jelinek  

PR tree-optimization/114965
* tree-ssa-reassoc.cc (optimize_range_tests_to_bit_test): Don't try 
to
optimize away exp - lowi subtraction from shift count unless entry
test is emitted or unless r.upper_bound () is smaller than prec.

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

(cherry picked from commit 9adec2d91e62a479474ae79df5b455fd4b8463ba)

Diff:
---
 gcc/testsuite/gcc.c-torture/execute/pr114965.c | 30 ++
 gcc/tree-ssa-reassoc.cc|  3 ++-
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.c-torture/execute/pr114965.c 
b/gcc/testsuite/gcc.c-torture/execute/pr114965.c
new file mode 100644
index ..89d68e187015
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr114965.c
@@ -0,0 +1,30 @@
+/* PR tree-optimization/114965 */
+
+static void
+foo (const char *x)
+{
+
+  char a = '0';
+  while (1)
+{
+  switch (*x)
+   {
+   case '_':
+   case '+':
+ a = *x;
+ x++;
+ continue;
+   default:
+ break;
+   }
+  break;
+}
+  if (a == '0' || a == '+')
+__builtin_abort ();
+}
+
+int
+main ()
+{
+  foo ("_");
+}
diff --git a/gcc/tree-ssa-reassoc.cc b/gcc/tree-ssa-reassoc.cc
index c5020465c2b3..d8f5471951af 100644
--- a/gcc/tree-ssa-reassoc.cc
+++ b/gcc/tree-ssa-reassoc.cc
@@ -3411,7 +3411,8 @@ optimize_range_tests_to_bit_test (enum tree_code opcode, 
int first, int length,
 We can avoid then subtraction of the minimum value, but the
 mask constant could be perhaps more expensive.  */
  if (compare_tree_int (lowi, 0) > 0
- && compare_tree_int (high, prec) < 0)
+ && compare_tree_int (high, prec) < 0
+ && (entry_test_needed || wi::ltu_p (r.upper_bound (), prec)))
{
  int cost_diff;
  HOST_WIDE_INT m = tree_to_uhwi (lowi);


[gcc r13-8732] gimple-ssa-sprintf: Use [0, 1] range for %lc with (wint_t) 0 argument [PR114876]

2024-05-08 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:e07df053031e109c50387c92d689950de1d193ab

commit r13-8732-ge07df053031e109c50387c92d689950de1d193ab
Author: Jakub Jelinek 
Date:   Tue Apr 30 11:22:32 2024 +0200

gimple-ssa-sprintf: Use [0, 1] range for %lc with (wint_t) 0 argument 
[PR114876]

Seems when Martin S. implemented this, he coded there strict reading
of the standard, which said that %lc with (wint_t) 0 argument is handled
as wchar_t[2] temp = { arg, 0 }; %ls with temp arg and so shouldn't print
any values.  But, most of the libc implementations actually handled that
case like %c with '\0' argument, adding a single NUL character, the only
known exception is musl.
Recently, C23 changed this in response to GB-141 and POSIX in
https://austingroupbugs.net/view.php?id=1647
so that it should have the same behavior as %c with '\0'.

Because there is implementation divergence, the following patch uses
a range rather than hardcoding it to all 1s (i.e. the %c behavior),
though the likely case is still 1 (forward looking plus most of
implementations).
The res.knownrange = true; assignment removed is redundant due to
the same assignment done unconditionally before the if statement,
rest is formatting fixes.

I don't think the min >= 0 && min < 128 case is right either, I'd think
it should be min >= 0 && max < 128, otherwise it is just some possible
inputs are (maybe) ASCII and there can be others, but this code is a total
mess anyway, with the min, max, likely (somewhere in [min, max]?) and then
unlikely possibly larger than max, dunno, perhaps for at least some chars
in the ASCII range the likely case could be for the ascii case; so perhaps
just the one_2_one_ascii shouldn't set max to 1 and mayfail should be true
for max >= 128.  Anyway, didn't feel I should touch that right now.
    
2024-04-30  Jakub Jelinek  

PR tree-optimization/114876
* gimple-ssa-sprintf.cc (format_character): For min == 0 && max == 
0,
set max, likely and unlikely members to 1 rather than 0.  Remove
useless res.knownrange = true;.  Formatting fixes.

* gcc.dg/pr114876.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust expected
diagnostics.

(cherry picked from commit 6c6b70f07208ca14ba783933988c04c6fc2fff42)

Diff:
---
 gcc/gimple-ssa-sprintf.cc  | 20 +++--
 gcc/testsuite/gcc.dg/pr114876.c| 34 ++
 .../gcc.dg/tree-ssa/builtin-sprintf-warn-1.c   | 12 
 3 files changed, 51 insertions(+), 15 deletions(-)

diff --git a/gcc/gimple-ssa-sprintf.cc b/gcc/gimple-ssa-sprintf.cc
index 18975708d2c2..e02977f0ac39 100644
--- a/gcc/gimple-ssa-sprintf.cc
+++ b/gcc/gimple-ssa-sprintf.cc
@@ -2170,8 +2170,7 @@ format_character (const directive , tree arg, 
pointer_query _qry)
 
   res.knownrange = true;
 
-  if (dir.specifier == 'C'
-  || dir.modifier == FMT_LEN_l)
+  if (dir.specifier == 'C' || dir.modifier == FMT_LEN_l)
 {
   /* A wide character can result in as few as zero bytes.  */
   res.range.min = 0;
@@ -2182,10 +2181,13 @@ format_character (const directive , tree arg, 
pointer_query _qry)
{
  if (min == 0 && max == 0)
{
- /* The NUL wide character results in no bytes.  */
- res.range.max = 0;
- res.range.likely = 0;
- res.range.unlikely = 0;
+ /* In strict reading of older ISO C or POSIX, this required
+no characters to be emitted.  ISO C23 changes that, so
+does POSIX, to match what has been implemented in most of the
+implementations, namely emitting a single NUL character.
+Let's use 0 for minimum and 1 for all the other values.  */
+ res.range.max = 1;
+ res.range.likely = res.range.unlikely = 1;
}
  else if (min >= 0 && min < 128)
{
@@ -2193,11 +2195,12 @@ format_character (const directive , tree arg, 
pointer_query _qry)
 is not a 1-to-1 mapping to the source character set or
 if the source set is not ASCII.  */
  bool one_2_one_ascii
-   = (target_to_host_charmap[0] == 1 && target_to_host ('a') == 
97);
+   = (target_to_host_charmap[0] == 1
+  && target_to_host ('a') == 97);
 
  /* A wide character in the ASCII range most likely results
 in a single byte, and only unlikely in up to MB_LEN_MAX.  */
- res.range.max = one_2_one_ascii ? 1 : target_mb_len_max ();;
+ res.range.max = one_2_one_ascii ? 1 : target_mb_len_max ();
  res.range.likely = 1;
  res.range.unlikely = target_mb_len_max ();
  

[gcc r13-8731] c++: Fix constexpr evaluation of parameters passed by invisible reference [PR111284]

2024-05-08 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:6f1b3f9c97e17aa717ae61bc70afa27adcb7ef44

commit r13-8731-g6f1b3f9c97e17aa717ae61bc70afa27adcb7ef44
Author: Jakub Jelinek 
Date:   Thu Apr 25 20:45:04 2024 +0200

c++: Fix constexpr evaluation of parameters passed by invisible reference 
[PR111284]

My r9-6136 changes to make a copy of constexpr function bodies before
genericization modifies it broke the constant evaluation of non-POD
arguments passed by value.
In the callers such arguments are passed as reference to usually a
TARGET_EXPR, but on the callee side until genericization they are just
direct uses of a PARM_DECL with some class type.
In cxx_bind_parameters_in_call I've used convert_from_reference to
pretend it is passed by value and then cxx_eval_constant_expression
is called there and evaluates that as an rvalue, followed by
adjust_temp_type if the types don't match exactly (e.g. const Foo
argument and passing to it reference to Foo TARGET_EXPR).

The reason this doesn't work is that when the TARGET_EXPR in the caller
is constant initialized, this for it is the address of the TARGET_EXPR_SLOT,
but if the code later on pretends the PARM_DECL is just initialized to the
rvalue of the constant evaluation of the TARGET_EXPR, it is as if there
is a bitwise copy of the TARGET_EXPR to the callee, so this in the callee
is then address of the PARM_DECL in the callee.

The following patch attempts to fix that by constexpr evaluation of such
arguments in the caller as an lvalue instead of rvalue, and on the callee
side when seeing such a PARM_DECL, if we want an lvalue, lookup the value
(lvalue) saved in ctx->globals (if any), and if wanting an rvalue,
recursing with vc_prvalue on the looked up value (because it is there
as an lvalue, nor rvalue).

adjust_temp_type doesn't work for lvalues of non-scalarish types, for
such types it relies on changing the type of a CONSTRUCTOR, but on the
other side we know what we pass to the argument is addressable, so
the patch on type mismatch takes address of the argument value, casts
to reference to the desired type and dereferences it.

2024-04-25  Jakub Jelinek  

PR c++/111284
* constexpr.cc (cxx_bind_parameters_in_call): For PARM_DECLs with
TREE_ADDRESSABLE types use vc_glvalue rather than vc_prvalue for
cxx_eval_constant_expression and if it doesn't have the same
type as it should, cast the reference type to reference to type
before convert_from_reference and instead of adjust_temp_type
take address of the arg, cast to reference to type and then
convert_from_reference.
(cxx_eval_constant_expression) : For lval case
on parameters with TREE_ADDRESSABLE types lookup result in
ctx->globals if possible.  Otherwise if lookup in ctx->globals
was successful for parameter with TREE_ADDRESSABLE type,
recurse with vc_prvalue on the returned value.

* g++.dg/cpp1z/constexpr-111284.C: New test.

(cherry picked from commit f541757ba4632e204169dd08a5f10c782199af42)

Diff:
---
 gcc/cp/constexpr.cc   | 44 +--
 gcc/testsuite/g++.dg/cpp1z/constexpr-111284.C | 19 
 2 files changed, 53 insertions(+), 10 deletions(-)

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index 216b98122007..acb5496085bb 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -1800,13 +1800,18 @@ cxx_bind_parameters_in_call (const constexpr_ctx *ctx, 
tree t, tree fun,
  x = build_address (x);
}
   if (TREE_ADDRESSABLE (type))
-   /* Undo convert_for_arg_passing work here.  */
-   x = convert_from_reference (x);
-  /* Normally we would strip a TARGET_EXPR in an initialization context
-such as this, but here we do the elision differently: we keep the
-TARGET_EXPR, and use its CONSTRUCTOR as the value of the parm.  */
-  arg = cxx_eval_constant_expression (ctx, x, vc_prvalue,
- non_constant_p, overflow_p);
+   {
+ /* Undo convert_for_arg_passing work here.  */
+ x = convert_from_reference (x);
+ arg = cxx_eval_constant_expression (ctx, x, vc_glvalue,
+ non_constant_p, overflow_p);
+   }
+  else
+   /* Normally we would strip a TARGET_EXPR in an initialization context
+  such as this, but here we do the elision differently: we keep the
+  TARGET_EXPR, and use its CONSTRUCTOR as the value of the parm.  */
+   arg = cxx_eval_constant_expression (ctx, x, vc_prvalue,
+   non_constant_p, overflow_p);
   /* Don't VERIFY_CONSTANT here.  */
   if (*non_constant_p && ctx->quiet)
break;

[gcc r13-8730] openmp: Copy DECL_LANG_SPECIFIC and DECL_LANG_FLAG_? to tree-nested decl copy [PR114825]

2024-05-08 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:6d30cfc3fc88976151d0d10e73e10111ccb71ee0

commit r13-8730-g6d30cfc3fc88976151d0d10e73e10111ccb71ee0
Author: Jakub Jelinek 
Date:   Thu Apr 25 20:09:35 2024 +0200

openmp: Copy DECL_LANG_SPECIFIC and DECL_LANG_FLAG_? to tree-nested decl 
copy [PR114825]

tree-nested.cc creates in 2 spots artificial VAR_DECLs, one of them is used
both for debug info and OpenMP/OpenACC lowering purposes, the other solely 
for
OpenMP/OpenACC lowering purposes.
When the decls are used in OpenMP/OpenACC lowering, the OMP langhooks 
(mostly
Fortran, C just a little and C++ doesn't have nested functions) then inspect
the flags on the vars and based on that decide how to lower the 
corresponding
clauses.

Unfortunately we weren't copying DECL_LANG_SPECIFIC and DECL_LANG_FLAG_?, so
the langhooks made decisions on the default flags on those instead.
As the original decl isn't necessarily a VAR_DECL, could be e.g. PARM_DECL,
using copy_node wouldn't work properly, so this patch just copies those
flags in addition to other flags it was copying already.  And I've removed
code duplication by introducing a helper function which does copying common
to both uses.

2024-04-25  Jakub Jelinek  

PR fortran/114825
* tree-nested.cc (get_debug_decl): New function.
(get_nonlocal_debug_decl): Use it.
(get_local_debug_decl): Likewise.

* gfortran.dg/gomp/pr114825.f90: New test.

(cherry picked from commit 14d48516e588ad2b35e2007b3970bdcb1b3f145c)

Diff:
---
 gcc/testsuite/gfortran.dg/gomp/pr114825.f90 | 16 
 gcc/tree-nested.cc  | 61 -
 2 files changed, 49 insertions(+), 28 deletions(-)

diff --git a/gcc/testsuite/gfortran.dg/gomp/pr114825.f90 
b/gcc/testsuite/gfortran.dg/gomp/pr114825.f90
new file mode 100644
index ..b635476af61e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/gomp/pr114825.f90
@@ -0,0 +1,16 @@
+! PR fortran/114825
+
+subroutine pr114825(b)
+  type t
+real, allocatable :: m(:)
+  end type t
+  type(t), allocatable, target :: b(:)
+  type(t), pointer :: d
+  !$omp parallel private(d)
+  d => b(1)
+  !$omp end parallel
+contains
+  subroutine sub
+d => b(1)
+  end subroutine sub
+end subroutine pr114825
diff --git a/gcc/tree-nested.cc b/gcc/tree-nested.cc
index 1418e1f7f562..0f44b3dc735e 100644
--- a/gcc/tree-nested.cc
+++ b/gcc/tree-nested.cc
@@ -1039,6 +1039,37 @@ get_frame_field (struct nesting_info *info, tree 
target_context,
 
 static void note_nonlocal_vla_type (struct nesting_info *info, tree type);
 
+/* Helper for get_nonlocal_debug_decl and get_local_debug_decl.  */
+
+static tree
+get_debug_decl (tree decl)
+{
+  tree new_decl
+= build_decl (DECL_SOURCE_LOCATION (decl),
+ VAR_DECL, DECL_NAME (decl), TREE_TYPE (decl));
+  DECL_ARTIFICIAL (new_decl) = DECL_ARTIFICIAL (decl);
+  DECL_IGNORED_P (new_decl) = DECL_IGNORED_P (decl);
+  TREE_THIS_VOLATILE (new_decl) = TREE_THIS_VOLATILE (decl);
+  TREE_SIDE_EFFECTS (new_decl) = TREE_SIDE_EFFECTS (decl);
+  TREE_READONLY (new_decl) = TREE_READONLY (decl);
+  TREE_ADDRESSABLE (new_decl) = TREE_ADDRESSABLE (decl);
+  DECL_SEEN_IN_BIND_EXPR_P (new_decl) = 1;
+  if ((TREE_CODE (decl) == PARM_DECL
+   || TREE_CODE (decl) == RESULT_DECL
+   || VAR_P (decl))
+  && DECL_BY_REFERENCE (decl))
+DECL_BY_REFERENCE (new_decl) = 1;
+  /* Copy DECL_LANG_SPECIFIC and DECL_LANG_FLAG_* for OpenMP langhook
+ purposes.  */
+  DECL_LANG_SPECIFIC (new_decl) = DECL_LANG_SPECIFIC (decl);
+#define COPY_DLF(n) DECL_LANG_FLAG_##n (new_decl) = DECL_LANG_FLAG_##n (decl)
+  COPY_DLF (0); COPY_DLF (1); COPY_DLF (2); COPY_DLF (3);
+  COPY_DLF (4); COPY_DLF (5); COPY_DLF (6); COPY_DLF (7);
+  COPY_DLF (8);
+#undef COPY_DLF
+  return new_decl;
+}
+
 /* A subroutine of convert_nonlocal_reference_op.  Create a local variable
in the nested function with DECL_VALUE_EXPR set to reference the true
variable in the parent function.  This is used both for debug info
@@ -1086,21 +1117,8 @@ get_nonlocal_debug_decl (struct nesting_info *info, tree 
decl)
 x = build_simple_mem_ref_notrap (x);
 
   /* ??? We should be remapping types as well, surely.  */
-  new_decl = build_decl (DECL_SOURCE_LOCATION (decl),
-VAR_DECL, DECL_NAME (decl), TREE_TYPE (decl));
+  new_decl = get_debug_decl (decl);
   DECL_CONTEXT (new_decl) = info->context;
-  DECL_ARTIFICIAL (new_decl) = DECL_ARTIFICIAL (decl);
-  DECL_IGNORED_P (new_decl) = DECL_IGNORED_P (decl);
-  TREE_THIS_VOLATILE (new_decl) = TREE_THIS_VOLATILE (decl);
-  TREE_SIDE_EFFECTS (new_decl) = TREE_SIDE_EFFECTS (decl);
-  TREE_READONLY (new_decl) = TREE_READONLY (decl);
-  TREE_ADDRESSABLE (new_decl) = TREE_ADDRESSABLE (decl);
-  DECL_SEEN_IN_BIND_EXPR_P (new_decl) = 1;
-  if ((TREE_CODE (decl) == PARM_DECL
-   || TREE_CODE (dec

[gcc r13-8729] libstdc++: Workaround kernel-headers on s390x-linux

2024-05-08 Thread Jakub Jelinek via Libstdc++-cvs
https://gcc.gnu.org/g:f1b1d515aa5836844cdb45e8bb2b941784f78fd2

commit r13-8729-gf1b1d515aa5836844cdb45e8bb2b941784f78fd2
Author: Jakub Jelinek 
Date:   Mon Apr 22 18:00:06 2024 +0200

libstdc++: Workaround kernel-headers on s390x-linux

We see
FAIL: 17_intro/headers/c++1998/all_attributes.cc   (test for excess errors)
FAIL: 17_intro/headers/c++2011/all_attributes.cc   (test for excess errors)
FAIL: 17_intro/headers/c++2014/all_attributes.cc   (test for excess errors)
FAIL: 17_intro/headers/c++2017/all_attributes.cc   (test for excess errors)
FAIL: 17_intro/headers/c++2020/all_attributes.cc   (test for excess errors)
FAIL: 17_intro/names.cc  -std=gnu++17 (test for excess errors)
on s390x-linux.
The first 5 are due to kernel-headers not using uglified attribute names,
where  contains
__attribute__((packed, aligned(4)))
I've filed a downstream bugreport for this in
https://bugzilla.redhat.com/show_bug.cgi?id=2276084
(not really sure where to report kernel-headers issues upstream), while the
last one is due to  from glibc containing:
  #ifdef __USE_MISC
  # define __ctx(fld) fld
  #else
  # define __ctx(fld) __ ## fld
  #endif
  ...
  typedef union
{
  double  __ctx(d);
  float   __ctx(f);
} fpreg_t;
and g++ predefining -D_GNU_SOURCE which implies define __USE_MISC.

The following patch adds a workaround for this on the libstdc++ testsuite
side.

2024-04-22  Jakub Jelinek  

* testsuite/17_intro/names.cc (d, f): Undefine on s390*-linux*.
* testsuite/17_intro/headers/c++1998/all_attributes.cc (packed): 
Don't
define on s390.
* testsuite/17_intro/headers/c++2011/all_attributes.cc (packed):
Likewise.
* testsuite/17_intro/headers/c++2014/all_attributes.cc (packed):
Likewise.
* testsuite/17_intro/headers/c++2017/all_attributes.cc (packed):
Likewise.
* testsuite/17_intro/headers/c++2020/all_attributes.cc (packed):
Likewise.

(cherry picked from commit cf5f7791056b3ed993bc8024be767a86157514a9)

Diff:
---
 libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc | 4 
 libstdc++-v3/testsuite/17_intro/headers/c++2011/all_attributes.cc | 4 
 libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc | 4 
 libstdc++-v3/testsuite/17_intro/headers/c++2017/all_attributes.cc | 4 
 libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc | 4 
 libstdc++-v3/testsuite/17_intro/names.cc  | 6 ++
 6 files changed, 26 insertions(+)

diff --git a/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc 
b/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc
index 74268b6a482f..658063bd0a4e 100644
--- a/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc
+++ b/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc
@@ -29,7 +29,11 @@
 # define noreturn 1
 # define visibility 1
 #endif
+#ifndef __s390__
+// kernel-headers  uses __attribute__((packed,aligned(4))) on
+// S390.
 #define packed 1
+#endif
 #define pure 1
 // glibc's sysdeps/unix/sysv/linux/arm/sys/ucontext.h uses this on ARM.
 #ifndef __arm__
diff --git a/libstdc++-v3/testsuite/17_intro/headers/c++2011/all_attributes.cc 
b/libstdc++-v3/testsuite/17_intro/headers/c++2011/all_attributes.cc
index 5d0c5fe81776..f1bcc1fbbc81 100644
--- a/libstdc++-v3/testsuite/17_intro/headers/c++2011/all_attributes.cc
+++ b/libstdc++-v3/testsuite/17_intro/headers/c++2011/all_attributes.cc
@@ -29,7 +29,11 @@
 # define visibility 1
 #endif
 #define no_unique_address 1
+#ifndef __s390__
+// kernel-headers  uses __attribute__((packed,aligned(4))) on
+// S390.
 #define packed 1
+#endif
 #define pure 1
 // glibc's sysdeps/unix/sysv/linux/arm/sys/ucontext.h uses this on ARM.
 #ifndef __arm__
diff --git a/libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc 
b/libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc
index 3cac2190ec77..48e7ef64afbe 100644
--- a/libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc
+++ b/libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc
@@ -29,7 +29,11 @@
 # define visibility 1
 #endif
 #define no_unique_address 1
+#ifndef __s390__
+// kernel-headers  uses __attribute__((packed,aligned(4))) on
+// S390.
 #define packed 1
+#endif
 #define pure 1
 // glibc's sysdeps/unix/sysv/linux/arm/sys/ucontext.h uses this on ARM.
 #ifndef __arm__
diff --git a/libstdc++-v3/testsuite/17_intro/headers/c++2017/all_attributes.cc 
b/libstdc++-v3/testsuite/17_intro/headers/c++2017/all_attributes.cc
index f607532aa90d..03e4e23c6865 100644
--- a/libstdc++-v3/testsuite/17_intro/headers/c++2017/all_attributes.cc
+++ b/libstdc++-v3/testsuite/17_intro/headers/c++2017/all_attributes.cc
@@ -28,7 +28,11 @@
 # define visibility 1
 #endif

Re: FE C++ requirement

2024-05-08 Thread Jakub Jelinek via Gcc
On Tue, May 07, 2024 at 04:40:55PM -0400, James K. Lowden wrote:
> /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not
> found (required by build-O2/gcc/cobol1

The cc1/cc1plus/f951/... binaries are normally linked with
-static-libstdc++ -static-libgcc in second and later stages (first
stage is linked against the host libstdc++, so not a problem, but
even that stage is often linked with it).
See e.g. --with-static-standard-libraries configure option in toplevel
configury.

Perhaps you don't link cobol1 with the correct make variables
as other FEs are linked?

I think it is $(LDFLAGS) that is needed:
grep ^LDFLAGS *gcc/Makefile
gcc/Makefile:LDFLAGS = -static-libstdc++ -static-libgcc  
prev-gcc/Makefile:LDFLAGS = -static-libstdc++ -static-libgcc  
stage1-gcc/Makefile:LDFLAGS = -static-libstdc++ -static-libgcc  
but better follow what other FEs do in Make-lang.in
E.g. the linking of the FE binaries need to be specially chained for
--enable-link-serialization
or
--enable-link-serialization=N
such that only N binaries are linked together, etc.
c++.serial = cc1plus$(exeext)
...
cc1plus$(exeext): $(CXX_OBJS) cc1plus-checksum.o $(BACKEND) $(CODYLIB) 
$(LIBDEPS) $(c++.prev)
@$(call LINK_PROGRESS,$(INDEX.c++),start)
+$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
  $(CXX_OBJS) cc1plus-checksum.o $(BACKEND) $(CODYLIB) \
$(LIBS) $(BACKENDLIBS)
@$(call LINK_PROGRESS,$(INDEX.c++),end)
does that (the lang.serial line, $(lang.prev) dependency, the
LINK_PROGRESS.lang calls, using $(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) ...
$(BACKEND) $(BACKENDLIBS) $(LIBS) too.

Jakub



Re: Error in gcc 14 porting document

2024-05-08 Thread Jakub Jelinek via Gcc
On Wed, May 08, 2024 at 01:15:21PM +0200, Matthias Urlichs via Gcc wrote:
> On 08.05.24 11:50, Richard Biener wrote:
> > > "With the |-fpermissive| option, programs can use C99 inlining semantics
> > > and features that were removed from C99"
> > > 
> > > Umm, what? this sentence doesn't make sense.
> > In the context of mentioning the -std=gnu89/-std=c89 workarounds
> 
> I thought as much, but shouldn't it then say "programs can use *C89*
> inlining semantics that were removed from C99"?

There was no C89 inline semantics, only GNU89 one.  Only C99 introduced
inline keyword into the standard.

Jakub



[gcc/redhat/heads/gcc-14-branch] (31 commits) Merge commit 'r14-10184-gd54151df3ba0ee3203e0b8cb8f8fcd168a

2024-05-08 Thread Jakub Jelinek via Gcc-cvs
The branch 'redhat/heads/gcc-14-branch' was updated to point to:

 9ae733ecd3cd... Merge commit 'r14-10184-gd54151df3ba0ee3203e0b8cb8f8fcd168a

It previously pointed to:

 748fd0ecf84c... Merge commit 'r14-10154-g7a00c459cbb913ac165a39d344a48fc278

Diff:

Summary of changes (added commits):
---

  9ae733e... Merge commit 'r14-10184-gd54151df3ba0ee3203e0b8cb8f8fcd168a
  d54151d... reassoc: Fix up optimize_range_tests_to_bit_test [PR114965] (*)
  cacc480... c++/c-common: Fix convert_vector_to_array_for_subscript for (*)
  61a095b... c++/modules: Stream unmergeable temporaries by value again  (*)
  f43f346... expansion: Use __trunchfbf2 calls rather than __extendhfbf2 (*)
  aca573e... tree-inline: Remove .ASAN_MARK calls when inlining function (*)
  07dab3f... [PR modula2/113768][PR modula2/114133] bugfix constants mus (*)
  23cf010... libgomp: Add gfx90c, 1036 and 1103 declare variant tests (*)
  a1c8ae1... gimple-ssa-sprintf: Use [0, 1] range for %lc with (wint_t)  (*)
  390bd23... c++/modules: imported spec befriending class tmpl [PR114889 (*)
  c6141ad... AVR: ipa/92606 - Don't optimize PROGMEM data against non-PR (*)
  43b730b... Bump BASE-VER (*)
  cd0059a... Update ChangeLog and version files for release (*)
  4f12e06... Update gennews for GCC 14. (*)
  308a39c... Daily bump. (*)
  c7b4305... testsuite: c++: Skip g++.dg/analyzer on Solaris [PR111475] (*)
  765ddff... Daily bump. (*)
  43b7e2f... Daily bump. (*)
  532d775... Daily bump. (*)
  d811080... [PATCH] PR modula2/114929 for loop fails to iterate down to (*)
  3b4d6b6... c++: initializer_list and EH [PR114935] (*)
  db447ec... Revert "tree-optimization/114921 - _Float16 -> __bf16 isn't (*)
  d7c06a8... libstdc++: Update powerpc-linux-gnu baseline_symbols (*)
  7963194... RISC-V: Add testcase for pr114734 (*)
  5c42872... middle-end/114734 - wrong code with expand_call_mem_ref (*)
  242fbc0... cfgrtl: Fix MEM_EXPR update in duplicate_insn_chain [PR1149 (*)
  fa7e05d... tree-optimization/114921 - _Float16 -> __bf16 isn't noop (*)
  f86f197... Daily bump. (*)
  8e39d4f... Regenerate gcc.pot (*)
  590a065... Daily bump. (*)
  9ccb16d... Daily bump. (*)

(*) This commit already exists in another branch.
Because the reference `refs/vendors/redhat/heads/gcc-14-branch' matches
your hooks.email-new-commits-only configuration,
no separate email is sent for this commit.


[gcc(refs/vendors/redhat/heads/gcc-14-branch)] Merge commit 'r14-10184-gd54151df3ba0ee3203e0b8cb8f8fcd168a766c51' into redhat/gcc-14-branch

2024-05-08 Thread Jakub Jelinek via Libstdc++-cvs
https://gcc.gnu.org/g:9ae733ecd3cd76d7e2f99385520783b01ab7e5dd

commit 9ae733ecd3cd76d7e2f99385520783b01ab7e5dd
Merge: 748fd0ecf84c d54151df3ba0
Author: Jakub Jelinek 
Date:   Wed May 8 10:21:32 2024 +0200

Merge commit 'r14-10184-gd54151df3ba0ee3203e0b8cb8f8fcd168a766c51' into 
redhat/gcc-14-branch

Diff:

 ChangeLog  |4 +
 c++tools/ChangeLog |4 +
 config/ChangeLog   |4 +
 contrib/ChangeLog  |4 +
 contrib/gennews|1 +
 contrib/header-tools/ChangeLog |4 +
 contrib/reghunt/ChangeLog  |4 +
 contrib/regression/ChangeLog   |4 +
 fixincludes/ChangeLog  |4 +
 gcc/BASE-VER   |2 +-
 gcc/ChangeLog  |   53 +
 gcc/DATESTAMP  |2 +-
 gcc/DEV-PHASE  |1 -
 gcc/ada/ChangeLog  |4 +
 gcc/analyzer/ChangeLog |4 +
 gcc/c-family/ChangeLog |4 +
 gcc/c-family/c-common.cc   |7 +-
 gcc/c/ChangeLog|4 +
 gcc/cfgrtl.cc  |3 +-
 gcc/config/avr/avr.cc  |6 +
 gcc/cp/ChangeLog   |   26 +
 gcc/cp/call.cc |3 +
 gcc/cp/constexpr.cc|3 +-
 gcc/cp/cp-gimplify.cc  |   18 +-
 gcc/cp/cp-tree.h   |1 +
 gcc/cp/init.cc |2 +-
 gcc/cp/module.cc   |2 +
 gcc/cp/typeck2.cc  |   34 +-
 gcc/d/ChangeLog|4 +
 gcc/expr.cc|   12 +-
 gcc/fortran/ChangeLog  |   18 +
 gcc/gimple-ssa-sprintf.cc  |   20 +-
 gcc/go/ChangeLog   |4 +
 gcc/internal-fn.cc |6 +-
 gcc/jit/ChangeLog  |4 +
 gcc/lto/ChangeLog  |4 +
 gcc/m2/ChangeLog   |   19 +
 gcc/m2/gm2-compiler/M2Quads.mod|  191 +-
 gcc/objc/ChangeLog |4 +
 gcc/objcp/ChangeLog|4 +
 gcc/optabs-libfuncs.cc |4 +-
 gcc/po/ChangeLog   |8 +
 gcc/po/gcc.pot | 2840 ++--
 gcc/rust/ChangeLog |4 +
 gcc/testsuite/ChangeLog|   61 +
 gcc/testsuite/g++.dg/analyzer/analyzer.exp |5 +
 gcc/testsuite/g++.dg/cpp0x/initlist-eh1.C  |   25 +
 gcc/testsuite/g++.dg/modules/friend-8_a.H  |   23 +
 gcc/testsuite/g++.dg/modules/friend-8_b.C  |9 +
 gcc/testsuite/g++.dg/modules/pr114856.h|   12 +
 gcc/testsuite/g++.dg/modules/pr114856_a.H  |5 +
 gcc/testsuite/g++.dg/modules/pr114856_b.C  |5 +
 gcc/testsuite/g++.dg/torture/vector-subaccess-1.C  |   23 +
 gcc/testsuite/gcc.c-torture/execute/pr114965.c |   30 +
 gcc/testsuite/gcc.dg/asan/pr114956.c   |   26 +
 gcc/testsuite/gcc.dg/pr114876.c|   34 +
 gcc/testsuite/gcc.dg/pr114907.c|   27 +
 gcc/testsuite/gcc.dg/pr83415.c |2 +-
 .../gcc.dg/tree-ssa/builtin-sprintf-warn-1.c   |   12 +-
 gcc/testsuite/gcc.target/avr/torture/pr92606.c |   57 +
 .../gcc.target/riscv/rvv/autovec/pr114734.c|   25 +
 .../gm2/extensions/run/pass/callingc10.mod |6 +-
 .../gm2/extensions/run/pass/callingc11.mod |6 +-
 gcc/testsuite/gm2/extensions/run/pass/vararg2.mod  |6 +-
 gcc/testsuite/gm2/iso/run/pass/packed.mod  |2 +
 gcc/testsuite/gm2/pim/run/pass/testforloopzero.mod |   33 +
 .../gm2/pim/run/pass/testforloopzero2.mod  |   35 +
 .../gm2/pim/run/pass/testforloopzero3.mod  |   32 +
 .../gm2/pim/run/pass/testforloopzero4.mod  |   32 +
 gcc/tree-inline.cc |   28 +-
 gcc/tree-ssa-reassoc.cc|3 +-
 gnattools/ChangeLog|4 +
 gotools/ChangeLog  |4 +
 include/ChangeLog  |4 +
 libada/ChangeLog   |4 +
 libatomic/ChangeLog|4

[gcc r14-10184] reassoc: Fix up optimize_range_tests_to_bit_test [PR114965]

2024-05-08 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:d54151df3ba0ee3203e0b8cb8f8fcd168a766c51

commit r14-10184-gd54151df3ba0ee3203e0b8cb8f8fcd168a766c51
Author: Jakub Jelinek 
Date:   Wed May 8 10:17:32 2024 +0200

reassoc: Fix up optimize_range_tests_to_bit_test [PR114965]

The optimize_range_tests_to_bit_test optimization normally emits a range
test first:
  if (entry_test_needed)
{
  tem = build_range_check (loc, optype, unshare_expr (exp),
   false, lowi, high);
  if (tem == NULL_TREE || is_gimple_val (tem))
continue;
}
so during the bit test we already know that exp is in the [lowi, high]
range, but skips it if we have range info which tells us this isn't
necessary.
Also, normally it emits shifts by exp - lowi counter, but has an
optimization to use just exp counter if the mask isn't a more expensive
constant in that case and lowi is > 0 and high is smaller than prec.

The following testcase is miscompiled because the two abnormal cases
are triggered.  The range of exp is [43, 43][48, 48][95, 95], so we on
64-bit arch decide we don't need the entry test, because 95 - 43 < 64.
And we also decide to use just exp as counter, because the range test
tests just for exp == 43 || exp == 48, so high is smaller than 64 too.
Because 95 is in the exp range, we can't do that, we'd either need to
do a range test first, i.e.
if (exp - 43U <= 48U - 43U) if ((1UL << exp) & mask1))
or need to subtract lowi from the shift counter, i.e.
if ((1UL << (exp - 43)) & mask2)
but can't do both unless r.upper_bound () is < prec.

The following patch ensures that.
    
2024-05-08  Jakub Jelinek  

PR tree-optimization/114965
* tree-ssa-reassoc.cc (optimize_range_tests_to_bit_test): Don't try 
to
optimize away exp - lowi subtraction from shift count unless entry
test is emitted or unless r.upper_bound () is smaller than prec.

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

(cherry picked from commit 9adec2d91e62a479474ae79df5b455fd4b8463ba)

Diff:
---
 gcc/testsuite/gcc.c-torture/execute/pr114965.c | 30 ++
 gcc/tree-ssa-reassoc.cc|  3 ++-
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.c-torture/execute/pr114965.c 
b/gcc/testsuite/gcc.c-torture/execute/pr114965.c
new file mode 100644
index ..89d68e187015
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr114965.c
@@ -0,0 +1,30 @@
+/* PR tree-optimization/114965 */
+
+static void
+foo (const char *x)
+{
+
+  char a = '0';
+  while (1)
+{
+  switch (*x)
+   {
+   case '_':
+   case '+':
+ a = *x;
+ x++;
+ continue;
+   default:
+ break;
+   }
+  break;
+}
+  if (a == '0' || a == '+')
+__builtin_abort ();
+}
+
+int
+main ()
+{
+  foo ("_");
+}
diff --git a/gcc/tree-ssa-reassoc.cc b/gcc/tree-ssa-reassoc.cc
index 61f54f07b577..556ecdebe2d7 100644
--- a/gcc/tree-ssa-reassoc.cc
+++ b/gcc/tree-ssa-reassoc.cc
@@ -3418,7 +3418,8 @@ optimize_range_tests_to_bit_test (enum tree_code opcode, 
int first, int length,
 We can avoid then subtraction of the minimum value, but the
 mask constant could be perhaps more expensive.  */
  if (compare_tree_int (lowi, 0) > 0
- && compare_tree_int (high, prec) < 0)
+ && compare_tree_int (high, prec) < 0
+ && (entry_test_needed || wi::ltu_p (r.upper_bound (), prec)))
{
  int cost_diff;
  HOST_WIDE_INT m = tree_to_uhwi (lowi);


[gcc r15-315] reassoc: Fix up optimize_range_tests_to_bit_test [PR114965]

2024-05-08 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:9adec2d91e62a479474ae79df5b455fd4b8463ba

commit r15-315-g9adec2d91e62a479474ae79df5b455fd4b8463ba
Author: Jakub Jelinek 
Date:   Wed May 8 10:17:32 2024 +0200

reassoc: Fix up optimize_range_tests_to_bit_test [PR114965]

The optimize_range_tests_to_bit_test optimization normally emits a range
test first:
  if (entry_test_needed)
{
  tem = build_range_check (loc, optype, unshare_expr (exp),
   false, lowi, high);
  if (tem == NULL_TREE || is_gimple_val (tem))
continue;
}
so during the bit test we already know that exp is in the [lowi, high]
range, but skips it if we have range info which tells us this isn't
necessary.
Also, normally it emits shifts by exp - lowi counter, but has an
optimization to use just exp counter if the mask isn't a more expensive
constant in that case and lowi is > 0 and high is smaller than prec.

The following testcase is miscompiled because the two abnormal cases
are triggered.  The range of exp is [43, 43][48, 48][95, 95], so we on
64-bit arch decide we don't need the entry test, because 95 - 43 < 64.
And we also decide to use just exp as counter, because the range test
tests just for exp == 43 || exp == 48, so high is smaller than 64 too.
Because 95 is in the exp range, we can't do that, we'd either need to
do a range test first, i.e.
if (exp - 43U <= 48U - 43U) if ((1UL << exp) & mask1))
or need to subtract lowi from the shift counter, i.e.
if ((1UL << (exp - 43)) & mask2)
but can't do both unless r.upper_bound () is < prec.

The following patch ensures that.
    
2024-05-08  Jakub Jelinek  

PR tree-optimization/114965
* tree-ssa-reassoc.cc (optimize_range_tests_to_bit_test): Don't try 
to
optimize away exp - lowi subtraction from shift count unless entry
test is emitted or unless r.upper_bound () is smaller than prec.

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

Diff:
---
 gcc/testsuite/gcc.c-torture/execute/pr114965.c | 30 ++
 gcc/tree-ssa-reassoc.cc|  3 ++-
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.c-torture/execute/pr114965.c 
b/gcc/testsuite/gcc.c-torture/execute/pr114965.c
new file mode 100644
index ..89d68e187015
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr114965.c
@@ -0,0 +1,30 @@
+/* PR tree-optimization/114965 */
+
+static void
+foo (const char *x)
+{
+
+  char a = '0';
+  while (1)
+{
+  switch (*x)
+   {
+   case '_':
+   case '+':
+ a = *x;
+ x++;
+ continue;
+   default:
+ break;
+   }
+  break;
+}
+  if (a == '0' || a == '+')
+__builtin_abort ();
+}
+
+int
+main ()
+{
+  foo ("_");
+}
diff --git a/gcc/tree-ssa-reassoc.cc b/gcc/tree-ssa-reassoc.cc
index 61f54f07b577..556ecdebe2d7 100644
--- a/gcc/tree-ssa-reassoc.cc
+++ b/gcc/tree-ssa-reassoc.cc
@@ -3418,7 +3418,8 @@ optimize_range_tests_to_bit_test (enum tree_code opcode, 
int first, int length,
 We can avoid then subtraction of the minimum value, but the
 mask constant could be perhaps more expensive.  */
  if (compare_tree_int (lowi, 0) > 0
- && compare_tree_int (high, prec) < 0)
+ && compare_tree_int (high, prec) < 0
+ && (entry_test_needed || wi::ltu_p (r.upper_bound (), prec)))
{
  int cost_diff;
  HOST_WIDE_INT m = tree_to_uhwi (lowi);


[PATCH] reassoc: Fix up optimize_range_tests_to_bit_test [PR114965]

2024-05-08 Thread Jakub Jelinek
Hi!

The optimize_range_tests_to_bit_test optimization normally emits a range
test first:
  if (entry_test_needed)
{
  tem = build_range_check (loc, optype, unshare_expr (exp),
   false, lowi, high);
  if (tem == NULL_TREE || is_gimple_val (tem))
continue;
}
so during the bit test we already know that exp is in the [lowi, high]
range, but skips it if we have range info which tells us this isn't
necessary.
Also, normally it emits shifts by exp - lowi counter, but has an
optimization to use just exp counter if the mask isn't a more expensive
constant in that case and lowi is > 0 and high is smaller than prec.

The following testcase is miscompiled because the two abnormal cases
are triggered.  The range of exp is [43, 43][48, 48][95, 95], so we on
64-bit arch decide we don't need the entry test, because 95 - 43 < 64.
And we also decide to use just exp as counter, because the range test
tests just for exp == 43 || exp == 48, so high is smaller than 64 too.
Because 95 is in the exp range, we can't do that, we'd either need to
do a range test first, i.e.
if (exp - 43U <= 48U - 43U) if ((1UL << exp) & mask1))
or need to subtract lowi from the shift counter, i.e.
if ((1UL << (exp - 43)) & mask2)
but can't do both unless r.upper_bound () is < prec.

The following patch ensures that.

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

2024-05-08  Jakub Jelinek  

PR tree-optimization/114965
* tree-ssa-reassoc.cc (optimize_range_tests_to_bit_test): Don't try to
optimize away exp - lowi subtraction from shift count unless entry
test is emitted or unless r.upper_bound () is smaller than prec.

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

--- gcc/tree-ssa-reassoc.cc.jj  2024-01-12 10:07:58.384848977 +0100
+++ gcc/tree-ssa-reassoc.cc 2024-05-07 18:18:45.558814991 +0200
@@ -3418,7 +3418,8 @@ optimize_range_tests_to_bit_test (enum t
 We can avoid then subtraction of the minimum value, but the
 mask constant could be perhaps more expensive.  */
  if (compare_tree_int (lowi, 0) > 0
- && compare_tree_int (high, prec) < 0)
+ && compare_tree_int (high, prec) < 0
+ && (entry_test_needed || wi::ltu_p (r.upper_bound (), prec)))
{
  int cost_diff;
  HOST_WIDE_INT m = tree_to_uhwi (lowi);
--- gcc/testsuite/gcc.c-torture/execute/pr114965.c.jj   2024-05-07 
18:17:16.767031821 +0200
+++ gcc/testsuite/gcc.c-torture/execute/pr114965.c  2024-05-07 
18:15:52.332188943 +0200
@@ -0,0 +1,30 @@
+/* PR tree-optimization/114965 */
+
+static void
+foo (const char *x)
+{
+
+  char a = '0';
+  while (1)
+{
+  switch (*x)
+   {
+   case '_':
+   case '+':
+ a = *x;
+ x++;
+ continue;
+   default:
+ break;
+   }
+  break;
+}
+  if (a == '0' || a == '+')
+__builtin_abort ();
+}
+
+int
+main ()
+{
+  foo ("_");
+}

Jakub



gcc-wwwdocs branch master updated. 506a866eae7f722c532bdcd513da6b8134be4091

2024-05-07 Thread Jakub Jelinek via Gcc-cvs-wwwdocs
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gcc-wwwdocs".

The branch, master has been updated
   via  506a866eae7f722c532bdcd513da6b8134be4091 (commit)
  from  0053d65e4071ba2e25073fdc2e1b7e8bf12a96a7 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 506a866eae7f722c532bdcd513da6b8134be4091
Author: Jakub Jelinek 
Date:   Tue May 7 22:39:57 2024 +0200

Adjust implementation status of C++26 P2893R3 - Variadic friends.

diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html
index 726b8153..4401c87e 100644
--- a/htdocs/projects/cxx-status.html
+++ b/htdocs/projects/cxx-status.html
@@ -163,7 +163,7 @@
 
Variadic friends 
https://wg21.link/P2893R3;>P2893R3
-   https://gcc.gnu.org/PR114459;>No
+   15
__cpp_variadic_friend >= 202403L 
 
 

---

Summary of changes:
 htdocs/projects/cxx-status.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
gcc-wwwdocs


[gcc r15-304] c++: Implement C++26 P2893R3 - Variadic friends [PR114459]

2024-05-07 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:17458d2bc74b904968e6bdc12527eb040c8d2370

commit r15-304-g17458d2bc74b904968e6bdc12527eb040c8d2370
Author: Jakub Jelinek 
Date:   Tue May 7 22:38:01 2024 +0200

c++: Implement C++26 P2893R3 - Variadic friends [PR114459]

The following patch imeplements the C++26 P2893R3 - Variadic friends
paper.  The paper allows for the friend type declarations to specify
more than one friend type specifier and allows to specify ... at
the end of each.  The patch doesn't introduce tentative parsing of
friend-type-declaration non-terminal, but rather just extends existing
parsing where it is a friend declaration which ends with ; after the
declaration specifiers to the cases where it ends with ...; or , or ...,
In that case it pedwarns for cxx_dialect < cxx26, handles the ... and
if there is , continues in a loop to parse the further friend type
specifiers.

2024-05-07  Jakub Jelinek  

PR c++/114459
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): Predefine
__cpp_variadic_friend=202403L for C++26.
gcc/cp/
* parser.cc (cp_parser_member_declaration): Implement C++26
P2893R3 - Variadic friends.  Parse friend type declarations
with ... or with more than one friend type specifier.
* friend.cc (make_friend_class): Allow TYPE_PACK_EXPANSION.
* pt.cc (instantiate_class_template): Handle PACK_EXPANSION_P
in friend classes.
gcc/testsuite/
* g++.dg/cpp26/feat-cxx26.C (__cpp_variadic_friend): Add test.
* g++.dg/cpp26/variadic-friend1.C: New test.

Diff:
---
 gcc/c-family/c-cppbuiltin.cc  |   1 +
 gcc/cp/friend.cc  |   3 +-
 gcc/cp/parser.cc  | 126 ++
 gcc/cp/pt.cc  |  16 
 gcc/testsuite/g++.dg/cpp26/feat-cxx26.C   |   6 ++
 gcc/testsuite/g++.dg/cpp26/variadic-friend1.C |  58 
 6 files changed, 169 insertions(+), 41 deletions(-)

diff --git a/gcc/c-family/c-cppbuiltin.cc b/gcc/c-family/c-cppbuiltin.cc
index b6f25e4db3c0..d9b84a0f1b97 100644
--- a/gcc/c-family/c-cppbuiltin.cc
+++ b/gcc/c-family/c-cppbuiltin.cc
@@ -1093,6 +1093,7 @@ c_cpp_builtins (cpp_reader *pfile)
  cpp_define (pfile, "__cpp_placeholder_variables=202306L");
  cpp_define (pfile, "__cpp_structured_bindings=202403L");
  cpp_define (pfile, "__cpp_deleted_function=202403L");
+ cpp_define (pfile, "__cpp_variadic_friend=202403L");
}
   if (flag_concepts)
 {
diff --git a/gcc/cp/friend.cc b/gcc/cp/friend.cc
index 758ea87b1721..2e70d0160c46 100644
--- a/gcc/cp/friend.cc
+++ b/gcc/cp/friend.cc
@@ -279,7 +279,8 @@ make_friend_class (tree type, tree friend_type, bool 
complain)
 }
 
   if (! MAYBE_CLASS_TYPE_P (friend_type)
-  && TREE_CODE (friend_type) != TEMPLATE_TEMPLATE_PARM)
+  && TREE_CODE (friend_type) != TEMPLATE_TEMPLATE_PARM
+  && TREE_CODE (friend_type) != TYPE_PACK_EXPANSION)
 {
   /* N1791: If the type specifier in a friend declaration designates a
 (possibly cv-qualified) class type, that class is declared as a
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 775067ed4bc5..c4191200291d 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -28100,8 +28100,17 @@ cp_parser_member_declaration (cp_parser* parser)
   && cp_parser_parse_and_diagnose_invalid_type_name (parser))
 goto out;
   /* If there is no declarator, then the decl-specifier-seq should
- specify a type.  */
-  if (cp_lexer_next_token_is (parser->lexer, CPP_SEMICOLON))
+ specify a type.  For C++26 Variadic friends don't just check for
+ a semicolon, but also for a comma and in both cases optionally
+ preceded by ellipsis.  */
+  if (cp_lexer_next_token_is (parser->lexer, CPP_SEMICOLON)
+  || (cp_parser_friend_p (_specifiers)
+ && cxx_dialect >= cxx11
+ && (cp_lexer_next_token_is (parser->lexer, CPP_COMMA)
+ || (cp_lexer_next_token_is (parser->lexer, CPP_ELLIPSIS)
+ && (cp_lexer_nth_token_is (parser->lexer, 2, CPP_SEMICOLON)
+ || cp_lexer_nth_token_is (parser->lexer, 2,
+   CPP_COMMA))
 {
   /* If there was no decl-specifier-seq, and the next token is a
 `;', then we have something like:
@@ -28136,44 +28145,81 @@ cp_parser_member_declaration (cp_parser* parser)
{
  /* If the `friend' keyword was present, the friend must
 be introduced with a class-key.  */
-  if (!declares_class_or_enum && cxx_dialect < cxx11)
-pedwarn (decl_spec_token_start->location, OPT_Wpedantic,
-

[gcc r14-10181] expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907]

2024-05-07 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:f43f346f19889a15a171a10c6ae1b1fe0a5bc038

commit r14-10181-gf43f346f19889a15a171a10c6ae1b1fe0a5bc038
Author: Jakub Jelinek 
Date:   Tue May 7 21:30:21 2024 +0200

expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907]

The HF and BF modes have the same size/precision and neither is
a subset nor superset of the other.
So, using either __extendhfbf2 or __trunchfbf2 is weird.
The expansion apparently emits __extendhfbf2, but on the libgcc side
we apparently have __trunchfbf2 implemented.

I think it is easier to switch to using what is available rather than
adding new entrypoints to libgcc, even alias, because this is backportable.

2024-05-07  Jakub Jelinek  

PR middle-end/114907
* expr.cc (convert_mode_scalar): Use trunc_optab rather than
sext_optab for HF->BF conversions.
* optabs-libfuncs.cc (gen_trunc_conv_libfunc): Likewise.

* gcc.dg/pr114907.c: New test.

(cherry picked from commit 28ee13db2e9d995bd3728c4ff3a3545e24b39cd2)

Diff:
---
 gcc/expr.cc | 12 ++--
 gcc/optabs-libfuncs.cc  |  4 +++-
 gcc/testsuite/gcc.dg/pr114907.c | 27 +++
 3 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/gcc/expr.cc b/gcc/expr.cc
index d4414e242cb9..9f66d4794459 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -355,8 +355,16 @@ convert_mode_scalar (rtx to, rtx from, int unsignedp)
  && REAL_MODE_FORMAT (from_mode) == _half_format));
 
   if (GET_MODE_PRECISION (from_mode) == GET_MODE_PRECISION (to_mode))
-   /* Conversion between decimal float and binary float, same size.  */
-   tab = DECIMAL_FLOAT_MODE_P (from_mode) ? trunc_optab : sext_optab;
+   {
+ if (REAL_MODE_FORMAT (to_mode) == _bfloat_half_format
+ && REAL_MODE_FORMAT (from_mode) == _half_format)
+   /* libgcc implements just __trunchfbf2, not __extendhfbf2.  */
+   tab = trunc_optab;
+ else
+   /* Conversion between decimal float and binary float, same
+  size.  */
+   tab = DECIMAL_FLOAT_MODE_P (from_mode) ? trunc_optab : sext_optab;
+   }
   else if (GET_MODE_PRECISION (from_mode) < GET_MODE_PRECISION (to_mode))
tab = sext_optab;
   else
diff --git a/gcc/optabs-libfuncs.cc b/gcc/optabs-libfuncs.cc
index 02e9bf6ea5aa..26729910d92b 100644
--- a/gcc/optabs-libfuncs.cc
+++ b/gcc/optabs-libfuncs.cc
@@ -589,7 +589,9 @@ gen_trunc_conv_libfunc (convert_optab tab,
   if (GET_MODE_CLASS (float_tmode) != GET_MODE_CLASS (float_fmode))
 gen_interclass_conv_libfunc (tab, opname, float_tmode, float_fmode);
 
-  if (GET_MODE_PRECISION (float_fmode) <= GET_MODE_PRECISION (float_tmode))
+  if (GET_MODE_PRECISION (float_fmode) <= GET_MODE_PRECISION (float_tmode)
+  && (REAL_MODE_FORMAT (float_tmode) != _bfloat_half_format
+ || REAL_MODE_FORMAT (float_fmode) != _half_format))
 return;
 
   if (GET_MODE_CLASS (float_tmode) == GET_MODE_CLASS (float_fmode))
diff --git a/gcc/testsuite/gcc.dg/pr114907.c b/gcc/testsuite/gcc.dg/pr114907.c
new file mode 100644
index ..628746e1f8c1
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr114907.c
@@ -0,0 +1,27 @@
+/* PR middle-end/114907 */
+/* { dg-do run } */
+/* { dg-options "" } */
+/* { dg-add-options float16 } */
+/* { dg-require-effective-target float16_runtime } */
+/* { dg-add-options bfloat16 } */
+/* { dg-require-effective-target bfloat16_runtime } */
+
+__attribute__((noipa)) _Float16
+foo (__bf16 x)
+{
+  return (_Float16) x;
+}
+
+__attribute__((noipa)) __bf16
+bar (_Float16 x)
+{
+  return (__bf16) x;
+}
+
+int
+main ()
+{
+  if (foo (11.125bf16) != 11.125f16
+  || bar (11.125f16) != 11.125bf16)
+__builtin_abort ();
+}


[gcc r14-10180] tree-inline: Remove .ASAN_MARK calls when inlining functions into no_sanitize callers [PR114956]

2024-05-07 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:aca573ea64ccfd54d4447e9a3200acd7a9157082

commit r14-10180-gaca573ea64ccfd54d4447e9a3200acd7a9157082
Author: Jakub Jelinek 
Date:   Tue May 7 21:29:14 2024 +0200

tree-inline: Remove .ASAN_MARK calls when inlining functions into 
no_sanitize callers [PR114956]

In r9-5742 we've started allowing to inline always_inline functions into
functions which have disabled e.g. address sanitization even when the
always_inline function is implicitly from command line options sanitized.

This mostly works fine because most of the asan instrumentation is done only
late after ipa, but as the following testcase the .ASAN_MARK ifn calls
gimplifier adds can result in ICEs.

Fixed by dropping those during inlining, similarly to how we drop
.TSAN_FUNC_EXIT calls.

2024-05-07  Jakub Jelinek  

PR sanitizer/114956
* tree-inline.cc: Include asan.h.
(copy_bb): Remove also .ASAN_MARK calls if id->dst_fn has 
asan/hwasan
sanitization disabled.

* gcc.dg/asan/pr114956.c: New test.

(cherry picked from commit d4e25cf4f7c1f51a8824cc62bbb85a81a41b829a)

Diff:
---
 gcc/testsuite/gcc.dg/asan/pr114956.c | 26 ++
 gcc/tree-inline.cc   | 28 +---
 2 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/asan/pr114956.c 
b/gcc/testsuite/gcc.dg/asan/pr114956.c
new file mode 100644
index ..fb87d514f255
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/asan/pr114956.c
@@ -0,0 +1,26 @@
+/* PR sanitizer/114956 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fsanitize=address,null" } */
+
+int **a;
+void qux (int *);
+
+__attribute__((always_inline)) static inline int *
+foo (void)
+{
+  int b[1];
+  qux (b);
+  return a[1];
+}
+
+__attribute__((no_sanitize_address)) void
+bar (void)
+{
+  *a = foo ();
+}
+
+void
+baz (void)
+{
+  bar ();
+}
diff --git a/gcc/tree-inline.cc b/gcc/tree-inline.cc
index 238afb7de80e..5f427608d778 100644
--- a/gcc/tree-inline.cc
+++ b/gcc/tree-inline.cc
@@ -65,6 +65,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "symbol-summary.h"
 #include "symtab-thunks.h"
 #include "symtab-clones.h"
+#include "asan.h"
 
 /* I'm not real happy about this, but we need to handle gimple and
non-gimple trees.  */
@@ -2226,13 +2227,26 @@ copy_bb (copy_body_data *id, basic_block bb,
}
  else if (call_stmt
   && id->call_stmt
-  && gimple_call_internal_p (stmt)
-  && gimple_call_internal_fn (stmt) == IFN_TSAN_FUNC_EXIT)
-   {
- /* Drop TSAN_FUNC_EXIT () internal calls during inlining.  */
- gsi_remove (_gsi, false);
- continue;
-   }
+  && gimple_call_internal_p (stmt))
+   switch (gimple_call_internal_fn (stmt))
+ {
+ case IFN_TSAN_FUNC_EXIT:
+   /* Drop .TSAN_FUNC_EXIT () internal calls during inlining.  */
+   gsi_remove (_gsi, false);
+   continue;
+ case IFN_ASAN_MARK:
+   /* Drop .ASAN_MARK internal calls during inlining into
+  no_sanitize functions.  */
+   if (!sanitize_flags_p (SANITIZE_ADDRESS, id->dst_fn)
+   && !sanitize_flags_p (SANITIZE_HWADDRESS, id->dst_fn))
+ {
+   gsi_remove (_gsi, false);
+   continue;
+ }
+   break;
+ default:
+   break;
+ }
 
  /* Statements produced by inlining can be unfolded, especially
 when we constant propagated some operands.  We can't fold


[gcc r15-303] expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907]

2024-05-07 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:28ee13db2e9d995bd3728c4ff3a3545e24b39cd2

commit r15-303-g28ee13db2e9d995bd3728c4ff3a3545e24b39cd2
Author: Jakub Jelinek 
Date:   Tue May 7 21:30:21 2024 +0200

expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907]

The HF and BF modes have the same size/precision and neither is
a subset nor superset of the other.
So, using either __extendhfbf2 or __trunchfbf2 is weird.
The expansion apparently emits __extendhfbf2, but on the libgcc side
we apparently have __trunchfbf2 implemented.

I think it is easier to switch to using what is available rather than
adding new entrypoints to libgcc, even alias, because this is backportable.

2024-05-07  Jakub Jelinek  

PR middle-end/114907
* expr.cc (convert_mode_scalar): Use trunc_optab rather than
sext_optab for HF->BF conversions.
* optabs-libfuncs.cc (gen_trunc_conv_libfunc): Likewise.

* gcc.dg/pr114907.c: New test.

Diff:
---
 gcc/expr.cc | 12 ++--
 gcc/optabs-libfuncs.cc  |  4 +++-
 gcc/testsuite/gcc.dg/pr114907.c | 27 +++
 3 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/gcc/expr.cc b/gcc/expr.cc
index d4414e242cb9..9f66d4794459 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -355,8 +355,16 @@ convert_mode_scalar (rtx to, rtx from, int unsignedp)
  && REAL_MODE_FORMAT (from_mode) == _half_format));
 
   if (GET_MODE_PRECISION (from_mode) == GET_MODE_PRECISION (to_mode))
-   /* Conversion between decimal float and binary float, same size.  */
-   tab = DECIMAL_FLOAT_MODE_P (from_mode) ? trunc_optab : sext_optab;
+   {
+ if (REAL_MODE_FORMAT (to_mode) == _bfloat_half_format
+ && REAL_MODE_FORMAT (from_mode) == _half_format)
+   /* libgcc implements just __trunchfbf2, not __extendhfbf2.  */
+   tab = trunc_optab;
+ else
+   /* Conversion between decimal float and binary float, same
+  size.  */
+   tab = DECIMAL_FLOAT_MODE_P (from_mode) ? trunc_optab : sext_optab;
+   }
   else if (GET_MODE_PRECISION (from_mode) < GET_MODE_PRECISION (to_mode))
tab = sext_optab;
   else
diff --git a/gcc/optabs-libfuncs.cc b/gcc/optabs-libfuncs.cc
index 02e9bf6ea5aa..26729910d92b 100644
--- a/gcc/optabs-libfuncs.cc
+++ b/gcc/optabs-libfuncs.cc
@@ -589,7 +589,9 @@ gen_trunc_conv_libfunc (convert_optab tab,
   if (GET_MODE_CLASS (float_tmode) != GET_MODE_CLASS (float_fmode))
 gen_interclass_conv_libfunc (tab, opname, float_tmode, float_fmode);
 
-  if (GET_MODE_PRECISION (float_fmode) <= GET_MODE_PRECISION (float_tmode))
+  if (GET_MODE_PRECISION (float_fmode) <= GET_MODE_PRECISION (float_tmode)
+  && (REAL_MODE_FORMAT (float_tmode) != _bfloat_half_format
+ || REAL_MODE_FORMAT (float_fmode) != _half_format))
 return;
 
   if (GET_MODE_CLASS (float_tmode) == GET_MODE_CLASS (float_fmode))
diff --git a/gcc/testsuite/gcc.dg/pr114907.c b/gcc/testsuite/gcc.dg/pr114907.c
new file mode 100644
index ..628746e1f8c1
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr114907.c
@@ -0,0 +1,27 @@
+/* PR middle-end/114907 */
+/* { dg-do run } */
+/* { dg-options "" } */
+/* { dg-add-options float16 } */
+/* { dg-require-effective-target float16_runtime } */
+/* { dg-add-options bfloat16 } */
+/* { dg-require-effective-target bfloat16_runtime } */
+
+__attribute__((noipa)) _Float16
+foo (__bf16 x)
+{
+  return (_Float16) x;
+}
+
+__attribute__((noipa)) __bf16
+bar (_Float16 x)
+{
+  return (__bf16) x;
+}
+
+int
+main ()
+{
+  if (foo (11.125bf16) != 11.125f16
+  || bar (11.125f16) != 11.125bf16)
+__builtin_abort ();
+}


[gcc r15-302] tree-inline: Remove .ASAN_MARK calls when inlining functions into no_sanitize callers [PR114956]

2024-05-07 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:d4e25cf4f7c1f51a8824cc62bbb85a81a41b829a

commit r15-302-gd4e25cf4f7c1f51a8824cc62bbb85a81a41b829a
Author: Jakub Jelinek 
Date:   Tue May 7 21:29:14 2024 +0200

tree-inline: Remove .ASAN_MARK calls when inlining functions into 
no_sanitize callers [PR114956]

In r9-5742 we've started allowing to inline always_inline functions into
functions which have disabled e.g. address sanitization even when the
always_inline function is implicitly from command line options sanitized.

This mostly works fine because most of the asan instrumentation is done only
late after ipa, but as the following testcase the .ASAN_MARK ifn calls
gimplifier adds can result in ICEs.

Fixed by dropping those during inlining, similarly to how we drop
.TSAN_FUNC_EXIT calls.

2024-05-07  Jakub Jelinek  

PR sanitizer/114956
* tree-inline.cc: Include asan.h.
(copy_bb): Remove also .ASAN_MARK calls if id->dst_fn has 
asan/hwasan
sanitization disabled.

* gcc.dg/asan/pr114956.c: New test.

Diff:
---
 gcc/testsuite/gcc.dg/asan/pr114956.c | 26 ++
 gcc/tree-inline.cc   | 28 +---
 2 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/asan/pr114956.c 
b/gcc/testsuite/gcc.dg/asan/pr114956.c
new file mode 100644
index ..fb87d514f255
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/asan/pr114956.c
@@ -0,0 +1,26 @@
+/* PR sanitizer/114956 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fsanitize=address,null" } */
+
+int **a;
+void qux (int *);
+
+__attribute__((always_inline)) static inline int *
+foo (void)
+{
+  int b[1];
+  qux (b);
+  return a[1];
+}
+
+__attribute__((no_sanitize_address)) void
+bar (void)
+{
+  *a = foo ();
+}
+
+void
+baz (void)
+{
+  bar ();
+}
diff --git a/gcc/tree-inline.cc b/gcc/tree-inline.cc
index b9fe2099d4f8..f31a34ac4105 100644
--- a/gcc/tree-inline.cc
+++ b/gcc/tree-inline.cc
@@ -65,6 +65,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "symbol-summary.h"
 #include "symtab-thunks.h"
 #include "symtab-clones.h"
+#include "asan.h"
 
 /* I'm not real happy about this, but we need to handle gimple and
non-gimple trees.  */
@@ -2226,13 +2227,26 @@ copy_bb (copy_body_data *id, basic_block bb,
}
  else if (call_stmt
   && id->call_stmt
-  && gimple_call_internal_p (stmt)
-  && gimple_call_internal_fn (stmt) == IFN_TSAN_FUNC_EXIT)
-   {
- /* Drop TSAN_FUNC_EXIT () internal calls during inlining.  */
- gsi_remove (_gsi, false);
- continue;
-   }
+  && gimple_call_internal_p (stmt))
+   switch (gimple_call_internal_fn (stmt))
+ {
+ case IFN_TSAN_FUNC_EXIT:
+   /* Drop .TSAN_FUNC_EXIT () internal calls during inlining.  */
+   gsi_remove (_gsi, false);
+   continue;
+ case IFN_ASAN_MARK:
+   /* Drop .ASAN_MARK internal calls during inlining into
+  no_sanitize functions.  */
+   if (!sanitize_flags_p (SANITIZE_ADDRESS, id->dst_fn)
+   && !sanitize_flags_p (SANITIZE_HWADDRESS, id->dst_fn))
+ {
+   gsi_remove (_gsi, false);
+   continue;
+ }
+   break;
+ default:
+   break;
+ }
 
  /* Statements produced by inlining can be unfolded, especially
 when we constant propagated some operands.  We can't fold


Re: [PATCH] expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907]

2024-05-07 Thread Jakub Jelinek
On Tue, May 07, 2024 at 08:57:00PM +0200, Richard Biener wrote:
> 
> 
> > Am 07.05.2024 um 18:02 schrieb Jakub Jelinek :
> > 
> > Hi!
> > 
> > The HF and BF modes have the same size/precision and neither is
> > a subset nor superset of the other.
> > So, using either __extendhfbf2 or __trunchfbf2 is weird.
> > The expansion apparently emits __extendhfbf2, but on the libgcc side
> > we apparently have __trunchfbf2 implemented.
> > 
> > I think it is easier to switch to using what is available rather than
> > adding new entrypoints to libgcc, even alias, because this is backportable.
> > 
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> Ok - do we have any target patterns that need adjustments?

I don't think so.
BFmode is i386/aarch64/arm/riscv backend only from what I can see,
I've done make mddump for all of them and none of the tmp-mddump.md
files show any matches for hfbf (nor bfhf).

Jakub



[gcc r14-10178] libgomp: Add gfx90c, 1036 and 1103 declare variant tests

2024-05-07 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:23cf0107684336e46fc5525bf22d3f6ee965b463

commit r14-10178-g23cf0107684336e46fc5525bf22d3f6ee965b463
Author: Jakub Jelinek 
Date:   Thu May 2 11:56:16 2024 +0200

libgomp: Add gfx90c, 1036 and 1103 declare variant tests

Recently -march=gfx{90c,1036,1103} support has been added, but corresponding
changes weren't done in the testsuite.

The following patch adds that.

Tested on x86_64-linux (with fiji and gfx1103 devices; had to use
OMP_DEFAULT_DEVICE=1 there, fiji doesn't really work due to LLVM dropping
support, but we still list those as offloading devices).

2024-05-02  Jakub Jelinek  

* testsuite/libgomp.c/declare-variant-4.h (gfx90c, gfx1036, 
gfx1103):
New functions.
(f): Add #pragma omp declare variant directives for those.
* testsuite/libgomp.c/declare-variant-4-gfx90c.c: New test.
* testsuite/libgomp.c/declare-variant-4-gfx1036.c: New test.
* testsuite/libgomp.c/declare-variant-4-gfx1103.c: New test.

(cherry picked from commit 5eb25d1561dd22316331feee92164f97ca79d1c3)

Diff:
---
 .../libgomp.c/declare-variant-4-gfx1036.c  |  8 
 .../libgomp.c/declare-variant-4-gfx1103.c  |  8 
 .../testsuite/libgomp.c/declare-variant-4-gfx90c.c |  8 
 libgomp/testsuite/libgomp.c/declare-variant-4.h| 24 ++
 4 files changed, 48 insertions(+)

diff --git a/libgomp/testsuite/libgomp.c/declare-variant-4-gfx1036.c 
b/libgomp/testsuite/libgomp.c/declare-variant-4-gfx1036.c
new file mode 100644
index ..93b8641b3e15
--- /dev/null
+++ b/libgomp/testsuite/libgomp.c/declare-variant-4-gfx1036.c
@@ -0,0 +1,8 @@
+/* { dg-do link { target { offload_target_amdgcn } } } */
+/* { dg-additional-options -foffload=amdgcn-amdhsa } */
+/* { dg-additional-options -foffload=-march=gfx1036 } */
+/* { dg-additional-options "-foffload=-fdump-tree-optimized" } */
+
+#include "declare-variant-4.h"
+
+/* { dg-final { only_for_offload_target amdgcn-amdhsa scan-offload-tree-dump 
"= gfx1036 \\(\\);" "optimized" } } */
diff --git a/libgomp/testsuite/libgomp.c/declare-variant-4-gfx1103.c 
b/libgomp/testsuite/libgomp.c/declare-variant-4-gfx1103.c
new file mode 100644
index ..6a6dc4fba3fd
--- /dev/null
+++ b/libgomp/testsuite/libgomp.c/declare-variant-4-gfx1103.c
@@ -0,0 +1,8 @@
+/* { dg-do link { target { offload_target_amdgcn } } } */
+/* { dg-additional-options -foffload=amdgcn-amdhsa } */
+/* { dg-additional-options -foffload=-march=gfx1103 } */
+/* { dg-additional-options "-foffload=-fdump-tree-optimized" } */
+
+#include "declare-variant-4.h"
+
+/* { dg-final { only_for_offload_target amdgcn-amdhsa scan-offload-tree-dump 
"= gfx1103 \\(\\);" "optimized" } } */
diff --git a/libgomp/testsuite/libgomp.c/declare-variant-4-gfx90c.c 
b/libgomp/testsuite/libgomp.c/declare-variant-4-gfx90c.c
new file mode 100644
index ..44629a806b46
--- /dev/null
+++ b/libgomp/testsuite/libgomp.c/declare-variant-4-gfx90c.c
@@ -0,0 +1,8 @@
+/* { dg-do link { target { offload_target_amdgcn } } } */
+/* { dg-additional-options -foffload=amdgcn-amdhsa } */
+/* { dg-additional-options -foffload=-march=gfx90c } */
+/* { dg-additional-options "-foffload=-fdump-tree-optimized" } */
+
+#include "declare-variant-4.h"
+
+/* { dg-final { only_for_offload_target amdgcn-amdhsa scan-offload-tree-dump 
"= gfx90c \\(\\);" "optimized" } } */
diff --git a/libgomp/testsuite/libgomp.c/declare-variant-4.h 
b/libgomp/testsuite/libgomp.c/declare-variant-4.h
index d2e9194bf5b6..f244d09c655c 100644
--- a/libgomp/testsuite/libgomp.c/declare-variant-4.h
+++ b/libgomp/testsuite/libgomp.c/declare-variant-4.h
@@ -35,6 +35,13 @@ gfx90a (void)
   return 0x90a;
 }
 
+__attribute__ ((noipa))
+int
+gfx90c (void)
+{
+  return 0x90c;
+}
+
 __attribute__ ((noipa))
 int
 gfx1030 (void)
@@ -42,6 +49,13 @@ gfx1030 (void)
   return 0x1030;
 }
 
+__attribute__ ((noipa))
+int
+gfx1036 (void)
+{
+  return 0x1036;
+}
+
 __attribute__ ((noipa))
 int
 gfx1100 (void)
@@ -49,6 +63,13 @@ gfx1100 (void)
   return 0x1100;
 }
 
+__attribute__ ((noipa))
+int
+gfx1103 (void)
+{
+  return 0x1103;
+}
+
 #ifdef USE_FIJI_FOR_GFX803
 #pragma omp declare variant(gfx803) match(device = {isa("fiji")})
 #else
@@ -58,8 +79,11 @@ gfx1100 (void)
 #pragma omp declare variant(gfx906) match(device = {isa("gfx906")})
 #pragma omp declare variant(gfx908) match(device = {isa("gfx908")})
 #pragma omp declare variant(gfx90a) match(device = {isa("gfx90a")})
+#pragma omp declare variant(gfx90c) match(device = {isa("gfx90c")})
 #pragma omp declare variant(gfx1030) match(device = {isa("gfx1030")})
+#pragma omp declare variant(gfx1036) match(device = {isa("gfx1036")})
 #pragma omp declare variant(gfx1100) match(device = {isa("gfx1100")})
+#pragma omp declare variant(gfx1103) match(device = {isa("gfx1103")})
 __attribute__ ((noipa))
 int
 f (void)


[gcc r14-10177] gimple-ssa-sprintf: Use [0, 1] range for %lc with (wint_t) 0 argument [PR114876]

2024-05-07 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:a1c8ae15d9df0caa839b47c8631571a1ec27e367

commit r14-10177-ga1c8ae15d9df0caa839b47c8631571a1ec27e367
Author: Jakub Jelinek 
Date:   Tue Apr 30 11:22:32 2024 +0200

gimple-ssa-sprintf: Use [0, 1] range for %lc with (wint_t) 0 argument 
[PR114876]

Seems when Martin S. implemented this, he coded there strict reading
of the standard, which said that %lc with (wint_t) 0 argument is handled
as wchar_t[2] temp = { arg, 0 }; %ls with temp arg and so shouldn't print
any values.  But, most of the libc implementations actually handled that
case like %c with '\0' argument, adding a single NUL character, the only
known exception is musl.
Recently, C23 changed this in response to GB-141 and POSIX in
https://austingroupbugs.net/view.php?id=1647
so that it should have the same behavior as %c with '\0'.

Because there is implementation divergence, the following patch uses
a range rather than hardcoding it to all 1s (i.e. the %c behavior),
though the likely case is still 1 (forward looking plus most of
implementations).
The res.knownrange = true; assignment removed is redundant due to
the same assignment done unconditionally before the if statement,
rest is formatting fixes.

I don't think the min >= 0 && min < 128 case is right either, I'd think
it should be min >= 0 && max < 128, otherwise it is just some possible
inputs are (maybe) ASCII and there can be others, but this code is a total
mess anyway, with the min, max, likely (somewhere in [min, max]?) and then
unlikely possibly larger than max, dunno, perhaps for at least some chars
in the ASCII range the likely case could be for the ascii case; so perhaps
just the one_2_one_ascii shouldn't set max to 1 and mayfail should be true
for max >= 128.  Anyway, didn't feel I should touch that right now.
    
2024-04-30  Jakub Jelinek  

PR tree-optimization/114876
* gimple-ssa-sprintf.cc (format_character): For min == 0 && max == 
0,
set max, likely and unlikely members to 1 rather than 0.  Remove
useless res.knownrange = true;.  Formatting fixes.

* gcc.dg/pr114876.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust expected
diagnostics.

(cherry picked from commit 6c6b70f07208ca14ba783933988c04c6fc2fff42)

Diff:
---
 gcc/gimple-ssa-sprintf.cc  | 20 +++--
 gcc/testsuite/gcc.dg/pr114876.c| 34 ++
 .../gcc.dg/tree-ssa/builtin-sprintf-warn-1.c   | 12 
 3 files changed, 51 insertions(+), 15 deletions(-)

diff --git a/gcc/gimple-ssa-sprintf.cc b/gcc/gimple-ssa-sprintf.cc
index abb934b08d5a..3b19f4d3f357 100644
--- a/gcc/gimple-ssa-sprintf.cc
+++ b/gcc/gimple-ssa-sprintf.cc
@@ -2177,8 +2177,7 @@ format_character (const directive , tree arg, 
pointer_query _qry)
 
   res.knownrange = true;
 
-  if (dir.specifier == 'C'
-  || dir.modifier == FMT_LEN_l)
+  if (dir.specifier == 'C' || dir.modifier == FMT_LEN_l)
 {
   /* A wide character can result in as few as zero bytes.  */
   res.range.min = 0;
@@ -2189,10 +2188,13 @@ format_character (const directive , tree arg, 
pointer_query _qry)
{
  if (min == 0 && max == 0)
{
- /* The NUL wide character results in no bytes.  */
- res.range.max = 0;
- res.range.likely = 0;
- res.range.unlikely = 0;
+ /* In strict reading of older ISO C or POSIX, this required
+no characters to be emitted.  ISO C23 changes that, so
+does POSIX, to match what has been implemented in most of the
+implementations, namely emitting a single NUL character.
+Let's use 0 for minimum and 1 for all the other values.  */
+ res.range.max = 1;
+ res.range.likely = res.range.unlikely = 1;
}
  else if (min >= 0 && min < 128)
{
@@ -2200,11 +2202,12 @@ format_character (const directive , tree arg, 
pointer_query _qry)
 is not a 1-to-1 mapping to the source character set or
 if the source set is not ASCII.  */
  bool one_2_one_ascii
-   = (target_to_host_charmap[0] == 1 && target_to_host ('a') == 
97);
+   = (target_to_host_charmap[0] == 1
+  && target_to_host ('a') == 97);
 
  /* A wide character in the ASCII range most likely results
 in a single byte, and only unlikely in up to MB_LEN_MAX.  */
- res.range.max = one_2_one_ascii ? 1 : target_mb_len_max ();;
+ res.range.max = one_2_one_ascii ? 1 : target_mb_len_max ();
  res.range.likely = 1;
  res.range.unlikely = target_mb_len_max ();
   

[PATCH] expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907]

2024-05-07 Thread Jakub Jelinek
Hi!

The HF and BF modes have the same size/precision and neither is
a subset nor superset of the other.
So, using either __extendhfbf2 or __trunchfbf2 is weird.
The expansion apparently emits __extendhfbf2, but on the libgcc side
we apparently have __trunchfbf2 implemented.

I think it is easier to switch to using what is available rather than
adding new entrypoints to libgcc, even alias, because this is backportable.

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

2024-05-07  Jakub Jelinek  

PR middle-end/114907
* expr.cc (convert_mode_scalar): Use trunc_optab rather than
sext_optab for HF->BF conversions.
* optabs-libfuncs.cc (gen_trunc_conv_libfunc): Likewise.

* gcc.dg/pr114907.c: New test.

--- gcc/expr.cc.jj  2024-04-09 09:29:04.0 +0200
+++ gcc/expr.cc 2024-05-06 13:21:33.933798494 +0200
@@ -355,8 +355,16 @@ convert_mode_scalar (rtx to, rtx from, i
  && REAL_MODE_FORMAT (from_mode) == _half_format));
 
   if (GET_MODE_PRECISION (from_mode) == GET_MODE_PRECISION (to_mode))
-   /* Conversion between decimal float and binary float, same size.  */
-   tab = DECIMAL_FLOAT_MODE_P (from_mode) ? trunc_optab : sext_optab;
+   {
+ if (REAL_MODE_FORMAT (to_mode) == _bfloat_half_format
+ && REAL_MODE_FORMAT (from_mode) == _half_format)
+   /* libgcc implements just __trunchfbf2, not __extendhfbf2.  */
+   tab = trunc_optab;
+ else
+   /* Conversion between decimal float and binary float, same
+  size.  */
+   tab = DECIMAL_FLOAT_MODE_P (from_mode) ? trunc_optab : sext_optab;
+   }
   else if (GET_MODE_PRECISION (from_mode) < GET_MODE_PRECISION (to_mode))
tab = sext_optab;
   else
--- gcc/optabs-libfuncs.cc.jj   2024-01-03 11:51:31.739728303 +0100
+++ gcc/optabs-libfuncs.cc  2024-05-06 15:50:21.611027802 +0200
@@ -589,7 +589,9 @@ gen_trunc_conv_libfunc (convert_optab ta
   if (GET_MODE_CLASS (float_tmode) != GET_MODE_CLASS (float_fmode))
 gen_interclass_conv_libfunc (tab, opname, float_tmode, float_fmode);
 
-  if (GET_MODE_PRECISION (float_fmode) <= GET_MODE_PRECISION (float_tmode))
+  if (GET_MODE_PRECISION (float_fmode) <= GET_MODE_PRECISION (float_tmode)
+  && (REAL_MODE_FORMAT (float_tmode) != _bfloat_half_format
+ || REAL_MODE_FORMAT (float_fmode) != _half_format))
 return;
 
   if (GET_MODE_CLASS (float_tmode) == GET_MODE_CLASS (float_fmode))
--- gcc/testsuite/gcc.dg/pr114907.c.jj  2024-05-06 15:59:08.734958523 +0200
+++ gcc/testsuite/gcc.dg/pr114907.c 2024-05-06 16:02:38.914139829 +0200
@@ -0,0 +1,27 @@
+/* PR middle-end/114907 */
+/* { dg-do run } */
+/* { dg-options "" } */
+/* { dg-add-options float16 } */
+/* { dg-require-effective-target float16_runtime } */
+/* { dg-add-options bfloat16 } */
+/* { dg-require-effective-target bfloat16_runtime } */
+
+__attribute__((noipa)) _Float16
+foo (__bf16 x)
+{
+  return (_Float16) x;
+}
+
+__attribute__((noipa)) __bf16
+bar (_Float16 x)
+{
+  return (__bf16) x;
+}
+
+int
+main ()
+{
+  if (foo (11.125bf16) != 11.125f16
+  || bar (11.125f16) != 11.125bf16)
+__builtin_abort ();
+}

Jakub



[PATCH] tree-inline: Remove .ASAN_MARK calls when inlining functions into no_sanitize callers [PR114956]

2024-05-07 Thread Jakub Jelinek
Hi!

In r9-5742 we've started allowing to inline always_inline functions into
functions which have disabled e.g. address sanitization even when the
always_inline function is implicitly from command line options sanitized.

This mostly works fine because most of the asan instrumentation is done only
late after ipa, but as the following testcase the .ASAN_MARK ifn calls
gimplifier adds can result in ICEs.

Fixed by dropping those during inlining, similarly to how we drop
.TSAN_FUNC_EXIT calls.

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

2024-05-07  Jakub Jelinek  

PR sanitizer/114956
* tree-inline.cc: Include asan.h.
(copy_bb): Remove also .ASAN_MARK calls if id->dst_fn has asan/hwasan
sanitization disabled.

* gcc.dg/asan/pr114956.c: New test.

--- gcc/tree-inline.cc.jj   2024-05-03 09:44:21.199055899 +0200
+++ gcc/tree-inline.cc  2024-05-06 10:45:37.231349328 +0200
@@ -65,6 +65,7 @@ along with GCC; see the file COPYING3.
 #include "symbol-summary.h"
 #include "symtab-thunks.h"
 #include "symtab-clones.h"
+#include "asan.h"
 
 /* I'm not real happy about this, but we need to handle gimple and
non-gimple trees.  */
@@ -2226,13 +2227,26 @@ copy_bb (copy_body_data *id, basic_block
}
  else if (call_stmt
   && id->call_stmt
-  && gimple_call_internal_p (stmt)
-  && gimple_call_internal_fn (stmt) == IFN_TSAN_FUNC_EXIT)
-   {
- /* Drop TSAN_FUNC_EXIT () internal calls during inlining.  */
- gsi_remove (_gsi, false);
- continue;
-   }
+  && gimple_call_internal_p (stmt))
+   switch (gimple_call_internal_fn (stmt))
+ {
+ case IFN_TSAN_FUNC_EXIT:
+   /* Drop .TSAN_FUNC_EXIT () internal calls during inlining.  */
+   gsi_remove (_gsi, false);
+   continue;
+ case IFN_ASAN_MARK:
+   /* Drop .ASAN_MARK internal calls during inlining into
+  no_sanitize functions.  */
+   if (!sanitize_flags_p (SANITIZE_ADDRESS, id->dst_fn)
+   && !sanitize_flags_p (SANITIZE_HWADDRESS, id->dst_fn))
+ {
+   gsi_remove (_gsi, false);
+   continue;
+ }
+   break;
+ default:
+   break;
+ }
 
  /* Statements produced by inlining can be unfolded, especially
 when we constant propagated some operands.  We can't fold
--- gcc/testsuite/gcc.dg/asan/pr114956.c.jj 2024-05-06 10:54:52.601892840 
+0200
+++ gcc/testsuite/gcc.dg/asan/pr114956.c2024-05-06 10:54:33.920143734 
+0200
@@ -0,0 +1,26 @@
+/* PR sanitizer/114956 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fsanitize=address,null" } */
+
+int **a;
+void qux (int *);
+
+__attribute__((always_inline)) static inline int *
+foo (void)
+{
+  int b[1];
+  qux (b);
+  return a[1];
+}
+
+__attribute__((no_sanitize_address)) void
+bar (void)
+{
+  *a = foo ();
+}
+
+void
+baz (void)
+{
+  bar ();
+}

Jakub



Re: [wwwdocs] Specify AArch64 BitInt support for little-endian only

2024-05-07 Thread Jakub Jelinek
On Tue, May 07, 2024 at 02:12:07PM +0100, Andre Vieira (lists) wrote:
> Hey Jakub,
> 
> This what ya had in mind?

Yes.

> diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> index 
> ca5174de991bb088f653468f77485c15a61526e6..924e045a15a78b5702a0d6997953f35c6b47efd1
>  100644
> --- a/htdocs/gcc-14/changes.html
> +++ b/htdocs/gcc-14/changes.html
> @@ -325,7 +325,7 @@ You may also want to check out our
>Bit-precise integer types (_BitInt (N)
>and unsigned _BitInt (N)): integer types with
>a specified number of bits.  These are only supported on
> -  IA-32, x86-64 and AArch64 at present.
> +  IA-32, x86-64 and AArch64 (little-endian) at present.
>Structure, union and enumeration types may be defined more
>than once in the same scope with the same contents and the same
>tag; if such types are defined with the same contents and the


Jakub



gcc-wwwdocs branch master updated. 1aef08f66802bbddaf9a048a1840e26597e4f62e

2024-05-07 Thread Jakub Jelinek via Gcc-cvs-wwwdocs
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gcc-wwwdocs".

The branch, master has been updated
   via  1aef08f66802bbddaf9a048a1840e26597e4f62e (commit)
  from  388e5d2bb70921d8c73c82df19b4a94de19ae936 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 1aef08f66802bbddaf9a048a1840e26597e4f62e
Author: Jakub Jelinek 
Date:   Tue May 7 09:32:14 2024 +

13.1 -> 14.1

diff --git a/htdocs/onlinedocs/14.1.0/index.html 
b/htdocs/onlinedocs/14.1.0/index.html
index 2abc06ac..b9cb9c23 100644
--- a/htdocs/onlinedocs/14.1.0/index.html
+++ b/htdocs/onlinedocs/14.1.0/index.html
@@ -3,106 +3,106 @@
 
 
 
-GCC 13.1 manuals
+GCC 14.1 manuals
 https://gcc.gnu.org/gcc.css;>
 
 
 
 
-13.1 manuals
+14.1 manuals
   
-https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/;>GCC
- 13.1 Manual (https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc.pdf;>also
+https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/;>GCC
+ 14.1 Manual (https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc.pdf;>also
  in PDF or https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc.ps.gz;>PostScript or https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc-html.tar.gz;>an
+ 
href="https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc.ps.gz;>PostScript or https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc-html.tar.gz;>an
  HTML tarball)
-https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gfortran/;>GCC
- 13.1 GNU Fortran Manual (https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gfortran.pdf;>also
+https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gfortran/;>GCC
+ 14.1 GNU Fortran Manual (https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gfortran.pdf;>also
  in PDF or https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gfortran.ps.gz;>PostScript 
or https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gfortran-html.tar.gz;>an
+ 
href="https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gfortran.ps.gz;>PostScript 
or https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gfortran-html.tar.gz;>an
  HTML tarball)
-https://gcc.gnu.org/onlinedocs/gcc-13.1.0/cpp/;>GCC 
- 13.1 CPP Manual (https://gcc.gnu.org/onlinedocs/gcc-13.1.0/cpp.pdf;>also
+https://gcc.gnu.org/onlinedocs/gcc-14.1.0/cpp/;>GCC 
+ 14.1 CPP Manual (https://gcc.gnu.org/onlinedocs/gcc-14.1.0/cpp.pdf;>also
  in PDF or https://gcc.gnu.org/onlinedocs/gcc-13.1.0/cpp.ps.gz;>PostScript or https://gcc.gnu.org/onlinedocs/gcc-13.1.0/cpp-html.tar.gz;>an
+ 
href="https://gcc.gnu.org/onlinedocs/gcc-14.1.0/cpp.ps.gz;>PostScript or https://gcc.gnu.org/onlinedocs/gcc-14.1.0/cpp-html.tar.gz;>an
  HTML tarball)
-https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gnat_rm/;>GCC
- 13.1 GNAT Reference Manual (https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gnat_rm.pdf;>also
+https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gnat_rm/;>GCC
+ 14.1 GNAT Reference Manual (https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gnat_rm.pdf;>also
  in PDF or https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gnat_rm.ps.gz;>PostScript 
or https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gnat_rm-html.tar.gz;>an
+ 
href="https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gnat_rm.ps.gz;>PostScript 
or https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gnat_rm-html.tar.gz;>an
  HTML tarball)
-https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gnat_ugn/;>GCC
- 13.1 GNAT User's Guide (https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gnat_ugn.pdf;>also
+https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gnat_ugn/;>GCC
+ 14.1 GNAT User's Guide (https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gnat_ugn.pdf;>also
  in PDF or https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gnat_ugn.ps.gz;>PostScript 
or https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gnat_ugn-html.tar.gz;>an
+ 
href="https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gnat_ugn.ps.gz;>PostScript 
or https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gnat_ugn-html.tar.gz;>an
  HTML tarball)
-https://gcc.gnu.org/onlinedocs/gcc-13.1.0/libstdc++/manual/;>GCC
- 13.1 Standard C++ Library Manual  (https://gcc.gnu.org/onlinedocs/gcc-13.1.0/libstdc++-manual.pdf.gz;>also
+https://gcc.gnu.org/onlinedocs/gcc-14.1.0/libstdc++/manual/;>GCC
+ 14.1 Standard C++ Library Manual  (https://gcc.gnu.org/onlinedocs/gcc-14.1.0/libstdc++-manual.pdf.gz;>also
  in PDF or https://gcc.gnu.org/onlinedocs/gcc-13.1.0/libstdc++-manual.xml.gz;>XML
 or https://gcc.gnu.org/onlinedocs/gcc-13.1.0/libstdc++-manual-html.tar.gz;>an
+ 
href="https://gcc.gnu.org/onlinedocs/gcc-14.1.0/libstdc++-manu

[gcc r14-10172] Update gennews for GCC 14.

2024-05-07 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:4f12e06d2d112823298ffcad9732785bb86cb022

commit r14-10172-g4f12e06d2d112823298ffcad9732785bb86cb022
Author: Jakub Jelinek 
Date:   Tue May 7 08:48:19 2024 +0200

Update gennews for GCC 14.

2024-05-07  Jakub Jelinek  

* gennews (files): Add files for GCC 14.

(cherry picked from commit 7ee3f769529f8d418bf361eb821aab17a33567e3)

Diff:
---
 contrib/gennews | 1 +
 1 file changed, 1 insertion(+)

diff --git a/contrib/gennews b/contrib/gennews
index 6b8bb40a58a..483907b0e19 100755
--- a/contrib/gennews
+++ b/contrib/gennews
@@ -23,6 +23,7 @@
 
 website=http://gcc.gnu.org/
 files="
+gcc-14/index.html gcc-14/changes.html
 gcc-13/index.html gcc-13/changes.html
 gcc-12/index.html gcc-12/changes.html
 gcc-11/index.html gcc-11/changes.html


[gcc r15-224] Update gennews for GCC 14.

2024-05-07 Thread Jakub Jelinek via Gcc-cvs
https://gcc.gnu.org/g:7ee3f769529f8d418bf361eb821aab17a33567e3

commit r15-224-g7ee3f769529f8d418bf361eb821aab17a33567e3
Author: Jakub Jelinek 
Date:   Tue May 7 08:48:19 2024 +0200

Update gennews for GCC 14.

2024-05-07  Jakub Jelinek  

* gennews (files): Add files for GCC 14.

Diff:
---
 contrib/gennews | 1 +
 1 file changed, 1 insertion(+)

diff --git a/contrib/gennews b/contrib/gennews
index 6b8bb40a58a..483907b0e19 100755
--- a/contrib/gennews
+++ b/contrib/gennews
@@ -23,6 +23,7 @@
 
 website=http://gcc.gnu.org/
 files="
+gcc-14/index.html gcc-14/changes.html
 gcc-13/index.html gcc-13/changes.html
 gcc-12/index.html gcc-12/changes.html
 gcc-11/index.html gcc-11/changes.html


gcc-wwwdocs branch master updated. e8188a572301966aab9fc19200d97773af308aa6

2024-05-07 Thread Jakub Jelinek via Gcc-cvs-wwwdocs
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gcc-wwwdocs".

The branch, master has been updated
   via  e8188a572301966aab9fc19200d97773af308aa6 (commit)
  from  323fd0012e1f45e6a4b40e227df5a07ea5f5ea05 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit e8188a572301966aab9fc19200d97773af308aa6
Author: Jakub Jelinek 
Date:   Tue May 7 08:39:24 2024 +0200

Small tweak.

diff --git a/htdocs/gcc-14/index.html b/htdocs/gcc-14/index.html
index 5274cc39..ff3f433f 100644
--- a/htdocs/gcc-14/index.html
+++ b/htdocs/gcc-14/index.html
@@ -16,7 +16,7 @@
 The GCC developers are pleased to announce the release of GCC 14.1.
 
 This release is a major release, containing new features (as well
-as many other improvements) relative to GCC 12.x.
+as many other improvements) relative to GCC 13.x.
 
 Release History
 

---

Summary of changes:
 htdocs/gcc-14/index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
gcc-wwwdocs


gcc-wwwdocs branch master updated. 323fd0012e1f45e6a4b40e227df5a07ea5f5ea05

2024-05-07 Thread Jakub Jelinek via Gcc-cvs-wwwdocs
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gcc-wwwdocs".

The branch, master has been updated
   via  323fd0012e1f45e6a4b40e227df5a07ea5f5ea05 (commit)
  from  8095e54fa7c659dc5b00ddc4ff4e48a30dfaa1f2 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 323fd0012e1f45e6a4b40e227df5a07ea5f5ea05
Author: Jakub Jelinek 
Date:   Tue May 7 08:38:19 2024 +0200

Releasing 14.1.

diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 28e5da9f..cb75867f 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -22,9 +22,6 @@ You may also want to check out our
 full GCC documentation.
 
 
-Note: GCC 14 has not been released yet, so this document is
-a work-in-progress.
-
 
 Caveats
 
@@ -1575,7 +1572,15 @@ it emits:
 
 
 
-
+GCC 14.1
+
+This is the https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVEDresolution=FIXEDtarget_milestone=14.0;>list
+of problem reports (PRs) from GCC's bug tracking system that are
+known to be fixed in the 14.1 release. This list might not be
+complete (that is, it is possible that some PRs that have been fixed
+are not listed here).
+
+
 
 
 
diff --git a/htdocs/gcc-14/index.html b/htdocs/gcc-14/index.html
index c8a9cb34..5274cc39 100644
--- a/htdocs/gcc-14/index.html
+++ b/htdocs/gcc-14/index.html
@@ -11,7 +11,24 @@
 
 GCC 14 Release Series
 
-As of this time no releases of GCC 14 have yet been made.
+May 7, 2024
+
+The GCC developers are pleased to announce the release of GCC 14.1.
+
+This release is a major release, containing new features (as well
+as many other improvements) relative to GCC 12.x.
+
+Release History
+
+
+
+GCC 14.1
+May 7, 2024
+(changes,
+ http://gcc.gnu.org/onlinedocs/14.1.0/;>documentation)
+
+
+
 
 References and Acknowledgements
 

---

Summary of changes:
 htdocs/gcc-14/changes.html | 13 +
 htdocs/gcc-14/index.html   | 19 ++-
 2 files changed, 27 insertions(+), 5 deletions(-)


hooks/post-receive
-- 
gcc-wwwdocs


gcc-wwwdocs branch master updated. 8095e54fa7c659dc5b00ddc4ff4e48a30dfaa1f2

2024-05-07 Thread Jakub Jelinek via Gcc-cvs-wwwdocs
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gcc-wwwdocs".

The branch, master has been updated
   via  8095e54fa7c659dc5b00ddc4ff4e48a30dfaa1f2 (commit)
  from  b018ddd6e4b85c37ea3129b567c1f67717a40132 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 8095e54fa7c659dc5b00ddc4ff4e48a30dfaa1f2
Author: Jakub Jelinek 
Date:   Tue May 7 08:32:45 2024 +0200

Adjust onlinedocs references to 14.1.0.

diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 82906de1..28e5da9f 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -32,12 +32,12 @@ a work-in-progress.
   Support for the GCC extension, a structure containing a C99 flexible 
array
   member, or a union containing such a structure, is not the last field of
   another structure, is deprecated. Refer to
-  https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html;>
+  https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Zero-Length.html;>
   Zero Length Arrays.
   Any code relying on this extension should be modifed to ensure that
   C99 flexible array members only end up at the ends of structures.
   Please use the warning option
-  https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wflex-array-member-not-at-end;>-Wflex-array-member-not-at-end
 to
+  https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Warning-Options.html#index-Wflex-array-member-not-at-end;>-Wflex-array-member-not-at-end
 to
   identify all such cases in the source code and modify them.
   
   C:
@@ -45,7 +45,7 @@ a work-in-progress.
   Porting to GCC 14
   for details.
   
-  https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html;>-fcf-protection=[full|branch|return|none|check]
+  https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Instrumentation-Options.html;>-fcf-protection=[full|branch|return|none|check]
   is refactored, to override -fcf-protection,
   -fcf-protection=none needs to be added and then
   with -fcf-protection=xxx.
@@ -58,7 +58,7 @@ a work-in-progress.
   declared obsolete in GCC 14, and the sources will also be removed
   in the next release of GCC.
   
-  https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html;>-fanalyzer
+  https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Static-Analyzer-Options.html;>-fanalyzer
 is still only suitable for analyzing C code.
 In particular, using it on C++ is unlikely to give meaningful output.
   
@@ -74,7 +74,7 @@ a work-in-progress.
   when the user or compiler links them on the host side. Thus, it is no
   longer required to explicitly pass -lm and/or
   -lgfortran to the offload-device linker using the https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-foffload-options;
+  
href="https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/C-Dialect-Options.html#index-foffload-options;
   >-foffload-options= flag.
   
   
@@ -85,14 +85,14 @@ a work-in-progress.
   
   
 New option
-https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fhardened;>-fhardened,
+https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Instrumentation-Options.html#index-fhardened;>-fhardened,
 an umbrella option that enables a set of hardening flags.
 The options it enables can be displayed using the
 --help=hardened option.
   
   
 New option
-https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fharden-control-flow-redundancy;>-fharden-control-flow-redundancy,
+https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Instrumentation-Options.html#index-fharden-control-flow-redundancy;>-fharden-control-flow-redundancy,
 to verify, at the end of functions, that the visited basic blocks
 correspond to a legitimate execution path, so as to detect and
 prevent attacks that transfer control into the middle of
@@ -100,7 +100,7 @@ a work-in-progress.
   
   
 New type attribute
-https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#index-hardbool-type-attribute;>hardbool,
+https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Common-Type-Attributes.html#index-hardbool-type-attribute;>hardbool,
 for C and Ada.  Hardened
 booleans take user-specified representations for true
 and false, presumably with higher hamming distance
@@ -109,7 +109,7 @@ a work-in-progress.
   
   
 New type attribute
-https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#index-strub-type-attribute;>strub
+https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Common-Type-Attributes.html#index-strub-type-attribute;>strub
 to control stack scrubbing
 properties o

Second GCC 14.1 Release Candidate available from gcc.gnu.org

2024-05-03 Thread Jakub Jelinek via Gcc
The second release candidate for GCC 14.1 is available from

 https://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240503/
 ftp://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240503/

and shortly its mirrors.  It has been generated from git commit
r14-10165-g3b4d6b6ecd79df790.

The https://gcc.gnu.org/PR114935 bug has been reported and determined
a release blocker, so we'd like to get extra testing on it prior to
the release.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.  Please test it and report any issues to bugzilla.

If all goes well, we'd still like to release 14.1 on Tuesday, May 7th.



Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types

2024-05-03 Thread Jakub Jelinek
On Fri, May 03, 2024 at 09:11:20PM +0200, Martin Uecker wrote:
> > TYPE_CANONICAL as used by the middle-end cannot express this but
> 
> Hm. so how does it work now for arrays?

Do you have a testcase which doesn't work correctly with the arrays?

E.g. same_type_for_tbaa has
  type1 = TYPE_MAIN_VARIANT (type1);
  type2 = TYPE_MAIN_VARIANT (type2);

  /* Handle the most common case first.  */
  if (type1 == type2)
return 1;

  /* If we would have to do structural comparison bail out.  */
  if (TYPE_STRUCTURAL_EQUALITY_P (type1)
  || TYPE_STRUCTURAL_EQUALITY_P (type2))
return -1;

  /* Compare the canonical types.  */
  if (TYPE_CANONICAL (type1) == TYPE_CANONICAL (type2))
return 1;

  /* ??? Array types are not properly unified in all cases as we have
 spurious changes in the index types for example.  Removing this
 causes all sorts of problems with the Fortran frontend.  */
  if (TREE_CODE (type1) == ARRAY_TYPE
  && TREE_CODE (type2) == ARRAY_TYPE)
return -1;
...
and later compares alias sets and the like.
So, even if int[] and int[0] have different TYPE_CANONICAL, they
will be considered maybe the same.  Also, guess get_alias_set
has some ARRAY_TYPE handling...

Anyway, I think we should just go with Richi's patch.

Jakub



Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types

2024-05-03 Thread Jakub Jelinek
On Fri, May 03, 2024 at 08:04:18PM +0200, Martin Uecker wrote:
> A change that is not optimal but would avoid a lot of trouble is to
> only use the tag of the struct for computing a TYPE_CANONICAL, which
> could then be set already for incomplete types and never needs to
> change again. We would not differentiate between different struct
> types with the same tag for aliasing analysis, but in most cases
> I would expect different structs to have a different tag.

Having incompatible types have the same TYPE_CANONICAL would lead to wrong
code IMHO, while for aliasing purposes that might be conservative (though
not sure, the alias set computation is based on what types the element have
etc., so if the alias set is computed for say struct S { int s; }; and
then the same alias set used for struct S { long long a; double b; union {
short c; float d; } c; };, I think nothing good will come out of that),
but middle-end also uses TYPE_CANONICAL to see if types are the same,
say e.g. useless_type_conversion_p says that conversions from one
RECORD_TYPE to a different RECORD_TYPE are useless if they have the
same TYPE_CANONICAL.
  /* For aggregates we rely on TYPE_CANONICAL exclusively and require
 explicit conversions for types involving to be structurally
 compared types.  */
  else if (AGGREGATE_TYPE_P (inner_type)
   && TREE_CODE (inner_type) == TREE_CODE (outer_type))
return TYPE_CANONICAL (inner_type)
   && TYPE_CANONICAL (inner_type) == TYPE_CANONICAL (outer_type);
So, if you have struct S { int s; } and struct S { short a, b; }; and
VIEW_CONVERT_EXPR between them, that VIEW_CONVERT_EXPR will be removed
as useless, etc.

BTW, the idea of lazily updating TYPE_CANONICAL is basically what I've
described as the option to update all the derived types where it would
pretty much do that for all TYPE_STRUCTURAL_EQUALITY_P types in the
hash table (see if they are derived from the type in question and recompute
the TYPE_CANONICAL after recomputing all the TYPE_CANONICAL of its base
types), except perhaps even more costly (if the trigger would be some
build_array_type/build_function_type/... function is called and found
a cached TYPE_STRUCTURAL_EQUALITY_P type).  Note also that
TYPE_STRUCTURAL_EQUALITY_P isn't the case just for the C23 types which
are marked that way when incomplete and later completed, but by various
other cases for types which will be permanently like that, so doing
expensive checks each time some build*_type* is called that refers
to those would be expensive.

Jakub



Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types

2024-05-03 Thread Jakub Jelinek
On Fri, May 03, 2024 at 05:32:12PM +0200, Martin Uecker wrote:
> Am Freitag, dem 03.05.2024 um 14:13 +0200 schrieb Richard Biener:
> > TYPE_STRUCTURAL_EQUALITY_P is part of our type system so we have
> > to make sure to include that into the type unification done via
> > type_hash_canon.  This requires the flag to be set before querying
> > the hash which is the biggest part of the patch.
> 
> I assume this does not affect structs / unions because they
> do not make this mechanism of type unification (each tagged type
> is a unique type), but only derived types that end up having
> TYPE_STRUCTURAL_EQUALITY_P because they are constructed from
> incomplete structs / unions before TYPE_CANONICAL is set.
> 
> I do not yet understand why this change is needed. Type
> identity should not be affected by setting TYPE_CANONICAL, so
> why do we need to keep such types separate?  I understand that we
> created some inconsistencies, but I do not see why this change
> is needed to fix it.  But I also haven't understood how we ended
> up with a TYPE_CANONICAL having TYPE_STRUCTURAL_EQUALITY_P in
> PR 114931 ...

So, the C23 situation before the r14-10045 change (not counting the
r14-9763 change that was later reverted) was that sometimes TYPE_CANONICAL
of a RECORD_TYPE/UNION_TYPE could change from self to a different
RECORD_TYPE/UNION_TYPE and we didn't bother to adjust derived types.
That was really dangerous, I think e.g. type alias set wasn't recomputed.

r14-10045 changed it to the non-ideal, but perhaps less wrong model,
where we start with TYPE_STRUCTURAL_EQUALITY_P on incomplete types in C23
and perhaps later on change them to !TYPE_STRUCTURAL_EQUALITY_P when
the type is completed, and adjust TYPE_CANONICAL of some easily discoverable
derived types but certainly not all.

Still, that change introduces something novel to the type system, namely
that TYPE_CANONICAL can change on a type, even when it is just limited to
the TYPE_STRUCTURAL_EQUALITY_P -> !TYPE_STRUCTURAL_EQUALITY_P kind of
change and we never change one non-NULL TYPE_CANONICAL to a different one
(ok, not counting the short lived TYPE_CANONICAL being initially set to
self during make_node and then quickly adjusted in the callers).

One question is, could we for C23 somehow limit this for the most common
case where people just forward declare some aggregate type and then soon
after define it?  But guess the problematic counterexample there is
struct S; // forward declare
struct S *p; // create some derived types from it
void foo (void)
{
  struct S { int s; };  // define the type in a different scope
// (perhaps with a forward declaration as well)
  struct S s;
  use (); // create derived types
}
struct S { int s; };// define the type in the global scope to something
// that matches previously defined struct S in
// another scope
So e.g. noting in the hash table that a particular type has been forward
declared so far and using TYPE_STRUCTURAL_EQUALITY_P only if it has been
forward declared in some other scope wouldn't work.

Another question is whether c_update_type_canonical can or should try to
update TYPE_ALIAS_SET if TYPE_ALIAS_SET_KNOWN_P.  Or do we never cache
alias sets for TYPE_STRUCTURAL_EQUALITY_P types?

Anyway, the ICE on the testcase is because alias.cc asserts that
a !TYPE_STRUCTURAL_EQUALITY_P (type) has
!TYPE_STRUCTURAL_EQUALITY_P (TYPE_CANONICAL (type)).

The possibilities to resolve that are either at c_update_type_canonical
time try to find all the derived types rather than just some and recompute
their TYPE_CANONICAL.  Guess we could e.g. just traverse the whole
type_hash_table hash table and for each type see if it is in any way related
to the type that is being changed and then recompute them.  Though,
especially FUNCTION_TYPEs make that really ugly and furthermore it needs
to be recomputed in the right order, basically in the derivation order.
Without doing that, we'll have some TYPE_STRUCTURAL_EQUALITY_P derived
types in the type_hash_table hash table; that is conservatively correct,
but can result in worse code generation because of using alias set 0.

Another possibility is what Richi posted, essentially stop reusing
derived types created from the time when the base type was incomplete
when asking for a new derived type.  We'll get the TYPE_STRUCTURAL_EQUALITY_P
derived types if they were created before the base type was completed
when used directly (e.g. when it is a TREE_TYPE of some decl etc.), but
when we ask for a new type we'd disregard the old type and create a new one.
I'm not sure the patch is complete for that, because it doesn't adjust
check_base_type, build_pointer_type_for_mode, build_reference_type_for_mode
which don't use type_hash_canon but walk TYPE_NEXT_VARIANT list or
TYPE_POINTER_TO or TYPE_REFERENCE_TO chains.  Though, maybe it is ok
as is when c_update_type_canonical adjusts the pointer types
and variant types, those 

[PATCH] c++: Implement C++26 P2893R3 - Variadic friends [PR114459]

2024-05-03 Thread Jakub Jelinek
Hi!

The following patch imeplements the C++26 P2893R3 - Variadic friends
paper.  The paper allows for the friend type declarations to specify
more than one friend type specifier and allows to specify ... at
the end of each.  The patch doesn't introduce tentative parsing of
friend-type-declaration non-terminal, but rather just extends existing
parsing where it is a friend declaration which ends with ; after the
declaration specifiers to the cases where it ends with ...; or , or ...,
In that case it pedwarns for cxx_dialect < cxx26, handles the ... and
if there is , continues in a loop to parse the further friend type
specifiers.

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

2024-05-03  Jakub Jelinek  

PR c++/114459
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): Predefine
__cpp_variadic_friend=202403L for C++26.
gcc/cp/
* parser.cc (cp_parser_member_declaration): Implement C++26
P2893R3 - Variadic friends.  Parse friend type declarations
with ... or with more than one friend type specifier.
* friend.cc (make_friend_class): Allow TYPE_PACK_EXPANSION.
* pt.cc (instantiate_class_template): Handle PACK_EXPANSION_P
in friend classes.
gcc/testsuite/
* g++.dg/cpp26/feat-cxx26.C (__cpp_variadic_friend): Add test.
* g++.dg/cpp26/variadic-friend1.C: New test.

--- gcc/c-family/c-cppbuiltin.cc.jj 2024-05-02 09:31:17.746298275 +0200
+++ gcc/c-family/c-cppbuiltin.cc2024-05-03 14:50:08.008242950 +0200
@@ -1093,6 +1093,7 @@ c_cpp_builtins (cpp_reader *pfile)
  cpp_define (pfile, "__cpp_placeholder_variables=202306L");
  cpp_define (pfile, "__cpp_structured_bindings=202403L");
  cpp_define (pfile, "__cpp_deleted_function=202403L");
+ cpp_define (pfile, "__cpp_variadic_friend=202403L");
}
   if (flag_concepts)
 {
--- gcc/cp/parser.cc.jj 2024-05-03 09:43:47.781511477 +0200
+++ gcc/cp/parser.cc2024-05-03 13:26:38.208088017 +0200
@@ -28102,7 +28102,14 @@ cp_parser_member_declaration (cp_parser*
 goto out;
   /* If there is no declarator, then the decl-specifier-seq should
  specify a type.  */
-  if (cp_lexer_next_token_is (parser->lexer, CPP_SEMICOLON))
+  if (cp_lexer_next_token_is (parser->lexer, CPP_SEMICOLON)
+  || (cp_parser_friend_p (_specifiers)
+ && cxx_dialect >= cxx11
+ && (cp_lexer_next_token_is (parser->lexer, CPP_COMMA)
+ || (cp_lexer_next_token_is (parser->lexer, CPP_ELLIPSIS)
+ && (cp_lexer_nth_token_is (parser->lexer, 2, CPP_SEMICOLON)
+ || cp_lexer_nth_token_is (parser->lexer, 2,
+   CPP_COMMA))
 {
   /* If there was no decl-specifier-seq, and the next token is a
 `;', then we have something like:
@@ -28137,44 +28144,81 @@ cp_parser_member_declaration (cp_parser*
{
  /* If the `friend' keyword was present, the friend must
 be introduced with a class-key.  */
-  if (!declares_class_or_enum && cxx_dialect < cxx11)
-pedwarn (decl_spec_token_start->location, OPT_Wpedantic,
- "in C++03 a class-key must be used "
- "when declaring a friend");
-  /* In this case:
+ if (!declares_class_or_enum && cxx_dialect < cxx11)
+   pedwarn (decl_spec_token_start->location, OPT_Wpedantic,
+"in C++03 a class-key must be used "
+"when declaring a friend");
+ if (!cp_lexer_next_token_is (parser->lexer, CPP_SEMICOLON)
+ && cxx_dialect < cxx26)
+   pedwarn (cp_lexer_peek_token (parser->lexer)->location,
+OPT_Wc__26_extensions,
+"variadic friends or friend type declarations with "
+"multiple types only available with "
+"%<-std=c++2c%> or %<-std=gnu++2c%>");
+ location_t friend_loc = decl_specifiers.locations[ds_friend];
+ do
+   {
+ /* In this case:
 
-   template  struct A {
- friend struct A::B;
-   };
+template  struct A {
+  friend struct A::B;
+};
 
- A::B will be represented by a TYPENAME_TYPE, and
- therefore not recognized by check_tag_decl.  */
-  if (!type)
-{
-  type = decl_specifiers.type;
-  if (type && TREE_CODE (type) == TYPE_DECL)
-type = TREE_TYPE (type);
-

Re: [PATCH v2] gcc-14: Mention that some warnings are now errors

2024-05-03 Thread Jakub Jelinek
On Fri, May 03, 2024 at 04:06:28PM +0100, Jonathan Wakely wrote:
> I agree it should be mentioned, but I would put it in the caveats
> section at the top, not as the last item of the C section.
> 
> How about this? OK for wwwdocs?

LGTM.

> commit fe5fd75ea5a7a08eee0831cadbdd05689e9408db
> Author: Jonathan Wakely 
> Date:   Fri May 3 16:04:49 2024 +0100
> 
> Add caveat to GCC 14 release notes about C warnings-as-errors change
> 
> diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> index 46a0266d..82906de1 100644
> --- a/htdocs/gcc-14/changes.html
> +++ b/htdocs/gcc-14/changes.html
> @@ -40,6 +40,11 @@ a work-in-progress.
> href="https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wflex-array-member-not-at-end;>-Wflex-array-member-not-at-end
>  to
>identify all such cases in the source code and modify them.
>
> +  C:
> +  Certain warnings about are now errors, see
> +  Porting to GCC 14
> +  for details.
> +  
> href="https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html;>-fcf-protection=[full|branch|return|none|check]
>is refactored, to override -fcf-protection,
>-fcf-protection=none needs to be added and then

Jakub



<    1   2   3   4   5   6   7   8   9   10   >