[avr-gcc-list] building avr-gcc from svn head?

of compilers to play with since we're doing some comparative testing that is aimed at finding compiler bugs. If there are IRA issues we can perhaps help find them. Thanks, John Regehr libbackend.a(avr.o): In function `avr_cpu_cpp_builtins': /home/regehr/avrgcc450/gcc/obj/gcc/../../gcc/config/avr

Re: [avr-gcc-list] avr superoptimizer

of the benefit. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: [avr-gcc-list] avr superoptimizer

Sean is your code available? A quick scan of the AVR Freaks thread didn't show it. Thanks, John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

RE: [avr-gcc-list] avr superoptimizer

That's why I'm (desperately) hoping that the LTO project in GCC will eventually help in this area. http://gcc.gnu.org/wiki/LinkTimeOptimization Alternatively, an LLVM backend for AVR would give this capability (approximately) for free. John ___

RE: [avr-gcc-list] avr superoptimizer

On Mon, 20 Apr 2009, Weddington, Eric wrote: Unfortunately diablo looks a bit stale. Their latest release was over 3 years ago (Feb. 2006), and their required patches are for binutils 2.13 and gcc 3.3.2. :-P Is this project even a going concern anymore? I don't think so. And anyway I think

RE: [avr-gcc-list] when is it safe to use -mtiny-stack

but certainly that would be nice. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: [avr-gcc-list] when is it safe to use -mtiny-stack

On Tue, 7 Apr 2009, Anatoly Sokolov wrote: The -mtiny-stack may (and should) be used only for devices with 0xFF max RAM adderss, i.e. if SP register is 8-bit. All devices with 1KB and 2KB FLASH memory satisfy this condition, now. Is it not sufficient for the maximum extent of the stack to be

RE: [avr-gcc-list] Any SimulAVR or avrtest users out there?

For the sake of discussion here, what makes it very easy to extend? Avrora makes it easy to write monitors which are Java classes that can receive callbacks when many interesting kinds of simulator events occur: memory operations, instruction execution, interrupts, etc. A majority of the

Re: [avr-gcc-list] Any SimulAVR or avrtest users out there?

to every other simulator I've hacked. John Regehr On Wed, 11 Mar 2009, Sascha Silbe wrote: On Wed, Mar 11, 2009 at 10:13:52AM -0600, Weddington, Eric wrote: There's a lot of new work being done at the SimulAVR project: http://savannah.nongnu.org/projects/simulavr FYI: There's avrora [1] as well

RE: More volatile musings [was: Re: [avr-gcc-list] memcpy() : problem when passing destination pointer]

for that version be useful? If not is there a definitive script for building a fully patched avr-gcc-pre-4.4.0 on Linux? Thanks, John Regehr On Thu, 12 Feb 2009, Weddington, Eric wrote: -Original Message- From: avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org [mailto:avr-gcc-list

Re: [avr-gcc-list] Most reliable version of avr-gcc?

register allocator, I think). John Regehr On Wed, 17 Dec 2008, David Carr wrote: By reliability, I mean least probability of undetected errors in machine code generation. IE: The machine code conforms to the source code. Thanks, -DC Weddington, Eric wrote: -Original Message- From

Re: [avr-gcc-list] Re: AVR LLVM backend?

PROTECTED] org] On Behalf Of John Regehr Sent: Thursday, November 13, 2008 9:23 PM To: David Brown Cc: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] Re: AVR LLVM backend? I'm pretty sure this is not an issue (anymore, at least). I could be wrong. The recently-added PIC port of LLVM would

Re: [avr-gcc-list] Re: AVR LLVM backend?

:). If the backend does materialize, I volunteer to beat the crap out of it with my random tester! John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

RE: [avr-gcc-list] AVR LLVM backend?

of volatile. The LLVM people almost always fix bugs in a few days whereas there's at least one volatile bug that has sat in the gcc bugzilla for 6 months without even being confirmed. As a result LLVM is at present almost totally volatile-correct, gcc has a ways to go. John Regehr -- John Regehr

RE: [avr-gcc-list] Re: AVR LLVM backend?

My experience with -fwhole-program -fcombine has been less than stellar. I have seen a 25% code reduction, which is great! But I have also seen up to 25% code *increase*, which is really bad. I would have thought that, at the very least, they would ensure that the code size would not increase.

Re: [avr-gcc-list] Re: AVR LLVM backend?

:). John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

RE: [avr-gcc-list] Stack usage under heavy inlining

for an embedded application. The hard part, which cannot be automated, is turning these parts into a sound and precise global stack bound. To see why this is hard, consider that there may be threads, there may be coroutines, there may be reentrant and/or nested interrupts, etc. John Regehr

Re: [avr-gcc-list] A few basic doubts regarding installing AVR-GCC on Fedora 9

I'm happy to help stress-test the new register allocator etc. if someone can make available a script for building pre-4.4 on Linux. For various reasons (my fault I'm sure) from-scratch patching and building has been failing for me on various Ubuntus. John Regehr

[avr-gcc-list] wrong code from avr-gcc 4.1.2?

the -fwrapv is relevant here but include it to be on the safe side. John Regehr static inline unsigned long int div_rhs(const long int rhs) { if (rhs == 0) return 1; return rhs; } unsigned long g_66; long g_73; int func_1 (void) { unsigned long l_86 = -1L; unsigned long l_93 = -9L

RE: [avr-gcc-list] wrong code from avr-gcc 4.1.2?

4.1.2 for TinyOS. Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of John Regehr Sent: Sunday, June 01, 2008 9:14 PM To: avr-gcc-list@nongnu.org Subject: [avr-gcc-list] wrong code from avr-gcc 4.1.2? In the code below, avr-gcc 4.1.2 wants to return

RE: [avr-gcc-list] wrong code from avr-gcc 4.1.2?

Sorry, but most of the developers are dealing with HEAD/4.4 or maybe 4.3.0. I understand that you're using 4.1.2 for TinyOS. Out of curiosity, what version of avr-gcc would you (and others) recommend right now for production use? Thanks, John

RE: [avr-gcc-list] wrong code from avr-gcc 4.1.2?

Can you post the output using?: -O1 -dP See below (but this isn't likely to be useful-- the function returns the correct result at -O1). Code is wrong at -Os, -O2, and -O3. Even further below is the compiler output for -Os -dP. Thanks, John [EMAIL PROTECTED] tmp14]$ avr-gcc -O1 -dP

[avr-gcc-list] even register number required

We found a bug in avr-gcc 4.1.2. Thanks, John Regehr [EMAIL PROTECTED] tmp11]$ avr-gcc --version avr-gcc (GCC) 4.1.2 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS

Re: [avr-gcc-list] even register number required

To elaborate a bit, the problem boils down to generation of this clearly wrong code: movw r13,r24 John ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: [avr-gcc-list] even register number required

I just checked and 4.2.2 doesn't have the problem either. So probably not that big of a deal except that 4.1.2 is going to see fairly heavy use fairly shortly due to an upcoming TinyOS release. Thanks, John On Fri, 30 May 2008, Preston Wilson wrote: John Regehr wrote: We found a bug

Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os

of sequence points John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

RE: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os

The PORTA bits are used for hardware control. I want to use the atan2(), etc. calls as pulse stretching. Then I recommend using the calls in util/delay.h to get exact delays instead of monkeying around with floating point routine calls. They'll be a lot more exact as well as being a boatlad

Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os

Well, isn't the net effect of volatile simply a more fine-grained clobbering lock? Almost but not quite: - volatile says nothing about the atomicity of any given access - volatile does not suppress reordering (except with other volatiles) - volatile has no effect on caches and out-of-order

Re: [avr-gcc-list] AVR-Gcc and overflow behavior

Unsigned overflow is always OK. Signed overflow is undefined behavior (no better--in principle at least--than accessing beyond an array bound) unless you use the -fwrapv flag. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http

[avr-gcc-list] accessing carry bit

of many nasty security holes. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: [avr-gcc-list] problem with malloc() in avr-libc 1.6.1

platform this kind of check is not optional. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

RE: [avr-gcc-list] More results from the testsuite with avrtest

Please see the GCC project about this. IIRC, they already have a script that does a binary search on failing test cases. IIRC, it is in the contrib subdirectory. Also this Delta implementation is very useful for minimizing an offending test program (either before or after narrowing settling

RE: AVR Benchmark Test Suite [was: RE: [avr-gcc-list] GCC-AVRRegisteroptimisations]

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

RE: AVR Benchmark Test Suite [was: RE: [avr-gcc-list]GCC-AVRRegisteroptimisations]

Is this program designed for general purpose AVR applications? Or just for TinyOS? The answer is unfortunately a bit subtle... The question is, how clever of an analysis do you want? This tool (and mine) attempt to be clever by inferring that at some program points, interrupts are disabled,

Re: AVR Benchmark Test Suite [was: RE: [avr-gcc-list] GCC-AVR Register optimisations]

codes since in a short simulation run the worst-case stack usage is unlikely to be encountered. Perhaps adding up the stack memory usage of main + all interrupts would be better. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http

Re: AVR Benchmark Test Suite [was: RE: [avr-gcc-list] GCC-AVR Register optimisations]

(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

Re: [avr-gcc-list] odd left-shift behavior, avr-gcc 4.1.2

across -O0, -O1, -O2, -Os, -O3. On the other hand, given the same input x86 gcc robustly puts 0x1fffe into x. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: [avr-gcc-list] odd left-shift behavior, avr-gcc 4.1.2

left operand. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[avr-gcc-list] odd left-shift behavior, avr-gcc 4.1.2

Using avr-gcc 4.1.2, this code: int32_t x = ((uint16_t)0xL) ((uint32_t)1L); puts 0xfffe into x, as opposed to 0x1fffe as I would have expected. Is a C compiler not required to promote such that both operands of a shift are the same size? Thanks, John Regehr

Re: [avr-gcc-list] Re: TinyOs avr-gcc-4 - a wrap-up

to support easy interoperation with C code, either through direct inclusion or through linking - AVR was the original platform for TinyOS/nesC and is still an important one, although several other architectures are now supported John Regehr

Re: [avr-gcc-list] Fwd: [Tinyos-help] TinyOs avr-gcc-4

that TinyOS applications are typical of interrupt-driven ATmega codes, this may be of general interest. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

RE: [avr-gcc-list] Fwd: [Tinyos-help] TinyOs avr-gcc-4

programs. - nesC isn't that obscure, I think it can parse all of C. John Regehr On Mon, 15 Oct 2007, Eric Weddington wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of John Regehr Sent: Monday, October 15, 2007 12:42 PM

RE: [avr-gcc-list] Problem with delay loop

Ah, ok then. In practice, I have never needed to use setjmp/longjmp, so I have a tendency to forget about these routines. We should all be so lucky :). John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org

RE: [avr-gcc-list] Problem with delay loop

to volatile globals: loads and stores in the abstract machine must correspond one-to-one with loads and stores (to RAM, not registers) in the physical machine. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org

[avr-gcc-list] possible 4.1.2 bug

in any case. The only other version I tried is 3.4.3 which has the same problem. Figured I'd check here to see if I'm missing something silly before filing a bug. John Regehr void foo (char, char, char, char, char); short bar (void) { char a = 0; volatile char b = 0; char c = 0; char d

Re: [avr-gcc-list] possible 4.1.2 bug

Doh. I figured that this sort of constraint would be implicit from the instructions used. Thanks! John Regehr On Thu, 29 Mar 2007, Joerg Wunsch wrote: John Regehr [EMAIL PROTECTED] wrote: I'm not at all sure that the asm is correct (didn't write it) but it seems that gcc shouldn't

[avr-gcc-list] avr-gcc 3.4.3 confused about function pointers

hearing about it if there's a patch for this or if the bug is known to be fixed in later versions. Thanks, John Regehr struct bar { void *yyy; void *aaa; }; void foo (void) { } void stuff (void) { struct bar back[2]; void (*p) (void) = foo; back[0].aaa = (void *) (foo + 1