Is this a bug?

Is this a bug?

[Jay Monkman]

I'm trying to use linux-x86 hosted egcs-1.0.2 to compile code for a
PowerPC and think I found
and error in the code that is generated. The C code and the assembly
code that is generated is below.
For the second add (temp=base + (unsigned long)0x8000;) the compiler
seems to want to do a
signed addition even though all the variables are unsigned. When I try
compiling this with a x86
targeted version of the compiler everything seems ok. Has anyone else
seen this problem?

main()
{
  unsigned long base, temp;
  base=0x02800000;
//      lis 0,0x280		Load upper half of R0 with 0x0280 so 
//				  that R0 becomes 0x02800000
//	stw 0,8(31)		Store in local variable sec of stack
frame
//				  - variable name = base

  temp=base + (unsigned long)0x7fff;
//	lwz 0,8(31)		Load R0 with base
//	addic 9,0,32767		add 0x7fff
//	stw 9,12(31)		store as temp in stack frame

  temp=base + (unsigned long)0x8000;
//	lwz 9,8(31)		Load R9 with base
//	addis 11,9,0x1		add 0x10000 and store in R11 - why is
this instruction here?
//	addi 0,11,-32768	add 0x8000 and store in R0
//	stw 0,12(31)		store R0 as temp in stack frame

  
}

Re: Is this a bug?

[David Edelsohn]

>>>>> Jay Monkman writes:

Jay> For the second add (temp=base + (unsigned long)0x8000;) the compiler
Jay> seems to want to do a
Jay> signed addition even though all the variables are unsigned.

Jay> temp=base + (unsigned long)0x8000;
Jay> //	lwz 9,8(31)		Load R9 with base
Jay> //	addis 11,9,0x1		add 0x10000 and store in R11 - why is
Jay> this instruction here?
Jay> //	addi 0,11,-32768	add 0x8000 and store in R0
Jay> //	stw 0,12(31)		store R0 as temp in stack frame

	This is not a bug.  If you actually look at the results produced
on PowerPC, they are correct.  On PowerPC, additions by constants always
are signed, so GCC needs to compensate when performing an unsigned
addition by biasing the carry so that the result will be correct.

	You also should mention that GCC only produces this sequence of
instructions for this example when not optimizing.

David
===============================================================================
David Edelsohn                                      T.J. Watson Research Center
dje@watson.ibm.com                                  P.O. Box 218
+1 914 945 4364 (TL 862)                            Yorktown Heights, NY 10598

Re: Is this a bug?

[Richard Li]

It's not a bug. It conforms the C standard. C, unlike C++,
distinguishes functions ONLY by name, not by arguments.

C allows calling functions that are not declared by assuming they
return int. So GCC would assume that the prototype of "func" to be
"int func()" when compiling "main.c", and can generate a call to
"func", although it's defined in another file with a different
prototype. When the prototypes are different, the behavior is
undefined.
(Yes, this would be a link error in C++. But for C, it's the
programmer's responsibility to make sure arguments and return values
are passed correctly if you call undeclared functions. Therefore, it
is always encouraged that every function be declared before called,
even in C code.)


On 9/29/07, Zhang Xiaoping <gcc.compiler@gmail.com> wrote:
> two c files: main.c and func.c, excute the command like this:
>
> gcc main.c func.c -Wall -ansi -pedantic
>
> there are two warnings, and is can generate binary file and the file
> can be excuted.
>
> //main.c
>
> int main()
> {
>     int a;
>     a = func();
>     printf("%d\n", a);
>     return a;
> }
>
> //func.c
> float func(int a, int b)
> {
>     return (float)(a + b);
> }
>
> I assume it's a bug:  func in main funcion is different from the
> function in func.c
>
> My gcc version is gcc 3.2.2.
>
> May be not this version, i have forgotten.
>

Is this a bug?

[Zhang Xiaoping]

two c files: main.c and func.c, excute the command like this:

gcc main.c func.c -Wall -ansi -pedantic

there are two warnings, and is can generate binary file and the file
can be excuted.

//main.c

int main()
{
    int a;
    a = func();
    printf("%d\n", a);
    return a;
}

//func.c
float func(int a, int b)
{
    return (float)(a + b);
}

I assume it's a bug:  func in main funcion is different from the
function in func.c

My gcc version is gcc 3.2.2.

May be not this version, i have forgotten.

Re: Is this a bug?

[Jim Wilson]

Troy Simpson wrote:
> ./include/stddef.h:57:26: machine/ansi.h: No such file or directory

This is a NetBSD header file which does not exist on Solaris. 
Unfortunately, you haven't given enough info for me to understand what 
you are doing.

If you are trying to build a solaris compiler, then you may have 
configured wrong.  What configure command did you use?  Or maybe, used 
the wrong compiler sources.  You probably should not use netbsd gcc 
souces to build a solaris native compiler.

If you are trying to build a solaris hosted cross compiler to netbsd, 
then you probably configured wrong.  What configure command did you use? 
  In order to build a cross compiler, you will need the target netbsd 
headers are library files on the solaris host.  The easiest way to get 
this to work is to use the --with-sys-root configure option to point at 
the target libraries/headers.  See the docs.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Is this a bug?

[Troy Simpson]

I am compiling gcc 3.4.1 on Sun Solaris using NetBSD Packages Collection 
(pkgsrc) framework and I am getting the following Error Results.  It 
appears that the ansi.h header cannot be found.  I have searched my 
whole file system looking for it and I can't find it?

----------------------------------
In file included from 
/global/lunadg/d01/usr/pkgsrc/lang/gcc34/work/gcc-3.4.1-20040625/gcc/tsystem.h:44,
                  from 
/global/lunadg/d01/usr/pkgsrc/lang/gcc34/work/gcc-3.4.1-20040625/gcc/crtstuff.c:62:
./include/stddef.h:57:26: machine/ansi.h: No such file or directory
gmake[2]: *** [crtbegin.o] Error 1
gmake[2]: Leaving directory 
`/global/lunadg/d01/usr/pkgsrc/lang/gcc34/work/obj/gcc'
gmake[1]: *** [stage1_build] Error 2
gmake[1]: Leaving directory 
`/global/lunadg/d01/usr/pkgsrc/lang/gcc34/work/obj/gcc'
gmake: *** [bootstrap] Error 2
*** Error code 2

Stop.
bmake: stopped in /global/lunadg/d01/usr/pkgsrc/lang/gcc34
*** Error code 1

Stop.
bmake: stopped in /global/lunadg/d01/usr/pkgsrc/lang/gcc34
$
--------------------------------------

I found this message the appears to be the same problem I am having.
http://gcc.gnu.org/ml/gcc/2003-01/msg01408.html

Any ideas how to resolve this problem?

Thanks,
Troy

-- 
Troy Simpson
   Applications Analyst/Programmer, OCPDBA, MCSE, SCSA
North Carolina State University Libraries
Campus Box 7111 | Raleigh | North Carolina
ph.919.515.3855 | fax.919.513.3330
E-mail: Troy_Simpson@ncsu.edu

RE: Is this a bug?

[Jay Monkman]

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

David Edelsohn[SMTP:dje@watson.ibm.com] wrote:

> 	This is not a bug.  If you actually look at the results produced
> on PowerPC, they are correct.  On PowerPC, additions by constants
always
> are signed, so GCC needs to compensate when performing an unsigned
> addition by biasing the carry so that the result will be correct.

You're right. I wasn't looking closely enough at the results. Now I feel
stupid. Thank you very much
for the help.

[-- Attachment #2: bin00000.bin --]
[-- Type: application/vnd.ms-tnef, Size: 2228 bytes --]