--- Comment #21 from pault at gcc dot gnu dot org 2006-12-22 20:49 ---
Subject: Bug 25818
Author: pault
Date: Fri Dec 22 20:49:00 2006
New Revision: 120155
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120155
Log:
2006-12-22 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #20 from patchapp at dberlin dot org 2006-12-22 02:20 ---
Subject: Bug number PR25818
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01527.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #19 from pault at gcc dot gnu dot org 2006-12-09 21:42 ---
Promises, promises...
>
> It is regtesting as I write; if all is well, I will submit tonight with a
> testcase based on pr30025.
>
I'll come to this just as soon as the interface stuff is a bit more sorted. -
like n
--- Comment #18 from paulthomas2 at wanadoo dot fr 2006-12-07 17:33 ---
Subject: Re: Problem with handling optional and entry
master arguments
elizabeth,
>
> We are talking about the same machine and the same operating system. All the
> x86_64 binaries are from http://quatramaran.en
--- Comment #17 from elizabeth dot l dot yip at boeing dot com 2006-12-07
01:37 ---
Paul,
I located the following binary and loaded it on my dell 670 (SUSE 9.3):
gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/var/tmp/gfor
--- Comment #16 from paulthomas2 at wanadoo dot fr 2006-12-02 17:56 ---
Subject: Re: Problem with handling optional and entry
master arguments
elizabeth dot l dot yip at boeing dot com wrote:
> It worked using gfortran on my OS X system.
>
> ~/src/C_C++ $ gfortran -v
> Using built-in
--- Comment #15 from elizabeth dot l dot yip at boeing dot com 2006-12-01
20:24 ---
One of my colleaques said my test code in Bug 30025 works on his MAC OS X
system at home. He has an older version of gfortran. Here is what he wrote:
It worked using gfortran on my OS X system.
~/src
--- Comment #13 from pault at gcc dot gnu dot org 2006-11-30 15:52 ---
Created an attachment (id=12715)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12715&action=view)
A development of Alexander Taeschner's patch
It is regtesting as I write; if all is well, I will submit tonight
--- Comment #13 from pault at gcc dot gnu dot org 2006-11-30 15:52 ---
Created an attachment (id=12715)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12715&action=view)
A development of Alexander Taeschner's patch
It is regtesting as I write; if all is well, I will submit tonight
--- Comment #12 from pault at gcc dot gnu dot org 2006-11-30 14:25 ---
(In reply to comment #2)
> I'm an absolute beginner in programming gfortran, but the following patch
I am coming to the conclusion that your patch is one of three possible
solutions to this and pr30025:
(i) Do as yo
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-11-30 11:58
---
*** Bug 30025 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from jakub at gcc dot gnu dot org 2006-10-12 12:46 ---
No, that sounds wrong. Not all dummy arguments have such type, so such a
change
just leads to strict aliasing violations and there are also dummy arguments
that
are larger than long.
--
http://gcc.gnu.org/bugzil
--- Comment #9 from pault at gcc dot gnu dot org 2006-10-12 12:31 ---
(In reply to comment #8)
> Paul, Jakub,
> Is the patch in comment #7 considered to be the right approach?
> I tried applying to my local tree, but a few chunks were rejected.
Jakub? What about it?
Paul
--
http:/
--- Comment #8 from kargl at gcc dot gnu dot org 2006-09-29 00:30 ---
Paul, Jakub,
Is the patch in comment #7 considered to be the right approach?
I tried applying to my local tree, but a few chunks were rejected.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25818
--- Comment #7 from paul dot richard dot thomas at cea dot fr 2006-09-18
15:33 ---
I mixed up my types above; using a gfc_array_index_type seems to
cover every circumstance where missing arguments can be addressed
with legal code.
Regtests on FC5/Athlon.
Index: gcc/fortran/trans-decl.
--- Comment #6 from pault at gcc dot gnu dot org 2006-08-21 13:35 ---
Jakub and co.,
Does the below do it for you? Instead of passing null, I propose to pass the
address of a longlong containing zero. This then leaves the normal passing of
NULL to possibly represent a missing optional
--- Comment #5 from taschna at uni-muenster dot de 2006-07-31 07:49 ---
(In reply to comment #3)
Steve,
> [...]It's more a question of "why is it a NULL pointer?" not
> whether we can work around the NULL pointer.
i finally found Paul's mail corresponding to patch revision
86128: http:
--- Comment #4 from taschna at uni-muenster dot de 2006-07-31 06:32 ---
(In reply to comment #3)
Steve,
> Thanks for the patch, but I think it is only covering up the real
> problem. It's more a question of "why is it a NULL pointer?" not
> whether we can work around the NULL pointer.
--- Comment #3 from kargl at gcc dot gnu dot org 2006-07-30 22:46 ---
(In reply to comment #2)
> I'm an absolute beginner in programming gfortran, but the following
> patch seems to solve this bug by inserting an if-block into the code
> in order to prevent the access to the NULL pointer
--- Comment #2 from taschna at uni-muenster dot de 2006-07-27 22:38 ---
I'm an absolute beginner in programming gfortran, but the following patch seems
to solve this bug by inserting an if-block into the code in order to prevent
the access to the NULL pointer in case the array is pointin
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-17 16:04 ---
There are a couple of issues here, first there is a missed optimization to sink
the load (there is a bug about that). In fact this is all related to that bug.
Also there is a front-end bug having the load there in
21 matches
Mail list logo
