[Bug c++/112715] Incorrect handling of template type aliases instantiated from decltype of lambdas

[gcc at nospam dot scs.stanford.edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112715

--- Comment #1 from David Mazières  ---
I should have mentioned, I hereby place the test case in the public domain.

[Bug c++/112715] New: Incorrect handling of template type aliases instantiated from decltype of lambdas

[gcc at nospam dot scs.stanford.edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112715

Bug ID: 112715
   Summary: Incorrect handling of template type aliases
instantiated from decltype of lambdas
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at nospam dot scs.stanford.edu
  Target Milestone: ---

Created attachment 56689
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56689=edit
File that should compile but doesn't

I'm using g++ version 13.2.1 on arch linux, configured as follows:


$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20230801 (GCC) 


When defining template type aliases, I get bizarrely incorrect types in some
contexts but not others.  For example, the static assertion fails in this code
but should not:


#include 

template
using uintsz = decltype([](auto i){
  if constexpr (i <= 32)
return 0;
  else
return 0L;
 }(std::integral_constant{}));

template
constexpr uintsz<8*Nbytes>
f()
{
  return 0;
}

static_assert(std::is_same_v()), uintsz<56>>);


Specifically I get the following error:


$ g++ -std=c++20 -ggdb -O -Wall -c -o uintsz.o uintsz.cc
uintsz.cc:18:20: error: static assertion failed
   18 | static_assert(std::is_same_v()), uintsz<56>>);
  |   ~^~~


This feels like some sort of state corruption in the compiler, because there
are more complicated examples in which gcc rejects other things inside
functions (like rejecting a using type alias and accepting the corresponding
typedef).  I think this example suffices to show the problem, but I could try
to reduce another test case if necessary.  In all cases, clang++ -std=c++20
accepts the code.

[Bug testsuite/112714] New: gcc.dg/tree-ssa/predcom-2.c fails on aarch64-* with -march=armv9-a+sve

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112714

Bug ID: 112714
   Summary: gcc.dg/tree-ssa/predcom-2.c fails on aarch64-* with
-march=armv9-a+sve
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Similar to how gcc.dg/unroll-8.c is handled, gcc.dg/tree-ssa/predcom-2.c 
should be handled too.
Note right now we have:
/* { dg-additional-options "-fno-tree-vectorize" { target amdgcn-*-* riscv*-*-*
} } */

See also https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637835.html .

Re: [PATCH 2/2] testsuite/unroll-8: Disable vectorization for varibale-factor targets

[Andrew Pinski]

On Wed, Nov 22, 2023 at 4:18 PM Jeff Law  wrote:
>
>
>
> On 11/21/23 16:27, Palmer Dabbelt wrote:
> > The vectorizer picks up these loops and disables unrolling on targets
> > with variable vector factors.  That result in better code here, but it
> > trips up the unrolling tests.  So just disable vectorization for these.
> >
> > gcc/testsuite/ChangeLog:
> >
> >   PR target/112531
> >   * gcc.dg/unroll-8.c: Disable vectorization on arm64 and riscv.
> So probably the right check is to test for vector and
> !vect_variable_length rather than doing something target specific for
> aarch64/riscv

Yes I think that would definitely be better.

>
> Jeff

[Bug target/112531] [14] RISC-V: gcc.dg/unroll-8.c rtl-dump scan errors with --param=riscv-autovec-preference=scalable

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112531

Andrew Pinski  changed:

   What|Removed |Added

 Target|riscv   |riscv aarch64-*-*
 CC||pinskia at gcc dot gnu.org

--- Comment #6 from Andrew Pinski  ---
I have the same failure on aarch64 with -march=armv9-a+sve:
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "Not unrolling loop, doesn't
roll"
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "likely upper bound: 6"
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "realistic bound: -1"


https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637835.html

[Bug testsuite/112691] [14 Regression] gcc.dg/vla-1.c fails

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112691

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Andrew Pinski  ---
Fixed.

[Bug testsuite/112691] [14 Regression] gcc.dg/vla-1.c fails

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112691

--- Comment #1 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:bd7f16b43e2afe5bd8429479485b5c70cedbdee6

commit r14-5850-gbd7f16b43e2afe5bd8429479485b5c70cedbdee6
Author: Andrew Pinski 
Date:   Sat Nov 25 20:24:56 2023 -0800

Fix gcc.dg/vla-1.c

r14-5628-g53ba8d669550d3 added noipa to f1 but `-fno-ipa-vrp` should have
been used
instead. The testcase is testing about the clone of f1 so turning off
IPA VRP is the correct approach here rather than turning off of IPA on the
function.

gcc/testsuite/ChangeLog:

PR testsuite/112691
* gcc.dg/vla-1.c: Add -fno-ipa-vrp.
Remove noipa from f1.

Signed-off-by: Andrew Pinski 

[COMMITTED] Fix gcc.dg/vla-1.c

[Andrew Pinski]

r14-5628-g53ba8d669550d3 added noipa to f1 but `-fno-ipa-vrp` should have been 
used
instead. The testcase is testing about the clone of f1 so turning off
IPA VRP is the correct approach here rather than turning off of IPA on the 
function.

gcc/testsuite/ChangeLog:

PR testsuite/112691
* gcc.dg/vla-1.c: Add -fno-ipa-vrp.
Remove noipa from f1.

Signed-off-by: Andrew Pinski 
---
 gcc/testsuite/gcc.dg/vla-1.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/vla-1.c b/gcc/testsuite/gcc.dg/vla-1.c
index 12aa314f385..d16e73d1dc3 100644
--- a/gcc/testsuite/gcc.dg/vla-1.c
+++ b/gcc/testsuite/gcc.dg/vla-1.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
-/* { dg-options "-g -O3 -fdump-tree-optimized -fvar-tracking-assignments 
-fno-selective-scheduling -fno-selective-scheduling2" } */
+/* { dg-options "-g -O3 -fdump-tree-optimized -fvar-tracking-assignments 
-fno-selective-scheduling -fno-selective-scheduling2 -fno-ipa-vrp" } */
 
-int __attribute__((noinline,noipa))
+int __attribute__((noinline))
 f1 (int i)
 {
   char a[i + 1];
-- 
2.39.3

[Bug testsuite/112688] [14 Regression] testcases: gcc.target/aarch64/movk.c and vmulxd_*_2.c need to updated after r14-5628-g53ba8d669550d3

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112688

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Andrew Pinski  ---
Fixed.

[Bug testsuite/112688] [14 Regression] testcases: gcc.target/aarch64/movk.c and vmulxd_*_2.c need to updated after r14-5628-g53ba8d669550d3

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112688

--- Comment #4 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:a9693bff396b28748464630e4c524776bce3ff4e

commit r14-5849-ga9693bff396b28748464630e4c524776bce3ff4e
Author: Andrew Pinski 
Date:   Sat Nov 25 18:50:46 2023 -0800

Fix gcc.target/aarch64/simd/vmulxd_{f64,f32}_2.c after after IPA-VRP
improvement for return values

Just like the patch against gcc.target/aarch64/movk.c, the issue here
is the two functions, foo32 and foo64 needed to mark as noipa so that
IPA-VRP cannot propagate the return value.

gcc/testsuite/ChangeLog:

PR testsuite/112688
* gcc.target/aarch64/simd/vmulx.x (foo32): Mark as noipa rather
than noinline.
(foo4): Likewise.

Signed-off-by: Andrew Pinski 

[Bug c++/108321] g++.dg/contracts/contracts-tmpl-spec2.C fails after r13-4160-g2efb237ffc68ec

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108321

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #9 from Andrew Pinski  ---
Fixed on the trunk.

[Bug c++/108321] g++.dg/contracts/contracts-tmpl-spec2.C fails after r13-4160-g2efb237ffc68ec

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108321

--- Comment #8 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:6e15e4e1abed02443a27a69455f4bfa49457c99e

commit r14-5848-g6e15e4e1abed02443a27a69455f4bfa49457c99e
Author: Andrew Pinski 
Date:   Thu Nov 23 18:55:30 2023 -0800

Fix contracts-tmpl-spec2.C on targets where plain char is unsigned by
default

Since contracts-tmpl-spec2.C is just testing contracts, I thought it would
be better
to just add `-fsigned-char` to the options rather than change the testcase
to support
both cases.

Committed after testing on aarch64-linux-gnu.

gcc/testsuite/ChangeLog:

PR testsuite/108321
* g++.dg/contracts/contracts-tmpl-spec2.C: Add -fsigned-char
to options.

Signed-off-by: Andrew Pinski 

[PATCH 2/2] Fix gcc.target/aarch64/simd/vmulxd_{f64, f32}_2.c after after IPA-VRP improvement for return values

[Andrew Pinski]

Just like the patch against gcc.target/aarch64/movk.c, the issue here
is the two functions, foo32 and foo64 needed to mark as noipa so that
IPA-VRP cannot propagate the return value.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/simd/vmulx.x (foo32): Mark as noipa rather
than noinline.
(foo4): Likewise.
---
 gcc/testsuite/gcc.target/aarch64/simd/vmulx.x | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/simd/vmulx.x 
b/gcc/testsuite/gcc.target/aarch64/simd/vmulx.x
index 8968a64a95c..869e7485646 100644
--- a/gcc/testsuite/gcc.target/aarch64/simd/vmulx.x
+++ b/gcc/testsuite/gcc.target/aarch64/simd/vmulx.x
@@ -33,13 +33,13 @@
   while (0)\
 
 /* Functions used to return values that won't be optimised away.  */
-float32_t  __attribute__ ((noinline))
+float32_t  __attribute__ ((noipa))
 foo32 ()
 {
   return 1.0;
 }
 
-float64_t  __attribute__ ((noinline))
+float64_t  __attribute__ ((noipa))
 foo64 ()
 {
   return 1.0;
-- 
2.34.1

[PATCH 1/2] Fix contracts-tmpl-spec2.C on targets where plain char is unsigned by default

[Andrew Pinski]

Since contracts-tmpl-spec2.C is just testing contracts, I thought it would be 
better
to just add `-fsigned-char` to the options rather than change the testcase to 
support
both cases.

Committed after testing on aarch64-linux-gnu.

gcc/testsuite/ChangeLog:

PR testsuite/108321
* g++.dg/contracts/contracts-tmpl-spec2.C: Add -fsigned-char
to options.
---
 gcc/testsuite/g++.dg/contracts/contracts-tmpl-spec2.C | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/g++.dg/contracts/contracts-tmpl-spec2.C 
b/gcc/testsuite/g++.dg/contracts/contracts-tmpl-spec2.C
index 82117671b2d..fd3a25bd051 100644
--- a/gcc/testsuite/g++.dg/contracts/contracts-tmpl-spec2.C
+++ b/gcc/testsuite/g++.dg/contracts/contracts-tmpl-spec2.C
@@ -1,6 +1,6 @@
 // basic test to ensure contracts work for class and member specializations
 // { dg-do run }
-// { dg-options "-std=c++2a -fcontracts -fcontract-continuation-mode=on" }
+// { dg-options "-std=c++2a -fcontracts -fcontract-continuation-mode=on 
-fsigned-char" }
 #include 
 
 // template specializations can have differing contracts
-- 
2.34.1

[Bug sanitizer/112708] "gcc -fsanitize=address" produces wrong debug info for variables in function prologue

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112708

--- Comment #6 from Bruno Haible  ---
For comparison, what clang 17 with -fsanitize=address does in this situation,
is to not generate a stepping point at the function entry (xg-message.c:50).
The gdb 'step' command brings me directly to the first statement in the
function (xg-message.c:55). This may have some other drawbacks, but at least it
prevents the possibility of displaying wrong values for function parameters.

Re: [PATCH] libstdc++/complex: Remove implicit type casts in complex

[Weslley da Silva Pereira]

Hi Jonathan,

Is there a way I can see my patch merged (when it gets merged)?
Particularly, I want to have a link for the commit. I would like to add
this as "impact on third party software" for the software
https://github.com/tlapack/tlapack.

Thanks,
  Weslley

On Mon, Nov 6, 2023 at 3:44 AM Jonathan Wakely  wrote:

> On Fri, 3 Nov 2023 at 17:47, Weslley da Silva Pereira
>  wrote:
> >
> > Hi Jonathan,
> >
> > I am sorry for the delay. The mailing lists libstd...@gcc.gnu.org and
> gcc-patches@gcc.gnu.org have just too many emails, so your email got
> lost. I hope my changes still make sense to be included in GCC. Please,
> find my comments below.
>
> Hi,
>
> Thanks for the updated patch, test etc. Yes, I think this still makes
> sense and I'll take care of committing it.
>
>
>
> >
> > On Thu, May 11, 2023 at 3:57 PM Jonathan Wakely 
> wrote:
> >>
> >>
> >>
> >> On Mon, 27 Mar 2023 at 22:25, Weslley da Silva Pereira via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
> >>>
> >>> Dear all,
> >>>
> >>> Here follows a patch that removes implicit type casts in std::complex.
> >>>
> >>> *Description:* The current implementation of `complex<_Tp>` assumes
> that
> >>> `int, double, long double` are explicitly convertible to `_Tp`.
> Moreover,
> >>> it also assumes that:
> >>>
> >>> 1. `int` is implicitly convertible to `_Tp`, e.g., when using
> >>> `complex<_Tp>(1)`.
> >>> 2. `long double` can be attributed to a `_Tp` variable, e.g., when
> using
> >>> `const _Tp __pi_2 = 1.5707963267948966192313216916397514L`.
> >>>
> >>> This patch transforms the implicit casts (1) and (2) into explicit type
> >>> casts. As a result, `std::complex` is now able to support more types.
> One
> >>> example is the type `Eigen::Half` from
> >>> https://eigen.tuxfamily.org/dox-devel/Half_8h_source.html which does
> not
> >>> implement implicit type conversions.
> >>>
> >>> *ChangeLog:*
> >>> libstdc++-v3/ChangeLog:
> >>>
> >>> * include/std/complex:
> >>
> >>
> >> Thank you for the patch. Now that we're in developement stage 1 for GCC
> 14, it's time to consider it.
> >>
> >> You're missing a proper changelog entry, I suggest:
> >>
> >>* include/std/complex (polar, __complex_sqrt)
> >>(__complex_pow_unsigned, pow, __complex_acos): Replace implicit
> >>conversions from int and long double to value_type.
> >
> >
> > I agree with your proposal for the changelog.
> >
> >>
> >> You're also missing either a copyright assignment on file with the FSF
> (unless you've completed that paperwork?), or a DCO sign-off. Please see
> https://gcc.gnu.org/contribute.html#legal and https://gcc.gnu.org/dco.html
> for more details.
> >
> >
> > Here is my DCO sign-off:
> >
> > Copyright:
> > Signed-off-by: Weslley da Silva Pereira 
> >
> >>
> >>
> >>>
> >>>
> >>> *Patch:* fix_complex.diff. (Also at
> >>> https://github.com/gcc-mirror/gcc/pull/84)
> >>>
> >>> *OBS:* I didn't find a good reason for adding new tests or test results
> >>> here since this is really a small upgrade (in my view) to std::complex.
> >>
> >>
> >> I don't agree. The purpose of this is to support std::complex for
> a type Foo without implicit conversions (which isn't required by the
> standard btw, only the floating-point types are required to work, but we
> can support others as an extension). Without tests, we don't know if that
> goal has been met, and we don't know if the goal continues to be met in
> future versions. A test would ensure that we don't accidentally
> re-introduce code requiring implicit conversions.
> >>
> >> With a suitable test, I think this patch will be OK for GCC 14.
> >>
> >> Thanks again for contributing.
> >>
> >>
> >
> > Tests:
> > See the attached file `test_complex_eigenhalf.cpp`
> >
> > Test results:
> > - When using x86-64 GCC (trunk), I obtained compilation errors as shown
> in the attached text file. Live example at:
> https://godbolt.org/z/oa9M34h8P.
> > - I observed no errors after applying the suggested patch on my machine.
> > - I tried it with the flag `-Wall`. No warnings were shown.
> > - My machine configuration and my GCC build information are displayed in
> the file `config.log` generated by the configuration step of GCC.
> >
> > Let me know if I need to do anything else.
> >
> > Thanks,
> >   Weslley
> >
> > --
> > Weslley S. Pereira
>
>

-- 
Weslley S. Pereira

[Bug target/112443] [12/13/14 Regression] Misoptimization of _mm256_blendv_epi8 intrinsic on avx512bw+avx512vl

[sjames at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112443

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |crazylht at gmail dot 
com
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Sam James  ---
Fixed for 12.4/13.3/14.

[Committed] RISC-V: Fix typo

[Juzhe-Zhong]

Fix typo. Committed.

gcc/ChangeLog:

* config/riscv/riscv-avlprop.cc (alv_can_be_propagated_p): Fix typo.
(avl_can_be_propagated_p): Ditto.
(vlmax_ta_p): Ditto.

---
 gcc/config/riscv/riscv-avlprop.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/riscv/riscv-avlprop.cc 
b/gcc/config/riscv/riscv-avlprop.cc
index 68b9af07d99..7a741c25d2b 100644
--- a/gcc/config/riscv/riscv-avlprop.cc
+++ b/gcc/config/riscv/riscv-avlprop.cc
@@ -106,7 +106,7 @@ avlprop_type_to_str (enum avlprop_type type)
 
 /* Return true if the AVL of the INSN can be propagated.  */
 static bool
-alv_can_be_propagated_p (rtx_insn *rinsn)
+avl_can_be_propagated_p (rtx_insn *rinsn)
 {
   /* The index of "vrgather dest, source, index" may pick up the
  element which has index >= AVL, so we can't strip the elements
@@ -118,7 +118,7 @@ static bool
 vlmax_ta_p (rtx_insn *rinsn)
 {
   return vlmax_avl_type_p (rinsn) && tail_agnostic_p (rinsn)
-&& alv_can_be_propagated_p (rinsn);
+&& avl_can_be_propagated_p (rinsn);
 }
 
 static machine_mode
-- 
2.36.3

[Bug c/112713] New: RISC-V: Trunk GCC regression on VSETVL PASS comparing with GCC-13

[juzhe.zhong at rivai dot ai via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112713

Bug ID: 112713
   Summary: RISC-V: Trunk GCC regression on VSETVL PASS comparing
with GCC-13
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juzhe.zhong at rivai dot ai
  Target Milestone: ---

https://godbolt.org/z/qePhcxd5z

#include "riscv_vector.h"

size_t
foo (char const *buf, size_t len)
{
size_t sum = 0;
size_t vl = __riscv_vsetvlmax_e8m8();
size_t step = vl * 4;
const char *it = buf, *end = buf + len;
for(; it + step <= end; ) {
it += vl;
vint8m8_t v3 = __riscv_vle8_v_i8m8((void*)it, vl); it += vl;
vbool1_t m3 = __riscv_vmsgt_vx_i8m8_b1(v3, -65, vl);
sum += __riscv_vcpop_m_b1(m3, vl);
}
return sum;
}

GCC-14 ASM:

foo:
vsetvli a4,zero,e8,m8,ta,ma
sllia5,a4,2
add a1,a0,a1
add a5,a0,a5
bltua1,a5,.L4
sllia6,a4,1
add a5,a0,a4
add t1,a6,a4
li  a0,0
li  a7,-65
vsetvli zero,zero,e8,m8,ta,ma   --> redundant
.L3:
vle8.v  v8,0(a5)
add a5,a5,a6
add a3,t1,a5
vmsgt.vxv8,v8,a7
vcpop.m a2,v8
add a0,a0,a2
bgeua1,a3,.L3
ret
.L4:
li  a0,0
ret

GCC-13 ASM:

foo:
vsetvli a4,zero,e8,m8,ta,ma
sllia5,a4,2
add a1,a0,a1
add a5,a0,a5
bltua1,a5,.L4
sllia6,a4,1
add a5,a0,a4
add t1,a6,a4
li  a0,0
li  a7,-65
.L3:
vle8.v  v8,0(a5)
add a5,a5,a6
add a3,t1,a5
vmsgt.vxv24,v8,a7
vcpop.m a2,v24
add a0,a0,a2
bgeua1,a3,.L3
ret
.L4:
li  a0,0
ret

Trunk GCC-14 has a regression that cause a redundant vsetvl.

Such regression need to be fixed and I will take a look at it.

Re: [PATCH] Update GMP/MPFR/MPC/ISL/gettext to latest release

[Iain Sandoe]

> On 25 Nov 2023, at 21:44, Sebastian Huber 
>  wrote:
> 
> On 25.11.23 14:59, Richard Biener wrote:
>> On Sat, Nov 25, 2023 at 12:26 PM Sebastian Huber
>>   wrote:
>>> contrib/ChangeLog
>> Did you verify an in-tree build with these works and the testsuite
>> is clean?
> 
> I was able to build a native GCC:
> 
> /tmp/sh/i-native/bin/gcc --version --verbose
> Using built-in specs.
> COLLECT_AS_OPTIONS='--version'
> COLLECT_GCC=/tmp/sh/i-native/bin/gcc
> COLLECT_LTO_WRAPPER=/tmp/sh/i-native/lib/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
> gcc (GCC) 14.0.0 20231125 (experimental) [master 9c26c91b94e]
> Copyright (C) 2023 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> Target: x86_64-pc-linux-gnu
> Configured with: /home/EB/sebastian_h/src/gcc/configure 
> --prefix=/tmp/sh/i-native --verbose --enable-checking=yes,rtl 
> --disable-libsanitizer --disable-multilib --disable-bootstrap 
> --enable-languages=c,c++
> Thread model: posix
> Supported LTO compression algorithms: zlib
> gcc version 14.0.0 20231125 (experimental) [master 9c26c91b94e] (GCC)
> COLLECT_GCC_OPTIONS='--version' '-v' '-mtune=generic' '-march=x86-64' 
> '-dumpdir' 'a-'
> /tmp/sh/i-native/lib/gcc/x86_64-pc-linux-gnu/14.0.0/cc1 -quiet -v help-dummy 
> -quiet -dumpdir a- -dumpbase help-dummy -mtune=generic -march=x86-64 -version 
> --version -o /tmp/ccHTKJ5B.s
> GNU C17 (GCC) version 14.0.0 20231125 (experimental) [master 9c26c91b94e] 
> (x86_64-pc-linux-gnu)
>compiled by GNU C version 14.0.0 20231122 (experimental) [master 
> 6bf66276e3e], GMP version 6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl 
> version isl-0.26-GMP
> [...]
> 
> However, I noticed that this was with a disabled bootstrap (for the git 
> bisect). The bootstrap fails with an error in ISL 0.26 which seems to be a 
> known issue:
> 
> https://www.mail-archive.com/gcc@gcc.gnu.org/msg101643.html
> 
> I thought that the GCC prerequisite library maintainers check that a new 
> release is able to bootstrap GCC, but this seems to be not the case. The 
> older releases have problems to recognize arm64-apple.

0.24 (at least) builds fine in-tree on aarch64-apple-darwin21; do you have a 
pointer to the recognition issue?
I’ll try 0.25 in the next few days.

Iain

[Bug c++/112712] New: Crash when compiling g++ -m68020-60 -O2

[miro.kropacek at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112712

Bug ID: 112712
   Summary: Crash when compiling g++ -m68020-60 -O2
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: miro.kropacek at gmail dot com
  Target Milestone: ---

Created attachment 56688
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56688=edit
Preprocessed output

This is a crash which seems to be specific to the -m68020-60 option (or better
said to 060 code generation as the only other option where this bugs occurs is
-m68060). When changing to any other CPU (-m68000, -mcpu=5475, ...) and/or
changing to -O1, -O0, ... everything is fine.

See the attached preprocessed file which triggers the bug:

m68k-elf-g++ -c -g -O2 -m68020-60 -fomit-frame-pointer -funsigned-char
-std=gnu++20 -fvisibility=hidden -Wno-sign-compare crash.cpp

similar/main/multi.cpp:6167:1: internal compiler error: in push_reload, at
reload.cc:1124
 6167 | }
  | ^
0x15fee77 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
???:0
0x15ffd3c internal_error(char const*, ...)
???:0
0x5e9465 fancy_abort(char const*, int, char const*)
???:0
0x5c9a9d push_reload(rtx_def*, rtx_def*, rtx_def**, rtx_def**, reg_class,
machine_mode, machine_mode, int, int, int, reload_type) [clone .cold]
???:0
0xca2ffb find_reloads(rtx_insn*, int, int, int, short*)
???:0
0xcb0dcb reload(rtx_insn*, int)
???:0
0xb4657a (anonymous namespace)::pass_reload::execute(function*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

Re: [PATCH v5 1/1] c++: Initial support for P0847R7 (Deducing This) [PR102609]

[waffl3x]

I don't think so, I'm concerned that it might eat the xobj parameter if
we do it that way. Besides, all we want is the lambda type anyway, I
don't want to build a whole new node just to do that. Upon further
consideration I think my solution does work and shouldn't cause
problems. The field that I'm using just doesn't get used anywhere else
for function_type nodes, and we create a new node in
tsubst_function_decl so we don't rely on that field anywhere after it's
used in tsubst_function_decl. I think I will null out the member,
consuming it, so that is clearly communicated.

I am still having issues trying to figure out where exactly to emit
errors from, it's really unclear how this stuff works during template
instantiation. I tried emitting conditionally based on the complain
parameter, but that seemed to suppress errors at all times. While at
the same time, I seemed to observe emitting errors unconditionally
(correctly) not not displaying the error when another candidate was
selected. This leads me to believe that there's already a mechanism for
discarding errors that occur during substitution. I don't really know
what to do for it, but surely I will figure it out now that I'm asking
for help, as tradition dictates.

The other problem I'm having is

auto f0 = [n = 5, ](this auto const&){ n = 10; };
This errors just fine, the lambda is unconditionally const so
LAMBDA_EXPR_MUTABLE_P flag is set for the closure.

This on the other hand does not. The constness of the captures depends
on (I assume) LAMBDA_EXPR_MUTABLE_P so all the captures are non-const
here.
auto f1 = [n = 5](this auto&& self){ n = 10; };
as_const(f1)();

I don't know the right way to solve this, I haven't even really tracked
down where the tree is built up. At the moment I think that hacking
something into instantiate_body to make them const is the right
decision, as the type of the closure shouldn't be changing when
instantiating it's call operator template. I'm not sure this is really
actually the right call though because it's another thing that feels
very much like a hack. As I near completion of the patch it feels like
more and more of the solutions I'm finding are hacks, and I don't know
if it's just a consequence of old assumptions or if I'm really just
reaching for the easy(ier) solutions way too quickly now.

These problems are the last few that I have and they are taking me way
more time than I am comfortable with.

I was going to close out this message there but I just realized why
exactly you think erroring in instantiate_body is too late, it's
because at that point an error is an error, while if we error a little
bit earlier during substitution it's not a hard error. I'm glad I
realized this now, because I am much more confident in how to implement
the errors for unrelated type now. I'm still a little confused on what
the exact protocol for emitting errors at this stage is, as there
aren't many explicit errors written in. It seems to me like the errors
are supposed to be emitted when calling back into non-template stages
of the compiler with substituted types. It also seems like that hasn't
always been strictly followed, and I hate to contribute to code debt
but I'm not sure how I would do it in this case, nor if I actually have
a valid understanding of how this all works.

Given my above realization, I'm now more confident in figuring out how
exactly to implement the errors for unrelated types. I guess I'm rubber
ducking a little bit in these e-mails. On the other hand, if the
conclusions I'm forming are incorrect, it's probably still helpful to
know the journey I took to get to them. I'm thinking it's probably
better I still include my initial concerns even though I feel like I
know the answer now.

One side note before I close up here, I don't like when *_P macros are
used to set flags. Is this
something else we should clean up in the future? I'm beginning to
wonder if an overhaul that gets rid of the macros from the public
interface is a good idea. I'm reluctant to suggest that as I've really
warmed up to the macros a lot. They are used in a consistent and easy
to understand way which is highly unlike the bad uses of macros that
I've seen before that really obscure what's actually going on. But they
are still macros, so maybe moving away from them is the right call,
especially since there has started to be a mix-up of macros and
functions for the same purposes. I'm mildly of the opinion that only
one style should be used (in the public interface) because mixing them
causes confusion, it did for me anyway. Perhaps I should open a thread
on the general mail list and see what others think, get some input
before I decide which direction to go with it. To be clear, when I say
getting rid of macros, I want to emphasize I mean only in the public
interface, I don't see any value in getting rid of macros under the
hood as the way the checking macros are implemented is already really
good and works. It would only cause problems to 

gcc-13-20231125 is now available

[GCC Administrator via Gcc]

Snapshot gcc-13-20231125 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/13-20231125/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-13 revision b8c1005181cb7e9964b48059453c767c371e77ec

You'll find:

 gcc-13-20231125.tar.xz   Complete GCC

  SHA256=29020f734c4e6171ac2fbf277f67052aad5e4dd53012cf8d6d93a9693d39efb8
  SHA1=361f484407871d269e62ebd1392018ea00cba7fb

Diffs from 13-20231118 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-13
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

[alexhenrie24 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07

--- Comment #13 from Alex Henrie  ---
I should clarify that I was testing with GCC 12.2. It turns out that GCC 12.3
does not crash, and I have now confirmed that the patch from comment #5 applied
to GCC 12.3 fixes https://bugs.winehq.org/show_bug.cgi?id=55007

What will it take to get the patch accepted?

Re: [PATCH] Update GMP/MPFR/MPC/ISL/gettext to latest release

[Sebastian Huber]

On 25.11.23 14:59, Richard Biener wrote:

On Sat, Nov 25, 2023 at 12:26 PM Sebastian Huber
  wrote:

contrib/ChangeLog

Did you verify an in-tree build with these works and the testsuite
is clean?


I was able to build a native GCC:

/tmp/sh/i-native/bin/gcc --version --verbose
Using built-in specs.
COLLECT_AS_OPTIONS='--version'
COLLECT_GCC=/tmp/sh/i-native/bin/gcc
COLLECT_LTO_WRAPPER=/tmp/sh/i-native/lib/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
gcc (GCC) 14.0.0 20231125 (experimental) [master 9c26c91b94e]
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Target: x86_64-pc-linux-gnu
Configured with: /home/EB/sebastian_h/src/gcc/configure 
--prefix=/tmp/sh/i-native --verbose --enable-checking=yes,rtl 
--disable-libsanitizer --disable-multilib --disable-bootstrap 
--enable-languages=c,c++

Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231125 (experimental) [master 9c26c91b94e] (GCC)
COLLECT_GCC_OPTIONS='--version' '-v' '-mtune=generic' '-march=x86-64' 
'-dumpdir' 'a-'
 /tmp/sh/i-native/lib/gcc/x86_64-pc-linux-gnu/14.0.0/cc1 -quiet -v 
help-dummy -quiet -dumpdir a- -dumpbase help-dummy -mtune=generic 
-march=x86-64 -version --version -o /tmp/ccHTKJ5B.s
GNU C17 (GCC) version 14.0.0 20231125 (experimental) [master 
9c26c91b94e] (x86_64-pc-linux-gnu)
compiled by GNU C version 14.0.0 20231122 (experimental) 
[master 6bf66276e3e], GMP version 6.3.0, MPFR version 4.2.1, MPC version 
1.3.1, isl version isl-0.26-GMP

[...]

However, I noticed that this was with a disabled bootstrap (for the git 
bisect). The bootstrap fails with an error in ISL 0.26 which seems to be 
a known issue:


https://www.mail-archive.com/gcc@gcc.gnu.org/msg101643.html

I thought that the GCC prerequisite library maintainers check that a new 
release is able to bootstrap GCC, but this seems to be not the case. The 
older releases have problems to recognize arm64-apple.


--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

[Bug testsuite/112688] [14 Regression] testcases: gcc.target/aarch64/movk.c and vmulxd_*_2.c need to updated after r14-5628-g53ba8d669550d3

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112688

--- Comment #3 from Andrew Pinski  ---
movk.c is fixed, I will submit the change for vmulxd_*_2.c in a few.

[Bug testsuite/112688] [14 Regression] testcases: gcc.target/aarch64/movk.c and vmulxd_*_2.c need to updated after r14-5628-g53ba8d669550d3

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112688

--- Comment #2 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:8d559a9b85d9a6de4f358171178a74605f554082

commit r14-5845-g8d559a9b85d9a6de4f358171178a74605f554082
Author: Andrew Pinski 
Date:   Tue Nov 21 18:25:24 2023 -0800

Fix gcc.target/aarch64/movk.c testcase after IPA-VRP improvement for return
values

The problem here is dummy_number_generator returns a constant which IPA VRP
is now able
propagate that so we need to mark the funciton as noipa to stop that.

gcc/testsuite/ChangeLog:

PR testsuite/112688
* gcc.target/aarch64/movk.c: Add noipa on dummy_number_generator
and remove -fno-inline option.

Signed-off-by: Andrew Pinski 

[Bug tree-optimization/112711] [14 Regression] SRA seems to ignore writes when using __builtin_assume_aligned

[slyfox at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112711

--- Comment #3 from Sergei Trofimovich  ---
I confirm bisect landed on r14-5831-gaae723d360ca26 as well.

[Bug tree-optimization/112711] [14 Regression] SRA seems to ignore writes when using __builtin_assume_aligned

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112711

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=109849
 CC||mjambor at suse dot cz

--- Comment #2 from Andrew Pinski  ---
I am 90% sure it was introduced by r14-5831-gaae723d360ca26 .

[Bug tree-optimization/112711] [14 Regression] SRA seems to ignore writes when using __builtin_assume_aligned

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112711

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-11-25
   Target Milestone|--- |14.0
Summary|[14 Regression] possibly|[14 Regression] SRA seems
   |wrong code in bswap32(int)  |to ignore writes when using
   |on llvm-16.0.6 test suite   |__builtin_assume_aligned
  Component|target  |tree-optimization
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||alias

--- Comment #1 from Andrew Pinski  ---
It has nothing to do with __builtin_bswap32 really but rather
__builtin_assume_aligned and the memcpy.

SRA does not detect:
  _9 = __builtin_assume_aligned (, 1);
  MEM  [(char * {ref-all})_9] = 3451308718;
  _1 = data[0];


The store to _9 as touching data ...

[Bug sanitizer/112709] [13/14 Regression] address sanitize and returns_twice causes an ICE

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112709

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|address sanitize and|[13/14 Regression] address
   |returns_twice causes an ICE |sanitize and returns_twice
   ||causes an ICE
 Ever confirmed|0   |1
   Last reconfirmed||2023-11-25
   Target Milestone|--- |13.3

--- Comment #1 from Andrew Pinski  ---
Confirmed, the checking is new in GCC 13. Though it seems like GCC 5 produced
IR that was ok.

I am not 100% sure how we should handle this case either.

[Bug middle-end/112711] New: [14 Regression] possibly wrong code in bswap32(int) on llvm-16.0.6 test suite

[slyfox at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112711

Bug ID: 112711
   Summary: [14 Regression] possibly wrong code in bswap32(int) on
llvm-16.0.6 test suite
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Initially noticed possibly wrong code on llvm-16.0.6 test suite when building
with gcc-master from r14-5844-g9c26c91b94eb72:

  Failed Tests (2):
LLVM-Unit :: Support/./SupportTests/Endian/Write
LLVM-Unit :: Support/./SupportTests/Endian/WriteBitAligned

I extracted the following self-contained example:

// $ cat EndianTest.cpp
typedef  int i32;
typedef unsigned int u32;

static inline void write_i32(void *memory, i32 value) {
  // swap i32 bytes as if it was u32:
  u32 u_value = value;
  value = __builtin_bswap32(u_value);

  // llvm infers '1' alignment from destination type
  __builtin_memcpy(__builtin_assume_aligned(memory, 1), , sizeof(value));
}

__attribute__((noipa))
static void bug (void) {
  #define assert_eq(lhs, rhs) if (lhs != rhs) __builtin_trap()

  unsigned char data[5];
  write_i32(data, -1362446643);
  assert_eq(data[0], 0xAE);
  assert_eq(data[1], 0xCA);
  write_i32(data + 1, -1362446643);
  assert_eq(data[1], 0xAE);
}

int main() {
bug();
}

Fails as:

$ gcc/xg++ -Bgcc EndianTest.cpp -o bug -O0 && ./bug
$ gcc/xg++ -Bgcc EndianTest.cpp -o bug -O2 && ./bug
Illegal instruction (core dumped)

$ gcc/xg++ -Bgcc -v
Reading specs from gcc/specs
COLLECT_GCC=gcc/xg++
COLLECT_LTO_WRAPPER=gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib
--disable-bootstrap --disable-lto --disable-libsanitizer
--disable-libstdcxx-pch --enable-languages=c,c++ --disable-libgomp
--disable-libquadmath --disable-libvtv CFLAGS='-O1 -g0' CXXFLAGS='-O1 -g0'
LDFLAGS='-O1 -g0'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231125 (experimental) (GCC)

[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

[alexhenrie24 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07

--- Comment #12 from Alex Henrie  ---
Created attachment 56687
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56687=edit
Minimal example to reproduce the crash

Here's a minimal example that crashes on MinGW 12 with -m32 -mavx512f
-mpreferred-stack-boundary=2. I tried it with MinGW 13 on Compiler Explorer
 and it does not crash, so it looks like that bug has
been fixed already.

[Bug fortran/106856] [12 Regression][OOP] CLASS attribute handling / ICE in gfc_conv_expr_present, at fortran/trans-expr.cc:1977 since r12-4346-geb92cd57a1ebe7cd

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106856

--- Comment #19 from anlauf at gcc dot gnu.org ---
*** Bug 96655 has been marked as a duplicate of this bug. ***

[Bug fortran/96655] [OOP] CLASS dummy arguments: Bogus "Duplicate OPTIONAL attribute specified"

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96655

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED
 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
This a variation of pr106856, fixed in 12.3, thus a duplicate.

*** This bug has been marked as a duplicate of bug 106856 ***

[Bug fortran/100651] [11/12/13/14 Regression] Bad handling of optional, allocatable character argument

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100651

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #11 from anlauf at gcc dot gnu.org ---
Possibly related: pr93762 (see Steve's analysis).

[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

[alexhenrie24 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07

--- Comment #11 from Alex Henrie  ---
Well, this is interesting: Unpatched MinGW 12 crashes in the same way if I set
both -march=native and -mpreferred-stack-boundary=2. So the problem is not the
patch itself, it's just that the patch revealed some other bug.

[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

[gabrielopcode at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07

--- Comment #10 from Gabriel Ivăncescu  ---
(In reply to Alexander Monakov from comment #9)
> -mpreferred-stack-boundary=n means that functions consume stack in
> increments of 2**n. This is sufficient to ensure that once stack is aligned
> to that boundary, it will keep it without the need for dynamic realignment.
> 
> -mincoming-stack-boundary specifies the guaranteed alignment on entry. If
> the function needs to place local variables with greater alignment
> requirement on the stack, it has perform dynamic realignment.

Yeah, but on 32-bit x86 Windows ABI, the stack is only guaranteed to be aligned
to 4 bytes (mincoming-stack-boundary=2). We don't control the callers, and apps
compiled with MSVC (i.e. the majority of them, including Windows' own
libraries) only adhere to this alignment, nothing more than that.

Therefore -mincoming-stack-boundary=2 should be the default on MinGW for this
target.

In general, setting -mpreferred-stack-boundary=2 is also preferable because the
vast majority of functions do *not* use SSE or AVX or whatever. If you set
-mpreferred-stack-boundary=4 it will *always* align the stack on entry, and
that's simply too much overhead. It's better only for functions that actually
need it to do it.

The point is, -mpreferred-stack-boundary=2 (and consequently
-mincoming-stack-boundary=2) is the default on MSVC and Windows 32-bit x86 ABI,
and that's for a reason. MinGW should follow that. By default, at least.

I've compiled Wine with those options for years now without trouble.

Re: [PATCH v5 1/1] c++: Initial support for P0847R7 (Deducing This) [PR102609]

[Jason Merrill]

On 11/24/23 01:49, waffl3x wrote:

and this in tsubst_lambda_expr that assumes iobj:

/* Fix the type of 'this'. */
fntype = build_memfn_type (fntype, type,
type_memfn_quals (fntype),
type_memfn_rqual (fntype));


Unfortunately, putting a condition on this had some unforeseen
consequences. I've been working on this about 8 hours today and I'm a
little defeated after discovering this.

commit 39ade88fa1632c659c5c4ed065fa2b62d16a8670
Author: Jason Merrill 
Date:   Tue Jan 24 15:29:35 2023 -0500

 c++: static lambda in template [PR108526]
 
 tsubst_lambda_expr uses build_memfn_type to build a METHOD_TYPE for the new

 lamba op().  This is not what we want for a C++23 static op(), but since we
 also use that METHOD_TYPE to communicate the closure type down to
 tsubst_function_decl, let's wait and turn it back at that point.
 
 PR c++/108526
 
 gcc/cp/ChangeLog:
 
 gcc/cp/ChangeLog:
 
 * pt.cc (tsubst_function_decl): Handle static lambda.
 
 gcc/testsuite/ChangeLog:
 
 * g++.dg/cpp23/static-operator-call5.C: New test.


diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 2a4d03c5e47..51fc246ed71 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -14306,6 +14306,11 @@ tsubst_function_decl (tree t, tree args, 
tsubst_flags_t complain,
tree ctx = closure ? closure : DECL_CONTEXT (t);
bool member = ctx && TYPE_P (ctx);
  
+  /* If this is a static lambda, remove the 'this' pointer added in

+ tsubst_lambda_expr now that we know the closure type.  */
+  if (lambda_fntype && DECL_STATIC_FUNCTION_P (t))
+lambda_fntype = static_fn_type (lambda_fntype);


Ah, right.  So the simplest thing would be to do the same thing here for 
xob lambdas.


Jason

[Bug target/112443] [12/13/14 Regression] Misoptimization of _mm256_blendv_epi8 intrinsic on avx512bw+avx512vl

[mikpelinux at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112443

--- Comment #8 from Mikael Pettersson  ---
Can this be closed now?

[Bug preprocessor/112701] wrong type inference for ternary operator with `0/0u` in preprocessing context

[mikpelinux at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701

--- Comment #2 from Mikael Pettersson  ---
gcc-2.95.3 generates neither, gcc-3.0.4 and up generate the bar: .long 0 (or
.zero 4) one.

[pushed] wwwdocs: reading: Update the MicroBlaze section

[Gerald Pfeifer]

MicroBlaze is now with AMD, spelt MicroBlaze not MicroBlace, and the
docs have a new address.
---
 htdocs/readings.html | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/htdocs/readings.html b/htdocs/readings.html
index 2e320945..e4e68909 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -192,9 +192,9 @@ names.
SID includes a MeP simulator.
  
 
- MicroBlace
-   Manufacturer: Xilinx
-   https://www.xilinx.com/htmldocs/xilinx11/mb_ref_guide.pdf;>
+ MicroBlaze
+   Manufacturer: AMD
+   https://docs.xilinx.com/v/u/en-US/ug984-vivado-microblaze-ref;>
  MicroBlaze Processor Reference Guide
GDB includes a simulator for an earlier version of the processor.
  
-- 
2.42.1

[pushed] wwwdocs: gcc-13: Refer to GCC (instead of gcc)

[Gerald Pfeifer]

Refer to the overall project as GCC.

Pushed.

Gerald
---
 htdocs/gcc-13/porting_to.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/gcc-13/porting_to.html b/htdocs/gcc-13/porting_to.html
index db0bf2fa..c727d66f 100644
--- a/htdocs/gcc-13/porting_to.html
+++ b/htdocs/gcc-13/porting_to.html
@@ -73,7 +73,7 @@ may change behavior or fail to compile in C++23.  For 
example:
 implicit move, whereby the compiler does two separate overload resolutions:
 one treating the operand as an rvalue, and then (if that resolution fails)
 another one treating the operand as an lvalue.  In the standard this was
-introduced in C++11 and implemented in gcc in
+introduced in C++11 and implemented in GCC in
 https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=4ce8c5dea53d80736b9c0ba6faa7430ed65ed365;>
 r251035.  In
 https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=1722e2013f05f1f1f99379dbaa0c0df356da731f;>
-- 
2.42.1

Re: c: tree: target: C2x (...) function prototypes and va_start relaxation

[Gerald Pfeifer]

On Fri, 21 Oct 2022, Joseph Myers wrote:
> C2x allows function prototypes to be given as (...), a prototype
> meaning a variable-argument function with no named arguments.

I noticed this did not make it into gcc-13/changes.html ? Was that 
intentional?

Gerald

Re: [PATCH] Update GMP/MPFR/MPC/ISL/gettext to latest release

[Richard Biener]

On Sat, Nov 25, 2023 at 12:26 PM Sebastian Huber
 wrote:
>
> contrib/ChangeLog

Did you verify an in-tree build with these works and the testsuite
is clean?

> * download_prerequisites: Update to gmp-6.3.0, mpfr-4.2.1,
> mpc-1.3.1, isl-0.26, and gettext-0.22.4.
> * prerequisites.md5: Update hash.
> * prerequisites.sha512: Likewise.
> ---
>  contrib/download_prerequisites | 10 +-
>  contrib/prerequisites.md5  | 10 +-
>  contrib/prerequisites.sha512   | 10 +-
>  3 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/contrib/download_prerequisites b/contrib/download_prerequisites
> index 9568091c0dba..b9deab316917 100755
> --- a/contrib/download_prerequisites
> +++ b/contrib/download_prerequisites
> @@ -27,11 +27,11 @@ version='(unversioned)'
>  # remember to also update the files `contrib/prerequisites.sha512` and
>  # `contrib/prerequisites.md5` with the new checksums.
>
> -gmp='gmp-6.2.1.tar.bz2'
> -mpfr='mpfr-4.1.0.tar.bz2'
> -mpc='mpc-1.2.1.tar.gz'
> -isl='isl-0.24.tar.bz2'
> -gettext='gettext-0.22.tar.gz'
> +gmp='gmp-6.3.0.tar.bz2'
> +mpfr='mpfr-4.2.1.tar.bz2'
> +mpc='mpc-1.3.1.tar.gz'
> +isl='isl-0.26.tar.bz2'
> +gettext='gettext-0.22.4.tar.gz'
>
>  base_url='http://gcc.gnu.org/pub/gcc/infrastructure/'
>
> diff --git a/contrib/prerequisites.md5 b/contrib/prerequisites.md5
> index 716a9ff910c7..2ccff4a4c44f 100644
> --- a/contrib/prerequisites.md5
> +++ b/contrib/prerequisites.md5
> @@ -1,5 +1,5 @@
> -28971fc21cf028042d4897f02fd355ea  gmp-6.2.1.tar.bz2
> -44b892bc5a45bafb4294d134e13aad1d  mpfr-4.1.0.tar.bz2
> -9f16c976c25bb0f76b50be749cd7a3a8  mpc-1.2.1.tar.gz
> -dd2f7b78e118c25bd96134a52aae7f4d  isl-0.24.tar.bz2
> -c092102240f8f66134d22718421d5115  gettext-0.22.tar.gz
> +c1cd6ef33085e9cb818b9b08371f9000  gmp-6.3.0.tar.bz2
> +7765afa036e4ce7fb0e02bce0fef894b  mpfr-4.2.1.tar.bz2
> +5c9bc658c9fd0f940e8e3e0f09530c62  mpc-1.3.1.tar.gz
> +da50c85e9841db36d48a492bbe836863  isl-0.26.tar.bz2
> +e541ba3603674a853cff9b28a68dd61e  gettext-0.22.4.tar.gz
> diff --git a/contrib/prerequisites.sha512 b/contrib/prerequisites.sha512
> index f71398bdbc31..9bc9ce468fdc 100644
> --- a/contrib/prerequisites.sha512
> +++ b/contrib/prerequisites.sha512
> @@ -1,5 +1,5 @@
> -8904334a3bcc5c896ececabc75cda9dec642e401fb5397c4992c4fabea5e962c9ce8bd44e8e4233c34e55c8010cc28db0545f5f750cbdbb5f00af538dc763be9
>   gmp-6.2.1.tar.bz2
> -410208ee0d48474c1c10d3d4a59decd2dfa187064183b09358ec4c4666e34d74383128436b404123b831e585d81a9176b24c7ced9d913967c5fce35d4040a0b4
>   mpfr-4.1.0.tar.bz2
> -3279f813ab37f47fdcc800e4ac5f306417d07f539593ca715876e43e04896e1d5bceccfb288ef2908a3f24b760747d0dbd0392a24b9b341bc3e12082e5c836ee
>   mpc-1.2.1.tar.gz
> -aab3bddbda96b801d0f56d2869f943157aad52a6f6e6a61745edd740234c635c38231af20bc3f1a08d416a5e973a90e18249078ed8e4ae2f1d5de57658738e95
>   isl-0.24.tar.bz2
> -e2a58dde1cae3e6b79c03e7ef3d888f7577c1f4cba283b3b0f31123ceea8c33d7c9700e83de57104644de23e5f5c374868caa0e091f9c45edbbe87b98ee51c04
>   gettext-0.22.tar.gz
> +3b684c9bcb9ede2b7e54d0ba4c9764bfa17c20d4f317c553b6f1e135b536949580ff37341680c25dc236cfe0ba1db8cfdfe619ce013656189ef0871b89f8
>   gmp-6.3.0.tar.bz2
> +c81842532ecc663348deb7400d911ad71933d3b525a2f9e5adcd04265c9c0fdd1f22eca229f482703ac7f222ef209fc9e339dd1fa47d72ae57f7f70b2336a76f
>   mpfr-4.2.1.tar.bz2
> +4bab4ef6076f8c5dfdc99d810b51108ced61ea2942ba0c1c932d624360a5473df20d32b300fc76f2ba4aa2a97e1f275c9fd494a1ba9f07c4cb2ad7ceaeb1ae97
>   mpc-1.3.1.tar.gz
> +492deba2cbfc693efb41621861a0679390becf2777e32111aceef8db1d38d772385dfd83cee14a41c930f9904549334e4d6dc2c5fce0c69e0bef9c8cf031d6b5
>   isl-0.26.tar.bz2
> +ad2fa2f69be996a637e9b51e8941a39e10050060245dcec1fe75c15b68d0ff973043c87b77e4e2830e407e3bdd040b578f8e24fd05bba43adb94eaee34001aa5
>   gettext-0.22.4.tar.gz
> --
> 2.35.3
>

[PATCH v5] libstdc++: Remove UB from month and weekday additions and subtractions.

[Cassio Neri]

The following invoke signed integer overflow (UB) [1]:

  month   + months{MAX} // where MAX is the maximum value of months::rep
  month   + months{MIN} // where MIN is the maximum value of months::rep
  month   - months{MIN} // where MIN is the minimum value of months::rep
  weekday + days  {MAX} // where MAX is the maximum value of days::rep
  weekday - days  {MIN} // where MIN is the minimum value of days::rep

For the additions to MAX, the crux of the problem is that, in libstdc++,
months::rep and days::rep are int64_t. Other implementations use int32_t, cast
operands to int64_t and perform arithmetic operations without risk of
overflowing.

For month + months{MIN}, the implementation follows the Standard's "returns
clause" and evaluates:

   modulo(static_cast(unsigned{__x}) + (__y.count() - 1), 12);

Overflow occurs when MIN - 1 is evaluated. Casting to a larger type could help
but, unfortunately again, this is not possible for libstdc++.

For the subtraction of MIN, the problem is that -MIN is not representable.

It's fair to say that the intention is for these additions/subtractions to
be performed in modulus (12 or 7) arithmetic so that no overflow is expected.

To fix these UB, this patch implements:

  template 
  unsigned __add_modulo(unsigned __x, _T __y);

  template 
  unsigned __sub_modulo(unsigned __x, _T __y);

which respectively, returns the remainder of Euclidean division of, __x + __y
and __x - __y by __d without overflowing. These functions replace

  constexpr unsigned __modulo(long long __n, unsigned __d);

which also calculates the reminder of __n, where __n is the result of the
addition or subtraction. Hence, these operations might invoke UB before __modulo
is called and thus, __modulo can't do anything to remediate the issue.

In addition to solve the UB issues, __add_modulo and __sub_modulo allow better
codegen (shorter and branchless) on x86-64 and ARM [2].

[1] https://godbolt.org/z/a9YfWdn57
[2] https://godbolt.org/z/Gh36cr7E4

libstdc++-v3/ChangeLog:

* include/std/chrono: Fix + and - for months and weekdays.
* testsuite/std/time/month/1.cc: Add constexpr tests against overflow.
* testsuite/std/time/month/2.cc: New test for extreme values.
* testsuite/std/time/weekday/1.cc: Add constexpr tests against overflow.
* testsuite/std/time/weekday/2.cc: New test for extreme values.
---
Good for trunk?

Changes with respect to previous versions:
  v5: Fix typos in commit message.
  v4: Remove UB also from operator-.
  v3: Fix screwed up email send with v2.
  v2: Replace _T with _Tp and _U with _Up. Remove copyright+license from test.

 libstdc++-v3/include/std/chrono  | 79 +---
 libstdc++-v3/testsuite/std/time/month/1.cc   | 19 +
 libstdc++-v3/testsuite/std/time/month/2.cc   | 32 
 libstdc++-v3/testsuite/std/time/weekday/1.cc | 16 +++-
 libstdc++-v3/testsuite/std/time/weekday/2.cc | 32 
 5 files changed, 151 insertions(+), 27 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/std/time/month/2.cc
 create mode 100644 libstdc++-v3/testsuite/std/time/weekday/2.cc

diff --git a/libstdc++-v3/include/std/chrono b/libstdc++-v3/include/std/chrono
index e4ba6eafceb..1b7cdb96e1c 100644
--- a/libstdc++-v3/include/std/chrono
+++ b/libstdc++-v3/include/std/chrono
@@ -501,18 +501,47 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

 namespace __detail
 {
-  // Compute the remainder of the Euclidean division of __n divided by __d.
-  // Euclidean division truncates toward negative infinity and always
-  // produces a remainder in the range of [0,__d-1] (whereas standard
-  // division truncates toward zero and yields a nonpositive remainder
-  // for negative __n).
+  // Helper to __add_modulo and __sub_modulo.
+  template 
+  constexpr auto
+  __modulo_offset()
+  {
+   using _Up = make_unsigned_t<_Tp>;
+   auto constexpr __a = _Up(-1) - _Up(255 + __d - 2);
+   auto constexpr __b = _Up(__d * (__a / __d) - 1);
+   // Notice: b <= a - 1 <= _Up(-1) - (255 + d - 1) and b % d = d - 1.
+   return _Up(-1) - __b; // >= 255 + d - 1
+  }
+
+  // Compute the remainder of the Euclidean division of __x + __y divided 
by
+  // __d without overflowing.  Typically, __x <= 255 + d - 1 is sum of
+  // weekday/month with a shift in [0, d - 1] and __y is a duration count.
+  template 
+  constexpr unsigned
+  __add_modulo(unsigned __x, _Tp __y)
+  {
+   using _Up = make_unsigned_t<_Tp>;
+   // For __y >= 0, _Up(__y) has the same mathematical value as __y and
+   // this function simply returns (__x + _Up(__y)) % d.  Typically, this
+   // doesn't overflow since the range of _Up contains many more positive
+   // values than _Tp's.  For __y < 0, _Up(__y) has a mathematical value in
+   // the upper-half range of _Up so that adding a positive value to it
+   // might overflow.  Moreover, most likely, _Up(__y) != 

[Bug tree-optimization/110062] missed vectorization in graphicsmagick

[hubicka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110062

--- Comment #11 from Jan Hubicka  ---
trunk -O3 -flto -march=native -fopenmp
Operation: Sharpen:
257
256
256

Average: 256 Iterations Per Minute
GCC13 -O3 -flto -march=native -fopenmp
257
256
256

Average: 256 Iterations Per Minute
clang17 O3 -flto -march=native -fopenmp
   Operation: Sharpen:
257
256
256
Average: 256 Iterations Per Minute

So I guess I will need to try on zen3 to see if there is any difference.

the internal loop is:
  0.00 │460:┌─→movzbl  0x2(%rdx,%rax,4),%esi ▒
  0.02 ││  vmovss  (%r8,%rax,4),%xmm2▒
  0.95 ││  vcvtsi2ss   %esi,%xmm0,%xmm1  ▒
 20.22 ││  movzbl  0x1(%rdx,%rax,4),%esi ▒
  0.01 ││  vfmadd231ss %xmm1,%xmm2,%xmm3 ▒
 11.97 ││  vcvtsi2ss   %esi,%xmm0,%xmm1  ▒
 18.76 ││  movzbl  (%rdx,%rax,4),%esi▒
  0.00 ││  inc %rax  ▒
  0.72 ││  vfmadd231ss %xmm1,%xmm2,%xmm4 ▒
 12.55 ││  vcvtsi2ss   %esi,%xmm0,%xmm1  ▒
 14.95 ││  vfmadd231ss %xmm1,%xmm2,%xmm5 ▒
 15.93 │├──cmp %rax,%r13 ▒
  0.35 │└──jne 460  

so it still does not get

Re: [wwwdocs][patch][OpenMP] gcc-14/changes.html + projects/gomp/: OpenMP update

[Tobias Burnus]

Gerald Pfeifer wrote:

On Fri, 24 Nov 2023, Tobias Burnus wrote:

While I expect more changes, I want to cleanup my stashed changes.


Good approach!

+  The destory now optionally accepts the depend object as
+  argument.

Is "depend object" a well known technical term in that context? And is it
"the depend object" or "a depend object"?


In this context is well known; the 'destroy' clause only exists for the
'depobj' directive and the still unimplemented 'interop' directive.

In OpenMP 5.1, the syntax was:

omp_depend_t obj;
#pragma omp depobj(obj) destroy

In OpenMP draft 6.0 (TR11/T12):

#pragma omp depobj(obj) destroy(obj)

In OpenMP 5.2, both are variants valid (deprecating the 5.1 syntax).
As there is only a single depend object 'obj' per directive, even when
specified twice, I think talking about "the" makes sense.

(I opened a specification issue discuss about avoiding the duplication - 
and to clarify a couple of other issues related to 'destroy'.)


Tobias

[Bug target/109811] libjxl 0.7 is a lot slower in GCC 13.1 vs Clang 16

[hubicka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811

--- Comment #18 from Jan Hubicka  ---
I made a typo:

Mainline with -O2 -flto  -march=native run manually since build machinery patch
is needed
23.03
22.85
23.04

Should be 
Mainline with -O3 -flto  -march=native run manually since build machinery patch
is needed
23.03
22.85
23.04

So with -O2 we still get slightly lower score than clang with -O3 we are
slightly better. push_back inlining does not seem to be a problem (as tested by
increasing limits) so perhaps more agressive unrolling/vectorization settings
clang has at -O2.

I think upstream jpegxl should use -O3 or -Ofast instead of -O2.  It is quite
typical kind of task that benefits from large optimization levels.

I filled in https://github.com/libjxl/libjxl/issues/2970

[pushed] doc: Complete and sort the list of front ends

[Gerald Pfeifer]

gcc:

PR other/69374
* doc/install.texi (Downloading the source): Sort the list of
front ends and add D, Go, and Modula-2.
---
 gcc/doc/install.texi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 9a5a7b5bb7d..c1ccb8ba02d 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -628,9 +628,9 @@ HTTPS as tarballs compressed with @command{gzip} or 
@command{bzip2}.
 Please refer to the @uref{https://gcc.gnu.org/releases.html,,releases web page}
 for information on how to obtain GCC@.
 
-The source distribution includes the C, C++, Objective-C, Fortran,
-and Ada (in the case of GCC 3.1 and later) compilers, as well as
-runtime libraries for C++, Objective-C, and Fortran.
+The source distribution includes the Ada, C, C++, Objective-C, D (GCC 9
+and later), Fortran, Go, and Modula-2 (GCC 13 and later) compilers, as
+well as runtime libraries for C++, Objective-C, and Fortran.
 For previous versions these were downloadable as separate components such
 as the core GCC distribution, which included the C language front end and
 shared components, and language-specific distributions including the
-- 
2.42.1

[Bug target/69374] install.texi is bit-rotten

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69374

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Gerald Pfeifer :

https://gcc.gnu.org/g:9c26c91b94eb72397a4892b28022070a33636492

commit r14-5844-g9c26c91b94eb72397a4892b28022070a33636492
Author: Gerald Pfeifer 
Date:   Sat Nov 25 14:10:25 2023 +0100

doc: Complete and sort the list of front ends

gcc:

PR other/69374
* doc/install.texi (Downloading the source): Sort the list of
front ends and add D, Go, and Modula-2.

[pushed] doc: Remove obsolete notes on GCC 4.x on FreeBSD

[Gerald Pfeifer]

FreeBSD 6 and 7 have been end of life for years as have been GCC 4.x
releases, so no point in detailing specifics of changes around those.

gcc:

PR target/69374
* doc/install.texi (Specific) <*-*-freebsd*>: Remove older
contents referencing GCC 4.x.
---
 gcc/doc/install.texi | 8 
 1 file changed, 8 deletions(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index b515cd1469f..9a5a7b5bb7d 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -4126,14 +4126,6 @@ This configuration is intended for embedded systems.
 @end html
 @anchor{x-x-freebsd}
 @heading *-*-freebsd*
-In order to better utilize FreeBSD base system functionality and match
-the configuration of the system compiler, GCC 4.5 and above as well as
-GCC 4.4 past 2010-06-20 leverage SSP support in libc (which is present
-on FreeBSD 7 or later) and the use of @code{__cxa_atexit} by default
-(on FreeBSD 6 or later).  The use of @code{dl_iterate_phdr} inside
-@file{libgcc_s.so.1} and boehm-gc (on FreeBSD 7 or later) is enabled
-by GCC 4.5 and above.
-
 We support FreeBSD using the ELF file format with DWARF 2 debugging
 for all CPU architectures.  There are
 no known issues with mixing object files and libraries with different
-- 
2.42.1

[Bug target/69374] install.texi is bit-rotten

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69374

--- Comment #2 from CVS Commits  ---
The trunk branch has been updated by Gerald Pfeifer :

https://gcc.gnu.org/g:f7df9d7aca6b7978ad4c08ee24267787a805a301

commit r14-5843-gf7df9d7aca6b7978ad4c08ee24267787a805a301
Author: Gerald Pfeifer 
Date:   Sat Nov 25 13:31:22 2023 +0100

doc: Remove obsolete notes on GCC 4.x on FreeBSD

FreeBSD 6 and 7 have been end of life for years as have been GCC 4.x
releases, so no point in detailing specifics of changes around those.

gcc:

PR target/69374
* doc/install.texi (Specific) <*-*-freebsd*>: Remove older
contents referencing GCC 4.x.

Re: [PATCH] rs6000: Canonicalize copysign (x, -1) back to -abs (x) in the backend [PR112606]

[Jakub Jelinek]

On Sat, Nov 25, 2023 at 12:03:56PM +, Tamar Christina wrote:
> For the C99 versions of copysign, expand_COPYSIGN has optimized expansions 
> inplace.
> One of the hooks there forces it to abs/neg.  There is also  code in place 
> for if the target
> prefers integer expansion over floating point one etc.

I thought the simplify-rtx.cc canonicalization of copysign (x, negative) to
(neg (abs ()) was disabled shortly after your change.

> However the issue here is that IFNs at the moment only support direct 
> expansion.  That is, you need an optab to get the
> rewriting done.  So you have a catch 22, unlike the C99 versions which have a 
> libcall fallback.

For POPCOUNT I've introduced recently a way to provide custom expand_*
function and decide there what optimizations to use, even when it otherwise
is an integral unary optab ifn.

Jakub

RE: [PATCH] rs6000: Canonicalize copysign (x, -1) back to -abs (x) in the backend [PR112606]

[Tamar Christina]

> -Original Message-
> From: Xi Ruoyao 
> Sent: Saturday, November 25, 2023 10:43 AM
> To: Jakub Jelinek ; Segher Boessenkool
> ; David Edelsohn 
> Cc: gcc-patches@gcc.gnu.org; Tamar Christina ;
> Andrew Pinski 
> Subject: Re: [PATCH] rs6000: Canonicalize copysign (x, -1) back to -abs (x) in
> the backend [PR112606]
> 
> On Sat, 2023-11-25 at 11:17 +0100, Jakub Jelinek wrote:
> > The middle-end has been changed quite recently to canonicalize -abs
> > (x) to copysign (x, -1) rather than the other way around.
> > While I agree with that at GIMPLE level, since it matches the GIMPLE
> > goal of as few operations as possible for a canonical form (-abs (x)
> > is 2 GIMPLE statements, copysign (x, -1) is just one), I must say I
> > don't really like that being done on RTL as well (or at least not
> > canonicalizing (COPYSIGN x, negative) back to (NEG (ABS x))), because
> > on most targets most of floating point constants need to be loaded
> > from memory, there are a few exceptions but -1 is often not one of them.
> 
> On LoongArch fneg+fabs is even slower than loading a -1 from mem then do
> copysign for some micro-architectural reason I don't know.  (FWIW on
> LoongArch with LSX, the fastest way may be directly setting the sign bit with
> LSX vbitseti instruction - it will also set the sign bits for "junk" elements 
> in the
> high bits of the vector register but there is no
> harm.)
> 
> Can we make a target hook to control this?

There already is.  I have been looking into this and this is the situation:

For the C99 versions of copysign, expand_COPYSIGN has optimized expansions 
inplace.
One of the hooks there forces it to abs/neg.  There is also  code in place for 
if the target
prefers integer expansion over floating point one etc.

There are several problems with it though, IFN expansions don't go through 
expand_COPYSIGN,
So copysignf (x, -1.f) and IFN_COPYSIGN (x, -1.f) are not treated the same, 
even though
Operationally they are.

The expansion also doesn't work for vector types, i.e. it's only doing it for 
types which have a C99
version of copysign.

match.pd has an unofficial "canonicalized" form for integer copysign, and 
expand_COPYSIGN expands
to a different one.  So most targets deal with the ones match.pd generate 
efficiently but not expand_COPYSIGNs.

All the optimizations only happen if the target does not implement the copysign 
optab.  Once you do, it's all up to you.

So even if we use expand_COPYSIGN for scalar expansions of IFN_COPYSIGN PPC 
would still need to reject the -1 case
or remove the optab and use combine to form the copysign instruction.

However the issue here is that IFNs at the moment only support direct 
expansion.  That is, you need an optab to get the
rewriting done.  So you have a catch 22, unlike the C99 versions which have a 
libcall fallback.

I have a patch locally that adds support for non-direct IFN expansions by 
providing hooks that a target can
Implement should they want to handle expansion or control which optimizations 
happen.  The patch also treats IFN and
C99 copysign the same, in that since we know we can always lower them to either 
equivalant integer or fp operations
we always allow the rewriting.

This allows most targets to just be able to remove the copysign optab 
implementation and get the same or better code than
before.

It's not a terribly big patch, but I missed stage 1 deadline and was unsure 
It's suitable for stage 3. It does fix years of copysign
issues once and for all though.

If maintainers want to see the patch I can finish regtesting and post it next 
week.

Cheers,
Tamar

> 
> --
> Xi Ruoyao 
> School of Aerospace Science and Technology, Xidian University

[Bug middle-end/112710] New: [13/14 Regression] ICE: in write_type, at cp/mangle.cc:2226 with -fdump-go-spec=filename -flto -fno-use-linker-plugin

[zsojka at seznam dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112710

Bug ID: 112710
   Summary: [13/14 Regression] ICE: in write_type, at
cp/mangle.cc:2226 with -fdump-go-spec=filename -flto
-fno-use-linker-plugin
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 56686
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56686=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -fdump-go-spec=filename -flto -fno-use-linker-plugin
testcase.C -w
testcase.C:2:6: internal compiler error: in write_type, at cp/mangle.cc:2226
2 | void foo(const bool *);
  |  ^~~
0x761ff3 write_type
/repo/gcc-trunk/gcc/cp/mangle.cc:2226
0xfcec7d write_type
/repo/gcc-trunk/gcc/cp/mangle.cc:2398
0xfd087e write_method_parms
/repo/gcc-trunk/gcc/cp/mangle.cc:2880
0xfd0a97 write_bare_function_type
/repo/gcc-trunk/gcc/cp/mangle.cc:2816
0xfd0c2c write_mangled_name
/repo/gcc-trunk/gcc/cp/mangle.cc:810
0xfd1410 mangle_decl_string
/repo/gcc-trunk/gcc/cp/mangle.cc:4092
0xfd15fa get_mangled_id
/repo/gcc-trunk/gcc/cp/mangle.cc:4113
0xfd15fa mangle_decl(tree_node*)
/repo/gcc-trunk/gcc/cp/mangle.cc:4151
0x1acb60d decl_assembler_name(tree_node*)
/repo/gcc-trunk/gcc/tree.cc:719
0x14a2f8d go_output_fndecl
/repo/gcc-trunk/gcc/godump.cc:1109
0x14a2f8d go_finish
/repo/gcc-trunk/gcc/godump.cc:1408
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-5841-20231125103155-g9866c98e101-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-5841-20231125103155-g9866c98e101-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231125 (experimental) (GCC)

Re: [PATCH] [gcc-wwwdocs]gcc-13/14: Mention Intel new ISA and march support

[Gerald Pfeifer]

On Mon, 17 Jul 2023, Haochen Jiang via Gcc-patches wrote:
>GCC now supports the Intel CPU named Granite Rapids through
>  -march=graniterapids.
> +The switch enables the AMX-FP16, PREFETCHI ISA extensions.

Do I understand correclty that it enables AMX-FP16 and PREFETCHI?

How about changing this to use "and", as in
  "The switch enables the AMX-FP16, PREFETCHI ISA extensions."
?

Let me know, and I can make the change.

Gerald

[PATCH] Update GMP/MPFR/MPC/ISL/gettext to latest release

[Sebastian Huber]

contrib/ChangeLog

* download_prerequisites: Update to gmp-6.3.0, mpfr-4.2.1,
mpc-1.3.1, isl-0.26, and gettext-0.22.4.
* prerequisites.md5: Update hash.
* prerequisites.sha512: Likewise.
---
 contrib/download_prerequisites | 10 +-
 contrib/prerequisites.md5  | 10 +-
 contrib/prerequisites.sha512   | 10 +-
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/contrib/download_prerequisites b/contrib/download_prerequisites
index 9568091c0dba..b9deab316917 100755
--- a/contrib/download_prerequisites
+++ b/contrib/download_prerequisites
@@ -27,11 +27,11 @@ version='(unversioned)'
 # remember to also update the files `contrib/prerequisites.sha512` and
 # `contrib/prerequisites.md5` with the new checksums.
 
-gmp='gmp-6.2.1.tar.bz2'
-mpfr='mpfr-4.1.0.tar.bz2'
-mpc='mpc-1.2.1.tar.gz'
-isl='isl-0.24.tar.bz2'
-gettext='gettext-0.22.tar.gz'
+gmp='gmp-6.3.0.tar.bz2'
+mpfr='mpfr-4.2.1.tar.bz2'
+mpc='mpc-1.3.1.tar.gz'
+isl='isl-0.26.tar.bz2'
+gettext='gettext-0.22.4.tar.gz'
 
 base_url='http://gcc.gnu.org/pub/gcc/infrastructure/'
 
diff --git a/contrib/prerequisites.md5 b/contrib/prerequisites.md5
index 716a9ff910c7..2ccff4a4c44f 100644
--- a/contrib/prerequisites.md5
+++ b/contrib/prerequisites.md5
@@ -1,5 +1,5 @@
-28971fc21cf028042d4897f02fd355ea  gmp-6.2.1.tar.bz2
-44b892bc5a45bafb4294d134e13aad1d  mpfr-4.1.0.tar.bz2
-9f16c976c25bb0f76b50be749cd7a3a8  mpc-1.2.1.tar.gz
-dd2f7b78e118c25bd96134a52aae7f4d  isl-0.24.tar.bz2
-c092102240f8f66134d22718421d5115  gettext-0.22.tar.gz
+c1cd6ef33085e9cb818b9b08371f9000  gmp-6.3.0.tar.bz2
+7765afa036e4ce7fb0e02bce0fef894b  mpfr-4.2.1.tar.bz2
+5c9bc658c9fd0f940e8e3e0f09530c62  mpc-1.3.1.tar.gz
+da50c85e9841db36d48a492bbe836863  isl-0.26.tar.bz2
+e541ba3603674a853cff9b28a68dd61e  gettext-0.22.4.tar.gz
diff --git a/contrib/prerequisites.sha512 b/contrib/prerequisites.sha512
index f71398bdbc31..9bc9ce468fdc 100644
--- a/contrib/prerequisites.sha512
+++ b/contrib/prerequisites.sha512
@@ -1,5 +1,5 @@
-8904334a3bcc5c896ececabc75cda9dec642e401fb5397c4992c4fabea5e962c9ce8bd44e8e4233c34e55c8010cc28db0545f5f750cbdbb5f00af538dc763be9
  gmp-6.2.1.tar.bz2
-410208ee0d48474c1c10d3d4a59decd2dfa187064183b09358ec4c4666e34d74383128436b404123b831e585d81a9176b24c7ced9d913967c5fce35d4040a0b4
  mpfr-4.1.0.tar.bz2
-3279f813ab37f47fdcc800e4ac5f306417d07f539593ca715876e43e04896e1d5bceccfb288ef2908a3f24b760747d0dbd0392a24b9b341bc3e12082e5c836ee
  mpc-1.2.1.tar.gz
-aab3bddbda96b801d0f56d2869f943157aad52a6f6e6a61745edd740234c635c38231af20bc3f1a08d416a5e973a90e18249078ed8e4ae2f1d5de57658738e95
  isl-0.24.tar.bz2
-e2a58dde1cae3e6b79c03e7ef3d888f7577c1f4cba283b3b0f31123ceea8c33d7c9700e83de57104644de23e5f5c374868caa0e091f9c45edbbe87b98ee51c04
  gettext-0.22.tar.gz
+3b684c9bcb9ede2b7e54d0ba4c9764bfa17c20d4f317c553b6f1e135b536949580ff37341680c25dc236cfe0ba1db8cfdfe619ce013656189ef0871b89f8
  gmp-6.3.0.tar.bz2
+c81842532ecc663348deb7400d911ad71933d3b525a2f9e5adcd04265c9c0fdd1f22eca229f482703ac7f222ef209fc9e339dd1fa47d72ae57f7f70b2336a76f
  mpfr-4.2.1.tar.bz2
+4bab4ef6076f8c5dfdc99d810b51108ced61ea2942ba0c1c932d624360a5473df20d32b300fc76f2ba4aa2a97e1f275c9fd494a1ba9f07c4cb2ad7ceaeb1ae97
  mpc-1.3.1.tar.gz
+492deba2cbfc693efb41621861a0679390becf2777e32111aceef8db1d38d772385dfd83cee14a41c930f9904549334e4d6dc2c5fce0c69e0bef9c8cf031d6b5
  isl-0.26.tar.bz2
+ad2fa2f69be996a637e9b51e8941a39e10050060245dcec1fe75c15b68d0ff973043c87b77e4e2830e407e3bdd040b578f8e24fd05bba43adb94eaee34001aa5
  gettext-0.22.4.tar.gz
-- 
2.35.3

Re: [patch][GCN] install.texi: Update GCN entry - @uref and LLVM version remark

[Gerald Pfeifer]

On Fri, 24 Nov 2023, Tobias Burnus wrote:
> Stumbled over this.

Same here. :-)

> Comments?

Thank you for fixing this.

Gerald

[pushed] doc: Update ISO C++ reference

[Gerald Pfeifer]

http->https it is, once again.

Gerald


gcc:

* doc/standards.texi (Standards): Update ISO C++ reference.
---
 gcc/doc/standards.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/standards.texi b/gcc/doc/standards.texi
index 6eebb9426f3..4b18fa91289 100644
--- a/gcc/doc/standards.texi
+++ b/gcc/doc/standards.texi
@@ -240,7 +240,7 @@ new specification.  For further details see
 To select this standard in GCC, use the option @option{-std=c++20}.
 
 More information about the C++ standards is available on the ISO C++
-committee's web site at @uref{http://www.open-std.org/@/jtc1/@/sc22/@/wg21/}.
+committee's web site at @uref{https://www.open-std.org/@/jtc1/@/sc22/@/wg21/}.
 
 To obtain all the diagnostics required by any of the standard versions
 described above you should specify @option{-pedantic}
-- 
2.42.1

Re: [PATCH] rs6000: Canonicalize copysign (x, -1) back to -abs (x) in the backend [PR112606]

[Xi Ruoyao]

On Sat, 2023-11-25 at 11:17 +0100, Jakub Jelinek wrote:
> The middle-end has been changed quite recently to canonicalize
> -abs (x) to copysign (x, -1) rather than the other way around.
> While I agree with that at GIMPLE level, since it matches the GIMPLE
> goal of as few operations as possible for a canonical form (-abs (x)
> is 2 GIMPLE statements, copysign (x, -1) is just one), I must say
> I don't really like that being done on RTL as well (or at least
> not canonicalizing (COPYSIGN x, negative) back to (NEG (ABS x))),
> because on most targets most of floating point constants need to be loaded
> from memory, there are a few exceptions but -1 is often not one of them.

On LoongArch fneg+fabs is even slower than loading a -1 from mem then do
copysign for some micro-architectural reason I don't know.  (FWIW on
LoongArch with LSX, the fastest way may be directly setting the sign bit
with LSX vbitseti instruction - it will also set the sign bits for
"junk" elements in the high bits of the vector register but there is no
harm.)

Can we make a target hook to control this?

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

[Bug target/109812] GraphicsMagick resize is a lot slower in GCC 13.1 vs Clang 16 on Intel Raptor Lake

[liuhongt at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812

liuhongt at gcc dot gnu.org changed:

   What|Removed |Added

 CC||liuhongt at gcc dot gnu.org

--- Comment #21 from liuhongt at gcc dot gnu.org ---
The main gap is from openmp for hybrid machine.

[PATCH] rs6000: Canonicalize copysign (x, -1) back to -abs (x) in the backend [PR112606]

[Jakub Jelinek]

Hi!

The middle-end has been changed quite recently to canonicalize
-abs (x) to copysign (x, -1) rather than the other way around.
While I agree with that at GIMPLE level, since it matches the GIMPLE
goal of as few operations as possible for a canonical form (-abs (x)
is 2 GIMPLE statements, copysign (x, -1) is just one), I must say
I don't really like that being done on RTL as well (or at least
not canonicalizing (COPYSIGN x, negative) back to (NEG (ABS x))),
because on most targets most of floating point constants need to be loaded
from memory, there are a few exceptions but -1 is often not one of them.

Anyway, the following patch fixes the rs6000 regression caused by the
change in GIMPLE canonicalization (i.e. the desirable one).  As rs6000
clearly prefers -abs (x) form because it has a single instruction to do
that while it also has copysign instruction, but that requires loading the
-1 from memory, the following patch just ensures the copysign expander
can actually see the floating point constant and in that case emits the
-abs (x) code (or in the hypothetical case of copysign with non-negative
constant abs (x) - but there copysign (x, 1) in GIMPLE is canonicalized
to abs (x)), otherwise forces the operand to be the expected gpc_reg_operand
and does what it did before.

Bootstrapped/regtested on powerpc64le-linux, ok for trunk?

2023-11-25  Jakub Jelinek  

PR target/112606
* config/rs6000/rs6000.md (copysign3): Change predicate
of the last argument from gpc_reg_operand to any_operand.  If
operands[2] is CONST_DOUBLE, emit abs or neg abs depending on
its sign, otherwise if it doesn't satisfy gpc_reg_operand,
force it to REG using copy_to_mode_reg.

--- gcc/config/rs6000/rs6000.md.jj  2023-10-13 19:34:43.927834877 +0200
+++ gcc/config/rs6000/rs6000.md 2023-11-24 18:54:13.587876170 +0100
@@ -5358,7 +5358,7 @@ (define_expand "copysign3"
(set (match_dup 4)
(neg:SFDF (abs:SFDF (match_dup 1
(set (match_operand:SFDF 0 "gpc_reg_operand")
-(if_then_else:SFDF (ge (match_operand:SFDF 2 "gpc_reg_operand")
+   (if_then_else:SFDF (ge (match_operand:SFDF 2 "any_operand")
   (match_dup 5))
 (match_dup 3)
 (match_dup 4)))]
@@ -5369,6 +5369,24 @@ (define_expand "copysign3"
|| TARGET_CMPB
|| VECTOR_UNIT_VSX_P (mode))"
 {
+  /* Middle-end canonicalizes -fabs (x) to copysign (x, -1),
+ but PowerPC prefers -fabs (x).  */
+  if (CONST_DOUBLE_AS_FLOAT_P (operands[2]))
+{
+  if (real_isneg (CONST_DOUBLE_REAL_VALUE (operands[2])))
+   {
+ operands[3] = gen_reg_rtx (mode);
+ emit_insn (gen_abs2 (operands[3], operands[1]));
+ emit_insn (gen_neg2 (operands[0], operands[3]));
+   }
+  else
+   emit_insn (gen_abs2 (operands[0], operands[1]));
+  DONE;
+}
+
+  if (!gpc_reg_operand (operands[2], mode))
+operands[2] = copy_to_mode_reg (mode, operands[2]);
+
   if (TARGET_CMPB || VECTOR_UNIT_VSX_P (mode))
 {
   emit_insn (gen_copysign3_fcpsgn (operands[0], operands[1],

Jakub

Re: [PATCH] Fix gcc.target/aarch64/movk.c testcase after IPA-VRP improvement for return values

[Richard Sandiford]

Andrew Pinski  writes:
> This fixes the testcase.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.target/aarch64/movk.c: Add noipa on dummy_number_generator
>   and remove -fno-inline option.
>
> Signed-off-by: Andrew Pinski 

OK, thanks.

Richard

> ---
>  gcc/testsuite/gcc.target/aarch64/movk.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.target/aarch64/movk.c 
> b/gcc/testsuite/gcc.target/aarch64/movk.c
> index e6e4e3a8961..1fa11540c6c 100644
> --- a/gcc/testsuite/gcc.target/aarch64/movk.c
> +++ b/gcc/testsuite/gcc.target/aarch64/movk.c
> @@ -1,8 +1,11 @@
>  /* { dg-do run } */
> -/* { dg-options "-O2 --save-temps -fno-inline" } */
> +/* { dg-options "-O2 --save-temps" } */
>  
>  extern void abort (void);
>  
> +/* Note GCC can optimize this to -346565474575675 even without inlining so
> +   mark it for noipa.  */
> +[[gnu::noipa]]
>  long long int
>  dummy_number_generator ()
>  {

[Bug fortran/100651] [11/12/13/14 Regression] Weird memory corruption with multiple triggers

[fxcoudert at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100651

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org
   Last reconfirmed|2021-07-29 00:00:00 |2023-11-25
 Target|x86_64-linux-gnu,   |
   |x86_64-apple-darwin |

--- Comment #10 from Francois-Xavier Coudert  ---
Further reduced to this:

meau /tmp $ cat a.f90
program main
  character(:), allocatable :: err_msg
  call to_int(err_msg)
  print *, 'allocated :', allocated(err_msg)
  print *, err_msg(1:7)
  print *, 'len :  ', len(err_msg)
  print *, 'err_msg :  ', err_msg
contains
  subroutine assert_code(err_msg)
character(:), optional, allocatable :: err_msg
err_msg = 'foo bar'
  end
  subroutine to_int(err_msg)
character(:), optional, allocatable :: err_msg
call assert_code(err_msg)
  end
end
meau /tmp $ gfortran a.f90 -O0 -g && ./a.out
 allocated : T
 foo bar
 len :  39026212
Operating system error: Cannot allocate memory
Memory allocation failure in xrealloc


The problem is in the code generated for the to_int subroutine, handling the
optional aspect. We can see above that the string is allocated and set
correctly. However, the length is not correctly set. You can see from the dump:

__attribute__((fn spec (". w ")))
void to_int (character(kind=1)[1:*_err_msg] * * err_msg, integer(kind=8) *
_err_msg)
{
  {
character(kind=1)[1:*_err_msg] * * D.3001;
integer(kind=8) D.3002;

D.3001 = err_msg != 0B ? err_msg : 0B;
D.3002 = err_msg != 0B ? *_err_msg : 0;
assert_code (D.3001, );
  }
}

The string length passed as second argument to assert_code is a pointer to a
local variable, and its value will not be propagated back into _err_msg (the
string length passed to to_int).

[Bug ipa/110334] [13/14 Regresssion] unused functions not eliminated before LTO streaming

[egallager at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #26 from Eric Gallager  ---
(In reply to Richard Biener from comment #20)
> Unfortunately there isn't a knob to diagnose late inlined always-inline
> functions.

Is there a separate bug for this?

[pushed] wwwdocs: readings: Update OpenPOWER link

[Gerald Pfeifer]

This is the original patch and a follow-up to fix an embarrassing markup 
mistake.

Gerald


commit 17418f262b17680a07a4493631aa0743b5fe9780
Author: Gerald Pfeifer 
Date:   Fri Nov 24 09:33:26 2023 +0100

readings: Update OpenPOWER link

The original link now redirects to a very generic page; refer to the
OpenPOWER Foundation instead.

diff --git a/htdocs/readings.html b/htdocs/readings.html
index 26f2af7a..90ad35d9 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -269,7 +269,7 @@ names.
  
  rs6000 (powerpc, powerpcle)
   Manufacturer: IBM, Motorola
-  https://www.ibm.com/systems/power/openpower/;>Power ISA
+  https://openpowerfoundation.org>OpenPOWER Foundation
   https://openpowerfoundation.org/?resource_lib=64-bit-elf-v2-abi-specification-power-architecture;>64-Bit
 ELF V2 ABI - OpenPOWER ABI
   https://www.ibm.com/docs/en/ssw_aix_72/assembler/assembler_pdf.pdf;>AIX 
7.2 Assembler Language Reference
  

commit ed16b71d535241fab09e85991dbaf7896524c72e
Author: Gerald Pfeifer 
Date:   Sat Nov 25 10:45:23 2023 +0100

readings: Fix markup around OpenPOWER

diff --git a/htdocs/readings.html b/htdocs/readings.html
index 90ad35d9..2e320945 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -269,7 +269,7 @@ names.
  
  rs6000 (powerpc, powerpcle)
   Manufacturer: IBM, Motorola
-  https://openpowerfoundation.org>OpenPOWER Foundation
+  https://openpowerfoundation.org;>OpenPOWER Foundation
   https://openpowerfoundation.org/?resource_lib=64-bit-elf-v2-abi-specification-power-architecture;>64-Bit
 ELF V2 ABI - OpenPOWER ABI
   https://www.ibm.com/docs/en/ssw_aix_72/assembler/assembler_pdf.pdf;>AIX 
7.2 Assembler Language Reference
  

[PATCH] Emit funcall external declarations only if actually used.

[Jose E. Marchesi]

There are many places in GCC where alternative local sequences are
tried in order to determine what is the cheapest or best alternative
to use in the current target.  When any of these sequences involve a
libcall, the current implementation of emit_library_call_value_1
introduce a side-effect consisting on emitting an external declaration
for the funcall (such as __divdi3) which is thus emitted even if the
sequence that does the libcall is not retained.

This is problematic in targets such as BPF, because the kernel loader
chokes on the spurious symbol __divdi3 and makes the resulting BPF
object unloadable.  Note that BPF objects are not linked before being
loaded.

This patch changes asssemble_external_libcall to defer emitting
declarations of external libcall symbols, by saving the call tree
nodes in a temporary list pending_libcall_symbols and letting
process_pending_assembly_externals to emit them only if they have been
referenced.  Solution suggested and sketched by Richard Sandiford.

Regtested in x86_64-linux-gnu.
Tested with host x86_64-linux-gnu with target bpf-unknown-none.

gcc/ChangeLog

* varasm.cc (pending_libcall_symbols): New variable.
(process_pending_assemble_externals): Process
pending_libcall_symbols.
(assemble_external_libcall): Defer emitting external libcall
symbols to process_pending_assemble_externals.

gcc/testsuite/ChangeLog

* gcc.target/bpf/divmod-libcall-1.c: New test.
* gcc.target/bpf/divmod-libcall-2.c: Likewise.
* gcc.c-torture/compile/libcall-2.c: Likewise.
---
 .../gcc.c-torture/compile/libcall-2.c |  8 +++
 .../gcc.target/bpf/divmod-libcall-1.c | 19 
 .../gcc.target/bpf/divmod-libcall-2.c | 16 ++
 gcc/varasm.cc | 22 ++-
 4 files changed, 64 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.c-torture/compile/libcall-2.c
 create mode 100644 gcc/testsuite/gcc.target/bpf/divmod-libcall-1.c
 create mode 100644 gcc/testsuite/gcc.target/bpf/divmod-libcall-2.c

diff --git a/gcc/testsuite/gcc.c-torture/compile/libcall-2.c 
b/gcc/testsuite/gcc.c-torture/compile/libcall-2.c
new file mode 100644
index 000..b33944c83ff
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/libcall-2.c
@@ -0,0 +1,8 @@
+/* Make sure that external refences for libcalls are generated even for
+   indirect calls.  */
+
+/* { dg-do compile } */
+/* { dg-options "-O2 -mcmodel=large" { target x86_64-*-* } } */
+/* { dg-final { scan-assembler "globl\t__divti3" } } */
+
+__int128 a, b; void foo () { a = a / b; }
diff --git a/gcc/testsuite/gcc.target/bpf/divmod-libcall-1.c 
b/gcc/testsuite/gcc.target/bpf/divmod-libcall-1.c
new file mode 100644
index 000..7481076602a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/bpf/divmod-libcall-1.c
@@ -0,0 +1,19 @@
+/* This test makes sure that no spurious external symbol declarations are
+   emitted for libcalls in tried but eventually not used code sequences.  */
+
+/* { dg-do compile } */
+/* { dg-options "-O2 -mcpu=v3" } */
+/* { dg-final { scan-assembler-not "global\t__divdi3" } } */
+/* { dg-final { scan-assembler-not "global\t__moddi3" } } */
+
+int
+foo (unsigned int len)
+{
+  return ((unsigned long)len) * 234 / 5;
+}
+
+int
+bar (unsigned int len)
+{
+  return ((unsigned long)len) * 234 % 5;
+}
diff --git a/gcc/testsuite/gcc.target/bpf/divmod-libcall-2.c 
b/gcc/testsuite/gcc.target/bpf/divmod-libcall-2.c
new file mode 100644
index 000..792d689395a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/bpf/divmod-libcall-2.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mcpu=v3" } */
+/* { dg-final { scan-assembler "global\t__divdi3" } } */
+/* { dg-final { scan-assembler "global\t__moddi3" } } */
+
+int
+foo (unsigned int len)
+{
+  return ((long)len) * 234 / 5;
+}
+
+int
+bar (unsigned int len)
+{
+  return ((long)len) * 234 % 5;
+}
diff --git a/gcc/varasm.cc b/gcc/varasm.cc
index 6ae35edc5ae..deb7eab7af9 100644
--- a/gcc/varasm.cc
+++ b/gcc/varasm.cc
@@ -2461,6 +2461,10 @@ contains_pointers_p (tree type)
it all the way to final.  See PR 17982 for further discussion.  */
 static GTY(()) tree pending_assemble_externals;
 
+/* A similar list of pending libcall symbols.  We only want to declare
+   symbols that are actually used in the final assembly.  */
+static GTY(()) rtx pending_libcall_symbols;
+
 #ifdef ASM_OUTPUT_EXTERNAL
 /* Some targets delay some output to final using TARGET_ASM_FILE_END.
As a result, assemble_external can be called after the list of externals
@@ -2520,8 +2524,17 @@ process_pending_assemble_externals (void)
   for (list = pending_assemble_externals; list; list = TREE_CHAIN (list))
 assemble_external_real (TREE_VALUE (list));
 
+  for (rtx list = pending_libcall_symbols; list; list = XEXP (list, 1))
+{
+  rtx symbol = XEXP (list, 0);
+  tree id = get_identifier (XSTR (symbol, 0));
+  if 

[Bug target/111408] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since r14-2866-ge68a31549d9

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111408

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #6 from Jakub Jelinek  ---
Fixed, eventhough backports are planned (but just for latent issue).

[Bug target/109977] [14 Regression] ICE: output_operand: incompatible floating point / vector register operand for '%d' at -Og since r14-215-g85279b0bddc1c5

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109977

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #7 from Jakub Jelinek  ---
Fixed.

[Bug target/111408] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since r14-2866-ge68a31549d9

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111408

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:9866c98e1015d98b8fc346d7cf73a0070cce5f69

commit r14-5841-g9866c98e1015d98b8fc346d7cf73a0070cce5f69
Author: Jakub Jelinek 
Date:   Sat Nov 25 10:31:55 2023 +0100

i386: Fix up *jcc_bt*_mask{,_1} [PR111408]

The following testcase is miscompiled in GCC 14 because the
*jcc_bt_mask and *jcc_bt_mask_1 patterns have just
one argument in (match_operator 0 "bt_comparison_operator" [...])
but as bt_comparison_operator is eq,ne, we need two.
The md readers don't warn about it, after all, some checks can
be done in the predicate rather than specified explicitly, and the
behavior is that anything is accepted as the second argument.

I went through all other i386.md match_operator uses and all others
looked right (extract_operator using 3 operands, all others 2).

I think we'll want to fix this at different spots in older releases
because I think the bug was introduced already in 2008, though most
likely just latent.

2023-11-25  Jakub Jelinek  

PR target/111408
* config/i386/i386.md (*jcc_bt_mask,
*jcc_bt_mask_1): Add (const_int 0) as expected
second operand of bt_comparison_operator.

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

[Bug target/109977] [14 Regression] ICE: output_operand: incompatible floating point / vector register operand for '%d' at -Og since r14-215-g85279b0bddc1c5

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109977

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:a6a43a3b763816fec7c4eec6ae7be5b263dff340

commit r14-5840-ga6a43a3b763816fec7c4eec6ae7be5b263dff340
Author: Jakub Jelinek 
Date:   Sat Nov 25 10:30:39 2023 +0100

aarch64: Fix up aarch64_simd_stp [PR109977]

The aarch64_simd_stp pattern uses w constraint in one alternative and
r in another, but for the latter incorrectly uses  iterator in %1
which
expands to %d1 for V2DF and %s1 for V2SF and V4SF (this one not relevant to
the pattern) and %w1 for others, so it ICEs if the alternative is selected
during final.  Compared to this,  macro has the same values for all
modes but uses w for V2DF and V2SF.

2023-11-24  Andrew Pinski  
Jakub Jelinek  

PR target/109977
* config/aarch64/aarch64-simd.md (aarch64_simd_stp): Use

rather than % for alternative with r constraint on input
operand.

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

Re: [PATCH] i386: Fix up *jcc_bt*_mask{,_1} [PR111408]

[Uros Bizjak]

On Sat, Nov 25, 2023 at 8:19 AM Jakub Jelinek  wrote:
>
> Hi!
>
> The following testcase is miscompiled in GCC 14 because the
> *jcc_bt_mask and *jcc_bt_mask_1 patterns have just
> one argument in (match_operator 0 "bt_comparison_operator" [...])
> but as bt_comparison_operator is eq,ne, we need two.
> The md readers don't warn about it, after all, some checks can
> be done in the predicate rather than specified explicitly, and the
> behavior is that anything is accepted as the second argument.
>
> I went through all other i386.md match_operator uses and all others
> looked right (extract_operator using 3 operands, all others 2).
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> I think we'll want to fix this at different spots in older releases
> because I think the bug was introduced already in 2008, though most
> likely just latent.
>
> 2023-11-25  Jakub Jelinek  
>
> PR target/111408
> * config/i386/i386.md (*jcc_bt_mask,
> *jcc_bt_mask_1): Add (const_int 0) as expected
> second operand of bt_comparison_operator.
>
> * gcc.c-torture/execute/pr111408.c: New test.

OK, also for backports.

Thanks,
Uros.

>
> --- gcc/config/i386/i386.md.jj  2023-11-24 08:43:31.892529819 +0100
> +++ gcc/config/i386/i386.md 2023-11-24 14:26:38.645009163 +0100
> @@ -16879,7 +16879,8 @@ (define_insn_and_split "*jcc_bt_ma
>(const_int 1)
>(and:QI
>  (match_operand:QI 2 "register_operand")
> -(match_operand 3 "const_int_operand")))])
> +(match_operand 3 "const_int_operand")))
> +(const_int 0)])
>   (label_ref (match_operand 4))
>   (pc)))
> (clobber (reg:CC FLAGS_REG))]
> @@ -16915,7 +16916,8 @@ (define_insn_and_split "*jcc_bt(subreg:QI
>  (and:SWI248
>(match_operand:SWI248 2 "register_operand")
> -  (match_operand 3 "const_int_operand")) 0))])
> +  (match_operand 3 "const_int_operand")) 0))
> +(const_int 0)])
>   (label_ref (match_operand 4))
>   (pc)))
> (clobber (reg:CC FLAGS_REG))]
> --- gcc/testsuite/gcc.c-torture/execute/pr111408.c.jj   2023-11-24 
> 14:45:51.992871046 +0100
> +++ gcc/testsuite/gcc.c-torture/execute/pr111408.c  2023-11-24 
> 14:44:54.809671610 +0100
> @@ -0,0 +1,26 @@
> +/* PR target/111408 */
> +
> +int a, b, c, d;
> +short e;
> +
> +int
> +foo ()
> +{
> +  c = a % (sizeof (int) * 8);
> +  if (b & 1 << c)
> +return -1;
> +  return 0;
> +}
> +
> +int
> +main ()
> +{
> +  for (; e != 1; e++)
> +{
> +  int g = foo ();
> +  if (g + d - 9 + d)
> +   continue;
> +  for (;;)
> +   __builtin_abort ();
> +}
> +}
>
> Jakub
>

[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

[amonakov at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #9 from Alexander Monakov  ---
-mpreferred-stack-boundary=n means that functions consume stack in increments
of 2**n. This is sufficient to ensure that once stack is aligned to that
boundary, it will keep it without the need for dynamic realignment.

-mincoming-stack-boundary specifies the guaranteed alignment on entry. If the
function needs to place local variables with greater alignment requirement on
the stack, it has perform dynamic realignment.

[PATCH] RISC-V: Remove incorrect function gate gather_scatter_valid_offset_mode_p

[Juzhe-Zhong]

Come back to review the codes of gather/scatter, notice 
gather_scatter_valid_offset_mode_p looks odd.
gather_scatter_valid_offset_mode_p is supposed to block vluxei64/vsuxei64 in 
RV32 system.
However, it failed to do that since it is passing data_mode instead of index 
mode:

riscv_vector::gather_scatter_valid_offset_mode_p (mode)
It should be RATIO2I instead of RATIO2.
So we have this following iterators which already can block the this situation:

(define_mode_iterator RATIO8I [
  RVVM1QI
  RVVM2HI
  RVVM4SI
  (RVVM8DI "TARGET_VECTOR_ELEN_64 && TARGET_64BIT")
])

We can see TARGET_64BIT to block EEW64 index mode on RV32 system.
So, gather_scatter_valid_offset_mode_p is no longer needed.

After remove it, I find due to incorrect gather_scatter_valid_offset_mode_p.
We failed to vectorize such case in RV32 in the past:

#include 
#define INDEX8 int8_t
#define TEST_LOOP(DATA_TYPE, BITS) \
  void __attribute__ ((noinline, noclone)) \
  f_##DATA_TYPE (DATA_TYPE *restrict dest, DATA_TYPE *restrict src,\
 INDEX##BITS *restrict indices, INDEX##BITS *restrict cond)\
  {\
for (int i = 0; i < 128; ++i)  \
  if (cond[i]) \
dest[i] += src[indices[i]];\
  }
#define TEST_ALL(T)\
  T (int64_t, 8)
TEST_ALL (TEST_LOOP)

https://godbolt.org/z/T3ara3fM3

Checked compiler explorer, we can see GCC failed to vectorize it but Clang can 
vectorize it.

So adapt the tests checking vectorization cases from 8 -> 11.

Confirm we have same behavior as Clang now.

Tested on zvl128/zvl256/zvl512/zvl1024 no regression.

Note this is not an optimization patch, it's buggy codes fix patch.

gcc/ChangeLog:

* config/riscv/autovec.md 
(mask_len_gather_load): Remove 
gather_scatter_valid_offset_mode_p.
(mask_len_gather_load): Ditto.
(mask_len_scatter_store): Ditto.
(mask_len_scatter_store): Ditto.
* config/riscv/predicates.md (const_1_or_8_operand): New predicate.
(vector_gs_scale_operand_64): Remove.
* config/riscv/riscv-protos.h (gather_scatter_valid_offset_mode_p): 
Remove.
* config/riscv/riscv-v.cc (expand_gather_scatter): Refine code.
(gather_scatter_valid_offset_mode_p): Remove.
* config/riscv/vector-iterators.md: Fix iterator bugs.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-1.c: 
Adapt test.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-10.c: 
Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-11.c: 
Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-2.c: 
Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-3.c: 
Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-4.c: 
Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-5.c: 
Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-6.c: 
Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-7.c: 
Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-8.c: 
Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-9.c: 
Ditto.
* 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-1.c: Ditto.
* 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-10.c: Ditto.
* 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-2.c: Ditto.
* 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-3.c: Ditto.
* 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-4.c: Ditto.
* 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-5.c: Ditto.
* 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-6.c: Ditto.
* 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-7.c: Ditto.
* 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-8.c: Ditto.
* 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-9.c: Ditto.

---
 gcc/config/riscv/autovec.md   | 44 +--
 gcc/config/riscv/predicates.md|  8 ++--
 gcc/config/riscv/riscv-protos.h   |  1 -
 gcc/config/riscv/riscv-v.cc   | 17 +--
 gcc/config/riscv/vector-iterators.md  | 23 +++---
 .../gather-scatter/mask_gather_load_32-1.c|  2 +-
 .../gather-scatter/mask_gather_load_32-10.c   |  2 +-
 .../gather-scatter/mask_gather_load_32-11.c   |  2 +-