Re: [avr-libc-dev] avr-libc 1.0.5 released

[E. Weddington]

Paul Schlie wrote:

> > From: "E. Weddington" <address@hidden>
> >    
> >
> > Which version of the autotools are you trying to use?
> >    
>
> autoconf (GNU autoconf) 2.59
> automake (GNU automake) 1.8.5
>
> also installing 1.4 etc, isn't an insurmountable problem, just a minor pain,
> as there are some cross incompatibles between different autoconf/automake
> versions.
>
>  
Ok, with my cygwin, I'm using autoconf 2.59 and automake 1.9.2 and I can 
bootstrap avr-libc, BUT I have to do it manually and not run the reconf 
script.

If you take a look at the reconf script, most of it in the beginning is 
checking for proper versions of the tools, then at the bottom it does:

----------------------------------
set -x

${ACLOCAL}
#${AUTOHEADER}
${AUTOCONF}
${AUTOMAKE} --foreign --add-missing --copy
----------------------------------

If you take this and do it manualy, or in your own script:

set -x
aclocal
autoconf
automake --foreign --add-missing --copy

I've never had any problems with the versions that I use listed above.

It is a known task to update avr-libc to be able to use newer versions 
of the autotools; This was a task that Ted was working on, and there's 
even a CVS branch for it.

But perhaps a move to newlib could remove the need for this task as well.

> > > Also a minor update, I experimented with disabling gcc's default promotion
> > > of small integers (char/short) to int; and so far so good, now attempting to
> > > also limit promoting enum's and bool's to the smallest integer type with
> > > sufficient precision, as opposed to defaulting to int, which 99% of the time
> > > will be a char, as most enums tend to be small; but will likely miss some
> > > places for similar improvements, as GCC's expression manipulation code is a
> > > bit tangled.
> > >
> > >      
> > This would be great
> >    
>
> In brief email exchange Richard Henderson, he's already expressed strong
> concerns that it may effect proper/compliant C/C++ function selection
> semantics, which I've just begun thinking about...
>
>  
Sheesh! This is a can of worms....

> > > But unfortunately don't have a great degree of confidence that it would be
> > > easily accepted, as all targets would need to be tested, and although I
> > > don't think it would be detrimental to other targets, it may effect some of
> > > their optimization assumptions if biased toward assuming int types, but not
> > > sure.
> > >      
> > Well, is there any way to make it avr backend specific? That would
> > probably make it easier to get it accepted....
> >    
>
> Unfortunately I doubt that a target specific patch to the C/C++ front-ends
> would be acceptable (that's where the default initial promotions are being
> done); 
Agreed.

What about the idea of adding backend optimizers to check for this stuff?

Eric