Mercury Bugs - mercury
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000514mercuryBugpublic2020-07-23 00:532020-07-28 19:19
Reporterkeri 
Assigned Tozs 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000514: asm_fast.gc.profdeep.stseg grade fails to compile with GCC 10
DescriptionCompiling Mercury with GCC 10 and profiling grades enabled can lead to a link-time failure:

$ ./configure --enable-prof-grades

$ make

$ make install

<snip>

gcc -shared -Wl,--no-undefined \
    -o libmer_rt.so mercury.pic_o mercury_accurate_gc.pic_o mercury_agc_debug.pic_o mercury_atomic_ops.pic_o mercury_backjump.pic_o mercury_bitmap.pic_o mercury_builtin_types.pic_o mercury_construct.pic_o mercury_context.pic_o mercury_debug.pic_o mercury_deconstruct.pic_o mercury_deep_copy.pic_o mercury_deep_profiling.pic_o mercury_dlist.pic_o mercury_dummy.pic_o mercury_engine.pic_o mercury_file.pic_o mercury_float.pic_o mercury_getopt.pic_o mercury_getopt_long.pic_o mercury_grade.pic_o mercury_hash_table.pic_o mercury_heap_profile.pic_o mercury_hgc.pic_o mercury_ho_call.pic_o mercury_int.pic_o mercury_label.pic_o mercury_layout_util.pic_o mercury_memory.pic_o mercury_memory_handlers.pic_o mercury_memory_zones.pic_o mercury_minimal_model.pic_o mercury_misc.pic_o mercury_mm_own_stacks.pic_o mercury_overflow.pic_o mercury_par_builtin.pic_o mercury_prof.pic_o mercury_prof_mem.pic_o mercury_prof_time.pic_o mercury_profiling_builtin.pic_o mercury_reg_workarounds.pic_o mercury_region.pic_o mercury_regs.pic_o mercury_runtime_util.pic_o mercury_signal.pic_o mercury_stack_layout.pic_o mercury_stack_trace.pic_o mercury_stacks.pic_o mercury_stm.pic_o mercury_string.pic_o mercury_tabling.pic_o mercury_term_size.pic_o mercury_thread.pic_o mercury_threadscope.pic_o mercury_timing.pic_o mercury_trace_base.pic_o mercury_trace_term.pic_o mercury_trail.pic_o mercury_type_desc.pic_o mercury_type_info.pic_o mercury_type_tables.pic_o mercury_wrapper.pic_o mercury_wsdeque.pic_o \
    -Wl,-rpath,''/usr/local/lib/mercury/lib \
    -L/home/keri/mercury-srcdist-rotd-2020-07-17/install_grade_dir.asm_fast.gc.profdeep.stseg/boehm_gc -L/usr/local/lib -lgc_prof -lm ` case "asm_fast.gc.profdeep.stseg" in *.hlc.par*) echo -lpthread -ldl ;; *.par*) echo "-lpthread -ldl " ;; esac ` \
    `gcc -print-libgcc-file-name` -lm -lc
/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: mercury_ho_call.pic_o:/home/keri/mercury-srcdist-rotd-2020-07-17/install_grade_dir.asm_fast.gc.profdeep.stseg/runtime/mercury_builtin_types_proc_layouts.h:71: multiple definition of `mercury_data__proc_layout__mercury____Compare___type_desc__type_ctor_desc_0_0'; mercury_builtin_types.pic_o:/home/keri/mercury-srcdist-rotd-2020-07-17/install_grade_dir.asm_fast.gc.profdeep.stseg/runtime/mercury_builtin_types_proc_layouts.h:71: first defined here

<snip>

/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: mercury_ho_call.pic_o:/home/keri/mercury-srcdist-rotd-2020-07-17/install_grade_dir.asm_fast.gc.profdeep.stseg/runtime/mercury_builtin_types_proc_layouts.h:41: multiple definition of `mercury_data__proc_layout__mercury____Unify___builtin__int8_0_0'; mercury_builtin_types.pic_o:/home/keri/mercury-srcdist-rotd-2020-07-17/install_grade_dir.asm_fast.gc.profdeep.stseg/runtime/mercury_builtin_types_proc_layouts.h:41: first defined here
collect2: error: ld returned 1 exit status


GCC 10 has included -fno-common in it's default set of flags. (The above build failure should be able to be reproduced with older versions of GCC by setting -fno-common in CFLAGS).


The workaround I'm using at the moment is to is include -fcommon in CFLAGS.
TagsNo tags attached.
Relationships
Attached Files

Notes
(0001097)
juliensf   
2020-07-24 01:04   
Placing proc layouts in common blocks is deliberate -- see the coment at the head of runtime/mercury_builtin_types_proc_layouts.h; we will need to arrange for -fcommon to be passed to GCC 10 and above.
(0001098)
zs   
2020-07-24 13:09   
I read that comment differently. To me, it says that the symbols of the *declarations*
of the proc layout structures will end up in a common block whether we them to or not,
and that we put those declarations into a separate .h file so that

- we can control where those declarations are referenced from, and thereby
- prevent those declarations from being mistaken by the linker for definitions.

The better solution that the linkers at the time did not permit is to put the
declarations in mercury_builtin_types.h, next to the definitions in the
corresponding .c file. If all the compilers (and compiler versions) that
we support have -fno-common or some equivalent, then we should switch to
that solution.

However, that will require us to fix another problem that I just discovered,
which is that *some* of the proc_layout structures that we declare we don't define,
and vice versa. Specifically, the definitions and declarations disagree about
the arity of two type constructors in private_builtin.m: type_info and type_ctor_info.
One says they are arity 0, while the other says arity 1, and the mismatch arises
because the arity ends up in the name of the proc layout structure. I am just now
bootchecking a fix for this problem. The only reason why this problem was not visible
until now was the use of common storage, with its peculiar "declarations can act
as definitions" rules.
(0001099)
zs   
2020-07-28 19:19   
Fix committed 2020 July 26.

Issue History
Date ModifiedUsernameFieldChange
2020-07-23 00:53keriNew Issue
2020-07-24 01:04juliensfNote Added: 0001097
2020-07-24 13:09zsNote Added: 0001098
2020-07-28 19:19zsAssigned To => zs
2020-07-28 19:19zsStatusnew => resolved
2020-07-28 19:19zsResolutionopen => fixed
2020-07-28 19:19zsNote Added: 0001099