[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #332 from John Paul Adrian Glaubitz  ---
Created attachment 59212
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59212&action=edit
Preprocessed source from from comment #331

[Bug target/116854] GCC incorrectly assumes all CPUs where -march=native resolves to -march=bdver4 will have RDRND support

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Uroš Bizjak  ---
g:890e586486bb

https://gcc.gnu.org/pipermail/gcc-patches/2014-August/394986.html

[Bug tree-optimization/116848] Check to see if is_maybe_undefined can be replaced with ssa_name_maybe_undef_p/mark_ssa_maybe_undefs in loop unrolling

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/116848] Check to see if is_maybe_undefined can be replaced with ssa_name_maybe_undef_p/mark_ssa_maybe_undefs in loop unrolling

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

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

--- Comment #2 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r15-3914-g9c04112fdc221b0a337f88572dfef4caaca78349
Author: Andrew Pinski 
Date:   Thu Sep 26 05:55:58 2024 +

unswitch: Replace manual ondemand maybe_undef with
ssa_name_maybe_undef_p/mark_ssa_maybe_undefs [PR116848]

The ondemand maybe_undef that follows phis was added in
r7-6427-g8b670f93ab1136
but then later ssa_name_maybe_undef_p/mark_ssa_maybe_undefs was added in
r13-972-gbe2861fe8c527a. This moves the ondemand one to use
mark_ssa_maybe_undefs/ssa_name_maybe_undef_p instead. Which itself will be
faster since the mark_ssa_maybe_undefs is a walk based on the uses of
undefined names (and only once) rather than a walk based on the def of
ones which are more likely defined (and on demand).

Even though the ondemand maybe_undef had some extra special cases, those
won't make
a big difference in most code.

Bootstrapped and tested on x86_64-linux-gnu.

PR tree-optimization/116848

gcc/ChangeLog:

* tree-ssa-loop-unswitch.cc (tree_ssa_unswitch_loops): Call
mark_ssa_maybe_undefs.
(is_maybe_undefined): Call ssa_name_maybe_undef_p instead of
ondemand undef.

Signed-off-by: Andrew Pinski 

[Bug tree-optimization/116818] gcc.target/aarch64/sve/strided_load_5.c fails since gcc-15-3735-g664e0ce580a8

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

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

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

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

commit r15-3916-gb1c7095a1da11d2543222d98243d10f9cc9823ce
Author: Richard Biener 
Date:   Mon Sep 23 15:24:01 2024 +0200

tree-optimization/116818 - try VMAT_GATHER_SCATTER also for SLP

When not doing SLP and we end up with VMAT_ELEMENTWISE we consider
using strided loads, aka VMAT_GATHER_SCATTER.  The following moves
this logic down to also apply to SLP where we now can end up
using VMAT_ELEMENTWISE as well.

PR tree-optimization/116818
* tree-vect-stmts.cc (get_group_load_store_type): Consider
VMAT_GATHER_SCATTER instead of VMAT_ELEMENTWISE also for SLP.
(vectorizable_load): For single-lane VMAT_GATHER_SCATTER also
ignore permutations.

[Bug tree-optimization/116818] gcc.target/aarch64/sve/strided_load_5.c fails since gcc-15-3735-g664e0ce580a8

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug target/116856] Generated Code with unaligned uint32_t potentially hardfaults on ARM (due to LDRD)

[robert.hoelzl at posteo dot de via Gcc-bugs]

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

--- Comment #6 from Robert Hölzl  ---
Sorry I oversimplified the Problem. Here is the self contained C-file that
allows to reproduce the Problem:

```
#include 

void f()
{
static uint8_t array[64];
for (uint8_t i = 0; i < sizeof(array); i++)
{
*(uint32_t __attribute__ ((__aligned__(1)))*) &array[i + 4] ^=
*(uint32_t __attribute__ ((__aligned__(1)))*)
&array[i];
}
}

```

Please note that you can neither remove the for loop nor the refactor the type
case into a typedef without making the issue vanish.

My command line was like
```
"C:\Program Files (x86)\Arm GNU Toolchain arm-none-eabi\13.3
rel1\bin\arm-none-eabi-gcc.exe" -Os -mcpu=cortex-m33 -S -c demo.c
```

Please note that the parameter "-Os" (or "-Oz") is required to reproduce the
problem.

[Bug tree-optimization/104789] [12/13/14/15 Regression] -Wstringop-overflow false positive at -O3 for an unrolled loop

[rverschelde at gmail dot com via Gcc-bugs]

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

--- Comment #16 from Rémi Verschelde  ---
Just noting that this is still reproducible in GCC 14.2 (14.2.1 20240912 (Red
Hat 14.2.1-3)), with the reproducers from comment 7 and comment 9.

I see it had milestone moved to successive 12.x minor releases, shouldn't this
target GCC 15 / trunk if it's still reproducible (presumably) in the
development branch?

[Bug c++/116502] [15 Regression] -Wunused-result warning cannot be suppressed if coroutine awaiter returns a reference after r15-2318-g2664c1bf83855b

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

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

--- Comment #4 from GCC Commits  ---
The trunk branch has been updated by Arsen Arsenovic :

https://gcc.gnu.org/g:05e4f07cad1eacf869c10622cae2a9cdee3b6a7a

commit r15-3921-g05e4f07cad1eacf869c10622cae2a9cdee3b6a7a
Author: Arsen ArsenoviÄ 
Date:   Wed Aug 28 21:59:18 2024 +0200

c++/coro: prevent ICV_STATEMENT diagnostics in temp promotion [PR116502]

If such a diagnostic is necessary, it has already been emitted,
otherwise, it is not correct and emitting it here is inactionable by the
user, and bogus.

PR c++/116502

gcc/cp/ChangeLog:

* coroutines.cc (maybe_promote_temps): Convert temporary
initializers to void without complaining.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/maybe-unused-1.C: New test.
* g++.dg/coroutines/pr116502.C: New test.

[Bug c++/116793] [15 regression] ice in gimplify_var_or_parm_decl, at gimplify.cc:3309 since r15-3513

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

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

--- Comment #14 from GCC Commits  ---
The trunk branch has been updated by Arsen Arsenovic :

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

commit r15-3923-gd888a8a8dcf391197ae82e2bbf99507effc27950
Author: Arsen ArsenoviÄ 
Date:   Tue Sep 24 18:16:01 2024 +0200

c++/coro: ignore cleanup_point_exprs while expanding awaits [PR116793]

If we reach a CLEANUP_POINT_EXPR while trying to walk statements, we
actually care about the statement or statement list contained within it.

Indeed, such a construction started happening with
r15-3513-g964577c31df206, after temporary promotion.  In the test case
presented in PR116793, the compiler generated:

  T002_2_3];

  int T002 [value-expr: frame_ptr->T002_2_3];
<) >;
  struct _cleanup_task Aw0 [value-expr: frame_ptr->Aw0_2_3];
<) >;
<
Aw0

{_cleanup_task::await_ready (&Aw0),
_cleanup_task::await_suspend<_task1::promise_type> (&Aw0, TARGET_EXPR ), <<< Unknown tree: aggr_init_expr
  4
  await_resume
  D.22443
  &Aw0 >>>}
0 >>>) >;
<;
  }
  D.22467 = 1;
  int & i [value-expr: frame_ptr->i_1_2];
  < (NON_LVALUE_EXPR )) >;>>;

... i.e. a statement list within a cleanup point.  In such a case, we
don't actually care about the cleanup point, but we do care about the
statement inside, so, we can just walk down into the CLEANUP_POINT_EXPR.

PR c++/116793

gcc/cp/ChangeLog:

* coroutines.cc (await_statement_expander): Just process
subtrees if encountering a CLEANUP_POINT_EXPR.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr116793-1.C: New test.

[Bug c++/116502] [15 Regression] -Wunused-result warning cannot be suppressed if coroutine awaiter returns a reference after r15-2318-g2664c1bf83855b

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

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

Arsen Arsenović  changed:

   What|Removed |Added

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

--- Comment #5 from Arsen Arsenović  ---
Fixed on trunk, thanks for the report.

[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel

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

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

--- Comment #31 from GCC Commits  ---
The master branch has been updated by Iain D Sandoe :

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

commit r15-3924-gdd5b823ce238161156e7a4b6267bd30d7dde7c6b
Author: Mark Mentovai 
Date:   Tue Sep 24 16:11:14 2024 -0400

libgcc, Darwin: Don't build legacy libgcc_s.1 on macOS 14 [PR116809]

d9cafa0c4f0a stopped building libgcc_s.1 on macOS >= 15, in part because
that is required to bootstrap the compiler using the macOS 15 SDK. The
macOS 15 SDK ships in Xcode 16, which also runs on macOS 14. libgcc_s.1
can no longer be built on macOS 14 using Xcode 16 by the same logic that
the previous change disabled it for macOS 15.

PR target/116809

libgcc/ChangeLog:

* config.host: Don't build legacy libgcc_s.1 on macOS 14.

Signed-off-by: Mark Mentovai 

[Bug target/116854] GCC incorrectly assumes all CPUs where -march=native resolves to -march=bdver4 will have RDRND support

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|REOPENED|SUSPENDED

--- Comment #11 from Uroš Bizjak  ---
Also, the table at [1] says that bdver4 (Excavator) architecture supports AVIC,
BMI2, RDRAND, and MWAITX/MONITORX.

IMO, the situation is different with -maes and -march=westmere/-march=haswell 
(comment #5). In -maes case, the manufacturer (Intel) claimed that some SKUs
don't support the feature, while in our case manufacturer (AMD) posted the
patch where it claims that the feature is always supported for the referred
arch.

For some reason the OPs target doesn't support all required ISAs (probably due
to comment #2), so it is in some way an outlier. We won't penalize the target
because of a single outlier, unless we get the confirmation from the
manufacturer (AMD) that some SKUs are indeed released without the mentioned ISA
(as was the case with -maes).

As a workaround, the OP should compile with "-march=bdver4 -mno-rdrnd".

Suspended until someone provides the required confirmation from the
manufacturer (AMD).

[1] https://en.wikipedia.org/wiki/Excavator_(microarchitecture)

[Bug target/116854] GCC incorrectly assumes all CPUs where -march=native resolves to -march=bdver4 will have RDRND support

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

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to Thiago Macieira from comment #3)
> The bug as reported is invalid, because it reported the wrong thing. The
> problem has nothing to do with -march=native.

The bug report is frustratingly unclear.

> The problem is only -march=bdver4, which enables RDRND unconditionally.

Yes, because that's what it's designed and documented to do. We don't want
-march=bdver4 to mean different things on different machines, that's what
-march=native is for. A named -march value should always mean the same thing.

> Since the BIOS and/or OS can disable it, it stands to reason not all
> Excavators have RDRND. GCC should not enable it unconditionally.

So should this bug report be a request to change the meaning of bdver4? Because
it's behaving as documented currently.

Can we fix the summary to be more accurate?

Would "-march=bdver4 should not enable RDRND" be better?

[Bug target/116854] GCC incorrectly assumes all CPUs where -march=native resolves to -march=bdver4 will have RDRND support

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #16 from Uroš Bizjak  ---
(In reply to GGanesh from comment #15)
> I wanted to get it confirmed from our BIOS and Kernel developer manuals
> (https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/
> programmer-references/50742_15h_Models_60h-6Fh_BKDG.pdf).
> 
> RDRAND is *supported*/*enabled* for Models 60h-6Fh.
> 
> However, since the latest kernel code is not setting it unconditionally, we
> can only rely on the cpuid bits enabled by Kernel. If it is disabled, I
> personally feel we need to remove it from the list of ISAs supported by
> Excavator in gcc as well.

Please note that the kernel patch (referred in Comment #2) says:

--quote--
Note, that clearing the RDRAND CPUID bit does not prevent a processor
that normally supports the RDRAND instruction from executing it. So any
code that determined the support based on family and model won't #UD.
--/quote--

[Bug ipa/113197] [12/13/14/15 Regression] ICE in in handle_call_arg, at tree-ssa-structalias.cc:4119 since r12-5177-g494bdadf28d0fb

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

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

--- Comment #10 from Sam James  ---
We're hitting this now, not sure how we didn't before.

conntrack.i:
```
enum a { b } register_dccp();
void c();
void __attribute__((noreturn)) exit_error(enum a d) {
  __builtin_va_end(0);
  if (d)
c();
  c();
  __builtin_exit(1);
}
int main() { register_dccp(); }
```

libct_proto_dccp.i:
```
int a;
void exit_error();
void register_dccp() { exit_error(a); }
```

[Bug target/116869] Profiler count register conflicts with regparm

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

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

--- Comment #1 from Andrew Pinski  ---

msdosdjgpp might be the only target which does not define NO_PROFILE_COUNTERS .

[Bug c++/116867] Incorrectly report a constexpr function as non-constant

[hzhou11 at students dot kennesaw.edu via Gcc-bugs]

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

--- Comment #3 from Heng Zhou  ---
(In reply to Andrew Pinski from comment #1)
> Looks to be already fixed in GCC 13.3.0.

Yes, it works with gcc 13.3. Thank you.

[Bug c++/111284] [12 Regression] Some passing-by-value parameters are mishandled since GCC 9, affecting libstdc++'s constexpr std::string

[hzhou11 at students dot kennesaw.edu via Gcc-bugs]

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

--- Comment #16 from Heng Zhou  ---
(In reply to Jakub Jelinek from comment #13)
> Fixed also for 13.3.

Yes, it works with gcc 13.3. Thank you.

[Bug c++/115919] ICE: in tsubst_expr, at cp/pt.cc:20300

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

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Fixed by r15-3027:

commit 53283c3231a7b94e728619cccbf21170fb36b2a8
Author: Marek Polacek 
Date:   Thu Aug 15 18:47:29 2024 -0400

c++: ICE with enum and conversion fn in template [PR115657]

[Bug target/116869] New: Profiler count register conflicts with regparm

[jwjagersma at gmail dot com via Gcc-bugs]

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

Bug ID: 116869
   Summary: Profiler count register conflicts with regparm
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwjagersma at gmail dot com
  Target Milestone: ---

On i386 targets that pass a profiler count address in EDX, the second
argument to a regparm function is clobbered:

$ cat test.c
__attribute((regparm(2)))
int add (int a, int b)
{
  return a + b;
}

$ i386-pc-msdosdjgpp-gcc -S test.c -O -pg -o -
.file   "test.c"
.section .text
.globl  _add
_add:
pushl   %ebp
movl%esp, %ebp
.section .data
.p2align 2
LP0:
.long   0
.section .text
movl$LP0, %edx
1:  call_mcount
addl%edx, %eax
popl%ebp
ret
.ident  "GCC: (GNU) 14.2.0"

[Bug target/116869] Profiler count register conflicts with regparm for i386-pc-msdosdjgpp

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> msdosdjgpp might be the only target which does not define
> NO_PROFILE_COUNTERS .

I should say for x86.

[Bug libstdc++/116853] [15 regression] Bootstrap fails on Darwin, Solaris after r15-3859-g63a598deb0c9

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

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

--- Comment #4 from Iain Sandoe  ---
fixed on Darwin, if it also works for Solaris then please feel free to close
the BZ.

[Bug target/116854] GCC incorrectly assumes all CPUs where -march=native resolves to -march=bdver4 will have RDRND support

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

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

--- Comment #13 from Jonathan Wakely  ---
(In reply to Anonymous from comment #8)
> (In reply to Thiago Macieira from comment #5)
> 
> > This has nothing to do with -march=native. In fact, for the Gentoo people
> > who are using -march=native, everything is fine because __RDRND__ is *not*
> > defined (I think; I don't have such a CPU to check, but on my TGL,
> > -march=native and -march=tigerlake differ).
> 
> I have to disagree. I specifically stated in the Qt bug that affected users
> were using -march=native and that was being resolved to -march=bdver4, so

What does "being resolved to -march=bdver4" mean?

Could you please provide the output of the command shown in comment 1?

gcc -march=native -### hello.c

That will resolve to a specific -march option **and** zero or more -m options
for specific instructions. If -march=native resolves to **only** -march=bdver4
on your machine (as you seem to be suggesting) then that's a problem.

But if it resolves to -march=bdver4 -mno-rdrnd then GCC is behaving correctly.


> everything is not fine when using -march=native. You are correct that with
> -march=native on an affected CPU, __RDRND__ is not defined,

Well then that suggests -march=native includes -mno-rdrnd and so GCC is
behaving correctly.

> but that's what
> I used to build Qt libraries that segfaulted. I only got working libraries
> by supplying -march=x86-64-v2 or omitting -march entirely.
> 
> This is why I was asking in the Qt bug about the lack of definition for
> __RDRND__ when GCC is supplied with -march=native, and whether the
> explanation about __haswell__ still worked - because nobody involved is
> supplying -march=bdver4 as a compiler argument, everyone is using
> -march=native and trusting gcc to make a decision on the correct environment.

Which contradicts what Thiago said above.

We really need some clarity here to do anything.

Please run the -### command to give some concrete facts about what GCC is
actually doing on a machine with the relevant CPU.

Then please also provide the output of:

gcc -march=native -E -dM -x c /dev/null | grep -E -i '__tune_|rdrnd'

[Bug target/115860] [15 regression] Register pairs and regrename since r15-1579-g792f97b44ffc5e

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Stefan Schulze Frielinghaus
:

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

commit r13-9058-gf7037fd03ad842dc69e20c03942f29d982ad655e
Author: Stefan Schulze Frielinghaus 
Date:   Fri Sep 27 08:18:47 2024 +0200

s390: Fix TF to FPRX2 conversion [PR115860]

Currently subregs originating from *tf_to_fprx2_0 and *tf_to_fprx2_1
survive register allocation.  This in turn leads to wrong register
renaming.  Keeping the current approach would mean we need two insns for
*tf_to_fprx2_0 and *tf_to_fprx2_1, respectively.  Something along the
lines

(define_insn "*tf_to_fprx2_0"
  [(set (subreg:DF (match_operand:FPRX2 0 "nonimmediate_operand" "=f") 0)
(unspec:DF [(match_operand:TF 1 "general_operand" "v")]
   UNSPEC_TF_TO_FPRX2_0))]
  "TARGET_VXE"
  "#")

(define_insn "*tf_to_fprx2_0"
  [(set (match_operand:DF 0 "nonimmediate_operand" "=f")
(unspec:DF [(match_operand:TF 1 "general_operand" "v")]
   UNSPEC_TF_TO_FPRX2_0))]
  "TARGET_VXE"
  "vpdi\t%v0,%v1,%v0,1
  [(set_attr "op_type" "VRR")])

and similar for *tf_to_fprx2_1.  Note, pre register allocation operand 0
has mode FPRX2 and afterwards DF once subregs have been eliminated.

Since we always copy a whole vector register into a floating-point
register pair, another way to fix this is to merge *tf_to_fprx2_0 and
*tf_to_fprx2_1 into a single insn which means we don't have to use
subregs at all.  The downside of this is that the assembler template
contains two instructions, now.  The upside is that we don't have to
come up with some artificial insn before RA which might be more
readable/maintainable.  That is implemented by this patch.

In commit r11-4872-ge627cda5686592, the output operand specifier %V was
introduced which is used in tf_to_fprx2 only, now.  Instead of coming up
with its counterpart %F for floating-point registers, which would also
only be used in tf_to_fprx2, I print the operands directly.  This
renders %V unused which is why it is removed by this patch.

gcc/ChangeLog:

PR target/115860
* config/s390/s390.cc (print_operand): Remove operand specifier
%V.
* config/s390/s390.md (UNSPEC_TF_TO_FPRX2): New.
* config/s390/vector.md (*tf_to_fprx2_0): Remove.
(*tf_to_fprx2_1): Remove.
(tf_to_fprx2): New.

gcc/testsuite/ChangeLog:

* gcc.target/s390/vector/long-double-asm-abi.c: Adapt
scan-assembler directive.
* gcc.target/s390/vector/long-double-to-i64.c: Adapt
scan-assembler directive.
* gcc.target/s390/pr115860-1.c: New test.

(cherry picked from commit 46c2538435dfc50dd5c67c4e03ce387d1f6ebe9b)

[Bug tree-optimization/116861] [15 regression] ICE when building netpbm-11.2.10

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

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

--- Comment #12 from GCC Commits  ---
The master branch has been updated by Pan Li :

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

commit r15-3926-gcd430b1fd95dce5868ce6a8063119d253ea2f995
Author: Pan Li 
Date:   Fri Sep 27 11:03:51 2024 +0800

Widening-Mul: Fix one ICE when iterate on phi node

We iterate all phi node of bb to try to match the SAT_* pattern
for scalar integer.  We also remove the phi mode when the relevant
pattern matched.

Unfortunately the iterator may have no idea the phi node is removed
and continue leverage the free data and then ICE similar as below.

[0] psi ptr 0x75216340c000
[0] psi ptr 0x75216340c400
[1] psi ptr 0xa5a5a5a5a5a5a5a5 <=== GC freed pointer.

during GIMPLE pass: widening_mul
tmp.c: In function âfâ:
tmp.c:45:6: internal compiler error: Segmentation fault
   45 | void f(int rows, int cols) {
  |  ^
0x36e2788 internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:517
0x18005f0 crash_signal
../../gcc/toplev.cc:321
0x752163c4531f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x103ae0e bool is_a_helper::test(gimple*)
../../gcc/gimple.h:1256
0x103f9a5 bool is_a(gimple*)
../../gcc/is-a.h:232
0x103dc78 gphi* as_a(gimple*)
../../gcc/is-a.h:255
0x104f12e gphi_iterator::phi() const
../../gcc/gimple-iterator.h:47
0x1a57bef after_dom_children
../../gcc/tree-ssa-math-opts.cc:6140
0x3344482 dom_walker::walk(basic_block_def*)
../../gcc/domwalk.cc:354
0x1a58601 execute
../../gcc/tree-ssa-math-opts.cc:6312

This patch would like to fix the iterate on modified collection problem
by backup the next phi in advance.

The below test suites are passed for this patch.
* The rv64gcv fully regression test.
* The x86 bootstrap test.
* The x86 fully regression test.

PR middle-end/116861

gcc/ChangeLog:

* tree-ssa-math-opts.cc (math_opts_dom_walker::after_dom_children):
Backup
the next psi iterator before remove the phi node.

gcc/testsuite/ChangeLog:

* gcc.dg/torture/pr116861-1.c: New test.

Signed-off-by: Pan Li 

[Bug fortran/83700] [Meta-bug] Fortran Coarray issues

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

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

Bug 77873 Summary: [Coarray] [OOP] ICE in gfc_is_class_scalar_expr, at 
fortran/class.c:380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77873

   What|Removed |Added

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

[Bug fortran/77873] [Coarray] [OOP] ICE in gfc_is_class_scalar_expr, at fortran/class.c:380

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||vehre at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #2 from Andre Vehreschild  ---
Seems to work with at least gfortran 13.3.1.

[Bug target/116856] Generated Code with unaligned uint32_t potentially hardfaults on ARM (due to LDRD)

[robert.hoelzl at posteo dot de via Gcc-bugs]

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

Robert Hölzl  changed:

   What|Removed |Added

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

--- Comment #9 from Robert Hölzl  ---
I know that this solves the problem (as I wrote in my last comment).

But why does GCC handle an inline typecast (uint32_t __attribute__
((__aligned__(1)))*) different from a typecast to an typedef (u32_u*) when the
typedef is identical to the inline typecast?

In other words:

typedef uint32_t __attribute__((aligned(1))) u32_u;
uint32_t x = *(u32_u *) y;

should be identical to

uint32_t x = *(uint32_t __attribute__ ((__aligned__(1)) *) y;

right?

But the latter one is generating wrong code (which contains LDRD)

[Bug fortran/83700] [Meta-bug] Fortran Coarray issues

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

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

Bug 77885 Summary: [Coarray] [OOP] ICE in gfc_add_class_array_ref, at 
fortran/class.c:259
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77885

   What|Removed |Added

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

[Bug fortran/77885] [Coarray] [OOP] ICE in gfc_add_class_array_ref, at fortran/class.c:259

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||vehre at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #3 from Andre Vehreschild  ---
Work from at least gfortran 13.3.1 on.

[Bug tree-optimization/104789] [12/13/14/15 Regression] -Wstringop-overflow false positive at -O3 for an unrolled loop

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #17 from Sam James  ---
(In reply to Rémi Verschelde from comment #16)
> Just noting that this is still reproducible in GCC 14.2 (14.2.1 20240912
> (Red Hat 14.2.1-3)), with the reproducers from comment 7 and comment 9.
> 
> I see it had milestone moved to successive 12.x minor releases, shouldn't
> this target GCC 15 / trunk if it's still reproducible (presumably) in the
> development branch?

No, it's the earliest supported branch that still reproduces it always AFAIK,
although it might make sense for it to always be trunk until there's a fix to
be backportable, that has the side-effect of making it harder to find
trunk-only regressions I guess.

[Bug libstdc++/116847] [15 regression] r15-3859-g63a598deb0c9fc causes many excess errors

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

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

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

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

commit r15-3928-gddc72ba6c6c2c84a1a95340840bd5fde1f2bde44
Author: Jakub Jelinek 
Date:   Fri Sep 27 16:06:29 2024 +0200

diagnostic: Use vec instead of custom array reallocations for
m_classification_history/m_push_list [PR116847]

diagnostic.h already relies on vec.h, it uses auto_vec in one spot.

The following patch converts m_classification_history and m_push_list
hand-managed arrays to vec templates.
The main advantage is exponential rather than linear reallocation,
e.g. with current libstdc++ headers if one includes all the standard
headers there could be ~ 300 reallocations of the m_classification_history
array (sure, not all of them will result in actually copying the data, but
still).
In addition to that it fixes some formatting issues in the code.

2024-09-26  Jakub Jelinek  

PR libstdc++/116847
* diagnostic.h (diagnostic_option_classifier): Change type
of m_classification_history from diagnostic_classification_change_t
*
to vec.  Change type of
m_push_list from int * to vec.  Remove
m_n_classification_history
and m_n_push members.
* diagnostic.cc (diagnostic_option_classifier::init): Set
m_push_list
to vNULL rather than nullptr.  Don't initialize m_n_push. 
Initialize
m_classification_history to vNULL.
(diagnostic_option_classifier::fini): Call release () method on
m_push_list instead of free on it.  Call release () on
m_classification_history.  Don't clear m_n_push.
(diagnostic_option_classifier::push): Adjust for m_push_list and
m_classification_history being vectors rather than custom allocated
arrays with counter.
(diagnostic_option_classifier::pop): Likewise.
(classify_diagnostic): Adjust for m_classification_history being
vector rather than custom allocated array with counter.
(update_effective_level_from_pragmas): Likewise.

[Bug libstdc++/116847] [15 regression] r15-3859-g63a598deb0c9fc causes many excess errors

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

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

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

https://gcc.gnu.org/g:64072e60b1599ae7d347c2cdee46c3b0e37fc338

commit r15-3929-g64072e60b1599ae7d347c2cdee46c3b0e37fc338
Author: Jakub Jelinek 
Date:   Fri Sep 27 16:07:40 2024 +0200

diagnostic: Save/restore diagnostic context history and push/pop state for
PCH [PR116847]

The following patch on top of the just posted cleanup patch
saves/restores the m_classification_history and m_push_list
vectors for PCH.  Without that as the testcase shows during parsing
of the templates we don't report ignored diagnostics, but after loading
PCH header when instantiating those templates those warnings can be
emitted.  This doesn't show up on x86_64-linux build because configure
injects there -fcf-protection -mshstk flags during library build (and so
also during PCH header creation), but make check doesn't use those flags
and so the PCH header is ignored.

2024-09-26  Jakub Jelinek  

PR libstdc++/116847
gcc/
* diagnostic.h (diagnostic_option_classifier): Add pch_save and
pch_restore method declarations.
(diagnostic_context): Add pch_save and pch_restore inline method
definitions.
* diagnostic.cc (diagnostic_option_classifier::pch_save): New
method.
(diagnostic_option_classifier::pch_restore): Likewise.
gcc/c-family/
* c-pch.cc: Include diagnostic.h.
(c_common_write_pch): Call global_dc->pch_save.
(c_common_read_pch): Call global_dc->pch_restore.
gcc/testsuite/
* g++.dg/pch/pr116847.C: New test.
* g++.dg/pch/pr116847.Hs: New test.

[Bug analyzer/116864] New: "*" and "......" in false positive -Wanalyzer-use-of-uninitialized-value

[eggert at cs dot ucla.edu via Gcc-bugs]

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

Bug ID: 116864
   Summary: "*" and ".." in false positive
-Wanalyzer-use-of-uninitialized-value
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

Created attachment 59213
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59213&action=edit
gunzip and compile with "gcc -O2 -S -fanalyzer" on x86-64 to see the bug

Normally coreutils isn't compiled with -fanalyzer, but I recently tried it (by
using './configure --enable-gcc-warnings=expensive') and quickly gave up
because there were too many false positives.

I'm reporting the first false positive. At least I *think* it's a false
positive: the diagnostic is so puzzling and gives so few details that it's hard
to see what GCC is complaining about.

This is gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3) on x86-64. Decompress and
compile the attached file t.i.gz with:

gunzip t.i.gz
gcc -O2 -S -fanalyzer t.i

GCC outputs the following, which I can't decipher, as all the details are
listed as "*" or "..".

parse-datetime.c: In function ‘yyparse’:
parse-datetime.c:1820:9: warning: use of uninitialized value ‘*’
[CWE-457] [-Wanalyzer-use-of-uninitialized-value]
  ‘parse_datetime’: events 1-2
|
|parse-datetime.y:2395:1:
|..
|
  ‘parse_datetime’: events 3-4
|
|parse-datetime.y:2402:12:
|
+--> ‘parse_datetime_body’: event 5
   |
   |parse-datetime.y:1739:1:
   |
 ‘parse_datetime_body’: events 6-8
   |
   |parse-datetime.y:1821:6:
   |..
   |..
   |
 ‘parse_datetime_body’: event 9
   |
   |parse-datetime.y:1841:18:
   |
 ‘parse_datetime_body’: event 10
   |
   |parse-datetime.y:1870:3:
   |
   +--> ‘populate_local_time_zone_table’: event 11
  |
  |parse-datetime.y:1577:1:
  |
‘populate_local_time_zone_table’: events 12-13
  |
  |parse-datetime.y:1590:6:
  |..
  |
   <--+
   |
 ‘parse_datetime_body’: events 14-15
   |
   |parse-datetime.y:1870:3:
   |..
   |
 ‘parse_datetime_body’: event 16
   |
   |parse-datetime.y:1877:19:
   |
 ‘parse_datetime_body’: event 17
   |
   |parse-datetime.y:1902:7:
   |
   +--> ‘yyparse’: events 18-20
  |
  |parse-datetime.c:1572:1:
  |..
  |..
  |
‘yyparse’: events 21-28
  |
  |parse-datetime.c:1715:6:
  |..
  |..
  |..
  |..
  |
  +--> ‘yylex’: event 29
 |
 |parse-datetime.y:1416:1:
 |
   ‘yylex’: event 30
 |
 |parse-datetime.y:1518:16:
 |
 +--> ‘lookup_word’: event 31
|
|parse-datetime.y:1348:1:
|
  ‘lookup_word’: events 32-34
|
|parse-datetime.y:1361:29:
|
  ‘lookup_word’: event 35
|
|cc1:
| (35): ...to here
|
 <--+
 |
   ‘yylex’: events 36-37
 |
 |parse-datetime.y:1518:16:
 |
   ‘yylex’: event 38
 |
 |parse-datetime.y:1525:29:
 |
  <--+
  |
‘yyparse’: events 39-49
  |
  |parse-datetime.c:1739:16:
  |..
  |..
  |..
  |..
  |
‘yyparse’: events 50-51
  |
  |parse-datetime.c:1800:6:
  |
‘yyparse’: event 52
  |
  |parse-datetime.c:1820:9:
  |

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

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

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

Bug 116867 Summary: Incorrectly report a constexpr function as non-constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116867

   What|Removed |Added

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

[Bug c++/116867] Incorrectly report a constexpr function as non-constant

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Fixed by r14-10133

commit f541757ba4632e204169dd08a5f10c782199af42
Author: Jakub Jelinek 
Date:   Thu Apr 25 20:45:04 2024 +0200

c++: Fix constexpr evaluation of parameters passed by invisible reference
[PR111284]

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

[Bug c++/111284] [12 Regression] Some passing-by-value parameters are mishandled since GCC 9, affecting libstdc++'s constexpr std::string

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||hzhou11 at students dot 
kennesaw.e
   ||du

--- Comment #15 from Marek Polacek  ---
*** Bug 116867 has been marked as a duplicate of this bug. ***

[Bug c++/116867] New: Incorrectly report a constexpr function as non-constant

[hzhou11 at students dot kennesaw.edu via Gcc-bugs]

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

Bug ID: 116867
   Summary: Incorrectly report a constexpr function as
non-constant
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hzhou11 at students dot kennesaw.edu
  Target Milestone: ---

Output of "gcc -v":

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
13.2.0-23ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-13
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-libstdcxx-backtrace --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-13-uJ7kn6/gcc-13-13.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-13-uJ7kn6/gcc-13-13.2.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (Ubuntu 13.2.0-23ubuntu4) 


Now the problem:

#include
#include
#include
#include
constexpr std::string join(std::vector vec, char delimiter) {
  auto result = std::accumulate(std::next(vec.begin()), vec.end(),
vec[0],
[&delimiter](const std::string& a, const std::string& b) {
  return a + delimiter + b;
});
  return result;
}
main() {
  static_assert(join({ "one", "two", "three" }, ';') == "one;two;three");
}

My expectation is there should be no error because the concatenated string is
deallocated by the end of constant evaluation, but gcc gives the following
error:

main.cpp:92:56: error: non-constant condition for static assertion
   92 | static_assert(join({ "one", "two", "three" }, ';') ==
"one;two;three");
  |  
~^~
main.cpp:92:75:   in ‘constexpr’ expansion of ‘join(std::vector >, char)(59)’
main.cpp:92:75:   in ‘constexpr’ expansion of ‘std::accumulate(_InputIterator,
_InputIterator, _Tp, _BinaryOperation) [with _InputIterator =
__gnu_cxx::__normal_iterator<__cxx11::basic_string*,
vector<__cxx11::basic_string > >; _Tp = __cxx11::basic_string; _BinaryOperation
= join(std::vector >, char)::](vec.std::vector >::end(),
std::__cxx11::basic_string((*(const std::__cxx11::basic_string*)(&
vec.std::vector >::operator[](0, join(std::vector >, char)::{delimiter})’
main.cpp:92:75:   in ‘constexpr’ expansion of
‘std::__cxx11::basic_string(__init)’
main.cpp:92:56: error: accessing
‘std::__cxx11::basic_string_M_allocated_capacity’ member instead of
initialized ‘std::__cxx11::basic_string_M_local_buf’ member in constant
expression

[Bug c++/102594] ICE in decay_conversion, at cp/typeck.c:2311 since r8-7514-ge278212eeea4f57d

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

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

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

https://gcc.gnu.org/g:96e0370f4daef29b918aafcff68c7f5e4ef397fd

commit r15-3933-g96e0370f4daef29b918aafcff68c7f5e4ef397fd
Author: Marek Polacek 
Date:   Thu Sep 5 16:45:32 2024 -0400

c++: ICE with structured bindings and m-d array [PR102594]

We ICE in decay_conversion with this test:

  struct S {
S() {}
  };
  S arr[1][1];
  auto [m](arr3);

But not when the last line is:

  auto [n] = arr3;

Therefore the difference is between copy- and direct-init.  In
particular, in build_vec_init we have:

  if (direct_init)
from = build_tree_list (NULL_TREE, from);

and then we call build_vec_init again with init==from.  Then
decay_conversion gets the TREE_LIST and it crashes.

build_aggr_init has:

  /* Wrap the initializer in a CONSTRUCTOR so that
build_vec_init
 recognizes it as direct-initialization.  */
  init = build_constructor_single (init_list_type_node,
   NULL_TREE, init);
  CONSTRUCTOR_IS_DIRECT_INIT (init) = true;

so I propose to do the same in build_vec_init.

PR c++/102594

gcc/cp/ChangeLog:

* init.cc (build_vec_init): Build up a CONSTRUCTOR to signal
direct-initialization rather than a TREE_LIST.

gcc/testsuite/ChangeLog:

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

Reviewed-by: Jason Merrill 

[Bug c++/116866] RFE: warn about suspected missing "throw" when discarding temporaries that inherit from std::exception

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

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

--- Comment #3 from Jonathan Wakely  ---
If we add [[nodiscard]] to the constructors of the standard exception types
then we get a warning with no compiler changes needed:

struct Exception
{
[[nodiscard]] Exception(const char*) { }
};

int divide(int num, int denom) {
if (denom == 0)
{
Exception("division by zero");
}
return num / denom;
}

It should work to do `struct [[nodiscard]] Exception` instead of putting it on
each constructor, but that's PR 85973

[Bug middle-end/116868] New: GCC trunk doesn't eliminate a superfluous new/delete pair

[dccitaliano at gmail dot com via Gcc-bugs]

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

Bug ID: 116868
   Summary: GCC trunk doesn't eliminate a superfluous new/delete
pair
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dccitaliano at gmail dot com
  Target Milestone: ---

Maybe this is known, but i wasn't able to find the exact duplicate.
(this is the closest I found -- apologies for the churn, if any)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78104

https://godbolt.org/z/579rGG95z

#include 
int sumVector() {
const std::vector vec = {1};
int sum = 0;
for (int i = 0; i < vec.size(); i++) {
sum += vec[i];
}
return sum;
}

At -O3 emits:

sumVector():
sub rsp, 8
mov edi, 4
calloperator new(unsigned long)
mov esi, 4
mov DWORD PTR [rax], 1
mov rdi, rax
calloperator delete(void*, unsigned long)
mov eax, 1
add rsp, 8
ret

I'd expect to emit something like (clang does it):

sumVector():
mov eax, 1
ret

[Bug middle-end/116868] GCC trunk doesn't eliminate a superfluous new/delete pair

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Maybe a dup of bug 96945 or PR 109442 .

[Bug c++/116866] RFE: warn about suspected missing "throw" when discarding temporaries that inherit from std::exception

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

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

--- Comment #4 from David Malcolm  ---
(In reply to Jonathan Wakely from comment #3)
> If we add [[nodiscard]] to the constructors of the standard exception types
> then we get a warning with no compiler changes needed:

...in Compiler Explorer as:
  https://godbolt.org/z/Po4oMPcox

[Bug middle-end/114855] ICE: Segfault when compiling large autogenerated C source file

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #57 from Andrew Macleod  ---
FWIW, on my last run, enabling early VRP sped up my -O1 compilation by a fair
amount. total compilation dropped from 480 seconds to 380 seconds... 

It took 2.5 seconds to run, and im going to guess might have cleaned the code
up somewhat.

Might be worth looking at a Fast VRP pass at -O1?  I'm not sure how/where to
add NEXT_PASS (pass_fast_vrp);  to run it at -O1, but it can be easily
experimented with via

--enable-tree-evrp --param=vrp-block-limit=1

which will always run Fast VRP as the EVRP pass.

[Bug analyzer/116865] New: ICE when compiling GNU coreutils numfmt with -fanalyzer

[eggert at cs dot ucla.edu via Gcc-bugs]

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

Bug ID: 116865
   Summary: ICE when compiling GNU coreutils numfmt with
-fanalyzer
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Keywords: ice-checking
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

Created attachment 59214
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59214&action=edit
Compile with "gcc -O2 -S -fanalyzer t.i" to get internal compiler error

This is gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3) on x86-64. I don't see a
problem with gcc-13 on Ubuntu so I guess it is a regression.

Decompress and compile the attached program with:

gunzip t.i.gz
gcc -O2 -S -fanalyzer t.i

The output is:

during IPA pass: analyzer
src/numfmt.c: In function ‘unit_to_umax’:
src/numfmt.c:843:53: internal compiler error: in build2, at tree.cc:5093
  843 |   if (*end == 'i' && 2 <= n_len && ! c_isdigit (*(end - 1)))
  | ^~
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
Preprocessed source stored into /tmp/cctQjDWE.out file, please attach this to
your bugreport.

[Bug analyzer/116865] ICE when compiling GNU coreutils numfmt with -fanalyzer

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

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

--- Comment #2 from Andrew Pinski  ---
./cc1 -fanalyzer t.i -quiet -O2
during IPA pass: analyzer
src/numfmt.c: In function ‘unit_to_umax’:
src/numfmt.c:843:53: internal compiler error: in build2, at tree.cc:5099
0x25cc02e internal_error(char const*, ...)
/home/apinski/src/upstream-gcc/gcc/gcc/diagnostic-global-context.cc:517
0x9dc15d fancy_abort(char const*, int, char const*)
/home/apinski/src/upstream-gcc/gcc/gcc/diagnostic.cc:1512
0x8f0775 build2(tree_code, tree_node*, tree_node*, tree_node*)
/home/apinski/src/upstream-gcc/gcc/gcc/tree.cc:5099
0x15c07a9 ana::region_model::get_representative_path_var_1(ana::svalue const*,
hash_set >*,
ana::logger*) const
/home/apinski/src/upstream-gcc/gcc/gcc/analyzer/region-model.cc:5409
0x15c0a9a ana::region_model::get_representative_path_var(ana::svalue const*,
hash_set >*,
ana::logger*) const
/home/apinski/src/upstream-gcc/gcc/gcc/analyzer/region-model.cc:5445
0x15c04cd ana::region_model::get_representative_path_var(ana::svalue const*,
hash_set >*,
ana::logger*) const
/home/apinski/src/upstream-gcc/gcc/gcc/analyzer/region-model.cc:5431
0x15c04cd ana::region_model::get_representative_path_var_1(ana::svalue const*,
hash_set >*,
ana::logger*) const
/home/apinski/src/upstream-gcc/gcc/gcc/analyzer/region-model.cc:5356
0x15c0a9a ana::region_model::get_representative_path_var(ana::svalue const*,
hash_set >*,
ana::logger*) const
/home/apinski/src/upstream-gcc/gcc/gcc/analyzer/region-model.cc:5445
0x15c0b84 ana::region_model::get_representative_path_var(ana::svalue const*,
hash_set >*,
ana::logger*) const
/home/apinski/src/upstream-gcc/gcc/gcc/analyzer/region-model.cc:5431
0x15c0b84 ana::region_model::get_representative_tree(ana::svalue const*,
ana::logger*) const
/home/apinski/src/upstream-gcc/gcc/gcc/analyzer/region-model.cc:5477
0x253d892 ana::region_model::check_symbolic_bounds(ana::region const*,
ana::svalue const*, ana::svalue const*, ana::svalue const*,
ana::access_direction, ana::svalue const*, ana::region_model_context*) const
/home/apinski/src/upstream-gcc/gcc/gcc/analyzer/bounds-checking.cc:1324
0x253db71 ana::region_model::check_region_bounds(ana::region const*,
ana::access_direction, ana::svalue const*, ana::region_model_context*) const
/home/apinski/src/upstream-gcc/gcc/gcc/analyzer/bounds-checking.cc:1427
0x15becfb ana::region_model::check_region_access(ana::region const*,
ana::access_direction, ana::svalue const*, ana::region_model_context*) const
/home/apinski/src/upstream-gcc/gcc/gcc/analyzer/region-model.cc:3299
0x15becfb ana::region_model::check_region_access(ana::region const*,
ana::access_direction, ana::svalue const*, ana::region_model_context*) const
/home/apinski/src/upstream-gcc/gcc/gcc/analyzer/region-model.cc:3288
0x15becfb ana::region_model::check_region_for_read(ana::region const*,
ana::region_model_context*) const
/home/apinski/src/upstream-gcc/gcc/gcc/analyzer/region-model.cc:
0x15becfb ana::region_model::check_region_for_read(ana::region const*,
ana::region_model_context*) const
/home/apinski/src/upstream-gcc/gcc/gcc/analyzer/region-model.cc:3330
0x15becfb ana::region_model::get_store_value(ana::region const*,
ana::region_model_context*) const
/home/apinski/src/upstream-gcc/gcc/gcc/analyzer/region-model.cc:2894
0x15c19ca ana::region_model::get_rvalue(ana::path_var,
ana::region_model_context*) const
/home/apinski/src/upstream-gcc/gcc/gcc/analyzer/region-model.cc:2814
0x15c6595 ana::region_model::on_assignment(gassign const*,
ana::region_model_context*)
/home/apinski/src/upstream-gcc/gcc/gcc/analyzer/region-model.cc:1448
0x15889a1 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::uncertainty_t*, bool*,
ana::path_context*)
/home/apinski/src/upstream-gcc/gcc/gcc/analyzer/engine.cc:1538
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 analyzer/116865] ICE when compiling GNU coreutils numfmt with -fanalyzer

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

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

--- Comment #1 from Andrew Pinski  ---
  if ((code == MINUS_EXPR || code == PLUS_EXPR || code == MULT_EXPR)
  && arg0 && arg1 && tt && POINTER_TYPE_P (tt)
  /* When sizetype precision doesn't match that of pointers
 we need to be able to build explicit extensions or truncations
 of the offset argument.  */
  && TYPE_PRECISION (sizetype) == TYPE_PRECISION (tt))
gcc_assert (TREE_CODE (arg0) == INTEGER_CST
&& TREE_CODE (arg1) == INTEGER_CST);


That means we are using a pointer type with PLUS/MINUS/MULT which is invalid
AST/IR for generic . Let me try to reduce it.

[Bug middle-end/116753] [13/14/15 Regression] GCC trunk (-O3) can't fold a loop into a constant

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com,
   ||jakub at gcc dot gnu.org
   Keywords|needs-bisection |

--- Comment #4 from Jakub Jelinek  ---
This changed with r13-3596-ge7310e24b1c0ca67b1bb507c1330b2bf39e59e32

[Bug tree-optimization/116861] [15 regression] ICE when building netpbm-11.2.10

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

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

Sam James  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pan2.li at intel dot com
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #13 from Sam James  ---
Fixed, thanks!

[Bug analyzer/116865] ICE when compiling GNU coreutils numfmt with -fanalyzer

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-09-27
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
Reduced testcase:
```
int f(int l) {
  char *t_string = __builtin_calloc(l + 2, 1);
  char *end = t_string + l - 1;
  return '0' != *(end - 1);
}
```

[Bug c++/116866] New: RFE: warn about suspected missing "throw" when discarding temporaries that inherit from std::exception

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

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

Bug ID: 116866
   Summary: RFE: warn about suspected missing "throw" when
discarding temporaries that inherit from
std::exception
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

See
https://gitlab.com/antto/pimpmykicadbom/-/commit/c338027d737d02504fe92a6df00add2f59f462dd

which has:

>From c338027d737d02504fe92a6df00add2f59f462dd Mon Sep 17 00:00:00 2001
From: cad 
Date: Fri, 27 Sep 2024 18:16:33 +0300
Subject: [PATCH] throwing an exception might work better with a throw

---
 pimpmykicadbom.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/pimpmykicadbom.cpp b/pimpmykicadbom.cpp
index 04bed95..a904086 100644
--- a/pimpmykicadbom.cpp
+++ b/pimpmykicadbom.cpp
@@ -2593,7 +2593,7 @@ tbl_group_t BOM::prep(GROUP &g)
 // generate a hash/color
 if (pcfg == nullptr)
 {
-std::logic_error("pcfg is nullptr");
+throw std::logic_error("pcfg is nullptr");
 }
 const CFG &cfg = *pcfg;
 const vector &v_cci = cfg.v_clrinfl;
@@ -2975,7 +2975,7 @@ vector gen_co(BOM &bom)
 vector vec;
 if (bom.pcfg == nullptr)
 {
-std::logic_error("pcfg is nullptr");
+throw std::logic_error("pcfg is nullptr");
 }
 const CFG &cfg = *bom.pcfg;
 const vector &v_co = cfg.v_colorder;

It would be nice if we warned about such cases (if we don't already), perhaps
something like:

  warning: possible missing `throw' [-Wsomething-or-other]
std::logic_error("pcfg is nullptr");

throw 

>From discussion on IRC:

 feels like a potential new warning for g++ if we don't have one
already
 I don't think they do, because it has a non-trivial dtor. We could
add [[nodiscard]] to the class declaration, but I think that doesn't actually
work with gcc right now (it doesn't warn when it should)
 jwakely: is it an instance of a subclass derived from an "exception"
base?
 or whatnot
 yes
 the non-trivial dtor makes the compiler think that creating a
temporary that immediately goes out of scope might be done for its side effects
 (my knowledge of C++ exceptions is hazy, sorry)
 but we could either add [[nodiscard]] to it, or add a heuristic in
the compiler that warns about any temporary of a type derived from
std::exception
 as a heuristic: if the C++ FE sees a   exception_subclass (args);   
 by itself, warn did you mean "throw "   ?
 since such types do not have useful side effects, and it's probably a
typo like this case
 yup
 for belt and braces, you could check if the statement that creates
that temporary exception object is the last statement of a block
 because if there are more statements in that block, maybe the author
expected them to be reached. If they were intending to throw, they wouldn't
have written unreachable statements after the throw
 probably overkill though
 in case I'm not being clear:  if (some_condition) {
std::range_error("blah");  func("this would be unreachable if the previous
statement was a throw"); }
 but I can't think of a time when anybody would ever do that, so I
think your original heuristic is good enough. A discarded temporary of a type
that inherits from std::exception is probably a mistake

[Bug c++/116866] RFE: warn about suspected missing "throw" when discarding temporaries that inherit from std::exception

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

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

--- Comment #1 from Andrew Pinski  ---
>We could add [[nodiscard]] to the class declaration, but I think that doesn't 
>actually work with gcc right now (it doesn't warn when it should)

That would be PR 85973 .

[Bug c++/116866] RFE: warn about suspected missing "throw" when discarding temporaries that inherit from std::exception

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-09-27
 Status|UNCONFIRMED |NEW

[Bug c++/116866] RFE: warn about suspected missing "throw" when discarding temporaries that inherit from std::exception

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

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

--- Comment #2 from David Malcolm  ---
A simple example:

#include 

int divide(int num, int denom) {
if (denom == 0)
  std::invalid_argument ("division by zero"); // forgot "throw"
return num / denom;
}

which compiles with -Wall with gcc 14.2 without warnings:
  https://godbolt.org/z/c6r5PM97W
constructing and desctructing the exception object, and then falling through to
the division.

[Bug c++/102594] ICE in decay_conversion, at cp/typeck.c:2311 since r8-7514-ge278212eeea4f57d

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

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

--- Comment #4 from Marek Polacek  ---
Fixed on trunk so far.  I think it makes sense to backport to 14.

[Bug c++/116867] Incorrectly report a constexpr function as non-constant

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection,
   ||rejects-valid

--- Comment #1 from Andrew Pinski  ---
Looks to be already fixed in GCC 13.3.0.

[Bug target/116869] Profiler count register conflicts with regparm for i386-pc-msdosdjgpp

[jwjagersma at gmail dot com via Gcc-bugs]

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

--- Comment #3 from jwjagersma at gmail dot com ---
(In reply to Andrew Pinski from comment #1)
> msdosdjgpp might be the only target which does not define
> NO_PROFILE_COUNTERS .

I figured as much, but wasn't sure.  From briefly poking around in
config/i386 I got the impression that there could be more such targets.

[Bug target/116870] Corrupt executable created by GCC 14.2 on Windows MinGW64 with mingw-w64-x86_64-toolchain

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Target|mingw-w64-x86_64|
 Status|UNCONFIRMED |RESOLVED
   Host|mingw-w64-x86_64|

--- Comment #1 from Andrew Pinski  ---
This is a binutils (ld) bug and not a GCC bug and should be reported there
instead: https://sourceware.org/bugzilla/ .

It might be the case that the debug segment needs to be stripped first and
seperated into a PDB and then you need to use gcodeview  .

[Bug target/116870] New: Corrupt executable created by GCC 14.2 on Windows MinGW64 with mingw-w64-x86_64-toolchain

[zmajeed at sbcglobal dot net via Gcc-bugs]

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

Bug ID: 116870
   Summary: Corrupt executable created by GCC 14.2 on Windows
MinGW64 with mingw-w64-x86_64-toolchain
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zmajeed at sbcglobal dot net
  Target Milestone: ---

The debug build of duckdb on Windows MinGW64 produces a bad executable binary -
the release build works fine

DuckDB is large program at https://github.com/duckdb/duckdb - it's built in
MSYS2 MinGW64 on Windows - a debug build takes 25-30 minutes

Here's the resulting executable

--

duckdb -version
-bash: duckdb: cannot execute binary file: Exec format error

ls -l duckdb
-rwxr-xr-x 3289334503 Sep 27 12:32 duckdb

file duckdb
duckdb: PE32+ executable (console) x86-64, for MS Windows, 21 sections

--

I used readobjpe to get more info on the object - it shows section 14
.debug_info is invalid

--

readobjpe duckdb

Reading: duckdb
WARNING section VirtualSize size 0xaf6f51c3 is larger than 2GB and suggests
this object is corrupt
File: duckdb  Object type letter: P version: 80
 64bit? : yes
 filesize   : 3301642798
 offsetsize : 64
 pointersize: 64
 ftype  : 0
 endianness : 2
 nthdroffset: 0x0084
 Opt-hdr-offset : 0x0098
 Opt-hdr-size   : 0x00f0
 symtab-offset  : 0xba562e00
 strtab-offset  : 0xbd2a358e
 strtab-size: 0x07a0dca0
 sectable-offset: 0x0188
nt header
  machine   : 0x8664
  NumberOfSects : 0x0016
  PtrToSymTab   : 0xba562e00
  NumberofSyms  : 0x0028394f
  OptHdrSize: 0x00f0
  Charctrstics  : 0x0026
Optional Header
  Magic : 0x020b
  SectionAlign  : 0x
  SizeOfHeadrs  : 0x0600
  ImageBase : 0x14000
Display 23 sections.

Section 14 fileoff: 0x0390
  Name:   /19   :  .debug_info
  VirtSize   : 0xaf6f51c3  (2943308227)
  VirtAddr   : 0x0468d000  (73977856)
  Raw size   : 0xaf6f5200  (2943308288)
  Ptr To Rawdata : 0x0467e600  (73917952)
  Characteristics: 0x4240  (1107296320)

--

Here's duckdb docs on setting the Windows environment and building from source
- https://duckdb.org/docs/dev/building/build_instructions

Here are incantations for a debug build that are not documented

cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DBUILD_EXTENSIONS="icu;parquet;json"
-B build -DENABLE_SANITIZER=FALSE -DENABLE_UBSAN=0 -DDISABLE_UNITY=1

cmake --build build --config Debug

The extra cmake options disable sanitizers that are not supported on Windows -
and disable cmake unity build to compile each source file separately

I tried a build with -gdwarf-4 but it also produced a bad executable

--

Snippets from build logs

[749/2146] c++.exe -DDUCKDB -DDUCKDB_BUILD_LIBRARY
-DDUCKDB_EXTENSION_ICU_LINKED=1 -DDUCKDB_EXTENSION_JSON_LINKED=1
-DDUCKDB_EXTENSION_PARQUET_LINKED=1 -DDUCKDB_MAIN_LIBRARY -Isrc/include
-Ithird_party/fsst -Ithird_party/fmt/include -Ithird_party/hyperloglog
-Ithird_party/fastpforlib -Ithird_party/skiplist -Ithird_party/fast_float
-Ithird_party/re2 -Ithird_party/miniz -Ithird_party/utf8proc/include
-Ithird_party/concurrentqueue -Ithird_party/pcg -Ithird_party/mbedtls/include
-Ithird_party/jaro_winkler -Ithird_party/yyjson/include -Iextension
-Iextension/icu/include -Iextension/parquet/include -Iextension/json/include -g
-g -O0 -DDEBUG -Wall-Wunused -Werror=vla -Wnarrowing -pedantic -Wextra
-Wno-unused-parameter -Wno-redundant-move -Wimplicit-fallthrough -std=c++11 -MD
-MT
src/function/table/system/CMakeFiles/duckdb_table_func_system.dir/duckdb_optimizers.cpp.obj
-MF
src\function\table\system\CMakeFiles\duckdb_table_func_system.dir\duckdb_optimizers.cpp.obj.d
-
o
src/function/table/system/CMakeFiles/duckdb_table_func_system.dir/duckdb_optimizers.cpp.obj
-c src/function/table/system/duckdb_optimizers.cpp

[2143/2146] cmd.exe /C "cd . && mingw64\bin\c++.exe -D_POSIX_C_SOURCE=200809L
-g -g -O0 -DDEBUG -Wall-Wu
nused -Werror=vla -Wnarrowing -pedantic -Wextra -Wno-unused-parameter
-Wno-redundant-move -Wimplicit-fallthrough   -shared -o src\libduckdb.dll
-Wl,--out-implib,src\libduckdb.dll.a
-Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles\duckdb.rsp &&
cd ."

[2144/2146] cmd.exe /C "cd . && mingw64\bin\c++.exe -D_POSIX_C_SOURCE=200809L
-g -g -O0 -DDEBUG -Wall-Wunused -Werror=vla -Wnarrowing -pedantic 
tools/shell/CMakeFiles/shell.dir/shell.c.obj -o duckdb.exe
-Wl,--out-implib,tools\shell\libduckdb.dll.a
-Wl,--major-image-version,0,--minor-image-version,0 
tools/sqlite3_a

[Bug c++/116866] RFE: warn about suspected missing "throw" when discarding temporaries that inherit from std::exception

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

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

--- Comment #5 from David Malcolm  ---
(In reply to Jonathan Wakely from comment #3)
> If we add [[nodiscard]] to the constructors of the standard exception types
> then we get a warning with no compiler changes needed:

Is it possible to do this to the standard library?  Even if it is, maybe a
warning for discarded temporary of a type that inherits from std::exception is
still useful.

A possible wording:

  warning: discarding temporary exception object; did you mean to `throw' it?
[-Wmissing-throw]
  std::invalid_argument ("division by zero");
  ^~
  

  note: `std::invalid_argument' is derived from `std::exception'
  

Probably shouldn't issue this warning for e.g.: named local that you forgot to
throw:

#include 

int divide(int num, int denom) {
std::invalid_argument exc ("division by zero");
return num / denom;
}

since the unused-variable warning should detect it.

[Bug sanitizer/116863] New: TSAN segfault in __sanitizer::CombinedAllocator::Allocate

[jpeng_xy at 163 dot com via Gcc-bugs]

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

Bug ID: 116863
   Summary: TSAN segfault in
__sanitizer::CombinedAllocator::Allocate
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jpeng_xy at 163 dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

The function aio_write() in glibc2.34 (including higher versions of glibc)
calls the internal function __pthread_create() to create a thread. TSAN is
unable to intercept internal function __pthread_create() (nptl: Move
pthread_create, thrd_create into libc:
https://sourceware.org/git/?p=glibc.git;a=commit;h=f47f1d91af985a9028fb399da21eab460d887a15).


segmentation fault call trace:
#0  0x76c0b826 in
__sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<__tsan::AP64>,
__sanitizer::LargeMmapAllocatorPtrArrayDynamic>::Allocate(__sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__tsan::AP64>
>*, unsigned long, unsigned long) ()
   from /lib64/libtsan.so.2
#1  0x76c08f4d in __tsan::user_alloc_internal(__tsan::ThreadState*,
unsigned long, unsigned long, unsigned long, bool) ()
   from /lib64/libtsan.so.2
#2  0x76c090b8 in __tsan::user_alloc(__tsan::ThreadState*, unsigned
long, unsigned long) ()
   from /lib64/libtsan.so.2
#3  0x76bc365c in __interceptor_malloc () from /lib64/libtsan.so.2
#4  0x76a198d3 in __aio_notify_only () from /lib/libc.so.6
#5  0x76a1995b in __aio_notify () from /lib/libc.so.6
#6  0x76a18e2b in handle_fildes_io () from /lib/libc.so.6
#7  0x76a10142 in start_thread () from /lib/libc.so.6
#8  0x76a8b8a0 in clone () from /lib/libc.so.6


Testcase preproduce bug:
https://sourceware.org/git/?p=glibc.git;a=blob;f=rt/tst-aio5.c;h=15b6558eb8fc66575a098266229792ac007dd283;hb=HEAD

Compilation command: x86_64-linux-gcc tst-aio5.c -Wall -Wextra
-fsanitize=thread

[Bug c++/116793] [15 regression] ice in gimplify_var_or_parm_decl, at gimplify.cc:3309 since r15-3513

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

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

Arsen Arsenović  changed:

   What|Removed |Added

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

--- Comment #15 from Arsen Arsenović  ---
should be fixed on trunk

[Bug target/116856] Generated Code with unaligned uint32_t potentially hardfaults on ARM (due to LDRD)

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

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

--- Comment #8 from Richard Earnshaw  ---
BTW, rewriting the code as:

#include 

typedef uint32_t __attribute__((aligned(1))) u32_u;

void f()
{
static uint8_t array[64];
for (uint8_t i = 0; i < sizeof(array); i++)
{
*(u32_u*) &array[i + 4] ^=
*(u32_u*)&array[i];
}
}

Seems to address the problem, giving
f():
  ldr r3, .L5
  add r0, r3, #64
.L2:
  ldr r2, [r3, #-4] @ unaligned
  ldr r1, [r3] @ unaligned
  eors r2, r2, r1
  str r2, [r3], #1 @ unaligned
  cmp r0, r3
  bne .L2
  bx lr

[Bug fortran/81265] allocatable coarrays in submodule subroutines wrongly identified as unallocated

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

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

Andre Vehreschild  changed:

   What|Removed |Added

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

--- Comment #3 from Andre Vehreschild  ---
Patch at https://gcc.gnu.org/pipermail/fortran/2024-September/061106.html

Waiting for review

[Bug target/115860] [15 regression] Register pairs and regrename since r15-1579-g792f97b44ffc5e

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Stefan Schulze Frielinghaus
:

https://gcc.gnu.org/g:7051fa5fa4eaa24785a64072490c1e0c65039915

commit r12-10729-g7051fa5fa4eaa24785a64072490c1e0c65039915
Author: Stefan Schulze Frielinghaus 
Date:   Fri Sep 27 12:45:42 2024 +0200

s390: Fix TF to FPRX2 conversion [PR115860]

Currently subregs originating from *tf_to_fprx2_0 and *tf_to_fprx2_1
survive register allocation.  This in turn leads to wrong register
renaming.  Keeping the current approach would mean we need two insns for
*tf_to_fprx2_0 and *tf_to_fprx2_1, respectively.  Something along the
lines

(define_insn "*tf_to_fprx2_0"
  [(set (subreg:DF (match_operand:FPRX2 0 "nonimmediate_operand" "=f") 0)
(unspec:DF [(match_operand:TF 1 "general_operand" "v")]
   UNSPEC_TF_TO_FPRX2_0))]
  "TARGET_VXE"
  "#")

(define_insn "*tf_to_fprx2_0"
  [(set (match_operand:DF 0 "nonimmediate_operand" "=f")
(unspec:DF [(match_operand:TF 1 "general_operand" "v")]
   UNSPEC_TF_TO_FPRX2_0))]
  "TARGET_VXE"
  "vpdi\t%v0,%v1,%v0,1
  [(set_attr "op_type" "VRR")])

and similar for *tf_to_fprx2_1.  Note, pre register allocation operand 0
has mode FPRX2 and afterwards DF once subregs have been eliminated.

Since we always copy a whole vector register into a floating-point
register pair, another way to fix this is to merge *tf_to_fprx2_0 and
*tf_to_fprx2_1 into a single insn which means we don't have to use
subregs at all.  The downside of this is that the assembler template
contains two instructions, now.  The upside is that we don't have to
come up with some artificial insn before RA which might be more
readable/maintainable.  That is implemented by this patch.

In commit r11-4872-ge627cda5686592, the output operand specifier %V was
introduced which is used in tf_to_fprx2 only, now.  Instead of coming up
with its counterpart %F for floating-point registers, which would also
only be used in tf_to_fprx2, I print the operands directly.  This
renders %V unused which is why it is removed by this patch.

gcc/ChangeLog:

PR target/115860
* config/s390/s390.cc (print_operand): Remove operand specifier
%V.
* config/s390/s390.md (UNSPEC_TF_TO_FPRX2): New.
* config/s390/vector.md (*tf_to_fprx2_0): Remove.
(*tf_to_fprx2_1): Remove.
(tf_to_fprx2): New.

gcc/testsuite/ChangeLog:

* gcc.target/s390/vector/long-double-asm-abi.c: Adapt
scan-assembler directive.
* gcc.target/s390/vector/long-double-to-i64.c: Adapt
scan-assembler directive.
* gcc.target/s390/pr115860-1.c: New test.

(cherry picked from commit 46c2538435dfc50dd5c67c4e03ce387d1f6ebe9b)

[Bug target/116854] GCC incorrectly assumes all CPUs where -march=native resolves to -march=bdver4 will have RDRND support

[Ganesh.Gopalasubramanian at amd dot com via Gcc-bugs]

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

--- Comment #15 from GGanesh  ---
I wanted to get it confirmed from our BIOS and Kernel developer manuals
(https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/programmer-references/50742_15h_Models_60h-6Fh_BKDG.pdf).

RDRAND is *supported*/*enabled* for Models 60h-6Fh.

However, since the latest kernel code is not setting it unconditionally, we can
only rely on the cpuid bits enabled by Kernel. If it is disabled, I personally
feel we need to remove it from the list of ISAs supported by Excavator in gcc
as well.

[Bug target/116856] Generated Code with unaligned uint32_t potentially hardfaults on ARM (due to LDRD)

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

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Earnshaw  ---
*(uint32_t __attribute__ ((__aligned__(1)))*) &array[i + 4] ^=
*(uint32_t __attribute__ ((__aligned__(1)))*)
&array[i];

By casting an address to uint32_t you are asserting to the compiler that the
address is 32-bit aligned.  LDRD does two 32-bit aligned loads (see the Arm ARM
DDI0553B).  So this code is safe iff your address calculations produce 32-bit
aligned values.  If they don't then that's a bug in your code, not the
compiler.

[Bug tree-optimization/116785] [15 Regression] RAJAPerf REDUCE_SUM regresses with r15-792-gf0a02467bbc35a

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2024-09-27

--- Comment #11 from Richard Biener  ---
Note I have to use -fno-vect-cost-model on the reduced testcase to get
vectorization.  There is indeed

  [t.ii:27:12] # PT = anything 
  tBasis_65 = [t.ii:27:21] this_61(D)->m_Bt;

  [t.ii:71:57] # PT = anything
  _507 = Y_66 + _506;

derefaddrtmp(22) = &NULL
*ANYTHING = derefaddrtmp(22)

Likely the volatile

  irep ={v} 0;



...
irep.1_36 = &ANYTHING
_37 = irep.1_36 + UNKNOWN
_37 = &NONLOCAL
*ANYTHING = _37
irep.3_38 = &ANYTHING
_39 = irep.3_38

because:

  irep.1_36 ={v} irep;
  _37 = irep.1_36 + 1;
  irep ={v} _37;

well, a volatile read-modify-write.  Not using volatile int for RepIndex_type
fixes it.

Note that the volatile handling was adjusted with r15-579-ga9251ab3c91c8c but
it didn't have the desired effect due to bugs fixed with the later changes.

Note that the handling of volatiles, esp. on the store side is a bit too
conservative.  Can you try the following on the original benchmark?

diff --git a/gcc/tree-ssa-structalias.cc b/gcc/tree-ssa-structalias.cc
index d6a53f801f0..54c4818998d 100644
--- a/gcc/tree-ssa-structalias.cc
+++ b/gcc/tree-ssa-structalias.cc
@@ -3646,7 +3646,7 @@ get_constraint_for_1 (tree t, vec *results, bool
address_p,
   }
 case tcc_reference:
   {
-   if (TREE_THIS_VOLATILE (t))
+   if (!lhs_p && TREE_THIS_VOLATILE (t))
  /* Fall back to anything.  */
  break;

@@ -3751,7 +3751,7 @@ get_constraint_for_1 (tree t, vec *results, bool
address_p,
   }
 case tcc_declaration:
   {
-   if (VAR_P (t) && TREE_THIS_VOLATILE (t))
+   if (!lhs_p && VAR_P (t) && TREE_THIS_VOLATILE (t))
  /* Fall back to anything.  */
  break;
get_constraint_for_ssa_var (t, results, address_p);

[Bug target/83464] [SH] ICE: in final_scan_insn, at final.c:3025 with -mlra

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #9 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #8)
> (In reply to John Paul Adrian Glaubitz from comment #6)
> > (In reply to Oleg Endo from comment #5)
> > > I'm not sure this is an acceptable solution.  It disables various other
> > > optimizations and reduces in worse code than normally should be.  When you
> > > rebuild all of debian with LRA enabled, please make sure to take out any
> > > such hacks.
> > 
> > It's not a solution, it was a work-around.
> > 
> > FWIW, I have tried to build the package with the gcc-10 package from Debian
> > (which is a recent snapshot) and -mlra, but so far cmake doesn't want to
> > accept gcc-10 as the build compiler when set with export CC/CXX, so I have
> > to poke around what the problem is.
> > 
> > I will report back once I have a result.
> 
> Adrian, could you please re-check this issue with latest version of
> https://github.com/olegendo/gcc/tree/devel/sh-lra ?

I just gave it a quick try and I can no longer reproduce the issue. qtwebkit
builds fine with a LRA-enabled gcc-15 using Kaz' sh-lra-take3 branch.

[Bug c++/56556] Wshadow warns for private members in base classes

[ossman at cendio dot se via Gcc-bugs]

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

Pierre Ossman  changed:

   What|Removed |Added

 CC||ossman at cendio dot se

--- Comment #5 from Pierre Ossman  ---
We're also getting bit by this when porting TigerVNC to Qt. -Wshadow avoids
bugs, so it would be very nice to not end up having to disable it.

[Bug c++/78147] The -Wshadow warning is too aggressive with constructor parameters

[ossman at cendio dot se via Gcc-bugs]

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

Pierre Ossman  changed:

   What|Removed |Added

 CC||ossman at cendio dot se

--- Comment #9 from Pierre Ossman  ---
I'd like to add a dissenting voice. I think the current behaviour is useful.

In your simple example, yes, it provides no value. But in a more complex
constructor with a body, then it's important to access the *member* foo, not
the *argument* foo. Otherwise, you might modify the wrong thing.

[Bug sanitizer/116863] TSAN segfault in __sanitizer::CombinedAllocator::Allocate

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

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

--- Comment #1 from Andrew Pinski  ---
Can you report this upstream to LLVM (libsanitizer upstream is LLVM) since I
suspect you will hit it with tsan with LLVM too?

[Bug c++/116852] -fvisibility-inlines-hidden does not hide template functions without 'inline'

[joerg.richter--- via Gcc-bugs]

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

--- Comment #4 from Jörg Richter  ---
> I don't think there's a way besides wrapping those inside #pragma GCC
> visibility, using attributes and/or -fvisibility

I had hoped the point of -fvisibility-inlines-hidden is to not have to do this 
in such detail.
Also a lot of libstdc++ or boost has template functions not marked as inline.
Its hard for a user to wrap this code with different visibility.

I think the C++ semantics for this function is totally identical with and 
without 'inline'.

Perhaps the "inline" in "-fvisibility-inlines-hidden" is different from the
pure
C++ definition of it and can be extended to also include this case?

[Bug target/116856] Generated Code with unaligned uint32_t potentially hardfaults on ARM (due to LDRD)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Robert Hölzl from comment #9)
> I know that this solves the problem (as I wrote in my last comment).
> 
> But why does GCC handle an inline typecast (uint32_t __attribute__
> ((__aligned__(1)))*) different from a typecast to an typedef (u32_u*) when
> the typedef is identical to the inline typecast?
> 
> In other words:
> 
> typedef uint32_t __attribute__((aligned(1))) u32_u;
> uint32_t x = *(u32_u *) y;
> 
> should be identical to
> 
> uint32_t x = *(uint32_t __attribute__ ((__aligned__(1)) *) y;
> 
> right?
> 
> But the latter one is generating wrong code (which contains LDRD)

The aligned in `uint32_t __attribute__ ((__aligned__(1)) *` gets attached to
the pointer type rather than what it is being pointed to.

[Bug libstdc++/116847] [15 regression] r15-3859-g63a598deb0c9fc causes many excess errors

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #18 from Jakub Jelinek  ---
Should be fixed now.

[Bug middle-end/116860] [15 Regression] New test case gcc.dg/tree-ssa/fold-xor-and-or.c from r15-3866-ga88d6c6d777ad7 fails

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Obviously optimizations like that shouldn't be done in match.pd but in
tree-ssa-reassoc.cc (optimize_range_tests) which has the infrastructure to do
such optimization not just when the 2 conditions appear in BIT_IOR_EXPR, but
also their negations in BIT_AND_EXPR and also when it appears in different
basic blocks linked through GIMPLE_CONDs and combination thereof, or at least
should be done in both places.

[Bug middle-end/116860] [15 Regression] New test case gcc.dg/tree-ssa/fold-xor-and-or.c from r15-3866-ga88d6c6d777ad7 fails

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

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

--- Comment #3 from Jakub Jelinek  ---
Even on targets like riscv, if one tries
int cmp1(int d1, int d2, int d3) {
  if (((d1 ^ d2) & 0xabcd) == 0 || d3 != 42 || d1 != d2)
return 0;
  return 1;
}
(i.e. inserts in between completely unrelated comparison (or many of them)), I
strongly doubt you can optimize that.

[Bug target/116854] GCC incorrectly assumes all CPUs where -march=native resolves to -march=bdver4 will have RDRND support

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

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

--- Comment #14 from Jonathan Wakely  ---
FWIW, libstdc++ checks for RDRND support at runtime using __get_cpuid_max, even
when it was detected when compiling.

[Bug libstdc++/116853] [15 regression] Bootstrap fails on Darwin, Solaris after r15-3859-g63a598deb0c9

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

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #5 from Rainer Orth  ---
Solaris bootstrap is restored, too.

[Bug target/116856] Generated Code with unaligned uint32_t potentially hardfaults on ARM (due to LDRD)

[robert.hoelzl at posteo dot de via Gcc-bugs]

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

Robert Hölzl  changed:

   What|Removed |Added

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

--- Comment #11 from Robert Hölzl  ---
ARE YOU SURE??

Ok given you are right, then how can I attach the alignment attribute to the
uint32_t instead of the pointer?

I tested 

 uint32_t x = *(uint32_t * __attribute__ ((__aligned__(1))) ) y;

as well as

 uint32_t x = *(__attribute__ ((__aligned__(1))) uint32_t *) y;

but neither of them did generate the expected code (without LDRD)...

[Bug target/116854] GCC incorrectly assumes all CPUs where -march=native resolves to -march=bdver4 will have RDRND support

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #17 from Thiago Macieira  ---
(In reply to comment #8)
> I have to disagree. I specifically stated in the Qt bug that affected users
> were using -march=native and that was being resolved to -march=bdver4, so
> everything is not fine when using -march=native. You are correct that with
> -march=native on an affected CPU, __RDRND__ is not defined, but that's what
> I used to build Qt libraries that segfaulted. I only got working libraries
> by supplying -march=x86-64-v2 or omitting -march entirely.

Sorry, that's a misunderstanding of the problem. __RDRND__ was *not* defined
for -march=native. The problem was that Qt's definition of the __haswell__
macro (which Qt #defines as a stand-in for __x86_64_v3__) and the
CpuArchHaswell bit flag were mismatched on the presence of __RDRND__. The
design was that if __haswell__ was defined, qCpuHasFeature(Haswell) would be a
constant true, but the mismatch caused the macro to be defined and yet the
qCpuHasFeature() call to return false.

If those users had built with -march=bdver4, Qt would not have crashed in the
painting engine.

But as a consequence, I thought the random number generator would have (though
see comment #16 why it wouldn't). That's *this* bug report.

(In reply to Jonathan Wakely from comment #12)
> The bug report is frustratingly unclear.

Sorry. Hopefully the above clarifies a bit. Instead of reporting it myself, I
asked the OP in the Qt bug report to do so, because he'd have "skin in the
game" for owning an affected AMD processor. But it looks like my explanation
requesting it be done wasn't clear. I apologise.

> So should this bug report be a request to change the meaning of bdver4?
> Because it's behaving as documented currently.
> 
> Can we fix the summary to be more accurate?
> 
> Would "-march=bdver4 should not enable RDRND" be better?

Yes, please.

[Bug target/116854] GCC incorrectly assumes all CPUs where -march=native resolves to -march=bdver4 will have RDRND support

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #18 from Thiago Macieira  ---
(In reply to Uroš Bizjak from comment #16)
> --quote--
> Note, that clearing the RDRAND CPUID bit does not prevent a processor
> that normally supports the RDRAND instruction from executing it. So any
> code that determined the support based on family and model won't #UD.
> --/quote--

FYI, Qt has some code to test the quality of the RNG at runtime because of this
very issue.

QT_FUNCTION_TARGET(BASELINE_RDRND) Q_DECL_COLD_FUNCTION
static bool checkRdrndWorks() noexcept
{
/*
 * Some AMD CPUs (e.g. AMD A4-6250J and AMD Ryzen 3000-series) have a
 * failing random generation instruction, which always returns
 * 0x, even when generation was "successful".
 *
 * This code checks if hardware random generator generates four consecutive
 * equal numbers. If it does, then we probably have a failing one and
 * should disable it completely.
 *
 * https://bugreports.qt.io/browse/QTBUG-69423
 */

However, this check is bypassed if __RDRND__ was defined by the compiler.

[Bug target/116856] Generated Code with unaligned uint32_t potentially hardfaults on ARM (due to LDRD)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #12 from Andrew Pinski  ---
(In reply to Robert Hölzl from comment #11)
> ARE YOU SURE??
> 
> Ok given you are right, then how can I attach the alignment attribute to the
> uint32_t instead of the pointer?
> 
> I tested 
> 
>  uint32_t x = *(uint32_t * __attribute__ ((__aligned__(1))) ) y;
> 
> as well as
> 
>  uint32_t x = *(__attribute__ ((__aligned__(1))) uint32_t *) y;
> 
> but neither of them did generate the expected code (without LDRD)...

You need to use a seperate typedef for the unaligned uint32_t.
typedef uint32_t __attribute__((aligned(1))) u32_u;

[Bug tree-optimization/116842] [15 Regression] ICE definition in block follows the use

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2024-09-27
 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1
   Priority|P3  |P1

--- Comment #3 from Jakub Jelinek  ---
Started with r15-3734-g4eba48a684b1a1f77aa18b29a1ae58dbdc842b5b

[Bug c/116871] New: -Wincompatible-pointer-types for function pointers could highlight the mismatch better

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

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

Bug ID: 116871
   Summary: -Wincompatible-pointer-types for function pointers
could highlight the mismatch better
   Product: gcc
   Version: 13.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

See https://godbolt.org/z/zavE7ePf9.

For the following:
```
void f(int a);

int main() {
void (*g) (float b) = &f;
}
```

With Clang, we get:
```
:4:12: error: incompatible function pointer types initializing 'void
(*)(float)' with an expression of type 'void (*)(int)'
[-Wincompatible-function-pointer-types]
4 | void (*g) (float b) = &f;
  |^  ~~
1 error generated.
Compiler returned: 1
```

But with GCC, we get:
```
: In function 'main':
:4:27: error: initialization of 'void (*)(float)' from incompatible
pointer type 'void (*)(int)' [-Wincompatible-pointer-types]
4 | void (*g) (float b) = &f;
  |   ^
Compiler returned: 1
```

i.e. clang underlines the LHS as well as the RHS. It's trivial but w/e.

[Bug c/116871] -Wincompatible-pointer-types for function pointers could highlight the mismatch better

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

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

--- Comment #2 from Sam James  ---
This matters more when you have quite long typedefs and the difference is just
a const on one parameter.

[Bug c/116871] -Wincompatible-pointer-types for function pointers could highlight the mismatch better

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

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

--- Comment #1 from Sam James  ---
tbh, I actually think we could do a bit better again and somehow annotate &f in
the diagram and colourise the 'float' vs 'int'?

[Bug target/69374] install.texi is bit-rotten

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

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

--- Comment #23 from GCC Commits  ---
The trunk branch has been updated by Gerald Pfeifer :

https://gcc.gnu.org/g:2531f014fb2364777fb1ce09641db85bda5883b7

commit r15-3941-g2531f014fb2364777fb1ce09641db85bda5883b7
Author: Gerald Pfeifer 
Date:   Sat Sep 28 09:20:31 2024 +0800

doc: Remove i?86-*-linux* installation note from 2003

gcc:
PR target/69374
* doc/install.texi (Specific) : Remove note
from 2003.

[Bug c/116871] -Wincompatible-pointer-types for function pointers could highlight the mismatch better

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

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

Sam James  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||diagnostic

[Bug tree-optimization/116835] [12/13/14/15 Regression] phiprop will prop back into a loop

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> Phiprop use commit on the edge, maybe that  could be improved/changed.

That won't work because the edges which are in use here are the edges of the
PHI.

Still looking into figuring out the best way of fixing this. Rejecting back
edges out right is not good either. I am thinking about changing around the
code to go through all of the usess and find the ones where we only have
conditional edges (or the bb of the use is the same as the phi) and insert
there otherwise put them into a worklist and go through the worklist at the end
and see if we could reuse a phi that was inserted.

[Bug tree-optimization/116873] New: esra does not remove unused store sometimes

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

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

Bug ID: 116873
   Summary: esra does not remove unused store sometimes
   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: ---

Take:
```
struct Foo {
  int t;
  int x;
};


int f(struct Foo a, struct Foo b, int c)
{
  struct Foo d;
  struct Foo e;
  struct Foo *l;
  if (c) l = &a; else l = &b;
  d = *l;
  e = *l;
  return d.t + e.x;
}
```

After esra we get:
```
  # l_3 = PHI <&a(2), &b(3)>
  d = MEM[(const struct Foo &)l_3];
  d$t_6 = MEM[(const struct Foo &)l_3].t;
  e = MEM[(const struct Foo &)l_3];
  e$x_5 = MEM[(const struct Foo &)l_3].x;
  _1 = d$t_6;
  _2 = e$x_5;
  _10 = _1 + _2;
  d ={v} {CLOBBER(eos)};
  e ={v} {CLOBBER(eos)};
  return _10;
```

BUT the store to d and e are dea. If we full scalarize d and e, the stores are
removed (that is use d.x and e.t).

Shouldn't we just mark d and e to be removed too?

Yes DSE does remove them later on but I don't see why SRA could not handle them
if fields are unused.

[Bug tree-optimization/116874] phiprop should handle more than just `a->t`

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/116874] New: phiprop should handle more than just `a->t`

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

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

Bug ID: 116874
   Summary: phiprop should handle more than just `a->t`
   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: ---

Take:
```
struct Foo {
  int t;
  int x;
};


int f(struct Foo a, struct Foo b, int c)
{
  struct Foo d;
  struct Foo *l;
  if (c) l = &a; else l = &b;
  d = *l;
  return d.t + d.x;
}
```

Right now phiprop only handles `MEM[x]` but it should handle more, e.g.:
```
  # l_3 = PHI <&a(2), &b(3)>
  d$t_6 = MEM[(const struct Foo &)l_3].t;
  d$x_5 = MEM[(const struct Foo &)l_3].x;
```

I don't know how often this should up though.

[Bug c++/116803] Linkage fails if modules are compiled in a certain order

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

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

Nathaniel Shead  changed:

   What|Removed |Added

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

--- Comment #3 from Nathaniel Shead  ---
Fixed for GCC 15, thanks for the report.

[Bug c++/116160] [DR36] Rejects repeated using-declaration `using A::x;` [namespace.udecl]

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

https://gcc.gnu.org/g:2196a20b82bdde2aeb099bcfd164fa29a698e837

commit r15-3939-g2196a20b82bdde2aeb099bcfd164fa29a698e837
Author: Nathaniel Shead 
Date:   Fri Sep 20 00:47:12 2024 +1000

c++: Implement resolution for DR 36 [PR116160]

This implements part of P1787 to no longer complain about redeclaring an
entity via using-decl other than in a class scope.

PR c++/116160

gcc/cp/ChangeLog:

* name-lookup.cc (supplement_binding): Allow redeclaration via
USING_DECL if not in class scope.
(do_nonmember_using_decl): Remove function-scope exemption.
(push_using_decl_bindings): Remove outdated comment.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/using-enum-3.C: No longer expect an error.
* g++.dg/lookup/using53.C: Remove XFAIL.
* g++.dg/cpp2a/using-enum-11.C: New test.

Signed-off-by: Nathaniel Shead 
Reviewed-by: Jason Merrill 

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 116803 Summary: Linkage fails if modules are compiled in a certain order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116803

   What|Removed |Added

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

[Bug middle-end/116868] GCC trunk doesn't eliminate a superfluous new/delete pair

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

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

--- Comment #2 from Jonathan Wakely  ---
Yes, they're all the same bug, and depend on Bug 110137

[Bug c++/116748] [15 Regression] internal compiler error: in pop_local_binding, at cp/name-lookup.cc:2651

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

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

Nathaniel Shead  changed:

   What|Removed |Added

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

--- Comment #8 from Nathaniel Shead  ---
Fixed.

[Bug c++/94404] [meta-bug] C++ core issues

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

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

Bug 116160 Summary: [DR36] Rejects repeated using-declaration `using A::x;` 
[namespace.udecl]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116160

   What|Removed |Added

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