https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55527
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |11.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926
Bug 101926 depends on bug 55527, which changed state.
Bug 55527 Summary: Passing structures containing floats by value in calls are
underoptimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55527
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56040
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56030
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #6 from Andrew Pin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103538
Andrew Pinski changed:
What|Removed |Added
CC||gregnietsky at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56030
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |4.8.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39840
--- Comment #10 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #9)
> GCC has support turning on/off target specific extensions since at least GCC
> 5, maybe earlier. So closing as fixed.
I Mean on specific on a per function level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39840
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |5.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114347
--- Comment #11 from Andrew Pinski ---
(In reply to Paul Eggert from comment #10)
> (In reply to Jakub Jelinek from comment #6)
> > You can use -fexcess-precision=16 if you don't want treating _Float16 and
> > __bf16 as having excess precision.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28277
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|NEW
Last reconfirmed|2006-07-05 23:00:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396
--- Comment #8 from Robin Dapp ---
No fallout on x86 or aarch64.
Of course using false instead of TYPE_SIGN (utype) is also possible and maybe
clearer?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114316
François Dumont changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114347
--- Comment #10 from Paul Eggert ---
(In reply to Jakub Jelinek from comment #6)
> You can use -fexcess-precision=16 if you don't want treating _Float16 and
> __bf16 as having excess precision. With excess precision, I think the above
> behavio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77348
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77588
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WONTFIX
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393
--- Comment #5 from Andrew Pinski ---
Reduced testcase which shows this never worked:
```
template struct c1 {};
template
inline constexpr auto b_v = t;
template
using c1_t = c1>;
template
constexpr auto g(_Data __data) {
return c1_t<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393
Andrew Pinski changed:
What|Removed |Added
Keywords||c++-lambda
--- Comment #4 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105547
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114400
Bug ID: 114400
Summary: The resolution of LWG3950 seems incorrectly
implemented
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114399
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #4 from Andrew Pins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111918
Lewis Hyatt changed:
What|Removed |Added
Target Milestone|--- |14.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111918
--- Comment #7 from GCC Commits ---
The master branch has been updated by Lewis Hyatt :
https://gcc.gnu.org/g:44ba7bcb752a40ec7490dea53d3a472ce633371d
commit r14-9561-g44ba7bcb752a40ec7490dea53d3a472ce633371d
Author: Lewis Hyatt
Date: Wed N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114399
Patrick O'Neill changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #3 from Patrick O'N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114399
--- Comment #2 from Andrew Pinski ---
That is doing:
long long f __attribute__((packed,aligned(4)));
Will produce the same result between the 2 targets.
Likewise:
long long f __attribute__((packed,aligned(8)));
With -Wpadded you can se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114399
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114399
Bug ID: 114399
Summary: [14] RISC-V rv32i miscompile
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393
--- Comment #3 from Andrew Pinski ---
Reducing ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114390
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-03-19
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114390
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596
--- Comment #9 from Jakub Jelinek ---
BTW, just curious, r14-162 had:
/* Ensure that the header will have just the latch as a predecessor
inside the loop. */
- if (!single_pred_p (exit->dest))
+ if (!single_pred_p (non
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114392
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38658
Andrew Pinski changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64786
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114391
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114254
--- Comment #2 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:bf838884fac573b4902a21bb82d9b6f777e32cb9
commit r14-9559-gbf838884fac573b4902a21bb82d9b6f777e32cb9
Author: Martin Jambor
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802
--- Comment #9 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:bf838884fac573b4902a21bb82d9b6f777e32cb9
commit r14-9559-gbf838884fac573b4902a21bb82d9b6f777e32cb9
Author: Martin Jambor
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99829
--- Comment #8 from GCC Commits ---
The master branch has been updated by Vladimir Makarov :
https://gcc.gnu.org/g:9c91f8a88b2db50c8faf70786d3cef27b39ac9fc
commit r14-9557-g9c91f8a88b2db50c8faf70786d3cef27b39ac9fc
Author: Vladimir N. Makarov
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396
--- Comment #7 from Robin Dapp ---
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 4375ebdcb49..f8f7ba0ccc1 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -9454,7 +9454,7 @@ vect_peel_nonlinear_iv_init (gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113505
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113505
--- Comment #6 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:c87f1f3d660f4103c91c72a4d3e1d19ff2858671
commit r14-9555-gc87f1f3d660f4103c91c72a4d3e1d19ff2858671
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71258
--- Comment #6 from Andrew Pinski ---
(In reply to Phosit from comment #5)
> struct Base{
> virtual ~Base() = default;
> };
>
> int main(){
> delete new Base;
> return 0;
> }
>
> In this partial test case the destructor is not inlin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71258
Phosit changed:
What|Removed |Added
CC||phosit at autistici dot org
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114001
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114001
--- Comment #4 from GCC Commits ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:5b928badac560ad48e0e9fc480096ff396d9d9c6
commit r13-8468-g5b928badac560ad48e0e9fc480096ff396d9d9c6
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103715
--- Comment #9 from GCC Commits ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:9623e5dd70b0d8334ebe093459721d0d447ce4f2
commit r13-8467-g9623e5dd70b0d8334ebe093459721d0d447ce4f2
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114395
--- Comment #9 from Andrew Pinski ---
https://eel.is/c++draft/dcl.init.general#16.2 applies here I think. Which comes
before the `Parenthesized aggregates initialization` clause. But I could be
wrong.
https://github.com/cplusplus/papers/issues/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #64 from Jan Hubicka ---
> Are you going to apply this patch, even if it just helps partially with some
> tests and not others?
I think we should fix this completely, since it is source of very
suprising bugs. I discussed it with Ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114395
--- Comment #8 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #7)
> All of Clang, MSVC and EDG disagree with GCC though, so maybe there's a DR
> that we're missing.
Maybe https://cplusplus.github.io/CWG/issues/1467.html (again
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #13 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #12)
> Further simplified without any headers, -O1 works, -O2 fails.
For this testcase (at -O3), GCC 4.7.4 works but 4.8.1 fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59863
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
See Also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114348
--- Comment #5 from David Malcolm ---
Should be fixed on trunk for GCC 14 by the above patch. Keeping open to
backport.
(In reply to Tobias Specht from comment #2)
[...snip...]
> A workaround could be, to only parse the first line as json, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114348
--- Comment #4 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:0bf99b1b7eda2f4c34b9f56b895980ea1c261765
commit r14-9554-g0bf99b1b7eda2f4c34b9f56b895980ea1c261765
Author: David Malcolm
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114398
Bug ID: 114398
Summary: Unexpected storage error when "executing" return
statement.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
nux-gnu-as --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9532-20240318213256-g9eeca775367-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240319 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #12 from Jakub Jelinek ---
Further simplified without any headers, -O1 works, -O2 fails.
double a[2] = { 0.8147, 0.9058 };
double b[6] = { 0.1576, 0.9706, 1, 1, 1, 1 };
double c[16];
typedef double U __attribute__ ((vector_size(16),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107263
AK changed:
What|Removed |Added
CC||hiraditya at msn dot com
--- Comment #3 from AK -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59863
AK changed:
What|Removed |Added
CC||hiraditya at msn dot com
--- Comment #9 from AK --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114342
AK changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787
--- Comment #12 from avieira at gcc dot gnu.org ---
Sorry, missed that comment, thanks! I'll test backporting both.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106295
--- Comment #7 from Jerry DeLisle ---
I don't think that is a bad idea. I realize that this comes up often enough to
consider some solution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114395
--- Comment #7 from Jonathan Wakely ---
All of Clang, MSVC and EDG disagree with GCC though, so maybe there's a DR that
we're missing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787
--- Comment #11 from Andrew Pinski ---
(In reply to avieira from comment #10)
> First of all, apologies for this! I don't know why I didn't test this on
> x86_64 too, I usually do for such backports.
>
> Anyway I checked locally and backporting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114395
--- Comment #6 from Marek Polacek ---
Right, another design principle is that () should work where {} works, and
const B &b{a}; works. A(b) previously didn't work so it's not really changing
meaning. So not a bug IMHO.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787
--- Comment #10 from avieira at gcc dot gnu.org ---
First of all, apologies for this! I don't know why I didn't test this on x86_64
too, I usually do for such backports.
Anyway I checked locally and backporting:
r14-2821-gd1c072a1c3411a6fe29900
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114395
--- Comment #5 from Jonathan Wakely ---
I disagree, A(b) definitely changed meaning. It now initializes A by copying
the base part of b
This is a combination of aggregates being allowed to have base classes and
paren-init doing aggregate-init.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #63 from Jakub Jelinek ---
(In reply to Jan Hubicka from comment #58)
> Created attachment 57702 [details]
> Compare value ranges in jump functions
s/functoins/functions/
Are you going to apply this patch, even if it just helps par
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396
Patrick O'Neill changed:
What|Removed |Added
Target|x86_64-*-* riscv*-*-* |riscv*-*-* aarch64-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396
--- Comment #4 from Jonathan Wakely ---
$ ~/gcc/14/bin/aarch64-unknown-linux-gnu-gcc -O3 -fwrapv -fno-vect-cost-model
-fwrapv red.c -o red.out
$ ./red.out
decimal: 32693
hex: 7FB5
$ ~/gcc/14/bin/aarch64-unknown-linux-gnu-gcc red.c -o red.out
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396
--- Comment #3 from Robin Dapp ---
-O3 -mavx2 -fno-vect-cost-model -fwrapv seems to be sufficient.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396
Robin Dapp changed:
What|Removed |Added
Target|riscv*-*-* |x86_64-*-* riscv*-*-*
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175
--- Comment #39 from GCC Commits ---
The master branch has been updated by Edwin Lu :
https://gcc.gnu.org/g:60586710b0646efdbbd77a7f53b93fb5edb87a61
commit r14-9552-g60586710b0646efdbbd77a7f53b93fb5edb87a61
Author: Edwin Lu
Date: Mon Mar 18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112499
--- Comment #4 from Jakub Jelinek ---
Or consider
typedef unsigned __INTPTR_TYPE__ uintptr_t;
volatile int v;
int
foo (int x)
{
static uintptr_t a = ((char *)&&l2 - (char *)&&l1) + ((char *)&&l4 - (char
*)&&l3) + ((char *)&&l6 - (char *)&&l5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114395
--- Comment #4 from Andrew Pinski ---
(In reply to Marek Polacek from comment #3)
> Changed with r10-5137-g43aae289866f5e:
>
> commit 43aae289866f5ea55d187444520412554aa2e171
> Author: Marek Polacek
> Date: Tue Dec 3 15:59:40 2019 +
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91363
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114395
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105547
--- Comment #2 from Mikael Morin ---
Created attachment 57739
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57739&action=edit
Patch fixing the problem
This small patch fixes the problem.
Unfortunately allowing more errors seems counter-p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114395
--- Comment #2 from Andrew Pinski ---
Except this works with C++20+ for GCC:
```
struct A {
int a;
};
struct B : public A {};
void f(const A &a)
{
typedef const B & Btype;
Btype b(a);
}
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596
--- Comment #8 from Jakub Jelinek ---
Great,
--- gcc/tree-ssa-loop-ch.cc.jj 2024-03-19 16:27:35.969474787 +0100
+++ gcc/tree-ssa-loop-ch.cc 2024-03-19 17:12:57.904712489 +0100
@@ -957,7 +957,7 @@ ch_base::copy_headers (function *fun)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #5 from Martin Jambor ---
I'd like to ping this, are there plans to implement this in the near-ish term?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113832
--- Comment #3 from Filip Kastl ---
It seems that the benchmark runtime returned to normal for a while but then
went back to 6% slowdown.
Somewhere between these two commits the benchmark sped up
g:eb7a8f213d59e0cf
g:15d1dae0d4d1be88
And betwe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114395
Andrew Pinski changed:
What|Removed |Added
Summary|std::is_constructible_v |[c++20+]
|result of c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106295
--- Comment #6 from ghlixo at gmail dot com ---
One last comment about this issue.
I maintain and distribute a Fortran subroutine package to users. In my
experience, most of them are unaware that Fortran compilers evolve over time,
and that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
Iain Sandoe changed:
What|Removed |Added
Target Milestone|14.0|11.5
--- Comment #10 from Iain Sandoe --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114359
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |12.4
--- Comment #5 from Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #22 from Uroš Bizjak ---
Fixed also for TImode STV.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114359
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:07e03761a7fc1626a6a74ed957e117f56981558c
commit r14-9551-g07e03761a7fc1626a6a74ed957e117f56981558c
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101228
--- Comment #17 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:c608b57f77a47179899666940c3b8b6a2e5435b2
commit r14-9550-gc608b57f77a47179899666940c3b8b6a2e5435b2
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #21 from GCC Commits ---
The releases/gcc-12 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:f6ed0466d40de496b14225fae44acf618dac1fd2
commit r12-10284-gf6ed0466d40de496b14225fae44acf618dac1fd2
Author: Uros Bizjak
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #20 from GCC Commits ---
The releases/gcc-13 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:1a6d04fce7d78b9e5201333be0c0877390f81bc3
commit r13-8466-g1a6d04fce7d78b9e5201333be0c0877390f81bc3
Author: Uros Bizjak
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596
--- Comment #6 from Jan Hubicka ---
On this testcase trunk does get same dump as gcc13 for pass just before ch2
with ch2 we get:
@@ -192,9 +236,8 @@
# DEBUG BEGIN_STMT
goto ; [100.00%]
- [local count: 954449105]:
+ [local count: 9544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596
--- Comment #5 from Jakub Jelinek ---
(In reply to Jan Hubicka from comment #4)
> The change makes loop iteration estimates more realistics, but does not
> introduce any new code that actually changes the IL, so it seems this makes
> existing pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396
--- Comment #1 from Patrick O'Neill ---
Here's the result when running with -fwrapv on rv64gcv at O2:
> /scratch/tc-testing/tc-mar-18/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
> -march=rv64gcv -O2 red.c -o red.out -fwrapv
> /scratch/tc-t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396
Bug ID: 114396
Summary: [14] RISC-V rv64gcv vector: Runtime mismatch at -O3
with -fwrapv
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113505
--- Comment #5 from David Malcolm ---
Thanks, am testing your patch now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596
--- Comment #4 from Jan Hubicka ---
The change makes loop iteration estimates more realistics, but does not
introduce any new code that actually changes the IL, so it seems this makes
existing problem more visible. I will try to debug what happ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653
Thomas Schwinge changed:
What|Removed |Added
CC||tschwinge at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596
--- Comment #3 from Jakub Jelinek ---
Loooking at pr90716.c, that case seems like a clear wrong-debug.
Before r14-162 j was everywhere, "j\0" DW_TAG_variable didn't
have any DW_AT_location/DW_AT_const_value, optimized dump doesn't show any
DEBU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114367
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:16afbd9c9c4282d56062cef95e6eccfdcf3efe03
commit r14-9545-g16afbd9c9c4282d56062cef95e6eccfdcf3efe03
Author: Jonathan Wakely
Date:
1 - 100 of 179 matches
Mail list logo
