Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: toon at moene dot org
Target Milestone: ---
A build + test run [r14-8465] on aarch64-linux-gnu draws the following ICE
while compiling math/cmplx:
during RTL pass: sched1
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: toon at moene dot org
Target Milestone: ---
The following program:
MODULE FIELD_2RM_UTIL_MODULE
INTERFACE
SUBROUTINE SET_ABOR1_EXCEPTION_HANDLER()
BIND(C,name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #29 from Toon Moene ---
On 9/8/21 10:05 PM, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
>
> anlauf at gcc dot gnu.org changed:
>
> What|Removed |Added
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #27 from Toon Moene ---
Yes, I am now convince this works (64 leads to stop 1, but 63 works).
Note that I slightly changed the program today, to add a sync all before the
forecasting loop, and adding one to the copy_local_to_global
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #25 from Toon Moene ---
BTW, the speed difference between the native and the OpenMPI based program is
staggering. For a 936x770x60 grid, the native run takes around 14 seconds
elapsed time, while the OpenMPI based one takes 2 minutes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #24 from Toon Moene ---
And I can reproduce the GFORTRAN_NUM_IMAGES=64 segfault:
(export
LD_LIBRARY_PATH=/home/toon/compilers/install/coarray_native/lib/gcc/x86_64-pc-linux-gnu/11.0.0;
export GFORTRAN_NUM_IMAGES=64; echo '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #23 from Toon Moene ---
The segfault at GFORTRAN_NUM_IMAGES=64 might be due to the fact that the
program doesn't contain a check whether the size of the boundary relaxation
zone (currently set to 4) is too large for the slabs.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #20 from Toon Moene ---
Example of the problem described in the last comment:
(export
LD_LIBRARY_PATH=/home/toon/compilers/install/coarray_native/lib/gcc/x86_64-pc-linux-gnu/11.0.0;
export GFORTRAN_NUM_IMAGES=28; echo '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #19 from Toon Moene ---
Thanks.
It works now for export GFORTRAN_NUM_IMAGES=1..10 for me.
Unfortunately, when I want to change the nxglobal and nyglobal values in the
domain via the namelist, sometimes the "default" values are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #11 from Toon Moene ---
Created attachment 49564
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49564=edit
The full program I am testing.
This is the full program I am testing.
I have compiled it as follows (after building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Toon Moene changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #7 from Toon Moene ---
I agree - the coarrays should be the same size and the program should just only
*use* the part that it needs.
I also got an error with the caf-mpi library, but that one was impossible to
understand (in fact,
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: toon at moene dot org
Target Milestone: ---
Created attachment 49446
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49446=edit
The failing program.
I compiled the attached program as follows:
~/compil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97530
--- Comment #1 from Toon Moene ---
Created attachment 49437
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49437=edit
Reduced test case.
I managed to reduce the failing program.
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: toon at moene dot org
Target Milestone: ---
Created attachment 49424
--> https://gcc.gnu.org/bugzilla/attachment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
Toon Moene changed:
What|Removed |Added
CC||toon at moene dot org
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96712
Toon Moene changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: toon at moene dot org
Target Milestone: ---
The following source:
integer i
real(kind=8) r
i = nint(r, 16)
end
generates an ICE when compiled with 10.2 as follows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93405
--- Comment #5 from Toon Moene ---
I have no problem with it.
I will ACK it on the fortran mailing list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93405
--- Comment #3 from Toon Moene ---
The patch indeed solved the test case.
Thanks !
: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: toon at moene dot org
Target Milestone: ---
I think the analyzer has a problem in the way constant arguments are passed "by
reference" in Fortran:
$ cat main1.f
Assignee: dmalcolm at gcc dot gnu.org
Reporter: toon at moene dot org
Target Milestone: ---
Trying to bootstrap with a new config/bootstrap-analyzer.mk:
STAGE2_CFLAGS += -fanalyzer
STAGE3_CFLAGS += -fanalyzer
fails while building libbacktrace/dwarf.c:448:12: warning: use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937
--- Comment #1 from Toon Moene ---
It compiles with gfortran 7.3
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: toon at moene dot org
Target Milestone: ---
Compiling he following code leads to the ICE in the summary:
SUBROUTINE LFIDIFF
IMPLICIT NONE
INTEGER, PARAMETER :: JPIM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #9 from Toon Moene ---
> So with this suggestion, this procedure would be generated without the hidden
> length argument. The brokenness comes from
> call foo("ab")
> which would generate a call to a procedure WITH the hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51310
--- Comment #10 from Toon Moene ---
On 1/14/19 11:52 PM, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51310
>
> --- Comment #9 from Dominique d'Humieres ---
> Output from the test in comment 0 is now
>
>
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: toon at moene dot org
Target Milestone: ---
Created attachment 45244
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45244=edit
Source code that provokes the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87218
--- Comment #1 from Toon Moene ---
Well, OK - it's more like 9 minutes ...
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: toon at moene dot org
Target Milestone: ---
Created attachment 44660
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44660=edit
Source of Fortran routine taking 12+ minu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71783
--- Comment #13 from Toon Moene ---
On 07/11/2016 10:26 PM, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71783
>
> Thomas Koenig changed:
>
>What|Removed |Added
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71783
--- Comment #6 from Toon Moene ---
On 07/08/2016 11:15 PM, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71783
>
> --- Comment #3 from Thomas Koenig ---
> The solution turns that fixes the ICE turns out to be
: unassigned at gcc dot gnu.org
Reporter: toon at moene dot org
Target Milestone: ---
Created attachment 38843
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38843=edit
The code leading to the ICE.
The following code:
SUBROUTINE prtdata(ilen)
INTEGER :: ilen
character(len=i
: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: toon at moene dot org
Target Milestone: ---
Created attachment 38805
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38805=edit
The (reduc
Severity: normal
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: toon at moene dot org
The following Fortran program, when compiled with gfortran 4.9.1 or trunk
(5.0), cannot read a valid namelist file from stdin (unit 5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51310
Toon Moene toon at moene dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51310
Toon Moene toon at moene dot org changed:
What|Removed |Added
Attachment #25948|0 |1
is obsolete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51310
--- Comment #3 from Toon Moene toon at moene dot org 2011-12-05 20:04:21 UTC
---
At first I thought that gfortran would initialize small local arrays to
whatever -finit-real indicated by making them static, instead of stack based.
However
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51310
--- Comment #1 from Toon Moene toon at moene dot org 2011-11-29 19:37:19 UTC
---
Created attachment 25948
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25948
Untested patch to the documentation
This is a completely untested patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51310
Bug #: 51310
Summary: -finit-bla doesn't initialize *all* items of type bla
to the requested constant.
Classification: Unclassified
Product: gcc
Version: 4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50178
Bug #: 50178
Summary: [4.6 regression] ICE with gfortran -O3, not with
gfortran -02
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50178
Toon Moene toon at moene dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149
--- Comment #6 from Toon Moene toon at moene dot org 2011-05-08 13:15:44 UTC
---
Well, that was a bit too quick (careful which compiler you are using).
It works with this compiler:
$ /usr/snp/bin/gfortran -v
Using built-in specs.
COLLECT_GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149
--- Comment #5 from Toon Moene toon at moene dot org 2011-05-08 13:00:33 UTC
---
The bug does not manifest itself with the default compiler and linker on a
recent version of Debian Testing:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
--- Comment #2 from toon at moene dot org 2010-05-16 18:35 ---
Created an attachment (id=20675)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20675action=view)
reduced test case
A reduced test case that failes in the same way.
--
toon at moene dot org changed:
What
--- Comment #3 from toon at moene dot org 2010-05-16 18:51 ---
It might be useful to compare the two decls that invoke the mismatch that
triggers the gcc_assert:
prevailing-decl is:
function_decl 0x7fb0f574f900 convect_satmixratio
type function_type 0x7fb0f5786b28
type
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot org
GCC host triplet: x64_86-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149
--- Comment #1 from toon at moene dot org 2010-05-15 09:32 ---
Created an attachment (id=20664)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20664action=view)
source code that shows the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149
--- Comment #7 from toon at moene dot org 2010-03-20 09:39 ---
Works when using Debian's version of gfortran 4.4.3 and their gdb (version
7.0.1).
--
toon at moene dot org changed:
What|Removed |Added
--- Comment #2 from toon at moene dot org 2010-01-23 13:24 ---
Tobias,
If we ask a bug submitter for more information, or to confirm our suspicions,
we put the bug report in WAITING.
Note to submitter: bug reports with status WAITING will be closed if not
replied to within 3 months
--- Comment #5 from toon at moene dot org 2009-12-17 21:58 ---
(Even with a temporary file, other things can go wrong!)
Paul, you are right - I agree with FX, but forgot to reply.
Closing as WONTFIX is OK with me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33905
--- Comment #12 from toon at moene dot org 2009-11-24 18:03 ---
Any tricks I have missed?
Yes - we could provide for loop versioning in the front end.
I.e., generate code like:
IF (M3 0) THEN
... compute loop count ...
... perform loop ...
ELSE IF (M3 0) THEN
... compute
--- Comment #9 from toon at moene dot org 2009-11-22 10:20 ---
Richard wondered about this earlier:
countm1.1 = (character(kind=4)) (D.1337 - D.1336) / (character(kind=4))
D.1338;
but perhaps it's better to asked explicitly:
Where does the (character(kind=4)) comes from
--- Comment #15 from toon at moene dot org 2009-11-21 12:11 ---
I don't see that the standard suggests the specific code the Frontend
generates. In fact it should be valid to increment the DO variable
by m3 and express the exit test in terms of the DO variable as well.
The Standard
--- Comment #2 from toon at moene dot org 2009-11-21 17:33 ---
Sorry, Steve - my mistake.
The original message should have been:
To illustrate this with a simple example:
DO I = M1, M2, M3
B(I) = A(I)
ENDDO
would be most easily, and straightforwardly, implemented as follows
--- Comment #5 from toon at moene dot org 2009-11-21 21:40 ---
The middle-end prefers do { } while () loop style so it knows the loop is
always executed.
And the Fortran Standard describes the loops being built (by compilers) just
so:
1. First you determine what is m1, m2, m3
2
--- Comment #13 from toon at moene dot org 2009-11-20 19:45 ---
The funny conditional initialization of countm1.6 makes the analysis of
the number of iterations of this loop impossible (not to mention the
conversions to character(kind=4)).
Why does the frontend do induction
--- Comment #6 from toon at moene dot org 2009-11-19 19:53 ---
Richard Guenther wrote:
Well, within eval there's nothing really obvious to me. The
innermost loop is exactly the same:
But it is a very inefficient way of vectorizing, because the inner loop's body
is either executed
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org
--- Comment #1 from toon at moene dot org 2009-10-10 09:26 ---
Created an attachment (id=18770)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18770action=view)
Source code that elicits the error.
Added source code that evokes error.
It is a .f90 source, not .f
--
http
--- Comment #2 from toon at moene dot org 2009-10-10 09:50 ---
(From update of attachment 18770)
Wrong (incomplete) source.
--
toon at moene dot org changed:
What|Removed |Added
--- Comment #3 from toon at moene dot org 2009-10-10 09:52 ---
Created an attachment (id=18771)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18771action=view)
Source code that elicits the error.
This is the complete source evoking the error.
--
http://gcc.gnu.org/bugzilla
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41566
--- Comment #1 from toon at moene dot org 2009-10-04 13:09 ---
Created an attachment (id=18701)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18701action=view)
Test case
bzip2'd tar file with test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41566
--- Comment #6 from toon at moene dot org 2009-09-20 17:03 ---
It seems we have exhausted the arguments in this case.
The best cause of action seems to be to document that gfortran won't allow to
open dangling symlinks with STATUS='NEW'.
This bug report remains open until that is done
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41387
--- Comment #1 from toon at moene dot org 2009-09-17 13:26 ---
Perhaps the system call 'access' can provide help here.
From the man page (man 2 access):
access() checks whether the calling process can access the file pathname.
If pathname is a symbolic link, it is dereferenced
--- Comment #4 from toon at moene dot org 2009-09-17 19:57 ---
In response to reply 2 (thanks Steve), we might be able to exploit the system
call access to at least solve the inconsistency between INQUIRE and OPEN:
man 2 access
ENOENT A component of pathname does not exist
--- Comment #7 from toon at moene dot org 2009-08-18 16:40 ---
The relevant wording in the Standard (2003) is:
9.5.3.4 Data transfer
...
The list items for a namelist input statement are processed in the order of the
entities specified within the input records.
...
To spell it out
--- Comment #5 from toon at moene dot org 2009-08-07 16:58 ---
Could indeed be the version of gdb.
Mine is:
$ gdb -v
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software
ReportedBy: toon at moene dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40801
--- Comment #1 from toon at moene dot org 2009-07-18 18:28 ---
Created an attachment (id=18220)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18220action=view)
Source code that elicits the error.
Not reduced (sorry).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40801
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC
--- Comment #5 from toon at moene dot org 2009-06-03 12:55 ---
It works for the testcase with your change (over revision 148127).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40328
--- Comment #5 from toon at moene dot org 2009-05-05 13:33 ---
Hmm, I said I'd put it in waiting until I found the definite wording in the
Standard about this use of namelist values ...
--
toon at moene dot org changed:
What|Removed |Added
--- Comment #3 from toon at moene dot org 2009-04-07 18:41 ---
Note that the namelist is overwriting earlier assignments, so it's doubtful
it's legal Fortran.
The original that got my colleague questioning gfortran was:
namtest
i(1,:)=1,2,3,
i(2,:)=4,5,6,
i(3,:)=7,8,9,
/
which
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39668
--- Comment #2 from toon at moene dot org 2009-03-29 13:36 ---
I'll try to come up with a bug report this week (the original case is much to
complicated to use as an example).
However, it might take some time and it also might be system dependent to
trigger this event.
It's clear
78 matches
Mail list logo
