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 #3 from Jonathan Larmour <jifl@ecoscentric.com> 2012-03-12 14:56:22 GMT ---
(In reply to comment #2)
> Apparently, the patched and non-patched versions produce identical code.

Good.

> At the beginning, I was little-bit confused too as "unused" sounds like we are
> telling the compiler that variable us "unused" while it really means "in know
> that it looks 'unused' to you but I know what I'm doing". To my understanding
> (only GCC fellows can give authentic clarification) this attribute doesn't
> affect compiler optimization only suppresses the warning.

Well, I was concerned it might have eliminated it the read because the variable
is unused, and once marked as unused, maybe this might change things. I knew it
would definitely suppress the warning, I wasn't certain it wouldn't affect
optimisation.

> 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.

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.

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.

Jifl

-- 
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]