0000467: compiling with -Wuninitialized or -Wmaybe-uninitialized

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0000467

mercury

Feature Request

public

2018-08-18 16:15

2018-09-07 10:23

Reporter

wangp

Assigned To

Priority

normal

Severity

minor

Reproducibility

always

Status

new

Resolution

open

Product Version

Target Version

Fixed in Version

Summary

0000467: compiling with -Wuninitialized or -Wmaybe-uninitialized

Description

The high-level C backend generates code like this:

    if (succeeded)
      U_4 = UPrime_5;
    else
    {
      mercury__require__error_1_p_0((MR_String) "uint.det_from_int: cannot convert int to uint");
    }
    return U_4;

gcc does not know that the function call will not return so it MAY warn that U_4 is never initialised. mgnuc just happens to suppress the warnings on x86 and x86-64 for an unrelated reason:

case "$FULLARCH" in
    i*86-*|x86_64*)
        # The use of stack_pointer in the ASM_JUMP macro defined in
        # runtime/mercury_goto.h causes lots of warnings about using possibly
        # uninitialized variables; there's no easy way to suppress them except
        # by disabling the warning.
        case "$COMPILER" in
            gcc)
                CHECK_OPTS="$CHECK_OPTS -Wno-uninitialized"
                ;;
        esac
        ;;

Ideally we would ONLY disable uninitialized variable warnings in the low-level C grades where it is unavoidable.

In high-level C grades, I think we should declare the C function corresponding to an `erroneous' Mercury procedure as not returning, e.g. using the macro MR_NO_RETURN or similar. MR_NO_RETURN has implementations for gcc/clang/msvc. C11 also adds _Noreturn.

Alternatively, we could add assert(0) after calls to functions that will not return, but presumably that would increase code size.

Tags

No tags attached.

Attached Files

Relationships

Relationships

Notes
~0001007 juliensf (administrator) 2018-08-19 15:21	No objections from me to using MR_NO_RETURN on erroneous procedures. (We probably can't rely on C11 just yet, although MR_NO_RETURN could be updated to use _Noreturn if the C implementation is C11.)

~0001010 zs (developer) 2018-09-07 10:23	I started work on adding a new function flag that will tell mlds_to_c_func.m whether it should emit MR_NO_RETURN for a function being declared or defined.

Notes

Date Modified	Username	Field
Issue History
2018-08-18 16:15	wangp	New Issue
2018-08-19 15:21	juliensf	Note Added: 0001007
2018-09-07 10:23	zs	Note Added: 0001010

Issue History