https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43798
--- Comment #18 from Zdenek Sojka ---
>From my (of course limited) experience, such behavior is unexpected by the
user. The user really wants:
typedef
struct __attribute__((aligned(16))) {
unsigned long long w[3];
} UINT192;
OR
typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90286
--- Comment #2 from tada at specyal dot com ---
There is no other compiler for Arduino.
On 4/29/2019 4:31 PM, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90286
>
> Andrew Pinski changed:
>
> What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078
--- Comment #12 from bin cheng ---
Author: amker
Date: Tue Apr 30 03:00:59 2019
New Revision: 270673
URL: https://gcc.gnu.org/viewcvs?rev=270673=gcc=rev
Log:
PR tree-optimization/90240
Revert:
2019-04-23 Bin Cheng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90240
--- Comment #9 from bin cheng ---
Author: amker
Date: Tue Apr 30 03:00:59 2019
New Revision: 270673
URL: https://gcc.gnu.org/viewcvs?rev=270673=gcc=rev
Log:
PR tree-optimization/90240
Revert:
2019-04-23 Bin Cheng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89721
--- Comment #4 from Peter Bergner ---
Segher, can we move this to Fixed now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273
--- Comment #23 from Alexandre Oliva ---
> what are the rules of which ones we can remove? Can we always just keep the
last? What about location differences? What about possibly interleaving
DEBUG_BEGIN stmts?
code insns and markers are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273
--- Comment #22 from Jan Hubicka ---
gcc 8 with debug info
real45m49.664s
user500m1.776s
sys 22m39.816s
llvm 7 with debug info
real43m43.798s
user447m36.028s
sys 10m13.512s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90287
Bug ID: 90287
Summary: [concepts] bogus error on overload failure inside
requires-expression
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90286
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87695
Andrew Pinski changed:
What|Removed |Added
CC||tada at specyal dot com
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90286
Bug ID: 90286
Summary: failure in arduino
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90285
Bug ID: 90285
Summary: Poor optimised codegen for memmove() back on top of
oneself
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
Eric Gallager changed:
What|Removed |Added
CC||glaubitz at physik dot
fu-berlin.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88696
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88696
--- Comment #2 from Bill Schmidt ---
Yes, we need a big clean-up on the documentation here. Presently working on a
better documentation vehicle for vector built-ins. Once that's done, we'll
have the GCC manual point to that instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89949
John Boyer changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69868
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90284
Bug ID: 90284
Summary: -Wunused-value points to the wrong expression
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271
--- Comment #8 from Eyal Rozenberg ---
(In reply to rguent...@suse.de from comment #5)
> int foo3()
> {
> struct { int x; int y; } s;
> s.x = 3;
> char c = 1;
> return replace_bytes_3(,c);
> }
>
> Coalescing successful!
> Merged into 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90272
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90096
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90282
--- Comment #2 from Andreas Schwab ---
Probably dup of bug 87281.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #15 from Jim Wilson ---
See also PR 87338 which has a response earlier today from John Paul Adrian
Glaubitz.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #14 from Jim Wilson ---
https://wiki.debian.org/Ports/ia64
James Clarke has been active recently on the binutils and/or gcc mailing lists.
My IA-64 work has dwindled down to nothing, as RISC-V work has kept me too
busy to do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89091
--- Comment #11 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #8)
> Well, for the decode_field_reference, I think it is essential not to change
> *exp_ if returning NULL, because the caller uses lr_arg/rr_arg without
> checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90278
Richard Biener changed:
What|Removed |Added
Known to work||10.0
Known to fail|10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90278
--- Comment #2 from Richard Biener ---
Author: rguenth
Date: Mon Apr 29 17:53:36 2019
New Revision: 270657
URL: https://gcc.gnu.org/viewcvs?rev=270657=gcc=rev
Log:
2019-04-29 Richard Biener
PR tree-optimization/90278
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90272
--- Comment #1 from Ian Lance Taylor ---
Thanks. To be clear, while of course the compiler should not crash, this is
not a valid Go program.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90283
Bug ID: 90283
Summary: 519.lbm_r is 7%-10% slower with -Ofast -march=native
and both LTO and PGO than with GCC 8
Product: gcc
Version: 9.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90282
--- Comment #1 from Jason Duerstock ---
Created attachment 46264
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46264=edit
gcc dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88709
--- Comment #3 from Jakub Jelinek ---
WIP:
--- gcc/gimple-ssa-store-merging.c.jj 2019-01-01 12:37:19.063943678 +0100
+++ gcc/gimple-ssa-store-merging.c 2019-04-29 19:02:55.992151104 +0200
@@ -1615,13 +1615,31 @@ encode_tree_to_bitpos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82081
--- Comment #9 from Jason Merrill ---
Author: jason
Date: Mon Apr 29 17:27:13 2019
New Revision: 270656
URL: https://gcc.gnu.org/viewcvs?rev=270656=gcc=rev
Log:
PR c++/82081 - tail call optimization breaks noexcept
If a noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90036
--- Comment #8 from Jeffrey A. Law ---
extern int sprintf (char *__restrict __s,
const char *__restrict __format, ...)
__attribute__ ((__nothrow__));
typedef int bfd_boolean;
struct stab_type_stack
{
long index;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90282
Bug ID: 90282
Summary: internal compiler error: qsort checking failed in
snapshot-20190429
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44435
--- Comment #8 from joseph at codesourcery dot com ---
I have not been tracking the state of review or lack thereof for these
patches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90036
--- Comment #7 from Jeffrey A. Law ---
Bah! Lost my reduced testcase...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149
--- Comment #10 from Roland Illig ---
(In reply to Richard Biener from comment #9)
> IMHO the error calls in our IL checkers are abusive, they could have been
> simple dumps to stderr for example. It was just "convenient" to use
> a disagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264
Roman Zhuykov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86172
Bug 86172 depends on bug 90264, which changed state.
Bug 90264 Summary: [9/10 Regression] -Wnull-dereference QoI issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273
--- Comment #21 from Jan Hubicka ---
I just built Firefox with GCC 9 branch and the updated patch. Debug enabled
build is:
real45m56.187s
user493m8.688s
sys 22m4.512s
compared to debug disabled build with GCC 9:
real35m5.141s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273
--- Comment #20 from Jakub Jelinek ---
Another report: https://gcc.gnu.org/ml/gcc/2019-04/msg00270.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782
Agner Fog changed:
What|Removed |Added
CC||agner at agner dot org
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90280
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149
Richard Biener changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90281
--- Comment #1 from Jonathan Wakely ---
The problem is that I'm using codecvt_utf8, which converts between
UTF-8 and UCS-2 (not UTF-16). The U+1D11E is outside the basic multilingual
plane, so is not valid UCS-2.
I need to use a different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271
--- Comment #7 from Jakub Jelinek ---
On the store-merging side
--- gimple-ssa-store-merging.c.jj 2019-01-01 12:37:19.063943678 +0100
+++ gimple-ssa-store-merging.c 2019-04-29 16:45:38.333266338 +0200
@@ -4164,7 +4164,8 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 90257, which changed state.
Bug 90257 Summary: [10 Regression] 8% degradation on cpu2006 403.gcc starting
with r270484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90178
Bug 90178 depends on bug 90257, which changed state.
Bug 90257 Summary: [10 Regression] 8% degradation on cpu2006 403.gcc starting
with r270484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257
Jakub Jelinek changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90281
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90050
Matthias Klose changed:
What|Removed |Added
CC||doko at debian dot org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90260
Martin Liška changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90260
--- Comment #2 from Nikolay Bogoychev ---
Hey Martin,
I know clang doesn't support that. I have opened a separate bug report there
https://bugs.llvm.org/show_bug.cgi?id=41613
Based on some discussions on their mailing lists, it seems like this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90281
Bug ID: 90281
Summary: utf-8 encoded std::filesystem::path can not be
converted to utf-16.
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
-prefix=/repo/gcc-trunk//binary-trunk-270639-checking-yes-rtl-df-extra-armv7a-hardfloat
Thread model: posix
gcc version 10.0.0 20190429 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90036
--- Comment #6 from Segher Boessenkool ---
(In reply to Martin Sebor from comment #5)
> A conversion specification is what follows the % character (i.e., just the
> 's' in in something like "%3s", with the 's' being called a conversion
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149
--- Comment #8 from Martin Sebor ---
(In reply to Richard Biener from comment #6)
The trouble is that there is no way to tell whether
error ("BIT_FIELD_REF of non-mode-precision operand");
is a user-facing error or an internal error not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90178
--- Comment #11 from Jakub Jelinek ---
Author: jakub
Date: Mon Apr 29 14:18:55 2019
New Revision: 270653
URL: https://gcc.gnu.org/viewcvs?rev=270653=gcc=rev
Log:
PR rtl-optimization/90257
* cfgrtl.c (flow_active_insn_p): Return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257
--- Comment #16 from Jakub Jelinek ---
Author: jakub
Date: Mon Apr 29 14:18:55 2019
New Revision: 270653
URL: https://gcc.gnu.org/viewcvs?rev=270653=gcc=rev
Log:
PR rtl-optimization/90257
* cfgrtl.c (flow_active_insn_p): Return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90036
--- Comment #5 from Martin Sebor ---
(In reply to Dmitry G. Dyachenko from comment #3)
The null pointer detection was added in r265648 so that would be the change
responsible for the warning. As Jeff noted, the root cause of false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #18 from Wilco ---
(In reply to Martin Liška from comment #14)
> Created attachment 46262 [details]
> Patch candidate
>
> Patch candidate that handles:
>
> $ cat ~/Programming/testcases/mempcpy.c
> int *mempcopy2 (int *p, int *q,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257
--- Comment #15 from Jakub Jelinek ---
I have tried:
--- gcc/cfgrtl.c(revision 270605)
+++ gcc/cfgrtl.c(working copy)
@@ -557,7 +557,8 @@ flow_active_insn_p (const rtx_insn *insn
keep the return value from being live across
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87982
--- Comment #11 from Jonathan Wakely ---
Addressed in r270651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90270
--- Comment #12 from rguenther at suse dot de ---
On Mon, 29 Apr 2019, amker at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90270
>
> --- Comment #10 from bin cheng ---
> (In reply to Richard Biener from comment #9)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71312
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #17 from Wilco ---
(In reply to Wilco from comment #16)
> (In reply to Martin Sebor from comment #15)
> > I just noticed I have been misreading mempcpy as memccpy and so making no
> > sense. Sorry about that! Please ignore my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273
--- Comment #19 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #18)
> (In reply to rsand...@gcc.gnu.org from comment #17)
> > Created attachment 46261 [details]
> > Doing the removal in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #16 from Wilco ---
(In reply to Martin Sebor from comment #15)
> I just noticed I have been misreading mempcpy as memccpy and so making no
> sense. Sorry about that! Please ignore my comments.
I see, yes we have too many and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87982
--- Comment #10 from Jan van Dijk ---
Thanks a lot. And sorry for being pedantic, but I believe that the
documentation of the return value of generate_n is still wrong for negative __n
(see the first part of comment #5).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #15 from Martin Sebor ---
I just noticed I have been misreading mempcpy as memccpy and so making no
sense. Sorry about that! Please ignore my comments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90279
Bug ID: 90279
Summary: DW_AT_location missing for struct-based Variable
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #14 from Martin Liška ---
Created attachment 46262
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46262=edit
Patch candidate
Patch candidate that handles:
$ cat ~/Programming/testcases/mempcpy.c
int *mempcopy2 (int *p, int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90260
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90278
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71312
--- Comment #2 from Jonathan Wakely ---
Author: redi
Date: Mon Apr 29 12:55:29 2019
New Revision: 270649
URL: https://gcc.gnu.org/viewcvs?rev=270649=gcc=rev
Log:
PR libstdc++/71312 Increase alignment of pooled mutexes
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #13 from Martin Sebor ---
I mean an equivalent of the following (with suitable symbol linkage):
void* memccpy (void *d, const void *s, int c, size_t n)
{
// efficient memccpy, perhaps in assembly
}
void* memcpy (void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90278
Bug ID: 90278
Summary: ICE: verify_gimple failed (error: statement marked for
throw, but doesn't)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90249
--- Comment #8 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #7)
> (In reply to Segher Boessenkool from comment #4)
> > That is code *size*. Code size is expected to grow a tiny bit, because of
> > *better* register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90249
--- Comment #7 from Richard Earnshaw ---
(In reply to Segher Boessenkool from comment #4)
> That is code *size*. Code size is expected to grow a tiny bit, because of
> *better* register allocation.
>
> But we could not do make_more_copies at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273
--- Comment #18 from Richard Biener ---
(In reply to rsand...@gcc.gnu.org from comment #17)
> Created attachment 46261 [details]
> Doing the removal in find_obviously_necessary_stmts
>
> Just for the record: I'd written this over the weekend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90249
--- Comment #6 from Segher Boessenkool ---
(In reply to Wilco from comment #5)
> (In reply to Segher Boessenkool from comment #4)
> > That is code *size*. Code size is expected to grow a tiny bit, because of
> > *better* register allocation.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90249
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #12 from Wilco ---
(In reply to Martin Sebor from comment #11)
> My concern is that transforming memccpy to memcpy would leave little
> incentive for libraries like glibc to provide a more optimal implementation.
> Would implementing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90275
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90249
--- Comment #4 from Segher Boessenkool ---
That is code *size*. Code size is expected to grow a tiny bit, because of
*better* register allocation.
But we could not do make_more_copies at -Os, if that helps? (The hard register
changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276
--- Comment #1 from Jonathan Wakely ---
Lots of others fail too:
make check RUNTESTFLAGS=conformance.exp="*/pstl/* \
--target_board=unix/-D_GLIBCXX_DEBUG"
...
FAIL: 20_util/specialized_algorithms/pstl/uninitialized_copy_move.cc execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87982
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87982
--- Comment #8 from Jonathan Wakely ---
Author: redi
Date: Mon Apr 29 12:12:43 2019
New Revision: 270646
URL: https://gcc.gnu.org/viewcvs?rev=270646=gcc=rev
Log:
PR libstdc++/87982 Fix generate_n and fill_n use of _Size parameter
The standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90277
Bug ID: 90277
Summary: Debug Mode test failures
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #11 from Martin Sebor ---
My concern is that transforming memccpy to memcpy would leave little incentive
for libraries like glibc to provide a more optimal implementation. Would
implementing the function simply as memcpy and having
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #10 from Martin Liška ---
(In reply to Wilco from comment #6)
> (In reply to Martin Liška from comment #5)
> > The discussion looks familiar to me. Isn't that PR70140, where I was
> > suggesting something like:
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276
Bug ID: 90276
Summary: FAIL:
20_util/specialized_algorithms/pstl/uninitialized_copy
_move.cc execution test
Product: gcc
Version: 9.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90252
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273
--- Comment #16 from Richard Biener ---
Created attachment 46260
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46260=edit
removed-unused-local patch
There do appear to be variables that are just appearing in # DEBUG var => NULL
stmts,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273
--- Comment #15 from Richard Biener ---
And it's indeed "caused" by the CFG-cleanup fixes. The DCE patch gets us back
to (nearly) the same number of debug stmts as before.
oat-linux-gnueabi-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-270639-checking-yes-rtl-df-extra-armv7a-hardfloat
Thread model: posix
gcc version 10.0.0 20190429 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86984
John Paul Adrian Glaubitz changed:
What|Removed |Added
CC||glaubitz at physik dot
1 - 100 of 130 matches
Mail list logo
