https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
--- Comment #18 from kargls at comcast dot net ---
On 1/17/25 10:17, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
>
> --- Comment #17 from anlauf at gcc dot gnu.org ---
>
> As it is not clear what is th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
--- Comment #16 from kargls at comcast dot net ---
On 1/17/25 03:47, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
>
> --- Comment #15 from Thomas Koenig ---
> (In reply to kargls from comment #14)
>> (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
--- Comment #14 from kargls at comcast dot net ---
(In reply to anlauf from comment #13)
> (In reply to kargls from comment #12)
> > (In reply to Thomas Koenig from comment #9)
> > > Question is, what should we permit...
> > >
> > > For 'normal'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
--- Comment #12 from kargls at comcast dot net ---
(In reply to Thomas Koenig from comment #9)
> Question is, what should we permit...
>
> For 'normal' operations, only unsigned op unsigned is permitted,
> so unsigned**unsigned is obviously ok.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
--- Comment #6 from kargls at comcast dot net ---
(In reply to kargls from comment #5)
> (In reply to Thomas Koenig from comment #3)
> Yes, please lift the restriction. I ran into this issue while
> writing a testcase as well. As J3 is not con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
--- Comment #5 from kargls at comcast dot net ---
(In reply to Thomas Koenig from comment #3)
> (In reply to kargls from comment #2)
> > Not Thomas, but ...
> >
> > https://j3-fortran.org/doc/year/24/24-116.txt
> >
> > The exponentiation operat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884
--- Comment #9 from kargls at comcast dot net ---
(In reply to anlauf from comment #8)
> Created attachment 60157 [details]
> Patch
>
> This patch rejects NULL() as source-expr, without or with MOLD.
>
> I believe that F03:C632 can be interprete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884
--- Comment #7 from kargls at comcast dot net ---
(In reply to anlauf from comment #5)
> But all other variations, like in comment#0, ICE here.
The code is comment #0 involves source-expr. The code
in comment #1 involves type-spec. These are n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884
--- Comment #6 from kargls at comcast dot net ---
(In reply to Jerry DeLisle from comment #4)
> (In reply to kargls from comment #3)
> > (In reply to Gerhard Steinmetz from comment #1)
> --- snip ---
> >
> > This now gives
> >
> > % gfcx -c pr71
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107596
--- Comment #2 from kargls at comcast dot net ---
This appears to be fixed in gcc 14 and trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118337
--- Comment #4 from kargls at comcast dot net ---
(In reply to Jakub Jelinek from comment #3)
> I wonder if the incompatibility isn't just about the iso-c-binding.def (and
> maybe iso-fortran-env.def) changes inserting stuff in the middle rather
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118337
--- Comment #2 from kargls at comcast dot net ---
(In reply to Thomas Koenig from comment #1)
> Probably safest to bump the module version
Agree with Thomas, here. The internally generated iso_c_binding module
from 14 and 15 are different.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118259
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #27 from kargls at comcast dot net ---
On 12/28/24 11:49, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
>
> --- Comment #26 from Jerry DeLisle ---
> Why not set it in gfc_resolve_expr near
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #24 from kargls at comcast dot net ---
(In reply to anlauf from comment #22)
> (In reply to anlauf from comment #21)
>
> > diff --git a/gcc/fortran/iresolve.cc b/gcc/fortran/iresolve.cc
> > index 580f8c8407d..759eb99a645 100644
> > -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #23 from kargls at comcast dot net ---
(In reply to anlauf from comment #20)
> (In reply to Jerry DeLisle from comment #19)
> > (In reply to kargls from comment #17)
> > > I suppose the error in check.cc(gfc_check_f_c_string) that sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #17 from kargls at comcast dot net ---
On 12/24/24 10:03, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
>
> --- Comment #15 from Jerry DeLisle ---
> From Harald's post. "There is another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #14 from kargls at comcast dot net ---
(In reply to Jerry DeLisle from comment #12)
> The following additional patch from Harald posted on the gfortran list:
>
> https://gcc.gnu.org/pipermail/fortran/2024-December/061452.html
>
> di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118120
--- Comment #10 from kargls at comcast dot net ---
(In reply to anlauf from comment #9)
> (In reply to kargls from comment #8)
> > (In reply to anlauf from comment #7)
> > > The following patch works and might be a reasonable compromise:
> > >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118120
--- Comment #8 from kargls at comcast dot net ---
(In reply to anlauf from comment #7)
> The following patch works and might be a reasonable compromise:
>
> diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
> index 82a2ae1f747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118120
--- Comment #6 from kargls at comcast dot net ---
(In reply to Slava Zakharin from comment #5)
> Right, this test deliberately introduces the aliasing to demonstrate that
> gfortran has too optimistic assumptions about aliasing of COMPLEX and REA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118120
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #10 from kargls at comcast dot net ---
On 12/17/24 16:23, jvdelisle at gcc dot gnu.org wrote:
> --- Comment #9 from Jerry DeLisle ---
> Patch applies cleanly. Testing started.
>
Thanks, Jerry, for taking a look at the patch.
On x8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #8 from kargls at comcast dot net ---
(In reply to kargls from comment #7)
> Created attachment 59903 [details]
> Complete patch with testcase included
>
> The new diff is a complete implementation with an included testcase.
Forgot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
kargls at comcast dot net changed:
What|Removed |Added
Attachment #59827|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116254
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
kargls at comcast dot net changed:
What|Removed |Added
Attachment #59830|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84245
--- Comment #15 from kargls at comcast dot net ---
(In reply to Paul Thomas from comment #14)
> (In reply to kargls from comment #13)
> >
> > If something goes wrong, do you possibly need to free expr1 and expr2.
> > Elsewhere in gfc_match_select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
kargls at comcast dot net changed:
What|Removed |Added
Attachment #59617|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #3 from kargls at comcast dot net ---
Created attachment 59827
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59827&action=edit
Testcase for f_c_string
The attached testcase has a number of tests currently commented out.
Those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84245
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117805
--- Comment #18 from kargls at comcast dot net ---
On 11/29/24 11:19, anlauf at gcc dot gnu.org wrote:
>> The '-' is an unary minus operator. In 'cmplx(-1.)', it operates
>> on only the real part. In '- cmplx(1.)', it operates on both
>> parts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117805
--- Comment #16 from kargls at comcast dot net ---
On 11/29/24 10:35, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117805
>
> --- Comment #15 from anlauf at gcc dot gnu.org ---
> (In reply to kargls from commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117805
--- Comment #14 from kargls at comcast dot net ---
(In reply to anlauf from comment #12)
> (In reply to kargls from comment #11)
> > This is not processor-dependent behavior. gfortran implements
> > real*complex in accordance with the words of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117805
--- Comment #11 from kargls at comcast dot net ---
On 11/28/24 04:54, rguenth at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117805
>
> --- Comment #10 from Richard Biener ---
> Note with a patch like in comment#4 you'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117765
--- Comment #10 from kargls at comcast dot net ---
On 11/25/24 09:50, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117765
>
> --- Comment #7 from anlauf at gcc dot gnu.org ---
> The patch catches functions but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117805
--- Comment #7 from kargls at comcast dot net ---
(In reply to Richard Biener from comment #3)
> You can get the desired behavior with -fno-signed-zeros I think - it might
> be reasonable to add an additional -fcx-* flag specifying that just for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117805
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117798
--- Comment #2 from kargls at comcast dot net ---
I think that Fortran 2023 may break the ABI for gfortran.
F2008 has "13.7.65 GET COMMAND ([COMMAND, LENGTH, STATUS])"
Currently, libgfortran/intrinsics/args.c has
void
get_command_i4 (char *co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117798
--- Comment #1 from kargls at comcast dot net ---
The following program comes from Fortran 2023, 16.9.92 GET_COMMAND.
PROGRAM hello
CHARACTER(:), ALLOCATABLE :: cmd
CALL GET_COMMAND(cmd)
PRINT *, 'Hello ', cmd
END PROGRAM
This hangs o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117798
Bug ID: 117798
Summary: Audit intrinsic subprograms with scalar INTENT(OUT)
character strings
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117774
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117765
--- Comment #9 from kargls at comcast dot net ---
(In reply to kargls from comment #8)
>
> Nice catch. I did not consider impure subroutines (obviously).
> It seems that resolve.cc does not have a check_pure_subroutine()
> like it does for func
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117765
--- Comment #8 from kargls at comcast dot net ---
(In reply to anlauf from comment #7)
> The patch catches functions but misses subroutine calls, as in:
>
> ! { dg-do compile }
> !
> program foo
>
>implicit none
>
>integer i
>integ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117765
--- Comment #5 from kargls at comcast dot net ---
On 11/24/24 13:51, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117765
>
> --- Comment #4 from Jerry DeLisle ---
> In the test case dg-error there is a miss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117765
Bug ID: 117765
Summary: Impure function within a BLOCK construct within a DO
CONCURRENT
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117654
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #2 from kargls at comcast dot net ---
Created attachment 59617
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59617&action=edit
initial partial implementation
The attached patch is an initial implementation of f_c_string() up t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #1 from kargls at comcast dot net ---
Here's a testcase (obviously untested).
!
! { dg-do run }
!
program foo
use iso_c_binding, only : c_null_char, f_c_string
logical, volatile :: asis
character(len=6, kind=c_char) s1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
Bug ID: 117643
Summary: F_C_STRING from F23 is missing
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104036
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117434
--- Comment #12 from kargls at comcast dot net ---
(In reply to Iain Sandoe from comment #11)
> (In reply to kargls from comment #10)
> > I suppose the question then comes down to where does the
> >
> > .section.note.GNU-stack,"x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117434
--- Comment #10 from kargls at comcast dot net ---
(In reply to Iain Sandoe from comment #9)
> (In reply to kargls from comment #8)
> > (In reply to Iain Sandoe from comment #7)
> >
>
> > /usr/local/bin/ld: warning: /tmp/ccVWAwWh.o: requires ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117434
--- Comment #8 from kargls at comcast dot net ---
(In reply to Iain Sandoe from comment #7)
>
>
> - however, for O0 we get a MAIN__ function which contains:
>:
> FRAME.3.FRAME_BASE.PARENT = 0B;
> __builtin_init_trampoline (&FRAME.3.t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117434
--- Comment #3 from kargls at comcast dot net ---
On 11/3/24 18:41, jvdelisle at gcc dot gnu.org wrote:
> I just finished doing the same thing.
>
> $ gfc test1.f90
> /usr/bin/ld: warning: /tmp/cc7FO4Ip.o: requires executable stack (because the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117434
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116668
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #16 from kargls at comcast dot net ---
(In reply to Jordan from comment #15)
> I do not mean to burst your bubble, but Vulkan 1.1 released in 2018 and
> ChatGPT came out in 2022 lol.
Snarky comments are a proven method to deter those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #12 from kargls at comcast dot net ---
(In reply to anlauf from comment #11)
> (In reply to kargls from comment #10)
> > (In reply to anlauf from comment #9)
> > > (In reply to kargls from comment #8)
> > > > One could set GFC_MAX_SYM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #10 from kargls at comcast dot net ---
(In reply to anlauf from comment #9)
> (In reply to kargls from comment #8)
> > One could set GFC_MAX_SYMBOL_LEN to a value larger than 63, but what
> > value makes sense? (Note it will be less
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #8 from kargls at comcast dot net ---
(In reply to Jerry DeLisle from comment #6)
> This begs the question whether we should support longer symbols as an
> extension.
This likely would require a big change to the frontend. There are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #7 from kargls at comcast dot net ---
(In reply to anlauf from comment #5)
> While Nvidia and flang seem to allow the sample code, even the latest
> Intel ifx 2025.0 rejects it:
>
> pr117381.f90(5): error #6439: This symbol has too m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117302
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117264
--- Comment #6 from kargls at comcast dot net ---
Agree with Harald, we need to see the actual code and error.
program p
type, abstract :: t
integer :: i = 0
end type
type, extends(t) :: tt
integer :: j = 0
end type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117264
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104826
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104827
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117188
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117110
--- Comment #3 from kargls at comcast dot net ---
I con no longer audit metadata of a PR. This should be a P1 bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117110
--- Comment #2 from kargls at comcast dot net ---
Likely broken with
commit c397a8c12296b75a91ae51e4889debf023e6c338
Author: Jakub Jelinek
Date: Sat Oct 12 10:44:17 2024 +0200
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117110
--- Comment #1 from kargls at comcast dot net ---
Bootstrapped worked on at least
% hotrats:kargl[264] gfcx --version
GNU Fortran (GCC) 15.0.0 20240919 (experimental)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117110
Bug ID: 117110
Summary: Bootstrap broken on FreeBSD with build/genmatch
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116859
--- Comment #7 from kargls at comcast dot net ---
(In reply to kargls from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > Created attachment 59203 [details]
> > gcc15-pr116859.patch
> >
> > Here it is in patch form. But I can't r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116859
--- Comment #6 from kargls at comcast dot net ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 59203 [details]
> gcc15-pr116859.patch
>
> Here it is in patch form. But I can't really test it on FreeBSD nor
> DragonFly.
I ju
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116859
Bug ID: 116859
Summary: Bootstrap broken on FreeBSD due to
_GLIBCXX_USE_C99_LONG_LONG_DYNAMIC
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116656
--- Comment #4 from kargls at comcast dot net ---
valgrind --leak-check=full ./z
==99899== Memcheck, a memory error detector
==99899== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==99899== Using Valgrind-3.23.0 and LibVEX; rer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116656
--- Comment #3 from kargls at comcast dot net ---
(In reply to Andrew Pinski from comment #2)
> >Apple M1 Pro.
>
> Considering the aarch64 darwin port has not been upstreamed yet, this should
> be reported to where you got gfortran.
The issue e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116656
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530
--- Comment #6 from kargls at comcast dot net ---
(In reply to anlauf from comment #3)
> Tentative obvious fix for NULL pointer dereference:
>
> diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc
> index 7ab82fa2f5b..de38f4a808f 1006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530
--- Comment #5 from kargls at comcast dot net ---
(In reply to anlauf from comment #4)
> (In reply to kargls from comment #1)
> > (In reply to philippe.wautelet from comment #0)
> >
> > >
> > > I'm not sure it is conforming to the Fortran stand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412
--- Comment #13 from kargls at comcast dot net ---
On 8/27/24 12:25, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412
>
> --- Comment #12 from anlauf at gcc dot gnu.org ---
> (In reply to kargls from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412
--- Comment #11 from kargls at comcast dot net ---
On 8/26/24 19:06, kargls at comcast dot net wrote:
> atanpi. I believe line
> 4451 should be emitting the error message you're looking for.
Ugh, it's worse than I originally thought. The con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412
--- Comment #10 from kargls at comcast dot net ---
On 8/26/24 18:47, kargls at comcast dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412
>
> --- Comment #9 from kargls at comcast dot net ---
> On 8/26/24 12:04, anlauf at gcc do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412
--- Comment #9 from kargls at comcast dot net ---
On 8/26/24 12:04, anlauf at gcc dot gnu.org wrote:
> subroutine s2
>external :: atan
>real :: r = 1.
>print *, atan (-1.d0,r)
> end
>
> subroutine s3
>real :: r = 1.
>print *,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116468
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308
--- Comment #15 from kargls at comcast dot net ---
(In reply to anlauf from comment #14)
>
> Can you construct a testcase which is missed?
>
Apparently, no! :)
Of course, I'm trying to multitask between work and non-work.
Patch looks good to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308
--- Comment #13 from kargls at comcast dot net ---
(In reply to anlauf from comment #11)
> Created attachment 58926 [details]
> Patch
>
> This patch applies the check of the declared type in resolve_array_list,
> where there is already a check f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116359
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308
--- Comment #9 from kargls at comcast dot net ---
(In reply to anlauf from comment #8)
> (In reply to kargls from comment #7)
> > I can no longer edit meta data for a PR. The keyword: field is wrong. This
> > is an ice-on-invalid-code. Please
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308
--- Comment #7 from kargls at comcast dot net ---
I can no longer edit meta data for a PR. The keyword: field is wrong. This is
an ice-on-invalid-code. Please change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308
--- Comment #6 from kargls at comcast dot net ---
Created attachment 58911
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58911&action=edit
Fix the ICE by detecting invalid code
The attached patch catches F2023:C7125. It does not address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308
--- Comment #5 from kargls at comcast dot net ---
(In reply to kargls from comment #4)
> F2023:C7124 (R781) An ac-value shall not be unlimited polymorphic.
>
> 3.149
> unlimited polymorphic
> able to have any dynamic type (3.144.4) during progra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116292
--- Comment #9 from kargls at comcast dot net ---
On 8/9/24 03:30, sjames at gcc dot gnu.org wrote:
> Should I upload the real testcase I hit it on in this bug (from
> 'fortran-stdlib' https://bugs.gentoo.org/937358), or file another bug instead?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116292
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115983
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
1 - 100 of 119 matches
Mail list logo
