Re: cp/default_conversion

2006-01-25 Thread Volker Reichelt
On 25 Jan, Marcin Dalecki wrote:
 The following removal of global default_conversion inside the C++  
 frontend:
 
 2006-01-25  Volker Reichelt  [EMAIL PROTECTED]
 
   (default_conversion): Likewise.
 
 Is junk due to the fact that it gets used for example in rs6000/rs6000.c
 The results in *actual* build failure on Darwin/PowerPC.

I reverted the patch to cure the bootstrap-failure, but there are
some things that make me wonder:

The function default_conversion is used in rs6000/rs6000-c.c.
The first line of the file reads:

  /* Subroutines for the C front end on the POWER and PowerPC architectures.

The file doesn't include cp-tree.h, but only c-tree.h.
But nevertheless the function default_conversion from the C++ frontend
is linked and not the one from the C frontend.

Is that intentional or a bug?
Do we need a langhook to get the right function?

Regards,
Volker




Re: cp/default_conversion

2006-01-25 Thread Andrew Pinski
 
 On 25 Jan, Marcin Dalecki wrote:
  The following removal of global default_conversion inside the C++  
  frontend:
  
  2006-01-25  Volker Reichelt  [EMAIL PROTECTED]
  
  (default_conversion): Likewise.
  
  Is junk due to the fact that it gets used for example in rs6000/rs6000.c
  The results in *actual* build failure on Darwin/PowerPC.
 
 I reverted the patch to cure the bootstrap-failure, but there are
 some things that make me wonder:
 
 The function default_conversion is used in rs6000/rs6000-c.c.
 The first line of the file reads:
 
   /* Subroutines for the C front end on the POWER and PowerPC architectures.
 
 The file doesn't include cp-tree.h, but only c-tree.h.
 But nevertheless the function default_conversion from the C++ frontend
 is linked and not the one from the C frontend.
 
 Is that intentional or a bug?
 Do we need a langhook to get the right function?

This is intentional, this function is called between the two front-ends.
Maybe this function prototype should be moved over to c-common.h like
the other common functions.

Thanks,
Andrew Pinski