--- Comment #18 from jvdelisle at gcc dot gnu dot org 2010-08-08 01:59
---
Subject: Bug 31588
Author: jvdelisle
Date: Sun Aug 8 01:59:15 2010
New Revision: 162990
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162990
Log:
2010-08-07 Daniel Franke
PR fortran/31588
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2010-08-07 16:52
---
Subject: Bug 31588
Author: jvdelisle
Date: Sat Aug 7 16:51:55 2010
New Revision: 162980
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162980
Log:
2010-08-07 Daniel Franke
2010-06-13 Daniel
--- Comment #16 from dfranke at gcc dot gnu dot org 2010-06-13 16:07
---
Fixed in trunk. See PR44526 for a follow-up request for libcpp.
Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #15 from dfranke at gcc dot gnu dot org 2010-06-13 16:05
---
Subject: Bug 31588
Author: dfranke
Date: Sun Jun 13 16:05:01 2010
New Revision: 160684
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160684
Log:
2010-06-13 Daniel Franke
PR fortran/31588
--- Comment #14 from dfranke at gcc dot gnu dot org 2010-06-12 21:46
---
(In reply to comment #13)
> Would it be ok to require '-cpp' with '-M' or shall '-M' work without explicit
> preprocessing enabled? In the latter case, would it be ok to enable
> preprocessing implicitly?
"Passing
--- Comment #13 from dfranke at gcc dot gnu dot org 2010-06-12 21:06
---
Would it be ok to require '-cpp' with '-M' or shall '-M' work without explicit
preprocessing enabled? In the latter case, would it be ok to enable
preprocessing implicitly?
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #12 from dfranke at gcc dot gnu dot org 2010-05-03 18:09
---
*** Bug 43954 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31588
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot
|dot org
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-03-26 03:35
---
Ignore comment #10, I entered the wrong number, it should have been 31558.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31588
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-03-26 03:32
---
Subject: Bug 31588
Author: pinskia
Date: Wed Mar 26 03:32:13 2008
New Revision: 133541
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133541
Log:
2008-03-25 Andrew Pinski <[EMAIL PROTECTED]>
PR
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2008-01-31 00:26
---
(In reply to comment #8)
> As I see it, gfortran never knows it does syntax checking only?!
Exactly.
> What exactly do you mean by "#file headers"? Preprocessor include directives
> as
> `#include "foo.inc"`?
--- Comment #8 from dfranke at gcc dot gnu dot org 2008-01-30 22:22 ---
> Not actively. It's probably not so hard, though: read the file, like we
> do with -fsyntax-only mode, and parse #file headers.
FX, I'm lost here. The flag_syntax_only is not used anywhere in the fortran
directory
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-10-06 21:36 ---
For once, the segfault is in the
gfortran driver, not the f951 binary.
Backtrace, plus some more debug info:
$ gdb ~/bin/gfortran
GNU gdb 6.6.90.20070912-debian
Copyright (C) 2007 Free Software Foundation, Inc.
Li
--- Comment #6 from rep dot dot dot nop at gmail dot com 2007-06-04 20:50
---
Subject: Re: gfortran should be able to output Makefile dependencies with -M*
options
On Mon, Jun 04, 2007 at 05:39:48PM -, fxcoudert at gcc dot gnu dot org
wrote:
>
>
>--- Comment #5 from fxcoudert
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-06-04 17:39
---
(In reply to comment #4)
> fx, are you still working on this?
Not actively. It's probably not so hard, though: read the file, like we do with
-fsyntax-only mode, and parse #file headers.
> yet another reason why
--- Comment #4 from aldot at gcc dot gnu dot org 2007-06-04 17:20 ---
fx, are you still working on this?
yet another reason why "-M" as an alias for -J should be dropped and instead
proper -M dependency handling should be added is this:
$ echo end > foo.f90 && gfortran -o main foo.f90
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-16 15:28 ---
What about
include "foo.f90"
and
#include "bar.f90"
(g95 handles both)
And what about
include "z.f90"
where "z.f90" is foo/z.f90 and is found via
gfortran -Jfoo ?
(g95 does not handle this and writes: b.o b.mod:
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-04-16 11:06
---
(In reply to comment #1)
> How about USE association?
That's also part of the plan.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31588
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-04-16 11:02 ---
FX, +5 karma for this proposal :)
How about USE association? For example
$> cat a.f90
module a
[...]
end module
$> cat b.f90
[...]
USE a
[...]
$> gfortran -M a.f90
a.o a.mod: a.f90
$> gfortran -M b.f90
b.o: a.mod
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
21 matches
Mail list logo
