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=109951
Bug ID: 109951
Summary: [14 Regression] libgomp, testsuite: non-native
multilib c++ tests fail on Darwin.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Sev
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=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 va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
Georg-Johann Lay changed:
What|Removed |Added
CC||uweigand at de dot ibm.com
--- Comme
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 V16QI
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=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=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
> --- a/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109944
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-05-24
Assignee|unassign
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 th
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:
/arm-linux-gnueabihf/libstdc++-v3/in
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=109939
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assigne
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=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 comment
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 con
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
Da
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
Resoluti
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 finalized
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: mo
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=109952
Gaius Mulley changed:
What|Removed |Added
Last reconfirmed||2023-05-24
Status|UNCONFIRME
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
Component
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 #2
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=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 si
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 #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 implici
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 --wi
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
'finalizatio
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 @option{
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=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=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 b/gcc/tree-ssa-structalias.
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
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=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 well
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=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=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=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=109921
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-05-24
Ever confirmed|0
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 #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=102989
Jakub Jelinek changed:
What|Removed |Added
Attachment #55141|0 |1
is obsolete|
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=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=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=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=109944
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
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=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=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=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 #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=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=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=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
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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=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=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=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=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=109695
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=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=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 #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=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=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=102989
Jakub Jelinek changed:
What|Removed |Added
Attachment #55148|0 |1
is obsolete|
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=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
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #2 f
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=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=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 #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=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=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=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=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=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=109958
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
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=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=104350
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|
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 #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=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=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
1 - 100 of 138 matches
Mail list logo
