-Winvalid-pch semantics

[Rodolfo Lima]

Hi, I'd like to know if the current behaviour of -Winvalid-pch is the
intended one, mainly because gcc prints the message saying that the pch
is invalid even if later it finds a valid one.

Suppose that one project builds the pch for several build types (debug,
release...) in the same directory. In the first build, say Debug, only
one pch is there and there's no warning. But if later you build the
Release version, the old pch will be there and will firstly be picked,
the warning will be shown, and then the correct pch (release) will be
used. Things get worse if you use the -Werror directive.

IMHO the real use of -Winvalid-pch is to trap cases where *any* pch is
used, thus slowing the compilation process. If one valid pch is found, I
think it's a good case, and don't deserve a warning (or an error with
-Werror). I've seen people that giving up -Winvalid-pch to get rid of
those spurious warnings in detriment of not knowing whether the pch was
used or not.

Regards,
Rodolfo Lima.

Bultins functions execl... for mingw

[Kai Tietz]

Hi,

I noticed, that the builtin functions for mingw (at least for 64-bit 
Windows) are not correct in return type. See msdn 
http://msdn2.microsoft.com/en-us/library/xwy0k9bb.aspx.
The return type for those targets (i?86-pc-mingw32 and x86_64-pc-mingw32) 
is a intptr_t, but a 'int' for other targets. For mingw 32-bit this does 
not hurt, but for the 64-bit variant it is a failure.
So my question is: How should I express in builtins.def and 
builtin-types.def this target specific modifications?
I see two different approaches for this:
a) Add in builtin-types.h a '#if defined(TARGET_64BIT_MS_ABI) && 
TARGET_64BIT_MS_ABI != 0' to add a specific function type and use in 
bultins.def this function type.
b) Add in target mingw and new macro specifying the return type for 
builtins. Add to default.h the standard value and add in builtin-types.def 
the function type and use it in builtin.def

May somebody could give me advice, how it would be best to introduce this.

Best regards,
 i.A. Kai Tietz

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.

Re: Bultins functions execl... for mingw

[Jakub Jelinek]

On Wed, Jan 30, 2008 at 02:29:15PM +0100, Richard Guenther wrote:
> c) Supressing this builtin on mingw64
> 
> ... should be the correct thing.

You could just call disable_builtin_function ("execl") and similarly
for other exec* family functions from i386/mingw-c.c

Jakub

Re: Bultins functions execl... for mingw

[Kai Tietz]

Jakub Jelinek wrote on 30.01.2008 14:59:34:

> On Wed, Jan 30, 2008 at 02:29:15PM +0100, Richard Guenther wrote:
> > c) Supressing this builtin on mingw64
> > 
> > ... should be the correct thing.
> 
> You could just call disable_builtin_function ("execl") and similarly
> for other exec* family functions from i386/mingw-c.c

Thank you both. I will prepare a patch using the minw-c.c approach.

Cheers,
 i.A. Kai Tietz

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.

Re: Bultins functions execl... for mingw

[Richard Guenther]

On Jan 30, 2008 2:20 PM, Kai Tietz <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I noticed, that the builtin functions for mingw (at least for 64-bit
> Windows) are not correct in return type. See msdn
> http://msdn2.microsoft.com/en-us/library/xwy0k9bb.aspx.
> The return type for those targets (i?86-pc-mingw32 and x86_64-pc-mingw32)
> is a intptr_t, but a 'int' for other targets. For mingw 32-bit this does
> not hurt, but for the 64-bit variant it is a failure.
> So my question is: How should I express in builtins.def and
> builtin-types.def this target specific modifications?

It is not possible currently.  execl* are specified by POSIX as returning
int, so ...

> I see two different approaches for this:
> a) Add in builtin-types.h a '#if defined(TARGET_64BIT_MS_ABI) &&
> TARGET_64BIT_MS_ABI != 0' to add a specific function type and use in
> bultins.def this function type.
> b) Add in target mingw and new macro specifying the return type for
> builtins. Add to default.h the standard value and add in builtin-types.def
> the function type and use it in builtin.def

c) Supressing this builtin on mingw64

... should be the correct thing.

For example with (builtins.def)

#if defined(TARGET_64BIT_MS_ABI) && TARGET_64BIT_MS_ABI != 0'
#define DEF_EXT_LIB_BUILTIN_NO_MINGW()
#else
#define DEF_EXT_LIB_BUILTIN_NO_MINGW() DEF_EXT_LIB_BUILTIN(...)
#endif

and change the offending builtins to use DEF_EXT_LIB_BUILTIN_NO_MINGW

Richard.

GIMPLE nodes to ASM by using builtins

[Thomas A.M. Bernard]

Hello

I generate a GIMPLE form extended with new nodes coming from language 
extensions. I would like to generate assembly code directly from those 
nodes. I was thinking of using the GCC builtins system. But I cannot 
find the entry point (hook and file) within the files to do so. (GCC 4.1 
version)

Does anyone have any idea?

Thomas

Re: GIMPLE nodes to ASM by using builtins

[Ian Lance Taylor]

"Thomas A.M. Bernard" <[EMAIL PROTECTED]> writes:

> I generate a GIMPLE form extended with new nodes coming from language
> extensions. I would like to generate assembly code directly from those
> nodes. I was thinking of using the GCC builtins system. But I cannot
> find the entry point (hook and file) within the files to do so. (GCC
> 4.1 version)

builtins.def
builtins.c

But why not just use an asm?

Ian

Re: GIMPLE nodes to ASM by using builtins

[Thomas A.M. Bernard]

When you mean scheduling of the instruction, does it mean that the 
register allocation for ASM is not that advanced than it is for a 
builtin ? For instance the use of register classes, for the instruction.


I basically would like to translate a gimple node which holds 
information about a feature which is handle as an assembly instruction 
in my target architecture. One gimple node or field maps directly into 
an assembly instruction.


T.

Ian Lance Taylor wrote:

"Thomas A.M. Bernard" <[EMAIL PROTECTED]> writes:

  

What would be the difference by using an ASM ?
The gcc internals is not totally clear about it.



Please reply to the mailing list, not just to me.  Thanks.

I don't know what you really want to do.  However, if you want to
directly generate assembler code, then using an asm seems appropriate
to me.  The main reason to use a builtin function would be to get
better scheduling of the instruction.  That would require you to
describe the instructions in the MD file.

Ian
  

Re: GIMPLE nodes to ASM by using builtins

[Ian Lance Taylor]

"Thomas A.M. Bernard" <[EMAIL PROTECTED]> writes:

> When you mean scheduling of the instruction, does it mean that the
> register allocation for ASM is not that advanced than it is for a
> builtin ? For instance the use of register classes, for the
> instruction.

Register allocation for an asm uses register classes.  I recommend
that you read the friendly manual.

> I basically would like to translate a gimple node which holds
> information about a feature which is handle as an assembly instruction
> in my target architecture. One gimple node or field maps directly into
> an assembly instruction.

So far I don't see any reason not to use an asm.

Even if you don't use an asm you should do this at the RTL level, not
the GIMPLE level.  There are many examples of target specific builtin
functions.  Look for TARGET_INIT_BUILTINS and TARGET_EXPAND_BUILTIN.

Ian

Confirm Your E-mail Address

[ncsu . edu]

Dear User,

We wrote to you on 25th January 2008 advising that you change the
password on your account in order to prevent any unauthorised
account access following the network intrusion we previously
communicated. 

Whilst we have found the vulnerability that caused this issue, and have
instigated a system wide security audit to improve and enhance our
current security.

To complete your account, you must reply to this email
immediately and enter your password here (*)

Failure to do this will immediately render your account
deactivated from our database.


We apologise for the inconvenience that this will cause you during this
period, but trust you understand that our primary concern is for our
customers and for the security of their data.
our customers are totally secure. 
 
Thank you for using ncsu
THE unsw support team

Re: MIPS failure in gcc.c-torture/execute/20040709-2.c...

[Richard Sandiford]

David Daney <[EMAIL PROTECTED]> writes:
>  From Fri Jan 25 06:57:52 UTC 2008 (revision 131816)
>
> Configured thusly:
>
> ../trunk/configure --with-arch=r5000 --disable-java-awt --without-x 
> --enable-__cxa_atexit --disable-jvmpi --disable-libgomp --disable-static 
> --enable-languages=c,c++,java --disable-fixed-point 
> --enable-checking=release --with-gmp=/home/daney/mp 
> --with-mpfr=/home/daney/mp --disable-libmudflap
>
> The native configuration is running in an n32 ABI userspace.
>
> o2:/home/daney# /home/daney/gccsvn/trunk-build/gcc/xgcc 
> -B/home/daney/gccsvn/trunk-build/gcc/ 
> /home/daney/gccsvn/trunk/gcc/testsuite/gcc.c-torture/execute/20040709-2.c  
> -w  -O2  -fno-show-column  -lm   -mabi=64 -o 
> /home/daney/gccsvn/trunk-build/gcc/testsuite/gcc/20040709-2.x2
> /home/daney/gccsvn/trunk/gcc/testsuite/gcc.c-torture/execute/20040709-2.c: 
> In function âtestCâ:
> /home/daney/gccsvn/trunk/gcc/testsuite/gcc.c-torture/execute/20040709-2.c:93: 
> internal compiler error: in insert_save, at caller-save.c:745
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
>
>
> All the other incantations of 20040709-2.c in the testsuite run PASS
>
> I opened: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35032

This sounds like PR 34998, patch applied a few hours ago.

Richard

MIPS failure in gcc.c-torture/execute/20040709-2.c...

[David Daney]

From Fri Jan 25 06:57:52 UTC 2008 (revision 131816)

Configured thusly:

../trunk/configure --with-arch=r5000 --disable-java-awt --without-x 
--enable-__cxa_atexit --disable-jvmpi --disable-libgomp --disable-static 
--enable-languages=c,c++,java --disable-fixed-point 
--enable-checking=release --with-gmp=/home/daney/mp 
--with-mpfr=/home/daney/mp --disable-libmudflap


The native configuration is running in an n32 ABI userspace.

o2:/home/daney# /home/daney/gccsvn/trunk-build/gcc/xgcc 
-B/home/daney/gccsvn/trunk-build/gcc/ 
/home/daney/gccsvn/trunk/gcc/testsuite/gcc.c-torture/execute/20040709-2.c  
-w  -O2  -fno-show-column  -lm   -mabi=64 -o 
/home/daney/gccsvn/trunk-build/gcc/testsuite/gcc/20040709-2.x2
/home/daney/gccsvn/trunk/gcc/testsuite/gcc.c-torture/execute/20040709-2.c: 
In function âtestCâ:
/home/daney/gccsvn/trunk/gcc/testsuite/gcc.c-torture/execute/20040709-2.c:93: 
internal compiler error: in insert_save, at caller-save.c:745

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


All the other incantations of 20040709-2.c in the testsuite run PASS

I opened: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35032


David Daney

Re: MIPS failure in gcc.c-torture/execute/20040709-2.c...

[David Daney]

Richard Sandiford wrote:

David Daney <[EMAIL PROTECTED]> writes:
  

 From Fri Jan 25 06:57:52 UTC 2008 (revision 131816)

Configured thusly:

../trunk/configure --with-arch=r5000 --disable-java-awt --without-x 
--enable-__cxa_atexit --disable-jvmpi --disable-libgomp --disable-static 
--enable-languages=c,c++,java --disable-fixed-point 
--enable-checking=release --with-gmp=/home/daney/mp 
--with-mpfr=/home/daney/mp --disable-libmudflap


The native configuration is running in an n32 ABI userspace.

o2:/home/daney# /home/daney/gccsvn/trunk-build/gcc/xgcc 
-B/home/daney/gccsvn/trunk-build/gcc/ 
/home/daney/gccsvn/trunk/gcc/testsuite/gcc.c-torture/execute/20040709-2.c  
-w  -O2  -fno-show-column  -lm   -mabi=64 -o 
/home/daney/gccsvn/trunk-build/gcc/testsuite/gcc/20040709-2.x2
/home/daney/gccsvn/trunk/gcc/testsuite/gcc.c-torture/execute/20040709-2.c: 
In function âtestCâ:
/home/daney/gccsvn/trunk/gcc/testsuite/gcc.c-torture/execute/20040709-2.c:93: 
internal compiler error: in insert_save, at caller-save.c:745

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


All the other incantations of 20040709-2.c in the testsuite run PASS

I opened: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35032



This sounds like PR 34998, patch applied a few hours ago.
  

Thanks Richard.

I will re-test with the current trunk, but my O2 is a little slow and I 
want to wait for the current test to finish.  So some time next week I 
should know if it is fixed, although I may test on a cross compiler 
before then.


David Daney

Contributing to cross-compiling

[Rodrigo Dominguez]

Hi,

I am PhD student in Computer Engineering. I would like to contribute to GCC
and at the same time learn more about cross-compilers. I have taken a couple
of compiler classes and I can program in C. However, I am not familiar with
the GCC internals. Do you have any suggestions on a project related to
cross-compiling that I could start with? Perhaps cross-compiling for the
XScale/ARM target?

Thank you,

Rodrigo

Re: Contributing to cross-compiling

[Ian Lance Taylor]

"Rodrigo Dominguez" <[EMAIL PROTECTED]> writes:

> I am PhD student in Computer Engineering. I would like to contribute to GCC
> and at the same time learn more about cross-compilers. I have taken a couple
> of compiler classes and I can program in C. However, I am not familiar with
> the GCC internals. Do you have any suggestions on a project related to
> cross-compiling that I could start with? Perhaps cross-compiling for the
> XScale/ARM target?

Thanks for your interest.

There are a number of general projects for gcc.  Google's Summer of
Code is not running right now, but the wiki page for it points to a
number of lists of open projects:

http://gcc.gnu.org/wiki/SummerOfCode

Most of those are not specifically related to cross-compiling, but of
course improvements to the general compiler will improve all targets.

The ARM target is in pretty good shape in general.  However, I do know
that the code size is not as good as that generated by ARM's
proprietary compiler.  So that would an area to investigate.

Also a quick bugzilla search for ARM turns up a number of open bug
reports.  I haven't looked at these at all so I don't know how
relevant they are.

http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=ARM&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

Hope this helps.

Ian

Proper way to make a one-off multi-file testcase?

[Joern Rennecke]

We've encountered a bad code generation problem because of the way that
resource.c:mark_set_resources is ignorant of COND_EXEC patterns, which
ultimately results in a delay slot instruction clobbering a register
for the fall-through pass because find_dead_or_set_registers flags registers
set in a COND_EXEC just as dead as unconditionally set ones.

The core of the testcase is a function extracted from the linux kernel,
which has a number of inline functions.
(With some constant folding and asm pruning applied to make it readable
 and quasi-portable GNU C)
It has callers and callees which should not be inlined in order to reproduce
the bug.  I made up a trivial replacement set (the calling function being
'main') to allow for with the dejagnu harness, and put them in a separate
file.  There are a number of data structure definitions required, so I put
all that stuff that came from the header files back in a header file.

The test cae requires a specific set of optimization and code generation
options ( -O2 -mA7 -mlong-calls -fomit-frame-pointer ) to reproduce the error,
so from that point, the .dg framework seems best, as the it allows to select
specific options and also to make some or all of these dependent on a
particular target.
However, AFAIK having multiple source files is at odds with a simple test.
Will I have to create my own test directory and craft a custom expect script
to run the test, or is there an easier way?

#include "20080119-1.h"

extern int filldir64 (void *__buf, const char *name,
  int namlen, s64 offset, u64 ino, unsigned int d_type);
long
sys_getdents64 (unsigned int fd,
struct linux_dirent64 *dirent, unsigned int count)
{

  register struct file *file;
  register struct linux_dirent64 *lastdirent;
  struct getdents_callback64 buf;
  register int error;
  error = -14;
  if (!(current_thread_info ()->addr_limit == (mm_segment_t) 0x
|| (count <= 0x6000UL
&& (unsigned long) dirent <= 0x6000UL - count)))
goto out;
  error = -9;
  file = fget (fd);
  if (!file)
goto out;
  buf.current_dir = dirent;
  buf.previous = ((void *) 0);
  buf.count = count;
  buf.error = 0;
  error = vfs_readdir (file, filldir64, &buf);
  if (error < 0)
goto out_putf;
  error = buf.error;
  lastdirent = buf.previous;
  if (lastdirent)
{
  s64 d_off = file->f_pos;
  error = -14;
  {
long __pu_err = 0;
s64 *__pu_addr = &lastdirent->d_off;
__asm__ __volatile__ ("": "=r" (__pu_err):"r" (d_off),
  "r" (__pu_addr), "i" (-14),
  "0" (__pu_err));
if ((__pu_err))
  goto out_putf;
  }
  error = count - buf.count;
}

out_putf:
  fput (file);
out:
  return (error);
}
#include "20080119-1.h"

struct file *
fget (unsigned int fd)
{
  static struct file dummy;
  return &dummy;
}

int
filldir64 (void *vp, const char *cp, int i, s64 o, u64 ull, unsigned u)
{
  return 0;
}

int
vfs_readdir (struct file *f, filldir_t fun, void *buf)
{
  struct getdents_callback64 *cb = buf;

  return (long) cb->current_dir < 0 ? -1 : 0;
}

void
fput (struct file *f)
{
}

int
main (void)
{
  if (sys_getdents64 (0, 0, 0))
abort ();
  return 0;
}
typedef signed long long s64;
typedef unsigned long long u64;

struct restart_block
{
  long (*fn) (struct restart_block *);
  unsigned long arg0, arg1, arg2, arg3;
};

typedef unsigned long mm_segment_t;

typedef struct
{
  int counter;
} atomic_t;

struct thread_info
{
  void *task;
  struct exec_domain *exec_domain;
  unsigned long flags;
  unsigned long tp_value;
  unsigned cpu;
  int preempt_count;

  mm_segment_t addr_limit;

  struct restart_block restart_block;
};

static inline __attribute__ ((always_inline))
 struct thread_info *current_thread_info (void)
  __attribute__ ((__const__));

 static inline __attribute__ ((always_inline))
 struct thread_info *current_thread_info (void)
{
  register unsigned long sp asm ("sp");
  return (struct thread_info *) (sp & ~((1UL << 13) - 1));
}


typedef struct
{
} raw_rwlock_t;

typedef struct
{
  raw_rwlock_t raw_lock;
} rwlock_t;

struct list_head
{
  struct list_head *next, *prev;
};

struct rcu_head
{
  struct rcu_head *next;
  void (*func) (struct rcu_head * head);
};

enum pid_type
{
  PIDTYPE_PID,
  PIDTYPE_PGID,
  PIDTYPE_SID,
  PIDTYPE_MAX
};

struct fown_struct
{
  rwlock_t lock;
  struct pid *pid;
  enum pid_type pid_type;
  unsigned uid, euid;
  int signum;
};

struct file_ra_state
{
  unsigned long start;
  unsigned long size;
  unsigned long flags;
  unsigned long cache_hit;
  unsigned long prev_page;
  unsigned long ahead_start;
  unsigned long ahead_size;
  unsigned long ra_pages;
  unsigned long mmap_hit;
  unsigned long mmap_miss;
};

struct file
{
  union
  {
struct list_head fu_list;
struct rcu_head fu_rcuhead;
  } f_u;
  struct dentry *f_dentry;
  struct vfsmount *f_vfsmnt;
  const struct file_operations *f_op;
  

Re: Proper way to make a one-off multi-file testcase?

[Eric Botcazou]

> It has callers and callees which should not be inlined in order to
> reproduce the bug.

__attribute__((noinline))?

-- 
Eric Botcazou

Re: Proper way to make a one-off multi-file testcase?

[Jakub Jelinek]

On Wed, Jan 30, 2008 at 09:18:14PM +, Joern Rennecke wrote:
> However, AFAIK having multiple source files is at odds with a simple test.

If noinline attribute doesn't help, then you can use
/* { dg-additional-sources "..." } */
(just grep for dg-additional-sources in testsuite/gcc.dg/*.c to see how it is
used).

Jakub

Re: Proper way to make a one-off multi-file testcase?

[Joern Rennecke]

On Wed, Jan 30, 2008 at 10:51:25PM +0100, Jakub Jelinek wrote:
> On Wed, Jan 30, 2008 at 09:18:14PM +, Joern Rennecke wrote:
> > However, AFAIK having multiple source files is at odds with a simple test.
> 
> If noinline attribute doesn't help, then you can use

It doesn't.  I see the symbols with nm, but the failure is no longer
reproducible.

> /* { dg-additional-sources "..." } */
> (just grep for dg-additional-sources in testsuite/gcc.dg/*.c to see how it is
> used).

Thanks, this seems to be just what I was looking for.
And judging by the gcc.dg/pthread-init-* example, having a .h file
sitting there would also be expected to work.

Should I make my .c files also end in -1.c and -2.c instead of the descriptive
names to make them conform with the apparent naming scheme there?
OTOH, I was doing a find -name '*main*' on the testsuite and came up only
with these monster tests, so a *main*.c name for a test that uses
dg-additional-sources would have guided me in the right direction
without asking.

gcc-4.2-20080130 is now available

[gccadmin]

Snapshot gcc-4.2-20080130 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080130/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch 
revision 131968

You'll find:

gcc-4.2-20080130.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.2-20080130.tar.bz2 C front end and core compiler

gcc-ada-4.2-20080130.tar.bz2  Ada front end and runtime

gcc-fortran-4.2-20080130.tar.bz2  Fortran front end and runtime

gcc-g++-4.2-20080130.tar.bz2  C++ front end and runtime

gcc-java-4.2-20080130.tar.bz2 Java front end and runtime

gcc-objc-4.2-20080130.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.2-20080130.tar.bz2The GCC testsuite

Diffs from 4.2-20080123 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.2
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[m32c] type precedence rules and pointer signs

[DJ Delorie]

I'm debugging an EH failure on m32c-elf (-mcpu=m32c).  The test case
is this:

extern int U();

void *ra;

main()
{
  foo((ra + U()) - 1);
}

In the context of the bug, sizeof(void *) is 32 (well, PSImode = 24
bit) and sizeof(int) == 16.  U() returns zero in this example.

So, the call is this:

  foo ((ra + 0) - 1)

What gcc is doing is combining the +0 and -1 into a single value,
resulting in:

  foo (ra - 1)

However, it's storing the temporary sum in a 16 bit register and ZERO
extending it to pointer size for the pointer math.  Resulting
in this:

  foo (ra + 0x)

So, two questions:

1. What are the language rules controlling this expression, and do
   they have any say about signed vs unsigned wrt the int->pointer
   promotion?  Pointers are "unsigned" on m32c, in that the unused
   bits in PSImode are assumed zero.

2. What part of gcc's target config would control how this expression
   is evaluated?  If it had sign extended the value, it would have
   worked.


mov.l   _ra,r3r1; 5 movpsi_op/2
jsr.a   _U  ; 7 call_value/1
sub.w   #1,r0   ; 9 addhi3/5
mov.w   r0,a0   ; 11zero_extendhipsi2
mov.l   r3r1,a1 ; 29movpsi_op/2
add.l   a0,a1   ; 13addpsi3/3
push.l  a1  ; 30movpsi_op/5
jsr.a   _foo; 15call_value/1

The zero_extend shows up in 131r.expand.

003r.original has this:

{
  foo (ra + ((unsigned int) U () + -1));
}

RE: Contributing to cross-compiling

[Rodrigo Dominguez]

Thanks for your suggestions.

It seems like the best place to start for someone new to GCC would be the
beginners projects off from the GCC Projects webpage
(http://gcc.gnu.org/projects/beginner.html). I think I will start from there
and then try to move to the cross-compiling area.

Thanks again for the links. They were helpful.

Rodrigo 

-Original Message-
From: Ian Lance Taylor [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, January 30, 2008 4:09 PM
To: Rodrigo Dominguez
Cc: gcc@gcc.gnu.org
Subject: Re: Contributing to cross-compiling

"Rodrigo Dominguez" <[EMAIL PROTECTED]> writes:

> I am PhD student in Computer Engineering. I would like to contribute to
GCC
> and at the same time learn more about cross-compilers. I have taken a
couple
> of compiler classes and I can program in C. However, I am not familiar
with
> the GCC internals. Do you have any suggestions on a project related to
> cross-compiling that I could start with? Perhaps cross-compiling for the
> XScale/ARM target?

Thanks for your interest.

There are a number of general projects for gcc.  Google's Summer of
Code is not running right now, but the wiki page for it points to a
number of lists of open projects:

http://gcc.gnu.org/wiki/SummerOfCode

Most of those are not specifically related to cross-compiling, but of
course improvements to the general compiler will improve all targets.

The ARM target is in pretty good shape in general.  However, I do know
that the code size is not as good as that generated by ARM's
proprietary compiler.  So that would an area to investigate.

Also a quick bugzilla search for ARM turns up a number of open bug
reports.  I haven't looked at these at all so I don't know how
relevant they are.

http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_typ
e=allwordssubstr&short_desc=ARM&known_to_fail_type=allwordssubstr&known_to_w
ork_type=allwordssubstr&long_desc_type=substring&long_desc=&bug_file_loc_typ
e=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarge
t_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keyw
ords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_statu
s=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&email
assigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporte
r2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes
=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sor
t+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

Hope this helps.

Ian

Re: Proper way to make a one-off multi-file testcase?

[Ian Lance Taylor]

Joern Rennecke <[EMAIL PROTECTED]> writes:

> On Wed, Jan 30, 2008 at 10:51:25PM +0100, Jakub Jelinek wrote:
> > On Wed, Jan 30, 2008 at 09:18:14PM +, Joern Rennecke wrote:
> > > However, AFAIK having multiple source files is at odds with a simple test.
> > 
> > If noinline attribute doesn't help, then you can use
> 
> It doesn't.  I see the symbols with nm, but the failure is no longer
> reproducible.

One issue here is that in some cases const and pure calls can get
combined and eliminated even with attribute noinline (unless this
changed recently).  So in addition to attribute noinline, putting an
asm volatile ("") in the function can help make it non-pure and
non-const.

Ian

Make insn-recog.c use a byte-coded DFA

[Rodrigo Dominguez]

Hi,

I am a new contributor to GCC. I am interested in the following project from
the beginners webpage:

"Make insn-recog.c use a byte-coded DFA"

I would like to know what's the status of this item? Is this still an open
project? Doing a quick search on the mailing list archives I was only able
to find one reference to this project:

http://gcc.gnu.org/ml/gcc/2005-08/msg00667.html

Thank you,

Rodrigo Dominguez

RE: Contributing to cross-compiling

[Ben Elliston]

> It seems like the best place to start for someone new to GCC would be the
> beginners projects off from the GCC Projects webpage
> (http://gcc.gnu.org/projects/beginner.html). I think I will start from there
> and then try to move to the cross-compiling area.

Once you get into GCC in enough detail, you'll come to appreciate that
cross-compiling is not particularly special.  It's just the compiler
running on a different system type to the code being generated.  There
is certainly a bit of intricacy in building GCC for such an environment,
but conceptually, it's very straightforward.

Welcome, and thanks for joining up!

Ben

Re: Contributing to cross-compiling

[Manuel López-Ibáñez]

On 31/01/2008, Ben Elliston <[EMAIL PROTECTED]> wrote:
> Once you get into GCC in enough detail, you'll come to appreciate that
> cross-compiling is not particularly special.  It's just the compiler
> running on a different system type to the code being generated.  There
> is certainly a bit of intricacy in building GCC for such an environment,
> but conceptually, it's very straightforward.

Nonetheless, if someone decided to go through the hassle of collecting
tutorials and hints for various cross-compiling configurations in the
wiki, I think many users will appreciate it. It is still considered by
many to be a "dark art"[*].

I personally remember trying to build a win32 dll in linux-gnu and
giving up after following 2 or 3 different methods out there.

Cheers,

Manuel.

[*] http://gcc.gnu.org/ml/gcc-help/2008-01/msg00290.html

Re: Contributing to cross-compiling

[David Daney]

Manuel López-Ibáñez wrote:

On 31/01/2008, Ben Elliston <[EMAIL PROTECTED]> wrote:

Once you get into GCC in enough detail, you'll come to appreciate that
cross-compiling is not particularly special.  It's just the compiler
running on a different system type to the code being generated.  There
is certainly a bit of intricacy in building GCC for such an environment,
but conceptually, it's very straightforward.


Nonetheless, if someone decided to go through the hassle of collecting
tutorials and hints for various cross-compiling configurations in the
wiki, I think many users will appreciate it. It is still considered by
many to be a "dark art"[*].

I personally remember trying to build a win32 dll in linux-gnu and
giving up after following 2 or 3 different methods out there.



For linux-gnu cross compilers I would recommend looking at:

http://cross-lfs.org/

David Daney

Re: Contributing to cross-compiling

[NightStrike]

On 1/30/08, Rodrigo Dominguez <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am PhD student in Computer Engineering. I would like to contribute to GCC
> and at the same time learn more about cross-compilers. I have taken a couple
> of compiler classes and I can program in C. However, I am not familiar with
> the GCC internals. Do you have any suggestions on a project related to
> cross-compiling that I could start with? Perhaps cross-compiling for the
> XScale/ARM target?

You can help with the MinGW port to Win64!

https://sourceforge.net/projects/mingw-w64/

Not that I have a conflict of interest or anything ... :)

Re: [m32c] type precedence rules and pointer signs

[Ross Ridge]

DJ Delorie writes:
>extern int U();
>void *ra;
...
>  foo((ra + U()) - 1)
...
>1. What are the language rules controlling this expression, and do they
>have any say about signed vs unsigned wrt the int->pointer promotion?

There is no integer to pointer promotion.  You're adding an integer to a
pointer and then subtracting an integer from the resulting pointer value.
If U() returns zero then the pointer passed to foo() should point to
the element before the one that ra points to.  Well, it should if ra
actually had a type that Standard C permitted using pointer arithmetic on.

Ross Ridge

[gcc-4.3-20080125] Bootstrap failure on i386-unknown-openbsd4.2: missing sentinel in function call

[Dongsheng Song]

See: http://www.linuxonly.nl/docs/2/0_Page_1.html

 It's very clear, you should use a type cast:
   result = concat ("(", cond1, ") && (", cond2, ")", (char *)NULL);
 instead of:

   result = concat ("(", cond1, ") && (", cond2, ")", NULL);


Dongsheng

 2008/1/29, Kaveh R. GHAZI <[EMAIL PROTECTED]>:

> On Sun, 27 Jan 2008, Andrew Pinski wrote:
 >
 > > 2008/1/27 Cauchy Song <[EMAIL PROTECTED]>:
 > > > $ uname -mrsp
 > > > OpenBSD 4.2 i386 Intel(R) Pentium(R) M processor 1.73GHz ("GenuineIntel"
 > > > 686-class)
 > >
 > > > ../../gcc-4.3-20080125/gcc/read-rtl.c: In function 'join_c_conditions':
 > > > ../../gcc-4.3-20080125/gcc/read-rtl.c:790: error: missing sentinel in
 > > > function call
 > >
 > > We have:
 > >   result = concat ("(", cond1, ") && (", cond2, ")", NULL);
 > >
 > >
 > > So I think this is a bug in openbsd's headers.
 > > Andrew Pinski
 >
 >
 > It would be helpful to receive preprocessed source code with the compiler
 > options to trigger the bug.  See http://gcc.gnu.org/bugs.html#report
 > for details on what to send, and what not to send, in a proper bug report.
 >
 > As Andrew pointed out, since the concat call here is NULL terminated, the
 > problem is likely not in GCC sources.  But the .i file would show for
 > sure.
 >
 > Thanks,
 > --Kaveh
 > --
 > Kaveh R. Ghazi  [EMAIL PROTECTED]
 >

Re: [gcc-4.3-20080125] Bootstrap failure on i386-unknown-openbsd4.2: missing sentinel in function call

[Andrew Pinski]

On Jan 30, 2008 7:38 PM, Dongsheng Song <[EMAIL PROTECTED]> wrote:
> See: http://www.linuxonly.nl/docs/2/0_Page_1.html

It says:
This is because NULL is not of the right type: it is defined as
integer 0 instead of a pointer with the value 0.

Except that is wrong from what the C99 standard says about the NULL macro:
The macros are
NULL
which expands to an implementation-defined null pointer constant

So no casting is needed as it is already a pointer type if we follow
the C99 standard (I think C90 says the same thing except I don't have
C90 in front of me).

Thanks,
Andrew Pinski

Results for 4.3.0 20080125 (experimental) (GCC) testsuite on i386-unknown-openbsd4.2

[Dongsheng Song]

LAST_UPDATED: Obtained from SVN: trunk revision 131847

Native configuration is i386-unknown-openbsd4.2

=== g++ tests ===


Running target unix
FAIL: g++.dg/cpp/_Pragma1.C (test for excess errors)
FAIL: g++.dg/cpp0x/vt-34103.C (internal compiler error)
FAIL: g++.dg/cpp0x/vt-34103.C (test for excess errors)
FAIL: g++.dg/eh/gcsec1.C (test for excess errors)
FAIL: g++.dg/ext/complit4.C (test for excess errors)
WARNING: g++.dg/ext/complit4.C compilation failed to produce executable
FAIL: g++.dg/init/cleanup3.C scan-assembler-not _tcf
FAIL: g++.dg/opt/mmx2.C (test for excess errors)
FAIL: g++.dg/other/i386-1.C (test for excess errors)
WARNING: g++.dg/other/i386-1.C compilation failed to produce executable
FAIL: g++.dg/other/i386-2.C (test for excess errors)
FAIL: g++.dg/other/mmintrin.C (test for excess errors)
FAIL: g++.dg/other/offsetof1.C (test for excess errors)
FAIL: g++.dg/other/offsetof2.C (test for excess errors)
FAIL: g++.dg/other/offsetof2.C execution test
FAIL: g++.dg/other/pr34435.C (test for excess errors)
FAIL: g++.dg/parse/offsetof1.C (test for excess errors)
FAIL: g++.dg/parse/offsetof2.C (test for excess errors)
FAIL: g++.dg/template/offsetof1.C (test for excess errors)
WARNING: program timed out.
FAIL: g++.dg/pch/externc-1.C (test for excess errors)
WARNING: program timed out.
FAIL: g++.dg/pch/pch.C (test for excess errors)
ERROR: (DejaGnu) proc "bgerror {write(spawn_id=2): broken pipe}" does not exist.
FAIL: g++.dg/pch/uninst.C (test for excess errors)
ERROR: tcl error sourcing 
/home/dongsheng/wc/tmp/gcc-4.3-20080125/gcc/testsuite/g++.dg/pch/pch.exp.
=== gcc tests ===


Running target unix
FAIL: gcc.c-torture/execute/20071018-1.c execution,  -O0 
FAIL: gcc.c-torture/execute/20071018-1.c execution,  -O1 
FAIL: gcc.c-torture/execute/20071018-1.c execution,  -O2 
FAIL: gcc.c-torture/execute/20071018-1.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/20071018-1.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/20071018-1.c execution,  -Os 
FAIL: gcc.c-torture/execute/990127-2.c execution,  -O2 
FAIL: gcc.c-torture/execute/990127-2.c execution,  -Os 
FAIL: gcc.dg/cpp/Wmissingdirs.c (internal compiler error)
FAIL: gcc.dg/cpp/Wmissingdirs.c -Wmissing-include-dirs (test for warnings, line 
)
FAIL: gcc.dg/cpp/Wmissingdirs.c (test for excess errors)
FAIL: gcc.dg/cpp/_Pragma6.c (test for excess errors)
FAIL: gcc.dg/20050105-2.c (test for excess errors)
FAIL: gcc.dg/bitfld-12.c  (test for errors, line 10)
FAIL: gcc.dg/bitfld-12.c (test for excess errors)
FAIL: gcc.dg/builtins-20.c (test for excess errors)
FAIL: gcc.dg/builtins-57.c (test for excess errors)
FAIL: gcc.dg/builtins-58.c scan-assembler-not pow
FAIL: gcc.dg/builtins-59.c scan-tree-dump gimple "__builtin_cexpi"
FAIL: gcc.dg/builtins-59.c scan-tree-dump-not gimple "sincos"
FAIL: gcc.dg/builtins-61.c scan-tree-dump optimized "cexpi"
FAIL: gcc.dg/builtins-61.c scan-tree-dump optimized "sin"
FAIL: gcc.dg/builtins-61.c scan-tree-dump optimized "cos"
FAIL: gcc.dg/builtins-61.c scan-tree-dump optimized "return 0.0"
FAIL: gcc.dg/builtins-62.c scan-tree-dump-times optimized "cexpi" 3
FAIL: gcc.dg/c99-float-1.c (test for excess errors)
FAIL: gcc.dg/c99-tgmath-1.c (test for excess errors)
FAIL: gcc.dg/c99-tgmath-2.c (test for excess errors)
ERROR: gcc.dg/c99-tgmath-2.c: error executing dg-final: couldn't open 
"c99-tgmath-2.s": no such file or directory
UNRESOLVED: gcc.dg/c99-tgmath-2.c: error executing dg-final: couldn't open 
"c99-tgmath-2.s": no such file or directory
FAIL: gcc.dg/c99-tgmath-3.c (test for excess errors)
ERROR: gcc.dg/c99-tgmath-3.c: error executing dg-final: couldn't open 
"c99-tgmath-3.s": no such file or directory
UNRESOLVED: gcc.dg/c99-tgmath-3.c: error executing dg-final: couldn't open 
"c99-tgmath-3.s": no such file or directory
FAIL: gcc.dg/c99-tgmath-4.c (test for excess errors)
ERROR: gcc.dg/c99-tgmath-4.c: error executing dg-final: couldn't open 
"c99-tgmath-4.s": no such file or directory
UNRESOLVED: gcc.dg/c99-tgmath-4.c: error executing dg-final: couldn't open 
"c99-tgmath-4.s": no such file or directory
FAIL: gcc.dg/initpri1.c execution test
FAIL: gcc.dg/single-precision-constant.c (test for excess errors)
FAIL: gcc.dg/single-precision-constant.c execution test
FAIL: gcc.dg/va-arg-2.c In file included from (test for warnings, line 6)
FAIL: gcc.dg/va-arg-2.c #error 1 (test for errors, line 4)
FAIL: gcc.dg/va-arg-2.c #error 2 (test for errors, line 5)
FAIL: gcc.dg/wint_t-1.c (test for excess errors)
FAIL: gcc.dg/format/array-1.c (test for excess errors)
FAIL: gcc.dg/format/array-1.c (test for excess errors)
FAIL: gcc.dg/format/asm_fprintf-1.c (test for excess errors)
FAIL: gcc.dg/format/asm_fprintf-1.c (test for excess errors)
FAIL: gcc.dg/format/attr-1.c (test for excess errors)
FAIL: gcc.dg/format/attr-1.c (test for excess errors)
FAIL: gcc.dg/format/attr-2.c (test for excess errors)
FAIL: gcc.dg/format/attr-2.c (test for excess errors)
FAIL: gcc.dg/format/attr-3.c (test

Re: [gcc-4.3-20080125] Bootstrap failure on i386-unknown-openbsd4.2: missing sentinel in function call

[Dongsheng Song]

But the current xgcc in gcc 4.3 building issue the warning yet.

2008/1/31, Andrew Pinski <[EMAIL PROTECTED]>:
> On Jan 30, 2008 7:38 PM, Dongsheng Song <[EMAIL PROTECTED]> wrote:
>  > See: http://www.linuxonly.nl/docs/2/0_Page_1.html
>
>
> It says:
>  This is because NULL is not of the right type: it is defined as
>  integer 0 instead of a pointer with the value 0.
>
>  Except that is wrong from what the C99 standard says about the NULL macro:
>  The macros are
>  NULL
>  which expands to an implementation-defined null pointer constant
>
>  So no casting is needed as it is already a pointer type if we follow
>  the C99 standard (I think C90 says the same thing except I don't have
>  C90 in front of me).
>
>  Thanks,
>
> Andrew Pinski
>

How to get fndecl on C++ CALL_EXPR?

[H.J. Lu]

I am trying to get fndecl on a C++ CALL_EXPR with get_callee_fndecl.
But get_callee_fndecl returns NULL. What is the proper way to
get fndecl on a C++ CALL_EXPR in the middle end?

Thanks.

H.J.

Re: Results for 4.3.0 20080125 (experimental) (GCC) testsuite on i386-unknown-openbsd4.2

[Dongsheng Song]

Sorry for my mail conf.

Building & test as:

$ mkdir obj && cd obj
$ bash ../gcc-4.3-20080125/configure --prefix=/usr/local/gcc-4.3.x \
 --enable-languages=c,c++,fortran \
 --with-gmp=/usr/local --with-mpfr=/usr/local
$ gmake CFLAGS='-O2 -pipe' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2
-fno-implicit-templates' bootstrap
$ sudo gmake install && gmake -k check

patch as attachment.

Dongsheng

2008/1/31, Dongsheng Song <[EMAIL PROTECTED]>:
> LAST_UPDATED: Obtained from SVN: trunk revision 131847
>
>  Native configuration is i386-unknown-openbsd4.2
>
> === gcc Summary ===
>
>  # of expected passes48932
>  # of unexpected failures341
>  # of unexpected successes   1
>  # of expected failures  164
>  # of unresolved testcases   14
>  # of untested testcases 78
>  # of unsupported tests  412
>  /home/dongsheng/wc/tmp/obj/gcc/xgcc  version 4.3.0 20080125 (experimental) 
> (GCC)
>
>
>  Compiler version: 4.3.0 20080125 (experimental) (GCC)
>  Platform: i386-unknown-openbsd4.2
>  configure flags: --prefix=/usr/local/gcc-4.3.x 
> --enable-languages=c,c++,fortran --with-gmp=/usr/local --with-mpfr=/usr/local
>

diff -udr -x contrib gcc-4.3-20080125.orig/gcc/builtins.c gcc-4.3-20080125/gcc/builtins.c
--- gcc-4.3-20080125.orig/gcc/builtins.c	Thu Dec  6 21:25:37 2007
+++ gcc-4.3-20080125/gcc/builtins.c	Tue Jan 29 05:21:15 2008
@@ -12729,13 +12729,13 @@
 	  int inexact;
 	  mpfr_t m1, m2;
 
-	  mpfr_inits2 (prec, m1, m2, NULL);
+	  mpfr_inits2 (prec, m1, m2, (char *)NULL);
 	  mpfr_from_real (m1, ra1, GMP_RNDN);
 	  mpfr_from_real (m2, ra2, GMP_RNDN);
 	  mpfr_clear_flags ();
 	  inexact = func (m1, m1, m2, GMP_RNDN);
 	  result = do_mpfr_ckconv (m1, type, inexact);
-	  mpfr_clears (m1, m2, NULL);
+	  mpfr_clears (m1, m2, (char *)NULL);
 	}
 }
   
@@ -12775,14 +12775,14 @@
 	  int inexact;
 	  mpfr_t m1, m2, m3;
 
-	  mpfr_inits2 (prec, m1, m2, m3, NULL);
+	  mpfr_inits2 (prec, m1, m2, m3, (char *)NULL);
 	  mpfr_from_real (m1, ra1, GMP_RNDN);
 	  mpfr_from_real (m2, ra2, GMP_RNDN);
 	  mpfr_from_real (m3, ra3, GMP_RNDN);
 	  mpfr_clear_flags ();
 	  inexact = func (m1, m1, m2, m3, GMP_RNDN);
 	  result = do_mpfr_ckconv (m1, type, inexact);
-	  mpfr_clears (m1, m2, m3, NULL);
+	  mpfr_clears (m1, m2, m3, (char *)NULL);
 	}
 }
   
@@ -12819,13 +12819,13 @@
 	  int inexact;
 	  mpfr_t m, ms, mc;
 
-	  mpfr_inits2 (prec, m, ms, mc, NULL);
+	  mpfr_inits2 (prec, m, ms, mc, (char *)NULL);
 	  mpfr_from_real (m, ra, GMP_RNDN);
 	  mpfr_clear_flags ();
 	  inexact = mpfr_sin_cos (ms, mc, m, GMP_RNDN);
 	  result_s = do_mpfr_ckconv (ms, type, inexact);
 	  result_c = do_mpfr_ckconv (mc, type, inexact);
-	  mpfr_clears (m, ms, mc, NULL);
+	  mpfr_clears (m, ms, mc, (char *)NULL);
 	  if (result_s && result_c)
 	{
 	  /* If we are to return in a complex value do so.  */
@@ -12933,7 +12933,7 @@
 	  long integer_quo;
 	  mpfr_t m0, m1;
 
-	  mpfr_inits2 (prec, m0, m1, NULL);
+	  mpfr_inits2 (prec, m0, m1, (char *)NULL);
 	  mpfr_from_real (m0, ra0, GMP_RNDN);
 	  mpfr_from_real (m1, ra1, GMP_RNDN);
 	  mpfr_clear_flags ();
@@ -12941,7 +12941,7 @@
 	  /* Remquo is independent of the rounding mode, so pass
 	 inexact=0 to do_mpfr_ckconv().  */
 	  result_rem = do_mpfr_ckconv (m0, type, /*inexact=*/ 0);
-	  mpfr_clears (m0, m1, NULL);
+	  mpfr_clears (m0, m1, (char *)NULL);
 	  if (result_rem)
 	{
 	  /* MPFR calculates quo in the host's long so it may
diff -udr -x contrib gcc-4.3-20080125.orig/gcc/c-aux-info.c gcc-4.3-20080125/gcc/c-aux-info.c
--- gcc-4.3-20080125.orig/gcc/c-aux-info.c	Thu Aug  9 06:29:12 2007
+++ gcc-4.3-20080125/gcc/c-aux-info.c	Tue Jan 29 04:55:25 2008
@@ -90,14 +90,14 @@
  add a blank after the data-type of course.  */
 
   if (p == type_or_decl)
-return concat (data_type, " ", type_or_decl, NULL);
+return concat (data_type, " ", type_or_decl, (char *)NULL);
 
   saved = *p;
   *p = '\0';
-  qualifiers_then_data_type = concat (type_or_decl, data_type, NULL);
+  qualifiers_then_data_type = concat (type_or_decl, data_type, (char *)NULL);
   *p = saved;
   return reconcat (qualifiers_then_data_type,
-		   qualifiers_then_data_type, " ", p, NULL);
+		   qualifiers_then_data_type, " ", p, (char *)NULL);
 }
 
 /* Given a tree node which represents some "function type", generate the
@@ -122,13 +122,13 @@
   const char *this_type;
 
   if (*formal_list)
-	formal_list = concat (formal_list, ", ", NULL);
+	formal_list = concat (formal_list, ", ", (char *)NULL);
 
   this_type = gen_type ("", TREE_VALUE (formal_type), ansi);
   formal_list
 	= ((strlen (this_type))
-	   ? concat (formal_list, affix_data_type (this_type), NULL)
-	   : concat (formal_list, data_type, NULL));
+	   ? concat (formal_list, affix_data_type (this_type), (char *)NULL)
+	   : concat (formal_list, data_type, (char *)NULL));
 
   formal_type = TREE_CHAIN (formal_type);
 }
@@ -177,10 +177,10 @@
 	 petered out to a NULL (

Re: [gcc-4.3-20080125] Bootstrap failure on i386-unknown-openbsd4.2: missing sentinel in function call

[Andrew Pinski]

On Jan 30, 2008 7:55 PM, Dongsheng Song <[EMAIL PROTECTED]> wrote:
> But the current xgcc in gcc 4.3 building issue the warning yet.

Yes because the header defines NULL incorrectly.  Which was the whole
issue in the first place.

-- Pinski

Re: How to get fndecl on C++ CALL_EXPR?

[Andrew Pinski]

On Jan 30, 2008 7:59 PM, H.J. Lu <[EMAIL PROTECTED]> wrote:
> I am trying to get fndecl on a C++ CALL_EXPR with get_callee_fndecl.
> But get_callee_fndecl returns NULL. What is the proper way to
> get fndecl on a C++ CALL_EXPR in the middle end?

If it is returning NULL, then there is no function decl associated with
that call, meaning it is an indirect call.  There is nothing you can do then.

-- Pinski

Re: How to get fndecl on C++ CALL_EXPR?

[Brendon Costa]

Andrew Pinski wrote:

On Jan 30, 2008 7:59 PM, H.J. Lu <[EMAIL PROTECTED]> wrote:

I am trying to get fndecl on a C++ CALL_EXPR with get_callee_fndecl.
But get_callee_fndecl returns NULL. What is the proper way to
get fndecl on a C++ CALL_EXPR in the middle end?


If it is returning NULL, then there is no function decl associated with
that call, meaning it is an indirect call.  There is nothing you can do then.



If it is an indirect call it is still possible to gather SOME useful 
information (depending on what you are trying to do). I have an 
application (EDoc++) where i find a list of "possible" functions that 
may be executed as the result of an indirect call.


There are two situations i check for:

virtual function calls
function pointer calls

Note: I am not overly familiar with things in GCC. This has worked for 
me so far with GCC 4.0.1.


For virtual functions it seems to be possible to obtain the fndecl for 
the virtual function that is being referenced. This is NOT the actual 
function that is called as that is determined at runtime.


Elsewhere i generate a list of functions that MAY be called as a 
result of a CALL_EXPR to a specific virtual function.



The other case is function pointer calls. In this case i get the type 
of the function pointer being called.


Elsewhere i maintain a list of functions which have had their 
addresses taken and then can match all of these to the function 
pointer type to determine what "MAY" be called.


Obviously there are problems with this approach like you don't get a 
restricted more accurate callgraph but an overly expanded one. It also 
requires data from other translation units, i.e. the fndecl's that MAY 
be called may be in different translation units. However it works fine 
for my purposes.


This was done for a project on sourceforge called EDoc++ that performs 
static analysis of C++ exception propagation.



I do all this in the C++ front end with the GENRIC tree. I am not sure 
if the data i use still exists at the GIMPLE level.


If you are interested in more information on how to do this let me 
know and i will pull out the relevant code. But as Andrew said, 
usually this is only known at runtime and most applications have no 
use knowing this information.


Brendon.

Re: How to get fndecl on C++ CALL_EXPR?

[H.J. Lu]

On Wed, Jan 30, 2008 at 08:04:52PM -0800, Andrew Pinski wrote:
> On Jan 30, 2008 7:59 PM, H.J. Lu <[EMAIL PROTECTED]> wrote:
> > I am trying to get fndecl on a C++ CALL_EXPR with get_callee_fndecl.
> > But get_callee_fndecl returns NULL. What is the proper way to
> > get fndecl on a C++ CALL_EXPR in the middle end?
> 
> If it is returning NULL, then there is no function decl associated with
> that call, meaning it is an indirect call.  There is nothing you can do then.
> 

It turns out that I only need return type. It is OK.

H.J.

Re: MIPS failure in gcc.c-torture/execute/20040709-2.c...

[David Daney]

Richard Sandiford wrote:
> David Daney <[EMAIL PROTECTED]> writes:
>   
>>  From Fri Jan 25 06:57:52 UTC 2008 (revision 131816)
>>
>> Configured thusly:
>>
>> ../trunk/configure --with-arch=r5000 --disable-java-awt --without-x 
>> --enable-__cxa_atexit --disable-jvmpi --disable-libgomp --disable-static 
>> --enable-languages=c,c++,java --disable-fixed-point 
>> --enable-checking=release --with-gmp=/home/daney/mp 
>> --with-mpfr=/home/daney/mp --disable-libmudflap
>>
>> The native configuration is running in an n32 ABI userspace.
>>
>> o2:/home/daney# /home/daney/gccsvn/trunk-build/gcc/xgcc 
>> -B/home/daney/gccsvn/trunk-build/gcc/ 
>> /home/daney/gccsvn/trunk/gcc/testsuite/gcc.c-torture/execute/20040709-2.c  
>> -w  -O2  -fno-show-column  -lm   -mabi=64 -o 
>> /home/daney/gccsvn/trunk-build/gcc/testsuite/gcc/20040709-2.x2
>> /home/daney/gccsvn/trunk/gcc/testsuite/gcc.c-torture/execute/20040709-2.c: 
>> In function âtestCâ:
>> /home/daney/gccsvn/trunk/gcc/testsuite/gcc.c-torture/execute/20040709-2.c:93:
>>  
>> internal compiler error: in insert_save, at caller-save.c:745
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See  for instructions.
>>
>>
>> All the other incantations of 20040709-2.c in the testsuite run PASS
>>
>> I opened: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35032
>> 
>
> This sounds like PR 34998, patch applied a few hours ago.
>   
Perhaps it is.  In any event it is fixed in trunk revision 131970, so I
closed the PR.

Thanks,
David Daney