pragma pack() in arm-elf-gcc 3.2.1

pragma pack() in arm-elf-gcc 3.2.1

[Aaron Case]

Hello,

I have looked through the gcc manual and the mailing various mailing lists
to find the status on pragma implementation in arm-elf-gcc version 3.2.1.

Is this supported in the 3.2.1 version?  I am porting code with pragma
pack()...pragma pack(1).

If anyone can point me to a concrete source on this subject or know from
experience. Otherwise it looks like I might be building gcc again(yuck).

Thanks in advance
Aaron Case

Re: pragma pack() in arm-elf-gcc 3.2.1

[Eljay Love-Jensen]

Hi Aaron,

The #pragma directive you described is compiler-specific, and not part of GCC.

GCC supports these #pragma directives:
#pragma GCC poison identifier(s)
  identifier(s) is one-or-more identifiers that have been marked for removal
#pragma GCC dependency "file" error message text
  file is the file that must be older (by fstat) than this source file
  error message text is the textual output when the check triggers
#pragma GCC system_header
  consider the rest of the file a system header

No "#pragma pack" nor "#pragma GCC pack" in GCC 3.2.

GCC has the C/C++ language extensions:
    __attribute__((aligned(8)))
    __attribute__((packed))

See <http://gcc.gnu.org/onlinedocs/gcc-3.2.3/gcc/Type-Attributes.html>

HTH,
--Eljay

Re: pragma pack() in arm-elf-gcc 3.2.1

[Ian Lance Taylor]

Eljay Love-Jensen <eljay@adobe.com> writes:

> No "#pragma pack" nor "#pragma GCC pack" in GCC 3.2.

That is not correct.  gcc does support #pragma pack for a number of
targets, for compatibility with other compilers.

It's not properly documented, but look for HANDLE_SYSV_PRAGMA on this
page of the internals manual:
    http://gcc.gnu.org/onlinedocs/gccint/Misc.html#Misc

Ian

Re: pragma pack() in arm-elf-gcc 3.2.1

[Eljay Love-Jensen]

Hi Ian,

Note, the macro need to be defined in the correct configuration file, so you can build your own GCC 3.2.1 (or whatever interests you) with the desired compiler capability.

--Eljay

PS to Ian: thanks for the information!
<http://gcc.gnu.org/onlinedocs/gccint/Target-Macros.html> 

making library calls inline w/ and w/o optimization ebabled

[Aaron Case]

Hello,

I am porting code from MSVC v5.1 to gcc.

The application code contains the pragma directive intrinsic as such.

#pragma intrinsic(memset)

This, as expected, is not recognized with GCC as it does not contain this
pragma directive(see warning below).

xyztask.c:56: warning: ignoring #pragma intrinsic


GCC does however have an attribute __always_inline, and says this in the
manual.

always_inline
Generally, functions are not inlined unless optimization is specified. For
functions declared inline, this attribute inlines the function even if no
optimization level was specified.

However, memset is a library function. So if the optimization is turned off
and I declare it as inline and apply this attribute the compiler will
compile the code in-line.

Since this is a library function how do you force the compiler to make it
inline(redeclare, overload...?), or does GCC have a mechanism to force
inline compilation of library calls.

Thanks in advance
Aaron

Re: making library calls inline w/ and w/o optimization ebabled

[John Love-Jensen]

Hi Aaron,

To port MSVC 5.1 code that has "#pragma intrinsic(memset)" stuff, just
comment out the #pragma.

That kind of #pragma is used in conjunction with built-ins that MSVC 5.1
has, which GCC does not have.

If you are really ambitious, you can write your own memset routine.  But I
think that would be overkill.

"Premature optimization is the root of all evil." ~ Donald Knuth

Having an inline memset is a premature optimization, unless you already know
that it is a bottleneck.  And as far as memset routines go, you could write
customized code that takes advantage of moving 32 or 64-bits around at a
time, whereas a plain-and-simple/naïve memset moves only a byte around at a
time.

NOTE:  I'm not claiming that any given compiler vendor's memset is
necessarily a naïve implementation.  I've seen memset routines that use the
whole bandwidth of the data-bus when possible.

HTH,
--Eljay