Thread: volatile markings to silence compilers
Looking over the release notes, we have added a few 'volatile' storage specifications to variables which are near longjump/TRY blocks to silence compilers. I am worried that these specifications don't clearly identify their purpose. Can we rename these to use a macro for 'volatile' that will make their purpose clearer and perhaps their removal one day easier? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Thu, Mar 17, 2011 at 12:36:59AM -0400, Bruce Momjian wrote: > Looking over the release notes, we have added a few 'volatile' storage > specifications to variables which are near longjump/TRY blocks to > silence compilers. I am worried that these specifications don't clearly > identify their purpose. Can we rename these to use a macro for > 'volatile' that will make their purpose clearer and perhaps their > removal one day easier? The question is, are they wrong? The longjmp manpage says: The values of automatic variables are unspecified after a call to longjmp() if they meet all the following criteria: · they are local to the function that made the corresponding setjmp(3) call; · their values are changed between the calls to setjmp(3) and longjmp(); and · they are not declared as volatile. It appears the issue is mostly that the compiler is unable to prove that the variables aren't changed. It's hard because the buffer created by setjmp() doesn't expire. We know that after PG_END_TRY() the buffer won't be used, but apparently the compiler doesn't. My point is, are we hopeful this problem will ever go away? Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patriotism is when love of your own people comes first; nationalism, > when hate for people other than your own comes first. > - Charles de Gaulle
On Thu, Mar 17, 2011 at 12:36 AM, Bruce Momjian <bruce@momjian.us> wrote: > Looking over the release notes, we have added a few 'volatile' storage > specifications to variables which are near longjump/TRY blocks to > silence compilers. I am worried that these specifications don't clearly > identify their purpose. Can we rename these to use a macro for > 'volatile' that will make their purpose clearer and perhaps their > removal one day easier? I don't particularly see the point of this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Martijn van Oosterhout <kleptog@svana.org> writes: > It appears the issue is mostly that the compiler is unable to prove > that the variables aren't changed. IME, older versions of gcc will warn about any variable that's assigned more than once, even if those assignments are before the setjmp call. Presumably this is stricter than necessary, but I don't know enough details of gcc's register usage to be sure. > My point is, are we hopeful this problem will ever go away? Since we're trying to silence the warning in existing and even obsolete compilers, whether it gets improved in future compilers is not terribly relevant. regards, tom lane