[Bug target/106691] Section anchors is not efficient for riscv

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #5 from Jeffrey A. Law  ---
Behaving per design.

[Bug c++/120757] New: ICE: in tsubst, at cp/pt.cc:16787

[rush102333 at gmail dot com via Gcc-bugs]

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

Bug ID: 120757
   Summary: ICE: in tsubst, at cp/pt.cc:16787
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rush102333 at gmail dot com
  Target Milestone: ---

Starts from gcc-13: https://godbolt.org/z/r66becMsx


Test Input:

~~~

template  struct A 
{
  auto foo() {}
};

auto bar(void (A::*)()) {}

template  auto baz()
{
  bar(&A::foo);
}

int main()
{
  baz<0>();
  return 0;
}

~~~

Stack Dump:

~~~

: In instantiation of 'auto baz() [with int  = 0]':
:15:9:   required from here
   15 |   baz<0>();
  |   ~~^~
:10:16: internal compiler error: in tsubst, at cp/pt.cc:16787
   10 |   bar(&A::foo);
  |^~~
0x283a165 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x285b8f6 internal_error(char const*, ...)
???:0
0xae0346 fancy_abort(char const*, int, char const*)
???:0
0xd3cceb tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd5f9cd instantiate_decl(tree_node*, bool, bool)
???:0
0xbe93c3 maybe_instantiate_decl(tree_node*)
???:0
0xbeb137 mark_used(tree_node*, int)
???:0
0xb17e6e build_new_function_call(tree_node*, vec**, int)
???:0
0xd899dc finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0xd07873 c_parse_file()
???:0
0xe6f359 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

~~~

[Bug modula2/120731] Possible error in Strings.Pos causing sigsegv

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

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

commit r16-1608-gfc276742e0db337c4d13e6c474abafd4796a6b69
Author: Gaius Mulley 
Date:   Sun Jun 22 04:13:26 2025 +0100

[PR modula2/120731] error in Strings.Pos causing sigsegv

This patch corrects the m2log library procedure function
Strings.Pos which incorrectly sliced the wrong component
of the source string.  The incorrect slice could cause
a sigsegv if negative slice indices were generated.

gcc/m2/ChangeLog:

PR modula2/120731
* gm2-libs-log/Strings.def (Delete): Rewrite comment.
* gm2-libs-log/Strings.mod (Pos): Rewrite.
(PosLower): New procedure function.

gcc/testsuite/ChangeLog:

PR modula2/120731
* gm2/pimlib/logitech/run/pass/teststrings.mod: New test.

Signed-off-by: Gaius Mulley 

[Bug rtl-optimization/108826] Inefficient address generation on POWER

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|Inefficient address |Inefficient address
   |generation on POWER and |generation on POWER
   |RISC-V  |
 Target|powerpc*, riscv |powerpc*

--- Comment #8 from Jeffrey A. Law  ---
RISC-V seems to be doing the right thing with this issue now.

[Bug target/111623] __sync_synchronize compiler barrier not honored (rv64)

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #2 from Jeffrey A. Law  ---
Testcase is no longer available.  If this is still a problem we will need to
get a fresh bug opened.

[Bug target/115759] RISC-V: complex code generated for lmbench's fwr when uses scalable autovec

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #2 from Jeffrey A. Law  ---
Given the size of the stride, it's more likely to be unprofitable since it's
going to be hitting different cache lines.  While not every uarch will be
sensitive to the size of the stride, it is a consideration.

I'd tend to agree with Juzhe though. This is behaving as designed and as
designs with more powerful load/store units become available we can always come
back and reevaluate.

Demin, if you have evidence the LLVM style code generation is better on a
design, then please chime in and reopen.

[Bug target/120683] vector_loop/unrolled_loop generates poor codes on memset/memcpy

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/120719] __builtin_rev_crc32_data8() should revert to __builtin_ia32_crc32qi() when available

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-06-22
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed. the backend needs some crc expanders added.

[Bug middle-end/120732] simd attribute needs better documentation when dealing with memory loops and C++

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Compiler doesn't generate a |simd attribute needs better
   |call to a vector function   |documentation when dealing
   ||with memory loops and C++
   Keywords||documentation
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
I think the documentation for the simd attribute needs to be improved.
To make a mention that the function needs no extra side effects besides return
a value and not writing and not reading outside memory. Otherwise you might get
the side effect out of order.
The reading outside memory is only needs to not happen if the loop that is
getting vectorized has not escaped (which it has in your case).

So the definition of square should be:
```
__attribute__ ((__simd__ ("notinbranch"), const, nothrow)) 
double square(double x);
```

And then GCC does the right thing.

[Bug rtl-optimization/120745] SEGV in process_uses_of_deleted_def, at rtl-ssa/changes.cc:271

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

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

--- Comment #1 from Andrew Pinski  ---
I am not sure bugzilla is the right place to ask for help while working on a
patch/pass; the gcc@ mailing list is where that normally takes place.

[Bug target/120736] [15/16 Regression] RISC-V: Miscompile at -O[23] since r15-5375-gbeec291225b

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.2
Summary|[16 Regression] RISC-V: |[15/16 Regression] RISC-V:
   |Miscompile at -O[23] since  |Miscompile at -O[23] since
   |r15-5375-gbeec291225b   |r15-5375-gbeec291225b

[Bug c++/120758] Empty initializer list (`{}`) incorrectly deduces an array size for array reference parameter

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2025-06-22

--- Comment #2 from Andrew Pinski  ---
GCC 4.8.x used to accept the code.
GCC 4.9.0 started to reject the code and produce the bad diagnostic.

clang and MSVC accepts the code but as I mentioned EDG rejects it for what
seems like a similar reason as GCC.

[Bug c++/120758] Empty initializer list (`{}`) incorrectly deduces an array size for array reference parameter

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

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

--- Comment #1 from Andrew Pinski  ---
EDG also rejects this code.

[Bug modula2/120761] New: GM2_FOR_BUILD is not substituted in the toplevel Makefile

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

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

Bug ID: 120761
   Summary: GM2_FOR_BUILD is not substituted in the toplevel
Makefile
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: ebotcazou at gcc dot gnu.org
  Target Milestone: ---

The toplevel Makefile contains these lines:

GFORTRAN_FOR_BUILD = $(GFORTRAN)
GOC_FOR_BUILD = $(GOC)
GDC_FOR_BUILD = $(GDC)
GM2_FOR_BUILD = @GM2_FOR_BUILD@

[Bug ada/120106] replace hardcoded gnatmake commands with configuration variables

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

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

--- Comment #4 from Eric Botcazou  ---
> v02 passes GNATMAKE_FOR_BUILD via BASE_TARGET_EXPORT instead of
> EXTRA_TARGET_FLAGS.  Is this less ugly?

Yes, thanks, I'm going to apply it.

[Bug tree-optimization/120752] 5% slowdown of 525.x264_r since r16-1346-gb0d50cbb42ab2c

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

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

--- Comment #3 from Filip Kastl  ---
Created attachment 61681
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61681&action=edit
perf report -n output after Honza's commit

[Bug c++/120756] New: internal compiler error: error reporting routines re-entered with [[deprecated]]

[rush102333 at gmail dot com via Gcc-bugs]

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

Bug ID: 120756
   Summary: internal compiler error: error reporting routines
re-entered with [[deprecated]]
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rush102333 at gmail dot com
  Target Milestone: ---

The following test triggers ICE since gcc-6: 

~~

struct A { 
template  [[deprecated]] void foo (); 
};

template  [[deprecated]] auto bar () -> decltype (&A::foo);

void foo ()
{
  bar<0> ();
}

~~

Stack Dump:

~~

: In substitution of 'template decltype (& A::foo) bar()
[with long int t = 0]':
:5:10:   required from here
5 |   bar<0> ();
  |   ~~~^~
:2:39: warning: 'void A::foo() [with long int  = 0]' is
deprecated [-Wdeprecated-declarations]
2 | template  [[deprecated]] auto bar () -> decltype (&A::foo);
  |   ^~~
:1:48: note: declared here
1 | struct A { template  [[deprecated]] void foo (); };
  |^~~

internal compiler error: error reporting routines re-entered.
0x283a04e diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x283a165 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x285a151 warning(diagnostic_option_id, char const*, ...)
???:0
0x182ec08 warn_deprecated_use(tree_node*, tree_node*)
???:0
0xbe9749 cp_handle_deprecated_or_unavailable(tree_node*, int)
???:0
0xbeaa72 mark_used(tree_node*, int)
???:0
0xd671ce resolve_nondeduced_context(tree_node*, int)
???:0
0xd92b40 finish_decltype_type(tree_node*, bool, int)
???:0
0xd3daaf tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x2886783 pretty_printer::format(text_info&)
???:0
0x2839ca6 diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x283a165 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x285a151 warning(diagnostic_option_id, char const*, ...)
???:0
0x182ec08 warn_deprecated_use(tree_node*, tree_node*)
???:0
0xbe9749 cp_handle_deprecated_or_unavailable(tree_node*, int)
???:0
0xbeaa72 mark_used(tree_node*, int)
???:0
0xb17e6e build_new_function_call(tree_node*, vec**, int)
???:0
0xd899dc finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0xd07873 c_parse_file()
???:0
0xe6f359 c_common_parse_file()
???:0
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.

~~

Please see https://godbolt.org/z/P5rvs8ne5

[Bug c++/120754] [12/13/14/15/16 Regression] Segfault when trying to print error about catching function type

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Segfault when trying to |[12/13/14/15/16 Regression]
   |print error about catching  |Segfault when trying to
   |function type   |print error about catching
   ||function type
   Target Milestone|--- |12.5
   Keywords||diagnostic,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
  Known to fail||4.1.2
  Known to work||4.0.4
 Ever confirmed|0   |1
   Last reconfirmed||2025-06-22

--- Comment #1 from Andrew Pinski  ---
Confirmed, the ICE is while printing out the error message which is why it
prints out `confused by earlier errors`.

[Bug c/120744] New diagnostic: -Wrealloc-zero-bytes

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/120748] [16 Regression] New crash with lambda code

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |16.0
   Keywords||c++-lambda
Summary|New crash with lambda code  |[16 Regression] New crash
   ||with lambda code

[Bug target/106587] RISCV invalid jump address when compiled with -fcall-saved-reg and TCO

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #1 from Jeffrey A. Law  ---
This appears to have been fixed for gcc-15.

[Bug c++/120757] [12/13/14/15/16 Regression] ICE: in tsubst, at cp/pt.cc:16787

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||12.4.0, 13.1.0, 14.1.0
   Target Milestone|--- |12.5
Summary|ICE: in tsubst, at  |[12/13/14/15/16 Regression]
   |cp/pt.cc:16787  |ICE: in tsubst, at
   ||cp/pt.cc:16787
   Keywords||needs-bisection
 Ever confirmed|0   |1
   Last reconfirmed||2025-06-22
 Blocks||101603
  Known to work||12.1.0, 12.2.0, 5.1.0
 Status|UNCONFIRMED |NEW

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603
[Bug 101603] [meta-bug] pointer to member functions issues

[Bug target/119830] RISC-V:Internal Compiler Error on RISC-V Windows Toolchain (32-bit program) with -march=rv64gc_zbb_zbs

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

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

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

https://gcc.gnu.org/g:07c02ff39e121a496c46d3a997a25e2f46ce227e

commit r16-1614-g07c02ff39e121a496c46d3a997a25e2f46ce227e
Author: Andrew Pinski 
Date:   Sun Jun 22 12:35:19 2025 -0600

[RISC-V][PR target/119830] Fix RISC-V codegen on 32bit hosts

So this is Andrew's patch from the PR.  We weren't clean for a 32bit host
in
some of the arithmetic for constant synthesis.

I confirmed the bug on a 32bit linux host, then confirmed that Andrew's
patch
from the PR fixes the problem, then ran Andrew's patch through my tester
successfully.

Naturally I'll wait for pre-commit testing, but I'm not expecting problems.

PR target/119830
gcc/
* config/riscv/riscv.cc (riscv_build_integer_1): Make arithmetic in
bclr case
clean for 32 bit hosts.

gcc/testsuite/
* gcc.target/riscv/pr119830.c: New test.

[Bug target/120550] [15 Regression] RISC-V: Miscompile at -O3 since r16-372-g064cac730f8

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

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

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

https://gcc.gnu.org/g:34e1e5e33ec3eb475c0c8278800b6fc246a86763

commit r16-1613-g34e1e5e33ec3eb475c0c8278800b6fc246a86763
Author: Jeff Law 
Date:   Sun Jun 22 12:06:08 2025 -0600

[committed][PR rtl-optimization/120550] Drop REG_EQUAL note after ext-dce
transformation

This bug was found by Edwin's fuzzing efforts on RISC-V, though it likely
affects other targets.

In simplest terms when ext-dce converts an extension into a (possibly
simplified) subreg copy it may make an attached REG_EQUAL note invalid.

In the case Edwin found the note was an extension, but I don't think that
would
necessarily always be the case.  The note could have other forms which
potentially need invalidation.  So the safest thing to do is just remove
any
attached REG_EQUAL or REG_EQUIV note.

Note adjusting Edwin's testcase in the obvious way to avoid having to
interpret
printf output for pass/fail status makes the bug go latent.  That's why no
testcase is included with this patch.

Bootstrapped and regression tested on x86_64.  Obviously also verified it
fixes
the testcase Edwin filed.

This is a good candidate for cherry-picking to the gcc-15 release branch
after
simmering on the trunk a bit.

PR rtl-optimization/120550
gcc/
* ext-dce.cc (ext_dce_try_optimize_insn): Drop REG_EQUAL/REG_EQUIV
notes on modified insns.

[Bug modula2/120761] GM2_FOR_BUILD is not substituted in the toplevel Makefile

[schwab--- via Gcc-bugs]

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

--- Comment #1 from Andreas Schwab  ---
Nothing uses it so far.

[Bug tree-optimization/120752] 5% slowdown of 525.x264_r since r16-1346-gb0d50cbb42ab2c

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

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

--- Comment #2 from Filip Kastl  ---
Created attachment 61680
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61680&action=edit
perf report -n output before Honza's commit

(In reply to Jan Hubicka from comment #1)
> if you happen to have binaries, it would be useful to know perf report
> with and without the hcange.

Yes, I do have those.  Here is perf report -n output.  This is measured on a
Zen3 machine.

[Bug target/119830] RISC-V:Internal Compiler Error on RISC-V Windows Toolchain (32-bit program) with -march=rv64gc_zbb_zbs

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

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

[Bug target/120763] [meta-bug] Tracker for bugs to visit during weekly RISC-V meeting

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Last reconfirmed||2025-06-22
 Depends on||120651, 120627, 120356,
   ||120242, 119944, 119007,
   ||118595, 109933, 104102,
   ||89173, 86005, 82106
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82106
[Bug 82106] [RISCV] Misaligned loads generated when doubles are split between
stack and registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
[Bug 86005] [RISCV] Invalid intermixing of __atomic_* libcalls and inline
atomic instruction sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89173
[Bug 89173] FAIL: runtime/pprof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104102
[Bug 104102] __builtin_frame_address(1) desn't work on riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109933
[Bug 109933] __atomic_test_and_set is broken for BIG ENDIAN riscv targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118595
[Bug 118595] [15/16 regression] RISC-V: gfortran/c-interop test execution
failures on RVV zvl > 128b since r15-3228-g771256bcb9d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119007
[Bug 119007] RISC-V: The optimization ignored the side effects of the rounding
mode, resulting in incorrect results for rvv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119944
[Bug 119944] [16] RISC-V: g++.dg/torture/pr119610.C "terminate called after
throwing an instance of 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120242
[Bug 120242] [15/16 regression] RISC-V: Miscompile at -O[23] since
r15-9239-g4d7a634f6d4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120356
[Bug 120356] [15/16 Regression] RISC-V: Miscompile at -O[23] since
r15-6881-g7b815107f40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120627
[Bug 120627] [15/16 regression] RISC-V: Miscompile at -O[23] since
r15-2186-g9d8ef2711df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120651
[Bug 120651] [15/16 Regression] RISC-V: Miscompile at -O3 with -flto since
r15-3228-g771256bcb9d

[Bug target/120763] New: [meta-bug] Tracker for bugs to visit during weekly RISC-V meeting

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

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

Bug ID: 120763
   Summary: [meta-bug] Tracker for bugs to visit during weekly
RISC-V meeting
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at gcc dot gnu.org
  Target Milestone: ---

We want a way to track bugs to discuss during the weekly RISC-V GCC meeting.

Keying that decision on the RISC-V keyword is far from ideal; that'll roughly
get 200 hits, some of which are just mentions of RISC-V in the comments.  Some
of which will be long term bugs which aren't getting attention right now, etc.

Keying on Keywords/Tags doesn't work as those are managed by BZ and we'd need
to get a keyword added to BZ for this purpose.

Personal tags don't work as they're in individual users' namespace.

So instead we'll just create a meta-bug for tracking.


--

This BZ is just for tracking, please don't discuss the bugs here; instead
discuss them in the individual BZs or in the upstream patch discussion.

Anyone can add to the bugs to be discussed; RISC-V port maintainers/developers
are welcome to remove bugs once they're discussed or if meaningful action has
been taken on the referenced bug.

Ideally bugs stay on the tracker for a relatively short period of time, just
long enough to do a review.  That review may result in deferring with no
action, assignment to an engineer working on the problem, closing the bug as
resolved or deferring, but keeping on the tracker if we want to come back to
the BZ the following week.

[Bug middle-end/44566] configuration with multiple targets / backends is not supported.

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

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

--- Comment #14 from Jorn Wolfgang Rennecke  ---
Shouldn't that be WONTFIX instead of FIXED?

Or do you count changes in hardware architecture trends as a 'fix',
as we see multi-core systems that use the same instruction set architecture
for a number of cores that are differentiated into subsets that use different
microarchitectures to specialize them for different kinds of tasks. (Currently
mostly
peak performance vs. low power continuous operation or highly-threaded loads,
but clearly that could progress to more heterogeneous systems while still
keeping
it in the same ISA family.)

[Bug target/119007] RISC-V: The optimization ignored the side effects of the rounding mode, resulting in incorrect results for rvv

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

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

--- Comment #1 from Jeffrey A. Law  ---
I think when we discussed his several weeks ago the conclusion was this was a
problem in the intrinsics space.

Essentially the intrinsics can modify FRM and when they do they probably need
to set -fno-rounding-math for at least the whole function in question.  That
way the generic optimizers won't try to simplify FP ops assuming we're still in
the default rounding mode.

[Bug other/52930] quadmath: missing logbq, modfq, nexttowardq, exp2q

[newbie-02 at gmx dot de via Gcc-bugs]

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

newbie-02  changed:

   What|Removed |Added

 CC||newbie-02 at gmx dot de

--- Comment #2 from newbie-02  ---
I had similar issues, could activate e.g. exp10q by a directive:  
```   
#define _GNU_SOURCE
// reg. e.g. exp10, acc. anonchatGTP required to use wchar.h, doesn't
help for that, 
```  
before the #includes section ...

[Bug c++/120764] New: redefinition errors when using certain std headers in GMF

[furyusss at yahoo dot fr via Gcc-bugs]

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

Bug ID: 120764
   Summary: redefinition errors when using certain std headers in
GMF
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: furyusss at yahoo dot fr
  Target Milestone: ---

cat std.cpp
module;

#include 

// first thing after the Global module fragment must be a module command
export module std;

export void fun(std::string_view) {
}

cat main.cpp
import std;

#include 

int main() {

}

g++ -std=c++23 -fmodules-ts -c std.cpp
g++ -std=c++23 -fmodules-ts main.cpp -o main

In file included from /usr/include/c++/15/concepts:48,
 from /usr/include/c++/15/compare:42,
 from /usr/include/c++/15/array:40,
 from /usr/include/c++/15/format:45,
 from /usr/include/c++/15/print:43,
 from main.cpp:3:
/usr/include/c++/15/type_traits:94:28: error: template definition of
non-template ‘constexpr const _Tp std::integral_constant<_Tp, __v>::value’
[-Wtemplate-body]
   94 |   static constexpr _Tp value = __v;
  |^
/usr/include/c++/15/type_traits:95:29: error: template definition of
non-template ‘using std::integral_constant<_Tp, __v>::value_type = _Tp’
[-Wtemplate-body]
   95 |   using value_type = _Tp;
  | ^
/usr/include/c++/15/type_traits:96:47: error: template definition of
non-template ‘using std::integral_constant<_Tp, __v>::type = struct
std::integral_constant<_Tp, __v>’ [-Wtemplate-body]
   96 |   using type = integral_constant<_Tp, __v>;
  |   ^
/usr/include/c++/15/type_traits:97:45: error: template definition of
non-template ‘constexpr std::integral_constant<_Tp, __v>::operator value_type()
const’ [-Wtemplate-body]
   97 |   constexpr operator value_type() const noexcept { return value; }
  | ^~~~
/usr/include/c++/15/type_traits:100:47: error: template definition of
non-template ‘constexpr std::integral_constant<_Tp, __v>::value_type
std::integral_constant<_Tp, __v>::operator()() const’ [-Wtemplate-body]
  100 |   constexpr value_type operator()() const noexcept { return value;
}
  |   ^~~~
/usr/include/c++/15/type_traits:219:27: error: redefinition of ‘template constexpr const bool std::__and_v’
  219 | inline constexpr bool __and_v = __and_<_Bn...>::value;
  |   ^~~
In file included from /usr/include/c++/15/ratio:41,
 from /usr/include/c++/15/bits/chrono.h:39,
 from /usr/include/c++/15/chrono:45,
 from std.cpp:3,
of module std, imported at main.cpp:1:
/usr/include/c++/15/type_traits:219:27: note: ‘template
constexpr const bool std::__and_v<_Bn ...>’ previously declared here
  219 | inline constexpr bool __and_v = __and_<_Bn...>::value;
  |   ^~~

g++ -v
gcc version 15.0.1 20250404 (experimental) [master r15-9193-g08e803aa9be]
(Ubuntu 15-20250404-0ubuntu1) 

This seems similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600.

[Bug target/120734] *mov_(and|or) can be used for TARGET_SPLIT_LONG_MOVES

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

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

H.J. Lu  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #5 from H.J. Lu  ---
83 22 00andl   $0x0,(%rdx)
83 0a fforl$0x,(%rdx)

are slower than

c7 02 00 00 00 00   movl   $0x0,(%rdx)
c7 02 ff ff ff ff   movl   $0x,(%rdx)

[Bug middle-end/82705] Missing tail calls for large structs returns

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||FIXME

--- Comment #7 from Andrew Pinski  ---
  /* Doing sibling call optimization needs some work, since
 structure_value_addr can be allocated on the stack.
 It does not seem worth the effort since few optimizable
 sibling calls will return a structure.  */
  if (structure_value_addr != NULL_RTX)
{
  maybe_complain_about_tail_call (exp, _("callee returns a structure"));
  return false;
}

[Bug libquadmath/120762] PRINT: issue activating "Q" print format specifier [solved]

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

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

--- Comment #3 from Andrew Pinski  ---
See
https://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries
which documents this downstream in debian.

[Bug ada/120106] replace hardcoded gnatmake commands with configuration variables

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Eric Botcazou :

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

commit r16-1615-gbab1b2488e2a01b311d584bbecbc6834194e30ed
Author: Nicolas Boulenguez 
Date:   Sun Jun 22 19:23:11 2025 +0200

Ada: Introduce GNATMAKE_FOR_BUILD Makefile variable

This gets rid of the hardcoded 'gnatmake' command used during the build.

/
PR ada/120106
* Makefile.tpl: Add GNATMAKE_FOR_BUILD to
{HOST,BASE_TARGET}_EXPORTS
* Makefile.in: Regenerate.
* configure.ac: Set the default and substitute the variable.
* configure: Regenerate.
gcc/ada/
PR ada/120106
* Make-generated.in: Use GNATMAKE_FOR_BUILD instead of gnatmake.
* gcc-interface/Makefile.in: Likewise.

[Bug libquadmath/120762] PRINT: issue activating "Q" print format specifier [solved]

[newbie-02 at gmx dot de via Gcc-bugs]

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

--- Comment #4 from newbie-02  ---
IMHO it's fully ok to build Debian with --no-as-needed if it works,  
not ok is defaulting the gcc for user individual compilations that  
way, it's user trapping.  
Do you know if it can be steered individually for building the OS and  
user use? And or where to report to Debian? Think it would save some  
people a lot of time ... :-)

[Bug middle-end/82705] Missing tail calls for large structs returns

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
   Keywords|FIXME   |
 Status|ASSIGNED|RESOLVED

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

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

[Bug middle-end/54770] sibling call optimization is not applied where it ought to be

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #4)
> Right now we only have control flow insensitive points to ESCAPED set, so
> I'm afraid this is unfixable, unless we change that.  Only with control flow
> sensitive ESCAPED we'd be able to clear the tmp var out of the escaped set
> at the CLOBBER point (but it would need to be kept in other points to sets,
> as we could e.g. CSE pure/const calls that return the var's address).

That is just PR 23384.

[Bug libquadmath/120762] PRINT: issue activating "Q" print format specifier [solved]

[newbie-02 at gmx dot de via Gcc-bugs]

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

--- Comment #2 from newbie-02  ---
:-)  thanks for clarifying, computer math and plethora of  
options which have to work together is sometimes confusing ...

[Bug middle-end/71761] missing tailcall optimization

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jmuizelaar at mozilla dot com

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

[Bug c++/115606] C++ front-end marks the return slot as addressable early on which prevents tail call being marked

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

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

Bug 82705 Summary: Missing tail calls for large structs returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82705

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

[Bug middle-end/71761] missing tailcall optimization

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #10 from Andrew Pinski  ---
Patch which I originally attached for PR 82705 fixes this one too.

[Bug ada/120106] replace hardcoded gnatmake commands with configuration variables

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Eric Botcazou :

https://gcc.gnu.org/g:8440db955b274472234071f79a35b504e96dc3d1

commit r16-1617-g8440db955b274472234071f79a35b504e96dc3d1
Author: Nicolas Boulenguez 
Date:   Mon Jun 23 00:37:35 2025 +0200

Ada: Replace hardcoded GNAT commands for GNAT tools

This replaces the hardcoded gnat{make,link,bind,ls} commands with expansion
of the GNAT{MAKE,BIND} variables computed by the configure machinery,
during
the build of the GNAT tools.

The default GNATMAKE_FOR_HOST duplicates the default GNATMAKE, and someone
setting GNATMAKE in the toplevel configuration may want it applied for all
host compilations.  Direct assignment of GNATMAKE_FOR_HOST keeps working.

gcc/ada/
PR ada/120106
* gcc-interface/Make-lang.in: Set GNAT{MAKE,BIND,LINK_LS}_FOR_HOST
from GNAT{MAKE,BIND} instead of using hardcoded commands.
gnattools/
PR ada/120106
* configure.ac: Remove ACX_NONCANONICAL_HOST and add ACX_PROG_GNAT.
* configure: Regenerate.
* Makefile.in: Do not substitute host_noncanonical but substitute
GNATMAKE and GNATBIND.
Set GNAT{MAKE,BIND,LINK_LS}_FOR_HOST from GNAT{MAKE,BIND} instead
of using hardcoded commands.

[Bug ada/120106] replace hardcoded gnatmake commands with configuration variables

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

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

Eric Botcazou  changed:

   What|Removed |Added

   Target Milestone|--- |16.0
Version|unknown |16.0
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Eric Botcazou  ---
> v02 uses the host compiler set by ./configure in gnattools/Makefile.in and
> gcc-interface/Make-lang.in.

Applied as well.  Thanks for all the work!

[Bug libquadmath/104695] different bit patterns in __builtin_nans and libquadmath::nanq

[newbie-02 at gmx dot de via Gcc-bugs]

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

newbie-02  changed:

   What|Removed |Added

 CC||newbie-02 at gmx dot de

--- Comment #3 from newbie-02  ---
Could it be that you are comparing signaling and quiet NANs?  
IMHO it's by design to be different in head and payload.

[Bug target/120728] vmovdqu8 is used on YMM unnecessarily

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

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

--- Comment #5 from H.J. Lu  ---
Fixed for GCC 16 so far.

[Bug ada/120106] replace hardcoded gnatmake commands with configuration variables

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||emr-gnu at hev dot psu.edu

--- Comment #8 from Eric Botcazou  ---
*** Bug 108909 has been marked as a duplicate of this bug. ***

[Bug libquadmath/120762] PRINT: issue activating "Q" print format specifier [solved]

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
The default behavior of upstream gcc is not as needed. The problem is only with
Debian derivatives.
So there is no bug in upstream gcc at all.

[Bug ada/108909] Build process does not honor discovered path to "gnatmake" and "gnatlink"

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
   Target Milestone|13.5|16.0
 Resolution|--- |DUPLICATE

--- Comment #14 from Eric Botcazou  ---
.

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

[Bug middle-end/82705] Missing tail calls for large structs returns

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

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

--- Comment #8 from Andrew Pinski  ---
Created attachment 61682
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61682&action=edit
Patch which I am testing but needs some testcases too

[Bug target/120728] vmovdqu8 is used on YMM unnecessarily

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:919f073ae5f45e9cc328be8a914cd80b3a0bc12d

commit r16-1620-g919f073ae5f45e9cc328be8a914cd80b3a0bc12d
Author: H.J. Lu 
Date:   Fri Jun 20 16:07:18 2025 +0800

x86: Don't use vmovdqu16/vmovdqu8 with non-EVEX registers

Don't use vmovdqu16/vmovdqu8 with non-EVEX register operands just because
AVX512BW is available.

gcc/

PR target/120728
* config/i386/i386.cc (ix86_get_ssemov): Use vmovdqu16/vmovdqu8
only with EVEX register operands.

gcc/testsuite/

PR target/120728
* gcc.target/i386/avx512bw-vmovdqu16-1.c: Scan vmovdqu for
non-EVEX register operands.
* gcc.target/i386/avx512bw-vmovdqu8-1.c: Likewise.
* gcc.target/i386/avx512fp16-13.c: Likewise.
* gcc.target/i386/pr100865-10b.c: Likewise.
* gcc.target/i386/pr100865-3.c: Likewise.
* gcc.target/i386/pr100865-4b.c: Likewise.
* gcc.target/i386/pr100865-5b.c: Likewise.
* gcc.target/i386/pr90773-15.c: Likewise.
* gcc.target/i386/pr90773-16.c: Likewise.
* gcc.target/i386/pr90773-17.c: Likewise.
* gcc.target/i386/pr95483-5.c: Likewise.
* gcc.target/i386/pr120728.c: New test.

Signed-off-by: H.J. Lu 

[Bug target/118890] ubsan bootstrap failure for powerpc64le-unknown-linux-gnu

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

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

--- Comment #4 from Thomas Koenig  ---
I reran the tests on current trunk and did not see the
poly-int failure. Maybe it was fixed in the meantime.

Here are the failures that I am seeing now, with current trunk (duplicates
removed):

./../trunk/gcc/config/rs6000/rs6000.cc:10312:29: runtime error: left shift of
negative value -140668823404544
../../trunk/gcc/config/rs6000/rs6000.cc:10313:29: runtime error: shift exponent
64 is too large for 64-bit type 'long int'
../../trunk/gcc/config/rs6000/rs6000.cc:10314:34: runtime error: left shift of
negative value -140668823404544
../../trunk/gcc/config/rs6000/rs6000.cc:10437:34: runtime error: left shift of
negative value -3689348814741910323
../../trunk/gcc/config/rs6000/rs6000.cc:10471:29: runtime error: left shift of
negative value -140806153306113
../../trunk/gcc/config/rs6000/rs6000.cc:10573:18: runtime error: shift exponent
64 is too large for 64-bit type 'long unsigned int'
../../trunk/gcc/config/rs6000/rs6000.cc:10573:35: runtime error: shift exponent
64 is too large for 64-bit type 'long unsigned int'
../../trunk/gcc/config/rs6000/rs6000.md:1974:43: runtime error: signed integer
overflow: 9223372036854775807 - -1 cannot be represented in type 'long int'

[Bug c++/120758] New: Empty initializer list (`{}`) incorrectly deduces an array size for array reference parameter

[mital at mitalashok dot co.uk via Gcc-bugs]

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

Bug ID: 120758
   Summary: Empty initializer list (`{}`) incorrectly deduces an
array size for array reference parameter
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mital at mitalashok dot co.uk
  Target Milestone: ---

Compiling the following with `-std=c++11 -fsyntax-only`
:

template<__SIZE_TYPE__ N, typename T>
void f(T(&)[N], T(&)[N]);

int main() {
const int arr[2] = {};
f<2>(arr, {});  // Compiles
f(arr, {});  // Fails
}

Results in the following error:

/tmp/test.cpp: In function 'int main()':
/tmp/test.cpp:7:6: error: no matching function for call to 'f(const int [2],
)'
7 | f(arr, {});  // Fails
  | ~^
/tmp/test.cpp:7:6: note: there is 1 candidate
/tmp/test.cpp:2:6: note: candidate 1: 'template
void f(T (&)[N], T (&)[N])'
2 | void f(T(&)[N], T(&)[N]);
  |  ^
/tmp/test.cpp:2:6: note: template argument deduction/substitution failed:

There are no more notes. Expected behaviour is that the two function calls
result in calling `f<2, const int>`, or if this is the intended behaviour, for
a note about why the template argument deduction/substitution failed.

The reason I believe this to be valid is because
:

> If removing references and cv-qualifiers from P gives 
> std::initializer_list or P′[N] for some P′ and N and the argument is a 
> non-empty initializer list, [...] Otherwise, an initializer list argument 
> causes the parameter to be considered a non-deduced context.

And `{}` is not non-empty, so it should not affect deduction.

[Bug target/112531] [14] RISC-V: gcc.dg/unroll-8.c rtl-dump scan errors with --param=riscv-autovec-preference=scalable

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #7 from Jeffrey A. Law  ---
Seems to be OK on the trunk now.

[Bug target/113035] RISC-V: regression testsuite errors -mtune=sifive-7-series

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #6 from Jeffrey A. Law  ---
So given this is ~18 months old, I'm not sure keeping this open is useful as it
just documents the failure set in the testsuite for a specific set of options.

I think we did some work on the vsetvl differences, but probably not enough to
make those fragile tests work irrespective of the cost model.

Dusan has a good observation about zicond vs sfb.  That's a problem space ripe
for exploration in 2026 as I'm aware of a target that will have zicond + sfb
along with some extra goodies that would tend to want us to steer towards sfb
in some cases.  But it's going to need silicon testing to really understand the
tradeoffs.

In all I just don't see the old data as all that useful 18 months later and
there's nothing really actionable in here.

[Bug testsuite/113238] [14] RISC-V: gcc.dg vect-tsvc flakey test timeouts when under heavy workload

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #3 from Jeffrey A. Law  ---
They're not really flakey tests, they just take a long time and under load they
may reach their timeouts, particularly in emulated environments.

[Bug tree-optimization/116773] [meta-bug] TSVC missed optimizations

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

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

Bug 113238 Summary: [14] RISC-V: gcc.dg vect-tsvc flakey test timeouts when 
under heavy workload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113238

   What|Removed |Added

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

[Bug target/116504] wrong code with -mcpu=sifive-x280

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

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

--- Comment #8 from Jeffrey A. Law  ---
So for the record.  Both testcases failed for me with QEMU.  THe first case
worked on real hardware while the second testcase failed on real hardware.

I'm digging data out of an old email, so no clear indication of what QEMu
version I was using.

[Bug target/120719] __builtin_rev_crc32_data8() should revert to __builtin_ia32_crc32qi() when available

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug target/120550] [16 Regression] RISC-V: Miscompile at -O3 since r16-372-g064cac730f8

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

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

--- Comment #6 from Jeffrey A. Law  ---
So this is an ext-dce bug, it just isn't obvious.

ext-dce removes the extension in this insn:

(insn 26 24 29 3 (set (reg:DI 141 [ pretmp_16 ])
(zero_extend:DI (subreg:QI (reg:DI 160) 0))) "j.c":8:5 126
{*zero_extendqidi2_internal}
 (expr_list:REG_DEAD (reg:DI 160) 
(expr_list:REG_EQUAL (zero_extend:DI (mem/c:QI (symbol_ref:DI ("u")
[flags 0x86]  ) [0 u+0 S1 A8]))
(nil

I've traced the values around the CFG and the removal is valid.  But there's a
REG_EQUAL note that gets left around.  So after ext-dce we have:

(insn 26 24 29 3 (set (reg:DI 141 [ pretmp_16 ])
(reg:DI 160)) "j.c":8:5 277 {*movdi_64bit}
 (expr_list:REG_DEAD (reg:DI 160)
(expr_list:REG_EQUAL (zero_extend:DI (mem/c:QI (symbol_ref:DI ("u")
[flags 0x86]  ) [0 u+0 S1 A8]))
(nil


That's the bug.  Combine later kicks in and sees the REG_EQUAL note and adjust
the nonzero bits for (reg 141) in the expected way, but they don't accurately
reflect  the value in (reg 141).  Combine later uses the incorrect nonzero_bits
 and eliminates a different (and necessary) extension.

The fix is simple.  When ext-dce makes a change it can just wipe the REG_EQUAL
note.  We could try and be selective about the notes we remove, but I doubt
it's worth the effort and analysis to be selective.

[Bug libgcc/120726] make clean (clean-stage1-target-libgcc): Recursive variable 'AR' references itself (eventually). Stop

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|bootstrap   |libgcc
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2025-06-22

--- Comment #1 from Andrew Pinski  ---
Can you provide the full set of commands that leads to this?

[Bug target/120741] [16 Regression] ICE on mingw-w64-12.0.0: during RTL pass: pro_and_epilogue ICE in ix86_expand_prologue, at config/i386/i386.cc:9446

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

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

--- Comment #4 from Sergei Trofimovich  ---
(In reply to cuilili from comment #1)
> Created attachment 61678 [details]
> Fix-shrink-wrap-separate-ICE-for-mingw
> 
> Hi Sergei,
> 
> Thanks for reporting this issue and providing a small testcase. I reproduced
> this issue locally and fixed it. Could you help verify it in your
> environment? Thank you!

The change fixes the build for my environment. Thank you!

[Bug rtl-optimization/120750] SEGV in remove_use, at rtl-ssa/accesses.cc:1276

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
As I mentioned in PR120745:
I am not sure bugzilla is the right place to ask for help while working on a
patch/pass; the gcc@ mailing list is where that normally takes place.

[Bug c++/120759] [12/13/14/15/16 Regression] Empty initializer list (`{}`) in a parameter pack disables deduction for the entire pack

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||4.7.1
  Known to work||4.6.4
   Last reconfirmed||2025-06-22
Summary|Empty initializer list  |[12/13/14/15/16 Regression]
   |(`{}`) in a parameter pack  |Empty initializer list
   |disables deduction for the  |(`{}`) in a parameter pack
   |entire pack |disables deduction for the
   ||entire pack
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||accepts-invalid
   Target Milestone|--- |12.5

--- Comment #1 from Andrew Pinski  ---
Confirmed. Looks like it started in GCC 4.7.0.

[Bug c++/120760] New: Deducing array bound with a small unsigned integral type silently overflows

[mital at mitalashok dot co.uk via Gcc-bugs]

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

Bug ID: 120760
   Summary: Deducing array bound with a small unsigned integral
type silently overflows
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mital at mitalashok dot co.uk
  Target Milestone: ---

The following fails to compile with `-std=c++11 -fsyntax-only`
 (You can make a version that fails in C++98
too):

template
struct hard_error_on {
static_assert(X != Val, "");
using type = void;
};

template typename hard_error_on::type
f1(int(&)[i]);
void f1(...);

template typename hard_error_on<1, i>::type
f2(int(&)[i]);
void f2(...);

int main() {
int a[2];
int b[257];

f1(a);
f2(b);
}

It fails both static_asserts, showing it tries to instantiate f1 and
f2<1>.

If the type is signed, it ends up working because signed overflow isn't a
constant expression.

It makes no sense to deduce `0` and `1` as the sizes of `int[2]` and `int[257]`
respectively.

 also explicitly says:

> 120) Although the template-argument corresponding to a template parameter of 
> type bool can be deduced from an array bound, the resulting value will always 
> be true because the array bound will be nonzero.

But GCC gives `false` to the constant parameter

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

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

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

Bug 120735 Summary: -Warray-bounds error via std::vector::data after unsigned 
int overflow potential
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120735

   What|Removed |Added

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

[Bug middle-end/44566] configuration with multiple targets / backends is not supported.

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #13 from Jeffrey A. Law  ---
Per my recommendation in c#12.

[Bug tree-optimization/120735] -Warray-bounds error via std::vector::data after unsigned int overflow potential

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
unsigned int dataSize = 4;
//assert(dataSize + n > dataSize);
dataSize += n;


Yes you need to check for an wrapping condition inside f to be 100% correct.
GCC is correctly warning here.

For `resize(0)`, std::vector has a nullptr as the vector is empty, *data() does
not have to be deferencable so a nullptr for data() is valid.
that is what is happening here.

[Bug fortran/120743] [16 regression] ice in verify_gimple_in_seq

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

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

Sam James  changed:

   What|Removed |Added

Summary|ice in verify_gimple_in_seq |[16 regression] ice in
   ||verify_gimple_in_seq
   Target Milestone|--- |16.0

[Bug web/120698] ./configure - unclear default for vtable-verify

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Last reconfirmed||2025-06-22

[Bug fortran/120743] ice in verify_gimple_in_seq

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

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #4 from Mikael Morin  ---
(In reply to Jerry DeLisle from comment #3)
> 
> Here is a smaller reproducer.
> 
...
> 
> Delete the if statement inside the do while and the problem diasappears.

For me the problem remains as long as there are substrings of attrlist.

Probable culprit: r16-1096-gafa2de8093a0cd

In gfc_conv_substring:

>  gfc_conv_expr_type (&start, ref->u.ss.start, gfc_charlen_type_node);
-> start.expr has type gfc_charlen_type_node

> diff = fold_build2 (MINUS_EXPR, size_type_node, start.expr,
> build_one_cst (size_type_node));
-> start.expr is used with type size_type node.

Oops.

[Bug c++/120759] New: Empty initializer list (`{}`) in a parameter pack disables deduction for the entire pack

[mital at mitalashok dot co.uk via Gcc-bugs]

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

Bug ID: 120759
   Summary: Empty initializer list (`{}`) in a parameter pack
disables deduction for the entire pack
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mital at mitalashok dot co.uk
  Target Milestone: ---

The following compiles with `-std=c++11 -fsyntax-only`
:

template
struct X {};

template
void f(X, T...);

int main() {
f(X{}, {}, 1L);
f(X{}, 1L, {});
}

This diverges from Clang, which fails to compile this with the following
diagnostic:

:8:5: error: no matching function for call to 'f'
8 | f(X{}, {}, 1L);
  | ^
:5:6: note: candidate template ignored: deduced conflicting types for
parameter 'T' ( vs. <(no value), long>)
5 | void f(X, T...);
  |  ^
:9:5: error: no matching function for call to 'f'
9 | f(X{}, 1L, {});
  | ^
:5:6: note: candidate template ignored: deduced conflicting types for
parameter 'T' ( vs. )
5 | void f(X, T...);

And a similar error with MSVC. All three compilers accept `{}, 1` or `1, {}`.

I believe GCC is interpreting 

> an initializer list argument causes the parameter to be considered a 
> non-deduced context.

... as making that entire parameter pack a non-deduced context, which is
unexpected. Clang and MSVC seem to interpret it as only that specific position
in the parameter pack become non-deduced.

[Bug target/120627] [15/16 regression] RISC-V: Miscompile at -O[23] since r15-2186-g9d8ef2711df

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

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

--- Comment #2 from Jeffrey A. Law  ---
*** Bug 120736 has been marked as a duplicate of this bug. ***

[Bug c++/120720] __builtin_rev_crc32_data8 (and family) should be constexpr functions

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Blocks||55004


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug target/118734] RISC-V: Vector broadcast via strided load.

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #4 from Jeffrey A. Law  ---
Shreya has a patch for this (to make it a tunable).  I don't know the state of
her bugzilla account, so assigning to me for now.

[Bug tree-optimization/120747] [16 Regression] 435.gromacs miscompares since r16-1550-g9244ea4bf55638

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

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

--- Comment #3 from Filip Kastl  ---
(In reply to Andrew Macleod from comment #2)
> Does it still fail with the fix for PR 120701?

Sadly, the fix for pr120701 doesn't help.  I can still replicate this on
r16-1594-gb03e0d69b37f6e and on current trunk.

[Bug target/120725] [meta] Poor memcpy/memset inline strategies for -mtune=generic

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug middle-end/120720] __builtin_rev_crc32_data8 (and family) should be able to constant fold

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2025-06-22
   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|__builtin_rev_crc32_data8   |__builtin_rev_crc32_data8
   |(and family) should be  |(and family) should be able
   |constexpr functions |to constant fold
  Component|c++ |middle-end
 Blocks|55004   |

--- Comment #3 from Andrew Pinski  ---
This is NOT just about constexpr but rather it is more about constant folding
the builtins in general.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug target/120736] [15/16 Regression] RISC-V: Miscompile at -O[23] since r15-5375-gbeec291225b

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #1 from Jeffrey A. Law  ---
Has all the tell-tale signs in the dumps that it's the same problem has 120627
and the WIP patch for 120627 fixes this bug too.

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

[Bug c++/120706] [14/15/16 Regression] Incorrect underlining for -Wformat when the type has a user-defined copy constructor

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.4
Summary|Incorrect underlining for   |[14/15/16 Regression]
   |-Wformat when the type has  |Incorrect underlining for
   |a user-defined copy |-Wformat when the type has
   |constructor |a user-defined copy
   ||constructor
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-06-22
 Ever confirmed|0   |1
  Known to work||13.4.0
  Known to fail||14.1.0

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

[Bug target/120709] [15/16 Regression] ICE in expand_builtin_crc_table_based with __builtin_crc8_data8 and non constant poly argument

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[15/16 Regression] ICE in   |[15/16 Regression] ICE in
   |expand_builtin_crc_table_ba |expand_builtin_crc_table_ba
   |sed with|sed with
   |__builtin_crc8_data8|__builtin_crc8_data8 and
   ||non constant poly argument
   Keywords|ice-on-valid-code   |documentation,
   ||ice-on-invalid-code

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

  tree rhs3 = CALL_EXPR_ARG (exp, 2); // polynomial

  gcc_assert (TREE_CODE (rhs3) == INTEGER_CST);


There are 2 issues here, __builtin_crc8_data8's polynomial argument needs to be
a constant which is NOT documented and we should be rejecting the code rather
than having an ICE here.

[Bug libquadmath/120762] New: PRINT: issue activating "Q" print format specifier [solved]

[newbie-02 at gmx dot de via Gcc-bugs]

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

Bug ID: 120762
   Summary: PRINT: issue activating "Q" print format specifier
[solved]
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libquadmath
  Assignee: unassigned at gcc dot gnu.org
  Reporter: newbie-02 at gmx dot de
  Target Milestone: ---

I had an issue with quadmath printing nonsense like  

%Qg  
%.36QE  

instead of the values intended.  
It turned out that on my system ( Linux - Debian - Kali ) the  
library sometimes isn't linked in when no quadmath calculations  
are performed and only the printing system / printf hooks are  
to be used.  

Similar happened with "lipdfp", decimal math, and a hint by  
Andrew Pinski in  
https://github.com/libdfp/libdfp/issues/186#issuecomment-2957037007solved  
unveiled it as a consequence of gcc defaulting to "--as-needed"  
linking on Debian / ubuntu systems, and using "-Wl,--no-as-needed"  
as option before the source and target files in the compile  
command can oversteer.  

I tried and the same works for quadmath.  

Posted to A.) spread the word ( before Andrew's comment I  
couldn't find any hint online ), B.) propose to change the  
behaviour, IMHO using the print format specifier in code should  
activate "library is needed".