[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change

--- Comment #14 from fxcoudert at gcc dot gnu dot org 2007-04-24 22:38 --- Fixed on mainline. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change

--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-04-24 22:37 --- Subject: Bug 31587 Author: fxcoudert Date: Tue Apr 24 22:37:37 2007 New Revision: 124126 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124126 Log: PR fortran/31587 * lib/gcc-dg.exp (sca

[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change

--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-04-20 22:13 --- (In reply to comment #11) > Time to CC Janis? No need. There's nothing a bit of trial-and-error can't help you write :) The following adds the necessary dejagnu directive, and uses it in a new test. I guess the

[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change

--- Comment #8 from tobi at gcc dot gnu dot org 2007-04-17 13:20 --- The patch looks good, though it would probably be a better idea to use tmpnam() to get the name for the temporary file. A further thing one could do: instead of threatening "If you edit this, you'll get what you deserv

[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change

--- Comment #11 from tobi at gcc dot gnu dot org 2007-04-17 13:41 --- (In reply to comment #10) > (In reply to comment #8) > > The patch looks good, though it would probably be a better idea to use > > tmpnam() > > to get the name for the temporary file. > > Why not. But I like the ide

[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change

--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-04-17 13:33 --- (In reply to comment #8) > The patch looks good, though it would probably be a better idea to use > tmpnam() > to get the name for the temporary file. Why not. But I like the idea that it is predictable :) > A

[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change

--- Comment #9 from tobi at gcc dot gnu dot org 2007-04-17 13:22 --- Oh, one more issue: do you have an idea how to write testcases for this? I'm a bit at a loss, though I've only thought about this for a few minutes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31587

[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change

-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch Target Milestone|--- |4.3.0 http:

[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change

--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-04-17 07:52 --- Created an attachment (id=13376) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13376&action=view) Patch that allows for module to be overwritten only if they changed This is the complete patch. Have fun!

[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change

--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-04-16 23:15 --- OK, I've researched the libiberty md5.c interface a bit and here's the first half of a patch :) It computes the MD5 sum of the module file (except the first 3 lines) and it writes it at the top, like this: GFORT

[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change

--- Comment #5 from tobi at gcc dot gnu dot org 2007-04-16 13:35 --- (In reply to comment #3) > Better than my current idea for that, which was to compare line after line the > old and new files. What cheap hash function should we use? MD5? Probably, as it is included in libiberty, and

[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change

--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-04-16 13:34 --- (In reply to comment #2) > include the > filename and modification date of the source file in the module file, and to > compare these before writing a module file I think that defeats the purpose: if the source f

[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change

--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-04-16 13:33 --- Better than my current idea for that, which was to compare line after line the old and new files. What cheap hash function should we use? MD5? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31587

[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change

--- Comment #2 from tobi at gcc dot gnu dot org 2007-04-16 13:31 --- Given your other PR, another solution that comes to mind is to include the filename and modification date of the source file in the module file, and to compare these before writing a module file. This would be more pro

[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change

--- Comment #1 from tobi at gcc dot gnu dot org 2007-04-16 13:28 --- An easy solution that I thought about implementing in the past would be to put a checksum into the file header. First the module file would be written to a temporary file. This file would be checksummed and only moved

[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change

-- 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