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=109956
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #2
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=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=109939
--- Comment #4 from CVS Commits ---
The master branch has been updated by Kyrylo Tkachov :
https://gcc.gnu.org/g:95542a6ec4b350c653b793b7c36a8210b0e9a89d
commit r14-1156-g95542a6ec4b350c653b793b7c36a8210b0e9a89d
Author: Kyrylo Tkachov
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-05-24
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954
--- Comment #6 from Jonathan Wakely ---
How about:
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -34089,7 +34089,9 @@ on x86-64 processors in 64-bit environments.
Generate code for a 16-bit, 32-bit or 64-bit environment.
The
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=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=109944
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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=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=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=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=102989
Jakub Jelinek changed:
What|Removed |Added
Attachment #55148|0 |1
is obsolete|
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=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=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=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=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=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=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=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=109695
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=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=109951
Bug ID: 109951
Summary: [14 Regression] libgomp, testsuite: non-native
multilib c++ tests fail on Darwin.
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
Georg-Johann Lay changed:
What|Removed |Added
Last reconfirmed|2021-06-25 00:00:00 |2023-5-24
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109939
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109953
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
--- Comment #3 from Matthias Kretz (Vir) ---
I need help on how to reproduce this error. Your first lines say that the test
was compiled with `-maltivec -mpower9-vector -O2 -Wno-psabi` but that it only
happens with POWER 10? Do I need different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954
--- Comment #3 from jbeulich at suse dot com ---
(In reply to Jakub Jelinek from comment #2)
> So s/on any i386 system/in 32-bit mode/ ?
Not sure. So far I was under the (possibly wrong) impression that -m32 would
produce objects sufficiently
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=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=109951
Iain Sandoe changed:
What|Removed |Added
Build||*-*-darwin*
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954
Bug ID: 109954
Summary: x86-64's -m32 does not conform to documentation
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954
--- Comment #7 from Jakub Jelinek ---
That is the case for -m64, -mx32, -m16 etc. options as well, it would be weird
to mention it just for one.
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=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=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=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=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=78115
Andrew Pinski changed:
What|Removed |Added
Blocks||90087
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90087
Andrew Pinski changed:
What|Removed |Added
Depends on||78115
Status|ASSIGNED
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=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=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=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=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=109944
--- Comment #3 from rguenther at suse dot de ---
On Wed, 24 May 2023, crazylht at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109944
>
> --- Comment #2 from Hongtao.liu ---
> > I think we can go and for a generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954
--- Comment #5 from Jakub Jelinek ---
If -march= isn't specified, then the default configured value (explicitly or
implicitly) is used for it. That is the case on lots of architectures, not
just for -m32.
We say in the documentation:
@item
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #6 from Paul Thomas ---
The trigger for this problem is not apparent to me at all. The chunk that I
mentioned in comment #5 is not responsible for it.
The finalization of 'grid' in 13.f90 is done by an invocation of the
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 #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=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=108682
--- Comment #10 from Xi Ruoyao ---
(In reply to Ian Lance Taylor from comment #9)
> If you really want to you can port the LoongArch changes back to 1.18. I
> don't think that would be too hard--it's mostly a matter of adding build
> tags in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711
jbeulich at suse dot com changed:
What|Removed |Added
CC||jbeulich at suse dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109952
Bug ID: 109952
Summary: Inconsistent HIGH values with 'ARRAY OF CHAR'
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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=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=109927
--- Comment #16 from Richard Biener ---
(In reply to Andreas Schwab from comment #15)
> TASK_SIZE is 0xF000UL on m68k.
That would mean ~3.75GB virtual address space is available. The cited
/proc/maps though looks like the lower half isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #13 from Richard Biener ---
(In reply to Richard Biener from comment #12)
> For the fun of it I'm testing
>
> diff --git a/gcc/tree-ssa-structalias.cc b/gcc/tree-ssa-structalias.cc
> index 56021c59cb9..1e7f0383371 100644
> ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #17 from Andreas Schwab ---
The linker just uses TEXT_START_ADDR=0x8000, but mmap can use any address.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109944
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-05-24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #8 from Christophe Lyon ---
I guess gcc185 is an aarch64 machine? (as opposed to arm)
I confirm your patch fixes the problem on aarch64 (the testcase now passes),
but it still fails on arm, with:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109940
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:ee2a8b373a88bae4c533aa68bed56bf01afea0e2
commit r14-1157-gee2a8b373a88bae4c533aa68bed56bf01afea0e2
Author: Richard Sandiford
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109952
Gaius Mulley changed:
What|Removed |Added
Last reconfirmed||2023-05-24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954
--- Comment #4 from Jonathan Wakely ---
If you override the --with-arch_32=x86-64 default then it's fine.
-m32 -march=i386 will indeed produce code that runs on any i386. -m32
-march=i686 won't, nor will -m32 -march=x86-64 (which is the
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=101188
Georg-Johann Lay changed:
What|Removed |Added
CC||gjl at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
Georg-Johann Lay changed:
What|Removed |Added
CC||uweigand at de dot ibm.com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #14 from Jakub Jelinek ---
(In reply to Richard Biener from comment #13)
> with the former for -m64 and the latter for -m32 only seems to be the
> only fallout here.
It will penalize C and other languages without mandatory NRV in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #16 from Jakub Jelinek ---
I think the C version is UB, it escapes address of a local variable. The C++
case is different when the language mandates NVR, in that case one can rely on
it.
TREE_ADDRESSABLE on a type is I think set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #17 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=109945
>
> --- Comment #16 from Jakub Jelinek ---
> I think the C version is UB, it escapes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109940
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #18 from Jakub Jelinek ---
We'd need the FE to note it somewhere (of course, if it is indirect call or the
call doesn't bind to the definition we'd need to assume it might be with
mandatory NRV).
I think in the C++ FE it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109953
Bug ID: 109953
Summary: segmentation fault with import "functional" during
program execution
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
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
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=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=109945
--- Comment #15 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=109945
>
> --- Comment #14 from Jakub Jelinek ---
> (In reply to Richard Biener from
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=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=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=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=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=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=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
Martin Seemann changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
Last reconfirmed||2023-05-25
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
1 - 100 of 144 matches
Mail list logo
