2024-11-07 13:40 AEDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000514mercuryBugpublic2020-07-28 19:19
Reporterkeri 
Assigned Tozs 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
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.
Attached Files

-Relationships
+Relationships

-Notes

~0001097

juliensf (administrator)

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 (developer)

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 (developer)

Fix committed 2020 July 26.
+Notes

-Issue History
Date Modified Username Field Change
2020-07-23 00:53 keri New Issue
2020-07-24 01:04 juliensf Note Added: 0001097
2020-07-24 13:09 zs Note Added: 0001098
2020-07-28 19:19 zs Assigned To => zs
2020-07-28 19:19 zs Status new => resolved
2020-07-28 19:19 zs Resolution open => fixed
2020-07-28 19:19 zs Note Added: 0001099
+Issue History