https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65082
--- Comment #4 from NickParker at Eaton dot com ---
That was with 's' optimisation, and it does the sames for optimisation level
'1'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65082
--- Comment #3 from NickParker at Eaton dot com ---
register uint16_t r4 asm ("r4");
register uint16_t r6 asm ("r6");
volatile int8_t localOscCosine;
volatile int8_t acInput;
void pllExec(void)
{
int16_t mix_out
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: NickParker at Eaton dot com
gcc version 4.8.0 20130306 (experimental) (GCC)
Was just playing around and found this. When using a register based variable,
the compiler misses an obvious optimisation.
Notice in
: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: NickParker at Eaton dot com
Created attachment 30526
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30526&action=edit
C code and a listing
There are supe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50314
--- Comment #6 from NickParker at Eaton dot com 2011-09-07 21:18:59 UTC ---
>> How is TCNT1 defined? Again just attach the preprocessed source.
Sorry, not sure how to get preprocessed source - I need to read the GCC manual.
>From A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50314
--- Comment #5 from NickParker at Eaton dot com 2011-09-07 21:16:02 UTC ---
So if its not a bug, what is the solution to this problem?
I tried wrapping up the code I wanted to time in a separate C function, but the
compiler still optimised my
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50314
--- Comment #3 from NickParker at Eaton dot com 2011-09-07 21:13:22 UTC ---
#define T1_GET_TIMER_NON_ATOMIC() (TCNT1)
uint16_t BGndTimerReadNowIsr(void)
{
uint16_t period_u2;
period_u2 = T1_GET_TIMER_NON_ATOMIC();
return(period_u2);
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50314
Bug #: 50314
Summary: GCC changes order of code so it does not work as
intended
Classification: Unclassified
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50256
--- Comment #5 from NickParker at Eaton dot com 2011-09-04 21:29:40 UTC ---
Thanks, also was able to add a few movws to save cycles.
Nick.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50256
--- Comment #4 from NickParker at Eaton dot com 2011-09-04 21:27:43 UTC ---
Hi,
Thanks for your input and sorry to make a mess of reporting this.
The arithmetic is fine and the code gives the results I expect.
However, I have since discovered and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
--- Comment #10 from NickParker at Eaton dot com 2011-09-04 21:22:30 UTC ---
Richard, 'bogus' isnt a technical term I'm familiar with - I'm not entirely
sure
what you mean, however, I have found the problem with my ASM code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
--- Comment #8 from NickParker at Eaton dot com 2011-09-03 04:46:45 UTC ---
Please ignore the r10/r20 guff I was experimenting. I later realised the
muls3s3u3 code gives the right answer, the problem occurs later on somehow the
registers where the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
--- Comment #7 from NickParker at Eaton dot com 2011-09-03 04:45:08 UTC ---
Please ignore the r10/r20 guff I was experimenting. I later realised the
muls3s3u3 code gives the right answer, the problem occurs later on somehow
Nick.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
--- Comment #5 from NickParker at Eaton dot com 2011-09-03 01:32:20 UTC ---
Sorry. I pasted a broken version. Before. Code below works.
uint32_t MulU3U3S3(uint32_t a_u4, uint32_t b_u4)
{
//uint32_t answer;
asm volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
--- Comment #4 from NickParker at Eaton dot com 2011-09-03 01:30:26 UTC ---
Hi Andrew,
Can you please explain what you mean by %1 and %2. Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
--- Comment #3 from NickParker at Eaton dot com 2011-09-03 01:28:57 UTC ---
The final printed calculation result of MulU3U3S3() is wrong, because two of
the four result registers are incorrect and have been overwritten.
"mulu3u3s3 : [ +00167
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
NickParker at Eaton dot com changed:
What|Removed |Added
Component|inline-asm |c
Severity|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
Bug #: 50281
Summary: result registers are overwritten giving incorrect
result
Classification: Unclassified
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50256
--- Comment #2 from NickParker at Eaton dot com 2011-09-01 21:30:41 UTC ---
I have the latest AVR GCC release from 2010-01-10 (4.3.3) and this is what I am
using.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50256
Bug #: 50256
Summary: AVR GCC - several unnecessary register moves
Classification: Unclassified
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Prior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50223
Bug #: 50223
Summary: AVRGCC - dont clear r26 and r27.its a (small)
waste of CPU cycles.
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONF
21 matches
Mail list logo
