openMP gcc vs icc, erratic results with gcc

[diego sandoval]

 Hi everybody,
I just started working with openMP,  i installed first gcc-4.2.3 and
then gcc-4.3.0,  both of them having  support for openMP.
I tried a code to calculate the product \pi*\e.  When i compile  the
code with gcc (both 4.2.3 and 4.3.0) withtout -fopenmp the result is
correct. When i try with the -fopenmp option the result is erroneous.
I also tried with the intel compiler icc  (with -openmp) in order to
verify the code correctness . There was no problem. I dont know what
is wrong with gcc and this particular code but the results are
erratic. If anyone of you can help me ... thanks in advance.

Let me ellaborate on this problem.

I am using gcc-4.3.0  in slackware 12.0 vanilla,  i have a quad core smp machine

$ uname -a
Linux ra 2.6.24.3-smp #1 SMP Wed Feb 27 18:46:56 COT 2008 i686
Intel(R) Core(TM)2 Quad CPUQ6600  @ 2.40GHz GenuineIntel GNU/Linux

$ gcc-4.3.0 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ./configure
--prefix=/home/medrano/compilers/gcc-4.3.0/ --enable-shared
--enable-languages=c,c++ --enable-threads=posix --enable-__cxa_atexit
--disable-checking --with-gnu-ld --verbose --program-suffix=-4.3.0
Thread model: posix
gcc version 4.3.0 (GCC)



I tried the  openMP code below from
http://www.kallipolis.com/openmp/taylor_mp.c   which is supposed to
calculate the product \pi*\e using the taylor series.

$ gcc-4.3.0 -O2 -fopenmp taylor_mp.c -o taylor.gcc.out
$ icc -O2 -openmp taylor_mp.c -o taylor.intel.out

The results are:

$ ./taylor.gcc.out
Reached result 5.142145 in 10640.000 seconds ### wrong result
$ ./taylor.gcc.out
Reached result 10.795894 in 10660.000 seconds ### wrong result

$ ./taylor.intel.out
Reached result 8.539734 in 9950.000 seconds ### right result
$ ./taylor.intel.out
Reached result 8.539734 in 9570.000 seconds  ### right result




/*
 * taylor.c
 *
 * This program calculates the value of e*pi by first calculating e
 * and pi by their taylor expansions and then multiplying them
 * together.
 */

#include 

#include 

#define num_steps 2000

int main(int argc, char *argv[])
{
  double start, stop; /* times of beginning and end of procedure */
  double e, pi, factorial, product;
  int i;


  /* start the timer */
  start = clock();

  /* Now there is no first and seccond, we calculate e and pi */
#pragma omp parallel sections shared(e, pi)
  {
#pragma omp section
{
  printf("e started\n");

  e = 1;
  factorial = 1; /* rather than recalculating the factorial from
scratch each iteration we keep it in this varialbe
and multiply it by i each iteration. */
  for (i = 1; i

Re: openMP gcc vs icc, erratic results with gcc

[Theodore Papadopoulo]

diego sandoval wrote:

 Hi everybody,
I just started working with openMP,  i installed first gcc-4.2.3 and
then gcc-4.3.0,  both of them having  support for openMP.
I tried a code to calculate the product \pi*\e.  When i compile  the
code with gcc (both 4.2.3 and 4.3.0) withtout -fopenmp the result is
correct. When i try with the -fopenmp option the result is erroneous.
I also tried with the intel compiler icc  (with -openmp) in order to
verify the code correctness . There was no problem. I dont know what
is wrong with gcc and this particular code but the results are
erratic. If anyone of you can help me ... thanks in advance.
  

I do not know where the problem lies but the good news seems to be that
it is either corrected in the development version (gcc version 4.4.0 
20080414 (experimental)),
and/or it works fine on x86-64 (both 32 and 64 bit)... and I would not 
have expected
such a speedup in the 64bit version (the timings are in milliseconds not 
in seconds)!!


/usr/local/gcc/bin/gcc -fopenmp -O3 taylor.c
./a.out
Reached result 8.539734 in 5650.000 seconds

/usr/local/gcc/bin/gcc -fopenmp -O3 -m32 taylor.c
./a.out
Reached result 8.539734 in 10410.000 seconds

Re: How to legitimize the reload address?

[Mohamed Shafi]

On Wed, May 21, 2008 at 1:42 AM, Jeff Law <[EMAIL PROTECTED]> wrote:
> Ian Lance Taylor wrote:
>>
>> "Mohamed Shafi" <[EMAIL PROTECTED]> writes:
>>
>>> For the 16 bit target that i am currently porting can have only
>>> positive offsets less than 0x100. (unsigned 8 bit) for offset
>>> addressing mode.
>>
>> I would expect reload to be able to handle this kind of thing anyhow,
>> assuming you define GO_IF_LEGITIMATE_ADDRESS correctly.  reload should
>> automatically try loading an out of range offset into a register.
>
> Agreed.
>
> Typically if there are problems in this area it is because the port hasn't
> properly defined secondary reloads, or the valid offsets are not consistent
> within a machine mode.
>
> Mohamed, without more details, there's not much we can do to help you.
>
I am sure that i have written GO_IF_LEGITIMATE_ADDRESS correctly.
What i have in my port is something similar to mcore back-end. These
are the relevant parts:

  else if (GET_CODE (X) == PLUS)
{
  rtx xop0 = XEXP (X,0);
  rtx xop1 = XEXP (X,1);

  if (BASE_REGISTER_RTX_P (xop0))
return legitimate_index_p (mode, xop1);
   }

static int
legitimate_index_p (enum machine_mode mode, rtx OP)
{
  if (GET_CODE (OP) == CONST_INT)
{
  if (GET_MODE_SIZE (mode) >= 4
  && (((unsigned)INTVAL (OP)) % 4) == 0
  &&  ((unsigned)INTVAL (OP)) <= 0x0100)
return 1;

  if (GET_MODE_SIZE (mode) == 2
  && (((unsigned)INTVAL (OP)) % 2) == 0
  &&  ((unsigned)INTVAL (OP)) <= 0x0100)
return 1;

  if (GET_MODE_SIZE (mode) == 1
  && ((unsigned)INTVAL (OP)) <= 0x0100)
return 1;
}

  return 0;
}


The compiler is crashing in change_address_1, at emit-rtl.c
...
  if (validate)
{
  if (reload_in_progress || reload_completed)
gcc_assert (memory_address_p (mode, addr));
  else
addr = memory_address (mode, addr);
}



Everything starts when cleanup_subreg_operands() is called from
reload() for the following pattern.

(set (subreg:HI (mem:SI (plus:HI (reg:HI 12 [SP]) (const_int 256)) 2)
   (reg:HI 3))

and then this becomes

(set (mem:HI (plus:HI (reg:HI 12 [SP] ) (const_int 258)))
   (reg:HI 3))

This pattern is not legitimate due to out of range offset.
Will i be able to overcome this if i write LEGITIMIZE_RELOAD_ADDRESS
or LEGITIMIZE_ADDRESS

Thank you for your time.

Regards,
Shafi

Re: openMP gcc vs icc, erratic results with gcc

[Ed Brambley]

Dear Diego,

As I understand it (which is not necessarily correct), your code is slightly
incorrect, since variable are by default shared between parallel sections.
Therefore, the "int i" is shared between threads, and hence the erratic
results if both loops execute at the same time.  To fix it, you could try
changing the first #pragma to read

#pragma omp parallel sections private(i)

Or, alternatively, define i in the for loops as, for example

for (int i = 0; i < num_steps*10; i++) {
...


So why does this works with icc or gcc 4.4?  My guess would be it's because
OpenMP doesn't guarantee that variables are in sync between threads unless it
hits a flush directive (either explicit or implicit), and so it would seem
with icc or gcc 4.4 the variable i is out of sync (probably because it's held
in a register, which is probably a good idea).

Yours,
Ed

Ps: For those interested, a great tutorial on OpenMP is available at
http://www.llnl.gov/computing/tutorials/openMP/.

Re: openMP gcc vs icc, erratic results with gcc

[Jakub Jelinek]

On Wed, May 21, 2008 at 11:21:27AM +0100, Ed Brambley wrote:
> As I understand it (which is not necessarily correct), your code is slightly
> incorrect, since variable are by default shared between parallel sections.
> Therefore, the "int i" is shared between threads, and hence the erratic
> results if both loops execute at the same time.  To fix it, you could try
> changing the first #pragma to read
> 
> #pragma omp parallel sections private(i)
> 
> Or, alternatively, define i in the for loops as, for example
> 
> for (int i = 0; i < num_steps*10; i++) {

Yep, or just in the block inside of #pragma omp sections or #pragma omp section.
In fact, it would be good to define factorial there too, or add
private(factorial) - while this one is not necessary for correctness,
it still would improve readability and could be tiny bit faster.

> So why does this works with icc or gcc 4.4?  My guess would be it's because
> OpenMP doesn't guarantee that variables are in sync between threads unless it
> hits a flush directive (either explicit or implicit), and so it would seem
> with icc or gcc 4.4 the variable i is out of sync (probably because it's held
> in a register, which is probably a good idea).

When multiple threads modify the same shared library you are really in an
undefined behavior territory, where the results will depend on what kind
of loop optimizations is performed etc. - if each iteration updates the
shared variable then it is of course much more likely to see "unexpected"
results than if the var is just written at the end of loop (which is
possible, both because the loops don't call any function and i's address
isn't taken).

Jakub

Pointers to add doulle-float capabilities for the avr target

[Tobias Frost]

Hallo,

I am currently evaluation the feasiblitiy to add (real) 64-doubles to the 
capabilities of the avr-gcc. The current state is, that the avr-gcc supports 
floats and alias them to doubles. However, a prospective project demands the 
resolution (accordung to their research), and therefore the company needing it 
might sponsor me to implement the support.

However, beside some trivial patches, I am not familiar with gcc hacking. 
Therefore it is hard for me to estimated how long this will take, but the 
numbers are cruicial to deside if I get the assignement. 

As far as I dugg into the gcc source, there is a soft-float library which is 
used widely among non-FPU targets. However, I am currently missing the link, 
how the target has to be configured to be aware of that. As I am currently 
stuck with that, I'd appreciate any hint, link, documents etc which might point 
me into the right direction. 

Thanks,

-- 
coldtobi
http://blog.coldtobi.de

Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Re: How to legitimize the reload address?

[Ian Lance Taylor]

"Mohamed Shafi" <[EMAIL PROTECTED]> writes:

> Everything starts when cleanup_subreg_operands() is called from
> reload() for the following pattern.
>
> (set (subreg:HI (mem:SI (plus:HI (reg:HI 12 [SP]) (const_int 256)) 2)
>(reg:HI 3))

I think your movhi operand predicate may have to look for this case
and reject it.

> This pattern is not legitimate due to out of range offset.
> Will i be able to overcome this if i write LEGITIMIZE_RELOAD_ADDRESS
> or LEGITIMIZE_ADDRESS

No, because those won't reliably be called on a legitimate address.
You need to reject the operand at some point.

Ian

Help with ifcvt

[Paul Brook]

I'm looking for help with an if-convert problem.

I have a local arm based target, but with most of the conditional execution 
patterns disabled. Before the first if-conversion pass we have the following 
RTL:

(set (reg2) (const_int 0))
(set (CC) (compare (reg1) (const_int 0)))
(jump if (CC) (label_ref 1)

(set (reg2) (const_int 1))

(label 1)
(jump if (CC) (label_ref 2))
...

The CE1 pass recognises the first conditional branch as a store-flag 
sequence, and replaces it with a abs/sub/shift sequence:

(set (CC) (compare (reg1) (const_int 0)))
(parallel (set (reg2) (abs (reg1)))
  (clobber (CC)))
(sub/shift)
(jump if (CC) (label_ref 2))

The problem is that it does this without any liveness information. An ARM the 
abs instruction clobbers the condition code register (CC).
The CC was live over this block and is still needed for the second conditional 
branch. Things go rapidly downhill from there.

I can't reproduce the bug with FSF sources, However I believe this is a latent 
bug that could effect any targets that use specific hard registers. CC is the 
most common example, but I guess this could also happen with other fixed 
registers (e.g. multipliers with fixed output registers).

Ideally I guess we'd do something similar to combine, and use life information 
to avoid clobbering useful values. However we don't have life info, and I 
guess calculating it would be expensive.

The best compromise I've been able to come up with is the scan the replacement 
sequence for new sets/clobbers of hard registers, and reject the replacement 
if this occurs.  This scanning is fairly ugly, but quicker than full life 
analysis and hopefully won't cause too many pessimizations, though I'd have 
to check x86.

Any suggestions?

Paul

GCC 4.2.4 Released

[Joseph S. Myers]

GCC 4.2.4 has been released.

GCC 4.2.4 is a bug-fix release, containing fixes for regressions in GCC 
4.2.3 relative to previous GCC releases.  This release is available from 
the FTP servers listed at:

  http://www.gnu.org/order/ftp.html

Please do not contact me directly regarding questions or comments about 
this release.  Instead, use the resources available from 
http://gcc.gnu.org.

As always, a vast number of people contributed to this GCC release -- far 
too many to thank individually!

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: How to legitimize the reload address?

[Jeff Law]

Mohamed Shafi wrote:

On Wed, May 21, 2008 at 1:42 AM, Jeff Law <[EMAIL PROTECTED]> wrote:

Ian Lance Taylor wrote:

"Mohamed Shafi" <[EMAIL PROTECTED]> writes:


For the 16 bit target that i am currently porting can have only
positive offsets less than 0x100. (unsigned 8 bit) for offset
addressing mode.

I would expect reload to be able to handle this kind of thing anyhow,
assuming you define GO_IF_LEGITIMATE_ADDRESS correctly.  reload should
automatically try loading an out of range offset into a register.

Agreed.

Typically if there are problems in this area it is because the port hasn't
properly defined secondary reloads, or the valid offsets are not consistent
within a machine mode.

Mohamed, without more details, there's not much we can do to help you.


I am sure that i have written GO_IF_LEGITIMATE_ADDRESS correctly.
What i have in my port is something similar to mcore back-end. These
are the relevant parts:

  else if (GET_CODE (X) == PLUS)
{
  rtx xop0 = XEXP (X,0);
  rtx xop1 = XEXP (X,1);

  if (BASE_REGISTER_RTX_P (xop0))
return legitimate_index_p (mode, xop1);
   }

static int
legitimate_index_p (enum machine_mode mode, rtx OP)
{
  if (GET_CODE (OP) == CONST_INT)
{
  if (GET_MODE_SIZE (mode) >= 4
  && (((unsigned)INTVAL (OP)) % 4) == 0
  &&  ((unsigned)INTVAL (OP)) <= 0x0100)
return 1;

  if (GET_MODE_SIZE (mode) == 2
  && (((unsigned)INTVAL (OP)) % 2) == 0
  &&  ((unsigned)INTVAL (OP)) <= 0x0100)
return 1;

  if (GET_MODE_SIZE (mode) == 1
  && ((unsigned)INTVAL (OP)) <= 0x0100)
return 1;
}

  return 0;
}


The compiler is crashing in change_address_1, at emit-rtl.c
...
  if (validate)
{
  if (reload_in_progress || reload_completed)
gcc_assert (memory_address_p (mode, addr));
  else
addr = memory_address (mode, addr);
}



Everything starts when cleanup_subreg_operands() is called from
reload() for the following pattern.

(set (subreg:HI (mem:SI (plus:HI (reg:HI 12 [SP]) (const_int 256)) 2)
   (reg:HI 3))

and then this becomes

(set (mem:HI (plus:HI (reg:HI 12 [SP] ) (const_int 258)))
   (reg:HI 3))

This pattern is not legitimate due to out of range offset.
Will i be able to overcome this if i write LEGITIMIZE_RELOAD_ADDRESS
or LEGITIMIZE_ADDRESS
You have a (subreg (mem)) expression.  The mem part of that expression 
should have been reloaded into a register.You probably want to look 
at your reload debugging dumps to see how/why that's not happening properly.


Using LEGITIMIZE_RELOAD_ADDRESS is definitely not the way to solve this 
problem.  It's intended solely as a means to optimize how reload 
generates code for certain cases.   LEGITIMIZE_ADDRESS won't have an 
affect at this stage in the compiler.


jeff


Thank you for your time.




Regards,
Shafi

Re: Pointers to add doulle-float capabilities for the avr target

[Uros Bizjak]

Hello!


I am currently evaluation the feasiblitiy to add (real) 64-doubles to the 
capabilities of the avr-gcc. The current state is, that the avr-gcc supports 
floats and alias them to doubles. However, a prospective project demands the 
resolution (accordung to their research), and therefore the company needing it 
might sponsor me to implement the support.

However, beside some trivial patches, I am not familiar with gcc hacking. Therefore it is hard for me to estimated how long this will take, but the numbers are cruicial to deside if I get the assignement. 

As far as I dugg into the gcc source, there is a soft-float library which is used widely among non-FPU targets. However, I am currently missing the link, how the target has to be configured to be aware of that. As I am currently stuck with that, I'd appreciate any hint, link, documents etc which might point me into the right direction. 

  


Add this code to avr/t-avr:

--cut here--
LIB2FUNCS_EXTRA = fp-bit.c dp-bit.c

dp-bit.c: $(srcdir)/config/fp-bit.c
   cat $(srcdir)/config/fp-bit.c > dp-bit.c

fp-bit.c: $(srcdir)/config/fp-bit.c
   echo '#define FLOAT' > fp-bit.c
   cat $(srcdir)/config/fp-bit.c >> fp-bit.c
--cut here--

then update avr/avr.h with

#define FLOAT_TYPE_SIZE 32
#define DOUBLE_TYPE_SIZE 64
#define LONG_DOUBLE_TYPE_SIZE 64

If everything works as expected, then you have just added soft-fp 
support to avr.


Uros.

Temporary object omits constructor

[Stefan Schulze Frielinghaus]

Hello all,

I just tried to easily show how many temporary objects get created in my
program. I created a test application like this one:

#include 

struct A {
static int c, d;
A() { ++c; }
~A() { ++d; }
void operator+=(const A&) { }
A operator+(const A&) { return *this; }
};

int A::c = 0;
int A::d = 0;

int main() {
A a, b, c;

a = b + c;
//a = b;
//a += c;

std::cout << A::c << " " << A::d << std::endl;
}

Whenever an object of class type A is created a counter is incremented.
So when I compile this application
(g++ -Wall -Wextra -O0 -ggdb2 -o test test.cpp) and run it I suspected
to get an output like this one: 4 1 (three objects plus one temporary
which gets destructed before std::cout).
But the actual result was: 3 1

The assembler output (i386) looks like this (without iostream etc):

gdb disas main:
0x080483d4 :leaecx,[esp+0x4]
0x080483d8 :andesp,0xfff0
0x080483db :push   DWORD PTR [ecx-0x4]
0x080483de :   push   ebp
0x080483df :   movebp,esp
0x080483e1 :   push   ecx
0x080483e2 :   subesp,0x24
0x080483e5 :   leaeax,[ebp-0x6]
0x080483e8 :   movDWORD PTR [esp],eax
0x080483eb :   call   0x804845c 
0x080483f0 :   leaeax,[ebp-0x7]
0x080483f3 :   movDWORD PTR [esp],eax
0x080483f6 :   call   0x804845c 
0x080483fb :   leaeax,[ebp-0x8]
0x080483fe :   movDWORD PTR [esp],eax
0x08048401 :   call   0x804845c 
0x08048406 :   leaedx,[ebp-0x5]
0x08048409 :   leaeax,[ebp-0x8]
0x0804840c :   movDWORD PTR [esp+0x8],eax
0x08048410 :   leaeax,[ebp-0x7]
0x08048413 :   movDWORD PTR [esp+0x4],eax
0x08048417 :   movDWORD PTR [esp],edx
0x0804841a :   call   0x8048480 <_ZN1AplERKS_>
0x0804841f :   subesp,0x4
0x08048422 :   leaeax,[ebp-0x5]
0x08048425 :   movDWORD PTR [esp],eax
0x08048428 :   call   0x804846e <~A>
0x0804842d :   leaeax,[ebp-0x8]
0x08048430 :   movDWORD PTR [esp],eax
0x08048433 :   call   0x804846e <~A>
0x08048438 :  leaeax,[ebp-0x7]
0x0804843b :  movDWORD PTR [esp],eax
0x0804843e :  call   0x804846e <~A>
0x08048443 :  leaeax,[ebp-0x6]
0x08048446 :  movDWORD PTR [esp],eax
0x08048449 :  call   0x804846e <~A>
0x0804844e :  moveax,0x0
0x08048453 :  movecx,DWORD PTR [ebp-0x4]
0x08048456 :  leave  
0x08048457 :  leaesp,[ecx-0x4]
0x0804845a :  ret

Only three times the constructor is called but four times the destructor
and a magic call to "0x8048480 <_ZN1AplERKS_>".

Can someone explain these results?

Best regards
Stefan

Re: Pointers to add doulle-float capabilities for the avr target

[Tobias Frost]

Thanks a lot... 
This is almost the state I was when I left work today. I never thought,
that will be sufficient ;-) 
I'll give feedback on Monday (tomorrow's holiday --> lng weekend ;-)

Tobi




On Wed, 2008-05-21 at 19:02 +0200, Uros Bizjak wrote:
> Hello!
> 
> > I am currently evaluation the feasiblitiy to add (real) 64-doubles to the 
> > capabilities of the avr-gcc. The current state is, that the avr-gcc 
> > supports floats and alias them to doubles. However, a prospective project 
> > demands the resolution (accordung to their research), and therefore the 
> > company needing it might sponsor me to implement the support.
> >
> > However, beside some trivial patches, I am not familiar with gcc hacking. 
> > Therefore it is hard for me to estimated how long this will take, but the 
> > numbers are cruicial to deside if I get the assignement. 
> >
> > As far as I dugg into the gcc source, there is a soft-float library which 
> > is used widely among non-FPU targets. However, I am currently missing the 
> > link, how the target has to be configured to be aware of that. As I am 
> > currently stuck with that, I'd appreciate any hint, link, documents etc 
> > which might point me into the right direction. 
> >
> >   
> 
> Add this code to avr/t-avr:
> 
> --cut here--
> LIB2FUNCS_EXTRA = fp-bit.c dp-bit.c
> 
> dp-bit.c: $(srcdir)/config/fp-bit.c
> cat $(srcdir)/config/fp-bit.c > dp-bit.c
> 
> fp-bit.c: $(srcdir)/config/fp-bit.c
> echo '#define FLOAT' > fp-bit.c
> cat $(srcdir)/config/fp-bit.c >> fp-bit.c
> --cut here--
> 
> then update avr/avr.h with
> 
> #define FLOAT_TYPE_SIZE 32
> #define DOUBLE_TYPE_SIZE 64
> #define LONG_DOUBLE_TYPE_SIZE 64
> 
> If everything works as expected, then you have just added soft-fp 
> support to avr.
> 
> Uros.

Re: Pointers to add doulle-float capabilities for the avr target

[hutchinsonandy]

That looks correct.


Be aware that support for handling  long long operands (64 bits) - or 
doubles is not well supported on AVR.  So you may expose some problems 
with this.


We currently have long long disabled in testsuite testing to avoid 
noise.  At some point I hope to switch it back on to see where we are - 
but I have enough to deal with <64 bits a present.



Andy

Re: Temporary object omits constructor

[Joe Buck]

On Wed, May 21, 2008 at 07:14:27PM +0200, Stefan Schulze Frielinghaus wrote:
> Hello all,
> 
> I just tried to easily show how many temporary objects get created in my
> program. I created a test application like this one:

> #include 
> 
> struct A {
>   static int c, d;
>   A() { ++c; }
>   ~A() { ++d; }
>   void operator+=(const A&) { }
>   A operator+(const A&) { return *this; }
> };

You forgot to add

A::A(const A&) { ++c;}

The missing call is to the copy constructor.  Since you didn't declare
one, the compiler inserts one, and it doesn't increment the counter.

Also, there are situations where a C++ compiler is allowed to eliminate
temporaries (even if this changes side effects that are invoked by
a copy constructor).

GDC

[Rohan]

Is there any plan to merge GDC with GCC?
I know that GDC package available separately, but I think it would be
much better to get in at one box. Now for adding support D language
needed to rebuild all GCC with GDC.

P.S. I talk about D language


-- 
С уважением,
 Rohan  mailto:[EMAIL PROTECTED]

Re: Pointers to add doulle-float capabilities for the avr target

[Uros Bizjak]

Tobias Frost wrote:
Thanks a lot... 
This is almost the state I was when I left work today. I never thought,

that will be sufficient ;-)
  


You will also need movdf (and perhaps pushdf) insn patterns in avr.md file.

Uros.

Re: GDC

[Tom Tromey]

> "Rohan" == Rohan  <[EMAIL PROTECTED]> writes:

Rohan> Is there any plan to merge GDC with GCC?
Rohan> I know that GDC package available separately, but I think it would be
Rohan> much better to get in at one box. Now for adding support D language
Rohan> needed to rebuild all GCC with GDC.

You would have to ask the GDC developers.

Tom

Re: GDC

[Joe Buck]

On Wed, May 21, 2008 at 09:38:06PM +0400, Rohan wrote:
> Is there any plan to merge GDC with GCC?

Not at present.

> I know that GDC package available separately, but I think it would be
> much better to get in at one box. Now for adding support D language
> needed to rebuild all GCC with GDC.

If the D front end developers want to contribute their work to GCC, I'm sure
that this would be welcomed.

Re: Temporary object omits constructor

[Stefan Schulze Frielinghaus]

On Wed, 2008-05-21 at 10:32 -0700, Joe Buck wrote:
> You forgot to add
> 
> A::A(const A&) { ++c;}
> 
> The missing call is to the copy constructor.  Since you didn't declare
> one, the compiler inserts one, and it doesn't increment the counter.

Arghl your right. I removed the copy constructor two test cases before
and forget to add it again.

> Also, there are situations where a C++ compiler is allowed to eliminate
> temporaries (even if this changes side effects that are invoked by
> a copy constructor).

Yes your right. C++ Standard 12.8/15 says the same. But the object has
to be cv-unqualified and/or unnamed.

Thanks for your hint!

Best regards
Stefan

m32c failure at cfgrtl.c:2332 (purge_dead_edges)

[DJ Delorie]

I've got a number of test cases that are all failing in the same place:

#1  0x081cf498 in purge_dead_edges (bb=0xb7f67834) at 
../../gcc/gcc/cfgrtl.c:2332
2332  gcc_assert (single_succ_p (bb));

(similar to http://gcc.gnu.org/ml/gcc/2008-04/msg00473.html but I'm using trunk)

What's up here?  I don't see these types of crashes in the 4.3 branch.


Example:

Executing on host: /sata/dj/gnu/gcc/m32c-elf/gcc/xgcc 
-B/sata/dj/gnu/gcc/m32c-elf/gcc/ 
/sata/dj/gnu/gcc/gcc/gcc/testsuite/gcc.dg/duff-1.c   -O2 -DSTACK_SIZE=4096 
-DNO_TRAMPOLINES -fno-show-column   -msim-lm   -mcpu=m16c -o ./duff-1.exe   
 (timeout = 30)
/sata/dj/gnu/gcc/gcc/gcc/testsuite/gcc.dg/duff-1.c: In function 'duffcpy':
/sata/dj/gnu/gcc/gcc/gcc/testsuite/gcc.dg/duff-1.c:36: internal compiler error: 
in purge_dead_edges, at cfgrtl.c:2332


The BB looks like this:

;; basic block 20, loop depth 0, count 0
;; prev block 19, next block 3
;; pred:  
;; succ:  
(code_label 31 30 83 20 8 "" [2 uses])
(note 83 31 32 20 [bb 20] NOTE_INSN_BASIC_BLOCK)


and the insns look like this (full listing also attached):

(note 82 28 29 19 [bb 19] NOTE_INSN_BASIC_BLOCK)

(jump_insn 29 82 30 19 dj.c:19 (set (pc)
(label_ref 32)) -1 (nil))

(barrier 30 29 31)

(code_label 31 30 83 20 8 "" [2 uses])

(note 83 31 32 20 [bb 20] NOTE_INSN_BASIC_BLOCK)

(code_label 32 83 33 3 5 "" [2 uses])

(note 33 32 34 3 [bb 3] NOTE_INSN_BASIC_BLOCK)

(insn 34 33 35 3 dj.c:25 (set (reg:QI 30)



--

(note 1 0 6 NOTE_INSN_DELETED)

(note 6 1 2 9 [bb 9] NOTE_INSN_BASIC_BLOCK)

(insn 2 6 3 9 dj.c:18 (set (reg/v/f:HI 25 [ dst ])
(reg:HI 2 r1 [ dst ])) -1 (nil))

(insn 3 2 4 9 dj.c:18 (set (reg/v/f:HI 26 [ src ])
(reg:HI 1 r2 [ src ])) -1 (nil))

(insn 4 3 5 9 dj.c:18 (set (reg/v:SI 27 [ size ])
(mem/c/i:SI (reg/f:HI 20 virtual-incoming-args) [2 size+0 S4 A8])) -1 
(expr_list:REG_EQUIV (mem/c/i:SI (reg/f:HI 20 virtual-incoming-args) [2 size+0 
S4 A8])
(nil)))

(note 5 4 7 9 NOTE_INSN_FUNCTION_BEG)

(note 7 5 8 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(insn 8 7 9 2 dj.c:19 (set (reg:SI 28)
(and:SI (reg/v:SI 27 [ size ])
(const_int 3 [0x3]))) -1 (nil))

(jump_insn 9 8 74 2 dj.c:19 (set (pc)
(if_then_else (ne (subreg:HI (reg:SI 28) 0)
(const_int 1 [0x1]))
(label_ref 13)
(pc))) -1 (nil))

(note 74 9 10 11 [bb 11] NOTE_INSN_BASIC_BLOCK)

(jump_insn 10 74 75 11 dj.c:19 (set (pc)
(if_then_else (ne (subreg:HI (reg:SI 28) 2)
(const_int 0 [0x0]))
(label_ref 13)
(pc))) -1 (nil))

(note 75 10 11 12 [bb 12] NOTE_INSN_BASIC_BLOCK)

(jump_insn 11 75 12 12 dj.c:19 (set (pc)
(label_ref 44)) -1 (nil))

(barrier 12 11 13)

(code_label 13 12 76 13 6 "" [2 uses])

(note 76 13 14 13 [bb 13] NOTE_INSN_BASIC_BLOCK)

(insn 14 76 15 13 dj.c:19 (set (mem:HI (pre_dec:HI (reg/f:HI 8 sp)) [0 S2 A8])
(const_int 0 [0x0])) -1 (nil))

(insn 15 14 16 13 dj.c:19 (set (mem:HI (pre_dec:HI (reg/f:HI 8 sp)) [0 S2 A8])
(const_int 1 [0x1])) -1 (nil))

(insn 16 15 17 13 dj.c:19 (set (mem:HI (pre_dec:HI (reg/f:HI 8 sp)) [0 S2 A8])
(subreg:HI (reg:SI 28) 2)) -1 (nil))

(insn 17 16 18 13 dj.c:19 (set (mem:HI (pre_dec:HI (reg/f:HI 8 sp)) [0 S2 A8])
(subreg:HI (reg:SI 28) 0)) -1 (nil))

(insn 18 17 19 13 dj.c:19 (set (reg/f:HI 29)
(symbol_ref:HI ("__ucmpsi2") [flags 0x41])) -1 (nil))

(call_insn/u 19 18 20 13 dj.c:19 (parallel [
(set (reg:HI 0 r0)
(call (mem:QI (reg/f:HI 29) [0 S1 A8])
(const_int 8 [0x8])))
(use (const_int 0 [0x0]))
]) -1 (expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil))
(expr_list:REG_DEP_TRUE (use (mem:SI (plus:HI (reg/f:HI 23 
virtual-outgoing-args)
(scratch:HI)) [0 S4 A8]))
(expr_list:REG_DEP_TRUE (use (mem:SI (plus:HI (reg/f:HI 23 
virtual-outgoing-args)
(scratch:HI)) [0 S4 A8]))
(nil

(insn 20 19 21 13 dj.c:19 (set (reg/f:HI 8 sp)
(plus:HI (reg/f:HI 8 sp)
(const_int 8 [0x8]))) -1 (nil))

(jump_insn 21 20 77 13 dj.c:19 (set (pc)
(if_then_else (ltu (reg:HI 0 r0)
(const_int 1 [0x1]))
(label_ref 50)
(pc))) -1 (nil))

(note 77 21 22 14 [bb 14] NOTE_INSN_BASIC_BLOCK)

(jump_insn 22 77 78 14 dj.c:19 (set (pc)
(if_then_else (ne (subreg:HI (reg:SI 28) 0)
(const_int 2 [0x2]))
(label_ref 26)
(pc))) -1 (nil))

(note 78 22 23 15 [bb 15] NOTE_INSN_BASIC_BLOCK)

(jump_insn 23 78 79 15 dj.c:19 (set (pc)
(if_then_else (ne (subreg:HI (reg:SI 28) 2)
(const_int 0 [0x0]))
(label_ref 26)
(pc))) -1 (nil))

(note 79 23 24 16 [bb 16] NOTE_INSN_BASIC_BLOCK)

(jump_insn 24 79 25 16 dj.c:19 (set (pc)
(label_ref 38)) -1 (nil))

(barrier 25 

Re: GCC Compile Farm News: two new bi-quad core machines available

[Laurent GUERBY]

On Tue, 2008-05-20 at 11:25 +0200, Richard Guenther wrote:
> On Mon, May 19, 2008 at 8:50 PM, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> >  The GCC Compile Farm project is pleased to announce that two bi-quad
> >  core machines with the latest Opteron 8354 "Barcelona B3" processor and
> >  16GB of RAM donated by AMD are now available online in datacenter space
> >  kindly donated by INRIA Saclay.
>
> Isn't this worth an entry on the GCC news page?

If there's consensus, I can certainly propose a patch.

Sincerely,

Laurent

store_motion query

[DJ Delorie]

Why is store_motion doing this?

STORE_MOTION  delete insn in BB 2:
  (insn 8 7 27 2 dj.c:10 (parallel [
(set (mem/s/j:HI (reg/v/f:HI 26 [ s ]) [0 
.buf+0 S2 A8])
(ashift:HI (reg/v:HI 27 [ n ])
(subreg:QI (reg/v:HI 27 [ n ]) 0)))
(clobber (scratch:HI))
]) 223 {ashlhi3_i} (expr_list:REG_DEAD (reg/v:HI 27 [ n ])
(nil)))
STORE MOTION  replaced with insn:
  (insn 27 8 9 2 dj.c:10 (set (reg:HI 29 [ .buf ])
(ashift:HI (reg/v:HI 27 [ n ])
(subreg:QI (reg/v:HI 27 [ n ]) 0))) -1 
(expr_list:REG_DEAD (reg/v:HI 27 [ n ])
(nil)))
deleting insn with uid = 8.


Notice that the clobber is gone.  Sure enough, later on recog fails
because the clobber is missing.

(this is gcc.dg/torture/pr24257.c at -O1 for m32c-elf)

Re: GCC Compile Farm News: two new bi-quad core machines available

[Joe Buck]

On Wed, May 21, 2008 at 10:45:15PM +0200, Laurent GUERBY wrote:
> On Tue, 2008-05-20 at 11:25 +0200, Richard Guenther wrote:
> > On Mon, May 19, 2008 at 8:50 PM, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > >  The GCC Compile Farm project is pleased to announce that two bi-quad
> > >  core machines with the latest Opteron 8354 "Barcelona B3" processor and
> > >  16GB of RAM donated by AMD are now available online in datacenter space
> > >  kindly donated by INRIA Saclay.
> >
> > Isn't this worth an entry on the GCC news page?
> 
> If there's consensus, I can certainly propose a patch.

Please do.  We should thank people for significant contributions.

Re: store_motion query

[Daniel Berlin]

On Wed, May 21, 2008 at 4:48 PM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> Why is store_motion doing this?
>
> STORE_MOTION  delete insn in BB 2:
>  (insn 8 7 27 2 dj.c:10 (parallel [
>(set (mem/s/j:HI (reg/v/f:HI 26 [ s ]) [0 
> .buf+0 S2 A8])
>(ashift:HI (reg/v:HI 27 [ n ])
>(subreg:QI (reg/v:HI 27 [ n ]) 0)))
>(clobber (scratch:HI))
>]) 223 {ashlhi3_i} (expr_list:REG_DEAD (reg/v:HI 27 [ n ])
>(nil)))
> STORE MOTION  replaced with insn:
>  (insn 27 8 9 2 dj.c:10 (set (reg:HI 29 [ .buf ])
>(ashift:HI (reg/v:HI 27 [ n ])
>(subreg:QI (reg/v:HI 27 [ n ]) 0))) -1 
> (expr_list:REG_DEAD (reg/v:HI 27 [ n ])
>(nil)))
> deleting insn with uid = 8.


It looks like it replaced the store with a reg move, and it should
have inserted the store back to memory with the clobber back later in
the CFG.

IE it pushed your store down to some later point in the CFG.

Re: store_motion query

[DJ Delorie]

> It looks like it replaced the store with a reg move, and it should
> have inserted the store back to memory with the clobber back later in
> the CFG.
> 
> IE it pushed your store down to some later point in the CFG.


It's not the store that needs the clobber, it's the shift.  The R8C
can only use shift counts in the UPPER half of $r1, which totally
confuses the register allocator, so I just clobber $r1 in the insn and
do the move myself.

Re: store_motion query

[Steven Bosscher]

xf. http://gcc.gnu.org/ml/gcc/2008-05/msg00274.html

> Why is store_motion doing this?
>
> STORE_MOTION  delete insn in BB 2:
>   (insn 8 7 27 2 dj.c:10 (parallel [
> (set (mem/s/j:HI (reg/v/f:HI 26 [ s ]) [0 
> .buf+0 S2 A8])
> (ashift:HI (reg/v:HI 27 [ n ])
> (subreg:QI (reg/v:HI 27 [ n ]) 0)))
> (clobber (scratch:HI))
> ]) 223 {ashlhi3_i} (expr_list:REG_DEAD (reg/v:HI 27 [ n ])
> (nil)))
> STORE MOTION  replaced with insn:
>   (insn 27 8 9 2 dj.c:10 (set (reg:HI 29 [ .buf ])
> > (ashift:HI (reg/v:HI 27 [ n ])
> (subreg:QI (reg/v:HI 27 [ n ]) 0))) -1 
> (expr_list:REG_DEAD (reg/v:HI 27 [ n ])
> (nil)))

This insn is generated by gen_move_insn in gcse.c:replace_store_insn().

Maybe that should be emit_move_insn()?

Gr.
Steven

Recursive template inline functions (C++)

[Ling Li]

Somehow g++ 3.4.3 can compile all the attached C++ programs, but g++ 4.2.4 
can only compile the first one. I probably abused the template inline 
functions in a bad way, but anyway could someone help to explain what I did 
wrong?


= Case 1 =
template 
inline T f (T i) {
T j = i - 1;
return g(&j) + i;
}

template 
inline T g (T* i) {
if (*i == 0) return 0;
return f(*i);
}
=

Both g++ 3.4.3 and 4.2.4 know where to find g() while instantiate f().


= Case 2 (change the name of g() to f()) =
template 
inline T f (T i) {
T j = i - 1;
return f(&j) + i;
}

template 
inline T f (T* i) {
if (*i == 0) return 0;
return f(*i);
}
=

g++ 4.2.4 doesn't seem to know about the 2nd template function of f(), and 
keeps coerce int* into int:


fwd-template-inline2.cpp: In function T f(T) [with T = int]:
fwd-template-inline2.cpp:14:   instantiated from here
fwd-template-inline2.cpp:4: error: invalid conversion from int* to int
fwd-template-inline2.cpp: In function T f(T) [with T = int*]:
fwd-template-inline2.cpp:4:   instantiated from T f(T) [with T = int]
fwd-template-inline2.cpp:14:   instantiated from here
fwd-template-inline2.cpp:4: error: invalid operands of types int** and int* 
to binary operator+

fwd-template-inline2.cpp: In function T f(T) [with T = int**]:
fwd-template-inline2.cpp:4:   instantiated from T f(T) [with T = int*]
fwd-template-inline2.cpp:4:   instantiated from T f(T) [with T = int]
fwd-template-inline2.cpp:14:   instantiated from here
fwd-template-inline2.cpp:4: error: invalid operands of types int*** and 
int** to binary operator+

fwd-template-inline2.cpp: In function T f(T) [with T = int***]:
fwd-template-inline2.cpp:4:   instantiated from T f(T) [with T = int**]
fwd-template-inline2.cpp:4:   instantiated from T f(T) [with T = int*]
fwd-template-inline2.cpp:4:   instantiated from T f(T) [with T = int]
fwd-template-inline2.cpp:14:   instantiated from here
...


= Case 3 
#include 

template 
inline size_t f (const T* x) {
if (x) return f(*x);
return 0;
}

template 
inline size_t f (const std::vector& x) {
return x.size();
}
=

Similar to case 2, g++ 4.2.4 doesn't see the 2nd definition, and complains 
about no matching function.


fwd-template-inline3.cpp: In function size_t f(const T*) [with T = 
std::vector >]:

fwd-template-inline3.cpp:16:   instantiated from here
fwd-template-inline3.cpp:5: error: no matching function for call to f(const 
std::vector >&)



I understand that adding a forward declaration of the 2nd definition, like 
the line below, would solve the problem of Case 3 (and Case 2 as well).


template 
inline size_t f (const std::vector&);

However, I am not sure if the compiler would still honor the "inline" hint. 
Actually, I don't even know if including "inline" in the forward 
declaration make any sense, since forward declaration means the definition 
is not available at this moment.


And anyway, g++ 3.4.3 is quite happy with all cases, so it is confusing 
which g++ version actually does the correct thing.


Any opinions would be highly appreciated! Thanks!

--Ling
template 
inline T f (T i) {
T j = i - 1;
return g(&j) + i;
}

template 
inline T g (T* i) {
if (*i == 0) return 0;
return f(*i);
}

int main () {
return f(3);
}
template 
inline T f (T i) {
T j = i - 1;
return f(&j) + i;
}

template 
inline T f (T* i) {
if (*i == 0) return 0;
return f(*i);
}

int main () {
return f(3);
}
#include 

template 
inline size_t f (const T* x) {
if (x) return f(*x);
return 0;
}

template 
inline size_t f (const std::vector& x) {
return x.size();
}

int main () {
std::vector vd(10);
return f(&vd);
}

Re: store_motion query

[Steven Bosscher]

On Wed, May 21, 2008 at 11:41 PM, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> Maybe that should be emit_move_insn()?

OK, so that is not it.

The problem is that can_assign_to_reg_p() returns true when x is
(ashift:HI (reg/v:HI 27 [ n ]) (subreg:QI (reg/v:HI 27 [ n ]) 0)).
num_clobbers == 1 but added_clobbers_hard_reg_p returns false.

It seems to me that store motion is OK here, but I don't know who is
usually responsible for adding the clobbers...

Gr.
Steven

Re: store_motion query

[Steven Bosscher]

On Thu, May 22, 2008 at 12:06 AM, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> On Wed, May 21, 2008 at 11:41 PM, Steven Bosscher <[EMAIL PROTECTED]> wrote:
>> Maybe that should be emit_move_insn()?
>
> OK, so that is not it.
>
> The problem is that can_assign_to_reg_p() returns true when x is
> (ashift:HI (reg/v:HI 27 [ n ]) (subreg:QI (reg/v:HI 27 [ n ]) 0)).
> num_clobbers == 1 but added_clobbers_hard_reg_p returns false.
>
> It seems to me that store motion is OK here, but I don't know who is
> usually responsible for adding the clobbers

In the rest of gcse.c this works because of process_insert_insn(),
which uses insn_invalid_p() to add clobbers if necessary.

But it looks like update_ld_motion_stores() and insert_store() also
call gen_move_insn without adding clobbers if necessary. I suppose the
insns produced there should also go through insn_invalid_p somewhere.
I sent a hack for that to DJ, but I guess the proper place to fix this
is inside gcse.c itself.

Gr.
Steven

gcc-4.2-20080521 is now available

[gccadmin]

Snapshot gcc-4.2-20080521 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080521/
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 135740

You'll find:

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

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

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

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

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

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

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

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

Diffs from 4.2-20080514 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.

apparent memory increase

[Tom Tromey]

You may have seen this warning from the memory consumption tester:

http://gcc.gnu.org/ml/gcc-regression/2008-05/msg00041.html

... related to the recent identifier GC patch.

I looked into this a little.  My theory is that this is an artifact of
how the tester collects its data.  In particular I suspect the tester
was not including the identifier data in its memory stats -- but now,
because identifiers are allocated via the GC, they are included.

If this theory is in error, let me know and I will investigate some
more.  In this case, it would be helpful to have the script that
generates the report.

Tom

Re: GCC Compile Farm News: two new bi-quad core machines available

[NightStrike]

On 5/21/08, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Wed, May 21, 2008 at 10:45:15PM +0200, Laurent GUERBY wrote:
> > On Tue, 2008-05-20 at 11:25 +0200, Richard Guenther wrote:
> > > On Mon, May 19, 2008 at 8:50 PM, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> > > > Hi,
> > > >
> > > >  The GCC Compile Farm project is pleased to announce that two bi-quad
> > > >  core machines with the latest Opteron 8354 "Barcelona B3" processor and
> > > >  16GB of RAM donated by AMD are now available online in datacenter space
> > > >  kindly donated by INRIA Saclay.
> > >
> > > Isn't this worth an entry on the GCC news page?
> >
> > If there's consensus, I can certainly propose a patch.
>
> Please do.  We should thank people for significant contributions.
>
>

For this, I think Laurent deserves significant thanks, as well.

Re: GCC Compile Farm News: two new bi-quad core machines available

[Gerald Pfeifer]

On Tue, 20 May 2008, Richard Guenther wrote:
> Isn't this worth an entry on the GCC news page?

Yes, it certainly is!

On Wed, 21 May 2008, Laurent GUERBY wrote:
> If there's consensus, I can certainly propose a patch.

Please. :-)

On Wed, 21 May 2008, Joe Buck wrote:
> Please do.  We should thank people for significant contributions.

Fully agreed.  For some reason many here tend to be very shy when it
comes to that, so thanks for Richi for raising this in this case.

Gerald

Deprecating or removing protoize, fixproto, -aux-info

[Joseph S. Myers]

Following up on an IRC discussion:

* The protoize tool has not been built by default for many years, but is 
still included in the GCC tree (and every so often someone breaks it, 
because it isn't built by default).  Should we remove it from the GCC tree 
(or deprecate, then remove) and leave it to anyone wishing to use it to 
maintain a version somewhere else?  Someone volunteered a long time ago 
 to create an 
external version, but I don't think we should wait forever.

* Do we still need fixproto?  Again, it breaks from time to time because 
of patches only tested on non-fixproto systems.  Most of the targets set 
to use fixproto are generic targets such as *-*-elf; on such a target, 
it's the user's responsibility to produce a suitable set of headers, not 
GCC's to fix it, and if newlib is being used it's presumably OK without 
fixproto, because other such targets do not use it.

The following non-generic targets use fixproto after my removal of 
deprecated targets is applied:

hppa[12]*-*-hpux10*
m32r-*-linux*
m32rle-*-linux*
mips-sgi-irix[56]*
pdp11-*-bsd
rs6000-ibm-aix4.[12]* | powerpc-ibm-aix4.[12]*
sh*-* (a case with a lot of specific targets)

The only ones among those which I think might actually need fixproto are 
pdp11-*-bsd, mips-sgi-irix[56]* and the old versions of HP-UX and AIX.  
Could people using those targets comment on the state of the headers with 
regard to prototypes, what fixproto does on them, how much of that is 
needed, and whether it could sensibly be moved into fixincludes rules 
specific to those targets?  (I'm inclined to think we could at least say 
that the use of fixproto is deprecated, remove it from all the targets 
except those few that might need it, and remove it in 4.5 along with any 
targets that haven't stopped using it; but maybe it's possible to remove 
it before then.)

* protoize and fixproto are entangled with several other files, makefile 
rules and features it might be possible to get rid of together, including 
at least the -aux-info option, sys-protos.h, sys-types.h, scan-types.sh, 
sort-protos, fix-header, protoize, SYSCALLS.c.X.  There was some 
suggestion on IRC, however, that the -aux-info option might have other 
uses.  Do people think this option is useful to keep if we get rid of 
protoize and fixproto?  There have been discussions of ways of exporting 
much more structured data from GCC, and GCC variants to do so - but 
nothing much that so far looks likely to enter official GCC.  A 
complication is that an external protoize might still need -aux-info, 
unless reimplemented to avoid needing this option.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

About the gcc Warning: setting incorrect section attributes for .note

[XU SHENG]

Hi community,
I want to add a note section in a ELF formatted file to
indentify some private information. So I declare a private variable in a
single c file use attribute like this:
int priv_dat  __attribute__ ((section(".note"))) = MAGIC;

while compile it using gcc 3.4.3, the compiler output following
warnings:

/tmp/cc7Q0lRs.s: Assembler messages:
/tmp/cc7Q0lRs.s:11: Warning: setting incorrect section
attributes for .note

It's clear to me that only section marked attribute with the
startup of ".note" can be compiled to section with type SHT_NOTE in ELF
file. Then only problem is assembler in gcc assumed ".note" section as
"aw" (allocate/write) as default property, but actually, the .note
section can be only marked with "a" (note section is readonly). If I
modify the temporary .s export by gcc assembler by delete "w" property,
the warning is disappeared.

I wonder if any processes can be done for remove this warning?
Because gcc variable attribute can not set detail section property.
Thanks. 

Best Regards
Edison Xu