2024-03-29 04:43 AEDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000330mercuryBugpublic2014-05-27 16:33
Reporterwangp 
Assigned Tozs 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version 
Target VersionFixed in Version 
Summary0000330: slice directory does not build in debugging grade
DescriptionSLICE_FLAGS contains --force-disable-tracing

After commit 5254245ae34ab6b3ca0f7dcd3c7fc807e1407f7d "Eliminate some unnecessary labels in low level grades." the modules in the slice directory no longer compile with GRADE=asm_fast.gc.debug, producing errors like:

mdbcomp.goal_path.c:2847:2: error: label ‘_entry_mercury__fn__mdbcomp__goal_path__goal_path_add_at_end_2_0_i7’ used but not defined
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0000686

zs (developer)

I cannot reproduce the problem, but this may be because the original report is unclear.

If I leave the --force-disable-tracing in SLICE_FLAGS, I see neither a use or a definition of_entry_mercury__fn__mdbcomp__goal_path__goal_path_add_at_end_2_0_i7 in mdbcomp.goal_path.c.

If I remove the --force-disable tracing from SLICE_FLAGS (after mmake depend and before just mmake in the slice directory, with GRADE=asm_fast.gc.debug in ../Mmake.params), I see both a definition and a use of that same label.

Can you please tell me the exact sequence of actions needed to reproduce the problem?

~0000687

wangp (developer)

mmc -v
Mercury Compiler, version 14.01.1-beta-2014-05-06, configured for x86_64-unknown-linux-gnu

echo GRADE=asm_fast.gc.debug > Mmake.params
aclocal -I m4 && autoconf && ./configure
mmake -j6
cd slice
mmake


I see in the generated C code that there are MR_init_label* lines for labels which were, presumably, eliminated. I have uploaded mdbcomp.goal_path.c

~0000688

juliensf (administrator)

I don't think commit 8c72b1e5c0c23353770c494bcdf35a450ebf7c85 has been merged on to the 14.01
branch, so that may be the problem here.

~0000689

wangp (developer)

That appears to be it. It cherry-picks cleanly onto the 14.01 branch. Should I do that?

~0000690

wangp (developer)

Or revert 5254245ae34ab6b3ca0f7dcd3c7fc807e1407f7d on 14.01 as it should not have been merged in the first place.

~0000691

juliensf (administrator)

Last edited: 2014-05-27 13:18

View 2 revisions

Given the length of time the original change has been on the 14.01 branch (mostly without incident!) I would be inclined to leave it there and merge 8c72b1e5c0c23353770c494bcdf35a450ebf7c85 onto the branch.

~0000692

wangp (developer)

Ok.

The no_refs_to_deleted_labels test case is problematic (also on the master branch). It passes -DMR_LOWLEVEL_DEBUG which implies MR_DEBUG_GOTOS, but the runtime may not have been built with MR_DEBUG_GOTOS. There are some undefined symbol errors when linking (e.g. to MR_goto_msg).

~0000693

juliensf (administrator)

With reference to the last bit, that looks wrong, MR_DEBUG_GOTOS should only be defined if
MR_LOWLEVEL_DEBUG && MR_USE_GCC_NONLOCAL_GOTOS.

(I would guess that no-one has used low-level debugging in a non asm_fast grade for a while
so it's probably just bitrot.)

~0000694

wangp (developer)

MR_DEBUG_LABEL_NAMES implies MR_INSERT_LABELS without implying MR_DEBUG_GOTOS.

~0000695

juliensf (administrator)

Or that.
+Notes

-Issue History
Date Modified Username Field Change
2014-05-26 10:43 wangp New Issue
2014-05-26 14:31 zs Assigned To => zs
2014-05-26 14:31 zs Status new => assigned
2014-05-26 20:18 zs Note Added: 0000686
2014-05-27 10:34 wangp File Added: mdbcomp.goal_path.c
2014-05-27 10:36 wangp Note Added: 0000687
2014-05-27 12:22 juliensf Note Added: 0000688
2014-05-27 12:43 wangp Note Added: 0000689
2014-05-27 12:55 wangp Note Added: 0000690
2014-05-27 13:14 juliensf Note Added: 0000691
2014-05-27 13:18 juliensf Note Edited: 0000691 View Revisions
2014-05-27 15:31 wangp Note Added: 0000692
2014-05-27 15:39 juliensf Note Added: 0000693
2014-05-27 15:44 wangp Note Added: 0000694
2014-05-27 15:49 juliensf Note Added: 0000695
2014-05-27 16:33 wangp Status assigned => resolved
2014-05-27 16:33 wangp Resolution open => fixed
+Issue History