https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94611
Richard Biener changed:
What|Removed |Added
CC||iant at google dot com
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94612
Bug ID: 94612
Summary: Failed to build simple examples with offloading.
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94571
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e4658c7dbbe88f742c96e5f58ee4a6d549d642ca
commit r10-7745-ge4658c7dbbe88f742c96e5f58ee4a6d549d642ca
Author: Jakub Jelinek
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #20 from Steve Kargl ---
On Thu, Apr 16, 2020 at 01:10:21AM +, dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
>
> --- Comment #18 from dave.anglin at bell dot net ---
> On 2020-04-15 2:14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #19 from dave.anglin at bell dot net ---
On 2020-04-15 2:32 p.m., sgk at troutmask dot apl.washington.edu wrote:
> On Wed, Apr 15, 2020 at 06:04:08PM +, dave.anglin at bell dot net wrote:
>> /usr/lib/dld.sl: Unresolved symbol: strt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #18 from dave.anglin at bell dot net ---
On 2020-04-15 2:14 p.m., sgk at troutmask dot apl.washington.edu wrote:
> What does -fdump-tree-original show for
>
> function foo(x)
>real(16) foo, x
>foo = cos(x)
> end function foo
fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94611
Bug ID: 94611
Summary: gccgo hangs (infinite loop) on complex projects,
seemingly in simplify-rtx.c/simplify_plus_minus
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94609
--- Comment #11 from Iain Buclaw ---
(In reply to H.J. Lu from comment #9)
>
> I tested with glibc 2.30 with fix for
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=25810
>
Nice, though currently the library testsuite is compiled at -O0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94609
--- Comment #10 from H.J. Lu ---
core.exception.RangeError@/export/gnu/import/git/gitlab/x86-gcc/libphobos/testsuite/../src/std/algorithm/mutation.d(1518):
Range violation
/export/gnu/import/git/gitlab/x86-gcc/libphobos/libdrunti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94609
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #23 from Segher Boessenkool ---
(cannot_substitute_mem_equiv_p,
"A target hook which returns @code{true} if @var{subst} can't\n\
substitute safely pseudos with equivalent memory values during\n\
register allocation.\n\
I guess "ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #13 from Jeffrey A. Law ---
Sigh. That code is good in that it's rejecting matching the pattern for the
SImode sign bit that we can't implement. For some dumb reason I was thinking
it was changing how we split, but it's actually th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94610
Bug ID: 94610
Summary: 'invalid use of incomplete type' error which show an
alias, but without the real type
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94600
--- Comment #8 from Hans-Peter Nilsson ---
(In reply to jos...@codesourcery.com from comment #7)
> The Arm AAPCS has detailed rules for operations on individual volatile
> bit-fields, but not for this case where the whole struct is volatile and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #22 from Peter Bergner ---
To be more specific, I have implemented the hook cannot_substitute_mem_equiv_p
for rs6000 that rejects these and: altivec addresses. The nice thing about the
patch is that it only affects rs6000, whereas a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94600
--- Comment #7 from joseph at codesourcery dot com ---
The Arm AAPCS has detailed rules for operations on individual volatile
bit-fields, but not for this case where the whole struct is volatile and
the operation is on the whole struct. I thin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94603
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94603
--- Comment #9 from CVS Commits ---
The releases/gcc-8 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:06d6120b7a5621d584bd0c861bc94096cc8b60b7
commit r8-10183-g06d6120b7a5621d584bd0c861bc94096cc8b60b7
Author: Uros Bizjak
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94584
--- Comment #4 from CVS Commits ---
The releases/gcc-9 branch has been updated by Max Filippov
:
https://gcc.gnu.org/g:79b59676531631331b9353107f7d40c887852433
commit r9-8501-g79b59676531631331b9353107f7d40c887852433
Author: Max Filippov
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91880
--- Comment #7 from CVS Commits ---
The releases/gcc-9 branch has been updated by Max Filippov
:
https://gcc.gnu.org/g:20c6c0c8b18ae1bb3582456085e98cb50ab5854a
commit r9-8500-g20c6c0c8b18ae1bb3582456085e98cb50ab5854a
Author: Max Filippov
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91880
--- Comment #6 from CVS Commits ---
The releases/gcc-8 branch has been updated by Max Filippov
:
https://gcc.gnu.org/g:87c1bfebcdda50ff8964a07c9963823de43de65a
commit r8-10181-g87c1bfebcdda50ff8964a07c9963823de43de65a
Author: Max Filippov
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94584
--- Comment #3 from CVS Commits ---
The releases/gcc-8 branch has been updated by Max Filippov
:
https://gcc.gnu.org/g:f45b87f786809997d2f8d418ab10de6640149422
commit r8-10182-gf45b87f786809997d2f8d418ab10de6640149422
Author: Max Filippov
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94609
--- Comment #8 from Iain Buclaw ---
(In reply to H.J. Lu from comment #6)
> (In reply to Iain Buclaw from comment #5)
> > The struct is built as a POD type. As the struct is nested, it should be
> > considered non-POD, otherwise it gets left up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94609
--- Comment #7 from Iain Buclaw ---
I'm initially considering the following:
--- a/gcc/d/types.cc
+++ b/gcc/d/types.cc
@@ -915,7 +915,7 @@ public:
/* For structs with a user defined postblit or a destructor,
also set TREE_ADDRESSABL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94558
Joseph S. Myers changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94609
--- Comment #6 from H.J. Lu ---
(In reply to Iain Buclaw from comment #5)
> The struct is built as a POD type. As the struct is nested, it should be
> considered non-POD, otherwise it gets left up to aggregate_value_p to decide
> how to pass it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94609
--- Comment #5 from Iain Buclaw ---
The struct is built as a POD type. As the struct is nested, it should be
considered non-POD, otherwise it gets left up to aggregate_value_p to decide
how to pass it around.
i386 returns true from aggregate_va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94609
--- Comment #4 from Iain Buclaw ---
(In reply to H.J. Lu from comment #2)
>
> RDI/EDI isn't used to pass argument. Is this done on purpose? Where does
> D frontend decide how to pass argument?
Ultimately the main deciding factor is whether or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94609
--- Comment #3 from Iain Buclaw ---
And indeed, comparing -mx32 vs -m32, NRVO is not kicking in.
test52a ()
{
- struct Scoped result;
+ struct Scoped result [value-expr: *];
typedef struct Scoped Scoped;
...
struct Scoped a1;
- a1 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94609
--- Comment #2 from H.J. Lu ---
LP64 has:
(gdb) disass _D8runnable6test52FZv
Dump of assembler code for function _D8runnable6test52FZv:
0x0040943a <+0>: push %rbp
0x0040943b <+1>: mov%rsp,%rbp
0x004
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94609
--- Comment #1 from Iain Buclaw ---
This assertion is triggered when a copy is not elided as it should be.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94607
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #21 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #20)
> Have you managed to make some progress? This is one of the last 10 P1
> blockers of the release.
I'm still working on it. I have a patch that fixes the issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94603
--- Comment #8 from CVS Commits ---
The releases/gcc-9 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:1eccf9955614a6f0597bf624bbc88788b8b0fdc5
commit r9-8499-g1eccf9955614a6f0597bf624bbc88788b8b0fdc5
Author: Uros Bizjak
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94607
--- Comment #4 from CVS Commits ---
The master branch has been updated by Ian Lance Taylor :
https://gcc.gnu.org/g:eef00439e6723e089e74cd374474e0eac0a9f513
commit r10-7741-geef00439e6723e089e74cd374474e0eac0a9f513
Author: Ian Lance Taylor
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93628
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-04-15
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93793
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94049
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #17 from dave.anglin at bell dot net ---
On 2020-04-15 2:32 p.m., sgk at troutmask dot apl.washington.edu wrote:
> On Wed, Apr 15, 2020 at 06:04:08PM +, dave.anglin at bell dot net wrote:
>> /usr/lib/dld.sl: Unresolved symbol: strt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #16 from dave.anglin at bell dot net ---
On 2020-04-15 2:14 p.m., sgk at troutmask dot apl.washington.edu wrote:
> It likely is the start of an approach, but it seems hpux is conflating
> long double and __float128, where it flips bet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94609
Bug ID: 94609
Summary: FAIL: gdc.dg/runnable.d
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #15 from Steve Kargl ---
On Wed, Apr 15, 2020 at 06:04:08PM +, dave.anglin at bell dot net wrote:
>
> /usr/lib/dld.sl: Unresolved symbol: strtoflt128 (data) from
This should be in libquadmath.
% nm /usr/home/kargl/work/lib/lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315
--- Comment #13 from Richard Biener ---
(In reply to Richard Biener from comment #12)
> Created attachment 48279 [details]
> patch
>
> Patch forward ported to current trunk.
Surprisingly small fallout:
FAIL: gcc.dg/tree-ssa/split-path-7.c scan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #14 from Steve Kargl ---
On Wed, Apr 15, 2020 at 03:28:29PM +, dave.anglin at bell dot net wrote:
>
> On 2020-04-15 11:02 a.m., sgk at troutmask dot apl.washington.edu wrote:
> >
> > #if defined(HAVE_GFC_REAL_16)
> > # if define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #13 from dave.anglin at bell dot net ---
On 2020-04-15 11:28 a.m., John David Anglin wrote:
> I tried the above approach yesterday but it led to a couple of undefined
> symbols in libgfortran that
> caused a new test fail.
The followi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94049
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94592
--- Comment #7 from Marek Polacek ---
Another problematical testcase:
struct A {
int i;
constexpr A(int n) : i(n) {}
};
template struct B { int i; constexpr B() : i(a.i) { } };
template void bar () {
B<{1}> var;
}
void fu() {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #12 from Jakub Jelinek ---
(In reply to Jeffrey A. Law from comment #11)
> Rather than extending that hack, I think just widening the mode when the
> sign bit is being tested (c#5) is simpler and easier to understand. The
> bits you'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94608
Nathan Sidwell changed:
What|Removed |Added
Last reconfirmed||2020-04-15
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #11 from Jeffrey A. Law ---
Rather than extending that hack, I think just widening the mode when the sign
bit is being tested (c#5) is simpler and easier to understand. The bits you're
changing should be killed rather than extended t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #10 from Jakub Jelinek ---
So something like:
--- gcc/config/i386/i386.md.jj 2020-03-16 22:56:55.556043275 +0100
+++ gcc/config/i386/i386.md 2020-04-15 19:07:04.405933639 +0200
@@ -8732,8 +8732,20 @@
&& ix86_match_ccmode (ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94608
Bug ID: 94608
Summary: Fix for PR94426 causes a regression in
g++.dg/lto/pr83720 on arm
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94568
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94570
jon_y <10walls at gmail dot com> changed:
What|Removed |Added
Attachment #48281|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008
Akim Demaille changed:
What|Removed |Added
CC||akim.demaille at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94568
--- Comment #1 from Martin Sebor ---
Another test case, this one not involving pointers. Somehow the form of the
initializer (= 0 vs { }) makes a difference.
$ cat t.C && gcc -O2 -c -Wall -std=c++2a t.C
template struct D { };
constexpr const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94192
--- Comment #5 from CVS Commits ---
The master branch has been updated by Fritz Reese :
https://gcc.gnu.org/g:49795733fdcc3a804dab59b63f86d5ebe4541374
commit r10-7738-g49795733fdcc3a804dab59b63f86d5ebe4541374
Author: Fritz Reese
Date: Wed Ap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
--- Comment #8 from Jakub Jelinek ---
I'd like to ping this, it would be nice to at least decide if this should be
handled for GCC10 or postponed to GCC11 only.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94598
--- Comment #4 from Martin Jambor ---
I proposed the fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543909.html
(Note that the one in comment #3 has a small but important typo.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #12 from dave.anglin at bell dot net ---
On 2020-04-15 11:02 a.m., sgk at troutmask dot apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
>
> --- Comment #11 from Steve Kargl ---
> On Tue, Apr 14, 2020 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94603
--- Comment #7 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:d4f655724c6e19ef0aeb5ac9e8d04abd962ccde7
commit r10-7737-gd4f655724c6e19ef0aeb5ac9e8d04abd962ccde7
Author: Uros Bizjak
Date: Wed Ap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #11 from Steve Kargl ---
On Tue, Apr 14, 2020 at 11:46:36PM +, dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
>
> --- Comment #10 from dave.anglin at bell dot net ---
> On 2020-04-14 6:08
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91153
--- Comment #4 from Bill Schmidt ---
Perfect, thanks! I'll take it off my concern list...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #23 from Jakub Jelinek ---
Eventually yes, but I'd like to test & submit the above patch too and let it be
tested on the trunk for a while before backporting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94557
--- Comment #3 from Michael Meissner ---
Just to be clear, this bug are only bugs in the GCC 9 branch, and it came about
due to the back port of the patch for PR target/93932 to the GCC 9 branch. The
master branch generates correct code. So, I'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89657
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |10.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91153
--- Comment #3 from Jonathan Wakely ---
It's just a buggy test, the code in the library is fine. I'll fix the test for
GCC 10 if I get a chance, but it's not a priority.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94607
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #22 from Piotr Kubaj ---
(In reply to CVS Commits from comment #21)
> The master branch has been updated by Jakub Jelinek :
>
> https://gcc.gnu.org/g:c00568f376078129196740d83946d54dc5437401
>
> commit r10-7736-gc00568f3760781291967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94598
--- Comment #3 from Martin Jambor ---
I'm going to test the following:
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -2357,9 +2357,11 @@ verify_sra_access_forest (struct access *root)
gcc_assert (base == first_base);
gcc_assert (off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91153
--- Comment #2 from Jakub Jelinek ---
Only bugs that are marked as [... Regression] and have corresponding Target
Milestone are classified that way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359
--- Comment #16 from Andreas Schwab ---
crtl != cfun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91153
Bill Schmidt changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94607
--- Comment #2 from David Binderman ---
Only -O2 -fprefetch-loop-arrays is needed to trigger the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #21 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c00568f376078129196740d83946d54dc5437401
commit r10-7736-gc00568f376078129196740d83946d54dc5437401
Author: Gustavo Romero
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94607
--- Comment #1 from Richard Biener ---
Possibly just -fprefetch-loop-arrays is required then (not really maintained,
not really used)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94607
Bug ID: 94607
Summary: ice in execute_todo, at passes.c:2034
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Hi,
should be fixed now by 8a4436d89bfa:
"aarch64: Fix valid_src_p for use of uninitialized value".
Thanks
Andrea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94530
--- Comment #7 from Andrea Corallo ---
Hi,
should be fixed now by 8a4436d89bfa:
"aarch64: Fix valid_src_p for use of uninitialized value".
Thanks
Andrea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359
--- Comment #15 from Iain Sandoe ---
(In reply to Andreas Schwab from comment #14)
> That completely breaks aarch64 (almost every coroutines test):
apologies,
do you have any immediate idea why the aarch64_function_ok_for_sibcall
is failing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94606
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94570
--- Comment #9 from jon_y <10walls at gmail dot com> ---
if defined(__MSDOS__) || (defined(_WIN32) && ! defined(__CYGWIN__) ||
defined(__OS2__)
I've tested the above and confirmed that coverage.ii does have the correct
separator after updating fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #43 from Mark Wielaard ---
It looks there is now some support for a symver function attribute. But it only
accepts the single and double @ forms. This makes things a little awkward when
using a symbol foo itself for foo@@DEFAULT_VERSI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94606
Bug ID: 94606
Summary: [10 Regression] ICE creating fixed-length SVE
predicate
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94606
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94570
--- Comment #8 from jon_y <10walls at gmail dot com> ---
I forgot to mention that while Cygwin runs on Windows, applications should
always use UNIX style paths.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94570
--- Comment #7 from jon_y <10walls at gmail dot com> ---
Created attachment 48281
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48281&action=edit
Alternate patch
I'm not sure if ltmain.sh is shared in the cygnus tree, but this patch should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #20 from Jakub Jelinek ---
So, we are running into PR33916 here, not very much reduced test:
class function_arg_info
{
public:
function_arg_info ()
: type (0), mode (0), named (false), pass_by_reference (false)
{}
function_a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359
--- Comment #14 from Andreas Schwab ---
That completely breaks aarch64 (almost every coroutines test):
spawn -ignore SIGHUP /opt/gcc/gcc-20200415/Build/gcc/testsuite/g++/../../xg++
-B/opt/gcc/gcc-20200415/Build/gcc/testsuite/g++/../../
/opt/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2020-04-15
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94570
--- Comment #6 from Martin Liška ---
(In reply to John Selbie from comment #5)
> > All right, so it's normal Unix file system. Can you please show me output
> of the 'pwd' command?
>
> jselbie@IRONMAIDEN ~/bench
> $ pwd
> /home/jselbie/bench
Wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94605
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94566
--- Comment #3 from Marc Glisse ---
I thought we had code to recognize a switch that represents a linear function,
I was hoping that it would kick in with your hoisting patch...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94605
Bug ID: 94605
Summary: [8/9/10 Regression] ICE in early-remat.c:process_block
with multi-output asms
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315
--- Comment #12 from Richard Biener ---
Created attachment 48279
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48279&action=edit
patch
Patch forward ported to current trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94566
Richard Biener changed:
What|Removed |Added
Blocks|11832, 33315|
Depends on|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94598
--- Comment #2 from Martin Jambor ---
For arrays of size 1, get_ref_base_and_extent knows that the expression can
only access the one element even if the index is a variable. It seems it does
not happen if the ARRAY_REF is within a COMPONENT_REF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94103
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94206
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
1 - 100 of 131 matches
Mail list logo
