https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97397
Ulrich Drepper changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97397
Bug ID: 97397
Summary: Unnecessary mov instruction
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98737
Bug ID: 98737
Summary: Atomic operation on x86 no optimized to use flags
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98737
--- Comment #8 from Ulrich Drepper ---
(In reply to Jakub Jelinek from comment #7)
> The sub fix won't be the same as would add, perhaps xor/or/and can be
> handled by the same peephole2, but even for that I'm not sure.
Just a proposal, but I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98737
--- Comment #6 from Ulrich Drepper ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 50058 [details]
> gcc11-pr98737.patch
>
> Untested fix.
This only handles sub?
The same applies to add, or, and, xor. Maybe nand? Can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98864
Bug ID: 98864
Summary: Warning for unnecessary final keyword
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103857
Bug ID: 103857
Summary: implement ternary without jump (and comparison)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103857
--- Comment #2 from Ulrich Drepper ---
(In reply to Jakub Jelinek from comment #1)
> I don't think that's equivalent.
You're right, I tried to generalize the code and failed. I my actual case this
was a single variable the compiler saw the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103749
Bug ID: 103749
Summary: Misleading error message on template/non-template
conflict
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103749
--- Comment #4 from Ulrich Drepper ---
(In reply to Marek Polacek from comment #3)
> Hopefully that's a bit better.
This indeed looks as good as one can hope for. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104781
Ulrich Drepper changed:
What|Removed |Added
CC||drepper.fsp+rhbz at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104486
Bug ID: 104486
Summary: if constexpr versus -Wtype-limits
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105626
Bug ID: 105626
Summary: -Wformat should accept u8"" strings
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105626
--- Comment #2 from Ulrich Drepper ---
Could something like this be added, it seems to have few chances if any to
disrupt any meaningful diagnostic while handling this specific case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105626
--- Comment #6 from Ulrich Drepper ---
(In reply to Marek Polacek from comment #5)
> Fixed for GCC 13. I could probably backport to GCC 12, if desirable.
Thanks. And I certainly would appreciate a backport since this is an annoying
warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107043
Bug ID: 107043
Summary: range information not used in popcount
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107043
--- Comment #2 from Ulrich Drepper ---
My original example and Andrew's g0 are handled by Aldy's patches
2022-09-26 Aldy Hernandez
PR tree-optimization/107009
* range-op.cc (operator_bitwise_and::op1_range): Optimize 0 = x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107414
Bug ID: 107414
Summary: dwarf 5 C macro support
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107414
--- Comment #2 from Ulrich Drepper ---
OK, I submitted:
https://sourceware.org/bugzilla/show_bug.cgi?id=29725
Let's see what they say.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107414
--- Comment #4 from Ulrich Drepper ---
Actually, Jakub was right. This is a gdb issue. The gdb maintainers pointed
me to the trunk version and this indeed works with this simple code sequence.
There might have been a bug as in 107012 but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009
Bug ID: 107009
Summary: massive unnecessary code blowup in vectorizer
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230
--- Comment #9 from Ulrich Drepper ---
Created attachment 53419
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53419=edit
diff -y of current and proposed output
To compare the results more easily.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230
Ulrich Drepper changed:
What|Removed |Added
Attachment #53410|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230
Ulrich Drepper changed:
What|Removed |Added
CC||drepper.fsp+rhbz at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230
--- Comment #5 from Ulrich Drepper ---
Or should the std::pair output even be
p1 = std::pair = {[0] = 0, [1] = 0}
??
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230
--- Comment #3 from Ulrich Drepper ---
Actually, I think for the std::pair definition I'd like to see
p1 = {[0] = 0, [1] = 0}
instead of
p1 = {first = 0, second = 0}
Again, more uniform and I'd say it should be encouraged to use std::get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230
--- Comment #4 from Ulrich Drepper ---
Ugh, this one is a pasto:
v1 = std::vector of length 0, capacity 0 = { }
instead of
v1 = std::vector of length 0, capacity 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230
--- Comment #6 from Ulrich Drepper ---
Created attachment 53410
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53410=edit
consistent pretty printing of contains
How about this patch?
I used the attached test case. With the current code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107972
Bug ID: 107972
Summary: backward propagation of finite property not performed
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109045
Bug ID: 109045
Summary: assume attribute and std::optional do not mix
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110655
Bug ID: 110655
Summary: incorrect position of indicator in error message
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110654
Bug ID: 110654
Summary: inconsistent error message in presence of unexpected
encoded characters
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110654
--- Comment #2 from Ulrich Drepper ---
(In reply to Andrew Pinski from comment #1)
> So this is due to differences in the languages themselves rather than due to
> C vs C++ front-end ...
This is certainly true for the validation.
But the
33 matches
Mail list logo
