https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #8 from Markus F.X.J. Oberhumer ---
Got it, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95830
--- Comment #6 from Martin Liška ---
Thanks for reduction, I can confirm that. What happens:
mips-ps-5.c.171t.loopdone:
_34 = vect__1.7_28 == vect__3.11_33;
vect_iftmp.12_35 = VEC_COND_EXPR <_34, vect__1.7_28, vect__2.10_31>;
which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95897
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:5b959c22bc0158faa359a5899bf46e815dc65290
commit r11-1671-g5b959c22bc0158faa359a5899bf46e815dc65290
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95897
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #7 from Jakub Jelinek ---
I believe all arrays larger than half of the address space are outside of the
standard already, one can't perform e.g. address arithmetics on those because
it overflows the ptrdiff_t in which it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95907
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2020-06-26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95907
Bug ID: 95907
Summary: ICE in unrecognizable insn
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #6 from Markus F.X.J. Oberhumer ---
Thanks for the quick fix!
And no need to be grumpy, I'm just trying to nail down those pesky edge
cases...
As for ILP32, here is another suspicious test case, now only using just a
little bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95809
--- Comment #3 from Haoxin Tu ---
(In reply to Nathan Sidwell from comment #2)
> yup, dr2061 made that ill-formed.
>
> p1701 (wg21.link/p1701) documents the behaviour and it appears EWG is
> exploring another avenue to resolve the underlying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95892
--- Comment #3 from Haoxin Tu ---
(In reply to Jonathan Wakely from comment #1)
> This is a well-known issue where diagnostics in function parameter-lists all
> have the location of the closing brace.
Thank you, Jonathan.
I guess bug 95831
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86568
Jonathan Wakely changed:
What|Removed |Added
CC||haoxintu at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86568
--- Comment #4 from Jonathan Wakely ---
PR 95892 points out the -Wsign-conversion warnings below all have the location
of the closing parenthesis:
unsigned int var = 10;
void foo (
int a = var,
int b = var,
int c = var )
{}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95892
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95892
--- Comment #1 from Jonathan Wakely ---
This is a well-known issue where diagnostics in function parameter-lists all
have the location of the closing brace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #5 from Jakub Jelinek ---
Created attachment 48788
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48788=edit
gcc11-pr95903.patch
Untested fix. I don't really care what clang generates or what you find
expected on ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95830
Paul Hua changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #4 from Markus F.X.J. Oberhumer ---
Yes, ilp32 might be a corner case.
Still, clang-10 does create the expected code.
See https://gcc.godbolt.org/z/aEokbX for
clang-10 -target arm64_32-ios -O2 -fomit-frame-pointer -fwrapv
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #3 from Jakub Jelinek ---
For ilp32 I'm not convinced it is a bug, the address space needs to be 32-bit
only and for this to cause problems, you need a 4GB+ element array with the
pointer pointing into the middle of it such that both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #2 from Markus F.X.J. Oberhumer ---
Somewhat related: the same code compiled with arm64-gcc -mabi=ilp32 -frwapv
does miscompile *both* functions.
See https://gcc.godbolt.org/z/uxDAtx
Should I open a new issue for this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95900
Christophe Lyon changed:
What|Removed |Added
Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95900
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95897
--- Comment #2 from Richard Biener ---
Testcase that also triggers on x86_64 and without graphite:
double foo (double x, int n)
{
double s = 0.;
for (int i = 0; i < n; ++i)
{
s += x;
s += x;
s += x;
}
return s;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95906
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95900
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
Summary|New test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95899
--- Comment #3 from Richard Biener ---
The register allocator cannot always recover so it can lead to spilling.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95897
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Last
101 - 127 of 127 matches
Mail list logo
