[Bug debug/113382] FAIL: gcc.dg/debug/btf/btf-bitfields-3.c scan-assembler-times [\t ]0x6000004[\t ]+[^\n]*btt_info 1

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

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

--- Comment #5 from John David Anglin  ---
The problem seems to be DW_AT_encoding is not found in this call:
static ctf_id_t
gen_ctf_enumeration_type (ctf_container_ref ctfc, dw_die_ref enumeration)
{
  const char *enum_name = get_AT_string (enumeration, DW_AT_name);
  unsigned int bit_size = ctf_die_bitsize (enumeration);
  unsigned int signedness = get_AT_unsigned (enumeration, DW_AT_encoding);

get_AT() returns NULL.

This is because dwarf_strict is 1:
  if (!dwarf_strict)
add_AT_unsigned (type_die, DW_AT_encoding,
 TYPE_UNSIGNED (type)
 ? DW_ATE_unsigned
 : DW_ATE_signed);

I believe we need to add -gno-strict-dwarf option on hppa*64*-*-hpux*.

[Bug debug/113382] FAIL: gcc.dg/debug/btf/btf-bitfields-3.c scan-assembler-times [\t ]0x6000004[\t ]+[^\n]*btt_info 1

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by John David Anglin :

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

commit r14-8338-gbc77c035c45bb224790b1c03d06a64c8a1cc51c5
Author: John David Anglin 
Date:   Mon Jan 22 19:07:32 2024 +

Add -gno-strict-dwarf to dg-options in various btf enum tests

The -gno-strict-dwarf option is needed to ensure enum signedness
is added to type_die.

2024-01-22  John David Anglin  

gcc/testsuite/ChangeLog:

PR debug/113382
* gcc.dg/debug/btf/btf-bitfields-3.c: Add -gno-strict-dwarf
option to dg-options.
* gcc.dg/debug/btf/btf-enum-1.c: Likewise.
* gcc.dg/debug/btf/btf-enum-small.c: Likewise.
* gcc.dg/debug/btf/btf-enum64-1.c: Likewise.

[Bug c++/113547] [13 Regression] c++: In function ‘std::vector package_b_info()’: cc1plus: internal compiler error: Segmentation fault

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.3
Summary|c++: In function|[13 Regression] c++: In
   |‘std::vector|function ‘std::vector
   |package_b_info()’: cc1plus: |package_b_info()’: cc1plus:
   |internal compiler error:|internal compiler error:
   |Segmentation fault  |Segmentation fault

[Bug libgomp/113513] [OpenMP] libgomp: cuCtxGetDevice error with OMP_DISPLAY_ENV=true OMP_TARGET_OFFLOAD="mandatory" for libgomp.c/target-52.c

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

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

--- Comment #2 from Tobias Burnus  ---
Patch:
  https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643648.html

[Bug c++/113541] Rejects __attribute__((section)) on explicit instantiation declaration of ctor/dtor

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2024-01-22

--- Comment #1 from Marek Polacek  ---
The error started with r5-1210-ge257a17cb9cc4d.

[Bug tree-optimization/113548] New: ICE vect-ifcvt-19 in build2, at tree.cc:5097

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 113548
   Summary: ICE vect-ifcvt-19 in build2, at tree.cc:5097
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

Created attachment 57186
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57186=edit
Preprocessed source from -freport-bug

ICE during testsuite run for vect-ifcvt-19.  Many similarly titled bugs, I
think the current title of this one is equally unhelpful, so feel free to
change this PR title to something better.

Running linux 64 to windows 64 cross compiler, fails on 11, 12, 13, 14.  I
didn't test prior versions.

Backtrace:

0x8bb855 build2(tree_code, tree_node*, tree_node*, tree_node*)
../../gcc/tree.cc:5097
0xa4dd1f build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/tree.h:4750
0xa4dd1f c_parser_gimple_binary_expression
../../gcc/c/gimple-parser.cc:1068
0xa4ec71 c_parser_gimple_statement
../../gcc/c/gimple-parser.cc:878
0xa4f95a c_parser_gimple_compound_statement
../../gcc/c/gimple-parser.cc:669
0xa51a58 c_parser_parse_gimple_body(c_parser*, char*, c_declspec_il,
profile_count)
../../gcc/c/gimple-parser.cc:253
0xa3d3f4 c_parser_declaration_or_fndef
../../gcc/c/c-parser.cc:3011
0xa4764b c_parser_external_declaration
../../gcc/c/c-parser.cc:2046
0xa48035 c_parser_translation_unit
../../gcc/c/c-parser.cc:1900
0xa48035 c_parse_file()
../../gcc/c/c-parser.cc:26815
0xabf271 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1301

[Bug c++/109642] False Positive -Wdangling-reference with std::span-like classes

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

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

--- Comment #15 from GCC Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r14-8339-gc596ce03120cc22e141186401c6656009ddebdaa
Author: Marek Polacek 
Date:   Mon Jan 22 16:12:33 2024 -0500

c++: extend Wdangling-reference17.C [PR109642]

This patch extends g++.dg/warn/Wdangling-reference17.C with code
from PR109642.  I'm not creating a new test because this one
already #includes the required headers.

PR c++/109642

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wdangling-reference17.C: Additional testing.

[Bug c++/113547] New: c++: In function ‘std::vector package_b_info()’: cc1plus: internal compiler error: Segmentation fault

[csfore at posteo dot net via Gcc-bugs]

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

Bug ID: 113547
   Summary: c++: In function ‘std::vector package_b_info()’:
cc1plus: internal compiler error: Segmentation fault
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: csfore at posteo dot net
  Target Milestone: ---

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

Originally reported downstream in Gentoo at https://bugs.gentoo.org/920322 when
building package =dev-util/build2-0.14.0

Command line required to trigger for the original:

x86_64-pc-linux-gnu-g++ -std=c++20 -c -fdirectives-only manifest-utility.o.ii

Command line required for the minimized version:

x86_64-pc-linux-gnu-g++ manifest-utility.o.ii


$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/13/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/13
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/13/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/13/python
--enable-languages=c,c++,go,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo
13.2.1_p20240113-r1 p12' --with-gcc-major-version-only --enable-libstdcxx-time
--enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
--with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all
--enable-libgomp --disable-libssp --disable-libada --disable-cet
--disable-systemtap --disable-valgrind-annotations --disable-vtable-verify
--disable-libvtv --with-zstd --without-isl --enable-default-pie
--enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20240113 (Gentoo 13.2.1_p20240113-r1 p12)

[Bug c++/113547] [13 Regression] c++: In function ‘std::vector package_b_info()’: cc1plus: internal compiler error: Segmentation fault

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Most likely a dup of bug 113347.

[Bug testsuite/113548] gcc.dg/vect/vect-ifcvt-19.c ICEs on LLP64 target

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #3 from nightstrike  ---
Seeing as how this is a testsuite issue, it seems that the crash in the same
location applies to the following:

FAIL: gcc.dg/vect/vect-ifcvt-19.c (internal compiler error: in build2, at
tree.cc:5097)
FAIL: gcc.dg/vect/slp-reduc-10a.c (internal compiler error: in build2, at
tree.cc:5097)
FAIL: gcc.dg/vect/slp-reduc-10b.c (internal compiler error: in build2, at
tree.cc:5097)
FAIL: gcc.dg/vect/slp-reduc-10c.c (internal compiler error: in build2, at
tree.cc:5097)
FAIL: gcc.dg/vect/slp-reduc-10d.c (internal compiler error: in build2, at
tree.cc:5097)
FAIL: gcc.dg/vect/slp-reduc-10e.c (internal compiler error: in build2, at
tree.cc:5097)
FAIL: gcc.dg/vect/vect-ifcvt-19.c -flto -ffat-lto-objects (internal compiler
error: in build2, at tree.cc:5097)
FAIL: gcc.dg/vect/vect-cond-arith-2.c -flto -ffat-lto-objects (internal
compiler error: in build2, at tree.cc:5097)
FAIL: gcc.dg/vect/vect-cond-arith-2.c (internal compiler error: in build2, at
tree.cc:5097)
FAIL: gcc.dg/vect/slp-reduc-10b.c -flto -ffat-lto-objects (internal compiler
error: in build2, at tree.cc:5097)
FAIL: gcc.dg/vect/slp-reduc-10c.c -flto -ffat-lto-objects (internal compiler
error: in build2, at tree.cc:5097)
FAIL: gcc.dg/vect/slp-reduc-10d.c -flto -ffat-lto-objects (internal compiler
error: in build2, at tree.cc:5097)
FAIL: gcc.dg/vect/slp-reduc-10e.c -flto -ffat-lto-objects (internal compiler
error: in build2, at tree.cc:5097)

[Bug rtl-optimization/113546] [13/14 Regression] aarch64: bootstrap-debug-lean broken with -fcompare-debug failure since r13-2921-gf1adf45b17f7f1

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

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

Alex Coplan  changed:

   What|Removed |Added

   Keywords||compare-debug-failure
Summary|aarch64:|[13/14 Regression] aarch64:
   |bootstrap-debug-lean broken |bootstrap-debug-lean broken
   |with -fcompare-debug|with -fcompare-debug
   |failure |failure since
   ||r13-2921-gf1adf45b17f7f1
 Target||aarch64-*-*

--- Comment #1 from Alex Coplan  ---
The reduced testcase started failing with
r13-2921-gf1adf45b17f7f1ede463524d80032bb2ec866ead:

commit f1adf45b17f7f1ede463524d80032bb2ec866ead
Author: Eugene Rozenfeld 
Date:   Thu Apr 21 23:42:15 2022

Add instruction level discriminator support.

This is the first in a series of patches to enable discriminator support
in AutoFDO.

[Bug c++/113529] Incorrect result of requires-expression in case of function call ambiguity and `operator<=>`

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug target/113549] float simd crash on windows in gcc.dg/vect/vect-simd-clone-16b.c

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #1 from nightstrike  ---
Created attachment 57188
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57188=edit
Failing source for easier copying

[Bug target/113549] float simd crash on windows in gcc.dg/vect/vect-simd-clone-16b.c

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

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

--- Comment #3 from Andrew Pinski  ---
Either the stack size or the stack alignment issue.

I am suspecting a stack alignement issue.

[Bug rtl-optimization/113546] [13/14 Regression] aarch64: bootstrap-debug-lean broken with -fcompare-debug failure since r13-2921-gf1adf45b17f7f1

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

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

--- Comment #4 from Andrew Pinski  ---
Note the reduced testcase might NOT be a representative of the original issue
though ...

[Bug testsuite/113548] gcc.dg/vect/vect-ifcvt-19.c ICEs on LLP64 target

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |testsuite
   Keywords||testsuite-fail
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=108954
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|ICE vect-ifcvt-19 in|gcc.dg/vect/vect-ifcvt-19.c
   |build2, at tree.cc:5097 |ICEs on LLP64 target
 Target|x86_64-w64-mingw32  |*-*-mingw
   Last reconfirmed||2024-01-22

--- Comment #1 from Andrew Pinski  ---
Note this is just the bug for the testcase issue rather than the ICE, the ICE
is PR 108954 .

We should change  the type of _2 and _1  to __SIZE_TYPE__ from `unsigned long`
as size_type on mingw (and some other targets) is NOT the same size as
`unsigned long`.

[Bug target/109929] profiledbootstrap failure on aarch64-linux-gnu with graphite optimization

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

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

--- Comment #6 from Xi Ruoyao  ---
The first commit deferring the failure to stagefeedback is:

commit 575858508090b18dcbc176db285c9f55227ca4c0
Author: Richard Sandiford 
Date:   Tue Oct 17 23:46:33 2023 +0100

aarch64: Use vecs to store register save order

[Bug tree-optimization/113476] [14 Regression] irange::maybe_resize leaks memory via IPA VRP

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

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

--- Comment #4 from Martin Jambor  ---
The right place where to free stuff in lattices post-IPA would be in
ipa_node_params::~ipa_node_params() where we should iterate over lattices and
deinitialize them or perhaps destruct the array because since ipcp_vr_lattice
directly contains Value_Range which AFAIU directly contains int_range_max which
has a virtual destructor... does not look like a POD anymore.  This has escaped
me when I was looking at the IPA-VR changes but hopefully it should not be too
difficult to deal with.

[Bug ada/113536] valid reduction expression rejected by -gnatVo

[devotus at yahoo dot com via Gcc-bugs]

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

--- Comment #1 from Jack Perry  ---
Per Simon Wright, gcc 14.0.0 does not fail on this, whereas gcc 14.0.1 does, in
the same location, but with a different error: `expected type "Value"... found
type "Standard.Character"`

I edited his message to conform with the types I used in the example below, but
I've also observed it on godbolt's compiler explorer when using gnat "trunk".

[Bug c++/113547] c++: In function ‘std::vector package_b_info()’: cc1plus: internal compiler error: Segmentation fault

[csfore at posteo dot net via Gcc-bugs]

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

--- Comment #1 from Christopher Fore  ---
Created attachment 57185
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57185=edit
minimized file with cvise

[Bug rtl-optimization/113546] [13/14 Regression] aarch64: bootstrap-debug-lean broken with -fcompare-debug failure since r13-2921-gf1adf45b17f7f1

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> That means this is most likely a dup of bug 107169.

And PR 100733.

[Bug rtl-optimization/113546] [13/14 Regression] aarch64: bootstrap-debug-lean broken with -fcompare-debug failure since r13-2921-gf1adf45b17f7f1

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Alex Coplan from comment #1)
> The reduced testcase started failing with
> r13-2921-gf1adf45b17f7f1ede463524d80032bb2ec866ead:
> 
> commit f1adf45b17f7f1ede463524d80032bb2ec866ead
> Author: Eugene Rozenfeld 
> Date:   Thu Apr 21 23:42:15 2022
> 
> Add instruction level discriminator support.
> 
> This is the first in a series of patches to enable discriminator support
> in AutoFDO.

That means this is most likely a dup of bug 107169.

[Bug debug/113382] FAIL: gcc.dg/debug/btf/btf-bitfields-3.c scan-assembler-times [\t ]0x6000004[\t ]+[^\n]*btt_info 1

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #7 from John David Anglin  ---
Fixed on trunk.

[Bug target/113549] float simd crash on windows in gcc.dg/vect/vect-simd-clone-16b.c

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #2 from nightstrike  ---
Test 16e uses double instead of float, which also crashes.

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

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

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

--- Comment #17 from Steve Kargl  ---
On Mon, Jan 22, 2024 at 05:35:41PM +, anlauf at gcc dot gnu.org wrote:
> --- Comment #16 from anlauf at gcc dot gnu.org ---
> (In reply to Steve Kargl from comment #14)
> > On Sun, Jan 21, 2024 at 09:52:39PM +, anlauf at gcc dot gnu.org wrote:
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
> > > 
> > > I think that you cannot do
> > > 
> > > +  if (MPFR_HALF_CYCLE)
> > > 
> > > you really must use
> > > 
> > > #if MPFR_HALF_CYCLE
> > > 
> > 
> > #include 
> > #include "mpfr.h"
> > 
> > #define MPFR_HALF_CYCLE (MPFR_VERSION_MAJOR * 100 + MPFR_VERSION_MINOR >=
> > 402)
> > 
> > int
> > main(void)
> > {
> >if (MPFR_HALF_CYCLE)
> >   printf("here\n");
> >else
> >   printf("there\n");
> >return (0);
> > }
> > 
> > % cc -o z -I/usr/local/include a.c && ./z
> 
> This does not test the right thing.
> 
> % cat sgk.cc
> #include 
> 
> #define MPFR_HALF_CYCLE 0

This is not what the pre-processor should be doing
(on at least FreeBSD).  See below.


> int
> main(void)
> {
>if (MPFR_HALF_CYCLE)
>   printf_not_declared_if_0 ("here\n");
>else
>   printf ("there\n");
>return (0);
> }
> 
> % g++ sgk.cc
> sgk.cc: In function 'int main()':
> sgk.cc:9:7: error: 'printf_not_declared_if_0' was not declared in this scope
>printf_not_declared_if_0 ("here\n");
>^~~~

Of course, it will fail.  You need to actually have a
printf_not_declared_if_0 function defined during parsing.

#include 
#include 

#define MPFR_HALF_CYCLE 1
#define printf_not_declared_if_0(a) abort()

int
main(void)
{
   if (MPFR_HALF_CYCLE)
  printf_not_declared_if_0 ("here\n");
   else
  printf ("there\n");
   return (0);
}

~/work/x/bin/g++ -I/usr/local/include -o z a.cc && ./z
Abort (core dumped)

Changing 1 to 0 the MPFR_HALF_CYCLE define.

 ~/work/x/bin/g++ -I/usr/local/include -o z a.cc && ./z
there

Going back to my original example and g++ from master, I'm seeing

% ~/work/x/bin/g++ -I/usr/local/include -E a.cc

int
main(void)
{
   if ((
# 9 "a.cc" 3
  4 
# 9 "a.cc"
  * 100 + 
# 9 "a.cc" 3
  2 
# 9 "a.cc"
  >= 402))
  printf("here\n");
   else
  printf("there\n");
   return (0);
}

and with clang++

% c++ -E -I/usr/local/include a.cc
int
main(void)
{
   if ((4 * 100 + 2 >= 402))
  printf("here\n");
   else
  printf("there\n");
   return (0);
}

Is there something that is different between your OS and FreeBSD?
Or is there some fundamental difference between C and C++ that
I am unaware of?

[Bug testsuite/113548] gcc.dg/vect/vect-ifcvt-19.c ICEs on LLP64 target

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
I will fix this testcase today or tomorrow.  It should not be hard.

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #16 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #14)
> On Sun, Jan 21, 2024 at 09:52:39PM +, anlauf at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
> > 
> > I think that you cannot do
> > 
> > +  if (MPFR_HALF_CYCLE)
> > 
> > you really must use
> > 
> > #if MPFR_HALF_CYCLE
> > 
> 
> #include 
> #include "mpfr.h"
> 
> #define MPFR_HALF_CYCLE (MPFR_VERSION_MAJOR * 100 + MPFR_VERSION_MINOR >=
> 402)
> 
> int
> main(void)
> {
>if (MPFR_HALF_CYCLE)
>   printf("here\n");
>else
>   printf("there\n");
>return (0);
> }
> 
> % cc -o z -I/usr/local/include a.c && ./z

This does not test the right thing.

% cat sgk.cc
#include 

#define MPFR_HALF_CYCLE 0

int
main(void)
{
   if (MPFR_HALF_CYCLE)
  printf_not_declared_if_0 ("here\n");
   else
  printf ("there\n");
   return (0);
}

% g++ sgk.cc
sgk.cc: In function 'int main()':
sgk.cc:9:7: error: 'printf_not_declared_if_0' was not declared in this scope
   printf_not_declared_if_0 ("here\n");
   ^~~~

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

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

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

--- Comment #18 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #17)
> Is there something that is different between your OS and FreeBSD?
> Or is there some fundamental difference between C and C++ that
> I am unaware of?

You should not expect everybody to have the latest MPFR installed.
That's the whole point.

Please use #if / #else / #endif

[Bug c++/109642] False Positive -Wdangling-reference with std::span-like classes

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

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

--- Comment #14 from Marek Polacek  ---
(In reply to Miro Palmu from comment #11)
> I'm not sure if this is useful information but, using span with a view in a
> ranged-based for loop triggers false positive -Wdangling-referene on gcc
> 14.0.1 20240117 but not on gcc 13.2.
> 
> // On godbold: https://godbolt.org/z/x9jKh4MoW
> #include 
> #include 
> #include 
> 
> int main() {
> const auto vec = std::vector{ 1, 2, 3 };
> const auto s = std::span{vec};
> 
> // -Wwaring=dangling-reference on gcc 14.0.1 20240117 but not on gcc 13.2
> for ([[maybe_unused]] auto _ : s | std::views::take(2)) { }
> 
> // No warning
> for ([[maybe_unused]] auto _ : vec | std::views::take(2)) { }
> 
> // No warning
> const auto s_view = s | std::views::take(2);
> for ([[maybe_unused]] auto _ : s_view) { }
> }

This should be fixed now.  I'm going to expand Wdangling-reference17.C with
this test though.  Thanks.

[Bug target/109929] profiledbootstrap failure on aarch64-linux-gnu with graphite optimization

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

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

--- Comment #7 from Richard Sandiford  ---
Hmm, yeah, like you say, neither of those commits should have made a different
to whether bootstrap works.  I guess the problem is just latent now.

[Bug target/113549] New: float simd crash on windows in gcc.dg/vect/vect-simd-clone-16b.c

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 113549
   Summary: float simd crash on windows in
gcc.dg/vect/vect-simd-clone-16b.c
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

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

The vect-simd-clone-16b.c test runs the vect-simd-clone-16.c test with the TYPE
set to float.  The default type is int, which works fine.  Reducing that
testcase yields the following:


```
#define TYPE float
#pragma omp declare simd inbranch
TYPE __attribute__((noinline))
foo (TYPE a)
{
  return a + 1;
}

void
masked_fixed (TYPE * a, TYPE * b)
{
  #pragma omp simd
  for (int i = 0; i < 128; i++)
b[i] = a[i]<1 ? foo(a[i]) : a[i];
}

int main() {
TYPE a[1024] = {0};
TYPE b[1024] = {0};
masked_fixed(a, b);
return 0;
}
```

The noipa attribute and the __restrict keywords were removed from masked_fixed.
 noinline is required on foo.


Minimal set of compile arguments required to trigger the problem:
$ x86_64-w64-mingw32-gcc  a.c -fopenmp-simd -O2 -mavx

Note that dropping to -01 or removing -mavx avoids the crash.  

Assembly from -save-temps -fverbose-asm attached.

This is technically running under wine 8.0.  This is the backtrace provided by
wine:

```
wine: Unhandled page fault on read access to  at address
00014000163F (thread 0024), starting debugger...
Unhandled exception: page fault on read access to 0x in 64-bit
code (0x014000163f).
Register dump:
 rip:00014000163f rsp:0021dc50 rbp:0021dcd0 eflags:00010246
(  R- --  I  Z- -P- )
 rax: rbx: rcx:0021dcf0
rdx:0021dcd0
 rsi:0021ed70 rdi:0021dd70  r8:0021dcb0 
r9:00c92000 r10:00c90330
 r11: r12:0021dcb0 r13:0021dcf0
r14: r15:
Stack dump:
0x21dc50:   
0x21dc60:   
0x21dc70:   
0x21dc80:   
0x21dc90:   
0x21dca0:   
0x21dcb0:   
0x21dcc0:   
0x21dcd0:   
0x21dce0:   
0x21dcf0:   
0x21dd00:   
Backtrace:
=>0 0x014000163f in a (+0x163f) (0x21dcd0)
  1 0x0140003384 in a (+0x3384) (0x21fdf0)
  2 0x0140001340 in a (+0x1340) (0x21fdf0)
  3 0x0140001146 in a (+0x1146) (0x21fe30)
  4 0x007b647b51 BaseThreadInitThunk+0x11(unknown=,
entry=, arg=)
[H:\home\user\p\gcc\src\wine-8.0-rc4p2p3\dlls\kernel32\thread.c:61] in kernel32
(0x0
00021fe60)
0x014000163f a+0x163f: ldsl %esp,%edi
```

[Bug rtl-optimization/113533] [14 Regression] Code generation regression after change for pr111267

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

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

--- Comment #9 from Oleg Endo  ---
(In reply to Roger Sayle from comment #8)
> Created attachment 57190 [details]
> proposed patch
> 
> Proposed patch to provide a sane/saner set of rtx_costs for SH.  There's
> plenty more that could be done, but these changes are (more than) sufficient
> to resolve the code quality regression caused by improved fwprop.  If
> someone could try this out on SH, and report back the results, that would be
> great.


You've added differentiation for 'speed ?' in 'sh_address_cost'.  Like this
one.

   /* 'GBR + 0'.  Account one more because of R0 restriction.  */
   if (REG_P (x) && REGNO (x) == GBR_REG)
-return 2;
+return speed ? 2 : 0;

What's the intention here?  Why does the cost of the address computation
reduced when not optimizing for speed?  It distorts the address costs and makes
them all equal.

[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings

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

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

Bug 90463 Summary: Documentation: -Wunused not listed among the options enabled 
by -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90463

   What|Removed |Added

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

[Bug c++/90463] Documentation: -Wunused not listed among the options enabled by -Wall

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from sandra at gcc dot gnu.org ---
Marking this fixed now.

[Bug tree-optimization/113441] [14 Regression] Fail to fold the last element with multiple loop

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

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

--- Comment #10 from JuzheZhong  ---
(In reply to Tamar Christina from comment #9)
> So on SVE the change is cost modelling.
> 
> Bisect landed on g:33c2b70dbabc02788caabcbc66b7baeafeb95bcf which changed
> the compiler's defaults to using the new throughput matched cost modelling
> used be newer cores.
> 
> It looks like this changes which mode the compiler picks for when using a
> fixed register size.
> 
> This is because the new cost model (correctly) models the costs for FMAs and
> promotions.
> 
> Before:
> 
> array1[0][_1] 1 times scalar_load costs 1 in prologue
> int) _2 1 times scalar_stmt costs 1 in prologue
> 
> after:
> 
> array1[0][_1] 1 times scalar_load costs 1 in prologue 
> (int) _2 1 times scalar_stmt costs 0 in prologue 
> 
> and the cost goes from:
> 
> Vector inside of loop cost: 125
> 
> to
> 
> Vector inside of loop cost: 83 
> 
> so far, nothing sticks out, and in fact the profitability for VNx4QI drops
> from
> 
> Calculated minimum iters for profitability: 5
> 
> to
> 
> Calculated minimum iters for profitability: 3
> 
> This causes a clash, as this is now exactly the same cost as VNx2QI which
> used to be what it preferred before.
> 
> Which then leads it to pick the higher VF.
> 
> In the end smaller VF shows:
> 
> ;; Guessed iterations of loop 4 is 0.500488. New upper bound 1.
> 
> and now we get:
> 
> Vectorization factor 16 seems too large for profile prevoiusly believed to
> be consistent; reducing.  
> ;; Guessed iterations of loop 4 is 0.500488. New upper bound 0.
> ;; Scaling loop 4 with scale 66.6% (guessed) to reach upper bound 0
> 
> which I guess is the big difference.
> 
> There is a weird costing going on in the PHI nodes though:
> 
> m_108 = PHI  1 times vector_stmt costs 0 in body 
> m_108 = PHI  2 times scalar_to_vec costs 0 in prologue
> 
> they have collapsed to 0. which can't be right..

I don't think this change makes the regression since the regression not only
happens on ARM SVE but also on RVV.
It should be middle-end.

I believe you'd better use -fno-vect-cost-model.

[Bug rtl-optimization/113533] [14 Regression] Code generation regression after change for pr111267

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #10 from Roger Sayle  ---
Hi Oleg.  Great question.  The "speed" parameter passed to rtx_costs, and
address_cost indicates whether the middle-end is optimizing for peformance, and
interested in the nummber of cycles taken by each instruction, or optimizing
for size, and interested in the number of bytes used to encode the instruction.
 Previously, this speed parameter was ignored by the SH backend, so the costs
were the same independent of the objective function.

In my proposed patch, the address cost (1) when optimizing for size attempts to
return the additional size of an instruction based on the addressing mode.  For
register, and reg+reg addressing modes there is no size increase (overhead),
and for adressing modes with displacements, and displacements to address
pointers, there is a cost.  (2) when optimizing for speed, address cost remains
between 0 and 3, and is used to prioritize between (equivalent numbers of)
instructions.  Normally, rtx_costs are defined in terms of COST_N_INSNS, which
multiplies by 4.  Hence on many platforms a single instruction that references
memory may be encoded as COSTS_N_INSNS(1)+1 (or a more complex addressing mode
as COSTS_N_INSNS(1)+2) to show that this is disfavored to a single instruction
that doesn't reference memory, COSTS_N_INSNS(1)+0.

This is the fix for this particular regression; SIGN_EXTEND of a register now
costs COSTS_N_INSNS(1), and SIGN_EXTEND of a MEM now costs COSTS_N_INSNS(1)+1.

A useful way to debug rtx_costs is to use the -dP command line option, and then
look at the [c=X, l=Y] annotations in the assembly language file.  One way to
check/confirm that these are sensible is that ideally they should be correlated
when optimizing for size (with -Os or -Oz).

I've found an interesting table of SH cycle counts (for different CPUs) at
http://www.shared-ptr.com/sh_insns.html and these could be used to improve
sh_rtx_costs further.  For example, SH currently reports multiplications as
a single cycle operation, which doesn't match the hardware specs, and prevents
GCC from using synth_mult to produce faster (or shorter) sequences using shifts
and additions.  Likewise, sh_rtx_costs doesn't distinguish the machine mode,
so the costs of SImode multiplications are the same as DImode multiplications.

In comment #5 you mention GCC's defaults; it turns out that for rtx_costs the
default values that would be provided by the middle-end, may be more accurate
than the values (currently) specified by the backend.

I hope this answers your question.

[Bug tree-optimization/113551] Miscompilation with -O1 -funswitch-loops -fno-strict-overflow

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|rtl-optimization|tree-optimization
   Keywords||wrong-code

--- Comment #3 from Andrew Pinski  ---
Looks like the unswitch is happening when it should not be ...

[Bug tree-optimization/113551] Miscompilation with -O1 -funswitch-loops -fno-strict-overflow

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||5.4.0

--- Comment #4 from Andrew Pinski  ---
The incorrect unswitch has been happening since at least GCC 5 ...

[Bug rtl-optimization/113533] [14 Regression] Code generation regression after change for pr111267

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

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

--- Comment #11 from Oleg Endo  ---
(In reply to Roger Sayle from comment #10)

> I've found an interesting table of SH cycle counts (for different CPUs) at
> http://www.shared-ptr.com/sh_insns.html

Yeah, I know.  I did that ;)

> In my proposed patch, the address cost (1) when optimizing for size attempts
> to return the additional size of an instruction based on the addressing
> mode.  For register, and reg+reg addressing modes there is no size increase
> (overhead), and for adressing modes with displacements, and displacements to
> address pointers, there is a cost.

AFAIR, I've added the 'sh_address_cost' function.  The intention was/is to
encourage/discourage usage of certain address modes based on the side effects
and impact on the surrounding code.  All insns/addr modes have the same length
and basically same execution time.  However, e.g. @(reg+reg) has a constraint
on 'r0' usage, so I weighted that heavier.  If there's anything that could use
@(reg+disp) as an alternative, that'd be better in some cases. (not sure if
such optimizations actually are done...)

> (2) when optimizing for speed, address
> cost remains between 0 and 3, and is used to prioritize between (equivalent
> numbers of) instructions.  Normally, rtx_costs are defined in terms of
> COST_N_INSNS, which multiplies by 4.  Hence on many platforms a single
> instruction that references memory may be encoded as COSTS_N_INSNS(1)+1 (or
> a more complex addressing mode as COSTS_N_INSNS(1)+2) to show that this is
> disfavored to a single instruction that doesn't reference memory,
> COSTS_N_INSNS(1)+0.

That's actually what sh_rtx_costs was supposed to do as well.  I think in usual
cases it does that, only that apparently I've screwed up the {SIGN|ZERO}_EXTEND
for the case of the mem load and it shows up only now, many years later.

It's still not entirely clear to me why we would want to squash the costs of
addresses to 0 when optimizing for size?  What does effect does it have on the
generated code?  I can't imagine how it would be possibly making any smaller
code?

With your patch, in case of the SIGN_EXTEND with mem operand, it would make the
address cost 0 with -Os, which would return COSTS_N_INSNS(1) for reg operand as
well as mem operand.  So both insns are equally weighted and could be
considered interchangeable.  And we might bump into this type of regression
again, if some (future) optimization decides that it can interchange/substitute
insns of the same cost... 


> For example, SH currently reports multiplications as a single cycle operation,

That doesn't seem to be the case.  It's supposed to be using the function
'multcosts' in sh.cc, which returns at least a cost of '2'.  Note that on SH1
and SH2 there is no dynamic (barrel) shift.  So actually some multiplications
could be faster than stitched shifts.


> sh_rtx_costs doesn't distinguish the machine mode, so the costs of SImode 
> multiplications are the same as DImode multiplications.

I guess this is because SH doesn't have real DImode multiplication (64 x 64 ->
64/128 bit).  It can only do 32 x 32 -> 64 bit widening multiplication.  Any
real DImode multiplication will result in either expanded sequence to calculate
sum of particial products or a libcall, AFAIR

[Bug rtl-optimization/113546] [13/14 Regression] aarch64: bootstrap-debug-lean broken with -fcompare-debug failure since r13-2921-gf1adf45b17f7f1

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

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

--- Comment #5 from Alex Coplan  ---
FWIW the original preprocessed testcase (regex.i) also started failing with the
same commit (as the reduced testcase).

[Bug rtl-optimization/113551] Miscompilation with -O1 -funswitch-loops -fno-strict-overflow

[yshuiv7 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Yuxuan Shui  ---
code is reduced from perf, source file util/dsos.c

[Bug target/113507] can't build a cross compiler to rs6000-ibm-aix7.2

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

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

--- Comment #4 from David Edelsohn  ---
rs6000-ibm-aix doesn't exist anymore.  This should have been configured as
powerpc-ibm-aix7.2 .  Maybe there is some magic about the "powerpc" name?

Those variables are provided by generated files and apparently something is not
generating them when building a cross compiler.

[Bug c++/113547] [13 Regression] c++: In function ‘std::vector package_b_info()’: cc1plus: internal compiler error: Segmentation fault

[csfore at posteo dot net via Gcc-bugs]

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

--- Comment #3 from Christopher Fore  ---
Backtrace:

In function ‘std::vector package_b_info()’:
cc1plus: internal compiler error: Segmentation fault
0xe4dfcf crash_signal
   
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/toplev.cc:314
0x759446 error_operand_p(tree_node const*)
   
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/tree.h:4501
0x759446 cp_gimplify_expr(tree_node**, gimple**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/cp/cp-gimplify.cc:550
0xb9c8d7 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/gimplify.cc:16292
0xba3f45 gimplify_stmt(tree_node**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/gimplify.cc:7226
0xba3f45 gimplify_compound_expr
   
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/gimplify.cc:6412
0xb9eaba gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/gimplify.cc:16373
0xb9d3a2 gimplify_stmt(tree_node**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/gimplify.cc:7226
0xb9d3a2 gimplify_and_add(tree_node*, gimple**)
   
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/gimplify.cc:492
0xb9d3a2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/gimplify.cc:16751
0xb9e065 gimplify_stmt(tree_node**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/gimplify.cc:7226
0xb9e065 gimplify_statement_list
   
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/gimplify.cc:2019
0xb9e065 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/gimplify.cc:16828
0xba576b gimplify_stmt(tree_node**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/gimplify.cc:7226
0xba576b gimplify_bind_expr
   
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/gimplify.cc:1430
0xb9dcd1 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/gimplify.cc:16584
0xba1629 gimplify_stmt(tree_node**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/gimplify.cc:7226
0xba1629 gimplify_body(tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/gimplify.cc:17645
0xba1a02 gimplify_function_tree(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/gimplify.cc:17844
0xa10d77 cgraph_node::analyze()
   
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/cgraphunit.cc:684
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/113550] New: data512_t initializers dereference a clobbered register

[ianthompson at microsoft dot com via Gcc-bugs]

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

Bug ID: 113550
   Summary: data512_t initializers dereference a clobbered
register
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ianthompson at microsoft dot com
  Target Milestone: ---
Target: aarch64

Created attachment 57189
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57189=edit
Additional non-minimal failing cases

When initializing or copying a data512_t, the compiler is generating code which
clobbers the register containing the source pointer of the copy. Initially
observed on Arm GNU Toolchain 12.2.Rel1, but this also reproduces on trunk.

Minimal reproduction, hits a segfault when compiled with "aarch64-none-elf-gcc
-march=armv9-a+ls64":

#include 
void test_data512_init() {
data512_t my_value = {};
}

This code generates this assembly snippet for initializing my_value:
adrpx0, .LC0
add x0, x0, :lo12:.LC0
ldp x0, x1, [x0]
ldp x2, x3, [x0, 16]
ldp x4, x5, [x0, 32]
ldp x6, x7, [x0, 48]

Notice that the first ldp clobbers x0, redirecting the remaining 3 loads to
whatever address happens to be in val[0] of the initializer.

Similar incorrect code is generated in many other situations that involve
copying a data512_t (passing a global variable to a function, dereferencing a
data512_t*, etc). See the attached source file for the other failing cases I'm
seeing.

[Bug target/113549] float simd crash on windows in gcc.dg/vect/vect-simd-clone-16b.c

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #4 from nightstrike  ---
(In reply to Andrew Pinski from comment #3)
> Either the stack size or the stack alignment issue.
> 
> I am suspecting a stack alignement issue.

Possibly related: PR110273

[Bug c++/113531] [14 Regression] AddressSanitizer: stack-use-after-scope when iterating over initializer list since r14-1500-g4d935f52b0d5c0

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

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

--- Comment #1 from Andrew Pinski  ---
It would be useful to get a reduced testcase without the use of the Catch2Main
library.

[Bug c++/90463] Documentation: -Wunused not listed among the options enabled by -Wall

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Sandra Loosemore :

https://gcc.gnu.org/g:7e758890a4c86db790a5f9aef0191eef77047f65

commit r14-8342-g7e758890a4c86db790a5f9aef0191eef77047f65
Author: Sandra Loosemore 
Date:   Mon Jan 22 22:38:49 2024 +

Correct lists of options enabled by -Wall and -Wextra [PR90463]

gcc/ChangeLog
PR c++/90463
* doc/invoke.texi (Warning Options): Correct lists of options
enabled by -Wall and -Wextra by checking against common.opt
and c-family/c.opt.

[Bug target/53929] [meta-bug] -masm=intel with global symbol

[lh_mouse at 126 dot com via Gcc-bugs]

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

--- Comment #25 from LIU Hao  ---
Created attachment 57191
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57191=edit
Draft patch

This is a draft patch, bootstrapped on {i686,x86_64}-w64-mingw32 successfully.
Haven't run tests though.

[Bug tree-optimization/113551] [13/14 Regression] Miscompilation with -O1 -funswitch-loops -fno-strict-overflow

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|Miscompilation with -O1 |[13/14 Regression]
   |-funswitch-loops|Miscompilation with -O1
   |-fno-strict-overflow|-funswitch-loops
   ||-fno-strict-overflow
   Last reconfirmed||2024-01-23
 Status|UNCONFIRMED |NEW
  Known to fail|5.4.0   |13.2.0
   Target Milestone|--- |13.3

--- Comment #5 from Andrew Pinski  ---
Confirmed at least for the bad unswitch which causes the other wrong code to
happen.

[Bug c++/113547] [13 Regression] c++: In function ‘std::vector package_b_info()’: cc1plus: internal compiler error: Segmentation fault

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Andrew Pinski  ---
(In reply to Christopher Fore from comment #3)
> Backtrace:
> 
> In function ‘std::vector package_b_info()’:
> cc1plus: internal compiler error: Segmentation fault
> 0xe4dfcf crash_signal
>   
> /var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/
> toplev.cc:314
> 0x759446 error_operand_p(tree_node const*)
>   
> /var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/
> tree.h:4501
> 0x759446 cp_gimplify_expr(tree_node**, gimple**, gimple**)
>   
> /var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/gcc/
> cp/cp-gimplify.cc:550


Yep, a dup of bug 113347.

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

[Bug c++/113347] [12/13 Regression] ICE during gimplification building TVM since r13-8079-gd237e7b291ff52

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||csfore at posteo dot net

--- Comment #9 from Andrew Pinski  ---
*** Bug 113547 has been marked as a duplicate of this bug. ***

[Bug target/113550] data512_t initializers dereference a clobbered register

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-22
 Ever confirmed|0   |1
   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

--- Comment #1 from Andrew Pinski  ---
Should be an easy fix.

The pattern:
(define_insn "*aarch64_movv8di"
  [(set (match_operand:V8DI 0 "nonimmediate_operand" "=r,m,r")
(match_operand:V8DI 1 "general_operand" " r,r,m"))]
  "(register_operand (operands[0], V8DImode)
|| register_operand (operands[1], V8DImode))"
  "#"
  [(set_attr "type" "multiple,multiple,multiple")
   (set_attr "length" "32,16,16")]
)

Is missing a & on the r/m case.

Or the split could be improved such that the one that gets loadded last is the
one that might conflict:
(define_split
  [(set (match_operand:V8DI 0 "nonimmediate_operand")
(match_operand:V8DI 1 "general_operand"))]
  "reload_completed"
  [(const_int 0)]

aarch64_simd_emit_reg_reg_move handles this case already too.

I am going to go with the improving the define_split ...

[Bug rtl-optimization/113551] Miscompilation with -O1 -funswitch-loops -fno-strict-overflow

[yshuiv7 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Yuxuan Shui  ---
regression from 12.3 -> 13.2

[Bug rtl-optimization/113533] [14 Regression] Code generation regression after change for pr111267

[roger at nextmovesoftware dot com via Gcc-bugs]

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

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

Proposed patch to provide a sane/saner set of rtx_costs for SH.  There's plenty
more that could be done, but these changes are (more than) sufficient to
resolve the code quality regression caused by improved fwprop.  If someone
could try this out on SH, and report back the results, that would be great.

[Bug c++/113531] [14 Regression] AddressSanitizer: stack-use-after-scope when iterating over initializer list

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |14.0
Summary|AddressSanitizer:   |[14 Regression]
   |stack-use-after-scope when  |AddressSanitizer:
   |iterating over initializer  |stack-use-after-scope when
   |list|iterating over initializer
   ||list

[Bug rtl-optimization/113551] New: Miscompilation with -O1 -funswitch-loops -fno-strict-overflow

[yshuiv7 at gmail dot com via Gcc-bugs]

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

Bug ID: 113551
   Summary: Miscompilation with -O1 -funswitch-loops
-fno-strict-overflow
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yshuiv7 at gmail dot com
  Target Milestone: ---

Code:

struct obj {
int __pad;
int i;
};

/* aborts when called with NULL */
int assert_not_null(void *); 

void bug(struct obj **root, struct obj *dso) {
while (1) {
struct obj *this = *root;

if (dso == (void *)0)
// should return here
return;

if (dso == this)
return;

// shouldn't reach here
assert_not_null(dso);

if (!>i)
break;
}
}

// call like this: bug(, NULL);

Result:

* -O1: ok
* -O1 -funswitch-loops: ok
* -O1 -fno-strict-overflow: ok
* -O1 -funswitch-loops -fno-strict-overflow: abort

[Bug libstdc++/113504] High memory usage for parallel `std::sort`

[ruben.laso at tuwien dot ac.at via Gcc-bugs]

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

--- Comment #2 from Ruben Laso  ---
(In reply to Jonathan Wakely from comment #1)
> The parallel algos are taken from
> https://github.com/llvm/llvm-project/tree/main/pstl so I would file an issue
> upstream rather than here. The Intel PSTL developers are the right people to
> ask.

I will ask there, then. Thank you!

[Bug target/109929] profiledbootstrap failure on aarch64-linux-gnu with graphite optimization

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
let's close this then

[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues

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

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

Bug 109929 Summary: profiledbootstrap failure on aarch64-linux-gnu with 
graphite optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109929

   What|Removed |Added

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

[Bug libgcc/113401] Memory (resource) leak in -ftrampoline-impl=heap

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

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

--- Comment #4 from Florian Weimer  ---
(In reply to Iain Sandoe from comment #3)
> for platforms using pthreads as the underlying resource, then perhaps we can
> do this without thread_atexit (which I do not see in many places) by using
> pthread_cleanup_push ()

The current implementation already uses the same underlying mechanism as
pthread_cleanup_push if building with -fexceptions. It does not solve the leak
because the outermost handler deliberately does not perform a full deallocation
of the thread state.

[Bug lto/113521] ICE when building swi-prolog-9.1.2 with LTO in verify_gimple_in_cfg

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

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

--- Comment #3 from Richard Biener  ---
It's probably the same issue though - IPA summarries not being forgiving to
decl type changes.

[Bug libgcc/113401] Memory (resource) leak in -ftrampoline-impl=heap

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

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

--- Comment #7 from Iain Sandoe  ---
(In reply to Florian Weimer from comment #6)
> Sorry, pthread_cleanup_push is purely scope-based, like the existing
> handler. It cannot be used to push a handler to some unscoped cleanup
> function list that persists even after the current function returns. It's
> also implemented as a macro, so it's not possible to emit it from builtin
> expansion.

Ah, then we have a documentation issue, because man pthread_cleanup_push(3)
describes running the registered functions on thread cancellation or on
thread_exit() [but not, unfortunately if the thread exits by returning - so
still not ideal].

[Bug tree-optimization/113539] New: [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f

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

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

Bug ID: 113539
   Summary: [14 Regression] perlbench miscompiled on aarch64 since
r14-8223-g1c1853a70f
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

I'm seeing miscompares of perlbench (both from SPEC CPU 2006 and SPEC CPU 2017)
on aarch64 with recent trunk changes, a bisect pointed to
r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c :

commit 1c1853a70f9422169190e65e568dcccbce02d95c
Author: Richard Biener 
Date:   Thu Jan 18 10:22:34 2024

Fix memory leak in vect_analyze_loop_form

The miscompares are with the checkspam.pl workload, I see:

*** Miscompare of checkspam.2500.5.25.11.150.1.1.1.1.out

I've seen this with:

-flto=auto -fomit-frame-pointer -O3 -fno-strict-aliasing

and various -mcpu options (at least -mcpu=cortex-a72 and -mcpu=neoverse-v1).

[Bug libgcc/113401] Memory (resource) leak in -ftrampoline-impl=heap

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

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

--- Comment #9 from Iain Sandoe  ---
(In reply to Florian Weimer from comment #8)
> Which version of the manual page are you looking at?
> 
> https://man7.org/linux/man-pages/man3/pthread_cleanup_push.3.html seems
> pretty clear about the scope-based nature (search for discussion of
> break/return/goto).

yeah, got it; one needs to read the union of the sections (the page I was
reading was slightly different but the same basic info).

I suppose if we were able to create a wrapper around the thread routine and the
cleanup was NOP for cases without nested fns.

Otherwise, it looks a bit tricky for platforms without thread_atexit support.

Have to think some more.

[Bug other/111966] GCN '--with-arch=[...]' not considered for 'mkoffload' default 'elf_arch'

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:13127dac106724bef3a979539a878b368b79ce56

commit r14-8332-g13127dac106724bef3a979539a878b368b79ce56
Author: Tobias Burnus 
Date:   Mon Jan 22 12:17:12 2024 +0100

[gcn] mkoffload: Fix linking with "-g"; fix file deletion; improve
diagnostic [PR111966]

With debugging enabled, '*.mkoffload.dbg.o' files are generated. The
e_flags
header of all *.o files must be the same - otherwise, the linker complains.
Since r14-4734-g56ed1055b2f40ac162ae8d382280ac07a33f789f the -march=
default
is now gfx900. If compiling without any -march= flag, the default value is
used by the compiler but not passed to mkoffload. Hence, mkoffload.cc's
uses
its own default for march - unfortunately, it still had gfx803/fiji as
default,
leading to the linker error: 'incompatible mach'. Solution: Update the
default to gfx900.

While debugging it, I saw that /tmp/cc*.mkoffload.dbg.o kept accumulating;
there were a couple of issues with the handling:
* dbgobj was always added to files_to_cleanup
* If copy_early_debug_info returned true, dbgobj was added again
  -> pointless and in theory a race if the same file was added in the
 faction of a second.
* If copy_early_debug_info returned false,
  - In exactly one case, it already deleted the file it self
(same potential race as above)
  - The pointer dbgobj was freed - such that files_to_cleanup contained
a dangling pointer - probably the reason that stale files remained.
Solution: Only if copy_early_debug_info returns true, dbgobj is added to
files_to_cleanup. If it returns false, the file is unlinked before freeing
the pointer.

When compiling, GCC warned about several fatal_error messages as having
no %<...%> or %qs quotes. This patch now silences several of those warnings
by using those quotes.

gcc/ChangeLog:

PR other/111966
* config/gcn/mkoffload.cc (elf_arch): Change default to gfx900
to match the compiler default.
(simple_object_copy_lto_debug_sections): Never unlink the outfile
on error as the caller does so.
(maybe_unlink, compile_native): Use %<...%> and %qs in fatal_error.
(main): Likewise. Fix 'mkoffload.dbg.o' cleanup.

Signed-off-by: Tobias Burnus 

[Bug target/109929] profiledbootstrap failure on aarch64-linux-gnu with graphite optimization

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

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

--- Comment #5 from Xi Ruoyao  ---
The first good commit is:

commit aa2ad77a9b3994fb679e5295d9570f6f8696540d
Author: Szabolcs Nagy 
Date:   Tue May 9 11:07:05 2023 +0100

aarch64: Do not force a stack frame for EH returns

but I cannot see how it's related to the issue...

And with the parent of this commit, the bootstrap fails in stagefeedback where
build/genhooks -d ../../gcc/gcc/doc/tm.texi.in > tmp-tm.texi segfaults.  I'll
do another round of bisection to see when the stagetrain error was "fixed". 
(Just for better understanding the issue.)

[Bug ipa/113520] ICE with mismatched types with LTO (tree check: expected array_type, have integer_type in array_ref_low_bound)

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #7 from Richard Biener  ---
It's also a missing WPA diagnostic (OTOH one decl is just external and IIRC
we kind-of allow builtin_names[] to refer of a single element array
implemented as 'int builtin_names').

[Bug testsuite/113425] gcc.dg/fold-copysign-1.c fails on arm since g:7cbe41d35e6

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

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

--- Comment #3 from Christophe Lyon  ---
What I meant by arm-* is that we see the same issue on several of the
configurations we test, as can be seen on
https://linaro.atlassian.net/browse/GNU-1100

We have recently improved the extraction of the configure line, so now some of
the xxx/details.txt on that page include it.

The two "simplest" configurations we test are tcwg_gcc_check/master-arm and
tcwg_gnu_native_check_gcc, but both of them ran before the improvement
mentioned above; in these cases, the information is present inside
console.log.xz in the relevant CI step directory (03-build_abe-gcc for
tcwg_gcc_check/master-arm and 
04-build_abe-gcc for tcwg_gnu_native_check_gcc/master-arm, the "-gcc" suffix
meaning it's the step is which we build gcc)

Anyway, here is the GCC configure line for tcwg_gcc_check/master-arm:
/configure SHELL=/bin/bash 
--with-mpc=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/armv8l-unknown-linux-gnueabihf
--with-mpfr=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/armv8l-unknown-linux-gnueabihf
--with-gmp=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/armv8l-unknown-linux-gnueabihf
--with-gnu-as --with-gnu-ld --disable-libmudflap --enable-lto --enable-shared
--without-included-gettext --enable-nls --with-system-zlib
--disable-sjlj-exceptions --enable-gnu-unique-object --enable-linker-build-id
--disable-libstdcxx-pch --enable-c99 --enable-clocale=gnu
--enable-libstdcxx-debug --enable-long-long --with-cloog=no --with-ppl=no
--with-isl=no --disable-multilib --with-float=hard --with-fpu=neon-fp-armv8
--with-mode=thumb --with-arch=armv8-a --enable-threads=posix --enable-multiarch
--enable-libstdcxx-time=yes --enable-gnu-indirect-function
--enable-checking=yes --disable-bootstrap --enable-languages=default
--prefix=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/armv8l-unknown-linux-gnueabih

[Bug testsuite/113425] gcc.dg/fold-copysign-1.c fails on arm since g:7cbe41d35e6

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

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

--- Comment #4 from Tamar Christina  ---
(In reply to Christophe Lyon from comment #3)
> What I meant by arm-* is that we see the same issue on several of the
> configurations we test, as can be seen on
> https://linaro.atlassian.net/browse/GNU-1100
> 
> We have recently improved the extraction of the configure line, so now some
> of the xxx/details.txt on that page include it.
> 
> The two "simplest" configurations we test are tcwg_gcc_check/master-arm and
> tcwg_gnu_native_check_gcc, but both of them ran before the improvement
> mentioned above; in these cases, the information is present inside
> console.log.xz in the relevant CI step directory (03-build_abe-gcc for
> tcwg_gcc_check/master-arm and 
> 04-build_abe-gcc for tcwg_gnu_native_check_gcc/master-arm, the "-gcc" suffix
> meaning it's the step is which we build gcc)
> 
> Anyway, here is the GCC configure line for tcwg_gcc_check/master-arm:
> /configure SHELL=/bin/bash 
> --with-mpc=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/
> armv8l-unknown-linux-gnueabihf
> --with-mpfr=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/
> armv8l-unknown-linux-gnueabihf
> --with-gmp=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/
> armv8l-unknown-linux-gnueabihf --with-gnu-as --with-gnu-ld
> --disable-libmudflap --enable-lto --enable-shared --without-included-gettext
> --enable-nls --with-system-zlib --disable-sjlj-exceptions
> --enable-gnu-unique-object --enable-linker-build-id --disable-libstdcxx-pch
> --enable-c99 --enable-clocale=gnu --enable-libstdcxx-debug
> --enable-long-long --with-cloog=no --with-ppl=no --with-isl=no
> --disable-multilib --with-float=hard --with-fpu=neon-fp-armv8
> --with-mode=thumb --with-arch=armv8-a --enable-threads=posix
> --enable-multiarch --enable-libstdcxx-time=yes
> --enable-gnu-indirect-function --enable-checking=yes --disable-bootstrap
> --enable-languages=default
> --prefix=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/
> armv8l-unknown-linux-gnueabih

Yes, but the reason I need the configure flags is because it doesn't fail with
the arm-none-linux-gnueabihf target our build scripts make.

I'll check with those options.  Immediately one big difference is the forcing
of armv8 and thumb which is likely causing the difference.

[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f

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

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #1 from Tamar Christina  ---
If that's the commit that's miscomparing then it's probably a bug in
early-break vect.

So I'll take a look.

+ if ((integer_zerop (may_be_zero)
+  || integer_nonzerop (may_be_zero)

is odd though, isn't that basically accepting all values of may_be_zero?

[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

--- Comment #2 from Richard Biener  ---
It accepts all constant known may_be_zero - we can handle all of those later.

I suspect this just triggers a latent issue (vectorizing now simply using
a different exit as canonical in one case).

[Bug rtl-optimization/113495] RISC-V: Time and memory awful consumption of SPEC2017 wrf benchmark

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

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

--- Comment #27 from Robin Dapp  ---
Following up on this:

I'm seeing the same thing Patrick does.  We create a lot of large non-sparse
sbitmaps that amount to around 33G in total.

I did local experiments replacing all sbitmaps that are not needed for LCM by
regular bitmaps.  Apart from output differences vs the original version the
testsuite is unchanged.

As expected, wrf now takes longer to compiler, 8 mins vs 4ish mins before and
we still use 2.7G of RAM for this single file (Likely because of the remaining
sbitmaps) compared to a max of 1.2ish G that the rest of the commpilation uses.

One possibility to get the best of both worlds would be to threshold based on
num_bbs * num_exprs.  Once we exceed it switch to the bitmap pass, otherwise
keep sbitmaps for performance. 

Messaging with Juzhe offline, his best guess for the LICM time is that he
enabled checking for dataflow which slows down this particular compilation by a
lot.  Therefore it doesn't look like a generic problem.

[Bug testsuite/113425] gcc.dg/fold-copysign-1.c fails on arm since g:7cbe41d35e6

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

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #2 from Tamar Christina  ---
It is updated for arm, but I need to know how the toolchain was configured. 
This is just a difference in default options.

So I need the configure flags to be able to do anything here.

[Bug target/82580] Optimize comparisons for __int128 on x86-64

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #17 from Uroš Bizjak  ---
(In reply to Roger Sayle from comment #16)
> Advance warning that the testcase pr82580.c will start FAILing due to
> differences in register allocation following improvements to __int128
> parameter passing as explained in
> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623756.html.
> We might need additional reload alternatives/preferences to ensure that we
> don't generate a movzbl.  Hopefully, Jakub and/or Uros have some suggestions
> for how best this can be fixed.
> 
> Previously, the SUBREGs and CLOBBERs generated by middle-end RTL expansion
> (unintentionally) ensured that rdx and rax would never be used for __int128
> arguments, which conveniently allowed the use of xor eax,eax; setc al in
> peephole2 as AX_REG wasn't live.  Now reload has more freedom, it elects to
> use rax as at this point the backend hasn't expressed any preference that it
> would like eax reserved for producing the result.

A different regression happens with pr82580.c, f0 function. Without the patch,
the compiler generates:

f0:
xorq%rdi, %rdx
xorq%rcx, %rsi
xorl%eax, %eax
orq %rsi, %rdx
sete%al
ret

But with the patch:

f0:
xchgq   %rdi, %rsi
movq%rdx, %r8
movq%rcx, %rax
movq%rsi, %rdx
movq%rdi, %rcx
xorq%rax, %rcx
xorq%r8, %rdx
xorl%eax, %eax
orq %rcx, %rdx
sete%al
ret

It looks to me that *concatditi3_3 ties two registers together so RA now tries
to satisfy *concatditi3_3 constraints *and* *cmpti_doubleword constraints.

The gcc.target/i386/pr43644-2.c mitigates this issue with
*addti3_doubleword_concat pattern that combines *addti3_doubleword with concat
insn, but doubleword compares (and other doubleword insn besides addti3) do not
provide these compound instructions.

So, without a common strategy to use doubleword_concat patterns for all double
word instructions, it is questionable if the complications with concat insn are
worth the pain of providing (many?) doubleword_concat patterns.

The real issue is with x86_64 doubleword arguments. Unfortunately, the ABI
specifies RDI/RSI to pass the double word argument, while the compiler regalloc
order sequence is RSI/RDI. IMO, we can try to swap RDI and RSI in the order and
RA would be able to allocate registers in the same optimal way as for x86_32
with -mregparm=3, even without synthetic concat patterns.

[Bug libgcc/113401] Memory (resource) leak in -ftrampoline-impl=heap

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

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

--- Comment #5 from Iain Sandoe  ---
(In reply to Florian Weimer from comment #4)
> (In reply to Iain Sandoe from comment #3)
> > for platforms using pthreads as the underlying resource, then perhaps we can
> > do this without thread_atexit (which I do not see in many places) by using
> > pthread_cleanup_push ()
> 
> The current implementation already uses the same underlying mechanism as
> pthread_cleanup_push if building with -fexceptions. It does not solve the
> leak because the outermost handler deliberately does not perform a full
> deallocation of the thread state.

hmm.. I'm slightly confused here.

We certainly make the __gcc_nested_func_ptr_deleted () call a cleanup attached
to scope exits and certainly the last page of trampolines is not deallocated
(as you note for the sake of avoiding churn in m-mapping).

However, in the current code the only pthread-specific stuff I see (in, say
config/i386/heap-trampoline.c) is specific to changing protections on the
mapped pages.

What I was thinking of is attaching a thread exit cleanup using
pthread_cleanup_push() for platforms with pthreads but without Libc support for
_thread_atexit - I guess I'm missing something :)

[Bug libgcc/113401] Memory (resource) leak in -ftrampoline-impl=heap

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

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

--- Comment #6 from Florian Weimer  ---
Sorry, pthread_cleanup_push is purely scope-based, like the existing handler.
It cannot be used to push a handler to some unscoped cleanup function list that
persists even after the current function returns. It's also implemented as a
macro, so it's not possible to emit it from builtin expansion.

[Bug libgcc/113401] Memory (resource) leak in -ftrampoline-impl=heap

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

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

--- Comment #8 from Florian Weimer  ---
Which version of the manual page are you looking at?

https://man7.org/linux/man-pages/man3/pthread_cleanup_push.3.html seems pretty
clear about the scope-based nature (search for discussion of
break/return/goto).

[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f

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

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

Tamar Christina  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-01-22
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org

--- Comment #3 from Tamar Christina  ---
(In reply to Richard Biener from comment #2)
> It accepts all constant known may_be_zero - we can handle all of those later.
> 
> I suspect this just triggers a latent issue (vectorizing now simply using
> a different exit as canonical in one case).

Indeed, I'll take a look.

[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f

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

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

--- Comment #4 from Alex Coplan  ---
Reproduces with just -O3 -fno-strict-aliasing FWIW, no LTO or -mcpu needed.

[Bug middle-end/113552] New: [11/12/13/14 Regression] vectorizer generates calls to vector math routines with 1 simd lane.

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

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

Bug ID: 113552
   Summary: [11/12/13/14 Regression] vectorizer generates calls to
vector math routines with 1 simd lane.
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: link-failure
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-*

In GCC 7 the Arm vector PCS was implemented to support libmvec but the libmvec
component never made it into glibc until now.

GLIBC 2.39 which will be paired with GCC 14 now implements the vector math
routines.

However consider this function:

> cat cosmo.fppized3.f
  SUBROUTINE a(b)
  DIMENSION b(3,0)
  COMMON c
  DO 4 m=1,c
 DO 4 d=1,3
 b(d,m)=b(d,m)+COS(5.0D00*m)
   4  CONTINUE
  END
  DIMENSION e(53)
  DIMENSION f(6,91),g(6,91),h(6,91),
 *  i(6,91),j(6,91),k(6,86)
  DIMENSION l(107)
  END

and compiled with headers from a glibc 2.39:

> aarch64-unknown-linux-gnu-gfortran -S -o - -Ofast 
> -L/data/repro/glibc/usr/lib64 -I/data/repro/glibc/include 
> --sysroot=/data/repro/glibc -w cosmo.fppized3.f

produces:

fmulv13.2d, v13.2d, v19.2d
fmovd0, d13
bl  _ZGVnN1v_cos
fmovd12, d0
dup d0, v13.d[1]
bl  _ZGVnN1v_cos
fmovd31, d0
stp d12, d31, [sp, 96]

which has deconstructed the vector to scalar and performs a vector call with 1
element.
This is not just inefficient but _ZGVnN1v_cos does not exist in glibc as such
code is produced that we cannot link.

It looks like the vectorizer starts with 4 floats and widens to 2x 2 double. 
But then during vectorizable simd this is again split into multiple vectors,
even though the operation already fits in a vector:

cosmo.fppized3.f:4:13: note:   -->vectorizing SLP node starting from: _49 =
__builtin_cos (_48);
cosmo.fppized3.f:4:13: note:   vect_is_simple_use: operand _47 * 5.0e+0, type
of def: internal
cosmo.fppized3.f:4:13: note:   transform call.
cosmo.fppized3.f:4:13: note:   add new stmt: _132 = BIT_FIELD_REF
;
cosmo.fppized3.f:4:13: note:   add new stmt: _133 = cos.simdclone.0 (_132);
cosmo.fppized3.f:4:13: note:   add new stmt: _134 = BIT_FIELD_REF
;
cosmo.fppized3.f:4:13: note:   add new stmt: _135 = cos.simdclone.0 (_134);
cosmo.fppized3.f:4:13: note:   add new stmt: vect__49.27_136 = {_133, _135};
cosmo.fppized3.f:4:13: note:   add new stmt: _137 = BIT_FIELD_REF
;
cosmo.fppized3.f:4:13: note:   add new stmt: _138 = cos.simdclone.0 (_137);
cosmo.fppized3.f:4:13: note:   add new stmt: _139 = BIT_FIELD_REF
;
cosmo.fppized3.f:4:13: note:   add new stmt: _140 = cos.simdclone.0 (_139);
...

Because we happen to have a V1DF mode that is meant to only be used by some
intrinsics the operation succeeds.

So several issues here:

1. We should remove the new libmvec headers from glibc from applying to GCC
10,9,8,7 since we can't fix those anymore.  So we need a GCC version check on
them, however glibc is now frozen for release.
2. The vectorizer should not decompose a simd call if the input and result
don't require it.
3. We shouldn't generate a call with simdlen 1.  That said in theory this could
still be beneficial because it would allow the rest of the code to vectorize
and the vector pcs is cheaper to call.

[Bug target/113255] [11/12/13/14 Regression] wrong code with -O2 -mtune=k8

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

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

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

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

commit r14-8346-ga98d5130a6dcff2ed4db371e500550134777b8cf
Author: Richard Biener 
Date:   Mon Jan 15 12:55:20 2024 +0100

rtl-optimization/113255 - base_alias_check vs. pointer difference

When the x86 backend generates code for cpymem with the rep_8byte
strathegy for the 8 byte aligned main rep movq it needs to compute
an adjusted pointer to the source after doing a prologue aligning
the destination.  It computes that via

  src_ptr + (dest_ptr - orig_dest_ptr)

which is perfectly fine.  On RTL this is then

8: r134:DI=const(`g'+0x44)
9: {r133:DI=frame:DI-0x4c;clobber flags:CC;}
  REG_UNUSED flags:CC
   56: r129:DI=const(`g'+0x4c)
   57: {r129:DI=r129:DI&0xfff8;clobber flags:CC;}
  REG_UNUSED flags:CC
  REG_EQUAL const(`g'+0x4c)&0xfff8
   58: {r118:DI=r134:DI-r129:DI;clobber flags:CC;}
  REG_DEAD r134:DI
  REG_UNUSED flags:CC
  REG_EQUAL const(`g'+0x44)-r129:DI
   59: {r119:DI=r133:DI-r118:DI;clobber flags:CC;}
  REG_DEAD r133:DI
  REG_UNUSED flags:CC

but as written find_base_term happily picks the first candidate
it finds for the MINUS which means it picks const(`g') rather
than the correct frame:DI.  This way find_base_term (but also
the unfixed find_base_value used by init_alias_analysis to
initialize REG_BASE_VALUE) performs pointer analysis isn't
sound.  The following restricts the handling of multi-operand
operations to the case we know only one can be a pointer.

This for example causes gcc.dg/tree-ssa/pr94969.c to miss some
RTL PRE (I've opened PR113395 for this).  A more drastic patch,
removing base_alias_check results in only gcc.dg/guality/pr41447-1.c
regressing (so testsuite coverage is bad).  I've looked at
gcc.dg/tree-ssa tests and mostly scheduling changes are present,
the cc1plus .text size is only 230 bytes worse.  With the this
less drastic patch below most scheduling changes are gone.

x86_64 might not the very best target to test for impact, but
test coverage on other targets is unlikely to be very much better.

PR rtl-optimization/113255
* alias.cc (find_base_term): Remove PLUS/MINUS handling
when both operands are not CONST_INT_P.

* gcc.dg/torture/pr113255.c: New testcase.

[Bug target/113507] can't build a cross compiler to rs6000-ibm-aix7.2

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

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

Kewen Lin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||segher at gcc dot gnu.org
   Last reconfirmed||2024-01-23
 Ever confirmed|0   |1

--- Comment #5 from Kewen Lin  ---
(In reply to H.J. Lu from comment #3)
> (In reply to Kewen Lin from comment #2)
> > Guessing /usr/local/bin/ld is a gnu ld? Based on what I heard before, gnu ld
> > has some problems on aix, people pass object files to aix system and use aix
> > ld there. Not sure if the understanding still holds.
> 
> I am building a cross compiler.  No AIX tools are involved.

Thanks for clarifying, I was dull and misunderstood it.

Confirmed, some symbols are from rs6000-builtin.cc (which is not generated) but
it requires some symbols in rs6000-builtins.cc (which is generated). Both
object files are not included in linking. The below diff can fix it:

diff --git a/gcc/config.gcc b/gcc/config.gcc
index b2d7d7dd475..6b62e4fe56c 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -557,8 +557,10 @@ rs6000*-*-*)
 extra_options="${extra_options} g.opt fused-madd.opt
rs6000/rs6000-tables.opt"
 extra_objs="rs6000-string.o rs6000-p8swap.o rs6000-logue.o"
 extra_objs="${extra_objs} rs6000-call.o rs6000-pcrel-opt.o"
+extra_objs="${extra_objs} rs6000-builtin.o rs6000-builtins.o"
 target_gtfiles="$target_gtfiles
\$(srcdir)/config/rs6000/rs6000-logue.cc
\$(srcdir)/config/rs6000/rs6000-call.cc"
 target_gtfiles="$target_gtfiles
\$(srcdir)/config/rs6000/rs6000-pcrel-opt.cc"
+target_gtfiles="$target_gtfiles ./rs6000-builtins.h"
 ;;
 sparc*-*-*)
 cpu_type=sparc

According to David's comments "rs6000-ibm-aix doesn't exist any more" and I
vaguely remembered Segher also mentioned rs6000*-*-*) becomes stale, maybe we
can aggressively drop the whole rs6000*-*-*) case handling?

[Bug middle-end/113540] missing -Warray-bounds warning with malloc and a simple loop

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

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||56456
   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-01-23

--- Comment #1 from Richard Biener  ---
If you remove the volatile, like

#include 

char *foo (void)
{
  char *t;
  t = malloc (4);
  for (int i = 0; i <= 4; i++)
t[i] = 0;
  return t;
}

you get

t.c: In function 'foo':
t.c:8:10: warning: '__builtin_memset' writing 5 bytes into a region of size 4
[-Wstringop-overflow=]
8 | t[i] = 0;
  | ~^~~
t.c:6:7: note: destination object of size 4 allocated by 'malloc'
6 |   t = malloc (4);
  |   ^~

note this is because we then unroll the loop.  If you change it like

#include 

short *foo (void)
{
  short *t;
  t = malloc (8);
  for (int i = 0; i <= 4; i++)
t[i] = 13;
  return t;
}

you get

t.c: In function 'foo':
t.c:8:6: warning: array subscript 4 is outside array bounds of 'short int[4]'
[-Warray-bounds=]
8 | t[i] = 13;
  | ~^~~
t.c:6:7: note: at offset 8 into object of size 8 allocated by 'malloc'
6 |   t = malloc (8);
  |   ^~

because we unroll the loop.  Upping the bounds like

#include 

short *foo (void)
{
  short *t;
  t = malloc (64);
  for (int i = 0; i <= 32; i++)
t[i] = 13;
  return t;
}

no longer warns because we hit unroll limits.  This is also the reason
we do not diagnose the original testcase - there's currently no analysis
done to compute the set of values 'i' must reach for the purpose of
array-bound diagnostics.  Instead we use value-ranges which are
conservative, aka [-INF, INF] is "correct".  But that means we only
diagnose cases where _all_ values of the range fall outside of the
array.

Using niter analysis and SCEV we could do a better job in cases like the
one in this bug.

I'm quite sure we have related/duplicate bugreports for this already.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug testsuite/113548] gcc.dg/vect/vect-ifcvt-19.c ICEs on LLP64 target

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

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

--- Comment #4 from Richard Biener  ---
Note for 'sizetype' you want to use '__SIZETYPE__', not '__SIZE_TYPE__'

[Bug tree-optimization/113476] [14 Regression] irange::maybe_resize leaks memory via IPA VRP

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-23
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org

--- Comment #5 from Richard Biener  ---
(In reply to Martin Jambor from comment #4)
> The right place where to free stuff in lattices post-IPA would be in
> ipa_node_params::~ipa_node_params() where we should iterate over lattices
> and deinitialize them or perhaps destruct the array because since
> ipcp_vr_lattice directly contains Value_Range which AFAIU directly contains
> int_range_max which has a virtual destructor... does not look like a POD
> anymore.  This has escaped me when I was looking at the IPA-VR changes but
> hopefully it should not be too difficult to deal with.

OK, that might work for the IPA side.

It's quite unusual to introduce a virtual DTOR in the middle of the class
hierarchy though.  Grepping I do see quite some direct uses of 'irange'
and also 'vrange' which do not have the DTOR visible but 'irange' already
exposes and uses 'maybe_resize'.  I think those should only be introduced
in the class exposing the virtual DTOR (but why virtual?!).

Would be nice to have a picture of the range class hierarchies with
pointers on which types to use in which circumstances ...

For example:

  Value_Range vr (parm_type);
...
   irange  = as_a  (vr);
   irange_bitmask bm = r.get_bitmask ();
...

should that really use 'irange'?  Why not int_range&?

All the complication might be because of GC (irange is GTY but int_range is
not), but re-allocation would happen with 'new', not ggc_alloc, so ...

But yes, please try to fix IPA CP, I'll see if this pops up elsewhere as well
then.

[Bug debug/112718] [11/12/13 Regression] ICE: in add_dwarf_attr, at dwarf2out.cc:4501 with -g -fdebug-types-section -flto -ffat-lto-objects

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||14.0
   Priority|P3  |P2
Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE:
   |ICE: in add_dwarf_attr, at  |in add_dwarf_attr, at
   |dwarf2out.cc:4501 with -g   |dwarf2out.cc:4501 with -g
   |-fdebug-types-section -flto |-fdebug-types-section -flto
   |-ffat-lto-objects   |-ffat-lto-objects

--- Comment #4 from Richard Biener  ---
Fixed on trunk sofar.

[Bug debug/112718] [11/12/13/14 Regression] ICE: in add_dwarf_attr, at dwarf2out.cc:4501 with -g -fdebug-types-section -flto -ffat-lto-objects

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

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

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

https://gcc.gnu.org/g:7218f5050cb7163edae331f54ca163248ab48bfa

commit r14-8345-g7218f5050cb7163edae331f54ca163248ab48bfa
Author: Richard Biener 
Date:   Mon Jan 22 15:42:59 2024 +0100

debug/112718 - reset all type units with -ffat-lto-objects

When mixing -flto, -ffat-lto-objects and -fdebug-type-section we
fail to reset all type units after early output resulting in an
ICE when attempting to add then duplicate sibling attributes.

PR debug/112718
* dwarf2out.cc (dwarf2out_finish): Reset all type units
for the fat part of an LTO compile.

* gcc.dg/debug/pr112718.c: New testcase.

[Bug tree-optimization/113441] [14 Regression] Fail to fold the last element with multiple loop

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

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

--- Comment #11 from Richard Biener  ---
(In reply to Tamar Christina from comment #9)
> There is a weird costing going on in the PHI nodes though:
> 
> m_108 = PHI  1 times vector_stmt costs 0 in body 
> m_108 = PHI  2 times scalar_to_vec costs 0 in prologue
> 
> they have collapsed to 0. which can't be right..

Note this is likely because of the backend going wrong.

bool
vectorizable_phi (vec_info *,
  stmt_vec_info stmt_info, gimple **vec_stmt,
  slp_tree slp_node, stmt_vector_for_cost *cost_vec)
{
..

  /* For single-argument PHIs assume coalescing which means zero cost
 for the scalar and the vector PHIs.  This avoids artificially
 favoring the vector path (but may pessimize it in some cases).  */
  if (gimple_phi_num_args (as_a  (stmt_info->stmt)) > 1)
record_stmt_cost (cost_vec, SLP_TREE_NUMBER_OF_VEC_STMTS (slp_node),
  vector_stmt, stmt_info, vectype, 0, vect_body);

You could check if we call this with sane values.

[Bug target/113255] [11/12/13 Regression] wrong code with -O2 -mtune=k8

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
  Known to work||14.0
 Status|NEW |ASSIGNED
Summary|[11/12/13/14 Regression]|[11/12/13 Regression] wrong
   |wrong code with -O2 |code with -O2 -mtune=k8
   |-mtune=k8   |

--- Comment #13 from Richard Biener  ---
Fixed on trunk sofar.

[Bug c++/113541] Rejects __attribute__((section)) on explicit instantiation declaration of ctor/dtor

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
Version|unknown |14.0
  Known to work||4.9.4
  Known to fail||5.1.0

--- Comment #2 from Richard Biener  ---
It sounds like an issue with the C++ mandated aliases.

But I'll note that the template instantiations have to adhere to certain
linkage so I wonder if simply putting them into a different section isn't going
to break the ABI.

[Bug tree-optimization/113552] [11/12/13/14 Regression] vectorizer generates calls to vector math routines with 1 simd lane.

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

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

Tamar Christina  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Priority|P3  |P1
  Component|middle-end  |tree-optimization

[Bug tree-optimization/113551] [13/14 Regression] Miscompilation with -O1 -funswitch-loops -fno-strict-overflow

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #6 from Richard Biener  ---
trunk doesn't unswitch for me (needs bisection).  Let me check what happens on
the branch.

[Bug debug/113519] [14 Regression] ICE: in replace_child, at dwarf2out.cc:5704 with -g -fdebug-types-section -fsso-struct=big-endian (or little-endian if the target is big-endian)

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

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

--- Comment #3 from Richard Biener  ---
Hmm, -fdebug-types-section ... mumbles sth about axing that.

[Bug libstdc++/113500] Using std::format with float or double based std::chrono::time_point causes error: no match for 'operator<<'

[Hirthammer--- via Gcc-bugs]

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

--- Comment #11 from hirtham...@allterra-dno.de ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Jonathan Wakely from comment #6)
> > (In reply to Hirthammer from comment #5)
> > > This whole thing with std::format and std::chrono::time_point is 
> > > currently a
> > > total minefield.
> > 
> > That seems like an exaggeration.
> > 
> > > In MSVC it is even more complicated and I already reported
> > > the bug in October 2023. See:
> > > 
> > > https://developercommunity.visualstudio.com/t/Using-std::format-with-
> > > unsigned-integer-/10501153
> > > 
> > > If you change the clock to utc_clock or gps_clock the code compiles with
> > > MSVC (but not with GCC) on Compiler Explorer.
> > 
> > It compiles fine with GCC for me.
> 
> Ah, maybe you mean your original example. The one at in the MSVC bug report
> compiles fine with GCC using utc_clock and gps_clock.
> 
> Your original example doesn't, because formatting a utc_time or gps_time is
> specified in terms of a sys_time, and that's how libstdc++ implements it. So
> if the utc_time or gps_time uses a float rep, we're back to square one.
> 
> I'll ask the committee to clarify that too.

Yes, I was referring to my original example because it helped me to understand
which combinations worked and which did not. 

I wrote a wrapper class around std::chrono::time_point, because I am dealing a
lot with different time formats. I am also doing multi-platform development,
and during the testing phase, it turned out that no compiler was able to
compile all templated test cases (Clang uses libstdc++ if you do not explicitly
tell it not to do, as you pointed out on the llvm bug report). Since the error
case parameter combinations differed from MSVC and GCC, I had to use many
different compiler-specific sections to get consistent and valid behavior in
the tests. That's why I called it a minefield. Maybe it was exaggerated ;).

Anyways, thank you a lot for your effort and clarifications and especially for
the fast fix.

[Bug modula2/113511] lack of libm2 ABI compatibility on powerpc platforms

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||powerpc*
   Keywords||ABI

--- Comment #1 from Richard Biener  ---
There's also the question on compatibility to libgm2 from GCC 13.

I suppose the frontend could simply not allow changing the M2 language
"long double" (however it is called) with -mabi=... (which really only
change the C language ABI!).  Of course calls to libm are subject to the
C language ABI.

Does the language standard have anything to say here?  I suppose there's
no ABI documents for M2 for various targets, so eventually C interoperability
language in the standard directs at the common sense?

[Bug rtl-optimization/111267] [14 Regression] Codegen regression from i386 argument passing changes

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

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

--- Comment #12 from Richard Sandiford  ---
I don't object to the patch, but for the record: the current heuristics go back
a long way.  Although I reworked the pass to use rtl-ssa a few years ago, I
tried as far as possible to preserve the old heuristics (tested by making sure
that there were no unexplained differences over a large set of targets).

I wouldn't characterise the old heuristics as a logic error.  Although I didn't
write them, my understanding is that they were being deliberately conservative,
in particular due to the risk of introducing excess register pressure.

So this change seems potentially quite invasive for stage 4.  Perhaps it'll
work out — if so, great!  But if there is some fallout, I think we should lean
towards reverting the patch and revisiting in GCC 15.

[Bug c/113538] New: [RISC-V] --param=riscv-vector-abi will fail some cases

[yanzhang.wang at intel dot com via Gcc-bugs]

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

Bug ID: 113538
   Summary: [RISC-V] --param=riscv-vector-abi will fail some cases
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yanzhang.wang at intel dot com
  Target Milestone: ---

When removing the riscv-vector-abi, I found some cases failed. We can test it
by passing the arg to the tests like,

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/zvfh-over-zvfhmin.c
b/gcc/testsuite/gcc.target/riscv/rvv/base/zvfh-over
-zvfhmin.c
index 1d82cc8de2d..0725ca69222 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/zvfh-over-zvfhmin.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/zvfh-over-zvfhmin.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-march=rv64gcv_zvfh -mabi=lp64 -O3" } */
+/* { dg-options "-march=rv64gcv_zvfh -mabi=lp64 -O3 --param=riscv-vector-abi"
} */

 #include "riscv_vector.h"



The test result will be,

=== gcc tests ===

Schedule of variations:
riscv-sim/-march=rv64gcv_zvfh/-mabi=lp64d/-mcmodel=medlow

Running target riscv-sim/-march=rv64gcv_zvfh/-mabi=lp64d/-mcmodel=medlow
Using /mnt/install/toolchains/gnu/share/dejagnu/baseboards/riscv-sim.exp as
board description file for target.
Using /mnt/install/toolchains/gnu/share/dejagnu/config/sim.exp as generic
interface file for target.
Using /mnt/install/toolchains/gnu/share/dejagnu/baseboards/basic-sim.exp as
board description file for target.
Using
/home/yanzhang/workspace/toolchains/gnu/gcc/gcc/testsuite/config/default.exp as
tool-and-target-specific interface fil
e.
Running
/home/yanzhang/workspace/toolchains/gnu/gcc/gcc/testsuite/gcc.target/riscv/rvv/rvv.exp
...
FAIL: gcc.target/riscv/rvv/base/zvfh-over-zvfhmin.c scan-assembler-times
vsetvli\\s+[a-x0-9]+,\\s*zero,\\s*e16,\\s*mf4,\\s*t
[au],\\s*m[au] 8
FAIL: gcc.target/riscv/rvv/base/zvfh-over-zvfhmin.c scan-assembler-times
vsetvli\\s+[a-x0-9]+,\\s*zero,\\s*e16,\\s*mf2,\\s*t
[au],\\s*m[au] 2
FAIL: gcc.target/riscv/rvv/base/zvfh-over-zvfhmin.c scan-assembler-times
vle16\\.v\\s+v[0-9]+,\\s*0\\([0-9ax]+\\) 7
FAIL: gcc.target/riscv/rvv/base/zvfh-over-zvfhmin.c scan-assembler-times
vse16\\.v\\s+v[0-9]+,\\s*0\\([a-x][0-9]+\\) 6
FAIL: gcc.target/riscv/rvv/base/zvfh-over-zvfhmin.c scan-assembler-times
vl1re16\\.v\\s+v[0-9]+,\\s*0\\([a-x][0-9]+\\) 1
FAIL: gcc.target/riscv/rvv/base/zvfh-over-zvfhmin.c scan-assembler-times
vl2re16\\.v\\s+v[0-9]+,\\s*0\\([a-x][0-9]+\\) 1
FAIL: gcc.target/riscv/rvv/base/zvfh-over-zvfhmin.c scan-assembler-times
vl4re16\\.v\\s+v[0-9]+,\\s*0\\([a-x][0-9]+\\) 3
FAIL: gcc.target/riscv/rvv/base/zvfh-over-zvfhmin.c scan-assembler-times
vl8re16\\.v\\s+v[0-9]+,\\s*0\\([a-x][0-9]+\\) 1
FAIL: gcc.target/riscv/rvv/base/zvfh-over-zvfhmin.c scan-assembler-times
vs2r\\.v\\s+v[0-9]+,\\s*0\\([a-x][0-9]+\\) 1
FAIL: gcc.target/riscv/rvv/base/zvfh-over-zvfhmin.c scan-assembler-times
vs4r\\.v\\s+v[0-9]+,\\s*0\\([a-x][0-9]+\\) 3
FAIL: gcc.target/riscv/rvv/base/zvfh-over-zvfhmin.c scan-assembler-times
vs8r\\.v\\s+v[0-9]+,\\s*0\\([a-x][0-9]+\\) 5


The failed test cases almost in rvv/base with same reason.

GCC commit: 57f611604e8bab67af6c0bcfe6ea88c001408412

[Bug ipa/113520] ICE with mismatched types with LTO (tree check: expected array_type, have integer_type in array_ref_low_bound)

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-22
  Component|tree-optimization   |ipa
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||hubicka at gcc dot gnu.org,
   ||jamborm at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Keywords||lto

--- Comment #6 from Richard Biener  ---
Hmm, we are supposed to "handle" this during in-streaming.  This seems to work
but then for some reason it gets fiddled with again...

Ah, so this is reading of IPA CP summaries where it seems that we do not
apply these "tricks", gimple-streamer-out.cc has

  /* Wrap all uses of non-automatic variables inside MEM_REFs
 so that we do not have to deal with type mismatches on
 merged symbols during IL read in.  The first operand
 of GIMPLE_DEBUG must be a decl, not MEM_REF, though.  */
  if (!flag_wpa && op && (i || !is_gimple_debug (stmt)))
{
  basep = 
  if (TREE_CODE (*basep) == ADDR_EXPR)
basep = _OPERAND (*basep, 0);
  while (handled_component_p (*basep))
basep = _OPERAND (*basep, 0);
  if (VAR_P (*basep)
  && !auto_var_in_fn_p (*basep, fn->decl)
  && !DECL_REGISTER (*basep)) 
{
  bool volatilep = TREE_THIS_VOLATILE (*basep);
  tree ptrtype = build_pointer_type (TREE_TYPE (*basep));
  *basep = build2 (MEM_REF, TREE_TYPE (*basep),
   build1 (ADDR_EXPR, ptrtype, *basep),
   build_int_cst (ptrtype, 0));
  TREE_THIS_VOLATILE (*basep) = volatilep;
...

and gimple-streamer-in.cc undoes this when the prevailing decls are compatible:

  /* At LTO output time we wrap all global decls in MEM_REFs to
 allow seamless replacement with prevailing decls.  Undo this
 here if the prevailing decl allows for this.
 ???  Maybe we should simply fold all stmts.  */
  if (TREE_CODE (*opp) == MEM_REF
  && TREE_CODE (TREE_OPERAND (*opp, 0)) == ADDR_EXPR
  && integer_zerop (TREE_OPERAND (*opp, 1))
  && (TREE_THIS_VOLATILE (*opp)
  == TREE_THIS_VOLATILE
   (TREE_OPERAND (TREE_OPERAND (*opp, 0), 0)))
  && !TYPE_REF_CAN_ALIAS_ALL (TREE_TYPE (TREE_OPERAND (*opp, 1)))
  && (TREE_TYPE (*opp)
  == TREE_TYPE (TREE_TYPE (TREE_OPERAND (*opp, 1
  && (TREE_TYPE (*opp)
  == TREE_TYPE (TREE_OPERAND (TREE_OPERAND (*opp, 0), 0
*opp = TREE_OPERAND (TREE_OPERAND (*opp, 0), 0);

I suppose we might want to split these out so summary streaming can apply
this to streamed trees as well?

[Bug middle-end/113540] New: missing -Warray-bounds warning with malloc and a simple loop

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

Bug ID: 113540
   Summary: missing -Warray-bounds warning with malloc and a
simple loop
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

Consider the following code:

#include 

int main (void)
{
  volatile char *t;
  t = malloc (4);
  for (int i = 0; i <= 4; i++)
t[i] = 0;
  return 0;
}

With -O2 -Warray-bounds, I do not get any warning.

Replacing the loop by "t[4] = 0;" gives a warning "array subscript 4 is outside
array bounds of 'volatile char[4]'" as expected.

Or replacing the use of malloc() by "volatile char t[4];" also gives a warning.

Tested with gcc (Debian 20240117-1) 14.0.1 20240117 (experimental) [master
r14-8187-gb00be6f1576]. But previous versions do not give any warning either.

[Bug debug/112718] [11/12/13/14 Regression] ICE: in add_dwarf_attr, at dwarf2out.cc:4501 with -g -fdebug-types-section -flto -ffat-lto-objects

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
I have a patch, but other issues with -fdebug-types-section and -flto will
prevail.