gcc 4.6.0 warning messages for SystemC 2.2.0

[tony_kirke]

Hi

I know people are aware of 2.2.0 compiler warnings, etc for recent gcc versions such as 4.6 or greater and that these have been addressed in SystemC 2.3.0

However, because various HLS synthesis tools only support 2.2.0 at the moment and there will be a delayed movement to 2.3.0, we are left with these warnings if we want to do a system simulation where we need to use a more modern version gcc and not a tool specific version.

Also given that people often use -Wall, this is a problem

Would it possible to release at 2.2.1 version of SystemC that just addresses these compiler issues?

 

Below are the warnings that I'm seeing with gcc 4.6.0. The fixes should only take someone familiar with the code a few minutes, but if you are not clear about operator precedence the -Wparentheses warnings are a little more tricky to fix.

 

 

 

/tools/systemc/2.2.0/src/sysc/datatypes/bit/sc_bit_proxies.h:1193:18: warning: reference 'm_left' cannot be declared 'mutable' [-fpermissive]

/tools/systemc/2.2.0/src/sysc/datatypes/bit/sc_bit_proxies.h:1194:18: warning: reference 'm_right' cannot be declared 'mutable' [-fpermissive]

/tools/systemc/2.2.0/src/sysc/datatypes/bit/sc_bit_proxies.h:1196:18: warning: reference 'm_refs' cannot be declared 'mutable' [-fpermissive]

/tools/systemc/2.2.0/src/sysc/datatypes/bit/sc_bit_proxies.h:716:16: warning: reference 'm_obj' cannot be declared 'mutable' [-fpermissivIn

/tools/systemc/2.2.0/src/sysc/datatypes/bit/sc_bit_proxies.h:716:16: warning: reference 'm_obj' cannot be declared 'mutable' [-fpermissive]

/tools/systemc/2.2.0/src/sysc/datatypes/bit/sc_lv_base.h:310:33: warning: suggest parentheses around arithmetic in operand of '|' [-Wparentheses]

/tools/systemc/2.2.0/src/sysc/datatypes/bit/sc_proxy.h:1002:51: warning: suggest parentheses around arithmetic in operand of '|' [-Wparentheses]

/tools/systemc/2.2.0/src/sysc/datatypes/bit/sc_proxy.h:1003:28: warning: suggest parentheses around arithmetic in operand of '|' [-Wparentheses]

/tools/systemc/2.2.0/src/sysc/datatypes/bit/sc_proxy.h:1026:53: warning: suggest parentheses around arithmetic in operand of '|' [-Wparentheses]

/tools/systemc/2.2.0/src/sysc/datatypes/bit/sc_proxy.h:1051:28: warning: suggest parentheses around arithmetic in operand of '|' [-Wparentheses]

/tools/systemc/2.2.0/src/sysc/datatypes/fx/scfx_utils.h:141:48: warning: suggest parentheses around '&&' within '||' [-Wparentheses]

/tools/systemc/2.2.0/src/sysc/datatypes/fx/scfx_utils.h:145:48: warning: suggest parentheses around '&&' within '||' [-Wparentheses]

/tools/systemc/2.2.0/src/sysc/datatypes/fx/scfx_utils.h:155:48: warning: suggest parentheses around '&&' within '||' [-Wparentheses]

/tools/systemc/2.2.0/src/sysc/datatypes/fx/scfx_utils.h:159:48: warning: suggest parentheses around '&&' within '||' [-Wparentheses]

/tools/systemc/2.2.0/src/sysc/datatypes/fx/scfx_utils.h:169:48: warning: suggest parentheses around '&&' within '||' [-Wparentheses]

/tools/systemc/2.2.0/src/sysc/datatypes/fx/scfx_utils.h:173:48: warning: suggest parentheses around '&&' within '||' [-Wparentheses]

/tools/systemc/2.2.0/src/sysc/datatypes/fx/scfx_utils.h:189:48: warning: suggest parentheses around '&&' within '||' [-Wparentheses]

 

Thanks

Tony

[Philipp A Hartmann]

However, because various HLS synthesis tools only support 2.2.0 at the moment and there will be a delayed movement to 2.3.0, we are left with these warnings if we want to do a system simulation where we need to use a more modern version gcc and not a tool specific version.

When using a specific tool, you should stick with their SystemC version (and compiler) anyhow. If you want to do a separate simulation with a new compiler, why can't you use SystemC 2.3 for this? (Esp. synthesizable) SystemC models compatible with 2.2.0 should work fine with SystemC 2.3.

Also given that people often use -Wall, this is a problem

Would it possible to release at 2.2.1 version of SystemC that just addresses these compiler issues?

You can add the SystemC headers via -isystem, instead of a plain -I to your compiler's include path. This way, warnings from these headers won't clutter the warnings originating from your model.

I don't think that there will be a 2.2.1 version of the proof-of-concept library released by Accellera. The bandwidth in the LWG is way too limited to maintain more than one version of the proof-of-concept library.

Below are the warnings that I'm seeing with gcc 4.6.0. The fixes should only take someone familiar with the code a few minutes, but if you are not clear about operator precedence the -Wparentheses warnings are a little more tricky to fix.

You should fix the "mutable reference" issues by dropping the "mutable" keyword in the reported lines. You'll probably need to add some missing headers as well, IIRC. The other warnings can be safely ignored (e.g. via -isystem).

hth,

Philipp

[tony_kirke]

When using a specific tool, you should stick with their SystemC version (and compiler) anyhow. If you want to do a separate simulation with a new compiler, why can't you use SystemC 2.3 for this? (Esp. synthesizable) SystemC models compatible with 2.2.0 should work fine with SystemC 2.3.You can add the SystemC headers via -isystem, instead of a plain -I to your compiler's include path. This way, warnings from these headers won't clutter the warnings originating from your model.

 

>  If I could use SystemC 2.3, I would have. However no HLS vendor that I'm using supports it. Calypto's ac types are bundled with SystemC 2.2 and as far as I know there is no way to change that to 2.3 programatically. So if I use ac_fixed, I'm stuck with the warnings even if I'm not using their tool. For simulation and synthesis matching I need to use the same version of SystemC.

I don't think that there will be a 2.2.1 version of the proof-of-concept library released by Accellera. The bandwidth in the LWG is way too limited to maintain more than one version of the proof-of-concept library.You should fix the "mutable reference" issues by dropping the "mutable" keyword in the reported lines. You'll probably need to add some missing headers as well, IIRC. The other warnings can be safely ignored (e.g. via -isystem).

 

> I could fix this myself in my local  version but I work at a company with multiple installs of SystemC and don't have access to change those installs. I can't believe that you expect users to fix compile errors in their local files, especially when the right thing to do is to patch the distribution. It seems to go against the idea of having a standard altogether. You probably already spent more time arguing against this than it would take to make a fix that would potentially benefit all users

 

 

hth,

Philipp

[apfitch]

Hi Tony,

 

Just one comment -   the Proof of Concept simulator is *not* the standard.

The Language Reference Manual is the standard,

 

Obviously the LWG tries to make the PoC simulator as close to the standard as it can, hence the release of 2.3.0 to match SystemC 1666-2011.

 

 

regards

Alan

[sumit_tuwien]

  If I could use SystemC 2.3, I would have. However no HLS vendor that I'm using supports it. Calypto's ac types are bundled with SystemC 2.2 and as far as I know there is no way to change that to 2.3 programatically. So if I use ac_fixed, I'm stuck with the warnings even if I'm not using their tool. For simulation and synthesis matching I need to use the same version of SystemC.

 

I think if that is the case you must stick to SystemC2.2 rather. I do not understand why would you like to have a mix of versions for simulation and synthesis. It would be the responsibility of you vendor to provide solution to you and you might want to check with them.

 

 I could fix this myself in my local  version but I work at a company with multiple installs of SystemC and don't have access to change those installs. I can't believe that you expect users to fix compile errors in their local files, especially when the right thing to do is to patch the distribution. It seems to go against the idea of having a standard altogether. You probably already spent more time arguing against this than it would take to make a fix that would potentially benefit all users

 

SystemC-2.2 PoC should be used as it is - and it is free. They do many other works and this work is mostly voluntary. The goal of  PoC is to prove the concept LWG is proposing. LWG is not responsible for fixing issues reported by every other person - unless it is a blocker. Please talk to your EDA vendor to resolve your issue.

 

One suggestion, while you seek help in a forum and expect members to help you out, it would be great if you are cautious about your choice of words.

 

Regards,

Sumit

[Philipp A Hartmann]

If I could use SystemC 2.3, I would have. However no HLS vendor that I'm using supports it. Calypto's ac types are bundled with SystemC 2.2 and as far as I know there is no way to change that to 2.3 programatically. So if I use ac_fixed, I'm stuck with the warnings even if I'm not using their tool. For simulation and synthesis matching I need to use the same version of SystemC.

I didn't try this very recently, but you can download the AC datatypes separately. I don't expect any particular problems to use them with SystemC 2.3. If there should be any issues, they should be easily fixable.

I could fix this myself in my local  version but I work at a company with multiple installs of SystemC and don't have access to change those installs.

If you already have company-wide installs, maintained by other people than yourself, why can't you just use the -isystem option in your compiler flags and be done with it?

I can't believe that you expect users to fix compile errors in their local files, especially when the right thing to do is to patch the distribution.

Accellera did the "right thing" and fixed the distribution. The version including the fixes is called 2.3.0.

I fail to see how a version 2.2.1 would solve any of your problems. This version would not be "bundled" with the AC datatypes, you would need to convince your company to install it, you'd still have your "simulation / synthesis" mismatches (whatever your concern is, in that regard).

Greetings from Oldenburg,

Philipp

[tony_kirke]

Thanks everyone for the replies. I'm sorry if i rubbed anyone the wrong way. I did misunderstand how this standard/organisation worked and thought the code was the standard.

I think a 2.2.1 would have solved my issues in that 1) next updates of most HLS tools would probably include it. 2) it could be downloaded and installed as a known entity company wide.

Otherwise I have to request HLS vendors that bundle SystemC to each make changes to their installs so I can also compile code with GCC 4.6.0 and then also update our own separate installs. Since I thought the code was the standard this didn't seem to be either feasible or make sense. But as a PoC I think it's fine to do this as needed.

Does anyone know the right fixes for the parenthesis issues (in first post)? I'm afraid I might get the operator precedence incorrect and not sure where the parenthesis should go to avoid the warnings.

Thanks again

[Philipp A Hartmann]

As a general remark: You should push your HLS vendor to bundle SystemC 2.3.0 with their next release. It should be no problem, since there are very few changes that affect synthesisable code (or rather the synthesis of the models) in the first place. Secondly, there are some nice features for synthesis as well, like async_reset_signal_is (or even sc_vector, but this may be more difficult to support).

Does anyone know the right fixes for the parenthesis issues (in first post)? I'm afraid I might get the operator precedence incorrect and not sure where the parenthesis should go to avoid the warnings.

Why bother? As I said in my previous post(s), you can silence the warnings originating from SystemC by using the -isystem switch:

$ g++ -Wall -isystem ${SYSTEMC_HOME}/include ...

If you insist to change the SystemC 2.2.0 implementation in that area, you can compare the differences in the sysc/datatypes directory between 2.2.0 and 2.3.0. This will show (in addition to quite some "real" bugfixes) the required changes to silence the operator precedence warnings.

hth,

Philipp