Compiler question....

Compiler question....

[Ivan Gyurdiev]

Kernel 2.5.17

Should the compiler be blamed or the code?
gcc 2.96 compiles it. 3.1 won't.
Before people yell at me to use the recommended compiler, I would like to say
that it really wouldn't solve the problem. Compilers move forward, the code 
has to comply. Therefore I'm excersing my right to ignore all warnings about 
my compiler and use it. If this is a bug in the compiler, I'd agree and 
switch back to 2.96. Otherwise I'd suggest the code be changed.
Comments or advice?

In file included from attrib.h:31,
                 from debug.h:31,
                 from ntfs.h:40,
                 from aops.c:29:
layout.h:299: unnamed fields of type other than struct or union are not 
allowed
layout.h:1450: unnamed fields of type other than struct or union are not 
allowed
layout.h:1466: unnamed fields of type other than struct or union are not 
allowed
layout.h:1715: unnamed fields of type other than struct or union are not 
allowed
layout.h:1892: unnamed fields of type other than struct or union are not 
allowed
layout.h:2052: unnamed fields of type other than struct or union are not 
allowed
layout.h:2064: unnamed fields of type other than struct or union are not 
allowed

Re: Compiler question....

[Anton Altaparmakov]

At 02:40 21/05/02, Ivan Gyurdiev wrote:
>Kernel 2.5.17
>
>Should the compiler be blamed or the code?
>gcc 2.96 compiles it. 3.1 won't.
>Before people yell at me to use the recommended compiler, I would like to say
>that it really wouldn't solve the problem. Compilers move forward, the code
>has to comply. Therefore I'm excersing my right to ignore all warnings about
>my compiler and use it. If this is a bug in the compiler, I'd agree and
>switch back to 2.96. Otherwise I'd suggest the code be changed.
>Comments or advice?

I consider it a bug in the compiler. The gcc folk have not replied to my 
filed bug report yet so I have no idea if they agree or not...

The error messages the compiler is generating are completely bogus because 
the unnamed fields ARE of type struct or union. It's just that they are 
typedeffed so that the words "struct" and "union" do not appear. IMO that 
is a screwup by gcc...

Best regards,

         Anton

>In file included from attrib.h:31,
>                  from debug.h:31,
>                  from ntfs.h:40,
>                  from aops.c:29:
>layout.h:299: unnamed fields of type other than struct or union are not
>allowed
>layout.h:1450: unnamed fields of type other than struct or union are not
>allowed
>layout.h:1466: unnamed fields of type other than struct or union are not
>allowed
>layout.h:1715: unnamed fields of type other than struct or union are not
>allowed
>layout.h:1892: unnamed fields of type other than struct or union are not
>allowed
>layout.h:2052: unnamed fields of type other than struct or union are not
>allowed
>layout.h:2064: unnamed fields of type other than struct or union are not
>allowed




-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

RE: Compiler question....

[Ed Vance]

On Tue, May 21, 2002, Anton Altaparmakov wrote:
> 
> The error messages the compiler is generating are completely 
> bogus because the unnamed fields ARE of type struct or union. 
> It's just that they are typedeffed so that the words "struct" 
> and "union" do not appear. IMO that is a screwup by gcc...

Agreed, IIRC, didn't ANSI C spec address this specific point? That any two
types which contain matching simple types must be considered to match,
regardless of how they were declared, typedef or explicitly. e.g. Unlike
Pascal, typedef does not create "new" types. It creates aggregates of simple
types. 

Ed

---------------------------------------------------------------- 
Ed Vance              edv@macrolink.com
Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
----------------------------------------------------------------

Compiler Question

[wei.li4]

Hi All,

It seems that there is a rule that Compiler or Linker assigns r3, r4 
... to the arguments of C function when it is called, and r1 is the 
address of Stack Pointer, and how is for r0 and r2? where can I find 
these rules? Thanks.

Wei

Re: Compiler Question

[Becky Bruce]

These requirements are part of the Application Binary Interface, or  
ABI for short.  Since you're posting to the Linux embedded list, I  
assume you want the general powerpc 32-bit ABI.  This can be found at

http://refspecs.freestandards.org/elf/elfspec_ppc.pdf

and other places on the web.

There's also a 32-bit powerpc Embedded ABI (not used by Linux).  Some  
tool and OS vendors use this ABI instead of the one above.  A quick  
googling of this shows a copy can be found at http:// 
www.cloudcaptech.com/MPC555%20Resources/Programming%20Environment/ 
ppceabi.pdf#search=%22powerpc%20eabi%22

Cheers,
B


On Oct 5, 2006, at 8:29 AM, wei.li4@elf.mcgill.ca wrote:

> Hi All,
>
> It seems that there is a rule that Compiler or Linker assigns r3, r4
> ... to the arguments of C function when it is called, and r1 is the
> address of Stack Pointer, and how is for r0 and r2? where can I find
> these rules? Thanks.
>
> Wei
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded