Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: baradi09 at gmail dot com
Target Milestone: ---
User defined assignment for derived types fails to compile, if the signature of
the various assignments only differ in their rank. The
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: baradi09 at gmail dot com
Target Milestone: ---
The line number and the code shown in error messages are inconsistent, when
instead of preprocessing a file on the fly (option -cpp) the file is
preprocessed first (-cpp
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: baradi09 at gmail dot com
Target Milestone: ---
I get an ICE on the minimal self containing input below. Shifting the module
import from within the internal subroutine to the host (program) level avoids
the ICE. Also
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: baradi09 at gmail dot com
Target Milestone: ---
Created attachment 36291
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36291&action=edit
Fortran file demonstrating the issue
Dear developer,
Thank you f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67444
--- Comment #2 from Bálint Aradi ---
Apparently, this is point c) in PR 37336 comment 27.
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: baradi09 at gmail dot com
Target Milestone: ---
Created attachment 36405
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36405&action=edit
Self containing
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: baradi09 at gmail dot com
Created attachment 34268
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34268&action=edit
Self contained source demonstrating
During an assingment with an allocatable type on both, the
Severity: major
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: baradi09 at gmail dot com
Created attachment 33474
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33474&action=edit
Source file which trigg
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: baradi09 at gmail dot com
Created attachment 33477
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33477&action=edit
Fortran source file demons
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: baradi09 at gmail dot com
Target Milestone: ---
When having a derived type with a type(C_PTR) component, which is default
initialized to C_NULL_PTR, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68778
--- Comment #2 from Bálint Aradi ---
For me on x86_64-linux, with GNU Fortran (GCC) 5.2.0 it produces:
TEST2: ASSOCIATED? (EXPECT: F) T
Since, it is an uninitialized c-pointer, it probably depends pretty much on the
environment whether the test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68778
--- Comment #3 from Bálint Aradi ---
(In reply to Bálint Aradi from comment #2)
> For me on x86_64-linux, with GNU Fortran (GCC) 5.2.0 it produces:
>
> TEST2: ASSOCIATED? (EXPECT: F) T
>
> Since, it is an uninitialized c-pointer, it probably de
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: baradi09 at gmail dot com
Target Milestone: ---
Created attachment 37279
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37279&action=edit
Self contained example, file 1
Compiler crashes when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69200
--- Comment #1 from Bálint Aradi ---
Created attachment 37280
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37280&action=edit
Self contained example, file 2
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: baradi09 at gmail dot com
Target Milestone: ---
Created attachment 52754
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52754&action=edit
Minimal working example demonstrating the bug
I have a deriv
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: baradi09 at gmail dot com
Target Milestone: ---
The following snippet triggers a compilation error
test.f90:17:25:
17 | inst = type2("test", 1)
|
Assignee: unassigned at gcc dot gnu.org
Reporter: baradi09 at gmail dot com
Target Milestone: ---
When trying to build Fortuno (https://github.com/aradi/fortuno), our new
Fortran unit testing system, I encounter a segfault with GFortran. The problem
can be reduced to the following MWE
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: baradi09 at gmail dot com
Target Milestone: ---
Created attachment 52196
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52196&action=edit
Demonstration code
Dear developer
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: baradi09 at gmail dot com
Target Milestone: ---
The following module is, at least according to the discussion on
fortran-lang.discourse
(https://fortran-lang.discourse.group/t
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: baradi09 at gmail dot com
Target Milestone: ---
Based on the discussion on FD
(https://fortran-lang.discourse.group/t/is-the-section-of-a-pointer-to-an-array-a-valid-pointer/2331),
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107362
--- Comment #3 from Bálint Aradi ---
> I'm getting the same issue on a recursive tree structure, I will post my
> testcase here instead of opening a new bug.
I am not sure, whether the two bugs are identical. If I understand correctly,
you can
: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: baradi09 at gmail dot com
Target Milestone: ---
Issue:
GIVEN a derived type with an allocatable component
WHEN an instance of this type is
: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: baradi09 at gmail dot com
Target Milestone: ---
* Issue:
GIVEN
a derived type containing a pointer array of a
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: baradi09 at gmail dot com
Target Milestone: ---
This is a very minor bug, but probably easy to fix. It seems, that the T data
edit descriptor handling is non-standard conforming when using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
--- Comment #5 from Bálint Aradi ---
I also think that by allowing for explicit EORs caused by achar(10) characters
in the variable being written or by explicit new_line() calls, the standard
made the formatted stream output probably more compli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740
--- Comment #14 from Bálint Aradi ---
Thanks a lot for fixing it!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105170
--- Comment #2 from Bálint Aradi ---
Thanks, with 13.2.0, it seems to behave correctly.
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: baradi09 at gmail dot com
Target Milestone: ---
I get an internal compiler error with the following demo code. As far, as I can
judge, the code is standard conforming.
module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113118
--- Comment #1 from Bálint Aradi ---
Just a further note, if I leave away dummy argument names, I do not get an ICE
any more, but the program still does not compile:
24 | item = base_type_item(derived_type(name, val))
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113118
--- Comment #2 from Bálint Aradi ---
Last note: replacing the problematic line with
allocate(item)
item%item = derived_type(name=name, val=val)
seems to compile (but I did not check, whether the compiled code behaves
correctly).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116679
--- Comment #1 from Bálint Aradi ---
# An even simpler, but probably strongly related scenario also causes a
leakage:
program bugdemo_app
use bugdemo
implicit none
type :: wrapper
integer, allocatable :: item
end type wrapper
ty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107362
--- Comment #5 from Bálint Aradi ---
Checked with gfortran 14.1, the example still gives a segfault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106507
--- Comment #1 from Bálint Aradi ---
Tested with gfortran 14.1, the issue is still present, the example still can
not be compiled and triggers the same (false) error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68778
Bálint Aradi changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104036
Bálint Aradi changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113118
Bálint Aradi changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114618
Bug 114618 depends on bug 109358, which changed state.
Bug 109358 Summary: Wrong formatting with T-descriptor during stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78942
Bálint Aradi changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103434
Bálint Aradi changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105170
Bálint Aradi changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
Bálint Aradi changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
41 matches
Mail list logo