[Bug c/110789] Internal Compiler Error: Illegal instruction

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

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

--- Comment #10 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #9)
> (In reply to Andrew Pinski from comment #7)
> > If you compile GMP (MPFR and MPC) as part of GCC build rather than
> > seperately, the build will do the correct thing and not use the "native"
> > options by default.
> > 
> > 
> > You could also configure GMP using --target=none-linux-gnu
> > --host=none-linux-gnu --build=none-linux-gnu to disable that similar thing
> > (just as building GMP as part of GCC's build).
> > 
> > From Makefile.def:
> > host_modules= { module= gmp; lib_path=.libs; bootstrap=true;
> > // Work around in-tree gmp configure bug with missing flex.
> > extra_configure_flags='--disable-shared LEX="touch lex.yy.c"
> > @host_libs_picflag@';
> > extra_make_flags='AM_CFLAGS="-DNO_ASM"';
> > no_install= true;
> > // none-*-* disables asm optimizations, bootstrap-testing
> > // the compiler more thoroughly.
> > host="none-${host_vendor}-${host_os}";
> > // gmp's configure will complain if given anything
> > // different from host for target.
> > target="none-${host_vendor}-${host_os}"; };
> 
> FWIW when I try this, configure script says:
> 
> configure: WARNING: the "none" host is obsolete, use --disable-assembly
> 
> So I'll change the LFS book to use --disable-assembly instead of these fancy
> "cp configfsf" things.  Not sure if we should use --disable-assembly too for
> GCC in-tree GMP (I don't know which the first version of GMP supports
> --disable-assembly).

Nope, --disable-assembly still sets CFLAGS to -march=nehalem.  So the configure
script is lying :(.

[Bug c/110789] Internal Compiler Error: Illegal instruction

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

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

--- Comment #9 from Xi Ruoyao  ---
(In reply to Andrew Pinski from comment #7)
> If you compile GMP (MPFR and MPC) as part of GCC build rather than
> seperately, the build will do the correct thing and not use the "native"
> options by default.
> 
> 
> You could also configure GMP using --target=none-linux-gnu
> --host=none-linux-gnu --build=none-linux-gnu to disable that similar thing
> (just as building GMP as part of GCC's build).
> 
> From Makefile.def:
> host_modules= { module= gmp; lib_path=.libs; bootstrap=true;
> // Work around in-tree gmp configure bug with missing flex.
> extra_configure_flags='--disable-shared LEX="touch lex.yy.c"
> @host_libs_picflag@';
> extra_make_flags='AM_CFLAGS="-DNO_ASM"';
> no_install= true;
> // none-*-* disables asm optimizations, bootstrap-testing
> // the compiler more thoroughly.
> host="none-${host_vendor}-${host_os}";
> // gmp's configure will complain if given anything
> // different from host for target.
> target="none-${host_vendor}-${host_os}"; };

FWIW when I try this, configure script says:

configure: WARNING: the "none" host is obsolete, use --disable-assembly

So I'll change the LFS book to use --disable-assembly instead of these fancy
"cp configfsf" things.  Not sure if we should use --disable-assembly too for
GCC in-tree GMP (I don't know which the first version of GMP supports
--disable-assembly).

[Bug c++/103497] [11/12/13/14 Regression] ICE when decltype(auto)... as parameters

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

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

--- Comment #5 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r14-2814-gca912a39cccdd990ef705768faa7311ac210b3f3
Author: Nathaniel Shead 
Date:   Fri Jun 30 17:05:24 2023 +1000

c++: Fix ICE with parameter pack of decltype(auto) [PR103497]

This patch ensures 'type_uses_auto' also checks for usages of 'auto' in
parameter packs.

PR c++/103497

gcc/cp/ChangeLog:

* pt.cc (type_uses_auto): Check inside parameter packs.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/decltype-auto-103497.C: New test.

Signed-off-by: Nathaniel Shead 

[Bug target/110795] Bad code gen for vector compare booleans

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

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

Kewen Lin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
   Last reconfirmed||2023-07-27
 Ever confirmed|0   |1

--- Comment #3 from Kewen Lin  ---
I'll have a look first.

[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

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

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #11 from Kewen Lin  ---
Should be fixed on trunk.

[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Kewen Lin :

https://gcc.gnu.org/g:9890d4e8bcda1f34b8eefb481935ef0e4cd8069e

commit r14-2813-g9890d4e8bcda1f34b8eefb481935ef0e4cd8069e
Author: Kewen Lin 
Date:   Wed Jul 26 21:43:09 2023 -0500

vect: Treat VMAT_ELEMENTWISE as scalar load in costing [PR110776]

PR110776 exposes one issue that we could query unaligned
load for vector type but actually no unaligned vector load
is supported there.  The reason is that the costed load is
with single-lane vector type and its memory access type is
VMAT_ELEMENTWISE, we actually take it as scalar load and
set its alignment_support_scheme as dr_unaligned_supported.

To avoid the ICE as exposed, following Rich's suggestion,
this patch is to make VMAT_ELEMENTWISE be costed as scalar
load.

Co-authored-by: Richard Biener 

PR tree-optimization/110776

gcc/ChangeLog:

* tree-vect-stmts.cc (vectorizable_load): Always cost
VMAT_ELEMENTWISE
as scalar load.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr110776.c: New test.

[Bug gcov-profile/110827] New: C++20 coroutines aren't being measured by gcov

[mwd at md5i dot com via Gcc-bugs]

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

Bug ID: 110827
   Summary: C++20 coroutines aren't being measured by gcov
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mwd at md5i dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55648
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55648=edit
Simple bug exemplar

When compiling with `--coverage` and running a program that utilizes C++20
coroutines, the statements in the coroutines aren't measured by gcov.

Compile the attached file, `foo.cpp`, with:
`g++ -std=c++20 --coverage -O0 -ggdb3 -o foo foo.cpp`

Then run the resulting `foo`, followed by `gcov foo.cpp`.

The resulting output in `foo.cpp.gcov` does not include lines 28 or 29 of
`foo.cpp`, the contents of the coroutine `foo()`.  In my tests this happens
with any coroutine of any size, though functions called by a coroutine are
covered properly.

[Bug c/110789] Internal Compiler Error: Illegal instruction

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #8 from Xi Ruoyao  ---
For LFS specific issue please ask lfs-supp...@lists.linuxfromscratch.org first. 

If you'd done so you'd avoid a unnecessary two-day debug session and we'd
reduce one invalid bug report in upstream issue tracker.

[Bug middle-end/110818] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'

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

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

Xi Ruoyao  changed:

   What|Removed |Added

   Keywords||needs-bisection,
   ||needs-reduction
  Known to work||12.1.0
  Known to fail||11.4.0

--- Comment #6 from Xi Ruoyao  ---
Not reproducible with 12.1.0 or later, maybe we can just bisect.

[Bug middle-end/110818] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #5 from Xi Ruoyao  ---
(In reply to CTC from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > The reduced testcase is undefined code 
> > Though the original is most likely well defined valid code.
> 
> I tried to add "-fsanitize=undefined" to make reduced testcase well defined.
> But the original testcase with "-fsanitize=undefined" can work successfully
> without run-time errors.

But this is really obvious that the reduced testcase is undefined.

Use your brain before pasting an output of automatic tools into a bug report.

[Bug target/88160] Error: register save offset not a multiple of 4 only with optimize

[vincent.riviere at freesbee dot fr via Gcc-bugs]

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

--- Comment #4 from Vincent Riviere  ---
Created attachment 55647
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55647=edit
Workaround for compiling libgcc with -mcpu=5475 -mshort

Here is a patch for GCC 13.1.0. It allows libgcc to be compiled with -mcpu=5475
-mshort. As a workaround, it uses -fno-combine-stack-adjustments on the
impacted functions.

__attribute__((optimize("-fno-combine-stack-adjustments")))

Of course, it would be much better to fix the root of the issue.

[Bug target/88160] Error: register save offset not a multiple of 4 only with optimize

[vincent.riviere at freesbee dot fr via Gcc-bugs]

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

--- Comment #3 from Vincent Riviere  ---
There are 2 lightweight workarounds for the OP testcase:
-fno-combine-stack-adjustments
-fno-omit-frame-pointer

$ m68k-elf-gcc -mshort -mcpu=5475 -g -O2 -c test.c
/tmp/ccW6hc6h.s: Assembler messages:
/tmp/ccW6hc6h.s:20: Error: register save offset not a multiple of 4
/tmp/ccW6hc6h.s:21: Error: register save offset not a multiple of 4
/tmp/ccW6hc6h.s:22: Error: register save offset not a multiple of 4

$ m68k-elf-gcc -mshort -mcpu=5475 -g -O2 -c test.c
-fno-combine-stack-adjustments
# OK

$ m68k-elf-gcc -mshort -mcpu=5475 -g -O2 -c test.c -fno-omit-frame-pointer
# OK

[Bug other/95316] Offload compilation fails when not all offload compilers are installed that were configured

[burnus--- via Gcc-bugs]

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

bur...@net-b.de  changed:

   What|Removed |Added

 CC||bur...@net-b.de

--- Comment #6 from bur...@net-b.de  ---
Matthias, isn't the issue just that for some reason the local patch, matching
what's nowadays --enable-offload-defaulted, wasn't working properly?

Cf. https://gcc.gnu.org/install/configure.html
and
https://inbox.sourceware.org/gcc-patches/251870a9-85e8-b69b-2f94-841f7548c...@ubuntu.com/t/
which also refers to lp #1878760 

At least with --enable-offload-defaulted both at compile time and at libgomp
runtime, no error should be shown if not install.

Can this now be closed as fixed? (I think since GCC 12.)

[Bug fortran/110825] TYPE(*) dummy argument to generate an unused hidden argument

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #3 from Steve Kargl  ---
On Wed, Jul 26, 2023 at 08:54:01PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110825
> 
> --- Comment #1 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from comment #0)
> > Thus, when compiled and executed the program hits 'STOP 1'.  Likely,
> > gfortran needs to add a possibly unused hidden argument to the argument list
> > for a TYPE(*) dummy argument.
> 
> I guess it should be the other way around: if the dummy argument is TPYE(*),
> we only pass a reference to the actual argument, but no hidden argument,
> as is the case for bind(c).  This is also what the called procedure expects.

I had not thought about how gfortran handles bind(c).  In my codes that
use bind(c), I use an array with character(len=1) with the last element
set to c_null_char.  On the C side, it looks like a C null-terminated
string. 

I don't use type(*) in my codes, so I'm unsure how, or even if,
the length type parameter would/(need to) be passed along.

> What if the caller passed a type other than character?

That's why I wrote '***possibly unused*** hidden argument'

> So we just need to update the caller (the "monster" gfc_conv_procedure_call).
> 
> Do you have an idea what would be the use of the hidden argument here anyway?

Hmmm, a scan of F2018 suggest that type(*) has rather limited uses

   C710  An assumed-type variable name shall not appear in a designator
  or expression except as an actual argument corresponding to a dummy
  argument that is assumed-type, or as the first argument to the
  intrinsic function IS_CONTIGUOUS, LBOUND, PRESENT, RANK, SHAPE, SIZE,
  or UBOUND, or the function C_LOC from the intrinsic module ISO_C_BINDING.

I suspect that a hidden argument isn't needed.  This means
that gfc_conv_procedure_call will need to suppress a hidden
argument for a type(*) dummy argument when the actual argument
is of character type.

> As TYPE(*) is rather new, and I did not find any mentioning of it in the
> ABI specification, we should clarify what we want and also document it at
> 
> https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html

Sorry, I cannot be of much help.  type(*) is well off my radar for
my owns codes.

[Bug c++/110566] [13 Regression] ICE when instantiating function template with template template parameter with 2 or more auto parameters with a dependent member template, ICE in tsubst, at cp/pt.cc:1

[waffl3x at protonmail dot com via Gcc-bugs]

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

--- Comment #6 from waffl3x  ---
(In reply to Patrick Palka from comment #5)
> Should be fixed on trunk so far.

Once it shows up on godbolt I will make sure that all the cases that exhibited
the bug are working for me now. I had a bunch of different combinations of
typename and auto and anything with 2 or more autos were breaking.
If I had to guess, I imagine they all should all be working now, but I'll
double check it to make sure.

[Bug middle-end/110818] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end

--- Comment #4 from Andrew Pinski  ---
(In reply to CTC from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > The reduced testcase is undefined code 
> > Though the original is most likely well defined valid code.
> 
> I tried to add "-fsanitize=undefined" to make reduced testcase well defined.
> But the original testcase with "-fsanitize=undefined" can work successfully
> without run-time errors.

The way I normally reduce testcases like this is to run it a few different ways
to avoid reducing it to an undefined code. Plus error out on uninitialized
variable warnings too.
Since this is reported against 11.4, it could be fixed already on the trunk too
so it might take me some time to reduce it ...

I might get around to trying to reduce the issue later today or tomorrow.

[Bug c++/110566] [13 Regression] ICE when instantiating function template with template template parameter with 2 or more auto parameters with a dependent member template, ICE in tsubst, at cp/pt.cc:1

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

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

Patrick Palka  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=108179
   Keywords|patch   |
 CC||ppalka at gcc dot gnu.org
Summary|[13/14 Regression] ICE when |[13 Regression] ICE when
   |instantiating function  |instantiating function
   |template with template  |template with template
   |template parameter with 2   |template parameter with 2
   |or more auto parameters |or more auto parameters
   |with a dependent member |with a dependent member
   |template, ICE in tsubst, at |template, ICE in tsubst, at
   |cp/pt.cc:16135  |cp/pt.cc:16135
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org

--- Comment #5 from Patrick Palka  ---
Should be fixed on trunk so far.

[Bug c++/110566] [13/14 Regression] ICE when instantiating function template with template template parameter with 2 or more auto parameters with a dependent member template, ICE in tsubst, at cp/pt.c

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r14-2810-gb8218eb2266811991b8163f36d5c1d974cb50b93
Author: Patrick Palka 
Date:   Wed Jul 26 17:21:43 2023 -0400

c++: passing partially inst ttp as ttp [PR110566]

The previous fix doesn't work for partially instantiated ttps mainly
because most_general_template is a no-op for them.  This patch fixes
this by giving such ttps a DECL_TEMPLATE_INFO (extending the
r11-734-g2fb595f8348e16 fix) with which most_general_template can obtain
the original, unlowered ttp.

This patch additionally makes coerce_template_template_parms use the
correct amount of levels from the scope of a ttp argument.

PR c++/110566
PR c++/108179

gcc/cp/ChangeLog:

* pt.cc (reduce_template_parm_level): Set DECL_TEMPLATE_INFO
on the DECL_TEMPLATE_RESULT of the new ttp.
(add_defaults_to_ttp): Make a copy of the original ttp's
DECL_TEMPLATE_RESULT, and update this copy's DECL_TEMPLATE_INFO
as well.
(coerce_template_template_parms): Make sure 'scope_args' has
the right amount of levels for the ttp argument.
(most_general_template): Handle template template parameters.
(rewrite_template_parm): Set DECL_TEMPLATE_RESULT on the
DECL_TEMPLATE_RESULT of the new ttp.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/class-deduction115.C: New test.
* g++.dg/template/ttp39.C: New test.

[Bug c++/108179] [11/12 regression] ICE related to template template parameters in tsubst, at cp/pt.cc:15782

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r14-2810-gb8218eb2266811991b8163f36d5c1d974cb50b93
Author: Patrick Palka 
Date:   Wed Jul 26 17:21:43 2023 -0400

c++: passing partially inst ttp as ttp [PR110566]

The previous fix doesn't work for partially instantiated ttps mainly
because most_general_template is a no-op for them.  This patch fixes
this by giving such ttps a DECL_TEMPLATE_INFO (extending the
r11-734-g2fb595f8348e16 fix) with which most_general_template can obtain
the original, unlowered ttp.

This patch additionally makes coerce_template_template_parms use the
correct amount of levels from the scope of a ttp argument.

PR c++/110566
PR c++/108179

gcc/cp/ChangeLog:

* pt.cc (reduce_template_parm_level): Set DECL_TEMPLATE_INFO
on the DECL_TEMPLATE_RESULT of the new ttp.
(add_defaults_to_ttp): Make a copy of the original ttp's
DECL_TEMPLATE_RESULT, and update this copy's DECL_TEMPLATE_INFO
as well.
(coerce_template_template_parms): Make sure 'scope_args' has
the right amount of levels for the ttp argument.
(most_general_template): Handle template template parameters.
(rewrite_template_parm): Set DECL_TEMPLATE_RESULT on the
DECL_TEMPLATE_RESULT of the new ttp.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/class-deduction115.C: New test.
* g++.dg/template/ttp39.C: New test.

[Bug c++/110566] [13/14 Regression] ICE when instantiating function template with template template parameter with 2 or more auto parameters with a dependent member template, ICE in tsubst, at cp/pt.c

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r14-2809-gb3adcc60dcf3314f47f5409aecef40607f82b80b
Author: Patrick Palka 
Date:   Wed Jul 26 17:21:26 2023 -0400

c++: passing partially inst tmpl as ttp [PR110566]

Since the template arguments 'pargs' we pass to coerce_template_parms from
coerce_template_template_parms are always a full set, we need to make sure
we always pass the parameters of the most general template because if the
template is partially instantiated then the levels won't match up.  In the
testcase below during said call to coerce_template_parms the parameters are
{X, Y}, both level 1 rather than 2, and the arguments are {{int}, {N, M}},
which results in a crash during auto deduction for parameters' types.

PR c++/110566
PR c++/108179

gcc/cp/ChangeLog:

* pt.cc (coerce_template_template_parms): Simplify by using
DECL_INNERMOST_TEMPLATE_PARMS and removing redundant asserts.
Always pass the parameters of the most general template to
coerce_template_parms.

gcc/testsuite/ChangeLog:

* g++.dg/template/ttp38.C: New test.

[Bug c++/108179] [11/12 regression] ICE related to template template parameters in tsubst, at cp/pt.cc:15782

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r14-2809-gb3adcc60dcf3314f47f5409aecef40607f82b80b
Author: Patrick Palka 
Date:   Wed Jul 26 17:21:26 2023 -0400

c++: passing partially inst tmpl as ttp [PR110566]

Since the template arguments 'pargs' we pass to coerce_template_parms from
coerce_template_template_parms are always a full set, we need to make sure
we always pass the parameters of the most general template because if the
template is partially instantiated then the levels won't match up.  In the
testcase below during said call to coerce_template_parms the parameters are
{X, Y}, both level 1 rather than 2, and the arguments are {{int}, {N, M}},
which results in a crash during auto deduction for parameters' types.

PR c++/110566
PR c++/108179

gcc/cp/ChangeLog:

* pt.cc (coerce_template_template_parms): Simplify by using
DECL_INNERMOST_TEMPLATE_PARMS and removing redundant asserts.
Always pass the parameters of the most general template to
coerce_template_parms.

gcc/testsuite/ChangeLog:

* g++.dg/template/ttp38.C: New test.

[Bug fortran/110825] TYPE(*) dummy argument to generate an unused hidden argument

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Untested fix:

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index ef3e6d08f78..a1eac8e611e 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -7521,6 +7521,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
  && !(fsym && fsym->ts.type == BT_DERIVED && fsym->ts.u.derived
   && fsym->ts.u.derived->intmod_sym_id == ISOCBINDING_PTR
   && fsym->ts.u.derived->from_intmod == INTMOD_ISO_C_BINDING )
+ && !(fsym && fsym->ts.type == BT_ASSUMED)
  && !(fsym && UNLIMITED_POLY (fsym)))
vec_safe_push (stringargs, parmse.string_length);

[Bug fortran/110826] New: Fortran array of derived type with a pointer to function with dimensional arguments

[mysecmailboks at gmail dot com via Gcc-bugs]

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

Bug ID: 110826
   Summary: Fortran array of derived type with a pointer to
function with dimensional arguments
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mysecmailboks at gmail dot com
  Target Milestone: ---

The following program fails at `func_array(1)%f => zero_state`:
```
program test_func_array
   implicit none

   type pp
 procedure(func_template), pointer, nopass :: f =>null()
   end type pp

   abstract interface
  function func_template(state) result(dstate)
implicit none
real, dimension(:,:), intent(in):: state
real, dimension(size(state,1), size(state,2)) :: dstate
  end function
   end interface

   type(pp) :: func_array(4)
   real, dimension(4,6) :: state

   func_array(1)%f => zero_state

   print*,func_array(1)%f(state)
contains

  function zero_state(state) result(dstate)
implicit none
real, dimension(:,:), intent(in):: state
real, dimension(size(state,1), size(state,2)) :: dstate

dstate = 0.

  end function zero_state
end program test_func_array
```
I have tested with various `gfortran` compilers at https://godbolt.org/. The
error is roughly the same. Along the lines of:
```
f951: internal compiler error: spec_dimen_size(): Bad dimension
0x75ee87 gfc_internal_error(char const*, ...)
???:0
0x72a016 spec_dimen_size(gfc_array_spec*, int, __mpz_struct (*) [1])
???:0
0x7d4bcb gfc_expression_rank(gfc_expr*)
???:0
0x7de37b gfc_resolve_code(gfc_code*, gfc_namespace*)
???:0
0x7c7500 gfc_parse_file()
???: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.
ASM generation compiler returned: 1
f951: internal compiler error: spec_dimen_size(): Bad dimension
0x75ee87 gfc_internal_error(char const*, ...)
???:0
0x72a016 spec_dimen_size(gfc_array_spec*, int, __mpz_struct (*) [1])
???:0
0x7d4bcb gfc_expression_rank(gfc_expr*)
???:0
0x7de37b gfc_resolve_code(gfc_code*, gfc_namespace*)
???:0
0x7c7500 gfc_parse_file()
???: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.
Execution build compiler returned: 1
```

The same error is given even if the dimensional arguments are explicitly
defined (as opposed to using `size`).

The program works if func_array is a scalar:
```
   type(pp) :: func_array
   real, dimension(4,6) :: state

   func_array%f => zero_state

   print*,func_array%f(state)
```

[Bug fortran/110825] TYPE(*) dummy argument to generate an unused hidden argument

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

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #0)
> Thus, when compiled and executed the program hits 'STOP 1'.  Likely,
> gfortran needs to add a possibly unused hidden argument to the argument list
> for a TYPE(*) dummy argument.

I guess it should be the other way around: if the dummy argument is TPYE(*),
we only pass a reference to the actual argument, but no hidden argument,
as is the case for bind(c).  This is also what the called procedure expects.
What if the caller passed a type other than character?

So we just need to update the caller (the "monster" gfc_conv_procedure_call).

Do you have an idea what would be the use of the hidden argument here anyway?

As TYPE(*) is rather new, and I did not find any mentioning of it in the
ABI specification, we should clarify what we want and also document it at

https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html

[Bug c++/110809] ICE: in unify, at cp/pt.cc:25226 with floating-point NTTPs

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |13.3

--- Comment #8 from Patrick Palka  ---
Fixed on trunk so far.

[Bug c++/110809] ICE: in unify, at cp/pt.cc:25226 with floating-point NTTPs

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:744e1f35266dbd6b6fb95c7e8422562815f8b56f

commit r14-2806-g744e1f35266dbd6b6fb95c7e8422562815f8b56f
Author: Patrick Palka 
Date:   Wed Jul 26 16:52:13 2023 -0400

c++: unifying REAL_CSTs [PR110809]

This teaches unify how to compare two REAL_CSTs.

PR c++/110809

gcc/cp/ChangeLog:

* pt.cc (unify) : Generalize to handle
REAL_CST as well.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/nontype-float3.C: New test.

[Bug c++/110824] Gcc crashing on a lambda capture

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

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

--- Comment #1 from Andrew Pinski  ---
Reducing to see if it is reproducible on the trunk ...

[Bug fortran/110825] TYPE(*) dummy argument to generate an unused hidden argument

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Priority|P3  |P4
 Ever confirmed|0   |1
  Known to fail||13.1.1, 14.0
   Last reconfirmed||2023-07-26

[Bug fortran/110825] New: TYPE(*) dummy argument to generate an unused hidden argument

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

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

Bug ID: 110825
   Summary: TYPE(*) dummy argument to generate an unused hidden
argument
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

The was pointed out in Fortran Discourse,

https://fortran-lang.discourse.group/t/strange-behaviour-when-using-type-and-character-in-gfortran/6233

that gfortran generates wrong code for a valid program.  Here's a slightly
modified version of the program.

  program foo

implicit none

character(100) :: not_used
call sub(not_used, "123")

contains

subroutine sub(useless_var, print_this)
type(*), intent(in)  :: useless_var
character(*), intent(in) :: print_this
if (len_trim(print_this) /= 3) stop 1
end subroutine sub

  end

The subroutine reference in the main program is generating a call with two
hidden arguments.  From -fdump-tree-original, 

void MAIN__ ()
{
  static void sub (void * & restrict, character(kind=1)[1:] & restrict,
integer(kind=8));
  character(kind=1) not_used[1:100];

  sub (_used, &"123"[1]{lb: 1 sz: 1}, 100, 3);
}

we have hidden arguments 100 and 3.  However, the code generated for the
contained subroutine is only expecting one hidden argument.

__attribute__((fn spec (". r r ")))
void sub (void * & restrict useless_var,
   character(kind=1)[1:_print_this] & restrict print_this,
   integer(kind=8) _print_this)
{
...
}

Thus, when compiled and executed the program hits 'STOP 1'.  Likely, gfortran
needs to add a possibly unused hidden argument to the argument list for a
TYPE(*) dummy argument.

[Bug fortran/80256] Cygwin test fail: bind_c_array_params_2.f90 scan-assembler-times

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|REOPENED|WAITING

--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to nightstrike from comment #6)
> This fails on x86_64-w64-mingw32 as well.

Can you provide details about that failure?

It appears that the original report is fixed.

[Bug c++/110824] New: Gcc crashing on a lambda capture

[denis.yaroshevskij at gmail dot com via Gcc-bugs]

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

Bug ID: 110824
   Summary: Gcc crashing on a lambda capture
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis.yaroshevskij at gmail dot com
  Target Milestone: ---

Created attachment 55646
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55646=edit
ninja.log and .ii file

Attaching ninja log and a .ii file
Let me know if you need anyting else.

[Bug rtl-optimization/110823] [missed optimization] >50% speedup for x86-64 ASCII processing a la GNU diffutils

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

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

--- Comment #3 from Andrew Pinski  ---
The gimple level looks like:
```
  if (_54 >= 0)
goto ; [90.00%]
  else
goto ; [10.00%]

   [local count: 63261141172]:
  _18 = (unsigned int) _54;
  goto ; [100.00%]
...
  len_37 = mbrtoc32 (, iter_39, _36, );
  len.0_38 = (signed long) len_37;
  if (len.0_38 < 0)
goto ; [10.00%]
  else
goto ; [90.00%]

   [local count: 632611429]:
  ch.1_42 = ch; // Note this is a local variable

   [local count: 7029015815]:
  # SR.45_12 = PHI 
  # SR.46_46 = PHI 
  mbs ={v} {CLOBBER(eol)};
  ch ={v} {CLOBBER(eol)};

   [local count: 70290156974]:
  # SR.41_16 = PHI <_18(4), SR.45_12(7)>
  # SR.42_47 = PHI <1(4), SR.46_46(7)>
  _6 = (long long unsigned int) SR.41_16;
```

Maybe we should have a type promotion pass on the gimple level that promotes
_54 to `long unsigned int`.

[Bug fortran/68569] ICE with automatic character object and DATA

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-14.  Closing.

Thanks for the report!

[Bug fortran/33056] [Meta-bug] Data - statement related bugs

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33056
Bug 33056 depends on bug 68569, which changed state.

Bug 68569 Summary: ICE with automatic character object and DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68569

   What|Removed |Added

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

[Bug fortran/68569] ICE with automatic character object and DATA

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:27ba73644f53c118e3f9b3fe9cd792210696ec55

commit r14-2805-g27ba73644f53c118e3f9b3fe9cd792210696ec55
Author: Harald Anlauf 
Date:   Wed Jul 26 21:12:45 2023 +0200

Fortran: diagnose strings of non-constant length in DATA statements
[PR68569]

gcc/fortran/ChangeLog:

PR fortran/68569
* resolve.cc (check_data_variable): Do not accept strings with
deferred length or non-constant length in a DATA statement.
Reject also substrings of string variables of non-constant length.

gcc/testsuite/ChangeLog:

PR fortran/68569
* gfortran.dg/data_char_4.f90: Adjust expected diagnostic.
* gfortran.dg/data_char_5.f90: Likewise.
* gfortran.dg/data_char_6.f90: New test.

[Bug rtl-optimization/110823] [missed optimization] >50% speedup for x86-64 ASCII processing a la GNU diffutils

[eggert at cs dot ucla.edu via Gcc-bugs]

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

--- Comment #2 from Paul Eggert  ---
Created attachment 55645
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55645=edit
code-mbcel1.s with the optimization suggested in the bug report

[Bug rtl-optimization/110823] [missed optimization] >50% speedup for x86-64 ASCII processing a la GNU diffutils

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug rtl-optimization/110823] [missed optimization] >50% speedup for x86-64 ASCII processing a la GNU diffutils

[eggert at cs dot ucla.edu via Gcc-bugs]

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

--- Comment #1 from Paul Eggert  ---
Created attachment 55644
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55644=edit
gcc -O2 -S output (from code-mbcel1.i)

[Bug rtl-optimization/110823] New: [missed optimization] >50% speedup for x86-64 ASCII processing a la GNU diffutils

[eggert at cs dot ucla.edu via Gcc-bugs]

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

Bug ID: 110823
   Summary: [missed optimization] >50% speedup for x86-64 ASCII
processing a la GNU diffutils
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

Created attachment 55643
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55643=edit
proprocessed source code inspired by GNU diffutils

This is GCC 13.1.1 20230614 (Red Hat 13.1.1-4) on x86-64.

While tuning GNU diffutils I noticed that its loops to process mostly-ASCII
text were not compiled well by GCC on x86-64. For a stripped-down example of
the problem, compile the attached program with:

gcc -O2 -S code-mbcel1.i

The result is in the attached file code-mbcel1.s. Its loop kernel assuming
ASCII text (starting on line 212) looks like this:

  .L33:
testb   %al, %al
js  .L30
movl$1, %edx
  .L31:
movl%eax, %eax
addq%rdx, %rbx
addq%rax, %rbp
movsbl  (%rbx), %eax
testb   %al, %al
jne .L33

As I understand it the "movl %eax, %eax" is unnecessary, as all code that
reaches .L31 guarantees that %rax's top 32 bits are zero.

Also, the loop body executes "testb %al, %al" twice when once would suffice.
(As a minor point, since the compiler can easily tell that %al is positive when
the loop is entered, it can omit the first testb.)

Suppose we change the above code to the following, as is done in the attached
file code-mbcel1-opt.s:

  .L33:
movl$1, %edx
  .L31:
addq%rdx, %rbx
addq%rax, %rbp
movsbl  (%rbx), %eax
testb   %al, %al
jg  .L33
js  .L30

This small change improves performance significantly: for me, the test program
runs 55% faster on a circa-2021 Intel Xeon W-1350, and 74% faster on a
circa-2010 AMD Phenom II x4 910e, using the following commands to benchmark:

gcc -O2 code-mbcel1.i -o code-mbcel1
gcc -O2 code-mbcel1-opt.s -o code-mbcel1-opt
time ./code-mbcel1
time ./code-mbcel1-opt

[Bug c++/110822] [13/14 Regression] ICE on constexpr initialized with non-constant expression also accepts-invalid

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE on constexpr|[13/14 Regression] ICE on
   |initialized with|constexpr initialized with
   |non-constant expression |non-constant expression
   |also accepts-invalid|also accepts-invalid
   Target Milestone|--- |13.2
  Known to fail||13.1.0
  Known to work||12.1.0

--- Comment #1 from Andrew Pinski  ---
Note I think GCC accepts this because the string fits in the (local) buffer of
std::string.

That is a longer string like:
constexpr std::string text = "012345678901234567890"s;

is rejected 

[Bug c++/110822] New: ICE on constexpr initialized with non-constant expression also accepts-invalid

[stevenxia990430 at gmail dot com via Gcc-bugs]

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

Bug ID: 110822
   Summary: ICE on constexpr initialized with non-constant
expression also accepts-invalid
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stevenxia990430 at gmail dot com
  Target Milestone: ---

The following invalid program reports an internal compiler error: verify_gimple
failed on gcc-trunk with -O1, -O2 or -O3 optimization

To quickly reproduce: https://gcc.godbolt.org/z/s5aP44sKb
```
#include 
using namespace std::string_literals;
constexpr std::string text = "Some text here"s;
int main()
{
std::cout << "The text is: " << text << '\n';
}
```

Note that compiling without optimization is successful, but is rejected on
clang-trunk

See this link: https://gcc.godbolt.org/z/G8vYhbe9E

[Bug c++/106310] [12/13 Regression] lookup after this-> seems wrong for dependent lookup since r12-6754-g30f2c22def739211

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

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||11.3.0, 14.0
Summary|[12/13/14 Regression]   |[12/13 Regression] lookup
   |lookup after this-> seems   |after this-> seems wrong
   |wrong for dependent lookup  |for dependent lookup since
   |since   |r12-6754-g30f2c22def739211
   |r12-6754-g30f2c22def739211  |

--- Comment #10 from Jason Merrill  ---
Fixed for 14 so far.

[Bug fortran/68569] ICE with automatic character object and DATA

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

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Submitted (v2): https://gcc.gnu.org/pipermail/fortran/2023-July/059652.html

[Bug c++/110821] gcc inline asm for the riscv architecture with the BNE (and possibly other instructions)

[devnexen at gmail dot com via Gcc-bugs]

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

--- Comment #2 from David CARLIER  ---
Ah, makes sense sorry for the disturbance. thanks

[Bug c++/110821] gcc inline asm for the riscv architecture with the BNE (and possibly other instructions)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
Fails when the assembler comes along:
:10: Error: illegal operands `bne t1 a6,jmp12'

Basically inline-asm just does substitution and outputs it for the assembler to
handle.  GCC does not include an assembler (unlike llmv/clang).

[Bug libstdc++/110807] [13 Regression] Copy list initialisation of a vector raises a warning with -O2

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r14-2802-gf30e62b0ee05befd20863466d1fb55a34d15c228
Author: Jonathan Wakely 
Date:   Wed Jul 26 19:08:39 2023 +0100

libstdc++: Require C++11 for 23_containers/vector/bool/110807.cc [PR110807]

This new test uses uniform initialization syntax, so requires C++11 or
later.

libstdc++-v3/ChangeLog:

PR libstdc++/110807
* testsuite/23_containers/vector/bool/110807.cc: Require c++11.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[dilyan.palauzov at aegee dot org via Gcc-bugs]

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

Дилян Палаузов  changed:

   What|Removed |Added

 CC||dilyan.palauzov at aegee dot 
org

--- Comment #27 from Дилян Палаузов  ---
With gcc 13 at commit 670caa3f043e6a7af72bd76482a79a703a652ee5
(origin/releases/gcc-13)
Author: GCC Administrator 
Date:   Tue Jul 25 00:23:26 2023 +

Daily bump.

after calling

export CONFIG_SITE="a"
mkdir -p build && cd build && ../configure --enable-threads=posix --enable-nls
--disable-multilib --enable-interpreter --with-system-zlib
--enable-languages=c,c++,go,lto --enable-targets=all --with-system-unwind
--without-x --with-linker-hash-style=gnu --enable-shared
--with-build-config=bootstrap-lto\ bootstrap-O3 &> ../c-out && make

build fails at stage 3 with

libtool: compile:  /git/gcc/build/./gcc/xgcc -B/git/gcc/build/./gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/
-isystem /usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../libgo
-I ../../../libgo/runtime -I../../../libgo/../libffi/include
-I../libffi/include -pthread -L../libatomic/.libs -fexceptions
-fnon-call-exceptions -fsplit-stack -Wall -Wextra -Wwrite-strings -Wcast-qual
-Werror -minline-all-stringops -D_GNU_SOURCE -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I ../../../libgo/../libgcc -I
../../../libgo/../libbacktrace -I ../../gcc/include -g -O2 -c
../../../libgo/go/golang.org/x/sys/cpu/cpu_gccgo_x86.c  -fPIC -DPIC -o
golang.org/x/sys/.libs/cpu_gccgo_x86.o
libtool: compile:  /git/gcc/build/./gcc/xgcc -B/git/gcc/build/./gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/
-isystem /usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../libgo
-I ../../../libgo/runtime -I../../../libgo/../libffi/include
-I../libffi/include -pthread -L../libatomic/.libs -fexceptions
-fnon-call-exceptions -fsplit-stack -Wall -Wextra -Wwrite-strings -Wcast-qual
-Werror -minline-all-stringops -D_GNU_SOURCE -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I ../../../libgo/../libgcc -I
../../../libgo/../libbacktrace -I ../../gcc/include -g -O2 -c
../../../libgo/go/golang.org/x/sys/cpu/cpu_gccgo_x86.c -o
golang.org/x/sys/cpu_gccgo_x86.o >/dev/null 2>&1
make[4]: *** No rule to make target '../libbacktrace/libbacktrace.la', needed
by 'libgo.la'.  Stop.
make[4]: Leaving directory '/git/gcc/build/x86_64-pc-linux-gnu/libgo'
make[3]: *** [Makefile:2347: all-recursive] Error 1
make[3]: Leaving directory '/git/gcc/build/x86_64-pc-linux-gnu/libgo'
make[2]: *** [Makefile:1212: all] Error 2
make[2]: Leaving directory '/git/gcc/build/x86_64-pc-linux-gnu/libgo'
make[1]: *** [Makefile:22370: all-target-libgo] Error 2
make[1]: Leaving directory '/git/gcc/build'
make: *** [Makefile:1082: all] Error 2

When I use instead --enable-languages=all it works (at least worked on the
releases/gcc-13 branch on 2023-04-28)

[Bug c++/110821] New: gcc inline asm for the riscv architecture with the BNE (and possibly other instructions)

[devnexen at gmail dot com via Gcc-bugs]

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

Bug ID: 110821
   Summary: gcc inline asm for the riscv architecture with the BNE
(and possibly other instructions)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: devnexen at gmail dot com
  Target Milestone: ---

Hi, sorry I'm new here I assume 14.0 means master ?
Anyway it seems there is a bug with risc-v architecture (tried with 32 bits)
with the bne instruction
(https://riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf) expects "bne
, , ".
Issue with gcc is passes without the comma as you can experience here

https://godbolt.org/z/G9EY84qG3

but fails rightfully with clang.

Thanks in advance.

[Bug tree-optimization/110819] Missed optimization: when vector's size is 0 but vector::reserve has been called.

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=110137

--- Comment #1 from Jonathan Wakely  ---
I guess gcc can't optimize this away because it doesn't know if operator new
has side effects. When compiled with clang, libstdc++'s std::vector uses
__builtin_operator_new which always has the -fassume-sane-operator-new
semantics, and so can be optimized.

[Bug tree-optimization/110817] [14 Regression] wrong code with vector compares and vector lowering

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-07-26
Summary|[14 Regression] wrong code  |[14 Regression] wrong code
   |with vector compares on |with vector compares and
   |multiple targets|vector lowering
 Status|UNCONFIRMED |NEW

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

[Bug tree-optimization/110817] [14 Regression] wrong code with vector compares on multiple targets

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|riscv64-unknown-linux-gnu   |
   Target Milestone|--- |14.0
   Host|x86_64-pc-linux-gnu |
 CC||pinskia at gcc dot gnu.org
 Blocks||88670

--- Comment #1 from Andrew Pinski  ---
This testcase fails with -mno-sse on x86_64 at -O1:
```
typedef unsigned char u8;
typedef unsigned __attribute__((__vector_size__ (8))) V;

V v;
unsigned char c;

int
main (void)
{
  V x = (v > 0) > (v != c);
 // V x = foo ();
  if (x[0] || x[1])
__builtin_abort ();
  return 0;
}
```


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88670
[Bug 88670] [meta-bug] generic vector extension issues

[Bug c/102989] Implement C2x's n2763 (_BitInt)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #55637|0   |1
is obsolete||

--- Comment #90 from Jakub Jelinek  ---
Created attachment 55642
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55642=edit
gcc14-bitint-wip.patch

Inline asm support with large/huge _BitInt (limited usefulness and makes mostly
sense with g constraint), abs/absu/min/max fixes (had a bug in one testcase
which prevented from those bugs to be seen) and one .{ADD,SUB}_OVERFLOW fix;
all the torture bitint run tests now pass even with -fsanitize=undefined.
Have to do something about stmt_ends_bb_p calls with large/huge _BitInt lhs and
deal with debuginfo, then bootstrap/regtest it as whole and submit.

[Bug c++/110820] New: vector_size attribute does not apply inside a template nttp argument

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

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

Bug ID: 110820
   Summary: vector_size attribute does not apply inside a template
nttp argument
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
#define vector__ __attribute__((vector_size(sizeof(double)*4)))
typedef vector__ double v4d;
template struct A { };

template void f(A);
```

The error message we get is:
:6:66: error: could not convert '__vector(4) double{1.0e+0, 1.0e+0,
2.0e+0, 2.0e+0}' from '__vector(4) double' to 'double'
6 | template void f(A);
  |  ^
  |  |
  | 
__vector(4) double
```
Which does not make sense really since I put vector__ there.

Note using v4d instead of `vector__ double` in line #3 we get:
```
:4:17: error: '__vector(4) double' is not a valid type for a template
non-type parameter because it is not structural
4 | template struct A { };
  | ^~~
```

[Bug analyzer/109365] Double delete yields -Wanalyzer-use-after-free instead of -Wanalyzer-double-free

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

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

--- Comment #6 from Benjamin Priour  ---
(In reply to David Malcolm from comment #5)
> (In reply to Benjamin Priour from comment #4)
> > (In reply to Benjamin Priour from comment #3)
> 
> Here's a link to the reproducer:
>   https://godbolt.org/z/Wa3fqjrTK
> with the fields renamed to avoid reusing the name "a".
> 
> 
> > [...snip...]
> > > 
> > > 
> > >:
> > >   *a.0_11 ={v} {CLOBBER};
> > >   operator delete (a.0_11, 8);
> > >
> > [...snip...] 
> > >
> > > Entry statement of bb3 is the one actually detected as
> > > -Wanalyzer-double-free.
> > 
> > Given the above IPA, we cannot just ignore the assignment statement, as it
> > could really be an injurious statement, not just a pre-deallocation
> > statement at it is now.
> 
> Ths assignment statement:
>   *a.0_11 ={v} {CLOBBER};
> is a "clobber", which is a special-case of assignment, generated by the
> frontends when something is going out of scope, or becoming invalid.
> 
> We could potentially just special-case such ass
> 

Wouldn't considering "clobber" as a trigger for double-delete also lead to many
false positives ?
I'm not yet 100% familiar with and when this "clobber" appears.

[...snip...]

> > 
> > struct A
> > {
> >   ...
> >   ~A() {}
> > }
> > 
> > ...
> > 
> >  :
> >   A::~A (a.0_12);
> >   operator delete (a.0_12, 8);
> >  
> > 
> > The warnings stay the same, though it is now more reliable to check for a
> > destructor call, instead any random single assignment.
> 
> There's a sense in which it does make sense to complain about
> use-after-delete in the destructor (when the destructor is non-empty): the
> memory is being accessed after deletion.  Maybe this case would make more
> sense to the user?  (albeit being rather verbose)

I believe in the case of a non-empty destructor, "double-delete" would be more
on point than "use-after-delete", as ultimately the issue is the second call to
delete. "double-delete" immediately warns about the actual issue, whereas if
the first "delete" is not as obvious as in the above test case, a
"use-after-delete" might confuse the user.

"use-after-delete" could mislead the user to believe there is something wrong
with their destructor, although only their double delete is.

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

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

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

Richard Earnshaw  changed:

   What|Removed |Added

   Last reconfirmed||2023-07-26
 CC||rearnsha at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #11 from Richard Earnshaw  ---
Confirmed.  It only happens when generating Thumb code.  For Arm code it works
correctly.

I think the problem is that the Thumb code generator is emitting vcmf, while
the Arm code generator uses vcmfe - the latter sets the exception bits.

I'm not sure why the code is different yet, still investigating.

[Bug c++/106310] [12/13/14 Regression] lookup after this-> seems wrong for dependent lookup since r12-6754-g30f2c22def739211

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

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

--- Comment #9 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:51b997ea1d07465cb0208c711975b545872a2d2b

commit r14-2799-g51b997ea1d07465cb0208c711975b545872a2d2b
Author: Jason Merrill 
Date:   Wed Jul 26 10:39:34 2023 -0400

c++: member vs global template [PR106310]

For backward compatibility we still want to allow patterns like
this->A::foo, but the template keyword in a qualified name is
specifically to specify that a dependent name is a template, so don't look
in the enclosing scope at all.

Also fix handling of dependent bases: if member lookup in the current
instantiation fails and we have dependent bases, the lookup is dependent.
We were already handling that for the case where lookup in the enclosing
scope also fails, but we also want it to affect that lookup itself.

PR c++/106310

gcc/cp/ChangeLog:

* parser.cc (cp_parser_template_name): Skip non-member
lookup after the template keyword.
(cp_parser_lookup_name): Pass down template_keyword_p.

gcc/testsuite/ChangeLog:

* g++.dg/template/template-keyword4.C: New test.

[Bug tree-optimization/110819] Missed optimization: when vector's size is 0 but vector::reserve has been called.

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |tree-optimization
   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug c++/110819] New: Missed optimization: when vector size is 0 but vector::reserve has been called.

[hiraditya at msn dot com via Gcc-bugs]

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

Bug ID: 110819
   Summary: Missed optimization: when vector size is 0 but
vector::reserve has been called.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hiraditya at msn dot com
  Target Milestone: ---

#include

void f(int);

void use_idx_const_size_reserve() {
std::vector v;
v.reserve(10);
auto s = v.size();
for (std::vector::size_type i = 0; i < s; i++)
f(v[i]);
}

$ g++ -O3

use_idx_const_size_reserve():
sub rsp, 8
mov edi, 40
calloperator new(unsigned long)
mov esi, 40
add rsp, 8
mov rdi, rax
jmp operator delete(void*, unsigned long)


$ clang++ -O3 -stdlib=libc++

use_idx_const_size_reserve():# @use_idx_const_size_reserve()
ret

[Bug c/110818] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'

[19373742 at buaa dot edu.cn via Gcc-bugs]

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

--- Comment #3 from CTC <19373742 at buaa dot edu.cn> ---
Created attachment 55641
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55641=edit
The compiler output

[Bug c/110818] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'

[19373742 at buaa dot edu.cn via Gcc-bugs]

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

--- Comment #2 from CTC <19373742 at buaa dot edu.cn> ---
(In reply to Andrew Pinski from comment #1)
> The reduced testcase is undefined code 
> Though the original is most likely well defined valid code.

I tried to add "-fsanitize=undefined" to make reduced testcase well defined.
But the original testcase with "-fsanitize=undefined" can work successfully
without run-time errors.

[Bug c/110818] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'

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

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

--- Comment #1 from Andrew Pinski  ---
The reduced testcase is undefined code 
Though the original is most likely well defined valid code.

[Bug c++/110816] Emit initialization code for empty class under -ftrivial-auto-var-init

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-07-26

--- Comment #3 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #2)
> The only way to access that byte is to use memcpy or via char. 
> -ftrivial-auto-var-init is not designed for security this way but rather for
> normal code ...

That's not what the manual says (emphasis mine):

"Initialize automatic variables with either a pattern or with zeroes to
increase the security and predictability of a program by preventing
**uninitialized memory disclosure** and use."

> IIRC atomic compare and swap will zero it out too ...

The std::atomic and std::atomic_ref compare_exchange members will zero it, but
the compiler built-in won't.

[Bug c/110818] New: Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'

[19373742 at buaa dot edu.cn via Gcc-bugs]

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

Bug ID: 110818
   Summary: Segmentation fault with '-O3 -fno-dce -fno-ipa-cp
-fno-tree-dce -fno-tree-sink'
   Product: gcc
   Version: 11.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 19373742 at buaa dot edu.cn
  Target Milestone: ---

Created attachment 55640
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55640=edit
The preprocessed file

***
OS and Platform:
CentOS Linux release 7.9.2009 (Core), x86_64 GNU/Linux
***
gcc version:
gcc -v
Using built-in specs.
COLLECT_GCC=/home/gcc-releases/gcc-11-0720/bin/gcc
COLLECT_LTO_WRAPPER=/home/gcc-releases/gcc-11-0720/libexec/gcc/x86_64-pc-linux-gnu/11.4.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/home/gcc-releases/gcc-11-0720
--disable-multilib --enable-language=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.1 20230720 (GCC)
***
Command lines:
# /home/gcc-releases/gcc-11-0720/bin/gcc -O3 -fno-dce -fno-ipa-cp -fno-tree-dce
-fno-tree-sink tmpp.i -o works
# ./works
Segmentation fault
***
Reduced issue:
a() { b(); }
b(int, int *c) { d(*c <= 0); }
d() {}
main() { a(); }

[Bug c++/110816] Emit initialization code for empty class under -ftrivial-auto-var-init

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

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

--- Comment #2 from Andrew Pinski  ---
> This potentially leaks a byte of memory.  
The only way to access that byte is to use memcpy or via char. 
-ftrivial-auto-var-init is not designed for security this way but rather for
normal code ...

IIRC atomic compare and swap will zero it out too ...

[Bug libstdc++/110807] [13 Regression] Copy list initialisation of a vector raises a warning with -O2

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

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[13/14 Regression] Copy |[13 Regression] Copy list
   |list initialisation of a|initialisation of a
   |vector raises a   |vector raises a
   |warning with -O2|warning with -O2

--- Comment #6 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug libstdc++/110807] [13/14 Regression] Copy list initialisation of a vector raises a warning with -O2

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:7931a1de9ec87b996d51d3d60786f5c81f63919f

commit r14-2797-g7931a1de9ec87b996d51d3d60786f5c81f63919f
Author: Jonathan Wakely 
Date:   Wed Jul 26 14:09:24 2023 +0100

libstdc++: Avoid bogus overflow warnings in std::vector [PR110807]

GCC thinks the allocation can alter the object being copied if it's
globally reachable, so doesn't realize that [x.begin(), x.end()) after
the allocation is the same as x.size() before it.

This causes a testsuite failure when testing with -D_GLIBCXX_DEBUG:
FAIL: 23_containers/vector/bool/swap.cc (test for excess errors)
A fix is to move the calls to x.begin() and x.end() to before the
allocation.

A similar problem exists in vector::_M_insert_range where *this is
globally reachable, as reported in PR libstdc++/110807. That can also be
fixed by moving calls to begin() and end() before the allocation.

libstdc++-v3/ChangeLog:

PR libstdc++/110807
* include/bits/stl_bvector.h (vector(const vector&)): Access
iterators before allocating.
* include/bits/vector.tcc (vector::_M_insert_range):
Likewise.
* testsuite/23_containers/vector/bool/110807.cc: New test.

[Bug c++/84542] missing -Wdeprecated-declarations on a redeclared function template

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r14-2796-gc01b344e814001e07fd304ce98d013d811e90192
Author: Jonathan Wakely 
Date:   Wed Jul 26 14:05:58 2023 +0100

libstdc++: Add deprecated attribute to std::random_shuffle declarations

We already have these attributes on the definitions in 
but they don't work due to PR c++/84542. Add the attributes to the
declarations in  as well, and add a test.

libstdc++-v3/ChangeLog:

* include/bits/algorithmfwd.h (random_shuffle): Add deprecated
attribute.
* include/bits/stl_algo.h (random_shuffle): Correct comments.
* testsuite/25_algorithms/random_shuffle/1.cc: Disable
deprecated warnings.
* testsuite/25_algorithms/random_shuffle/59603.cc: Likewise.
* testsuite/25_algorithms/random_shuffle/moveable.cc: Likewise.
* testsuite/25_algorithms/random_shuffle/deprecated.cc: New
test.

[Bug tree-optimization/110817] New: [14 Regression] wrong code with vector compares on multiple targets

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 110817
   Summary: [14 Regression] wrong code with vector compares on
multiple targets
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu

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

Output:
$ aarch64-unknown-linux-gnu-gcc -O testcase.c -static && ./a.out
$ x86_64-pc-linux-gnu-gcc -O testcase.c -static && ./a.out
$ armv7a-hardfloat-linux-gnueabi-gcc -O testcase.c -static && ./a.out
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted
$ mips64el-unknown-linux-gnuabi64-gcc -O testcase.c -static && ./a.out
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted
$ mipsel-unknown-linux-gnu-gcc -O testcase.c -static && ./a.out
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted
$ powerpc64-unknown-linux-gnu-gcc -O testcase.c -static && ./a.out
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted
$ powerpc64le-unknown-linux-gnu-gcc -O testcase.c -static && ./a.out
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted
$ powerpc-unknown-linux-gnu-gcc -O testcase.c -static && ./a.out
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted
$ riscv64-unknown-linux-gnu-gcc -O testcase.c -static && ./a.out
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

armv7a-hardfloat-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-armv7a-hardfloat/bin/armv7a-hardfloat-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-20230726115220-g819f3d3692c-checking-yes-rtl-df-extra-sanitizer-armv7a-hardfloat/bin/../libexec/gcc/armv7a-hardfloat-linux-gnueabi/14.0.0/lto-wrapper
Target: armv7a-hardfloat-linux-gnueabi
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --enable-libsanitizer --with-float=hard
--with-fpu=vfpv4 --with-arch=armv7-a
--with-sysroot=/usr/armv7a-hardfloat-linux-gnueabi --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=armv7a-hardfloat-linux-gnueabi
--with-ld=/usr/bin/armv7a-hardfloat-linux-gnueabi-ld
--with-as=/usr/bin/armv7a-hardfloat-linux-gnueabi-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-20230726115220-g819f3d3692c-checking-yes-rtl-df-extra-sanitizer-armv7a-hardfloat
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230726 (experimental) (GCC) 

$

[Bug c++/106310] [12/13/14 Regression] lookup after this-> seems wrong for dependent lookup since r12-6754-g30f2c22def739211

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug c++/110816] Emit initialization code for empty class under -ftrivial-auto-var-init

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

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

--- Comment #1 from Jonathan Wakely  ---
The testcase is:


struct f { void crash(); };

void bar(bool cond) {
f t;
if(cond)
t.crash();
//user();
}

[Bug analyzer/104940] RFE: integrate analyzer with an SMT solver

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r14-2793-g9d804f9b2709b38235a2fe4c6705f2af6784aa2a
Author: David Malcolm 
Date:   Wed Jul 26 10:29:20 2023 -0400

analyzer: add symbol base class, moving region id to there [PR104940]

This patch introduces a "symbol" base class that region and svalue
both inherit from, generalizing the ID from the region class so it's
also used by svalues.  This gives a way of sorting regions and svalues
into creation order, which I've found useful in my experiments with
adding SMT support (PR analyzer/104940).

gcc/ChangeLog:
PR analyzer/104940
* Makefile.in (ANALYZER_OBJS): Add analyzer/symbol.o.

gcc/analyzer/ChangeLog:
PR analyzer/104940
* region-model-manager.cc
(region_model_manager::region_model_manager): Update for
generalizing region ids to also cover svalues.
(region_model_manager::get_or_create_constant_svalue): Likewise.
(region_model_manager::get_or_create_unknown_svalue): Likewise.
(region_model_manager::create_unique_svalue): Likewise.
(region_model_manager::get_or_create_initial_value): Likewise.
(region_model_manager::get_or_create_setjmp_svalue): Likewise.
(region_model_manager::get_or_create_poisoned_svalue): Likewise.
(region_model_manager::get_ptr_svalue): Likewise.
(region_model_manager::get_or_create_unaryop): Likewise.
(region_model_manager::get_or_create_binop): Likewise.
(region_model_manager::get_or_create_sub_svalue): Likewise.
(region_model_manager::get_or_create_repeated_svalue): Likewise.
(region_model_manager::get_or_create_bits_within): Likewise.
(region_model_manager::get_or_create_unmergeable): Likewise.
(region_model_manager::get_or_create_widening_svalue): Likewise.
(region_model_manager::get_or_create_compound_svalue): Likewise.
(region_model_manager::get_or_create_conjured_svalue): Likewise.
(region_model_manager::get_or_create_asm_output_svalue): Likewise.
(region_model_manager::get_or_create_const_fn_result_svalue):
Likewise.
(region_model_manager::get_region_for_fndecl): Likewise.
(region_model_manager::get_region_for_label): Likewise.
(region_model_manager::get_region_for_global): Likewise.
(region_model_manager::get_field_region): Likewise.
(region_model_manager::get_element_region): Likewise.
(region_model_manager::get_offset_region): Likewise.
(region_model_manager::get_sized_region): Likewise.
(region_model_manager::get_cast_region): Likewise.
(region_model_manager::get_frame_region): Likewise.
(region_model_manager::get_symbolic_region): Likewise.
(region_model_manager::get_region_for_string): Likewise.
(region_model_manager::get_bit_range): Likewise.
(region_model_manager::get_var_arg_region): Likewise.
(region_model_manager::get_region_for_unexpected_tree_code):
Likewise.
(region_model_manager::get_or_create_region_for_heap_alloc):
Likewise.
(region_model_manager::create_region_for_alloca): Likewise.
(region_model_manager::log_stats): Likewise.
* region-model-manager.h (region_model_manager::get_num_regions):
Replace with...
(region_model_manager::get_num_symbols): ...this.
(region_model_manager::alloc_region_id): Replace with...
(region_model_manager::alloc_symbol_id): ...this.
(region_model_manager::m_next_region_id): Replace with...
(region_model_manager::m_next_symbol_id): ...this.
* region-model.cc (selftest::test_get_representative_tree): Update
for generalizing region ids to also cover svalues.
(selftest::test_binop_svalue_folding): Likewise.
(selftest::test_state_merging): Likewise.
* region.cc (region::cmp_ids): Delete, in favor of
symbol::cmp_ids.
(region::region): Update for introduction of symbol base class.
(frame_region::get_region_for_local): Likewise.
(root_region::root_region): Likewise.
(symbolic_region::symbolic_region): Likewise.
* region.h: Replace include of "analyzer/complexity.h" with
"analyzer/symbol.h".
(class region): Make a subclass of symbol.
(region::get_id): Delete in favor of symbol::get_id.
(region::cmp_ids): Delete in favor of symbol::cmp_ids.
(region::get_complexity): Delete in favor of

[Bug c/110815] [static] not as useful as the nonnull attribute

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #1 from Martin Uecker  ---
Created attachment 55638
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55638=edit
patch




This patch would synthesize a nonnull attribute for such parameters, making
this fully equivalent.

[Bug c++/110809] ICE: in unify, at cp/pt.cc:25226 with floating-point NTTPs

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org

[Bug c++/110816] New: Emit initialization code for empty class under -ftrivial-auto-var-init

[serge.guelton--- via Gcc-bugs]

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

Bug ID: 110816
   Summary: Emit initialization code for empty class under
-ftrivial-auto-var-init
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: serge.guel...@telecom-bretagne.eu
  Target Milestone: ---

As show cased by https://godbolt.org/z/o5asYGq8G, gcc doesn't fill the byte
used by empty class/struct under -ftrivial-auto-var-init. This potentially
leaks a byte of memory.

[Bug c/110815] New: [static] not as useful as the nonnull attribute

[muecker at gwdg dot de via Gcc-bugs]

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

Bug ID: 110815
   Summary: [static] not as useful as the nonnull attribute
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: muecker at gwdg dot de
  Target Milestone: ---

C code increasingly uses

void foo(char buf[static 10]);

to indicate that buf is a non-null pointer.

GCC already has some warnings for this but all you would get with the nonnull
attribute. In particular, -Wnonnull-compare is missing. 


void
foo (int a[static 1])
{
  if ((void*)0 == a)  // should warn
return;
}


https://godbolt.org/z/E6E33Pa8h

[Bug c++/108080] ICE: in core_vals, at cp/module.cc:6262 with -fmodule-header

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

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

--- Comment #4 from Matthias Klose  ---
the original attached test case also fails

[Bug c++/108080] ICE: in core_vals, at cp/module.cc:6262 with -fmodule-header

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

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #3 from Matthias Klose  ---
seen with trunk 20230718:

$ cat foo.ii
module;
# 1 "" 1 3
namespace std {
template  struct hash;
}
typedef long unsigned size_t;
namespace std {
template  struct pair {
  int second;
  template  constexpr pair();
};
template 
void operator>(pair<_T1, _T2>, pair<_T1, _T2>);
template  struct __new_allocator {
  allocate___n() { allocate___n > this; }
};
template  using __allocator_base = __new_allocator<_Tp>;
template  struct allocator : __allocator_base {
  __attribute__allocator() {}
};
template class allocator;
template  struct array;
void get(array<1>);
template 
template 
constexpr pair<_T1, _T2>::pair() : second(get) {}
struct vector {
  friend hash;
};
void swap(vector);
template  struct __uniq_ptr_impl {
  swap() { std::swap; }
};
template  struct unique_ptr {
  __uniq_ptr_impl pointer;
};
struct shared_ptr {
  operator=(unique_ptr<>);
};
struct __shared_ptr {
  friend shared_ptr;
};
void operator==(__shared_ptr, __shared_ptr);
template  struct array {
  size() { size == 0; }
};
} // namespace std
#pragma GCC optimize ""
namespace std {
struct id {
  friend operator>(id, id);
};
struct hash;
} // namespace std
# 7 "" 2
export module spdlog_wrapper;

$ /usr/lib/gcc-snapshot/bin/g++ -std=c++20 -fmodules-ts -Wall -c foo.ii
foo.ii:7:8: internal compiler error: in core_vals, at cp/module.cc:6262
7 | namespace std {
  |^~
0x11e5613 trees_out::core_vals(tree_node*)
../../src/gcc/cp/module.cc:6262
0x11e6353 trees_out::tree_node_vals(tree_node*)
../../src/gcc/cp/module.cc:7218
0x11ec349 trees_out::tree_value(tree_node*)
../../src/gcc/cp/module.cc:9083
0x11e8faf trees_out::tree_node(tree_node*)
../../src/gcc/cp/module.cc:9281
0x11e59be trees_out::core_vals(tree_node*)
../../src/gcc/cp/module.cc:6171
0x11e6353 trees_out::tree_node_vals(tree_node*)
../../src/gcc/cp/module.cc:7218
0x11e6cb7 trees_out::decl_value(tree_node*, depset*)
../../src/gcc/cp/module.cc:7797
0x11ee50d depset::hash::find_dependencies(module_state*)
../../src/gcc/cp/module.cc:13328
0x11eea54 module_state::write_begin(elf_out*, cpp_reader*,
module_state_config&, unsigned int&)
../../src/gcc/cp/module.cc:17895
0x79f4e7 finish_module_processing(cpp_reader*)
../../src/gcc/cp/module.cc:20237
0x1bc5fd5 c_parse_final_cleanups()
../../src/gcc/cp/decl2.cc:5184
0x21034b1 c_common_parse_file()
../../src/gcc/c-family/c-opts.cc:1274
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.

[Bug libstdc++/110807] [13/14 Regression] Copy list initialisation of a vector raises a warning with -O2

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|13.2|13.3

[Bug libstdc++/110807] [13/14 Regression] Copy list initialisation of a vector raises a warning with -O2

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #4 from Jonathan Wakely  ---
A similar change in vector::_M_insert_range fixes this one though.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 106081, which changed state.

Bug 106081 Summary: missed vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106081

   What|Removed |Added

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

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 106081, which changed state.

Bug 106081 Summary: missed vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106081

   What|Removed |Added

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

[Bug middle-end/106081] missed vectorization

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #17 from Richard Biener  ---
Fixed now.

[Bug middle-end/106081] missed vectorization

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

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:5d09fb683a8abce49dc0992f5102aa0189f8f632

commit r14-2790-g5d09fb683a8abce49dc0992f5102aa0189f8f632
Author: Richard Biener 
Date:   Wed Jul 26 13:31:16 2023 +0200

tree-optimization/106081 - elide redundant permute

The following patch makes sure to elide a redundant permute that
can be merged with existing splats represented as load permutations
as we now do for non-grouped SLP loads.  This is the last bit
missing to fix this PR where the main fix was already done by
r14-2117-gdd86a5a69cbda4

PR tree-optimization/106081
* tree-vect-slp.cc
(vect_optimize_slp_pass::start_choosing_layouts):
Assign layout -1 to splats.

* gcc.dg/vect/pr106081.c: New testcase.

[Bug c/102989] Implement C2x's n2763 (_BitInt)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #55628|0   |1
is obsolete||

--- Comment #89 from Jakub Jelinek  ---
Created attachment 55637
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55637=edit
gcc14-bitint-wip.patch

Updated patch with -fsanitize=undefined _BitInt support.
Some of the runtime messages are inaccurate and some are totally incorrect, but
I'm afraid I can't do much until libubsan adds support for _BitInt, which I've
requested in https://github.com/llvm/llvm-project/issues/64100
For +-* overflow the messages look good until (inclusive) _BitInt(128) on
64-bit arches (or _BitInt(64) on 32-bit ones), larger print  instead
of numbers and think it is unsigned integer overflow rather than signed (but I
think that is better than what clang does when stuff just crashes with what it
emits or prints random numbers).
For / overflow, again up to _BitInt(128) it works fine, otherwise prints
division by zero rather than minimum / -1.  For shifts with non-mode precision
_BitInts, even small ones, there are various inaccuracies, because libubsan
think the mode precision is the precision of the type.

[Bug target/110758] [14 Regression] 8% hmmer regression on zen1/3 with -Ofast -march=native -flto between g:8377cf1bf41a0a9d (2023-07-05 01:46) and g:3a61ca1b9256535e (2023-07-06 16:56); g:d76d19c9bc5

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

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

Jan Hubicka  changed:

   What|Removed |Added

   Last reconfirmed||2023-07-26
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #3 from Jan Hubicka  ---
Regression between  
  g:d76d19c9bc5ef113 (2023-07-16 00:16) and 
  g:a5088dc3f5ef73c8 (2023-07-17 03:24)  
seems to be gone. 


The range is:
  1c6231c05bdccab3 (2023-07-21 03:06) and
  f33fdf9e7c038639 (2023-07-23 00:17)

Looking at the patches in range, it is likely the flat profile detection in 
vectorizer:

Author: Jan Hubicka 
Date:   Fri Jul 21 19:38:26 2023 +0200

Avoid scaling flat loop profiles of vectorized loops

[Bug middle-end/106081] missed vectorization

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #15 from rguenther at suse dot de  ---
On Wed, 26 Jul 2023, rsandifo at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106081
> 
> --- Comment #14 from rsandifo at gcc dot gnu.org  gnu.org> ---
> FWIW, changing:
> 
>   if (!STMT_VINFO_GROUPED_ACCESS (dr_stmt))
> continue;
> 
> to:
> 
>   if (!STMT_VINFO_GROUPED_ACCESS (dr_stmt))
> {
>   partition.layout = -1;
>   continue;
> }
> 
> in start_choosing_layouts fixes it for me.  We can then choose layout 1 for 
> the
> splat.
> 
> I think these conditions were carried over from the old code.  Without 
> checking
> further, I'm not 100% sure what effect relaxing them would have :)

I've added the above condition when introducing the support for splats
recently.  The above change indeed works - I'm going to give it further
testing.

[Bug sanitizer/110814] New: Address Sanitizer misses 'global-buffer-overflow' for const arrays

[egor_suvorov at mail dot ru via Gcc-bugs]

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

Bug ID: 110814
   Summary: Address Sanitizer misses 'global-buffer-overflow' for
const arrays
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egor_suvorov at mail dot ru
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Consider the following code (https://godbolt.org/z/ddz6q8xra):

const int a[1];
int b[1];
int main() {
int x = a[1];  // line 4
int y = b[1];  // line 5
}

Here GCC's ASan fails in the line 5 only, completely missing array overflow for
'a' in line 4:

==1==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00404124
at pc 0x004011ad bp 0x7fffbe0976e0 sp 0x7fffbe0976d8
READ of size 4 at 0x00404124 thread T0
#0 0x4011ac in main /app/example.c:5
#1 0x7f01c82ad082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x4010ad in _start (/app/output.s+0x4010ad) (BuildId:
8b89d3acf504057c132647f3c9558b7377ff8ce0)

0x00404124 is located 0 bytes after global variable 'b' defined in
'/app/example.c:2:5' (0x404120) of size 4
SUMMARY: AddressSanitizer: global-buffer-overflow /app/example.c:5 in main

The only different between lines 4 and 5 is that 'a' is const. Clang's ASan
correctly catches the error in line 4.

[Bug libstdc++/110807] [13/14 Regression] Copy list initialisation of a vector raises a warning with -O2

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

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

--- Comment #3 from Jonathan Wakely  ---
I think this is the same warning that causes libstdc++ testsuite failures when
testing with --target_board=unix/-D_GLIBCXX_DEBUG

FAIL: 23_containers/vector/bool/swap.cc (test for excess errors)

I thought I'd already reported that, but I can't find it.

The library allocates space for N elements then copies n elements:

  vector(const vector& __x)
  : _Base(_Bit_alloc_traits::_S_select_on_copy(__x._M_get_Bit_allocator()))
  {
_M_initialize(__x.size());
_M_copy_aligned(__x.begin(), __x.end(), begin());
  }

We probably have the usual problem that GCC thinks allocating memory might
alter __x because it's a global, and so in theory (but never in practice) the
program could replace operator new with something insane that modifies the
global.

I tried changing the constructor to:

const_iterator __xbegin = __x.begin(), __xend = __x.end();
_M_initialize(__x.size());
_M_copy_aligned(__xbegin, __xend, begin());

That fixes the library test FAILs, but not the case in this bug report.

[Bug testsuite/110763] FAIL: gcc.dg/ubsan/object-size-dyn.c -O2 execution test

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

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Siddhesh Poyarekar  ---
Fixed.

[Bug web/53257] GCC wiki takes a very, very long time to save a page

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Jonathan Wakely  ---
I think this was fixed by periodically culling user accounts that have never
edited a page (which removes all the spam accounts that get created).

[Bug testsuite/110763] FAIL: gcc.dg/ubsan/object-size-dyn.c -O2 execution test

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Siddhesh Poyarekar
:

https://gcc.gnu.org/g:386df7ce7b38ef00e28080a779ef2dfd6949cf15

commit r14-2789-g386df7ce7b38ef00e28080a779ef2dfd6949cf15
Author: Siddhesh Poyarekar 
Date:   Fri Jul 21 11:13:58 2023 -0400

testsuite/110763: Ensure zero return from test

The test deliberately reads beyond bounds to exersize ubsan and the
return value may be anything, based on previous allocations.  The OFF
test caters for it by ANDing the return with 0, do the same for the DYN
test.

gcc/testsuite/ChangeLog:

PR testsuite/110763
* gcc.dg/ubsan/object-size-dyn.c (dyn): New parameter RET.
(main): Use it.

Signed-off-by: Siddhesh Poyarekar 

[Bug middle-end/106081] missed vectorization

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

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

--- Comment #14 from rsandifo at gcc dot gnu.org  
---
FWIW, changing:

  if (!STMT_VINFO_GROUPED_ACCESS (dr_stmt))
continue;

to:

  if (!STMT_VINFO_GROUPED_ACCESS (dr_stmt))
{
  partition.layout = -1;
  continue;
}

in start_choosing_layouts fixes it for me.  We can then choose layout 1 for the
splat.

I think these conditions were carried over from the old code.  Without checking
further, I'm not 100% sure what effect relaxing them would have :)

[Bug middle-end/106081] missed vectorization

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

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

--- Comment #13 from rsandifo at gcc dot gnu.org  
---
(In reply to Richard Biener from comment #12)
> Btw, I see we actually materialize a permute before the splat:
> 
> t.c:14:24: note:   node 0x5b311c0 (max_nunits=1, refcnt=2) vector(2) double
> t.c:14:24: note:   op: VEC_PERM_EXPR
> t.c:14:24: note:stmt 0 _1 = *k_50;
> t.c:14:24: note:stmt 1 _1 = *k_50;
> t.c:14:24: note:stmt 2 _1 = *k_50;
> t.c:14:24: note:stmt 3 _1 = *k_50;
> t.c:14:24: note:lane permutation { 0[3] 0[2] 0[1] 0[0] }
> t.c:14:24: note:children 0x5b30fc0
> t.c:14:24: note:   node 0x5b30fc0 (max_nunits=2, refcnt=1) vector(2) double
> t.c:14:24: note:   op template: _1 = *k_50;
> t.c:14:24: note:stmt 0 _1 = *k_50;
> t.c:14:24: note:stmt 1 _1 = *k_50;
> t.c:14:24: note:stmt 2 _1 = *k_50;
> t.c:14:24: note:stmt 3 _1 = *k_50;
> t.c:14:24: note:load permutation { 0 0 0 0 }
> 
> this is because vect_optimize_slp_pass::get_result_with_layout doesn't
> seem to consider load permutations?
Yeah.  That's because, if to_layout_i != from_layout_i, the caller
is asking for a different layout from the one that we picked for
the load.  If we wanted to change the load permutation in-place
for the given to_layout_i, we'd need to duplicate the load too,
which didn't seem like a good trade-off.

[Bug middle-end/106081] missed vectorization

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

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

--- Comment #12 from Richard Biener  ---
Btw, I see we actually materialize a permute before the splat:

t.c:14:24: note:   node 0x5b311c0 (max_nunits=1, refcnt=2) vector(2) double
t.c:14:24: note:   op: VEC_PERM_EXPR
t.c:14:24: note:stmt 0 _1 = *k_50;
t.c:14:24: note:stmt 1 _1 = *k_50;
t.c:14:24: note:stmt 2 _1 = *k_50;
t.c:14:24: note:stmt 3 _1 = *k_50;
t.c:14:24: note:lane permutation { 0[3] 0[2] 0[1] 0[0] }
t.c:14:24: note:children 0x5b30fc0
t.c:14:24: note:   node 0x5b30fc0 (max_nunits=2, refcnt=1) vector(2) double
t.c:14:24: note:   op template: _1 = *k_50;
t.c:14:24: note:stmt 0 _1 = *k_50;
t.c:14:24: note:stmt 1 _1 = *k_50;
t.c:14:24: note:stmt 2 _1 = *k_50;
t.c:14:24: note:stmt 3 _1 = *k_50;
t.c:14:24: note:load permutation { 0 0 0 0 }

this is because vect_optimize_slp_pass::get_result_with_layout doesn't
seem to consider load permutations?  It's the value-numbering we perform
that in the end elides the redundant permute.

I have the feeling something doesn't fit together exactly, during
materialize () we apply the chosen layout to the partitions, then
eliminate redundant permutes but we still end up with
get_result_with_layout adding the above permute.

I can add the same logic as I've added to change_layout_cost also to
get_result_with_layout but as said, it feels like I'm missing something ...

[Bug libgomp/110813] New: [OpenMP] omp_target_memcpy_rect (+ strided 'target update'): Improve GCN performance and contiguous subranges

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

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

Bug ID: 110813
   Summary: [OpenMP] omp_target_memcpy_rect (+ strided 'target
update'): Improve GCN performance and contiguous
subranges
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization, openmp
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---

omp_target_memcpy_rect_worker is used by omp_target_memcpy_rect and
omp_target_memcpy_rect_async.

It is also used when passing strided memory to 'target update' - either on OG13
or when applying the patch
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623502.html - as can be
seen on OG13:
https://github.com/gcc-mirror/gcc/blob/devel/omp/gcc-13/libgomp/target.c#L5689-L5843
(links to omp_target_memcpy_rect_worker; lines might be off when the file was
changed after I linked there.)


ISSUES:

* The current algorithm always loops until dim == 1,
  even if the referenced memory is contiguous

That's the case for _rect if src_dim == dst_dim == volume such as:
 volume=[V1,N2,N3], ..., dst_dimension=[D1,N2,N3], ... src_dimension=[S1,N2,N3]
the inner two dimensions are contiguous, only the outermost isn't.

Likewise for  '!$omp target update to(cont_array(:,:,::2)'


* While for nvptx, a patch exists (see below) that handles _rect copying
for dim=2 and dim=3 more efficiently (CUDA functions), for GCN such a feature
is currently missing.

EXPECTED:
* Improve performance if partially contiguous
* Improve performance on GCN


Cross ref:
- "[patch] OpenMP: Call cuMemcpy2D/cuMemcpy3D for nvptx for
omp_target_memcpy_rect"
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625465.html
(as mentioned in that patch, cross ref to:
- PR101581 - [OpenMP] omp_target_memcpy – support inter-device memcpy )

[Bug middle-end/106081] missed vectorization

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

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

--- Comment #11 from Richard Biener  ---
(In reply to rsand...@gcc.gnu.org from comment #10)
> (In reply to Richard Biener from comment #9)
[...]
> > The following elides the unnecessary permutation for this special case
> > (but not the general case):
> > 
> > diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
> > index e4430248ab5..e9048a61891 100644
> > --- a/gcc/tree-vect-slp.cc
> > +++ b/gcc/tree-vect-slp.cc
> > @@ -4389,6 +4389,19 @@ vect_optimize_slp_pass::change_layout_cost (slp_tree
> > node,
> >if (from_layout_i == to_layout_i)
> >  return 0;
> >  
> > +  /* When there's a uniform load permutation permutating that in any
> > + way is free.  */
> > +  if (SLP_TREE_LOAD_PERMUTATION (node).exists ())
> > +{
> > +  unsigned l = SLP_TREE_LOAD_PERMUTATION (node)[0];
> > +  unsigned i;
> > +  for (i = 1; i < SLP_TREE_LOAD_PERMUTATION (node).length (); ++i)
> > +   if (SLP_TREE_LOAD_PERMUTATION (node)[i] != l)
> > + break;
> > +  if (i == SLP_TREE_LOAD_PERMUTATION (node).length ())
> > +   return 0;
> > +}
> > +
> >auto_vec children (1);
> >children.quick_push (node);
> >auto_lane_permutation_t perm (SLP_TREE_LANES (node));
> > 
> > I'm not sure this is the correct place to factor in cost savings
> > materialization would give.  Is it?
> Yeah, I think so.  The patch LGTM.  I don't know if it's worth
> caching the “all the same element” result, but probably not.

Yeah, I thought of changing the load_permutation representation to
vec_perm_indices but then as I consider merging lane and load permutes
that would be wrong step.

I've thought of generalizing the above but then change_layout_cost
is always positive but for example when doing { 3, 2, 1, 0 } ontop
an existing load permutation of { 3, 2, 1, 0 } the cost should be
negative?

Anyway, going to test the above patch.

[Bug target/110762] inappropriate use of SSE (or AVX) insns for v2sf mode operations

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

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

--- Comment #19 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r14-2786-gade30fad6669e5f34ca4c587c724d74ecc953175
Author: Uros Bizjak 
Date:   Wed Jul 26 11:10:46 2023 +0200

i386: Clear upper half of XMM register for V2SFmode operations [PR110762]

Clear the upper half of a V4SFmode operand register in front of all
potentially trapping instructions. The testcase:

--cut here--
typedef float v2sf __attribute__((vector_size(8)));
typedef float v4sf __attribute__((vector_size(16)));

v2sf test(v4sf x, v4sf y)
{
  v2sf x2, y2;

  x2 = __builtin_shufflevector (x, x, 0, 1);
  y2 = __builtin_shufflevector (y, y, 0, 1);

  return x2 + y2;
}
--cut here--

now compiles to:

movq%xmm1, %xmm1# 9 [c=4 l=4]  *vec_concatv4sf_0
movq%xmm0, %xmm0# 10[c=4 l=4]  *vec_concatv4sf_0
addps   %xmm1, %xmm0# 11[c=12 l=3]  *addv4sf3/0

This approach addresses issues with exceptions, as well as issues with
denormal/invalid values. An obvious exception to the rule is a division,
where the value != 0.0 should be loaded into the upper half of the
denominator to avoid division by zero exception.

The patch effectively tightens the solution from PR95046 by clearing upper
halves of all operand registers before every potentially trapping
instruction.
The testcase:

--cut here--
typedef float __attribute__((vector_size(8))) v2sf;

v2sf test (v2sf a, v2sf b, v2sf c)
{
  return a * b - c;
}
--cut here--

compiles to:

movq%xmm1, %xmm1# 8 [c=4 l=4]  *vec_concatv4sf_0
movq%xmm0, %xmm0# 9 [c=4 l=4]  *vec_concatv4sf_0
movq%xmm2, %xmm2# 12[c=4 l=4]  *vec_concatv4sf_0
mulps   %xmm1, %xmm0# 10[c=16 l=3]  *mulv4sf3/0
movq%xmm0, %xmm0# 13[c=4 l=4]  *vec_concatv4sf_0
subps   %xmm2, %xmm0# 14[c=12 l=3]  *subv4sf3/0

The implementation emits V4SFmode operation, so we can remove all
"emulated"
SSE2 V2SFmode trapping instructions and remove "emulated" SSE2 V2SFmode
alternatives from 3dNOW! insn patterns.

PR target/110762

gcc/ChangeLog:

* config/i386/i386.md (plusminusmult): New code iterator.
* config/i386/mmx.md (mmxdoublevecmode): New mode attribute.
(movq__to_sse): New expander.
(v2sf3): Macroize expander from addv2sf3,
subv2sf3 and mulv2sf3 using plusminusmult code iterator.  Rewrite
as a wrapper around V4SFmode operation.
(mmx_addv2sf3): Change operand 1 and operand 2 predicates to
nonimmediate_operand.
(*mmx_addv2sf3): Remove SSE alternatives.  Change operand 1 and
operand 2 predicates to nonimmediate_operand.
(mmx_subv2sf3): Change operand 2 predicate to nonimmediate_operand.
(mmx_subrv2sf3): Change operand 1 predicate to
nonimmediate_operand.
(*mmx_subv2sf3): Remove SSE alternatives.  Change operand 1 and
operand 2 predicates to nonimmediate_operand.
(mmx_mulv2sf3): Change operand 1 and operand 2 predicates to
nonimmediate_operand.
(*mmx_mulv2sf3): Remove SSE alternatives.  Change operand 1 and
operand 2 predicates to nonimmediate_operand.
(divv2sf3): Rewrite as a wrapper around V4SFmode operation.
(v2sf3): Ditto.
(mmx_v2sf3): Change operand 1 and operand 2
predicates to nonimmediate_operand.
(*mmx_v2sf3): Remove SSE alternatives.  Change
operand 1 and operand 2 predicates to nonimmediate_operand.
(mmx_ieee_v2sf3): Ditto.
(sqrtv2sf2): Rewrite as a wrapper around V4SFmode operation.
(*mmx_haddv2sf3_low): Ditto.
(*mmx_hsubv2sf3_low): Ditto.
(vec_addsubv2sf3): Ditto.
(*mmx_maskcmpv2sf3_comm): Remove.
(*mmx_maskcmpv2sf3): Remove.
(vec_cmpv2sfv2si): Rewrite as a wrapper around V4SFmode operation.
(vcondv2sf): Ditto.
(fmav2sf4): Ditto.
(fmsv2sf4): Ditto.
(fnmav2sf4): Ditto.
(fnmsv2sf4): Ditto.
(fix_truncv2sfv2si2): Ditto.
(fixuns_truncv2sfv2si2): Ditto.
(mmx_fix_truncv2sfv2si2): Remove SSE alternatives.
Change operand 1 predicate to nonimmediate_operand.
(floatv2siv2sf2): Rewrite as a wrapper around V4SFmode operation.
(floatunsv2siv2sf2): Ditto.
(mmx_floatv2siv2sf2): Remove SSE alternatives.
Change operand 1 predicate to nonimmediate_operand.
(nearbyintv2sf2): Rewrite as a wrapper around V4SFmode operation.

[Bug libgomp/101581] [OpenMP] omp_target_memcpy – support inter-device memcpy

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

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

--- Comment #1 from Tobias Burnus  ---
For omp_target_memcpy_rect, see:

"[patch] OpenMP: Call cuMemcpy2D/cuMemcpy3D for nvptx for
omp_target_memcpy_rect"
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625465.html

[Bug sanitizer/110799] [tsan] False positive due to -fhoist-adjacent-loads

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

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

--- Comment #14 from Richard Biener  ---
The PRE/hoisting bug is fixed now.

[Bug middle-end/106081] missed vectorization

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

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

--- Comment #10 from rsandifo at gcc dot gnu.org  
---
(In reply to Richard Biener from comment #9)
> So I can adjust change_layout_cost in a bit awkward way, but it seems that
> internal_node_cost would already work out that a permute can be merged into
> an existing permute.
Right.

> It seems that existing permutes are not recorded in the "layout".
They should be if they're bijective, via:

  else if (SLP_TREE_CODE (node) == VEC_PERM_EXPR
   && SLP_TREE_CHILDREN (node).length () == 1
   && (child = SLP_TREE_CHILDREN (node)[0])
   && (TYPE_VECTOR_SUBPARTS (SLP_TREE_VECTYPE (child))
   .is_constant ()))
{
  /* If the child has the same vector size as this node,
 reversing the permutation can make the permutation a no-op.
 In other cases it can change a true permutation into a
 full-vector extract.  */
  tmp_perm.reserve (SLP_TREE_LANES (node));
  for (unsigned j = 0; j < SLP_TREE_LANES (node); ++j)
tmp_perm.quick_push (SLP_TREE_LANE_PERMUTATION (node)[j].second);
}

> Also vectorizable_slp_permutation_1 doesn't try to elide permutes that
> are noop based on knowledge of the layout of 'node', say a permute
> { 1 0 3 2 } of a { _1, _1, _2, _2 } node would be noop.
To do that in general, I think we'd need to value-number each
element of each node (which sounds doable).  But I guess doing
it at leaves would be better than nothing.

> But change_layout_cost does MAX (count, 1) on its result anyway.
At the moment, yes, because having from_layout_i != to_layout_i
for identical layouts would be a consistency failure.

> The following elides the unnecessary permutation for this special case
> (but not the general case):
> 
> diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
> index e4430248ab5..e9048a61891 100644
> --- a/gcc/tree-vect-slp.cc
> +++ b/gcc/tree-vect-slp.cc
> @@ -4389,6 +4389,19 @@ vect_optimize_slp_pass::change_layout_cost (slp_tree
> node,
>if (from_layout_i == to_layout_i)
>  return 0;
>  
> +  /* When there's a uniform load permutation permutating that in any
> + way is free.  */
> +  if (SLP_TREE_LOAD_PERMUTATION (node).exists ())
> +{
> +  unsigned l = SLP_TREE_LOAD_PERMUTATION (node)[0];
> +  unsigned i;
> +  for (i = 1; i < SLP_TREE_LOAD_PERMUTATION (node).length (); ++i)
> +   if (SLP_TREE_LOAD_PERMUTATION (node)[i] != l)
> + break;
> +  if (i == SLP_TREE_LOAD_PERMUTATION (node).length ())
> +   return 0;
> +}
> +
>auto_vec children (1);
>children.quick_push (node);
>auto_lane_permutation_t perm (SLP_TREE_LANES (node));
> 
> I'm not sure this is the correct place to factor in cost savings
> materialization would give.  Is it?
Yeah, I think so.  The patch LGTM.  I don't know if it's worth
caching the “all the same element” result, but probably not.

> Are explicit VEC_PERM nodes also still there in the optimization
> process or are they turned into sth implicit?
They're still there.  The current algorithm inherits the old
restriction that candidate layouts must be bijective, and not
all VEC_PERM_EXPRs are.  So some VEC_PERM_EXPRs would have to
be explicit whatever happens.  Same for non-bijective load
permutations.