https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85053
Martin Sebor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97553
--- Comment #4 from Jakub Jelinek ---
Depends on what you mean by properly. -O3 can be used with sanitization, but
expecting the code to be optimized the same way as without sanitization is
wrong, it is more important to catch as many bugs as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97567
--- Comment #2 from Andrew Macleod ---
Created attachment 49441
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49441=edit
combine OR operands with union, not intersect
Fundamentally, this boils down to a bug in logical-combine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97568
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
--- Comment #9 from Segher Boessenkool ---
Yes, that looks correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97581
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97491
--- Comment #3 from anlauf at gcc dot gnu.org ---
Submitted here: https://gcc.gnu.org/pipermail/fortran/2020-October/055235.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97584
Bug ID: 97584
Summary: ADL inconsistency when calling the stream operator
with x << y or with operator<<(x,y)
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97540
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97553
--- Comment #3 from Eyal Rozenberg ---
> And, the runtime sanitization intentionally isn't heavily optimized away,
> because the intent is to detect when the code is invalid, so it can't e.g.
> optimize away those checks based on assumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97581
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97567
--- Comment #3 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:48722d158cbf692c24025e345ec570f66aa5
commit r11-4393-g48722d158cbf692c24025e345ec570f66aa5
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96863
--- Comment #5 from Sergei Trofimovich ---
gcc's backtrace:
Breakpoint 2, internal_error (gmsgid=0x2df9a67 "in %s, at %s:%d") at
../../gcc/gcc/diagnostic.c:1752
1752{
(gdb) bt
#0 internal_error (gmsgid=0x2df9a67 "in %s, at %s:%d") at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97553
--- Comment #5 from Eyal Rozenberg ---
(In reply to Jakub Jelinek from comment #4)
> Depends on what you mean by properly. -O3 can be used with sanitization,
> but expecting the code to be optimized the same way as without sanitization
> is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
--- Comment #6 from Libin Dang ---
(In reply to Martin Liška from comment #2)
> Using latest GCC release you can see what happens:
>
> $ g++ pr96919.cc --coverage && ./a.out && gcov a-pr96919.cc -t
> hello
> libgcov profiling
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97565
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-10-26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97576
Richard Biener changed:
What|Removed |Added
Keywords||openmp
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97559
--- Comment #2 from Richard Biener ---
OK, so as expected this is
static bool
statement_sink_location (gimple *stmt, basic_block frombb,
gimple_stmt_iterator *togsi, bool *zero_uses_p)
{
...
/* If this is a load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97576
Bug ID: 97576
Summary: [11 Regression] ICE: verify_cgraph_node failed (error:
reference to dead statement)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97558
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97557
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97559
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=97554
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97575
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97577
Bug ID: 97577
Summary: [11 Regression] ICE: Segmentation fault (in
get_location_from_adhoc_loc)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87731
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97587
Bug ID: 97587
Summary: [coroutines] promise_type constructor is called with
original parameters, not parameter copies
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94527
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46181
Martin Sebor changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97585
Bug ID: 97585
Summary: Improve documentation for -march=x86-64 to say MMX,
SSE, SSE2 are implied
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97586
Bug ID: 97586
Summary: "make check" failures in binutils with -flto=jobserver
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97539
--- Comment #3 from Richard Biener ---
So the fundamental issue is that we have a debug-only live use and we do not
have LC SSA for those. When vectorizer epilogue peeling then creates the
loop copy the debug use is still refering to the first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97574
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97551
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |11.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97576
--- Comment #2 from Jan Hubicka ---
The problem here is that clone materialization invalidates statement pointers
in refs. We clean these at the begining of late optimization, I guess it
should be done on demand during materialization (they are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97574
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97578
Bug ID: 97578
Summary: ice during IPA pass: inline
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97578
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97569
--- Comment #3 from Jonathan Wakely ---
Ah right, so
int main()
{
struct A
{
struct B *b;
struct C {} *c;
};
using U = B;
using V = C;
}
For the `struct C {}` case that explicitly defines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
--- Comment #7 from jbeulich at suse dot com ---
For the problem originally reported here (operator name space collision) a
workaround could be introduced (e.g. a new operand to .intel_syntax to allow
suppressing the recognition of MASM-like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97559
Jakub Jelinek changed:
What|Removed |Added
Summary|ICE at -O1 and above on |[11 Regression] ICE at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
--- Comment #6 from jbeulich at suse dot com ---
(In reply to Jakub Jelinek from comment #3)
> The problem is that the intel asm syntax is just badly defined (broken by
> design). I'm not aware of any compiler that would emit for such testcases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97556
--- Comment #2 from Jakub Jelinek ---
I think the problem is that compute_objsize doesn't bother to check for any
kind of overflow on any arithmetics it does.
E.g. in:
4815 offset_int sz = wi::to_offset (tpsize);
4816
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97539
Richard Biener changed:
What|Removed |Added
Known to fail|11.0|
Summary|[10/11 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97572
--- Comment #2 from Dimitri Gorokhovik ---
Fair enough, passing a boolean by value into 'any()' is evaluation of local
parameter 't', and that is prohibited (7.5.7.4/2).
Doesn't this merit a better diagnostics though?
A slightly modified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97521
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97546
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579
Bug ID: 97579
Summary: [11 Regression] ICE in gimple_expand_vec_cond_expr, at
gimple-isel.cc:201 since r11-4123-g128f43cf679e5156
Product: gcc
Version: 11.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97546
--- Comment #4 from CVS Commits ---
The master branch has been updated by Kyrylo Tkachov :
https://gcc.gnu.org/g:7f0ce82a4c033b78ec5131a27bac87271bb95185
commit r11-4382-g7f0ce82a4c033b78ec5131a27bac87271bb95185
Author: Kyrylo Tkachov
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97574
--- Comment #1 from Jonathan Wakely ---
I think "nul" should work, but it looks like the error is in the linker,
ld.exe, not GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97575
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97576
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97559
Martin Liška changed:
What|Removed |Added
Known to work||10.2.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95151
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97521
--- Comment #23 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:605c2a393d3a2db86454a70fd7c9467db434060c
commit r11-4381-g605c2a393d3a2db86454a70fd7c9467db434060c
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97558
--- Comment #2 from Richard Biener ---
Huh. OK, so we're having a !relevant and !live stmt in the SLP tree, and the
removed check for !vectype caught this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97558
--- Comment #3 from Richard Biener ---
But then in vect_fixup_scalar_cycles_with_patterns we leave us with
a reduction chain with eventually half irrelevant stmts because we
mix in-pattern and non-in-pattern stmts for gcc.dg/vect/pr83965-2.c.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97539
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:27c14056f4805c9d8cfc655ef2c846be128b02c9
commit r11-4376-g27c14056f4805c9d8cfc655ef2c846be128b02c9
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97554
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97570
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95458
--- Comment #3 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:4052c05e5b30fee0fb95a51e74e12a56dce29491
commit r11-4380-g4052c05e5b30fee0fb95a51e74e12a56dce29491
Author: H.J. Lu
Date: Wed Jul 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95458
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97572
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97577
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97570
--- Comment #2 from Jonathan Wakely ---
Thanks for the report. It's fixed on the development trunk now, but I will also
backport it to the release branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97570
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:93e9a7bcd5434a24c945de33cd7fa01a25f68418
commit r11-4383-g93e9a7bcd5434a24c945de33cd7fa01a25f68418
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97576
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97581
Bug ID: 97581
Summary: libgfortran/intrinsics/random.c:754: bad array size ?
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97561
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97570
--- Comment #3 from Jonathan Wakely ---
(In reply to Matwey V. Kornilov from comment #0)
> Then gcc and libstdc++ are compiled and installed successfully without any
> further errors.
P.S. this is great news. I've been meaning to check this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97562
--- Comment #1 from Jonathan Wakely ---
Dup of PR 51571 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97578
Jan Hubicka changed:
What|Removed |Added
CC||jakub at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97562
--- Comment #2 from Barry Revzin ---
Yep, looks like the same issue to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97580
Bug ID: 97580
Summary: reinterpret_cast<> and constant expression
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97580
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97572
--- Comment #4 from Dimitri Gorokhovik ---
I probably cannot objectively tell anymore which one is better, since I just
read the specification.
However, subjectively, Clang's diagnostics:
a) seems to have phrasing much closer to the spec, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97576
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:783dc02d89712f5219093d33ad7f08e1509a2134
commit r11-4385-g783dc02d89712f5219093d33ad7f08e1509a2134
Author: Jan Hubicka
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97576
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97580
Richard Biener changed:
What|Removed |Added
Keywords||accepts-invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97578
--- Comment #2 from David Binderman ---
Here is a second simpler test case:
int a;
static void b(int c) {
if (a)
while (c)
b(0);
d();
}
void e(c) { b(c); }
void f() { e(0); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97561
--- Comment #2 from Jonathan Wakely ---
Do you have a real world use case where the inheritance is actually required?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97497
--- Comment #7 from rsandifo at gcc dot gnu.org
---
(In reply to Andreas Krebbel from comment #6)
> Alternatively I could also mark r12 as preserved across function calls for
> -fpic in the backend. In fact all the bits we care about are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97582
Bug ID: 97582
Summary: Regression Internal compiler error in lambda
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92831
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92831
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97553
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97124
Liu Hao changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97536
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96342
--- Comment #8 from rsandifo at gcc dot gnu.org
---
(In reply to yangyang from comment #3)
> The work is mainly composed of three parts: the generating of SVE
> functions for "omp declare simd" in pass_omp_simd_clone, the supporting of
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97446
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97418
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97555
--- Comment #4 from Aldy Hernandez ---
The problem here is we're trying to add 1 to a -1 in a signed 1-bit field.
Signed 1-bits are annoying because you can't really add or subtract one,
because the one is unrepresentable. For invert() we have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97376
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97376
--- Comment #2 from Marek Polacek ---
s/pro/for/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97554
--- Comment #3 from Rimvydas (RJ) ---
The g:50f9e1f4d458e36d306b2449c689e45492847f68 applied on top of gcc-10.2
release tarball also allows to compile without segfault in reasonable amount of
time. Could this fix be added to gcc-10 branch for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97561
--- Comment #3 from stinkingmadgod at gmail dot com ---
Thanks for the link.
I was attempting to create a type-erased task type where the handles in one
case was be passed in as a std::coroutine_handle<>& to avoid using
std::function and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97214
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97214
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|ICE in
1 - 100 of 125 matches
Mail list logo