https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
--- Comment #26 from Thomas Koenig ---
(In reply to Dominique d'Humieres from comment #25)
> > If you find anything still missing in the library, please let me know.
> > I thought I had converted everything to the macros, which are fairly
> > eas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
--- Comment #25 from Dominique d'Humieres ---
> If you find anything still missing in the library, please let me know.
> I thought I had converted everything to the macros, which are fairly
> easy to change, but I may be mistaken.
Is there anyth
--- Comment #24 from tkoenig at gcc dot gnu dot org 2010-04-29 19:09
---
(In reply to comment #22)
> It is my intention to change the array descriptor representation and
> to start with an API that provides the (lbound, ubound,stride) values.
> In fact, this API has already been put i
--- Comment #23 from jakub at gcc dot gnu dot org 2010-04-29 13:18 ---
Created an attachment (id=20514)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20514&action=view)
d3.c
BTW, I've timed different variants of the C code for the tonto loop, and
time /tmp/d3 1
real0m0.667s
u
--- Comment #22 from paul dot richard dot thomas at gmail dot com
2010-04-29 10:02 ---
Subject: Re: Weird temporary array allocation
> As an aside, for the 4.6 array descriptor update, there has been some
> discussion to move from the current (lbound, ubound, stride) triplet for every
--- Comment #21 from jb at gcc dot gnu dot org 2010-04-28 15:43 ---
(In reply to comment #19)
> (In reply to comment #18)
> > 3) for the same reason you can also drop the + 1 in computing the
> > allocation
> > size which is currently (ubound - lbound + 1) * 4
>
> Sorry, but isn't +1
--- Comment #20 from jv244 at cam dot ac dot uk 2010-04-28 15:20 ---
(In reply to comment #18)
>
> If that's all acceptable I will work on this soon.
>
FYI, this would fix PR38318 and PR21046
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
--- Comment #19 from amonakov at gcc dot gnu dot org 2010-04-28 15:15
---
(In reply to comment #18)
> 3) for the same reason you can also drop the + 1 in computing the allocation
> size which is currently (ubound - lbound + 1) * 4
Sorry, but isn't +1 needed because bounds are inclusiv
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-04-28 14:52
---
Updating the status on this bugreport. I am working on middle-end support
for hoisting/sinking malloc/free pairs out of loops (in case the size is
loop invariant). The Fortran FE makes this somewhat difficult.
F
--- Comment #17 from burnus at gcc dot gnu dot org 2010-04-16 08:17 ---
Another case where the "if NULL" check is not needed before the "free" are
automatic arrays:
subroutine sub(n)
integer :: a(n)
a(1) = 0
end
Additionally, the dump looks overly complicated and a least two
--- Comment #16 from rguenther at suse dot de 2010-03-28 14:45 ---
Subject: Re: Weird temporary array allocation
On Sun, 28 Mar 2010, burnus at gcc dot gnu dot org wrote:
> --- Comment #15 from burnus at gcc dot gnu dot org 2010-03-28 14:10
> ---
> Actually, I am wondering w
--- Comment #15 from burnus at gcc dot gnu dot org 2010-03-28 14:10 ---
Actually, I am wondering whether one needs to do
D.1620_135 = __builtin_malloc (1);
for temporary arrays. For user-accessible ALLOCATABLE arrays one does - because
ALLOCATED(array) needs also to be .TRUE. for zero-
--- Comment #14 from burnus at gcc dot gnu dot org 2010-03-28 13:56 ---
Created an attachment (id=20230)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20230&action=view)
Draft patch for NULL check for deallocation
Draft patch for removing the NULL check before __builtin_free. Acco
--- Comment #13 from burnus at gcc dot gnu dot org 2010-03-28 13:05 ---
(In reply to comment #12)
> (I am thinking of
>call f(array(...))
> where one knows that "f" does not allow for a zero-sized array argument.
s/where/if/ - in the general case one does not know. Especially for
--- Comment #12 from burnus at gcc dot gnu dot org 2010-03-28 12:57 ---
(In reply to comment #8)
> atmp.5.dim[0].lbound = 0;
> atmp.5.dim[0].ubound = D.1612;
> D.1616 = D.1612 < 0;
>
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-03-27 19:12
---
The middle-end ends up with the following optimized:
D.1776_95 = D.1775_94 - D.1591_90;
if (D.1776_95 <= 0)
goto ;
else
goto ;
:
D.1620_204 = __builtin_malloc (D.1795_11);
D.1796_281 = iy.dim[1]
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-03-27 19:08
---
The gimplifier of course transforms the COND_EXPRs back to control flow, thus
the CFG looks like
D.1616 = D.1612 < 0;
D.1617 = D.1612 + 1;
if (D.1616 != 0)
goto ;
else
goto ;
:
iftmp.17 = 0;
g
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-03-27 19:06 ---
Created an attachment (id=20225)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20225&action=view)
testcase from tonto
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-27 19:05 ---
I suppose I should have provided a testcase. The FE now produces control-flow
free allocation like:
D.1612 = D.1601 - D.1600;
atmp.5.dtype = 537;
--- Comment #7 from pault at gcc dot gnu dot org 2010-03-27 18:55 ---
Tobias,
Can this be closed now?
Certainly, it can be confirmed!
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from burnus at gcc dot gnu dot org 2010-02-20 08:31 ---
Subject: Bug 42958
Author: burnus
Date: Sat Feb 20 08:31:25 2010
New Revision: 156923
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156923
Log:
2010-02-20 Tobias Burnus
PR fortran/42958
*
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-02-17 20:17
---
Tobias, reply to your RFC on fortran list. I think the negative check should
go away. Then I think we should consider an option of -fcheck-mem-alloc which
we can then make more elaborate and do numerouse useful
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-05 14:23 ---
(In reply to comment #3)
> Subject: Re: Weird temporary array allocation
>
> On Fri, 5 Feb 2010, pault at gcc dot gnu dot org wrote:
>
> > --- Comment #2 from pault at gcc dot gnu dot org 2010-02-05 05:36
>
--- Comment #3 from rguenther at suse dot de 2010-02-05 09:32 ---
Subject: Re: Weird temporary array allocation
On Fri, 5 Feb 2010, pault at gcc dot gnu dot org wrote:
> --- Comment #2 from pault at gcc dot gnu dot org 2010-02-05 05:36 ---
> (In reply to comment #1)
>
> > Wh
--- Comment #2 from pault at gcc dot gnu dot org 2010-02-05 05:36 ---
(In reply to comment #1)
> Why there is a negative check? Well, I do not know. I also can speculate about
> a poor man's overflow check, which sometimes indeed works, but often fails.
I suspect that you are being gen
--- Comment #1 from burnus at gcc dot gnu dot org 2010-02-04 19:32 ---
> so, we check if the array-size is empty, ubound - lbound < 0. In that
> case we set size to zero. Otherwise we compute it
> as (ubound - lbound + 1) *8.
> Then we check whether size is negative and error out.
> Th
27 matches
Mail list logo
