https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110047
--- Comment #1 from Richard Biener ---
Maybe just diagnose at the point of conversions that are not just sign
conversions but truncations/extensions?
Note even then this will have a high rate of false positives (I'm myself
always short-cutting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110039
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110048
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110044
--- Comment #3 from Sergey Fedorov ---
(In reply to Eric Gallager from comment #2)
> possible dup of either bug 60972 and/or bug 68160?
>From those topics it looks that the bug, if identical, has never been addressed
since GCC 4.9. Would it be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110035
--- Comment #6 from rguenther at suse dot de ---
On Tue, 30 May 2023, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110035
>
> Andrew Pinski changed:
>
>What|Removed |Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110048
Bug ID: 110048
Summary: undefined reference when build with O0
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59666
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110044
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110041
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110047
Bug ID: 110047
Summary: RFE: Add a warning for use of bare "unsigned"
(possibly under -Wimplicit-int?)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29970
--- Comment #18 from Martin Uecker ---
What is not fixed is returning structs with VLA members as in the first three
test cases, e.g. the second one still ICEs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70802
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71768
Andrew Pinski changed:
What|Removed |Added
Known to fail||7.5.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27663
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2007-07-25 17:29:16 |2023-5-30
Component|middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109971
--- Comment #10 from Kewen Lin ---
(In reply to JuzheZhong from comment #9)
> (In reply to Kewen Lin from comment #8)
> > I did SPEC2017 int/fp evaluation on Power10 at Ofast and an extra explicit
> > --param=vect-partial-vector-usage=2 (the def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109971
--- Comment #9 from JuzheZhong ---
(In reply to Kewen Lin from comment #8)
> I did SPEC2017 int/fp evaluation on Power10 at Ofast and an extra explicit
> --param=vect-partial-vector-usage=2 (the default is 1 on Power), baseline
> r14-1241 vs. ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109971
Kewen Lin changed:
What|Removed |Added
Keywords|testsuite-fail |missed-optimization
Assignee|link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110038
--- Comment #2 from cuilili ---
(In reply to Richard Biener from comment #1)
> Probably best to limit the values to reassoc-width by adding the
> appropriate IntegerRange attribute in params.opt
>
> IntegerRange(0, 256)
>
> maybe?
"rewrite_ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847
--- Comment #5 from Jerry DeLisle ---
Hi Steve,I will see if I can get all this tested and committed this coming
weekend.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50486
Eric Gallager changed:
What|Removed |Added
Summary|No warning at signed -> |Missed -Wsign-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29970
--- Comment #17 from Eric Gallager ---
(In reply to CVS Commits from comment #16)
> The master branch has been updated by Martin Uecker :
>
> https://gcc.gnu.org/g:4e6bf0b9dd5585df1a1472d6a93b9fff72fe2524
>
> commit r12-5338-g4e6bf0b9dd5585df1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55077
--- Comment #10 from Eric Gallager ---
(In reply to David Binderman from comment #9)
> -Wfloat-conversion does the deed: any chance of getting it someplace useful
> like -Wall or -Wextra anytime soon ?
>
> I will put it into my local compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110045
--- Comment #7 from Frank J. T. Wojcik ---
After playing with this a bit more, I was able to find a Generator which
produces a slightly wider bound, but still nowhere near 0x1.fep+127.
This also includes the requested change to SimpleGen.
#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110045
--- Comment #6 from Frank J. T. Wojcik ---
(In reply to Andrew Pinski from comment #5)
> 2 things, I think your result_type in SimpleGen needs to be public.
Sure, I'll change that.
> Second is LLVM's libc++ outputs:
> -inf -inf
> inf inf
I on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110035
--- Comment #5 from Pontakorn Prasertsuk ---
(In reply to Andrew Pinski from comment #3)
> We don't even optimize:
> ```
> struct MyClass
> {
> unsigned long long arr[128];
> };
>
> [[gnu::noipa]]
> void sink(void *m);
> void gg(MyClass &a,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110045
--- Comment #5 from Andrew Pinski ---
2 things, I think your result_type in SimpleGen needs to be public.
Second is LLVM's libc++ outputs:
-inf -inf
inf inf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110035
--- Comment #4 from Pontakorn Prasertsuk ---
(In reply to Richard Biener from comment #1)
> Ick - convoluted C++. We end up with
>
> void ff (struct MyClass & obj)
> {
> vector(2) long unsigned int vect_SR.16;
> vector(2) long unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110045
--- Comment #4 from Frank J. T. Wojcik ---
(In reply to Andrew Pinski from comment #3)
> With 24bit precision, maybe it is ~8 standard deviations away from the mean.
> But the generator argument can change for each call though so that does not
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110045
--- Comment #3 from Andrew Pinski ---
With 24bit precision, maybe it is ~8 standard deviations away from the mean.
But the generator argument can change for each call though so that does not
mean the next call to operator() could produce one wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110045
--- Comment #2 from Frank J. T. Wojcik ---
(In reply to Andrew Pinski from comment #1)
> The heavy weight goes to potentially. The way I understand it is not the max
> of what operator() has produced currently but will potentially return in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110045
--- Comment #1 from Andrew Pinski ---
The heavy weight goes to potentially. The way I understand it is not the max of
what operator() has produced currently but will potentially return in the
future.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110045
Bug ID: 110045
Summary: std::normal_distribution (and likely others)
give wrong min() and max() values
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108938
Hongtao.liu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108804
--- Comment #6 from Hongtao.liu ---
Fixed for GCC14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108804
--- Comment #5 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:3279b6223066d36d2e6880a137f80a46d3c82c8f
commit r14-1421-g3279b6223066d36d2e6880a137f80a46d3c82c8f
Author: liuhongt
Date: Wed Feb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110043
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110043
Andrew Pinski changed:
What|Removed |Added
Summary|ice in size_remaining, at |[14 Regression] ice in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110044
Andrew Pinski changed:
What|Removed |Added
Keywords||ABI, wrong-code
--- Comment #1 from And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109836
Eric Gallager changed:
What|Removed |Added
Keywords||patch
--- Comment #5 from Eric Gallager
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110044
Bug ID: 110044
Summary: #pragma pack(push, 1) may not force packing, while
__attribute__((packed, aligned(1))) works
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109826
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110042
--- Comment #6 from Andrew Pinski ---
Created attachment 55219
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55219&action=edit
untested patch
I am going to test this on both x86_64 and aarch64 tonight.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110042
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-05-30
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110042
--- Comment #4 from Andrew Pinski ---
Because of the subreg.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110042
--- Comment #3 from Andrew Pinski ---
bb_valid_for_noce_process_p returns false for the zero_extract case ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110043
Bug ID: 110043
Summary: ice in size_remaining, at pointer-query.cc:875
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109592
--- Comment #10 from Jeffrey A. Law ---
Created attachment 55218
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55218&action=edit
(Incomplete) Patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108041
--- Comment #4 from Jeffrey A. Law ---
Patch was for a different problem. Sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109592
--- Comment #9 from Jeffrey A. Law ---
Weird, I don't see the attachment either. I'll extract & upload it again.
WRT costing. fwprop and combine will both query the target rtx costs and will
reject when the target costing model indicates the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109822
Matthias Kretz (Vir) changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109822
--- Comment #5 from CVS Commits ---
The releases/gcc-11 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:39a60f2d5f7bf6806a4c4d7d1f52f139e157e01a
commit r11-10835-g39a60f2d5f7bf6806a4c4d7d1f52f139e157e01a
Author: Matthias Kret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641
--- Comment #21 from CVS Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:e4c986fde56a6248f8fbe6cf0704e1da34b055d8
commit r14-1418-ge4c986fde56a6248f8fbe6cf0704e1da34b055d8
Author: Georg-Johann Lay
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109822
--- Comment #4 from CVS Commits ---
The releases/gcc-12 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:467887d5750d03d438ab704437b2c5e5da78497e
commit r12-9666-g467887d5750d03d438ab704437b2c5e5da78497e
Author: Matthias Kretz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #50 from Oleg Endo ---
Actually, let's take any further discussion of shift patterns to PR 54089.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #49 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #48)
> I made tests (including *.c files from GCC testsuite) and everything looks
> fine for now. But I'm still afraid that pattern for 'ashrsi3_libcall_expand'
> is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110042
--- Comment #2 from Andrew Pinski ---
Here is a bitfield testcase which shows this was a latent issue:
```
struct f
{
unsigned t:3;
unsigned t1:4;
};
unsigned f2(struct f);
unsigned
f1(int t, struct f y)
{
int tt = 0;
if(t)
tt = y.t1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110042
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110042
--- Comment #1 from Andrew Pinski ---
I am still looking into this. This is definitely a latent bug and maybe even
can be reproduced some bitfield extractions too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110042
Bug ID: 110042
Summary: [14 Regression] missed cmov optimization after
r14-1014-gc5df248509b489364c573e8
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50286
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
--- Comment #11 from Georg-Johann Lay ---
Created attachment 55217
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55217&action=edit
Proposed patch for postreload.cc to record clobbers of next insn + test case.
This patch solves the proble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110041
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110041
--- Comment #2 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:2720bbd597f56742a17119dfe80edc2ba86af255
commit r14-1416-g2720bbd597f56742a17119dfe80edc2ba86af255
Author: Uros Bizjak
Date: Tue M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58483
--- Comment #17 from Andrew Pinski ---
Here is related reduced testcase:
```
int f(void)
{
int tt = 100;
int t[3] = {10,20,30};
int *t1 = new int[3];
__builtin_memcpy(t1, t, sizeof(t));
for(int *i = t1; i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110041
David Binderman changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110041
Bug ID: 110041
Summary: gcc/config/i386/i386-expand.cc:23394:5: warning:
misleading indentation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572
--- Comment #31 from Jakub Jelinek ---
In theory, what we could do (expensive though) is keep the IL of the functions
that were ICF merged with the picked up candidate, just mark them in cgraph
specially so that e.g. IPA doesn't consider referenc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110035
--- Comment #3 from Andrew Pinski ---
We don't even optimize:
```
struct MyClass
{
unsigned long long arr[128];
};
[[gnu::noipa]]
void sink(void *m);
void gg(MyClass &a, MyClass *b)
{
MyClass c = a;
*b = c;
sink(b);
}
```
As I mentio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106776
--- Comment #6 from Leandro Nini ---
Can't reproduce anymore with gcc 13.1.0
Still there in gcc 12.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110035
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Ever confirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101024
--- Comment #10 from Andrew Pinski ---
The only thing left to do to remove minmax_replacement, is the improvement
mentioned in PR 95699 (or rather r11-1504-g2e0f4a18bc978c7362 ).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87913
--- Comment #7 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:45466eecf5ef669164c0922e5be8fd288b144886
commit r14-1412-g45466eecf5ef669164c0922e5be8fd288b144886
Author: Andrew Pinski
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106907
Jeevitha changed:
What|Removed |Added
CC||jeevitha at gcc dot gnu.org
--- Comment #4 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110040
Jeevitha changed:
What|Removed |Added
Target Milestone|--- |14.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110040
Bug ID: 110040
Summary: rs6000 port emits dead mfvsrd instruction for simple
test case
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109822
--- Comment #3 from CVS Commits ---
The releases/gcc-13 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:717a14e727bce409ac7e7f10c413530e704f4ca7
commit r13-7393-g717a14e727bce409ac7e7f10c413530e704f4ca7
Author: Matthias Kretz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Jack O'Connor changed:
What|Removed |Added
CC||oconnor663 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110026
Andrew Pinski changed:
What|Removed |Added
Keywords||ra
--- Comment #3 from Andrew Pinski -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110023
--- Comment #2 from d_vampile ---
(In reply to Andrew Pinski from comment #1)
> This is almost definitely an aarch64 cost model issue ...
Do you mean that the vectorized cost_model of the underlying hardware causes
the policy of not peeling the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110026
--- Comment #2 from d_vampile ---
(In reply to Jakub Jelinek from comment #1)
> Note, any benchmarking for speed with -O rather than -O2/-O3 is
> intentionally missing various optimizations which can greatly improve
> performance.
O0 does miss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109822
--- Comment #2 from CVS Commits ---
The master branch has been updated by Matthias Kretz :
https://gcc.gnu.org/g:668d43502f465d48adbc1fe2956b979f36657e5f
commit r14-1409-g668d43502f465d48adbc1fe2956b979f36657e5f
Author: Matthias Kretz
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #51 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:69185294f322dd53d4e1592115014c5488302e2e
commit r14-1405-g69185294f322dd53d4e1592115014c5488302e2e
Author: Roger Sayle
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109973
--- Comment #6 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:69185294f322dd53d4e1592115014c5488302e2e
commit r14-1405-g69185294f322dd53d4e1592115014c5488302e2e
Author: Roger Sayle
Date: Tue M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106887
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110039
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110039
Bug ID: 110039
Summary: FAIL: gcc.target/aarch64/rev16_2.c
scan-assembler-times rev16\\tw[0-9]+ 2
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: miss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #48 from Alexander Klepikov
---
I made tests (including *.c files from GCC testsuite) and everything looks fine
for now. But I'm still afraid that pattern for 'ashrsi3_libcall_expand' is too
wide. It is possible to narrow it down as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110037
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106756
Patrick Palka changed:
What|Removed |Added
CC||jlame646 at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110035
--- Comment #1 from Richard Biener ---
Ick - convoluted C++. We end up with
void ff (struct MyClass & obj)
{
vector(2) long unsigned int vect_SR.16;
vector(2) long unsigned int vect_SR.15;
vector(2) long unsigned int vect_SR.14;
void *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110038
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-05-30
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110036
Andreas Schwab changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110036
--- Comment #3 from CVS Commits ---
The releases/gcc-12 branch has been updated by Andreas Schwab
:
https://gcc.gnu.org/g:2910660f00c74d12d17e3114870e287804a3332c
commit r12-9661-g2910660f00c74d12d17e3114870e287804a3332c
Author: Andreas Schwab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86880
--- Comment #3 from Jonathan Wakely ---
We have the same problem with std::subtract_with_carry_engine. Its equality
operator doesn't work for rotated states.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60441
--- Comment #3 from Jonathan Wakely ---
We have the same problem with std::subtract_with_carry_engine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86880
--- Comment #2 from Jonathan Wakely ---
This would fix the equality operator to correctly compare rotated states:
--- a/libstdc++-v3/include/bits/random.h
+++ b/libstdc++-v3/include/bits/random.h
@@ -601,8 +601,37 @@ _GLIBCXX_BEGIN_NAMESPACE_VER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110036
--- Comment #2 from CVS Commits ---
The releases/gcc-13 branch has been updated by Andreas Schwab
:
https://gcc.gnu.org/g:acf4fac6c5d14b30dca6cbde75f8b7db89850e04
commit r13-7389-gacf4fac6c5d14b30dca6cbde75f8b7db89850e04
Author: Andreas Schwab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
--- Comment #3 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:a899401404186843f38462c8fc9de733f19ce864
commit r14-1404-ga899401404186843f38462c8fc9de733f19ce864
Author: Tobias Burnus
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109827
Eric Gallager changed:
What|Removed |Added
Last reconfirmed||2023-05-30
Status|UNCONFIRM
1 - 100 of 143 matches
Mail list logo
