[Bug tree-optimization/113385] [14 regression] ICE when building opencv (dfs_enumerate_from, at cfganal.cc:1590)

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

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

--- Comment #2 from Andrew Pinski  ---
Fuller backtrace:
```
#2  0x0083f554 in dfs_enumerate_from (bb=,
reverse=reverse@entry=1, predicate=predicate@entry=0xe00620
, rslt=,
rslt@entry=0x4604c70, rslt_max=36, data=data@entry=0x7fffddb02960)
at /home/apinski/src/upstream-gcc-match/gcc/gcc/cfganal.cc:1590
#3  0x00e01272 in get_loop_body_with_size (max_size=,
body=0x4604c70, loop=0x7fffddb02960) at
/home/apinski/src/upstream-gcc-match/gcc/gcc/cfgloop.cc:872
#4  get_loop_body (loop=loop@entry=0x7fffddb02960) at
/home/apinski/src/upstream-gcc-match/gcc/gcc/cfgloop.cc:901
#5  0x014d0bea in estimate_numbers_of_iterations (loop=0x7fffddb02960)
at /home/apinski/src/upstream-gcc-match/gcc/gcc/tree-ssa-loop-niter.cc:4833
#6  0x014d4616 in loop_exits_before_overflow (loop=0x7fffddb02960,
at_stmt=0x7fffd7d63d20, step=0x74314f48, base=0x776603a8) at
/home/apinski/src/upstream-gcc-match/gcc/gcc/tree-ssa-loop-niter.cc:5259
#7  scev_probably_wraps_p (var=var@entry=0x0, base=base@entry=0x776603a8,
step=step@entry=0x74314f48, at_stmt=0x7fffd7d63d20,
loop=loop@entry=0x7fffddb02960,
use_overflow_semantics=use_overflow_semantics@entry=false) at
/home/apinski/src/upstream-gcc-match/gcc/gcc/tree-ssa-loop-niter.cc:5511
#8  0x02462fff in convert_affine_scev (loop=0x7fffddb02960,
type=, base=0x7fffc1d0, step=0x7fffc1d8,
at_stmt=, use_overflow_semantics=,
from=0x7fffd814b708) at
/home/apinski/src/upstream-gcc-match/gcc/gcc/tree-chrec.cc:1425
#9  0x02462a59 in chrec_convert_1 (type=0x77826738,
chrec=0x7fffd7d819b0, at_stmt=0x7fffd7d63d20, use_overflow_semantics=, from=0x7fffd814b708) at
/home/apinski/src/upstream-gcc-match/gcc/gcc/tree-chrec.cc:1483
#10 0x0141b887 in interpret_gimple_assign (stmt=0x7fffd7d63d20,
loop=0x7fffddb02960) at
/home/apinski/src/upstream-gcc-match/gcc/gcc/tree-scalar-evolution.cc:1919
#11 analyze_scalar_evolution_1 (loop=0x7fffddb02960, var=0x7fffd8130828) at
/home/apinski/src/upstream-gcc-match/gcc/gcc/tree-scalar-evolution.cc:1970
#12 0x0141c193 in analyze_scalar_evolution (loop=0x7fffddb02960,
var=0x7fffd8130828) at
/home/apinski/src/upstream-gcc-match/gcc/gcc/tree-scalar-evolution.cc:2039
#13 0x0141eceb in analyze_scalar_evolution_in_loop
(wrto_loop=wrto_loop@entry=0x7fffddb02960,
use_loop=use_loop@entry=0x7fffddb02960, version=,
folded_casts=folded_casts@entry=0x7fffc37b) at
/home/apinski/src/upstream-gcc-match/gcc/gcc/tree-scalar-evolution.cc:2165
#14 0x01420696 in simple_iv_with_niters (wrto_loop=0x7fffddb02960,
use_loop=0x7fffddb02960, op=, iv=0x7fffc480, iv_niters=0x0,
allow_nonconstant_step=false) at
/home/apinski/src/upstream-gcc-match/gcc/gcc/tree-scalar-evolution.cc:3237
#15 0x014c2c02 in get_cst_init_from_scev (var=var@entry=0x7fffd8130828,
init=init@entry=0x7fffc580, is_min=is_min@entry=true) at
/home/apinski/src/upstream-gcc-match/gcc/gcc/tree-ssa-loop-niter.cc:4015
#16 0x014c64f0 in record_nonwrapping_iv (loop=0x7fffddaf0320,
base=0x7fffe6031d00, step=0x7692fbb8, stmt=0x7fffd8121cb8,
low=0x776603a8, high=, upper=true, realistic=false) at
/home/apinski/src/upstream-gcc-match/gcc/gcc/tree-ssa-loop-niter.cc:4101
#17 0x014c6bb9 in infer_loop_bounds_from_signedness
(loop=0x7fffddaf0320, stmt=0x7fffd8121cb8) at
/home/apinski/src/upstream-gcc-match/gcc/gcc/tree-ssa-loop-niter.cc:4380
#18 0x014d21c3 in infer_loop_bounds_from_undefined (bbs=, loop=) at
/home/apinski/src/upstream-gcc-match/gcc/gcc/tree-ssa-loop-niter.cc:4418
#19 estimate_numbers_of_iterations (loop=0x7fffddaf0320) at
/home/apinski/src/upstream-gcc-match/gcc/gcc/tree-ssa-loop-niter.cc:4872
#20 0x014d3f38 in estimated_loop_iterations (nit=0x7fffd340,
loop=0x7fffddaf0320) at
/home/apinski/src/upstream-gcc-match/gcc/gcc/tree-ssa-loop-niter.cc:4904
#21 estimated_loop_iterations_int (loop=loop@entry=0x7fffddaf0320) at
/home/apinski/src/upstream-gcc-match/gcc/gcc/tree-ssa-loop-niter.cc:4919
#22 0x014d3f69 in estimated_stmt_executions_int
(loop=loop@entry=0x7fffddaf0320) at
/home/apinski/src/upstream-gcc-match/gcc/gcc/tree-ssa-loop-niter.cc:5007
#23 0x015e1c58 in vect_analyze_loop_costing (loop_vinfo=, suggested_unroll_factor=) at
/home/apinski/src/upstream-gcc-match/gcc/gcc/tree-vect-loop.cc:2450
#24 0x015ee8df in vect_analyze_loop_2 (loop_vinfo=,
fatal=, suggested_unroll_factor=0x7fffd83c,
slp_done_for_suggested_uf=@0x7fffd83b: false) at
/home/apinski/src/upstream-gcc-match/gcc/gcc/tree-vect-loop.cc:3187
#25 0x015f050f in vect_analyze_loop_1 (loop=0x7fffddaf0320,
shared=0x7fffda70, loop_form_info=0x7fffd900, main_loop_vinfo=0x0,
vector_modes=..., mode_i=@0x7fffd8dc: 0,
autodetected_vector_mode=@0x7fffd8d8: E_VOIDmode, fatal=@0x7fffd8d7:
false)
at /home/apinski/src/upstream-gcc-match/gcc/gcc/tree-vect-loop.cc:3482
#26 0x015f0d38 in 

[Bug testsuite/106879] [13 regression] new test case gcc.dg/vect/bb-slp-layout-19.c fails

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

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

Jiu Fu Guo  changed:

   What|Removed |Added

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

--- Comment #11 from Jiu Fu Guo  ---
(In reply to Richard Biener from comment #9)
> Fixed on trunk I suppose?  If so please also sync to the 13 branch and close
> this issue.

Thanks.

[Bug testsuite/106879] [13 regression] new test case gcc.dg/vect/bb-slp-layout-19.c fails

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

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

--- Comment #10 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jiu Fu Guo
:

https://gcc.gnu.org/g:9347879fb622b024e8924a731c2acc7100d5e9b4

commit r13-8221-g9347879fb622b024e8924a731c2acc7100d5e9b4
Author: Jiufu Guo 
Date:   Tue Apr 18 15:56:53 2023 +0800

PR testsuite/106879 FAIL: gcc.dg/vect/bb-slp-layout-19.c on powerpc64

On P7, option -mno-allow-movmisalign is added during testing, which
prevents slp happen on the case.

Like PR65484 and PR87306, this patch use vect_hw_misalign to guard
the case on powerpc targets.

gcc/testsuite/ChangeLog:

PR testsuite/106879
* gcc.dg/vect/bb-slp-layout-19.c: Modify to guard the check with
vect_hw_misalign on POWERs.

[Bug objc++/23616] obj-c++.dg/try-catch-[29].mm (objc exceptions are broken) fails with the GNU Runtime

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #15 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> The fix would be change choose_personality_routine but that would mean you
> cannot mix C++ and 
> Objc exceptions in one TU.  So far there are no tests for this.  I might
> implement the change to the 
> ObjC and C++'s to implement this but I am not going to do it until 4.2. 
> Maybe by then we can mix 
> them but I really doubt it.

Actually I think there is a way to mix them now. I have not looked into this
for a long time either ...

[Bug tree-optimization/113385] [14 regression] ICE when building opencv (dfs_enumerate_from, at cfganal.cc:1590)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Keywords||ice-on-valid-code

[Bug tree-optimization/113385] [14 regression] ICE when building opencv (dfs_enumerate_from, at cfganal.cc:1590)

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

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

--- Comment #1 from Andrew Pinski  ---
Reducing ...

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

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #7 from Roger Sayle  ---
Very many thanks to Jeff Law for pointing me to fwprop.  The following simple
patch also fixes this regression.

diff --git a/gcc/fwprop.cc b/gcc/fwprop.cc
index 0c588f8..cbba44e 100644
--- a/gcc/fwprop.cc
+++ b/gcc/fwprop.cc
@@ -449,15 +449,6 @@ try_fwprop_subst_pattern (obstack_watermark ,
insn_
change _change,
   if (prop.num_replacements == 0)
 return false;

-  if (!prop.profitable_p ())
-{
-  if (dump_file && (dump_flags & TDF_DETAILS))
-   fprintf (dump_file, "cannot propagate from insn %d into"
-" insn %d: %s\n", def_insn->uid (), use_insn->uid (),
-"would increase complexity of pattern");
-  return false;
-}
-
   if (dump_file && (dump_flags & TDF_DETAILS))
 {
   fprintf (dump_file, "\npropagating insn %d into insn %d, replacing:\n",

[Bug tree-optimization/113385] New: [14 regression] ICE when building opencv (dfs_enumerate_from, at cfganal.cc:1590)

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

port-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.
```

```
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/14/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.1./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/14
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/14/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl,df
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 14.0.1 p,
commit 9d69e54a3b402b0fad067464bd402e92c14504a9' --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-host-pie --disable-host-bind-now
--enable-default-ssp --with-build-config='bootstrap-O3 bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240113 (experimental)
9935667a69896865b848dfa690f94c9c693a48a3 (Gentoo 14.0.1 p, commit
9d69e54a3b402b0fad067464bd402e92c14504a9)
```

[Bug tree-optimization/113371] [14 Regression] ICE: verify_ssa failed: PHI node with wrong VUSE on edge from BB 19 with -O -march=silvermont -ftree-vectorize

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-01-13
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed but note the reduced testcase depends on an uninitialized variable.

[Bug tree-optimization/113371] [14 Regression] ICE: verify_ssa failed: PHI node with wrong VUSE on edge from BB 19 with -O -march=silvermont -ftree-vectorize

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 CC||pinskia at gcc dot gnu.org

[Bug c++/113375] GCC accepts invalid program involving template keyword when used without a template arg list

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 55588.

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

[Bug c++/55588] Failure to diagnose non-template-id prefixed by keyword template

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jlame646 at gmail dot com

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

[Bug tree-optimization/113373] [14 regression] ICE in verify_ssa

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-13
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

[Bug tree-optimization/113373] [14 regression] ICE in verify_ssa

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

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

--- Comment #4 from Andrew Pinski  ---
Created attachment 57076
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57076=edit
Reduced C testcase

[Bug tree-optimization/113374] [14 regression] ICE in find_uses_to_rename_use

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-01-13
 Ever confirmed|0   |1

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

[Bug tree-optimization/113374] [14 regression] ICE in find_uses_to_rename_use

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

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

--- Comment #3 from Andrew Pinski  ---
Created attachment 57075
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57075=edit
Reduced C testcase

Note I think there is a missed VRP removing some bounds check but this is not
the issue here.

[Bug preprocessor/109704] #pragma {push,pop}_macro broken for identifiers that contain dollar signs at nonfirst positions

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

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

Lewis Hyatt  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-01-13
 Status|UNCONFIRMED |NEW
   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-January
   ||/642926.html

--- Comment #4 from Lewis Hyatt  ---
Patch submitted for review at
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642926.html

[Bug fortran/67277] segfault when passing a missing optional argument to an elemental intrinsic

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:20da56165273c8814b3c53e6d71549ba6a37e0cd

commit r14-7228-g20da56165273c8814b3c53e6d71549ba6a37e0cd
Author: Harald Anlauf 
Date:   Sat Jan 13 22:00:21 2024 +0100

Fortran: intrinsic ISHFTC and missing optional argument SIZE [PR67277]

gcc/fortran/ChangeLog:

PR fortran/67277
* trans-intrinsic.cc (gfc_conv_intrinsic_ishftc): Handle optional
dummy argument for SIZE passed to ISHFTC.  Set default value to
BIT_SIZE(I) when missing.

gcc/testsuite/ChangeLog:

PR fortran/67277
* gfortran.dg/ishftc_optional_size_1.f90: New test.

[Bug tree-optimization/113373] [14 regression] ICE in verify_ssa

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
Reduced C++ code seems to be:

void __assert_fail(char *, char *, int, const char *)
__attribute__((__noreturn__));
template  struct asCArray {
  asCArray(int);
  T [](unsigned);
  T *array;
  int length;
};
template  T ::operator[](unsigned index) {
  index < length ? void() : __assert_fail("", "", 8, __PRETTY_FUNCTION__);
  return array[index];
}
unsigned asCReaderTranslateFunction_bc_1;
int asCReaderTranslateFunction_bcLength;
void asCReaderTranslateFunction() {
  asCArray bcSizes(asCReaderTranslateFunction_bcLength);
  int offset, size;
  for (int num; offset--; num++)
size += bcSizes[num];
  asCReaderTranslateFunction_bc_1 = size;
}

[Bug tree-optimization/113373] [14 regression] ICE in verify_ssa

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Keywords||ice-on-valid-code

[Bug tree-optimization/113373] [14 regression] ICE in verify_ssa

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
Reducing ...

[Bug fortran/113305] ICE with do concurrent and ivdep

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
Fixed in gcc-14.

[Bug libfortran/113223] NAMELIST internal write missing leading blank character

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

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #7 from Jerry DeLisle  ---
Backported to gcc-13 using the gcc-backport script.

[Bug libfortran/113223] NAMELIST internal write missing leading blank character

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jerry DeLisle
:

https://gcc.gnu.org/g:370aa06510cc714efd1f24170a09c9ba1f3d76f9

commit r13-8219-g370aa06510cc714efd1f24170a09c9ba1f3d76f9
Author: Jerry DeLisle 
Date:   Sun Jan 7 10:22:19 2024 -0800

libgfortran: Emit a space at beginning of internal unit NML.

PR libgfortran/113223

libgfortran/ChangeLog:

* io/write.c (namelist_write): If internal_unit precede with space.

gcc/testsuite/ChangeLog:

* gfortran.dg/dtio_25.f90: Update.
* gfortran.dg/namelist_57.f90: Update.
* gfortran.dg/namelist_65.f90: Update.

(cherry picked from commit add995ec117d756e61d207041cd32f937c1a1cd9)

[Bug fortran/113384] New: [14 Regression] FAIL: gfortran.dg/array_reference_1.f90 -O0 execution test

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

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

Bug ID: 113384
   Summary: [14 Regression] FAIL:
gfortran.dg/array_reference_1.f90   -O0  execution
test
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa*-*-linux*
Target: hppa*-*-linux*
 Build: hppa*-*-linux*

spawn -ignore SIGHUP
/home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfor
tran -B/home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
-B/home/dave/gnu/
gcc/objdir/hppa-linux-gnu/./libgfortran/
/home/dave/gnu/gcc/gcc/gcc/testsuite/gf
ortran.dg/array_reference_1.f90 -fdiagnostics-plain-output
-fdiagnostics-plain-o
utput -O0 -pedantic-errors
-B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libatomi
c/ -B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libatomic/.libs
-B/home/dave/gnu
/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs
-L/home/dave/gnu/gcc/objdir/hppa-
linux-gnu/./libgfortran/.libs
-L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgf
ortran/.libs -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libatomic/.libs -lm
-o
 ./array_reference_1.exe
PASS: gfortran.dg/array_reference_1.f90   -O0  (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfort
ran/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs:/home/dav
e/gnu/gcc/objdir/hppa-linux-gnu/./libatomic/.libs:/home/dave/gnu/gcc/objdir/gcc/
testsuite/gfortran/../..:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libatomic/.l
ibs:.:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libatomic/.libs:/home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran/../..:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libatomic/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libphobos/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gcc:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libphobos/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gcc
Execution timeout is: 300
spawn [open ...]
STOP 1
FAIL: gfortran.dg/array_reference_1.f90   -O0  execution test

Test doesn't fail at -O1 and above.

23  if (any (b .ne. c)) STOP 1
(gdb) p b
$1 = (((-1,-5.25255582e+35), (-3,1.40129846e-45)) ((-2,1.40129846e-45),
(-4,0)))
(gdb) p c
$2 = (((1,-1), (3,-3)) ((2,-2), (4,-4)))

Apparent similar fails:
FAIL: gfortran.dg/dependency_58.f90   -O0  execution test
FAIL: gfortran.dg/transpose_conjg_1.f90   -O0  execution test
FAIL: gfortran.fortran-torture/execute/intrinsic_transpose.f90 execution,  -O0

[Bug target/113312] Update __attribute__((interrupt)) for Intel FRED

[hpa at zytor dot com via Gcc-bugs]

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

--- Comment #21 from H. Peter Anvin  ---
I think this could be a really useful performance improvement in general. The
Linux exception and syscall paths have a fair number of tail calls on the
primary path, and this would make it possible to avoid the register save and
restores for each of the functions in the tail called path.

I have asked Xin Li (FRED maintainer) to try this out when he has the
opportunity, although right now the Linux kernel merge window is open and so
that is necessarily his first priority.

[Bug tree-optimization/113374] [14 regression] ICE in find_uses_to_rename_use

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

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

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

[Bug tree-optimization/113383] New: `MAX(a, b) == 0` and `MAX(a, b) != 0` can be simplified (for unsigned types)

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

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

Bug ID: 113383
   Summary: `MAX(a,b) == 0` and `MAX(a,b) != 0` can be simplified
(for unsigned types)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
unsigned maxeq0(unsigned a, unsigned b)
{
unsigned c = a > b ? a : b;
return c == 0; // b == 0 && a == 0
}

unsigned maxeq0_1(unsigned a, unsigned b)
{
return b == 0 && a == 0;
}

unsigned maxne0(unsigned a, unsigned b)
{
unsigned c = a > b ? a : b;
return c != 0; // b != 0 || a != 0
}

unsigned maxne0_1(unsigned a, unsigned b)
{
return b != 0 || a != 0;
}

```
maxeq0 and maxeq0_1 are equivalent.
Likewise for maxne0 and maxne0_1.

LLVM is able to do this simplification.
Note this is only valid for unsigned MAX.

[Bug target/113312] Update __attribute__((interrupt)) for Intel FRED

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #20 from H.J. Lu  ---
In Linux kernel 6.7.0 on x86-64, do_exit is changed from

do_exit:
endbr64
call   
push   %r15
push   %r14
push   %r13
push   %r12
mov%rdi,%r12
push   %rbp
push   %rbx
mov%gs:0x0,%rbx
sub$0x28,%rsp
mov%gs:0x28,%rax
mov%rax,0x20(%rsp)
xor%eax,%eax
call   *0x0(%rip)# 
test   $0x2,%ah
je 

to

do_exit:
endbr64
call   
sub$0x28,%rsp
mov%rdi,%r12
mov%gs:0x28,%rax
mov%rax,0x20(%rsp)
xor%eax,%eax
mov%gs:0x0,%rbx
call   *0x0(%rip)# 
test   $0x2,%ah
je 

Kernel seems to work fine.

[Bug target/113312] Update __attribute__((interrupt)) for Intel FRED

[hpa at zytor dot com via Gcc-bugs]

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

--- Comment #19 from H. Peter Anvin  ---
I'm away for the long weekend, but I'll try it out on Tuesday.

[Bug debug/113382] New: 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

Bug ID: 113382
   Summary: FAIL: gcc.dg/debug/btf/btf-bitfields-3.c
scan-assembler-times [\t ]0x604[\t
]+[^\n]*btt_info 1
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

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

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/xgcc
-B/home/dave/gnu/gcc/o
bjdir64/gcc/
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields
-3.c -fdiagnostics-plain-output -O0 -gbtf -dA -fno-ident -S -o
btf-bitfields-3.s
PASS: gcc.dg/debug/btf/btf-bitfields-3.c (test for excess errors)
gcc.dg/debug/btf/btf-bitfields-3.c: [\t ]0x604[\t ]+[^\n]*btt_info found 0
t
imes
FAIL: gcc.dg/debug/btf/btf-bitfields-3.c scan-assembler-times [\t ]0x604[\t
]+[^\n]*btt_info 1
PASS: gcc.dg/debug/btf/btf-bitfields-3.c scan-assembler-times [\t
]0x8401[\t ]+[^\n]*btt_info 1
PASS: gcc.dg/debug/btf/btf-bitfields-3.c scan-assembler-times  btm_type:
\\(BTF_KIND_ENUM 'foo' 1

[Bug c++/112737] [14 Regression] g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors)

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

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

--- Comment #4 from John David Anglin  ---
On hppa64-hp-hpux11.11:

Excess errors:
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error:
conflicting global module declaration 'template class
_Cont, class _Rg, class ... _Args> using std::ranges::__detail::_DeduceExpr1 =
decltype (_Cont<...auto...>(declval<_Rg>(), (declval<_Args>)()...))'
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error:
conflicting global module declaration 'template class
_Cont, class _Rg, class ... _Args> using std::ranges::__detail::_DeduceExpr2 =
decltype (_Cont<...auto...>(std::from_range, declval<_Rg>(),
(declval<_Args>)()...))'
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error:
conflicting global module declaration 'template class
_Cont, class _Rg, class ... _Args> using std::ranges::__detail::_DeduceExpr3 =
decltype (_Cont<...auto...>(declval >(),
declval >(), (declval<_Args>)()...))'
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error:
conflicting global module declaration 'using
std::ranges::__detail::_DeduceExpr1 = decltype
(_Cont<...auto...>(declval<_Rg>(), (declval<_Args>)()...))'
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error:
conflicting global module declaration 'using
std::ranges::__detail::_DeduceExpr2 = decltype
(_Cont<...auto...>(std::from_range, declval<_Rg>(), (declval<_Args>)()...))'
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error:
conflicting global module declaration 'using
std::ranges::__detail::_DeduceExpr3 = decltype
(_Cont<...auto...>(declval >(),
declval >(), (declval<_Args>)()...))'

[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a

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

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #8 from John David Anglin  ---
> Only partially: the "g++.dg/modules/hello-1 -std=c++2b execute"
> is still there, and was part of the regression; at least introduced at the
> same time.

Same failure is observed on hppa64-hp-hpux11.11.

[Bug c/89072] -Wall -Werror should be defaults

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

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

--- Comment #13 from Segher Boessenkool  ---
I always have -Wmissing-declarations -Wformat=2 , for some reason those aren't
in
-Wall, not even in -W .  Crazy if you ask me :-)

[Bug c++/113381] New: FAIL: g++.dg/cpp2a/consteval-prop6.C -std=c++20 at line 58 (test for warnings, line 57)

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

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

Bug ID: 113381
   Summary: FAIL: g++.dg/cpp2a/consteval-prop6.C  -std=c++20  at
line 58 (test for warnings, line 57)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../xg++
-B
/home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../
/home/dave/gnu/gcc/gcc/gcc/
testsuite/g++.dg/cpp2a/consteval-prop6.C -fdiagnostics-plain-output -nostdinc++
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp
-hpux11.11
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/includ
e -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/gcc/gcc/libst
dc++-v3/include/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util
-f
message-length=0 -std=c++20 -pedantic-errors -Wno-long-long -S -o
consteval-prop
6.s
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp2a/consteval-prop6.C: In
construc
tor 'SS::SS()':
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp2a/consteval-prop6.C:20:8:
error:
 call to consteval function 'f(0)' is not a constant expression
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp2a/consteval-prop6.C:20:8:   in
'
constexpr' expansion of 'f(0)'
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp2a/consteval-prop6.C:11:16:
error
: call to non-'constexpr' function 'void side_effect()'
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp2a/consteval-prop6.C:5:6: note:
'
void side_effect()' declared here
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp2a/consteval-prop6.C: In
function
 'void test()':
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp2a/consteval-prop6.C:57:22:
error
: call to consteval function 'x.X::X()' is not a constant expression
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp2a/consteval-prop6.C:57:22:   in
'constexpr' expansion of 'X()'
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp2a/consteval-prop6.C:51:3:
error:
 'consteval int undef(int)' used before its definition
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp2a/consteval-prop6.C:51:3: note:
'consteval X::X()' was promoted to an immediate function because its body
contai
ns an immediate-escalating expression 'undef(0)'
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp2a/consteval-prop6.C: At global
s
cope:
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp2a/consteval-prop6.C:45:15:
warning: inline function 'consteval int undef(int)' used but never defined
compiler exited with status 1
PASS: g++.dg/cpp2a/consteval-prop6.C  -std=c++20  (test for errors, line 11)
PASS: g++.dg/cpp2a/consteval-prop6.C  -std=c++20  (test for errors, line 20)
PASS: g++.dg/cpp2a/consteval-prop6.C  -std=c++20  (test for warnings, line 45)
PASS: g++.dg/cpp2a/consteval-prop6.C  -std=c++20  (test for errors, line 51)
PASS: g++.dg/cpp2a/consteval-prop6.C  -std=c++20  (test for errors, line 57)
FAIL: g++.dg/cpp2a/consteval-prop6.C  -std=c++20  at line 58 (test for
warnings, line 57)
PASS: g++.dg/cpp2a/consteval-prop6.C  -std=c++20 (test for excess errors)

[Bug target/113312] Update __attribute__((interrupt)) for Intel FRED

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #18 from H.J. Lu  ---
(In reply to H.J. Lu from comment #17)
> Please try users/hjl/pr113312/gcc-13 branch:
> 
> https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/pr113312/gcc-
> 13?ref_type=heads
> 
> It supports no_callee_saved_registers attribute. It should also avoid saving
> registers in noreturn functions in Linux kernel.

I updated users/hjl/pr113312/gcc-13 branch. It works on glibc. Please try it
on Linux kernel.

[Bug tree-optimization/113380] New: `(a CMP CST) | (a*a CMP CST1)` is not optimized as decent as with `||`

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

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

Bug ID: 113380
   Summary: `(a CMP CST) |  (a*a CMP CST1)` is not optimized as
decent as with `||`
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
int foo(int a)
{
   return (a < 4) | (a * a > 7);
}

int bar(int a)
{
   return (a < 4) | (a * a < 7);
}

int baz(int a)
{
   return (a > -4) | (a * a > 7);
}

int qux(int a)
{
   return (a > -4) | (a * a < 7);
}
```

This is not as optimized as:
```
int foo(int a)
{
   return (a < 4) || (a * a > 7);
}

int bar(int a)
{
   return (a < 4) || (a * a < 7);
}

int baz(int a)
{
   return (a > -4) || (a * a > 7);
}

int qux(int a)
{
   return (a > -4) || (a * a < 7);
}
```

[Bug tree-optimization/113379] `MIN == MAX` should be optimzed to `a == b`

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
The rest of the comparison operators:

`MIN  <= MAX ` should be simplified down to true.
`MIN  > MAX ` should be simplified down to false.

`MIN  < MAX ` should be simplified down to `a != b`
`MIN  >= MAX ` should be simplified down to `a == b`

[Bug tree-optimization/113379] New: `MIN == MAX` should be optimzed to `a == b`

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

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

Bug ID: 113379
   Summary: `MIN == MAX` should be optimzed to `a == b`
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
int f(int a, int b)
{
int c = a > b ? a : b;
int d = a < b ? a : b;
return c == d;
}
```

This should be optimized to `a == b;`

Likewise for the `!=` case too.

[Bug libstdc++/113230] 27_io/print/1.cc fails when run with qemu

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

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

--- Comment #9 from Hans-Peter Nilsson  ---
By the (In reply to Jonathan Wakely from comment #8)
> Although I guess Andrew's qemu setup doesn't match the simulator ET.

FWIW, by his uploaded board-info file calling 'load_generic_config "sim"' and a
look at what's in my /usr/share/dejagnu/config/sim.exp, and comparing that to
what's tested in ET simulator, I'd say it does: use and setting of
"set_board_info slow_simulator 1" is key.

[Bug c/113378] _Static_assert diagnostics lack information when compiling stdin

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #2 from Alejandro Colomar  ---
(In reply to Andrew Pinski from comment #1)
> >I expect the same diagnostic information when compiling stdin.
> 
> 
> This part of the diagnostic:
> 2 | foo();
>   | ^~~
> 
> Comes from re-reading in the source file.

Makes sense.

I've tested with other diagnostics, and it's a general thing, not just about
static_assert().  Sorry, for the bogus bug report :)

[Bug tree-optimization/113374] [14 regression] ICE in find_uses_to_rename_use

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 CC||pinskia at gcc dot gnu.org

[Bug c/113378] _Static_assert diagnostics lack information when compiling stdin

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Andrew Pinski  ---
>I expect the same diagnostic information when compiling stdin.


This part of the diagnostic:
2 | foo();
  | ^~~

Comes from re-reading in the source file.  Since stdin does not have a source
file backing, there is no output there.

[Bug target/113070] [14 regression] [AArch64] [PGO/LTO] Miscompilation of go compiler

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

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

Alex Coplan  changed:

   What|Removed |Added

   Keywords||patch
URL||https://patchwork.sourcewar
   ||e.org/project/gcc/list/?ser
   ||ies=29671

--- Comment #8 from Alex Coplan  ---
Patch series posted:
https://patchwork.sourceware.org/project/gcc/list/?series=29671

[Bug c/113378] New: _Static_assert diagnostics lack information when compiling stdin

[alx at kernel dot org via Gcc-bugs]

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

Bug ID: 113378
   Summary: _Static_assert diagnostics lack information when
compiling stdin
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alx at kernel dot org
  Target Milestone: ---

alx@debian:~/tmp$ cat is/asc.h 
#pragma GCC system_header
#define foo()  _Static_assert(sizeof(int) == sizeof(char))
alx@debian:~/tmp$ cat asc.c 
#include 
foo();
alx@debian:~/tmp$ cc -Wall -Wextra -isystem is asc.c
In file included from asc.c:1:
asc.c:2:1: error: static assertion failed
2 | foo();
  | ^~~
alx@debian:~/tmp$ cc -Wall -Wextra -isystem is -x c - :1:
:2:1: error: static assertion failed


I expect the same diagnostic information when compiling stdin.

[Bug target/113324] internal compiler error: in reload_combine_note_use, at postreload.c:1534

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #4 from Mikael Pettersson  ---
The ICE was fixed for 11.0 and up by 85f5a7d6ac9380fb9a07a8c900aa2e21d83d6805
 which is
part of a series of major updates to the vax backend.

Your best bet is to upgrade to gcc-11 or newer.

[Bug tree-optimization/113374] [14 regression] ICE in find_uses_to_rename_use

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
trunk.20210101 $ ~/gcc/results.20240112.asan.ubsan/bin/gcc -v 2>&1 | grep exp
gcc version 14.0.0 20240112 (experimental) (72b3495dfdddc277) 
trunk.20210101 $ ~/gcc/results.20240113.asan.ubsan/bin/gcc -v 2>&1 | grep exp
gcc version 14.0.1 20240113 (experimental) (34a827039fabcf24) 
trunk.20210101 $ git log 72b3495dfdddc277..34a827039fabcf24 | grep -c "^commit"
52
trunk.20210101 $

[Bug tree-optimization/113373] [14 regression] ICE in verify_ssa

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
$  /home/dcb38/gcc/results.20231221.asan.ubsan/bin/g++  -v 2>&1 | grep exp
gcc version 14.0.0 20231221 (experimental) (514ea1df444ca7f6) 
$  /home/dcb38/gcc/results.20231227.asan.ubsan/bin/g++  -v 2>&1 | grep expgcc
version 14.0.0 20231227 (experimental) (f19ceb2d49afdfa5) 
$ git log 514ea1df444ca7f6..f19ceb2d49afdfa5 | grep -c "^commit"
83
$

[Bug fortran/67277] segfault when passing a missing optional argument to an elemental intrinsic

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #7 from anlauf at gcc dot gnu.org ---
Created attachment 57073
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57073=edit
Patch for the ISFHTC optional SIZE argument

This patch addresses a bug when an optional dummy argument is passed as SIZE.

There is a separate, general issue with passing optional arguments to
elemental procedures, see PR113377.

[Bug libstdc++/113376] Confusing notes when using C++17 parallel algorithms

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug fortran/113377] New: Wrong code passing optional dummy argument to elemental procedure with optional dummy

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

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

Bug ID: 113377
   Summary: Wrong code passing optional dummy argument to
elemental procedure with optional dummy
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

There are likely several related PRs, e.g. pr67277, but here is a smaller
reproducer:

program p
  implicit none
  integer :: k(4) = 1, m(4)
  m = one (k)
  print *, m
contains
  function one (i, j) result (r)
integer, intent(in)   :: i(4)
integer, intent(in), optional :: j
integer   :: r(size(i))
r = two (i, j)  ! scalarizer dereferences loop invariant j ...
  end

  elemental function two (i, j) result (r)
integer, intent(in)   :: i
integer, value,  optional :: j
integer   :: r
r = 42*i
  end
end

This crashes in function one.  A scalar invocation does not fail.
The dump-tree suggests that the scalarizer sees the loop invariant j,
unconditionally dereferences it outside the loop, generates code that
unconditionally dereferences j in the invocation of two, and uses a
wrong interface:

integer(kind=4) two (integer(kind=4) & restrict i, integer(kind=4) j,
logical(kind=1) .j)

but one has:

D.4339 = (integer(kind=4) *) j;
{
  integer(kind=8) S.3;
  integer(kind=8) D.4341;

  D.4341 = stride.0;
  S.3 = 1;
  while (1)
{
  if (S.3 > 4) goto L.1;
  *((integer(kind=4) *) __result.0 + (sizetype) ((S.3 * D.4341 +
D.4338) * 4)) = two (&(*i)[S.3 + -1], *D.4339);
  S.3 = S.3 + 1;
}
  L.1:;

[Bug fortran/113305] ICE with do concurrent and ivdep

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:9935667a69896865b848dfa690f94c9c693a48a3

commit r14-7226-g9935667a69896865b848dfa690f94c9c693a48a3
Author: Harald Anlauf 
Date:   Fri Jan 12 19:51:11 2024 +0100

Fortran: annotations for DO CONCURRENT loops [PR113305]

gcc/fortran/ChangeLog:

PR fortran/113305
* gfortran.h (gfc_loop_annot): New.
(gfc_iterator, gfc_forall_iterator): Use for annotation control.
* array.cc (gfc_copy_iterator): Adjust.
* gfortran.texi: Document annotations IVDEP, UNROLL n, VECTOR,
NOVECTOR as applied to DO CONCURRENT.
* parse.cc (parse_do_block): Parse annotations IVDEP, UNROLL n,
VECTOR, NOVECTOR as applied to DO CONCURRENT.  Apply UNROLL only to
first loop control variable.
* trans-stmt.cc (iter_info): Use gfc_loop_annot.
(gfc_trans_simple_do): Adjust.
(gfc_trans_forall_loop): Annotate loops with IVDEP, UNROLL n,
VECTOR, NOVECTOR as needed for DO CONCURRENT.
(gfc_trans_forall_1): Handle loop annotations.

gcc/testsuite/ChangeLog:

PR fortran/113305
* gfortran.dg/do_concurrent_7.f90: New test.

[Bug libstdc++/113376] New: Confusing notes when using C++17 parallel algorithms

[pilarlatiesa at gmail dot com via Gcc-bugs]

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

Bug ID: 113376
   Summary: Confusing notes when using C++17 parallel algorithms
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pilarlatiesa at gmail dot com
  Target Milestone: ---

With GCC 14, the following code:

#include 
#include 
#include 

void f(std::vector )
{
std::for_each(std::execution::par, v.begin(), v.end(),
  [](int ) { i *= 2; });
}

when compiled emits a lot of notes like:

/home/pililatiesa/gcc-14/include/c++/14.0.0/pstl/algorithm_impl.h: In function
'_RandomAccessIterator
__pstl::__internal::__brick_unique(_RandomAccessIterator,
_RandomAccessIterator, _BinaryPredicate, std::true_type)':
/home/pililatiesa/gcc-14/include/c++/14.0.0/pstl/algorithm_impl.h:1219:5: note:
'#pragma message:  [Parallel STL message]: "Vectorized algorithm unimplemented,
redirected to serial"'
 1219 | _PSTL_PRAGMA_MESSAGE("Vectorized algorithm unimplemented,
redirected to serial");
  | ^~~~

I don't understand why all these functions are even instantiated as they appear
to be related to the vectorization of other algorithms.

Furthermore, in pstl_config.h we have:

// Check the user-defined macro for warnings
#if defined(PSTL_USAGE_WARNINGS)
#undef _PSTL_USAGE_WARNINGS
#define _PSTL_USAGE_WARNINGS PSTL_USAGE_WARNINGS
// Check the internal macro for warnings
#elif !defined(_PSTL_USAGE_WARNINGS)
#define _PSTL_USAGE_WARNINGS 0
#endif

and later in this file:


#if defined(_PSTL_USAGE_WARNINGS)
#define _PSTL_PRAGMA_MESSAGE(x) _PSTL_PRAGMA_MESSAGE_IMPL(x)
#define _PSTL_PRAGMA_MESSAGE_POLICIES(x) _PSTL_PRAGMA_MESSAGE_IMPL(x)
#else
#define _PSTL_PRAGMA_MESSAGE(x)
#define _PSTL_PRAGMA_MESSAGE_POLICIES(x)
#endif

i.e. is checking defined(_PSTL_USAGE_WARNINGS) instead of just
_PSTL_USAGE_WARNINGS. This logic doesn't seem right.

[Bug libstdc++/113318] [C++23] Implement P1185R12, Naming text encodings to demystify them

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

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

--- Comment #5 from Jonathan Wakely  ---
V2 https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642908.html

[Bug c++/113375] New: GCC accepts invalid program involving template keyword when used without a template arg list

[jlame646 at gmail dot com via Gcc-bugs]

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

Bug ID: 113375
   Summary: GCC accepts invalid program involving template keyword
when used without a template arg list
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jlame646 at gmail dot com
  Target Milestone: ---

The following invalid program(as per [temp.name#6]) compiles with gcc and
clang. https://godbolt.org/z/Yrj94haa4

```
template
struct C
{
 template void func(U)
 {

 }
};
int main()
{
C c;  
c.template func(5); //this is invalid as per current wording gcc and clang
accepts but msvc rejects 
//c.template func<>(5); //valid as per current wording. All compilers
accepts this
}

```

[Bug libstdc++/108976] codecvt for Unicode allows surrogate code points

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |13.3

--- Comment #12 from Jonathan Wakely  ---
Thanks, I think that makes sense.

[Bug libstdc++/108976] codecvt for Unicode allows surrogate code points

[dmjpp at hotmail dot com via Gcc-bugs]

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

--- Comment #11 from Dimitrij Mijoski  ---
(In reply to Jonathan Wakely from comment #10)
> I think it would be good to backport it, what do you think?

I don't really have strong need. Maybe porting only to v13 as that is pretty
straightforward (simple cherry-picking). Porting to v12 and v11 will require
porting other patches first.

[Bug middle-end/113364] [14 regression] ICE verify_ssa: `definition in block N does not dominate use in block` with `-O3 -march=znver2`

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

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

--- Comment #10 from Sam James  ---
(In reply to Tamar Christina from comment #8)
> Hmm curious, does it work for you with --with-build-config='bootstrap-O3'
> that's how I tested it before

Will have a look. I'll try ignore the bootstrap failure and build userland
stuff now so we can get some other cases if any.

Did you have -march= too? I
imagine bare '-O2' or '-O3' will be ok on amd64.

I built with the above configure args but also:
1. make -j32 -l32 'STAGE1_CFLAGS=-O3 -march=znver2 -pipe' 'BOOT_CFLAGS=-O3
-march=znver2 -pipe' ...
2. CFLAGS=... exported in the env

[Bug testsuite/113366] g++.dg/cpp2a/concepts-pr67774.C FAIL

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

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

--- Comment #3 from Jonathan Wakely  ---
It seems like there's no macro predefined by the front end to tell me
-fconcepts-ts is being used? It defines __cpp_concepts=201507L for C++17 mode,
but for C++20 that is __cpp_concepts=202002L instead (as required for C++20).

If there was a macro telling me the non-C++20 -fconcepts-ts parsing code was in
use, I could just omit the always_inline attributes entirely. That would be
simpler.

Having no way to tell that the compiler is in a broken^W non-conforming mode
isn't helpful.

[Bug libstdc++/113230] 27_io/print/1.cc fails when run with qemu

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

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

--- Comment #8 from Jonathan Wakely  ---
Although I guess Andrew's qemu setup doesn't match the simulator ET.

[Bug libstdc++/113230] 27_io/print/1.cc fails when run with qemu

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

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

--- Comment #7 from Jonathan Wakely  ---
Maybe that part of the test could just use { target { ! simulator } }

It's testing something that is highly dependent on the runtime context. It's
worth testing ... but only when we can control the context properly.

[Bug testsuite/113366] g++.dg/cpp2a/concepts-pr67774.C FAIL

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-01-13
 Status|UNCONFIRMED |NEW

--- Comment #2 from Jonathan Wakely  ---
I already defined a constexpr bool variable template in that class, and using
it in the __maybe_const_t alias seems to fix the -fconcepts-ts problem:

// Format as const if possible, to reduce instantiations.
template
  using __maybe_const_t
= __conditional_t<__formattable<_Tp>, const _Tp, _Tp>;

But then there are loads of other errors due to using attributes on constrained
functions:

format:4159:5: error: two consecutive '[' shall only introduce an attribute
before '[' token
 4159 | [[__gnu__::__always_inline__]]

I'll need to move those attributes.

Or maybe I can just make  reject attempts to use it with -fconcepts-ts 
]:-)

 is C++20 code, so you don't need the Concepts TS. Fix your concepts to
work with C++20 instead!

[Bug testsuite/113366] g++.dg/cpp2a/concepts-pr67774.C FAIL

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

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

--- Comment #1 from Jonathan Wakely  ---
Odd.

We get the type/value mismatch from here:

template
  using __maybe_const_t
= __conditional_t<__format::__formattable_with<_Tp, _Context>,
  const _Tp, _Tp>;


Where the boolean condition is:

  template>,
   typename _ParseContext
 = basic_format_parse_context>
concept __formattable_with
  = semiregular<_Formatter>
  && requires (const _Formatter __cf, _Tp&& __t, _Context __fc)
{
  { __cf.format(__t, __fc) } -> same_as;
};


That seems like a valid concept. Is something in the -fconcepts-ts code
tripping up?

[Bug libstdc++/106749] Implement C++23 library features

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

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

Bug 108822 Summary: [C++23] Implement P2255R2, type trait to detect reference 
binding to temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108822

   What|Removed |Added

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

[Bug libstdc++/108822] [C++23] Implement P2255R2, type trait to detect reference binding to temporary

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Done for GCC 14

[Bug libstdc++/108822] [C++23] Implement P2255R2, type trait to detect reference binding to temporary

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r14-7225-gf8a5298c97c460d45e888b123fe1bbcdb49b8ad4
Author: Jonathan Wakely 
Date:   Wed Jan 10 17:29:22 2024 +

libstdc++: Implement P2255R2 dangling checks for std::tuple [PR108822]

This is the last part of PR libstdc++/108822 implementing P2255R2, which
makes it ill-formed to create a std::tuple that would bind a reference
to a temporary.

The dangling checks are implemented as deleted constructors for C++20
and higher, and as Debug Mode static assertions in the constructor body
for older standards. This is similar to the r13-6084-g916ce577ad109b
changes for std::pair.

As part of this change, I've reimplemented most of std::tuple for C++20,
making use of concepts to replace the enable_if constraints, and using
conditional explicit to avoid duplicating most constructors. We could
use conditional explicit for the C++11 implementation too (with pragmas
to disables the -Wc++17-extensions warnings), but that should be done as
a stage 1 change for GCC 15 rather than now.

The partial specialization for std::tuple is no longer used for
C++20 (or more precisely, for a C++20 compiler that supports concepts
and conditional explicit). The additional constructors and assignment
operators that take std::pair arguments have been added to the C++20
implementation of the primary template, with sizeof...(_Elements)==2
constraints. This avoids reimplementing all the other constructors in
the std::tuple partial specialization to use concepts. This way
we avoid four implementations of every constructor and only have three!
(The primary template has an implementation of each constructor for
C++11 and another for C++20, and the tuple specialization has an
implementation of each for C++11, so that's three for each constructor.)

In order to make the constraints more efficient on the C++20 version of
the default constructor I've also added a variable template for the
__is_implicitly_default_constructible trait, implemented using concepts.

libstdc++-v3/ChangeLog:

PR libstdc++/108822
* include/std/tuple (tuple): Add checks for dangling references.
Reimplement constraints and constant expressions using C++20
features.
* include/std/type_traits [C++20]
(__is_implicitly_default_constructible_v): Define.
(__is_implicitly_default_constructible): Use variable template.
* testsuite/20_util/tuple/dangling_ref.cc: New test.

Reviewed-by: Patrick Palka 

[Bug c++/113332] [12/13/14 regression] checking ICE when building fcitx-5.1.6

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

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

--- Comment #3 from Sam James  ---
Created attachment 57072
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57072=edit
reduced.ii

[Bug tree-optimization/113370] wrong code with shift and _BitInt() at -O0

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 57071
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57071=edit
gcc14-pr113370.patch

Untested fix.

[Bug tree-optimization/113361] wrong code with __builtin_mul_overflow_p() and _BitInt() at -O0

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r14-7224-gf77a87982db60baa047b489ee4fea58b190503fb
Author: Jakub Jelinek 
Date:   Sat Jan 13 11:29:15 2024 +0100

lower-bitint: Fix up handle_operand_addr INTEGER_CST handling [PR113361]

As the testcase shows, the INTEGER_CST handling in handle_operand_addr
(i.e. what is used when passing address of an integer to a bitint library
routine) wasn't correct.  If the minimum precision to represent an
INTEGER_CST is smaller or equal to limb_prec, the code correctly uses
m_limb_type; if the minimum precision of a _BitInt INTEGER_CST is large
enough such that the bitint is middle, large or huge, everything is fine
too.  But the code wasn't handling correctly e.g. __int128 constants which
need more than limb_prec bits or _BitInt constants which on the
architecture
are considered small (say have DImode limb_mode, TImode abi_limb_mode and
for [65, 128] bits use TImode scalar like the proposed aarch64 patch).
Best would be to use an array of 2/3/4 limbs in that case, but we'd need to
convert the INTEGER_CST to a CONSTRUCTOR in the right endianity etc.,
so the code was using mid_min_prec to enforce a middle _BitInt precision.
Except that mid_min_prec can be 0 and not computed yet, or it doesn't have
to be the smallest middle _BitInt precision, just the smallest so far
encountered.  So, on the testcase one possibility was that it used
precision
65 from mid_min_prec, even when the INTEGER_CST actually needed larger
minimum precision (96 bits at least), or crashed when mid_min_prec was 0.

The patch fixes it in 2 hunks, the first makes sure we actually try to
create a BITINT_TYPE for the > limb_prec cases like __int128, and the
second
instead of using mid_min_prec attempts to increase mp precision until it
isn't small anymore.

2024-01-13  Jakub Jelinek  

PR tree-optimization/113361
* gimple-lower-bitint.cc (bitint_large_huge::handle_operand_addr):
Fix up determination of the type for > limb_prec constants.

* gcc.dg/torture/bitint-47.c: New test.

[Bug c++/113374] New: new breakage in find_uses_to_rename_use

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113374
   Summary: new breakage in find_uses_to_rename_use
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 57070
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57070=edit
C++ source code

In the last 24 hours or so, the attached code seems to have broken:

$ ~/gcc/results.20240112.asan.ubsan/bin/gcc -c -w -O3 -march=znver2 bug997.cc
$ ~/gcc/results.20240113.asan.ubsan/bin/gcc -c -w -O3 -march=znver2 bug997.cc
during GIMPLE pass: vect
bug997.cc: In member function ‘Botan::BER_Decoder&
Botan::BER_Decoder::decode(Botan::BigInt&, Botan::ASN1_Tag, Botan::ASN1_Tag)’:
bug997.cc:26093:14: internal compiler error: Segmentation fault
26093 | BER_Decoder& BER_Decoder::decode(BigInt& out,
  |  ^~~
0x11e8ad9 crash_signal(int)
../../trunk.20210101/gcc/toplev.cc:317
0x1388e28 find_uses_to_rename_use(basic_block_def*, tree_node*, bitmap_head**,
bitmap_head*)

[Bug tree-optimization/113287] wrong code with __builtin_mul_overflow_p() and _BitInt() with -O3 -msse4

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

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

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:7012a252528233ca3ced5b9230013c50b604da9b

commit r14-7223-g7012a252528233ca3ced5b9230013c50b604da9b
Author: Jakub Jelinek 
Date:   Sat Jan 13 10:46:51 2024 +0100

testsuite: Fix up vect-early-break_100-pr113287.c testcase [PR113287]

When the testcase was being adjusted for unsigned long -> unsigned long
long,
two spots using long weren't changed to long long, so the testcase still
warns
about UB in shifts.

2024-01-13  Jakub Jelinek  

PR tree-optimization/113287
* gcc.dg/vect/vect-early-break_100-pr113287.c: Use long long
instead
of long.

[Bug c++/113373] New: ice in verify_ssa

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113373
   Summary: ice in verify_ssa
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 57069
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57069=edit
C++ source code

Still some fallout from recent gcc trunk changes.

The attached code does this:

foundBugs $ /home/dcb38/gcc/results.20231221.asan.ubsan/bin/g++ -c -w -O3
-march=znver3 bug996.cc
foundBugs $ /home/dcb38/gcc/results.20231227.asan.ubsan/bin/g++ -c -w -O3
-march=znver3 bug996.cc
../sdk/angelscript/source/as_restore.cpp: In member function ‘void
asCReader::TranslateFunction(asCScriptFunction*)’:
../sdk/angelscript/source/as_restore.cpp:2824:6: error: definition in block 453
does not dominate use in block 457
for SSA_NAME: _1244 in statement:
size_1336 = PHI <_1244(457), 0(227)>
PHI argument
_1244
for PHI node
size_1336 = PHI <_1244(457), 0(227)>
during GIMPLE pass: vect
../sdk/angelscript/source/as_restore.cpp:2824:6: internal compiler error:
verify_ssa failed

[Bug middle-end/113364] [14 regression] ICE verify_ssa: `definition in block N does not dominate use in block` with `-O3 -march=znver2`

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

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

--- Comment #9 from Tamar Christina  ---
vect_create_epilog_for_reduction needs to handle the case where the vectorizer
has picked a different exit than the main one.

diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index eccf0953bba..6f761a4a78f 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -5965,7 +5965,8 @@ vect_create_epilog_for_reduction (loop_vec_info
loop_vinfo,
  loop-closed PHI of the inner loop which we remember as
  def for the reduction PHI generation.  */
   bool double_reduc = false;
-  bool main_exit_p = LOOP_VINFO_IV_EXIT (loop_vinfo) == loop_exit;
+  bool main_exit_p = LOOP_VINFO_IV_EXIT (loop_vinfo) == loop_exit
+&& !LOOP_VINFO_EARLY_BREAKS_VECT_PEELED (loop_vinfo);
   stmt_vec_info rdef_info = stmt_info;
   if (STMT_VINFO_DEF_TYPE (stmt_info) == vect_double_reduction_def)
 {

fixes it. But would be good if I can reproduce the bootstrap issue. Will try
with provided options.

[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-13
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

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

A slightly different testcase which made it easier to test with clang (clang
does not have the _p variants):
```
_BitInt(8) a, b, c;

_BitInt(8)
foo(_BitInt(6384) y)
{
  _BitInt(4745) x = -(b % y) * b;
  int t;
  _BitInt(8) tt;
  int i = __builtin_sub_overflow(-y, 0, );
  c |= __builtin_add_overflow(i, 0, );
  return x;
}

int
main(void)
{
  _BitInt(8) x = foo(4);
  if (x != 0)
__builtin_abort();
  return 0;
}
```

[Bug tree-optimization/113372] New: wrong code with _BitInt() arithmetics at -O1

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 113372
   Summary: wrong code with _BitInt() arithmetics at -O1
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c
$ ./a.out 
Aborted

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

[Bug middle-end/113364] [14 regression] ICE verify_ssa: `definition in block N does not dominate use in block` with `-O3 -march=znver2`

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #8 from Tamar Christina  ---
Hmm curious, does it work for you with --with-build-config='bootstrap-O3'
that's how I tested it before