RE: Inefficient loop unrolling.

2008-07-03 Thread Bingfeng Mei
Steven,
I just created a bug report. You should receive a CCed mail now.

I can see these issues are solvable at RTL-level, but require lots of
efforts. The main optimization in loop unrolling pass, split iv, can
reduce dependence chain but not extra ADDs and alias issue. What is the
main reason that loop unrolling should belong to RTL level? Is it
fundamental?

Cheers,
Bingfeng

-Original Message-
From: Steven Bosscher [mailto:[EMAIL PROTECTED] 
Sent: 02 July 2008 17:01
To: Bingfeng Mei
Cc: gcc@gcc.gnu.org
Subject: Re: Inefficient loop unrolling.

On Wed, Jul 2, 2008 at 1:13 PM, Bingfeng Mei <[EMAIL PROTECTED]> wrote:
> Hello,
> I am looking at GCC's loop unrolling and find it quite inefficient
> compared with manually unrolled loop even for very simple loop. The
> followings are a simple loop and its manually unrolled version. I
didn't
> apply any trick on manually unrolled one as it is exact replications
of
> original loop body. I have expected by -funroll-loops the first
version
> should produce code of similar quality as the second one. However,
> compiled with ARM target of mainline GCC, both functions produce very
> different results.
>
> GCC-unrolled version mainly suffers from two issues. First, the
> load/store offsets are registers. Extra ADD instructions are needed to
> increase offset over iteration. In the contrast, manually unrolled
code
> makes use of immediate offset efficiently and only need one ADD to
> adjust base register in the end. Second, the alias (dependence)
analysis
> is over conservative. The LOAD instruction of next unrolled iteration
> cannot be moved beyond previous STORE instruction even they are
clearly
> not aliased. I suspect the failure of alias analysis is related to the
> first issue of handling base and offset address. The .sched2 file
shows
> that the first loop body requires 57 cycles whereas the second one
takes
> 50 cycles for arm9 (56 cycles vs 34 cycles for Xscale).  It become
even
> worse for our VLIW porting due to longer latency of MUL and Load
> instructions and incapability of filling all slots (120 cycles vs. 20
> cycles)

Both issues should be solvable for RTL (where unrolling belongs IMHO).
 If you file a PR in bugzilla (with this test case, target, compiler
options, etc), I promise I will analyze why we don't fold away the
ADDs, and why the scheduler doesn't glob the loads (may be due to bad
alias analysis, but maybe something else is not working properly).

Gr.
Steven




Re: gcc-in-cxx branch created

2008-07-03 Thread Hendrik Boom
Thank you for your thoughtful and patient reply.  I should probably 
apologize for the strident tone of my first letter to this mailing list.  
It reflects a decades-long frustration with the trends in the computer 
industry, rather than a specific critique of ggc development itself.  Gcc 
is a wonderful compiler, and has done a lot for the liberation of 
programming from proprietary shackles.  I am in awe of what its 
developers have accomplished.


On Thu, 03 Jul 2008 02:50:11 -0400, Daniel Berlin wrote:

> On Wed, Jul 2, 2008 at 2:30 PM, Hendrik Boom <[EMAIL PROTECTED]>
> wrote:
>>
>> There are a number of languages that would probably be better-suited to
>> programming gcc than C or C++, on technical grounds alone.
> 
> 
> That's great.
> We have more than just technical concerns.

I agree.

> 
>>   But if it is a requirement for using a language that everyone
>> already knows it, we will forever be doomed to C and its insecure
>> brethren.
>>
> This has never been listed as a requirement. It is certainly a
> consideration.
> The main requirement for communities like GCC for something like
> changing languages is consensus or at least a large set of active
> developers willing to do something and the rest of them willing to not
> commit suicide if it happens.
> There are secondary requirements like "not stalling for years while
> moving languages", "not losing serious performance", etc.
> 
> You are free to propose whatever language you like. It is unlikely you
> will get support from any of the active contributors simply saying we
> should use X because Y.
> The best way to show us the advantages of using some other languages is
> to convert some part of GCC to use it and show how much better it is.
> 
> This is a big job, of course.  Then again, tree-ssa was started by diego
> as a side project, and gained supporters and helpers as others decided
> to spend their time on it.
> You may find the same thing, in which case you may find it is not hard
> to convince people to move to some other language. You may find nobody
> agrees with you, even after seeing parts of gcc in this new language.
> I can guarantee you you will find nobody agrees with you if you sit on
> the sidelines and do nothing but complain.
> 
> --Dan

I first started using C and Algol 68 in 1975 -- C on a PDP-11, and Algol 
68 on a CDC Cyber.  Without doubt, Algol 68 was a better language for 
most programming, but its operating environment (the NOS operating 
system) was so hostile that I preferred the PDP-11 (with Unix).  It has 
been the Unix operating system that has carried C to the ubiquitous 
presence it has today.

C is a 30-year-old language.  Most people adopt C nowadays because 
everyone else is using it, even though there are much better 20-year-old 
languages available.  I've spent years of my life tracking down dangling 
pointers in other people's C code while hired to do development on 
existing projects, all the while remembering that the first program I 
wrote in Algol 68 was over a thousand lines long, contained complicated 
data structures, and ran correctly the first time it passed through the 
compiler without compile-time diagnostics.

Don't get me wrong.  I can write C.  I can write C++.  I've even written 
a substantial part of a C++ implementation in C++.

That said, I understand the inertia of an existing code base.  Gcc is as 
much the victim of the curse of compatibility as a multitude of other 
projects.  C++ is a big improvement over C, if you can restrict yourself 
to a comprehensible subset (as you are apparently attempting to do).  And 
it has, qua inertia, the enormous advantage that it's possible to 
incrementally move a large project from C to C++.

But I am still frustrated by the enormous pain the industry inflict on 
itself by persisting is using such flawed tools for new projects.

-- hendrik



Bootstrap failures due to C++ warnings with --enable-gather-detailed-memory-stats

2008-07-03 Thread Diego Novillo
Kaveh,

I'm testing trunk as of revision 137346 with
--enable-gather-detailed-memory-stats and I'm getting a bootstrap
failure due to C++ cast problems.  Since you've been hacking at this
and added the stricter checking, could you fix the invalid casts?  If
not, I may try to produce a patch soonish.


Thanks.  Diego.


Re: Feature request - a macro defined for GCC

2008-07-03 Thread Jim Wilson

x z wrote:

If we want to fix this, gcc must change. And this may
also require GNU libc changes and linux kernel changes, etc.
Maybe you can enlighten us a bit on why GNU libc and linux kernel need 
changes so that we can realize better how complicated the issue is.


Because there are header files in /usr/include that test __GNUC__.  In 
order for these header files to do the right thing, the Intel compiler 
(and other compilers) need to define __GNUC__.


Now suppose we add a new macro __GCC_COMPILER__ that is intended to be 
unambiguous, and mean only that this is the GCC compiler.  What happens 
next?  Within a few months, someone will post a patch to glibc and/or 
the linux kernel that uses __GCC_COMPILER__, based on the misconception 
that because it is new, that they are supposed to use it.  A few months 
later, there is a glibc release and/or linux kernel release that 
contains this code.  A few months later it gets into a linux release. 
Then Intel discovers that their compiler no longer works as intended on 
linux, and in order to fix it, they have to define __GCC_COMPILER__. 
And now we are back where we started, except now we have two useless 
ambiguous macros instead of one, and hence we are worse off than before.


If we want to make progress on this issue, we need to get people to 
understand what the underlying problem is first, and adopt changes that 
will lead to a solution, otherwise adding new macros is futile.


One thing I haven't seen you answer yet is why you think you need a 
macro that uniquely identifies GCC.  If the Intel compiler correctly 
implements the GNU C language, then it should not matter whether the 
code is being compiled by GCC or ICC.  I think it would help the 
discussion if you could give a specific testcase where this matters.


Jim


Re: Feature request - a macro defined for GCC

2008-07-03 Thread Chris Lattner


On Jul 3, 2008, at 9:01 AM, Jim Wilson wrote:


x z wrote:

If we want to fix this, gcc must change. And this may
also require GNU libc changes and linux kernel changes, etc.
Maybe you can enlighten us a bit on why GNU libc and linux kernel  
need changes so that we can realize better how complicated the  
issue is.


Because there are header files in /usr/include that test __GNUC__.   
In order for these header files to do the right thing, the Intel  
compiler (and other compilers) need to define __GNUC__.


Now suppose we add a new macro __GCC_COMPILER__ that is intended to  
be unambiguous, and mean only that this is the GCC compiler.  What  
happens next?  Within a few months, someone will post a patch to  
glibc and/or the linux kernel that uses __GCC_COMPILER__, based on  
the misconception that because it is new, that they are supposed to  
use it.  A few months later, there is a glibc release and/or linux  
kernel release that contains this code.  A few months later it gets  
into a linux release. Then Intel discovers that their compiler no  
longer works as intended on linux, and in order to fix it, they have  
to define __GCC_COMPILER__. And now we are back where we started,  
except now we have two useless ambiguous macros instead of one, and  
hence we are worse off than before.


IMO, the whole notion of a compiler-specific macro has pretty limited  
usefulness.  Why not add macros for specific *features* offered by the  
compiler.  For example:


#ifdef __SUPPORTS_NESTED_FUNCTIONS__

is much better than some mismash of version checking, which isn't  
guaranteed to be right in the future.  One disadvantage of this is  
that it will put even more burden on the already overloaded  
preprocessor.  It would be much nicer to have a feature query system  
that doesn't rely on one macro per system.  Perhaps something like:


#if __feature_supported(nested_functions) &&  
__feature_supported(transparent_union) &&  
__feature_supported(attribute_aligned)

...

Taking an approach reduces startup time of the preprocessor, because  
it doesn't have to populate the identifier table with tons of  
predefines.


-Chris



handle preserving gcov

2008-07-03 Thread Robert Henry
I'm pondering some extension to gcov and its compile-time and run-time support.

I want to be able to run an unchanging instrumented victim binary
multiple times.  Each time I run the victim binary I have a
unique invocation handle.  The handle can be an integer; some client
of gcov and the driver can map integers to names.

I'd like to add a 2nd column to the gcov statement profile output that
shows some invocation handle, where the handle is chosen from the
first (or last, or most frequent) victim invocation to execute the
statement.

This way I can look at the statement profile output and determine
which invocation I should rerun in order to get some desired behaviour
out of the victim program.

Case in point: the victim is gcc.  The invocation handle is a hash of
the test program's name from some test suite.  The question at hand is
"which test program causes gcc to execute this statement inside of
gcc?".

Has anybody in the gcov developer community pondered  or done such a thing?

Robert Henry
Google


Re: Feature request - a macro defined for GCC

2008-07-03 Thread Andrew Haley
Chris Lattner wrote:

> IMO, the whole notion of a compiler-specific macro has pretty limited
> usefulness.  Why not add macros for specific *features* offered by the
> compiler.  For example:
> 
> #ifdef __SUPPORTS_NESTED_FUNCTIONS__
> 
> is much better than some mismash of version checking, which isn't
> guaranteed to be right in the future.

Yeah, but in the absence of an external specification of the syntax it'd
have to be __SUPPORTS_GNU_NESTED_FUNCTIONS__.  Hmm, looks like this could
get very messy, very quickly; I don't think you could do this in any
effective way without some compiler-independent organization to define
these macros.

Andrew.


Re: handle preserving gcov

2008-07-03 Thread Janis Johnson
On Thu, 2008-07-03 at 09:37 -0700, Robert Henry wrote:
> I'm pondering some extension to gcov and its compile-time and run-time 
> support.
> 
> I want to be able to run an unchanging instrumented victim binary
> multiple times.  Each time I run the victim binary I have a
> unique invocation handle.  The handle can be an integer; some client
> of gcov and the driver can map integers to names.
> 
> I'd like to add a 2nd column to the gcov statement profile output that
> shows some invocation handle, where the handle is chosen from the
> first (or last, or most frequent) victim invocation to execute the
> statement.
> 
> This way I can look at the statement profile output and determine
> which invocation I should rerun in order to get some desired behaviour
> out of the victim program.
> 
> Case in point: the victim is gcc.  The invocation handle is a hash of
> the test program's name from some test suite.  The question at hand is
> "which test program causes gcc to execute this statement inside of
> gcc?".
> 
> Has anybody in the gcov developer community pondered  or done such a thing?

I once helped with the development of some proprietary code
coverage tools that let you keep multiple sets of data and
get various combinations of them, or subtract one set from
another, and then look at the results to find out which sets
of tests covered which lines of code.  I think we used
environment variables to add prefixes or suffixes to the data
files.

Janis



Re: Feature request - a macro defined for GCC

2008-07-03 Thread Chris Lattner


On Jul 3, 2008, at 10:01 AM, Andrew Haley wrote:


Chris Lattner wrote:


IMO, the whole notion of a compiler-specific macro has pretty limited
usefulness.  Why not add macros for specific *features* offered by  
the

compiler.  For example:

#ifdef __SUPPORTS_NESTED_FUNCTIONS__

is much better than some mismash of version checking, which isn't
guaranteed to be right in the future.


Yeah, but in the absence of an external specification of the syntax  
it'd

have to be __SUPPORTS_GNU_NESTED_FUNCTIONS__.


The feature names should be independent of the set of compilers that  
happen to implement them, that's the whole point.  Consider:


#ifdef __SUPPORTS_GNU_CXX_MIN_MAX_OPERATORS__

Mainline GCC doesn't support "GNU" min max operators!   GCC adds and  
removes extensions, and other compilers have good support for subsets  
of the GCC extensions.  Obviously if Intel is defining __GNUC__ with  
moderate success, then they implement whatever extensions the macro is  
guarding.



Hmm, looks like this could
get very messy, very quickly; I don't think you could do this in any
effective way without some compiler-independent organization to define
these macros.


Huh?  Why not?

-Chris


Re: Feature request - a macro defined for GCC

2008-07-03 Thread Basile STARYNKEVITCH

Jim Wilson wrote:

x z wrote:

If we want to fix this, gcc must change. And this may
also require GNU libc changes and linux kernel changes, etc.
Maybe you can enlighten us a bit on why GNU libc and linux kernel need 
changes so that we can realize better how complicated the issue is.


Because there are header files in /usr/include that test __GNUC__.  In 
order for these header files to do the right thing, the Intel compiler 
(and other compilers) need to define __GNUC__.


Now suppose we add a new macro __GCC_COMPILER__ that is intended to be 
unambiguous, and mean only that this is the GCC compiler.  What happens 
next?  Within a few months, someone will post a patch to glibc and/or 
the linux kernel that uses __GCC_COMPILER__, based on the misconception 
that because it is new, that they are supposed to use it. 



I fully agree with the argument, but I'll add a caveat.

The __GNUC__ macro serves two different purposes:

1. permitting the extremely useful GCC languages extensions which, for 
sad and various reasons, did not enter any official C standard (in 
particular, computed gotos, statement exprs, typeof). We might add 
the extended asm instruction here also. I guess it is the most common 
use of __GNUC__.


2. selecting one way of expressing (in perfectly usual C code) instead 
of another which fits well with the GCC compiler in particular. I've got 
no concrete example, but I could imagine some code like


#ifdef __GNUC__
int twice(int x) { return x*2; }
#else
int twice(int x) { return x<<1; }
#endif

Of course, the above example is very stupid, but I hope you get my 
point. I expect this kind of use to be very rare.


And I agree that the separation is a bit fuzzy. Some people could argue 
that some __builtin fits in between the two points.


Maybe we should separate the two roles above, and most importantly 
*document* them, We might perhaps:


leave the __GNUC__ macro for the first role (GCC language extensions), 
and perhaps define a __GCC_COMPILER__ macro for the second role, by 
documenting it appropriately, and prohibiting any way of defining it 
[except by patching the source code of GCC].


Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***


Re: Feature request - a macro defined for GCC

2008-07-03 Thread Ralf Wildenhues
Hello,

>> Chris Lattner wrote:
>>
>>> IMO, the whole notion of a compiler-specific macro has pretty limited
>>> usefulness.  Why not add macros for specific *features* offered by  
>>> the compiler.  For example:
>>>
>>> #ifdef __SUPPORTS_NESTED_FUNCTIONS__
[...]
>> Hmm, looks like this could
>> get very messy, very quickly; I don't think you could do this in any
>> effective way without some compiler-independent organization to define
>> these macros.

I feel like I'm stating the obvious, but maybe you're just trying to
rediscover feature-based tests: do a test compile that exposes the
compiler bug or feature you're looking for.

Autoconf provides a framework that supports this kind of testing, among
others.

Cheers,
Ralf


Re: Feature request - a macro defined for GCC

2008-07-03 Thread Paul Koning
> "Ralf" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:

 Ralf> I feel like I'm stating the obvious, but maybe you're just
 Ralf> trying to rediscover feature-based tests: do a test compile
 Ralf> that exposes the compiler bug or feature you're looking for.

 Ralf> Autoconf provides a framework that supports this kind of
 Ralf> testing, among others.

Autoconf is a massively cryptic and complicated way to make up for the
lack of "I have feature X" CPP flags in the compiler.

Chris is right, that's the correct way to do things.

  paul



Re: Feature request - a macro defined for GCC

2008-07-03 Thread Chris Lattner


On Jul 3, 2008, at 10:50 AM, Ralf Wildenhues wrote:


Hello,


Chris Lattner wrote:

IMO, the whole notion of a compiler-specific macro has pretty  
limited

usefulness.  Why not add macros for specific *features* offered by
the compiler.  For example:

#ifdef __SUPPORTS_NESTED_FUNCTIONS__

[...]

Hmm, looks like this could
get very messy, very quickly; I don't think you could do this in any
effective way without some compiler-independent organization to  
define

these macros.


I feel like I'm stating the obvious, but maybe you're just trying to
rediscover feature-based tests: do a test compile that exposes the
compiler bug or feature you're looking for.

Autoconf provides a framework that supports this kind of testing,  
among

others.


That doesn't work for system headers.

-Chris


Re: Feature request - a macro defined for GCC

2008-07-03 Thread Joseph S. Myers
On Thu, 3 Jul 2008, Basile STARYNKEVITCH wrote:

> The __GNUC__ macro serves two different purposes:
> 
> 1. permitting the extremely useful GCC languages extensions which, for sad and
> various reasons, did not enter any official C standard (in particular,
> computed gotos, statement exprs, typeof). We might add the extended asm
> instruction here also. I guess it is the most common use of __GNUC__.

Note that the view was expressed at the London WG14 meeting (going through 
a list of extensions considering what might be worth putting in C1x) that 
statement expressions and typeof might be worth standardising.  This does 
not of course mean that anyone will produce a concrete proposal to add 
appropriate words to the standard, or that such a proposal will be 
accepted for C1x.

-- 
Joseph S. Myers
[EMAIL PROTECTED]


Re: [10 PATCHES] inline functions to avoid stack overflow

2008-07-03 Thread Mikulas Patocka

On Tue, 1 Jul 2008, David Miller wrote:


From: Mikulas Patocka <[EMAIL PROTECTED]>
Date: Wed, 2 Jul 2008 00:39:35 -0400 (EDT)


The ABI is very vague about it. The V9 ABI just displays that 6-word space
in a figure bug doesn't say anything about it's usage. The V8 ABI just
says that "the function may write incoming arguments there". If it may
write anything other, it is unknown --- probably yes, but it is not said
in the document.

The document nicely specifies who owns which registers, but doesn't say
that about the stack space :-(


Actually, I know for a fact that you have to have those slots there.

A long time ago in the sparc64 kernel, in the trap entry code, I tried
only giving 128 bytes of stack frame as the trap entry called into C
code.  And it did not work, I had to put the 6 slots there.


The bad thing is that gcc can't use those slots optimally. If you have for 
example:


void f(int *x)
{
}

void g()
{
int a;
f(&a);
}

void h()
{
g();
}

Then the variable "a" can't be placed into one of the 6 implicit slots for 
g->f call (beacuse "f" may overwrite that slot). But "a" could be placed 
into one of those 6 slots that "h" allocates for "g" (because these slots 
are owned by "g"). But it isn't --- additional place is allocated for "a" 
:-/


Mikulas


Re: Feature request - a macro defined for GCC

2008-07-03 Thread Josh Triplett
[Adding the Sparse mailing list to CC.]

On Thu, 2008-07-03 at 09:37 -0700, Chris Lattner wrote:
> IMO, the whole notion of a compiler-specific macro has pretty limited  
> usefulness.  Why not add macros for specific *features* offered by the  
> compiler.  For example:
> 
> #ifdef __SUPPORTS_NESTED_FUNCTIONS__
> 
> is much better than some mismash of version checking, which isn't  
> guaranteed to be right in the future.  One disadvantage of this is  
> that it will put even more burden on the already overloaded  
> preprocessor.  It would be much nicer to have a feature query system  
> that doesn't rely on one macro per system.  Perhaps something like:
> 
> #if __feature_supported(nested_functions) &&  
> __feature_supported(transparent_union) &&  
> __feature_supported(attribute_aligned)
> ...
> 
> Taking an approach reduces startup time of the preprocessor, because  
> it doesn't have to populate the identifier table with tons of  
> predefines.

Speaking as the maintainer of Sparse, I would love to see GCC adopt
such an approach.  I don't like that Sparse currently has to define GNUC
and other such macros, and impersonate a GCC version that implies
support for the GCC extensions it has.  While that support probably
needs to stick around for backward compatibility, I'd much rather have
Sparse support some new feature-testing construct.

I'd suggest defining exactly one new preprocessor symbol, to advertise
the support for the feature-testing mechanism.  For instance,
__HAVE_EXTENSION_SUPPORTED__, or __FEATURE_SUPPORTED_SUPPORTED__. :)
The rest could use syntax like you suggest above.  For instance:

#ifdef __HAVE_EXTENSION_SUPPORTED__
#if __have_extension__(noreturn)
#define ATTR_NORETURN __extension__((noreturn))
#endif
#if __have_extension__(sentinel)
#define ATTR_SENTINEL __extension__((sentinel))
#endif
#endif
#ifndef ATTR_NORETURN
#define ATTR_NORETURN
#endif
#ifndef ATTR_SENTINEL
#define ATTR_SENTINEL
#endif

The same thing would work for Sparse extensions:

#ifdef __HAVE_EXTENSION_SUPPORTED__
#if __have_extension__(address_space) && __have_extension__(noderef)
#define __user __extension__((address_space(1),noderef))
#endif
#endif
#ifndef __user
#define __user
#endif

The only problem then becomes maintaining the canonical list of
extension names.  We could use the ugly approach of names like
"org.gnu.gcc.extension.sentinel" and "org.kernel.sparse.address_space",
but that seems entirely too ugly.  The other alternative seems like a
central registry of extension names; I'd happily help maintain such a
registry.

Thoughts?

- Josh Triplett




Re: Feature request - a macro defined for GCC

2008-07-03 Thread Chris Lattner

On Jul 3, 2008, at 2:12 PM, Josh Triplett wrote:

I'd suggest defining exactly one new preprocessor symbol, to advertise
the support for the feature-testing mechanism.  For instance,
__HAVE_EXTENSION_SUPPORTED__, or __FEATURE_SUPPORTED_SUPPORTED__. :)
The rest could use syntax like you suggest above.  For instance:



Sure.  The idea was that you'd do something like:

#ifndef __FEATURE_SUPPORTED_SUPPORTED__  /* or whatever :) */
#define has_extension(x) 0
#else
#define has_extension(x) __has_extension__(x)
#endif

which allows you to use "#if has_extension(typeof)" in your code  
portably.


In fact, it would be easy to make __has_extension__ actually be a  
macro itself, allowing one to say:


#ifdef __has_extension__
...

which is even more clear.


The only problem then becomes maintaining the canonical list of
extension names.  We could use the ugly approach of names like
"org.gnu.gcc.extension.sentinel" and  
"org.kernel.sparse.address_space",

but that seems entirely too ugly.  The other alternative seems like a
central registry of extension names; I'd happily help maintain such a
registry.


I have no opinion on an approach, but I agree that it would be good to  
have a centralized list.  I would definitely add support for this to  
Clang.


-Chris


Re: Feature request - a macro defined for GCC

2008-07-03 Thread Joseph S. Myers
On Thu, 3 Jul 2008, Chris Lattner wrote:

> is much better than some mismash of version checking, which isn't guaranteed
> to be right in the future.  One disadvantage of this is that it will put even
> more burden on the already overloaded preprocessor.  It would be much nicer to
> have a feature query system that doesn't rely on one macro per system.
> Perhaps something like:
> 
> #if __feature_supported(nested_functions) &&
> __feature_supported(transparent_union) &&
> __feature_supported(attribute_aligned)
> ...

This looks rather like a reinvention of the #assert system (which is 
deprecated, or at least recommended against in the manual).

> Taking an approach reduces startup time of the preprocessor, because it
> doesn't have to populate the identifier table with tons of predefines.

I'd hope this is not a significant cost (certainly not compared to the 
thousands of built-in functions on some target), though I haven't seen 
recent figures for startup costs.

We have some existing practice for feature macros (__GNUC_GNU_INLINE__, 
__GNUC_STDC_INLINE__, __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1, ...).

-- 
Joseph S. Myers
[EMAIL PROTECTED]


question about the ddg construction

2008-07-03 Thread Tianwei
Hi, all,
My current project wants to reuse DDG's infrastructure to get some
loop carried dependency information, I debug these code for a while,
but have some questions, Hope you can
give me some suggestions.

1. my platform is X86,  and gcc version is 4.3.1, when i use -fsms,
and debug the code, found that for the following code, if always
return NULL_RTX:

  /* Make sure this is a doloop.  */
  if ( !(count_reg = doloop_register_get (head, tail)))
  {
if (dump_file)
  fprintf (dump_file, "SMS doloop_register_get failed\n");
continue;
  }

when I check the doloop_register_get, and found that it's guarded by a
ifdef "HAVE_doloop_end", even i make clobber the whole compiler,
rebuild the compiler by "CFLAGS='-DHAVE_doloop_end'", it still will
complain error, can't find the gen_doloop_end.

so the first question is:  does SMS is support on X86?

2. because of the problem(1) , i just comment out the above code and
continue to debug the create_ddg code to see how these code work.
but for the following code, i don't know if it does the right thing:

testcase is:
  float dot_product(float *a, float *b)
{
  int i; float c = 0;
  for ( i  = 0; i < 100; i ++)
c += a[i] + b[i];

  return c;

}


the RTL  for the a[i] + b[i] is:

a:$68 = *($65 + 62)
(insn:HI 14 13 15 3 mod.c:5 (set (reg:SF 68)
(mem:SF (plus:DI (reg/v/f:DI 65 [ a ])
(reg:DI 62 [ ivtmp.22 ])) [2 S4 A32])) 97 {*movsf_1} (nil))


b.  $68 = $68 + *( $66 + $62)

(insn:HI 15 14 16 3 mod.c:5 (set (reg:SF 68)
(plus:SF (reg:SF 68)
(mem:SF (plus:DI (reg/v/f:DI 66 [ b ])
(reg:DI 62 [ ivtmp.22 ])) [2 S4 A32]))) 669
{*fop_sf_comm_sse} (nil))


it should be only  REG_DEP there, no MEM_DEP, but the ddg construction
will assert there are MEM_DEP between these two insn.
the problem is:
2.a
in ddg construction, it will use   sched_analyze (&tmp_deps, head,
tail)  to compute all intra-loop dependency,  also it  can get right
result for this case
and then it use the following statement to create ddg edge:

 create_ddg_dep_from_intra_loop_link (g, src_node, dest_node, dep)

in this function:(ddg.c)
static void
create_ddg_dep_from_intra_loop_link (ddg_ptr g, ddg_node_ptr src_node,
 ddg_node_ptr dest_node, dep_t link)
{
  dep_type t = TRUE_DEP;
  dep_data_type dt = (mem_access_insn_p (src_node->insn)
  && mem_access_insn_p (dest_node->insn) ? MEM_DEP
 : REG_DEP);
}

here the source is instruction 15, and dest is instruction 14, link is
compute from sched_analyze,
(gdb) p DEP_TYPE(link)
$73 = REG_DEP_TRUE

but dt will be set as MEM_DEP because both these two instruction is
mem_access_insn, but they are both read, and no mem dependency,
however  there're really REG dependency between these instruction for
pseduo register $68

is that by designed or i missed something?



3. the final question is there any existed optimization phase which
use ddg's code beside sms?



thanks very much.

Tianwei


Re: Feature request - a macro defined for GCC

2008-07-03 Thread Chris Lattner

On Jul 3, 2008, at 3:01 PM, Joseph S. Myers wrote:
Taking an approach reduces startup time of the preprocessor,  
because it
doesn't have to populate the identifier table with tons of  
predefines.


I'd hope this is not a significant cost (certainly not compared to the
thousands of built-in functions on some target), though I haven't seen
recent figures for startup costs.


I was referring to clang startup times, not GCC.  clang registers  
builtins completely lazily, so they don't take significant time at  
startup.  Much of clang startup time is populating the predefined  
identifier table for macros.


We have some existing practice for feature macros  
(__GNUC_GNU_INLINE__,

__GNUC_STDC_INLINE__, __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1, ...).


Understood.  Likewise many system headers have these.  I don't think  
we can eliminate existing macros, but adding a plethora of new macros  
would be bad.


-Chris


Re: question about the ddg construction

2008-07-03 Thread Steven Bosscher
On Fri, Jul 4, 2008 at 12:05 AM, Tianwei <[EMAIL PROTECTED]> wrote:
> Hi, all,
>My current project wants to reuse DDG's infrastructure to get some
> loop carried dependency information, I debug these code for a while,
> but have some questions, Hope you can
> give me some suggestions.
>
> 1. my platform is X86,  and gcc version is 4.3.1, when i use -fsms,
> and debug the code, found that for the following code, if always
> return NULL_RTX:
>
>  /* Make sure this is a doloop.  */
>  if ( !(count_reg = doloop_register_get (head, tail)))
>  {
>if (dump_file)
>  fprintf (dump_file, "SMS doloop_register_get failed\n");
>continue;
>  }
>
> when I check the doloop_register_get, and found that it's guarded by a
> ifdef "HAVE_doloop_end", even i make clobber the whole compiler,
> rebuild the compiler by "CFLAGS='-DHAVE_doloop_end'", it still will
> complain error, can't find the gen_doloop_end.
>
> so the first question is:  does SMS is support on X86?

No. the x86 backend has no doloop insn pattern.  To see what that
means, see loop-doloop.c, and look for doloop in
http://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html.

Gr.
Steven


gcc-4.3-20080703 is now available

2008-07-03 Thread gccadmin
Snapshot gcc-4.3-20080703 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080703/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

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

You'll find:

gcc-4.3-20080703.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.3-20080703.tar.bz2 C front end and core compiler

gcc-ada-4.3-20080703.tar.bz2  Ada front end and runtime

gcc-fortran-4.3-20080703.tar.bz2  Fortran front end and runtime

gcc-g++-4.3-20080703.tar.bz2  C++ front end and runtime

gcc-java-4.3-20080703.tar.bz2 Java front end and runtime

gcc-objc-4.3-20080703.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.3-20080703.tar.bz2The GCC testsuite

Diffs from 4.3-20080626 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.3
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.


Re: Bootstrap failures due to C++ warnings with --enable-gather-detailed-memory-stats

2008-07-03 Thread Kaveh R. GHAZI
On Thu, 3 Jul 2008, Diego Novillo wrote:

> Kaveh,
>
> I'm testing trunk as of revision 137346 with
> --enable-gather-detailed-memory-stats and I'm getting a bootstrap
> failure due to C++ cast problems.  Since you've been hacking at this
> and added the stricter checking, could you fix the invalid casts?  If
> not, I may try to produce a patch soonish.
> Thanks.  Diego.

Actually it's --enable-gather-detailed-mem-stats ("mem" not "memory"),
this threw me for a while as I was unable to reproduce any failures until
I figured that out. :-)

Patch completed bootstrapped on x86_64-unknown-linux-gnu configured with
--enable-gather-detailed-mem-stats.  Okay for mainline?

--Kaveh


2008-07-03  Kaveh R. Ghazi  <[EMAIL PROTECTED]>

* alloc-pool.c (hash_descriptor, eq_descriptor,
alloc_pool_descriptor): Fix -Wc++-compat warnings.
* bitmap.c (hash_descriptor, eq_descriptor, bitmap_descriptor):
Likewise.
* ggc-common.c (hash_descriptor, eq_descriptor, hash_ptr, eq_ptr,
loc_descriptor, ggc_prune_ptr, ggc_free_overhead,
final_cmp_statistic, cmp_statistic, dump_ggc_loc_statistics):
Likewise.
* varray.c (hash_descriptor, eq_descriptor, varray_descriptor):
Likewise.

diff -rup orig/egcc-SVN20080703/gcc/alloc-pool.c 
egcc-SVN20080703/gcc/alloc-pool.c
--- orig/egcc-SVN20080703/gcc/alloc-pool.c  2008-06-29 07:37:45.0 
+0200
+++ egcc-SVN20080703/gcc/alloc-pool.c   2008-07-03 19:18:54.0 +0200
@@ -81,13 +81,15 @@ static htab_t alloc_pool_hash;
 static hashval_t
 hash_descriptor (const void *p)
 {
-  const struct alloc_pool_descriptor *d = p;
+  const struct alloc_pool_descriptor *const d =
+(const struct alloc_pool_descriptor * )p;
   return htab_hash_pointer (d->name);
 }
 static int
 eq_descriptor (const void *p1, const void *p2)
 {
-  const struct alloc_pool_descriptor *d = p1;
+  const struct alloc_pool_descriptor *const d =
+(const struct alloc_pool_descriptor *) p1;
   return d->name == p2;
 }

@@ -106,7 +108,7 @@ alloc_pool_descriptor (const char *name)
  1);
   if (*slot)
 return *slot;
-  *slot = xcalloc (sizeof (**slot), 1);
+  *slot = XCNEW (struct alloc_pool_descriptor);
   (*slot)->name = name;
   return *slot;
 }
diff -rup orig/egcc-SVN20080703/gcc/bitmap.c egcc-SVN20080703/gcc/bitmap.c
--- orig/egcc-SVN20080703/gcc/bitmap.c  2008-07-03 02:00:18.0 +0200
+++ egcc-SVN20080703/gcc/bitmap.c   2008-07-03 19:21:22.0 +0200
@@ -51,7 +51,8 @@ static htab_t bitmap_desc_hash;
 static hashval_t
 hash_descriptor (const void *p)
 {
-  const struct bitmap_descriptor *const d = p;
+  const struct bitmap_descriptor *const d =
+(const struct bitmap_descriptor *) p;
   return htab_hash_pointer (d->file) + d->line;
 }
 struct loc
@@ -63,8 +64,9 @@ struct loc
 static int
 eq_descriptor (const void *p1, const void *p2)
 {
-  const struct bitmap_descriptor *const d = p1;
-  const struct loc *const l = p2;
+  const struct bitmap_descriptor *const d =
+(const struct bitmap_descriptor *) p1;
+  const struct loc *const l = (const struct loc *) p2;
   return d->file == l->file && d->function == l->function && d->line == 
l->line;
 }

@@ -88,7 +90,7 @@ bitmap_descriptor (const char *file, con
  1);
   if (*slot)
 return *slot;
-  *slot = xcalloc (sizeof (**slot), 1);
+  *slot = XCNEW (struct bitmap_descriptor);
   (*slot)->file = file;
   (*slot)->function = function;
   (*slot)->line = line;
diff -rup orig/egcc-SVN20080703/gcc/ggc-common.c 
egcc-SVN20080703/gcc/ggc-common.c
--- orig/egcc-SVN20080703/gcc/ggc-common.c  2008-06-26 02:31:32.0 
+0200
+++ egcc-SVN20080703/gcc/ggc-common.c   2008-07-03 19:28:44.0 +0200
@@ -791,7 +791,7 @@ static htab_t loc_hash;
 static hashval_t
 hash_descriptor (const void *p)
 {
-  const struct loc_descriptor *const d = p;
+  const struct loc_descriptor *const d = (const struct loc_descriptor *) p;

   return htab_hash_pointer (d->function) | d->line;
 }
@@ -799,8 +799,8 @@ hash_descriptor (const void *p)
 static int
 eq_descriptor (const void *p1, const void *p2)
 {
-  const struct loc_descriptor *const d = p1;
-  const struct loc_descriptor *const d2 = p2;
+  const struct loc_descriptor *const d = (const struct loc_descriptor *) p1;
+  const struct loc_descriptor *const d2 = (const struct loc_descriptor *) p2;

   return (d->file == d2->file && d->line == d2->line
  && d->function == d2->function);
@@ -819,7 +819,7 @@ struct ptr_hash_entry
 static hashval_t
 hash_ptr (const void *p)
 {
-  const struct ptr_hash_entry *const d = p;
+  const struct ptr_hash_entry *const d = (const struct ptr_hash_entry *) p;

   return htab_hash_pointer (d->ptr);
 }
@@ -827,7 +827,7 @@ hash_ptr (const void *p)
 static int
 eq_ptr (const void *p1, const void *p2)
 {
-  const struct ptr_hash_entry *const p = p1;
+  const struct ptr_hash_entry *const p = (const struct ptr_hash_entry *) p1;

  

Re: question about the ddg construction

2008-07-03 Thread Tianwei
On Thu, Jul 3, 2008 at 3:26 PM, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 4, 2008 at 12:05 AM, Tianwei <[EMAIL PROTECTED]> wrote:
>> Hi, all,
>>My current project wants to reuse DDG's infrastructure to get some
>> loop carried dependency information, I debug these code for a while,
>> but have some questions, Hope you can
>> give me some suggestions.
>>
>> 1. my platform is X86,  and gcc version is 4.3.1, when i use -fsms,
>> and debug the code, found that for the following code, if always
>> return NULL_RTX:
>>
>>  /* Make sure this is a doloop.  */
>>  if ( !(count_reg = doloop_register_get (head, tail)))
>>  {
>>if (dump_file)
>>  fprintf (dump_file, "SMS doloop_register_get failed\n");
>>continue;
>>  }
>>
>> when I check the doloop_register_get, and found that it's guarded by a
>> ifdef "HAVE_doloop_end", even i make clobber the whole compiler,
>> rebuild the compiler by "CFLAGS='-DHAVE_doloop_end'", it still will
>> complain error, can't find the gen_doloop_end.
>>
>> so the first question is:  does SMS is support on X86?
>
> No. the x86 backend has no doloop insn pattern.  To see what that
> means, see loop-doloop.c, and look for doloop in
> http://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html.
>
> Gr.
> Steven
>
Steven, thanks very much. I will look at it.
BTW, now the ddg construction seems to do the following step:
1. compuate the intra-dependency accoring to  scheduler dependency analysis
2. during the intra-dependency function, it will also perform inter-loop-mem-dep
3. then it will use another pass to perform inter-loop-reg-dep.

i will debug some testcase to understand why it did in this
way(especially why inter-loop-mem is embedded in intra-dependency
phase), how it can guarantee we won't miss any dependency.

Tianwei


Re: question about the ddg construction

2008-07-03 Thread Tianwei
On Thu, Jul 3, 2008 at 4:13 PM, Tianwei <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 3, 2008 at 3:26 PM, Steven Bosscher <[EMAIL PROTECTED]> wrote:
>> On Fri, Jul 4, 2008 at 12:05 AM, Tianwei <[EMAIL PROTECTED]> wrote:
>>> Hi, all,
>>>My current project wants to reuse DDG's infrastructure to get some
>>> loop carried dependency information, I debug these code for a while,
>>> but have some questions, Hope you can
>>> give me some suggestions.
>>>
>>> 1. my platform is X86,  and gcc version is 4.3.1, when i use -fsms,
>>> and debug the code, found that for the following code, if always
>>> return NULL_RTX:
>>>
>>>  /* Make sure this is a doloop.  */
>>>  if ( !(count_reg = doloop_register_get (head, tail)))
>>>  {
>>>if (dump_file)
>>>  fprintf (dump_file, "SMS doloop_register_get failed\n");
>>>continue;
>>>  }
>>>
>>> when I check the doloop_register_get, and found that it's guarded by a
>>> ifdef "HAVE_doloop_end", even i make clobber the whole compiler,
>>> rebuild the compiler by "CFLAGS='-DHAVE_doloop_end'", it still will
>>> complain error, can't find the gen_doloop_end.
>>>
>>> so the first question is:  does SMS is support on X86?
>>
>> No. the x86 backend has no doloop insn pattern.  To see what that
>> means, see loop-doloop.c, and look for doloop in
>> http://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html.
>>
>> Gr.
>> Steven
>>
> Steven, thanks very much. I will look at it.
> BTW, now the ddg construction seems to do the following step:
> 1. compuate the intra-dependency accoring to  scheduler dependency analysis
> 2. during the intra-dependency function, it will also perform 
> inter-loop-mem-dep

also now for this inter-loop-mem-dep, it's very conservative, it will
simply assume  that
if one mem instruction modified the memory, then there will be an edge
to any insns that access mem

 /* If this insn modifies memory, add an edge to all insns that access
 memory.  */
  if (mem_access_insn_p (dest_node->insn))
{
  int j;

  for (j = 0; j <= i; j++)
{
  ddg_node_ptr j_node = &g->nodes[j];
  if (mem_access_insn_p (j_node->insn))
/* Don't bother calculating inter-loop dep if an intra-loop dep
   already exists.  */
  if (! TEST_BIT (dest_node->successors, j))
add_inter_loop_mem_dep (g, dest_node, j_node);
}
}

/* Given two nodes, analyze their RTL insns and add inter-loop mem deps
   to ddg G.  */
static void
add_inter_loop_mem_dep (ddg_ptr g, ddg_node_ptr from, ddg_node_ptr to)
{
  if (mem_write_insn_p (from->insn))
{
  if (mem_read_insn_p (to->insn))
create_ddg_dep_no_link (g, from, to, TRUE_DEP, MEM_DEP, 1);
  else if (from->cuid != to->cuid)
create_ddg_dep_no_link (g, from, to, OUTPUT_DEP, MEM_DEP, 1);
}
  else
{
  if (mem_read_insn_p (to->insn))
return;
  else if (from->cuid != to->cuid)
{
  create_ddg_dep_no_link (g, from, to, ANTI_DEP, MEM_DEP, 1);
  create_ddg_dep_no_link (g, to, from, TRUE_DEP, MEM_DEP, 1);
}
}

}

it won't query the aliaser for more precise information, maybe the
code is a little older.

> 3. then it will use another pass to perform inter-loop-reg-dep.
> i will debug some testcase to understand why it did in this
> way(especially why inter-loop-mem is embedded in intra-dependency
> phase), how it can guarantee we won't miss any dependency.
>
> Tianwei
>


Re: Feature request - a macro defined for GCC

2008-07-03 Thread rkiesling
Paul Koning:
> > "Ralf" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> 
>  Ralf> I feel like I'm stating the obvious, but maybe you're just
>  Ralf> trying to rediscover feature-based tests: do a test compile
>  Ralf> that exposes the compiler bug or feature you're looking for.
> 
>  Ralf> Autoconf provides a framework that supports this kind of
>  Ralf> testing, among others.
> 
> Autoconf is a massively cryptic and complicated way to make up for the
> lack of "I have feature X" CPP flags in the compiler.
> 
> Chris is right, that's the correct way to do things.
> 
>   paul

Cpp does not, however, define macros based on command line options,
for example __C99_STD_CMD_LINE_OPTION__.  You could do the same thing
yourself with a -D__MY_C99_STUFF__, for example, on the command line.

I also feel like I keep stating the obvious, but there are a lot of
GNU C platforms that don't use glibc and wouldn't have any need for
such feature-based macros, (or they would need their own unique
features) but they still comply with standard C.

-- 
Ctalk Home Page: http://www.ctalklang.org


Re: Bootstrap failures due to C++ warnings with --enable-gather-detailed-memory-stats

2008-07-03 Thread Diego Novillo
On Thu, Jul 3, 2008 at 19:02, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:

> Actually it's --enable-gather-detailed-mem-stats ("mem" not "memory"),
> this threw me for a while as I was unable to reproduce any failures until
> I figured that out. :-)

Oops, sorry!  I composed the message in a hurry and didn't actually
cut-n-paste the flag name.

>
>* alloc-pool.c (hash_descriptor, eq_descriptor,
>alloc_pool_descriptor): Fix -Wc++-compat warnings.
>* bitmap.c (hash_descriptor, eq_descriptor, bitmap_descriptor):
>Likewise.
>* ggc-common.c (hash_descriptor, eq_descriptor, hash_ptr, eq_ptr,
>loc_descriptor, ggc_prune_ptr, ggc_free_overhead,
>final_cmp_statistic, cmp_statistic, dump_ggc_loc_statistics):
>Likewise.
>* varray.c (hash_descriptor, eq_descriptor, varray_descriptor):
>Likewise.

OK, thanks.

I wonder if other major configuration modes may also trigger
warnings (e.g., --disable-checking).  I tried
--enable-checking=release and that works fine.


Diego.


Re: Bootstrap failures due to C++ warnings with --enable-gather-detailed-memory-stats

2008-07-03 Thread Kaveh R. GHAZI
On Thu, 3 Jul 2008, Diego Novillo wrote:

> I wonder if other major configuration modes may also trigger
> warnings (e.g., --disable-checking).  I tried
> --enable-checking=release and that works fine.
> Diego.

Based on history there's a good chance they'll each have a few minor nits.
Can you suggest a few things to try?  E.g. I did --with-gc=zone and a
couple of errors cropped up.  If there are other configurations that come
to mind, let me know.

--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]


Re: Bootstrap failures due to C++ warnings with --enable-gather-detailed-memory-stats

2008-07-03 Thread Diego Novillo
On Thu, Jul 3, 2008 at 19:57, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:

> Based on history there's a good chance they'll each have a few minor nits.

Yeah.

> Can you suggest a few things to try?  E.g. I did --with-gc=zone and a
> couple of errors cropped up.  If there are other configurations that come
> to mind, let me know.

I had these in mind:

--disable-checking
--enable-checking=all,valgrind  (you got time to go on holiday with this one)
--enable-coverage


Diego.


Re: Bootstrap failures due to C++ warnings with --enable-gather-detailed-memory-stats

2008-07-03 Thread Kaveh R. GHAZI
On Thu, 3 Jul 2008, Diego Novillo wrote:

> > Can you suggest a few things to try?  E.g. I did --with-gc=zone and a
> > couple of errors cropped up.  If there are other configurations that come
> > to mind, let me know.
>
> I had these in mind:
>
> --disable-checking
> --enable-checking=all,valgrind  (you got time to go on holiday with this one)
> --enable-coverage
> Diego.

I tried --disable-checking and --enable-coverage, no problems bootstrap
completed.  Using --with-gc=zone had some warnings which are fixed below.
I'll try extra --enable-checking options overnight.


Meantime, patch below bootstrapped with --with-gc=zone on
x86_64-unknown-linux-gnu.  Okay for mainline?

Thanks,
--Kaveh

2008-07-04  Kaveh R. Ghazi  <[EMAIL PROTECTED]>

* ggc-zone.c (lookup_page_table_if_allocated,
set_page_table_entry, zone_find_object_size, alloc_small_page,
alloc_large_page, ggc_free, gt_ggc_m_S, ggc_marked_p, init_ggc,
new_ggc_zone, init_ggc_pch, ggc_pch_this_base, ggc_pch_read): Fix
-Wc++-compat and/or -Wcast-qual warnings.

diff -rup orig/egcc-SVN20080703/gcc/ggc-zone.c egcc-SVN20080703/gcc/ggc-zone.c
--- orig/egcc-SVN20080703/gcc/ggc-zone.c2008-06-07 02:00:13.0 
+0200
+++ egcc-SVN20080703/gcc/ggc-zone.c 2008-07-04 01:32:40.0 +0200
@@ -541,7 +541,7 @@ lookup_page_table_if_allocated (const vo
 return NULL;
   /* We might have a page entry which does not correspond exactly to a
  system page.  */
-  if (base[L1][L2] && (char *) p < base[L1][L2]->page)
+  if (base[L1][L2] && (const char *) p < base[L1][L2]->page)
 return NULL;

   return base[L1][L2];
@@ -566,7 +566,7 @@ set_page_table_entry (void *p, page_entr
   goto found;

   /* Not found -- allocate a new table.  */
-  table = xcalloc (1, sizeof(*table));
+  table = XCNEW (struct page_table_chain);
   table->next = G.lookup;
   table->high_bits = high_bits;
   G.lookup = table;
@@ -579,7 +579,7 @@ found:
   L2 = LOOKUP_L2 (p);

   if (base[L1] == NULL)
-base[L1] = xcalloc (PAGE_L2_SIZE, sizeof (page_entry *));
+base[L1] = XCNEWVEC (page_entry *, PAGE_L2_SIZE);

   base[L1][L2] = entry;
 }
@@ -715,7 +715,7 @@ zone_find_object_size (struct small_page
   unsigned int start_word = zone_get_object_alloc_word (object_midptr);
   unsigned int start_bit = zone_get_object_alloc_bit (object_midptr);
   size_t max_size = (page->common.page + SMALL_PAGE_SIZE
-- (char *) object);
+- (const char *) object);

   return zone_object_size_1 (page->alloc_bits, start_word, start_bit,
 max_size);
@@ -898,7 +898,7 @@ alloc_small_page (struct alloc_zone *zon
 memory order.  */
   for (i = G.quire_size - 1; i >= 1; i--)
{
- e = xcalloc (1, G.small_page_overhead);
+ e = XCNEWVAR (struct small_page_entry, G.small_page_overhead);
  e->common.page = page + (i << GGC_PAGE_SHIFT);
  e->common.zone = zone;
  e->next = f;
@@ -908,7 +908,7 @@ alloc_small_page (struct alloc_zone *zon

   zone->free_pages = f;

-  entry = xcalloc (1, G.small_page_overhead);
+  entry = XCNEWVAR (struct small_page_entry, G.small_page_overhead);
   entry->common.page = page;
   entry->common.zone = zone;
   set_page_table_entry (page, &entry->common);
@@ -935,7 +935,7 @@ alloc_large_page (size_t size, struct al
   size_t needed_size;

   needed_size = size + sizeof (struct large_page_entry);
-  page = xmalloc (needed_size);
+  page = XNEWVAR (char, needed_size);

   entry = (struct large_page_entry *) page;

@@ -1439,7 +1439,7 @@ ggc_free (void *p)

   /* Add the chunk to the free list.  We don't bother with coalescing,
 since we are likely to want a chunk of this size again.  */
-  free_chunk (p, size, page->zone);
+  free_chunk ((char *)p, size, page->zone);
 }
 }

@@ -1494,7 +1494,7 @@ gt_ggc_m_S (const void *p)
 a STRING_CST.  */
   gcc_assert (offset == offsetof (struct tree_string, str));
   p = ((const char *) p) - offset;
-  gt_ggc_mx_lang_tree_node ((void *) p);
+  gt_ggc_mx_lang_tree_node (CONST_CAST(void *, p));
   return;
 }

@@ -1560,7 +1560,7 @@ int
 ggc_marked_p (const void *p)
 {
   struct page_entry *page;
-  const char *ptr = p;
+  const char *ptr = (const char *) p;

   page = zone_get_object_page (p);

@@ -1686,7 +1686,7 @@ init_ggc (void)
 if (GGC_PAGE_SIZE == G.pagesize)
   {
/* We have a good page, might as well hold onto it...  */
-   e = xcalloc (1, G.small_page_overhead);
+   e = XCNEWVAR (struct small_page_entry, G.small_page_overhead);
e->common.page = p;
e->common.zone = &main_zone;
e->next = main_zone.free_pages;
@@ -1714,7 +1714,7 @@ new_ggc_zone_1 (struct alloc_zone *new_z
 struct alloc_zone *
 new_ggc_zone (const char * name)
 {
-  struct alloc_zone *new_zone = xcalloc (1, sizeof (struct alloc_zone));
+  struct 

Re: Bootstrap failures due to C++ warnings with --enable-gather-detailed-memory-stats

2008-07-03 Thread Gabriel Dos Reis
>
> Meantime, patch below bootstrapped with --with-gc=zone on
> x86_64-unknown-linux-gnu.  Okay for mainline?
>

yes, this looks good.
Thanks for doing this.

-- Gaby


Re: [whopr] Design/implementation alternatives for the driver and WPA

2008-07-03 Thread Cary Coutant
> We've started working on the driver and WPA components for whopr.
> These are some of our initial thoughts and implementation strategy.  I
> have linked these to the WHOPR page as well.  I'm hoping we can
> discuss these at the Summit BoF, so I'm posting them now to start the
> discussion.

I've updated the WHOPR Driver wiki page with our latest thoughts on
the plug-in interface:

 http://gcc.gnu.org/wiki/whopr/driver

-cary


Re: Bootstrap failures due to C++ warnings with --enable-gather-detailed-memory-stats

2008-07-03 Thread Ian Lance Taylor
"Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:

> 2008-07-03  Kaveh R. Ghazi  <[EMAIL PROTECTED]>
>
>   * alloc-pool.c (hash_descriptor, eq_descriptor,
>   alloc_pool_descriptor): Fix -Wc++-compat warnings.
>   * bitmap.c (hash_descriptor, eq_descriptor, bitmap_descriptor):
>   Likewise.
>   * ggc-common.c (hash_descriptor, eq_descriptor, hash_ptr, eq_ptr,
>   loc_descriptor, ggc_prune_ptr, ggc_free_overhead,
>   final_cmp_statistic, cmp_statistic, dump_ggc_loc_statistics):
>   Likewise.
>   * varray.c (hash_descriptor, eq_descriptor, varray_descriptor):
>   Likewise.

This is OK.

Thanks.

Ian


Re: Bootstrap failures due to C++ warnings with --enable-gather-detailed-memory-stats

2008-07-03 Thread Ian Lance Taylor
"Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:

> 2008-07-04  Kaveh R. Ghazi  <[EMAIL PROTECTED]>
>
>   * ggc-zone.c (lookup_page_table_if_allocated,
>   set_page_table_entry, zone_find_object_size, alloc_small_page,
>   alloc_large_page, ggc_free, gt_ggc_m_S, ggc_marked_p, init_ggc,
>   new_ggc_zone, init_ggc_pch, ggc_pch_this_base, ggc_pch_read): Fix
>   -Wc++-compat and/or -Wcast-qual warnings.

This is OK.

Thanks.

Ian


Re: [whopr] Design/implementation alternatives for the driver and WPA

2008-07-03 Thread Ian Lance Taylor
"Cary Coutant" <[EMAIL PROTECTED]> writes:

>> We've started working on the driver and WPA components for whopr.
>> These are some of our initial thoughts and implementation strategy.  I
>> have linked these to the WHOPR page as well.  I'm hoping we can
>> discuss these at the Summit BoF, so I'm posting them now to start the
>> discussion.
>
> I've updated the WHOPR Driver wiki page with our latest thoughts on
> the plug-in interface:
>
>  http://gcc.gnu.org/wiki/whopr/driver

A few comments.

* "End of first pass" may be a little gold specific.  Perhaps it
  should be called something like "after all input files have been
  seen."

* The linker does normally copy unrecognized sections with the
  SHF_ALLOC bit clear to the output file.  It doesn't allocate address
  space for them, but it does copy them.  I think this follows the ELF
  ABI.  I don't know of any generic way to direct the linker to not
  copy sections to the output file.

* Do we need to worry about the type of the symbol in the "add
  symbols" interface?  For example, what about a TLS symbol?  Also,
  when the GNU linker sees a common symbol in a regular object and a
  symbol with the same name in a shared library, the action depends on
  the type of the symbol in the shared library.  For STT_OBJECT, the
  common symbol becomes an undefined reference to the shared library.
  For STT_FUNCTION, it does not.  Gold does not currently behave this
  way--the common symbol always overrides.  But in any case, there is
  some precedent for worrying about symbol type.

* The command line arguments should explicitly be placed in the
  transfer vector in the order in which they appear on the command
  line.

* Type names ending in "_t" are reserved by POSIX.  We shouldn't use
  them (I'm looking at ld_plugin_status_t).

* GOLD_VERSION should perhaps say something about the format of the
  string.

* I guess that having the message hook take a va_list is most
  flexible, but it is inconvenient for typical uses.  Taking a
  variable number of arguments would be more convenient.  Or it might
  be reasonable to just take a string, and push formatting to the
  plugin.

Ian


Re: question about the ddg construction

2008-07-03 Thread Steven Bosscher
On Fri, Jul 4, 2008 at 1:25 AM, Tianwei <[EMAIL PROTECTED]> wrote:
> it won't query the aliaser for more precise information, maybe the
> code is a little older.

Not at all, the DDG file is for the SMS pass which is relatively new.
One of the problems is that you can't really compute a dependence
distance on RTL, so for memory the DDG is just very conservative.

You're not telling anything new, you know ;-)  You probably want to
read http://gcc.gnu.org/wiki/SwingModuloScheduling too,

Gr.
Steven