Re: [avr-gcc-list] modulo vs. loop (gcc 4.3.x bug)

[Joerg Wunsch]

Szikra Istvan <address@hidden> wrote:

> Maybe we need some kind of "-keep-section-together=.bootloader"
> linker option.

Sections /are/ kept together.

The problem is that your libgcc.a function does not live in the
..bootloader section.  There's no simple way the linker could move it
there, because if both, the application *and* the bootloader section
reference the same symbol, it will only be included once.  Changing
this will require major structural changes in the linker, I guess,
just to solve an arguably fairly rare case.

> My problem here is caused partly because the tool-chain is not in
> sync: the compiler is thinking it's being smart, but the linker is
> not.

You're vastly misinterpreting what you see.

> so how do I tell the compiler to stop messing around, and I know
> what I'm doing so leave that part of the code alone, or stop
> recognizing that pattern in the entire project?

Well, you'd have to turn off optimizations. ;-)  Currently, that
can only be done on a per-compilation unit (i.e., per-file) base,
I've heard it should be possible in future to do it per-function.

You could also try messing around with the optimization settings.
I could imagine that this "optimization" is never activated for
-O3.

Btw., your test code compiles into:

test:
/* prologue: function */
/* frame size = 0 */
        in r25,59-32
        ldi r24,lo8(0)
        rjmp .L5
..L6:
        subi r24,lo8(-(1))
        subi r25,lo8(-(-3))
..L5:
        cpi r25,lo8(3)
        brsh .L6
        out 56-32,r24
        out 53-32,r25
/* epilogue start */
        ret

with my compiler (GCC 4.3.4, FreeBSD patches, identical to the
"Bingo600" build script).

> I think any programmers who writes a loop instead of a modulo or
> divide by mistake really deserves the result.

Compilers recognize patterns, and reorder code on that.  The pattern
is not necessarily as clear as in your case.  Often, such patterns are
hidden e.g. inside a C++ template or such.

Anyway, I never disagreed it's a pessimization (i.e. a typical case
for a "missed optimization" bug), I only disagreed to qualify it as
any kind of serious (in the sense of: wrong code generated) bug.  I
cannot imagine a case where calling the division function on the AVR
would result in really smaller code than the simple loop.

I'm surprised about the different result in your compilation, because
after all, I think my compiler patches are basically on sync with the
latest WinAVR patches (modulo the Ada-related patches, as I don't
build the Ada compiler on FreeBSD [right now]).

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)