https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95622
--- Comment #7 from Tobias Burnus ---
(In reply to Richard Biener from comment #6)
> not sure if fixed?
Not fixed – only XFAILed.
The issue is that optimizations are not done with "node->force_output". As in
the example in comment 0:
"a = 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95679
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96202
Bug ID: 96202
Summary: --enable-cet complains about missing assembler support
with GCC 7 host compiler
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96202
Richard Biener changed:
What|Removed |Added
CC||hjl at gcc dot gnu.org
Targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96203
Bug ID: 96203
Summary: LTO bootstrap with --enable-cet is broken
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96203
Richard Biener changed:
What|Removed |Added
CC||doko at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96203
--- Comment #2 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:76641cd8b53128e1a962f1313ba75acf0855fd00
commit r10-8499-g76641cd8b53128e1a962f1313ba75acf0855fd00
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96198
Thomas Schwinge changed:
What|Removed |Added
CC||tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96197
--- Comment #2 from Erich Erstu ---
Richard Biener, you were right. I optimized the implementation of all the
problematic constant expression functions similarly to the one seen below, and
the compilation time went down to practically zero with u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204
Bug ID: 96204
Summary: gcc complains about private member access in SFINAE
context
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204
--- Comment #1 from Klaus Rudolph ---
Maybe related to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393
--- Comment #7 from Alan Modra ---
(In reply to Peter Bergner from comment #5)
> Alan, I think you pushed some changes to help with 1) above, correct?
> Is there more to do for 1)?
Possibly, I haven't looked at what needs to be done (if anything)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96203
Matthias Klose changed:
What|Removed |Added
CC||doko at debian dot org
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96197
--- Comment #3 from rguenther at suse dot de ---
On Wed, 15 Jul 2020, hyena at hyena dot net.ee wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96197
>
> --- Comment #2 from Erich Erstu ---
> Richard Biener, you were right. I optimized t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96203
Richard Biener changed:
What|Removed |Added
Summary|LTO bootstrap with |[11 Regression] LTO
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96176
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:410675cb63466d8de9ad590521f0766b012d2475
commit r11-2103-g410675cb63466d8de9ad590521f0766b012d2475
Author: Jakub Jelinek
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96174
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:12d69dbfff9dd5ad4a30b20d1636f5cab6425e8c
commit r11-2104-g12d69dbfff9dd5ad4a30b20d1636f5cab6425e8c
Author: Jakub Jelinek
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96174
--- Comment #3 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:9a9e1ed88614b96944d2e5e92e932f65dcf2d920
commit r10-8500-g9a9e1ed88614b96944d2e5e92e932f65dcf2d920
Author: Jakub Jelinek
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96197
--- Comment #4 from Erich Erstu ---
Intuitive logic says that even for a slow algorithm it should not be THAT slow
and memory heavy. And for a constant expression, the slowness of an algorithm
should not be that much of a concern in the first pla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
--- Comment #4 from Jonathan Wakely ---
(In reply to Federico Kircheis from comment #3)
> My guess, without having looked at the implementation of std::lock, is that
> the algorithm uses try_lock to eventually lock/unlock the mutexes and see if
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96174
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96176
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64335
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-07-15
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204
--- Comment #3 from Jonathan Wakely ---
Reduced:
template using void_t = void;
template T&& declval();
template
struct has_set_attr_method {
static constexpr bool value = false;
};
template
struct has_set_attr_method().setAttr(1))>> {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204
--- Comment #4 from Jonathan Wakely ---
The reduced example above doesn't need -std=c++17, it should compile in C++11
or later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95868
--- Comment #2 from Tobias Burnus ---
(In reply to Dominique d'Humieres from comment #1)
> Confirmed. Quite complex test case!
Came up when trying to write a patch for OpenMP structure/derived-type element
mapping (r11-2079). Hence:
Additional t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95837
--- Comment #8 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:e0685fadb6aa7c9cc895bc14cbbe2b9026fa3a94
commit r11-2105-ge0685fadb6aa7c9cc895bc14cbbe2b9026fa3a94
Author: Tobias Burnus
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
--- Comment #12 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Sandiford
:
https://gcc.gnu.org/g:932e9140d3268cf2033c1c3e93219541c53fcd29
commit r10-8501-g932e9140d3268cf2033c1c3e93219541c53fcd29
Author: Richard San
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96203
--- Comment #5 from H.J. Lu ---
(In reply to Richard Biener from comment #4)
> Arguably the simplest solution is to demote the error to a warning,
> --enable-cet
> is supposed to only enable CET instrumentation of (part of) the runtime. If
> we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96203
--- Comment #6 from H.J. Lu ---
By design, mixing CET and non-CET objects must be allowed. We should
revisit PR 95604.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95604
--- Comment #6 from H.J. Lu ---
LTO should follow GNU property spec by merging GNU_PROPERTY_X86_FEATURE_1_IBT
and GNU_PROPERTY_X86_FEATURE_1_SHSTK from all IR files, just like ld. The
current behavior can be retained by a new option, -fcf-protec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96202
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95062
Thomas Schwinge changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
Tobias Schlüter changed:
What|Removed |Added
Assignee|tobi at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96167
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96167
--- Comment #3 from Jakub Jelinek ---
Yeah. But at least if the target has corresponding mode rotate optab, there is
no reason not to support any rotates by constant multiples of byte size (for
bit rotates we don't have infrastructure for that).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96205
Bug ID: 96205
Summary: compile error on: #define JJWIDE(x) L#x
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96167
--- Comment #4 from Jakub Jelinek ---
Like:
unsigned long long
foo (unsigned long long x)
{
union U { unsigned long long x; char y[8]; } u, v;
u.x = x;
v.y[0] = u.y[7];
v.y[1] = u.y[0];
v.y[2] = u.y[1];
v.y[3] = u.y[2];
v.y[4] = u.y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96205
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Resolut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96206
Bug ID: 96206
Summary: internal compiler error: in convert_move, at
expr.c:218
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96198
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:79c12969ec3e9185fdbb90d3b1699d64b1cd0901
commit r11-2138-g79c12969ec3e9185fdbb90d3b1699d64b1cd0901
Author: Jakub Jelinek
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96202
H.J. Lu changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96207
Bug ID: 96207
Summary: GCC accepts "delete" function definition inside a
class member function
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96208
Bug ID: 96208
Summary: non-power-of-2 group size can be vectorized for
2-element vectors case
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96205
--- Comment #2 from francis.andre.kampbell at orange dot fr ---
This '#define JJWIDE(x) L#x' is workign fine with MSVC VS2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96205
--- Comment #3 from Jakub Jelinek ---
But not in GCC, clang or ICC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96209
Bug ID: 96209
Summary: Redundant error message split out when adding
"typename" keyword
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96210
Bug ID: 96210
Summary: Diagnostic message for using-directive in template
definition should be more clear?
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywor
gcc --version
gcc (GCC) 11.0.0 20200715 (experimental)
$
$ gcc -O2 -fno-dce -fno-tree-dce a.c; ./a.out
Segmentation fault (core dumped)
$ gcc -O3 -fno-dce -fno-tree-dce a.c; ./a.out
Segmentation fault (core dumped)
$ gcc -Os -fno-dce -fno-tree-dce a.c; ./a.out
Segmentation fault (core dumped)
$
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96211
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
--- Comment #5 from Federico Kircheis ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Federico Kircheis from comment #3)
> > My guess, without having looked at the implementation of std::lock, is that
> > the algorithm uses try_l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90664
ofv at wanadoo dot es changed:
What|Removed |Added
Summary|noexcept confuses template |[7/8 regression] noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68737
--- Comment #30 from dave.anglin at bell dot net ---
I'll test when I get a chance.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90664
Jakub Jelinek changed:
What|Removed |Added
Summary|[7/8 regression] noexcept |[9/10/11 regression]
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
--- Comment #6 from Federico Kircheis ---
For what is worth, I imagined the implementation for parameters of different
type and more or less than two to be similar to
template
auto sorted_indexes(Args&... args) {
const void* addresses[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96200
--- Comment #2 from Carlos O'Donell ---
(In reply to Florian Weimer from comment #1)
> __builtin_set_thread_pointer has little value from a glibc perspective
> because when used in application code, it will always result in undefined
> behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
--- Comment #7 from Jonathan Wakely ---
(In reply to Federico Kircheis from comment #6)
> For what is worth, I imagined the implementation for parameters of different
> type and more or less than two to be similar to
>
>
> template
> auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95355
--- Comment #8 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:6c2848ad02feef5ac094d1158be3861819b3bb49
commit r11-2140-g6c2848ad02feef5ac094d1158be3861819b3bb49
Author: Uros Bizjak
Date: Wed Ju
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95355
--- Comment #9 from Uroš Bizjak ---
(In reply to CVS Commits from comment #8)
> The master branch has been updated by Uros Bizjak :
Bah. Wrong PR reference, should be PR96189.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95355
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|11.0|10.2
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96189
--- Comment #3 from Uroš Bizjak ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:6c2848ad02feef5ac094d1158be3861819b3bb49
commit r11-2140-g6c2848ad02feef5ac094d1158be3861819b3bb49
Author: Uros Bizjak
Date: Wed Ju
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96189
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96212
Bug ID: 96212
Summary: new test case libgomp.fortran/alloc-3.F fails in
r11-2101
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95942
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2020-07-15
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488
--- Comment #4 from Peter Bergner ---
So the following pattern added to dfp.md:
+(define_insn "trunctdsd2"
+ [(set (match_operand:SD 0 "gpc_reg_operand" "=d")
+ (float_truncate:SD (match_operand:TD 1 "gpc_reg_operand" "d")))
+ (clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96212
--- Comment #1 from Bill Seurer ---
After running on a few more machines this appears to be a BE only issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90189
Aleksey Covacevice changed:
What|Removed |Added
CC||aleksey.covacevice at gmail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95942
--- Comment #3 from Sergei Trofimovich ---
Another example is edb-debugger project
https://github.com/eteran/edb-debugger/blob/070d0196227a58ce2ba15c695944ba16ce66c080/plugins/DebuggerCore/unix/linux/arch/x86-generic/PlatformThread.cpp#L331:
l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488
--- Comment #5 from Segher Boessenkool ---
operands[2] needs an earlyclobber as well (it is written while some
operands are still read later). Everything else is fine as far as I
can see :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488
--- Comment #6 from Segher Boessenkool ---
(So, pre-approved with that change, and with a testcase... A run test
ideally, if that isn't too hard?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95942
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96212
--- Comment #2 from Tobias Burnus ---
(In reply to Bill Seurer from comment #1)
> After running on a few more machines this appears to be a BE only issue.
alloc-1.F90 uses a proper interface (Fortran module). alloc-3.F uses a header
file with th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488
--- Comment #7 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #5)
> operands[2] needs an earlyclobber as well (it is written while some
> operands are still read later). Everything else is fine as far as I
> can see :-)
I o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488
--- Comment #8 from Peter Bergner ---
(In reply to Peter Bergner from comment #7)
> If you still want operands[2] marked early clobber, I can do that.
Segher set me straight offline on why we need that early clobber too.
I'll kick off testing wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96213
Bug ID: 96213
Summary: GCC doesn't complain about ill-formed non-dependent
template default argument
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87234
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82850
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96214
Bug ID: 96214
Summary: gcc warn unreached else {}
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39970
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96215
Bug ID: 96215
Summary: Wrong mangling for non-dependent return type involving
decltype(g.x) or decltype(p->x)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96216
Thomas Koenig changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96216
Bug ID: 96216
Summary: Gap in interface checking
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
A
84 matches
Mail list logo
