Test
--
Best Regards,
-- Royce Pereira
Hi i am Ismail, student of avr micro controllers.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Am 04/21/2015 um 03:24 PM schrieb Georg-Johann Lay:
Without fat LTO objects, the compiler just puts gimple IR into the objects,
there is no asm code. Built-in functions are represented by their decls as
provided by targetm.builtin_decl(). This means there is no expansion of tree
to rtl.
That ex
Am 04/21/2015 um 09:17 AM schrieb Sivanupandi, Pitchumani:
Hi,
Test gcc.target/avr/torture/builtins-error.c is failed in gcc-4.9 and trunk for
-Os -flto options.
This test expects error for compile time constant. Option flto delays the
builtin expand
(to link time??) and there is no error
Hi,
Test gcc.target/avr/torture/builtins-error.c is failed in gcc-4.9 and trunk for
-Os -flto options.
This test expects error for compile time constant. Option flto delays the
builtin expand
(to link time??) and there is no error. Can this test be skipped for above
option?
If -ffat-lto
age-
> From: John Regehr [mailto:reg...@cs.utah.edu]
> Sent: Saturday, June 09, 2012 11:02 AM
> To: g...@gcc.gnu.org
> Subject: announcing C-Reduce, a test-case reducer for C/C++ programs
>
> http://blog.regehr.org/archives/697
>
> John
_
g
> Subject: [avr-gcc-list] test
>
> test
w00t! It worked!
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
test
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
tarmigan wrote:
> (Reading through some very old email, it looks like this one might not
> have been resolved...)
>
> On Fri, May 8, 2009 at 2:41 AM, Robert von Knobloch wrote:
>
>> Hallo,
>>
>> I am writing code for an ATMega 644P and have come across some very
>> strange behaviour.
>> A small
urn-Path:
> Received: from localhost (localhost [127.0.0.1]) (uid 1000) by minni with
> local; Fri, 08 May 2009 13:01:05 +0200 id 0061A00D.4A0410F1.1EF1
> From: li...@hczim.de (Heike C. Zimmerer)
> Newsgroups: lists.avr-chat
> Subject: Re: [avr-chat] Mega644 bit test problem
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 02, 2008 10:14 AM
> To: Weddington, Eric; avr-gcc-list@nongnu.org;
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Updates needed to AVR test f
BTW Mike Stein has patched his as his latest compares are showing
updated cflags on Compat tests. Way to go Mike!
The compat test are potentially VERY USEFUL. It has the ability to
compare and link 2 different compilers. For example, gcc 4.3 with gcc
4.4 to check ABI.
For now it compares
R-GCC ;
Paulo Marques <[EMAIL PROTECTED]>; Mike Stein
<[EMAIL PROTECTED]>; Anatoly Sokolov <[EMAIL PROTECTED]>
Sent: Mon, 2 Jun 2008 11:59 am
Subject: RE: Updates needed to AVR test files
-Original Message-
From: Andy H [mailto:[EMAIL PROTECTED]
Sent: Friday, May 30,
> -Original Message-
> From: Andy H [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 30, 2008 8:59 PM
> To: AVR-GCC; Paulo Marques; Mike Stein; Weddington, Eric;
> Anatoly Sokolov
> Subject: Updates needed to AVR test files
>
> There are a couple of changes nee
need to use testsuite).
The others failures are problems are with tests. But until I go thru
each one and check, I cannot be sure.
There are pending patches that will reduce this further, so the near
horizon is about 300 failures.
When a test is fixed, often more tests are run - so total number
werp: Re: [avr-gcc-list] Updates needed to AVR test files
>
> Small typo - in COMPLEX_INT
>
> Should be
>
> set COMPAT_SKIPS [list {VA} {COMPLEX_INT}]
>
> not plural
>
> Duh!
> Andy
>
>
> Andy H wrote:
> > BTW you can also just define t
-prologues} {-Os
-mcall-prologues}]]
Andy
Andy H wrote:
There are a couple of changes needed to AVR test files to pass a few
tests.
Compatibility tests default to no optimization and maximum tests -
this can easily overflow 128K code area.
Add these lines to end board file (mine is called
BTW you can also just define these in environment and leave board file
unchanged
set COMPAT_SKIPS [list {VA} {COMPLEX_INTS}]
set COMPAT_OPTIONS [list [list {-Os -mcall-prologues} {-Os
-mcall-prologues}]]
Andy
Andy H wrote:
There are a couple of changes needed to AVR test files to pass a few
There are a couple of changes needed to AVR test files to pass a few tests.
Compatibility tests default to no optimization and maximum tests - this
can easily overflow 128K code area.
Add these lines to end board file (mine is called atmega128-simnew.exp).
They set environment vars that
On Tuesday 29 January 2008 19:22, Wouter van Gulik wrote:
[...]
> Hmm, this is all ready so for __mulqihi3 and __umulqihi3, they do a rjmp
> to __mulhi3. So I thought it was save.
Hmm... Yes, rcall/rjmp is used in libgcc.S. Though math functions are
bulky enough. And decimal float point in futur
Paulo Marques wrote:
Wouter van Gulik wrote:
[...]
I tested the clzsi2 against all 4.2 billion cases :P It would have
saved me a half a day if avrtest was twice as fast :). I tested the
rest against the test case.
Great. Finally I have a good excuse to tweak the performance of avrtest
Dmitry K. schreef:
On Friday 25 January 2008 22:35, Wouter van Gulik wrote:
__clzqi2:
clr r_count ; load with 0
com r_count ; invert (load with -1) + set carry
__clzqi2_loop:
rol r_arg1L ; Rotate through carry
inc r_count ; Carry not touch
On Friday 25 January 2008 22:35, Wouter van Gulik wrote:
> __clzqi2:
> clr r_count ; load with 0
> com r_count ; invert (load with -1) + set carry
> __clzqi2_loop:
> rol r_arg1L ; Rotate through carry
> inc r_count ; Carry not touch by inc
>
Wouter van Gulik wrote:
Hi list,
Hi, Wouter
I have been planning this fix of __clz a long time. I wanted to test it
against gcc testsuite which required fixing all of missing functions. So
I did the missing functions as well!
Nice job :)
It will now pass the earlier failed testcase
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of John Regehr
> Sent: Monday, January 14, 2008 8:12 PM
> To: avr-gcc-list@nongnu.org
> Subject: RE: AVR Benchmark Test Suite [was:
> RE:[avr-gcc-list]GCC-AVRRegis
a bit less precise) Bill's tool should work fine on generic AVR
codes. I'll ping him and see if he'll add an option that does this.
Stack depth analysis should definitely be a part of an AVR test suite. It
should also be in most developers' compilation toolchain but that
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of John Regehr
> Sent: Monday, January 14, 2008 2:07 PM
> To: avr-gcc-list@nongnu.org
> Subject: RE: AVR Benchmark Test Suite [was: RE:
> [avr-gcc-list]G
> Okaaayy. "The Ohio one".
> Do you have link to what you mean?
What, that wasn't clear enough???
Here's the link:
http://selab.csuohio.edu/dsnrg/stack-estimator/
If you try it out I'd be interested to hear your experiences. My
impression is that it needs just a bit of hacking before being
"Weddington, Eric" <[EMAIL PROTECTED]> wrote:
>> Agreed, I think both locations (sf.net, or savannah.nongnu.org)
>> would do fine.
> I lean towards putting it on WinAVR, mainly because doing file
> releases is easier (no GPG key required). Unless you have a
> counter-argument, Joerg?
As I wrote,
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of John Regehr
> Sent: Monday, January 14, 2008 12:33 PM
> To: avr-gcc-list@nongnu.org
> Subject: RE: AVR Benchmark Test Suite [was: RE:
> [avr-gcc-list] G
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Joerg Wunsch
> Sent: Monday, January 14, 2008 12:35 PM
> To: avr-gcc-list@nongnu.org
> Subject: Re: AVR Benchmark Test Suite [was: RE:
> [avr-gcc-list] GC
Dave N6NZ <[EMAIL PROTECTED]> wrote:
>> the Atmel 802.15.4 MAC,
> Need to check license on that one -- but a good choice otherwise
BSD-style.
>> If it is desired to have it in a more neutral place, such as
>> avr-libc, I'm open to that too, if Joerg Wunsch is willing.
> Seems to me that as lon
> application statically... What was it called?
> Oh, yeah, stacktool! ;-) Maybe we could use this... :-)
Unfortunately my tool is unmaintained and tenure-type presssures seem to
be conspiring to keep it that way... but I still plan to take a different
stack analyzer (the Ohio one) and help get
> -Original Message-
> From: Dave N6NZ [mailto:[EMAIL PROTECTED]
> Sent: Sunday, January 13, 2008 4:19 PM
> To: Weddington, Eric
> Cc: John Regehr; avr-gcc-list@nongnu.org
> Subject: Re: AVR Benchmark Test Suite [was: RE:
> [avr-gcc-list] GCC-AVR R
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of John Regehr
> Sent: Sunday, January 13, 2008 11:10 AM
> To: avr-gcc-list@nongnu.org
> Subject: Re: AVR Benchmark Test Suite [was: RE:
> [avr-gcc-list] GC
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of John Regehr
> Sent: Sunday, January 13, 2008 11:10 AM
> To: avr-gcc-list@nongnu.org
> Subject: Re: AVR Benchmark Test Suite [was: RE:
> [avr-gcc-list] GC
> (A friend is currently tearing his hair out
> over a code size regression in a commercial PIC C compiler -- he needs to
> release a minor firmware update to the field... but not even the original code
> fits his flash any more...)
Embedded compiler rule #1: If you find a version of the compiler
Weddington, Eric wrote:
Hi John, Dave, others,
Here are some random thoughts about a benchmark test suite:
- GCC has a page on benchmarks:
<http://gcc.gnu.org/benchmarks/>
However all of those are geared towards larger processors and host
systems. There is a link to a benchmark that f
about
program events such as memory operations, I/O operations, execution of
different kinds of instructions, interrupts, etc.
> focus
> on AVR-specific code, and GCC-specific AVR code at that.
Definitely. If people want to test avr-gcc against other compilers, or
compare AVR to other ar
have worked in and managed various
> different hardware and software validation teams. This is probably a
> good way for me to contribute, since I'm not a compiler
> back-end guru,
> but I have relevant experience writing and reviewing test
> plans. Some
> of those
On May 17, 2007, at 20:45 , kitts wrote:
You need to make sCommandReceived a volatile variable.
Yeah, I realized that, thanks. I'm fully aware of the dangers of the
optimizer, and was operating from the assumption that it was turned
off. I should've known.
Thanks!
--
Rick
_
Rick Mann <[EMAIL PROTECTED]> wrote: On an AVR ATmega128:
I have two source files. In Serial.c, I define a global:
char sCommandReceived;
in the corresponding Serial.h file, I have:
extern char sCommandReceived;
sCommandReceived is set to 1 when enough bytes have been copied into
a buffer fr
On Friday 18 May 2007 9:09:32 am Rick Mann wrote:
> I have two source files. In Serial.c, I define a global:
> charsCommandReceived;
>
> in the corresponding Serial.h file, I have:
>
> extern char sCommandReceived;
>
> sCommandReceived is set to 1 when enough bytes have been copied into
> a b
On an AVR ATmega128:
I have two source files. In Serial.c, I define a global:
charsCommandReceived;
in the corresponding Serial.h file, I have:
extern char sCommandReceived;
sCommandReceived is set to 1 when enough bytes have been copied into
a buffer from the serial port. In main.c, whi
This is a test.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Hello,
the AVR-Ada project has released two binaries for i386-Unix and Windows.
The compiler was configured with --enable-languages=ada,c,c++, so it should
be useful for c/c++ developers, too.
See
http://sourceforge.net/project/shownotes.php?release_id=395122&group_id=74228
for details.
as Lövgren
Cc: 'Vincent Trouilliez'; 'avr-gcc'
Subject: Re: [avr-gcc-list] How to (efficeiently !!!) test a bit
withinamulti-byte integer ?
Niklas Lövgren wrote:
> That's interesting it makes that much differnce between the minors. So how
> much "better"
Niklas Lövgren wrote:
That's interesting it makes that much differnce between the minors. So how
much "better" is gcc 4.x.x?
And also why isn't the newer gcc versions included in a winavr release?
1. Previously, there have been bugs in that tree affecting the AVR port
which has made it a "no-
> Alas, the fix is not yet in any released version of avr-libc, I just
> checked. So you'd either need to pull the fix straight from CVS (as
> all this is just in a header file, the fix would be self-contained,
> you don't need more than that file itself), or you gotta wait a bit.
> Both, avr-libc
Vincent Trouilliez <[EMAIL PROTECTED]> wrote:
>> Bug report #14224, has been resolved meanwhile.
> The bug relates to _delay_ms() though, which I have never problems
> with. It's _delay_us() that misbehaved. But I guess the two are
> related...
Both have been implemented similarly, so I'd assum
On Sat, 2005-11-05 at 20:24 +0100, Joerg Wunsch wrote:
> Vincent Trouilliez <[EMAIL PROTECTED]> wrote:
>
> > Lucky you ! Other than wanting to avoid all this in-line stuff, the
> > reason I replaced _delay_us(40) in my lcd routine, by an empty for
> > loop, is that I accidentally realised that _de
Vincent Trouilliez <[EMAIL PROTECTED]> wrote:
> Lucky you ! Other than wanting to avoid all this in-line stuff, the
> reason I replaced _delay_us(40) in my lcd routine, by an empty for
> loop, is that I accidentally realised that _delay_us(40) produced a
> 1,500us delay somehow !!! Couldn't figure
> Didn't I tell you to poll the LCD's busy bit in the first place?
> Wouldn't have had the above problem if you had. :-)
>
> --
> David Kelly N4HHE, [EMAIL PROTECTED]
Yes yes, you did ;-)
So I decided to tackle it last night, and I wired the LCD R/W line.
I now poll the Busy Flag successfully
On Nov 4, 2005, at 6:18 PM, Vincent Trouilliez wrote:
Correct :-)
actually I did'nt even make it a function, as I use it only in one
place, the routine the send the character to LCD and waits 40us for
the
LCD to process it.
I delcared the loop counter volatile and that indeed fixed it,
tha
cent Trouilliez
Sent: den 5 november 2005 01:28
To: avr-gcc
Subject: Re: [avr-gcc-list] How to (efficeiently !!!) test a bit within
amulti-byte integer ?
> >I compiled 3.4.3 ... does 3.4.4 or 4.0 do a better job at it ?
> >
> >
> With gcc-3.4.4 and -Os, the compiler lo
On Nov 4, 2005, at 6:28 PM, Vincent Trouilliez wrote:
Hmmm, it's interesting to see that 3.4.4 is that much better than
3.4.3 ! It means that avr-gcc is being actively improved, that's
rather
encouraging, at this pace, in 2 or 3 years, it will rival or better
the
most expensive commercial
> FWIW, I always had good luck with the delay functions in delay.h for short
> hardcoded (usec) delays.
Lucky you ! Other than wanting to avoid all this in-line stuff, the
reason I replaced _delay_us(40) in my lcd routine, by an empty for loop,
is that I accidentally realised that _delay_us(40) p
> >I compiled 3.4.3 ... does 3.4.4 or 4.0 do a better job at it ?
> >
> >
> With gcc-3.4.4 and -Os, the compiler loads 4 registers with the 32 bits
> value (address) and then use 'sbrs ,2' to perform the test.
> Hence it is very fast. It would be faster if
> For a long time I always put address bit 0 on address pin A0 of the
> memory,
> bit 1 on A1, etc. But this is not always needed! Especially for a RAM
> device where you the AVR is the only one having access, the address
> lines
> can be swapped as you like. The same holds for the data lines. F
and produces the best possible code:
if (addr.u8.c & 0x04)
2830: 80 91 83 01 lds r24, 0x0183
2834: 82 ff sbrsr24, 2
2836: 02 c0 rjmp.+4 ; 0x283c
only loads the required byte, and performs a straight forward bit tes
> The bug is almost certainly a delay loop variable that is not declared
> volatile. The delay function is probably something like:
>
> void shortDelay(void) {
> uint8_t n = 50;
> while (n--);
> }
Correct :-)
actually I did'nt even make it a function, as I use it only in one
place, the
Empty loops and optimization don't go together. Also
check to ensure you're using 'volatile' where
appropriate. I'm running into this same problem with
some inherited code at work right now.
Tubbs
--- Vincent Trouilliez
<[EMAIL PROTECTED]> wrote:
> On Fri, 2005-11-04 at 10:04 +0100, Jurek Szcz
> FWIW, I always had good luck with the delay functions in delay.h for short
> hardcoded (usec) delays. I don't have access to the code now, but I had a
> macro that calculated the minimum number of trips through the four-cycle
> loop that would guarantee the specified delay. Something like
>
>
From: "David Brown" <[EMAIL PROTECTED]>
[...]
The bug is almost certainly a delay loop variable that is not declared
volatile. The delay function is probably something like:
void shortDelay(void) {
uint8_t n = 50;
while (n--);
}
That (might) work fine with little or no optomisation, bu
gcc do you use?).
I compiled 3.4.3 ... does 3.4.4 or 4.0 do a better job at it ?
With gcc-3.4.4 and -Os, the compiler loads 4 registers with the 32 bits
value (address) and then use 'sbrs ,2' to perform the test.
Hence it is very fast. It would be faster if it needs only one register
Vincent,
I just remembered something that might be of use.
This is a quote
from your first message:
>I just ran into a weird problem that I hardly
expected.
>I wrote a trivial routine that takes a 32bit unsigned int, which holds
a
>memory address, and shifts the lower 19 bits, out to a port pin
> From: Vincent Trouilliez <[EMAIL PROTECTED]>
>
> [...]
>
> >About the -Os flag, I noticed this morning that it managed MASSIVE code
> >size reduction ! SO far I had been using just -O (I guess that means no
> >particular optimisation ?), and the program is about 13KB in size. With
> >-Os, it's on
n 4 november 2005 14:37
To: Vincent Trouilliez
Cc: avr-gcc
Subject: Re: [avr-gcc-list] How to (efficeiently !!!) test a bit within
amulti-byte integer ?
On Nov 3, 2005, at 11:35 PM, Vincent Trouilliez wrote:
>
> static void log_address_set( uint32_t address )
> {
> ...
From: Vincent Trouilliez <[EMAIL PROTECTED]>
[...]
About the -Os flag, I noticed this morning that it managed MASSIVE code
size reduction ! SO far I had been using just -O (I guess that means no
particular optimisation ?), and the program is about 13KB in size. With
-Os, it's only 10KB !!! Sad
On Nov 3, 2005, at 11:35 PM, Vincent Trouilliez wrote:
static void log_address_set( uint32_t address )
{
...
...
if (address & 0x0004)
PORTB |= LOG_SDA;
else
PORTB &= ~LOG_SDA;
...
}
On Nov 4, 2005, at 1:20 AM, Ian Caddy wrote:
I haven't
> Now your problem with 'address & 0x0004' is a real one: avr-gcc is
> not yet very good with 32 bits operators
Well, this way we have nice things to be looking forward to, for
upcoming releases of gcc :-)
> (BTW what version of avr-gcc do you use?).
I compiled 3.4.3 ... does 3.4.4 or
on {
uint32_t my_ulong;;
struct {
uint8_t a;
uint8_t b;
uint8_t c;
uint8_t d;
} my_bytes;
} value;
value.my_ulong=address;
if(value.my_bytes.c & 0x40)
This is very dir
On Fri, 2005-11-04 at 13:23 +0100, niklo wrote:
> Does your lcd-routines rely on busy-waiting? That might be the reason why
> opt doesn't work. I don't know but "badly" written wait-loops might e opt'ed
> away.
Yeah I think we got the same idea... I did replace the _delay_us(40)
delay loop by a cu
liez
Sent: den 4 november 2005 13:11
To: avr-gcc
Subject: Re: [avr-gcc-list] How to (efficeiently !!!) test a bit
withinamulti-byte integer ?
On Fri, 2005-11-04 at 10:04 +0100, Jurek Szczesiul wrote:
> Hi Vince !
> You could also try to retrieve directly the 2. ( from 0) byte of ulong and
check
On Fri, 2005-11-04 at 10:04 +0100, Jurek Szczesiul wrote:
> Hi Vince !
> You could also try to retrieve directly the 2. ( from 0) byte of ulong and
> check
> the bit , something like this ( -Os) :
>
> if( *((uchar*)&long1+2) & 0x4) PORTB = 0x1;
> 8c: 80 91 65 00 lds r24, 0x0065
> 90: 82 ff
On Fri, 2005-11-04 at 10:17 +0100, Alex Wenger wrote:
> Him
>
> Vincent Trouilliez schrieb:
> > Thank you very much Ian, your code is highly efficient, and does work
> > perfectly, unlike && or &. :o) I am in heaven :
> >
> > temp = (address >> 16) & 0xFF;
> > 28bc: ca 01
Him
Vincent Trouilliez schrieb:
> Thank you very much Ian, your code is highly efficient, and does work
> perfectly, unlike && or &. :o) I am in heaven :
>
> temp = (address >> 16) & 0xFF;
> 28bc: ca 01 movwr24, r20
> 28be: aa 27 eor r26,
>>
>> unsigned char temp;
>>
>> temp = (address >> 16) & 0xFF;
>>
>> if(temp & 0x04)
>
>
Hi Vince !
You could also try to retrieve directly the 2. ( from 0) byte of ulong and check
the bit , something like this ( -Os) :
if( *((uchar*)&long1+2) & 0x4) PORTB = 0x1;
8c: 80 91 65 00 lds r24,
On Fri, 2005-11-04 at 15:20 +0800, Ian Caddy wrote:
> Hi Vince,
>
> All your new code is doing is checking that address is non-zero as it is
> a logical AND with a non-zero number, which would get optimised out.
>
> I haven't tried this, but it might be better:
>
> unsigned char temp;
>
> temp
the
previous code.
So that's indeed about 20 times faster. Although I still don't get why
it can't just use one single SBRC/S instruction instead of these 4 cp or
cpc instructions... I guess I am still missing something in the bit test
department...
if (addr
t can't just use one single SBRC/S instruction instead of these 4 cp or
> cpc instructions... I guess I am still missing something in the bit test
> department...
>
> if (address && 0x0004)
> 24ec: 21 15 cp r18, r1
> 2
hI,
On Fri, 04 Nov 2005 11:41:35 +0530, Vincent Trouilliez
<[EMAIL PROTECTED]> wrote:
So that's indeed about 20 times faster. Although I still don't get why
it can't just use one single SBRC/S instruction instead of these 4 cp or
--
Have you tried creating a structu
> How should I re-word my bit test statement/expression, to cause the
> compiler to use these lovely SBRS/C instructions at last ?
Sorry for the noise :-/
Why is it always AFTER I hit the 'send' button, that I suddenly get the
bright idea that stops me pulling my hair ??
chip).
The 19th/MSbit is shifted first, so this is the bit I actually test.
But when I timed the routine, I discovered with much surprise and
horror, that instead of being very quick, it's massively slow to
execute ! About 3ms/3,000 cycles ! This makes it useless in the case at
hand sadly.
I l
84 matches
Mail list logo
