minimal requirements for build C compiler?

[Rob Landley]

On Wednesday 31 May 2006 3:01 am, Bernhard Fischer wrote:
> On Tue, May 30, 2006 at 06:48:30PM -0700, Andre wrote:
> >Mike Frysinger <vapier at gentoo.org> wrote:
> >> On Friday 26 May 2006 08:31, Andre wrote:
> >> > "You should upgrade to a later version" is of course the standard
> >> > argument for dropping support for older tools. It doesn't change
> >> > the fact that 3.4.4 is an offical release and 'bleeding edge' not
> >> > much more than a year ago - which for most projects would be
> >> > reason enough to try to support it.
> >>
> >> your rant here is really pretty weak
> >>
> >> we're not telling you your compiler is outdated, we're telling you
> >> you're using a broken compiler
> >
> >If 'broken' is defined as 'has known bugs' then I have no argument
> >that gcc 3.4.x for ARM is broken (although I would disagree that this
> >is the normal definition...).
> >
> >That isn't really the point though.
> >
> >The point is that writing code which relies on undocumented behaviour
> >within an optimisation pass of the compiler is/was risky and this
> >time you lost. Please just admit it, shrug it off and move on ;-)
>
> To cite landley on this ".. every C compiler since DOS times does
> DeadCodeElimination".
> While i personally see no great benefit in moving the duty of the
> preprocessor into the C compiler domain and to rely on eventual passes
> being performed, the current maintainer did choose to go that route.
> Perhaps complain to him that your compiler has "missed optimization"
> bugs ;)

Well, technically speaking his compiler _is_ doing dead code elimination.  
What it isn't doing is constant propagation.

I.E:

  if (0) thingy();

Will indeed remove the call to thingy() before the linker can barf on it, even 
on the broken compiler.  This is why our makefiles don't bother to build 
thingy() when we know it won't be used.

The problem is with stuff like this:
  int x = 0;

  if (x) thingy();

Which does _not_ remove the call to thingy().  Which is a bug in the compiler.  
The current standard algorithm for constant propogation was published by IBM 
15 years ago:

http://en.wikipedia.org/wiki/Sparse_conditional_constant_propagation
http://www.cs.umass.edu/~emery/classes/cmpsci710-spring2003/p181-wegman.pdf

Not that it was a _new_ technique even then, but the current standard way of 
doing it is as old as the Linux kernel, and a compiler that can't manage even 
that much when told to optimize for size is _broken_.

We can work around it very easily (if (ENABLE_BLAH && x) thingy();), which is 
what we were doing earlier, but it's not worth it because the compiler in 
question is broken and this is a workaround for a broken compiler.

Rob
-- 
Never bet against the cheap plastic solution.