public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/109453] New: UBOUND incorrect when used in declartion of another array
@ 2023-04-09 0:02 jvdelisle at gcc dot gnu.org
2023-04-09 0:31 ` [Bug fortran/109453] " kargl at gcc dot gnu.org
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2023-04-09 0:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109453
Bug ID: 109453
Summary: UBOUND incorrect when used in declartion of another
array
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jvdelisle at gcc dot gnu.org
Target Milestone: ---
The following program illustrates:
integer, parameter :: a(0:19)=(/(i,i=0,19)/)
integer :: b(-1:ubound(a,dim=1)) ! <<<< This gives wrong result
! integer, parameter :: c = ubound(a,dim=1) ! Using an intermediate works
! integer :: b(-1:c) ! Using the intermediate
b(-1:ubound(a,dim=1))=(/0,a(0:19)/)
write(*,'(1000i3)') a
write(*,'(1000i3)') b
print *, rank(b), size(b), ubound(b), lbound(b)
print *, rank(a), size(a), ubound(a), lbound(a)
end
Giving:
$ ./a.out
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 0
1 22 20 -1
1 20 19 0
Commenting out the wrong result line and uncommenting the alternate lines:
$ ./a.out
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
1 21 19 -1
1 20 19 0
Looks like an off by one somewhere.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/109453] UBOUND incorrect when used in declartion of another array
2023-04-09 0:02 [Bug fortran/109453] New: UBOUND incorrect when used in declartion of another array jvdelisle at gcc dot gnu.org
@ 2023-04-09 0:31 ` kargl at gcc dot gnu.org
2023-04-09 0:33 ` kargl at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: kargl at gcc dot gnu.org @ 2023-04-09 0:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109453
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
Works for me.
gfcx -o z -O a.f90 -fcheck=all && ./z
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
1 21 19 -1
1 20 19 0
hotrats:kargl[321] valgrind ./z
==50637== Memcheck, a memory error detector
==50637== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==50637== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info
==50637== Command: ./z
==50637==
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
1 21 19 -1
1 20 19 0
==50637==
==50637== HEAP SUMMARY:
==50637== in use at exit: 0 bytes in 0 blocks
==50637== total heap usage: 20 allocs, 20 frees, 9,661 bytes allocated
==50637==
==50637== All heap blocks were freed -- no leaks are possible
==50637==
==50637== For lists of detected and suppressed errors, rerun with: -s
==50637== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/109453] UBOUND incorrect when used in declartion of another array
2023-04-09 0:02 [Bug fortran/109453] New: UBOUND incorrect when used in declartion of another array jvdelisle at gcc dot gnu.org
2023-04-09 0:31 ` [Bug fortran/109453] " kargl at gcc dot gnu.org
@ 2023-04-09 0:33 ` kargl at gcc dot gnu.org
2023-04-09 1:25 ` [Bug fortran/109453] [REGRESSION] " jvdelisle at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: kargl at gcc dot gnu.org @ 2023-04-09 0:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109453
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> Works for me.
>
> gfcx -o z -O a.f90 -fcheck=all && ./z
GNU Fortran (GCC) 13.0.1 20230310 (experimental)
This is with the above. So the change is in the
last 3 weeks.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/109453] [REGRESSION] UBOUND incorrect when used in declartion of another array
2023-04-09 0:02 [Bug fortran/109453] New: UBOUND incorrect when used in declartion of another array jvdelisle at gcc dot gnu.org
2023-04-09 0:31 ` [Bug fortran/109453] " kargl at gcc dot gnu.org
2023-04-09 0:33 ` kargl at gcc dot gnu.org
@ 2023-04-09 1:25 ` jvdelisle at gcc dot gnu.org
2023-04-09 1:42 ` sgk at troutmask dot apl.washington.edu
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2023-04-09 1:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109453
Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|UBOUND incorrect when used |[REGRESSION] UBOUND
|in declartion of another |incorrect when used in
|array |declartion of another array
--- Comment #3 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
I am using:
$ gfc -v
Using built-in specs.
COLLECT_GCC=gfc
COLLECT_LTO_WRAPPER=/home/jerry/dev/usr/libexec/gcc/x86_64-pc-linux-gnu/13.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk/configure --prefix=/home/jerry/dev/usr
--enable-languages=c,c++,fortran --enable-libgomp --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.1 20230407 (experimental) (GCC)
So that makes this a regression I believe.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/109453] [REGRESSION] UBOUND incorrect when used in declartion of another array
2023-04-09 0:02 [Bug fortran/109453] New: UBOUND incorrect when used in declartion of another array jvdelisle at gcc dot gnu.org
` (2 preceding siblings ...)
2023-04-09 1:25 ` [Bug fortran/109453] [REGRESSION] " jvdelisle at gcc dot gnu.org
@ 2023-04-09 1:42 ` sgk at troutmask dot apl.washington.edu
2023-04-09 1:46 ` jvdelisle at gcc dot gnu.org
2023-04-09 2:16 ` jvdelisle at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2023-04-09 1:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109453
--- Comment #4 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sun, Apr 09, 2023 at 01:25:16AM +0000, jvdelisle at gcc dot gnu.org wrote:
> $ gfc -v
> Using built-in specs.
> COLLECT_GCC=gfc
> COLLECT_LTO_WRAPPER=/home/jerry/dev/usr/libexec/gcc/x86_64-pc-linux-gnu/13.0.1/lto-wrapper
> Target: x86_64-pc-linux-gnu
> Configured with: ../trunk/configure --prefix=/home/jerry/dev/usr
> --enable-languages=c,c++,fortran --enable-libgomp --disable-bootstrap
> Thread model: posix
> Supported LTO compression algorithms: zlib
> gcc version 13.0.1 20230407 (experimental) (GCC)
>
> So that makes this a regression I believe.
I get the expected output with
GNU Fortran (GCC) 13.0.1 20230408 (experimental)
that I built this morning with Paul's large patch.
It definitely fails with
GNU Fortran (FreeBSD Ports Collection) 11.3.0
I don't have 12.x installed to test.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/109453] [REGRESSION] UBOUND incorrect when used in declartion of another array
2023-04-09 0:02 [Bug fortran/109453] New: UBOUND incorrect when used in declartion of another array jvdelisle at gcc dot gnu.org
` (3 preceding siblings ...)
2023-04-09 1:42 ` sgk at troutmask dot apl.washington.edu
@ 2023-04-09 1:46 ` jvdelisle at gcc dot gnu.org
2023-04-09 2:16 ` jvdelisle at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2023-04-09 1:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109453
--- Comment #5 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Correction, this must be a duplicate of something.
With gfortran gcc version 12.2.1 20221121 I get the error.
With gfortran gcc version 12.2.1 20230327 it is fixed.
As far as I can tell it has been fixed back to version 10 recently. I dont
have nything farther back.
I am not sure which PR resolved it though. The fix has not made it out to
Fedora 37 release yet.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/109453] [REGRESSION] UBOUND incorrect when used in declartion of another array
2023-04-09 0:02 [Bug fortran/109453] New: UBOUND incorrect when used in declartion of another array jvdelisle at gcc dot gnu.org
` (4 preceding siblings ...)
2023-04-09 1:46 ` jvdelisle at gcc dot gnu.org
@ 2023-04-09 2:16 ` jvdelisle at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2023-04-09 2:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109453
Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #6 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Looks like a duplicate of 108131. Marking as fixed.
*** This bug has been marked as a duplicate of bug 108131 ***
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-04-09 2:16 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-09 0:02 [Bug fortran/109453] New: UBOUND incorrect when used in declartion of another array jvdelisle at gcc dot gnu.org
2023-04-09 0:31 ` [Bug fortran/109453] " kargl at gcc dot gnu.org
2023-04-09 0:33 ` kargl at gcc dot gnu.org
2023-04-09 1:25 ` [Bug fortran/109453] [REGRESSION] " jvdelisle at gcc dot gnu.org
2023-04-09 1:42 ` sgk at troutmask dot apl.washington.edu
2023-04-09 1:46 ` jvdelisle at gcc dot gnu.org
2023-04-09 2:16 ` jvdelisle at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).