Home > Archive > Fortran > November 2004 > Re: recompile everything after compiler upgrade?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: recompile everything after compiler upgrade?
|
|
| Jan Vorbrüggen 2004-11-18, 8:58 am |
| >>Wouldn't it be a good idea for the standard to require that a compiler
> That is *WAY* *WAY* outside of the bounds of anything in the scope
> of the standard. Ok, the way things are now isn't necessarily the way
> things always have to be. But you might as well be talking about
> writing a whole different standard. The basic concepts to even
> talk about this subject aren't even in the current standard.
I think I agree with the general sentiment - that this is a quality-of-
implementation issue - but I'm not so sure about that last statement.
Surely, the standard could suggest/mandate/... that a processor check
whether a MODULE that is USEd be "compatible" (whatever that may be
defined to mean) with its operation? That likely would include rejecting
to USE a module that has been generated by a different processor (which,
I'm sure, all current compilers do...). AFAICT, the required concepts
are there.
Jan
| |
| Richard Edgar 2004-11-18, 8:58 am |
| Jan Vorbrüggen wrote:
>
> I think I agree with the general sentiment - that this is a quality-of-
> implementation issue - but I'm not so sure about that last statement.
> Surely, the standard could suggest/mandate/... that a processor check
> whether a MODULE that is USEd be "compatible" (whatever that may be
> defined to mean) with its operation? That likely would include rejecting
> to USE a module that has been generated by a different processor (which,
> I'm sure, all current compilers do...). AFAICT, the required concepts
> are there.
I must confess my ignorance of the detailed workings of the standards
process, but would it be possible to add an appendix basically saying
"We suggest you do it this way?" It would _not_ be part of the official
standard, but it would be there to help nudge compatibility between
compilers on the same platform.
The whole issue seems related to the recompile cascade which afflicts
module use - it's profoundly annoying when changing a PRIVATE constant
triggers the recompile of (most of) an entire program. Now, in the most
general case, with full inter-procedural optimisation is turned on, a
full recompile is needed. But not when I'm trying to debug something!
IIRC someone has come up with a PERL script which examines the .mod
files produced by compilers (not mandated by the standard, but most seem
to do this), and restores the old ones if they've not changed. In this
case, the appendix would suggest that compilers don't 'touch' (in the
UNIX sense) their .mod files if they've not changed.
I agree that this is not something that should be in the 'full' standard
- I hope that someone's going to come up with a better way of making
computers work, and I don't want Fortran nailed to the current mess -
but it would be nice to see something that helped with some of these issues.
Richard
|
|
|
|
|