[Bug fortran/78293] [5/6/7 Regression] SIGABRT with function result used as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78293 --- Comment #6 from Andre Vehreschild --- Hi Paul, I am busy doing Coarray work at the moment. So from my side: no time. You may want to have a look whether the part in trans-expr.c fixes the issue sufficiently or with just a small work-around in gfc_trans_allocate. But I would not spend to much time on that, because the part in trans_allocate may heavily depend on the new structure and therefore be a pain in the ass to port. (But honestly, I haven't shed an eye on this). HTH. - Andre On Sat, 01 Apr 2017 12:03:20 + "pault at gcc dot gnu.org" wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78293 > > --- Comment #5 from Paul Thomas --- > (In reply to Dominique d'Humieres from comment #4) > > Revision r242875 caused pr79344. Is there any plan to back port the fixes to > > the 6 branch? > > That's a good question. What is your opinion? > > Cheers > > Paul >
[Bug fortran/78958] FAIL: gfortran.dg/alloc_comp_class_5.f03 - Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78958 Andre Vehreschild changed: What|Removed |Added CC||vehre at gmx dot de --- Comment #3 from Andre Vehreschild --- Created attachment 40620 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40620&action=edit Preliminary patch The attached patch fixes the issue at least on x86_64-linux and the sanitizer does not report any further issues. Please test.
[Bug fortran/78505] [F08] Coarray source allocation not synchronizing on oversubscribed cores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78505 --- Comment #7 from Andre Vehreschild --- As you can see from the commit message in comment #3 it hit trunk on 9th of Dezember. Am 19. Dezember 2016 21:03:38 MEZ, schrieb damian at sourceryinstitute dot org : >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78505 > >--- Comment #6 from Damian Rouson >--- >Please let me know which day this hit (or will hit) the trunk. I'm >currently >using a build dated 20161215.
[Bug fortran/67171] [6 regression] sourced allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67171 --- Comment #6 from Andre Vehreschild --- Hi Paul, No it's not, but the patch for the other pr addresses a lot of things in the allocate. Mostly about functions returning class objects, but I remember to have changed some of the things your patch might address . I just wanted to point you to similar work. Regards, Andre
[Bug fortran/67171] [6 regression] sourced allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67171 --- Comment #4 from Andre Vehreschild --- Hi Paul, please compare: https://gcc.gnu.org/ml/fortran/2015-10/msg00033.html to your fix. Sounds like we are doing the same. - Andre On Tue, 20 Oct 2015 14:13:55 + "pault at gcc dot gnu.org" wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67171 > > Paul Thomas changed: > >What|Removed |Added > >Assignee|unassigned at gcc dot gnu.org |pault at gcc dot > gnu.org > > --- Comment #3 from Paul Thomas --- > The bug arises because array sections are marked as DECL_ARTIFICIAL and so the > offending SOURCE expression produces a temporary variable, whose offset is out > of kilter, being zero. The most economical solution, in terms of effort, is > simply to suppress the creation of the temporary, when the source is a > variable. This is regtesting right now. Alternatively, the array descriptor > could be converted to unity based indexes, with the appropriate offset. > > I'll take it. > > Paul >
[Bug fortran/60255] [OOP] Deferred character length variable at (1) cannot yet be associated with unlimited polymorphic entities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60255 Andre Vehreschild changed: What|Removed |Added Status|ASSIGNED|RESOLVED Version|4.9.0 |5.0 Resolution|--- |FIXED --- Comment #8 from Andre Vehreschild --- Fixed with r219827.
[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60322 Andre Vehreschild changed: What|Removed |Added CC||vehre at gmx dot de --- Comment #6 from Andre Vehreschild --- When I see this correctly, we have two ways to resolve this issue: 1. Make sure that the temporary array created to be passed to copyFromArr() has lbound=1, ubound=1, size(1), or 2. Make sure the additional temporary array in copyFromArr() is created and the bounds are set correctly. Which one is the preferred way?
[Bug fortran/60334] Segmentation fault on character pointer assignments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60334 Andre Vehreschild changed: What|Removed |Added CC||vehre at gmx dot de --- Comment #4 from Andre Vehreschild --- Patch available in: https://gcc.gnu.org/ml/fortran/2015-01/msg00048.html
[Bug fortran/55901] [OOP] type is (character(len=*)) misinterpreted as array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901 --- Comment #12 from Andre Vehreschild --- Hi Paul, hi Tobias, I am guilty in asking both of you to look at the issue. I would be very happy, if one of you two can really have a look into the issue and notify the other one, that he found a reason for the issue and may be already has a solution. I just want to get the issue resolved but not produce duplicate work. Regards, Andre On Wed, 07 Jan 2015 13:16:25 + "paul.richard.thomas at gmail dot com" wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901 > > --- Comment #11 from paul.richard.thomas at gmail dot com > --- Hi Harald, > > Happy New Year! I have been away in Claifornia these last few weeks and > just got back last night. > > I am working with Andre on pr60255 tonight. Once this is done, we should be > in a position to fix pr55901 and have it do something useful! > > Cheers > > Paul > > On 6 January 2015 at 20:50, anlauf at gmx dot de > wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901 > > > > --- Comment #10 from Harald Anlauf --- > > (In reply to paul.richard.tho...@gmail.com from comment #9) > > > By the way, the patch of comment 8 bootstraps and regtests OK > > > > > > Paul > > > > Hi Paul, > > > > any news on that patch? > > > > Harald > > > > -- > > You are receiving this mail because: > > You are on the CC list for the bug. > > >
[Bug fortran/60289] allocating class(*) pointer as character gives type-spec requires the same character-length parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60289 --- Comment #5 from Andre Vehreschild --- Patch available in: https://gcc.gnu.org/ml/fortran/2014-12/msg00133.html
[Bug fortran/60357] [F08] structure constructor with unspecified values for allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357
--- Comment #11 from Andre Vehreschild ---
Hi Janus,
before you invest too much time into that: My current patch level produces
intermediate code as attached (for a slightly different program, also
attached).
I was solving the (re-)alloc on assign issue like in PR61275. I now run into
the
runtime error:
At line 15 of file test_pr60357.f08: Attempting to allocate
already allocated variable 'de'.
Obviously I have over fullfilled the needed allocs:
(1) a.5.y is allocated
(2) a.4.y is allocated
(3) a.0.y is allocated
(4) de.y is allocated
(5) a.2.y is allocated
I am wondering which allocs should really be done, and which one are accidently
added. I doubt that (1) and (2) should be there. (3) and (5) are ok imho. Now
my client (the reporter of the bug, Antony) tells me, that (4) is valid Fortran
("valid" by ifort), but the allocate(De%y) is useless there, as it is freed
before the constructor assign with implicit alloc is done. With my current
patch level, your program would be running fine, because I would auto alloc y
on the assignment.
To summarize my questions:
Which allocs should be done?
Given the too allocs in (1) and (2) are removed, would the intermediate code be
correct for the fortran?
Can you help me on this.
Regards,
Andre
On Mon, 29 Dec 2014 16:42:01 +
"janus at gcc dot gnu.org" wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357
>
> --- Comment #10 from janus at gcc dot gnu.org ---
> (In reply to Andre Vehreschild from comment #9)
> > I just need to
> > figure, if allocating the component explicitly is valid in Fortran.
>
> For sure. I think both the examples in comment 4 and 5 are actually valid
> Fortran code.
>
> In order to make sure we're talking about the same thing, let's have a look at
> the following code:
>
> Type A
> integer :: X = 1
> integer, allocatable :: y
> end type
> Type(A) :: Me
> allocate(Me%y)
> print *,"A"
> Me = A(X=1, y=2)
> print *,"B"
> print *, Me%y
> end
>
> This is a variant of the example above that produced the segfault. I inserted
> some print statements in order to debug it. It prints at runtime:
>
> A
> B
>
> Program received signal SIGSEGV: Segmentation fault - invalid memory
> reference.
>
>
> This shows clearly that the segfault occurs when we try to access Me%y in the
> last print statement, meaning that it is probably unallocated although it
> clearly should be.
>
> -fdump-tree-original shows that the problem is in the translation of the
> structure constructor assignment, which apparently leaves the y-component
> unallocated.
>
[Bug fortran/60357] [F08] structure constructor with unspecified values for allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357 --- Comment #12 from Andre Vehreschild --- Created attachment 34353 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34353&action=edit test_pr60357.f08
[Bug fortran/60357] [F08] structure constructor with unspecified values for allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357 Andre Vehreschild changed: What|Removed |Added CC||vehre at gmx dot de --- Comment #9 from Andre Vehreschild --- Hi Janus, be careful with the code in comment #4 and #5. When I remember correctly then it was me who added the allocate trying to understand how Fortran worked there. Meaning: That must not be valid Fortran. In fact, does my current work on this pr and on #61275 report that Me%y is already allocated and must not be reallocated again. That is, I may already have a patch that touches the issue. I just need to figure, if allocating the component explicitly is valid in Fortran. Do you know something about that? I am still reading the Fortran standards, but haven't found the location that answers my question. Andre
[Bug fortran/60414] internal compiler error: tree check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60414 --- Comment #6 from Andre Vehreschild --- I got no complains about the fix not working for someone, so at least the status can be set to resolved.
[Bug fortran/60255] Deferred character length variable at (1) cannot yet be associated with unlimited polymorphic entities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60255 Andre Vehreschild changed: What|Removed |Added CC||vehre at gmx dot de --- Comment #6 from Andre Vehreschild --- Created attachment 33267 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33267&action=edit Extended version of janus' patch. Includes testcase and more Hi, I propose an extended version of the patch janus began. I think we should also mark the symbol in the vtab to be deferred and not to have length 0 to prevent confussion with zero-length arrays. Please find patch attached and on ml. - Andre
[Bug fortran/60414] internal compiler error: tree check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60414 --- Comment #3 from Andre Vehreschild --- Hi, this is my first attempt on a patch. Please comment, when something is missing. The error occurs in the translation phase, but I tracked its source to the parse phase where parameter matching is done. The actual argument (array_ref) is not interpreted correctly. In fact, was the current code ignoring the array_ref and examined only the type of object to deref. Added check, if the actual argument is a deref. Added testcase. Found no regressions yet. - Andre
[Bug fortran/60414] internal compiler error: tree check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60414 Andre Vehreschild changed: What|Removed |Added CC||vehre at gmx dot de --- Comment #2 from Andre Vehreschild --- Created attachment 33141 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33141&action=edit Patch to resolve the compile problem
