char alignment on ARM

2007-01-17 Thread Inder

Hi All
I have similar question as for arm
http://gcc.gnu.org/ml/gcc/2007-01/msg00691.html
consider the following program.
e.g..
- align.c -
int main()
{
int bc;
char a[6];
int ac;

bc = 0x;
/* fill with zeros.  */
a[0] = 0x00;
a[1] = 0x01;
 a[2] = 0x02;
  a[3] = 0x03;
   a[4] = 0x04;
a[5] = 0x05;

ac=0x;
make(a);
}
void make(char* a)
{
*(unsigned long*)a = 0x12345678;
}
--- End ---

the local variable for function main are pushed on the stack
as ac(4byte) + bc(4bytes)+a[6](6bytes)+2bytes padding
stating address of the char array now starts from an
unaligned address and is acessed by the instruction
  strbr3, [fp, #-26]

which gives a very wrong result when passed to the function make.

Previously we were using an older version of gcc
which actually aligned the address of the char array also.

Older version of gcc : v2.94
New Version : v4.0.1

Is the compiler doing a right thing or is it a bug??
--
Thanks,
Inder


no warning being displayed.

2005-11-06 Thread Inder
Hi all,
I am compiling small program on a SPARC gcc 3.4.3

test.c
---

struct test1
{
 int a;
 int b;
 char c;
};

struct test2
 {
 char a;
 char b;
 char c;
};

struct test3
{
 int a;
 int b;
 int c;
};

int main()
{
 struct test1* t1, t11;
 struct test2* t2 ;
 struct test3* t3;

 t1 = &t11;
 t2 = (struct t2*)t1;
 t3 = (struct t3*)t1;
 return 0;
}


I suppose such an assignment should give a warning
"incompatible pointer type" but when compiling with
gcc 3.4.3 no such warning is given even with -Wall enabled.

Is this a bug in this version?

GCC version used
---
 ./cc1 --version
GNU C version 3.4.3 (sparc-elf)
compiled by GNU C version 3.2.3 20030502 (Red Hat Linux 3.2.3-20).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072


--
Thanks,
Inder


Re: no warning being displayed.

2005-11-07 Thread Inder
Hi Richard

Well i know that this is a list for development of gcc.
Let me be more precise about my question -
I am using gcc 3.4.3 (sparc-elf) to compile my codebase which uses such kind of
assignments but the compiler gives no warnings what so ever.
but the more recent version given below gives these warnings.

So the question now is if this is a problem for that particular
version of gcc(3.4.3) where can i start to fix it.


[EMAIL PROTECTED] gcc]$ ./cc1 test.c
 main
../../gccbin/gcc/test.c: In function main:
../../gccbin/gcc/test.c:33: warning: assignment from incompatible pointer type
../../gccbin/gcc/test.c:34: warning: assignment from incompatible pointer type
../../gccbin/gcc/test.c:35: warning: assignment from incompatible pointer type

[EMAIL PROTECTED] gcc]$ ./cc1 --version
GNU C version 4.1.0 20051102 (experimental) (sparc-elf)
   compiled by GNU C version 3.2.3 20030502 (Red Hat Linux 3.2.3-20).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096


conditional expression evaluation at compile time in gcc 4.01

2006-02-22 Thread Inder
Hi All

I am trying to compile 'test.cc' (code attached) with the gcc 4.0.1
it gives me the following error:

test.cc:19: error: array bound is not an integer constant

so it is not able to evaluate the conditional expression in gcc 4.0.1,
while this is being compile by gcc 3.4 without any errors.

Is this a bug in gcc 4.0.1

Any help will be appreciated.

Thanks
Inder.




--- test.cc
---
#include 

typedef struct
{
 int length;
 int a;
 int b;
}CYANBUFFER;

typedef struct
{
 int a;
 int length;
}tNPMessage;



#define my_offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
int hello[my_offsetof(CYANBUFFER, length)==my_offsetof(tNPMessage,
length)?10:1];

int main()
{
 return 0;
}

--- test.cc
---


_GLOBAL_ query

2006-03-16 Thread Inder
Hi All

I have  a query regarding __GLOBAL_ prefixed symbols.
while compiling the testcase given below produces
a symbol '_GLOBAL__I_main', which according to the defination of
static global initiallization should be a global symbol. But
gcc makes it a local symbols.

can anyone explain the reason for this behaviour.

i am using gcc 4.0.1.





- testcase.cc
class tempttt{
int a;
int b;

public:
tempttt()
{ a=10; b=100;}

};

static tempttt t;
int main()
{
 return 0;
}

-

-
Thanks,
Inder


question regarding stack size for SPARC

2006-04-19 Thread Inder
Hi All

While compiling code for SPARC Architecture, Its seems reasonable that
when calling a new function, stack Size of 92 + 4(for alignment) is
allocated. But
with gcc version greater than 3.0, It allocates 104 bytes for the
stack of a new function.

Can anyone please let me know the reason of the difference of 8 bytes?

 test.c

int foo();

int main()
{
  foo();
 return 0;
}

Corresponding assembly using gcc 4.0.1
 test.s ( sparc-gcc -S test.c -O3 )
.align 4
.global main
.type   main, #function
.proc   04
main:
save%sp, -104, %sp   ; why save 104 bytes
callfoo, 0
 mov0, %i0
jmp %i7+8
 restore
.size   main, .-main
.ident  "GCC: (GNU) 4.0.1

--


Any help will be appreciated.
Thanks,
Inder


Related to Optmization Options in GCC

2006-05-24 Thread Inder

Hi All,

From the GCC manual, its clear that optimization options from –O1 to
–O3 or any greater level emphasis On the performance while –Os
emphasis only on the code size, it (-Os) says nothing about the
performance (execution time).

In our case : Size in case of –Os is less than that in case of –O4
that is according to the
manual  but the performance is also better in –Os case. So, Can we
predict something like that the performance in case of –Os will always
be better than that is in –O4 or it is just undefined (Can be better
or worse)

Following is according to the manual:

-O2 :   GCC performs nearly all supported optimizations that do not
involve a space-speed tradeoff. Also it deos not  Perform
finline-functions, -funswitch-loops and -frename-registers options.
(which are basically for Function Inlining, loop unrolling and
register renaming)

-O3 [-O4]:Turns on all optimizations specified by -O2 + Function
Inlining, loop unrolling and register renaming

-Os :enables all -O2 optimizations that do not typically increase
code size and also performs further optimizations  designed to reduce
code size

Any help is greatly appreciated.

--
Thanks,
Inder