https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114070
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114070
--- Comment #1 from Sam James ---
I'll reduce.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114070
Bug ID: 114070
Summary: [12/13/13 regression] ICE when building git-2.43.2
with -mcpu=niagara4 -fno-vect-cost-model
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114069
Bug ID: 114069
Summary: Type punning RISC-V vectors causes ICE at -O1
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114061
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114057
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
--- Comment #3 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068
--- Comment #4 from Andrew Pinski ---
`-std=c++20 -O3 -mavx` is enough to reproduce the ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068
--- Comment #3 from Andrew Pinski ---
(In reply to Sam James from comment #2)
> Note that this is the second time we've seen the weird "double crash" w/
> x86_64_fallback_frame_state when unwinding, see
> https://gcc.gnu.org/bugzilla/show_bug.cg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068
--- Comment #2 from Sam James ---
Note that this is the second time we've seen the weird "double crash" w/
x86_64_fallback_frame_state when unwinding, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114048#c3 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068
--- Comment #1 from Sam James ---
Reducing now...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068
Bug ID: 114068
Summary: [14 regression] ICE when building darktable-4.6.1
(error: PHI node with wrong VUSE on edge from BB 25)
Product: gcc
Version: 14.0
Status: UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109668
--- Comment #4 from GCC Commits ---
The master branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:23f5da91ccb4927562ea4d1c245639bfd4a0088b
commit r14-9144-g23f5da91ccb4927562ea4d1c245639bfd4a0088b
Author: Palmer Dabbelt
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114067
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #2 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114067
--- Comment #1 from Jason Liam ---
That is, even if the type of `a` was complete the program would've been
ill-formed. So saying only that `A` is incomplete is the problem doesn't seem
right.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107270
Andrew Pinski changed:
What|Removed |Added
Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114067
Bug ID: 114067
Summary: GCC gives wrong diagnostic in the definition of a
static data member of same class type
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113950
Peter Bergner changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107270
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101737
pietro changed:
What|Removed |Added
CC||pietro.gcc at sociotechnical
dot x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59465
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=91161
--- Comment #14 from H.J. Lu ---
(In reply to Andrew Pinski from comment #13)
> I looked into the IR between GCC 12 and GCC 13 (with the added attributes),
> before sched2 there is no difference. So it would good to see what change
> "fixes" this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113749
--- Comment #3 from Samuel Thibault ---
I don't think it is a regression. We noticed it only recently in Debian only
because the configuration files got bogus. See for instance
https://buildd.debian.org/status/fetch.php?pkg=gcc-13&arch=hurd-i38
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104111
--- Comment #10 from W E Brown ---
(In reply to Eric Estievenart from comment #9)
Sorry, but I find neither "weirdness" nor "spooky"-ness in the comment #9 code
as shown. Rather, I believe it to be simply an example of a program that the
C++ s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114026
Rainer Orth changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114066
--- Comment #3 from Emilio López ---
Hi Andrew,
Thanks for the fast reply, I understand that some things are outside the spec,
but it'd be a great addition, if possible. The simplified test case you made
would definitely repro the error messag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114066
--- Comment #2 from Andrew Pinski ---
>anonymous structs
Which are a GNU extension to begin with ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114066
--- Comment #1 from Andrew Pinski ---
Simplified/corrected testcase:
```
struct swizzle4
{
swizzle4& operator = (const swizzle4& other);
};
struct
float4x4
{
struct {
swizzle4 _m00_m10_m20_m30;
};
};
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114066
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91161
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #13 from And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114066
Bug ID: 114066
Summary: Allow classes with constructors in anonymous struct
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91161
--- Comment #12 from Andrew Pinski ---
(In reply to Martin Liška from comment #8)
> Btw. one can't see it on master after r10--g7313607478c11e94.
But if you do:
```
[[gnu::noinline, noreturn]]
void
ni ()
```
You can reproduce it except it i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85640
--- Comment #14 from Andrew Pinski ---
Seems like it has been improved again for GCC 12.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971
Patrick O'Neill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113083
--- Comment #7 from Jakub Jelinek ---
As in:
2024-02-22 Jakub Jelinek
PR c++/113083
* cp-gimplify.cc (cp_fold): For targetm.cxx.cdtor_returns_this ()
wrap r into a COMPOUND_EXPR and return folded CALL_EXPR_ARG (x, 0).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113001
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Last recon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113083
--- Comment #6 from Jakub Jelinek ---
What about:
2024-02-22 Jakub Jelinek
PR c++/113083
* cp-gimplify.cc (cp_fold): For targetm.cxx.cdtor_returns_this ()
wrap r into a COMPOUND_EXPR and return folded CALL_EXPR_ARG (x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113749
Gaius Mulley changed:
What|Removed |Added
Last reconfirmed||2024-02-22
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804
Andrew Pinski changed:
What|Removed |Added
Known to work||13.2.1
Summary|[11/12/13 Reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804
--- Comment #14 from GCC Commits ---
The releases/gcc-13 branch has been updated by Andrew Pinski
:
https://gcc.gnu.org/g:a15427e75f2521ed5e467e3c5cb8446586bbdabb
commit r13-8354-ga15427e75f2521ed5e467e3c5cb8446586bbdabb
Author: Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114058
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-02-22
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109499
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109498
Andrew Pinski changed:
What|Removed |Added
Known to work||14.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
Bug ID: 114065
Summary: gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64
fails on 32bit archs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114064
Bug ID: 114064
Summary: [meta-bug] Use SVE instructions more for Advanced.
SIMD
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: meta-bug, missed-optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114063
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114063
Bug ID: 114063
Summary: Use IFN_CHECK_RAW_PTRS/IFN_CHECK_WAR_PTRS for
Advanced. SIMD
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimizati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114062
Andrew Pinski changed:
What|Removed |Added
Target||hppa-linux-gnu
--- Comment #1 from Andr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114062
Bug ID: 114062
Summary: "GNAT BUG DETECTED" 13.2.0 (hppa-linux-gnu) in remove,
at alloc-pool.h:437
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114058
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114061
--- Comment #4 from Tamar Christina ---
(In reply to Andrew Pinski from comment #3)
> Confirmed.
>
> Though maybe we should drop them in the vectorized version of the loop. HW
> prefetchers usually do a decent job and sometimes (maybe most) SW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456
--- Comment #4 from Jerry DeLisle ---
Created attachment 57504
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57504&action=edit
Proposed partial patch
Proposed patch for the original test case with a READ function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114061
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-02-22
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114061
--- Comment #2 from Tamar Christina ---
(In reply to Andrew Pinski from comment #1)
> I thought there was already one recorded about this.
I could only find https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103938 about an
ICE when prefetching a vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114061
--- Comment #1 from Andrew Pinski ---
I thought there was already one recorded about this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114060
--- Comment #2 from Rich Felker ---
How could there be such a contract? In order to call any other function, the
GOT address of the callee needs to be loaded, replacing the caller's value,
which must be spilled and reloaded if it's needed again
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114061
Bug ID: 114061
Summary: GCC fails vectorization when using __builtin_prefetch
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114060
--- Comment #1 from Andrew Pinski ---
https://github.com/mickael-guene/fdpic_doc/blob/master/abi.txt
>as there is no contract that this register permanently hold the GOT address
>for the executing code
So I am reading the GCC code, it looks l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113257
--- Comment #5 from Tamar Christina ---
(In reply to Sam James from comment #3)
> (In reply to Richard Earnshaw from comment #2)
> I'm missing why the combination then works though?
So we've made several changes here over time.
-mcpu=native do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #27 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:37127ed975e09813eaa2d1cf1062055fce45dd16
commit r14-9139-g37127ed975e09813eaa2d1cf1062055fce45dd16
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114060
Bug ID: 114060
Summary: asm constraints getting GOT address for ARM/FDPIC look
wrong
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114057
--- Comment #2 from Filip Kastl ---
Hm, seems like g:eb619490b01baa2f actually doesn't miscompare. My bad.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114057
--- Comment #1 from Filip Kastl ---
The oldest commit with this miscomparison i found so far is g:eb619490b01baa2f.
The most recent commit without the miscomparison i found so far is
g:405096f908e1ceb0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114054
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114042
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804
Andrew Pinski changed:
What|Removed |Added
Known to fail|14.0|
Summary|[11/12/13/14 Regres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804
--- Comment #12 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:1076ffda6ce5e6d5fc9577deaf8233e549e5787a
commit r14-9138-g1076ffda6ce5e6d5fc9577deaf8233e549e5787a
Author: Andrew Pinski
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104111
Eric Estievenart changed:
What|Removed |Added
CC||steve+gcc at tecwec dot eu
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111770
--- Comment #6 from Joseph S. Myers ---
X + 0. -> X is invalid for FP with signed zero or signaling NaN, and also gets
the wrong quantum exponent for decimal FP unless the zero has the maximum
possible quantum exponent (which is not what you get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114044
--- Comment #3 from Jakub Jelinek ---
Smaller testcase:
void
foo (void)
{
unsigned _BitInt(256) a = 3;
__builtin_clzg (a);
}
The thing is that in this testcase bitint lowering doesn't even know it should
do anything.
The whole behavior of t
me/mjires/built/master
--target=aarch64-linux-gnu --disable-bootstrap --enable-languages=c,c++,fortran
--disable-multilib --disable-libsanitizer --enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240222 (experimental) (GCC)
o --disable-multilib --disable-libsanitizer
--enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240222 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59465
--- Comment #6 from Marek Polacek ---
Started to be accepted with r0-110915-ga034826198b771:
https://gcc.gnu.org/pipermail/gcc-patches/2011-August/320236.html
which was supposed to be a cleanup, not a deliberate change to start accepting
the code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114057
Bug ID: 114057
Summary: [14 Regression] 435.gromacs fails verification on with
-Ofast -march=znver4 and PGO
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keyw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441
Tamar Christina changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|[14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970
--- Comment #4 from Iain Sandoe ---
Created attachment 57501
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57501&action=edit
without PCH
As Andrew says, the differences are in the debug info (it might even only be in
the order of the deb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970
--- Comment #3 from Iain Sandoe ---
Created attachment 57500
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57500&action=edit
with PCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #18 from Aldy Hernandez ---
(In reply to rguent...@suse.de from comment #17)
> On Wed, 21 Feb 2024, aldyh at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
> >
> > --- Comment #8 from Aldy Hernande
|--- |FIXED
--- Comment #2 from Maksim Shabunin ---
Verified with version riscv64-unknown-linux-gnu-g++ (g7d8585c0c0e) 14.0.1
20240222 (experimental) (branch master).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107270
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2024-02-22
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59465
--- Comment #5 from Marek Polacek ---
We accept the test because we do
else if (type_build_ctor_call (type)
|| (init && CLASS_TYPE_P (strip_array_types (type
{
if (TREE_CODE (type) == ARRAY_TYPE)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111076
Maksim Shabunin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112375
--- Comment #4 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:7d8585c0c0e5934780281abdee256ae6553e56e8
commit r14-9137-g7d8585c0c0e5934780281abdee256ae6553e56e8
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105898
--- Comment #4 from David Malcolm ---
I implemented this a different way, for memcpy, in r14-3556-g034d99e81484fb (by
special-casing it).
We don't yet check mempcpy, wmemcpy, or wmempcp; keeping bug open to handle
those.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114055
Gaius Mulley changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114055
--- Comment #3 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:c1667b1ef538e4da10cf83bdf1ae62d7bdd96128
commit r14-9136-gc1667b1ef538e4da10cf83bdf1ae62d7bdd96128
Author: Gaius Mulley
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #26 from Jakub Jelinek ---
(In reply to Peter Bergner from comment #25)
> CCing Mike and David for possible comments about the possible workarounds
> mentioned in Comment 23 and Comment 24.
Doing the workaround on the caller side is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114048
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114048
--- Comment #7 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:92c40297991f51e7fa942f29517bc4398fce33f9
commit r14-9135-g92c40297991f51e7fa942f29517bc4398fce33f9
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608
--- Comment #16 from GCC Commits ---
The releases/gcc-13 branch has been updated by Lewis Hyatt
:
https://gcc.gnu.org/g:0e438772e788244236045d75cd2be895e2ab4e08
commit r13-8353-g0e438772e788244236045d75cd2be895e2ab4e08
Author: Lewis Hyatt
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59465
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
Peter Bergner changed:
What|Removed |Added
CC||dje at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114040
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
--- Comment #7 from Jan Hubicka ---
> I see it doesn't do anything if mark_dfs_back_edges returns false, so it
> will claim the function is finite even when it calls a non-finite function?
> So I assume this is local analysis only and call edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #128 from John Paul Adrian Glaubitz ---
Created attachment 57498
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57498&action=edit
Build log including preprocessed source for building gcc-14 (20240221) natively
with LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #127 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #126)
> I'm retesting a native build with LRA enabled by default now and report back.
>
> If that works, I will try to build and boot a kerne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
--- Comment #6 from Richard Biener ---
(In reply to Jan Hubicka from comment #5)
> So if I understand it right, you want to determine the property that if the
> loop header is executed then BB containing undefined behavior at that
> iteration wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
--- Comment #5 from Iain Sandoe ---
The manual currently says:
-I dir
-iquote dir
-isystem dir
-idirafter dir
Add the directory dir to the list of directories to be searched for header
files dur- ing preprocessing. If dir begins with ‘=’ or $SY
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
--- Comment #5 from Jan Hubicka ---
So if I understand it right, you want to determine the property that if the
loop header is executed then BB containing undefined behavior at that iteration
will be executed, too.
modref tracks if function wil
1 - 100 of 205 matches
Mail list logo
