Jump to content
plafratt

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

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...