[Bug target/107757] PPCLE: Inefficient vector constant creation

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

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

--- Comment #2 from Jiu Fu Guo  ---
For the scenario of this PR, the 2insn sequence would be faster than
non-prefixed loading.

One finding may be useful: when building 64bit constants, I notice that loading
may be faster sometimes if the constant needs more instruction to build from
scratch.
For example, the one prefix loading(e.g. pld) could be faster than 2insn
sequence.

[Bug tree-optimization/109334] tree-object-size: Improve size computation in arguments

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||uecker at gcc dot gnu.org
 Status|RESOLVED|NEW
 Resolution|FIXED   |---

--- Comment #8 from uecker at gcc dot gnu.org ---
Reopen, that still does not work for many relevant cases, including the first
example in #1

[Bug analyzer/116173] [15 regression] analyzer/call-summary.cc:727:28: warning: unused variable ‘summary_cast_reg’ [-Wunused-variable] since r15-1108-g70f26314b62e2d

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build, internal-improvement
   Target Milestone|--- |15.0

[Bug target/116174] [14/15 regression] Alignment request is added before endbr with -fcf-protection=branch

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Keywords||needs-bisection, wrong-code
 CC||hjl.tools at gmail dot com
   Target Milestone|--- |14.3
 Target||x86_64-*-*
  Known to fail||15.0

--- Comment #1 from Richard Biener  ---
Confirmed with just -fcf-protection=branch -O2

.p2align 4
.globl  stpcpy
.type   stpcpy, @function
stpcpy:
.LFB0:
.cfi_startproc
.p2align 5
endbr64

[Bug other/116182] bootstrap-lto should set a small list of -Werror options for LTO correctness (-Werror=lto-type-mismatch,odr,strict-aliasing)

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2024-08-02
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
I don't think -Wstrict-aliasing fires after frontends finish so it's not
special with LTO.  I do agree with -Wodr and -Wlto-type-mismatch though.

[Bug bootstrap/116188] Drop building libcody for stage1 for bootstraps

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

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

--- Comment #2 from Richard Biener  ---
You can try to remove bootstrap=true from

// As with libiconv, don't install any of libcody
host_modules= { module= libcody; bootstrap=true;
no_install= true; 
missing= pdf;

but then

dependencies = { module=all-gcc; on=all-libcody; hard=true; };

for whatever reason.

[Bug ipa/116191] Avoid inlining in unlikely branches

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c   |ipa
   Last reconfirmed||2024-08-02
   Keywords||missed-optimization
 Ever confirmed|0   |1
 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Confirmed:

t.c:26:5: optimized:  Inlined zend_string_release/31 into normal/23 which now
has time 11.00 and size 18, net change of +13.
t.c:35:9: optimized:  Inlined zend_string_release/32 into unlikely_branch/25
which now has time 29.009000 and size 27, net change of +13.
t.c:42:9: optimized:  Inlined zend_string_release/33 into
unlikely_branch_in_hot_function/26 which now has time 29.009000 and size 27,
net change of +13.

Considering zend_string_release/22 with 19 size
 to be inlined into unlikely_branch/25 in t.c:35
 Estimated badness is -0.00, frequency 0.00.
Badness calculation for unlikely_branch/25 -> zend_string_release/22
  size growth 13, time 9.00 unspec 12.00
  -0.00: guessed profile. frequency 0.001000, count -1 caller count -1
time saved 0.014000 overall growth 39 (current) 52 (original) 2704
(compensated)
  Adjusted by hints -0.00
...
Processing frequency zend_string_release/32
  Called by unlikely_branch/25 that is normal or hot
Accounting size:-2.00, time:-0.01 on predicate exec:(op1,((long
int) #) != 0) 
Accounting size:2.00, time:0.00 on new predicate exec:(op0[ref
offset: 32],(# & 2) != 0) && (op0[ref offset: 0],(# + -1) == 0) && (op0[ref
offset: 32],(# & 1) == 0) && (op1,((long int) #) != 0)
Accounting size:2.00, time:0.00 on new predicate exec:(op0[ref
offset: 32],(# & 2) == 0) && (op0[ref offset: 0],(# + -1) == 0) && (op0[ref
offset: 32],(# & 1) == 0) && (op1,((long int) #) != 0)
t.c:35:9: optimized:  Inlined zend_string_release/32 into unlikely_branch/25
which now has time 29.009000 and size 27, net change of +13.

I'm not sure how our IPA logic goes when optimizing unlikely calls in
normal/hot functions.  The calculations at least do not look much different
compared to inlining into normal().

Note that GCC generally tries to exhaust its inlining budget, but the cold
call should at least make inlining it low priority.

[Bug target/116043] [15 regression] TLS relocation issue when building glibc with -O3 -mavx512bf16 by r15-1619

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

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

--- Comment #17 from GCC Commits  ---
The releases/gcc-14 branch has been updated by hongtao Liu
:

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

commit r14-10551-ga295076bee293aa3112c615f9af7a27231816a36
Author: liuhongt 
Date:   Wed Jul 24 11:29:23 2024 +0800

Refine constraint "Bk" to define_special_memory_constraint.

For below pattern, RA may still allocate r162 as v/k register, try to
reload for address with leaq __libc_tsd_CTYPE_B@gottpoff(%rip), %rsi
which result a linker error.

(set (reg:DI 162)
 (mem/u/c:DI
   (const:DI (unspec:DI
 [(symbol_ref:DI ("a") [flags 0x60]  )]
 UNSPEC_GOTNTPOFF))

Quote from H.J for why linker issue an error.
>What do these do:
>
>leaq__libc_tsd_CTYPE_B@gottpoff(%rip), %rax
>vmovq   (%rax), %xmm0
>
>From x86-64 TLS psABI:
>
>The assembler generates for the x@gottpoff(%rip) expressions a R X86
>64 GOTTPOFF relocation for the symbol x which requests the linker to
>generate a GOT entry with a R X86 64 TPOFF64 relocation. The offset of
>the GOT entry relative to the end of the instruction is then used in
>the instruction. The R X86 64 TPOFF64 relocation is pro- cessed at
>program startup time by the dynamic linker by looking up the symbol x
>in the modules loaded at that point. The offset is written in the GOT
>entry and later loaded by the addq instruction.
>
>The above code sequence looks wrong to me.

gcc/ChangeLog:

PR target/116043
* config/i386/constraints.md (Bk): Refine to
define_special_memory_constraint.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr116043.c: New test.

(cherry picked from commit bc1fda00d5f20e2f3e77a50b2822562b6e0040b2)

[Bug tree-optimization/116142] vec_widen_smult_{odd,even}_M ineffective for a simple widening dot product (vect_used_by_reduction is not set?)

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #10 from rguenther at suse dot de  ---
On Thu, 1 Aug 2024, xry111 at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116142
> 
> --- Comment #9 from Xi Ruoyao  ---
> In the following call stack:
> 
> #0  single_imm_use (var=0x7564a3a8, use_p=0x7fffc9d8, 
> stmt=0x7fffc9e0) at ../../gcc/gcc/ssa-iterators.h:427
> #1  0x01aabcde in vec_info::lookup_single_use (this=0x33a1b80, 
> lhs=0x7564a3a8) at ../../gcc/gcc/tree-vectorizer.cc:581
> #2  0x01a1a40a in supportable_widening_operation (vinfo=0x33a1b80, 
> code=..., stmt_info=0x3482b50, vectype_out=0x7595a1f8, 
> vectype_in=0x7595a000, code1=0x7fffcb90, code2=0x7fffcb94, 
> multi_step_cvt=0x7fffcba0, interm_types=0x7fffcc48)
> at ../../gcc/gcc/tree-vect-stmts.cc:14196
> #3  0x019f7c2d in vectorizable_conversion (vinfo=0x33a1b80, 
> stmt_info=0x3482b50, gsi=0x0, vec_stmt=0x0, slp_node=0x33b4cc8, 
> cost_vec=0x7fffd190) at ../../gcc/gcc/tree-vect-stmts.cc:5438
> #4  0x01a16ecc in vect_analyze_stmt (vinfo=0x33a1b80, 
> stmt_info=0x3482b50, need_to_vectorize=0x7fffcf73, node=0x33b4cc8, 
> node_instance=0x32fb6e0, cost_vec=0x7fffd190)
> at ../../gcc/gcc/tree-vect-stmts.cc:13291
> 
> "ptr == ptr->next" is satisfied (the comment says it means "there aren't any
> uses whatsoever" but I don't really understand it: I knows almost nothing 
> about
> tree vectorization) and single_imm_use directly returns false.

So likely 

  tree lhs = gimple_assign_lhs (stmt_info->stmt);
  stmt_vec_info use_stmt_info = loop_info->lookup_single_use 
(lhs);
  if (use_stmt_info

needs to be

  tree lhs = gimple_assign_lhs (vect_orig_stmt (stmt_info)->stmt);
  stmt_vec_info use_stmt_info = loop_info->lookup_single_use 
(lhs);

[Bug rust/116192] New: [15 regression] 32-bit rust build fails

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

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

Bug ID: 116192
   Summary: [15 regression] 32-bit rust build fails
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rust
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org
  Target Milestone: ---
Target: i386-pc-solaris2.11, sparc-sun-solaris2.11,
i686-pc-linux-gnu

The recent gigantic rust import broke the 32-bit rust build everywhere:

* There are several instances where size_t args are printed using %ld, e.g.

In file included from /vol/gcc/src/hg/master/local/gcc/rust/ast/rust-ast.h:27,
 from
/vol/gcc/src/hg/master/local/gcc/rust/hir/tree/rust-hir.h:22,
 from
/vol/gcc/src/hg/master/local/gcc/rust/checks/errors/borrowck/rust-borrow-checker.h:22,
 from
/vol/gcc/src/hg/master/local/gcc/rust/checks/errors/borrowck/rust-borrow-checker.cc:19:
/vol/gcc/src/hg/master/local/gcc/rust/checks/errors/borrowck/rust-bir-builder.h:
In member function ‘void
Rust::BIR::Builder::handle_lifetime_param_constraints(const
Rust::TyTy::RegionConstraints&)’:
/vol/gcc/src/hg/master/local/gcc/rust/checks/errors/borrowck/rust-bir-builder.h:94:21:
error: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has
type ‘unsigned int’ [-Werror=format=]
   94 | rust_debug ("\t\t %ld: %ld", last_bound.first,
last_bound.second);
  | ^~~  
  | |
  |  

  Given that %z cannot yet be assumed, those should be printed as %lu and
  the args cast to unsigned long.  This should be an unsigned format and type
  to match the signedness of size_t.

* There's an overload issue with PlaceId vs. FreeRegion:

In file included from
/vol/gcc/src/hg/master/local/gcc/rust/checks/errors/borrowck/rust-borrow-checker.cc:23:
/vol/gcc/src/hg/master/local/gcc/rust/checks/errors/borrowck/rust-bir-fact-collector.h:
At global scope:
/vol/gcc/src/hg/master/local/gcc/rust/checks/errors/borrowck/rust-bir-fact-collector.h:663:8:
error: ‘void Rust::BIR::FactCollector::push_subset(Rust::BIR::PlaceId,
Rust::BIR::PlaceId)’ cannot be overloaded with ‘void
Rust::BIR::FactCollector::push_subset(Rust::FreeRegion, Rust::FreeRegion)’
  663 |   void push_subset (PlaceId lhs, PlaceId rhs)
  |^~~
/vol/gcc/src/hg/master/local/gcc/rust/checks/errors/borrowck/rust-bir-fact-collector.h:622:8:
note: previous declaration ‘void
Rust::BIR::FactCollector::push_subset(Rust::FreeRegion, Rust::FreeRegion)’
  622 |   void push_subset (FreeRegion lhs, FreeRegion rhs)
  |^~~

  PlaceId is uint32_t while FreeRegion is size_t (also uint32_t).

The attached patch fixes the format issues, but I've no idea what to do about
the overload one.

Given that this isn't the first time that rust broke 32-bit targets, it would
be very helpful to try at least one 32-bit build before commit.

[Bug rust/116192] [15 regression] 32-bit rust build fails

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

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

--- Comment #1 from Rainer Orth  ---
Created attachment 58806
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58806&action=edit
partial patch

[Bug rust/116192] [15 regression] 32-bit rust build fails

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug target/113341] Using GCC as the bootstrap compiler breaks LLVM on 32-bit PowerPC

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

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

--- Comment #17 from John Paul Adrian Glaubitz  ---
(In reply to Sam James from comment #16)
> glaubitz, could you check with gcc-14.2 or trunk? I have a feeling honza's
> IPA fixes recently sort this.

No improvement here, unfortunately. clang still crashes during stage2.

See:
https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-17&arch=powerpc&ver=1%3A17.0.6-15&stamp=1722579969&raw=0

[Bug target/116174] [14/15 regression] Alignment request is added before endbr with -fcf-protection=branch

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

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2024-08-02
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from H.J. Lu  ---
(In reply to Richard Biener from comment #1)
> Confirmed with just -fcf-protection=branch -O2
> 
> .p2align 4
> .globl  stpcpy
> .type   stpcpy, @function
> stpcpy:
> .LFB0:
> .cfi_startproc
> .p2align 5

It is wrong to place .p2align after label.

> endbr64

[Bug rust/107700] Several testsuite failures on SPARC

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

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

Arthur Cohen  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||cohenarthur at gcc dot gnu.org

[Bug rust/116192] [15 regression] 32-bit rust build fails

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

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

Arthur Cohen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-08-02
 Ever confirmed|0   |1

[Bug rust/107700] Several testsuite failures on SPARC

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

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

Arthur Cohen  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug target/115683] [15 Regression] SSE2 regressions after obselete of vcond{,u,eq}.

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

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

--- Comment #2 from Richard Biener  ---
For gcc.target/i386/pr88540.c we expand the mask producer as

(insn 12 11 13 (set (reg:V2DF 109)
(lt:V2DF (reg:V2DF 101 [ vect__23.6 ])
(reg:V2DF 98 [ vect__25.9 ]))) -1
 (nil))

(insn 13 12 14 (set (reg:V2DI 108)
(subreg:V2DI (reg:V2DF 109) 0)) -1
 (nil))

(insn 14 13 15 (set (reg:V2DI 107 [ mask__26.10_21 ])
(reg:V2DI 108)) -1
 (nil))

I think that we go though a named expander for the vec_cmp means we cannot
use TER tricks like we do with the scalar expansion which produces the
min from the x86 expander directly.

combine sees

   12: r109:V2DF=r105:V2DF 17 and 16, 15 -> 17 but I think the four-insn combinations
do not include this "diamond" variant.  It has I0, I1 -> I2, I2 -> I3
but this would be I0 -> I1, I0 -> I2, (I1, I2) -> I3, not sure if it were
to do that at all if we pass the insns to try_combine.

I don't see a good way for combine helpers, the only option would have been
to keep the blend (15, 16, 17) in a single insn to be split only after
combine.  With SSE 4.1 this is what happens (UNSPEC_BLENDV).

And of course catching this min/max form with a new optab during ISEL
or to be emitted (and costed) by the vectorizer directly.  It would be
quite special, select_lt and select_gt maybe, eventually merged
select with a compare op like we have for vec_cmp to specify the comparison
code.  select (A code B) would then be A code B ? A : B.

[Bug target/114189] Target implements obsolete vcond{,u,eq} expanders

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

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

Richard Biener  changed:

   What|Removed |Added

 Target|x86_64-*-*, i?86-*-*,   |sparc, mips, loongarch,
   |sparc, mips, loongarch, |ia64, gcn, arm, aarch64,
   |ia64, gcn, arm, aarch64,|

--- Comment #13 from Richard Biener  ---
The i386 backend is also clear of vcond{,u,eq} patterns, there's some XFAILed
fallout when just SSE is available (PR115683).

[Bug target/114189] Target implements obsolete vcond{,u,eq} expanders

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

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

Richard Biener  changed:

   What|Removed |Added

Version|14.0|15.0
 CC||ams at gcc dot gnu.org,
   ||chenglulu at loongson dot cn,
   ||rearnsha at gcc dot gnu.org

--- Comment #14 from Richard Biener  ---
CCing maintainers for loongarch, arm/aarch64 and gcn.

[Bug c++/116178] wish: command line -std=c++newest

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

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

--- Comment #11 from Jonathan Wakely  ---
(In reply to Sam James from comment #8)
> Build systems like autoconf currently hardcode a list of C++ and C standards
> which has to be updated every so often (and often gets forgotten about).
> autoconf at least will aggressively pick the latest one it knows about.

We asked them to fix that, I haven't checked whether they did or not.

> Obviously, it should be tested to make sure it works, but having to manually
> do "what's the latest I know about vs. latest the compiler knows about"
> feels cheesy.
> 
> More so in C land, we also often see people doing things like "-std=gnu99"

In general, the "not stable yet" case is much less of a problem for C. The -std
option has a much smaller impact on ABI compat for C than for C++, because most
C ABIs are just a symbol name anyway. For the C++ std::lib every detail of
every class, inline function, and function template is an ABI artefact.

> because at one point, that was new, and they don't mind using something
> newer, but then they have to try balance with whatever the latest the
> compiler supports. Being able to say "OK, try -std=latest-stable-std" is
> useful there.

But in theory that should be the default, so you don't need it.

If you use C17 features and the default -std option is C11, then relying on the
default doesn't work, but neither does -std=latest-stable (because that should
be the same as the default).

So you really need "latest unstable" ... and then you're doing something which
possibly shouldn't be put into distro builds anyway (for C++, less so for C).

Better yet, Autoconf has a AC_PROG_CXX_STDCXX_EDITION_TRY which can be used to
say "I need C++17, add the relevant option if required but don't add it if the
default already meets that". So if the default is already C++17, or is even
newer, then it doesn't add any -std option. That way you don't get -std=c++17
still hardcoded in 10 years when it's no longer needed, because every compiler
defaults to something newer anyway.

The cmake equivalent is
target_compile_features(mylib PUBLIC cxx_std_11)
https://cmake.org/cmake/help/latest/manual/cmake-compile-features.7.html#requiring-language-standards
"clients must use a compiler mode that is no less than C++ 11"

> I think it's also likely to be useful in CI as people may not realise when
> their compiler starts to support a new standard (they may already know it
> exists and such but it's not yet in their Ubuntu image or whatever).

Yup, that makes sense. "Run tests using the latest -std mode to check for
incompatibilities, we don't care if it's stable or experimental because this is
CI not builds we plan to keep or distribute".

Calling it -std=c++-unstable-no-warranty-given-or-implied works fine for that
case, but -std=c++latest-stable doesn't help (because again, it should be the
default -std anyway).

[Bug c/116193] New: enhancement: type attribute that causes overflow for unsigned integer types to trap

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

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

Bug ID: 116193
   Summary: enhancement: type attribute that causes overflow for
unsigned integer types to trap
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: uecker at gcc dot gnu.org
  Target Milestone: ---

It would be nice to have an attribute that one can add to an unsigned integer
type that makes overflow trap.

typedef unsigned int __attribute__ ((__overflow__)) positive_int;

[Bug c/116193] enhancement: type attribute that causes overflow for unsigned integer types to trap

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/116178] wish: command line -std=c++newest

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

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

--- Comment #12 from Jonathan Wakely  ---
So autoconf and cmake both already have a way to only add a -std option
conditionally, but if you use that and it selects an unstable release like
-std=c++26 in GCC 14, then that's for you to deal with (if it matters ... which
depends on which symbols you use, and if you rebuild the world on compiler
upgrades anyway).

For the CI case, maybe we could make this output easier to parse so your CI
jobs can decide on a flag to use:

$ gcc  --help=c++ -Q | grep .-std
  -fhonor-std   [disabled]
  -std=c++03-std=c++98
  -std=c++0x-std=c++11
  -std=c++11[disabled]
  -std=c++14[disabled]
  -std=c++17[disabled]
  -std=c++1y-std=c++14
  -std=c++1z-std=c++17
  -std=c++20[disabled]
  -std=c++23[disabled]
  -std=c++2a-std=c++20
  -std=c++2b-std=c++23
  -std=c++98[disabled]
  -std=gnu++03  -std=gnu++98
  -std=gnu++0x  -std=gnu++11
  -std=gnu++11  [disabled]
  -std=gnu++14  [disabled]
  -std=gnu++17  [disabled]
  -std=gnu++1y  -std=gnu++14
  -std=gnu++1z  -std=gnu++17
  -std=gnu++20  [disabled]
  -std=gnu++23  [disabled]
  -std=gnu++2a  -std=gnu++20
  -std=gnu++2b  -std=gnu++23
  -std=gnu++98  [disabled]

If it's just something you use in CI it can't be hardcoded into the build
system anyway, so you need some way to override it like CXXFLAGS=-std=c++23

Or we could add -std=c++-move-fast-and-break-things so you don't need to do
that parsing.

[Bug c++/116178] wish: command line -std=c++newest

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

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

--- Comment #13 from Jakub Jelinek  ---
Finding the latest numeric -std=c++ version isn't that hard,
g++ --help -v 2>&1 | awk '{print $1}' | grep std=c[+][+][0-8][0-9] | sort -n |
tail -n 1
will do it.
And
g++ --help -v 2>&1 | awk '{print $1}' | grep std=c[+][+][0-8][0-9a-z] | sort -n
| tail -n 1
will give the latest non-numeric one (like -std=c++2c).

[Bug c/116194] New: enhancement: attribute to protect tagged unions

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

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

Bug ID: 116194
   Summary: enhancement: attribute to protect tagged unions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: uecker at gcc dot gnu.org
  Target Milestone: ---

An attribute that can be attached to tagged unions that traps when a non-active
field is accesses.

One option may be a generic attribute that specifies a condition that needs to
be fulfilled on access of a field.

struct {
  enum { A, B } tag;
  union {
int a [[guard(.tag == A)]];
float b [[guard(.tag == B]];
  };
};

[Bug c/116193] enhancement: type attribute that causes overflow for unsigned integer types to trap

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-08-02
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Huh? Is this thinking about being added to the C standard?
I suspect this will be abused just as clang's "unsigned overflow" ubsan has
been abused and incorrect bug reports to library developers has happened (e.g.
one to libstdc++ for some psedu-random code where it uses wrapping).

[Bug c/116193] enhancement: type attribute that causes overflow for unsigned integer types to trap

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

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

--- Comment #2 from Jakub Jelinek  ---
That opens the door of issues how you can actually subtract those things
validly.
Would x - y and x + (-y) then behave differently for it?

[Bug tree-optimization/116156] [14/15 regression] -fcompare-debug -gno-statement-frontiers failure with -O2 when building gdk-pixbuf

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

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

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

https://gcc.gnu.org/g:33baa20c5cdcf5ff8164606115f00aa30f559312

commit r15-2691-g33baa20c5cdcf5ff8164606115f00aa30f559312
Author: Andrew Pinski 
Date:   Thu Aug 1 10:33:34 2024 -0700

forwprop: Don't add uses to dce list if debug statement [PR116156]

The problem here is that when forwprop does a copy prop, into a statement,
we mark the uses of that statement as possibly need to be removed. But it
just
happened that statement was a debug statement, there will be a difference
when
compiling with debuging info turned on vs off; this is not expected.
So the fix is not to add the old use to dce list to process if it was a
debug
statement.

Bootstrapped and tested on x86_64-linux-gnu with no regressions.

PR tree-optimization/116156

gcc/ChangeLog:

* tree-ssa-forwprop.cc (pass_forwprop::execute): Don't add
uses if the statement was a debug statement.

gcc/testsuite/ChangeLog:

* c-c++-common/torture/pr116156-1.c: New test.

Signed-off-by: Andrew Pinski 

[Bug tree-optimization/116156] [14 regression] -fcompare-debug -gno-statement-frontiers failure with -O2 when building gdk-pixbuf

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||13.3.0, 15.0
  Known to fail||14.1.0, 14.2.0
Summary|[14/15 regression]  |[14 regression]
   |-fcompare-debug |-fcompare-debug
   |-gno-statement-frontiers|-gno-statement-frontiers
   |failure with -O2 when   |failure with -O2 when
   |building gdk-pixbuf |building gdk-pixbuf

--- Comment #9 from Andrew Pinski  ---
Fixed on the trunk, working on the backport.

[Bug libstdc++/113578] Incorrect sign printed for -nan on RISC-V

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

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

--- Comment #13 from Jonathan Wakely  ---
Oh I need to use constexpr not _GLIBCXX17_CONSTEXPR, because those branches
must not be taken unless the sizes match. Thanks for the CI checks!

[Bug target/116170] [15 regression] ICE unrecognizable insn since r15-2084-g33dca0a4c1c421

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

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

--- Comment #2 from Kewen Lin  ---
Reduced test case:

$ cat test.i
int a, d;
_Float128 b, c;
void e() {
  int f = 0;
  if (a)
if (b || c)
  f = 1;
  if (d)
e(f ? 0 : b);
}

Options: -w -fstack-protector-strong -ffloat-store -O2 -mcpu=power8

[Bug ipa/102061] Cloned function names get exposed in warning messages

[peter0x44 at disroot dot org via Gcc-bugs]

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

--- Comment #5 from Peter Damianov  ---
I finally got some time to look at the test failures this patch causes.

https://gcc.gnu.org/cgit/gcc/tree/gcc/testsuite/gcc.dg/independent-cloneids-1.c
Perhaps decl_printable_name is also used when writing names out in RTL dumps.
I will take a look later and verify if this is the case. I assume it's desired
to have cloned functions mentioned there, but I'm not sure.

[Bug target/116170] [15 regression] ICE unrecognizable insn since r15-2084-g33dca0a4c1c421

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

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

Kewen Lin  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #3 from Kewen Lin  ---
The culprit commit offers more chances on float constant copying, but it leads
LRA to generate one insn which is an unrecognizable insn:

(insn 181 0 0 (set (const_vector:V1TI [
(const_int 0 [0])
])
(reg:V1TI 179)) -1
 (nil))

Initially at function curr_insn_transform curr_insn is

(insn 106 102 160 12 (set (mem:V1TI (and:DI (plus:DI (plus:DI (reg/f:DI 110
sfp)
(reg:DI 162))
(const_int 144 [0x90]))
(const_int -16 [0xfff0])) [2  S16 A128])
(subreg:V1TI (reg:KF 133) 0)) "test.i":9:5 discrim 2 1178
{*vsx_le_perm_store_v1ti}
 (expr_list:REG_DEAD (reg:DI 162)
(expr_list:REG_DEAD (reg:KF 133)
(nil

with equiv substition, it becomes to

(insn 106 102 160 12 (set (mem:V1TI (and:DI (plus:DI (plus:DI (reg/f:DI 110
sfp)
(reg:DI 162))
(const_int 144 [0x90]))
(const_int -16 [0xfff0])) [2  S16 A128])
(const_vector:V1TI [
(const_int 0 [0])
])) "test.i":9:5 discrim 2 1178 {*vsx_le_perm_store_v1ti}
 (expr_list:REG_DEAD (reg:DI 162)
(expr_list:REG_DEAD (reg:KF 133)
(nil

the corresponding pattern is:

(define_insn "*vsx_le_perm_store_"
  [(set (match_operand:VSX_LE_128 0 "memory_operand" "=Z,Q")
(match_operand:VSX_LE_128 1 "vsx_register_operand" "+wa,r"))]
  "!BYTES_BIG_ENDIAN && TARGET_VSX && !TARGET_P9_VECTOR
   && !altivec_indexed_or_indirect_operand (operands[0], mode)"
  "@
   #
   #"
  [(set_attr "type" "vecstore,store")
   (set_attr "length" "12,8")
   (set_attr "isa" ",*")])

, alt 0 is selected, LRA fixes it up with:

Creating newreg=179, assigning class VSX_REGS to r179

(insn 180 179 0 (set (reg:V1TI 179)
(const_vector:V1TI [
(const_int 0 [0])
])) 1193 {vsx_movv1ti_64bit}
 (nil))

which is sensible, but the unexpected thing is that is also generates 

(insn 181 0 0 (set (const_vector:V1TI [
(const_int 0 [0])
])
(reg:V1TI 179)) -1
 (nil))

...
via the code:

  *loc = new_reg;
  if (type != OP_IN
  && find_reg_note (curr_insn, REG_UNUSED, old) == NULL_RTX)
{
  start_sequence ();
  lra_emit_move (type == OP_INOUT ? copy_rtx (old) : old, new_reg);
  emit_insn (after);
  after = get_insns ();
  end_sequence ();
  *loc = new_reg;
}
...

the reason here is the type isn't OP_IN so it wants to assign back to the OUT
OP, but the old here is a const_vector which is replaced with equiv, I think we
should stop move emission for this case.

The below patch makes it pass:

diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc
index 92b343fa99a..024c85c87d9 100644
--- a/gcc/lra-constraints.cc
+++ b/gcc/lra-constraints.cc
@@ -4742,7 +4742,8 @@ curr_insn_transform (bool check_only_p)
 }
   *loc = new_reg;
   if (type != OP_IN
-  && find_reg_note (curr_insn, REG_UNUSED, old) == NULL_RTX)
+  && find_reg_note (curr_insn, REG_UNUSED, old) == NULL_RTX
+  && nonimmediate_operand (old, GET_MODE (old)))
 {
   start_sequence ();
   lra_emit_move (type == OP_INOUT ? copy_rtx (old) : old,
new_reg);

[Bug libstdc++/113578] Incorrect sign printed for -nan on RISC-V

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

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

--- Comment #14 from Jonathan Wakely  ---
New patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659254.html

[Bug rtl-optimization/116179] [15 regression] -fcompare-debug -gno-statement-frontiers failure with -O3 when building mesa-24.1.4 since r15-1735-ge62ea4fb8ffcab (late combine)

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

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

--- Comment #10 from Andrew Pinski  ---
Hmm:
```
  for (df_ref use = DF_REG_USE_CHAIN (REGNO(dest));
   use;
   use = DF_REF_NEXT_REG (use))
{
  int ubbi = DF_REF_BB (use)->index;
  if (bitmap_bit_p (reachable, ubbi))
bitmap_set_bit (need_new, ubbi);
}

```

I think this should check if the use was not a debug insn.
that is `!DEBUG_INSN_P (DF_REF_INSN (use))` .

Let me check that tomorrow.


What late_combine1 is doing is ok, I think just exposing the latent bug in this
code.

[Bug c/116193] enhancement: type attribute that causes overflow for unsigned integer types to trap

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

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

--- Comment #3 from uecker at gcc dot gnu.org ---

It came up  as a possibility in various discussions, including on the kernel
mailing list or inside WG14.   I personally use signed type if I want to detect
overflow and unsigned only if I want modulo behavior, and I am relatively happy
with this.  But others like to  (or have code that does) use unsigned types
also for positive numbers such as sizes or indices where wraparound often leads
to bugs.

I don't see the risk of misuse as much as with the sanitizer, as it would be
opt-in for specific types, so can be introduced on where it is clear that
wraparound is not intended.

I would say x - y would be different than x + (-y) and the later should trap.
Although I guess (-y) could already be diagnosed in the FE, so for middle end
this would not matter.

[Bug rust/116192] [15 regression] 32-bit rust build fails

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

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

--- Comment #2 from Arthur Cohen  ---
Hi Rainer,

Thank you for the report. We've fixed this in our development repository and
will upstream the commits soon. I am looking at adding a 32-bit CI build so
that this does not happen again.

Best,

Arthur

[Bug c/116193] enhancement: type attribute that causes overflow for unsigned integer types to trap

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

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

--- Comment #4 from Richard Biener  ---
-y is OK when y == 0

I hope you are not suggesting that it's UB to overflow though.  The attribute
should make the frontend to lower operations according to semantics and leave
everything in the middle-end unaffected.

[Bug c++/43745] [avr] g++ puts VTABLES in SRAM

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Last reconfirmed|2012-01-07 00:00:00 |2024-8-2
 Status|RESOLVED|NEW
 Resolution|WONTFIX |---
Version|4.7.0   |15.0

[Bug middle-end/111821] [12/13/14/15 Regression] OOM with packed struct and stack variable with copy

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
So the issue is that we expand 'v' as a register despite of the large
out-of-bound access.  With -O0 we expand it to (stack) memory and use memcpy as
fallback.

I have a patch.

[Bug middle-end/12454] large number of if (); else if in g++.dg/parse/stack1.C cause stack exhaustion

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords|compile-time-hog|
Summary|large number of if ();else  |large number of if (); else
   |if cause|if in g++.dg/parse/stack1.C
   ||cause stack exhaustion

--- Comment #11 from Richard Biener  ---
g++.dg/parse/stack1.C is now optimized quickly by the FE and we enter
gimplification with

;; Function void foo() (null)
;; enabled by -tree-original


(void) 0;

adjusting the testcase to the following reproduces the recursion issue in
gimplify_cond_expr though the problem is hardly that but the generic design
of the gimplifier.

#define ONE else if (i) { }
#define TEN ONE ONE ONE ONE ONE ONE ONE ONE ONE ONE
#define HUN TEN TEN TEN TEN TEN TEN TEN TEN TEN TEN
#define THOUHUN HUN HUN HUN HUN HUN HUN HUN HUN HUN

void foo(int i)
{
  if (i) { }
  /* 11,000 else if's.  */
  THOU THOU THOU THOU THOU THOU THOU THOU THOU THOU THOU
}

[Bug other/30920] Incorrect splaying that fails to assure the caching property

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
typed_splay_tree is only used by edit-context.{h,cc} and jit/libgccjit.cc

splay-tree-utils is more recent and might be used to implement typed_splay_tree
which IIRC was simply a C++ version of the libiberty code.  The libiberty
splay_tree is still used quite a lot.

[Bug libstdc++/116140] [15 Regression] 5-35% slowdown of 483.xalancbmk and 523.xalancbmk_r since r15-2356-ge69456ff9a54ba

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

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

--- Comment #6 from Alex Coplan  ---
Just to give an update on this, the following testcase shows why adding:

#pragma GCC unroll 4

in libstdc++ doesn't immediately seem to help.  The testcase is:

$ cat lambda.cc
template
inline Iter
my_find(Iter first, Iter last, Pred pred)
{
#pragma GCC unroll 4
while (first != last && !pred(*first))
++first;
return first;
}

short *use_find(short *p)
{
auto pred = [](short x) { return x == 42; };
return my_find(p, p + 1024, pred);
}

compiling, we get:

$ /xgcc -B . -c lambda.cc -S -o /dev/null
lambda.cc: In function ‘Iter my_find(Iter, Iter, Pred) [with Iter = short int*;
Pred = use_find(short int*)::]’:
lambda.cc:6:5: warning: ignoring loop annotation
6 | while (first != last && !pred(*first))
  | ^

so the #pragma is indeed getting dropped.  This warning comes from
tree-cfg.cc:replace_loop_annotate.  The exiting basic block here is:

 :
D.4524 = .ANNOTATE (iftmp.1, 1, 4);
retval.0 = D.4524;
if (retval.0 != 0)
  goto ; [INV]
else
  goto ; [INV]

and the code in replace_loop_annotate_in_block (which looks for the .ANNOTATE
ifn call) iterates backwards over the gimple in that block, skipping over the
gcond, but it then expects to find any .ANNOTATE calls immediately before the
gcond.
In this case it doesn't, so we end up dropping the .ANNOTATE call on the floor
and emitting the warning (and not unrolling).

Consider the simpler testcase without the lambda:

template
inline Iter
find_nolambda(Iter first, Iter last)
{
#pragma GCC unroll 4
while (first != last && *first != 42)
++first;
return first;
}

short *use_nolambda(short *p)
{
return find_nolambda (p, p + 1024);
}

for this testcase, we don't get the warning, and indeed the exiting block for
this loop is just:

 :
D.4460 = .ANNOTATE (iftmp.0, 1, 4);
if (D.4460 != 0)
  goto ; [INV]
else
  goto ; [INV]

i.e. the .ANNOTATE comes immediately before the gcond.  To see what is really
going on we can look at -fdump-tree-original.  For the problematic testcase we
have:

if (<::operator() (&pred, *first), unroll 4>>>) goto
; else goto ;

and the simpler testcase without the lambda has:

if (ANNOTATE_EXPR ) goto ;
else
goto ;

so I think the problem is the CLEANUP_POINT_EXPR wrapping the ANNOTATE_EXPR in
the lambda case.  The following fixes that:

diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index a9abf32e01f..b2c29fbb028 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -966,6 +966,16 @@ maybe_convert_cond (tree cond)
   if (type_dependent_expression_p (cond))
 return cond;

+  /* If the condition has an ANNOTATE_EXPR, that must remain the outermost
+ expression of the condition.  Strip it off and re-apply it after the
+ conversion to maintain this invariant.  */
+  tree annotate = NULL_TREE;
+  if (TREE_CODE (cond) == ANNOTATE_EXPR)
+{
+  annotate = cond;
+  cond = TREE_OPERAND (cond, 0);
+}
+
   /* For structured binding used in condition, the conversion needs to be
  evaluated before the individual variables are initialized in the
  std::tuple_{size,elemenet} case.  cp_finish_decomp saved the conversion
@@ -983,7 +993,15 @@ maybe_convert_cond (tree cond)

   /* Do the conversion.  */
   cond = convert_from_reference (cond);
-  return condition_conversion (cond);
+  cond = condition_conversion (cond);
+
+  /* Restore the ANNOTATE_EXPR, if there was one.  */
+  if (annotate)
+{
+  TREE_OPERAND (annotate, 0) = cond;
+  cond = annotate;
+}
+  return cond;
 }

 /* Finish an expression-statement, whose EXPRESSION is as indicated.  */

where the CLEANUP_POINT_EXPR was getting added in condition_conversion.
That passes bootstrap on aarch64.  With that patch, adding:

#pragma GCC unroll 4

above the __find_if loop in stl_algobase.h, we get unrolled std::find
again.  E.g. for the following testcase I get:

#include 
long *f(long *p)
{
  return std::find (p, p + 1024, 42);
}

_Z1fPl:
.LFB675:
.cfi_startproc
mov x1, x0
add x0, x0, 8192
.p2align 5,,15
.L3:
ldr x2, [x1]
cmp x2, 42
beq .L4
ldr x2, [x1, 8]
add x1, x1, 8
mov x3, x1
cmp x2, 42
beq .L4
ldr x2, [x1, 8]!
cmp x2, 42
beq .L4
ldr x2, [x3, 16]
add x1, x3, 16
cmp x2, 42
beq .L4
add x1, x3, 24
cmp x0, x1
bne .L3
ret

at -O2.  But importantly this version should still be vectorizable
further down the line (unlike the hand-unrolled version).

Now for xalancbmk this seems to give back about 4.8% on Neoverse V1
_without_ LTO.  Unfortunately for some reason there is no difference in
the relevant hot function _with_ LTO, so that needs debugging (I'm
looking into that).

[Bug target/116195] New: arm: ICE building pr111150.C

[adhemerval.zanella at linaro dot org via Gcc-bugs]

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

Bug ID: 116195
   Summary: arm: ICE building pr50.C
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adhemerval.zanella at linaro dot org
  Target Milestone: ---

It seems that this change triggered with Linaro CI on arm 32 bit [1]:

--
Executing on host:
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/bin/arm-eabi-g++
 
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/g++.dg/tree-ssa/pr50.C
 -mthumb -march=armv8.1-m.main+mve.fp+fp.dp -mtune=cortex-m55 -mfloat-abi=hard
-mfpu=auto   -fdiagnostics-plain-output  -nostdinc++
-I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/include/arm-eabi
-I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/include
-I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libstdc++-v3/libsupc++
-I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libstdc++-v3/include/backward
-I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libstdc++-v3/testsuite/util
-fmessage-length=0  -std=gnu++98 -O1 -fdump-tree-forwprop1 -Wno-psabi  -S  -o
pr50.s(timeout = 600)
spawn -ignore SIGHUP
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/bin/arm-eabi-g++
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/g++.dg/tree-ssa/pr50.C
-mthumb -march=armv8.1-m.main+mve.fp+fp.dp -mtune=cortex-m55 -mfloat-abi=hard
-mfpu=auto -fdiagnostics-plain-output -nostdinc++
-I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/include/arm-eabi
-I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/include
-I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libstdc++-v3/libsupc++
-I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libstdc++-v3/include/backward
-I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libstdc++-v3/testsuite/util
-fmessage-length=0 -std=gnu++98 -O1 -fdump-tree-forwprop1 -Wno-psabi -S -o
pr50.s
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/g++.dg/tree-ssa/pr50.C:
In function 'v4si f1_(v4si, v4si, v4si, v4si, v4si, v4si)':
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/g++.dg/tree-ssa/pr50.C:13:1:
error: unrecognizable insn:
(insn 22 21 26 2 (set (reg:V4SI 120 [  ])
(unspec:V4SI [
(reg:V4SI 136)
(reg:V4SI 137)
(subreg:V4BI (reg:HI 135) 0)
] VPSELQ_S))
"/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/g++.dg/tree-ssa/pr50.C":12:17
-1
 (nil))
during RTL pass: vregs
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/g++.dg/tree-ssa/pr50.C:13:1:
internal compiler error: in extract_insn, at recog.cc:2848
0x21fd635 internal_error(char const*, ...)
../../../../../../gcc/gcc/diagnostic-global-context.cc:491
0x9a0958 fancy_abort(char const*, int, char const*)
../../../../../../gcc/gcc/diagnostic.cc:1725
0x840e4d _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../../../../../gcc/gcc/rtl-error.cc:108
0x840e6f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../../../../../gcc/gcc/rtl-error.cc:116
0x83f76b extract_insn(rtx_insn*)
../../../../../../gcc/gcc/recog.cc:2848
0xf1a805 instantiate_virtual_regs_in_insn
../../../../../../gcc/gcc/function.cc:1612
0xf1a805 instantiate_virtual_regs
../../../../../../gcc/gcc/function.cc:1995
0xf1a805 execute
../../../../../../gcc/gcc/function.cc:2042
--

Accordingly to Andrew Piski, this is backend bug that was exposed by the patch.

`vcond_mask_` for operand[3] uses s_register_operand which
allows subreg but then it creates a VPSELQ_S unspec which uses
vpr_register_operand as the operand which does not allow subreg and
does not forces into a register.


[1]
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/517/artifact/artifacts/00-sumfiles/

[Bug c++/116169] [DR882] `int main() = delete` is incorrect accepted

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

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

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

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

commit r15-2695-ga790828ccb3b06a7771f871651e7b54d13c3a168
Author: Marek Polacek 
Date:   Thu Aug 1 11:32:26 2024 -0400

c++: DR882, main cannot be deleted [PR116169]

This DR clarifies that "int main() = delete;" is ill-formed.

PR c++/116169

gcc/cp/ChangeLog:

* decl.cc (cp_finish_decl): Disallow deleting ::main.

gcc/testsuite/ChangeLog:

* g++.dg/DRs/dr882.C: New test.

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

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

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

Bug 116169 Summary: [DR882] `int main() = delete` is incorrect accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116169

   What|Removed |Added

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

[Bug c++/116169] [DR882] `int main() = delete` is incorrect accepted

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Done in GCC 15.

[Bug fortran/116196] New: Missing temporary with WHERE and aliasing TARGET array references

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

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

Bug ID: 116196
   Summary: Missing temporary with WHERE and aliasing TARGET array
references
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikael at gcc dot gnu.org
  Target Milestone: ---

The following example outputs:
   1   1   2   3   5
while I think it should output:
   1   1   2   4   5

I found it looking for an example exercising gfc_check_dependency with aliasing
arrays, after the analysis posted as followup to Jakub's recent pasto fix:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/658971.html


MODULE m
  IMPLICIT NONE
  INTEGER, TARGET :: arr(5)
END MODULE m

PROGRAM main
  USE m
  IMPLICIT NONE
  arr = (/ 1, 2, 3, 4, 5 /)
  CALL bar(arr)
  PRINT *, arr
  IF (ANY(arr /= (/ 1, 1, 2, 4, 5 /))) STOP 1
CONTAINS
  SUBROUTINE bar(x)
INTEGER, TARGET :: x(:)
WHERE (arr(1:4) < 3) x(2:5) = x(2:5) - 1
  END SUBROUTINE bar
END PROGRAM main

[Bug c++/115296] CTAD fails

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 14.3, thanks for the bug report.

[Bug libstdc++/116038] ambiguous overload in bind_front caused by deducing this

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #9 from Patrick Palka  ---
Fixed for GCC 14.3, thanks for the bug report.

[Bug c++/115897] [14/15 Regression] vector_size attribute on alias template has no effect when used in a dependent variable template-id

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #15 from Patrick Palka  ---
The alias template with dependent attribute case is partially fixed for 14.2
and should be fully fixed for 14.3.  The non-template alias with dependent
attribute case should be fixed on trunk.

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

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #7 from Patrick Palka  ---
Should be fixed for GCC 14.3.

[Bug c++/54367] [meta-bug] lambda expressions

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

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

Bug 88313 Summary: generic lambda in default template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88313

   What|Removed |Added

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

[Bug target/116145] SVE constant pool loads not hoisted outside loops

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

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

--- Comment #10 from GCC Commits  ---
The trunk branch has been updated by Richard Sandiford :

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

commit r15-2696-gba730fd10934e4ca004251aa3748bf9da4d35e62
Author: Richard Sandiford 
Date:   Fri Aug 2 15:58:31 2024 +0100

Make may_trap_p_1 return false for constant pool references [PR116145]

The testcase contains the constant:

  arr2 = svreinterpret_u8(svdup_u32(0x0a0d5c3f));

which was initially hoisted by hand, but which gimple optimisers later
propagated to each use (as expected).  The constant was then expanded
as a load-and-duplicate from the constant pool.  Normally that load
should then be hoisted back out of the loop, but may_trap_or_fault_p
stopped that from happening in this case.

The code responsible was:

  if (/* MEM_NOTRAP_P only relates to the actual position of the memory
 reference; moving it out of context such as when moving code
 when optimizing, might cause its address to become invalid. 
*/
  code_changed
  || !MEM_NOTRAP_P (x))
{
  poly_int64 size = MEM_SIZE_KNOWN_P (x) ? MEM_SIZE (x) : -1;
  return rtx_addr_can_trap_p_1 (XEXP (x, 0), 0, size,
GET_MODE (x), code_changed);
}

where code_changed is true.  (Arguably it doesn't need to be true in
this case, if we inserted invariants on the preheader edge, but it
would still need to be true for conditionally executed loads.)

Normally this wouldn't be a problem, since rtx_addr_can_trap_p_1
would recognise that the address refers to the constant pool.
However, the SVE load-and-replicate instructions have a limited
offset range, so it isn't possible for them to have a LO_SUM address.
All we have is a plain pseudo base register.

MEM_READONLY_P is defined as:

  /* 1 if RTX is a mem that is statically allocated in read-only memory. 
*/
  #define MEM_READONLY_P(RTX) \
(RTL_FLAG_CHECK1 ("MEM_READONLY_P", (RTX), MEM)->unchanging)

and so I think it should be safe to move memory references if both
MEM_READONLY_P and MEM_NOTRAP_P are true.

The testcase isn't a minimal reproducer, but I think it's good
to have a realistic full routine in the testsuite.

gcc/
PR rtl-optimization/116145
* rtlanal.cc (may_trap_p_1): Trust MEM_NOTRAP_P even for code
movement if MEM_READONLY_P is also true.

gcc/testsuite/
PR rtl-optimization/116145
* gcc.target/aarch64/sve/acle/general/pr116145.c: New test.

[Bug target/116145] SVE constant pool loads not hoisted outside loops

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

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

Richard Sandiford  changed:

   What|Removed |Added

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

--- Comment #11 from Richard Sandiford  ---
Fixed.

[Bug fortran/116196] Missing temporary with WHERE and aliasing TARGET array references

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

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

--- Comment #1 from Mikael Morin  ---
Draft patch:

diff --git a/gcc/fortran/dependency.cc b/gcc/fortran/dependency.cc
index 15edf1af9df..348fd562ef6 100644
--- a/gcc/fortran/dependency.cc
+++ b/gcc/fortran/dependency.cc
@@ -1253,11 +1253,8 @@ check_data_pointer_types (gfc_expr *expr1, gfc_expr
*expr2)
   if (sym1->ts.type == BT_DERIVED && sym2->ts.type == BT_DERIVED)
 return false;

-  if (sym1->attr.pointer)
-{
-  if (gfc_compare_types (&sym1->ts, &sym2->ts))
-   return false;
-}
+  if (gfc_compare_types (&sym1->ts, &sym2->ts))
+return false;

   /* This is a conservative check on the components of the derived type
  if no component references have been seen.  Since we will not dig

[Bug c/116016] enhancement: add __builtin_set_counted_by(P->FAM, COUNT) or equivalent

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

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

--- Comment #48 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #30)
> Then perhaps we should ASAP change 
> handle_counted_by_attribute so that it emits a sorry message if
> (c_dialect_cxx ()),
> either as the first thing, or perhaps after doing the current diagnostics.

agreed, and a patch is under testing now, will submit for review soon.

[Bug c/116193] enhancement: type attribute that causes overflow for unsigned integer types to trap

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #5 from Martin Uecker  ---

I agree this could be done completely in the FE.

[Bug other/30920] Incorrect splaying that fails to assure the caching property

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

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

Richard Sandiford  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2024-08-02

--- Comment #6 from Richard Sandiford  ---
When I added splay-tree-utils.h, Jeff asked me to look at converting
typed_splay_utils to use it, so that we didn't have two competing C++
implementations.  I forgot to go back and do that.  I wasn't aware of this PR
though.

So I'll assign myself for the part about moving typed_splay_utils over to
splay-tree-utils.h.  Looks like the main missing piece is foreach, for which
I'll try to use iterators.

[Bug tree-optimization/116156] [14 regression] -fcompare-debug -gno-statement-frontiers failure with -O2 when building gdk-pixbuf

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

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

--- Comment #10 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Andrew Pinski
:

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

commit r14-10552-g14fa2b2ae7f49dee5e7e7469243e281e48d925b9
Author: Andrew Pinski 
Date:   Thu Aug 1 10:33:34 2024 -0700

forwprop: Don't add uses to dce list if debug statement [PR116156]

The problem here is that when forwprop does a copy prop, into a statement,
we mark the uses of that statement as possibly need to be removed. But it
just
happened that statement was a debug statement, there will be a difference
when
compiling with debuging info turned on vs off; this is not expected.
So the fix is not to add the old use to dce list to process if it was a
debug
statement.

Bootstrapped and tested on x86_64-linux-gnu with no regressions.

PR tree-optimization/116156

gcc/ChangeLog:

* tree-ssa-forwprop.cc (pass_forwprop::execute): Don't add
uses if the statement was a debug statement.

gcc/testsuite/ChangeLog:

* c-c++-common/torture/pr116156-1.c: New test.

Signed-off-by: Andrew Pinski 

[Bug tree-optimization/116156] [14 regression] -fcompare-debug -gno-statement-frontiers failure with -O2 when building gdk-pixbuf

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug middle-end/116058] [15 Regression] sh4-linux-gnu fails to bootstrap, late combine issue

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

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

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

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

commit r15-2700-gda33ad53bcb57943fa671c745938a53f4de89a1b
Author: Andrew Pinski 
Date:   Thu Aug 1 14:22:36 2024 -0700

genemit: Fix handling of explicit parallels for clobbers [PR116058]

In a define_insn, you could use either an explicit parallel for
the insns or genrecog/genemit will add one for you.
The problem when genemit is processing the pattern for clobbers
(to create the function add_clobbers), genemit hadn't add the implicit
parallel yet but at the same time forgot to ignore that there
could be an explicit parallel there.
This means in some cases (like in the sh backend), add_clobbers
and recog had a different idea if there was clobbers on the insn.
This fixes the problem by looking through the explicit parallel
for the instruction in genemit.

Bootstrapped and tested on x86_64-linux-gnu.

PR middle-end/116058

gcc/ChangeLog:

* genemit.cc (struct clobber_pat): Change pattern to be rtvec.
Add code field.
(gen_insn): Look through an explicit parallel if there was one.
Update store to new clobber_pat.
(output_add_clobbers): Update call to gen_exp for the changed
clobber_pat.

Signed-off-by: Andrew Pinski 

[Bug middle-end/116058] [15 Regression] sh4-linux-gnu fails to bootstrap, late combine issue

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/116185] [15 Regression] Comparison failure on sh4 due to debug symbols since r15-2069-g9f9faebb8ebfc0

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

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

Bug 116058 Summary: [15 Regression] sh4-linux-gnu fails to bootstrap, late 
combine issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116058

   What|Removed |Added

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

[Bug rtl-optimization/116179] [15 regression] -fcompare-debug -gno-statement-frontiers failure with -O3 when building mesa-24.1.4 since r15-1735-ge62ea4fb8ffcab (late combine)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #10)
> Hmm:
> ```
>   for (df_ref use = DF_REG_USE_CHAIN (REGNO(dest));
>use;
>use = DF_REF_NEXT_REG (use))
> {
>   int ubbi = DF_REF_BB (use)->index;
>   if (bitmap_bit_p (reachable, ubbi))
> bitmap_set_bit (need_new, ubbi);
> }
> 
> ```
> 
> I think this should check if the use was not a debug insn.
> that is `!DEBUG_INSN_P (DF_REF_INSN (use))` .
> 
> Let me check that tomorrow.

Yes that fixes the issue.

[Bug target/116195] [MVE] arm: ICE building pr111150.C

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|arm: ICE building   |[MVE] arm: ICE building
   |pr50.C  |pr50.C
 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
 Target||arm-eabi
 Status|UNCONFIRMED |NEW
Version|14.0|15.0
   Last reconfirmed||2024-08-02

--- Comment #1 from Andrew Pinski  ---
Note using -fno-tree-ter also works around the backend issue because we don't
end up with a subreg with that.

[Bug target/116197] New: [14/15 only] RISC-V: zvkn does not imply "v" extension

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 116197
   Summary: [14/15 only] RISC-V: zvkn does not imply "v" extension
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
int a, b;
int main() {
  for (; a < 6; a++) {
b = 8;
if (a)
  b = 0;
  }
}

Command:
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -O3 -march=rv64imzvkn_d red.c -w -o red.out
> QEMU_CPU=rv64,vlen=64,rvv_ta_all_1s=true,rvv_ma_all_1s=true 
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/qemu-riscv64 red.out
zsh: illegal hardware instruction (core dumped) 
QEMU_CPU=rv64,vlen=64,rvv_ta_all_1s=true,rvv_ma_all_1s=true  red.out

v isn't defined in any of the isa strings in the final file:
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-readelf
>  -a --wide red.out | grep "rv"
29: 00010464 0 NOTYPE  LOCAL  DEFAULT   11
$xrv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zmmul1p0_zaamo1p0_zalrsc1p0_zca1p0_zcd1p0
34: 00010494 0 NOTYPE  LOCAL  DEFAULT   11
$xrv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zmmul1p0_zaamo1p0_zalrsc1p0_zca1p0_zcd1p0
36: 000103f0 0 NOTYPE  LOCAL  DEFAULT   11
$xrv64i2p1_m2p0_f2p2_d2p2_zicsr2p0_zmmul1p0_zve32x1p0_zve64x1p0_zvkb1p0_zvkn1p0_zvkned1p0_zvknha1p0_zvknhb1p0_zvkt1p0_zvl32b1p0_zvl64b1p0
39: 00010496 0 NOTYPE  LOCAL  DEFAULT   11
$xrv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zmmul1p0_zaamo1p0_zalrsc1p0_zca1p0_zcd1p0
  Tag_RISCV_arch:
"rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zmmul1p0_zaamo1p0_zalrsc1p0_zca1p0_zcd1p0_zve32x1p0_zve64x1p0_zvkb1p0_zvkn1p0_zvkned1p0_zvknha1p0_zvknhb1p0_zvkt1p0_zvl32b1p0_zvl64b1p0"

Godbolt: https://godbolt.org/z/1PnY6cjs8

>From the zvkn spec:
>The Zvknhb and Zvbc Vector Crypto Extensions --and accordingly the composite 
>extensions Zvkn
>and Zvks-- require a Zve64x base, or application ("V") base Vector Extension.
https://github.com/riscv/riscv-crypto/releases

See also: pr116150

[Bug c++/116198] New: Wdeprecated-enum-enum-conversion triggers inside extern "C"

[rsaxvc at gmail dot com via Gcc-bugs]

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

Bug ID: 116198
   Summary: Wdeprecated-enum-enum-conversion triggers inside
extern "C"
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsaxvc at gmail dot com
  Target Milestone: ---

deprecated-enum-enum-conversion warnings apply to C code compiled by G++,
should they? I'm assuming if this code would not trigger a warning in C, it
shouldn't trigger a warning in extern "C". Here's a minimal contrived example:

   #include 

   extern "C"{
  enum {TWO = 2};
  enum {ONE = 1};
  void * triggerDeprecatedEnumConversion() {
 return malloc(ONE | TWO);
  }
   }

When the above code is compiled with g++ 12.2.0, -Wall -Wextra -O2 -std=c++23,
triggers this warning:

   : In function 'void* triggerDeprecatedEnumConversion()':
   :17:27: warning: bitwise operation between different enumeration
types '' and '' is deprecated
[-Wdeprecated-enum-enum-conversion]
  17 | return malloc(ONE | TWO);
 |   ^

One real-world use-case this impacts occurs in LVGL, which uses separate enums
for different parts of a bitfield that are then combined in functions in a
header, so every C++ file that includes those headers triggers this warning.
Related discussion here: https://github.com/lvgl/lvgl/issues/5119

Specific compiler version:
   xtensa-esp32s3-elf-c++.exe (crosstool-NG esp-12.2.0_20230208) 12.2.0
   Copyright (C) 2022 Free Software Foundation, Inc.
   This is free software; see the source for copying conditions.  There is NO
   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug c++/116198] Wdeprecated-enum-enum-conversion triggers inside extern "C"

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

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

--- Comment #1 from Sam James  ---
extern "C" does _not_ change the language something is built as, just linkage.

[Bug c++/116198] Wdeprecated-enum-enum-conversion triggers inside extern "C"

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   See Also||https://github.com/lvgl/lvg
   ||l/issues/5119
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
Why do you think `extern "C"` changes the language? It does not it just changes
the linkage.

[Bug rtl-optimization/116199] New: [15 Regression] reload ICE building glibc for m68k

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

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

Bug ID: 116199
   Summary: [15 Regression] reload ICE building glibc for m68k
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: law at gcc dot gnu.org
  Target Milestone: ---
Target: m68k-*-*

Created attachment 58807
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58807&action=edit
preprocessed source

The following ICE building glibc for m68k-linux-gnu was introduced by:

commit 88d16194d0c8a6bdc2896c8944bfbf3e6038c9d2
Author: Jeff Law 
Date:   Mon Jul 22 08:45:10 2024 -0600

[NFC][PR rtl-optimization/115877] Avoid setting irrelevant bit groups as
live in ext-dce

and is still present as of 7ecd6610528a301e349df273b624513ef3827321. Build the
attached testcase with -O2 (not reduced, but pretty short anyway).

during RTL pass: reload
makedev.c: In function '__gnu_dev_makedev':
makedev.c:34:316: internal compiler error: Segmentation fault
0x1b413ce internal_error(char const*, ...)
   
/notnfs/josmyers/glibc-manual/src/gcc/gcc/diagnostic-global-context.cc:491
0xf02c3f crash_signal
/notnfs/josmyers/glibc-manual/src/gcc/gcc/toplev.cc:321
0xe7990a operands_match_p(rtx_def*, rtx_def*)
/notnfs/josmyers/glibc-manual/src/gcc/gcc/reload.cc:2252
0xe809b0 find_reloads(rtx_insn*, int, int, int, short*)
/notnfs/josmyers/glibc-manual/src/gcc/gcc/reload.cc:2782
0xe9162d calculate_needs_all_insns
/notnfs/josmyers/glibc-manual/src/gcc/gcc/reload1.cc:1469
0xe9162d reload(rtx_insn*, int)
/notnfs/josmyers/glibc-manual/src/gcc/gcc/reload1.cc:983
0xcd577f do_reload
/notnfs/josmyers/glibc-manual/src/gcc/gcc/ira.cc:5985
0xcd577f execute
/notnfs/josmyers/glibc-manual/src/gcc/gcc/ira.cc:6161
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 c++/116198] Wdeprecated-enum-enum-conversion triggers inside extern "C"

[rsaxvc at gmail dot com via Gcc-bugs]

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

--- Comment #3 from rsaxvc at gmail dot com ---
Thanks, that makes sense. I didn't realize that any code in a header would need
to be able to compile as any language including that header, so we'll need to
fix LVGL.

[Bug ipa/116191] Avoid inlining in unlikely branches

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

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

Andi Kleen  changed:

   What|Removed |Added

 CC||andi-gcc at firstfloor dot org

--- Comment #2 from Andi Kleen  ---
I suppose it depends on the programing style if it's a good idea. Sometimes
inlining allows to constant propagate and collapse a lot of code, and you
definitely want that for cold code too.

[Bug rtl-optimization/116199] [15 Regression] reload ICE building glibc for m68k

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Keywords||ra

--- Comment #1 from Andrew Pinski  ---
Hmm, I thought at least we were going to deprecate all non LRA based targets
which in this case includes m68k.

[Bug testsuite/116155] c-c++-common/fam-in-union-alone-in-struct-1.c fails on pru-unknown-elf

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

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

--- Comment #9 from Dimitar Dimitrov  ---
(In reply to qinzhao from comment #8)
> (In reply to Dimitar Dimitrov from comment #7)
> > Size of only_fam_2 is 1.
> sizeof (int) and alignof (int) still is 4?

For pru:
  sizeof (int) = 4
  __alignof__ (int) = 1

>From gcc/config/pru.h:
  #define INT_TYPE_SIZE 32
  #define BIGGEST_ALIGNMENT 8

[Bug ipa/116191] Avoid inlining in unlikely branches

[ilija.tovilo at me dot com via Gcc-bugs]

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

--- Comment #3 from ilija.tovilo  ---
(In reply to Andi Kleen from comment #2)
> I suppose it depends on the programing style if it's a good idea. Sometimes
> inlining allows to constant propagate and collapse a lot of code, and you
> definitely want that for cold code too.

Right, I agree. __builtin_expect() is often misused, including in our codebase.
I do think there is some probability threshold where inlining is hurtful. It
seems like gcc already uses this rationale in some cases. For example:

void unlikely_branch_through_cold_func_call(zend_string *s, bool cond) {
if (cond) {
zend_string_release(s);
cold_func();
}
printf("Hello world");
}

Here, zend_string_release() is not inlined, because the branch is considered
unlikely due to the cold_func() call. Removing the cold attribute from
cold_func() causes zend_string_release() to be inlined
(https://godbolt.org/z/rbxdsoq9n).

How exactly the branch probability should be integrated in inlining heuristics,
I don't know. But gcc not paying attention to branching probability at all does
seem a bit surprising.

[Bug c++/105475] coroutines: ICE in coerce_template_parms, at cp/pt.cc:9183

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

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

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

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

commit r15-2702-g5b4476a165565cb20729c0a97a3f43b060595209
Author: Arsen ArsenoviÄ 
Date:   Thu Jul 25 22:41:34 2024 +0200

c++/coroutines: check for members we use in handle_types [PR105475]

Currently, it is possible to ICE GCC by giving it sufficiently broken
code, where sufficiently broken means a std::coroutine_handle missing a
default on the promise_type template argument, and missing members.
As the code generator relies on lookups in the coroutine_handle never
failing (and has no way to signal that error), lets do it ahead of time,
save the result, and use that.  This saves us some lookups and allows us
to propagate an error.

PR c++/105475 - coroutines: ICE in coerce_template_parms, at cp/pt.cc:9183

gcc/cp/ChangeLog:

PR c++/105475
* coroutines.cc (struct coroutine_info): Add from_address.
Carries the from_address member we looked up earlier.
(coro_resume_identifier): Remove.  Unused.
(coro_init_identifiers): Do not initialize the above.
(void_coro_handle_address): New variable.  Contains the baselink
for the std::coroutine_handle::address() instance method.
(get_handle_type_address): New function.  Looks up and validates
handle_type::address in a given handle_type.
(get_handle_type_from_address): New function.  Looks up and
validates handle_type::from_address in a given handle_type.
(coro_promise_type_found_p): Remove reliance on
coroutine_handle<> defaulting the promise type to void.  Store
get_handle_type_* results where appropriate.
(get_coroutine_from_address): New helper.  Gets the
handle_type::from_address BASELINK from a coroutine_info.
(build_actor_fn): Use the get_coroutine_from_address helper and
void_coro_handle_address.

gcc/testsuite/ChangeLog:

PR c++/105475
* g++.dg/coroutines/pr103868.C: Add std::coroutine_handle
members we check for now.
* g++.dg/coroutines/pr105287.C: Ditto.
* g++.dg/coroutines/pr105301.C: Ditto.
* g++.dg/coroutines/pr94528.C: Ditto.
* g++.dg/coroutines/pr94879-folly-1.C: Ditto.
* g++.dg/coroutines/pr94883-folly-2.C: Ditto.
* g++.dg/coroutines/pr98118.C: Ditto.
* g++.dg/coroutines/pr105475.C: New test.
* g++.dg/coroutines/pr105475-1.C: New test.
* g++.dg/coroutines/pr105475-2.C: New test.
* g++.dg/coroutines/pr105475-3.C: New test.
* g++.dg/coroutines/pr105475-4.C: New test.
* g++.dg/coroutines/pr105475-5.C: New test.
* g++.dg/coroutines/pr105475-6.C: New test.
* g++.dg/coroutines/pr105475-broken-spec.C: New test.
* g++.dg/coroutines/pr105475-broken-spec-2.C: New test.

[Bug other/116200] New: [15 regression] ICE in stage 2

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

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

Bug ID: 116200
   Summary: [15 regression] ICE in stage 2
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This started between r15-2695-ga790828ccb3b06 and r15-2699-g7ecd6610528a30

libtool: compile: 
/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./gcc/gfortran
-B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./gcc/
-B/home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/sys-include
-fno-checking -L. -Wall -L../libgfortran -c
/home/seurer/gcc/git/gcc-trunk-bootstrap/libgomp/openacc.f90  -fPIC -o
.libs/openacc.o
/home/seurer/gcc/git/gcc-trunk-bootstrap/libgomp/openacc.f90:1039:61:

 1039 |  bytes, async_arg) bind(C)
  | 1
Warning: Variable 'async_arg' at (1) is a dummy argument of the BIND(C)
procedure 'acc_memcpy_from_device_async' but may not be C interoperable
[-Wc-binding-type]
/home/seurer/gcc/git/gcc-trunk-bootstrap/libgomp/openacc.f90:1017:59:

 1017 |bytes, async_arg) bind(C)
  |   1
Warning: Variable 'async_arg' at (1) is a dummy argument of the BIND(C)
procedure 'acc_memcpy_to_device_async' but may not be C interoperable
[-Wc-binding-type]
f951: internal compiler error: Segmentation fault

[Bug rtl-optimization/116200] [15 regression] ICE in stage 2

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
   Target Milestone|--- |15.0
  Component|other   |rtl-optimization
   Keywords||build, wrong-code

[Bug rtl-optimization/116200] [15 regression] ICE in stage 2

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

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

--- Comment #1 from Andrew Pinski  ---
Compiling fortran/module.o at "-O0 -g" works but fails if compiled at "-O2 -g".

[Bug rtl-optimization/116200] [15 regression] ICE in stage 2 since r15-2696-gba730fd10934e4

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

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

Sam James  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org,
   ||sjames at gcc dot gnu.org
Summary|[15 regression] ICE in  |[15 regression] ICE in
   |stage 2 |stage 2 since
   ||r15-2696-gba730fd10934e4

--- Comment #2 from Sam James  ---
It has to be r15-2696-gba730fd10934e4.

[Bug rtl-optimization/116200] [15 regression] ICE in stage 2 since r15-2696-gba730fd10934e4

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

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

--- Comment #3 from Andrew Pinski  ---
Note I am testing on x86_64-linux-gnu but it looks like it fails mostly
everywhere too.

[Bug rtl-optimization/116200] [15 regression] ICE in stage 2 since r15-2696-gba730fd10934e4

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-08-02
 Status|UNCONFIRMED |NEW
 Target||*-*-*
 Ever confirmed|0   |1

[Bug rtl-optimization/116200] [15 regression] ICE in stage 2 since r15-2696-gba730fd10934e4

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |blocker

[Bug rtl-optimization/116200] [15 regression] ICE in stage 2 since r15-2696-gba730fd10934e4

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

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

Sam James  changed:

   What|Removed |Added

 CC||haochen.jiang at intel dot com

--- Comment #4 from Sam James  ---
https://inbox.sourceware.org/gcc-regression/20240802170522.0901d2c9...@gnu-skx-1.sc.intel.com/T/#u
too

[Bug c++/115361] "possibly dangling reference to a temporary" when object is_empty

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

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

--- Comment #2 from Marek Polacek  ---
I've moved -Wdangling-reference to -Wextra in r15-2703-g5ebfaf2d4994c1

[Bug testsuite/116155] c-c++-common/fam-in-union-alone-in-struct-1.c fails on pru-unknown-elf

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

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

--- Comment #10 from qinzhao at gcc dot gnu.org ---
(In reply to Dimitar Dimitrov from comment #9)
> For pru:
>   sizeof (int) = 4
>   __alignof__ (int) = 1
> 
> From gcc/config/pru.h:
>   #define INT_TYPE_SIZE 32
>   #define BIGGEST_ALIGNMENT 8

thanks a lot for the info.
Okay, I see the issue. 

I think the line 

  if (sizeof (struct only_fam_2) != sizeof (int))

is wrong, it should be:

  if (sizeof (struct only_fam_2) != __alignof__ (int))

[Bug rtl-optimization/116199] [15 Regression] reload ICE building glibc for m68k

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

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

--- Comment #2 from Jeffrey A. Law  ---
Even if we're going to drop m68k due to lack of LRA support, if ext-dce is
doing something wrong, it's still worth debugging & fixing as it likely affects
other ports.  And note this is the second issue bisect to what was supposed to
be a NFC change :(  Ugh.

And you never know, maybe someone will come along and enable LRA on the m68k. 
I think one of the bugbounty folks that worked on the cc0 transition also had
bits to enable LRA.  So it may not be a huge lift if we can find those old
bits...

[Bug modula2/116181] -Wlto-type-mismatch warnings/errors during m2 bootstrap

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2024-08-02

--- Comment #1 from Gaius Mulley  ---
Confirmed with the following configure and make invocation:

$ CFLAGS="-Werror=lto-type-mismatch -g -O0" CXXFLAGS="-Werror=lto-type-mismatch
-g -O0" ../configure --prefix=$HOME/opt --enable-bootstrap
--with-build-config="bootstrap-O3 bootstrap-lto"
--enable-languages=c,c++,m2,lto ; CFLAGS="-Werror=lto-type-mismatch -g -O0"
CXXFLAGS="-Werror=lto-type-mismatch -g -O0" make -j 12 >& $HOME/log

[Bug rtl-optimization/116200] [15 regression] ICE in stage 2 since r15-2696-gba730fd10934e4

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

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

--- Comment #5 from Andrew Pinski  ---
On x86_64 we are crashing on:
=> 0x00a01bb6 <+2278>:  mov0x2612db0(,%rax,8),%rdx

(insn:TI 1615 3377 1617 104 (set (reg:DI 0 ax [690])
(zero_extend:DI (reg:SI 2 cx [681])))
"/home/apinski/src/upstream-gcc-isel/gcc/gcc/fortran/module.cc":6796:6 168
{*zero_extendsidi2}
 (nil))

(insn:TI 1617 1615 5449 104 (set (reg:DI 1 dx [691])
(mem/u/c:DI (plus:DI (ashift:DI (reg:DI 0 ax [690])
(const_int 3 [0x3]))
(label_ref:DI 1620)) [0  S8 A8]))
"/home/apinski/src/upstream-gcc-isel/gcc/gcc/fortran/module.cc":6796:6 88
{*movdi_internal}
 (expr_list:REG_DEAD (reg:DI 0 ax [690])

rax here is -9 .

This was pulled out before the comparison to make sure eax/ecx is range of
[0..2]:
(insn:TI 1613 4828 1614 105 (set (reg:CC 17 flags)
(compare:CC (reg:SI 2 cx [681])
(const_int 2 [0x2])))
"/home/apinski/src/upstream-gcc-isel/gcc/gcc/fortran/module.cc":6796:6 15
{*cmpsi_1}
 (nil))
(jump_insn 1614 1613 3282 105 (set (pc)
(if_then_else (gtu (reg:CC 17 flags)
(const_int 0 [0]))
(label_ref 1986)
(pc)))
"/home/apinski/src/upstream-gcc-isel/gcc/gcc/fortran/module.cc":6796:6 1246
{*jcc}
 (expr_list:REG_DEAD (reg:CC 17 flags)
(int_list:REG_BR_PROB 5572 (nil)))
 -> 1986)

[Bug target/116197] [14/15 only] RISC-V: zvkn does not imply "v" extension

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

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

--- Comment #1 from Patrick O'Neill  ---
Apologies, I was using an old version of QEMU that didn't support zve64x

[Bug other/116201] New: SARIF output doesn't properly reference the CWE taxonomy

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

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

Bug ID: 116201
   Summary: SARIF output doesn't properly reference the CWE
taxonomy
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: SARIF
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

We have:


std::unique_ptr
sarif_builder::
make_tool_component_reference_object_for_cwe () const
{
  auto comp_ref_obj = ::make_unique ();

  /* "name" property  (SARIF v2.1.0 section 3.54.3).  */
  comp_ref_obj->set_string ("name", "cwe");

  return comp_ref_obj;
}


where name is lowercase "cwe" whereas in:


std::unique_ptr
sarif_builder::maybe_make_cwe_taxonomy_object () const
{
  if (m_cwe_id_set.is_empty ())
return nullptr;

  auto taxonomy_obj = ::make_unique ();

  /* "name" property (SARIF v2.1.0 section 3.19.8).  */
  taxonomy_obj->set_string ("name", "CWE");


the taxonomy object has uppercase name "CWE".

We should use uppercase for both for consistency.


That said, the spec says:

> 3.54.3 name property
> 
> A toolComponentReference object MAY contain a property named name whose 
> value is a string equal to theComponent.name (§3.19.8).
> 
> NOTE: This property does not participate in the lookup, but its presence
> improves the readability of the log file at the expense of increased file 
> size.

and so we should be using "index" or "guid" to establish the reference
(probably by adding an "index" property to the toolComponentReference).

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

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

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-08-02
 Ever confirmed|0   |1

--- Comment #13 from Peter Bergner  ---
Just as an FYI, the following error on a powerpc64le-linux
--without-long-double-128 build:

In file included from ../../../libquadmath/math/sqrtq.c:13:
../../../libquadmath/math/../../libgcc/soft-fp/quad.h:69:1: error: unable to
emulate 'TF'
   69 | typedef float TFtype __attribute__ ((mode (TF)));
  | ^~~

...first shows up with the following commit:


commit 481ba4fb5fce8257f5dbeb994dac2748c0237fa2 (HEAD)
Author: Jakub Jelinek 
AuthorDate: Tue Apr 9 08:17:25 2024 +0200
Commit: Jakub Jelinek 
CommitDate: Tue Apr 9 08:17:25 2024 +0200

libquadmath: Use soft-fp for sqrtq finite positive arguments [PR114623]

sqrt should be 0.5ulp precise, but the current implementation is less
precise than that.
The following patch uses the soft-fp code (like e.g. glibc for x86) for it
if possible.  I didn't want to replicate the libgcc infrastructure for
choosing the right sfp-machine.h, so the patch just uses a single generic
implementation.  As the code is used solely for the finite positive
arguments,
it shouldn't generate NaNs (so the exact form of canonical QNaN/SNaN is
irrelevant), and sqrt for these shouldn't produce underflows/overflows
either,
for < 1.0 arguments it always returns larger values than the argument and
for
> 1.0 smaller values than the argument.

2024-04-09  Jakub Jelinek  

PR libquadmath/114623
* sfp-machine.h: New file.
* math/sqrtq.c: Include from libgcc/soft-fp also soft-fp.h and
quad.h
if possible.
(USE_SOFT_FP): Define in that case.
(sqrtq): Use soft-fp based implementation for the finite positive
arguments if possible.

...which is due to the above commit code includes quad.h, and quad.h (even
before the above commit) seems to require TFmode exists, which it doesn't on a
--without-long-double-128 build.

[Bug rtl-optimization/116199] [15 Regression] reload ICE building glibc for m68k

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-08-02
 Ever confirmed|0   |1

--- Comment #3 from Jeffrey A. Law  ---
So the code coming out of ext-dce looks quite sensible.   The key insns:

(insn 7 4 8 2 (set (reg:DI 31 [ _1 ])
(subreg:DI (reg/v:SI 37 [ __major ]) 0)) "j.c":7:32 75 {*m68k.md:1568}
 (nil))
(insn 8 7 10 2 (set (reg:DI 39 [ _2 ])
(ashift:DI (reg:DI 31 [ _1 ])
(const_int 8 [0x8]))) "j.c":7:48 322 {*ashldi3}
 (expr_list:REG_DEAD (reg:DI 31 [ _1 ])
(nil)))

Insn 7 had previously been a extension, but the upper bits aren't used and we
could safely turn it into a paradoxical subreg.

Combine's actions are sensible, combining insns 7 and 8 into:

(insn 8 7 10 2 (set (reg:DI 39 [ _2 ])
(ashift:DI (subreg:DI (reg/v:SI 37 [ __major ]) 0)
(const_int 8 [0x8]))) "j.c":7:48 322 {*ashldi3}
 (nil))

Still quite sensible.  IRA allocates (reg:SI 37) to d0.  Still quite sensible. 
We ultimately have this inside reload:

(insn 8 7 10 2 (set (reg:DI 8 %a0 [orig:39 _2 ] [39])
(ashift:DI (subreg:DI (reg/v:SI 0 %d0 [orig:37 __major ] [37]) 0)
(const_int 8 [0x8]))) "j.c":7:48 322 {*ashldi3}
 (nil))

Then reload blows up trying to ensure that op0/op1 match.  Looks like a reload
issue to me.

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

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

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

--- Comment #14 from Jakub Jelinek  ---
So, can you explain how could libquadmath build at all in such configurations?
__float128 type is supported and not TFmode?
Is that because it is KFmode instead or what?
quadmath.h has
#if (!defined(_ARCH_PPC)) || defined(__LONG_DOUBLE_IEEE128__)
typedef _Complex float __attribute__((mode(TC))) __complex128;
#else
typedef _Complex float __attribute__((mode(KC))) __complex128;
#endif

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

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

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

--- Comment #15 from Jakub Jelinek  ---
If so, then perhaps
--- libquadmath/math/sqrtq.c.jj 2024-04-09 08:16:54.128737859 +0200
+++ libquadmath/math/sqrtq.c2024-08-02 23:28:00.862495012 +0200
@@ -9,6 +9,9 @@
 && defined(FE_TOWARDZERO) \
 && defined(FE_INEXACT)
 #define USE_SOFT_FP 1
+#if defined(_ARCH_PPC) && !defined(__LONG_DOUBLE_IEEE128__)
+#define TFtype __float128
+#endif
 #include "../../libgcc/soft-fp/soft-fp.h"
 #include "../../libgcc/soft-fp/quad.h"
 #endif
would fix that.

[Bug tree-optimization/116166] risc-v (last) insn-emit-nn.c build takes hours

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #9 from Sam James  ---
(It already blocks PR111600.)

[Bug target/116174] [14/15 regression] Alignment request is added before endbr with -fcf-protection=branch

[gcc at breakpoint dot cc via Gcc-bugs]

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

--- Comment #3 from Sebastian Andrzej Siewior  ---
bisect says:

commit b644126237a1aa8599f767a5e0bbada1d7286f44
Author: liuhongt 
Date:   Wed May 29 11:14:26 2024 +0800

Align tight&hot loop without considering max skipping bytes.

When hot loop is small enough to fix into one cacheline, we should align
the loop with ceil_log2 (loop_size) without considering maximum
skipp bytes. It will help code prefetch.

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

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

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

--- Comment #16 from Peter Bergner  ---
(In reply to Jakub Jelinek from comment #14)
> So, can you explain how could libquadmath build at all in such
> configurations?
> __float128 type is supported and not TFmode?
> Is that because it is KFmode instead or what?

I don't know. :-).  Hopefully Mike can answer, since he knows the TF/IF/KFmode
support on Power better than anyone.

That said...

(In reply to Jakub Jelinek from comment #15)
> If so, then perhaps
> --- libquadmath/math/sqrtq.c.jj   2024-04-09 08:16:54.128737859 +0200
> +++ libquadmath/math/sqrtq.c  2024-08-02 23:28:00.862495012 +0200
> @@ -9,6 +9,9 @@
>  && defined(FE_TOWARDZERO) \
>  && defined(FE_INEXACT)
>  #define USE_SOFT_FP 1
> +#if defined(_ARCH_PPC) && !defined(__LONG_DOUBLE_IEEE128__)
> +#define TFtype __float128
> +#endif
>  #include "../../libgcc/soft-fp/soft-fp.h"
>  #include "../../libgcc/soft-fp/quad.h"
>  #endif
> would fix that.

I applied that patch and my powerpc64le-linux --without-lond-double-128 build
completed with no errors.  Whether what it produced is correct or not, I'll
leave to Mike to answer.