0000514: asm_fast.gc.profdeep.stseg grade fails to compile with GCC 10

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0000514

mercury

Bug

public

2020-07-23 00:53

2020-07-28 19:19

Reporter

keri

Assigned To

Priority

normal

Severity

minor

Reproducibility

always

Status

resolved

Resolution

fixed

Product Version

Target Version

Fixed in Version

Summary

0000514: asm_fast.gc.profdeep.stseg grade fails to compile with GCC 10

Description

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

Tags

No tags attached.

Attached Files

Relationships

Relationships

Notes
~0001097 juliensf (administrator) 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 (developer) 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 (developer) 2020-07-28 19:19	Fix committed 2020 July 26.

Notes

Date Modified	Username	Field	Change
Issue History
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