https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100224
--- Comment #2 from Zhao Chun ---
(In reply to Richard Biener from comment #1)
> You are accessing 'double' via a pointer to uint64_t * here:
>
> k = *((uint64_t*)data);
>
> that violates type based aliasing rules. You can use -fno-st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98301
Andre Vehreschild changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100178
--- Comment #3 from GengQi ---
Thanks for your replies, I have taken enough information from them.
I hope this is made clear in the documentation soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100225
Bug ID: 100225
Summary: [8/9/10/11/12 Regression] ICE in
add_cross_iteration_register_deps, at ddg.c:291
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100226
Bug ID: 100226
Summary: [11/12 Regression] c++/11/bits/stl_tree.h:770:8:
error: static assertion failed: comparison object must
be invocable as const
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100226
--- Comment #1 from Martin Liška ---
Created attachment 50656
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50656&action=edit
test-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100226
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100224
--- Comment #3 from Richard Biener ---
(In reply to Zhao Chun from comment #2)
> (In reply to Richard Biener from comment #1)
> > You are accessing 'double' via a pointer to uint64_t * here:
> >
> > k = *((uint64_t*)data);
> >
> > that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100226
Richard Biener changed:
What|Removed |Added
Known to work||10.3.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100225
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99971
--- Comment #8 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:700e542971251b11623cce877075567815f72965
commit r12-79-g700e542971251b11623cce877075567815f72965
Author: Richard Biener
Date: Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99971
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #12 from Jakub Jelinek ---
They do. Though, in the combined patch I'm still a little bit worried about
the first 4 modified peephole2s, the last 4 look good to me.
The last 4 are where the original insn did a normal DFmode store and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #13 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #12)
> They do. Though, in the combined patch I'm still a little bit worried about
> the first 4 modified peephole2s, the last 4 look good to me.
> The last 4 are wher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #14 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #13)
> DFmode loads and stores *are* atomic, this is what the optimization is based
> on.
Loads and stores to/from x87 and SSE registers, to be clear.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #15 from Jakub Jelinek ---
Yes, but do they preserve all the bits and never modify any bit patterns,
including qNaNs and sNaNs? I thought the point of using the fistp was that it
preserves everything.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100227
Bug ID: 100227
Summary: write with implicit loop
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #16 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #15)
> Yes, but do they preserve all the bits and never modify any bit patterns,
> including qNaNs and sNaNs? I thought the point of using the fistp was that
> it pres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100174
--- Comment #2 from LinoPeng <608410104 at alum dot ccu.edu.tw> ---
Hi Andrew Pinski,
I am new here. I am sorry if I had offended you.
Float a = 0.. It 23 fraction bits is "01010101010011001001100".
I trace gcc-9.2.0 source code from real.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #17 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #16)
> (In reply to Jakub Jelinek from comment #15)
> > Yes, but do they preserve all the bits and never modify any bit patterns,
> > including qNaNs and sNaNs? I though
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Summary|[10.3, 11, 12 Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #2 from Jakub Jelinek ---
Created attachment 50658
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50658&action=edit
gcc11-pr100217.patch
Untested fix. IMHO when we have a hard reg in the inline asm, we just need to
honor it,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100223
--- Comment #1 from Jonathan Wakely ---
Arguably, the caller can do this check if they think it can occur in their
code. That way all calls to the algorithm don't pay for the check.
But it's probably cheap enough to check anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100226
--- Comment #3 from Jonathan Wakely ---
The static assert was added intentionally, the comparison function used with
the container must have a const-qualified operator().
I would check that in the nurses code first.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #18 from Jakub Jelinek ---
Indeed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100228
Bug ID: 100228
Summary: repeated std::atomic::load() misoptimized by
x87 peephole
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100226
--- Comment #4 from Jonathan Wakely ---
The template argument '_Compare = paircmp' shows the type user as the
comparison object.
So paircmp::operator() needs to be const.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100226
Martin Liška changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #31 from Iain Sandoe ---
(In reply to Richard Biener from comment #30)
> (In reply to Iain Sandoe from comment #29)
> > what is also somewhat peculiar is that replacing the first function in the
> > reduced test case with "extern voi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932
--- Comment #2 from Tom de Vries ---
Minimal example:
...
$ cat libgomp/testsuite/libgomp.oacc-c-c++-common/parallel-dims.c
int
main (void)
{
int vectors_max = -1;
#pragma acc parallel \
num_gangs (1) \
num_workers (1) \
vector_length (32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100226
--- Comment #6 from Jonathan Wakely ---
Bug 89370 would really help simplify this diagnostic.
The last three lines would be:
.../src/NCPkgFilterPattern.cc:343:28: required from here
/usr/include/c++/11/bits/stl_tree.h:770:8: error: static as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100179
--- Comment #6 from Christophe Lyon ---
Yes, I confirm it's now fixed, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #19 from Jakub Jelinek ---
Perhaps best would be to try to construct a testcase for each of the peephole2s
and try some bit pattern that isn't preserved through the FPU except for
fistp/fildp and see what enabling/disabling each of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100227
Mathieu changed:
What|Removed |Added
Known to work||6.3.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100228
--- Comment #1 from Jonathan Wakely ---
Is this the same cause as bug 100182?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100179
--- Comment #7 from Jonathan Wakely ---
Great, thanks for report, so that this could be fixed for gcc-11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100228
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Resolu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
Jakub Jelinek changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99971
--- Comment #10 from andysem at mail dot ru ---
Thanks. Will this be backported to 10 and 11 branches?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100223
--- Comment #2 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #1)
> Arguably, the caller can do this check if they think it can occur in their
> code. That way all calls to the algorithm don't pay for the check.
>
> But it's probably ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #32 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #31)
> (In reply to Richard Biener from comment #30)
> > (In reply to Iain Sandoe from comment #29)
> > > what is also somewhat peculiar is that replacing the first funct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
Richard Biener changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #34 from Richard Biener ---
(In reply to Richard Biener from comment #33)
> (In reply to Iain Sandoe from comment #32)
> > (In reply to Iain Sandoe from comment #31)
> > > (In reply to Richard Biener from comment #30)
> > > > (In rep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99971
--- Comment #11 from rguenther at suse dot de ---
On Fri, 23 Apr 2021, andysem at mail dot ru wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99971
>
> --- Comment #10 from andysem at mail dot ru ---
> Thanks. Will this be backported to 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #35 from Richard Biener ---
Which means another possible candidate for the "bug" is darwin_binds_local_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #36 from Iain Sandoe ---
(In reply to Richard Biener from comment #35)
> Which means another possible candidate for the "bug" is darwin_binds_local_p
yeah... see below.
> > > .. but something similar must apply to PLT and targets w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99726
--- Comment #8 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Sandiford
:
https://gcc.gnu.org/g:7e2db68a77fb211898a024c5a7ad7c4449c7e355
commit r10-9749-g7e2db68a77fb211898a024c5a7ad7c4449c7e355
Author: Richard Sand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98268
--- Comment #11 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Sandiford
:
https://gcc.gnu.org/g:18a190c3ee32548de3888b7a64f701999893727b
commit r10-9750-g18a190c3ee32548de3888b7a64f701999893727b
Author: Richard San
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726
--- Comment #13 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Sandiford
:
https://gcc.gnu.org/g:8849e4a94550ffc9a564c105f0cefed5f42b3a7d
commit r10-9752-g8849e4a94550ffc9a564c105f0cefed5f42b3a7d
Author: Richard Bie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98136
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Sandiford
:
https://gcc.gnu.org/g:63da018de828b4792e95d1431118fd10efef87d1
commit r10-9751-g63da018de828b4792e95d1431118fd10efef87d1
Author: Richard Sand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726
--- Comment #14 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Sandiford
:
https://gcc.gnu.org/g:dc9233a4f65a67ca280903d60d57c5fd5d95303e
commit r10-9753-gdc9233a4f65a67ca280903d60d57c5fd5d95303e
Author: Richard San
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97141
--- Comment #8 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Sandiford
:
https://gcc.gnu.org/g:dc9233a4f65a67ca280903d60d57c5fd5d95303e
commit r10-9753-gdc9233a4f65a67ca280903d60d57c5fd5d95303e
Author: Richard Sand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99249
--- Comment #5 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Sandiford
:
https://gcc.gnu.org/g:690aa217cf2882e58a0572171a3dd8e346f616cf
commit r10-9754-g690aa217cf2882e58a0572171a3dd8e346f616cf
Author: Richard Sand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99726
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolutio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98268
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100227
Richard Biener changed:
What|Removed |Added
Summary|write with implicit loop|[8/9/10/11/12 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100222
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97141
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
Uroš Bizjak changed:
What|Removed |Added
Attachment #50649|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98069
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|8.5 |10.4
--- Comment #7 from r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97960
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolutio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98069
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95396
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolutio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98069
--- Comment #9 from rsandifo at gcc dot gnu.org
---
*** Bug 95396 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100229
Bug ID: 100229
Summary: arm: UB in arm_block_set_aligned_non_vect (shift
exponent 32 is too large for 32-bit type)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100214
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2021-04-23
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98297
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100216
Richard Earnshaw changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100230
Bug ID: 100230
Summary: ASan: alloc-dealloc-mismatch in early-remat.c
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100230
Alex Coplan changed:
What|Removed |Added
Last reconfirmed||2021-04-23
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100230
--- Comment #1 from Alex Coplan ---
Testing a fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100225
Alexander Monakov changed:
What|Removed |Added
Blocks|85099 |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99488
--- Comment #12 from YunQiang Su ---
This problem disappears if we build gcc 11 with binutils 2.36.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100225
--- Comment #2 from Martin Liška ---
Ah, you are right, sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100227
Dominique d'Humieres changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
Ilya Leoshkevich changed:
What|Removed |Added
CC||iii at linux dot ibm.com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #4 from Jakub Jelinek ---
That seems like quite undesirable API change.
Can't the backend when it sees long double register vars for the fN registers
change the mode from TFmode to that new FPRX2mode, so that old code keeps
working?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100222
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:500305a92ef85e6b87ad428a35221c62f4037b93
commit r12-82-g500305a92ef85e6b87ad428a35221c62f4037b93
Author: Richard Biener
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100222
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100225
Alex Coplan changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #37 from Richard Biener ---
Oh, and FYI a cc1 cross from x86_64 to x86_64-apple-darwin19.6.0 doesn't seem
to reproduce the issue with the reduced testcase (I seee no call to
___UTF_8_put remaining with -O3 -fPIC -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #5 from Ilya Leoshkevich ---
That would be an ideal solution, but I wonder how to implement it? Suppose we
find a way to convince expand to pick FPRX2mode for such a long double. What if
the following comes up?
register long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #6 from Jakub Jelinek ---
(In reply to Ilya Leoshkevich from comment #5)
> That would be an ideal solution, but I wonder how to implement it? Suppose
> we find a way to convince expand to pick FPRX2mode for such a long double.
> What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #7 from Jakub Jelinek ---
That said, I'm afraid I don't really understand what wrong happens with the
patch I've attached.
Trying something like:
long double
foo (void)
{
register long double f0 asm ("f0");
f0 = 1.0L;
f0 += 127
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99748
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Alex Coplan
:
https://gcc.gnu.org/g:283367662c25057fd7c9c98257cca858f85b75fc
commit r10-9755-g283367662c25057fd7c9c98257cca858f85b75fc
Author: Alex Coplan
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99748
Alex Coplan changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98297
--- Comment #6 from Jakub Jelinek ---
Ah, tracked already in PR98358.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558
Jakub Jelinek changed:
What|Removed |Added
Priority|P1 |P2
--- Comment #31 from Jakub Jelinek -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #8 from Ilya Leoshkevich ---
Yeah, inline asm seems to be problematic:
/home/iii/gcc/build/gcc/xgcc -B/home/iii/gcc/build/gcc/
/home/iii/gcc/gcc/testsuite/gcc.target/s390/vector/long-double-asm-hardreg.c
-fdiagnostics-plain-outpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99402
--- Comment #13 from François Dumont ---
Fixed on gcc-10 branch by this commit
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ab83ce42ea0b2fbc09d51b7bd5e69905dcaa2041.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #38 from Iain Sandoe ---
(In reply to Richard Biener from comment #37)
> Oh, and FYI a cc1 cross from x86_64 to x86_64-apple-darwin19.6.0 doesn't seem
> to reproduce the issue with the reduced testcase (I seee no call to
> ___UTF_8_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100210
Jakub Jelinek changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99362
Jakub Jelinek changed:
What|Removed |Added
CC||georg.schwab at emocean dot io
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98767
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:87fc34a461cf362947a430d8a241f653fd83bc7b
commit r12-86-g87fc34a461cf362947a430d8a241f653fd83bc7b
Author: Patrick Palka
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932
--- Comment #3 from Tom de Vries ---
Created attachment 50660
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50660&action=edit
Cuda reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100231
Bug ID: 100231
Summary: [C++17] Variable template specialization inside a
class gives compilation error
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #39 from Richard Biener ---
(In reply to Iain Sandoe from comment #38)
> (In reply to Richard Biener from comment #37)
> > Oh, and FYI a cc1 cross from x86_64 to x86_64-apple-darwin19.6.0 doesn't
> > seem
> > to reproduce the issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100180
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:0e1e7b77904f1fe2a6dbfe84bb4fc026584ba480
commit r12-89-g0e1e7b77904f1fe2a6dbfe84bb4fc026584ba480
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #40 from Richard Biener ---
(In reply to Richard Biener from comment #39)
> (In reply to Iain Sandoe from comment #38)
> > (In reply to Richard Biener from comment #37)
> > > Oh, and FYI a cc1 cross from x86_64 to x86_64-apple-darwin
1 - 100 of 166 matches
Mail list logo
