--- 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=gccview=revrev=162980
Log:
2010-08-07 Daniel Franke franke.dan...@gmail.com
--- 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=gccview=revrev=162990
Log:
2010-08-07 Daniel Franke franke.dan...@gmail.com
--- 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=gccview=revrev=160684
Log:
2010-06-13 Daniel Franke franke.dan...@gmail.com
--- 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 #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?
--
--- 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 -M
--- 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 #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=gccview=revrev=133541
Log:
2008-03-25 Andrew Pinski [EMAIL PROTECTED]
PR
--- 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 #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 #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`?
Yes.
--- 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.
--- 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 -v
--- 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 #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 at
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
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
--- 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
--- 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 #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: b.F90
21 matches
Mail list logo
