This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1001520] Fix compiler warnings in Cortex-M architecture HAL


Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001520

--- Comment #4 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-12 16:25:34 GMT ---
(In reply to comment #3)
> (In reply to comment #2)

[snip]

> > What I really wander (am curious) is: what hinders the compiler from seeing
> > that the variable within (this) macro is (actually) being used.
> 
> It isn't being used, only set. It would take something to read the variable
> contents for it to be used.

Yeah,!@#$ Probably I was carried by the fact that it is volatile thus
implicitly used (out of compiler domain). IMHO this warning should be abolished
for volatiles. Very often/typically they are either a sink or a spring.

> 
> Yes for us it is needed in order to cause a magic address to be read, but from
> a C language point of view that sort of thing is a side-effect which is
> perfectly allowed to be eliminated during optimisation. Evidently the use of
> volatile casts in the definition of HAL_READ_UINT32 is still sufficient to make
> sure the right thing happens for us.
> 

Prudent to check.

> Although I do notice that the definition of HAL_CLOCK_RESET doesn't look
> correct since it ignores __period.
> 
> Anyway, yes this patch can be committed now, thanks for looking into it.

Thank you for the review. I am going to do so today evening.

Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]