AVR C Runtime Library - Bugs: bug #39875, Warning 1 unused variable...
You are not allowed to post comments on this tracker with your current authentication level.
bug #39875: Warning 1 unused variable '__ticks' [-Wunused-variable] C:\PROGRA~2\Atmel\ATMELT~1\AVR8GC~1\Native\342~1.939\AVR8-G~1\av
Submitter: | None | ||
Submitted: | Tue 27 Aug 2013 06:01:43 AM UTC | ||
Category: | Library | Severity: | 3 - Normal |
Priority: | 5 - Normal | Item Group: | libc code |
Status: | Need Info | Assigned to: | None |
Percent Complete: | 0% | Originator Email: | -email is unavailable- |
Open/Closed: | Open | Release: | 1.8.0 |
Fixed Release: | None |
Tue 27 Aug 2013 11:22:23 AM UTC, comment #2: |
Mike Ady <farquahrsen> |
Tue 27 Aug 2013 06:23:11 AM UTC, comment #1: I think this is a duplicate for bug #38904, even though the
|
Joerg Wunsch <joerg_wunsch> |
Tue 27 Aug 2013 06:01:43 AM UTC, original submission:
_delay_ms has the following definition:
|
Anonymous |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Follow 2 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2013-08-27 | joerg_wunsch | Status | None | Need Info | |
Summary | Warning 1 unused variable \'__ticks\' [-Wunused-variable] C:\\PROGRA~2\\Atmel\\ATMELT~1\\AVR8GC~1\\Native\\342~1.939\\AVR8-G~1\\av | Warning 1 unused variable '__ticks' [-Wunused-variable] C:\PROGRA~2\Atmel\ATMELT~1\AVR8GC~1\Native\342~1.939\AVR8-G~1\av |
Powered by Savane 3.13-3230.
Corresponding source code
I did see #38904, and I thought that this was different. In my experience, if there is any mystery about the "may be used uninitialized" error mentioned in #38904, then it is often caused by an unexpected interaction with a macro. The OP might want to take a look at the preprocessor expansion in the listing file.
The fix that I suggested below does get rid of the "unused variable" warning message from the compiler. I don't think that the change would have any effect on #38904. It seems to me that the bug that I'm complaining about is a simple oversight and who ever introduced the bug failed to test both code paths of the preprocessor conditional.