--- 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&#x
Product: gcc
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 #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
--- 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 |
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 #1 from toon at moene dot org 2009-06-03 08:50 ---
Created an attachment (id=17947)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17947&action=view)
Testcase
Attached the testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40328
--- Comment #2 from toon at moene dot org 2009-06-03 08:52 ---
The bug started to appear between revisions 147846 and 147982 of the trunk.
--
toon at moene dot org changed:
What|Removed |Added
--- 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
: 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 host triplet: x
--- 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
--- 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
--- 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
--- 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
--- 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))&q
--- 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 <
--- 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 #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 #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 |
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=20664&action=view)
source code that shows the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149
--- 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=20675&action=view)
reduced test case
A reduced test case that failes in the same way.
--
toon at moene dot org
--- 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:
>
QI
size
unit size
align 8 symtab 0 alias set -1 canonica
: 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&acti
: 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&action=edit
The code leading to the ICE.
The following code:
SUBROUTINE prtdata(ilen)
INTEGER :: ilen
charac
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
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=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 strin
: 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=96712
Toon Moene changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
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
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&action=edit
Source code that provo
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
>
>
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
Status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51310
--- Comment #1 from Toon Moene 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 to the documentation, as I cann
||
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011-12-05
AssignedTo|unassigned at gcc dot |toon at moene dot org
|gnu.org |
Ever Confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51310
--- Comment #3 from Toon Moene 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, perusing the assembler outp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51310
Toon Moene changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #6 from Toon Moene
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149
--- Comment #6 from Toon Moene 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=/usr/snp/bin/gfortran
CO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149
--- Comment #5 from Toon Moene 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
COLLECT_LTO_WRAPPER=/usr/lib/g
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 changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=18220&action=view)
Source code that elicits the error.
Not reduced (sorry).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40801
mbol "nerr" in current context
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40998
--- 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 so
--- 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
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=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 deref
--- 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 or
--- 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 unt
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/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=18701&action=view)
Test case
bzip2'd tar file with test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41566
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 host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
ht
--- 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=18770&action=view)
Source code that elicits the error.
Added source code that evokes error.
It is a .f90 source, not .f
--
--- 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=18771&action=view)
Source code that elicits the error.
This is the complete source evoking the error.
--
http://gcc.gnu.org/b
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
: 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=90937
--- Comment #1 from Toon Moene ---
It compiles with gfortran 7.3
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 of
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93405
--- Comment #3 from Toon Moene ---
The patch indeed solved the test case.
Thanks !
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.
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&action=edit
Source of Fortran routine ta
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: ---
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
>
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=97530
--- Comment #1 from Toon Moene ---
Created attachment 49437
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49437&action=edit
Reduced test case.
I managed to reduce the failing program.
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&action=edit
The failing program.
I compiled the attached program as
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, th
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 #11 from Toon Moene ---
Created attachment 49564
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49564&action=edit
The full program I am testing.
This is the full program I am testing.
I have compiled it as follows (after buil
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 used.
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 ' &config nxglo
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 bo
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 ' &config nx
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 #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 d
81 matches
Mail list logo
