Re: adding ability to scan few local variables in GGC?

[Basile STARYNKEVITCH]

Richard Guenther wrote:

On Mon, Oct 13, 2008 at 7:23 AM, Basile STARYNKEVITCH
<[EMAIL PROTECTED]> wrote:

Hello All,

Andrew Pinski wrote:

On Sun, Oct 12, 2008 at 1:15 PM, Basile STARYNKEVITCH
<[EMAIL PROTECTED]> wrote:

Hello All,

I am sometimes wishing to be able to scan some few local variables in GCC
garbage collector, GGC.

The only time I can think of when you want to do that is when the pass
creates lots of garbage.  The only pass I can think of that might
cause that much garbage is the inliner but even then it would only be
make stuff dead rather than creating new data structures which are
dead.

Can you give a more concrete example of why you want this?

Yes, the MELT branch. There is some incomplete documentation on the wiki,
and in the MELT branch itself, file gcc/doc/melt.texi.

[...]

In addition, I also do think that a ggc_collect_with_local would be useful
to plugins.


It looks like the MELT scheme of garbage collection is simply incompatible
with the GCC one.  And I don't see a reason to complicate GCC GGC by
introducing a possibility to scan the stack (you would have to register all
stack objects as (temporary) roots, otherwise GGCs precise nature would
break).



I'm not sure to understand the meaning of "MELT GC being incompatible 
with GGC one". On the contrary, it is designed to be compatible, it is 
compatble in practice, and it works quite well.


The point is how should MELT handle unboxed GCC stuff (like gimple_seq 
gimple tree edge ...etc...) which is allocated inside MELT code.


If an ggc_collect_with_local scheme is not possible (but I repeat that I 
find it simpler, more efficient, and even perhaps more elegant), I have 
always the possibility of having static vectors for every such type of 
stuff (ie one vector of gimple, another of gimple_seq, another of 
tree-s, and so forth) and generate code which pushes value there.
Generating code which directly marks (in the GGC collector) stuff would 
be simpler [this means a solution like the ggc_collect_with_local I just 
suggested], but I can do without. By the way, the


So my perception is on the contrary that MELT GC is fully compatible 
with GGC (and this is expected, since MELT was *designed* for 
compatibility with GCC internals; in other words, compatibility with GGC 
is a major design goal of MELT.), so I feel a little surprised by your 
"imcompatible" wording, probably because I did not explain MELT well enough.


My only question was how to make MELT even more compatible for stuff 
allocated in MELT code (this does not yet happen in practice, but it 
could in the future, so it is not my topmost priority for now). So if a 
ggc_collect_with_local is not acceptable (ie patching a bit ggc.c) when 
GCC goes back in stage1 I could live without (using the static vector 
tricks I suggested above). But again, such a solution is simpler to me, 
and I believe it could help plugins.


> otherwise GGCs precise nature would break).

Strico sensu, GGC is not precise enough, precisely (sorry for the poor 
pun on words) because it does not handle at all any local pointers. So I 
won't describe GGC as a precise collector, only as a garbage collector 
precise for global data, and ignoring all local data. This makes a huge 
difference to everyone using GGC, and every GGC user has to be aware of 
this fact (which is documented).


Regards.

PS. English is not a native language for me, so excuse my approximate 
language.



--
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: adding ability to scan few local variables in GGC?

[Basile STARYNKEVITCH]

Basile STARYNKEVITCH wrote:


I'm not sure to understand the meaning of "MELT GC being incompatible 
with GGC one". On the contrary, it is designed to be compatible, it is 
compatble in practice, and it works quite well.




If an ggc_collect_with_local scheme is not possible (but I repeat that I 
find it simpler, more efficient, and even perhaps more elegant), I have 
always the possibility of having static vectors for every such type of 
stuff (ie one vector of gimple, another of gimple_seq, another of 
tree-s, and so forth) and generate code which pushes value there.
Generating code which directly marks (in the GGC collector) stuff would 
be simpler [this means a solution like the ggc_collect_with_local I just 
suggested], but I can do without. By the way, the



Sorry, I forgot a sentence here. I mean that

By the way, the current MELT handing of MELT values is to copy them 
(before calling ggc_collect) in a static vector, and the same scheme can 
be extended for other stuff. But a ggc_collect_with_local would be 
simpler (and more efficient, avoiding copying into vectors).



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: adding ability to scan few local variables in GGC?

[Richard Guenther]

On Mon, Oct 13, 2008 at 7:23 AM, Basile STARYNKEVITCH
<[EMAIL PROTECTED]> wrote:
> Hello All,
>
> Andrew Pinski wrote:
>>
>> On Sun, Oct 12, 2008 at 1:15 PM, Basile STARYNKEVITCH
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> Hello All,
>>>
>>> I am sometimes wishing to be able to scan some few local variables in GCC
>>> garbage collector, GGC.
>>
>> The only time I can think of when you want to do that is when the pass
>> creates lots of garbage.  The only pass I can think of that might
>> cause that much garbage is the inliner but even then it would only be
>> make stuff dead rather than creating new data structures which are
>> dead.
>>
>> Can you give a more concrete example of why you want this?
>
> Yes, the MELT branch. There is some incomplete documentation on the wiki,
> and in the MELT branch itself, file gcc/doc/melt.texi.
[...]
> In addition, I also do think that a ggc_collect_with_local would be useful
> to plugins.

It looks like the MELT scheme of garbage collection is simply incompatible
with the GCC one.  And I don't see a reason to complicate GCC GGC by
introducing a possibility to scan the stack (you would have to register all
stack objects as (temporary) roots, otherwise GGCs precise nature would
break).

Richard.

Re: opt-1.c/opt-2.c ICEs on i686-apple-darwin9

[Dominique Dhumieres]

Jack,

This is pr37106. It first appeared with -m64 and is now also with
-m32.

Dominique

RE: opt-1.c/opt-2.c ICEs on i686-apple-darwin9

[Jack Howarth]

  The problem build was at r141079 so perhaps that change could be 
at fault...

Author: hjl
Date: Sun Oct 12 21:44:33 2008
New Revision: 141079

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141079
Log:
2008-10-12  H.J. Lu  <[EMAIL PROTECTED]>

Backport from mainline:
2008-10-12  Richard Henderson  <[EMAIL PROTECTED]>

PR middle-end/37447
* Makefile.in (reload1.o): Depend on EMIT_RTL_H.
* alias.c (value_addr_p, stack_addr_p): Remove.
(nonoverlapping_memrefs_p): Remove IRA special case.
* emit-rtl.c (get_spill_slot_decl, set_mem_attrs_for_spill): New.
* emit-rtl.h (set_mem_attrs_for_spill): Declare.
* reload1.c (alter_reg): Use it.

Modified:
branches/ira-merge/gcc/ChangeLog.ira
branches/ira-merge/gcc/Makefile.in
branches/ira-merge/gcc/alias.c
branches/ira-merge/gcc/emit-rtl.c
branches/ira-merge/gcc/emit-rtl.h
branches/ira-merge/gcc/reload1.c

I can't test regressing that change out until tonight. Perhaps someone else
can confirm the opt-1.c/opt-2.c regressions on Darwin i686 and try reverting
r141079 out to see if that is the offender.
 Jack

Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Vincent Lefevre]

On 2008-10-07 21:42:30 +0300, Adrian Bunk wrote:
> But is there any "need to upgrade" to 2.3.2 since it would fix a bug
> gcc ran into?

FYI, GCC can be affected by some bugs in MPFR 2.3.0, amongst the bugs
listed on . I think that the
bugs in question are:

  * The mpfr_gamma function applied on a huge integer fails on 64-bit
machines. But I don't know what the failure was (Paul Zimmermann
fixed this bug, so that he should know more than me).
Note: any double-precision number >= 2^52 is an integer.

  * The mpfr_erfc function is very inefficient on large negative
numbers.

  * The mpfr_j0 function applied on a large negative number and the
mpfr_jn function applied on (even integer, large negative number)
return a result with a wrong sign.

  * The mpfr_asin function applied on ±0 does not set the sign of the
null result.

  * The mpfr_gamma function can return a result with a wrong sign
(negative instead of positive) in case of underflow with a
positive value, e.g. on -11.5 in the default exponent
range.

and perhaps bugs in mpfr_pow on particular values.

All these bugs were fixed in MPFR 2.3.1. AFAIK, MPFR 2.3.2 should
not make any difference for GCC. The fixed bugs are listed here:
. They mainly concern
underflow/overflow exceptions, which should not occur on
double-precision numbers. And according to my tests, it is very
unlikely that the first mpfr_exp bug can have an influence on
double-precision numbers.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: gcc moving memory reference across call

[Andrew Haley]

Andrew Pinski wrote:
> On Fri, Oct 10, 2008 at 11:14 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>> Richard Guenther wrote:
>>> On Fri, Oct 10, 2008 at 7:55 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:
 I have some broken code, compiled from Java source.

 It looks like:

D.843 = &java.text.Collator.class$$;
_Jv_InitClass (D.843);
D.845 = &_CD_java_text_Collator;

 is being turned into:

D.843 = &java.text.Collator.class$$;
D.845 = &_CD_java_text_Collator;
_Jv_InitClass (D.843);
>>> This is always a valid transformation.
>>>
 i.e. the memory reference is moved to before the call to _Jv_InitClass.
>>> There is no memory reference in the above case, it seems just the address
>>> of _CD_java_text_Collator is taken.
>>>
>>> Or maybe I'm missing sth?
>> In the RTL code it moves the mem ref, not just the address:
>>
>> (call (mem:QI (symbol_ref:DI ("_Jv_InitClass") [flags 0x41]
>>
>> (set (reg/f:DI 95 [ #ref#8#1 ])
>>(mem/s/u/f/j:DI (const:DI (plus:DI (symbol_ref:DI 
>> ("_CD_java_text_Collator")
>>(const_int 16 [0x10])))
>>
>> is turned to:
>>
>> (set (reg/f:DI 162 [ #ref#8#1 ])
>>(mem/s/u/f/j:DI (const:DI (plus:DI (symbol_ref:DI 
>> ("_CD_java_text_Collator")
>>(const_int 16 [0x10])))
>>
>> ...
>>
>> (call (mem:QI (symbol_ref:DI ("_Jv_InitClass")
> 
> Well the mem has a /u on it so it is being marked as MEM_READONLY_P so
> it is valid optimization.  Why it is being marked with MEM_READONLY_P,
> I don't know.

I've found the code that's incorrectly marking the decl as TREE_READONLY.
It's here:

  /* If the variable is never written, we can set the TREE_READONLY
 flag.  Additionally if it has a DECL_INITIAL that is made up of
 constants we can treat the entire global as a constant.  */

  bitmap_and_compl (module_statics_readonly, all_module_statics,
module_statics_written);
  EXECUTE_IF_SET_IN_BITMAP (module_statics_readonly, 0, index, bi)
{
  tree var = get_static_decl (index);

  /* Ignore variables in named sections - changing TREE_READONLY
 changes the section flags, potentially causing conflicts with
 other variables in the same named section.  */
  if (DECL_SECTION_NAME (var) == NULL_TREE)
{
  TREE_READONLY (var) = 1;

The decl (called _CD_ppp) is not written by the code we generate, that's true.
However, there is a global struct class$, which contains a field which points to
_CD_ppp:

ppp::class$:
.quad   vtable for java::lang::Class+16
.quad   1074145824
.quad   _Utf6
.value  33
.zero   6
.quad   java::lang::Object::class$
.long   2
.zero   4
.quad   _CT_ppp
.quad   _CD_ppp
...

.type   _CD_ppp, @object
.size   _CD_ppp, 16
_CD_ppp:
.quad   0
.quad   _Utf5

I would expect that this would mean that _CD_ppp has its address taken, and
therefore should not be marked as TREE_READONLY.

Andrew.

Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Markus Milleder]

Vincent Lefevre schrieb am 13.10.2008 16:16:38:

> On 2008-10-07 21:42:30 +0300, Adrian Bunk wrote:
> > But is there any "need to upgrade" to 2.3.2 since it would fix a bug
> > gcc ran into?
>
> FYI, GCC can be affected by some bugs in MPFR 2.3.0, amongst the bugs



> All these bugs were fixed in MPFR 2.3.1. AFAIK, MPFR 2.3.2 should
> not make any difference for GCC. The fixed bugs are listed here:



This seems to call for MPFR 2.3.1 as a minimum version for GCC 4.4

However, let me ask the reverse question:

Is there any reason not to demand 2.3.2 for GCC 4.4 ? Or even the newest MPFR 
version published before creating the GCC 4.4 release branch (which could be 
2.3.3) ?

  Markus Milleder

Re: gcc moving memory reference across call

[Richard Guenther]

On Mon, Oct 13, 2008 at 4:38 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:
> Andrew Pinski wrote:
>> On Fri, Oct 10, 2008 at 11:14 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>>> Richard Guenther wrote:
 On Fri, Oct 10, 2008 at 7:55 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:
> I have some broken code, compiled from Java source.
>
> It looks like:
>
>D.843 = &java.text.Collator.class$$;
>_Jv_InitClass (D.843);
>D.845 = &_CD_java_text_Collator;
>
> is being turned into:
>
>D.843 = &java.text.Collator.class$$;
>D.845 = &_CD_java_text_Collator;
>_Jv_InitClass (D.843);
 This is always a valid transformation.

> i.e. the memory reference is moved to before the call to _Jv_InitClass.
 There is no memory reference in the above case, it seems just the address
 of _CD_java_text_Collator is taken.

 Or maybe I'm missing sth?
>>> In the RTL code it moves the mem ref, not just the address:
>>>
>>> (call (mem:QI (symbol_ref:DI ("_Jv_InitClass") [flags 0x41]
>>>
>>> (set (reg/f:DI 95 [ #ref#8#1 ])
>>>(mem/s/u/f/j:DI (const:DI (plus:DI (symbol_ref:DI 
>>> ("_CD_java_text_Collator")
>>>(const_int 16 [0x10])))
>>>
>>> is turned to:
>>>
>>> (set (reg/f:DI 162 [ #ref#8#1 ])
>>>(mem/s/u/f/j:DI (const:DI (plus:DI (symbol_ref:DI 
>>> ("_CD_java_text_Collator")
>>>(const_int 16 [0x10])))
>>>
>>> ...
>>>
>>> (call (mem:QI (symbol_ref:DI ("_Jv_InitClass")
>>
>> Well the mem has a /u on it so it is being marked as MEM_READONLY_P so
>> it is valid optimization.  Why it is being marked with MEM_READONLY_P,
>> I don't know.
>
> I've found the code that's incorrectly marking the decl as TREE_READONLY.
> It's here:
>
>  /* If the variable is never written, we can set the TREE_READONLY
> flag.  Additionally if it has a DECL_INITIAL that is made up of
> constants we can treat the entire global as a constant.  */
>
>  bitmap_and_compl (module_statics_readonly, all_module_statics,
>module_statics_written);
>  EXECUTE_IF_SET_IN_BITMAP (module_statics_readonly, 0, index, bi)
>{
>  tree var = get_static_decl (index);
>
>  /* Ignore variables in named sections - changing TREE_READONLY
> changes the section flags, potentially causing conflicts with
> other variables in the same named section.  */
>  if (DECL_SECTION_NAME (var) == NULL_TREE)
>{
>  TREE_READONLY (var) = 1;
>
> The decl (called _CD_ppp) is not written by the code we generate, that's true.
> However, there is a global struct class$, which contains a field which points 
> to
> _CD_ppp:
>
> ppp::class$:
>.quad   vtable for java::lang::Class+16
>.quad   1074145824
>.quad   _Utf6
>.value  33
>.zero   6
>.quad   java::lang::Object::class$
>.long   2
>.zero   4
>.quad   _CT_ppp
>.quad   _CD_ppp
>...
>
>.type   _CD_ppp, @object
>.size   _CD_ppp, 16
> _CD_ppp:
>.quad   0
>.quad   _Utf5
>
> I would expect that this would mean that _CD_ppp has its address taken, and
> therefore should not be marked as TREE_READONLY.

Right.  So I guess ipa-reference doesn't properly treat all TU local globals
as written-to if the write occurs through a pointer we don't know where it
points to.

Honza - you recently looked into ipa-reference -- does it try to do the
right thing with pointer accesses here?  I guess it may miss taking addresses
from inside initializers.  Andrew - is this address-taking from ppp::class$
visible from a DECL_INITIAL or is this hidden behind some magic?

Thanks,
Richard.

Re: install path in libgcc Makefile.in

[Eus]

Hi Ho!

On Saturday, October 11, 2008, "Zhang Le" <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> Another problem when cross building the native mips compiler.
> I.e. build=x86, host=target=mipsel
> I have done some search, but haven't found any related discussion.

Please have a look at:
http://gcc.gnu.org/ml/gcc/2008-09/msg00376.html

Also, I think Jay has done a research to solve that particular problem:
http://gcc.gnu.org/ml/gcc-help/2008-08/msg00315.html
http://gcc.gnu.org/ml/gcc/2008-09/msg9.html

> The install path of libgcc contains gcc version.
> Currently in libgcc/Makefile.in, gcc version is get like this:
>   version := $(shell $(CC) -dumpversion)
> 
> This will lead to a problem that I have only experienced when cross building
> the native compiler. The problem is that crtbegin.o/crtend.o/etc. will be
> installed into old gcc's path, overwrite existing ones. New gcc will have no
> crtbegin.o...
> 
> There is no problem when natively building native compiler.
> 
> I don't understand why the problem only happens when cross building native
> compiler. I know I need to study how gcc is built. Just want make you aware of
> this problem. And I have a suggestion to this problem.
> 
> I have observed that in other components, the version is get like this:
> version := $(shell cat $(srcdir)/../gcc/BASE-VER)
> 
> So what about we do the same in libgcc/Makefile.in?
> Because this can ensure that the install dir will be new gcc's path.
> 
> If this is ok, I will post a little patch.
> 
> Zhang Le

Best regards,
Eus


  

Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Adrian Bunk]

On Mon, Oct 13, 2008 at 04:42:08PM +0200, Markus Milleder wrote:
> Vincent Lefevre schrieb am 13.10.2008 16:16:38:
> 
> > On 2008-10-07 21:42:30 +0300, Adrian Bunk wrote:
> > > But is there any "need to upgrade" to 2.3.2 since it would fix a bug
> > > gcc ran into?
> >
> > FYI, GCC can be affected by some bugs in MPFR 2.3.0, amongst the bugs
> 
> 
> 
> > All these bugs were fixed in MPFR 2.3.1. AFAIK, MPFR 2.3.2 should
> > not make any difference for GCC. The fixed bugs are listed here:
> 
> 
> 
> This seems to call for MPFR 2.3.1 as a minimum version for GCC 4.4
> 
> However, let me ask the reverse question:
> 
> Is there any reason not to demand 2.3.2 for GCC 4.4 ? Or even the newest MPFR 
> version published before creating the GCC 4.4 release branch (which could be 
> 2.3.3) ?

Upgrading can cause the user some unneeded work.

E.g. the next stable release of Debian will likely ship with 2.3.1 .
So in this specific case fulfilling a 2.3.1 requirement would be easy, 
while a 2.3.2 requirement would make it much harder to build gcc 4.4 .

And upgrading from 2.3.1 to let's say 3.0.0 might be a bad choice if
the new version contains regressions.

>   Markus Milleder

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: gcc moving memory reference across call

[Andrew Haley]

Richard Guenther wrote:
> On Mon, Oct 13, 2008 at 4:38 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>> Andrew Pinski wrote:
>>> On Fri, Oct 10, 2008 at 11:14 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
 Richard Guenther wrote:
> On Fri, Oct 10, 2008 at 7:55 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>> I have some broken code, compiled from Java source.
>>
>> It looks like:
>>
>>D.843 = &java.text.Collator.class$$;
>>_Jv_InitClass (D.843);
>>D.845 = &_CD_java_text_Collator;
>>
>> is being turned into:
>>
>>D.843 = &java.text.Collator.class$$;
>>D.845 = &_CD_java_text_Collator;
>>_Jv_InitClass (D.843);
> This is always a valid transformation.
>
>> i.e. the memory reference is moved to before the call to _Jv_InitClass.
> There is no memory reference in the above case, it seems just the address
> of _CD_java_text_Collator is taken.
>
> Or maybe I'm missing sth?
 In the RTL code it moves the mem ref, not just the address:

 (call (mem:QI (symbol_ref:DI ("_Jv_InitClass") [flags 0x41]

 (set (reg/f:DI 95 [ #ref#8#1 ])
(mem/s/u/f/j:DI (const:DI (plus:DI (symbol_ref:DI 
 ("_CD_java_text_Collator")
(const_int 16 [0x10])))

 is turned to:

 (set (reg/f:DI 162 [ #ref#8#1 ])
(mem/s/u/f/j:DI (const:DI (plus:DI (symbol_ref:DI 
 ("_CD_java_text_Collator")
(const_int 16 [0x10])))

 ...

 (call (mem:QI (symbol_ref:DI ("_Jv_InitClass")
>>> Well the mem has a /u on it so it is being marked as MEM_READONLY_P so
>>> it is valid optimization.  Why it is being marked with MEM_READONLY_P,
>>> I don't know.
>> I've found the code that's incorrectly marking the decl as TREE_READONLY.
>> It's here:
>>
>>  /* If the variable is never written, we can set the TREE_READONLY
>> flag.  Additionally if it has a DECL_INITIAL that is made up of
>> constants we can treat the entire global as a constant.  */
>>
>>  bitmap_and_compl (module_statics_readonly, all_module_statics,
>>module_statics_written);
>>  EXECUTE_IF_SET_IN_BITMAP (module_statics_readonly, 0, index, bi)
>>{
>>  tree var = get_static_decl (index);
>>
>>  /* Ignore variables in named sections - changing TREE_READONLY
>> changes the section flags, potentially causing conflicts with
>> other variables in the same named section.  */
>>  if (DECL_SECTION_NAME (var) == NULL_TREE)
>>{
>>  TREE_READONLY (var) = 1;
>>
>> The decl (called _CD_ppp) is not written by the code we generate, that's 
>> true.
>> However, there is a global struct class$, which contains a field which 
>> points to
>> _CD_ppp:
>>
>> ppp::class$:
>>.quad   vtable for java::lang::Class+16
>>.quad   1074145824
>>.quad   _Utf6
>>.value  33
>>.zero   6
>>.quad   java::lang::Object::class$
>>.long   2
>>.zero   4
>>.quad   _CT_ppp
>>.quad   _CD_ppp
>>...
>>
>>.type   _CD_ppp, @object
>>.size   _CD_ppp, 16
>> _CD_ppp:
>>.quad   0
>>.quad   _Utf5
>>
>> I would expect that this would mean that _CD_ppp has its address taken, and
>> therefore should not be marked as TREE_READONLY.
> 
> Right.  So I guess ipa-reference doesn't properly treat all TU local globals
> as written-to if the write occurs through a pointer we don't know where it
> points to.
> 
> Honza - you recently looked into ipa-reference -- does it try to do the
> right thing with pointer accesses here?  I guess it may miss taking addresses
> from inside initializers.  Andrew - is this address-taking from ppp::class$
> visible from a DECL_INITIAL or is this hidden behind some magic?

It's a field in the class$ structure.  class$ is initialized by creating a
CONSTRUCTOR tree and calling CONSTRUCTOR_APPEND_ELT for each field.  The
DECL_INITIAL of class$ points to the CONSTRUCTOR tree.

_CD_pp is an array of void*.  These are initialized by DECL_INITIAL too.

InitClass is passed class$$ (not class$) and that has a DECL_INITIAL
that points to class$.  As far as I can tell all the types are correct.

Andrew.

opt-1.c/opt-2.c ICEs on i686-apple-darwin9

[Jack Howarth]

  We have some new regressions on i686-apple-darwin9...

FAIL: gcc.target/i386/opt-1.c (internal compiler error)
FAIL: gcc.target/i386/opt-1.c (test for excess errors)
ERROR: gcc.target/i386/opt-1.c: error executing dg-final: couldn't open 
"opt-1.s": no such file or directory
FAIL: gcc.target/i386/opt-2.c (internal compiler error)
FAIL: gcc.target/i386/opt-2.c (test for excess errors)
ERROR: gcc.target/i386/opt-2.c: error executing dg-final: couldn't open 
"opt-2.s": no such file or directory

...in the current gcc trunk. These errors manifest themselves as...

Executing on host: 
/sw/src/fink.build/gcc44-4.3.999-20081012/darwin_objdir/gcc/xgcc 
-B/sw/src/fink.build/gcc44-4.3.999-20081012/darwin_objdir/gcc/ /sw/sr
c/fink.build/gcc44-4.3.999-20081012/gcc-4.4-20081012/gcc/testsuite/gcc.target/i386/opt-1.c
   -O1 -msse2 -mfpmath=sse -march=k8 -S  -o opt-1.s(timeout
 = 300)
/sw/src/fink.build/gcc44-4.3.999-20081012/gcc-4.4-20081012/gcc/testsuite/gcc.target/i386/opt-1.c:
 In function 'not_opt3':
/sw/src/fink.build/gcc44-4.3.999-20081012/gcc-4.4-20081012/gcc/testsuite/gcc.target/i386/opt-1.c:34:
 internal compiler error: in mems_in_disjoint_alias_s
ets_p, at alias.c:278
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
compiler exited with status 1
output is:
/sw/src/fink.build/gcc44-4.3.999-20081012/gcc-4.4-20081012/gcc/testsuite/gcc.target/i386/opt-1.c:
 In function 'not_opt3':
/sw/src/fink.build/gcc44-4.3.999-20081012/gcc-4.4-20081012/gcc/testsuite/gcc.target/i386/opt-1.c:34:
 internal compiler error: in mems_in_disjoint_alias_s
ets_p, at alias.c:278
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

FAIL: gcc.target/i386/opt-1.c (internal compiler error)
FAIL: gcc.target/i386/opt-1.c (test for excess errors)
Excess errors:
/sw/src/fink.build/gcc44-4.3.999-20081012/gcc-4.4-20081012/gcc/testsuite/gcc.target/i386/opt-1.c:34:
 internal compiler error: in mems_in_disjoint_alias_s
ets_p, at alias.c:278

ERROR: gcc.target/i386/opt-1.c: error executing dg-final: couldn't open 
"opt-1.s": no such file or directory
UNRESOLVED: gcc.target/i386/opt-1.c: error executing dg-final: couldn't open 
"opt-1.s": no such file or directory

Executing on host: 
/sw/src/fink.build/gcc44-4.3.999-20081012/darwin_objdir/gcc/xgcc 
-B/sw/src/fink.build/gcc44-4.3.999-20081012/darwin_objdir/gcc/ /sw/sr
c/fink.build/gcc44-4.3.999-20081012/gcc-4.4-20081012/gcc/testsuite/gcc.target/i386/opt-2.c
   -O1 -msse2 -mfpmath=sse -march=k8 -S  -o opt-2.s(timeout
 = 300)
/sw/src/fink.build/gcc44-4.3.999-20081012/gcc-4.4-20081012/gcc/testsuite/gcc.target/i386/opt-2.c:
 In function 'not_opt3':
/sw/src/fink.build/gcc44-4.3.999-20081012/gcc-4.4-20081012/gcc/testsuite/gcc.target/i386/opt-2.c:37:
 internal compiler error: in mems_in_disjoint_alias_s
ets_p, at alias.c:278
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
compiler exited with status 1
output is:
/sw/src/fink.build/gcc44-4.3.999-20081012/gcc-4.4-20081012/gcc/testsuite/gcc.target/i386/opt-2.c:
 In function 'not_opt3':
/sw/src/fink.build/gcc44-4.3.999-20081012/gcc-4.4-20081012/gcc/testsuite/gcc.target/i386/opt-2.c:37:
 internal compiler error: in mems_in_disjoint_alias_s
ets_p, at alias.c:278
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

FAIL: gcc.target/i386/opt-2.c (internal compiler error)
FAIL: gcc.target/i386/opt-2.c (test for excess errors)
Excess errors:
/sw/src/fink.build/gcc44-4.3.999-20081012/gcc-4.4-20081012/gcc/testsuite/gcc.target/i386/opt-2.c:37:
 internal compiler error: in mems_in_disjoint_alias_s
ets_p, at alias.c:278

ERROR: gcc.target/i386/opt-2.c: error executing dg-final: couldn't open 
"opt-2.s": no such file or directory

...in gcc.log. This problem didn't exist on 20081008.
   Jack

Re: gcc moving memory reference across call

[Daniel Berlin]

>
> It's a field in the class$ structure.  class$ is initialized by creating a
> CONSTRUCTOR tree and calling CONSTRUCTOR_APPEND_ELT for each field.  The
> DECL_INITIAL of class$ points to the CONSTRUCTOR tree.
>
> _CD_pp is an array of void*.  These are initialized by DECL_INITIAL too.
>
> InitClass is passed class$$ (not class$) and that has a DECL_INITIAL
> that points to class$.  As far as I can tell all the types are correct.
>

If class$$ has an initial of &class$ which has an initial (in it
somewhere) of CD_ppp it should definitely be noticing.
It used to walk these all and get it right, AFAIK, by disqualifying
all variables with their addresses taken (or escaping the function
unit).
Maybe the walking broke when we moved to tuples or something?

Re: install path in libgcc Makefile.in

[Zhang Le]

On 04:19 Mon 13 Oct , Eus wrote:
> Hi Ho!
> 
> On Saturday, October 11, 2008, "Zhang Le" <[EMAIL PROTECTED]> wrote:
> 
> > Hi,
> > 
> > Another problem when cross building the native mips compiler.
> > I.e. build=x86, host=target=mipsel
> > I have done some search, but haven't found any related discussion.
> 
> Please have a look at:
> http://gcc.gnu.org/ml/gcc/2008-09/msg00376.html
> 
> Also, I think Jay has done a research to solve that particular problem:
> http://gcc.gnu.org/ml/gcc-help/2008-08/msg00315.html
> http://gcc.gnu.org/ml/gcc/2008-09/msg9.html

Thanks!
But I don't think that problem is exactly the same as mine.
Plus my patch already solved my problem. ;)

My patch seems to work well, I will post to gcc-patch soon.

BTW, fontconfig 2.6.0 failed to build using 20081010 snapshot native compiler
on Loongson 2F box. But I believe this is irrelevant to my patch. Because I
found the .s files generate by 4.3 and 4.4 are different. Using .o file produced
by gcc 4.3, both gcc 4.3 and 4.4 could produce a working executable.  Using .o
file produced by gcc 4.4, none of them could produce a working executable.

I will try to find the reason.

Regards,

Zhang, Le

Re: divmodsi4

[Omar Torres]

On Fri, Oct 10, 2008 at 10:40 AM, Dave Korn <[EMAIL PROTECTED]> wrote:
> Ian Lance Taylor wrote on 10 October 2008 15:53:
>
>> "Omar Torres" <[EMAIL PROTECTED]> writes:
>>
>>>  The problem is that both, the quotient and reminder, registers are
>>> getting marked with a REG_UNUSED note:
>>>
>>>  (insn 12 11 17 (parallel [
>>> (set (reg:SI 1 %r3 [33])
>>> (div:SI (reg:SI 1 %r3 [30])
>>> (reg:SI 5 %iph [orig:31 current ] [31])))
>>> (set (reg:SI 5 %iph [34])
>>> (mod:SI (reg:SI 1 %r3 [30])
>>> (reg:SI 5 %iph [orig:31 current ] [31])))
>>> ]) 56 {*divmodsi4} (insn_list:REG_DEP_TRUE 10
>>> (insn_list:REG_DEP_TRUE 11 (nil)))
>>> (expr_list:REG_UNUSED (reg:SI 5 %iph [34])
>>> (expr_list:REG_UNUSED (reg:QI 2 %r2)
>>> (expr_list:REG_UNUSED (reg:QI 1 %r3)
>>> (nil)
>>>
>>> Any suggestions on how I might be able to work around this?
>>
>> This makes it sounds like the whole insn is useless.  I wonder why it
>> hasn't simply been deleted?
>
>  Is it not unusual that the insn sets r1 in SImode, but the note says it is
> unused in QImode?  Does that mean only the lowest byte is unused?
>
>cheers,
>  DaveK
> --
> Can't think of a witty .sigline today
>
>

 Hi, thanks for the comments.

 A closer look revealed that this insn is not deleted because it is
needed to (partially) set (reg:SI 33).
 But, as Dave suggested, only the lower part of the quotient is used
afterwards. Below is the src code and the corresponding basic block.

 I suspect that a workaround will be to look not only for the presence
of the REG_UNUSED note, but check check the reg's mode as well, to
successfully determine whether the quotient or remainder  is needed in
divmodsi4.

 Do you agree this will be a practical approach, or is it fundamentally flawed?

Thanks,
-Omar


(machine's word size is 8-bits)

int Resistance (int volt, int current)
{
return ((long) volt<<10)/current;
}

;; basic block 2, loop depth 0, count 0
;; prev block 0, next block 1
;; pred:   ENTRY [100.0%]  (fallthru)
;; succ:   EXIT [100.0%]  (fallthru)
;; Registers live at start:  1 [%r3] 2 [%r2] 3 [%r1] 4 [%r0] 11 [%i2h]
13 [%i3h] 16 [%ap_hi] 18 [%fp_hi]
(note 6 2 3 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 3 6 4 2 (set (reg/v:HI 26 [ volt ])
(reg:HI 1 %r3 [ volt ])) 1 {movhi} (nil)
(nil))
(insn 4 3 5 2 (set (reg/v:HI 27 [ current ])
(reg:HI 3 %r1 [ current ])) 1 {movhi} (nil)
(nil))
(note 5 4 8 2 NOTE_INSN_FUNCTION_BEG)
(insn 8 5 9 2 (set (reg:SI 29 [ volt ])
(sign_extend:SI (reg/v:HI 26 [ volt ]))) 149 {extendhisi2} (nil)
(nil))
(insn 9 8 10 2 (set (reg:SI 1 %r3)
(ashift:SI (reg:SI 29 [ volt ])
(const_int 10 [0xa]))) 71 {*ashlsi3} (nil)
(nil))
(insn 10 9 11 2 (set (reg:SI 30)
(reg:SI 1 %r3)) 2 {movsi} (nil)
(expr_list:REG_EQUAL (ashift:SI (reg:SI 29 [ volt ])
(const_int 10 [0xa]))
(nil)))
(insn 11 10 12 2 (set (reg:SI 31 [ current ])
(sign_extend:SI (reg/v:HI 27 [ current ]))) 149 {extendhisi2} (nil)
(nil))
(insn 12 11 17 2 (parallel [
(set (reg:SI 33)
(div:SI (reg:SI 30)
(reg:SI 31 [ current ])))
(set (reg:SI 34)
(mod:SI (reg:SI 30)
(reg:SI 31 [ current ])))
]) 56 {*divmodsi4} (nil)
(nil))
(note 17 12 20 2 NOTE_INSN_FUNCTION_END)
(insn 20 17 26 2 (set (reg/i:HI 1 %r3 [  ])
(subreg:HI (reg:SI 33) 2)) 1 {movhi} (insn_list:REG_DEP_TRUE 12 (nil))
(expr_list:REG_DEAD (reg:SI 33)
(nil)))
(insn 26 20 0 2 (use (reg/i:HI 1 %r3 [  ])) -1
(insn_list:REG_DEP_TRUE 20 (nil))
(nil))
;; Registers live at end:  1 [%r3] 2 [%r2] 11 [%i2h] 13 [%i3h] 16
[%ap_hi] 18 [%fp_hi]

how does GCC support 24 bit addresses on 16 bit targets ?

[Dong Phuong]

I'm porting for C166 microcontrollers. It supports 24
bit addresses, but as I know, GCC does not support
segmented memory, which is devided into many pages. 

C166 has four page of addressed, each page has a 16
bit address space. The selection of which page to use
is controlled by for DPP register.

So is it possibe in GCC to use all of 24 bit addressed
of  C166 ? 

THank you very much.


  

trivial gccint documentation bug

[namhyung]

Hi,

On section 16.9 Standard Pattern Names For Generation,
first line of description of 'strlenm':
   It seems to use four operands, not three.

-- 
Regards,
Namhyung Kim

Re: query regarding adding a pass to undo final value replacement.

[Ramana Radhakrishnan]

Hi Zdenek,

[Sorry about dropping the ball on this. I've had some trouble with
internet connectivity and was on vacation for a few days.  ]

On Thu, Oct 2, 2008 at 2:56 AM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> Hi,
>
>> >>   b) If any PHI node has count zero it can be inserted back and its
>> >>  corresponding computations removed, iff the argument of the PHI 
>> >> node
>> >>  still exists as an SSA variable. This means that we can insert
>> >>  a_1 = PHI  if D.10_1 still exists and hasnt been removed by
>> >>  any of the passes between the scalar evolution pass and the
>> >>  loopdone pass.
>> >
>> > this does not work:
>> > -- we reuse ssa names, so it can happen that the argument of the PHI node
>> >   is eliminated, then reused for a different purpose
>>
>> I wasn't sure if from the proposal strong enough to catch this case ? i.e. if
>>
>>
>> So if the ssa_names are infact reused they won't be the same
>> computations.
>
> do you also check this for ssa names inside the loop (in your example,
> D.10_1?

If we have to reinsert for a = phi (B) . We do the following checks.

1. If the edge information in the phi node has remained the same then
we don't insert the phi node back in. This check is done by running
the phi node applying iterative_hash_expr on its PHI_ARG_DEF_PTR .

Something like this is done for checking the consistency of hash values.

  arg_p = PHI_ARG_DEF_PTR (phi_node , 0);
  op0 = USE_FROM_PTR (arg_p);
  val = iterative_hash_expr (op0, val);
  if (TREE_CODE (op0) == SSA_NAME)
{
  val = iterative_hash_expr (SSA_NAME_VAR (op0), val);
  val += SSA_NAME_VERSION (op0);

}

I suspect that this should catch the case that you mention here.


>
>> > -- in case more complex loop transformations were performed
>> >   (e.g., loop reversal), the final value of the ssa name might have
>> >   changed.
>>
>> Could you give an example for this ?
>
> for (i = 100; i > 0; i--)
>  a[i] = i;
>
> transformed to
>
> for (i = 1; i <= 100; i++)
>  a[i] = i;
>
> the final value of i was originally 0, now it is 101.
>
>> Is there anything else you might
>> suggest in terms of undoing the transformations from scalar cprop.?
>
> I would probably try to somehow pass the information from scev analysis
> to value numbering, and let PRE take care of the issue,


 I do not know the value numbering code or the scev code well enough
to attempt this immediately. I'm trying to see if this intermediate
solution is good enough for the time being.

>
> Zdenek
>



-- 
Ramana Radhakrishnan

Re: query regarding adding a pass to undo final value replacement.

[Zdenek Dvorak]

Hi,

> [Sorry about dropping the ball on this. I've had some trouble with
> internet connectivity and was on vacation for a few days.  ]
> 
> On Thu, Oct 2, 2008 at 2:56 AM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> >> >>   b) If any PHI node has count zero it can be inserted back and its
> >> >>  corresponding computations removed, iff the argument of the 
> >> >> PHI node
> >> >>  still exists as an SSA variable. This means that we can insert
> >> >>  a_1 = PHI  if D.10_1 still exists and hasnt been removed by
> >> >>  any of the passes between the scalar evolution pass and the
> >> >>  loopdone pass.
> >> >
> >> > this does not work:
> >> > -- we reuse ssa names, so it can happen that the argument of the PHI node
> >> >   is eliminated, then reused for a different purpose
> >>
> >> I wasn't sure if from the proposal strong enough to catch this case ? i.e. 
> >> if
> >>
> >>
> >> So if the ssa_names are infact reused they won't be the same
> >> computations.
> >
> > do you also check this for ssa names inside the loop (in your example,
> > D.10_1?
> 
> If we have to reinsert for a = phi (B) . We do the following checks.
> 
> 1. If the edge information in the phi node has remained the same then
> we don't insert the phi node back in. This check is done by running
> the phi node applying iterative_hash_expr on its PHI_ARG_DEF_PTR .
> 
> Something like this is done for checking the consistency of hash values.
> 
>   arg_p = PHI_ARG_DEF_PTR (phi_node , 0);
>   op0 = USE_FROM_PTR (arg_p);
>   val = iterative_hash_expr (op0, val);
>   if (TREE_CODE (op0) == SSA_NAME)
> {
>   val = iterative_hash_expr (SSA_NAME_VAR (op0), val);
>   val += SSA_NAME_VERSION (op0);
> 
> }
> 
> I suspect that this should catch the case that you mention here.

now you have lost me completely -- this does not seem to check anything
regarding the computations inside the loop, just about the phi node,

Zdenek

Re: query regarding adding a pass to undo final value replacement.

[Ramana Radhakrishnan]

Hi,
 >>
>> >> So if the ssa_names are infact reused they won't be the same
>> >> computations.
>> >
>> > do you also check this for ssa names inside the loop (in your example,
>> > D.10_1?
>>
>> If we have to reinsert for a = phi (B) . We do the following checks.
>>
>> 1. If the edge information in the phi node has remained the same then
>> we don't insert the phi node back in. This check is done by running
>> the phi node applying iterative_hash_expr on its PHI_ARG_DEF_PTR .
>>
>> Something like this is done for checking the consistency of hash values.
>>
>>   arg_p = PHI_ARG_DEF_PTR (phi_node , 0);
>>   op0 = USE_FROM_PTR (arg_p);
>>   val = iterative_hash_expr (op0, val);
>>   if (TREE_CODE (op0) == SSA_NAME)
>> {
>>   val = iterative_hash_expr (SSA_NAME_VAR (op0), val);
>>   val += SSA_NAME_VERSION (op0);
>>
>> }
>>
>> I suspect that this should catch the case that you mention here.
>
> now you have lost me completely -- this does not seem to check anything
> regarding the computations inside the loop, just about the phi node,

Well since the phi node with a single operand depends on statements /
operations within the loop, the hashcode computed initially and
finally need to match. If the computations within the loop change then
clearly the hash values at the time of storing and restoring would be
different . So if the assignment to D.10_1 has changed in some form,
the hashvalues would be different.

>
> Zdenek
>



-- 
Ramana Radhakrishnan