2019-04-21 04:19 AEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000004mercuryBugpublic2007-12-09 03:45
Reporteranonymous 
Assigned Tojuliensf 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionwon't fix 
Product Version 
Target VersionFixed in Version 
Summary0000004: change in --runtime-flags should rebuild <main>_init.o
DescriptionFrom bojar@csse.unimelb.edu.au Fri Aug 17 14:47:53 2007
Date: Fri, 17 Aug 2007 14:49:19 +1000
From: Ondrej Bojar <bojar@csse.unimelb.edu.au>
To: mercury-bugs@csse.unimelb.edu.au
Subject: change in --runtime-flags should rebuild <main>_init.o

 Hi.

If 'mmc --make' is used with --runtime-flags, it is not sufficient to touch the
source file of the main module after I change the flags.

If the correct behaviour (i.e. dependency of <main>_init.o on the actual string
of --runtime-flags) is difficult to implement, the user's manual/manpage should
probably remind users to delete the _init.o file.

Thanks, O.

--
Ondrej Bojar (mailto:obo@cuni.cz / bojar@ufal.mff.cuni.cz)
http://www.cuni.cz/~obo
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0000041

juliensf (administrator)

Last edited: 2007-10-26 16:32

<main>_init.c (and consequently .o) should be rebuilt after _any_ .m file
in the program is touched. The implementation does not appear to be
doing this.

~0000053

juliensf (administrator)

Ignore my previous note. The implementation is working correctly.
<main>_init.o will be rebuilt if the contents of <main>_init.c have
changed since the last build. The implementation checks to see if this
is case and only rebuild <main>_init.o if they have changed. Touching
<main>.m has no effect upon whether <main>_init.o is rebuilt - it will
only be rebuilt if <main>_init.c has changed.

~0000054

juliensf (administrator)

Ondrej, can you provide an example of where this is not working?
(I will close this bug otherwise.)

~0000055

obo (reporter)

Use the above attached example:
bug-runtime-flags.tgz [^] (577 bytes) 11-19-07 14:38

make
# ... this will pass

SUBDIRS=--use-grade-subdirs make
# ... this will fail, the two executables will be identical,
# despite different detstack-size requests in --runtime-flags

~0000056

juliensf (administrator)

Making the programs in bug-runtime-flags.tgz with --use-grade-subdirs works
for me with rotd-2007-11-18, i.e. it prints out "PASSED" at the end.

Also, strings test-w-stacksize.x | grep "\-\-detstack-size"

prints out the appropriate thing where x is either 1000 or 400000.

Can you please compile it on your machine with -V enabled and check that
the _init.c file actually being updated second time around.

~0000057

obo (reporter)

It failed now even without --use-subdirs.
My guess is that Mercury/os/test_init.o is not being recompiled, though Mercury/cs/test_init.c is correctly updated:

...
make test-w-stacksize.1000
make[1]: Entering directory `/home/obo/bug-runtime-flags'
rm -f test
mmc -V --make test --runtime-flags "--detstack-size 1000"
% Creating initialization file...
% Invoking system command `mkinit -g asm_fast.gc -r "--detstack-size 1000" -o Mercury/cs/test_init.c.tmp -I /home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/modules/asm_fast.gc /home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/modules/asm_fast.gc/mer_rt.init /home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/modules/asm_fast.gc/mer_std.init Mercury/cs/test.c'...
% done.
% Updating interface:
% `Mercury/cs/test_init.c' has CHANGED.
% Invoking system command `cp Mercury/cs/test_init.c.tmp Mercury/cs/test_init.c'...
% done.
Making test
% Linking...
% Invoking system command `gcc -s -o test Mercury/os/test_init.o Mercury/os/test.o -L/home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/lib -L/home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/lib/asm_fast.gc -Wl,-rpath,/home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/lib -Wl,-rpath,/home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/lib/asm_fast.gc /home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/lib/asm_fast.gc/libmer_std.a /home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/lib/asm_fast.gc/libmer_rt.a /home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/lib/libgc.a -lm '...
% done.
% done.
cp -L test test-w-stacksize.1000
make[1]: Leaving directory `/home/obo/bug-runtime-flags'
if diff test-w-stacksize.400000 test-w-stacksize.1000; then \
          echo "Files don't differ!"; \
          exit 1; \
        fi
Files don't differ!
make: *** [all] Error 1



When I run the two first lines of 'all' manually one by one, mmc -V log for the second run looks differently:

...
% `Mercury/cs/test_init.c' has CHANGED.
% Invoking system command `cp Mercury/cs/test_init.c.tmp Mercury/cs/test_init.c'...
% done.
% Compiling initialization file...
% Compiling `Mercury/cs/test_init.c':
% Invoking system command `gcc -I. -I. -I./Mercury/mihs -I/home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/lib/asm_fast.gc/inc -I/home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/conf -I/home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/inc -O2 -fomit-frame-pointer -fno-strict-aliasing -DMR_USE_GCC_GLOBAL_REGISTERS -DMR_USE_GCC_NONLOCAL_GOTOS -DMR_USE_ASM_LABELS -fno-builtin -fno-omit-frame-pointer -fno-defer-pop -fno-function-cse -fno-gcse -DMR_CONSERVATIVE_GC -DMR_BOEHM_GC -DMR_TAGBITS=2 -ansi -Wall -Wwrite-strings -Wshadow -Wmissing-prototypes -Wno-unused -Wno-uninitialized -Wstrict-prototypes -c Mercury/cs/test_init.c -o Mercury/os/test_init.o'...
% done.
Making test
% Linking...
...


Could it be a slight time-stamping bug/hack between
  - % Invoking system command `cp Mercury/cs/test_init.c.tmp Mercury/cs/test_init.c'...
and
  - Making test
?

~0000058

juliensf (administrator)

Ondrej and I have looked at this in person. It's a timing issue - apparently
the timestamp on the new version of the _init.c file hasn't been updated
when --make checks to see if the _init.o file should be rebuilt. Adding
a small delay between the invocations of mmc in Ondrej's Makefile avoids
the problem. (Thus far I have only been able to reproduce it on his machine.)

~0000063

juliensf (administrator)

I don't think this is worth fixing at the moment - it seems to be specific
to Ondrej's setup.
+Notes

-Issue History
Date Modified Username Field Change
2007-09-27 23:36 anonymous New Issue
2007-10-26 16:32 juliensf Note Added: 0000041
2007-10-26 16:32 juliensf Status new => confirmed
2007-10-26 16:32 juliensf Note Edited: 0000041
2007-11-19 14:11 juliensf Note Added: 0000053
2007-11-19 14:12 juliensf Note Added: 0000054
2007-11-19 14:12 juliensf Status confirmed => feedback
2007-11-19 14:38 obo File Added: bug-runtime-flags.tgz
2007-11-19 14:40 obo Note Added: 0000055
2007-11-19 14:57 juliensf Note Added: 0000056
2007-11-19 15:16 obo Note Added: 0000057
2007-11-19 15:53 juliensf Note Added: 0000058
2007-12-09 03:44 juliensf Status feedback => resolved
2007-12-09 03:44 juliensf Resolution open => won't fix
2007-12-09 03:44 juliensf Assigned To => juliensf
2007-12-09 03:44 juliensf Note Added: 0000063
+Issue History