sc_fifo::read() - g++ gives warning that tmp is unset

[plafratt]

For sc_fifo::read(), some versions of g++ give me a warning that the variable tmp is unset. I see there is a path through read() that leaves tmp unset, but I don't think it is possible that this path ever gets executed. Is there a way around this warning that doesn't require disabling the warning in g++ or changing sc_fifo.h?

[plafratt]

I get the warning when building my code that uses sc_fifo.h, not when building systemc. I assume this is because the function is declared inline.

[Roman Popov]

I was not able to reproduce. What g++ version do you use? Can you provide any example that reproduces the problem?

Quote

I see there is a path through read() that leaves tmp unset, but I don't think it is possible that this path ever gets executed. 

I don't see that path, which line of code?

[maehne]

@plafratt: It would be very helpful if you could provide more detailed information to reproduce your observation as suggested by @Roman Popov. With what version of g++ running on which platform have you observed the warning. A small self-contained code example demonstrating the issue would help us to reproduce the issue on our side so that we can forward the issue with enough information to the SystemC Language Working Group for fixing.

[plafratt]

Thank you for the responses. Sorry for the delay in my response. I'd gotten busy, and I am just now getting around to signing back in.

We don't seem to be having this issue anymore. I am not sure if it because of code updates or because of a compiler upgrade. We recently switched from g++ 4.9.2 to 6.2.1, so that may have resolved the issue.

The path in question is sc_fifo::read() -> sc_fifo::read(T& val_) -> sc_fifo<T>::buf_read( T& val_ ). 

On line 410, buf_read() returns false without setting val. None of the functions in the call chain set val, so when the original call to sc_fifo::read() returns, it is returning its locally-declared tmp variable, which was passed to sc_fifo::read(T& val), which never sets val.

As I mentioned, though, this doesn't seem to be causing a problem for us at the moment. It may have been a compiler issue that got resolved when we upgraded.

Thank You and Regards,

Patrick

[maehne]

Thanks @plafratt for providing these additional details. I have reported this issue to the LWG for investigation. The warning can be probably fixed by default-initialising the tmp in line 235 of sc_fifo.h

[Philipp A Hartmann]

This compiler warning is a false positive.

There is a loop in sc_fifo<T>::read(T&) ensuring that the fifo is not empty (and the success of the nb_read(T&) is even guarded by an sc_assert😞

    while( num_available() == 0 ) {
	sc_core::wait( m_data_written_event );
    }
    bool read_success = sc_fifo<T>::nb_read(val_);
    sc_assert( read_success );

The check for num_available() is even stricter than the check in buf_read, but I can imagine that some compilers might not be able to prove this invariant.  Therefore, unconditionally initializing the local variable to silence the warning might be an acceptable trade-off.