date:20091111


Frank Ch. Eigler wrote:

Ian Lance Taylor i...@google.com writes:


[...]  Go, a new experimental systems programming language designed
by a small group at Google.  [...]  The frontend is written in, yes,
C++. [...]


Neat.  Are there any plans to have a front-end written in its own
language (and use the current C++ one only for bootstrapping)?



My feeling is that Google's Go (quite a nice language from the slides I just have read) is almost canonically the case 
for a front-end plugin.


That is, gccgo could be the following shellscript
  #! /bin/sh
  gcc -fplugin=gofrontend.so $*
and of course we need to add into gcc-4.5 the few plugin hooks to make that 
easy.

Regards.


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

Creating a function dynamically

2009-11-11 Thread Taro Okumichi

I am hacking in the gcc code and come to a point where I cant come
any further: I want to expand the -finstrument-functions to create a dynamic
dump function in the background, instead of  calling a fixed
__cyg_profile_func_enter/exit
I.e:
 if I have
 f1(int a,int b) { }
 I would like to create a dynamic function
 _trace_f1(int a,int b) {
   __trace_int(a);
   __trace_int(b);
 }

I apended the code I use below. the function
gimplify_create_trace_func (shown below) is
called from:

gimplify_function_tree (tree fndecl)-
 gimplify_create_trace_func(fndecl,_trace_f1);


These are the steps I do in gimplify_create_trace_func():

1. Build function definition for _trace_f1:   build_decl
(FUNCTION_DECL, get_identifier (n), fntyp);
2. Declare function parameters for a and b: build_decl (PARM_DECL,
get_identifier (argname), TREE_TYPE(param));
3. Output each parameter:  build_function_call_expr (trace ,
thisparaml );
  where thisparaml is a or b and trace is a external function
ref repending on the typ:

The problem now is this:
The assembler output is:

_trace_f1:
   pushl   %ebp
   movl%esp, %ebp
   subl$8, %esp
   movl$0, (%esp)
   call__trace__int
   movl$0, (%esp)
   call__trace__int
   leave
   ret

whereas I would expect:

_trace_f1:
   pushl   %ebp
   movl%esp, %ebp
   subl$8, %esp
   movl8(%ebp), %eax
   movl%eax, (%esp)
   call__trace__int
   movl12(%ebp), %eax
   movl%eax, (%esp)
   call__trace__int
   ...

Can anyone tell me what I am doing wrong. The compiler oututs
__trace__int(0) instead of using the function parameter as an argument:
 _trace_f1(int a,int b) {
   __trace_int(a);
  ...

Or can somebody point me to a codesnippet in  gcc that
does the same (create functions dynamically on the fly) so
I can  take a look and learn...


Greetings



--- create a dynamic funtion 

void
gimplify_create_trace_func (tree fndecl, char *n)
{
   int i;
   tree body = NULL;
   tree ir, prev, param, fn, fntyp, parm, tdef, argstyp =
NULL_TREE, argslist = NULL_TREE ;
   char argname[256];

   /* create function type */
   for (i = 0,param = DECL_ARGUMENTS (fndecl); param ; i++,param
=TREE_CHAIN (param)) {
   argstyp = tree_cons (NULL_TREE, TREE_TYPE(param), argstyp);
   }
   if (argstyp == NULL_TREE)
   argstyp = void_list_node;
   else {
   tree last = argstyp;
   argstyp = nreverse (argstyp);
   TREE_CHAIN (last) = void_list_node;
   }
   fntyp = build_function_type (void_type_node, argstyp);

   /* build function prototype */
   fn = build_decl (FUNCTION_DECL, get_identifier (n), fntyp);

   pushdecl (fn);

   prev = current_function_decl;
   current_function_decl = fn;

   push_scope();
   declare_parm_level ();

   /* build function argument list */
   for (i = 0,param = DECL_ARGUMENTS (fndecl); param ; i++,param
=TREE_CHAIN (param)) {
   tree argdecl;
   sprintf(argname,a%d,i);
   argdecl = build_decl (PARM_DECL, get_identifier
(argname), TREE_TYPE(param));
   argslist = chainon (argdecl, argslist);
   printf(decl:%x\n,argdecl);
   pushdecl(argdecl);
   DECL_ARTIFICIAL(argdecl) = 1;


   /* if (DECL_NAME (argdecl)) { */
   /*  bind (DECL_NAME (decl), decl, current_scope, */
   /*/\*invisible=*\/false, /\*nested=*\/false); */
   /* } */

   DECL_CONTEXT (argdecl) = fn;
   }
   argslist = nreverse (argslist);
   DECL_ARGUMENTS (fn) = argslist;


   ir = build_decl (RESULT_DECL, NULL_TREE, void_type_node);
   DECL_CONTEXT (ir) = fn;
   DECL_ARTIFICIAL (ir) = 1;
   DECL_IGNORED_P (ir) = 1;
   DECL_RESULT (fn) = ir;


   TREE_STATIC (fn) = 0;
   TREE_USED (fn) = 1;
   DECL_ARTIFICIAL (fn) = 1;
   DECL_IGNORED_P (fn) = 1;
   DECL_NO_INSTRUMENT_FUNCTION_ENTRY_EXIT (fn) = 1;

   allocate_struct_function (fn);

   if (tracetype == trace_out_none) {

   DECL_SAVED_TREE (fn) = build_empty_stmt();

   } else if (tracetype == trace_out_all) {

   tree thisp, stmts;

   stmts = alloc_stmt_list();

   /* output one call for each argument */
   for (i = 0,thisp = argslist, param = DECL_ARGUMENTS
(fndecl); param; i++,thisp = TREE_CHAIN (thisp), param =TREE_CHAIN
(param)) {
   tree trace, thisparaml = NULL, x;
   char *name =
gen_aux_info_type_str_canonical(TREE_TYPE(param));
   name = concat(__trace__, name, NULL);
   fprintf(stderr, typ: \%s\ \n, name);

   trace = build_function_type_list
(void_type_node, TREE_TYPE(thisp), NULL);

Re: libtool update?

2009-11-11 Thread Ralf Wildenhues

Hello Rainer,

* Rainer Emrich wrote on Wed, Nov 11, 2009 at 05:47:13PM CET:
 Any news on libtool? Does anybody care to update?

Work in progress:
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00032.html

Since then, I found a couple of issues, one of which was a
bug in the sync and the other I'm not yet sure whether it
is a GCC configury or Libtool upstream bug.

I hope to get to it within the next couple of weekends,
but I'm swamped ATM (of course won't mind being beaten
to if someone feels so inclined).

Cheers,
Ralf

RE: Understanding IRA

2009-11-11 Thread Ian Bolton

Ian Bolton wrote:
 Vladimir Makarov wrote:
  Ian Bolton wrote:
   Yesterday, I wrote:
  
   BTW, today I have achieved some good results with existing IRA by
  doing
   the following:
  
   1) Changed the REG_ALLOC_ORDER so that TOP_CREGS are given out
  before
   BOTTOM_REGS.  My previous hacked version worked by increasing the
   priority of those that wanted BOTTOM_REGS, so they got first pick;
  this
   new version makes them wait their turn, but ensures those with
  higher
   priority take TOP_CREGS before BOTTOM_REGS.
  
   The analogy, I think, is of giving out meals on an airplane.  Most
   people will eat meat or vegetarian meals, whereas vegetarians only
   want vegetarian meals.  My hacked version was effectively allowing
   the vegetarians to push to the front of the queue and get their
  meals;
   this new version works by encouraging the meat eaters to eat the
  meaty
   meals first, leaving more suitable meals for the vegetarians
 further
   down the plane.
  
   2) I have forced propagation of allocnos to parent regions with
 the
   following hack in find_allocno_class_costs():
  
   {
 /* Propagate costs to upper levels in the region
tree.  */
 parent_a_num = ALLOCNO_NUM (parent_a);
 for (k = 0; k  cost_classes_num; k++)
   COSTS_OF_ALLOCNO (total_costs, parent_a_num)-cost[k]
 += COSTS_OF_ALLOCNO (total_costs, a_num)-cost[k];
 COSTS_OF_ALLOCNO (total_costs, parent_a_num)-mem_cost
   += COSTS_OF_ALLOCNO (total_costs, a_num)-mem_cost;
 /* BEGIN IGB-IRA CHANGE 2 */
 /* Force total_costs to propagate upwards, by setting
allocno_costs to be total_costs */
 for (k = 0; k  cost_classes_num; k++)
   COSTS_OF_ALLOCNO (allocno_costs, parent_a_num)-cost[k]
 = COSTS_OF_ALLOCNO (total_costs, parent_a_num)-cost[k];
   COSTS_OF_ALLOCNO (allocno_costs, parent_a_num)-mem_cost
 = COSTS_OF_ALLOCNO (total_costs, parent_a_num)-mem_cost;
 /* END IGB-IRA CHANGE 2 */
   }
  
   I don't know why propagation isn't happening normally, but
   this total_costs hack achieves the same thing for me at the
   moment.  Is there any information I could provide to help
   someone tell me why propagation isn't happening?
  
  
   Good news!  I have been able to remove my total_costs hack
   above by instead commenting out the following line from ira_build()
   in ira-build.c:
  
 remove_unnecessary_regions (false);
  
   For my situation at least, this function is preventing the
   propagation of useful allocno information from region 1 to
   region 0.  Without my change, the allocation for a pseudo in
   region 0 is not aware of how that pseudo will be used inside
   a loop in region 1; the real impact of this is that we need
   to then do a register move *inside the loop* into a valid
   register class for the instruction in region 1.
  
   I do not believe this will impact anyone with a regular
   register set, but for any architecture where some instructions
   can only use a subset of the register bank, I believe that
   all regions are always necessary, since cost information
   for each allocno is relevant and important.
  
   I still need to do some more testing in regards this fix,
   but I wanted to put my findings out there as soon as possible
   for comment from the experts.
  
  The function (remove_unnecessary_regions) is used to increase RA
 speed
  by decreasing number of regions.  The region is removed if the
 register
  pressure is not high in the region in other words if the probability
 to
  spill pseudos on the region border to improve RA in the region is
  small.
 
  But when the region is removed and correspondingly allocnos (see
  function remove_unecessary_allocnos) in the region the info including
  hard register costs is propagated to the  corresponding allocnos in
 the
  parent region (see function propagate_some_info_from_allocno).
 
  I've just checked the code it looks ok to me.  Ian, it would be nice
 if
  you figure out why the propagation does not happen.   As Jeff wrote,
  fixing that would be important practically for any target.
 
 (I'm in the middle of a hefty compile at the moment, so I can't do any
 more debugging yet, but I figured I'd think out loud on this list in
 the
 mean time.)
 
 At first, I thought the problem was that
 propagate_some_info_from_allocno()
 appears to only pass up information about the cover class, as opposed
 to every cost_class (which was what my total_costs hack did).  However,
 I see
 that the propagate_allocno_info() function, which is now being called
 when
 I comment out remove_unnecessary_regions(), also only passes up
 information
 about the cover class, so I don't think it's propagation that's the
 issue.
 
 Looking at ira_build(), I see that there is a call to create_caps()
 just
 after the call to propagate_allocno_info() - both of which were guarded
 by
 the condition more_one_region_p(), which is only true when I comment
 out
 the call to

Re: gccgo: A gcc frontend for Go, a new programming language

2009-11-11 Thread Joseph S. Myers

On Wed, 11 Nov 2009, Basile STARYNKEVITCH wrote:

 My feeling is that Google's Go (quite a nice language from the slides I just
 have read) is almost canonically the case for a front-end plugin.

Well, if you really wish to impede host portability in several different 
ways.

* Use of a plugin drops portability to all non-ELF hosts.

 That is, gccgo could be the following shellscript

* Use of a shell script for an installed tool drops portability to MinGW 
hosts (see recent discussion of how while using MinGW as a *build* system 
is a pain because of all the other infrastructure needed to support shell 
scripts and other tools for the build, it works fine as a *host*).

   #! /bin/sh
   gcc -fplugin=gofrontend.so $*

* Use of $* drops support for file names with spaces in (and various other 
cases), use $@.

(Note: I have not looked at whether there are in fact host or target 
portability issues with the present implementation.)

I'm sure GNU/Linux distributors would find it useful to be able to build 
front ends separately from GCC rather than needing to patch in several 
different out-of-tree front ends.  But plugins (in the .so sense, as 
opposed to dropping in another executable alongside cc1 etc. and providing 
the objects needed to build such executables) may not be the best approach 
for that (rather, I'd imagine per-language specs potentially being read 
from a file by the driver).  And users *should* be able to use just the 
gcc driver for all languages rather than needing separate drivers for 
each language, and not need special options for a particular language.

(For some of the less esoteric languages distributors find themselves 
patching in, I'd favour integration in the GCC source tree, but the 
maintainers of the front ends don't generally seem to have been interested 
in that.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: gccgo: A gcc frontend for Go, a new programming language

2009-11-11 Thread Joe Buck

On Wed, Nov 11, 2009 at 11:26:36AM -0800, Basile STARYNKEVITCH wrote:
 My feeling is that Google's Go (quite a nice language from the slides I just 
 have read) is almost canonically the case 
 for a front-end plugin.

I have some major concerns about this suggestion.  Isn't this a recipe for
getting people to stop contributing changes to gcc?

You seem to want people to use plugins for everything.  I would prefer to
see more limited uses.  Plugins are appropriate for small, specialized
additions to gcc that aren't generally useful enough, or stable enough, to
include in the main gcc distribution.  For example, a specialized static
checker, or a pass to add an unusual kind of instrumentation, or something
to gather statistics on a body of source code.

They weren't intended as a way of attaching complete new front ends
or complete new back ends.  That was the thing that RMS feared the most,
and he had at least some justification: would we have a C++ compiler or
an Objective-C compiler if the companies who employed the original authors
had the alternative of hooking into GCC without contributing their code?
There's some evidence that they would not have.

We currently lack enough plugin hooks to give a complete front end a
stable interface, and I would argue that this is a feature.

Re: gccgo: A gcc frontend for Go, a new programming language

2009-11-11 Thread Chris Lattner



On Nov 11, 2009, at 12:43 PM, Joe Buck wrote:



They weren't intended as a way of attaching complete new front ends
or complete new back ends.  That was the thing that RMS feared the  
most,
and he had at least some justification: would we have a C++ compiler  
or
an Objective-C compiler if the companies who employed the original  
authors
had the alternative of hooking into GCC without contributing their  
code?

There's some evidence that they would not have.


I thought it *was* a goal to allow attaching new (GPL3 compatible)  
backends?


-Chris

Re: gccgo: A gcc frontend for Go, a new programming language

Joe Buck wrote:

On Wed, Nov 11, 2009 at 11:26:36AM -0800, Basile STARYNKEVITCH wrote:
My feeling is that Google's Go (quite a nice language from the slides I just have read) is almost canonically the case
for a front-end plugin.

I have some major concerns about this suggestion. Isn't this a recipe for
getting people to stop contributing changes to gcc?

You seem to want people to use plugins for everything. I would prefer to
see more limited uses. Plugins are appropriate for small, specialized
additions to gcc that aren't generally useful enough, or stable enough, to
include in the main gcc distribution. For example, a specialized static
checker, or a pass to add an unusual kind of instrumentation, or something
to gather statistics on a body of source code.

My intuitions (perhaps wrong) when posting my initial suggestion have been

* Google Go is still a niche language. And I would guess it is targetted to Linux Unix variants (because I heard that
Google does not use Windows on their web-crawling servers, but only Unix variants, mostly Linux). I really feel that a
niche language is exactly a small, specialized addition to gcc that isn't generally useful enough, or stable enough,
to be included in the main gcc distribution. I would be glad to

* Looking at other niche languages in the past having had a GCC front-end (D, Mercury, perhaps some Modula, or Cobol, or
Pascal, ...) it seems that most of them are not accepted in the GCC trunk proper. As far as I understand, neither
gcc-4.4 nor the current trunk can be configured to accept D or Mercury (or any else non-mainstream) langauge. So it
seems that it is *extremely* difficult to have an experimental language accepted inside GCC core. But I admit I might be
very wrong, because I don't know of all the details. My feeling (perhaps wrong) is that the GCC community don't care
much about exotic languages (and that is sadly ok for me), only about very mainstream languages. In addition, some
existing front-ends in GCC does not seem very used (I never met any person using gcj, and I don't know of many Debian
packages compiled with it). Several FSF blessed language implementations (GNU Smalltalk, GNU Clisp, the future GNU
Epsilon) are *not* GCC derived implementations.

* The current GCC trunk still lacks a few hooks for other frontend languages as plugins. I really believe that feature
would be a good thing (notice that LLVM in contrast was initially designed to be a library usable by front-ends, with
Clang appearing later). Because I am widely guessing that for people experimenting new languages, making a plugin would
be a bit easier (assuming it is possible) and more importantly, distributing plugin binaries will hopefully be easier
than distributing GCC variants. Of course, there will be a plugin mess (this is not avoidable).

* GCC branches experimental variants are so complex that nobody uses them. This includes GCC variants for exotic
languages. And even a bit used GCC variants (like D) are lagging w.r.t. to GCC core evolution (AFAIK D is only at GCC
4.2 level).

I can tell it differently: imagine you are an academic (or a researcher at Google or some big corporation) wanting to
experiment some new language. Today (end of 2009) you better not base your implementation on GCC (better use LLVM, or
target some existing bytecode like CIL/C# -as F# does-, Java/JVM as Clojure Scala do, ...- or build your own VM (as in
Ocaml), or perhaps generate C code for GCC. We might aim to change that, and make easier to make new GCC front-ends. I
feel that plugins could help here.

I am indeed hoping that in a couple of years, most systems having GCC installed
will permit plugins for it.

Of course, we could also not care about GCC supporting strange front-ends.

In addition, plugin extensions required for front-ends will very probably have a lot more success if they are pushed by
Google people than by random GCC hackers like me.

I do know quite well the Ocaml team, but I won't dare suggesting them to make an Ocaml front-end to GCC. Xavier Leroy
(the head of Ocaml team at Inria) would rightly laugh at such a suggestion.

Regards.

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

Re: gccgo: A gcc frontend for Go, a new programming language

2009-11-11 Thread Ian Lance Taylor

f...@redhat.com (Frank Ch. Eigler) writes:

 Ian Lance Taylor i...@google.com writes:

 [...]  Go, a new experimental systems programming language designed
 by a small group at Google.  [...]  The frontend is written in, yes,
 C++. [...]

 Neat.  Are there any plans to have a front-end written in its own
 language (and use the current C++ one only for bootstrapping)?

I don't personally have any plans to write the gcc frontend in Go,
though that would be clearly possible.  There are vague plans for a
full compiler written in Go.

Note that there is another Go compiler, gccgo is really more of a
secondary one at this point.

Ian

Re: gccgo: A gcc frontend for Go, a new programming language


Basile STARYNKEVITCH wrote:


* Google Go is still a niche language. And I would guess it is targetted 
to Linux  Unix variants (because I heard that Google does not use 
Windows on their web-crawling servers, but only Unix variants, mostly 
Linux). I really feel that a niche language is exactly a small,  
specialized addition to gcc that isn't generally useful enough, or 
stable enough, to be included in the main gcc distribution. I would be 
glad to


I forgot to type be wrong.

I mean also

I would be happy if niche languages could be more easily added into GCC core.

But I think nobody wants that. I could guess reasons for not wanting extra front-ends in GCC (the same reasons could 
even perhaps be used to remove rarely used front-ends like Objective-C++ from future GCC). But I also think that


Regards

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

Invitation avant-première

2009-11-11 Thread Rotary espoir en tête

Bonjour,

Nous vous proposons de découvrir en avant-première le dernier Disney, « Le
drôle de Noël de Scrooge » avec Jim Carrey,

De faire avancer la recherche sur les maladies du cerveau,

De faire plaisir à vos collaborateurs et à vos clients… 

Et de découvrir le Rotary !

C'est une initiative des 1 035 Rotary clubs de France qui avec leurs 4
éditions précédentes ont déjà permis de recueillir près de 3 millions
d’euros, totalement attribués au financement de matériel nécessaire à la
recherche.

 
Dès à présent, réservez le nombre de places que vous souhaitez et
participez ainsi à cette mobilisation nationale !

En vous remerciant de votre réponse au présent courrier. 

Une facture ou un reçu fiscal vous sera établi à votre demande pour tout
don de 150€, équivalent à 10 places.

Pour tout renseignement et envoi de dons, contactez :

Mr TUMER  , 233 rue du Faubourg Saint Martin 75010 Paris
Tél : 06 74 19 35 16  Email : contact-rot...@myreso.fr

Pour plus d'information sur l'opération: http://www.espoir-en-tete.org/

Pour plus d'information sur le Rotary: http://www.rotary-paris-nord.fr/

Pour ne plus recevoir de mail de notre part, cliquez sur le lien ci-dessous:
http://ml.myreso.fr/form.php?1651d7ca755f7fb42d1e

Re: gccgo: A gcc frontend for Go, a new programming language

2009-11-11 Thread Joseph S. Myers

On Wed, 11 Nov 2009, Basile STARYNKEVITCH wrote:

 * Looking at other niche languages in the past having had a GCC front-end (D,
 Mercury, perhaps some Modula, or Cobol, or Pascal, ...) it seems that most of
 them are not accepted in the GCC trunk proper. As far as I understand, neither
 gcc-4.4 nor the current trunk can be configured to accept D or Mercury (or any
 else non-mainstream) langauge. So it seems that it is *extremely* difficult to
 have an experimental language accepted inside GCC core. But I admit I might be

No, it's not difficult.  The basic requirement is that the maintainers of 
the front end, or someone with the interest and ability to maintain a fork 
of it (as with gfortran originating based on g95), actually want to 
include it in GCC and do the development in the GCC context (and of course 
that the legal requirements are met regarding assignments).  We last had 
discussions of Pascal integration in March 2005, and the others haven't 
even got to the point of someone expressing an interest in integrating it; 
and the basic requirement for any front end or back end to be integrated 
is that it gets submitted by someone willing to be a maintainer for it in 
GCC.

If maintainers want to work in the GCC context and have their front ends 
become a full part of GCC on the same level and under the same rules as 
other front ends, I expect their front ends to be accepted, even those for 
fairly obscure languages (we had a CHILL front end for a while).  I don't 
think any of those you mention have been rejected, just not submitted.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: gccgo: A gcc frontend for Go, a new programming language


Joseph S. Myers wrote:

On Wed, 11 Nov 2009, Basile STARYNKEVITCH wrote:


* Looking at other niche languages in the past having had a GCC front-end (D,
Mercury, perhaps some Modula, or Cobol, or Pascal, ...) it seems that most of
them are not accepted in the GCC trunk proper. 




No, it's not difficult.  The basic requirement is that the maintainers of 
the front end, or someone with the interest and ability to maintain a fork 
of it (as with gfortran originating based on g95), actually want to 
include it in GCC and do the development in the GCC context (and of course 
that the legal requirements are met regarding assignments).  We last had 
discussions of Pascal integration in March 2005, and the others haven't 
even got to the point of someone expressing an interest in integrating it; 
and the basic requirement for any front end or back end to be integrated 
is that it gets submitted by someone willing to be a maintainer for it in 
GCC.


If maintainers want to work in the GCC context and have their front ends 
become a full part of GCC on the same level and under the same rules as 
other front ends, I expect their front ends to be accepted, even those for 
fairly obscure languages (we had a CHILL front end for a while).  I don't 
think any of those you mention have been rejected, just not submitted.


This is a very interesting information.

But I feel that as a community we can understand it as both a half-full or a 
half-empty glass of wine.

On one hand, foreign languages implementors (of GCC based compilers for niche 
languages)
did usually not make the effort to even ask their front-end to enter GCC. Maybe 
they are too shy...

But perhaps, as a community, we could possibly have (involuntarily) frightenned 
them.

And my feeling is that offering the small infrastructure to permit niche front-ends thru plugins (or something else) 
could be percieved as an invitation to join our GCC community. [In contrast to some people, I don't see plugins as a 
possibility of fragmenting the community; I see plugins as a way to attract more external people to GCC].


And the landscape did change w.r.t. RMS feelings about Objective C. My understanding is that Apple is more interested 
today (end of 2009) in LLVM than in GCC. So I won't be surprised if in a couple of years most compilers on Apple systems 
would be LLVM based (and no more GCC based). Of course, I know nothing about that, so I could be entirely wrong. (I 
suppose that most north-american GCC people know a lot more Apple than I do; I only used to have a an Apple G4 laptop 
several years ago, and it was a disappointing experience - the hardware broke after 13 months!).


BTW, I understood perhaps wrongly that Ian Taylor seems to believe that gccgo has not much future, and that most of the 
software written in Go (the Google niche language) could be compiled by something which is not GCC based.


Again, I do believe that plugins will attract new people to GCC. And I also 
believe it is a good thing.

Regards.

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

Re: gccgo: A gcc frontend for Go, a new programming language

2009-11-11 Thread Ian Lance Taylor

Basile STARYNKEVITCH bas...@starynkevitch.net writes:

 BTW, I understood perhaps wrongly that Ian Taylor seems to believe
 that gccgo has not much future, and that most of the software written
 in Go (the Google niche language) could be compiled by something which
 is not GCC based.

I certainly hope that gccgo has a future.  I wouldn't have spent so
much time on it otherwise.  It generates better code than the other Go
compiler.

I don't personally see any particular advantage to worrying about
writing new frontends as plugins.  I think plugins have specific very
useful goals, but I don't think that new frontends are one of them.

Ian

[Bug middle-end/42004] [4.5 regression] Revision 154079 failed g++.dg/torture/stackalign/unwind-2.C

2009-11-11 Thread ebotcazou at gcc dot gnu dot org



--- Comment #1 from ebotcazou at gcc dot gnu dot org  2009-11-11 08:25 
---
 On Linux/ia32, revision 154079:
 
 http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00300.html
 
 caused:
 
 FAIL: g++.dg/torture/stackalign/unwind-2.C  -O1  execution test
 FAIL: g++.dg/torture/stackalign/unwind-2.C  -O2  execution test
 FAIL: g++.dg/torture/stackalign/unwind-2.C  -O2 -flto  execution test
 FAIL: g++.dg/torture/stackalign/unwind-2.C  -O2 -fwhopr  execution test

On i686 only, i[345]86 are OK.  Investigating.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|ebotcazou at gcc dot gnu dot|
   |org |
 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-11-11 08:25:01
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42004

[Bug fortran/41631] [OOP] Support CLASS IS () in SELECT TYPE



--- Comment #1 from janus at gcc dot gnu dot org  2009-11-11 09:41 ---
Fixed on the fortran-dev branch as of r154089.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-11-11 09:41:40
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41631

[Bug middle-end/41930] [4.5 regression] cc1 SEGV compiling maxval_r16.c



--- Comment #6 from ubizjak at gmail dot com  2009-11-11 10:01 ---
(In reply to comment #3)
 Subject: Re:  [4.5 regression] cc1 SEGV compiling maxval_r16.c
 
  I'll build a cross compiler from i386-pc-solaris2.10 and see if I can
  reproduce the problem there.
 
 Unfortunately, the problem does not reproduce in such a cross compiler,
 so I'll have to either start a native reghunt or find a way to debug the
 native compiler (maybe compiling with -g without -O2 or try the stage1
 compiler if it is also affected).

Add --with-long-double-128 to your configure flags and it will also trigger
with a cross compiler.

Confirmed with a cross from x86_64-pc-linux-gnu.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-11-11 10:01:06
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41930

[Bug middle-end/41930] [4.5 regression] cc1 SEGV compiling maxval_r16.c



--- Comment #7 from ubizjak at gmail dot com  2009-11-11 10:37 ---
We recurse with:

simplify_replace_fn_rtx called, x =
(expr_list:REG_DEP_TRUE (symbol_ref:DI (_OtsGeqX) [flags 0x41])
(expr_list:REG_DEP_TRUE (mem:TF (reg/f:DI 75 [ array_3(D)-data ]) [3 S16
A128])
(expr_list:REG_DEP_TRUE (reg:TF 76)
(nil

simplify_replace_fn_rtx called, x =
(symbol_ref:DI (_OtsGeqX) [flags 0x41])

simplify_replace_fn_rtx called, x =
(expr_list:REG_DEP_TRUE (mem:TF (reg/f:DI 75 [ array_3(D)-data ]) [3 S16
A128])
(expr_list:REG_DEP_TRUE (reg:TF 76)
(nil)))

simplify_replace_fn_rtx called, x =
(mem:TF (reg/f:DI 75 [ array_3(D)-data ]) [3 S16 A128])

simplify_replace_fn_rtx called, x =
(reg/f:DI 75 [ array_3(D)-data ])

simplify_replace_fn_rtx called, x =
(expr_list:REG_DEP_TRUE (reg:TF 76)
(nil))

simplify_replace_fn_rtx called, x =
(reg:TF 76)

gcc dies in case 'e':, recursing with (nil) from:

(expr_list:REG_DEP_TRUE (reg:TF 76)
(nil))

The fix is then trivial, like [no whitespace diff]:

--cut here--
Index: simplify-rtx.c
===
--- simplify-rtx.c  (revision 154088)
+++ simplify-rtx.c  (working copy)
@@ -489,6 +489,8 @@ simplify_replace_fn_rtx (rtx x, const_rt
break;

   case 'e':
+   if (XEXP (x, i))
+ {
op = simplify_replace_fn_rtx (XEXP (x, i), old_rtx, fn, data);
if (op != XEXP (x, i))
  {
@@ -496,6 +498,7 @@ simplify_replace_fn_rtx (rtx x, const_rt
  newx = shallow_copy_rtx (x);
XEXP (newx, i) = op;
  }
+ }
break;
   }
   return newx;
--cut here--


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-11-11 10:01:06 |2009-11-11 10:37:52
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41930

[Bug middle-end/41930] [4.5 regression] cc1 SEGV compiling maxval_r16.c



--- Comment #8 from ubizjak at gmail dot com  2009-11-11 11:10 ---
Testing patch (it bootstraps OK on alpha-linux-gnu).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41930

[Bug fortran/42008] New: Wrongly rejected derived types with default initializers in PURE procedures

2009-11-11 Thread burnus at gcc dot gnu dot org

Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/141265154c2fcc71

Reinhold Bader thinks that at least the second program, using default
initializers, is valid. Oddly, the program works with the TYPE is not defined
locally but use-associated.

The first program of M. Restelli is presumably wrong as it uses variables which
are implicitly declared as SAVE. - But one should re-check.


ifort v11.1, NAG f95 v5.1, pathscale 3.3b all accept all programs, g95 and
gfortran reject one and two (B).


!-- Program one --
module mod_xyz
 implicit none
contains
 pure subroutine psub()
  type ilist
type(ilist), pointer :: next = null()
integer :: i
  end type ilist
 end subroutine psub
end module mod_xyz
!--

!-- Program two (A) --
module mod_xyz
 implicit none
 type ilist
   type(ilist), pointer :: next = null()
   integer :: i
 end type ilist
contains
 pure subroutine psub()
  type(ilist) :: var ! ACCEPTED
 end subroutine psub
end module mod_xyz

!-- Program two (B) --
module mod_xyz2
 implicit none
contains
 pure subroutine psub()
  type ilist
type(ilist), pointer :: next = null()
integer :: i
  end type ilist
  type(ilist) :: var ! REJECTED
 end subroutine psub
end module mod_xyz2
!-


-- 
   Summary: Wrongly rejected derived types with default initializers
in PURE procedures
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42008

[Bug c++/42000] missing -Wuninitialized warning on a user-defined class ctor

2009-11-11 Thread redi at gcc dot gnu dot org



--- Comment #1 from redi at gcc dot gnu dot org  2009-11-11 11:50 ---
It would certainly be nice to get warnings about members that are not
initialized in the constructor, I don't think GCC currently does that anywhere.

If you add -O then you will get a warning for the use of the member.  It's
unfortunate that this warning is missed without optimisation, but
-Wuninitialized no longer warns if you use it without -O


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42000

[Bug fortran/42008] Wrongly rejected derived types with default initializers in PURE procedures

2009-11-11 Thread burnus at gcc dot gnu dot org



--- Comment #1 from burnus at gcc dot gnu dot org  2009-11-11 12:54 ---
Misread the program one. I think it is also valid.

The constraint which is wrongly applied is:

C1268 A local variable declared in the specification-part or
internal-subprogram-part of a pure subprogram shall not have the SAVE
attribute.

I could not find any (other) relevant constraint in 12.6 Pure procedures.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||32834
  nThis||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42008

[Bug libstdc++/35569] [c++0x] std::bind result functor doesn't accept rvalues

2009-11-11 Thread paolo dot carlini at oracle dot com



--- Comment #9 from paolo dot carlini at oracle dot com  2009-11-11 13:19 
---
Jon, do you have any updated plans about this and related issues? I think it
would be nice if we could make progress on the C++0x functional for 4.5.0...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||paolo dot carlini at oracle
   ||dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35569

[Bug bootstrap/42002] Bootstrap failure: ld doesn't find 64-bit libelf on Fedora 11

2009-11-11 Thread lucier at math dot purdue dot edu



--- Comment #2 from lucier at math dot purdue dot edu  2009-11-11 13:52 
---
Thanks a lot for the explanation!

I'm looking through the list of packages on Fedora with elfutils in the title;
there is no elfutils-libelf-devel.ppc64, but the only ppc64 packages I can find
are

elfutils-devel-0.142-1.fc11 (ppc64)

with file list

/usr/include/dwarf.h
/usr/include/elfutils
/usr/include/elfutils/elf-knowledge.h
/usr/include/elfutils/libasm.h
/usr/include/elfutils/libdw.h
/usr/include/elfutils/libdwfl.h
/usr/include/elfutils/libebl.h
/usr/include/elfutils/version.h
/usr/lib64/libasm.so
/usr/lib64/libdw.so
/usr/lib64/libebl.a

and

elfutils-libelf-0.142-1.fc11 (ppc64)

with file list

/usr/lib64/libelf-0.142.so
/usr/lib64/libelf.so.1

So I put in the link from libelf.so to libelf.so.1 by hand and the bootstrap is
proceeding.

Should I file a bug report with Fedora?  I was told Fedora 12 won't support
ppc64, so maybe there's no point.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42002

[Bug libstdc++/35569] [c++0x] std::bind result functor doesn't accept rvalues

2009-11-11 Thread redi at gcc dot gnu dot org



--- Comment #10 from redi at gcc dot gnu dot org  2009-11-11 14:05 ---
Sorry for the lack of progress, I'll take another crack at it this week and
report back on what I've got and what doesn't work.  If I can't finish it I'll
say so and unassign myself from this PR


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35569

[Bug bootstrap/42002] Bootstrap failure: ld doesn't find 64-bit libelf on Fedora 11

2009-11-11 Thread jakub at gcc dot gnu dot org



--- Comment #3 from jakub at gcc dot gnu dot org  2009-11-11 14:20 ---
Not sure where you searched,
http://download.fedora.redhat.com/pub/fedora/linux/updates/11/ppc/
certainly contains both
elfutils-libelf-devel-0.142-1.fc11.ppc.rpm
elfutils-libelf-devel-0.142-1.fc11.ppc64.rpm
and similarly Everything tree.  And F12 also supports ppc64.  This is all
distro specific and doesn't belong here though.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42002

[Bug lto/42009] New: LTO unable to link in presence of multiple inheritance

The C++ testcase that I am about to attach compiles and links well
without LTO at all optimizations levels.  Unfortunately, whenever I
try to compile it with LTO (at any optimization level including zero),
I get the following link error:

mjam...@host:~/gcc/fail$ ~/gcc/inst/trunk/bin/g++ -flto testcase.cpp 
/tmp/ccxMi1Vq.lto.o:(.rodata._ZTV1B[_ZTV1B]+0x18): undefined reference to
`_ZThn16_N1B3fooEi'
collect2: ld returned 1 exit status

When I remove the first ancestor of class B from the list of
ancestors, the testcase links and works fine.

I get a very similar error on x86_64 too.  On both machines the used
compiler is pristine trunk revision 154038.


-- 
   Summary: LTO unable to link in presence of multiple inheritance
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jamborm at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42009

[Bug lto/42009] LTO unable to link in presence of multiple inheritance



--- Comment #1 from jamborm at gcc dot gnu dot org  2009-11-11 14:40 ---
Created an attachment (id=19004)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19004action=view)
Testcase

This is the testcase.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42009

[Bug lto/41932] LTO ICE when compiling ocaml trunk (incompatible type)

--- Comment #10 from jamborm at gcc dot gnu dot org  2009-11-11 15:07 
---
Subject: Bug 41932

Author: jamborm
Date: Wed Nov 11 15:07:18 2009
New Revision: 154095

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154095
Log:
2009-11-11  Martin Jambor  mjam...@suse.cz

PR lto/41932
* ipa-prop.c (ipa_update_after_lto_read): Call
ipa_check_create_node_params and ipa_check_create_edge_args.  Also
call ipa_initialize_node_params instead of ipa_populate_param_decls.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-prop.c

-- 

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41932

[Bug testsuite/42001] LTO tests fail with non multilib targets (but still not --disable-multilib )

2009-11-11 Thread hjl dot tools at gmail dot com



--- Comment #7 from hjl dot tools at gmail dot com  2009-11-11 15:08 ---
(In reply to comment #5)
 well most targets are multilibbed now so I never saw it.  I think you should
 just remove -lm then .
 

-lm is added to most, if not, tests. How do you remove it? Shouldn't
we have both -r and -shared options? We use -r for those targets which
don't support shared libraries.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42001

[Bug lto/41932] LTO ICE when compiling ocaml trunk (incompatible type)

2009-11-11 Thread wouter dot vermaelen at scarlet dot be



--- Comment #11 from jamborm at gcc dot gnu dot org  2009-11-11 15:10 
---
Basile, can you please confirm that this is now fixed?  Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41932

[Bug testsuite/41913] ERROR: tcl error sourcing gcc.dg/lto/lto.exp

2009-11-11 Thread hjl dot tools at gmail dot com



--- Comment #5 from hjl dot tools at gmail dot com  2009-11-11 15:33 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00541.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||11/msg00541.html
Summary|ERROR: tcl error sourcing   |ERROR: tcl error sourcing
   |/home/dave/gnu/gcc- |gcc.dg/lto/lto.exp
   |4.5/gcc/gcc/testsuite/gcc.dg|
   |/lto/lt |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41913

[Bug driver/42007] Make -mfloat-gprs=double the default when compiling for powerpc-linux-gnuspe target

2009-11-11 Thread jsm28 at gcc dot gnu dot org



--- Comment #1 from jsm28 at gcc dot gnu dot org  2009-11-11 15:36 ---
Changing the meaning of an existing target triplet is a bad idea.  Use
--enable-e500-double when configuring GCC if you want
-mfloat-gprs=double by default.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42007

[Bug lto/42009] LTO unable to link in presence of multiple inheritance



--- Comment #2 from wouter dot vermaelen at scarlet dot be  2009-11-11 
18:26 ---
I (independently) found the same issue today.

I managed to reduce it to the following testcase:

 cat foo.cc
struct Base1 { virtual ~Base1(); };
struct Base2 { virtual ~Base2(); };
struct Foo : Base1, Base2 { virtual ~Foo(); };
Base1::~Base1() {}
Base2::~Base2() {}
Foo::~Foo() {}
int main() { return 0; }

 g++ foo.cc
[works fine]

 g++ -flto foo.cc
/usr/bin/ld: /tmp/ccNr43fh.lto.o: in function
_ZTV3Foo:ccuOnB3i.o(.gnu.linkonce.r._ZTV3Foo+0x30): error: undefined reference
to '_ZThn8_N3FooD1Ev'
/usr/bin/ld: /tmp/ccNr43fh.lto.o: in function
_ZTV3Foo:ccuOnB3i.o(.gnu.linkonce.r._ZTV3Foo+0x38): error: undefined reference
to '_ZThn8_N3FooD0Ev'
collect2: ld returned 1 exit status


-- 

wouter dot vermaelen at scarlet dot be changed:

   What|Removed |Added

 CC||wouter dot vermaelen at
   ||scarlet dot be


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42009

[Bug lto/42009] LTO unable to link in presence of multiple inheritance



--- Comment #3 from pinskia at gcc dot gnu dot org  2009-11-11 18:27 ---
Yes this is a known issue, thunks are not implemented.  I thought there was a
bug about this already too.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42009

[Bug c++/37352] thunks for virtual function should work on lto



--- Comment #9 from pinskia at gcc dot gnu dot org  2009-11-11 18:28 ---
*** Bug 42009 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37352

[Bug lto/42009] LTO unable to link in presence of multiple inheritance



--- Comment #4 from pinskia at gcc dot gnu dot org  2009-11-11 18:28 ---
This is a dup of bug 37352 which is about thunks not working.

*** This bug has been marked as a duplicate of 37352 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42009

[Bug c++/42010] New: ICE: lang_* check: failed in discriminator_for_local_entity, at cp/mangle.c:1581

2009-11-11 Thread zsojka at seznam dot cz

Following code crashes in gcc trunk revisions r154095 and r154098. r153685
compiles fine.

Command line switches:
g++ -std=c++0x
or
g++ -std=gnu++0x

-- testcase.cpp --
struct A {
  void f()
  {
static struct {
} s;
  }
};
--

$ /mnt/svn/gcc-trunk/binary-154095-lto/bin/g++ -v -std=gnu++0x -c -o tmp.o
testcase.cpp
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-154095-lto/bin/g++
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-154095-lto/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=lto,c,c++
--prefix=/mnt/svn/gcc-trunk/binary-154095-lto/
Thread model: posix
gcc version 4.5.0 2009 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-std=gnu++0x' '-c' '-o' 'tmp.o' '-shared-libgcc'
'-mtune=generic'

/mnt/svn/gcc-trunk/binary-154095-lto/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1plus
-fpreprocessed testcase-x.i -quiet -dumpbase testcase-x.i -mtune=generic
-auxbase-strip tmp.o -std=gnu++0x -version -o /tmp/ccQx8uCh.s
GNU C++ (GCC) version 4.5.0 2009 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 2009 (experimental), GMP version
4.3.1, MPFR version 2.4.1-p5, MPC version 0.7
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.5.0 2009 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 2009 (experimental), GMP version
4.3.1, MPFR version 2.4.1-p5, MPC version 0.7
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: ea1de8eb0212138b74b7539fd1683110
testcase-x.i: In member function #8216;void A::f()#8217;:
testcase-x.i:5:7: internal compiler error: lang_* check: failed in
discriminator_for_local_entity, at cp/mangle.c:1581
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.


-- 
   Summary: ICE: lang_* check: failed in
discriminator_for_local_entity, at cp/mangle.c:1581
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42010

[Bug testsuite/42001] LTO tests fail with non multilib targets (but still not --disable-multilib )

2009-11-11 Thread hjl dot tools at gmail dot com



--- Comment #8 from hjl dot tools at gmail dot com  2009-11-11 20:06 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00566.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||11/msg00566.html


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42001

[Bug c++/37352] thunks for virtual function should work on lto



--- Comment #10 from rguenth at gcc dot gnu dot org  2009-11-11 20:32 
---
There's a simple workaround for most cases, condition asm-thunks on
!flag_write_lto.  We'll do this if a proper implementation doesn't come up
for 4.5.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37352

[Bug testsuite/42001] LTO tests fail with non multilib targets (but still not --disable-multilib )

2009-11-11 Thread hjl at gcc dot gnu dot org

--- Comment #9 from hjl at gcc dot gnu dot org  2009-11-11 20:34 ---
Subject: Bug 42001

Author: hjl
Date: Wed Nov 11 20:34:13 2009
New Revision: 154104

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154104
Log:
2009-11-11  H.J. Lu  hongjiu...@intel.com

PR testsuite/42001
* gcc.dg/lto/lto.exp: Pass no-mathlib to lto_init.  Call
lto_finish at the end.

* lib/lto.exp (lto_init): Set mathlib to   for no-mathlib.
(lto_finish): New. Restore mathlib.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/lto/lto.exp
trunk/gcc/testsuite/lib/lto.exp

-- 

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42001

[Bug c/42006] [4.5 Regression] Termination problem with -O2 and -O3



--- Comment #1 from rguenth at gcc dot gnu dot org  2009-11-11 20:35 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
  Known to work||4.4.2
   Last reconfirmed|-00-00 00:00:00 |2009-11-11 20:35:30
   date||
Summary|Termination problem with -O2|[4.5 Regression] Termination
   |and -O3 |problem with -O2 and -O3
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42006

[Bug middle-end/42004] [4.5 regression] Revision 154079 failed g++.dg/torture/stackalign/unwind-2.C



-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42004

[Bug c++/42011] New: linker error with typedef struct

2009-11-11 Thread ookami1 at gmx dot de

Hello,

I'd like to point your attention to a weird linker error I see on my system
on gcc version 4.3.3, 4.4.1 and 4.4.2.
I could not find anything related to this in bugzilla using the keyword
typedef.
Here are three files I use to produce the error:

/*
 * bug.cpp
 *
 *  Created on: 07.11.2009
 *  Author: Wolf Lammen
 */

#include A.h

int main()
{
A::B().foo();
return 0;
}

===
/*
 * A.h
 *
 *  Created on: 07.11.2009
 *  Author: Wolf Lammen
 */

/*
 * this compiles and links fine, if I
 * a) inline foo i.e use void foo(){} and remove foo() from A.cpp
 * b) avoid the keyword typedef and use struct B { void foo(); }; instead
 */

struct A {
typedef struct {
void foo();
} B;
};

===
/*
 * A.cpp
 *
 *  Created on: 07.11.2009
 *  Author: Wolf Lammen
 */

#include A.h

void A::B::foo() {}

===

Here's the output I get with g++, latest version
(similar for 4.3.3 or 4.4.1)

w...@kubuntu-910:~/bug$ ../bin/gcc-4.4.2/bin/g++ --version
Copyright (C) 2009 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE.

w...@kubuntu-910:~/bug$ cat A.h
/*
 * A.h
 *
 *  Created on: 07.11.2009
 *  Author: Wolf Lammen
 */

/*
 * this compiles fine, if I
 * a) inline foo i.e use void foo(){} and remove foo() from A.cpp
 * b) avoid the keyword typedef and use struct B { void foo(); }; instead
 */

struct A {
typedef struct {
void foo();
} B;
};
w...@kubuntu-910:~/bug$ ~/bin/gcc-4.4.2/bin/g++ -O0 -g3 -Wall -c
-fmessage-length=0 -MMD -MP -MFA.d -MTA.d -oA.o A.cpp
w...@kubuntu-910:~/bug$ ../bin/gcc-4.4.2/bin/g++ -O0 -g3 -Wall -c
-fmessage-length=0 -MMD -MP -MFbug.d -MTbug.d -obug.o bug.cpp
w...@kubuntu-910:~/bug$ ../bin/gcc-4.4.2/bin/g++  -otest  ./A.o ./bug.o
./bug.o: In function `main':
/home/wolf/bug/bug.cpp:12: undefined reference to `A::B::foo()'
collect2: ld gab 1 als Ende-Status zurück

There is a simple work-around:
use
struct B{
void foo();
};
instead of the typedef struct {...} in file A.h, and everything compiles
and links fine (see below):

w...@kubuntu-910:~/bug$ ../bin/gcc-4.4.2/bin/g++ --version
g++ (GCC) 4.4.2
Copyright (C) 2009 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE.

w...@kubuntu-910:~/bug$ ~/bin/gcc-4.4.2/bin/g++ -O0 -g3 -Wall -c
-fmessage-length=0 -MMD -MP -MFA.d -MTA.d -oA.o A.cpp
w...@kubuntu-910:~/bug$ ../bin/gcc-4.4.2/bin/g++ -O0 -g3 -Wall -c
-fmessage-length=0 -MMD -MP -MFbug.d -MTbug.d -obug.o bug.cpp
w...@kubuntu-910:~/bug$ ../bin/gcc-4.4.2/bin/g++  -otest  ./A.o ./bug.o
w...@kubuntu-910:~/bug$ cat A.h
/*
 * A.h
 *
 *  Created on: 07.11.2009
 *  Author: Wolf Lammen
 */

/*
 * this compiles fine, if I
 * a) inline foo i.e use void foo(){} and remove foo() from A.cpp
 * b) avoid the keyword typedef and use struct B { void foo(); }; instead
 */

struct A {
struct B{
void foo();
};
};

Although there is a simple work-around (with slightly different semantics), the
example is AFAIK correct C++ code, that shouldn't rise any problems.

cheers

Wolf Lammen


-- 
   Summary: linker error with typedef struct
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ookami1 at gmx dot de
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42011

[Bug testsuite/42001] LTO tests fail with non multilib targets (but still not --disable-multilib )



--- Comment #10 from rguenth at gcc dot gnu dot org  2009-11-11 20:37 
---
Fixed?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42001

[Bug tree-optimization/41879] [4.5 Regression] 172.mgrid regression, vectorizer prevents predictive commoning



--- Comment #4 from rguenth at gcc dot gnu dot org  2009-11-11 20:38 ---
I didn't check yet.  We'll work on a simple cost-model integration of
predcom.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41879

[Bug fortran/41978] ICE in gfc_conv_expr_descriptor for array PPC assignment



--- Comment #1 from janus at gcc dot gnu dot org  2009-11-11 20:38 ---
Replacing the PPC assignment by a plain pointer component assignment

  IMPLICIT NONE
  TYPE t
integer, pointer :: p
  END TYPE t
  integer :: i
  TYPE(t) :: arr(2)
  arr%p = i
END

is being rejected with:

  arr%p = i
  1
Error: Component to the right of a part reference with nonzero rank must not
have the POINTER attribute at (1)

This is C614 in the F03 standard:

C614 (R612) There shall not be more than one part-ref with nonzero rank. A
part-name to the right of a part-ref with nonzero rank shall not have the
ALLOCATABLE or POINTER attribute.

I'm not 100% sure, but I think this also applies to PPCs.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41978

[Bug fortran/41978] [F03] ICE in gfc_conv_expr_descriptor for array PPC assignment

2009-11-11 Thread mikulas at artax dot karlin dot mff dot cuni dot cz



--- Comment #2 from janus at gcc dot gnu dot org  2009-11-11 21:02 ---
(In reply to comment #1)
 I'm not 100% sure, but I think this also applies to PPCs.

If this is correct, then the fix for this PR is as simple as

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 153965)
+++ gcc/fortran/resolve.c   (working copy)
@@ -4272,7 +4272,8 @@ resolve_ref (gfc_expr *expr)
case REF_COMPONENT:
  if (current_part_dimension || seen_part_dimension)
{
- if (ref-u.c.component-attr.pointer)
+ if (ref-u.c.component-attr.pointer
+ || ref-u.c.component-attr.proc_pointer)
{
  gfc_error (Component to the right of a part reference 
 with nonzero rank must not have the POINTER 

Daniel, what do you think?


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-11-11 21:02:50
   date||
Summary|ICE in  |[F03] ICE in
   |gfc_conv_expr_descriptor for|gfc_conv_expr_descriptor for
   |array PPC assignment|array PPC assignment


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41978

[Bug fortran/41978] [F03] ICE in gfc_conv_expr_descriptor for array PPC assignment

2009-11-11 Thread domob at gcc dot gnu dot org



--- Comment #3 from domob at gcc dot gnu dot org  2009-11-11 21:08 ---
I've not checked the standard about this, but seems fine to me.  I also give
you an ok for that patch (maybe with a test-case) if you want to submit/commit.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41978

[Bug middle-end/41992] ICE on invalid dereferencing of void *



--- Comment #3 from mikulas at artax dot karlin dot mff dot cuni dot cz  
2009-11-11 21:06 ---
You can dereference void * in asm arguments --- i.e.
void *p; ... asm volatile (prefetch %0::m(*p));

gcc warns in this case about the dereference and maybe it shouldn't (but it's
trivial to supress the warning with a cast to char *).

If you change m constraint to mr, you get an ICE.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41992

[Bug target/41993] [sh] ICE in create_pre_exit, at mode-switching.c:399

2009-11-11 Thread kkojima at gcc dot gnu dot org



--- Comment #1 from kkojima at gcc dot gnu dot org  2009-11-11 21:59 ---
All 4.x sh compilers fail with similar way.  Looks only when unoptimized.
Does the patch below work for you?

--- ORIG/trunk/gcc/mode-switching.c 2009-02-21 09:26:24.0 +0900
+++ trunk/gcc/mode-switching.c  2009-11-11 11:03:04.0 +0900
@@ -325,7 +325,14 @@ create_pre_exit (int n_entities, int *en
else
  break;
if (copy_start = FIRST_PSEUDO_REGISTER)
- break;
+ {
+   if (!optimize)
+ {
+   last_insn = return_copy;
+   continue;
+ }
+   break;
+ }
copy_num
  = hard_regno_nregs[copy_start][GET_MODE (copy_reg)];



BTW, I guess that __builtin_apply/__builtin_return may be a bit obsolete.
If my memory is correct, there was an argument on the list for dropping
them from the compiler.


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.0.4 4.1.3 4.2.4 4.3.4
   ||4.4.2 4.5.0
  Known to work||3.4.6
   Priority|P3  |P4
   Last reconfirmed|-00-00 00:00:00 |2009-11-11 21:59:45
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41993

[Bug c/42012] New: server not respond

2009-11-11 Thread aleppos at hotmail dot com

i build glibc 

../glibc/configure --prefix=/usr --enable-shared --disable-profile --enable-
add-ons --with-tls --with-__thread --enable-kernel=2.6.18 --
libexecdir=/usr/lib/glibc --build=x86_64-redhat-linux
make



gcc (GCC) 4.5.0 20091003 (experimental)


it's work but stop in this lines

-

gcc ../sysdeps/ieee754/dbl-64/dosincos.c -c -std=gnu99 -fgnu89-inline -O2 -
Wall -Winline -Wwrite-strings -fmerge-all-constants -fno-unwind-tables -g -
Wstrict-prototypes -Wno-uninitialized -D__NO_MATH_INLINES -
D__LIBC_INTERNAL_MATH_INLINES -I../include -
I/root/aleppos/libraries/glibc_build/math -
I/root/aleppos/libraries/glibc_build -I../sysdeps/x86_64/elf -
I../nptl/sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/x86_64 -
I../sysdeps/unix/sysv/linux/wordsize-64 -I../nptl/sysdeps/unix/sysv/linux -
I../nptl/sysdeps/pthread -I../sysdeps/pthread -
I../ports/sysdeps/unix/sysv/linux -I../sysdeps/unix/sysv/linux -
I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -
I../sysdeps/unix/inet -I../nptl/sysdeps/unix/sysv -
I../ports/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 -
I../nptl/sysdeps/unix -I../ports/sysdeps/unix -I../sysdeps/unix -
I../sysdeps/posix -I../sysdeps/x86_64/fpu -I../nptl/sysdeps/x86_64 -
I../sysdeps/x86_64 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754/ldbl-96 -
I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -
I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I../ports  -I.. -
I../libio -I.  -D_LIBC_REENTRANT -include ../include/libc-symbols.h   -
DNOT_IN_libc=1 -DIS_IN_libm=1-
o /root/aleppos/libraries/glibc_build/math/dosincos.o -MD -MP -
MF /root/aleppos/libraries/glibc_build/math/dosincos.o.dt -
MT /root/aleppos/libraries/glibc_build/math/dosincos.o



--
http://sourceware.org/bugzilla/show_bug.cgi?id=10941
--
If you are using experimental gcc, it can be gcc bug. But you didn't even
report
the actual error message...


-- 
   Summary: server not respond
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aleppos at hotmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42012

[Bug middle-end/41729] Undefined reference with -fPIC -fwhole-program -flto



--- Comment #1 from hubicka at gcc dot gnu dot org  2009-11-11 22:15 ---
This seems to be some issue with EH producing type infos too early.
LDFCM0 appears there is action record:
.LLSDACSE1:
.byte   0x1 # Action record table
.byte   0x0
.align 4
.long   .LDFCM0-.

and later here:
.type   .LDFCM0.2083, @object
.size   .LDFCM0.2083, 8
.LDFCM0.2083:
.quad   _ZTIP10cException
.hidden DW.ref.__gxx_personality_v0
.weak   DW.ref.__gxx_personality_v0
.section   
.data.DW.ref.__gxx_personality_v0,awG,@progbits,DW.ref.__gxx_personality_v0,comdat
.align 8
.type   DW.ref.__gxx_personality_v0, @object
.size   DW.ref.__gxx_personality_v0, 8

it is however gets this


-- 

hubicka at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hubicka at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-11-11 22:15:17
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41729

[Bug tree-optimization/41735] [4.5 Regression] inlined comdat function sometimes is emitted



--- Comment #3 from hubicka at gcc dot gnu dot org  2009-11-11 22:23 ---
Testing patch.


-- 

hubicka at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hubicka at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-10-24 11:59:05 |2009-11-11 22:23:40
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41735

[Bug fortran/41978] [F03] ICE in gfc_conv_expr_descriptor for array PPC assignment



--- Comment #4 from janus at gcc dot gnu dot org  2009-11-11 22:37 ---
Subject: Bug 41978

Author: janus
Date: Wed Nov 11 22:37:31 2009
New Revision: 154107

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154107
Log:
2009-11-11  Janus Weil  ja...@gcc.gnu.org

PR fortran/41978
* resolve.c (resolve_ref): Take care of procedure pointer component
references.


2009-11-11  Janus Weil  ja...@gcc.gnu.org

PR fortran/41978
* gfortran.dg/proc_ptr_comp_22.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_22.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41978

[Bug fortran/41978] [F03] ICE in gfc_conv_expr_descriptor for array PPC assignment

2009-11-11 Thread mikulas at artax dot karlin dot mff dot cuni dot cz



--- Comment #5 from janus at gcc dot gnu dot org  2009-11-11 22:38 ---
Fixed with r154107. Closing.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41978

[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*

2009-11-11 Thread andreast at gcc dot gnu dot org



--- Comment #3 from andreast at gcc dot gnu dot org  2009-11-11 22:40 
---
Does this help:

[deuterium:head/gcc/libjava] andreast% svn diff Makefile.am Makefile.in 
Index: Makefile.am
===
--- Makefile.am (revision 154097)
+++ Makefile.am (working copy)
@@ -1085,7 +1085,7 @@

 if NATIVE

-ecjx_LINK = $(GCJLINK) $(ecjx_LDFLAGS)
+ecjx_LINK = $(GCJLINK) $(ecjx_LDFLAGS) $(extra_gij_ldflags)

 if ENABLE_SHARED
 ## Use ecj.jar at runtime.
Index: Makefile.in
===
--- Makefile.in (revision 154097)
+++ Makefile.in (working copy)
@@ -8511,7 +8511,7 @@
--main=org.eclipse.jdt.internal.compiler.batch.GCCMain

 @native_fa...@ecjx_link = $(GCJ_FOR_ECJX_LINK) $(ecjx_LDFLAGS)
-...@native_true@ecjx_LINK = $(GCJLINK) $(ecjx_LDFLAGS)
+...@native_true@ecjx_LINK = $(GCJLINK) $(ecjx_LDFLAGS) $(extra_gij_ldflags)
 @ENABLE_SHARED_FALSE@@native_t...@ecjx_ldflags = $(ECJX_BASE_FLAGS)
$(ECJ_BUILD_JAR) -fbootclasspath=$(BOOTCLASSPATH)
 @ENABLE_SHARED_TRUE@@native_t...@ecjx_ldflags = $(ECJX_BASE_FLAGS)
-Djava.class.path=$(ECJ_JAR)
 @native_fa...@ecjx_ldflags = $(ECJX_BASE_FLAGS) $(ECJ_BUILD_JAR)


-- 

andreast at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |andreast at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-11-11 22:40:42
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991

[Bug target/40983] The scheduler incorrectly swaps MMX and floating point instructions



--- Comment #6 from mikulas at artax dot karlin dot mff dot cuni dot cz  
2009-11-11 23:06 ---
I think you can commit it to gcc. I don't see a reason why it shouldn't be
committed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40983

[Bug c/42012] server not respond

2009-11-11 Thread paolo dot carlini at oracle dot com



--- Comment #1 from paolo dot carlini at oracle dot com  2009-11-11 23:27 
---
Indeed, please provide the error message, at least, plus all the required bug
information per: http://gcc.gnu.org/bugs/


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42012

[Bug c/42012] server not respond

2009-11-11 Thread joseph at codesourcery dot com



--- Comment #2 from joseph at codesourcery dot com  2009-11-11 23:35 ---
Subject: Re:  server not respond

This is probably a duplicate of bug 41343 (it's reported against a trunk 
version more than a month old).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42012

[Bug c/42012] server not respond

2009-11-11 Thread paolo dot carlini at oracle dot com



--- Comment #3 from paolo dot carlini at oracle dot com  2009-11-11 23:40 
---
Thanks Joseph. Thus, let's close this one as duplicate, please re-open if the
problem can be reproduced also with current mainline. Thanks.

*** This bug has been marked as a duplicate of 41343 ***


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42012

[Bug debug/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

2009-11-11 Thread paolo dot carlini at oracle dot com



--- Comment #22 from paolo dot carlini at oracle dot com  2009-11-11 23:40 
---
*** Bug 42012 has been marked as a duplicate of this bug. ***


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||aleppos at hotmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343

[Bug tree-optimization/41735] [4.5 Regression] inlined comdat function sometimes is emitted

--- Comment #4 from hubicka at gcc dot gnu dot org  2009-11-11 23:45 ---
Subject: Bug 41735

Author: hubicka
Date: Wed Nov 11 23:45:09 2009
New Revision: 154108

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154108
Log:

PR middle-end/41729
* ipa.c (function_and_variable_visibility): Do not privatize COMDAT
and WEAK variables at -fwhole-program.

PR middle-end/41735
* ipa.c (whole_program_function_and_variable_visility): COMDAT
functions/variables are not needed even if they are externally visible.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa.c

-- 

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41735

[Bug middle-end/41729] Undefined reference with -fPIC -fwhole-program -flto

2009-11-11 Thread howarth at nitro dot med dot uc dot edu

--- Comment #2 from hubicka at gcc dot gnu dot org  2009-11-11 23:45 ---
Subject: Bug 41729

Author: hubicka
Date: Wed Nov 11 23:45:09 2009
New Revision: 154108

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154108
Log:

PR middle-end/41729
* ipa.c (function_and_variable_visibility): Do not privatize COMDAT
and WEAK variables at -fwhole-program.

PR middle-end/41735
* ipa.c (whole_program_function_and_variable_visility): COMDAT
functions/variables are not needed even if they are externally visible.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa.c

-- 

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41729

[Bug middle-end/41440] SEG FAULT in CSE.C caused by bad RTL expansion

2009-11-11 Thread hutchinsonandy at gcc dot gnu dot org

--- Comment #10 from hutchinsonandy at gcc dot gnu dot org  2009-11-12 
02:36 ---
Subject: Bug 41440

Author: hutchinsonandy
Date: Thu Nov 12 02:35:49 2009
New Revision: 154112

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154112
Log:
PR middle-end/41440
* cfgexpand.c (expand_gimple_basic_block): Append NOP to a fallthru,
single successor block, ending with jump created by RTL expander.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c

-- 

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41440

[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*



--- Comment #4 from howarth at nitro dot med dot uc dot edu  2009-11-12 
02:43 ---
Unfortunately, the proposed patch doesn't solve the crashes in gcj on intel
darwin. I would note that if I use javac to convert testme.java into
testme.class that...

gcj --main=testme -O testme.class

compiles fine on x86_64-apple-darwin10. This is likely why the problem went
unnoticed for so long as the libjava testsuite appears to test gcj via the
class files in the associated jar files rather than with the java files
themselves (if ejc1 is present).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991

[Bug driver/42007] Make -mfloat-gprs=double the default when compiling for powerpc-linux-gnuspe target

2009-11-11 Thread oakad at yahoo dot com



--- Comment #2 from oakad at yahoo dot com  2009-11-12 02:51 ---
I understand that changing a triplet behavior is not a good idea.

However, it seems quite unfortunate, that important, performance affecting
feature depends on obscure gcc configuration flag in situation where most
existing and all future chips of this type provide the necessary functionality.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42007

[Bug driver/42007] Make -mfloat-gprs=double the default when compiling for powerpc-linux-gnuspe target

2009-11-11 Thread joseph at codesourcery dot com



--- Comment #3 from joseph at codesourcery dot com  2009-11-12 03:01 ---
Subject: Re:  Make -mfloat-gprs=double the default when
 compiling for powerpc-linux-gnuspe target

Note that there are more than just e500 processors with the SPE 
functionality; for example, at least some e200 processors also support SPE 
with single-precision floating point only.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42007

[Bug c++/42013] New: cv-qualification of conditional expression type depending on the value of its first expression?!?

2009-11-11 Thread paolo dot carlini at oracle dot com

I'm seeing something strange while implementing C++0x declval. In a nutshell,
since I'm not reading anything in 5.16 (of C++03) saying that the type of a
conditional expression depends on the value of its first expression, I'm
surprised that this is the case with GCC, as far as cv-qualification is
concerned.

By the way, if actually this is conforming behavior, then the current C++0x
specifications for the two arguments common_type become really weird (see
20.6.7/3 in N2960): the cv-qualification of the common_type ends up depending
on the order of the types. Cannot be right, IMHO.

For example, the below doesn't compile:

templatetypename _Tp
  struct __declval_protector
  {
 static _Tp __delegate();
  };

templatetypename _Tp
  _Tp
  declval()
  {
return __declval_protector_Tp::__delegate();
  }

templatetypename _Tp, typename _Up
  struct common_type
  {
typedef __decltype(true  ? declval_Tp() : declval_Up()) typet;
typedef __decltype(false ? declval_Tp() : declval_Up()) typef;
  };

templatetypename, typename struct is_same;

templatetypename _Tp struct is_same_Tp, _Tp { typedef _Tp type; };

void f()
{
  typedef common_typeint, const int::typet typet;
  typedef common_typeint, const int::typef typef;

  typedef is_sametypet, typef::type type;
}


-- 
   Summary: cv-qualification of conditional expression type
depending on the value of its first expression?!?
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paolo dot carlini at oracle dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42013

[Bug c++/42013] cv-qualification of conditional expression type depending on the value of its first expression?!?

2009-11-11 Thread paolo dot carlini at oracle dot com



--- Comment #1 from paolo dot carlini at oracle dot com  2009-11-12 04:09 
---
Actually, the observation about C++0x is largely incorrect, because the actual
specifications in DR 1255 are different, use std::add_rvalue_reference.

However, my main puzzlement stands.

Also, as regards the C++0x common_type (per DR 1255), I'm seeing the problem
with cv-qualified void, eg, replace in the snippet int - void and const int -
const void, because in that case std::add_rvalue_reference does nothing:

#include type_traits

templatetypename _Tp
  struct __declval_protector
  {
 static typename std::add_rvalue_reference_Tp::type __delegate();
  };

templatetypename _Tp
  typename std::add_rvalue_reference_Tp::type
  declval()
  {
return __declval_protector_Tp::__delegate();
  }

templatetypename _Tp, typename _Up
  struct common_type
  {
typedef __decltype(true  ? declval_Tp() : declval_Up()) typet;
typedef __decltype(false ? declval_Tp() : declval_Up()) typef;
  };

templatetypename, typename struct is_same;

templatetypename _Tp struct is_same_Tp, _Tp { typedef _Tp type; };

void f()
{
  typedef common_typevoid, const void::typet typet;
  typedef common_typevoid, const void::typef typef;

  typedef is_sametypet, typef::type type;
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42013

[Bug c++/39131] decimal float point: ICE on typeid( 0.dd )

--- Comment #3 from jason at gcc dot gnu dot org  2009-11-12 04:44 ---
Subject: Bug 39131

Author: jason
Date: Thu Nov 12 04:44:24 2009
New Revision: 154113

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154113
Log:
PR c++/39131
* rtti.c (emit_support_tinfos): Add DFP types.
* config/abi/pre/gnu.ver: Add DFP types.
* testsuite/util/testsuite_abi.cc (check_version): Add CXXABI_1.3.4.

Added:
trunk/gcc/testsuite/g++.dg/dfp/typeid1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/rtti.c
trunk/gcc/testsuite/ChangeLog
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/abi/pre/gnu.ver
trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc

-- 

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39131

[Bug other/42014] Inconsistant column number display for In file incuded from



--- Comment #1 from pinskia at gcc dot gnu dot org  2009-11-12 04:47 ---
This affects any inflexible error parsing program.

Considering flag_show_column controls the display of column info, it does not
say always display it, only when aviable.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |other


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42014

[Bug c++/42013] cv-qualification of conditional expression type depending on the value of its first expression?!?



--- Comment #2 from pinskia at gcc dot gnu dot org  2009-11-12 04:16 ---
Might be related to the old fixed bug 36628.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42013

[Bug c++/42014] New: Inconsistant column number display for In file incuded from

2009-11-11 Thread indy2718 at gmail dot com

In file included from a.h:3:0,
 from c.cpp:2:

Notice there's a 0 on the first line, and no column number on the second line.
This affects any inflexible error parsing program.
In gcc/diagnostic.c line 245 there's a check for flag_show_column for the first
error line but no check for the rest.
{
  map = INCLUDED_FROM (line_table, map);
  if (flag_show_column)
pp_verbatim (context-printer,
 In file included from %s:%d:%d,
 map-to_file,
 LAST_SOURCE_LINE (map), LAST_SOURCE_COLUMN (map));
  else
pp_verbatim (context-printer,
 In file included from %s:%d,
 map-to_file, LAST_SOURCE_LINE (map));
  while (! MAIN_FILE_P (map))
{
  map = INCLUDED_FROM (line_table, map);
  pp_verbatim (context-printer,
   ,\n from %s:%d,
   map-to_file, LAST_SOURCE_LINE (map));
}
  pp_verbatim (context-printer, :);
  pp_newline (context-printer);
}


-- 
   Summary: Inconsistant column number display for In file incuded
from
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: indy2718 at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42014

[Bug c++/39131] decimal float point: ICE on typeid( 0.dd )



--- Comment #4 from jason at gcc dot gnu dot org  2009-11-12 04:49 ---
The ICE was fixed a while back; the patch I just checked in makes uses of
typeid(0.dd) link.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39131

[Bug c++/3187] gcc lays down two copies of constructors



-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|jason at gcc dot gnu dot org|unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3187

[Bug c++/2316] g++ fails to overload on language linkage



--- Comment #19 from jason at gcc dot gnu dot org  2009-11-12 04:54 ---
I was thinking that the ABI didn't distinguish between C and C++ function
types, but I was wrong; it does specify a different mangling for extern C
functions.  The problem is that currently G++ only tracks language linkage for
declarations, not types.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

[Bug c++/4926] C++ ABI needs clarification on mangling of complex expressions



--- Comment #14 from jason at gcc dot gnu dot org  2009-11-12 04:57 ---
Actually, we have PR 38712 specifically about the template-id case, so let's go
ahead and close this PR.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4926

[Bug c++/38712] can't mangle template-id gN(t)



--- Comment #4 from jason at gcc dot gnu dot org  2009-11-12 04:59 ---
This issue isn't limited to C++0x mode:

struct A
{
  typedef int Type;
};

template class T
typename T::Type f ();

template class T
char (* g())[sizeof(fT())];

int main()
{
  gA();
}


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[c++0x] can't mangle|can't mangle template-id
   |template-id gN(t) |gN(t)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38712

[Bug other/42014] Inconsistant column number display for In file incuded from

2009-11-11 Thread indy2718 at gmail dot com



--- Comment #2 from indy2718 at gmail dot com  2009-11-12 05:14 ---
(In reply to comment #1)
 This affects any inflexible error parsing program.
 
 Considering flag_show_column controls the display of column info, it does not
 say always display it, only when aviable.
 
Should be consistent though.  Possibly remove the flag_show_column block or add
another pp_verbatim LAST_SOURCE_COLUMN in the while loop.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42014

[Bug c++/42013] cv-qualification of conditional expression type depending on the value of its first expression?!?



--- Comment #3 from jason at gcc dot gnu dot org  2009-11-12 05:47 ---
More hoops to jump through to prevent the magic decltype handling of calls
exposed by constant folding...


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-11-12 05:47:08
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42013

[Bug gcov-profile/42015] New: gcov reports incorrect branches executed

2009-11-11 Thread frodak17 at gmail dot com

While trying to rerun the gcov example supplied in man gcov it was noticed
that the branch values reported are incorrect.  The contents in tmp.c.gcov
appears to be correct.

gcc (Ubuntu 4.4.1-4ubuntu8) 4.4.1

#include stdio.h

int main (void)
{
  int i, total;

  total = 0;

  for (i = 0; i  10; i++)
total += i;

  if (total != 45)
printf (Failure\n);
  else
printf (Success\n);
  return 0;
}

fro...@frodak-laptop:~/gcov$ gcov -b tmp.c
File 'tmp.c'
Lines executed:87.50% of 8
Branches executed:100.00% of 4
Taken at least once:75.00% of 4
Calls executed:50.00% of 2
tmp.c:creating 'tmp.c.gcov'

fro...@frodak-laptop:~/gcov$ cat tmp.c.gcov
-:0:Source:tmp.c
-:0:Graph:tmp.gcno
-:0:Data:tmp.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include stdio.h
-:2:
function main called 1 returned 100% blocks executed 86%
1:3:int main (void)
-:4:{
-:5:  int i, total;
-:6:
1:7:  total = 0;
-:8:
   11:9:  for (i = 0; i  10; i++)
branch  0 taken 91%
branch  1 taken 9% (fallthrough)
   10:   10:total += i;
-:   11:
1:   12:  if (total != 45)
branch  0 taken 0% (fallthrough)
branch  1 taken 100%
#:   13:printf (Failure\n);
call0 never executed
-:   14:  else
1:   15:printf (Success\n);
call0 returned 100%
1:   16:  return 0;
-:   17:}
-:   18:


-- 
   Summary: gcov reports incorrect branches executed
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: frodak17 at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42015

[Bug middle-end/41930] [4.5 regression] cc1 SEGV compiling maxval_r16.c

2009-11-11 Thread uros at gcc dot gnu dot org

--- Comment #9 from uros at gcc dot gnu dot org  2009-11-12 07:30 ---
Subject: Bug 41930

Author: uros
Date: Thu Nov 12 07:30:05 2009
New Revision: 154116

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154116
Log:
PR middle-end/41930
* simplify-rtx.c (simplify_replace_fn_rtx) case 'e': Skip
processing if XEXP (x, i) is NULL.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c

-- 

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41930

[Bug middle-end/41930] [4.5 regression] cc1 SEGV compiling maxval_r16.c