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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115997
Bug ID: 115997
Summary: Findloc does not find the result of a function with a
deferred-length character return value
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
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'
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113797
Bug ID: 113797
Summary: Deferred length character concatenation in openmp
region has wrong length
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112764
Bug ID: 112764
Summary: Associating entity does not have target attribute if
selector has pointer attribute in associate block
Product: gcc
Version: 13.1.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110623
Bug ID: 110623
Summary: Segfault if type-bound procedure function provided for
an assumed rank class(*) argument
Product: gcc
Version: 14.0
Status: UNCONFIRMED
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=edit
fixed testcase class_dealloc.f90
As I just see, the first attachment does not show the bug as return value "a"
of function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106557
Bug ID: 106557
Summary: nesting intrinsics ibset and transfer gives wrong
result
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105800
Bug ID: 105800
Summary: Segfault deallocating a class, dimension(:) array
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105543
Bug ID: 105543
Summary: Function returning a class array with contiguous
attribute rejected
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
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=edit
reduced uninit_vptr
Testcase further reduced.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105503
Bug ID: 105503
Summary: vptr and data are uninitialised error for intent(out)
argument of abstract type
Product: gcc
Version: 12.0
Status: UNCONFIRMED
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
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,
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=edit
seemingly same problem but with associate instead of select type
A similar problem with associate shows the same problem
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)
| ^
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103039
Bug ID: 103039
Summary: Segfault with openmp block within a select type block
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
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=edit
second test case which segfaults
Playing around with some variants in select_rank_expression2.f90, I can see
that I
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100961
Bug ID: 100961
Summary: Intrinsic function as value to a class(*) assumed rank
argument fails
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity:
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==
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):
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
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
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=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=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
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=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=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=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
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
Bug ID: 98426
Summary: find_symbol in module.c traverses O(N) part of a
search tree
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
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(*)).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342
Bug ID: 98342
Summary: Allocatable component in call to assumed-rank routine
causes invalid pointer
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97723
Bug ID: 97723
Summary: type bound ASSIGNMENT(=) within select rank block
wrongly rejected
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97694
martin changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97694
Bug ID: 97694
Summary: ICE with optional assumed rank class(*) argument
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97612
Bug ID: 97612
Summary: Structure constructor of type with nested allocatable
array components fails to compile
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
54 matches
Mail list logo
