autocompilation hosed?

autocompilation hosed?

[david mosberger]

Hi Ian,

It looks like something is wrong with cogito on the auto kernel build
machine.  All builds have been failing as of yesterday because of
that, as this page shows:

  http://www.gelato.unsw.edu.au/kerncomp/

  --david

Re: autocompilation hosed?

[Ian Wienand]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]

On Tue, Jul 12, 2005 at 02:28:50PM -0700, david mosberger wrote:
> It looks like something is wrong with cogito on the auto kernel build
> machine.

Yeah, we've moved offices and in the name of "security" our machines
are spilt across three different networks with all sorts of firewalls
and crap in between, breaking everything that just used to work.

Hopefully I'll fix it today or tomorrow (at least you can see it which
means we must have DNS sorted out ... finally :)

-i


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: autocompilation hosed?

[david mosberger]

On 7/12/05, Ian Wienand <ianw@gelato.unsw.edu.au> wrote:

> Yeah, we've moved offices and in the name of "security" our machines
> are spilt across three different networks with all sorts of firewalls
> and crap in between, breaking everything that just used to work.
> 
> Hopefully I'll fix it today or tomorrow (at least you can see it which
> means we must have DNS sorted out ... finally :)

Ah, OK, no big rush.

Thanks,

  --david

Re: autocompilation hosed?

[Ian Wienand]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

On Tue, Jul 12, 2005 at 03:28:35PM -0700, david mosberger wrote:
> On 7/12/05, Ian Wienand <ianw@gelato.unsw.edu.au> wrote:
> > Hopefully I'll fix it today or tomorrow (at least you can see it which
> > means we must have DNS sorted out ... finally :)

Ok, some fiddling and a quick cogito update and it is running again.
For future runs it should use gcc-4.0; do you think this is a good
idea?

-i

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: autocompilation hosed?

[david mosberger]

On 7/12/05, Ian Wienand <ianw@gelato.unsw.edu.au> wrote:
> On Tue, Jul 12, 2005 at 03:28:35PM -0700, david mosberger wrote:
> > On 7/12/05, Ian Wienand <ianw@gelato.unsw.edu.au> wrote:
> > > Hopefully I'll fix it today or tomorrow (at least you can see it which
> > > means we must have DNS sorted out ... finally :)
> 
> Ok, some fiddling and a quick cogito update and it is running again.
> For future runs it should use gcc-4.0; do you think this is a good
> idea?

I'm also using gcc-4.0.1 by default now.  It basically seems to work
(apart from lots of additional annoying warning messages).  There is
one oddity: on my zx2000, it doesn't boot anymore without console=tty0
or console=ttyS0 arguments.  I'm not sure yet whether that's a
compiler-triggered problem or whether something changed in the kernel
that's causing this.

  --david

Re: autocompilation hosed?

[Tony Luck]

> I'm also using gcc-4.0.1 by default now.  It basically seems to work
> (apart from lots of additional annoying warning messages).  There is
> one oddity: on my zx2000, it doesn't boot anymore without console=tty0
> or console=ttyS0 arguments.  I'm not sure yet whether that's a
> compiler-triggered problem or whether something changed in the kernel
> that's causing this.

No ... I saw it too without gcc-4.  See http://tinyurl.com/clzbu where I
identified the patch that seems to be the cause.

-Tony

Re: autocompilation hosed?

[david mosberger]

[-- Attachment #1: Type: text/plain, Size: 686 bytes --]

On 7/12/05, Tony Luck <tony.luck@gmail.com> wrote:
> > I'm also using gcc-4.0.1 by default now.  It basically seems to work
> > (apart from lots of additional annoying warning messages).  There is
> > one oddity: on my zx2000, it doesn't boot anymore without console=tty0
> > or console=ttyS0 arguments.  I'm not sure yet whether that's a
> > compiler-triggered problem or whether something changed in the kernel
> > that's causing this.
> 
> No ... I saw it too without gcc-4.  See http://tinyurl.com/clzbu where I
> identified the patch that seems to be the cause.

Patch below fixes the problem.  Moral of the story: don't add
"attributed(packed)" lightly!

  --david

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: pcdp-fix.diff --]
[-- Type: text/x-patch; name="pcdp-fix.diff", Size: 606 bytes --]

[IA64] Make PCDP work again.

Mark's patch added "attribute((packed))" for pcdp_uart, without
accounting for the fact that the structure definition _relied_ on
implicit padding by 6 bytes.  Fix is to make the padding explicit.

Signed-off-by: David Mosberger-Tang <David.Mosberger@acm.org>

diff --git a/drivers/firmware/pcdp.h b/drivers/firmware/pcdp.h
--- a/drivers/firmware/pcdp.h
+++ b/drivers/firmware/pcdp.h
@@ -52,6 +52,8 @@ struct pcdp_uart {
 	u32				clock_rate;
 	u8				pci_prog_intfc;
 	u8				flags;
+	u16				conout_index;
+	u32				reserved;
 } __attribute__((packed));
 
 #define PCDP_IF_PCI	1

RE: autocompilation hosed?

[Magenheimer, Dan (HP Labs Fort Collins)]

> > No ... I saw it too without gcc-4.  See 
> http://tinyurl.com/clzbu where I
> > identified the patch that seems to be the cause.
> 
> Patch below fixes the problem.  Moral of the story: don't add
> "attributed(packed)" lightly!

IIRC as of gcc3.2, attribute(packed) on ia64 meant roughly the
equivalent of specifying "generate the worst case possible
code even for things that are aligned".  Is that still the
case in gcc-4?

Re: autocompilation hosed?

[david mosberger]

On 7/14/05, Magenheimer, Dan (HP Labs Fort Collins)
<dan.magenheimer@hp.com> wrote:
> > > No ... I saw it too without gcc-4.  See
> > http://tinyurl.com/clzbu where I
> > > identified the patch that seems to be the cause.
> >
> > Patch below fixes the problem.  Moral of the story: don't add
> > "attributed(packed)" lightly!
> 
> IIRC as of gcc3.2, attribute(packed) on ia64 meant roughly the
> equivalent of specifying "generate the worst case possible
> code even for things that are aligned".  Is that still the
> case in gcc-4?

I'm not sure whether gcc-4 is doing a better job at identifying
structures which are aligned better than the worst-case (I'd be
curious to hear about that, if somebody plays with this or already
knows how it behaves).  Having said that, for EFI that's hardly an
issue since most of the code using those structures is executed only
once at boot-time, so performance isn't an issue (I suppose code-size
may be almost a bigger issue in that area).

  --david

RE: autocompilation hosed?

[James E Wilson]

[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]

On Thu, 2005-07-14 at 08:23, Magenheimer, Dan (HP Labs Fort Collins)
wrote:
> IIRC as of gcc3.2, attribute(packed) on ia64 meant roughly the
> equivalent of specifying "generate the worst case possible
> code even for things that are aligned".  Is that still the
> case in gcc-4?

attribute((packed)) means that the type has alignment of 1 byte.  Thus
we must use unaligned/bit-field load/store instructions.  Some targets
have efficient instructions for that, some don't.  Some ports can use
those instructions efficiently, some can't.

If a variable has greater alignment than its type, then we can make use
of that info to generate better code.  For instance, if a variable is
allocated on the stack, then we know that it must have a certain
alignment which may be greater than the alignment of its type.

You can also specify alignment by using __attribute__((aligned(X))).
This can be added either to a type or to a variable, to specify an
alignment greater than the default alignment for the type or variable.

Consider the attached testcase.  Compile with -O -S.  The code emitted
for loading the variable "tmp" is good, because we know it has stack
alignment.  The code for loading "bar" is bad, because it inherits
1-byte alignment from its type.  The code for loading "baz" is good,
because we explicitly aligned it via an attribute.

We don't emit run time checks for alignment, so if something has a
default alignment of 1 byte, but accidentally happens to have 8-byte
alignment at runtime, then you still have to execute the slow code for
it.

[-- Attachment #2: tmp.c --]
[-- Type: text/x-c, Size: 210 bytes --]

struct foo
{
  int i;
  char c;
  int j;
} __attribute__ ((packed));

struct foo bar;

struct foo baz __attribute__ ((aligned(8)));

int
main (void)
{
  struct foo tmp;
  sub (tmp);
  sub (bar);
  sub (baz);
}

RE: autocompilation hosed?

[Magenheimer, Dan (HP Labs Fort Collins)]

Very educational.  Thanks! 

> -----Original Message-----
> From: James E Wilson [mailto:wilson@tuliptree.org] 
> Sent: Thursday, July 14, 2005 4:02 PM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: David Mosberger; Tony Luck; Ian Wienand; 
> linux-ia64@vger.kernel.org
> Subject: RE: autocompilation hosed?
> 
> On Thu, 2005-07-14 at 08:23, Magenheimer, Dan (HP Labs Fort Collins)
> wrote:
> > IIRC as of gcc3.2, attribute(packed) on ia64 meant roughly the
> > equivalent of specifying "generate the worst case possible
> > code even for things that are aligned".  Is that still the
> > case in gcc-4?
> 
> attribute((packed)) means that the type has alignment of 1 byte.  Thus
> we must use unaligned/bit-field load/store instructions.  Some targets
> have efficient instructions for that, some don't.  Some ports can use
> those instructions efficiently, some can't.
> 
> If a variable has greater alignment than its type, then we 
> can make use
> of that info to generate better code.  For instance, if a variable is
> allocated on the stack, then we know that it must have a certain
> alignment which may be greater than the alignment of its type.
> 
> You can also specify alignment by using __attribute__((aligned(X))).
> This can be added either to a type or to a variable, to specify an
> alignment greater than the default alignment for the type or variable.
> 
> Consider the attached testcase.  Compile with -O -S.  The code emitted
> for loading the variable "tmp" is good, because we know it has stack
> alignment.  The code for loading "bar" is bad, because it inherits
> 1-byte alignment from its type.  The code for loading "baz" is good,
> because we explicitly aligned it via an attribute.
> 
> We don't emit run time checks for alignment, so if something has a
> default alignment of 1 byte, but accidentally happens to have 8-byte
> alignment at runtime, then you still have to execute the slow code for
> it.
>