[Bug c++/107186] GCC rejects use of static constexpr member function in noexcept complete-class context

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||4.6.4

--- Comment #1 from Andrew Pinski  ---
clang and MSVC also rejects this for the same reason as GCC ...

[Bug c++/86970] Rejected constexpr expression involving lambdas and inheritance, "use of this in a constant expression"

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Martin Liška from comment #4)
> Fixed with r11-1677-g0801f419440c14f6.

No, you missed that you need -std=c++17 to test with the example. That commit
just changed the default from -std=gnu++14 to -std=gnu++17  ...

[Bug middle-end/97265] building vec.h produces warning with clang (const not implicitly with constexpr in C++14 and above)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |11.0
 Status|NEW |RESOLVED

--- Comment #2 from Andrew Pinski  ---
Fixed in GCC 11 by r11-5962-gda40a69c9ef878 .

[Bug c++/110999] New: GCC rejects static variable with constexpr storage from inline method definition

[danakj at orodu dot net via Gcc-bugs]

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

Bug ID: 110999
   Summary: GCC rejects static variable with constexpr storage
from inline method definition
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danakj at orodu dot net
  Target Milestone: ---

Godbolt: https://godbolt.org/z/srvhxjqqz

GCC will accept it if the method definition comes after the `constexpr` storage
definition. But it rejects it if the method definition is inline in the class.

```
struct OutOfLine {
static const OutOfLine kConstant;
constexpr int f();
int i = 2;
};
inline constexpr OutOfLine OutOfLine::kConstant;
// Accepted.
constexpr int OutOfLine::f() { return kConstant.i; }

struct InLine {
static const InLine kConstant;
// Rejected.
constexpr int f() { return kConstant.i; }
int i = 2;
};
inline constexpr InLine InLine::kConstant;

int main() {
constexpr int x = OutOfLine().f();
constexpr int y = InLine().f();
}
```

[Bug middle-end/110994] RISC-V Fortran: Illegal instruction ICE with scalable autovec

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Pan Li :

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

commit r14-3177-g9890f377013cf1e4f5b9fab8a7287a5380dade1f
Author: Juzhe-Zhong 
Date:   Sat Aug 12 10:30:02 2023 +0800

RISC-V: Add TAREGT_VECTOR check into VLS modes

This patch fixes bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110994

This is caused VLS modes incorrect codes int register allocation.

The original case trigger the ICE is fortran code but I can reproduce
with a C code.

gcc/ChangeLog:

PR target/110994
* config/riscv/riscv-opts.h (TARGET_VECTOR_VLS): Add TARGET_VETOR.

gcc/testsuite/ChangeLog:

PR target/110994
* gcc.target/riscv/rvv/autovec/vls/pr110994.c: New test.

[Bug modula2/108119] m2rte plugin should be disabled by default

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

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

--- Comment #5 from Gaius Mulley  ---
Created attachment 55730
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55730=edit
Proposed fix v2

Here is version 2 of the patch which disables the plugin by default.  The
testsuite expect scripts have been adjusted to add -fm2-plugin if necessary.
The expect scripts understand ENABLE_PLUGIN and will skip tests if necessary.
By default m2rte is not enabled in the gm2 driver.

Currently bootstrap testing on gcc-14 and gcc-13 for both --enable-plugin and
--disable-plugin.

[no subject]

[มะลิ แซ่ตั่ง via Gcc-bugs]

ทุนหมุนเวียนธุรกิจระยะสั้นสำหรับ ผู้ประกอบการ โรงงานฯ หจก. บริษัท ธุรกิจ
SMEs
 ง่ายกว่าธนาคาร | ไม่เช็คบูโร | ลดต้น ลดดอกเบี้ย | ไม่ต้องค้ำ | คุยง่าย
อนุมัติไวเร็ว
โทร 082 5928519 คุณเอก
โทร 063 2543219 ตะวัน
ไลน์ไอดี esc.credit
✅ดอกเบี้ยต่ำสุด 1.25%*
✅ปิดยอดได้ตลอดเวลา ไม่ต้องรอให้ครบสัญญา
✅ฟรีค่าธรรมเนียม ไม่เรียกเก็บเงินก่อนทำสัญญาทุกกรณี

[Bug middle-end/110986] [14 Regression] aarch64 has support for conditional not (and vectors can do conditional not still) after r14-3110-g7fb65f10285

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #55728|0   |1
is obsolete||

--- Comment #13 from Andrew Pinski  ---
Created attachment 55729
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55729=edit
First patch

First part to fix sve/cond_unary_5.c .
Testing it right now and will submit it tomorrow.

[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing

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

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

JuzheZhong  changed:

   What|Removed |Added

 CC||juzhe.zhong at rivai dot ai

--- Comment #1 from JuzheZhong  ---
I don't think this is RISC-V target specific issue, at leas it should not be
the RVV specific issue:

[jzzhong@rios-cad5:/work/home/jzzhong/work/insn]$~/work/rvv-opensource/output/gcc-rv64/bin/riscv64-rivai-elf-gfortran
-march=rv64gc -mabi=lp64d -Ofast pr110996.f90
pr110996.f90:6:20:

6 |SUBROUTINE c(d) e
  |1
Error: Syntax error in SUBROUTINE statement at (1)
f951: internal compiler error: Segmentation fault
0x17bd167 crash_signal
../../../riscv-gcc/gcc/toplev.cc:314
0xe9d659 resolve_symbol
../../../riscv-gcc/gcc/fortran/resolve.cc:16643
0xec5dfd do_traverse_symtree
../../../riscv-gcc/gcc/fortran/symbol.cc:4190
0xec5eb8 gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*))
../../../riscv-gcc/gcc/fortran/symbol.cc:4215
0xea0421 resolve_types
../../../riscv-gcc/gcc/fortran/resolve.cc:17963
0xea04d9 resolve_types
../../../riscv-gcc/gcc/fortran/resolve.cc:17977
0xea0915 gfc_resolve(gfc_namespace*)
../../../riscv-gcc/gcc/fortran/resolve.cc:18083
0xe6bd6b resolve_all_program_units
../../../riscv-gcc/gcc/fortran/parse.cc:6909
0xe6c558 gfc_parse_file()
../../../riscv-gcc/gcc/fortran/parse.cc:7165
0xed11d9 gfc_be_parse_file
../../../riscv-gcc/gcc/fortran/f95-lang.cc:229
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.


It can be reproduced without 'v' extension in '-march'.

[Bug middle-end/110994] RISC-V Fortran: Illegal instruction ICE with scalable autovec

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

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

JuzheZhong  changed:

   What|Removed |Added

 CC||juzhe.zhong at rivai dot ai

--- Comment #1 from JuzheZhong  ---
confirm and fix patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627219.html

[Bug middle-end/110986] [14 Regression] aarch64 has support for conditional not (and vectors can do conditional not still) after r14-3110-g7fb65f10285

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

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

--- Comment #12 from Andrew Pinski  ---
It turns out we should only turn `(a ? -1 : 0) ^ b` into a conditional not if
that exists.

Even on armv8-a without SVE we get on the trunk:
cmtst   v31.8h, v31.8h, v31.8h
eor v31.16b, v31.16b, v30.16b

vs GCC 13:
not v1.16b, v2.16b
cmeqv0.8h, v0.8h, #0
bsl v0.16b, v2.16b, v1.16b

Anyways still have a patch for the same type case. But it now depends on
getting conditional not in place.

[Bug middle-end/110986] [14 Regression] aarch64 has support for conditional not (and vectors can do conditional not still) after r14-3110-g7fb65f10285

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

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

--- Comment #11 from Andrew Pinski  ---
So actually for x86_64, The trunk actually produces better code (figures)

.L2:
movdqu  (%rdx,%rax), %xmm0
movdqu  (%rsi,%rax), %xmm2
movdqu  (%rsi,%rax), %xmm1
pcmpeqw %xmm3, %xmm0
pxor%xmm4, %xmm2
pand%xmm0, %xmm1
pandn   %xmm2, %xmm0
por %xmm1, %xmm0
movups  %xmm0, (%rdi,%rax)
addq$16, %rax
cmpq$256, %rax
jne .L2

.L2:
movdqu  (%rdx,%rax), %xmm0
movdqu  (%rsi,%rax), %xmm2
pcmpeqw %xmm1, %xmm0
pcmpeqw %xmm1, %xmm0
pxor%xmm2, %xmm0
movups  %xmm0, (%rdi,%rax)
addq$16, %rax
cmpq$256, %rax
jne .L2

[Bug c++/106094] Lifetime extension of temporary do not obey some rules of [class.temporary]

[de34 at live dot cn via Gcc-bugs]

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

Jiang An  changed:

   What|Removed |Added

 CC||de34 at live dot cn

--- Comment #6 from Jiang An  ---
CWG2666 may be related.
https://cplusplus.github.io/CWG/issues/2666.html

[Bug middle-end/110986] [14 Regression] aarch64 has support for conditional not (and vectors can do conditional not still) after r14-3110-g7fb65f10285

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

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #9)
> Created attachment 55728 [details]
> Fixes part of this
> 
> This patch does 2 things which I will split out.
> First is it creates COND_NOT like COND_NEG to allow better code generation
> earlier on.
> 
> Next it simplifies:
> vector `(a ? -1 : 0) ^ b` -> `a ? ~b : b` as there might be a conditional
> not.
> 
> That fixes the case where the types are the same. Still need to fix up the
> case where the types are different.

The second part is really enough to fix that. The COND_NOT just improves the
situtation ...

[Bug middle-end/110986] [14 Regression] aarch64 has support for conditional not (and vectors can do conditional not still) after r14-3110-g7fb65f10285

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

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

--- Comment #9 from Andrew Pinski  ---
Created attachment 55728
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55728=edit
Fixes part of this

This patch does 2 things which I will split out.
First is it creates COND_NOT like COND_NEG to allow better code generation
earlier on.

Next it simplifies:
vector `(a ? -1 : 0) ^ b` -> `a ? ~b : b` as there might be a conditional not.

That fixes the case where the types are the same. Still need to fix up the case
where the types are different.

[Bug c++/106604] Fully-specified deduction guide in anonymous namespace warns as-if a function? Unsuppressably?

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

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

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

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

commit r14-3175-gf50f603cbfd05653555e9856360c83108bbd1d8a
Author: Patrick Palka 
Date:   Fri Aug 11 21:13:23 2023 -0400

c++: bogus warning w/ deduction guide in anon ns [PR106604]

Here we're unintentionally issuing a "declared static but never defined"
warning from wrapup_namespace_globals for a deduction guide declared in
an anonymous namespace.  This patch fixes this by giving deduction guides
a dummy DECL_INITIAL, which suppresses the warning and also allows us to
simplify redeclaration checking for them.

Co-authored-by: Jason Merrill 

PR c++/106604

gcc/cp/ChangeLog:

* decl.cc (redeclaration_error_message): Remove special handling
for deduction guides.
(grokfndecl): Give deduction guides a dummy DECL_INITIAL.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/class-deduction74.C: Expect "defined" instead
of "declared" in the repeated deduction guide diagnostics.
* g++.dg/cpp1z/class-deduction116.C: New test.

[Bug target/110985] RISC-V: Incorrect code gen for RVV VLS

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Pan Li :

https://gcc.gnu.org/g:685abdb4a1fe46a12da5cc9ae1d5aaef9344a339

commit r14-3173-g685abdb4a1fe46a12da5cc9ae1d5aaef9344a339
Author: Juzhe-Zhong 
Date:   Fri Aug 11 16:45:26 2023 +0800

RISC-V: Fix vec_series expander[PR110985]

This patch fix bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110985

gcc/ChangeLog:
PR target/110985
* config/riscv/riscv-v.cc (expand_vec_series): Refactor the
expander.

gcc/testsuite/ChangeLog:
PR target/110985
* gcc.target/riscv/rvv/autovec/vls-vlmax/pr110985.c: New test.

[Bug middle-end/110986] [14 Regression] aarch64 has support for conditional not (and vectors can do conditional not still) after r14-3110-g7fb65f10285

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
So the SVE issue here is related to the old PR 93183 .

[Bug middle-end/110986] [14 Regression] aarch64 has support for conditional not (and vectors can do conditional not still) after r14-3110-g7fb65f10285

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

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

--- Comment #6 from Andrew Pinski  ---
Oh and:
  vect_patt_10.16_58 = .VCOND (vect__4.10_47, { 0, 0, 0, 0, 0, 0, 0, 0 }, { 1,
1, 1, 1, 1, 1, 1, 1 }, { 0, 0, 0, 0, 0, 0, 0, 0 }, 114);
  vect_patt_10.16_59 = .VCOND (vect__4.11_49, { 0, 0, 0, 0, 0, 0, 0, 0 }, { 1,
1, 1, 1, 1, 1, 1, 1 }, { 0, 0, 0, 0, 0, 0, 0, 0 }, 114);
  vect_patt_42.17_60 = VEC_PACK_TRUNC_EXPR ;
  vect__40.18_61 = -vect_patt_42.17_60;

needs to change just into:
  mask__9.16_54 = vect__4.10_46 != { 0, 0, 0, 0, 0, 0, 0, 0 };
  mask__9.16_55 = vect__4.11_48 != { 0, 0, 0, 0, 0, 0, 0, 0 };
  mask_patt_40.17_56 = VEC_PACK_TRUNC_EXPR ;

That is push the negative back if it is a VCOND I think ...

--- Comment #7 from Andrew Pinski  ---
Oh and:
  vect_patt_12.16_57 = .VCOND (vect__3.10_47, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0 }, { 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 }, { 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, 114);
  vect_patt_42.17_58 = [vec_unpack_lo_expr] vect_patt_12.16_57;
  vect_patt_42.17_59 = [vec_unpack_hi_expr] vect_patt_12.16_57;
  vect__40.18_60 = -vect_patt_42.17_58;
  vect__40.18_61 = -vect_patt_42.17_59;

[Bug tree-optimization/110199] [12/13/14 Regression] Missing VRP transformation with MIN_EXPR and known relation

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

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

--- Comment #2 from Andrew Pinski  ---
I Kinda see how to implement this by creating
operator_min::fold_range/operator_max::fold_range but I am still new on using
these interfaces so I am not 100% sure how to use them.

[Bug analyzer/105899] RFE: -fanalyzer could complain about misuses of standard C string APIs

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

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

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-08-11

[Bug libstdc++/110990] `format_to_n` returns wrong value

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

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

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

[Bug libstdc++/110990] `format_to_n` returns wrong value

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

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

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

https://gcc.gnu.org/g:003016a40844701c48851020df672b70f3446bdb

commit r14-3170-g003016a40844701c48851020df672b70f3446bdb
Author: Jonathan Wakely 
Date:   Fri Aug 11 23:02:44 2023 +0100

libstdc++: Fix std::format_to_n return value [PR110990]

When writing to a contiguous iterator, std::format_to_n(out, n, ...)
always returns out + n, even if it wrote fewer than n characters to the
iterator.

The problem is in the _M_finish() member function of the _Iter_sink
specialization for contiguous iterators. _M_finish() calls _M_overflow()
to update its count of characters written, so it can return the count of
characters that would be written if there was room. But _M_overflow()
assumes it's only called when the buffer is full, and so switches to the
internal buffer. _M_finish() then thinks that if the internal buffer is
in use, we already wrote at least n characters and so returns out+n as
the output position.

We can fix the problem by adding a check in _M_overflow() so that we
don't update the count and switch to the internal buffer unless we've
run out of room, i.e. _M_unused().size() is zero. The caller then needs
to be prepared for _M_count not being the final total, and so add
_M_used.size() to it.

However, there's not actually any need for _M_finish() to call
_M_overflow() to get the count. We now need to use _M_count and
_M_used.size() to get the total anyway so _M_overflow() doesn't help
with that. And we don't need to use _M_overflow() to flush unwritten
characters to the output, because the specialization for contiguous
iterators always writes directly to the output without buffering (except
when we've exceeded the maximum number of characters, in which case we
want to discard the buffered characters anyway). So _M_finish() can be
simplified and can avoid calling _M_overflow().

This change also fixes some member functions of other sink classes to
only call _M_overflow() when there are characters in the buffer, which
is needed to meet _M_overflow's precondition that _M_used().size()!=0.

libstdc++-v3/ChangeLog:

PR libstdc++/110990
* include/std/format (_Seq_sink::get): Only call _M_overflow if
its precondition is met.
(_Iter_sink::_M_finish): Likewise.
(_Iter_sink::_M_overflow): Only switch to the
internal buffer after running out of space.
(_Iter_sink::_M_finish): Do not use _M_overflow.
(_Counting_sink::count): Likewise.
* testsuite/std/format/functions/format_to_n.cc: Check cases
where the output fits into the buffer.

[Bug c++/102455] ICE in verify_ctor_sanity with vector types in constexpr and variable template

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to work||13.1.0

--- Comment #2 from Andrew Pinski  ---
Looks to be fixed for GCC 13.1.0.

[Bug analyzer/105899] RFE: -fanalyzer could complain about misuses of standard C string APIs

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

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

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

https://gcc.gnu.org/g:325f9e88802daaca0a4793ca079bb504f7d76c54

commit r14-3169-g325f9e88802daaca0a4793ca079bb504f7d76c54
Author: David Malcolm 
Date:   Fri Aug 11 18:05:48 2023 -0400

analyzer: new warning: -Wanalyzer-unterminated-string [PR105899]

This patch adds new functions to the analyzer for checking that
an argument at a callsite is a pointer to a valid null-terminated
string, and uses this for the following known functions:

- error (param 3, the format string)
- error_at_line (param 5, the format string)
- putenv
- strchr (1st param)
- strcpy (2nd param)
- strdup

Currently the check merely detects pointers to unterminated string
constants, and adds a new -Wanalyzer-unterminated-string to complain
about that.  I'm experimenting with detecting other ways in which
a buffer can fail to be null-terminated, and for other problems with
such buffers, but this patch at least adds the framework for wiring
up the check to specific parameters of known_functions.

gcc/analyzer/ChangeLog:
PR analyzer/105899
* analyzer.opt (Wanalyzer-unterminated-string): New.
* call-details.cc
(call_details::check_for_null_terminated_string_arg): New.
* call-details.h
(call_details::check_for_null_terminated_string_arg): New decl.
* kf-analyzer.cc (class kf_analyzer_get_strlen): New.
(register_known_analyzer_functions): Register it.
* kf.cc (kf_error::impl_call_pre): Check that format arg is a
valid null-terminated string.
(kf_putenv::impl_call_pre): Likewise for the sole param.
(kf_strchr::impl_call_pre): Likewise for the first param.
(kf_strcpy::impl_call_pre): Likewise for the second param.
(kf_strdup::impl_call_pre): Likewise for the sole param.
* region-model.cc (get_strlen): New.
(struct call_arg_details): New.
(inform_about_expected_null_terminated_string_arg): New.
(class unterminated_string_arg): New.
(region_model::check_for_null_terminated_string_arg): New.
* region-model.h
(region_model::check_for_null_terminated_string_arg): New decl.

gcc/ChangeLog:
PR analyzer/105899
* doc/analyzer.texi (__analyzer_get_strlen): New.
* doc/invoke.texi: Add -Wanalyzer-unterminated-string.

gcc/testsuite/ChangeLog:
PR analyzer/105899
* gcc.dg/analyzer/analyzer-decls.h (__analyzer_get_strlen): New.
* gcc.dg/analyzer/error-1.c (test_error_unterminated): New.
(test_error_at_line_unterminated): New.
* gcc.dg/analyzer/null-terminated-strings-1.c: New test.
* gcc.dg/analyzer/putenv-1.c (test_unterminated): New.
* gcc.dg/analyzer/strchr-1.c (test_unterminated): New.
* gcc.dg/analyzer/strcpy-1.c (test_unterminated): New.
* gcc.dg/analyzer/strdup-1.c (test_unterminated): New.

Signed-off-by: David Malcolm 

[Bug c/110998] New: Inconsistent -Wformat warnings issued for %I64d

[syeberman at gmail dot com via Gcc-bugs]

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

Bug ID: 110998
   Summary: Inconsistent -Wformat warnings issued for %I64d
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: syeberman at gmail dot com
  Target Milestone: ---

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

GCC reports inconsistent warnings with -Wformat where the Windows-only %I64d
format is used.

It is understood that before Windows supported %lld, the correct specifier to
use for long long was %I64d. As such, the following code should compile without
error:

  fprintf(stdout, "%I64d\n", 1LL);

However, on GCC 13.2.0 on Windows (specifically, the WinLibs build available at
https://winlibs.com), the following error is issued:

  warning: format '%d' expects argument of type 'int', but argument 3 has type
'long long int' [-Wformat=]

What is interesting, however, is that if the LL suffix is removed, the exact
opposite error is issued:

  fprintf(stdout, "%I64d\n", 1);

  warning: format '%I64d' expects argument of type 'long long int', but
argument 3 has type 'int' [-Wformat=]


Minimal testcase


#include 

int main(int argc, char **argv) {
fprintf(stdout, "%I64d\n", 1LL);
fprintf(stdout, "%I64d\n", 1);
}


Command line


C:\MinGW\winlibs-i686-posix-dwarf-gcc-13.2.0-llvm-16.0.6-mingw-w64ucrt-11.0.0-r1\mingw32\bin\gcc.exe
-v -save-temps -Wformat testcase.c


Output
--

Using built-in specs.
COLLECT_GCC=C:\MinGW\winlibs-i686-posix-dwarf-gcc-13.2.0-llvm-16.0.6-mingw-w64ucrt-11.0.0-r1\mingw32\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/MinGW/winlibs-i686-posix-dwarf-gcc-13.2.0-llvm-16.0.6-mingw-w64ucrt-11.0.0-r1/mingw32/bin/../libexec/gcc/i686-w64-mingw32/13.2.0/lto-wrapper.exe
OFFLOAD_TARGET_NAMES=nvptx-none
Target: i686-w64-mingw32
Configured with: ../configure
--prefix=/R/winlibs32ucrt_stage/inst_gcc-13.2.0/share/gcc
--build=i686-w64-mingw32 --host=i686-w64-mingw32
--enable-offload-targets=nvptx-none --with-pkgversion='MinGW-W64
i686-ucrt-posix-dwarf, built by Brecht Sanders' --with-tune=generic
--enable-checking=release --enable-threads=posix --with-dwarf2
--disable-sjlj-exceptions --disable-libunwind-exceptions
--disable-serial-configure --disable-bootstrap --enable-host-shared
--enable-plugin --disable-default-ssp --disable-rpath --disable-libstdcxx-debug
--disable-version-specific-runtime-libs --with-stabs --disable-symvers
--enable-languages=c,c++,fortran,lto,objc,obj-c++ --disable-gold --disable-nls
--disable-stage1-checking --disable-win32-registry --disable-multilib
--enable-ld --enable-libquadmath --enable-libada --enable-libssp
--enable-libstdcxx --enable-lto --enable-fully-dynamic-string --enable-libgomp
--enable-graphite --enable-mingw-wildcard --enable-libstdcxx-time
--enable-libstdcxx-pch --with-mpc=/d/Prog/winlibs32ucrt_stage/custombuilt
--with-mpfr=/d/Prog/winlibs32ucrt_stage/custombuilt
--with-gmp=/d/Prog/winlibs32ucrt_stage/custombuilt
--with-isl=/d/Prog/winlibs32ucrt_stage/custombuilt --enable-large-address-aware
--disable-libstdcxx-backtrace --enable-install-libiberty --enable-__cxa_atexit
--without-included-gettext --with-diagnostics-color=auto
--enable-clocale=generic --with-libiconv --with-system-zlib
--with-build-sysroot=/R/winlibs32ucrt_stage/gcc-13.2.0/build_mingw/mingw-w64
CFLAGS='-I/d/Prog/winlibs32ucrt_stage/custombuilt/include/libdl-win32
-Wno-int-conversion -march=pentium4 -mtune=generic -O2 '
CXXFLAGS='-Wno-int-conversion -march=pentium4 -mtune=generic -O2 '
LDFLAGS='-pthread -Wl,--no-insert-timestamp -Wl,--dynamicbase  -Wl,--nxcompat
-Wl,--tsaware'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (MinGW-W64 i686-ucrt-posix-dwarf, built by Brecht Sanders) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wformat=1' '-mtune=generic'
'-march=pentiumpro' '-dumpdir' 'a-'

C:/MinGW/winlibs-i686-posix-dwarf-gcc-13.2.0-llvm-16.0.6-mingw-w64ucrt-11.0.0-r1/mingw32/bin/../libexec/gcc/i686-w64-mingw32/13.2.0/cc1.exe
-E -quiet -v -iprefix
C:/MinGW/winlibs-i686-posix-dwarf-gcc-13.2.0-llvm-16.0.6-mingw-w64ucrt-11.0.0-r1/mingw32/bin/../lib/gcc/i686-w64-mingw32/13.2.0/
-D_REENTRANT sye.test.c -mtune=generic -march=pentiumpro -Wformat=1
-fpch-preprocess -o a-sye.test.i
ignoring duplicate directory
"C:/MinGW/winlibs-i686-posix-dwarf-gcc-13.2.0-llvm-16.0.6-mingw-w64ucrt-11.0.0-r1/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/13.2.0/include"
ignoring nonexistent directory
"R:/winlibs32ucrt_stage/inst_gcc-13.2.0/share/gcc/include"
ignoring nonexistent directory
"/R/winlibs32ucrt_stage/inst_gcc-13.2.0/share/gcc/include"
ignoring duplicate directory
"C:/MinGW/winlibs-i686-posix-dwarf-gcc-13.2.0-llvm-16.0.6-mingw-w64ucrt-11.0.0-r1/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/13.2.0/include-fixed"
ignoring 

[Bug libstdc++/110990] `format_to_n` returns wrong value

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

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

--- Comment #2 from Jonathan Wakely  ---
The problem is that the _Iter_sink for contiguous iterators calls _M_overflow()
to update its count of characters written, but _M_overflow() assumes it's only
called when the buffer is full, and so switches to the internal buffer. The
_M_finish()&& function then thinks that if the internal buffer is in use, we
wrote n characters already and so returns out+n which is the end of the buffer.

I'm testing a fix.

[Bug middle-end/110989] RISC-V vector ICE due to invalid tree code in GIMPLE vect pass

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Pan Li :

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

commit r14-3167-g5bfb5e772f6cf121563f08d27d2c652ea469bbfb
Author: Juzhe-Zhong 
Date:   Fri Aug 11 21:55:42 2023 +0800

VECT: Fix ICE on MASK_LEN_{LOAD, STORE} when no LEN recorded[PR110989]

This ICE is caused because of this situation:

mask__49.21_99 = vect__17.19_96 == { 0.0, ... };
...
vect__6.24_107 = .MASK_LEN_LOAD (vectp.22_105, 32B, mask__49.21_99,
POLY_INT_CST [2, 2], 0);

The MASK_LEN_LOAD is using real MASK which is produced by the EQ comparison
wheras the LEN
is the dummy LEN which is the vectorization factor.

In this situation, we didn't enter 'vect_record_loop_len' since there is no
LEN loop control.
Then 'LOOP_VINFO_RGROUP_IV_TYPE' is not suitable type for 'build_int_cst'
used for producing
LEN argument for 'MASK_LEN_LOAD', so use sizetype instead which is
perfectly matching
RVV length requirement.

gcc/ChangeLog:
PR middle-end/110989
* tree-vect-stmts.cc (vectorizable_store): Replace iv_type with
sizetype.
(vectorizable_load): Ditto.

gcc/testsuite/ChangeLog:
PR middle-end/110989
* gcc.target/riscv/rvv/autovec/pr110989.c: New test.

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

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #13 from Jason Merrill  ---
Fixed for 12.4/13.3/14.

[Bug c++/109678] [13/14 Regression] exponential time behavior on std::variant

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Jason Merrill
:

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

commit r13-7713-gd3088f0ed25fe7200fd657b70cb5af53139b0193
Author: Jason Merrill 
Date:   Mon May 1 17:41:44 2023 -0400

c++: std::variant slow to compile [PR109678]

Here, when dealing with a class with a complex subobject structure, we
would
try and fail to find the relevant FIELD_DECL for an empty base before
giving
up.  And we would do this at each level, in a combinatorially problematic
way.  Instead, we should check for an empty base first.

PR c++/109678

gcc/cp/ChangeLog:

* constexpr.cc (cxx_fold_indirect_ref_1): Handle empty base first.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/variant1.C: New test.

[Bug c++/110997] [13/14 Regression] internal compiler error: in cxx_eval_constant_expression, at cp/constexpr.cc:8005

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-08-11

[Bug c++/110997] [13/14 Regression] internal compiler error: in cxx_eval_constant_expression, at cp/constexpr.cc:8005

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |13.3
 CC||jason at gcc dot gnu.org
   Priority|P3  |P2
 Blocks||107687

--- Comment #1 from Marek Polacek  ---
Started with r13-3256:

commit 9bf74082bc93226e1ceb66430706e957e460c841
Author: Jason Merrill 
Date:   Fri Oct 7 20:34:53 2022 -0400

c++: defer all consteval in default args [DR2631]


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107687
[Bug 107687] [C++23] P2564 - consteval needs to propagate up

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

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Jason Merrill
:

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

commit r13-7712-gdb6c4ba976a795480cbccc380e3a84eec1de8e68
Author: Jason Merrill 
Date:   Wed Jul 26 10:39:34 2023 -0400

c++: member vs global template [PR106310]

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

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

PR c++/106310

gcc/cp/ChangeLog:

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

gcc/testsuite/ChangeLog:

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

[Bug c++/106890] [11 Regression] virtual inheritance triggers compiler error when instatiating derived class with in-class initialization since r8-2709-g12659e10c7820071

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jason Merrill
:

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

commit r12-9811-gc4212c41daa8584c0e63862a709d03da0c7f3dee
Author: Jason Merrill 
Date:   Mon May 1 10:57:20 2023 -0400

c++: array DMI and member fn [PR109666]

Here it turns out I also needed to adjust cfun when stepping out of the
member function to instantiate the DMI.  But instead of adding that tweak,
let's unify with instantiate_body and just push_to_top_level instead of
trying to do the minimum subset of it.  There was no measurable change in
compile time on stdc++.h.

This should also resolve 109506 without yet another tweak.

PR c++/106890
PR c++/109666

gcc/cp/ChangeLog:

* name-lookup.cc (maybe_push_to_top_level)
(maybe_pop_from_top_level): Split out...
* pt.cc (instantiate_body): ...from here.
* init.cc (maybe_instantiate_nsdmi_init): Use them.
* name-lookup.h: Declare them..

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/nsdmi-array2.C: New test.
* g++.dg/cpp0x/nsdmi-template25.C: New test.

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

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:1cb272a8b1669e438aadf4a95da3979ac07ca9ce

commit r12-9812-g1cb272a8b1669e438aadf4a95da3979ac07ca9ce
Author: Jason Merrill 
Date:   Wed Jul 26 10:39:34 2023 -0400

c++: member vs global template [PR106310]

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

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

PR c++/106310

gcc/cp/ChangeLog:

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

gcc/testsuite/ChangeLog:

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

[Bug c++/109666] [12 Regression] Segmentation fault with std::array

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jason Merrill
:

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

commit r12-9811-gc4212c41daa8584c0e63862a709d03da0c7f3dee
Author: Jason Merrill 
Date:   Mon May 1 10:57:20 2023 -0400

c++: array DMI and member fn [PR109666]

Here it turns out I also needed to adjust cfun when stepping out of the
member function to instantiate the DMI.  But instead of adding that tweak,
let's unify with instantiate_body and just push_to_top_level instead of
trying to do the minimum subset of it.  There was no measurable change in
compile time on stdc++.h.

This should also resolve 109506 without yet another tweak.

PR c++/106890
PR c++/109666

gcc/cp/ChangeLog:

* name-lookup.cc (maybe_push_to_top_level)
(maybe_pop_from_top_level): Split out...
* pt.cc (instantiate_body): ...from here.
* init.cc (maybe_instantiate_nsdmi_init): Use them.
* name-lookup.h: Declare them..

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/nsdmi-array2.C: New test.
* g++.dg/cpp0x/nsdmi-template25.C: New test.

[Bug c++/108099] [12 Regression] ICE with type alias with `signed __int128_t`

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

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

--- Comment #30 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:50812881bbc1a78552682ae3a690bc0f512e762f

commit r12-9810-g50812881bbc1a78552682ae3a690bc0f512e762f
Author: Jason Merrill 
Date:   Tue Apr 18 21:32:07 2023 -0400

c++: fix 'unsigned typedef-name' extension [PR108099]

In the comments for PR108099 Jakub provided some testcases that
demonstrated
that even before the regression noted in the patch we were getting the
semantics of this extension wrong: in the unsigned case we weren't
producing
the corresponding standard unsigned type but another distinct one of the
same size, and in the signed case we were just dropping it on the floor and
not actually returning a signed type at all.

The former issue is fixed by using c_common_signed_or_unsigned_type instead
of unsigned_type_for, and the latter issue by adding a (signed_p &&
typedef_decl) case.

This patch introduces a failure on std/ranges/iota/max_size_type.cc due to
the latter issue, since the testcase expects 'signed rep_t' to do something
sensible, and previously we didn't.  Now that we do, it exposes a bug in
the
__max_diff_type::operator>>= handling of sign extension: when we evaluate
-1000 >> 2 in __max_diff_type we keep the MSB set, but leave the
second-most-significant bit cleared.

PR c++/108099

gcc/cp/ChangeLog:

* decl.cc (grokdeclarator): Don't clear typedef_decl after
'unsigned
typedef' pedwarn.  Use c_common_signed_or_unsigned_type.  Also
handle 'signed typedef'.

gcc/testsuite/ChangeLog:

* g++.dg/ext/int128-7.C: New test.
* g++.dg/ext/int128-8.C: New test.
* g++.dg/ext/unsigned-typedef2.C: New test.
* g++.dg/ext/unsigned-typedef3.C: New test.

[Bug c++/110997] New: [13/14 Regression] internal compiler error: in cxx_eval_constant_expression, at cp/constexpr.cc:8005

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

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

Bug ID: 110997
   Summary: [13/14 Regression] internal compiler error: in
cxx_eval_constant_expression, at cp/constexpr.cc:8005
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

While workin' on P2564 I found this ICE:

// P2564R3
// { dg-do compile { target c++20 } }
// From clang's cxx2b-consteval-propagate.cpp.  This test ICEd when I worked on
// P2564.

consteval int f (int);

struct S {
  int a = 0;
  int b = f (a);
};

constexpr bool
g (auto i)
{
  S s{i};
  return s.b == 2 *i;
}

consteval int
f (int i)
{
  return 2 * i;
}

void
test ()
{
  static_assert(g(42));
}


$ ./cc1plus -quiet -std=c++20 consteval-prop4.C
consteval-prop4.C: In instantiation of ‘constexpr bool g(auto:1) [with auto:1 =
int]’:
consteval-prop4.C:29:18:   required from here
consteval-prop4.C:16:5: internal compiler error: in
cxx_eval_constant_expression, at cp/constexpr.cc:8005
   16 |   S s{i};
  | ^
0xdb5f20 cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.cc:8005
0xdac220 cxx_eval_indirect_ref
/home/mpolacek/src/gcc/gcc/cp/constexpr.cc:5735
0xdb3a7a cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.cc:7471
0xda66a6 cxx_eval_component_reference
/home/mpolacek/src/gcc/gcc/cp/constexpr.cc:4363
0xdb4109 cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.cc:7644
0xd9bc4a cxx_bind_parameters_in_call
/home/mpolacek/src/gcc/gcc/cp/constexpr.cc:1830
0xda093c cxx_eval_call_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.cc:2926
0xdb2626 cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.cc:7196
0xdb8143 cxx_eval_outermost_constant_expr
/home/mpolacek/src/gcc/gcc/cp/constexpr.cc:8438
0xdb8dc8 cxx_constant_value(tree_node*, tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/constexpr.cc:8594
0x1133fda bot_replace
/home/mpolacek/src/gcc/gcc/cp/tree.cc:3302
0x1df1281 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/mpolacek/src/gcc/gcc/tree.cc:11341
0x113410d break_out_target_exprs(tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/tree.cc:3337
0xeca1b1 get_nsdmi(tree_node*, bool, int)
/home/mpolacek/src/gcc/gcc/cp/init.cc:693
0x1189148 process_init_constructor_record
/home/mpolacek/src/gcc/gcc/cp/typeck2.cc:1827
0x118a406 process_init_constructor
/home/mpolacek/src/gcc/gcc/cp/typeck2.cc:2094
0x11874da digest_init_r
/home/mpolacek/src/gcc/gcc/cp/typeck2.cc:1358
0x11876e9 digest_init_flags(tree_node*, tree_node*, int, int)
/home/mpolacek/src/gcc/gcc/cp/typeck2.cc:1404
0x11852ac store_init_value(tree_node*, tree_node*, vec**, int)
/home/mpolacek/src/gcc/gcc/cp/typeck2.cc:848
0xe4f3af check_initializer
/home/mpolacek/src/gcc/gcc/cp/decl.cc:7595

[Bug c++/85282] CWG 727 (full specialization in non-namespace scope)

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jozef.kosoru at pobox dot sk

--- Comment #18 from Jason Merrill  ---
*** Bug 8665 has been marked as a duplicate of this bug. ***

[Bug c++/8665] [DR727] explicit specialization of the member class template of a class template

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

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

Jason Merrill  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|REOPENED|RESOLVED

--- Comment #6 from Jason Merrill  ---
Ah, there's already a PR specifically about DR727.

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

[Bug c++/8665] [DR727] explicit specialization of the member class template of a class template

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

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

Jason Merrill  changed:

   What|Removed |Added

Summary|explicit specialization of  |[DR727] explicit
   |the member class template   |specialization of the
   |of a class template |member class template of a
   ||class template
 CC||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #5 from Jason Merrill  ---
This was made valid in C++17 (and retroactively) by CWG727.

[Bug c++/106094] Lifetime extension of temporary do not obey some rules of [class.temporary]

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

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
 CC||jason at gcc dot gnu.org
   Last reconfirmed||2023-08-11
 Ever confirmed|0   |1

--- Comment #5 from Jason Merrill  ---
Confirmed.

[Bug c++/106094] Lifetime extension of temporary do not obey some rules of [class.temporary]

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

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

Bug 53288 Summary: [C++11] Lifetime of temporary object backing 
pointer-to-member expression not extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53288

   What|Removed |Added

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

[Bug c++/53288] [C++11] Lifetime of temporary object backing pointer-to-member expression not extended

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed for GCC 13.

[Bug c++/81420] When a reference is bound to a member in the base of a temporary, lifetime of the temporary is not extended

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
(In reply to Ion Lupascu from comment #7)
> Not really, The issue still persists
> 
> std::optional getValue(){
...
> const double  = *getValue();
...
> const double  = getValue()->v;

Neither of these bind the reference to a prvalue; std::optional operator*
returns a reference, and operator-> returns a pointer, so in both cases we're
binding the reference to an xvalue, and GCC is correct not to extend the
temporary.

Fixed in 8.2.

[Bug c++/107687] [C++23] P2564 - consteval needs to propagate up

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

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

--- Comment #2 from Marek Polacek  ---
I don't understand why clang++ doesn't error here:

--
consteval int id(int i) { return i; }

template
constexpr int
f (T t)
{
  auto p = id; // immediate-escalating expr
  return t;
}

auto q = ; // error?
--

I though naming 'id' should promote f to consteval and therefore you can't
take its address.

[Bug c++/108468] [11 Regression] ICE in most_specialized_partial_spec/builtin_guide_p in C++20 mode

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed in 11.4/12.3/13.

[Bug c++/105406] [11 Regression] coroutines: since 11.3 co_await attempts to copy a move-only value when await_transform(T &) exists

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed in 11.4/12.3/13.

[Bug c++/109506] [11/12 regression] -fchecking=2 causes some template constructor not be instantiated when used with NSDMI

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
   Target Milestone|11.5|13.2
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #14 from Jason Merrill  ---
No need to backport fixes for -fchecking mode.

[Bug c++/110349] [C++26] P2169R4 - Placeholder variables with no name

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

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

--- Comment #3 from Jason Merrill  ---
Yeah, we don't want to give errors in lookup_name, pretty much for the reasons
you found.  cp_parser_lookup_name gives an ambiguity error when lookup_name
returns a TREE_LIST, so I think it makes sense to represent the case of
multiple _ declarations as a TREE_LIST rather than OVERLOAD.  Then I think you
don't need PLACEHOLDER_AMBIGUOUS_BINDING_P because you can see that from the
binding being a TREE_LIST.

I think find_last_decl should return nothing for a name-independent decl, and
give up on a TREE_LIST.

[Bug libstdc++/88322] Implement C++20 library features.

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

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

Bug 104167 Summary: Implement C++20 std::chrono::utc_clock, std::chrono::tzdb 
etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104167

   What|Removed |Added

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

[Bug libstdc++/110357] [C++26] P2592R3 Hashing support for std::chrono value classes

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

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

Bug 104167 Summary: Implement C++20 std::chrono::utc_clock, std::chrono::tzdb 
etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104167

   What|Removed |Added

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

[Bug libstdc++/104167] Implement C++20 std::chrono::utc_clock, std::chrono::tzdb etc.

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Fixed for GCC 14

[Bug libstdc++/104167] Implement C++20 std::chrono::utc_clock, std::chrono::tzdb etc.

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

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

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

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

commit r14-3165-gce6c4d3b4d336493cab128795467d832cb04c9ee
Author: Jonathan Wakely 
Date:   Fri Jul 21 17:19:08 2023 +0100

libstdc++: Implement C++20 std::chrono::parse [PR104167]

This adds the missing C++20 features to .

I've implemented my proposed resolutions to LWG issues 3960, 3961, and
3962. There are some unimplemented flags such as %OI which I think are
not implementable in general. It might be possible to use na_llanginfo
with ALT_DIGITS, but that isn't available on all targets. I intend to
file another LWG issue about that.

libstdc++-v3/ChangeLog:

PR libstdc++/104167
* include/bits/chrono_io.h (operator|=, operator|): Add noexcept
to _ChronoParts operators.
(from_stream, parse): Define new functions.
(__detail::_Parse, __detail::_Parser): New class templates.
* include/std/chrono (__cpp_lib_chrono): Define to 201907L for
C++20.
* include/std/version (__cpp_lib_chrono): Likewise.
* testsuite/20_util/duration/arithmetic/constexpr_c++17.cc:
Adjust expected value of feature test macro.
* testsuite/20_util/duration/io.cc: Test parsing.
* testsuite/std/time/clock/file/io.cc: Likewise.
* testsuite/std/time/clock/gps/io.cc: Likewise.
* testsuite/std/time/clock/system/io.cc: Likewise.
* testsuite/std/time/clock/tai/io.cc: Likewise.
* testsuite/std/time/clock/utc/io.cc: Likewise.
* testsuite/std/time/day/io.cc: Likewise.
* testsuite/std/time/month/io.cc: Likewise.
* testsuite/std/time/month_day/io.cc: Likewise.
* testsuite/std/time/weekday/io.cc: Likewise.
* testsuite/std/time/year/io.cc: Likewise.
* testsuite/std/time/year_month/io.cc: Likewise.
* testsuite/std/time/year_month_day/io.cc: Likewise.
* testsuite/std/time/syn_c++20.cc: Check value of macro and for
the existence of parse and from_stream in namespace chrono.
* testsuite/std/time/clock/local/io.cc: New test.
* testsuite/std/time/parse.cc: New test.

[Bug c++/55918] Stack partially unwound when noexcept causes call to std::terminate

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
As discussed on PR97720, I think we could address this by changing noexcept
regions to be represented as exception-specifications in the action table, and
for C++17 and up using a different personality routine that knows that
exception-specifications are noexcept.

[Bug tree-optimization/110992] [14 Regression] Dead Code Elimination Regression at -O3 since r14-1654-g7ceed7e3e29

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 Ever confirmed|0   |1
   Last reconfirmed||2023-08-11
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed the problem is ethread is not able to do the jump threading with the
new IR:
```
Checking profitability of path (backwards):  bb:3 (3 insns) bb:2
  Control statement insns: 2
  Overall: 1 insns

 Registering killing_def (path_oracle) b.0_1
 Registering killing_def (path_oracle) _7
 Registering killing_def (path_oracle) _6
 Registering killing_def (path_oracle) _25
 Registering killing_def (path_oracle) _3
 Registering killing_def (path_oracle) c.1_2
path: 2->3->xx REJECTED
```

I don't understand why though ...

[Bug analyzer/107646] RFE: can we reimplement gcc-python-plugin's cpychecker as a -fanalyzer plugin?

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Eric Feng :

https://gcc.gnu.org/g:38c00edd65c39b07166aa0913c79adb9bcac943c

commit r14-3162-g38c00edd65c39b07166aa0913c79adb9bcac943c
Author: Eric Feng 
Date:   Fri Aug 11 12:30:43 2023 -0400

analyzer: More features for CPython analyzer plugin [PR107646]

This patch adds known function subclasses for Python/C API functions
PyList_New, PyLong_FromLong, and PyList_Append. It also adds new
optional parameters for
region_model::get_or_create_region_for_heap_alloc, allowing for the
newly allocated region to immediately transition from the start state to
the assumed non-null state in the malloc state machine if desired.
Finally, it adds a new procedure, dg-require-python-h, intended as a
directive in Python-related analyzer tests, to append necessary Python
flags during the tests' build process.

The main warnings we gain in this patch with respect to the known function
subclasses mentioned are leak related. For example:

rc3.c: In function âcreate_py_objectâ:
â
rc3.c:21:10: warning: leak of âitemâ [CWE-401] [-Wanalyzer-malloc-leak]
â
   21 |   return list;
  â
  |  ^~~~
â
  âcreate_py_objectâ: events 1-4
â
|
â
|4 |   PyObject* item = PyLong_FromLong(10);
â
|  |^~~
â
|  ||
â
|  |(1) allocated here
â
|  |(2) when âPyLong_FromLongâ succeeds
â
|5 |   PyObject* list = PyList_New(2);
â
|  |~
â
|  ||
â
|  |(3) when âPyList_Newâ fails
â
|..
â
|   21 |   return list;
â
|  |  
â
|  |  |
â
|  |  (4) âitemâ leaks here; was allocated at (1)
â

Some concessions were made to
simplify the analysis process when comparing kf_PyList_Append with the
real implementation. In particular, PyList_Append performs some
optimization internally to try and avoid calls to realloc if
possible. For simplicity, we assume that realloc is called every time.
Also, we grow the size by just 1 (to ensure enough space for adding a
new element) rather than abide by the heuristics that the actual
implementation
follows.

gcc/analyzer/ChangeLog:
PR analyzer/107646
* call-details.h: New function.
* region-model.cc
(region_model::get_or_create_region_for_heap_alloc):
New optional parameters.
* region-model.h (class region_model): New optional parameters.
* sm-malloc.cc (on_realloc_with_move): New function.
(region_model::transition_ptr_sval_non_null): New function.

gcc/testsuite/ChangeLog:
PR analyzer/107646
* gcc.dg/plugin/analyzer_cpython_plugin.c: Analyzer support for
PyList_New, PyList_Append, PyLong_FromLong
* gcc.dg/plugin/plugin.exp: New test.
* lib/target-supports.exp: New procedure.
* gcc.dg/plugin/cpython-plugin-test-2.c: New test.

Signed-off-by: Eric Feng 

[Bug c++/71954] template partial specialization for constexpr error

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

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

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
 Resolution|--- |FIXED
   Target Milestone|--- |14.0
 Status|NEW |RESOLVED

--- Comment #9 from Patrick Palka  ---
Fixed for GCC 14.

[Bug c++/110927] GCC fails to parse dependent type in concept through partial specialization

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

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

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

https://gcc.gnu.org/g:63bd36be990f3b08fcee5b69718ef97c055fbb31

commit r14-3161-g63bd36be990f3b08fcee5b69718ef97c055fbb31
Author: Patrick Palka 
Date:   Fri Aug 11 13:26:02 2023 -0400

c++: dependently scoped template-id in type-req [PR110927]

Here we're incorrectly rejecting the first type-requirement at parse
time with

  concepts-requires35.C:14:56: error: âtypename A::Bâ is not a
template [-fpermissive]

We also incorrectly reject the second type-requirement at satisfaction time
with

  concepts-requires35.C:17:34: error: âtypename A::Bâ names
âtemplate struct A::Bâ, which is not a type

and similarly for the third type-requirement.  This seems to happen only
within a type-requirement; if we instead use e.g. an alias template then
it works as expected.

The difference ultimately seems to be that during parsing of a using-decl,
we pass check_dependency_p=true to cp_parser_nested_name_specifier_opt
whereas for a type-requirement we pass check_dependency_p=false.
Passing =false causes cp_parser_template_id for the dependently-scoped
template-id B to create a TYPE_DECL of TYPENAME_TYPE (with
TYPENAME_IS_CLASS_P unexpectedly set in the last two cases) whereas
passing =true causes it to return a TEMPLATE_ID_EXPR.  We then call
make_typename_type on this TYPE_DECL which does the wrong thing.

Since there seems to be no justification for using check_dependency_p=false
here, the simplest fix seems to be to pass check_dependency_p=true instead,
matching the behavior of cp_parser_elaborated_type_specifier.

PR c++/110927

gcc/cp/ChangeLog:

* parser.cc (cp_parser_type_requirement): Pass
check_dependency_p=true instead of =false.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-requires35.C: New test.

[Bug c++/71954] template partial specialization for constexpr error

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

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

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

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

commit r14-3160-gca2676654736e6b0bd1ba88edf5694df43718cd9
Author: Patrick Palka 
Date:   Fri Aug 11 13:25:58 2023 -0400

c++: recognize in-class var tmpl partial spec [PR71954]

This makes us recognize member variable template partial specializations
defined directly inside the class body.  It seems we mainly just need to
call check_explicit_specialization when we see a static TEMPLATE_ID_EXPR
data member, which sets SET_DECL_TEMPLATE_SPECIALIZATION for us and which
we otherwise don't call (for the out-of-class case we call it from
grokvardecl).

We also need to make finish_member_template_decl return NULL_TREE for
such partial specializations, matching its behavior for class template
partial specializations, so that later we don't try to register it as a
separate member declaration.

PR c++/71954

gcc/cp/ChangeLog:

* decl.cc (grokdeclarator): Pass 'dname' instead of
'unqualified_id' as the name when building the VAR_DECL for a
static data member.  Call check_explicit_specialization for a
TEMPLATE_ID_EXPR such member.
* pt.cc (finish_member_template_decl): Return NULL_TREE
instead of 'decl' when DECL_TEMPLATE_SPECIALIZATION is not
set.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/var-templ84.C: New test.
* g++.dg/cpp1y/var-templ84a.C: New test.

[Bug c++/60027] [DR1228] Problem with braced-init-lists and explicit ctors

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

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

--- Comment #10 from Jason Merrill  ---
Note that for PR109247 I've changed how this is handled in the case of using
the explicit constructor to initialize the argument of a copy/move constructor
or op=, which should make some of the duplicates work.

[Bug libstdc++/110860] std::format("{:f}",2e304) invokes undefined behaviour

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

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

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

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

commit r14-3159-g9e33d71834416b7eddadae2b0f68e85f04cd0c7f
Author: Jonathan Wakely 
Date:   Fri Aug 11 18:10:29 2023 +0100

libstdc++: Do not call log10(0.0) in std::format [PR110860]

Calling log10(0.0) returns -inf which has undefined behaviour when
converted to an integer. We only need to use log10 for large values
anyway. If the value is zero then the larger buffer is only needed due
to a large precision, so we don't need to use log10 to estimate the
number of digits for the significand.

libstdc++-v3/ChangeLog:

PR libstdc++/110860
* include/std/format (__formatter_fp::format): Do not call log10
with zero values.

[Bug libstdc++/110860] std::format("{:f}",2e304) invokes undefined behaviour

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

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

--- Comment #10 from Jonathan Wakely  ---
GCC's ubsan doesn't seem to diagnose this rule:

"A prvalue of a floating-point type can be converted to a prvalue of an integer
type. The conversion truncates; that is, the fractional part is discarded. The
behavior is undefined if the truncated value cannot be represented in the
destination type."

There's no ubsan diagnostic for:

unsigned long i = -HUGE_VAL;

So it doesn't complain about adding log10(0) to a size_t.

I can reproduce it with Clang though, and have tested a fix.

[Bug libstdc++/110990] `format_to_n` returns wrong value

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |13.3
   Last reconfirmed||2023-08-11
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Jonathan Wakely  ---
Hmm, apparently I only tested cases where format_to_n truncates the output, not
where it fits!

[Bug c++/85873] [8/9 regression] GCC omits array constant in .rodata causing a segmentation fault.

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

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

--- Comment #8 from Jason Merrill  ---
(In reply to Jason Merrill from comment #7)
> It does seem wrong that a constexpr function can't define a constexpr static
> local variable.

Incidentally, this was fixed for C++23 by P2647, implemented in GCC 13.

[Bug fortran/110996] New: RISC-V vector Fortran: SEGV ICE during parsing

[jeremy.bennett at embecosm dot com via Gcc-bugs]

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

Bug ID: 110996
   Summary: RISC-V vector Fortran: SEGV ICE during parsing
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeremy.bennett at embecosm dot com
  Target Milestone: ---

Created attachment 55726
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55726=edit
Fortran 90 source code for the test case

This appears to be a failure in the Fortran parser, which only occurs if the
RISC-V vector ISA extension is specified.

This is the reproducer (testcase.f90):

  CONTAINS
   SUBROUTINE a
   END
   SUBROUTINE b
   END
   SUBROUTINE c(d) e
SUBROUTINE f
  END
END

(which has a syntax error with the stray "e" at the end of the declaration of
"SUBROUTINE c").

This is compiled with:

riscv64-unknown-linux-gnu-gfortran -march=rv64gcv -mabi=lp64d -c \
-Ofast testcase.f90

NOTE. The error only occurs if the "v" extensions is specified in the "-march"
string.

The output is:

testcase.f90:6:20:

6 |SUBROUTINE c(d) e
  |1
Error: Syntax error in SUBROUTINE statement at (1)
f951: internal compiler error: Segmentation fault
0x112a263 crash_signal
/home/jeremy/gittrees/mustang/gcc/gcc/toplev.cc:314
0x7fdd1203c4af ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xaaea0a resolve_symbol
/home/jeremy/gittrees/mustang/gcc/gcc/fortran/resolve.cc:16643
0xadadc2 do_traverse_symtree
/home/jeremy/gittrees/mustang/gcc/gcc/fortran/symbol.cc:4190
0xab95ed resolve_types
/home/jeremy/gittrees/mustang/gcc/gcc/fortran/resolve.cc:17963
0xab9697 resolve_types
/home/jeremy/gittrees/mustang/gcc/gcc/fortran/resolve.cc:17977
0xac08ec gfc_resolve(gfc_namespace*)
/home/jeremy/gittrees/mustang/gcc/gcc/fortran/resolve.cc:18083
0xa9f250 resolve_all_program_units
/home/jeremy/gittrees/mustang/gcc/gcc/fortran/parse.cc:6909
0xa9f250 gfc_parse_file()
/home/jeremy/gittrees/mustang/gcc/gcc/fortran/parse.cc:7165
0xaf3533 gfc_be_parse_file
/home/jeremy/gittrees/mustang/gcc/gcc/fortran/f95-lang.cc:229
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

System information
--

Using built-in specs.
COLLECT_GCC=riscv64-unknown-linux-gnu-gfortran
COLLECT_LTO_WRAPPER=/home/jeremy/gittrees/mustang/install/libexec/gcc/riscv64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /home/jeremy/gittrees/mustang/gcc/configure
--target=riscv64-unknown-linux-gnu
--prefix=/home/jeremy/gittrees/mustang/install
--with-sysroot=/home/jeremy/gittrees/mustang/install/sysroot
--with-pkgversion=g68783211f66 --with-system-zlib --enable-shared --enable-tls
--enable-languages=c,c++,fortran --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap
--src=/home/jeremy/gittrees/mustang/gcc --enable-multilib --with-abi=lp64d
--with-arch=rv64gc --with-tune= --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2
   -mcmodel=medany' 'CXXFLAGS_FOR_TARGET=-O2-mcmodel=medany'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230811 (experimental) (g68783211f66)

[Bug tree-optimization/110991] [14 Regression] Dead Code Elimination Regression at -O2 since r14-1135-gc53f51005de

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-08-11

--- Comment #1 from Uroš Bizjak  ---
For gcc-13, fre4 pass is able to simplify the scalar code, but nothing
simplifies vectorized code in gcc-14.

[Bug bootstrap/110646] [14 Regression] gensupport.cc:643:18: error: 'stoi' is not a member of 'std'

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #6 from John David Anglin  ---
Fixed.

[Bug c/107954] Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #5 from joseph at codesourcery dot com  ---
The straw poll at the June meeting said to keep calling it C23 (votes 
4/12/2 for/against/abstain on the question of changing the informal name 
to C24).  Of course the actual standard will be ISO/IEC 9899:2024 (but 
__STDC_VERSION__ will remain as 202311L, consistent with the informal name 
rather than the publication date, in the absence of a technical DIS 
comment requesting a change of version number being accepted, and 
accepting any technical DIS comments would delay the standard by requiring 
an FDIS).

[Bug bootstrap/110646] [14 Regression] gensupport.cc:643:18: error: 'stoi' is not a member of 'std'

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

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

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

https://gcc.gnu.org/g:834d1422c2e056f483542f1aff2cfc211bfcc748

commit r14-3155-g834d1422c2e056f483542f1aff2cfc211bfcc748
Author: John David Anglin 
Date:   Fri Aug 11 15:44:37 2023 +

Use strtol instead of std::stoi [PR110646]

Implementation of std::stoi was overlooked on hppa-hpux, so use
strtol instead.

2023-08-11  John David Anglin  

gcc/ChangeLog:

PR bootstrap/110646
* gensupport.cc(class conlist): Use strtol instead of std::stoi.

[Bug libstdc++/110970] clang / c++23 missing 'typename' prior to dependent type name 'iterator_traits<_It>::iterator_category'

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Fixed for 13.3, thanks for the report.

[Bug libstdc++/110970] clang / c++23 missing 'typename' prior to dependent type name 'iterator_traits<_It>::iterator_category'

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:2e094543715fbd1a5486d77dcbfeec52d86aba61

commit r13-7710-g2e094543715fbd1a5486d77dcbfeec52d86aba61
Author: Jonathan Wakely 
Date:   Thu Aug 10 13:48:48 2023 +0100

libstdc++: Use alias template for iterator_category [PR110970]

This renames __iterator_category_t to __iter_category_t, for consistency
with std::iter_value_t, std::iter_difference_t and std::iter_reference_t
in C++20. Then use __iter_category_t in , which
fixes the problem of the missing 'typename' that Clang 15 incorrectly
still requires.

libstdc++-v3/ChangeLog:

PR libstdc++/110970
* include/bits/stl_iterator.h (__detail::__move_iter_cat): Use
__iter_category_t.
(iterator_traits>::_S_iter_cat): Likewise.
(__detail::__basic_const_iterator_iter_cat): Likewise.
* include/bits/stl_iterator_base_types.h (__iterator_category_t):
Rename to __iter_category_t.

(cherry picked from commit 9cb2a7c8d54b1f6685bc509a07104c458262cb9f)

[Bug c++/110349] [C++26] P2169R4 - Placeholder variables with no name

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

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

I've played with this a little bit so far, but am a little bit stuck.
When lookup_name reports error on ambiguous _ because 2+ declarations with the
_ name are in the same scope (counting function overloads as one obviously),
the error is reported too many times, even from tentative parsing.
And also unsure if it should return error_mark_node in that case or not, if I
return error_mark_node I get some extra error recovery errors as well (though
if the error is avoided during tentative parsing, I guess we have to return
error_mark_node in that case.

[Bug libgcc/110956] [13/14 regression] gcc_assert is hit at gcc-13.2.0/libgcc/unwind-dw2-fde.c#L291 with some special library

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Jeff Law :

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

commit r13-7709-gab8fed849ab345974e5b83472749ac1393878f71
Author: Thomas Neumann 
Date:   Fri Aug 11 09:20:27 2023 -0600

preserve base pointer for __deregister_frame [PR110956]

Original bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
Rainer Orth successfully tested the patch on Solaris with a full bootstrap.

Some uncommon unwinding table encodings need to access the base pointer
for address computations. We do not have that information in calls to
__deregister_frame_info_bases, and previously simply used nullptr as
base pointer. That is usually fine, but for some Solaris i386 shared
libraries that results in wrong address computations.

To fix this problem we now associate the unwinding object with
the table pointer itself, which is always known, in addition to
the PC range. When deregistering a frame, we first locate the object
using the table pointer, and then use the base pointer stored within
the object to compute the PC range.

libgcc/ChangeLog:
PR libgcc/110956
* unwind-dw2-fde.c: Associate object with address of unwinding
table.

[Bug libgcc/110956] [13/14 regression] gcc_assert is hit at gcc-13.2.0/libgcc/unwind-dw2-fde.c#L291 with some special library

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Jeff Law :

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

commit r14-3154-gc46bded78f3733ad1312d141ebf1ae541032a48b
Author: Thomas Neumann 
Date:   Fri Aug 11 09:20:27 2023 -0600

preserve base pointer for __deregister_frame [PR110956]

Original bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
Rainer Orth successfully tested the patch on Solaris with a full bootstrap.

Some uncommon unwinding table encodings need to access the base pointer
for address computations. We do not have that information in calls to
__deregister_frame_info_bases, and previously simply used nullptr as
base pointer. That is usually fine, but for some Solaris i386 shared
libraries that results in wrong address computations.

To fix this problem we now associate the unwinding object with
the table pointer itself, which is always known, in addition to
the PC range. When deregistering a frame, we first locate the object
using the table pointer, and then use the base pointer stored within
the object to compute the PC range.

libgcc/ChangeLog:
PR libgcc/110956
* unwind-dw2-fde.c: Associate object with address of unwinding
table.

[Bug fortran/110995] New: segfault for function in declaration of module function

[thod_ at gmx dot de via Gcc-bugs]

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

Bug ID: 110995
   Summary: segfault for function in declaration of module
function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thod_ at gmx dot de
  Target Milestone: ---

Created attachment 55724
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55724=edit
Test code

In this example (which looks a bit strange in its minimalistic form), gfortran
(in all versions that I have access to, i.e. on SUSE 7.5.0, 12.3.0, 13.2.1)
fails with segfault. The example works with ifort and if the function is
charArrToString_ is used in the main program instead of charArrToString in the
module - or alternatively
  character(len = lenCharArr(data)) :: charArrToString
is changed to
  character(len = size(data)) :: charArrToString
in the module function charArrToString.

Steps to reproduce (str.f90 attached):
$ gfortran str.f90

Output:
str.f90:38:48:

   38 |   write(*,*) "write module-", charArrToString(c), "-"
  |1
interner Compiler-Fehler: Speicherzugriffsfehler
0x10f0b1a internal_error(char const*, ...)
???:0
0x11d4bb7 size_binop_loc(unsigned int, tree_code, tree_node*, tree_node*)
???:0
0x12371ca get_inner_reference(tree_node*, poly_int_pod<1u, long>*,
poly_int_pod<1u, long>*, tree_node**, machine_mode*, int*, int*, int*)
???:0
0x11dfcbe fold_unary_loc(unsigned int, tree_code, tree_node*, tree_node*)
???:0
0x11df5ac fold_build1_loc(unsigned int, tree_code, tree_node*, tree_node*)
???:0
0x19c436f convert(tree_node*, tree_node*)
???:0
0x19e045c gfc_get_dataptr_offset(stmtblock_t*, tree_node*, tree_node*,
tree_node*, bool, gfc_expr*)
???:0
0x19ea313 gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
???:0
0x19f3ab5 gfc_conv_array_parameter(gfc_se*, gfc_expr*, bool, gfc_symbol const*,
char const*, tree_node**)
???:0
0x1a240e0 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
???:0
0x1a1217e gfc_apply_interface_mapping(gfc_interface_mapping*, gfc_se*,
gfc_expr*)
???:0
0x1a26696 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
???:0
0x1a4940a gfc_conv_expr_reference(gfc_se*, gfc_expr*)
???:0
0x1a63c99 gfc_trans_transfer(gfc_code*)
???:0
0x1a1c127 gfc_generate_function_code(gfc_namespace*)
???:0
0x1986404 gfc_parse_file()
???:0

Version info:
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Ziel: x86_64-suse-linux
Konfiguriert mit: ../configure CFLAGS=' -O2 -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g'
CXXFLAGS=' -O2 -funwind-tables -fasynchronous-unwind-tables
-fstack-clash-protection -Werror=return-type -g' XCFLAGS=' -O2 -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g'
TCFLAGS=' -O2 -funwind-tables -fasynchronous-unwind-tables
-fstack-clash-protection -Werror=return-type -g' GDCFLAGS=' -O2 -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection -g' --prefix=/usr
--infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64
--libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d,jit,m2
--enable-offload-targets=nvptx-none,amdgcn-amdhsa, --enable-offload-defaulted
--without-cuda-driver --enable-host-shared --enable-checking=release
--disable-werror --with-gxx-include-dir=/usr/include/c++/13
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --enable-ssp --disable-libssp
--disable-libvtv --enable-cet=auto --disable-libcc1 --enable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-13 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic
--with-build-config=bootstrap-lto-lean --enable-link-serialization
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread-Modell: posix
Unterstützte LTO-Kompressionsalgorithmen: zlib zstd
gcc-Version 13.2.1 20230803 [revision cc279d6c64562f05019e1d12d0d825f9391b5553]
(SUSE Linux)

[Bug middle-end/110994] New: RISC-V Fortran: Illegal instruction ICE with scalable autovec

[jeremy.bennett at embecosm dot com via Gcc-bugs]

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

Bug ID: 110994
   Summary: RISC-V Fortran: Illegal instruction ICE with scalable
autovec
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeremy.bennett at embecosm dot com
  Target Milestone: ---

Created attachment 55723
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55723=edit
Fortran 90 source code of the test case

Discovered by accident when hunting down a RVV bug, but this appears to be
connected with the autovectorizer generically rather than specifically the
RISC-V vector ISA extension.

The following code (testcase.f90) causes an ICE when using RISC-V as target
with
--param=riscv-autovec-preference=scalable.

SUBROUTINE d(e) f

(this is invalid Fortran 90, but it should still not trigger an ICE)

Compiled with:

riscv64-unknown-linux-gnu-gfortran -march=rv64gc -mabi=lp64d -c \
-Ofast --param=riscv-autovec-preference=scalable testcase.f90

Output is:

f951: internal compiler error: Illegal instruction
0x112a263 crash_signal
/home/jeremy/gittrees/mustang/gcc/gcc/toplev.cc:314
0x7f0d57e3c4af ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x9342a9 poly_int_pod<2u, unsigned short>::to_constant() const
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv.cc:6565
0x9342a9 riscv_hard_regno_nregs
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv.cc:6578
0x1092519 init_reg_modes_target()
/home/jeremy/gittrees/mustang/gcc/gcc/reginfo.cc:466
0xd00827 init_emit_regs()
/home/jeremy/gittrees/mustang/gcc/gcc/emit-rtl.cc:6072
0x9e6058 backend_init
/home/jeremy/gittrees/mustang/gcc/gcc/toplev.cc:1749
0x9e6058 do_compile
/home/jeremy/gittrees/mustang/gcc/gcc/toplev.cc:2108
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

System information
--

Using built-in specs.
COLLECT_GCC=riscv64-unknown-linux-gnu-gfortran
COLLECT_LTO_WRAPPER=/home/jeremy/gittrees/mustang/install/libexec/gcc/riscv64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /home/jeremy/gittrees/mustang/gcc/configure
--target=riscv64-unknown-linux-gnu
--prefix=/home/jeremy/gittrees/mustang/install
--with-sysroot=/home/jeremy/gittrees/mustang/install/sysroot
--with-pkgversion=g68783211f66 --with-system-zlib --enable-shared --enable-tls
--enable-languages=c,c++,fortran --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap
--src=/home/jeremy/gittrees/mustang/gcc --enable-multilib --with-abi=lp64d
--with-arch=rv64gc --with-tune= --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2
   -mcmodel=medany' 'CXXFLAGS_FOR_TARGET=-O2-mcmodel=medany'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230811 (experimental) (g68783211f66)

[Bug fortran/110993] New: Possibly bogus diagnostic on renamed interface import

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

Bug ID: 110993
   Summary: Possibly bogus diagnostic on renamed interface import
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rimvydas.jas at gmail dot com
  Target Milestone: ---

Spotted while checking why someone was manually mangling names with bind(c).
$ cat foo.f90
module intfb_pack
  interface
!subroutine bar(x) bind(c, name="bar_") ! does not warn
!subroutine bar(x) bind(c, name="bar") ! Error: More actual than formal
arguments in procedure call
subroutine bar(x) ! Warning: Shape mismatch in argument 'x'
  use iso_c_binding, only : c_float
  implicit none
  real(c_float) :: x(45)
end subroutine
  end interface
end module

subroutine foo(x)
  use intfb_pack, notthisone => bar
  implicit none
  real :: x(3)
  call bar(x)
end subroutine

$ gfortran -c foo.f90
foo.f90:17:13:

   14 |   use intfb_pack, notthisone => bar
  |  2
..
   17 |   call bar(x)
  | 1
Warning: Shape mismatch in argument 'x' between (1) and (2)

The diagnostic is a bit surprising given that selective import with "use
intfb_pack, only:" does not emit diagnostics.  Moreover, the "bind(c,
name="bar")" case hard error seems very wrong.

[Bug rtl-optimization/110939] [14 Regression] 14.0 ICE at rtl.h:2297 while bootstrapping on loongarch64

[stefansf at linux dot ibm.com via Gcc-bugs]

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

--- Comment #11 from Stefan Schulze Frielinghaus  ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627024.html

[Bug middle-end/110973] 9% 444.namd regression between g:c2a447d840476dbd (2023-08-03 18:47) and g:73da34a538ddc2ad (2023-08-09 20:17)

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-08-11
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
For generic the biggest difference is in calc_pair_energy_fullelect:

Samples: 1M of event 'cycles', Event count (approx.): 678752091 
Overhead   Samples  Command  Shared Object Symbol   
   6.68%132170  namd_peak.amd64  namd_peak.amd64-m64-mine  [.]
ComputeNonbondedUtil::calc_pair_energy_fullelect #
   6.16%121796  namd_base.amd64  namd_base.amd64-m64-mine  [.]
ComputeNonbondedUtil::calc_pair_fullelect#
   6.16%121875  namd_peak.amd64  namd_peak.amd64-m64-mine  [.]
ComputeNonbondedUtil::calc_pair_fullelect#
   5.98%118457  namd_base.amd64  namd_base.amd64-m64-mine  [.]
ComputeNonbondedUtil::calc_pair_energy_fullelect #
   5.33%105302  namd_peak.amd64  namd_peak.amd64-m64-mine  [.]
ComputeNonbondedUtil::calc_pair  #
   5.19%102880  namd_peak.amd64  namd_peak.amd64-m64-mine  [.]
ComputeNonbondedUtil::calc_pair_energy   #
   5.15%101892  namd_base.amd64  namd_base.amd64-m64-mine  [.]
ComputeNonbondedUtil::calc_pair_energy_merge_fullelect   #
   5.15%102119  namd_peak.amd64  namd_peak.amd64-m64-mine  [.]
ComputeNonbondedUtil::calc_pair_energy_merge_fullelect   #
   5.02% 99415  namd_base.amd64  namd_base.amd64-m64-mine  [.]
ComputeNonbondedUtil::calc_pair_energy   #
   5.00% 98964  namd_peak.amd64  namd_peak.amd64-m64-mine  [.]
ComputeNonbondedUtil::calc_pair_merge_fullelect  #
   4.98% 98257  namd_base.amd64  namd_base.amd64-m64-mine  [.]
ComputeNonbondedUtil::calc_pair  #
   4.90% 96943  namd_base.amd64  namd_base.amd64-m64-mine  [.]
ComputeNonbondedUtil::calc_pair_merge_fullelect

it's again very difficult to pin-point an offender :/

Re: [Predicated Ins vs Branches] O3 and PGO result in 2x performance drop relative to O2

[Changbin Du via Gcc-bugs]

On Mon, Jul 31, 2023 at 08:55:35PM +0800, Changbin Du wrote:
> Hello, folks.
> This is to discuss Gcc's heuristic strategy about Predicated Instructions and
> Branches. And probably something needs to be improved.
> 
> [The story]
> Weeks ago, I built a huffman encoding program with O2, O3, and PGO 
> respectively.
> This program is nothing special, just a random code I found on the internet. 
> You
> can download it from http://cau.ac.kr/~bongbong/dsd08/huffman.c.
> 
> Build it with O2/O3/PGO (My GCC is 13.1):
> $ gcc -O2 -march=native -g -o huffman huffman.c
> $ gcc -O3 -march=native -g -o huffman.O3 huffman.c
> 
> $ gcc -O2 -march=native -g -fprofile-generate -o huffman.instrumented 
> huffman.c
> $ ./huffman.instrumented test.data
> $ gcc -O2 -march=native -g -fprofile-use=huffman.instrumented.gcda -o 
> huffman.pgo huffman.c
> 
> Run them on my 12900H laptop:
> $ head -c 50M /dev/urandom > test.data
> $ perf stat  -r3 --table -- taskset -c 0 ./huffman test.data
> $ perf stat  -r3 --table -- taskset -c 0 ./huffman.O3 test.data
> $ perf stat  -r3 --table -- taskset -c 0 ./huffman.pgo test.data
> 
> The result (p-core, no ht, no turbo, performance mode):
> 
> O2  O3  PGO
> cycles  2,581,832,749   8,638,401,568   9,394,200,585
> (1.07s) (3.49s) (3.80s)
> instructions12,609,600,094  11,827,675,782  12,036,010,638
> branches2,303,416,221   2,671,184,833   2,723,414,574
> branch-misses   0.00%   7.94%   8.84%
> cache-misses3,012,613   3,055,722   3,076,316
> L1-icache-load-misses   11,416,391  12,112,703  11,896,077
> icache_tag.stalls   1,553,521   1,364,092   1,896,066
> itlb_misses.stlb_hit6,856   21,756  22,600
> itlb_misses.walk_completed  14,430  4,454   15,084
> baclears.any131,573 140,355 131,644
> int_misc.clear_resteer_cycles   2,545,915   586,578,125 679,021,993
> machine_clears.count22,235  39,671  37,307
> dsb2mite_switches.penalty_cycles 6,985,838  12,929,675  8,405,493
> frontend_retired.any_dsb_miss   28,785,677  28,161,724  28,093,319
> idq.dsb_cycles_any  1,986,038,896   5,683,820,258   5,971,969,906
> idq.dsb_uops11,149,445,952  26,438,051,062  28,622,657,650
> idq.mite_uops   207,881,687 216,734,007 212,003,064
> 
> 
> Above data shows:
>   o O3/PGO lead to *2.3x/2.6x* performance drop than O2 respectively.
>   o O3/PGO reduced instructions by 6.2% and 4.5%. I think this attributes to
> aggressive inline.
>   o O3/PGO introduced very bad branch prediction. I will explain it later.
>   o Code built with O3 has high iTLB miss but much lower sTLB miss. This is 
> beyond
> my expectation.
>   o O3/PGO introduced 78% and 68% more machine clears. This is interesting and
> I don't know why. (subcategory MC is not measured yet)
>   o O3 has much higher dsb2mite_switches.penalty_cycles than O2/PGO.
>   o The idq.mite_uops of O3/PGO increased 4%, while idq.dsb_uops increased 2x.
> DSB hit well. So frontend fetching and decoding is not a problem for 
> O3/PGO.
>   o Other events are mainly affected by bad branch misprediction.
> 
> Additionally, here is the TMA level 2 analysis: The main changes in the 
> pipeline
> slots are of Bad Speculation and Frontend Bound categories. I doubt the 
> accuracy
> of tma_fetch_bandwidth according to above frontend_retired.any_dsb_miss and
> idq.mite_uops data.
> 
> $ perf stat --topdown --td-level=2 --cputype core -- taskset -c 0 ./huffman 
> test.data
> test.data.huf is 1.00% of test.data
> 
>  Performance counter stats for 'taskset -c 0 ./huffman test.data':
> 
>  %  tma_branch_mispredicts%  tma_core_bound %  tma_heavy_operations %  
> tma_light_operations  %  tma_memory_bound %  tma_fetch_bandwidth %  
> tma_fetch_latency %  tma_machine_clears
>0.0  0.8 11.4  
>76.8  2.0 8.3  
> 0.80.0
> 
>1.073381357 seconds time elapsed
> 
>0.945233000 seconds user
>0.095719000 seconds sys
> 
> 
> $ perf stat --topdown --td-level=2 --cputype core -- taskset -c 0 
> ./huffman.O3 test.data
> test.data.huf is 1.00% of test.data
> 
>  Performance counter stats for 'taskset -c 0 ./huffman.O3 test.data':
> 
>  %  tma_branch_mispredicts%  tma_core_bound %  tma_heavy_operations %  
> tma_light_operations  %  tma_memory_bound %  tma_fetch_bandwidth %  
> tma_fetch_latency %  tma_machine_clears
>   38.2  6.6  3.5  
>21.7  0.9  

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

[sumbera at volny dot cz via Gcc-bugs]

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

--- Comment #16 from Petr Sumbera  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #14)
> That's almost certainly due to Solaris still including LLVM 13, which is
> pretty old by now.  In particular, it lacks llvm::sys::getHostCPUName.
> My patch to implement this on SPARC only landed in LLVM 16.

LLVM update is quite complicated due Mesa dependency. But main update blocker
is now: https://bugzilla.mozilla.org/show_bug.cgi?id=1795899

[Bug middle-end/110973] 9% 444.namd regression between g:c2a447d840476dbd (2023-08-03 18:47) and g:73da34a538ddc2ad (2023-08-09 20:17)

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization,
   ||needs-bisection
 Target||x86_64-*-*
 CC||rguenth at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=110972

--- Comment #1 from Richard Biener  ---
Probably the same cause as PR110972, but I can only confirm a 2.5% regression
on Zen2 due to r14-3078-gd9f3ea61fe36e2.  Looks like the bigger regression was
for generic?  I can confirm a 5.5% regression for -Ofast generic on Zen2 due to
r14-3078-gd9f3ea61fe36e2.

[Bug target/110979] Miss-optimization for O2 fully masked loop on floating point reduction.

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
For this particular costing there's also the issue that we perform costing at
vectorizable_reduction time but then we don't know yet whether we will use
partial vectors in the end.  We try to apply costs due to using partial vectors
in vect_estimate_min_profitable_iters but we don't have any good way to
account for extra costs because some operations might expand differently
when using partial vectors vs. not using partial vectors.  The only way
would be to separate costing of operations from the analysis phase or
alternatively record multiple cost variants during analysis and pick the
correct one later.  I think the former, separating costing from analysis,
might be the better way in the end.

Note currently we cost

_4 + sum_13 8 times vec_to_scalar costs 64 in body
_4 + sum_13 8 times scalar_stmt costs 96 in body
*_3 1 times unaligned_load (misalign -1) costs 12 in body
t.c:9:21: note:  operating on partial vectors.
 2 times vector_stmt costs 8 in prologue
 2 times vector_stmt costs 8 in body
t.c:9:21: note:  Cost model analysis:
  Vector inside of loop cost: 180
  Vector prologue cost: 8
  Vector epilogue cost: 0
  Scalar iteration cost: 24
  Scalar outside cost: 0
  Vector outside cost: 8
  prologue iterations: 0
  epilogue iterations: 0
  Minimum number of vector iterations: 1
  Calculated minimum iters for profitability: 8
t.c:9:21: note:Runtime profitability threshold = 8
t.c:9:21: note:Static estimate profitability threshold = 8
t.c:9:21: note:  * Analysis succeeded with vector mode V8DF

The vector + overhead is thus cheaper than the scalar version but
that assumes we'd actually run a full round of VF scalar iterations!

If we'd add 7 times vec_to_scalar + scalar_stmt as epilogue cost
we'd up the requirement considerably because the difference between
scalar (192) and vector (180) is already quite small.

I wonder if we wouldn't need to adjust our formula for static profitability
to account for partial vectors?

When using a variable upper loop bound we still see

t.c:9:21: note:  Cost model analysis:
  Vector inside of loop cost: 180
  Vector prologue cost: 8 
  Vector epilogue cost: 0
  Scalar iteration cost: 24
  Scalar outside cost: 32
  Vector outside cost: 8
  prologue iterations: 0
  epilogue iterations: 0
  Minimum number of vector iterations: 1
  Calculated minimum iters for profitability: 7
t.c:9:21: note:Runtime profitability threshold = 7
t.c:9:21: note:Static estimate profitability threshold = 32
t.c:9:21: note:  no need for a runtime choice between the scalar and vector
loops
t.c:9:21: note:  * Analysis succeeded with vector mode V8DF

but if the scalar loop would only iterate once we'd have a cost of 24 there.

[Bug tree-optimization/110992] New: [14 Regression] Dead Code Elimination Regression at -O3 since r14-1654-g7ceed7e3e29

[scherrer.sv at gmail dot com via Gcc-bugs]

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

Bug ID: 110992
   Summary: [14 Regression] Dead Code Elimination Regression at
-O3 since r14-1654-g7ceed7e3e29
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: scherrer.sv at gmail dot com
  Target Milestone: ---

static unsigned b;
static short c = 4;
void foo(void);
static short(a)(short d, short g) { return d * g; }
void e();
static char f() {
  b = 0;
  return 0;
}
int main() {
  int h = b;
  if ((short)(a(c && e, 65535) & h)) {
foo();
h || f();
  }
}

gcc-bcda361daae (trunk) -O3 cannot eliminate the call to foo but
gcc-releases/gcc-13.1.0 -O3 can.
---
gcc-bcda361daaec8623c91d0dff3ea8e576373b5f50 -O3 case.c -S -o case.s
- OUTPUT -
main:
.LFB2:
.cfi_startproc
cmpw$0, b(%rip)
jne .L8
xorl%eax, %eax
ret
.L8:
pushq   %rax
.cfi_def_cfa_offset 16
callfoo
xorl%eax, %eax
popq%rdx
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -

---
gcc-2b98cc24d6af0432a74f6dad1c722ce21c1f7458 -O3 case.c -S -o case.s
- OUTPUT -
main:
.LFB2:
.cfi_startproc
xorl%eax, %eax
ret
-- END OUTPUT -

---
Bisects to r14-1654-g7ceed7e3e29

[Bug tree-optimization/110991] New: [14 Regression] Dead Code Elimination Regression at -O2 since r14-1135-gc53f51005de

[scherrer.sv at gmail dot com via Gcc-bugs]

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

Bug ID: 110991
   Summary: [14 Regression] Dead Code Elimination Regression at
-O2 since r14-1135-gc53f51005de
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: scherrer.sv at gmail dot com
  Target Milestone: ---

static unsigned char a;
static char b;
void foo(void);
int main() {
  a = 25;
  for (; a > 13; --a)
b = a > 127 ?: a << 3;
  if (!b)
foo();
}

gcc-3a13884b23a (trunk) -O2 cannot eliminate the call to foo but
gcc-releases/gcc-13.1.0 -O2 can.
---
gcc-3a13884b23ae32b43d56d68a9c6bd4ce53d60017 -O2 case.c -S -o case.s
- OUTPUT -
main:
.LFB0:
.cfi_startproc
movd.LC0(%rip), %xmm0
movd.LC1(%rip), %xmm1
xorl%eax, %eax
.L2:
addl$1, %eax
movdqa  %xmm0, %xmm2
paddb   %xmm1, %xmm0
cmpl$3, %eax
jne .L2
movdqa  %xmm2, %xmm0
movb$13, a(%rip)
paddb   %xmm2, %xmm0
paddb   %xmm0, %xmm0
movdqa  %xmm0, %xmm1
paddb   %xmm0, %xmm1
pxor%xmm0, %xmm0
pcmpgtb %xmm2, %xmm0
movd.LC2(%rip), %xmm2
pand%xmm0, %xmm2
pandn   %xmm1, %xmm0
por %xmm2, %xmm0
movd%xmm0, %eax
sarl$24, %eax
movb%al, b(%rip)
testb   %al, %al
je  .L10
xorl%eax, %eax
ret
.L10:
pushq   %rax
.cfi_def_cfa_offset 16
callfoo
xorl%eax, %eax
popq%rdx
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -

---
gcc-2b98cc24d6af0432a74f6dad1c722ce21c1f7458 -O2 case.c -S -o case.s
- OUTPUT -
main:
.LFB0:
.cfi_startproc
movb$112, b(%rip)
xorl%eax, %eax
movb$13, a(%rip)
ret
-- END OUTPUT -

---
Bisects to r14-1135-gc53f51005de

[Bug target/110979] Miss-optimization for O2 fully masked loop on floating point reduction.

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
The wrong-code part is fixed now, what remains is the inefficiency.  I don't
think we currently cost the "excess" lanes in regular vectorized operations but
of course for open-coded fold-left reductions we should likely account for
possibly VF - 1 extra scalar ops (but in the "epilog" even if that doesn't
exist, since that only applies to the last vector iteration).  I fear it's not
going to be enough to fend off vectorization though.

[Bug target/110979] Miss-optimization for O2 fully masked loop on floating point reduction.

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

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

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

https://gcc.gnu.org/g:798a880a0b1fed8a9e3b3e026dd8bd09314b7c38

commit r14-3149-g798a880a0b1fed8a9e3b3e026dd8bd09314b7c38
Author: Richard Biener 
Date:   Fri Aug 11 13:00:17 2023 +0200

tree-optimization/110979 - fold-left reduction and partial vectors

When we vectorize fold-left reductions with partial vectors but
no target operation available we use a vector conditional to force
excess elements to zero.  But that doesn't correctly preserve
the sign of zero.  The following patch disables partial vector
support when we have to do that and also need to honor rounding
modes other than round-to-nearest.  When round-to-nearest is in
effect and we have to preserve the sign of zero instead use
negative zero for the excess elements.

PR tree-optimization/110979
* tree-vect-loop.cc (vectorizable_reduction): For
FOLD_LEFT_REDUCTION without target support make sure
we don't need to honor signed zeros and sign dependent rounding.

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

[Bug libstdc++/110860] std::format("{:f}",2e304) invokes undefined behaviour

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
Gah!

[Bug middle-end/110989] RISC-V vector ICE due to invalid tree code in GIMPLE vect pass

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

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

--- Comment #2 from JuzheZhong  ---
Confirm it's caused by:

if (!final_len)
  {
/* Pass VF value to 'len' argument of
   MASK_LEN_LOAD if LOOP_LENS is invalid.  */
tree iv_type
  = LOOP_VINFO_RGROUP_IV_TYPE (loop_vinfo);
final_len
  = build_int_cst (iv_type,
   TYPE_VECTOR_SUBPARTS (vectype));
  }


The final_len is false when we didn't record len. 
In this situation, LOOP_VINFO_RGROUP_IV_TYPE (loop_vinfo) is not 
set correctly.


Thanks for reporting.

[Bug middle-end/110989] RISC-V vector ICE due to invalid tree code in GIMPLE vect pass

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

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

JuzheZhong  changed:

   What|Removed |Added

 CC||juzhe.zhong at rivai dot ai,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from JuzheZhong  ---
I didn't

[Bug libstdc++/110860] std::format("{:f}",2e304) invokes undefined behaviour

[gcc at pauldreik dot se via Gcc-bugs]

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

--- Comment #8 from Paul Dreik  ---
I do unfortunately not think the fix is entirely correct.

When 0 is passed, log10 returns -inf, which can not be converted to an integer.

I had a bit of problem to reproduce this with gcc, but it worked with clang.
The following program:

#include 
#include 
#include 

int main(int argc, char* argv[]) {
[[maybe_unused]] auto x = std::format("{:.292f}", 0.f);
}

causes the following output when compiled with clang-16 using
-fsanitize=undefined -fno-sanitize-recover=all -g -O0:

/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/14.0.0/../../../../include/c++/14.0.0/format:1496:15:
runtime error: -inf is outside the range of representable values of type
'unsigned long'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/14.0.0/../../../../include/c++/14.0.0/format:1496:15
in 

Link to reproducer (expected to go stale quick, had to use clang trunk to get a
sufficiently new libstdc++): https://godbolt.org/z/8aGf7YGWs

[Bug libstdc++/110990] New: `format_to_n` returns wrong value

[ensadc at mailnesia dot com via Gcc-bugs]

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

Bug ID: 110990
   Summary: `format_to_n` returns wrong value
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ensadc at mailnesia dot com
  Target Milestone: ---

https://godbolt.org/z/4fv71hhGe

#include 
#include 

int main() {
char buf[10] = "@";
auto result = std::format_to_n(buf, std::size(buf), "a");

std::cout << result.out - buf << '\n';
}


On libstdc++, `result.out - buf` evaluates to 10. I expect it to be 1. Both
libc++ and MSVC STL produce 1.

[Bug middle-end/110989] New: RISC-V vector ICE due to invalid tree code in GIMPLE vect pass

[jeremy.bennett at embecosm dot com via Gcc-bugs]

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

Bug ID: 110989
   Summary: RISC-V vector ICE due to invalid tree code in GIMPLE
vect pass
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeremy.bennett at embecosm dot com
  Target Milestone: ---

Created attachment 55722
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55722=edit
C source of the testcase

The following code (testcase.c) causes an ICE when using RISC-V vector as
target.

int a, b, c;
double *d;
void e() {
  double f;
  for (; c; c++, d--)
f = *d ?: *( + c);
  b = f;
}

Compiled with:

riscv64-unknown-linux-gnu-gcc -march=rv64gcv -mabi=lp64d -c \
-Ofast --param=riscv-autovec-preference=scalable testcase.c

The output is:

during GIMPLE pass: vect
testcase.c: In function 'e':
testcase.c:3:6: internal compiler error: tree check: expected class 'type',
have 'exceptional' () in build_int_cst, at tree.cc:1507
3 | void e() {
  |  ^
0x914c99 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/jeremy/gittrees/mustang/gcc/gcc/tree.cc:8949
0x91e2c7 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/home/jeremy/gittrees/mustang/gcc/gcc/tree.h:3700
0x91e2c7 build_int_cst(tree_node*, poly_int<2u, long>)
/home/jeremy/gittrees/mustang/gcc/gcc/tree.cc:1507
0x20f3e2d vectorizable_load
/home/jeremy/gittrees/mustang/gcc/gcc/tree-vect-stmts.cc:10719
0x2100ee5 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/home/jeremy/gittrees/mustang/gcc/gcc/tree-vect-stmts.cc:12337
0x131f464 vect_transform_loop_stmt
/home/jeremy/gittrees/mustang/gcc/gcc/tree-vect-loop.cc:11039
0x13442bc vect_transform_loop(_loop_vec_info*, gimple*)
/home/jeremy/gittrees/mustang/gcc/gcc/tree-vect-loop.cc:11488
0x138611f vect_transform_loops
/home/jeremy/gittrees/mustang/gcc/gcc/tree-vectorizer.cc:1004
0x138679c try_vectorize_loop_1
/home/jeremy/gittrees/mustang/gcc/gcc/tree-vectorizer.cc:1150
0x138679c try_vectorize_loop
/home/jeremy/gittrees/mustang/gcc/gcc/tree-vectorizer.cc:1180
0x1386b44 execute
/home/jeremy/gittrees/mustang/gcc/gcc/tree-vectorizer.cc:1296
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

System information
--

Using built-in specs.
COLLECT_GCC=riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/jeremy/gittrees/mustang/install/libexec/gcc/riscv64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /home/jeremy/gittrees/mustang/gcc/configure
--target=riscv64-unknown-linux-gnu
--prefix=/home/jeremy/gittrees/mustang/install
--with-sysroot=/home/jeremy/gittrees/mustang/install/sysroot
--with-pkgversion=g68783211f66 --with-system-zlib --enable-shared --enable-tls
--enable-languages=c,c++,fortran --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap
--src=/home/jeremy/gittrees/mustang/gcc --enable-multilib --with-abi=lp64d
--with-arch=rv64gc --with-tune= --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2
   -mcmodel=medany' 'CXXFLAGS_FOR_TARGET=-O2-mcmodel=medany'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230811 (experimental) (g68783211f66)

[Bug gcov-profile/110988] New: ICE when building 523.xalancbmk_r with pgo and lto

[fkastl at suse dot cz via Gcc-bugs]

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

Bug ID: 110988
   Summary: ICE when building 523.xalancbmk_r with pgo and lto
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

On x86_64 Zen3-based CPU (and probably others) building 523.xalancbmk_r fails
with an ICE in the final build step.

We have bisected this to 2e93b92c1ec5fbbbe10765c6e059c3c90d564245 (Fix profile
update after cancelled loop distribution).

The backtrace is

during GIMPLE pass: vect
./xalanc/PlatformSupport/XalanArrayAllocator.hpp: In member function
'createEntry':
./xalanc/PlatformSupport/XalanArrayAllocator.hpp:174:9: internal compiler
error: in apply_scale, at profile-count.h:1180
  174 | createEntry(
  | ^ 
0x97fd4f profile_count::apply_scale(profile_count, profile_count) const 
../../gcc/gcc/profile-count.h:1180
0xe921fc fold_loop_internal_call(gimple*, tree_node*)
../../gcc/gcc/tree-cfg.cc:7738
0x1124a02 execute
../../gcc/gcc/tree-vectorizer.cc:1328
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.
make[1]: *** [/tmp/ccHpVuHE.mk:26: /tmp/cc6fS858.ltrans8.ltrans.o] Error 1
make[1]: *** Waiting for unfinished jobs

[Bug middle-end/110972] 13% fatigue regression between g:bb3ceeb6520c13fc (2023-08-07 21:09) and g:d9dc70cc65becca9 (2023-08-08 13:30)

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

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

--- Comment #4 from Richard Biener  ---
-fatigue2.f90:1077:93: optimized: basic block part vectorized using 32 byte
vectors
+fatigue2.f90:1002:56: optimized: basic block part vectorized using 32 byte
vectors
+fatigue2.f90:1058:93: optimized: basic block part vectorized using 32 byte
vectors

OTOH that's a bit imprecise, the - is bogus I think, but the + are real,
:1058 is also loop vectorized.  The body is very large, perf shows

Samples: 279K of event 'cycles', Event count (approx.): 316851940248
Overhead   Samples  Command   Shared Object Symbol  
  30.84% 86412  fatigue2  fatigue2  [.] MAIN__
  24.26% 67530  fatigue   fatigue   [.] MAIN__
  20.05% 56167  fatigue2  fatigue2  [.]
__perdida_m_MOD_generalized_hookes_law.constprop.0.isra.0
  18.73% 52127  fatigue   fatigue   [.]
__perdida_m_MOD_generalized_hookes_law.constprop.0.isra.0
   1.96%  5459  fatigue   fatigue   [.]
__perdida_m_MOD_generalized_hookes_law.constprop.1.isra.0
   1.84%  5140  fatigue2  fatigue2  [.]
__perdida_m_MOD_generalized_hookes_law.constprop.1.isra.0
   0.83%  2308  fatigue   libc-2.31.so  [.]
__memset_avx2_unaligned_erms
   0.60%  1693  fatigue2  libc-2.31.so  [.]
__memset_avx2_unaligned_erms

[Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls

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

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #10 from Wilco  ---
(In reply to Feng Xue from comment #9)
> On some occasions, we may not use the new ld, the kernel-building relies on
> its own runtime linker which is used for kernel modules. So I created a
> patch (https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626084.html),
> and this provides user another option that could be done at the compiler
> side.

Reducing BTI is important for security. With LTO a binary should only have BTI
on functions that are indirectly called. So I don't like the idea of adding
more BTI with a new option - it means we will need a linker optimization to
remove those redundant BTIs (eg. by changing them into NOPs).

Note that branch offsets up to 256MB don't need special veneer handling: one
should place a direct branch about halfway to the destination.

Does Linux do any weird hacks in -fpatchable-function-entry that makes it hard
to use BTI?

[Bug tree-optimization/110984] phiopt's spaceship_replacement should support cast and !=

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-August/
   ||627123.html

--- Comment #3 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627123.html

[Bug fortran/110987] Segmentation fault after finalization of a temporary variable

[chilikin.k at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Kirill Chilikin  ---
Created attachment 55721
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55721=edit
Objdump of the corresponding code

[Bug fortran/110987] New: Segmentation fault after finalization of a temporary variable

[chilikin.k at gmail dot com via Gcc-bugs]

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

Bug ID: 110987
   Summary: Segmentation fault after finalization of a temporary
variable
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chilikin.k at gmail dot com
  Target Milestone: ---

Created attachment 55720
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55720=edit
Test case

The attached test program works fine with gfortran 12.2.0 and crashes with
a segmentation fault when compiled with gfortran 13.2.0. The compilation
command is

gfortran -g -o test test.f90

The segmentation fault happens when the function T1_GET_NEXT() tries to access
SELF%NEXT(1)%T1, which is deallocated and overwritten:

$ valgrind ./test

==1651009== Invalid read of size 8
==1651009==at 0x40251D: __test_module_MOD_t1_get_next (in test)
==1651009==by 0x403678: MAIN__ (in test)
==1651009==by 0x4036D0: main (in test)
==1651009==  Address 0x4e92d48 is 8 bytes inside a block of size 16 free'd
==1651009==at 0x48399AB: free (vg_replace_malloc.c:538)
==1651009==by 0x402876: __test_module_MOD_t1_destructor (in test)
==1651009==by 0x401812: __test_module_MOD___final_test_module_T1 (in test)
==1651009==by 0x4035CF: MAIN__ (in test)
==1651009==by 0x4036D0: main (in test)
==1651009==  Block was alloc'd at
==1651009==at 0x483877F: malloc (vg_replace_malloc.c:307)
==1651009==by 0x4026AF: __test_module_MOD_t1_set_n_next (in test)
==1651009==by 0x402466: __test_module_MOD_t2_constructor (in test)
==1651009==by 0x402E93: MAIN__ (in test)
==1651009==by 0x4036D0: main (in test)

The corresponding part of the output of

$ objdump -S ./test | less

is attached. The final-subroutine call which incorrectly deallocates memory
happens at 4035cd, between the calls of __test_module_MOD_t3_constructor and
__test_module_MOD_t1_set_n_next. Thus, the finalization seems to happen for
the temporary variable allocated as the result of T3() call, which is assigned
then to X3, and the memory corresponding to

CLASS(T1_POINTER), ALLOCATABLE :: NEXT(:)

is probably the same for that temporary variable and X3 (in contradiction with
10.2.1.3.13 item (2) of Fortran 2018?).

May be related to the fix of bug 80524.