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
> >
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
--- 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 #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=20514action=view)
d3.c
BTW, I've timed different variants of the C code for the tonto loop, and
time /tmp/d3 1
real0m0.667s
--- 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 in
--- 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.
--- 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
--- 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 #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 needed
--- 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 #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 #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 #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=20230action=view)
Draft patch for NULL check for deallocation
Draft patch for removing the NULL check before __builtin_free.
--- 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
--- 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
--- 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 #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 #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=20225action=view)
testcase from tonto
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
--- 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 bb 32;
else
goto bb 33;
bb 32:
--- 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 bb 34;
else
goto bb 33;
bb 33:
D.1620_204 = __builtin_malloc (D.1795_11);
--- 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=gccview=revrev=156923
Log:
2010-02-20 Tobias Burnus bur...@net-b.de
PR
--- 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 #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)
Why
--- 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 #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.
Then we
--- 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
26 matches
Mail list logo
