[Bug tree-optimization/115629] Inefficient if-convert of masked conditionals

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

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

--- Comment #7 from Richard Biener  ---
(In reply to Tamar Christina from comment #6)
> (In reply to rguent...@suse.de from comment #5)
> > > In this case, the second load is conditional on the first load mask,  
> > > which
> > > means it's already done an AND.
> > > And crucially inverting it means you also inverted both conditions.
> > > 
> > > So there are some superflous masking operations happening.  But I guess 
> > > that's
> > > a separate bug.  Shall I just add some tests here and close it and open a 
> > > new
> > > PR?
> > 
> > Not sure if that helps - do we fully understand this is a separate issue and
> > not related to how we if-convert?
> > 
> 
> if-convert looks ok to me:
> 
>[local count: 955630226]:
>   # i_28 = PHI 
>   _1 = (long unsigned int) i_28;
>   _2 = _1 * 4;
>   _3 = a_16(D) + _2;
>   _4 = *_3;
>   _31 = _4 != 0;
>   _55 = _54 + _2;
>   _6 = (int *) _55;
>   _56 = ~_31;
>   _7 = .MASK_LOAD (_6, 32B, _56);
>   _22 = _7 == 0;
>   _34 = _22 & _56;
>   _58 = _57 + _2;
>   _9 = (int *) _58;
>   iftmp.0_19 = .MASK_LOAD (_9, 32B, _34);
>   _61 = _4 | _7;
>   _35 = _61 != 0;
>   _60 = _59 + _2;
>   _8 = (int *) _60;
>   iftmp.0_21 = .MASK_LOAD (_8, 32B, _35);
>   iftmp.0_12 = _34 ? iftmp.0_19 : iftmp.0_21;
>   _10 = res_23(D) + _2;
>   *_10 = iftmp.0_12;
>   i_25 = i_28 + 1;
>   if (n_15(D) > i_25)
> goto ; [89.00%]
>   else
> goto ; [11.00%]
> 
> I think what's missing here is that
> 
>   _7 = .MASK_LOAD (_6, 32B, _56);
>   _22 = _7 == 0;
>   _34 = _22 & _56;
>   iftmp.0_19 = .MASK_LOAD (_9, 32B, _34);
> 
> in itself produces an AND. namely (_7 && _34) && _56 where _56 is the loop
> mask.
> 
> my (probably poor understanding) is that the mask tracking in the vectorizer
> attempts to prevent to keep masks and their inverse live at the same time.
> 
> but that this code in this case doesn't track masks introduced by nested
> MASK_LOADS.  at least, that's my naive interpretation.

Hmm, without carrying out the math it seems like for

  iftmp.0_19 = .MASK_LOAD (_9, 32B, _34);
..
  iftmp.0_21 = .MASK_LOAD (_8, 32B, _35);
  iftmp.0_12 = _34 ? iftmp.0_19 : iftmp.0_21;

the _34 conditional and the _34 and _35 masks would make it so this
could be written with sth like

  iftmp.0_12 = iftmp.0_19 | iftmp.0_21;

but a detail might have escaped me ;)  Is that what you're trying to say
as well?  That of course still leaves maybe partly redundant mask
computations.  In the ifcvt dump it doesn't help that != 0 is sometimes
elided and sometimes not ...

IIRC the vectorizer at some point tries to optimize loop mask and mask
mask?  Maybe we need to teach that mechanism to track how mask masks are
combined from other masks via & and | to improve the masks used?

This could be also a separate mask optimization phase on the SLP
representation.  While it doesn't represent loop masking at least
it does for .MASK_LOAD and .MASK_STORE (and .COND_*).

[Bug tree-optimization/115723] [14 Regression] SPEC CPU2017 521/621 build error with -Ofast and AVX512 enabled(-ftree-vectorize?)

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

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

--- Comment #14 from Richard Biener  ---
(In reply to edison from comment #13)
> (In reply to GCC Commits from comment #11)
> > The master branch has been updated by Richard Biener :
> > 
> > https://gcc.gnu.org/g:286cda3461d6f5ce7d911d3f26bd4975ea7ea11d
> > 
> > commit r15-1745-g286cda3461d6f5ce7d911d3f26bd4975ea7ea11d
> > Author: Richard Biener 
> > Date:   Mon Jul 1 10:06:55 2024 +0200
> > 
> > tree-optimization/115723 - ICE with .COND_ADD reduction
> > 
> > The following fixes an ICE with a .COND_ADD discovered as reduction
> > even though its else value isn't the reduction chain link but a
> > constant.  This would be wrong-code with --disable-checking I think.
> > 
> > PR tree-optimization/115723
> > * tree-vect-loop.cc (check_reduction_path): For a .COND_ADD
> > verify the else value also refers to the reduction chain op.
> > 
> > * gcc.dg/vect/pr115723.c: New testcase.
> 
> Does this fix work with gcc 14.1? I have try to use it to replace the same
> file in gcc 14.1 and then build gcc 14.1, got these error:

Yes, the git revision cherry-picks to GCC 14.1 (well, the GCC 14 branch head
which is what I tested) just fine.  I've actually verified it fixes building
of 521 with patched GCC 14.  You can't simply replace whole files though.

[Bug tree-optimization/115659] powerpc fallout from removing vcond{,u,eq} patterns

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

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

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Kewen Lin :

https://gcc.gnu.org/g:56670281c6db19d75c7b63e38971ab84681b245c

commit r15-1763-g56670281c6db19d75c7b63e38971ab84681b245c
Author: Kewen Lin 
Date:   Tue Jul 2 02:13:35 2024 -0500

isel: Fold more in gimple_expand_vec_cond_expr [PR115659]

As PR115659 shows, assuming c = x CMP y, there are some
folding chances for patterns r = c ? -1/z : z/0.

For r = c ? -1 : z, it can be folded into:
  - r = c | z (with ior_optab supported)
  - or r = c ? c : z

while for r = c ?  z : 0, it can be foled into:
  - r = c & z (with and_optab supported)
  - or r = c ? z : c

This patch is to teach ISEL to take care of them and also
remove the redundant gsi_replace as the caller of function
gimple_expand_vec_cond_expr will handle it.

PR tree-optimization/115659

gcc/ChangeLog:

* gimple-isel.cc (gimple_expand_vec_cond_expr): Add more foldings
for
patterns x CMP y ? -1 : z and x CMP y ? z : 0.

[Bug target/115734] Missed optimization: carry chains with __builtin_addc missed except on x86

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||arm aarch64

--- Comment #1 from Richard Biener  ---
It would probably be good to split this bug for the missed optimization when
using __builtin_addc (on arm and aarch64 at least) and the missed optimization
to detect addc with the open-coded variant.

I've classified the bug as for the first issue.

[Bug target/115741] [15 Regression] RISC-V: ICE in vectorizable_load, at tree-vect-stmts.cc:11524

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2024-07-02
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Target Milestone|--- |15.0
 Target||riscv
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
Summary|[15] RISC-V: ICE in |[15 Regression] RISC-V: ICE
   |vectorizable_load, at   |in vectorizable_load, at
   |tree-vect-stmts.cc:11524|tree-vect-stmts.cc:11524

--- Comment #1 from Richard Biener  ---
I'm guessing you hit

/* For loop vectorization we now should have
   an alternate type or LOOP_VINFO_PEELING_FOR_GAPS
   set.  */
if (loop_vinfo)
  gcc_assert (new_vtype
  || LOOP_VINFO_PEELING_FOR_GAPS
   (loop_vinfo));

it's always helpful to quote the line an assert happens on given it "moves" a
lot during development.  I can reproduce it with a cross.

[Bug target/115741] [15 Regression] RISC-V: ICE in vectorizable_load, at tree-vect-stmts.cc:11524

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

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

--- Comment #2 from Richard Biener  ---
So this is the VMAT_CONTIGUOUS_REVERSE case.  I have a patch.

[Bug rtl-optimization/109009] Shrink Wrap missed opportunity

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #13 from Andrew Pinski  ---
Looks to be fixed after r15-1619-g3b9b8d6cfdf593

[Bug target/110473] vec_convert for aarch64 seems to lower to something which should be improved

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|NEW |ASSIGNED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=107432

--- Comment #2 from Andrew Pinski  ---
Fixed by r15-1677-gc320a7efcd35ba .

I will add a testcase.

veclower now produces:
v4si f (v4si a, v4si b)
{
  v4si t1;
  v4hi t;

   [local count: 1073741824]:
  t_2 = (v4hi) a_1(D);
  t1_3 = (v4si) t_2;
  return t1_3;

}

[Bug target/115739] Building cross-compiler to sparc-wrs-vxworks fails since r15-1594-g55947b32c38a40

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

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

--- Comment #3 from Eric Botcazou  ---
The fix is OK for mainline, thanks!

[Bug c/115729] case label does not reduce to an integer constant

[stsp at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #2 from Stas Sergeev  ---
> rejects-valid

You meant accepts-invalid?

Anyway, constexpr makes it consistent, thanks!

[Bug target/107432] __builtin_convertvector generates inefficient code

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

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

Hongtao Liu  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||liuhongt at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #13 from Hongtao Liu  ---
Fixed in GCC15.

[Bug target/107432] __builtin_convertvector generates inefficient code

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug other/115742] New: MacOS Monterey : /usr/include not found

[bug-reports.delphin at laposte dot net via Gcc-bugs]

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

Bug ID: 115742
   Summary: MacOS Monterey : /usr/include not found
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bug-reports.delphin at laposte dot net
  Target Milestone: ---

Created attachment 58554
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58554&action=edit
config.log

macOS : Monterey 12.7.5
Mac mini 2014 (i5 processor)
Xcode and compilation tools : 14.x (please see the config.log enclosed).

"BUG" : during the compilation, a test is performed by the GCC process. This
test looks for the(a) /usr/include (system). The process of compilation fails
and stops because there is nomore /usr/include folder under Monterey (see the
make.log file).

In fact, one can see it somewhere in the Contents of Xcode application (to see
it, do Show Package Contents applying it to Xcode).

It fails with the following attempts to fix this issue :
1/ with Xcode only installed ;
2/ with the Command Line Tools only installed ;
3/ with both Xcode and Command Line tools.

After these failures, I mad the decision to keep only Xcode in my computer. I
succeed to compile and to build all other open sources I need, including the
GNU ones.

Please note that I check /usr/bin/clang too : it seems that it should not be
the compiler itself, because I saw that it contains many xml lines inside.

Remark : with my former and "old" mac Mini with Lion, all the GCC suites were
well compiled and installed, in particular with previous versions of GNU GCC I
compiled (e.g., v. 49x, v. 75.x).

A wish : to fix this issue, for example in removing the '/usr/include' inside
test and checking it to see if it works.

Eventaulley, no GNU gcc installed, no gfortran at all...

Thank you !


Encl.

[Bug other/115742] MacOS Monterey : /usr/include not found

[bug-reports.delphin at laposte dot net via Gcc-bugs]

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

--- Comment #1 from bug-reports.delphin at laposte dot net ---
Created attachment 58555
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58555&action=edit
What configure dsipalys

[Bug libstdc++/115743] New: libstdc++: pretty printer is installed in wrong location on cross compiled i686|x86_64-w64-mingw32 target

[ralf.habacker at freenet dot de via Gcc-bugs]

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

Bug ID: 115743
   Summary: libstdc++: pretty printer is installed in wrong
location on cross compiled i686|x86_64-w64-mingw32
target
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ralf.habacker at freenet dot de
  Target Milestone: ---

Created attachment 58556
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58556&action=edit
Patch

Building native gcc on linux installs the gdb printer for libstdc++ into 

/usr/share/gcc-13
/usr/share/gcc-13/python
/usr/share/gcc-13/python/libstdcxx
/usr/share/gcc-13/python/libstdcxx/__init__.py
/usr/share/gcc-13/python/libstdcxx/v6
/usr/share/gcc-13/python/libstdcxx/v6/__init__.py
/usr/share/gcc-13/python/libstdcxx/v6/printers.py
/usr/share/gcc-13/python/libstdcxx/v6/xmethods.py

but building gcc for the mentioned target with gcc version 13.2.0 installs the
gdb printer for libstdc++ into

/usr/i686-w64-mingw32/sys-root/mingw/lib/gcc/i686-w64-mingw32/share/gcc-13.2.0/python
/usr/i686-w64-mingw32/sys-root/mingw/lib/gcc/i686-w64-mingw32/share/gcc-13.2.0/python/libstdcxx
/usr/i686-w64-mingw32/sys-root/mingw/lib/gcc/i686-w64-mingw32/share/gcc-13.2.0/python/libstdcxx/__init__.py
/usr/i686-w64-mingw32/sys-root/mingw/lib/gcc/i686-w64-mingw32/share/gcc-13.2.0/python/libstdcxx/v6
/usr/i686-w64-mingw32/sys-root/mingw/lib/gcc/i686-w64-mingw32/share/gcc-13.2.0/python/libstdcxx/v6/__init__.py
/usr/i686-w64-mingw32/sys-root/mingw/lib/gcc/i686-w64-mingw32/share/gcc-13.2.0/python/libstdcxx/v6/printers.py
/usr/i686-w64-mingw32/sys-root/mingw/lib/gcc/i686-w64-mingw32/share/gcc-13.2.0/python/libstdcxx/v6/xmethods.py

where they are expected to be installed into 

/usr/i686-w64-mingw32/sys-root/mingw/share/gcc-13.2.0/python
/usr/i686-w64-mingw32/sys-root/mingw/share/gcc-13.2.0/python/libstdcxx
/usr/i686-w64-mingw32/sys-root/mingw/share/gcc-13.2.0/python/libstdcxx/__init__.py
/usr/i686-w64-mingw32/sys-root/mingw/share/gcc-13.2.0/python/libstdcxx/v6
/usr/i686-w64-mingw32/sys-root/mingw/share/gcc-13.2.0/python/libstdcxx/v6/__init__.py
/usr/i686-w64-mingw32/sys-root/mingw/share/gcc-13.2.0/python/libstdcxx/v6/printers.py
/usr/i686-w64-mingw32/sys-root/mingw/share/gcc-13.2.0/python/libstdcxx/v6/xmethods.py

The attached patch was used to fix this problem for
https://build.opensuse.org/package/show/openSUSE:Factory/mingw32-gcc.

[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

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

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

--- Comment #14 from Robin Dapp  ---
Thanks Kito.  In addition, I asked Daniel to have a look into the vmv.s.x 
policy handling.  From what I saw it is special in that it currently always
uses undisturbed and doesn't observe the specified policy.

[Bug other/115742] MacOS Monterey : /usr/include not found

[bug-reports.delphin at laposte dot net via Gcc-bugs]

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

--- Comment #2 from bug-reports.delphin at laposte dot net ---
NB make.log too big. So, final message (botom of make.log) is :

warning: unknown warning option '-Wconditionally-supported'
[-Wunknown-warning-option]
warning: unknown warning option '-Wconditionally-supported'
[-Wunknown-warning-option]
1 warning generated.
1 warning generated.
/usr/bin/clang++ -std=c++11 -pie   -g -DIN_GCC   -fno-strict-aliasing
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -pie 
-o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o
c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o
c/c-fold.o c/gimple-parser.o c-family/c-common.o c-family/c-cppbuiltin.o
c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o
c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o
c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o
c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o
c-family/c-ubsan.o c-family/known-headers.o c-family/c-attribs.o
c-family/c-warn.o c-family/c-spellcheck.o i386-c.o darwin-c.o \
  cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a  -liconv ../libbacktrace/.libs/libbacktrace.a
../libiberty/pic/libiberty.a ../libdecnumber/libdecnumber.a 
-L/Users/laurentdelphin/_Ze-Libraries/_ISL/lib -lisl
-L/Users/laurentdelphin/_Ze-Libraries/_GNU-MP/lib
-L/Users/laurentdelphin/_Ze-Libraries/_GNU-MPFR/lib
-L/Users/laurentdelphin/_Ze-Libraries/_GNU-MPC/lib -lmpc -lmpfr -lgmp  
-L./../zlib -lz 
/usr/bin/clang++ -std=c++11 -pie   -g -DIN_GCC   -fno-strict-aliasing
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -pie 
-o cc1plus \
  cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/class.o
cp/constexpr.o cp/constraint.o cp/coroutines.o cp/cp-gimplify.o
cp/cp-objcp-common.o cp/cp-ubsan.o cp/cvt.o cp/contracts.o
cp/cxx-pretty-print.o cp/decl.o cp/decl2.o cp/dump.o cp/error.o cp/except.o
cp/expr.o cp/friend.o cp/init.o cp/lambda.o cp/lex.o cp/logic.o cp/mangle.o
cp/mapper-client.o cp/mapper-resolver.o cp/method.o cp/module.o
cp/name-lookup.o cp/optimize.o cp/parser.o cp/pt.o cp/ptree.o cp/rtti.o
cp/search.o cp/semantics.o cp/tree.o cp/typeck.o cp/typeck2.o
cp/vtable-class-hierarchy.o attribs.o c-family/c-common.o
c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o
c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o
c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o
c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o
c-family/c-ada-spec.o c-family/c-ubsan.o c-family/known-headers.o
c-family/c-attribs.o c-family/c-warn.o c-family/c-spellcheck.o i386-c.o
darwin-c.o cc1plus-checksum.o libbackend.a main.o libcommon-target.a
libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a
../libcody/libcody.a  \
libcommon.a ../libcpp/libcpp.a  -liconv
../libbacktrace/.libs/libbacktrace.a ../libiberty/pic/libiberty.a
../libdecnumber/libdecnumber.a  -L/Users/laurentdelphin/_Ze-Libraries/_ISL/lib
-lisl -L/Users/laurentdelphin/_Ze-Libraries/_GNU-MP/lib
-L/Users/laurentdelphin/_Ze-Libraries/_GNU-MPFR/lib
-L/Users/laurentdelphin/_Ze-Libraries/_GNU-MPC/lib -lmpc -lmpfr -lgmp  
-L./../zlib -lz 
clang: warning: argument unused during compilation: '-pie'
[-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-pie'
[-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-pie'
[-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-pie'
[-Wunused-command-line-argument]
echo |
/Volumes/External_7/_IT-GNU/_GNU-Compilers/_Workspace/_Build-Dir/./gcc/xgcc
-B/Volumes/External_7/_IT-GNU/_GNU-Compilers/_Workspace/_Build-Dir/./gcc/
-fno-checking -nostdinc -E -dM - | \
  sed -n -e 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p' \
 -e 's/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \
  sort -u > tmp-macro_list
/bin/sh
/Volumes/External_7/_IT-GNU/_GNU-Compilers/_Source/_14.1.x/gcc-14.1.0/gcc/../move-if-change
tmp-macro_list macro_list
echo timestamp > s-macro_list
rm -rf include-fixed; mkdir include-fixed
chmod a+rx include-fixed
if [ -d ../prev-gcc ]; then \
  cd ../prev-gcc && \
  /Applications/Xcode.app/Contents/Developer/usr/bin/make
real-install-headers-tar DESTDIR=`pwd`/../gcc/ \
libsubdir=. ; \
else 

[Bug c++/115744] New: [C++26] P2747R2 - constexpr placement new

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

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

Bug ID: 115744
   Summary: [C++26] P2747R2 - constexpr placement new
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/115745] New: [C++26] P0963R3 - Structured binding declaration as a condition

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

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

Bug ID: 115745
   Summary: [C++26] P0963R3 - Structured binding declaration as a
condition
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/115745] [C++26] P0963R3 - Structured binding declaration as a condition

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-07-02
 Ever confirmed|0   |1

[Bug target/115739] Building cross-compiler to sparc-wrs-vxworks fails since r15-1594-g55947b32c38a40

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

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

--- Comment #4 from Kewen Lin  ---
(In reply to Eric Botcazou from comment #3)
> The fix is OK for mainline, thanks!

Thanks Eric! btw, a formal patch was sent at
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656136.html

[Bug c++/115746] New: [C++26] P2963R3 - Ordering of constraints involving fold expressions

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

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

Bug ID: 115746
   Summary: [C++26] P2963R3 - Ordering of constraints involving
fold expressions
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/115747] New: [C++26] P3144R2 - Deleting a pointer to an incomplete type should be ill-formed

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

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

Bug ID: 115747
   Summary: [C++26] P3144R2 - Deleting a pointer to an incomplete
type should be ill-formed
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/115745] [C++26] P0963R3 - Structured binding declaration as a condition

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

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 58557
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58557&action=edit
gcc15-pr115745.patch

Untested implementation.

[Bug target/115748] New: [15 Regression] gcc.target/i386/avx512bw-pr70509.c SIGILL with -m32

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

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

Bug ID: 115748
   Summary: [15 Regression] gcc.target/i386/avx512bw-pr70509.c
SIGILL with -m32
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

On a non-AVX512 machine some of the avx512bw tests FAIL as we seem to use kmov
in the cpu detection code:

Program received signal SIGILL, Illegal instruction.
0x080491eb in __get_cpuid_count (__leaf=7, __subleaf=0, 
__eax=, __ebx=, 
__ecx=, __edx=)
at /home/rguenther/obj/gcc/include/cpuid.h:346
346   __cpuid_count (__leaf, __subleaf, *__eax, *__ebx, *__ecx, *__edx);
(gdb) disassemble
...
   0x080491df <+46>:mov$0x7,%eax
   0x080491e4 <+51>:mov$0x0,%ecx
   0x080491e9 <+56>:cpuid
=> 0x080491eb <+58>:kmovd  %ebx,%k0
   0x080491ef <+62>:mov$0x1,%eax
   0x080491f4 <+67>:mov$0x0,%ebx

this is in avx512-check.h which contains main that's compiled with flags
assuming there's no incentive to use any non-base x86-64 ISA.

[Bug target/115748] [15 Regression] gcc.target/i386/avx512bw-pr70509.c SIGILL with -m32

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Keywords||testsuite-fail
 Target||x86_64-*-*

--- Comment #1 from Richard Biener  ---
It's really a testsuite issue of course.

[Bug target/115739] Building cross-compiler to sparc-wrs-vxworks fails since r15-1594-g55947b32c38a40

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Kewen Lin :

https://gcc.gnu.org/g:39e679e25deca32e73870f7f7a9c4f2c108d4a5e

commit r15-1766-g39e679e25deca32e73870f7f7a9c4f2c108d4a5e
Author: Kewen Lin 
Date:   Tue Jul 2 03:58:06 2024 -0500

sparc: define SPARC_LONG_DOUBLE_TYPE_SIZE for vxworks [PR115739]

Commit r15-1594 removed define of LONG_DOUBLE_TYPE_SIZE in
sparc.cc, it's based on the assumption that each OS has its
own define (see the comments in sparc.h), but it exposes an
issue on vxworks which lacks of the define.

We can bring back the default SPARC_LONG_DOUBLE_TYPE_SIZE to
sparc.cc, but according to the comments in sparc.h, I think
it's better to define this in vxworks.h.  btw, I also went
through all the sparc supported triples, vxworks is the only
one that misses this define.

PR target/115739

gcc/ChangeLog:

* config/sparc/vxworks.h (SPARC_LONG_DOUBLE_TYPE_SIZE): New define.

[Bug target/115739] Building cross-compiler to sparc-wrs-vxworks fails since r15-1594-g55947b32c38a40

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

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

Kewen Lin  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/115709] missed optimisation: vperms not reordered to eliminate

[mjr19 at cam dot ac.uk via Gcc-bugs]

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

--- Comment #3 from mjr19 at cam dot ac.uk ---
Created attachment 58558
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58558&action=edit
Demo of effect of vperm rearrangement

I still believe that my code is correct. To make what I propose clearer, I
attach a runnable demo, which checks itself.

Whether the optimisation is easy enough to be worthwhile, or whether it would
generalise to other cases, is another matter. On a Kaby Lake the optimised
version is about 20% faster, but on a Haswell it is only about 7% faster.

[Bug c++/115749] New: Missed BMI2 optimization on x86-64

[kim.walisch at gmail dot com via Gcc-bugs]

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

Bug ID: 115749
   Summary: Missed BMI2 optimization on x86-64
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kim.walisch at gmail dot com
  Target Milestone: ---

Hi,

I have debugged a performance issue in one of my C++ applications on x86-64
CPUs where GCC produces noticeably slower code (using all GCC versions) than
Clang. I was able to find that the performance issue was caused by GCC not
using the mulx instruction from BMI2 even when compiling with -mbmi2. Clang on
the other hand used the mulx instruction producing a shorter and faster
assembly sequence. For this particular code sequence Clang used up to 30% fewer
instructions than GCC.

Here is a minimal C/C++ code snippet that reproduces the issue:


extern const unsigned long array[240];

unsigned long func(unsigned long x)
{
unsigned long index = x / 240;
return array[index % 240];
}



GCC trunk produces the following 15 instruction assembly sequence (without
mulx) when compiled using -O3 -mbmi2:

func(unsigned long):
movabs  rcx, -8608480567731124087
mov rax, rdi
mul rcx
mov rdi, rdx
shr rdi, 7
mov rax, rdi
mul rcx
shr rdx, 7
mov rax, rdx
sal rax, 4
sub rax, rdx
sal rax, 4
sub rdi, rax
mov rax, QWORD PTR array[0+rdi*8]
ret


Clang trunk produces the following shorter and faster 12 instruction assembly
sequence (with mulx) when compiled using -O3 -mbmi2:

func(unsigned long):   # @func(unsigned long)
movabs  rax, -8608480567731124087
mov rdx, rdi
mulxrdx, rdx, rax
shr rdx, 7
movabs  rax, 153722867280912931
mulxrax, rax, rax
shr eax
imuleax, eax, 240
sub edx, eax
mov rax, qword ptr [rip + array@GOTPCREL]
mov rax, qword ptr [rax + 8*rdx]
ret

[Bug target/115733] [avr] Improve __memx address handling

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

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

--- Comment #1 from Georg-Johann Lay  ---
Created attachment 58559
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58559&action=edit
proposed patch

AVR: target/115733 - Improve __memx address handling.

Allow CONSTANT_ADDRESS_P addresses in insns that load from __memx.
This requires two new insns that can load the constant address parts of
(subreg:HI (symbol-or-const) 0)  and  (subreg:QI (symbol-or-const) 2).

PR target/115733
gcc/
* config/avr/predicates.md (const_symbol_operand): New.
* config/avr/avr.cc (avr_addr_space_legitimate_address_p)
[ADDR_SPACE_MEMX && CONSTANT_ADDRESS_P]: Return true.
(avr_address_cost) [const_symbol_operand]: Costs 3.
* config/avr/avr.md (mov) [avr_mem_memx_p]: Leave
constant addresses alone.
(xload8_A, xload_A): Allow CONSTANT_ADDRESS_P
addresses in insn condition.
(*set_z_lo16, *set_reg_hh8): New insns.

[Bug target/115750] New: [14/15 regression] Emacs fails to build on HPPA since r14-4426-g0ee3266b3dec4d

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

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

Bug ID: 115750
   Summary: [14/15 regression] Emacs fails to build on HPPA since
r14-4426-g0ee3266b3dec4d
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ABI, wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: danglin at gcc dot gnu.org, matoro_gcc_bugzilla at matoro 
dot tk
  Target Milestone: ---

Originally reported downstream in Gentoo at https://bugs.gentoo.org/935027.

Emacs fails to build with:
```
Loading emacs-lisp/debug-early...
Loading emacs-lisp/byte-run...
Loading emacs-lisp/backquote...
Loading subr...
Loading keymap...
Memory exhausted--use M-x save-some-buffers then exit and restart Emacs
make[2]: *** [Makefile:923: bootstrap-emacs.pdmp] Error 255
make[2]: Leaving directory
'/var/tmp/portage/app-editors/emacs-29.4/work/emacs-29.4/src'
```

This bisects to r14-4426-g0ee3266b3dec4d. We did have some discussion about
this at
https://inbox.sourceware.org/libc-alpha/668d1c2d-1b02-bea8-d5a7-ea8a044f3...@bell.net/
for lock alignment at least...

[Bug target/115750] [14/15 regression] Emacs fails to build on HPPA since r14-4426-g0ee3266b3dec4d

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

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

--- Comment #1 from Sam James  ---
FWIW, I bisected with:
```
# build gcc
[...]

# build emacs
emacs_build=$(mktemp -d)
fatal cd "${emacs_build}"
CC="${prefix}"/bin/gcc CXX="${prefix}"/bin/g++
/home/sam/git/emacs/emacs-29.3/configure
CC="${prefix}"/bin/gcc CXX="${prefix}"/bin/g++ make -j$(nproc)
1>/tmp/emacs-log.txt 2>&1
ret=$?

case ${ret} in
0)
exit 0
;;
*)
if grep -q "Memory exhausted--use M-x save-some-buffers then
exit and restart Emacs" /tmp/emacs-log.txt ; then
exit 1
else
exit 125
fi
;;
esac

exit 0
```

[Bug target/115732] Arm32 architecture definitions for v8+ appear to have wrong FPU/SIMD defaults

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

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #4 from Richard Earnshaw  ---
In Arm v8+ fp and SIMD are just one option.  You can't add FP without adding
SIMD and you can't remove FP without removing SIMD.  Since older versions of
the architecture essentially support SIMD as an extension of the FP extension,
we chose to make the options +simd and +nofp, these being the outer envelope of
the previous options.

[Bug fortran/115700] [11/12/13/14 regression] Bogus warning for associate with assumed-length character array

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

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

--- Comment #4 from Paul Thomas  ---
(In reply to anlauf from comment #2)
> Created attachment 58553 [details]
> Draft patch
> 
> Very hackish patch that sets the character length of the selector at the
> beginning of the associate block if the target is a variable and thus is
> known in advance.
> 
> Not sure if this is the right approach, but it fixes the testcase.

It looks OK to me.

Cheers

Paul

[Bug c++/115747] [C++26] P3144R2 - Deleting a pointer to an incomplete type should be ill-formed

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2024-07-02
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Jakub Jelinek  ---
Created attachment 58560
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58560&action=edit
gcc15-pr115747.patch

Untested implementation.

[Bug target/115748] [15 Regression] gcc.target/i386/avx512bw-pr70509.c SIGILL with -m32

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

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

Hongtao Liu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-07-02

--- Comment #2 from Hongtao Liu  ---
We can add move that part into a separate function and add target attribute for
that.

[Bug rtl-optimization/111673] assign_hard_reg() routine should scale save/restore costs of callee save registers with basic block frequency

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

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

Sam James  changed:

   What|Removed |Added

   Last reconfirmed||2024-07-02
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

[Bug rtl-optimization/109009] Shrink Wrap missed opportunity

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

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-07-02
 Ever confirmed|0   |1

[Bug tree-optimization/115723] [14 Regression] SPEC CPU2017 521/621 build error with -Ofast and AVX512 enabled(-ftree-vectorize?)

[edison_chan_gz at hotmail dot com via Gcc-bugs]

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

--- Comment #15 from edison  ---
(In reply to Richard Biener from comment #14)
> (In reply to edison from comment #13)
> > (In reply to GCC Commits from comment #11)
> > > The master branch has been updated by Richard Biener 
> > > :
> > > 
> > > https://gcc.gnu.org/g:286cda3461d6f5ce7d911d3f26bd4975ea7ea11d
> > > 
> > > commit r15-1745-g286cda3461d6f5ce7d911d3f26bd4975ea7ea11d
> > > Author: Richard Biener 
> > > Date:   Mon Jul 1 10:06:55 2024 +0200
> > > 
> > > tree-optimization/115723 - ICE with .COND_ADD reduction
> > > 
> > > The following fixes an ICE with a .COND_ADD discovered as reduction
> > > even though its else value isn't the reduction chain link but a
> > > constant.  This would be wrong-code with --disable-checking I think.
> > > 
> > > PR tree-optimization/115723
> > > * tree-vect-loop.cc (check_reduction_path): For a .COND_ADD
> > > verify the else value also refers to the reduction chain op.
> > > 
> > > * gcc.dg/vect/pr115723.c: New testcase.
> > 
> > Does this fix work with gcc 14.1? I have try to use it to replace the same
> > file in gcc 14.1 and then build gcc 14.1, got these error:
> 
> Yes, the git revision cherry-picks to GCC 14.1 (well, the GCC 14 branch head
> which is what I tested) just fine.  I've actually verified it fixes building
> of 521 with patched GCC 14.  You can't simply replace whole files though.

How can I apply the fix? I’m very unfamiliar with the patch application method 
here.

[Bug c++/111160] [11/12/13/14/15 Regression] ICE on assigning volatile through ternary operator

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Simon Martin :

https://gcc.gnu.org/g:49058fecbfd09a3354064e7d695b4a1056ce7547

commit r15-1768-g49058fecbfd09a3354064e7d695b4a1056ce7547
Author: Simon Martin 
Date:   Tue Jun 11 11:44:28 2024 +0200

c++: Relax too strict assert in stabilize_expr [PR60]

The case in the ticket is an ICE on invalid due to an assert in
stabilize_expr,
but the underlying issue can actually trigger on this *valid* code:

=== cut here ===
struct TheClass {
  TheClass() {}
  TheClass(volatile TheClass& t) {}
  TheClass operator=(volatile TheClass& t) volatile { return t; }
};
void the_func() {
  volatile TheClass x, y, z;
  (false ? x : y) = z;
}
=== cut here ===

The problem is that stabilize_expr asserts that it returns an expression
without TREE_SIDE_EFFECTS, which can't be if the involved type is volatile.

This patch relaxes the assert to accept having TREE_THIS_VOLATILE on the
returned expression.

Successfully tested on x86_64-pc-linux-gnu.

PR c++/60

gcc/cp/ChangeLog:

* tree.cc (stabilize_expr): Stabilized expressions can have
TREE_SIDE_EFFECTS if they're volatile.

gcc/testsuite/ChangeLog:

* g++.dg/overload/error8.C: New test.
* g++.dg/overload/volatile2.C: New test.

[Bug c++/111160] [11/12/13/14/15 Regression] ICE on assigning volatile through ternary operator

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

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

Simon Martin  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Target Milestone|11.5|15.0
 Resolution|--- |FIXED

--- Comment #6 from Simon Martin  ---
Fixed on trunk.

[Bug c++/115749] Missed BMI2 optimization on x86-64

[kim.walisch at gmail dot com via Gcc-bugs]

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

--- Comment #1 from kim.walisch at gmail dot com ---
I played a bit more with my C/C++ code snippet and managed to further simplify
it. The GCC performance issue seems to be mostly caused by GCC producing worse
assembly than Clang for the integer modulo by a constant on x86-64 CPUs:

unsigned long func(unsigned long x)
{
return x % 240;
}


GCC trunk produces the following 11 instruction assembly sequence (without
mulx) when compiled using -O3 -mbmi2:

func:
movabs  rax, -8608480567731124087
mul rdi
mov rax, rdx
shr rax, 7
mov rdx, rax
sal rdx, 4
sub rdx, rax
mov rax, rdi
sal rdx, 4
sub rax, rdx
ret

Clang trunk produces the following shorter and faster 8 instruction assembly
sequence (with mulx) when compiled using -O3 -mbmi2:

func:
mov rax, rdi
movabs  rcx, -8608480567731124087
mov rdx, rdi
mulxrcx, rcx, rcx
shr rcx, 7
imulrcx, rcx, 240
sub rax, rcx
ret

In my first post one can see that Clang uses mulx for both the integer division
by a constant and the integer modulo by a constant, while GCC does not use
mulx. However, for the integer division by a constant GCC uses the same number
of instructions as Clang (even without GCC using mulx) but for the integer
modulo by a constant GCC uses up to 30% more instructions and is noticeably
slower.

Please note that Clang's assembly is also shorter (8 asm instructions) than
GCC's assembly for the integer modulo by a constant on x86-64 CPUs when
compiling without -mbmi2 e.g. with just -O3:

func:
movabs  rcx, -8608480567731124087
mov rax, rdi
mul rcx
shr rdx, 7
imulrax, rdx, 240
sub rdi, rax
mov rax, rdi
ret

[Bug target/115742] MacOS Monterey : /usr/include not found

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-07-02
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #3 from Andrew Pinski  ---
Did you read the error mesage:
(on Darwin this usually means you need to pass the --with-sysroot= flag to
point to a valid MacOS SDK)

[Bug tree-optimization/115723] [14 Regression] SPEC CPU2017 521/621 build error with -Ofast and AVX512 enabled(-ftree-vectorize?)

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

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

--- Comment #16 from Richard Biener  ---
Created attachment 58561
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58561&action=edit
patch

I have attached it as a patch for your convenience.  You can apply it to a
source tree with the 'patch' utility.

[Bug target/115749] Non optimal assembly for integer modulo by a constant on x86-64 CPUs

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||X86_64

--- Comment #2 from Andrew Pinski  ---
This seems like a tuning issue. In that gcc thinks the shifts and stuff is
faster than mulx.

What happens if you do -march=native?

Does it use mulx?

[Bug target/115749] Non optimal assembly for integer modulo by a constant on x86-64 CPUs

[kim.walisch at gmail dot com via Gcc-bugs]

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

--- Comment #3 from kim.walisch at gmail dot com ---
(In reply to Andrew Pinski from comment #2)
> This seems like a tuning issue. In that gcc thinks the shifts and stuff is
> faster than mulx.
> 
> What happens if you do -march=native?
> 
> Does it use mulx?

I tried using g++-14 using both -march=native and -march=x86-64-v4 (on a 12th
Gen Intel Core i5-12600K which supports BMI2 and AVX2) but GCC always produces
that same 11 instruction assembly sequence without mulx for the integer modulo
by a constant.

[Bug target/115750] [14/15 regression] Emacs fails to build on HPPA since r14-4426-g0ee3266b3dec4d

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||pa
   Target Milestone|--- |14.2
Version|unknown |14.1.0

[Bug target/115749] Non optimal assembly for integer modulo by a constant on x86-64 CPUs

[kim.walisch at gmail dot com via Gcc-bugs]

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

--- Comment #4 from kim.walisch at gmail dot com ---
One possible explanation for why GCC's current integer division by a constant
assembly sequence was chosen back in the day (I guess one or two decades ago)
is that GCC's current assembly sequence uses only 1 mul instruction whereas
Clang uses 2 mul instructions.

Historically, multiplication instructions used to be slower than add, sub and
shift instructions on nearly all CPU architectures and so it made sense to
avoid mul instructions whenever possible. However in the past decade this
performance gap has narrowed and now it is more important to avoid long
instruction dependency chains which GCC's current integer modulo by a constant
assembly sequence suffers from.

[Bug target/115751] New: ICE building 521.wrf_r

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

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

Bug ID: 115751
   Summary: ICE building 521.wrf_r
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

I see the following - note this is from a patched compiler (vectorizer) so
YMMV.  Maybe the bug is obvious though?

/space/rguenther/install/trunk/usr/local/bin/gfortran -c -o
module_mp_wdm5.fppized.o -I. -I./netcdf/include -I./inc -Ofast -march=znver4 -g
-fopt-info-vec -fdump-tree-vect-details -std=legacy -fconvert=big-endian
-fno-openmp -g0 module_mp_wdm5.fppized.f90
...
during RTL pass: split1
module_mp_wdm5.fppized.f90:1498:23:
 1498 |   END SUBROUTINE wdm52d
  |   ^
internal compiler error: Segmentation fault
0x23d54ab internal_error(char const*, ...)
   
/space/rguenther/src/gcc-autopar_devel/gcc/diagnostic-global-context.cc:491
0xfb7dbf crash_signal
/space/rguenther/src/gcc-autopar_devel/gcc/toplev.cc:319
0xaf5f7a force_reg(machine_mode, rtx_def*)
/space/rguenther/src/gcc-autopar_devel/gcc/explow.cc:688
0x155d98f ix86_expand_ternlog(machine_mode, rtx_def*, rtx_def*, rtx_def*, int,
rtx_def*)
   
/space/rguenther/src/gcc-autopar_devel/gcc/config/i386/i386-expand.cc:26060
0x1c86d00 gen_split_1609(rtx_insn*, rtx_def**)

[Bug target/115751] ICE building 521.wrf_r

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

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

--- Comment #1 from Richard Biener  ---
Program received signal SIGSEGV, Segmentation fault.
force_reg (mode=mode@entry=E_V8SFmode, x=x@entry=0x75f4a4a0)
at /space/rguenther/src/gcc-autopar_devel/gcc/explow.cc:688
688   if (REG_P (temp))
(gdb) p temp
$1 = (rtx) 0x0
(gdb) p debug_rtx (x)
(vec_duplicate:V8SF (mem/u/c:SF (symbol_ref/u:DI ("*.LC213") [flags 0x2]) [0 
S4 A32]))

this tried to use force_operand which is restricted in the RTXen it handles.
The above doesnt' qualify general_operand, so there isn't just a new
temporary created.

[Bug target/115751] ICE building 521.wrf_r

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

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

--- Comment #2 from Richard Biener  ---
This is splitting

(insn 5525 5518 5526 377 (set (reg:V8SF 10674)
(ior:V8SF (and:V8SF (vec_duplicate:V8SF (mem/u/c:SF (symbol_ref/u:DI
("*.LC136") [flags 0x2]) [0  S4 A32]))
(reg:V8SF 7250 [ vect__17340.7364 ]))
(vec_duplicate:V8SF (mem/u/c:SF (symbol_ref/u:DI ("*.LC213") [flags
0x2]) [0  S4 A32]
"/abuild/rguenther/cpu2017/benchspec/CPU/521.wrf_r/build/build_base_gcc7-m64./module_mp_wdm5.fppized.f90":609:71
5084 {*avx512vl_vpternlogv8sf_0}
 (nil))

[Bug c/115752] New: [loongarch -O1] ICE: maximum number of generated reload insns per insn achieved (90)

[chenglulu at loongson dot cn via Gcc-bugs]

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

Bug ID: 115752
   Summary: [loongarch -O1] ICE: maximum number of generated
reload insns per insn achieved (90)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chenglulu at loongson dot cn
  Target Milestone: ---

[loongarch -O1] ICE: maximum number of generated reload insns per insn achieved
(90)

[Bug c/115752] [loongarch -O1] ICE: maximum number of generated reload insns per insn achieved (90)

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #1 from chenglulu  ---
test.c

extern long double test1 (long double);
extern long double test2 (long double);

long double
__ieee754_y1l (long double x, long double xx,
   long double z, long double p)
{
  if (xx <= 2)
{
  __asm ("" : "+f"(x));
  p = test1 (x) * test2 (x) + p;
  return p;
}
  return z;
}

$ gcc/cc1 test.c -o - -O1
.file   "test.c"
 __ieee754_y1l
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data> {heap 908k}  {heap 908k} 
{heap 908k}  {heap 1180k}  {heap 1784k}
 {heap 1784k}  {heap 1784k}Streaming LTO
  {heap 1784k}  {heap 1784k}  {heap
1784k}  {heap 1784k}  {heap 1784k}  {heap 1784k}
 {heap 1784k}  {heap 1784k}  {heap
1784k}  {heap 1784k}   .text
Assembling functions:
 __ieee754_y1lduring RTL pass: reload

test.c: In function '__ieee754_y1l':
test.c:16:1: internal compiler error: maximum number of generated reload insns
per insn achieved (90)
   16 | }
  | ^
0x11d5abd lra_constraints(bool)
   
/home/chenglulu/work/loongisa-toolchain/new_toolchain/src/gcc-upstream-test/gcc/lra-constraints.cc:5402
0x11bf43f lra(_IO_FILE*, int)
   
/home/chenglulu/work/loongisa-toolchain/new_toolchain/src/gcc-upstream-test/gcc/lra.cc:2442
0x116c862 do_reload
   
/home/chenglulu/work/loongisa-toolchain/new_toolchain/src/gcc-upstream-test/gcc/ira.cc:5973
0x116cd16 execute
   
/home/chenglulu/work/loongisa-toolchain/new_toolchain/src/gcc-upstream-test/gcc/ira.cc:6161
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.

[Bug target/115751] ICE building 521.wrf_r

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   Last reconfirmed||2024-07-02
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com
 CC||roger at nextmovesoftware dot 
com
 Status|UNCONFIRMED |ASSIGNED

--- Comment #3 from Roger Sayle  ---
Doh!  Thanks for the analysis Richard.  Looks like it isn't safe for
i386-expand to call force_reg on a vec_duplicate, and I should simply call
gen_reg_rtx and emit_move_insn manually [as i386 knows this broadcast is a
valid instruction].
Sorry for the incovenience, I'll bootstrap and regression test a fix [unless
someone beats me to it].

Hopefully, someone can reduce a small testcaase to add to the testsuite, but
the logic that leads to this problem is clear enough for a solution.

[Bug c/115752] [loongarch -O1] ICE: maximum number of generated reload insns per insn achieved (90)

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #2 from chenglulu  ---
I have one place that I don't understand, and the description of the
TARGET_HARD_REGNO_MODE_OK is as follows:

This hook returns true if it is permissible to store a value of mode mode in
hard
register number regno (or in several registers starting with that one). The
default definition returns true unconditionally.

On LA, if mode is TFmode and regno is the number of the floating-point
register, can this hook return true, or must it return false?

[Bug tree-optimization/115753] New: tree check: expected ssa_name, have integer_cst in supportable_indirect_convert_operation, at tree-vect-stmts.cc:14680[15 Regression] ICE:

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 115753
   Summary: tree check: expected ssa_name, have integer_cst in
supportable_indirect_convert_operation, at
tree-vect-stmts.cc:14680[15 Regression] ICE:
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-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: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -frounding-math testcase.c 
during GIMPLE pass: slp
testcase.c: In function 'foo':
testcase.c:2:1: internal compiler error: tree check: expected ssa_name, have
integer_cst in supportable_indirect_convert_operation, at
tree-vect-stmts.cc:14680
2 | foo (void)
  | ^~~
0x2a68abb internal_error(char const*, ...)
/repo/gcc-trunk/gcc/diagnostic-global-context.cc:491
0x8a6ff4 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/repo/gcc-trunk/gcc/tree.cc:9001
0x898a80 tree_check(tree_node*, char const*, int, char const*, tree_code)
/repo/gcc-trunk/gcc/tree.h:3632
0x898a80 supportable_indirect_convert_operation(code_helper, tree_node*,
tree_node*, vec, va_heap, vl_ptr>*,
tree_node*)
/repo/gcc-trunk/gcc/tree-vect-stmts.cc:14680
0x17fb8d8 vectorizable_conversion
/repo/gcc-trunk/gcc/tree-vect-stmts.cc:5388
0x17fd2f8 vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*,
_slp_instance*, vec*)
/repo/gcc-trunk/gcc/tree-vect-stmts.cc:13307
0x18581ec vect_slp_analyze_node_operations_1
/repo/gcc-trunk/gcc/tree-vect-slp.cc:6537
0x18581ec vect_slp_analyze_node_operations
/repo/gcc-trunk/gcc/tree-vect-slp.cc:6736
0x185810f vect_slp_analyze_node_operations
/repo/gcc-trunk/gcc/tree-vect-slp.cc:6715
0x1859c5a vect_slp_analyze_operations(vec_info*)
/repo/gcc-trunk/gcc/tree-vect-slp.cc:7133
0x185ec88 vect_slp_analyze_bb_1
/repo/gcc-trunk/gcc/tree-vect-slp.cc:8144
0x185ec88 vect_slp_region
/repo/gcc-trunk/gcc/tree-vect-slp.cc:8191
0x1860e8c vect_slp_bbs
/repo/gcc-trunk/gcc/tree-vect-slp.cc:8402
0x1861410 vect_slp_function(function*)
/repo/gcc-trunk/gcc/tree-vect-slp.cc:8524
0x186ba81 execute
/repo/gcc-trunk/gcc/tree-vectorizer.cc:1534
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[Bug tree-optimization/104265] Missed vectorization in 526.blender_r

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

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

--- Comment #3 from Richard Biener  ---
Note the SLP discovery opportunity is from the "reduction" PHI to the
return which merges control flow to a zero/one flag.

[Bug target/115741] [15 Regression] RISC-V: ICE in vectorizable_load, at tree-vect-stmts.cc:11524

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Richard Biener :

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

commit r15-1783-g9bd51351c175d345b8a9b3c19ba49ba358940272
Author: Richard Biener 
Date:   Tue Jul 2 09:33:29 2024 +0200

tree-optimization/115741 - ICE with VMAT_CONTIGUOUS_REVERSE and gap

When we determine overrun we have to consider VMAT_CONTIGUOUS_REVERSE
the same as VMAT_CONTIGUOUS.

PR tree-optimization/115741
* tree-vect-stmts.cc (get_group_load_store_type): Also
handle VMAT_CONTIGUOUS_REVERSE when determining overrun.

[Bug c++/115747] [C++26] P3144R2 - Deleting a pointer to an incomplete type should be ill-formed

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #1)
> Created attachment 58560 [details]
> gcc15-pr115747.patch
> 
> Untested implementation.

Thanks; I'd prefer a permerror using the existing OPT_Wdelete_incomplete, and
also using cxx_incomplete_type_diagnostic like the current warning.

[Bug testsuite/113005] 'libgomp.fortran/rwlock_1.f90', 'libgomp.fortran/rwlock_3.f90' execution test timeouts

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   Last reconfirmed|2023-12-21 00:00:00 |2024-7-2

--- Comment #15 from Thomas Schwinge  ---
First, I apologize for the delay in continuing the discussion here.  Siemens
decided to cancel their Open Source Toolchains business (and more), so my group
had to find a new home...

At BayLibre, I first didn't run into this issue anymore.  However, today I've
done some "environmental changes", and it's back: I switched from "local disk"
to "NFS" testing, that is, the testing directory is NFS-mounted.

(In reply to Lipeng Zhu from comment #14)
> (In reply to Lipeng Zhu from comment #13)
> > OK, I think I find the root cause of this error, when thread number greater
> > than 1000, the file_name = 1000_tst.dat, character(11) will overflow. This
> > will generate the same file_name like ***_tst.dat. 

That's not the issue I've been running into, so:

> Can you help to verify if this draft patch will fix the error on your side?

No, that doesn't help in my case.  (..., but supposedly is still necessary for
the "greater than 1000" case.)

The problem I'm running into, on the following system:

$ grep ^cpu < /proc/cpuinfo | uniq -c
128 cpu : POWER9, altivec supported

..., when running 'libgomp.fortran/rwlock_1.f90' via 'strace -o s -ff
[...]/rwlock_1.exe', that produces 25984 (!) 's.*' files (process 'clone's --
OpenMP threads, I suppose; I didn't try to understand that number in more
detail), and in total:

$ cat s.* | grep -F '_tst.dat' | wc -l
51712

... 51712 operations on '*_tst.dat' files (multiplied by the number of
operations on the respective opened file descriptors), and I assume that's what
overwhelms the NFS subsystem.

I don't think there's really any kind of existing mechanism/precedent for test
cases to open files outside of their current working directory (local disk, for
example: '/tmp/' instead of NFS in my case), or is there?


Are these 'libgomp.fortran/rwlock_{1,2,3}.f90' test cases intended to be
correctness test cases (and therefore may be limiting themselves to some
suitable lower 'OMP_NUM_THREADS', for example via 'num_threads' clauses, as
discussed before), or performance test cases that really need to exercise all
cores, for example?

[Bug tree-optimization/115753] [15 Regression] ICE: tree check: expected ssa_name, have integer_cst in supportable_indirect_convert_operation, at tree-vect-stmts.cc:14680

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||lin1.hu at intel dot com
Version|14.0|15.0
   Target Milestone|--- |15.0

[Bug c++/115745] [C++26] P0963R3 - Structured binding declaration as a condition

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #1)
> Created attachment 58557 [details]
> gcc15-pr115745.patch
> 
> Untested implementation.

The later uses of the condition TARGET_EXPR can refer to the TARGET_EXPR_SLOT
instead of using the TARGET_EXPR itself.

[Bug testsuite/113005] 'libgomp.fortran/rwlock_1.f90', 'libgomp.fortran/rwlock_3.f90' execution test timeouts

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

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

--- Comment #16 from Thomas Schwinge  ---
Even with 'call omp_set_num_threads(8)' added, 'libgomp.fortran/rwlock_1.f90'
still takes ~1 min to execute with working directory on NFS, compared to almost
instantaneous via local disk.  (I've not observed any other irregularities in
NFS access.)

[Bug target/115741] [15 Regression] RISC-V: ICE in vectorizable_load, at tree-vect-stmts.cc:11524

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Should be fixed.

[Bug c++/115746] [C++26] P2963R3 - Ordering of constraints involving fold expressions

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-07-02
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/115744] [C++26] P2747R2 - constexpr placement new

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

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

Jason Merrill  changed:

   What|Removed |Added

   Last reconfirmed||2024-07-02
 Status|UNCONFIRMED |NEW
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/115744] [C++26] P2747R2 - constexpr placement new

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

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 58563
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58563&action=edit
gcc15-pr115744-wip.patch

Untested WIP patch.

[Bug c++/114990] Compiler errors in compiling a module-based app

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

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

--- Comment #8 from Jason Merrill  ---
bar.cppm:4:20: error: conflicting declaration of ‘void foo()’ in module ‘bar’
4 | export inline void foo() noexcept;
  |^~~
In file included from bar.cppm:2:
someheader.hpp:1:13: note: previously declared in global module

[Bug c++/115754] New: C++26 ICE on constexpr new

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

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

Bug ID: 115754
   Summary: C++26 ICE on constexpr new
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: jason at gcc dot gnu.org, unassigned at gcc dot gnu.org
Depends on: 115744
Blocks: 110338
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #115744 +++

While working on the PR115744 patch, I've noticed that vanilla trunk or GCC 14
ICE on

namespace std
{
  using size_t = decltype (sizeof 0);

  template 
  struct allocator
  {
constexpr allocator () noexcept {}

constexpr T *allocate (size_t n)
{ return static_cast (::operator new (n * sizeof(T))); }

constexpr void
deallocate (T *p, size_t n)
{ ::operator delete (p); }
  };
}

constexpr void *
operator new (std::size_t, void *p) noexcept
{ return p; }

constexpr bool
foo ()
{
  std::allocator a;
  auto b = a.allocate (1);
  ::new (b) int ();
  a.deallocate (b, 1);
  return true;
}

constexpr bool a = foo ();

with -std=c++26.  Of course, the C++26 constexpr placement new support isn't
there and users shouldn't be declaring placement operator new themselves,
especially with constexpr when it is not, but still we shouldn't ICE.

Filing separately in case we want to backport it.

The fix for this in the WIP patch was the
@@ -8103,7 +8103,10 @@ cxx_eval_constant_expression (const cons
tree oldop = TREE_OPERAND (t, 0);

tree op = cxx_eval_constant_expression (ctx, oldop,
-   lval,
+   (VOID_TYPE_P (TREE_TYPE (t))
+|| (tcode == VIEW_CONVERT_EXPR
+&& lval == vc_glvalue))
+   ? lval : vc_prvalue,
non_constant_p, overflow_p);
if (*non_constant_p)
  return t;
hunk in constexpr.cc, if lval is vc_discard but we aren't really discarding the
result,
I think the void * -> something * cast code at least but most likely various
other checks rely on op being actually an rvalue.  If this is a (void) cast,
discarding it is fine, we won't process anything.  And I think
VIEW_CONVERT_EXPR can be around various VAR_DECLs on the lhs, so I think we
also need at least vc_glvalue handling for that.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338
[Bug 110338] Implement C++26 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115744
[Bug 115744] [C++26] P2747R2 - constexpr placement new

[Bug c++/115754] [14/15 Regression] C++26 ICE on constexpr new

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to fail||14.1.0, 15.0
   Target Milestone|--- |14.2
Summary|C++26 ICE on constexpr new  |[14/15 Regression] C++26
   ||ICE on constexpr new

[Bug c++/115744] [C++26] P2747R2 - constexpr placement new

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

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

--- Comment #2 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #1)
> Untested WIP patch.

In the conversion lval change, I'd think we want vc_discard for conversion to
void, and to pass through whatever lval for VIEW_CONVERT_EXPR.

[Bug c++/114990] Compiler errors in compiling a module-based app

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #9 from cqwrteur  ---
(In reply to Jason Merrill from comment #8)
> bar.cppm:4:20: error: conflicting declaration of ‘void foo()’ in module ‘bar’
> 4 | export inline void foo() noexcept;
>   |^~~
> In file included from bar.cppm:2:
> someheader.hpp:1:13: note: previously declared in global module

That is my problem. This just breaks header only libraries right?

This is the same.

import std;
#include //it uses std features.


This is absolutely the standard bug. I am 100% correct here.

[Bug c++/115754] [14/15 Regression] C++26 ICE on constexpr new

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

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

--- Comment #1 from Jason Merrill  ---
Agreed, with the adjustment I commented on 115744.

[Bug c++/115745] [C++26] P0963R3 - Structured binding declaration as a condition

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #58557|0   |1
is obsolete||

--- Comment #3 from Jakub Jelinek  ---
Created attachment 58564
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58564&action=edit
gcc15-pr115745.patch

Indeed, this worked in brief testing.  I'm currently bootstrapping/regtesting
the first versions of the 2 patches, once that is done, will test this.

[Bug analyzer/115724] analyzer does not recognise glibc (GNU) extension, non-returning error

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

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

--- Comment #4 from David Malcolm  ---
The analyzer *does* try to handle error() and error_at_line() from GNU's
non-standard ; see:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/analyzer/kf.cc;h=4213b89ac9fb4ff11994cf2c35f15a281be3b024;hb=HEAD#l496
 

In particular it tries to "know" that arg0 == 0 means "doesn't return".

So something's going wrong with that; I'll take a look.

[Bug target/115750] [14/15 regression] Emacs fails to build on HPPA since r14-4426-g0ee3266b3dec4d

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

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

--- Comment #2 from John David Anglin  ---
The bisection result is puzzling.  The linux MALLOC_ABI_ALIGNMENT define
in pa32-linux.h is replaced by the one in pa.h by the commit.  As far as
I know, the malloc alignment for hppa-linux has always been 8 bytes.  It was
never 16 bytes.  As a result, malloc'd data is insufficiently aligned for
pthreads.

I removed the define from pa32-linux.h because it didn't reflect the
actual alignment provided by malloc in glibc.

Although emacs doesn't build in Debian,
https://buildd.debian.org/status/logs.php?pkg=emacs&arch=hppa
the issue is a couple of testsuite fails.  The main difference is
Debian builds using PA 1.1 code.  The Memory exhausted error doesn't
occur there.

[Bug c++/115747] [C++26] P3144R2 - Deleting a pointer to an incomplete type should be ill-formed

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

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

--- Comment #3 from Jakub Jelinek  ---
Do you mean something like:
@@ -4114,6 +4114,14 @@ build_vec_delete_1 (location_t loc, tree

   if (!COMPLETE_TYPE_P (type))
 {
+  if (cxx_dialect > cxx23)
+   {
+ if ((complain & tf_error)
+ && permerror (loc, "operator % used on "
+   "incomplete type"))
+   cxx_incomplete_type_diagnostic (base, type, DK_PERMERROR);
+ return error_mark_node;
+   }
   if (complain & tf_warning)
{
  auto_diagnostic_group d;
or
@@ -4114,19 +4114,22 @@ build_vec_delete_1 (location_t loc, tree

   if (!COMPLETE_TYPE_P (type))
 {
-  if (complain & tf_warning)
+  if (complain & (cxx_dialect > cxx23 ? tf_error : tf_warning))
{
  auto_diagnostic_group d;
- if (warning_at (loc, OPT_Wdelete_incomplete,
- "possible problem detected in invocation of "
- "operator %"))
+ diagnostic_t kind = cxx_dialect > cxx23 ? DK_PERMERROR : DK_WARNING;
+ if (emit_diagnostic (kind,loc, OPT_Wdelete_incomplete,
+  "possible problem detected in invocation of "
+   "operator %"))
{
- cxx_incomplete_type_diagnostic (base, type, DK_WARNING);
+ cxx_incomplete_type_diagnostic (base, type, kind);
  inform (loc, "neither the destructor nor the "
  "class-specific operator % will be called, "
  "even if they are declared when the class is defined");
}
}
+  if (cxx_dialect > cxx23)
+   return error_mark_node;
   /* This size won't actually be used.  */
   size_exp = size_one_node;
   goto no_destructor;
or something else?  I think the former is fine, the wording of the second
variant is just weird, because it isn't a possible problem, it is strictly
invalid code for C++26 and there is no need to explain what would happen in
that case.

[Bug c++/115747] [C++26] P3144R2 - Deleting a pointer to an incomplete type should be ill-formed

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

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

--- Comment #4 from Jason Merrill  ---
I think we want parallel changes for the vec and non-vec cases.

I agree that the diagnostic message needs to be different for C++26, just that
the C++26 diagnostic should also be affected by -Wno-delete-incomplete.

if (complain & tf_error) but permerror_opt returns false, we should not return
error_mark_node.

[Bug c++/115747] [C++26] P3144R2 - Deleting a pointer to an incomplete type should be ill-formed

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

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Jason Merrill from comment #4)
> I think we want parallel changes for the vec and non-vec cases.

Of course, left those out for brevity.

> I agree that the diagnostic message needs to be different for C++26, just
> that the C++26 diagnostic should also be affected by -Wno-delete-incomplete.

So
@@ -4114,6 +4114,21 @@ build_vec_delete_1 (location_t loc, tree

   if (!COMPLETE_TYPE_P (type))
 {
+  if (cxx_dialect > cxx23)
+   {
+ if (complain & tf_error)
+   {
+ if (warn_delete_incomplete
+ && permerror (loc, "operator % used on "
+   "incomplete type"))
+   {
+ cxx_incomplete_type_diagnostic (base, type, DK_PERMERROR);
+ return error_mark_node;
+   }
+   }
+ else
+   return error_mark_node;
+   }
   if (complain & tf_warning)
{
  auto_diagnostic_group d;
then?  -Wno-delete-incomplete will make it silently accepted except during
SFINAE,
-fpermissive accepted with a warning?
And obviously I'll adjust the testsuite to whatever is chosen.

[Bug c++/114990] Compiler errors in compiling a module-based app

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

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

--- Comment #10 from Jason Merrill  ---
(In reply to cqwrteur from comment #9)
> (In reply to Jason Merrill from comment #8)
> > bar.cppm:4:20: error: conflicting declaration of ‘void foo()’ in module 
> > ‘bar’
> > 4 | export inline void foo() noexcept;
> >   |^~~
> > In file included from bar.cppm:2:
> > someheader.hpp:1:13: note: previously declared in global module
> 
> That is my problem. This just breaks header only libraries right?

No, you just need to #include the library header before the "export module"
line.  Or better yet, use import  instead of #include.

> This is the same.
> 
> import std;
> #include //it uses std features.
> 
> This is absolutely the standard bug.

This is a GCC bug, as described in comment #1.  If you

import ;

instead, it should work fine.  Naturally, that requires that you first

g++ -fmodules-ts -c -x c++-system-header aheaderonlylibrary

[Bug c++/115747] [C++26] P3144R2 - Deleting a pointer to an incomplete type should be ill-formed

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

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

--- Comment #6 from Jason Merrill  ---
Almost, but permerror_opt instead of checking the flag directly.

And actually I think cxx_incomplete_type_inform is enough, rather than
cxx_incomplete_type_diagnostic.

[Bug c++/114990] Compiler errors in compiling a module-based app

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #11 from cqwrteur  ---
(In reply to Jason Merrill from comment #10)
> (In reply to cqwrteur from comment #9)
> > (In reply to Jason Merrill from comment #8)
> > > bar.cppm:4:20: error: conflicting declaration of ‘void foo()’ in module 
> > > ‘bar’
> > > 4 | export inline void foo() noexcept;
> > >   |^~~
> > > In file included from bar.cppm:2:
> > > someheader.hpp:1:13: note: previously declared in global module
> > 
> > That is my problem. This just breaks header only libraries right?
> 
> No, you just need to #include the library header before the "export module"
> line.  Or better yet, use import  instead of #include.
> 
> > This is the same.
> > 
> > import std;
> > #include //it uses std features.
> > 
> > This is absolutely the standard bug.
> 
> This is a GCC bug, as described in comment #1.  If you
> 
> import ;
> 
> instead, it should work fine.  Naturally, that requires that you first
> 
> g++ -fmodules-ts -c -x c++-system-header aheaderonlylibrary

The question is still how this library could work. The same simply absolutely
conflicts. Unless the standard allows inline to be discarded across modules I
don't see how this could work.

[Bug c++/114990] Compiler errors in compiling a module-based app

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #12 from cqwrteur  ---
(In reply to Jason Merrill from comment #10)
> (In reply to cqwrteur from comment #9)
> > (In reply to Jason Merrill from comment #8)
> > > bar.cppm:4:20: error: conflicting declaration of ‘void foo()’ in module 
> > > ‘bar’
> > > 4 | export inline void foo() noexcept;
> > >   |^~~
> > > In file included from bar.cppm:2:
> > > someheader.hpp:1:13: note: previously declared in global module
> > 
> > That is my problem. This just breaks header only libraries right?
> 
> No, you just need to #include the library header before the "export module"
> line.  Or better yet, use import  instead of #include.
> 
> > This is the same.
> > 
> > import std;
> > #include //it uses std features.
> > 
> > This is absolutely the standard bug.
> 
> This is a GCC bug, as described in comment #1.  If you
> 
> import ;
> 
> instead, it should work fine.  Naturally, that requires that you first
> 
> g++ -fmodules-ts -c -x c++-system-header aheaderonlylibrary

std is actually just one example. It applies to any library that have the same
dependency issue.

[Bug c++/110343] [C++26] P2558R2 - Add @, $, and ` to the basic character set

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

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

--- Comment #8 from Jakub Jelinek  ---
Ed, ping again, will you post this to gcc-patches?

[Bug c++/115747] [C++26] P3144R2 - Deleting a pointer to an incomplete type should be ill-formed

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #58560|0   |1
is obsolete||

--- Comment #7 from Jakub Jelinek  ---
Created attachment 58565
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58565&action=edit
gcc15-pr115747.patch

Updated patch.  Had to guard return error_mark_node for the non-SFINAE case on
!flag_permissive, otherwise it triggers an ICE (statement parsing into
error_mark_node without seen_error ()).

[Bug c++/115745] [C++26] P0963R3 - Structured binding declaration as a condition

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #58564|0   |1
is obsolete||

--- Comment #4 from Jakub Jelinek  ---
Created attachment 58566
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58566&action=edit
gcc15-pr114745.patch

Bootstrap/regtest of the first patch found one testcase that needed to be
adjusted, here is an updated patch with that.

[Bug analyzer/115724] analyzer does not recognise glibc (GNU) extension, non-returning error

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

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

--- Comment #5 from David Malcolm  ---
glib'c bits/error.h has:

/* If we know the function will never return make sure the compiler
   realizes that, too.  */
__extern_always_inline void
error (int __status, int __errnum, const char *__format, ...)
{
  if (__builtin_constant_p (__status) && __status != 0)
__error_noreturn (__status, __errnum, __format, __va_arg_pack ());
  else
__error_alias (__status, __errnum, __format, __va_arg_pack ());
}

and similar for error_at_line.

However, looking at GENERIC (via -fdump-tree-original=stderr)
  https://godbolt.org/z/dqWr1G97s
I see that this is coming out of the C front end as:

;; Function error (null)
;; enabled by -tree-original

{
  if (0)
{
  __error_noreturn (__status, __errnum, __format, __builtin_va_arg_pack
());
}
  else
{
  __error_alias (__status, __errnum, __format, __builtin_va_arg_pack ());
}
}

before any of GCC's inlining logic gets to work on it.

Hence "test" quickly gets optimized down to just:
  __error_alias (__status_2(D), __errnum_3(D), __format_4(D),
__builtin_va_arg_pack ());

and this is what is inlined into the callsite of "error".

Hence by the time the analyzer sees it we have a call to "__error_alias" which
the analyzer/kf.cc doesn't recognize, and conservatively assumes could return.

So there are arguably three issues here:
(a) should gcc keep the __builtin_constant_p around longer so that it's still
around when the inliner gets a chance to work on it?  (I don't know if this is
a good idea or not)
(b) should glibc's header be rewritten (perhaps losing the
__builtin_constant_p?)
(c) the analyzer's special-casing for error and error_at_line should also
recognize __error_alias and __error_at_line_alias (probably an easy workaround)

[Bug c++/114990] Compiler errors in compiling a module-based app

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

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

--- Comment #13 from Jason Merrill  ---
> The question is still how this library could work. The same simply
> absolutely conflicts. Unless the standard allows inline to be discarded
> across modules I don't see how this could work.

It works because everything in a header unit is attached to the global module. 
If the same global module declarations are imported from multiple module units,
any duplicates are discarded.

[Bug target/115591] internal error on global variable-length array

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

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

--- Comment #6 from Jeffrey A. Law  ---
Eric,
Just threw this into my tester.  Figure ~90 minutes to get back the cross
results.

I assume that if we go forward that you'll handle putting together a regression
test since it's Ada source?

[Bug fortran/108889] [12/13/14/15 Regression] (Re)Allocate in assignment shows used uninitialized memory warning with -Wall if LHS is unallocated

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

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #5 from Paul Thomas  ---
(In reply to Tobias Burnus from comment #0)
> The following testcase shows the following -Wall warnings:
> 
> Warning: ‘reference.offset’ is used uninitialized [-Wuninitialized]
> Warning: ‘reference.dim[0].lbound’ is used uninitialized [-Wuninitialized]
> Warning: ‘reference.dim[0].ubound’ may be used uninitialized
> [-Wmaybe-uninitialized]
> 
> The warning (but not the issue) is new since GCC 12. The dump shows:
> 
> D.4310 = reference.offset;
> D.4311 = reference.dim[0].lbound;
> D.4312 = reference.dim[0].ubound;
> 
> D.4313 = D.4311 - D.4307;  // D.4307 = single.var.dim[0].lbound
> 
> But all expressions are actually re-evaluated later:
> D.4317 = (real(kind=4)[0:] * restrict) reference.data == 0B;
> if (D.4317) goto L.4;
> ...
> L.4:;
> ...
> reference.dim[0].lbound = single.var.dim...
> reference.offset = -NON_LVALUE_EXPR ;
> D.4310 = reference.offset;
> D.4313 = reference.dim[0].lbound - D.4307;
> ...
> L.5:;  /// If the shape was correct, there is a jump to here / L.5
>   while (1)
> {
>   if (S.2 > D.4308) goto L.6;
>   (*D.4309)[(S.2 + D.4313) + D.4310] = (*D.4305)[S.2 + D.4306];
> 
> Thus, D.4313 + D.4310 needs to be evaluated in the no-(re)alloc case and in
> the needs-to-be allocated case.
> 
> 
> Thus, the produced code is fine at the end – even though there was
> uninitialized memory in between. — But this should be fixed, also to silence
> the warning.
> 
> * * * 
> 
> ! Testcase: Compile with -Wall
> 
> program main
>   implicit none
>  
>   type :: struct
> real, allocatable :: var(:)
>   end type struct
>  
>   type(struct) :: single
>   real, allocatable :: reference(:)
>  
>   single%var = [1,2,3,4,5]
>   reference = single%var
> 
>   if (size(reference) /= size(single%var)) stop 1
>   if (lbound(reference, 1) /= 1) stop 3
>   if (any (reference /= single%var)) stop 3
> end

The offending temporaries are emerging out of the scalarizer, rather than
gfc_alloc_allocatable_for_assignment, and are used for the saved_offset and
deltas. These are set in gfc_alloc_allocatable_for_assignment  at lines
11378-11392, which is why the temporaries pop up again.

I'm thinking about it :-)

Cheers

Paul

[Bug analyzer/115724] analyzer does not recognise glibc (GNU) extension, non-returning error

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

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

--- Comment #6 from David Malcolm  ---
Posted to mailing lists:
  https://gcc.gnu.org/pipermail/gcc/2024-July/244257.html
  https://sourceware.org/pipermail/libc-alpha/2024-July/157942.html

[Bug target/115751] ICE building 521.wrf_r

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #4 from Roger Sayle  ---
Created attachment 58567
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58567&action=edit
proposed patch

Here's my proposed patch.

[Bug target/115188] [14/15 regression] invalid Thumb assembly for atomic store in loop on ARMv6

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Wilco Dijkstra :

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

commit r15-1786-gd04c5537f5ae4a3acd3f5135347d7e2d8c218811
Author: Wilco Dijkstra 
Date:   Tue Jul 2 17:37:04 2024 +0100

Arm: Fix disassembly error in Thumb-1 relaxed load/store [PR115188]

A Thumb-1 memory operand allows single-register LDMIA/STMIA. This doesn't
get
printed as LDR/STR with writeback in unified syntax, resulting in strange
assembler errors if writeback is selected.  To work around this, use the
'Uw'
constraint that blocks writeback.  Also use a new 'mem_and_no_t1_wback_op'
which is a general memory operand that disallows writeback in Thumb-1.
A few other patterns were using 'm' for Thumb-1 in a similar way, update
these
to also use 'mem_and_no_t1_wback_op' and 'Uw'.

gcc:
PR target/115188
* config/arm/arm.md (unaligned_loadsi): Use 'Uw' constraint and
'mem_and_no_t1_wback_op'.
(unaligned_loadhiu): Likewise.
(unaligned_storesi): Likewise.
(unaligned_storehi): Likewise.
* config/arm/predicates.md (mem_and_no_t1_wback_op): Add new
predicate.
* config/arm/sync.md (arm_atomic_load): Use 'Uw' constraint.
(arm_atomic_store): Likewise.

gcc/testsuite:
PR target/115188
* gcc.target/arm/pr115188.c: Add new test.

[Bug target/115093] RISC-V Vector ICE in extract_insn: unrecognizable insn

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Jeffrey A. Law  ---
Per c#1.

[Bug c++/115747] [C++26] P3144R2 - Deleting a pointer to an incomplete type should be ill-formed

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

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

--- Comment #8 from Jason Merrill  ---
> Updated patch.  Had to guard return error_mark_node for the non-SFINAE case
> on !flag_permissive, otherwise it triggers an ICE (statement parsing into
> error_mark_node without seen_error ()).

Hmm, I think checking seen_error() would be better than flag_permissive, to
support -Wno-error=delete-incomplete .  Or even compare errorcount before and
after the permerror_opt.

Perhaps the currently bool diagnostic functions should instead different values
for warning and error...

[Bug target/115068] RISC-V: Illegal instruction of vfwadd

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
 CC||law at gcc dot gnu.org

--- Comment #2 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug rtl-optimization/114996] [15 Regression] [RISC-V] 2->2 combination no longer occurring

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #8 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug target/114988] RISC-V: ICE in intrinsic __riscv_vfwsub_wf_f32mf2

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug c++/114990] Compiler errors in compiling a module-based app

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #14 from cqwrteur  ---
(In reply to Jason Merrill from comment #13)
> > The question is still how this library could work. The same simply
> > absolutely conflicts. Unless the standard allows inline to be discarded
> > across modules I don't see how this could work.
> 
> It works because everything in a header unit is attached to the global
> module.  If the same global module declarations are imported from multiple
> module units, any duplicates are discarded.

But it is not declaration, but definition. The actual implementation duplicates
twice.