https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101794
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/microsof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101794
--- Comment #1 from Andrew Pinski ---
The section of std::lerp in the standard does not define what value should be
returned if t is nan. I have not tried to find out what other parts of the
standard say but I think this might be just unspecifie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101795
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #2 from And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96862
Andrew Pinski changed:
What|Removed |Added
Known to work||10.3.0, 11.1.0, 9.4.0
Known to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99801
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2021-03-30 00:00:00 |2022-12-24
--- Comment #5 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99801
--- Comment #4 from Andrew Pinski ---
Created attachment 54155
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54155&action=edit
Original testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70885
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101804
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101806
--- Comment #3 from Andrew Pinski ---
Even a simple:
unsigned char g(unsigned char a, unsigned char b)
{
return ((~a) & b)&1;
}
Produces the extra zero extend.
But it is ok with:
unsigned char g(unsigned char *a, unsigned char *b)
{
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101856
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-12-25
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108220
Andrew Pinski changed:
What|Removed |Added
Keywords||inline-asm
--- Comment #1 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108220
Bug ID: 108220
Summary: ICE: maximum number of generated reload insns per insn
achieved (90)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105327
--- Comment #2 from Andrew Pinski ---
Switching around the order to do:
g.p_ = 0;
P p (new (v) T);
Fixes the warning and I think correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105327
--- Comment #1 from Andrew Pinski ---
I don't think this is a bogus one.
std::shared_ptr owns the pointer once it is passed, not before.
So when you do:
mem_guard g (v);
...
P p (new (v) T);
...
the constructor of p might cause operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #7 from And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101922
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108219
Andrew Pinski changed:
What|Removed |Added
Known to work||11.3.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218
--- Comment #7 from Steven Sun ---
I got one simple idea as a workaround. I do not have the resources to do the
tests.
I agree anyone to take the following patch or the idea.
>From 35b4186a0ed3671de603bed6df5fb1156f087581 Mon Sep 17 00:00:00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107548
--- Comment #2 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:3cf6d0e1830231dd47740e66926499db600b9ae4
commit r13-4886-g3cf6d0e1830231dd47740e66926499db600b9ae4
Author: Roger Sayle
Date: Sat D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108219
Bug ID: 108219
Summary: requirement fails on a valid expression
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105116
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100806
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |11.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105294
Matthew House changed:
What|Removed |Added
CC||mattlloydhouse at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218
--- Comment #6 from Steven Sun ---
g:4df7f8c79835d56928f51f9e674d326300936e8e
c++: don't do constexpr folding in unevaluated context
The implicit constexpr patch revealed that we were doing constant evaluation
of arbitrary expressions in uneva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218
--- Comment #5 from Steven Sun ---
h:4df7f8c79835d56928f51f9e674d326300936e8e
sorry, copied wrong hash code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218
--- Comment #4 from Andrew Pinski ---
(In reply to Steven Sun from comment #3)
> Bisecting tells me:
>
> 2551cd4f9bc1afee444a56e03c1cee6899593da9 is bad
> adcfd2c45c3523d74279b5fcac1d7c6c34dd1382 is good
>
>
>
> I think commit ddd25bd1a7c8f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86318
Andrew Pinski changed:
What|Removed |Added
CC||jhaberman at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108217
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 108217, which changed state.
Bug 108217 Summary: bogus -Warray-bounds with pointer to constant local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108217
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218
--- Comment #3 from Steven Sun ---
Bisecting tells me:
2551cd4f9bc1afee444a56e03c1cee6899593da9 is bad
adcfd2c45c3523d74279b5fcac1d7c6c34dd1382 is good
I think commit ddd25bd1a7c8f456bc914e34b77d43f39a1062d4 might be the root
cause.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108217
--- Comment #4 from Andrew Pinski ---
The problem with const is GCC does not have an idea of a store once and then
become constant.
an example of that would be:
```
void ExternFunc(const int*);
int f();
int Bad() {
const int i = f();
const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 108217, which changed state.
Bug 108217 Summary: bogus -Warray-bounds with pointer to constant local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108217
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108217
Josh Haberman changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108206
Andrew Pinski changed:
What|Removed |Added
Severity|normal |trivial
Summary|ICE: tree ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65568
Andrew Pinski changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108207
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108215
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108217
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23384
Andrew Pinski changed:
What|Removed |Added
CC||jhaberman at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 108217, which changed state.
Bug 108217 Summary: bogus -Warray-bounds with pointer to constant local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108217
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108217
Andrew Pinski changed:
What|Removed |Added
Keywords|diagnostic |missed-optimization
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106959
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108197
--- Comment #2 from Stephen ---
Richard, are you saying this a bug in the boost code? It's not quite clear to
me from your message. Can you be more specific about what the bug is in that
case?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183
--- Comment #14 from Iain Sandoe ---
coming back to this code:
===
extern "C" void
_M2_termios_init (int, char *[], char *[])
{
}
extern "C" void
_M2_termios_fini (int, char *[], char *[])
{
}
extern "C" void
_M2_termios_dep (void)
{
}
struc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933
Roger Sayle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218
--- Comment #1 from Steven Sun ---
My concern is that, expressions within the require expressions are also
considered as "unevaluated operands".
Thus, the following concept is evaluated as true, but the program is ill-formed
and does not compil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218
Bug ID: 108218
Summary: [12 Regression] Constant arguments in the new
expression is not checked in unevaluated operand
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81051
Matthew House changed:
What|Removed |Added
CC||mattlloydhouse at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108217
Bug ID: 108217
Summary: bogus -Warray-bounds with pointer to constant local
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #7 from Stefan Schulze Frielinghaus
---
The difference in the assembly output shown in comment 2 happens in function
void
AssociatedImplTrait::setup_associated_types (
const TyTy::BaseType *self, const TyTy::TypeBoundPredicate &b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #6 from Stefan Schulze Frielinghaus
---
Created attachment 54154
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54154&action=edit
preprocessed rust-hir-trait-resolve.cc
52 matches
Mail list logo
