https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106423
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106024
Andrew Pinski changed:
What|Removed |Added
CC||amir.ahmed.ansari at outlook
dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106351
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106554
Richard Biener changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106559
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106560
--- Comment #6 from Richard Biener ---
(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 a/gcc/gimplify.cc b/gcc/gimplify.cc
> index f0fbdb48012..d9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106563
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.2
Priority|P3
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
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.
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=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=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 tr
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=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=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 S
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 #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=106570
Bug ID: 106570
Summary: DCE sometimes fails with depending if statements
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
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
Assi
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=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=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=106523
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #2
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 A
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
Date
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=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
> 4f15d2234608e82159d030dadb17af678cf
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 #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 fr
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=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 #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.
COLLECT_G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
Martin Liška changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
Summ
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=106570
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-08-09
Status|UNCONFIRME
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
--- Comment
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
--- 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). Seem
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 (or
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 #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
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
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=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=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 f
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 #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 a
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 kno
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 co
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 co
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 32
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
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106572
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
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=106554
Eric Botcazou changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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 sho
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 sho
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=106565
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
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=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=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=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=105360
Iain Buclaw changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
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=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
Resolution|--- |DUPLICATE
Status|UNCONFIRME
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=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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=db8
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 ha
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, kargl
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:
>
> http
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 -fexternal-b
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 -fexternal-
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 a/gcc/g
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 a
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 A
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 A
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 Au
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=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
tim
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=106566
Tobias Burnus changed:
What|Removed |Added
Keywords||accepts-invalid
Summary|[Ope
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=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 st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77876
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|mpolacek at gcc d
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=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
> unable
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=106338
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
Severit
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
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
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=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
Pr
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
--- 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 #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=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: T
1 - 100 of 110 matches
Mail list logo
