https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #10 from Andrew Pinski ---
(In reply to Alexander Monakov from comment #8)
> I think the following testcase indicates that GCC assumes that tail padding
> is accessible:
Well it aligned accesses are always accessable
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #9 from Martin Uecker ---
Clang as well, but that would be only padding inside the first part without
taking into account extra element in the FAM.
I am more concert about programmers using the formula sizeof(.) + n * sizeof
for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90504
--- Comment #2 from Janne Blomqvist ---
(In reply to anlauf from comment #1)
> (In reply to Janne Blomqvist from comment #0)
> > Hanson, Hopkins, Remark on Algorithm 539: A Modern Fortran Reference
> > Implementation for Carefully Computing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959
--- Comment #4 from Andrew Pinski ---
Note the underlaying issue with VRP is similar to PR 109959 but it is about a
slightly different optimization though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
--- Comment #5 from Rimvydas (RJ) ---
(In reply to anlauf from comment #4)
> Can you check if this works for you?
This patch allows to avoid issue on all other associate use cases (tried on
gcc-13 branch).
However it is a bit suspicious that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109960
--- Comment #4 from Andrew Pinski ---
I happened to notice this because I am working on a match patch that transform
`a ? 1 : b` into `a | b`.
In the case of stmt_can_terminate_bb_p, I noticed we had:
[local count: 330920071]:
_48 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100106
--- Comment #10 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:d6b756447cd58bcca20e6892790582308b869817
commit r14-1187-gd6b756447cd58bcca20e6892790582308b869817
Author: Alexandre Oliva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109933
--- Comment #9 from Rory Bolt ---
Created attachment 55153
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55153=edit
patch
Tested fix for big endian, NOT tested on little endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109960
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109961
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|storage size of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109960
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-05-25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109961
Bug ID: 109961
Summary: storage size of 'variable name' isn't known
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109960
--- Comment #1 from Andrew Pinski ---
We could have a pattern that does:
`(a & CST) != 0 ? 1: (bool)a` -> `a & (CST|1) != 0` to fix this I think.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109960
Andrew Pinski changed:
What|Removed |Added
Known to work||8.5.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109960
Bug ID: 109960
Summary: [10/11/12/13/14 Regression] missing combining of
`(a&1) != 0 || (a&2)!=0` into `(a&3)!=0`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #18 from Stan Johnson ---
$ git clone git://gcc.gnu.org/git/gcc.git
$ cd gcc
$ git checkout master
I'm testing a manual bootstrap of "gcc version 14.0.0 20230524 (experimental)
(GCC)" now, accessed via git as s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959
--- Comment #3 from Andrew Pinski ---
here is another related testcase but this was the exactly reduced one from
bitmap_single_bit_set_p :
```
_Bool f(unsigned a, int t)
{
void g(void);
if (t)
return 0;
g();
if (a > 1)
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959
--- Comment #2 from Andrew Pinski ---
I should note I found this while looking at code generation of
bitmap_single_bit_set_p after a match pattern addition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959
Andrew Pinski changed:
What|Removed |Added
Summary|`(a > 1) ? 0 : (a == 1)` is |`(a > 1) ? 0 : (a == 1)` is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959
Bug ID: 109959
Summary: `(a > 1) ? 0 : (a == 1)` is not optimized when spelled
out
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #7 from joseph at codesourcery dot com ---
I suppose the question is how to interpret "the longest array (with the
same element type) that would not make the structure larger than the
object being accessed". The difficulty of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #6 from joseph at codesourcery dot com ---
For the standard, dynamically allocated case, you should only need to
allocate enough memory to contain the initial part of the struct and the
array members being accessed - not any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107986
--- Comment #9 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:1cd5bc387c453126fdb4c9400096180484ecddee
commit r14-1179-g1cd5bc387c453126fdb4c9400096180484ecddee
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107822
--- Comment #6 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:1cd5bc387c453126fdb4c9400096180484ecddee
commit r14-1179-g1cd5bc387c453126fdb4c9400096180484ecddee
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109947
Martin Seemann changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90504
--- Comment #1 from anlauf at gcc dot gnu.org ---
(In reply to Janne Blomqvist from comment #0)
> Hanson, Hopkins, Remark on Algorithm 539: A Modern Fortran Reference
> Implementation for Carefully Computing the Euclidean Norm,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87270
--- Comment #6 from anlauf at gcc dot gnu.org ---
All current compilers seem to give the same, apparently correct result,
even with different optimization level.
So can we close this finally?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876
--- Comment #9 from Jason Merrill ---
(In reply to Marek Polacek from comment #8)
> > Instead, we should probably treat num as value-dependent even though it
> > actually isn't.
>
> An attempt to implement that:
>
> --- a/gcc/cp/pt.cc
> +++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #5 from Martin Uecker ---
Clang bug:
https://github.com/llvm/llvm-project/issues/62929
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109947
--- Comment #4 from Jonathan Wakely ---
(In reply to Martin Seemann from comment #3)
> So it comes down to how to interpret the "Effects:" clause: Does "Equivalent
> to " mean that all restrictions of
> `value()` apply transitively or is it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876
--- Comment #8 from Marek Polacek ---
> Instead, we should probably treat num as value-dependent even though it
> actually isn't.
An attempt to implement that:
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -27969,6 +27969,12 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104350
--- Comment #4 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:ec2e86274427a402d2de2199ba550f7295ea9b5f
commit r14-1175-gec2e86274427a402d2de2199ba550f7295ea9b5f
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103794
--- Comment #3 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:5fd5d8fb744fd9251d04e4b17d04f2340e6a283b
commit r14-1174-g5fd5d8fb744fd9251d04e4b17d04f2340e6a283b
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #13 from CVS Commits ---
The releases/gcc-12 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:2b502c3119c91fe3ba2313f0842a3bedd395bc91
commit r12-9651-g2b502c3119c91fe3ba2313f0842a3bedd395bc91
Author: Matthias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
--- Comment #10 from CVS Commits ---
The releases/gcc-12 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:ff7360dafe209b960535eaaa3efcfbaaa44daff9
commit r12-9652-gff7360dafe209b960535eaaa3efcfbaaa44daff9
Author: Matthias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #12 from CVS Commits ---
The releases/gcc-12 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:8be71168f7bbafa04f592a7524432351ffea71ba
commit r12-9650-g8be71168f7bbafa04f592a7524432351ffea71ba
Author: Matthias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
--- Comment #9 from CVS Commits ---
The master branch has been updated by Matthias Kretz :
https://gcc.gnu.org/g:efd2b55d8562c6e80cb7ee8b9b1f9418f0c00cd9
commit r14-1173-gefd2b55d8562c6e80cb7ee8b9b1f9418f0c00cd9
Author: Matthias Kretz
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109947
--- Comment #3 from Martin Seemann ---
Thanks for pointing me to the LWG issue. It makes sense that the error type
must be copyable for the `value()` overloads due to potentially throwing a
`bad_expected_access` with the embedded error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #4 from Martin Uecker ---
The concern would be that a program relying on the size of an object being
larger may then have out of bounds accesses. But rereading the standard, I am
also not not seeing that this is required. (for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104350
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
--- Comment #6 from Georg-Johann Lay ---
Created attachment 55152
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55152=edit
diff testcase by v4.9.2 vs v5.2.1
Code from v4.9.2 is correct, but from v5.2.1 is bogus:
--- fail1-4.9.2.sx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109958
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109958
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109958
Bug ID: 109958
Summary: ICE: in build_ptrmem_type, at cp/decl.cc:11066 taking
the address of bound static member function brought
into derived class by using-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
--- Comment #4 from anlauf at gcc dot gnu.org ---
The following patch fixes NULL pointer dereference with the reduced
testcases:
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 83e45f1b693..89c62b3eb1e 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #3 from Pascal Cuoq ---
@Andrew Pinski
You don't even need to invoke the fact that this is an extension. GCC could
reserve 17 bytes for each variable i of type “int”, and as long as “sizeof i”
continued to evaluate to 4 (4 being
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594
Joseph changed:
What|Removed |Added
CC||schuchart at icl dot utk.edu
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109957
Bug ID: 109957
Summary: Missing loop PHI optimization
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to Rimvydas (RJ) from comment #1)
> More trivial testcase resulting in similar ICE.
Yep, even smaller:
subroutine foo(k_2d)
implicit none
integer :: k_2d(:)
integer :: i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
--- Comment #1 from Rimvydas (RJ) ---
More trivial testcase resulting in similar ICE.
$ cat test_associate2.f90
subroutine foo(grib)
implicit none
type b
integer, allocatable :: k_2d(:)
end type
type(b) :: grib
integer :: i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109840
--- Comment #5 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:2738955004256c2e9753364d78a7be340323b74b
commit r14-1171-g2738955004256c2e9753364d78a7be340323b74b
Author: Roger Sayle
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
Andrew Pinski changed:
What|Removed |Added
Severity|normal |trivial
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
Bug ID: 109956
Summary: GCC reserves 9 bytes for struct s { int a; char b;
char t[]; } x = {1, 2, 3};
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
Jakub Jelinek changed:
What|Removed |Added
Attachment #55148|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
--- Comment #8 from Matthias Kretz (Vir) ---
Created attachment 55150
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55150=edit
proposed solution
This patch allows unsigned intrinsic types and calls vec_cntm correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #38 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #37)
>
> As far as I understand from GCC sources, function I patched
> 'expand_ashiftrt' process only constant values of shift. As you can see
> earlier, I added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #48 from rguenther at suse dot de ---
> Am 24.05.2023 um 16:18 schrieb jakub at gcc dot gnu.org
> :
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
>
> --- Comment #47 from Jakub Jelinek ---
> But then the pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
--- Comment #7 from Matthias Kretz (Vir) ---
> You should backport to N-1 first [...]
That was my intent. My workflow had not yet adapted to the existence of
releases/gcc-13. Fixed.
> never use -mpower9-vector and friends
I use -mpcu in my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #47 from Jakub Jelinek ---
But then the pass effectively has to do lifetime analysis of the _BitInt(N) for
N > 128 etc. SSA_NAMEs and perform the partitioning of those SSA_NAMEs into
VAR_DECLs/PARM_DECLs/RESULT_DECLs, so that we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109933
--- Comment #8 from Rory Bolt ---
So...
The logic for this is simple:
For little endian the shift amount is ((address & 3) * 8)
For big endian the shift amount is ((3 -(address & 3)) * 8)
Unfortunately I have ZERO experience modifying GCC,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
--- Comment #6 from Segher Boessenkool ---
(In reply to Matthias Kretz (Vir) from comment #4)
> With -mcpu=power10 I see the issue. The problem has been there all the time
> and only surfaced with this test. (It should also have shown on `make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
--- Comment #5 from Segher Boessenkool ---
(In reply to Matthias Kretz (Vir) from comment #2)
> Yes, I stopped my backporting efforts when I became aware that it's failing
> on ARM. I'll get to PPC ASAP and then continue with the backports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99195
--- Comment #16 from CVS Commits ---
The master branch has been updated by Kyrylo Tkachov :
https://gcc.gnu.org/g:b30ab0dcf9db2ac6d81fb3743add1fbfa0d18f6e
commit r14-1167-gb30ab0dcf9db2ac6d81fb3743add1fbfa0d18f6e
Author: Kyrylo Tkachov
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #37 from Alexander Klepikov
---
> Can you also compile for little endian, and most of all, use -O2
> optimization level. Some optimizations are not done below -O2.
Here's source file, I added functions with non-constant shifts
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #46 from rguenther at suse dot de ---
On Wed, 24 May 2023, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
>
> --- Comment #45 from Jakub Jelinek ---
> Let's consider some simple testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #45 from Jakub Jelinek ---
Let's consider some simple testcase (where one doesn't really mix different
_BitInt sizes etc.).
_BitInt(512)
foo (_BitInt(512) a, _BitInt(512) b, _BitInt(512) c, _BitInt(512) d)
{
return (a + b) - (c +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109921
--- Comment #1 from Jonathan Wakely ---
The proposed change would result in ABI changes for some targets.
I think the correct fix is something more like this:
--- a/libstdc++-v3/src/c++17/floating_from_chars.cc
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109944
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109944
--- Comment #6 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:affee7dcfa1ee272d43ac7cb68cf423dbd956fd8
commit r14-1166-gaffee7dcfa1ee272d43ac7cb68cf423dbd956fd8
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #44 from rguenther at suse dot de ---
On Wed, 24 May 2023, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
>
> Jakub Jelinek changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109955
--- Comment #2 from Richard Biener ---
One thing I see is
-(insn 11 10 15 2 (set (subreg:V16QI (reg:V2DI 83 [ ]) 0)
-(unspec:V16QI [
-(reg:V16QI 92)
-(reg:V16QI 91)
-(lt:V16QI (reg:V16QI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #41 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:257c2be7ff8dfdc610202a1e1f5a8a668b939bdb
commit r14-1165-g257c2be7ff8dfdc610202a1e1f5a8a668b939bdb
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #40 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:cfd6569e9c41181231a8427235d0c0a7ad9262e4
commit r14-1164-gcfd6569e9c41181231a8427235d0c0a7ad9262e4
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #39 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:d8b058d3ca4ebbef5575105164417f125696f5ce
commit r14-1163-gd8b058d3ca4ebbef5575105164417f125696f5ce
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #8 from Neil Carlson ---
We've been bitten by what looks to be the same bug in our large Fortran code:
245 | end module kuprat_mapper_type
| 1
Error: Contained procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #11 from Christophe Lyon ---
Thanks, trunk is now OK on both arm and aarch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109944
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109955
--- Comment #1 from Richard Biener ---
Created attachment 55149
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55149=edit
patch I tested
This is the patch I tested. I have not yet investigated any of the FAILs.
Causes might be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109955
Bug ID: 109955
Summary: Should be possible to remove vcond{,u,eq} expanders
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #12 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> I see this on power 9 fedora 37 (glibc-2.36) but not on power 8 centos 7.9
> (glibc-2.17).
Also seen on power 9 rhel 9 (glibc-2.34-60.el9.ppc64le)
Not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
--- Comment #4 from Matthias Kretz (Vir) ---
With -mcpu=power10 I see the issue. The problem has been there all the time and
only surfaced with this test. (It should also have shown on `make check-simd`
in libstdc++.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #36 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #35)
>
> As I understand, you meant the following (I added new functions at the end
> of file):
>
> $ cat f.c
> #define ADDR 0x
> #define P ((unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
Jakub Jelinek changed:
What|Removed |Added
Attachment #55141|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #35 from Alexander Klepikov
---
(In reply to Oleg Endo from comment #34)
> Bit-tests of char and unsigned char should be covered by the test-suite and
> should work -- at least originally. However, what might be triggering this
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #13 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:5476de2618ffb77f3a52e59e2c9f10b018329689
commit r14-1161-g5476de2618ffb77f3a52e59e2c9f10b018329689
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109921
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-05-24
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
--- Comment #5 from Georg-Johann Lay ---
It happens in postreload.cc::reload_cse_move2add() when
(insn 45 16 17 2 (set (reg/f:HI 30 r30 [60])
(reg/v/f:HI 16 r16 [orig:51 self ] [51])) "fail1.c":29:9 101
{*movhi_split} (nil))
(insn 17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #10 from CVS Commits ---
The master branch has been updated by Matthias Kretz :
https://gcc.gnu.org/g:aa8b363171a95b8f867a74f29c75f9577e9087e1
commit r14-1160-gaa8b363171a95b8f867a74f29c75f9577e9087e1
Author: Matthias Kretz
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #9 from CVS Commits ---
The master branch has been updated by Matthias Kretz :
https://gcc.gnu.org/g:b0a483b0a011f9cbc8b25053eae809c77dae2a12
commit r14-1159-gb0a483b0a011f9cbc8b25053eae809c77dae2a12
Author: Matthias Kretz
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109940
--- Comment #7 from Peter Waller ---
I can confirm that the original (not reduced) program no longer hits an ICE
with
ee2a8b373a88bae4c533aa68bed56bf01afea0e2 (but does with the parent commit).
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109951
--- Comment #2 from Iain Sandoe ---
OK so the best bracket I've been able to get without doing surgery to make a
branch with a back port for the bootstrap break;
r14-803-g20ca33db817cec OK
r14-857-g30adfb85ff994c NOT OK,
My analysis could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109952
Gaius Mulley changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109952
--- Comment #2 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:b4df098647b687ca4e43952ec4a198b2816732ba
commit r14-1158-gb4df098647b687ca4e43952ec4a198b2816732ba
Author: Gaius Mulley
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #7 from Tomáš Trnka ---
(In reply to Paul Thomas from comment #5)
> Created attachment 55144 [details]
> Fix for this PR
>
> Thanks for reporting this. The patch "fingered" in comment #4 is certainly
> responsible for this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #19 from Richard Biener ---
(In reply to Richard Biener from comment #13)
> (In reply to Richard Biener from comment #12)
> > For the fun of it I'm testing
> >
> > diff --git a/gcc/tree-ssa-structalias.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954
--- Comment #8 from Jonathan Wakely ---
Yeah, my suggestion doesn't try to explain the full details that you pointed
out, just adds a brief note to avoid the pitfall of not overriding the default
arch, for a probably quite common case.
I chose
1 - 100 of 144 matches
Mail list logo
