This is the mail archive of the
ecos-bugs@sourceware.org
mailing list for the eCos project.
[Bug 1001520] Fix compiler warnings in Cortex-M architecture HAL
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: ecos-bugs at ecos dot sourceware dot org
- Date: Mon, 12 Mar 2012 16:25:36 +0000
- Subject: [Bug 1001520] Fix compiler warnings in Cortex-M architecture HAL
- Auto-submitted: auto-generated
- References: <bug-1001520-13@http.bugs.ecos.sourceware.org/>
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.