[Bug tree-optimization/116126] New: vectorize libcpp search_line_fast

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

Bug ID: 116126
   Summary: vectorize libcpp search_line_fast
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andi-gcc at firstfloor dot org
  Target Milestone: ---

This is somewhat of a metabug to track vectorization of libcpp/lex.c
search_line_fast, which currently has manual vectorization for various
architectures. It would be better if gcc could just figure it out by itself.

The definition is:

// Find any occurrence for \n \r \\ ? and return pointer to it. 
// Can assume that the string ends with \n, so end can be ignored

const unsigned char *search_line_fast (const unsigned char *s, const unsigned
char *end)
{
for (;;) {
if (*s == '\n' || *s == '\r' || *s == '\\' || *s == '?')
return s;
s++;
}
}

currently this fails due to

- Vectorizer cannot determine number of iterations
- Early return is not supported
- if to switch creates an unsupported switch

If we don't ignore end to work around the uncountable problem we get:

const unsigned char *search_line_fast2 (const unsigned char *s, const unsigned
char *end)
{
while (s < end) {
if (*s == '\n' || *s == '\r' || *s == '\\' || *s == '?')
return s;
s++;
}
}

[Bug fortran/110033] rejects-valid: associate name corresponding to coarray selector should be considered a coarray

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

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

Andre Vehreschild  changed:

   What|Removed |Added

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

[Bug target/116111] RISC-V: 'd' extension allowed with -mabi=ilp32e

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

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

Kito Cheng  changed:

   What|Removed |Added

 CC||kito at gcc dot gnu.org

--- Comment #2 from Kito Cheng  ---
Cross post my reply here:

In short: Yeah, I think it's a GCC bug, but I am not sure what's the right
direction to fix that either.

Longer version: I feel a responsibility to tell this story since I am one of
the main authors of the GCC implementation and the author of the psABI ilp32e
draft*1. With many new friends joining the RISC-V development, it's time to
talk about some history here.

First, RV32E was not supported for use with F and D[1]. Therefore, the design
of ilp32e did not consider the alignment of the `fld` instruction at all. The
only goal of RV32E was to minimize the memory footprint, so the stack alignment
was set to 4 bytes.

The constraints for the E extension have been relaxed, so we should update the
`ilp32e` draft. A few ideas have been proposed in the past years: 1) increasing
the stack alignment to 8 bytes or 16 bytes, or 2) adding new ABI variants like
`ilp32ef` and `ilp32ed`, while also restricting `ilp32e` to be used only
without D.

BUT...not enough people are interested in the `ilp32e` ABI, so it's been stuck
for a while.

Lastly, here is a call for help. Let me know if anyone is interested in the
`ilp32e` and/or `lp64e` ABI. Since the E extension has become ratified, we
should move this forward.

*1 Yes, ilp32e is still under draft status. One major reason is that rv32e was
under version 1.9 for a long time, which meant it could still change. rv32e
became version 2.0 last year[3].

[1] Relax the constraint of the E extension, allowing rv64e and combinations
with F and D extensions.
https://github.com/riscv/riscv-isa-manual/commit/4845f5d61f96a827ec4d21d2c5a80b6bf7881e56
[2] Bump version from 1.9 to 1.95
https://github.com/riscv/riscv-isa-manual/commit/ec4919caf5638e2d1c437391c6eab097e038aaec
[3] Bump version from 1.95 to 2.0
https://github.com/riscv/riscv-isa-manual/commit/fefbe61f8ffa04d6942fc5493ef65f3f66e48170

[Bug c++/115986] [14 Regression] ICE in fold_convert_loc, at fold-const.cc:2644 involving consteval user-defined uint128 literals

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

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

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

https://gcc.gnu.org/g:331f23540eec39fc1e665f573c4aac258bba6043

commit r15-2375-g331f23540eec39fc1e665f573c4aac258bba6043
Author: Jakub Jelinek 
Date:   Mon Jul 29 09:33:09 2024 +0200

testsuite: Fix up consteval-prop21.C for 32-bit targets [PR115986]

The test fails on 32-bit targets (which don't support __int128 type).
Using unsigned long long instead still ICEs before the fix and passes
after it on those targets.

2024-07-29  Jakub Jelinek  

PR c++/115986
* g++.dg/cpp2a/consteval-prop21.C (operator "" _c): Use
unsigned long long rather than __uint128_t for return type if
int128
is unsupported.

[Bug target/116125] RISC-V: Does not fully checking for overlapping memory regions

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

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

Robin Dapp  changed:

   What|Removed |Added

  Known to fail||14.1.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 Target||riscv
   Last reconfirmed||2024-07-29

--- Comment #1 from Robin Dapp  ---
Confirmed failing on the trunk,  instead of reverting the patch we can just use
-fno-vect-cost-model, so the full command line would be
-O3 -march=rv64gcv -fno-inline -fno-vect-cost-model.

[Bug target/116103] [15 Regression] GCN vs. "Internal-fn: Only allow modes describe types for internal fn[PR115961]"

[pan2.li at intel dot com via Gcc-bugs]

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

--- Comment #7 from Li Pan  ---
Hi Thomas,

Could you please help to double confirm the below patch is able to fix these
asm check failure?

https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658519.html

I tested below cases for target=amdgcn-amdhsa, but would like to double confirm
with you all related failures are covered.

gcc.target/gcn/cond_smax_1.c scan-assembler-times \\tv_cmp_gt_i32\\tvcc,
s[0-9]+, v[0-9]+ 80
gcc.target/gcn/cond_smin_1.c scan-assembler-times \\tv_cmp_gt_i32\\tvcc,
s[0-9]+, v[0-9]+ 80
gcc.target/gcn/cond_umax_1.c scan-assembler-times \\tv_cmp_gt_i32\\tvcc,
s[0-9]+, v[0-9]+ 56
gcc.target/gcn/cond_umin_1.c scan-assembler-times \\tv_cmp_gt_i32\\tvcc,
s[0-9]+, v[0-9]+ 56
gcc.dg/tree-ssa/loop-bound-2.c scan-tree-dump-not ivopts "zero if "

Pan

[Bug tree-optimization/116125] [12/13/14/15 Regression] Does not fully checking for overlapping memory regions

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org
   Target Milestone|--- |12.5
 Target|riscv   |x86_64-*-*
  Component|target  |tree-optimization
Summary|RISC-V: Does not fully  |[12/13/14/15 Regression]
   |checking for overlapping|Does not fully checking for
   |memory regions  |overlapping memory regions
   Last reconfirmed|2024-07-29 00:00:00 |
   Keywords||wrong-code
  Known to fail|14.1.0  |
   Priority|P3  |P2

--- Comment #2 from Richard Biener  ---
Confirmed, this also fails on x86-64.  It works when using
unsigned char or unsigned int data and only fails with the bitfield.
The bitfield has the effect of aligning num and we get padding.

create runtime check for data references _3->D.3529 and _5->D.3529
using an address-based WAR/WAW test
t.c:10:21: note:  created 1 versioning for alias checks.

  _39 = b_10(D) + 4;
  _40 = a_11(D) - _39;
  _41 = (sizetype) _40;
  _42 = _41 + 18446744073709551613; // _41 - 3
  _18 = 1;
  if (_42 > 18)
goto ; [80.00%]

$2 = (const dr_with_seg_len_pair_t &) @0x4774088: {first = {dr = 0x48b1610, 
seg_len = , access_size = {coeffs = {1}}, 
align = 4}, second = {dr = 0x48b31a0, 
seg_len = , access_size = {coeffs = {1}}, 
align = 4}, flags = 2}
(gdb) p debug_generic_expr (0x7686b7c8)
28

the vectorization factor is 8.

Richard, you did create_waw_or_war_checks - can you check?

The testcase needs bitfield handling in if-conversion but I suspect we can
do without as well.  The following fails with GCC 12 already (you might
or might not need -fno-vect-cost-model)

typedef struct __attribute__((aligned(4)))
{
  unsigned char num;
} st;

void __attribute__((noipa))
mem_overlap (st *a, st *b)
{
  for (int i = 0; i < 9; i++)
a[i].num = b[i].num + 1;
}

int main ()
{
  st * a;
  a = (st*) __builtin_malloc (9 * sizeof(st));
  __builtin_memset (a, 0, 9 * sizeof(st));

  // input a = 0, 0, 0, 0, 0, 0, 0, 0, 0
  mem_overlap(&a[1], a);

  // output a = 0, 1, 2, 3, 4, 5, 6, 7, 8
  if (a[2].num != 2)
__builtin_abort();
  return 0;
}

[Bug ipa/116055] [14/15 Regression] ICE from gcc.c-torture/unsorted/dump-noaddr.c after "Fix modref's iteraction with store merging"

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

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jan Hubicka
:

https://gcc.gnu.org/g:98baaa17561ca299eefc98f469f4326e551604c9

commit r14-10515-g98baaa17561ca299eefc98f469f4326e551604c9
Author: Jan Hubicka 
Date:   Mon Jul 29 10:48:34 2024 +0200

Fix ICE with -fdump-tree-moref

gcc/ChangeLog:

PR ipa/116055
* ipa-modref.cc (analyze_function): Do not ICE when flags regress.

[Bug ipa/116055] [14/15 Regression] ICE from gcc.c-torture/unsorted/dump-noaddr.c after "Fix modref's iteraction with store merging"

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Jan Hubicka :

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

commit r15-2376-gb3176b620ff29a06c90992ca3d29f3cffd459537
Author: Jan Hubicka 
Date:   Mon Jul 29 10:49:49 2024 +0200

Fix ICE with -fdump-tree-moref

gcc/ChangeLog:

PR ipa/116055
* ipa-modref.cc (analyze_function): Do not ICE when flags regress.

[Bug ipa/116055] [14/15 Regression] ICE from gcc.c-torture/unsorted/dump-noaddr.c after "Fix modref's iteraction with store merging"

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

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #9 from Jan Hubicka  ---
Fixed.

[Bug c++/101232] Bad error message with stray semicolon in initializer

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

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

--- Comment #10 from Jonathan Wakely  ---
Please send the v2 patch to gcc-patches for review, thanks!

[Bug tree-optimization/116100] (VEC_COND (UNCOND_EXPR)) -> COND_FN conversion should happen in isel

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

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

Richard Sandiford  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #2 from Richard Sandiford  ---
Also, the COND_FNs are generated directly by the vectoriser for things that
cannot be accurately represented any other way (for FP ops).  So I think it's
relatively more important that other passes handle them well.

[Bug middle-end/116107] [OpenMP] Array-section mapping with 'declare target' link accesses the wrong data

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

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

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

https://gcc.gnu.org/g:14c47e7eb06e8b95913794f6059560fc2fa6de91

commit r15-2377-g14c47e7eb06e8b95913794f6059560fc2fa6de91
Author: Tobias Burnus 
Date:   Mon Jul 29 11:40:38 2024 +0200

libgomp: Fix declare target link with offset array-section mapping
[PR116107]

Assume that 'int var[100]' is 'omp declare target link(var)'. When now
mapping an array section with offset such as 'map(to:var[20:10])',
the device-side link pointer has to store &[0] minus
the offset such that var[20] will access [0]. But
the offset calculation was missed such that the device-side 'var' pointed
to the first element of the mapped data - and var[20] points beyond at
some invalid memory.

PR middle-end/116107

libgomp/ChangeLog:

* target.c (gomp_map_vars_internal): Honor array mapping offsets
with declare-target 'link' variables.
* testsuite/libgomp.c-c++-common/target-link-2.c: New test.

[Bug middle-end/116107] [OpenMP] Array-section mapping with 'declare target' link accesses the wrong data

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #2 from Tobias Burnus  ---
FIXED on mainline (GCC 15) with the C/C++ testcase.

The Fortran testcase will be committed as part of PR 115559.

[Bug fortran/115559] [OpenMP] 'link' clause of 'declare target' causes link errors

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

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

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

https://gcc.gnu.org/g:29b1587e7d34667a1fd63071c1e4f5475cd71026

commit r15-2378-g29b1587e7d34667a1fd63071c1e4f5475cd71026
Author: Tobias Burnus 
Date:   Mon Jul 29 11:46:57 2024 +0200

OpenMP/Fortran: Fix handling of 'declare target' with 'link' clause
[PR115559]

Contrary to a normal 'declare target', the 'declare target link' attribute
also needs to set node->offloadable and push the offload_vars in the front
end.

Linked variables require that the data is mapped. For module variables,
this
can happen anywhere. For variables in an external subprograms or the main
programm, this can only happen in the either that program itself or in an
internal subprogram. - Whether a variable is just normally mapped or linked
then
becomes relevant if a device routine exists that can access that variable,
i.e. an internal procedure has then to be marked as declare target.

PR fortran/115559

gcc/fortran/ChangeLog:

* trans-common.cc (build_common_decl): Add 'omp declare target' and
'omp declare target link' variables to offload_vars.
* trans-decl.cc (add_attributes_to_decl): Likewise; update args and
call decl_attributes.
(get_proc_pointer_decl, gfc_get_extern_function_decl,
build_function_decl): Update calls.
(gfc_get_symbol_decl): Likewise; move after 'DECL_STATIC (t)=1'
to avoid errors with symtab_node::get_create.

libgomp/ChangeLog:

* testsuite/libgomp.fortran/declare-target-link.f90: New test.

[Bug fortran/115577] [OpenMP] COMMON names rejected in MAP clauses

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

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

--- Comment #1 from Tobias Burnus  ---
>From the other issue, now fixed:

(B) Issues found when writing a testcase:

* COMMON blocks: Using map(a,b,c) instead of map(/mycommon/) fails with:
 error: undefined symbol: mycommon_
  TESTCASE: attachment 58478


ISSUE (A) is (→ comment 0):

   10 |!$omp target enter data map(/mycommon/)
  |1
Error: Syntax error in OpenMP variable list at (1)

[Bug fortran/115559] [OpenMP] 'link' clause of 'declare target' causes link errors

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #9 from Tobias Burnus  ---
MAIN issue now FIXED on mainline (GCC 15).

Array-section issue was fixed via PR 116107
(and is included in the testcase of this PR)

* * *

Follow-up/related issue are tracked elsewhere:

* C: Nested functions + declare variant link → PR 115574

* DECL issue 'arr2' aka
  PR 115637 - gimple_regimplify_operands doesn't handle VALUE_EXPR inside a
MEM_REF / OpenMP declare target link

* COMMON block issues
  (i)  COMMON blocks: Using map(a,b,c) instead of map(/mycommon/) fails
  (ii) MAP issue: map(/mycommon/) is wrongly rejected for MAP
  → PR 115577

[Bug libfortran/105361] Incorrect end-of-file condition for derived-type I/O

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org
 Resolution|FIXED   |---
   Last reconfirmed||2024-07-29
 Ever confirmed|0   |1
 Status|RESOLVED|REOPENED

--- Comment #9 from Thomas Schwinge  ---
In some of my test runs (have not yet been able to deduce any pattern), I'm
seeing this new test case FAIL its execution test:

At line 33 of file [...]/source-gcc/gcc/testsuite/gfortran.dg/pr105361.f90
(unit = 10, file = 'fort.10')
Fortran runtime error: Bad real number in item 2 of list input

Error termination. Backtrace:
#0  0xf7f114e1 in read_real
at [...]/source-gcc/libgfortran/io/list_read.c:2080
#1  0xf7f12a87 in list_formatted_read_scalar
at [...]/source-gcc/libgfortran/io/list_read.c:2236
#2  0xf7f182bd in wrap_scalar_transfer
at [...]/source-gcc/libgfortran/io/transfer.c:2591
#3  0x8049486 in ???
#4  0x8049695 in ???
#5  0xf7996ed4 in ???
#6  0x8049155 in ???
#7  0x in ???

There also appear to be similar "twinkling" PASS <-> FAIL reports in
 posts.

[Bug fortran/20585] [meta-bug] Fortran 2003 support

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

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

Bug 105361 Summary: Incorrect end-of-file condition for derived-type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361

   What|Removed |Added

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

[Bug c++/116127] New: __builtin_lgamma(1.0e+0) is not a constant expression

[tomerv at gmail dot com via Gcc-bugs]

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

Bug ID: 116127
   Summary: __builtin_lgamma(1.0e+0) is not a constant expression
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tomerv at gmail dot com
  Target Milestone: ---

The other builtin math functions are constant expressions, e.g. this compiles:

static_assert(__builtin_tgamma(1.0) == 1.0);
static_assert(__builtin_log(__builtin_tgamma(1.0)) == 0.0);

However, this does not:

static_assert(__builtin_lgamma(1.0) == 0.0);

The error is:

:5:37: error: non-constant condition for static assertion
5 | static_assert(__builtin_lgamma(1.0) == 0.0);
  |   ~~^~
:5:31: error: '__builtin_lgamma(1.0e+0)' is not a constant expression
5 | static_assert(__builtin_lgamma(1.0) == 0.0);
  |   ^

[Bug c++/116127] __builtin_lgamma(1.0e+0) is not a constant expression

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Jakub Jelinek  ---
That is correct.
lgamma in addition to returning the result sets the int signgam; variable, so
it can't be a constant expression.

[Bug target/116104] [15 Regression] GCN vs. "[rtl-optimization/116037] Explicitly track if a destination was skipped in ext-dce"

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

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

--- Comment #3 from Andrew Stubbs  ---
(In reply to Jeffrey A. Law from comment #1)
> So, how am I supposed to reproduce this?  I don't have an assembler/binutils
> for amdgcn and thus libgcc won't configure.  Thus I can't extract a testcase.
> 
> Alternately, if you could just attach a .i file, it'd be helpful.

In fact, you probably do have an assembler and linker already installed!

Just copy "llvm-mc" to amdgcn-amdhsa/bin/as and llvm's "lld" to
amdgcn-amdhsa/bin/ld. You might want ar, ranlib, and nm too. Full details here:
https://gcc.gnu.org/wiki/Offloading#For_AMD_GCN

[Bug c++/116127] __builtin_lgamma(1.0e+0) is not a constant expression

[tomerv at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Tomer Vromen  ---
Jakub, thanks for the quick answer!

I see that this is a POSIX extension. I also see that according to
cppreference, std::lgamma is "constexpr since C++26". I do wonder how that will
work.

Is there a constexpr replacement for __builtin_lgamma? Using
__builtin_log(__builtin_tgamma(1000)) will not work due to overflow.

If there isn't currently a constexpr version then maybe there should be. Sounds
like it will be needed for C++26 support.

[Bug c++/116124] Can't use captured 'this' in lambda function that deduces this

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED
 CC||nshead at gcc dot gnu.org

--- Comment #1 from Nathaniel Shead  ---
This is PR113563.

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

[Bug c++/113563] Rejects capture of `this` in C++23 `this auto` lambda

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 CC||eddiejnolan at gmail dot com

--- Comment #5 from Nathaniel Shead  ---
*** Bug 116124 has been marked as a duplicate of this bug. ***

[Bug c++/116127] __builtin_lgamma(1.0e+0) is not a constant expression

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
CCing Jonathan as libstdc++ maintainer.
I'm not aware of any replacement.  As math libraries don't actually implement
any variant, one would need a GCC builtin which would be constexpr and in
constant evaluation never write signgam and when not constexpr evaluated allow
signgam to be modified but making it unspecified (so that it could be folded to
constant without signgam modification).

[Bug target/116104] [15 Regression] GCN vs. "[rtl-optimization/116037] Explicitly track if a destination was skipped in ext-dce"

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

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

--- Comment #4 from Andrew Stubbs  ---
The problem insn is this:

(insn 31 30 32 2 (set (reg:V2SI 711)
(ashift:V2SI (reg:V2SI 161 v1)
(const_vector:V2SI [
(const_int 3 [0x3]) repeated x2
])))
"/srv/data/ams/upB/gcn/src/gcc-mainline/libgcc/libgcc2.c":70:11 2043
{vashlv2si3}
 (expr_list:REG_DEAD (reg:V2SI 161 v1)
(nil)))

That is, it shifts each element in a 2-element vector by 3 bits. This looks
like valid GCN code to me.

ext_dce does not seem to be handling the vector case.

[Bug c++/64053] asm labels to accept extra parameters

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #3 from Georg-Johann Lay  ---
As the test case suggests, the issue is to use a static function or method as
an interrupt handler.  This has been added as PR116056 which allows to specify
the IRQ number as an argument to the "signal" function attribute.

Hence while not strictly the same issue, the desired code can be formulated
using PR116056:

template
struct ISR
{
static void handler();
};

template<>
[[gnu::signal(2)]]
[[gnu::signal(3)]]
void ISR<1>::handler()
{
__asm ("nop");
}

The generated assembly will be something like:
_ZN3ISRILj1EE7handlerEv:
.global __vector_3
__vector_3 = _ZN3ISRILj1EE7handlerEv
.global __vector_2
__vector_2 = _ZN3ISRILj1EE7handlerEv
__gcc_isr 1
/* #APP */
nop
/* #NOAPP */
__gcc_isr 2
reti
__gcc_isr 0,r0

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

[Bug target/116056] [avr] Add support for __attribute__((signal(n)))

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||eugene at hutorny dot in.ua

--- Comment #3 from Georg-Johann Lay  ---
*** Bug 64053 has been marked as a duplicate of this bug. ***

[Bug fortran/116128] New: missed optimisation: fortran sum instrinsic performed in order

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

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

Bug ID: 116128
   Summary: missed optimisation: fortran sum instrinsic performed
in order
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjr19 at cam dot ac.uk
  Target Milestone: ---

gfortran-14 performs the Fortran sum intrinsic strictly in order, thus
preventing any vectorisation and imposing a data dependency between each scalar
add operation.

The Fortran standard does not seem to require this. F2023 16.9.201 "the result
of SUM (ARRAY) has a value equal to a processor-dependent approximation to the
sum of all the elements of ARRAY or has the value zero if ARRAY has size zero."
The lack of a specified ordering, and the use of the term "processor-dependent
approximation", makes me think that the optimisations of omp simd reduce(+)
would be permitted.

On a quick test case, gfortran-14 -O3 -mavx2 summed a double precision array at
1.33ns per element. Nvfortran, with the same options, managed 0.1ns per
element, using four independent ymm registers as accumulators, so having
sixteen scalar partial sums.

The same comment applies to dot_product, and probably the other intrinsic
reduction operations.

[Bug c++/111728] C++ 20 coroutine segmentation fault in generic lambda

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

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

Arsen Arsenović  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |arsen at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||arsen at gcc dot gnu.org

--- Comment #3 from Arsen Arsenović  ---
Fixed on trunk w/ r15-2317-g1a37d6b732506f

[Bug target/116129] New: Use SVE INDEX instruction to create constant vectors

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

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

Bug ID: 116129
   Summary: Use SVE INDEX instruction to create constant vectors
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: aarch64-sve, missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

The INDEX (immediates) instruction can be used to create vectors based on a
base value and a step. We should make use of it even if generating fixed-length
vector immediates as it allows base and step values in [-16, 15]. We can use it
when TARGET_SVE is available.

For example:
#include 

typedef char v16qi __attribute__((vector_size (16)));

v16qi
foo (void)
{
  return (v16qi){0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
}

svint8_t
foo_sve (void)
{
  return svindex_s8 (0, 1);
}

These two functions should just use:
index   z0.b, #0, #1

Currently function foo will emit an ADR and an LDR from a constant pool

[Bug c/116130] New: Implement C23 N2956 paper - [[unsequenced]] and [[reproducible]] function type arguments

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

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

Bug ID: 116130
   Summary: Implement C23 N2956 paper - [[unsequenced]] and
[[reproducible]] function type arguments
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

The paper claims that the two are supersets of [[gnu::const]] and
[[gnu::pure]], but I think that is not the case.
See e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109914#c5 on the lack of
assertion of finitness.
I guess for function types without pointer (for C++ reference too) arguments we
could just imply ECF_CONST|ECF_LOOPING_CONST_OR_PURE or
ECF_PURE|ECF_LOOPING_CONST_OR_PURE
(say in flags_from_decl_or_type?).
For the rest it becomes more difficult.
Richi suggested using "fn spec" attribute for that, would that be
".c" for the first 2 chars, ". " for non-pointer arguments and "w " for the
pointer ones?  Though, I wonder if [[unsequenced]] or [[reproducible]]
functions can't say escape arguments in something the argument points to.
[[unsequenced]] int foo (int *p, int **q) {
  p[0] = q[0][0];
  q[1] = p;
  return 42;
}
or similar.

[Bug c/116130] Implement C23 N2956 paper - [[unsequenced]] and [[reproducible]] function type arguments

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||jsm28 at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
https://open-std.org/JTC1/SC22/WG14/www/docs/n2956.htm
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf

[Bug c++/115561] [14 Regression] ICE checking constraints when a local class is involved since r14-9659

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

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

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

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

commit r14-10516-gf30caf1bda8a0d086d0308e5024c2b4c43cbd6c0
Author: Jason Merrill 
Date:   Fri Jul 26 16:53:03 2024 -0400

c++: ICE with concept, local class, and lambda [PR115561]

Here when we want to synthesize methods for foo()::B
maybe_push_to_top_level
calls push_function_context, which sets cfun to a dummy value; later
finish_call_expr tries to set something in
cp_function_chain (i.e. cfun->language), which isn't set.  Many places in
the compiler check cfun && cp_function_chain to avoid this problem; here we
also want to check !cp_unevaluated_operand, like set_flags_from_callee
does.

PR c++/115561

gcc/cp/ChangeLog:

* semantics.cc (finish_call_expr): Check cp_unevaluated_operand.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit 3129a2ed6a764c0687efaca9eba53dcf12d1d8a0)

[Bug c++/115986] [14 Regression] ICE in fold_convert_loc, at fold-const.cc:2644 involving consteval user-defined uint128 literals

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

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

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

https://gcc.gnu.org/g:56d5f8a60519f6c76df671e9f96acf995b0ffc6c

commit r14-10517-g56d5f8a60519f6c76df671e9f96acf995b0ffc6c
Author: Jason Merrill 
Date:   Fri Jul 26 17:20:18 2024 -0400

c++: consteval propagation and templates [PR115986]

Here the call to e() makes us decide to check d() for escalation at EOF,
but
while checking it we try to fold_immediate 0_c, and get confused by the
template trees.  Let's not mess with escalation for function templates.

PR c++/115986

gcc/cp/ChangeLog:

* cp-gimplify.cc (remember_escalating_expr): Skip function
templates.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/consteval-prop21.C: New test.

(cherry picked from commit a9e9f772c7488ac0c09dd92f28890bdab939771a)

[Bug c++/115583] [14 Regression] C++23: Call to consteval function in `if consteval` immediate function context rejected at -O1 since r14-4140

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

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

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

https://gcc.gnu.org/g:9662299593c0b028e5008def72744732da429e9f

commit r14-10518-g9662299593c0b028e5008def72744732da429e9f
Author: Jason Merrill 
Date:   Sat Jul 27 16:40:02 2024 -0400

c++: if consteval and consteval propagation [PR115583]

During speculative constant folding of an if consteval, we take the false
branch, but the true branch is an immediate function context, so we don't
want to to cp_fold_immediate it.  So we could check IF_STMT_CONSTEVAL_P
here.  But beyond that, we don't want to do this inside a call, only when
first parsing a function.

PR c++/115583

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_conditional_expression): Don't
cp_fold_immediate for if consteval.

gcc/testsuite/ChangeLog:

* g++.dg/cpp23/consteval-if13.C: New test.

(cherry picked from commit d5f1948640815a554d106542c2e91e4e117aa3bc)

[Bug target/116104] [15 Regression] GCN vs. "[rtl-optimization/116037] Explicitly track if a destination was skipped in ext-dce"

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

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

--- Comment #5 from Jeffrey A. Law  ---
Given the relatively unstructured nature of RTL and the error message, this is
almost certainly a bug in ext-dce.  I should have noted that when I assigned
the issue to myself.

I've been able to trip it with 2629-1.c.  I don't expect it'll be hard to
fix at all.  Thanks.

[Bug c++/115986] [14 Regression] ICE in fold_convert_loc, at fold-const.cc:2644 involving consteval user-defined uint128 literals

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

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

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

https://gcc.gnu.org/g:61cb0c889e1f9a9f4ea5b22bbe089a906410374a

commit r14-10519-g61cb0c889e1f9a9f4ea5b22bbe089a906410374a
Author: Jakub Jelinek 
Date:   Mon Jul 29 09:33:09 2024 +0200

testsuite: Fix up consteval-prop21.C for 32-bit targets [PR115986]

The test fails on 32-bit targets (which don't support __int128 type).
Using unsigned long long instead still ICEs before the fix and passes
after it on those targets.

2024-07-29  Jakub Jelinek  

PR c++/115986
* g++.dg/cpp2a/consteval-prop21.C (operator "" _c): Use
unsigned long long rather than __uint128_t for return type if
int128
is unsupported.

(cherry picked from commit 331f23540eec39fc1e665f573c4aac258bba6043)

[Bug c/116130] Implement C23 N2956 paper - [[unsequenced]] and [[reproducible]] function type arguments

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

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

--- Comment #2 from Jakub Jelinek  ---
Also there is
"If possible, it is recommended that implementations diagnose if an attribute
of this clause is applied to a function definition that does not have the
corresponding property."
so we'd want some warnings, maybe in the FE, or during gimplification.

[Bug tree-optimization/116057] [12/13/14 Regression] SLP can introduces partialized unintialized vectors

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

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

--- Comment #16 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Richard Biener
:

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

commit r14-10520-ga7f1b00ed69810ce7f000d385a60e148d0228d48
Author: Richard Biener 
Date:   Wed Jul 24 13:16:35 2024 +0200

tree-optimization/116057 - wrong code with CCP and vector CTORs

The following fixes an issue with CCPs likely_value when faced with
a vector CTOR containing undef SSA names and constants.  This should
be classified as CONSTANT and not UNDEFINED.

PR tree-optimization/116057
* tree-ssa-ccp.cc (likely_value): Also walk CTORs in stmt
operands to look for constants.

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

(cherry picked from commit 1ea551514b9c285d801ac5ab8d78b22483ff65af)

[Bug c++/115900] [14 Regression] constexpr object modification during construction gives "Modifying a const object is not allowed in a constant expression"

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

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

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

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

commit r14-10521-gda7f0be91e2ae15342541546152a7a27a601c4b4
Author: Marek Polacek 
Date:   Wed Jul 17 11:19:32 2024 -0400

c++: wrong error initializing empty class [PR115900]

In r14-409, we started handling empty bases first in
cxx_fold_indirect_ref_1
so that we don't need to recurse and waste time.

This caused a bogus "modifying a const object" error.  I'm appending my
analysis from the PR, but basically, cxx_fold_indirect_ref now returns
a different object than before, and we mark the wrong thing as const,
but since we're initializing an empty object, we should avoid setting
the object constness.

~~
Pre-r14-409: we're evaluating the call to C::C(), which is in the body of
B::B(), which is the body of D::D(&d):

  C::C ((struct C *) this, NON_LVALUE_EXPR <0>)

It's a ctor so we get here:

 3118   /* Remember the object we are constructing or destructing.  */
 3119   tree new_obj = NULL_TREE;
 3120   if (DECL_CONSTRUCTOR_P (fun) || DECL_DESTRUCTOR_P (fun))
 3121 {
 3122   /* In a cdtor, it should be the first `this' argument.
 3123  At this point it has already been evaluated in the call
 3124  to cxx_bind_parameters_in_call.  */
 3125   new_obj = TREE_VEC_ELT (new_call.bindings, 0);

new_obj=(struct C *) &d.D.2656

 3126   new_obj = cxx_fold_indirect_ref (ctx, loc, DECL_CONTEXT (fun),
new_obj);

new_obj=d.D.2656.D.2597

We proceed to evaluate the call, then we get here:

 3317   /* At this point, the object's constructor will have run,
so
 3318  the object is no longer under construction, and its
possible
 3319  'const' semantics now apply.  Make a note of this fact
by
 3320  marking the CONSTRUCTOR TREE_READONLY.  */
 3321   if (new_obj && DECL_CONSTRUCTOR_P (fun))
 3322 cxx_set_object_constness (ctx, new_obj,
/*readonly_p=*/true,
 3323   non_constant_p, overflow_p);

new_obj is still d.D.2656.D.2597, its type is "C", cxx_set_object_constness
doesn't set anything as const.  This is fine.

After r14-409: on line 3125, new_obj is (struct C *) &d.D.2656 as before,
but we go to cxx_fold_indirect_ref_1:

 5739   if (is_empty_class (type)
 5740   && CLASS_TYPE_P (optype)
 5741   && lookup_base (optype, type, ba_any, NULL, tf_none, off))
 5742 {
 5743   if (empty_base)
 5744 *empty_base = true;
 5745   return op;

type is C, which is an empty class; optype is "const D", and C is a base of
D.
So we return the VAR_DECL 'd'.  Then we get to cxx_set_object_constness
with
object=d, which is const, so we mark the constructor READONLY.

Then we're evaluating A::A() which has

  ((A*)this)->data = 0;

we evaluate the LHS to d.D.2656.a, for which the initializer is
{.D.2656={.a={.data=}}} which is TREE_READONLY and 'd' is const, so we
think
we're modifying a const object and fail the constexpr evaluation.

PR c++/115900

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_call_expression): Set new_obj to NULL_TREE
if cxx_fold_indirect_ref set empty_base to true.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/constexpr-init23.C: New test.

(cherry picked from commit d890b04197fb0ddba4fbfb32f88e266fa27e02f3)

[Bug c++/115583] [14 Regression] C++23: Call to consteval function in `if consteval` immediate function context rejected at -O1 since r14-4140

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed for 14.2/15

[Bug c++/55004] [meta-bug] constexpr issues

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

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

Bug 115583 Summary: [14 Regression] C++23: Call to consteval function in `if 
consteval` immediate function context rejected at -O1 since r14-4140
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115583

   What|Removed |Added

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

[Bug c++/55004] [meta-bug] constexpr issues

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

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

Bug 115900 Summary: [14 Regression] constexpr object modification during 
construction gives "Modifying a const object is not allowed in a constant 
expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115900

   What|Removed |Added

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

[Bug c++/115900] [14 Regression] constexpr object modification during construction gives "Modifying a const object is not allowed in a constant expression"

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
 CC||jason at gcc dot gnu.org

--- Comment #12 from Jason Merrill  ---
Fixed for 14.2/15.

[Bug c++/115561] [14 Regression] ICE checking constraints when a local class is involved since r14-9659

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed for 14.2/15.

[Bug c++/115986] [14 Regression] ICE in fold_convert_loc, at fold-const.cc:2644 involving consteval user-defined uint128 literals

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed for 14.2/15.

[Bug c++/88313] generic lambda in default template argument

[leonid.satanovsky at gmail dot com via Gcc-bugs]

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

Leonid Satanovsky  changed:

   What|Removed |Added

 CC||leonid.satanovsky at gmail dot 
com

--- Comment #4 from Leonid Satanovsky  ---
Greetings, the bug still exists in latest Gcc (14+):

C++20

-
Works:

#include 

constexpr auto l = [](auto v) {return v;};
template
constexpr auto c(L f = {}) {return f(42);}
int main () {std::cout << c() << std::endl;}

-
Works:

#include 

constexpr auto c(decltype([](auto v) {return v;}) f = {}) {return f(42);}
int main () { std::cout << c() << std::endl; }

-
(Gcc 14 and latest trunk) Doesn't work / (Clang) Works:
(https://godbolt.org/z/bcbP44bK3)

#include 

template 
constexpr auto c(F f = {}) {return f(42);}
int main () { std::cout << c() << std::endl; }

[Bug target/116129] Use SVE INDEX instruction to create constant vectors

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug ipa/109914] --suggest-attribute=pure misdiagnoses static functions

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

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

--- Comment #7 from Jan Hubicka  ---
The idea is to help developers to annotate i.e. binary tree search function,
which he clearly knows is always to be finite, but compiler can not prove it.
Intentional infinite loops with no side effects written in a convoluted ways
are almost never intentional, so almost always developer can add the pure
attribute based on his/her understanding of what the code really does.

[Bug target/113328] Some fixed length vector constants can be generated using SVE index instruction

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

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

[Bug target/113328] Some fixed length vector constants can be generated using SVE index instruction

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-07-29

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

[Bug c++/115425] [13/14 regression] ICE: tree check: expected type_pack_expansion or expr_pack_expansion, have error_mark in tsubst_pack_expansion, at cp/pt.cc:13778

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

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

--- Comment #6 from Patrick Palka  ---
*** Bug 109648 has been marked as a duplicate of this bug. ***

[Bug c++/109648] [13/14/15 Regression] ICE: tree check: expected type_pack_expansion or expr_pack_expansion, have error_mark in tsubst_pack_expansion, at cp/pt.cc:13551 since r13-272-gdc6c96f0707aba

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #3 from Patrick Palka  ---
Recently fixed on trunk by r15-1621, so let's call this PR a dup of 115425

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

[Bug target/116103] [15 Regression] GCN vs. "Internal-fn: Only allow modes describe types for internal fn[PR115961]"

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

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

--- Comment #8 from Andrew Stubbs  ---
(In reply to Thomas Schwinge from comment #4)
> (In reply to Richard Biener from comment #2)
> >   if (VECTOR_BOOLEAN_TYPE_P (type)
> >   && SCALAR_INT_MODE_P (TYPE_MODE (type)))
> > return true;
> 
> >   && TYPE_PRECISION (TREE_TYPE (type)) == 1
> 
> > Thomas, does that resolve the issue?
> 
> Thanks, it does: restores the original '*.s' exactly.  (Assuming that's the
> desired outcome, Andrew?)

It looks like while_ult is being rejected ... we really do want that!

[Bug c/116130] Implement C23 N2956 paper - [[unsequenced]] and [[reproducible]] function type arguments

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=32911
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-07-29

--- Comment #3 from Andrew Pinski  ---
.

[Bug c/116130] Implement C23 N2956 paper - [[unsequenced]] and [[reproducible]] function type arguments

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/113860] SVE popcount can be used for 16bit, 32bit and 64bit

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug fortran/116128] missed optimisation: fortran sum instrinsic performed in order

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
   Severity|normal  |enhancement
   Keywords||missed-optimization

[Bug tree-optimization/24379] gcc.dg/ipa/ipa-5.c fails

[natmari6117 at gmail dot com via Gcc-bugs]

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

Emma Kivimaki  changed:

   What|Removed |Added

 CC||natmari6117 at gmail dot com

--- Comment #3 from Emma Kivimaki  ---
Confirmed. https://12efv.weebly.com https://1grth.weebly.com
https://2fsds.weebly.com https://32qr3g.weebly.com https://3gfdr.weebly.com
https://3ghgs.weebly.com https://45n5b.weebly.com https://45tgd.weebly.com
https://56yrh.weebly.com https://5fnhbv.weebly.com https://5htfn.weebly.com
https://5htrt.weebly.com https://5ygrbd.weebly.com https://5ytdg.weebly.com
https://6bfy5.weebly.com https://6g5bh.weebly.com https://6hybn.weebly.com
https://6hyrt.weebly.com https://7hf6b.weebly.com https://87gggr.weebly.com
https://87tgfn.weebly.com https://8hfbf.weebly.com https://9hyff.weebly.com
https://aaqsw.weebly.com https://aatkt.weebly.com https://adesee.weebly.com
https://adsnfsd.weebly.com https://adwfr.weebly.com https://adwht.weebly.com
https://aefscc.weebly.com https://aesgb.weebly.com https://aesgr.weebly.com
https://aesgry.weebly.com https://aesjy.weebly.com https://aetnv.weebly.com
https://af1sg.weebly.com https://afbewd.weebly.com https://afeqg.weebly.com
https://afgbu.weebly.com https://afwesgr.weebly.com
https://ahmetcapsiz.weebly.com https://aktapot.weebly.com
https://alievi.weebly.com https://alinki.weebly.com https://anlayis.weebly.com
https://annsns.weebly.com https://aramaka.weebly.com https://athirs.weebly.com
https://atumgu.weebly.com https://awaol.weebly.com https://awdpb.weebly.com
https://awesg.weebly.com https://awfevn.weebly.com https://awhtu.weebly.com
https://awlpv.weebly.com https://ayrl1k.weebly.com https://babtra.weebly.com
https://bagimsiz.weebly.com https://baltamaksut.weebly.com
https://basarisiz.weebly.com https://batnly.weebly.com https://bawpl.weebly.com
https://baysis.weebly.com https://bbdfd.weebly.com https://bbsbb.weebly.com
https://bbtyb.weebly.com https://bcgnhmm.weebly.com https://bcuty.weebly.com
https://bcxzre.weebly.com https://bddty.weebly.com https://bdfny.weebly.com
https://bdnfsr.weebly.com https://bdntfy.weebly.com https://bdrsa.weebly.com
https://bdt76.weebly.com https://bdtfv.weebly.com https://bdtnb.weebly.com
https://bdtndrs.weebly.com https://bdy4d.weebly.com
https://benimkilermi.weebly.com https://berebv.weebly.com
https://bern4.weebly.com https://besincisigeldi.weebly.com
https://beszza.weebly.com https://beuny.weebly.com https://bf54e.weebly.com
https://bfcnn.weebly.com https://bfdtr.weebly.com https://bfnss.weebly.com
https://bfnyre.weebly.com https://bft56v.weebly.com https://bft5b.weebly.com
https://bftuj.weebly.com https://bfy76.weebly.com https://bgnewr.weebly.com
https://bgrfx.weebly.com https://bgtrce.weebly.com https://bildircin.weebly.com
https://birinc.weebly.com https://bizidik.weebly.com https://bnft4.weebly.com
https://bntfrd.weebly.com https://bnyfr.weebly.com https://bnyresx.weebly.com
https://bolees.weebly.com https://br4tb.weebly.com https://brddrb.weebly.com
https://brdyub.weebly.com https://brebgf.weebly.com https://brht6.weebly.com
https://brtbbt.weebly.com https://brtol.weebly.com https://btdfny.weebly.com
https://btfylm.weebly.com https://btfyn.weebly.com https://bthyt65.weebly.com
https://btnfo.weebly.com https://btnrsr.weebly.com https://btnytd.weebly.com
https://btrece.weebly.com https://btrnyv.weebly.com https://btuht.weebly.com
https://btydr.weebly.com https://btynb.weebly.com https://btynu9.weebly.com
https://bu4nis.weebly.com https://buissonu.weebly.com
https://bulusuz.weebly.com https://bulutus.weebly.com
https://bunlarbeles.weebly.com https://butbh.weebly.com
https://bwevs.weebly.com https://bwwrd.weebly.com https://bxpam.weebly.com
https://bygdy.weebly.com https://bytty.weebly.com https://bzdrb.weebly.com
https://cabucak.weebly.com https://caepu.weebly.com https://caesas.weebly.com
https://caeyb.weebly.com https://canisi.weebly.com https://canylm.weebly.com
https://casdv.weebly.com https://cbezb.weebly.com https://cbtbv.weebly.com
https://cbtubr.weebly.com https://ccemcm.weebly.com https://ccsvrb.weebly.com
https://cdeab.weebly.com https://cdlrd.weebly.com https://cebiink.weebly.com
https://cekteli.weebly.com https://celimsiz.weebly.com
https://cem1001.weebly.com https://cem1002.weebly.com
https://cem1003.weebly.com https://cem1004.weebly.com
https://cem1005.weebly.com https://cem1006.weebly.com
https://cem1007.weebly.com https://cem1008.weebly.com
https://cem1009.weebly.com https://cem1010.weebly.com
https://cem1011.weebly.com https://cem1012.weebly.com
https://cem1013.weebly.com https://cem1014.weebly.com
https://cem1015.weebly.com https://cem1016.weebly.com
https://cem1017.weebly.com https://cem1018.weebly.com
https://cem1019.weebly.com https://cem1020.weebly.com
https://cem1021.weebly.com https://cem1022.weebly.com
https://cem1023.weebly.com https://cem1024.weebly.com
https://cem1025.weebly.com https:

[Bug ada/24381] Error in visibility rules of formal generic packages

[natmari6117 at gmail dot com via Gcc-bugs]

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

Emma Kivimaki  changed:

   What|Removed |Added

 CC||natmari6117 at gmail dot com

--- Comment #2 from Emma Kivimaki  ---
Compiles cleanly on trunk https://5pa660.weebly.com https://5pa661.weebly.com
https://5pa662.weebly.com https://5pa663.weebly.com https://5pa664.weebly.com
https://5pa665.weebly.com https://5pa666.weebly.com https://5pa667.weebly.com
https://5pa668.weebly.com https://5pa669.weebly.com https://5pa670.weebly.com
https://5pa671.weebly.com https://5pa672.weebly.com https://5pa673.weebly.com
https://5pa674.weebly.com https://5pa675.weebly.com https://5pa676.weebly.com
https://5pa677.weebly.com https://5pa678.weebly.com https://5pa679.weebly.com
https://5pa680.weebly.com https://5pa681.weebly.com https://5pa682.weebly.com
https://5pa683.weebly.com https://5pa684.weebly.com https://5pa685.weebly.com
https://5pa686.weebly.com https://5pa687.weebly.com https://5pa688.weebly.com
https://5pa689.weebly.com https://5pa690.weebly.com https://5pa691.weebly.com
https://5pa692.weebly.com https://5pa693.weebly.com https://5pa694.weebly.com
https://5pa695.weebly.com https://5oa546.weebly.com https://5oa547.weebly.com
https://5oa548.weebly.com https://5oa549.weebly.com https://5oa550.weebly.com
https://5oa551.weebly.com https://5oa552.weebly.com https://5oa553.weebly.com
https://5oa554.weebly.com https://5oa555.weebly.com https://5oa556.weebly.com
https://5oa557.weebly.com https://5oa558.weebly.com https://5oa559.weebly.com
https://5oa560.weebly.com https://5oa561.weebly.com https://5oa562.weebly.com
https://5oa563.weebly.com https://5oa564.weebly.com https://5oa565.weebly.com
https://5oa566.weebly.com https://5oa567.weebly.com https://5oa568.weebly.com
https://5oa569.weebly.com https://5oa570.weebly.com https://5oa571.weebly.com
https://5oa572.weebly.com https://5oa573.weebly.com https://5oa574.weebly.com
https://5oa575.weebly.com https://5oa576.weebly.com https://5oa577.weebly.com
https://5oa578.weebly.com https://5oa579.weebly.com https://5oa580.weebly.com
https://5oa581.weebly.com https://5oa582.weebly.com https://5oa583.weebly.com
https://5oa584.weebly.com https://5oa585.weebly.com https://5oa586.weebly.com
https://5oa587.weebly.com https://5oa588.weebly.com https://5oa589.weebly.com
https://5oa590.weebly.com https://5oa591.weebly.com https://5oa592.weebly.com
https://5oa593.weebly.com https://5oa594.weebly.com https://5oa595.weebly.com
https://3bd946.weebly.com https://3bd947.weebly.com https://3bd948.weebly.com
https://3bd949.weebly.com https://3bd950.weebly.com https://3bd951.weebly.com
https://3bd952.weebly.com https://3bd953.weebly.com https://3bd954.weebly.com
https://3bd955.weebly.com https://3bd956.weebly.com https://3bd957.weebly.com
https://3bd958.weebly.com https://3bd959.weebly.com https://3bd960.weebly.com
https://3bd961.weebly.com https://3bd962.weebly.com https://3bd963.weebly.com
https://3bd964.weebly.com https://3bd965.weebly.com https://3bd966.weebly.com
https://3bd967.weebly.com https://3bd968.weebly.com https://3bd969.weebly.com
https://3bd970.weebly.com https://3bd971.weebly.com https://3bd972.weebly.com
https://3bd973.weebly.com https://3bd974.weebly.com https://3bd975.weebly.com
https://3bd976.weebly.com https://3bd977.weebly.com https://3bd978.weebly.com
https://3bd979.weebly.com https://3bd980.weebly.com https://3bd981.weebly.com
https://3bd982.weebly.com https://3bd983.weebly.com https://3bd984.weebly.com
https://3bd985.weebly.com https://3bd986.weebly.com https://3bd987.weebly.com
https://3bd988.weebly.com https://3bd989.weebly.com https://3bd990.weebly.com
https://3bd991.weebly.com https://3bd992.weebly.com https://3bd993.weebly.com
https://3bd994.weebly.com https://3bd995.weebly.com https://4ns146.weebly.com
https://4ns147.weebly.com https://4ns148.weebly.com https://4ns149.weebly.com
https://4ns150.weebly.com https://4ns151.weebly.com https://4ns152.weebly.com
https://4ns153.weebly.com https://4ns154.weebly.com https://4ns155.weebly.com
https://4ns156.weebly.com https://4ns157.weebly.com https://4ns158.weebly.com
https://4ns159.weebly.com https://4ns160.weebly.com https://4ns161.weebly.com
https://4ns162.weebly.com https://4ns163.weebly.com https://4ns164.weebly.com
https://4ns165.weebly.com https://4ns166.weebly.com https://4ns167.weebly.com
https://4ns168.weebly.com https://4ns169.weebly.com https://4ns170.weebly.com
https://4ns171.weebly.com https://4ns172.weebly.com https://4ns173.weebly.com
https://4ns174.weebly.com https://4ns175.weebly.com https://4ns176.weebly.com
https://4ns177.weebly.com https://4ns178.weebly.com https://4ns179.weebly.com
https://4ns180.weebly.com https://4ns181.weebly.com https://4ns182.weebly.com
https://4ns183.weebly.com https://4ns184.weebly.com https://4ns185.weebly.com
https://4ns186.weebly.com https://4ns187.weebly.com https://4ns188.wee

[Bug libffi/24388] Assembler error building libffi

[natmari6117 at gmail dot com via Gcc-bugs]

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

Emma Kivimaki  changed:

   What|Removed |Added

 CC||natmari6117 at gmail dot com

--- Comment #2 from Emma Kivimaki  ---
Java is not supported on AIX. https://micir274.weebly.com
https://micir275.weebly.com https://micir276.weebly.com
https://micir277.weebly.com https://micir278.weebly.com
https://micir279.weebly.com https://micir280.weebly.com
https://micir281.weebly.com https://micir282.weebly.com
https://micir283.weebly.com https://micir284.weebly.com
https://micir285.weebly.com https://micir286.weebly.com
https://micir287.weebly.com https://micir288.weebly.com
https://micir289.weebly.com https://micir290.weebly.com
https://micir291.weebly.com https://micir292.weebly.com
https://micir293.weebly.com https://micir294.weebly.com
https://micir295.weebly.com https://cfmqx146.weebly.com
https://cfmqx147.weebly.com https://cfmqx148.weebly.com
https://cfmqx149.weebly.com https://cfmqx150.weebly.com
https://cfmqx151.weebly.com https://cfmqx152.weebly.com
https://cfmqx153.weebly.com https://cfmqx154.weebly.com
https://cfmqx155.weebly.com https://cfmqx156.weebly.com
https://cfmqx157.weebly.com https://cfmqx158.weebly.com
https://cfmqx159.weebly.com https://cfmqx160.weebly.com
https://cfmqx161.weebly.com https://cfmqx162.weebly.com
https://cfmqx163.weebly.com https://cfmqx164.weebly.com
https://cfmqx165.weebly.com https://cfmqx166.weebly.com
https://cfmqx167.weebly.com https://cfmqx168.weebly.com
https://cfmqx169.weebly.com https://cfmqx170.weebly.com
https://cfmqx171.weebly.com https://cfmqx172.weebly.com
https://cfmqx173.weebly.com https://cfmqx174.weebly.com
https://cfmqx175.weebly.com https://cfmqx176.weebly.com
https://cfmqx177.weebly.com https://cfmqx178.weebly.com
https://cfmqx179.weebly.com https://cfmqx180.weebly.com
https://cfmqx181.weebly.com https://cfmqx182.weebly.com
https://cfmqx183.weebly.com https://cfmqx184.weebly.com
https://cfmqx185.weebly.com https://cfmqx186.weebly.com
https://cfmqx187.weebly.com https://cfmqx188.weebly.com
https://cfmqx189.weebly.com https://cfmqx190.weebly.com
https://cfmqx191.weebly.com https://cfmqx192.weebly.com
https://cfmqx193.weebly.com https://cfmqx194.weebly.com
https://cfmqx195.weebly.com https://zpzpb146.weebly.com
https://zpzpb147.weebly.com https://zpzpb148.weebly.com
https://zpzpb149.weebly.com https://zpzpb150.weebly.com
https://zpzpb151.weebly.com https://zpzpb152.weebly.com
https://zpzpb153.weebly.com https://zpzpb154.weebly.com
https://zpzpb155.weebly.com https://zpzpb156.weebly.com
https://zpzpb157.weebly.com https://zpzpb158.weebly.com
https://zpzpb159.weebly.com https://zpzpb160.weebly.com
https://zpzpb161.weebly.com https://zpzpb162.weebly.com
https://zpzpb163.weebly.com https://zpzpb164.weebly.com
https://zpzpb165.weebly.com https://zpzpb166.weebly.com
https://zpzpb167.weebly.com https://zpzpb168.weebly.com
https://zpzpb169.weebly.com https://zpzpb170.weebly.com
https://zpzpb171.weebly.com https://zpzpb172.weebly.com
https://zpzpb173.weebly.com https://zpzpb174.weebly.com
https://zpzpb175.weebly.com https://zpzpb176.weebly.com
https://zpzpb177.weebly.com https://zpzpb178.weebly.com
https://zpzpb179.weebly.com https://zpzpb180.weebly.com
https://zpzpb181.weebly.com https://zpzpb182.weebly.com
https://zpzpb183.weebly.com https://zpzpb184.weebly.com
https://zpzpb185.weebly.com https://zpzpb186.weebly.com
https://zpzpb187.weebly.com https://zpzpb188.weebly.com
https://zpzpb189.weebly.com https://zpzpb190.weebly.com
https://zpzpb191.weebly.com https://zpzpb192.weebly.com
https://zpzpb193.weebly.com https://zpzpb194.weebly.com
https://zpzpb195.weebly.com https://pzpzm146.weebly.com
https://pzpzm147.weebly.com https://pzpzm148.weebly.com
https://pzpzm149.weebly.com https://pzpzm150.weebly.com
https://pzpzm151.weebly.com https://pzpzm152.weebly.com
https://pzpzm153.weebly.com https://pzpzm154.weebly.com
https://pzpzm155.weebly.com https://pzpzm156.weebly.com
https://pzpzm157.weebly.com https://pzpzm158.weebly.com
https://pzpzm159.weebly.com https://pzpzm160.weebly.com
https://pzpzm161.weebly.com https://pzpzm162.weebly.com
https://pzpzm163.weebly.com https://pzpzm164.weebly.com
https://pzpzm165.weebly.com https://pzpzm166.weebly.com
https://pzpzm167.weebly.com https://pzpzm168.weebly.com
https://pzpzm169.weebly.com https://pzpzm170.weebly.com
https://pzpzm171.weebly.com https://pzpzm172.weebly.com
https://pzpzm173.weebly.com https://pzpzm174.weebly.com
https://pzpzm175.weebly.com https://pzpzm176.weebly.com
https://pzpzm177.weebly.com https://pzpzm178.weebly.com
https://pzpzm179.weebly.com https://pzpzm180.weebly.com
https://pzpzm181.weebly.com https://pzpzm182.weebly.com
https://pzpzm183.weebly.com https://pzpzm184.weebly.com
https://pzpzm185.weebly.com https://pzpzm186.weebly.com
https://pzpzm187.weebly.com https://pzpzm188.weebly.com
https://pzpzm189.weebl

[Bug middle-end/115277] [13 regression] ICF needs to match loop bound estimates

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Sam James :

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

commit r15-2383-gca255ca2760a5e6176031ea62a9c29c7bb92c212
Author: Sam James 
Date:   Mon Jul 29 16:47:09 2024 +0100

testsuite: make PR115277 test an execute one

PR middle-end/115277
* gcc.c-torture/compile/pr115277.c: Rename to...
* gcc.c-torture/execute/pr115277.c: ...this.

[Bug target/97276] A whole if-block is ignored by avr-gcc 9.3.0

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

[Bug target/116131] New: [14/15 Regression] RISC-V: Unrecognizable insn with xtheadmemidx

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 116131
   Summary: [14/15 Regression] RISC-V: Unrecognizable insn with
xtheadmemidx
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
volatile long long a;
int b;
int c[1];
void d() { c[a] = b; }

Command/backtrace:
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -march=rv32ixtheadmemidx -mabi=ilp32 -O1 red.c -c -S -o /dev/null
red.c: In function 'd':
red.c:4:22: error: unrecognizable insn:
4 | void d() { c[a] = b; }
  |  ^
(insn 17 13 0 2 (set (mem:SI (plus:SI (reg/f:SI 141)
(ashift:SI (subreg:SI (reg:DI 134 [ a.0_1 ]) 0)
(const_int 2 [0x2]))) [0  S4 A32])
(reg:SI 143 [ b ])) "red.c":4:17 -1
 (nil))
during RTL pass: subreg3
red.c:4:22: internal compiler error: in extract_insn, at recog.cc:2848
0x2ddf545 internal_error(char const*, ...)
../../../gcc/gcc/diagnostic-global-context.cc:491
0xc4f10e fancy_abort(char const*, int, char const*)
../../../gcc/gcc/diagnostic.cc:1755
0xae2985 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../../gcc/gcc/rtl-error.cc:108
0xae29a7 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../../gcc/gcc/rtl-error.cc:116
0xae125b extract_insn(rtx_insn*)
../../../gcc/gcc/recog.cc:2848
0x2800737 decompose_multiword_subregs
../../../gcc/gcc/lower-subreg.cc:1584
0x28016f1 execute
../../../gcc/gcc/lower-subreg.cc:1849
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.


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

Found via fuzzer.

[Bug other/116132] New: New test case gfortran.dg/pr105361.f90 from r15-2320-g3aeb697a2158d3 fails intermittently

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

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

Bug ID: 116132
   Summary: New test case gfortran.dg/pr105361.f90 from
r15-2320-g3aeb697a2158d3 fails intermittently
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

I am seeing intermittent failure of the test case gfortran.dg/pr105361.f90 for
both powerpc64 BE and LE.

At line 33 of file
/home/seurer/gcc/git/gcc-trunk/gcc/testsuite/gfortran.dg/pr105361.f90 (unit =
10, file = 'fort.10')
Fortran runtime error: Bad real number in item 2 of list input

Error termination. Backtrace:
#0  0x7fff7ed9d42f in read_real
at /home/seurer/gcc/git/gcc-trunk/libgfortran/io/list_read.c:2080
#1  0x7fff7ed9edaf in list_formatted_read_scalar
at /home/seurer/gcc/git/gcc-trunk/libgfortran/io/list_read.c:2236
#2  0x1f93 in MAIN__
at
/home/seurer/gcc/git/gcc-trunk/gcc/testsuite/gfortran.dg/pr105361.f90:33
#3  0x1c63 in main
at
/home/seurer/gcc/git/gcc-trunk/gcc/testsuite/gfortran.dg/pr105361.f90:25
FAIL: gfortran.dg/pr105361.f90   -O3 -g  execution test


It first showed up in a make check run against
3aeb697a2158d359d9f951f6c6c6bcd9c53c8c2f, r15-2320-g3aeb697a2158d3

Which is where the test was actually added:

commit 3aeb697a2158d359d9f951f6c6c6bcd9c53c8c2f
Author: Jerry DeLisle 
Date:   Wed Jul 24 10:29:08 2024 -0700

* gfortran.dg/pr105361.f90: New test.

[Bug other/116119] Error building gcc 8.3.0

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

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

--- Comment #12 from Jonathan Wakely  ---
I can build fine using these steps:

  export TARGET=arm-linux-gnueabihf
  export PREFIX=/tmp/rpi-toolchain
  wget https://ftp.gnu.org/gnu/binutils/binutils-2.31.tar.gz
  tar xf binutils-2.31.tar.gz 
  cd bobj
  ../binutils-2.31/configure --target=${TARGET} --prefix=${PREFIX}
--with-arch=armv8-a --with-fpu=vfp --with-float=hard --disable-multilib
  make -j10 && make install
  cd ../
  ~/src/gcc/gcc-8/configure --prefix=${PREFIX} --target=${TARGET} 
--enable-languages=c,c++ --disable-multilib --enable-multiarch
--with-arch=armv8-a --with-fpu=vfp --with-float=hard
  make all-gcc -j10 

Where ~/src/gcc/gcc-8 contains the gcc-8.5.0 sources and gmp, mpfr and mpc
sources.

I don't have a sysroot, so I can't build libgcc and the rest of the compiler,
but I don't get an error from configure-gmp like in comment 7. My build gets
past that without problems. So you must be doing something differently.

Start again. Remove the entire working directory that you're building in, as
it's clearly messed up (see comment 11, with the error taken from the logs in
comment 6).

Build and install binutils first.
Use contrib/download_prerequisites after un-tarring the gcc sources.
Build and install gcc.

Don't reconfigure in the same directory where you've already got a failed build
using a different configuration. Don't mess with LD_LIBRARY_PATH.
Use gcc-8.5.0 not 8.3.0 because it has various bugs fixed (probably nothing
relevant to your problem, it's just a better release).

The instructions you're following seem broken:

cd ~/rpi0/toolchain/sources/gcc-8.3.0
contrib/download_prerequisites
mkdir -p ../../build/gcc2
pushd build/gcc2
  ^^ that's not the directory that was just created, should be
../../

../../src/gcc-8.3.0/configure
  ^^^ that's not where the sources are, should be sources not src

[Bug tree-optimization/95852] Failure to optimize __builtin_mul_overflow pattern

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug tree-optimization/116133] New: Missing mult_overflow detection for aarch64

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

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

Bug ID: 116133
   Summary: Missing mult_overflow detection for aarch64
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-linux-gnu

Using the testcase from PR 95852:
```
bool f(unsigned x, unsigned y, unsigned* res)
{
*res = x * y;
return x && ((*res / x) != y);
}
```

This should be optimized to just:
```
  _14 = (int) x_7(D);
  _15 = (int) y_8(D);
  _16 = .MUL_OVERFLOW (_14, _15);
  _17 = REALPART_EXPR <_16>;
  _1 = (unsigned int) _17;
  _18 = IMAGPART_EXPR <_16>;
  *res_10(D) = _1;
  _12 = _18 != 0;
  _13 = (int) _12;
```

Like it is on x86_64 But it looks like widening multiply is not considered if
MUL_OVERFLOW will be better than the original IR.

[Bug tree-optimization/116133] Missing mult_overflow detection for aarch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
```
  || (code == MULT_EXPR
  && optab_handler (cast_stmt ? mulv4_optab : umulv4_optab,
TYPE_MODE (type)) == CODE_FOR_nothing
  && (use_seen
  || cast_stmt
  || !can_mult_highpart_p (TYPE_MODE (type), true
```

This misses that we could also handle it via [us]mul_widen_optab too.

[Bug tree-optimization/116133] Missing mult_overflow detection for aarch64

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

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

--- Comment #2 from Andrew Pinski  ---
The check in internal-fn.cc is:
  if (GET_MODE_2XWIDER_MODE (mode).exists (&wmode)
  && targetm.scalar_mode_supported_p (wmode)
  && can_widen_mult_without_libcall (wmode, mode, op0, op1, uns))

Oh can_widen_mult_without_libcall does test [us]mul_widen_optab first and then
if that fails see if we could use the widen mul_opt. for the right now we
should just test [us]mul_widen_optab .

[Bug middle-end/116134] New: [15 Regression] ICE: 'verify_gimple' failed

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 116134
   Summary: [15 Regression] ICE: 'verify_gimple' failed
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
int a;
int b;
int d;
void c() { 1UL <= (d < b) != (1UL & (0 < a | 0L)); }


Command/backtrace:
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
>  red.c -c -S -o /dev/null
red.c: In function 'c':
red.c:4:6: error: type mismatch in binary expression
4 | void c() { 1UL <= (d < b) != (1UL & (0 < a | 0L)); }
  |  ^
unsigned int

unsigned int

long int

_8 = _4 ^ _7;
red.c:4:6: internal compiler error: 'verify_gimple' failed
0x2ddf545 internal_error(char const*, ...)
../../../gcc/gcc/diagnostic-global-context.cc:491
0x13d8775 verify_gimple_in_seq(gimple*, bool)
../../../gcc/gcc/tree-cfg.cc:5332
0x104825b gimplify_body(tree_node*, bool)
../../../gcc/gcc/gimplify.cc:19460
0x10483e9 gimplify_function_tree(tree_node*)
../../../gcc/gcc/gimplify.cc:19578
0xe50607 cgraph_node::analyze()
../../../gcc/gcc/cgraphunit.cc:687
0xe52c17 analyze_functions
../../../gcc/gcc/cgraphunit.cc:1251
0xe53961 symbol_table::finalize_compilation_unit()
../../../gcc/gcc/cgraphunit.cc:2560
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.

Godbolt:
riscv: https://godbolt.org/z/5ncqjTvs3
x86: https://godbolt.org/z/sbW96d97v

Found via fuzzer.

[Bug c++/116019] Incorrect cannot-tail messages on targets

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

Andi Kleen  changed:

   What|Removed |Added

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

--- Comment #3 from Andi Kleen  ---
Patch was reverted, it just made a bunch of tests unsupported.

problems:
- Need unique name for each new test to not confuse the caching
- -O0 tests need to use musttail explictly because the musttail pass
only handles musttail annotated returns.

[Bug middle-end/116134] [15 Regression] ICE: 'verify_gimple' failed

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2024-07-29
   Target Milestone|--- |15.0
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

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

[Bug c++/116019] Incorrect cannot-tail messages on targets

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

Andi Kleen  changed:

   What|Removed |Added

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

--- Comment #4 from Andi Kleen  ---
Reopened the wrong bug

[Bug middle-end/116134] [15 Regression] ICE: 'verify_gimple' failed

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

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

--- Comment #2 from Andrew Pinski  ---
Caused by r15-2106-g44fcc1ca11e7ea .

[Bug testsuite/116080] [15 regression] New tests from r15-2233-g8d1af8f904a0c0 fail

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

--- Comment #8 from Andi Kleen  ---
Patch was reverted, it just made a bunch of tests unsupported.

problems:
- Need unique name for each new test to not confuse the caching
- -O0 tests need to use musttail explictly because the musttail pass
only handles musttail annotated returns.

[Bug middle-end/116134] [15 Regression] ICE: 'verify_gimple' failed since r15-2106-g44fcc1ca11e7ea

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

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

--- Comment #3 from Andrew Pinski  ---
Caused by r15-2106-g44fcc1ca11e7ea .

Generic is a pain when it comes to types of comparisons, they are not always
bool (or vector bool for vector comparisons).

[Bug libfortran/105361] Incorrect end-of-file condition for derived-type I/O

[ewlu at rivosinc dot com via Gcc-bugs]

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

Edwin Lu  changed:

   What|Removed |Added

 CC||ewlu at rivosinc dot com

--- Comment #10 from Edwin Lu  ---
(In reply to Thomas Schwinge from comment #9)
> In some of my test runs (have not yet been able to deduce any pattern), I'm
> seeing this new test case FAIL its execution test:
> 
> At line 33 of file
> [...]/source-gcc/gcc/testsuite/gfortran.dg/pr105361.f90 (unit = 10, file =
> 'fort.10')
> Fortran runtime error: Bad real number in item 2 of list input
> 
> Error termination. Backtrace:
> #0  0xf7f114e1 in read_real
> at [...]/source-gcc/libgfortran/io/list_read.c:2080
> #1  0xf7f12a87 in list_formatted_read_scalar
> at [...]/source-gcc/libgfortran/io/list_read.c:2236
> #2  0xf7f182bd in wrap_scalar_transfer
> at [...]/source-gcc/libgfortran/io/transfer.c:2591
> #3  0x8049486 in ???
> #4  0x8049695 in ???
> #5  0xf7996ed4 in ???
> #6  0x8049155 in ???
> #7  0x in ???
> 
> There also appear to be similar "twinkling" PASS <-> FAIL reports in
>  posts.

I also see this appear to be flakey on riscv targets as well, albeit with a
longer and more unreadable backtrace

At line 33 of file
/disk-1/github/patrick-postcommit-3/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/gcc/gcc/testsuite/gfortran.dg/pr105361.f90
(unit = 10, file = 'fort.10')
Fortran runtime error: Bad real number in item 2 of list input

Error termination. Backtrace:
#0  0x2b2eebe9 in ???
#1  0x2b2ef469 in ???
#2  0x2b2efac9 in ???
#3  0x2b380bff in ???
#4  0x2b381c1b in ???
#5  0x2b3824ed in ???
#6  0x10a53 in ???
#7  0x10bc7 in ???
#8  0x2b4bc901 in ???
#9  0x2b4bc997 in ???
#10  0x107cb in ???
#11  0x in ???

Full list of our results can be found here:
https://github.com/patrick-rivos/gcc-postcommit-ci/issues?q=FAIL%3A+gfortran.dg%2Fpr105361.f90

[Bug c/116130] Implement C23 N2956 paper - [[unsequenced]] and [[reproducible]] function type arguments

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

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

--- Comment #4 from Jakub Jelinek  ---
BTW, the rule about composite types sounds fairly dangerous in the ?: operator
case.
For redeclarations it is the right thing, but for ?: yielding the union of the
standard attributes will cause problems say on:
int foo (int);
[[unsequenced]] int bar (int);

int
baz (int x, int y)
{
  int a = (y ? &foo : &bar) (x);
  int b = (y ? &foo : &bar) (x);
  return a + b;
}

[Bug testsuite/116080] [15 regression] New tests from r15-2233-g8d1af8f904a0c0 fail

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

Andi Kleen  changed:

   What|Removed |Added

  Attachment #58761|0   |1
is obsolete||

--- Comment #9 from Andi Kleen  ---
Created attachment 58773
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58773&action=edit
New test suite fixes

[Bug c/116130] Implement C23 N2956 paper - [[unsequenced]] and [[reproducible]] function type arguments

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

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

--- Comment #5 from Sam James  ---
(In reply to Jakub Jelinek from comment #4)
> BTW, the rule about composite types sounds fairly dangerous in the ?:
> operator case.
> For redeclarations it is the right thing, but for ?: yielding the union of
> the standard attributes will cause problems say on:

Clang had this problem before with noreturn in
https://github.com/llvm/llvm-project/issues/59792#issuecomment-1369314436.

https://reviews.llvm.org/D140868#4024060 has discussion of the problematic
phrasing.

[Bug c/116130] Implement C23 N2956 paper - [[unsequenced]] and [[reproducible]] function type arguments

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

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

--- Comment #6 from Sam James  ---
(In reply to Sam James from comment #5)

I brought it up at
https://social.treehouse.systems/@thesamesam/110148110341108345 too where
[[unsequenced]] and [[reproducible]]  were mentioned.

[Bug c/116130] Implement C23 N2956 paper - [[unsequenced]] and [[reproducible]] function type arguments

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

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

--- Comment #7 from Jakub Jelinek  ---
Seems we actually implement it that way already, or at least sometimes.
build_conditional_expr has
  /* Quickly detect the usual case where op1 and op2 have the same type
 after promotion.  */
  if (TYPE_MAIN_VARIANT (type1) == TYPE_MAIN_VARIANT (type2))
{
  if (type1 == type2)
result_type = type1;
  else
result_type = TYPE_MAIN_VARIANT (type1);
}
which would do the wrong thing and
  else if (code1 == POINTER_TYPE && code2 == POINTER_TYPE)
{
...
  if (comp_target_types (colon_loc, type1, type2))
result_type = common_pointer_type (type1, type2);
which would merge them.
All I want to say is that there are big chances of this breaking real-world
code if somebody decides to add the new standard attributes to decls.

[Bug target/116103] [15 Regression] GCN vs. "Internal-fn: Only allow modes describe types for internal fn[PR115961]"

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pan2.li at intel dot com
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Keywords||patch
   Last reconfirmed||2024-07-29

--- Comment #9 from Thomas Schwinge  ---
(In reply to Li Pan from comment #7)
> confirm with you all related failures are covered.

Yes, the testing state is restored to what it was before, thanks!


Before 'git push', please note Richard Sandiford's comment:
.

[Bug tree-optimization/51492] vectorizer does not support saturated arithmetic patterns

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #23 from Uroš Bizjak  ---
Current compiler produces (-O3):

f:
movl$4194368, %edx
movl$head, %eax
movd%edx, %xmm1
pshufd  $0, %xmm1, %xmm1
.L2:
movdqa  (%rax), %xmm0
addq$16, %rax
psubusw %xmm1, %xmm0
movaps  %xmm0, -16(%rax)
cmpq$head+131072, %rax
jne .L2
ret

[Bug target/113484] Add support for _Float16 type on PowerPC

[john_platts at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from John Platts  ---
(In reply to Joseph S. Myers from comment #1)
> It would of course be necessary to define the ABI used for _Float16 (and
> _Complex _Float16) argument passing and return (in each PowerPC ABI for
> which we support use of this feature).

Should scalar _Float16 and _Complex _Float16 function parameters be first
passed in the F1-F13 registers on PPC, following the same rules as float,
double, _Complex _Float, and _Complex double function parameters (and with the
_Float16 function parameters that are passed into F1-F13 be converted to
double-precision floating point)?

Should a scalar _Float16 result be returned in the F1 register on PPC, with the
_Float16 result in the F1 register in double-precision floating point format
(but rounded to the precision and range of a _Float16)?

[Bug c++/88313] generic lambda in default template argument

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:72a7ab891ae0061841c4eb641ef6ab7719bf0369

commit r15-2387-g72a7ab891ae0061841c4eb641ef6ab7719bf0369
Author: Patrick Palka 
Date:   Mon Jul 29 16:37:19 2024 -0400

c++: generic lambda in default template argument [PR88313]

Here we're rejecting the generic lambda inside the default template
argument ultimately because auto_is_implicit_function_template_parm_p
doesn't get set during parsing of the lambda's parameter list, due
to the !processing_template_parmlist restriction.  But when parsing a
lambda parameter list we should always set that flag regardless of where
the lambda appears.  This patch makes sure of this via a local lambda_p
flag.

PR c++/88313

gcc/cp/ChangeLog:

* parser.cc (cp_parser_lambda_declarator_opt): Pass
lambda_p=true to cp_parser_parameter_declaration_clause.
(cp_parser_direct_declarator): Pass lambda_p=false to
to cp_parser_parameter_declaration_clause.
(cp_parser_parameter_declaration_clause): Add bool lambda_p
parameter.  Consider lambda_p instead of current_class_type
when setting parser->auto_is_implicit_function_template_parm_p.
Don't consider processing_template_parmlist.
(cp_parser_requirement_parameter_list): Pass lambda_p=false
to cp_parser_parameter_declaration_clause.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/lambda-targ6.C: New test.

Reviewed-by: Jason Merrill 

[Bug c++/88313] generic lambda in default template argument

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

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 CC||ppalka at gcc dot gnu.org
 Status|NEW |ASSIGNED
   Target Milestone|--- |14.3

[Bug tree-optimization/116120] [15 regression] Wrong code for (a ? x : y) != (b ? x : y) since r15-2106-g44fcc1ca11e7ea35dc9fb25a5317346bc1eaf7b2

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

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

--- Comment #3 from Andrew Pinski  ---
Testing a fix, should be submitted later today.

[Bug middle-end/116134] [15 Regression] ICE: 'verify_gimple' failed since r15-2106-g44fcc1ca11e7ea

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

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

--- Comment #4 from Andrew Pinski  ---
Testing a fix, should be submitted later today.

[Bug ipa/111613] [12/13 Regression] Bit field stores can be incorrectly optimized away when -fstore-merging is in effect since r12-5383-g22c242342e38eb

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

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

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Sam James :

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

commit r15-2388-g5e5d7a88932b132437069f716160f8b20862890b
Author: Sam James 
Date:   Mon Jul 29 21:47:16 2024 +0100

testsuite: fix PR111613 test

PR ipa/111613
* gcc.c-torture/pr111613.c: Rename to..
* gcc.c-torture/execute/pr111613.c: ...this.

[Bug target/113484] Add support for _Float16 type on PowerPC

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

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #3 from Segher Boessenkool  ---
Yup, it needs to be added to the ABI first.  And that is unlikely to get any
priority soon, since bf16 is pretty useless anyway, and we have no instructions
that efficiently round to it.

There are instructions to convert from it (by simply adding a bunch of zero
bits
to the right) (xvcvbf16spn), and more proper conversion to it (from SP)
(xvcvspbf16).

Those are ISA 3.1 insns btw, so POWER10, not POWER9!  What instructions did you
mean?

This isn't good enough to use it as an actual computational type.  It is fine
for
what it is meant for: do all of your computations as SP float, and only load
and
store as bfloat16.  We do have builtin functions to do that already.

[Bug target/113484] Add support for _Float16 type on PowerPC

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

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

--- Comment #4 from Segher Boessenkool  ---
Ah, this was about *actual* half-precision float, which indeed is 3.0 (Power9).

But all the same holds: it needs to be added to the ABI before we can have a
type for it, and it still won't be terribly useful (it will make for *slowe
code*, not using fewer resources either).

[Bug libstdc++/106852] Implement C++23 P2465R3 Standard Library Modules std and std.compat

[ilia.chachanidze24 at gmail dot com via Gcc-bugs]

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

Ilia Chachanidze  changed:

   What|Removed |Added

 CC||ilia.chachanidze24 at gmail 
dot co
   ||m

--- Comment #7 from Ilia Chachanidze  ---
(In reply to m.cencora from comment #6)
> Created attachment 58415 [details]
> C++ std module working with gcc-15 20240609 snapshot
> 
> Attaching an updated version of std module implementation.
> 
> Still TODO:
> 1. #include  - ICE + TBB code is not module friendly due to use
> of anonymous namespaces in header-files (no bug report)
> 2. cannot export operator new/delete (bug #115446, regression)
> 
> Workarounds applied:
> 1. cannot export same function twice (bug #115445, regression)
> 2. cannot export type declared/aliased in different namespace (bug #114685,
> affected are: vector, exception_ptr, lldiv_t, chrono::*_clock)

I have noticed that attached module implementation file is missing exporting of
std::unreachable()

[Bug target/116104] [15 Regression] GCN vs. "[rtl-optimization/116037] Explicitly track if a destination was skipped in ext-dce"

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Jeff Law :

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

commit r15-2390-g5ab9a351247a551c47b0ab9d8e8b907223e7faf6
Author: Jeff Law 
Date:   Mon Jul 29 16:17:25 2024 -0600

[target/116104] Fix test guarding UINTVAL to extract shift count

Minor oversight in the ext-dce bits.  If the shift count is a constant
vector,
then we shouldn't be extracting values with [U]INTVAL.  We guarded that
test
with CONSTANT_P, when it should have been CONSTANT_INT_P.

Shows up on gcn, but I wouldn't be terribly surprised if it could be
triggered
elsewhere.

Verified the testcase compiles on gcn.  Haven't done a libgcc build for gcn
though.  Also verified x86 bootstraps and regression tests cleanly.

Pushing to the trunk.

PR target/116104
gcc/
* ext-dce.cc (carry_backpropagate): Fix test guarding UINTVAL
extraction of shift count.

[Bug target/116104] [15 Regression] GCN vs. "[rtl-optimization/116037] Explicitly track if a destination was skipped in ext-dce"

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

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

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

[Bug target/116131] [14/15 Regression] RISC-V: Unrecognizable insn with xtheadmemidx on rv32

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #1 from Jeffrey A. Law  ---
Looks like non-canonical RTL to me.  Inside a MEM that shift should have been
turned into a multiply.

@item
Within address computations (i.e., inside @code{mem}), a left shift is
converted into the appropriate multiplication by a power of two.

[Bug target/116104] [15 Regression] GCN vs. "[rtl-optimization/116037] Explicitly track if a destination was skipped in ext-dce"

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #8 from Jeffrey A. Law  ---
Actually fix the state this time :-)