https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711
--- Comment #9 from Hongtao.liu ---
(In reply to jbeulich from comment #8)
> Since the commit doesn't really explain it (maybe it's obvious to others,
> but it isn't to me), may I ask why two splitters were introduced, yet then
> still not cover
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87270
Paul Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
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 align
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 me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
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 E
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 u
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 = MEM[(c
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
Date
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&action=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 'v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109960
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-05-25
Status|UNCONFIRM
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 shown
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 0;
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: missed-optimization
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 inte
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 paddin
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://dl.acm.or
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
> +++ b
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 mer
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 @@ value_dependent_exp
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: W
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: S
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 Kret
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 Kret
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 Kret
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 embedded.
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
Assignee|
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&action=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.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109958
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3
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
Pr
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
--- a/gcc/fortran
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 the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594
Joseph changed:
What|Removed |Added
CC||schuchart at icl dot utk.edu
--- Comment #10 fr
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
Priori
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
associ
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 c
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
associate(k=>grib
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 M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
Andrew Pinski changed:
What|Removed |Added
Severity|normal |trivial
--- Comment #1 from Andrew Pins
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&action=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 you
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 effective
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 de
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 don'
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, a
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.
You
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
$ c
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 (whe
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 + d
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
+++ b/libstdc++-v3/src/c++17/flo
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 |Adde
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 ‘__final_integer_set_type_
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
--- Com
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&action=edit
patch I tested
This is the patch I tested. I have not yet investigated any of the FAILs.
Causes might be mi
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
Compone
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 rep
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
> pr
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 4
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 well
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: Wed
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 regressio
1 - 100 of 138 matches
Mail list logo
