[
https://issues.apache.org/jira/browse/TS-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić updated TS-1278:
---------------------------
Description:
{noformat}
Making all in eventsystem
make[2]: Entering directory
`/home/igalic/src/asf/trafficserver/BUILD/iocore/eventsystem'
CXX EventSystem.o
In file included from ../../../iocore/eventsystem/EventSystem.cc:31:
In file included from ../../../iocore/eventsystem/P_EventSystem.h:41:
In file included from ../../../iocore/eventsystem/I_EventSystem.h:35:
In file included from ../../../iocore/eventsystem/I_Action.h:30:
In file included from ../../../iocore/eventsystem/I_Continuation.h:40:
../../../iocore/eventsystem/I_Lock.h:404:19: error: expression result unused;
assign into a variable to force a volatile load
[-Werror,-Wunused-volatile-lvalue]
ink_assert(m->thread_holding);
~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
../../../lib/ts/ink_assert.h:54:31: note: expanded from macro 'ink_assert'
#define ink_assert(EX) (void)(EX)
^
1 error generated.
make[2]: *** [EventSystem.o] Error 1
{noformat}
Discussion from {{#llvm}} on IRC:
{noformat}
< jMCg> volatile EThreadPtr thread_holding;
<@baldrick> the clang warning sounds very sensible then
< jMCg>
http://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=blob;f=iocore/eventsystem/I_Lock.h#l80
< jMCg> The comment is great. "You must not modify or set this value directly."
-- that's why it's public!
< jMCg> baldrick: can you still help me understand it?
<@baldrick> jMCg: reading a volatile variable may have side-effects (that's
what volatile is for). For example, if it is mapped to some I/O area, each
read could fire off a nuclear warhead for example.
<@baldrick> jMCg: thus it seems sensible to warn if it looks like someone is
readying it but not using the result.
< jMCg> Oh. Now I'm back on track. *Reading* a volatile variable may have
*side-effects* - sometimes I'm slow.
< jMCg> baldrick: I'll open a Bug in our project. Thank you very much.
{noformat}
This is it.
was:
{code}
Making all in eventsystem
make[2]: Entering directory
`/home/igalic/src/asf/trafficserver/BUILD/iocore/eventsystem'
CXX EventSystem.o
In file included from ../../../iocore/eventsystem/EventSystem.cc:31:
In file included from ../../../iocore/eventsystem/P_EventSystem.h:41:
In file included from ../../../iocore/eventsystem/I_EventSystem.h:35:
In file included from ../../../iocore/eventsystem/I_Action.h:30:
In file included from ../../../iocore/eventsystem/I_Continuation.h:40:
../../../iocore/eventsystem/I_Lock.h:404:19: error: expression result unused;
assign into a variable to force a volatile load
[-Werror,-Wunused-volatile-lvalue]
ink_assert(m->thread_holding);
~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
../../../lib/ts/ink_assert.h:54:31: note: expanded from macro 'ink_assert'
#define ink_assert(EX) (void)(EX)
^
1 error generated.
make[2]: *** [EventSystem.o] Error 1
{code}
Discussion from {{#llvm}} on IRC:
{code}
< jMCg> volatile EThreadPtr thread_holding;
<@baldrick> the clang warning sounds very sensible then
< jMCg>
http://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=blob;f=iocore/eventsystem/I_Lock.h#l80
< jMCg> The comment is great. "You must not modify or set this value directly."
-- that's why it's public!
< jMCg> baldrick: can you still help me understand it?
<@baldrick> jMCg: reading a volatile variable may have side-effects (that's
what volatile is for). For example, if it is mapped to some I/O area, each
read could fire off a nuclear warhead for example.
<@baldrick> jMCg: thus it seems sensible to warn if it looks like someone is
readying it but not using the result.
< jMCg> Oh. Now I'm back on track. *Reading* a volatile variable may have
*side-effects* - sometimes I'm slow.
< jMCg> baldrick: I'll open a Bug in our project. Thank you very much.
{code}
This is it.
> Clang warns: Volatile fields read but results discarded
> -------------------------------------------------------
>
> Key: TS-1278
> URL: https://issues.apache.org/jira/browse/TS-1278
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Environment: clang version 3.2 (trunk 157601)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> Reporter: Igor Galić
>
> {noformat}
> Making all in eventsystem
> make[2]: Entering directory
> `/home/igalic/src/asf/trafficserver/BUILD/iocore/eventsystem'
> CXX EventSystem.o
> In file included from ../../../iocore/eventsystem/EventSystem.cc:31:
> In file included from ../../../iocore/eventsystem/P_EventSystem.h:41:
> In file included from ../../../iocore/eventsystem/I_EventSystem.h:35:
> In file included from ../../../iocore/eventsystem/I_Action.h:30:
> In file included from ../../../iocore/eventsystem/I_Continuation.h:40:
> ../../../iocore/eventsystem/I_Lock.h:404:19: error: expression result unused;
> assign into a variable to force a volatile load
> [-Werror,-Wunused-volatile-lvalue]
> ink_assert(m->thread_holding);
> ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
> ../../../lib/ts/ink_assert.h:54:31: note: expanded from macro 'ink_assert'
> #define ink_assert(EX) (void)(EX)
> ^
> 1 error generated.
> make[2]: *** [EventSystem.o] Error 1
> {noformat}
> Discussion from {{#llvm}} on IRC:
> {noformat}
> < jMCg> volatile EThreadPtr thread_holding;
> <@baldrick> the clang warning sounds very sensible then
> < jMCg>
> http://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=blob;f=iocore/eventsystem/I_Lock.h#l80
> < jMCg> The comment is great. "You must not modify or set this value
> directly." -- that's why it's public!
> < jMCg> baldrick: can you still help me understand it?
> <@baldrick> jMCg: reading a volatile variable may have side-effects (that's
> what volatile is for). For example, if it is mapped to some I/O area, each
> read could fire off a nuclear warhead for example.
> <@baldrick> jMCg: thus it seems sensible to warn if it looks like someone is
> readying it but not using the result.
> < jMCg> Oh. Now I'm back on track. *Reading* a volatile variable may have
> *side-effects* - sometimes I'm slow.
> < jMCg> baldrick: I'll open a Bug in our project. Thank you very much.
> {noformat}
> This is it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
