https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #38 from Kewen Lin ---
Created attachment 53428
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53428=edit
untested patch
A untested patch which can make it pass.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #37 from Kewen Lin ---
(In reply to Andrew Pinski from comment #36)
> You might need to do -O2 -fPIE -pie to reproduce the issue as debian is
> configured with --enable-default-pie
Thanks for the hint! I can reproduce this but it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472
--- Comment #14 from Petr Sumbera ---
Sorry for late response. Unfortunatelly above patch dosen't make any
difference. The problem is still there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101839
--- Comment #8 from Xionghu Luo (luoxhu at gcc dot gnu.org) ---
The relationship is:
A A::type
|
| |
BA BA::type CACA::type
|
CBA CBA::type
class CA and CBA are final, also function CA::type and BA::type are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106575
Bug ID: 106575
Summary: new test case gcc.dg/fold-eqandshift-4.c fails
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106338
--- Comment #6 from Kito Cheng ---
My understanding is static chain is sort of compiler internal implementation,
any register could be picked if that is not used for passing argument, so I
would also prefer keep that out psABI spec for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106573
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106573
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:bddd8d86e3036e480158ba9219ee3f290ba652ce
commit r13-2007-gbddd8d86e3036e480158ba9219ee3f290ba652ce
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574
--- Comment #3 from Michael Hudson-Doyle
---
Certainly this could be "handled" by bumping the tolerance I guess. Not sure
how to tell if that is appropriate though...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574
--- Comment #2 from Andrew Pinski ---
this is just 2 ulp difference ...
This could be constant folding difference between GCC and what is done for
_Float128 in the software. Which could mean this is a not a bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574
--- Comment #1 from Michael Hudson-Doyle
---
oops forgot the link to my glibc bug
https://sourceware.org/bugzilla/show_bug.cgi?id=29463
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574
Bug ID: 106574
Summary: gcc 12 with O3 leads to failures in glibc's y1f128
tests
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106338
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106573
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106207
--- Comment #2 from Marek Polacek ---
Reduced:
#define FOO(no) \
void f_##no() \
{ \
int gen_##no(); \
}
#define GEN_FOO \
FOO(f##1) \
FOO(f##2)
GEN_FOO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106573
Bug ID: 106573
Summary: Missing -Wanalyzer-use-of-uninitialized-value on calls
handled by state machines
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106338
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102765
--- Comment #6 from Iain Buclaw ---
r13-2002 (and r12-8673) is a start that sows the seeds to make the codegen
option -fno-weak-templates the default. Should just be a case of extending the
forced emission to all instantiations too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104317
--- Comment #3 from Iain Buclaw ---
(In reply to Siarhei Siamashka from comment #2)
> I first tried to toggle "flag_weak_templates" in "gcc/d/lang.opt" from 1 to
> 0 in GDC11 instead of reverting PR99914, but the resulting toolchain was
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101421
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77876
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|mpolacek at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106569
--- Comment #4 from David Binderman ---
(In reply to Martin Liška from comment #3)
> > My best guess is that if gcc trunk is written in some recent version of C++,
> > then all that recent version can be used.
>
> We are written in C++11, is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65372
Nick Desaulniers changed:
What|Removed |Added
CC||ndesaulniers at google dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106566
Tobias Burnus changed:
What|Removed |Added
Keywords||accepts-invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106569
--- Comment #3 from Martin Liška ---
> My best guess is that if gcc trunk is written in some recent version of C++,
> then all that recent version can be used.
We are written in C++11, is std::find_if available in the given standard?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106565
--- Comment #9 from Quanhua Liu ---
Hi Richard,
It seems that I cannot add comment online to the ticket.
I tried
gfortran -o z -O3 -march=native test_matrixCal.f90 -fexternal-blas
-lblas -fdump-tree-optimized
time a.out 1
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81159
Marek Polacek changed:
What|Removed |Added
Keywords||patch
--- Comment #8 from Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98954
--- Comment #6 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:6fc14f1963dfefead588a4cd8902d641ed69255c
commit r13-2005-g6fc14f1963dfefead588a4cd8902d641ed69255c
Author: Roger Sayle
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21137
--- Comment #13 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:6fc14f1963dfefead588a4cd8902d641ed69255c
commit r13-2005-g6fc14f1963dfefead588a4cd8902d641ed69255c
Author: Roger Sayle
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94026
--- Comment #14 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:6fc14f1963dfefead588a4cd8902d641ed69255c
commit r13-2005-g6fc14f1963dfefead588a4cd8902d641ed69255c
Author: Roger Sayle
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106565
--- Comment #8 from Steve Kargl ---
On Tue, Aug 09, 2022 at 05:51:51PM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106565
>
> --- Comment #6 from Steve Kargl ---
> On Tue, Aug 09, 2022
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106560
--- Comment #7 from Andrew Pinski ---
(In reply to Richard Biener from comment #6)
> (In reply to Andrew Pinski from comment #3)
> > Here is the simple fix, I will submit it this weekend.
> > [apinski@xeond2 gcc]$ git diff
> > diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106565
--- Comment #7 from Steve Kargl ---
On Tue, Aug 09, 2022 at 05:17:57PM +, quanhua.liu at noaa dot gov wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106565
>
> --- Comment #5 from Quanhua Liu ---
> Hi Richard,
>
> Using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106565
--- Comment #6 from Steve Kargl ---
On Tue, Aug 09, 2022 at 05:14:16PM +, quanhua.liu at noaa dot gov wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106565
>
> --- Comment #4 from Quanhua Liu ---
> Using
> gfortran -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106571
--- Comment #3 from Andrew Pinski ---
(In reply to Boris from comment #2)
> How can you check a mismatch if only the definition has the section
> attribute?
You don't need to.
>
> Here's the kernel commit which fixes this for clang:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106565
--- Comment #5 from Quanhua Liu ---
Hi Richard,
Using -fexternal-blas for gfortran v10.3.0 is much slower than
the method 2:
BB = transpose(B)
C = matmul(A, BB)
How about on your machine?
Thanks,
Quanhua Liu
On 8/9/2022 11:07 AM,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106565
--- Comment #4 from Quanhua Liu ---
Using
gfortran -O3 -fexternal-blas -L/. -lblas testmatrixCal.f90
time a.out 1
real: 6.14 (s)
time a.out 2
real: 5.41
It is 6 times slower than
BB = transpose(B)
C = matmul(A, BB)
ifort doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106571
--- Comment #2 from Boris ---
How can you check a mismatch if only the definition has the section attribute?
Here's the kernel commit which fixes this for clang:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106571
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-08-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105360
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89139
Andrew Pinski changed:
What|Removed |Added
CC||witold.baryluk+gcc at gmail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105360
Andrew Pinski changed:
What|Removed |Added
Assignee|ibuclaw at gdcproject dot org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105360
Iain Buclaw changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105360
--- Comment #2 from Iain Buclaw ---
Looks like it's a middle-end missed-optimization, not a D front-end one.
https://godbolt.org/z/5WWYEG4jW
Perhaps we need an extra DCE pass?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #36 from Andrew Pinski ---
You might need to do -O2 -fPIE -pie to reproduce the issue as debian is
configured with --enable-default-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106572
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> >which blows up the command line for the compilation.
>
> You can use a response file and that won't blow up the command line at all.
>
> That is:
> g++ -Q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106572
--- Comment #5 from Andrew Pinski ---
>which blows up the command line for the compilation.
You can use a response file and that won't blow up the command line at all.
That is:
g++ -Q --help=warnings | tail -n +2 | awk '{print $1}' | tr '\n'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106565
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106565
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106572
--- Comment #4 from Jayesh Badwaik ---
I don't think any of the previous bug reports address the requirements that
this bug report does. This is not about production runs, this is about
development workflow. Unless the position is that users
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106572
--- Comment #3 from Jayesh Badwaik ---
I don't think any of the previous bug reports address the requirements that
this bug report does. This is not about production runs, this is about
development workflow. Unless the position is that users
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106554
Eric Botcazou changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106572
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106572
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106572
Bug ID: 106572
Summary: A programmatic list of all possible compiler warnings
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106443
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Gaius Mulley ---
> I've pushed a fix to devel/modula2 to fix multilib install (seen on amd64).
> It
> now builds and installs multilib. Prior to this fix the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457
--- Comment #9 from qinzhao at gcc dot gnu.org ---
one more testing case failed with the current array_at_struct_end_p
is:gcc/testsuite/gcc.dg/torture/pr50067-2.c:
1 /* { dg-do run } */
2
3 /* Make sure data-dependence analysis does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457
--- Comment #8 from qinzhao at gcc dot gnu.org ---
another testing case failed with the current array_at_struct_end_p is:
gcc/testsuite/gcc.dg/torture/pr50067-1.c:
1 /* { dg-do run } */
2
3 /* Make sure data-dependence analysis does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106569
--- Comment #2 from David Binderman ---
(In reply to Richard Biener from comment #1)
> I find those less obvious, for example does std::any_of guarantee some
> evaluation order?
I also find any_of less obvious, but that's because my working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #35 from Mathieu Malaterre ---
(In reply to Mathieu Malaterre from comment #33)
> (In reply to Kewen Lin from comment #32)
> > (In reply to Mathieu Malaterre from comment #30)
> > > (In reply to Martin Liška from comment #29)
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106565
--- Comment #2 from Quanhua Liu ---
I modified the application code (see below) and use the "method" as a control
variable from command line.
I use the same code for both gfortran 10.3.0 and ifort 19.0.5.281
gfortran -O3 matrixCal.f90
time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #34 from Mathieu Malaterre ---
(In reply to Mathieu Malaterre from comment #33)
> (In reply to Kewen Lin from comment #32)
> > (In reply to Mathieu Malaterre from comment #30)
> > > (In reply to Martin Liška from comment #29)
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #33 from Mathieu Malaterre ---
(In reply to Kewen Lin from comment #32)
> (In reply to Mathieu Malaterre from comment #30)
> > (In reply to Martin Liška from comment #29)
> > > (In reply to Kewen Lin from comment #28)
> > > > Sorry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106569
--- Comment #1 from Richard Biener ---
I find those less obvious, for example does std::any_of guarantee some
evaluation order?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106570
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #32 from Kewen Lin ---
(In reply to Mathieu Malaterre from comment #30)
> (In reply to Martin Liška from comment #29)
> > (In reply to Kewen Lin from comment #28)
> > > Sorry for the breakage, I'll have a look tomorrow.
> > >
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #31 from Mathieu Malaterre ---
(In reply to Mathieu Malaterre from comment #30)
> (In reply to Martin Liška from comment #29)
> > (In reply to Kewen Lin from comment #28)
> > > Sorry for the breakage, I'll have a look tomorrow.
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #30 from Mathieu Malaterre ---
(In reply to Martin Liška from comment #29)
> (In reply to Kewen Lin from comment #28)
> > Sorry for the breakage, I'll have a look tomorrow.
> >
> > btw, is it able to reproduce the issue on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #29 from Martin Liška ---
(In reply to Kewen Lin from comment #28)
> Sorry for the breakage, I'll have a look tomorrow.
>
> btw, is it able to reproduce the issue on ppc64 (or ppc64le) as well?
No for gcc112 machine (ppc64le).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106570
--- Comment #2 from Andrew Macleod ---
I think this is a duplicate of PR106379 . At the VRP2 stage I see:
[local count: 1073741824]:
if (c_6(D) == s_7(D))
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 365072224]:
_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106570
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-08-09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #27 from Martin Liška ---
Crashes also w/ -fno-strict-aliasing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
Martin Liška changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #25 from Mathieu Malaterre ---
(In reply to Martin Liška from comment #24)
> > sid64 % g++ *.cc -O2 -m32 && ./a.out
>
> Please provide output with --verbose.
% g++ --verbose *.cc -O2 -m32 && ./a.out
Using built-in specs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106524
Martin Liška changed:
What|Removed |Added
Summary|[12/13 Regression] ICE in |[12/13 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #24 from Martin Liška ---
> sid64 % g++ *.cc -O2 -m32 && ./a.out
Please provide output with --verbose.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #23 from Mathieu Malaterre ---
Nevermind; I can reproduce the issue with a sid/amd64 chroot:
stable64 % schroot -c sid64
sid64 % g++ --version
g++ (Debian 12.1.0-7) 12.1.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #22 from Uroš Bizjak ---
(In reply to Martin Liška from comment #20)
> Hmm, can't reproduce with x86_64 compiler with -m32:
>
> $ g++ --version
> g++ (SUSE Linux) 12.1.1 20220721 [revision
> 4f15d2234608e82159d030dadb17af678cfad626
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #21 from Mathieu Malaterre ---
(In reply to Martin Liška from comment #20)
> Hmm, can't reproduce with x86_64 compiler with -m32:
>
> $ g++ --version
> g++ (SUSE Linux) 12.1.1 20220721 [revision
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106563
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106563
--- Comment #3 from CVS Commits ---
The releases/gcc-12 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:79a86a608691621659b3ce3a24a72aeea4054668
commit r12-8673-g79a86a608691621659b3ce3a24a72aeea4054668
Author: Iain Buclaw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106563
--- Comment #2 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:04284176d549ff2565406406a6d53ab4ba8e507d
commit r13-2002-g04284176d549ff2565406406a6d53ab4ba8e507d
Author: Iain Buclaw
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106523
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #20 from Martin Liška ---
Hmm, can't reproduce with x86_64 compiler with -m32:
$ g++ --version
g++ (SUSE Linux) 12.1.1 20220721 [revision
4f15d2234608e82159d030dadb17af678cfad626
...
$ g++ *.cc -O2 -m32 && ./a.out && echo Ok
Ok
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-08-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106426
--- Comment #3 from Tom Honermann ---
I believe this issue can be resolved as fixed via commit
053876cdbe8057210e6f4da4eec2df58f92ccd4c for the gcc 13 release.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106571
Bug ID: 106571
Summary: Implement -Wsection diag
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106570
Bug ID: 106570
Summary: DCE sometimes fails with depending if statements
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106514
--- Comment #7 from Richard Biener ---
For the testcase m_imports is so big because we have
...
[local count: 1073741824]:
# c_1198 = PHI
_599 = MEM[(unsigned int *)b_1201(D) + 2792B];
d_2401 = _599 + d_2399;
if (d_2399 > d_2401)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103498
--- Comment #2 from Segher Boessenkool ---
Mike, do you still see this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106514
--- Comment #6 from Richard Biener ---
So one now needs to bump the limit to 60 to get enough samples for perf. Then
we now see
Samples: 55K of event 'cycles:u', Event count (approx.): 49013411833
Overhead Samples Command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106514
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:409978d58dafa689c5b3f85013e2786526160f2c
commit r13-1998-g409978d58dafa689c5b3f85013e2786526160f2c
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106567
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #21 from Richard Biener ---
Try -fsanitize=unreachable - when reordering BBs makes crashes appear/disappear
the most likely culprit is we run into a path deemed unreachable which means we
fall through to random code.
You can also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #19 from Mathieu Malaterre ---
Without hwy dependency:
% more Makefile bytes.cc demo.cc
::
Makefile
::
CXXFLAGS := -O2
demo: demo.o bytes.o
$(CXX) $(CXXFLAGS) -o $@ $^
clean:
rm -f bytes.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106565
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2022-08-09
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106551
--- Comment #2 from Immad Mir ---
Sergei Trofimovich: Thanks for bringing the issue to our attention.
Dave: I've sent a patch via gcc-patches.
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Static analyser cppcheck can produce these style messages for gcc trunk source
code:
$ fgrep useStlAlgorithm cppcheck.20220809.out
trunk.git/gcc/analyzer/call-string.cc
1 - 100 of 111 matches
Mail list logo
