[Bug target/19718] [3.3 Regression] longcall attributed doesn't work for standard C function names

2005-02-16 Thread jason at catapult dot com

--- Additional Comments From jason at catapult dot com  2005-02-16 22:39 
---
(In reply to comment #2)
> Does -fno-builtin cure the problem?  See also pr19746

Just tried it out now, and it does seem to fix the problem.  Unfortunately I
didn't know about fno-builtin at the time, so I just moved to 3.4.3 and resolved
the C++ issues.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19718


[Bug c/19718] New: longcall attributed doesn't work for standard C function names

2005-01-30 Thread jason at catapult dot com
I'm working on some code that has implemented functions with the same name as
standard C string functions (eg. sprintf, memcpy), and for some reason the
longcall attribute is being ignored by the assembler, according to the output
from objdumpppc.  This happens even though I'm not including the standard C
headers, and the preprocessed output only shows one function prototype.

The problem seems to have been fixed in 3.4.3, but due to issues with existing
C++ code I'm not sure if I can make the switch.  I can't find any bug report or
patch listed for this, apart from PR 12769.  Applying the patch described there
didn't fix this particular problem though.

-- 
   Summary: longcall attributed doesn't work for standard C function
names
   Product: gcc
   Version: 3.3.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: jason at catapult dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc-*-eabi


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19718


[Bug c/19718] longcall attributed doesn't work for standard C function names

2005-01-30 Thread jason at catapult dot com

--- Additional Comments From jason at catapult dot com  2005-01-31 04:19 
---
Created an attachment (id=8110)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8110&action=view)
A simple program with differently-named function prototypes

This program has function prototypes for the library functions sprintf, strlen,
bzero, and identical prototypes renamed sprintf2, strlen2, and bzero2.  Despite
the fact that all 6 prototypes use the longcall attribute (and there are no
conflicting duplicate prototypes from the std C headers), only the functiones
with the '2' suffix use long calls (check with 'objdumpppc -x longcalltest.o |
grep PPC).  

This works fine in 2.95.3, and 3.4.3, but not 3.3.5 (although taking another
look, strlen doesn't use a long call for any of the compilers, don't know why).

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19718


[Bug target/19746] New: printf() optimisation ignores longcall attribute

2005-02-01 Thread jason at catapult dot com
Using the -O flag, the longcall attribute is ignored by the compiler when
replacing printf() with puts(), even if a prototype for puts() exists with a
long call.  The test case below illustrates this.  

==
int printf(const char *format, ...) __attribute__ ((__longcall__)); 
int puts(const char *s) __attribute__ ((__longcall__));

int main(int argc, char* argv[])
{
   printf("Should be a long call\n"); 
   return 0;
}

==

At the moment I'm using -fno-builtin-printf as a workaround.

-- 
   Summary: printf() optimisation ignores longcall attribute
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: jason at catapult dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc-eabi


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19746


[Bug preprocessor/19836] New: -E -dD includes predefined macros

2005-02-08 Thread jason at catapult dot com
The -dD flag includes all the defined macros that -dM includes.  Unless I'm
mistaken in my understanding of a predefined macro, it shouldn't include the
ones defined in the std C headers.  This is the case for 3.4.3 and 3.3.5.  

===

~/misc> touch foo.h ; cpp -dD foo.h | sort > test2
~/misc> touch foo.h ; cpp -dM foo.h | sort > test1
~/misc> diff test1 test2
0a1,9
>
>
>
>
>
> # 1 ""
> # 1 ""
> # 1 "foo.h"
> # 1 "foo.h"
~/misc> 
~/misc> cat test1
#define __CHAR_BIT__ 8
#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
#define __DBL_DIG__ 15
#define __DBL_EPSILON__ 2.2204460492503131e-16
#define __DBL_HAS_INFINITY__ 1
#define __DBL_HAS_QUIET_NAN__ 1
#define __DBL_MANT_DIG__ 53
#define __DBL_MAX_10_EXP__ 308
#define __DBL_MAX__ 1.7976931348623157e+308
#define __DBL_MAX_EXP__ 1024
#define __DBL_MIN_10_EXP__ (-307)
#define __DBL_MIN__ 2.2250738585072014e-308
#define __DBL_MIN_EXP__ (-1021)
#define __DECIMAL_DIG__ 21
#define __ELF__ 1
#define __FINITE_MATH_ONLY__ 0
#define __FLT_DENORM_MIN__ 1.40129846e-45F
#define __FLT_DIG__ 6
#define __FLT_EPSILON__ 1.19209290e-7F
#define __FLT_EVAL_METHOD__ 2
#define __FLT_HAS_INFINITY__ 1
#define __FLT_HAS_QUIET_NAN__ 1
#define __FLT_MANT_DIG__ 24
#define __FLT_MAX_10_EXP__ 38
#define __FLT_MAX__ 3.40282347e+38F
#define __FLT_MAX_EXP__ 128
#define __FLT_MIN_10_EXP__ (-37)
#define __FLT_MIN__ 1.17549435e-38F
#define __FLT_MIN_EXP__ (-125)
#define __FLT_RADIX__ 2
#define __GNUC__ 3
#define __GNUC_MINOR__ 4
#define __GNUC_PATCHLEVEL__ 3
#define __gnu_linux__ 1
#define __GXX_ABI_VERSION 1002
#define __i386 1
#define __i386__ 1
#define i386 1
#define __INT_MAX__ 2147483647
#define __LDBL_DENORM_MIN__ 3.64519953188247460253e-4951L
#define __LDBL_DIG__ 18
#define __LDBL_EPSILON__ 1.08420217248550443401e-19L
#define __LDBL_HAS_INFINITY__ 1
#define __LDBL_HAS_QUIET_NAN__ 1
#define __LDBL_MANT_DIG__ 64
#define __LDBL_MAX_10_EXP__ 4932
#define __LDBL_MAX__ 1.18973149535723176502e+4932L
#define __LDBL_MAX_EXP__ 16384
#define __LDBL_MIN_10_EXP__ (-4931)
#define __LDBL_MIN__ 3.36210314311209350626e-4932L
#define __LDBL_MIN_EXP__ (-16381)
#define __linux 1
#define __linux__ 1
#define linux 1
#define __LONG_LONG_MAX__ 9223372036854775807LL
#define __LONG_MAX__ 2147483647L
#define __NO_INLINE__ 1
#define __PTRDIFF_TYPE__ int
#define __REGISTER_PREFIX__
#define __SCHAR_MAX__ 127
#define __SHRT_MAX__ 32767
#define __SIZE_TYPE__ unsigned int
#define __STDC_HOSTED__ 1
#define __tune_i686__ 1
#define __tune_pentiumpro__ 1
#define __unix 1
#define __unix__ 1
#define unix 1
#define __USER_LABEL_PREFIX__
#define __VERSION__ "3.4.3"
#define __WCHAR_MAX__ 2147483647
#define __WCHAR_TYPE__ long int
#define __WINT_TYPE__ unsigned int

-- 
   Summary: -E -dD includes predefined macros
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
     Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jason at catapult dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19836


[Bug preprocessor/19836] -E -dD includes predefined macros

2005-02-08 Thread jason at catapult dot com

--- Additional Comments From jason at catapult dot com  2005-02-09 06:27 
---
(In reply to comment #1)
> This is documented to do this so this is not a bug.

I thought -dD was supposed to NOT include predefined macros?

Jason


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19836


[Bug preprocessor/19836] -E -dD includes predefined macros

2005-02-09 Thread jason at catapult dot com

--- Additional Comments From jason at catapult dot com  2005-02-09 22:44 
---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > This is documented to do this so this is not a bug.
> > 
> > I thought -dD was supposed to NOT include predefined macros?
> This is what the documentation say:
> Tell the preprocessing to pass all macro definitions into the output, in their
proper sequence in the rest 
> of the output.
> 
> see the "all" there it really means all, even predefined ones.

Where did you read this?  This is what is written in the CPP and GCC manpages,
and the GCC online docs.

D - Like M except in two respects: it does not include the predefined macros,
and it outputs both the #define directives and the result of preprocessing. Both
kinds of output go to the standard output file. 

Neil, thanks for the suggestion, it removed all of them except for #define
__STDC_HOSTED__ 1, which I can take out with sed.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19836


[Bug preprocessor/19836] -E -dD includes predefined macros

2005-02-09 Thread jason at catapult dot com

--- Additional Comments From jason at catapult dot com  2005-02-09 23:50 
---
(In reply to comment #6)
> Subject: Re:  -E -dD includes predefined macros
> 
> jason at catapult dot com wrote:-
> 
> > Where did you read this?  This is what is written in the CPP and GCC 
> > manpages,
> > and the GCC online docs.
> > 
> > D - Like M except in two respects: it does not include the predefined 
> > macros,
> > and it outputs both the #define directives and the result of preprocessing. 
> > Both
> > kinds of output go to the standard output file. 
> > 
> > Neil, thanks for the suggestion, it removed all of them except for #define
> > __STDC_HOSTED__ 1, which I can take out with sed.
> 
> OK, so 2 bugs here then 8-)
> 

Maybe not.  The docs mention that "The standard predefined macros remain
defined.".  I guess it depend on what sort of predefined macro __STDC_HOSTED__ 
is.

Another problem with the -dD flag I've just found is that it includes the macros
predefined with the -D flag.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19836