https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110125
Gaius Mulley changed:
What|Removed |Added
CC||gaius at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110264
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
Andrew Pinski changed:
What|Removed |Added
Summary|[14 Regression] llvm-16 |[13/14 Regression] llvm-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110284
Gaius Mulley changed:
What|Removed |Added
Last reconfirmed||2023-06-17
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
--- Comment #14 from Sergei Trofimovich ---
> LookupFlags = LookupFlags | t;
That makes `LookupFlags` to guarantee to contain uninitialized bits. Did you
mean `LookupFlags = t;`?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
--- Comment #13 from Andrew Pinski ---
The big question is this code here:
```
unsigned a[4] = {1,1,1,1};
__attribute__((noipa))
void sink(int){}
__attribute__((noipa))
static void bug(unsigned & p, unsigned *t, int n) {
bool LookupFlags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92887
--- Comment #3 from anlauf at gcc dot gnu.org ---
When using the tentative patch
https://gcc.gnu.org/bugzilla/attachment.cgi?id=55333
and adding a hackish
else if (e && fsym && fsym->attr.value && e->expr_type == EXPR_VARIABLE)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92887
--- Comment #2 from anlauf at gcc dot gnu.org ---
Created attachment 55356
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55356&action=edit
Partial patch for the presence attribute
The attached patch generates a test for the presence that d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110295
Andrew Pinski changed:
What|Removed |Added
Summary|internal compiler error: in |[10/11/12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110295
Andrew Pinski changed:
What|Removed |Added
Known to fail||14.0
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110298
--- Comment #2 from Andrew Pinski ---
loop->nb_iterations still includes reference to a removed SSA name ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110298
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.5
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #82 from Alexander Klepikov
---
I have read the docs and other targets' code, and the puzzle finally came
together. A struct with additional current function context is a really good
idea! I'll implement it in a couple of days.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
--- Comment #12 from Andrew Pinski ---
I should note my reduced testcase does not even need the ranger to tell me that
the range is [0,1] because it uses a bool which has a PRECISION of 1.
If an expand solution is not implemented in a few months
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110033
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
Bloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224
Paul Thomas changed:
What|Removed |Added
Blocks||87477
--- Comment #2 from Paul Thomas --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #24 from Jakub Jelinek ---
Sorry, in that case nothing needs to be done for riscv. I'm sure aarch64, arm
has one (e.g. adcs), I think powerpc has some, but e.g. PR43892 is still open,
and I'm sure s390 has them too (alc*, slb*).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #23 from Jeffrey A. Law ---
risc-v doesn't have any special instructions to implement add-with-carry or
subtract-with-borrow. Depending on who you talk do, it's either a feature or a
mis-design.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110298
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|ICE at -Os on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110298
Bug ID: 110298
Summary: ICE at -Os on x86_64-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110287
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> @@ -946,7 +945,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
>else
> {
> const size_type __len =
> - _M_check_len(size_type(1),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110287
--- Comment #3 from Jonathan Wakely ---
Do you mean something like this?
diff --git a/libstdc++-v3/include/bits/stl_vector.h
b/libstdc++-v3/include/bits/stl_vector.h
index 70ced3d101f..a4dbfeb8b5b 100644
--- a/libstdc++-v3/include/bits/stl_vect
When using std::conditional_t inside a class/struct with one of the
conditional types being `decltype([]{})`, the type is wrong.
https://godbolt.org/z/3jhfcKav4
```
#include
#include
#include
template
using test_alias = std::conditional_t;
template
using test_alias3 = std::conditional_t;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #81 from Alexander Klepikov
---
(In reply to Oleg Endo from comment #78)
> The compiler processes one function at a time, all passes at once. It
> doesn't mix passes of different functions. So I think using global variable
> in sh.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88688
Paul Thomas changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110297
Bug ID: 110297
Summary: [13/14 Regression] all libgo tests fail on
arm-linux-gnueabi and arm-linxu-gnueabihf
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #80 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #79)
>
> I mean that if a user run GCC with -O1 and we don't do SH specific loop move
> invariants pass at -O1, a user could look at binary (or at .S file) and find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110296
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110271
Andrew Pinski changed:
What|Removed |Added
CC||manuel.lauss at googlemail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110296
Bug ID: 110296
Summary: ICE in gsi_replace, at gimple-iterator.cc:437 during
GIMPLE pass: widening_mul
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #79 from Alexander Klepikov
---
(In reply to Oleg Endo from comment #78)
> (In reply to Alexander Klepikov from comment #77)
> > > It'd be good if the newly added passes are ran only with -O2 or higher.
> >
> > This can be confusing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110295
Bug ID: 110295
Summary: internal compiler error: in dwarf2out_finish
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110280
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110280
--- Comment #8 from Andrew Pinski ---
In the original case FRE is trying to do the same thing as the reduced
testcase:
```
Successfully combined 4 partial definitions
Setting value number of _39 to { 0, 0, 0, 0 } (changed)
Value numbering stmt =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110280
--- Comment #7 from Andrew Pinski ---
I think this part of match is incorrect:
(if (sel.series_p (0, 1, 0, 1))
{ op0; }
(if (sel.series_p (0, 1, nelts, 1))
{ op1; }
This is only true if type == TREE_TYPE (op0) (well compatib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110280
--- Comment #6 from Andrew Pinski ---
Match-and-simplified VEC_PERM_EXPR <_10, _10, { 0, 1, 2, 3, ... }> to { 0, 0,
0, 0 }
Ok, that is wrong ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110280
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.2
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #78 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #77)
> > It'd be good if the newly added passes are ran only with -O2 or higher.
>
> This can be confusing to users when they discover that not all invariants
> are
39 matches
Mail list logo
