https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455
martin changed:
What|Removed |Added
CC||mscfd at gmx dot net
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115997
--- Comment #2 from martin ---
Thanks for checking and looking up. I have not been able to use gfortran-14 due
to bug 114874 (a regression which has been resolved after release). Strangely,
the search box of bugzilla does not show relevant findl
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
Created attachment 58705
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58705&action=edit
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113797
--- Comment #3 from martin ---
Thanks for the patch, it does the job. But if I compile with
"gfortran-14 -fopenmp -Wuninitialized"
then I obtain
20 | out = concat_f('0123456 ', some()) // ' abc'
|
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
Created attachment 57349
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57349&action=edit
concat.f90
The code c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112764
--- Comment #10 from martin ---
Thanks for the speedy fix! I just thought about a variation, which should now
with the fix work as well (was not yet able to compile current dev branch, so
cannot check myself):
program assoc_ptr_in
implicit no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112764
--- Comment #4 from martin ---
(In reply to anlauf from comment #1)
> Confirmed.
>
> F2018:11.1.3.3 has:
>
> "The associating entity does not have the ALLOCATABLE or POINTER attributes;
> it has the TARGET attribute if and only if the selector
: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
The selector has the pointer attribute but association is with an array
section. The associating
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
Created attachment 55519
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55519&action=edit
testca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105800
--- Comment #1 from martin ---
Created attachment 54856
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54856&action=edit
fixed testcase class_dealloc.f90
As I just see, the first attachment does not show the bug as return value "a"
of fun
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
Created attachment 53425
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53425&action=edit
ibset_transfer.f90
Nesting ibset and t
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
Created attachment 53062
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53062&action=edit
test class_dealloc.f90
Creating an array in a function with retur
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
Created attachment 52947
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52947&action=edit
func_contiguous.f90
The attach
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105503
--- Comment #1 from martin ---
Created attachment 52934
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52934&action=edit
reduced uninit_vptr
Testcase further reduced.
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
Created attachment 52932
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52932&action=edit
uninit_vptr
The a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105054
martin changed:
What|Removed |Added
CC||mscfd at gmx dot net
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103039
--- Comment #12 from martin ---
Thanks for fixing! I just checked with the real code and there it also looks
good.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100961
--- Comment #4 from martin ---
In contrast to gfortran-11, with current master I do not see any errors or
segfaults (not even with valgrind) anymore. Seems to have been fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87448
--- Comment #3 from martin ---
With gfortran-12, the ICE is gone, but the produced error message does not look
right.
mod.f90:12:25:
12 |associate(l => len(cs))
| 1
Error: Symbol ‘l’ at (1) has no IMPLICIT t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103039
--- Comment #4 from martin ---
Is there any chance of fixing this regression (in particular the associate
block variant) till gfortran-12 release? Having an openmp block within an
associate block should not be that uncommon in modern code, right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342
--- Comment #8 from martin ---
Seems to work fine with current master. Not even valgrind complains.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103039
--- Comment #3 from martin ---
Created attachment 51722
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51722&action=edit
seemingly same problem but with associate instead of select type
A similar problem with associate shows the same prob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103039
--- Comment #1 from martin ---
The warning which is shown during compilation is:
seltype.f90:16:59:
16 | !$omp parallel do default(shared) private(k) reduction(+:s)
| ^
Warning:
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
Created attachment 51720
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51720&action=edit
seltype.f90
The attached code compiles and executes fine with g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100961
--- Comment #3 from martin ---
Created attachment 50968
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50968&action=edit
second test case which segfaults
Playing around with some variants in select_rank_expression2.f90, I can see
that I s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100961
--- Comment #2 from martin ---
It is releases/gcc-11.1.0:
Using built-in specs.
COLLECT_GCC=gfortran-11
COLLECT_LTO_WRAPPER=.../gcc/lib/gcc/x86_64-linux-gnu/11.1.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../gcc-repo/configure --pro
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
Created attachment 50961
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50961&action=edit
test case
Providing the v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99529
--- Comment #4 from martin ---
Ok, here is another suspicious data race in unit.c (backtrace from helgrind):
==7831== Possible data race during read of size 4 at 0x5DE4620 by thread #296
==7831== Locks held: 1, at address 0x2EE5D00
==7831==a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99529
--- Comment #3 from martin ---
Thanks for looking at the report and providing a patch to test.
For completeness sake, here is the simple test code, which does not fail, but
which shows the data race in helgrind (compile with -fopenmp -g2):
progr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88735
--- Comment #5 from martin ---
Hi Ev,
the testcase is actually derived from a smart pointer implementation (where i
is the reference count, shared between all smart pointers [hence allocatable
will not do], and incremented upon sharing). It woul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924
--- Comment #7 from martin ---
With a recent gfortran version I get (how did you compile that you can run the
code):
fun_select.f90:37:15:
37 | f => selector()
| 1
internal compiler error: Segmentation fault
0xc1f3af cras
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924
--- Comment #4 from martin ---
Created attachment 50053
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50053&action=edit
reduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93918
--- Comment #6 from martin ---
Sorry, wrong issue...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93918
--- Comment #5 from martin ---
Created attachment 50052
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50052&action=edit
reduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924
--- Comment #3 from martin ---
The submitted testcase is invalid fortran, see bug 93925. However, with the
same small fix it becomes valid and still fails. Sorry for the mistake.
Instead of a fix, I have attached a much reduced testcase showing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925
--- Comment #5 from martin ---
Sorry for this invalid test case, obviously I did reduce too much. The three
attached variations should hopefully all be conforming to the standard and
still produce the same error. Please reopen if the testcases ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925
--- Comment #4 from martin ---
Created attachment 50050
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50050&action=edit
classStar_map4 without target nor pointer attributes for variable x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925
--- Comment #3 from martin ---
Created attachment 50049
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50049&action=edit
classStar_map3 with class(*), pointer for variable x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925
--- Comment #2 from martin ---
Created attachment 50048
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50048&action=edit
classStar_map2 with pointer attribute for variable x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
--- Comment #3 from martin ---
Sorry for the noise, but as this gives big reductions in compilation time it is
quite important to me (and probably other big module based projects).
I just realised that I mixed up gfc_symtree->name and gfc_symtre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
--- Comment #2 from martin ---
I further tried to find out what the call to find_symbol (this is the call
which consumed the compilation time) is achieving in read_modules(). Even with
the accidentially wrong patch everything just seems to work (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
--- Comment #1 from martin ---
Created attachment 49846
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49846&action=edit
corrected patch
Comparison with c was wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454
martin changed:
What|Removed |Added
CC||mscfd at gmx dot net
--- Comment #9 from
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
Created attachment 49837
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49837&action=edit
patch
Compilation times of top level mod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342
--- Comment #4 from martin ---
Just checked the patch and it works great, except that I can now easily produce
an ICE by changing (in sel_rank)
type(tuple), dimension(..), intent(in) :: x
to
class(*), dimension(..), intent(in) :: x
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342
--- Comment #1 from martin ---
This does not the require the recent patch proposed for bug 97694 and bug
97723. It also fails with gfortran 10.1.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97694
--- Comment #6 from martin ---
There is still a somewhat related problem if a variable of a derived type with
allocatable component is provided to cssel. See bug 98342 with a simplified
example code (without class(*)).
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
Created attachment 49784
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49784&action=edit
Fortran source co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97694
--- Comment #5 from martin ---
Thanks a lot. The patch seems to work great. Tried it with the more complex
code from which the two failed tests were boiled down.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97612
--- Comment #2 from martin ---
I do not see why it should not be valid.
t() is a structure constructor acting much like a function with (in this case)
one optional argument. And as an allocatable component has default
initialisation, no value nee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87142
--- Comment #4 from martin ---
With yesterdays master branch, I still see an invalid read with valgrind and an
"AddressSanitizer: heap-use-after-free"-error with -fsanitize=address. So looks
like this has not been fixed by the patch for PR 92178.
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
Created attachment 49504
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49504&action=edit
Fortran source code
Using an ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97694
martin changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
|
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
Created attachment 49494
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49494&action=edit
Fortran source code
The attached code crashs with an ICE. It requir
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
The program below does not compile with error message:
constructor_allocatable.F90:4:9:
4 | type :: s
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
The code below fails with an ICE in fold_convert_loc, at fold-const.c:2435.
There is another recent bug 94730 with an ICE at this location, but triggered
with C code. Is this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93691
martin changed:
What|Removed |Added
CC||mscfd at gmx dot net
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956
--- Comment #3 from martin ---
Sorry, indeed the line 'n=1' is missing. Not sure how that single line got
lost.
There are a few possibilities as a work around for this simple case, but the
context where I came upon this bug is (as often) mor
P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
The following code (compiled without any options) prints "15000, 1" for the
second call to foo, instead of the expected "2, 1". The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93918
--- Comment #4 from martin ---
After playing around a bit I am really confused about why and when array
temporaries are created.
The variant ppp_1 with a non-contiguous array pointer p works fine (with
-Ofast), but the variation ppp_2 (this time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93918
--- Comment #3 from martin ---
But there should not be an temporary array in the first place, which is causing
the problem?
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
The following code aborts with a segfault (invalid memory reference) upon call
of the apply function. This happens
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
The code below aborts with an ICE. This happens with 9.1.1 as well as a recent
gfortran-10 compiled version. The
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
The code below results in a SEGFAULT when compiled with -Ofast in gfortran
9.1.1 as well as some recent compiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
martin changed:
What|Removed |Added
CC||mscfd at gmx dot net
--- Comment #9 from
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
The following code (classstar_alloc3 from PR86328, but much reduced; the
original bug case from this PR has been fixed, the one below
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88669
--- Comment #6 from martin ---
Thanks for fixing.
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
The code below should be invalid, as the selector x has attribute "target" but
not "pointer" inside the sel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88768
--- Comment #3 from martin ---
I have opened a separate PR 88899 for the openmp related invalid memory read,
but I guess it might have the same cause.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88899
martin changed:
What|Removed |Added
Known to fail||8.2.1
--- Comment #2 from martin ---
Related t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88899
--- Comment #1 from martin ---
With sufficiently many threads (at least 5 or 6 for me) the address santizer
gives (for gfortran-9, compiled a few weeks ago):
==3485==ERROR: AddressSanitizer: attempting double-free on 0x6020001956d0 in
thread T4:
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
The code below fails with an invalid memory read. The derivated type IO
write(formatted) is declared but not used. Without this line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88768
--- Comment #2 from martin ---
If I add the "generic :: write(unformatted) => write_unformatted" part in my
code (but do not use it), I see other failures somehow triggered by openmp
parallelisation (no recursion involved). Using the address sani
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
This is a strange bug, which requires a some kind of dt IO (defined as "
generic :: write(unformatted) => write_unf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88735
--- Comment #1 from martin ---
Remark: output should be one line
setting: 123
If the output starts with
finalising: 123
then this is wrong (as b%x%i is not associated when finalise is called for
b%x).
Also present in current g
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
In the following code a type "t" is defined in module mod, which provides an
assignment method and a final routine. The prog
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
The code below gives the following error
contiguous_pointer.f90:7:51:
class(t), dimension(:), contiguous, pointer :: x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88447
--- Comment #1 from martin ---
Here is a smaller reproducer. The component "integer :: i" in type t is
necessary to reproduce the bug.
module mod
implicit none
private
public qv
type, public :: s
real, dimension(1:3) :: vec
end type s
typ
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
Using a non-contiguous argument to a subroutine whose declaration is "class(s),
dimension(:)" gives wrong results.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87448
--- Comment #2 from martin ---
Originally I came across this problem in a large module with a slightly more
complex function with gfortran-7.3.0 (standard version from ubuntu 18.4). I got
the same bogus error, which Janus has seen for this reduce
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
The following code triggers an ICE (also seen in some gfortran-7 version):
module mod
implicit none
public
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87142
--- Comment #1 from martin ---
The relevant passage from the standard is:
F2008, 12.4.3.4.3 (Defined assignments) says: "A defined assignment is treated
as a reference to the subroutine, with the left-hand side as the first argument
and the righ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328
--- Comment #17 from martin ---
Thanks for fixing it! Using class(*) with gfortran is still a bit of a
precarious ride.
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
The following code does not work, as the left hand side in "str = str%cs(1:10)"
is deallocated, before the right hand side,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328
--- Comment #12 from martin ---
The workaround mentioned by Paul in comment #9 is working only partially. For
character sequences (and possibly other data types), valgrind still complains.
Surprisingly, using a single character works as well. On
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86350
martin changed:
What|Removed |Added
CC||mscfd at gmx dot net
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328
martin changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
|
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
The following code leads to a runtime segfault:
program ptr_alloc
type :: t
class(*), allocatable :: val
end
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
The following program, compiled with -Wall gives the warning
l2 = len(s)
1
Warning: Possible change of
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
Compiling the following module with
gfortran -Og -Wall -fcheck=all -c mod.f90
gives
Warning: ‘’ may be used
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
The following module should not compile. Calling sub(z) with z declared as
"type(t), allocatable :: z" shows the ambiguity.
Replacing "type(t) :: x" by &
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
related: bug 72790
Applying move_alloc(x,y) for x and y both declared as class(*) and x currently
containing a string
92 matches
Mail list logo
