https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113498
--- Comment #2 from Bob Miller ---
Apologies, I should have reduced this test case further before submission, but
I was under the mistaken impression that the template weirdness was the cause.
I believe this is a minimized example:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64064
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113500
--- Comment #2 from Jonathan Wakely ---
(In reply to Hirthammer from comment #0)
> Consider the following code snippet:
As stated at https://gcc.gnu.org/bugs we want a complete test case, not a
snippet.
#include
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113500
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |13.3
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113488
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113487
--- Comment #3 from Richard Biener ---
Feels more like reassoc to me. You could also view it as "bit-DCE", eliding
defs of dead bits. Which might make it suitable for backprop (currently
doing sth similar for the sign "bit").
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113485
Richard Biener changed:
What|Removed |Added
Target||aarch64
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113500
Bug ID: 113500
Summary: Using std::format with float or double based
std::chrono::time_point causes error: no match for
'operator<<'
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113488
Jakub Jelinek changed:
What|Removed |Added
Summary|[14 Regression] ICE in |[14 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113499
--- Comment #1 from Richard Biener ---
Note it might also be because the failing build is using glibc-2.31, IIRC
newer glibc might include libdl directly (at least that's the case for
libpthreads ...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #15 from Richard Biener ---
(In reply to Sam James from comment #14)
> I tried 'if (candidate && candidate->src != EDGE_PRED (loop->latch,
> 0)->src)' as well given that seems way more sensible and that works too, but
> obviously if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113488
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99913
Brecht Sanders changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113499
Bug ID: 113499
Summary: crab1 fails to link when configuring with
--disable-plugin
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113498
--- Comment #1 from Bob Miller ---
Bug also occurs on GCC Trunk in Compiler Explorer.
Small test case to reproduce bug: https://godbolt.org/z/TorE88bMT
#include
template class ThisTT,
typename T,
size_t...Dims>
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113498
Bug ID: 113498
Summary: ICE in GCC trunk: tree check: have using_decl in
get_template_info, at cp/pt.cc:357
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113497
--- Comment #2 from cqwrteur ---
https://github.com/gcc-mirror/gcc/blob/9693459e030977d6e906ea7eb587ed09ee4fddbd/libgcc/config/i386/enable-execute-stack-mingw32.c#L31
Looks like it misses stdlib.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113497
cqwrteur changed:
What|Removed |Added
CC||unlvsur at live dot com
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113497
Bug ID: 113497
Summary: error: implicit declaration of function 'abort' on
enable-execute-stack.c
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #25 from Xin Li ---
(In reply to Xin Li from comment #22)
> Per Peter's suggestion, I added __attribute__((no_callee_saved_registers))
> to a linux source tree containing FRED patches:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #24 from Xin Li ---
(In reply to H.J. Lu from comment #23)
> (In reply to Xin Li from comment #22)
> > Per Peter's suggestion, I added __attribute__((no_callee_saved_registers))
> > to a linux source tree containing FRED patches:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113488
--- Comment #3 from Jakub Jelinek ---
Created attachment 57151
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57151=edit
v8_turboshaft.late-optimization-phase.ii
./cc1plus -fpreprocessed v8_turboshaft.late-optimization-phase.ii -quiet
rap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240118 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113443
--- Comment #3 from Jason Liam ---
Clang is also wrong in rejecting the code. Here is the clang bub:
https://github.com/llvm/llvm-project/issues/78449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113447
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113447
--- Comment #1 from GCC Commits ---
The master branch has been updated by Ian Lance Taylor :
https://gcc.gnu.org/g:7e949ffaafb415150047127f529377502097d897
commit r14-8268-g7e949ffaafb415150047127f529377502097d897
Author: Ian Lance Taylor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 104355, which changed state.
Bug 104355 Summary: Misleading -Warray-bounds documentation says "always out of
bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104355
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104355
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #17 from JuzheZhong ---
Ok. Confirm the original test 33383M -> 4796k now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #16 from JuzheZhong ---
(In reply to Andrew Pinski from comment #15)
> (In reply to JuzheZhong from comment #14)
> > Oh. I known the reason now.
> >
> > The issue is not RISC-V backend VSETVL PASS.
> >
> > It's memory bug of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #15 from Andrew Pinski ---
(In reply to JuzheZhong from comment #14)
> Oh. I known the reason now.
>
> The issue is not RISC-V backend VSETVL PASS.
>
> It's memory bug of rtx_equal_p I think.
It is not rtx_equal_p but rather
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #14 from JuzheZhong ---
Oh. I known the reason now.
The issue is not RISC-V backend VSETVL PASS.
It's memory bug of rtx_equal_p I think.
We are calling rtx_equal_p which is very costly.
For example, has_nonvlmax_reg_avl is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #13 from JuzheZhong ---
So I think we should investigate why calling has_nonvlmax_reg_avl cost so much
memory.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #12 from JuzheZhong ---
Ok. Here is a simple fix which give some hints:
diff --git a/gcc/config/riscv/riscv-vsetvl.cc
b/gcc/config/riscv/riscv-vsetvl.cc
index 2067073185f..ede818140dc 100644
--- a/gcc/config/riscv/riscv-vsetvl.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113405
Nathaniel Shead changed:
What|Removed |Added
CC||nathanieloshead at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #11 from JuzheZhong ---
It should be compute_lcm_local_properties. The memory usage reduce 50% after I
remove this function. I am still investigating.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #10 from JuzheZhong ---
No, it's not caused here. I removed the whole function compute_avl_def_data.
The memory usage doesn't change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 113429, which changed state.
Bug 113429 Summary: RISC-V: SPEC2017 527 cam4 miscompilation in autovec VLA
build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113429
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113429
Vineet Gupta changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #9 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #8)
> How sparse is this bitmap will be? bitmap instead of sbitmap should be used
> if the bitmap is going to be sparse. sbitmap is a fixed sized based on the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #8 from Andrew Pinski ---
(In reply to Patrick O'Neill from comment #7)
> I believe the memory hog is caused by this:
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/riscv/riscv-vsetvl.cc;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
Patrick O'Neill changed:
What|Removed |Added
CC||patrick at rivosinc dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #14 from Sam James ---
I tried 'if (candidate && candidate->src != EDGE_PRED (loop->latch, 0)->src)'
as well given that seems way more sensible and that works too, but obviously if
I pick something eager or always true, it's going
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102397
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113437
Hongtao Liu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113437
--- Comment #7 from GCC Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:1c51d0109a4730827c40c3bbd3a59d459828017e
commit r14-8266-g1c51d0109a4730827c40c3bbd3a59d459828017e
Author: liuhongt
Date: Fri Jan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113437
Hans-Peter Nilsson changed:
What|Removed |Added
Target|arm, sparc* |arm, sparc*, cris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 113038, which changed state.
Bug 113038 Summary: [14 regression] Excess errors for
g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038
Hans-Peter Nilsson changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #13 from Sam James ---
if I just cast RHS to basic_block (doubt that's the right thing), then
libgcrypt tests pass!
this also fixes mpfr + gmp tests, thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110029
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110029
--- Comment #2 from GCC Commits ---
The master branch has been updated by Sandra Loosemore :
https://gcc.gnu.org/g:ed28a835058d2e72036f4adb1dd60edf735c7d00
commit r14-8263-ged28a835058d2e72036f4adb1dd60edf735c7d00
Author: Sandra Loosemore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #4 from Kewen Lin ---
(In reply to Naveen N Rao from comment #2)
> I don't really have a preference, though I tend to agree that nops before
> the local entry point aren't that useful. Even with the current approach,
> not all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #6 from JuzheZhong ---
(In reply to Andrew Pinski from comment #5)
> Note "loop invariant motion" is the RTL based loop invariant motion pass.
So you mean it should be still RISC-V issue, right ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |rtl-optimization
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #4 from JuzheZhong ---
Also, the original file with -fno-move-loop-invariants reduce compile time from
60 minutes into 7 minutes:
real7m12.528s
user6m55.214s
sys 0m17.147s
machine dep reorg : 75.93 (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #3 from JuzheZhong ---
Ok. The reduced case:
# 1 "module_first_rk_step_part1.fppized.f90"
# 1 ""
# 1 ""
# 1 "module_first_rk_step_part1.fppized.f90"
!WRF:MEDIATION_LAYER:SOLVER
MODULE module_first_rk_step_part1
CONTAINS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #2 from JuzheZhong ---
To build the attachment file, we need these following file from SPEC2017:
module_big_step_utilities_em.mod module_cumulus_driver.mod
module_fddagd_driver.modmodule_model_constants.mod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #1 from JuzheZhong ---
Created attachment 57149
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57149=edit
spec2017 wrf
spec2017 wrf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113437
--- Comment #5 from Hongtao Liu ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Hongtao Liu from comment #2)
> > Maybe we can add target vect_int.
>
> Not really because vect_int depends on the vect.exp framework still. See PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
Bug ID: 113495
Summary: RISC-V: Time and memory awful consumption of SPEC2017
wrf benchmark
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112588
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038
--- Comment #9 from Hans-Peter Nilsson ---
For cris-elf, a change in the range (known to fail, known to pass]
(r14-8193-g3340878009acfc, r14-8200-g9a5e8f9d112adb] seems to have fixed the
remaining hello-1 execution failure, so fixed by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113458
--- Comment #6 from Hongtao Liu ---
> thus
>
> vect__16.5_40 = MEM [(short int *)a_22(D)];
> vect__17.6_41 = (vector(4) int) vect__16.5_40;
> vect__18.9_44 = MEM [(signed char *)b_23(D)];
> vect_patt_36.10_45 = (vector(4) signed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108470
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108470
--- Comment #5 from GCC Commits ---
The master branch has been updated by Sandra Loosemore :
https://gcc.gnu.org/g:9b6b7d615543d73381cb1f994825d9bca024c838
commit r14-8261-g9b6b7d615543d73381cb1f994825d9bca024c838
Author: Sandra Loosemore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113415
--- Comment #4 from Andrew Pinski ---
Note without RTL checking we get:
```
:7:3: error: impossible constraint in 'asm'
7 | __asm__ goto("" : "=r"(bitint0) : : : lab);
| ^~~
:8:1: error: wrong number of branch edges after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109640
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113415
Andrew Pinski changed:
What|Removed |Added
Keywords||inline-asm
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113466
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-01-18
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111410
--- Comment #1 from Marek Polacek ---
Thanks for the report. I think we should disable the warning for operator|
coming from std::ranges.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69807
--- Comment #4 from John David Anglin ---
Fixed for hppa64-hp-hpux11.11 on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69807
--- Comment #3 from GCC Commits ---
The master branch has been updated by John David Anglin :
https://gcc.gnu.org/g:0c7c65c4c359f8bfa1ebcb7b1c409af314064da2
commit r14-8260-g0c7c65c4c359f8bfa1ebcb7b1c409af314064da2
Author: John David Anglin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113494
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113489
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113494
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113481
--- Comment #10 from Andrew Pinski ---
Note the code in dw2_asm_output_data has been zeroing the top bits on value
since at least 2001. So I really doubt this is a new issue. It just folks are
now testing with checking enabled more it seems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113481
--- Comment #9 from Andrew Pinski ---
This fixes the ICE but I am not 100% sure it is correct:
```
diff --git a/gcc/dwarf2asm.cc b/gcc/dwarf2asm.cc
index 6c835bafbc4..7bd9c5f8bcc 100644
--- a/gcc/dwarf2asm.cc
+++ b/gcc/dwarf2asm.cc
@@ -146,11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113494
Bug ID: 113494
Summary: [14 Regression] ICE (segfault) in
slpeel_tree_duplicate_loop_to_edge_cfg since
r14-8206-g0f3880d6ad0e
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113481
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |debug
--- Comment #8 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113481
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-01-18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113471
--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #3)
> Thanks for the quick reaction, indeed with your fix, all our tests do work
> again when all check flags are switched on (we don't do it in our CI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113471
--- Comment #3 from Jürgen Reuter ---
(In reply to anlauf from comment #2)
> The following patch fixes the reduced testcase for me, as well as the
> full testcase in comment#0:
>
> diff --git a/gcc/fortran/trans-array.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111410
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2024-01-18
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111607
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113486
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113317
--- Comment #6 from seurer at gcc dot gnu.org ---
>From experimenting this seems to be an issue with the system compiler
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
I tried an older compiler (8.4) and it worked ok.
I just experimented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67277
--- Comment #9 from GCC Commits ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:09301f083d86b04753d93e84dc1b8a313285e40a
commit r13-8239-g09301f083d86b04753d93e84dc1b8a313285e40a
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113256
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111287
--- Comment #3 from Joseph S. Myers ---
"even in strict ISO C90 mode" is used, correctly, when referring to C90 mode as
the one with the fewest built-in functions; it's talking about __builtin_*,
which are valid in all standards modes.
"except
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111287
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113484
--- Comment #1 from Joseph S. Myers ---
It would of course be necessary to define the ABI used for _Float16 (and
_Complex _Float16) argument passing and return (in each PowerPC ABI for which
we support use of this feature).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450
--- Comment #5 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:5240df78a07303a37b1f0b83165624d2a648089e
commit r13-8238-g5240df78a07303a37b1f0b83165624d2a648089e
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113366
--- Comment #5 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:35000c65470792aed3a3c23a3b3fc45db4bec2c4
commit r13-8237-g35000c65470792aed3a3c23a3b3fc45db4bec2c4
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113437
John David Anglin changed:
What|Removed |Added
CC||danglin at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113481
--- Comment #6 from Georg-Johann Lay ---
This is as simple as it gets:
void Afun5 (__uint24 num)
{
__asm volatile ("" :: "r" (num));
}
void func (void)
{
Afun5 (0xcc);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113493
Bug ID: 113493
Summary: FAIL: gcc.dg/tree-ssa/slsr-13.c scan-tree-dump-times
optimized
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
1-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240118 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113484
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113150
--- Comment #3 from Iain Sandoe ---
on darwin we also get (all with the same diagnostic - about a leaked fd)
I can report them separately if you like - but it seems likely to be a common
cause:
FAIL:
1 - 100 of 269 matches
Mail list logo
