shouldn't every middle-end pass be uniquely named?

[Basile STARYNKEVITCH]

Hello All,

Some middle-end passes (those declared in tree-passes.h) are still unnamed.

I tend to believe that it would be helpful (mostly for gcc debugging 
purposes) that every struct opt_pass (without exception) should be 
uniquely named (and that this should be enforced, eg. in ENABLE_CHECKING 
mode (essentially by registering each pass in an hash table in function 
next_pass_1 of gcc/passes.c)


What do people think about that?

Except as a habit (which I think is a bad one) is there any reason to 
have anonymous passes (those with a null pass->name), or (I don't know 
if such beast exists) homonym passes (two different passes with equal 
pass->name)?


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: shouldn't every middle-end pass be uniquely named?

[Andrew Thomas Pinski]

Sent from my iPhone

On Jul 31, 2008, at 1:11, Basile STARYNKEVITCH  
<[EMAIL PROTECTED]> wrote:



Hello All,

Some middle-end passes (those declared in tree-passes.h) are still  
unnamed.


I tend to believe that it would be helpful (mostly for gcc debugging  
purposes) that every struct opt_pass (without exception) should be  
uniquely named (and that this should be enforced, eg. in  
ENABLE_CHECKING mode (essentially by registering each pass in an  
hash table in function next_pass_1 of gcc/passes.c)


What do people think about that?

Except as a habit (which I think is a bad one) is there any reason  
to have anonymous passes (those with a null pass->name), or (I don't  
know if such beast exists) homonym passes (two different passes with  
equal pass->name)?


Yes. To prevent a dump file. One such example is freeing the internal  
data structures. That should not have a dump.





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: shouldn't every middle-end pass be uniquely named?

[Basile STARYNKEVITCH]

Andrew Thomas Pinski wrote:



Sent from my iPhone


Except as a habit (which I think is a bad one) is there any reason to 
have anonymous passes (those with a null pass->name), or (I don't know 
if such beast exists) homonym passes (two different passes with equal 
pass->name)?


Yes. To prevent a dump file. One such example is freeing the internal 
data structures. That should not have a dump.


We might add a field (e.g. unsigned avoid_dump) to struct opt_pass for 
that, or decide that passes name starting with a star (or whatever 
convention people want) do not have any dump file.


In addition of help debugging of GCC, having each pass be named could be 
helpful for other reasons. For example, a plugin machinery would be much 
simpler (basically a plugin could say add my pass named foo after every 
pass named bar).



--
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} ***

Access the BIND_EXPR of a function

[Thomas A.M. Bernard]

Hi,

When I encounter a FUNCTION_DECL, I want to access the node BIND_EXPR
where I can find the artificial declarations of the current functions
that the compiler adds. Following what the documentation says, I use the
macro DECL_SAVED_TREE which should point to the node BIND_EXPR (used as
follows, DECL_SAVED_TREE (current_function_decl)). Unfortunately, this
returns the STATEMENT_LIST node instead. In theory in the GIMPLE, if
there are artificial declarations, FUNCTION_DECL has a child called body
which points to BIND_EXPR and then BIND_EXPR has a child body which
points to STATEMENT_LIST.
Btw, I use GCC 4.1. Any ideas for accessing the BIND_EXPR node?

Thomas

Re: shouldn't every middle-end pass be uniquely named?

[Basile STARYNKEVITCH]

Basile STARYNKEVITCH wrote:

Andrew Thomas Pinski wrote:


Except as a habit (which I think is a bad one) is there any reason to 
have anonymous passes (those with a null pass->name), or (I don't 
know if such beast exists) homonym passes (two different passes with 
equal pass->name)?


Yes. To prevent a dump file. One such example is freeing the internal 
data structures. That should not have a dump.


We might add a field (e.g. unsigned avoid_dump) to struct opt_pass for 
that, or decide that passes name starting with a star (or whatever 
convention people want) do not have any dump file.



I actually proposed a patch on gcc-patches@ which do not dump when the 
pass name starts with a dot (better than a star, because following unix 
conventions for "hidden" files)

http://gcc.gnu.org/ml/gcc-patches/2008-07/msg02406.html

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} ***

GCC 4.3.2 Status Report (2008-07-31)

[Jakub Jelinek]

Status
==

The GCC 4.3 branch is open for commits under normal release branch
rules.  The 4.3.2 release was expected around 2008-08-06, but as
there are still P1s, it might be delayed a little bit.

Quality Data


Priority  # Change from Last Report
--- ---
P13 -  5
P2  115 -  2
P32 -  1
--- ---
Total   120 -  8


As we are approaching the intended release date of 4.3.2 we need to
address the P1 bugs or downgrade them accordingly.  Two of the P1s
have patches posted (more than 3 resp. 2 weeks ago), so they just
need reviewing.

If you think you have spotted a regression on the branch for a
primary or secondary target that does not show up when invoking the
"Serious regressions" link from the GCC homepage please tell one
of the RMs.


Previous Report
===

http://gcc.gnu.org/ml/gcc/2008-07/msg00240.html

The next report for the 4.3 branch will be sent by Mark.

RE: gcc will become the best optimizing x86 compiler

[Dave Korn]

Agner Fog wrote on 31 July 2008 07:14:

> Denys Vlasenko wrote:
>> I tend to doubt that odd-byte aligned large memcpys are anywhere
>> near typical. malloc and mmap both return well-aligned buffers
>> (say, 8 byte aligned). Static and on-stack objects are also
>> at least word-aligned 99% of the time.
>> 
>> memcpy can just use "relatively simple" code for copies in which
>> either src or dst is not word aligned. This cuts possibilities down from
>> 16 to 4 (or even 2?). 
>> 
> The XMM code is still more than 3 times faster than rep movsl when data
> are aligned by 4 or 8, but not by 16.
> Even if odd addresses are rare, they must be supported, but we can put
> the most common cases first.


  In the real world, unaligned memcpys are anything but rare.  Everything's
networked these days, remember?  Stuff gets misaligned real quick when you
start adding and removing various network layer headers and trailers to
unpredictably-sized packets.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: gcc emit wrong symbols in multiple inheritance case

[Bo Yang]

On Thu, Jul 31, 2008 at 12:48 AM, Brian Dessent <[EMAIL PROTECTED]> wrote:
> Benjamin Smedberg wrote:
>
>> For what it's worth, Bo is my intern in the Google SoC and has traced this
>> back to being a code-generation error (missed stdcall mangling) in the mingw
>> backend. I will work with him to narrow the problem and reformulate the
>> question..
>
> Isn't this ?  If so it has regressed as that
> was supposedly fixed in 4.3.

I have test the PR27067's test case, and it indeed works. I mean, gcc
4.3.0 create a correct app. But in Mozilla, the problem is not such
simple. The test case is just to compile a single c++ source file to
get a exe. There is no shared library and import library.
After I compile the test case of PR27067, I examine the object file of
the c++ file and I got:

 U __ZTVN10__cxxabiv117__class_type_infoE
 U __ZTVN10__cxxabiv120__si_class_type_infoE
 U __ZTVN10__cxxabiv121__vmi_class_type_infoE
0007 T __ZThn4_N6bottom4fun1Ev
 U [EMAIL PROTECTED]
0021 T __ZThn4_N6bottom4fun2Ev
 U [EMAIL PROTECTED]
003b T __ZThn4_N6bottom4fun3Ev
 U [EMAIL PROTECTED]
 T __ZThn4_N6bottom4fun5Ev
 U [EMAIL PROTECTED]
 T __ZThn4_N6bottomD0Ev
 T __ZThn4_N6bottomD1Ev
 T __ZThn8_N6bottom4fun1Ev
 U [EMAIL PROTECTED]
001a T __ZThn8_N6bottom4fun2Ev
 U [EMAIL PROTECTED]
0034 T __ZThn8_N6bottom4fun3Ev
 U [EMAIL PROTECTED]
 T __ZThn8_N6bottom4fun6Ev
 U [EMAIL PROTECTED]
 T __ZThn8_N6bottomD0Ev
 T __ZThn8_N6bottomD1Ev

Take the
0007 T __ZThn4_N6bottom4fun1Ev
   U [EMAIL PROTECTED]
for example. Very similar pattern, yes, it is the same pattern with my
test case above. And this this mean that our object file has the
definition of  bottom:fun1() but not have the definition of
__attribute__((__stdcall__)) bottom:fun1().
Obviously, we have definition of __attribute__((__stdcall__))
bottom:fun1(), but the generated object file said it does not have!

When we produce an exe from a single c++ file, there is no linking
need, so there is no problem. But when we separate the definition and
the usage. I mean, we put the definition into a DLL and then use it to
generate another exe. This time, we need a linker to link the DLL.
Rationally, the linker should search for [EMAIL PROTECTED]
(__attribute__((__stdcall__)) bottom:fun1() ), but it only find there
is a "  U [EMAIL PROTECTED]" in the library, so a fail occur
this way.
And Obviously, this is not a linker error, it is the problem gcc
generate a " U [EMAIL PROTECTED]" for indeed existing
definition of "__attribute__((__stdcall__)) bottom:fun1()" .

I hope I make the problem clear here. Any question and advice are welcomed!

Regards!
Bo

RE: configuring in-tree gmp/mpfr with "none"?

[Jay]

Andrew, Can you explain more why?

Why I'm asking again now:

I have found another "problem" because of this (besides the
 reduced ability to share config.cache files).

This exacerbates what looks like a minor bug in gmp's configure.

Sometimes, depending on build/host/target, gmp's configure
sets M4=m4-not-needed.

Setting the processor to "none" is a good way to get it down the "not needed" 
path.
Though there might be other ways there, granted.

And then gmp/configure runs flex.
And then sometimes?always flex tries to run getenv("M4") || "m4".

Flex fails, sometimes creating lex.yy.c, sometimes not.
I haven't tracked down this "sometimes".
When I run build under Python, no lex.yy.c, outside of Python, ok.
I still have to dig in further to find out why.
When lex.yy.c is not created, configure fails. It is looking for what file is 
the output.

gmp/configure probably should not be setting M4, at least not when it runs flex.

But gcc using processor=none doesn't help.

I'll follow up with gmp folks.

Thanks,
 - Jay


> Date: Wed, 18 Jun 2008 06:53:35 -0400
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: configuring in-tree gmp/mpfr with "none"?
> CC: gcc@gcc.gnu.org
>
> On Wed, Jun 18, 2008 at 12:40 AM, Jay  wrote:
>> Ah, I didn't realize any C or C++ code could be configured for other than a
>> specific processor but I guess that makes sense -- it is Makefile, config.h,
>> and such that are being modified, not the .o files, and they might be the
>> same across many configurations, like if the compiler command lines and
>> #defines can be the same, like if there is no need to know the size of a
>> pointer or the endianness, etc.. I guess more code should work this way if
>> possible. Thanks Andrew.
>
> Well gmp/mpfr are special in that they try to do the same thing as
> -mcpu=native with their configure script and they have some assembly
> files.
>
> Thanks,
> Andrew Pinski

Re: std::isfinite broken?

[Neal Becker]

Paolo Carlini wrote:

> Hi ho, ho!! ;)
>> It worked with me.
>>   
> Try a recent gcc (eg, 4.3.x) and you will get the same, actually
> expected, result of the original poster.
> 
> Paolo.

I believe this is a bug.  I agree that -ffast-math will not always comply 100% 
with IEEE, as advertised.  But, if I explicity ask isfinite(), I expect it to 
work.  If it is really intended not to work, then at least documentation should 
state that.

RE: std::isfinite broken?

[Dave Korn]

Neal Becker wrote on 31 July 2008 12:42:

> Paolo Carlini wrote:
> 
>> Hi ho, ho!! ;)
>>> It worked with me.
>>> 
>> Try a recent gcc (eg, 4.3.x) and you will get the same, actually
>> expected, result of the original poster.
>> 
>> Paolo.
> 
> I believe this is a bug.  I agree that -ffast-math will not always comply
> 100% with IEEE, as advertised.  But, if I explicity ask isfinite(), I
> expect it to work.  If it is really intended not to work, then at least
> documentation should state that.   

  It does, as was already explained to you; re-read the thread.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

RE: std::isfinite broken?

[Dave Korn]

Dave Korn wrote on 31 July 2008 12:45:

> Neal Becker wrote on 31 July 2008 12:42:

>> If it is really intended not to work, then at least
>> documentation should state that.
> 
>   It does, as was already explained to you; re-read the thread.

  Actually I can be more use than that,  I'll show you the relevant bits of
the manual:

-ffast-math'
Sets `-fno-math-errno', `-funsafe-math-optimizations',
`-fno-trapping-math', `-ffinite-math-only' and
   ^^^
`-fno-signaling-nans'.

`-ffinite-math-only'
 Allow optimizations for floating-point arithmetic that assume that
 arguments and results are not NaNs or +-Infs.


  So, to address your point:

>>But, if I explicity ask isfinite(), I expect it to work.  


  Fine.  But what do you expect to happen if you explicitly tell it that no
number in your program will ever be infinite, and then call isinfinite?  You
told GCC that it could assume isinfinite will always return zero, so it took
your word for that and replaced all the calls by a constant zero.  What do
you want to happen in those circumstances?




cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: GCC 4.3.2 Status Report (2008-07-31)

[Paolo Bonzini]

Priority  # Change from Last Report
--- ---
P13 -  5
P2  115 -  2
P32 -  1
--- ---
Total   120 -  8


PR35752, which is a P2 regression caused by libtool, is waiting for 
approval upstream.  Should we make an exception to the usual rules and 
apply the fix on the branch?


Paolo

Re: GCC 4.3.2 Status Report (2008-07-31)

[Paolo Bonzini]

As we are approaching the intended release date of 4.3.2 we need to
address the P1 bugs or downgrade them accordingly.  Two of the P1s
have patches posted (more than 3 resp. 2 weeks ago), so they just
need reviewing.


For the record, these are:

http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00722.html
reload.c (CCing Ulrich Weigand)

http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01305.html
dwarf2out.c (CCing Jason Merrill)

Paolo

Re: GCC 4.3.2 Status Report (2008-07-31)

[Ralf Wildenhues]

Hi Paolo,

* Paolo Bonzini wrote on Thu, Jul 31, 2008 at 02:53:21PM CEST:
>
> PR35752, which is a P2 regression caused by libtool, is waiting for  
> approval upstream.  Should we make an exception to the usual rules and  
> apply the fix on the branch?

If by exception to the usual rule, you mean that you would like to apply
the patch to GCC before it's accepted in Libtool, then can you give me
24 hours, which may just be enough to not need to bend this particular
rule?

Thanks,
Ralf

Re: GCC 4.3.2 Status Report (2008-07-31)

[Paolo Bonzini]

Ralf Wildenhues wrote:

Hi Paolo,

* Paolo Bonzini wrote on Thu, Jul 31, 2008 at 02:53:21PM CEST:
PR35752, which is a P2 regression caused by libtool, is waiting for  
approval upstream.  Should we make an exception to the usual rules and  
apply the fix on the branch?


If by exception to the usual rule, you mean that you would like to apply
the patch to GCC before it's accepted in Libtool


And only on the branch.

Tomorrow it's a public holiday here, so I wouldn't apply the patch 
before monday anyway.


Paolo

Re: GCC 4.3.2 Status Report (2008-07-31)

[Jakub Jelinek]

On Thu, Jul 31, 2008 at 03:10:46PM +0200, Paolo Bonzini wrote:
> Ralf Wildenhues wrote:
> Tomorrow it's a public holiday here, so I wouldn't apply the patch 
> before monday anyway.

If the patch is checked in on Monday or Tuesday, that's still fine,
no need to use exceptions.

Jakub

Re: configuring in-tree gmp/mpfr with "none"?

[Paolo Bonzini]

Jay wrote:

Andrew, Can you explain more why?


Because at some point, no released version worked on intel macs.


And then gmp/configure runs flex.
And then sometimes?always flex tries to run getenv("M4") || "m4".


Yes, Flex uses m4.


gmp/configure probably should not be setting M4


Yes, I think that setting M4=m4-not-needed should be done only for 
debugging purposes.  Otherwise, GMP should always look for m4 in its 
configure script, and set it to a valid value in the makefile.


Paolo

Re: GCC 4.3.2 Status Report (2008-07-31)

[Jason Merrill]

Paolo Bonzini wrote:

http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01305.html
dwarf2out.c (CCing Jason Merrill)


That patch went in a while back, but your message led me to the one that 
still needed reviewing. :)


Jason

Re: gcc emit wrong symbols in multiple inheritance case

[Brian Dessent]

Bo Yang wrote:

> When we produce an exe from a single c++ file, there is no linking
> need, so there is no problem. But when we separate the definition and

That's not how it works, the linker is always required to produce an
executable.

> And Obviously, this is not a linker error, it is the problem gcc
> generate a " U [EMAIL PROTECTED]" for indeed existing
> definition of "__attribute__((__stdcall__)) bottom:fun1()" .

The "U" lines are correct and aren't the problem; those are call sites
to the properly mangled symbol name.  What's incorrect is that gcc emits
the function definitions (the 'T' lines) without the proper stdcall name
mangling.  If gcc used the proper mangling for the definitions then the
undefined call sites would no longer be undefined and would not show up
in the objdump output any more.

Brian

Re: [Ada] GCC Ada bootstrap suggestion

[Daniel Kraft]

Arnaud Charlet wrote:
For half a year now, I've been working on the GCC Fortran front-end; but 
I'm also quite interested in Ada as a language.  However, I don't quite 
like the idea that one needs a working Ada compiler to bootstrap the Ada 
front-end.  Well, it's the same with a C compiler to bootstrap GCC, but 
anyways :D


Also, at some point GCC will require C++ to bootstrap, so the same issues
will arise there.


Well, the point is, I'm using a GNU/Linux system I mainly built from 
scratch, so there's no easy package-installer available for me and I've 
to built everything from source (which is, of course, "my own fault"). 
My system started out with a gcc C compiler, so I could easily bootstrap 
and install any newer GCC, including C++, Java or Fortran, as I wanted.


And even if gcc eventually moves on to C++, there will still be an older 
gcc I could bootstrap with a C compiler only and use that version's C++ 
compiler for the newest release.


With Ada, however, I'm at least not aware of another compiler I could 
bootstrap using my C compiler and use that one subsequentally to 
bootstrap GNAT.  At the moment, I'm trying to bootstrap it using a 
binary GNAT 3.15p which was also somewhat hard to find on the net; and 
this does not quite work out at the moment, as the included gcc (2.8.1 
IIRC) is far too old and buggy to build even gcc-3.1 with Ada support 
for bootstrapping the gcc-4.3 release.  At least I don't quite find it 
an easy task to get a recent GNAT build from source...


I had the idea, based upon how gfortran works, that one could implement 
some basic AST-to-C translation component (it would be quite easy for the 
Fortran AST) that could then be used as a very basic Ada-to-C compiler 
re-using most of the existing Ada compiler.  With this new tool, one could 
compile the Ada front-end sources to C files.


Sure, this could theoretically be done, but so far, there has not been much
interest in doing that, given that cross compiling GCC is always available
as an option.


So you think I should boot into Microsoft Windows, install the cygwin 
GNAT binaries and use those to cross-compile gcc-4.3 for my GNU/Linux 
system?  Or at least boot up a live-cd that has the option to use a 
package installer for an existing GNAT and compile GCC with that?  At 
least to me this sounds somewhat disgusting.


I believe it would be at least some nice idea to make some 
binary-distributions easily available (and in a place they can be found).


If I give my idea some further thoughts (and finally manage to build 
GNAT on my system) and it seems to be quite easily doable, are you 
interested in results of my research and experiments?


Cheers,
Daniel

--
Done: Arc-Bar-Sam-Val-Wiz, Dwa-Elf-Gno-Hum-Orc, Law-Neu-Cha, Fem-Mal
Underway: Cav-Dwa-Law-Fem
To go:Cav-Hea-Kni-Mon-Pri-Ran-Rog-Tou

Re: [Ada] GCC Ada bootstrap suggestion

[Arnaud Charlet]

> Well, the point is, I'm using a GNU/Linux system I mainly built from 
> scratch, so there's no easy package-installer available for me and I've to 
> built everything from source (which is, of course, "my own fault"). My 
> system started out with a gcc C compiler, so I could easily bootstrap and 
> install any newer GCC, including C++, Java or Fortran, as I wanted.

Right, so when building such system from scratch, doing a cross compiler is
not really the hardest part.

> So you think I should boot into Microsoft Windows, install the cygwin GNAT 
> binaries and use those to cross-compile gcc-4.3 for my GNU/Linux system?  
> Or at least boot up a live-cd that has the option to use a package 
> installer for an existing GNAT and compile GCC with that?  At least to me 
> this sounds somewhat disgusting.

I have no idea what your set up is.
I'd suggest using whatever environment you can cross compile from (which
includes any standard linux box, or any windows box).

> I believe it would be at least some nice idea to make some 
> binary-distributions easily available (and in a place they can be found).

Sure, there are some binaries available from libre.adacore.com and from some
other sites.

> If I give my idea some further thoughts (and finally manage to build GNAT 
> on my system) and it seems to be quite easily doable, are you interested in 
> results of my research and experiments?

Not sure what 'my idea' is here. If you're talking about creating a C
generator, that does not fit into the 'quite easily doable' category.

Arno

Re: [Ada] GCC Ada bootstrap suggestion

[Laurent GUERBY]

On Thu, 2008-07-31 at 18:42 +0200, Daniel Kraft wrote:
> With Ada, however, I'm at least not aware of another compiler I could 
> bootstrap using my C compiler and use that one subsequentally to 
> bootstrap GNAT.  At the moment, I'm trying to bootstrap it using a 
> binary GNAT 3.15p which was also somewhat hard to find on the net; and 
> this does not quite work out at the moment, as the included gcc (2.8.1 
> IIRC) is far too old and buggy to build even gcc-3.1 with Ada support 
> for bootstrapping the gcc-4.3 release.  At least I don't quite find it 
> an easy task to get a recent GNAT build from source...

Most  Linux distributions have been packaging GNAT binaries
for a while now so you just need to take any recent gcc/gnat (4.1 and
above) .deb or .rpm, extract the gcc/gnat binaries following the
documented way for the given packaging format (ar and tar for .deb, cpio
for rpm) and use them on your system to build your own GCC.

Sincerely,

Laurent

GNAT build failure on cross

[Joel Sherrill]

Hi,

I seem to have bumped into something.  I threw away
my svn trunk checkout and did another just in case.
There are no Ada multilib patches in this tree.

I have checked and am pretty sure I have no changes
to anything that is not an RTEMS run-time related file.

I can build a native compiler but when using that
to build a cross rtems compiler, I get this:

make.adb:662:32: expected type "Gnat.Strings.String_Access" defined at 
g-string.ads:41

make.adb:662:32: found type "System.Strings.String_Access"
make.adb:663:32: expected type "Gnat.Strings.String_Access" defined at 
g-string.ads:41

make.adb:663:32: found type "System.Strings.String_Access"
make.adb:664:32: expected type "Gnat.Strings.String_Access" defined at 
g-string.ads:41

make.adb:664:32: found type "System.Strings.String_Access"
make.adb:689:39: "Get_Target_Object_Suffix" is not visible
make.adb:689:39: non-visible declaration at s-os_lib.ads:556
make.adb:1700:19: no candidate interpretations match the actuals:
make.adb:1700:19: too many arguments in call to 
"Normalize_Compiler_Switches"

make.adb:1702:22: expected type "System.Strings.String_List_Access"
make.adb:1702:22: found type "Gnat.Strings.String_List_Access" defined 
at g-string.ads:51
make.adb:1702:22:   ==> in call to "Normalize_Compiler_Switches" at 
switch-m.ads:45

make.adb:4460:36: expected type "System.Os_Lib.File_Descriptor"
make.adb:4460:36: found type "Gnat.Os_Lib.File_Descriptor" defined at 
g-os_lib.ads:160

make.adb:6605:13: expected type "System.Os_Lib.File_Descriptor"
make.adb:6605:13: found type "Gnat.Os_Lib.File_Descriptor" defined at 
g-os_lib.ads:160


Any suggestions?

--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

The g++ error output

[ingmar wirths]

Hello,

i had the following Problem today:

I have a class called GUI, that i included and instantiated.
Today i extended my Code (among other things) with an enum that had an
Element 'GUI'.
I didn't knew that this isn't possible and never even thought about it.

When i tried to compile my Code, i got an error, of course.
g++ tells me that GUI is not a type, and where the error occurs.
g++ unfortunately didn't told me, why GUI is not a type.

I knew, there is a type called GUI, i defined it. After hours of pondering about
my changes to the code, it just came to me: maybe its the newly added enum.
If g++ just would've told me that it considers GUI to be an element of
that enum,
that would've saved me a lot of time.

I believe this is a general problem: g++ tells *what* the problem is and *where*
the problem occurs (file/line). But it does not tell me *why* there is
a problem.
Usually that is enough information: I have the information what the problem is
and where to look, and i just see why there is a problem.

But sometimes it bits me, like today. The enum wasn't even in that
file, but in another i included.

I hope you don't consider this as flaming or something, just critics
to improve this wonderful compiler
and make hacking easier for people like me without an expert
understanding of C++.

Cheers,
ingmar

Help with identifing all cost models in GCC to make it adaptable ?..

[Grigori Fursin]

Dear All,

We continue developing adaptable GCC (MILEPOST GCC) and we plan to have more
results this fall on selecting good optimization passes and their orders 
to improve program execution time, reduce code size and compilation time 
across different architectures automatically using statistical techniques and 
machine
learning. 

As I mentioned during last GCC Summit, we are now ready to look at a 
finer-grain 
level optimizations, i.e. how to automatically tune all GCC optimization cost 
models 
within passes to decide whether to apply specific transformations and 
what should be their parameters. 

To do that, ideally we need to identify all the cost models within GCC with 
their
dependencies, and add support to our Interactive Compilation Interface to be 
able
to continuously monitor and bias their behavior to automatically (re)tune them
on new architectures. 

I am afraid it will take me ages to find myself all the cost models within GCC,
so I would be very grateful for any help in identifying those cost models 
(with the pass names and places in the source code) particularly that are known 
to be hard to tune manually or which may have complex interactions 
with other transformations (we should be able to capture those interactions 
automatically)!

Ideally, we would like to make GCC a fully modular compiler which will be tuned
(mostly) automatically to any particular architecture using a given set of 
related optimizations. We hope that it may simplify evolution of the compiler
and it will be much easier to add new optimizations (even by end-user through
plugins) since developers will have less problems thinking how to plug them
into the current hardwired optimization heuristic.

So I hope that with your help we can make GCC a best optimizing compiler,
and not only for x86 but for any architecture ;) ...

By the way, in case someone is interested, you can find some of our ideas 
on self-tuning MILEPOST GCC here:
http://gcc-ici.sourceforge.net/papers/fmtp2008.pdf

Sorry for bothering and looking forward to hearing from you,
Grigori

P.S. I will be on vacations soon so you can also contact Abid Malik from INRIA 
(in CC)
who will help adding support to GCC-ICI to monitor optimization cost models ...


Grigori Fursin, PhD
Research Scientist, INRIA Saclay, France

http://unidapt.org - tackling the complexity of
future computing systems using machine learning  

Re: The g++ error output

[Ian Lance Taylor]

"ingmar wirths" <[EMAIL PROTECTED]> writes:

> I hope you don't consider this as flaming or something, just critics
> to improve this wonderful compiler
> and make hacking easier for people like me without an expert
> understanding of C++.

Thanks for your note.  Unfortunately it is too vague for us to know
what to change.  I would encourage you to file a report at
http://gcc.gnu.org/bugzilla/ with a specific example of what g++ does
today and what you would like it to do in the future.  See also
http://gcc.gnu.org/bugs.html.  Thanks.

Ian

Re: Help with identifing all cost models in GCC to make it adaptable ?..

[David Edelsohn]

Grigori,

Many of the costs now are handled by GCC parameters.  See
gcc/params.def accessed in the source code using PARAM_VALUE.

Many other cost models use macros with "COST in their name, such as

TARGET_RTX_COSTS / rtx_cost
BRANCH_COST (and LOGICAL_OP_NON_SHORT_CIRCUIT)
MEMORY_MOVE_COST
REGISTER_MOVE_COST
MAX_CONDITIONAL_EXECUTE

David

gcc-4.3-20080731 is now available

[gccadmin]

Snapshot gcc-4.3-20080731 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080731/
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 138440

You'll find:

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

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

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

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

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

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

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

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

Diffs from 4.3-20080724 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.

Inconsistent use of allocator wrapper macros in libiberty

[Aaron W. LaFramboise]

Quite a few files in libiberty use XNEWVEC as a replacement for 
malloc(), but the they are being paired with plain free(); XDELVEC is 
not being used.


Is there some reason for the inconsistency, such as some transitional 
issue, or should this be fixed?

Re: Inconsistent use of allocator wrapper macros in libiberty

[DJ Delorie]

> Is there some reason for the inconsistency,

Not really.  Patches welcome.

RE: Help with identifing all cost models in GCC to make it adaptable ?..

[Grigori Fursin]

Thanks, David!

That's a good start. I will need to find places in GCC where these
parameters are used to monitor the behavior of transformations 
based on these parameters and be able to change the compiler decisions 
through ICI to learn how to tune those costs based on program execution 
time/code size...

Also, I would prefer to concentrate on only most critical/important 
costs right now (for example, within register allocation, scheduling, etc) 
since this research is very time consuming ...

Cheers,
Grigori



Grigori Fursin, PhD
Research Scientist, INRIA, France
http://fursin.net/research
  





> -Original Message-
> From: David Edelsohn [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 31, 2008 9:44 PM
> To: Grigori Fursin
> Cc: 'gcc'
> Subject: Re: Help with identifing all cost models in GCC to make it adaptable 
> ?..
> 
> Grigori,
> 
>   Many of the costs now are handled by GCC parameters.  See
> gcc/params.def accessed in the source code using PARAM_VALUE.
> 
>   Many other cost models use macros with "COST in their name, such as
> 
> TARGET_RTX_COSTS / rtx_cost
> BRANCH_COST (and LOGICAL_OP_NON_SHORT_CIRCUIT)
> MEMORY_MOVE_COST
> REGISTER_MOVE_COST
> MAX_CONDITIONAL_EXECUTE
> 
> David

Re: gcc will become the best optimizing x86 compiler

[Denys Vlasenko]

On Thursday 31 July 2008 11:36, Dave Korn wrote:
> Agner Fog wrote on 31 July 2008 07:14:
> 
> > Denys Vlasenko wrote:
> >> I tend to doubt that odd-byte aligned large memcpys are anywhere
> >> near typical. malloc and mmap both return well-aligned buffers
> >> (say, 8 byte aligned). Static and on-stack objects are also
> >> at least word-aligned 99% of the time.
> >> 
> >> memcpy can just use "relatively simple" code for copies in which
> >> either src or dst is not word aligned. This cuts possibilities down from
> >> 16 to 4 (or even 2?). 
> >> 
> > The XMM code is still more than 3 times faster than rep movsl when data
> > are aligned by 4 or 8, but not by 16.
> > Even if odd addresses are rare, they must be supported, but we can put
> > the most common cases first.
> 
>   In the real world, unaligned memcpys are anything but rare.  Everything's
> networked these days, remember?  Stuff gets misaligned real quick when you
> start adding and removing various network layer headers and trailers to
> unpredictably-sized packets.

Headers are usually at least rounded to 16-bit multiple.
Trailers do not matter to alignment.

This happens in kernel space. In kernel space, there are many differences.
* memcpy are rarely bigger than a page - this negates any gains from
  non-temporal MOVs
* memcpy cannot use XMM registers (otherwise lazy FPU saving doesn't work)
* kernel developers would never accept multi-kilobyte memcpy
  implementation anyway

Not to mention that network packets are ~1500 bytes long, even jumbo packets
are only 9k tops.
--
vda

Re: gcc emit wrong symbols in multiple inheritance case

[Bo Yang]

On Thu, Jul 31, 2008 at 11:00 PM, Brian Dessent <[EMAIL PROTECTED]> wrote:
> Bo Yang wrote:
>
>> When we produce an exe from a single c++ file, there is no linking
>> need, so there is no problem. But when we separate the definition and
>
> That's not how it works, the linker is always required to produce an
> executable.

I am wrong. But how the linker find the __attribute__((__stdcall__))
bottom::fun1() when there is a single source file? There is no such
definition in the object file.

>> And Obviously, this is not a linker error, it is the problem gcc
>> generate a " U [EMAIL PROTECTED]" for indeed existing
>> definition of "__attribute__((__stdcall__)) bottom:fun1()" .
>
> The "U" lines are correct and aren't the problem; those are call sites
> to the properly mangled symbol name.  What's incorrect is that gcc emits
> the function definitions (the 'T' lines) without the proper stdcall name
> mangling.  If gcc used the proper mangling for the definitions then the
> undefined call sites would no longer be undefined and would not show up
> in the objdump output any more.

So, are you sure this bug is identical to PR27067 or not?

Regards!
Bo

Is there some mistakes in comments of passes.c?

[梁�]

The comments in passes.c at the beginning are identical to toplev.c.

--
   此致
敬礼！

梁��