Re: apply for the relevant forms

[Manuel López-Ibáñez]

On 08/06/06, Jie Zhang <[EMAIL PROTECTED]> wrote:

On 6/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Our Co. have a new 32b embedded processor, and we have ported the gcc
> backend for it(support c/c++), now we want add its backend code into gcc
> packages. i read the "Contributing to GCC " pages that we must sign some
> forms, can you kindly send the forms to me?
>
It said on :  "It's a good idea to
send [EMAIL PROTECTED] a copy of your request.", not gcc mailing
list.

And [EMAIL PROTECTED] and gcc@gcc.gnu.org are same thing, no need to send to 
both.

Jie



Actually, you only quoted part of the paragraph. The previous sentence
says exactly:

"[...] and contact us (either via the gcc@gcc.gnu.org list or the GCC
maintainer that is taking care of your contributions) to obtain the
relevant forms."

Thus, I would expect that I had to contact gcc@gcc.gnu.org to obtain
the relevant forms...

Cheers,
Manuel.

Re: Symbol table resolution

[Andrew Haley]

Properly enforcing access rules in libgcj causes problems in that
compiler-generated code sometimes wants to access private methods.

This patch uses a single bit in the signature pointer to indicate that
this is a compiler-generated access, so we should not perform any
access checks.  Encoding the bit in this way isn't very nice, but it
is fast and backward compatible.

Bootstrapped x86_64.

Andrew.


2006-06-08  Andrew Haley  <[EMAIL PROTECTED]>

* expr.c (build_field_ref): Pass NULL_TREE as SPECIAL arg to
get_symbol_table_index().
(maybe_rewrite_invocation): Set SPECIAL if we need to access a
private method.
(build_known_method_ref): New arg: special.  Pass it to
get_symbol_table_index.
(get_symbol_table_index): Put SPECIAL in the TREE_PURPOSE field of
the method list.
(build_invokevirtual): New arg: special.  Pass it to
get_symbol_table_index.
(expand_invoke): New variable: special.
Pass it to maybe_rewrite_invocation().
Pass it to build_known_method_ref().
* class.c (build_symbol_entry): Add new arg: special.  Use it to
build the symbol table conbstructor.
(emit_symbol_table): Extract SPECIAL from the method list and pass
it to build_symbol_entry().
* parse.y (patch_invoke): Call maybe_rewrite_invocation() and set
special accordingly.

Index: java/parse.y
===
--- java/parse.y(revision 114484)
+++ java/parse.y(working copy)
@@ -11043,8 +11043,14 @@
   switch (invocation_mode (method, CALL_USING_SUPER (patch)))
{
case INVOKE_VIRTUAL:
- dtable = invoke_build_dtable (0, args);
- func = build_invokevirtual (dtable, method);
+ {
+   tree signature = build_java_signature (TREE_TYPE (method));
+   tree special;
+   maybe_rewrite_invocation (&method, &args, &signature, &special);
+
+   dtable = invoke_build_dtable (0, args);
+   func = build_invokevirtual (dtable, method, special);
+ }
  break;
 
case INVOKE_NONVIRTUAL:
@@ -11066,10 +11072,11 @@
case INVOKE_STATIC:
  {
tree signature = build_java_signature (TREE_TYPE (method));
-   maybe_rewrite_invocation (&method, &args, &signature);
+   tree special;
+   maybe_rewrite_invocation (&method, &args, &signature, &special);
func = build_known_method_ref (method, TREE_TYPE (method),
   DECL_CONTEXT (method),
-  signature, args);
+  signature, args, special);
  }
  break;
 
Index: java/class.c
===
--- java/class.c(revision 114484)
+++ java/class.c(working copy)
@@ -62,7 +62,7 @@
 static tree maybe_layout_super_class (tree, tree);
 static void add_miranda_methods (tree, tree);
 static int assume_compiled (const char *);
-static tree build_symbol_entry (tree);
+static tree build_symbol_entry (tree, tree);
 static tree emit_assertion_table (tree);
 static void register_class (void);
 
@@ -2651,7 +2651,7 @@
 /* Make a symbol_type (_Jv_MethodSymbol) node for DECL. */
 
 static tree
-build_symbol_entry (tree decl)
+build_symbol_entry (tree decl, tree special)
 {
   tree clname, name, signature, sym;
   clname = build_utf8_ref (DECL_NAME (TYPE_NAME (DECL_CONTEXT (decl;
@@ -2667,6 +2667,12 @@
   signature = build_utf8_ref (unmangle_classname 
  (IDENTIFIER_POINTER (signature),
   IDENTIFIER_LENGTH (signature)));
+  /* SPECIAL is either NULL_TREE or integer_one_node.  We emit
+ signature addr+1 if SPECIAL, and this indicates to the runtime
+ system that this is a "special" symbol, i.e. one that should
+ bypass access controls.  */
+  if (special != NULL_TREE)
+signature = build2 (PLUS_EXPR, TREE_TYPE (signature), signature, special);
   
   START_RECORD_CONSTRUCTOR (sym, symbol_type);
   PUSH_FIELD_VALUE (sym, "clname", clname);
@@ -2701,8 +2707,9 @@
   list = NULL_TREE;  
   while (method_list != NULL_TREE)
 {
+  tree special = TREE_PURPOSE (method_list);
   method = TREE_VALUE (method_list);
-  list = tree_cons (NULL_TREE, build_symbol_entry (method), list);
+  list = tree_cons (NULL_TREE, build_symbol_entry (method, special), list);
   method_list = TREE_CHAIN (method_list);
   index++;
 }
Index: java/expr.c
===
--- java/expr.c (revision 114484)
+++ java/expr.c (working copy)
@@ -1711,7 +1711,8 @@
{
  tree otable_index
= build_int_cst (NULL_TREE, get_symbol_table_index 
-(field_decl, &TYPE_OTABLE_METHODS (output_class)));
+

PR 26792

[Jack Howarth]

Geoff,
I noticed PR 26792 last night. After reading that it became clear what
was causing the massive c++ regressions when I built gcc trunk under fink.
Fink sets MACOSX_DEPLOYMENT_TARGET to 10.4 when a package is built in
fink 10.4 branch. They also were applying the rejected patch from...

http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02041.html

to their gcc4 builds as well. That explains why the c++ regressions
suddenly appeared when I stopped applying their gcc4.patch (which
contains that and other changes for building on MacIntel).
The good news is that when I build gcc trunk under fink with
MACOSX_DEPLOYMENT_TARGET unset, the massive c++ regressions now
disappear. The bad news is that the resulting gcc, when used to
build xplor-nih, still results in the c++ regression in the xplor-nih
testsuite which I reported several weeks ago. Did the information
I reported give you any hints as to where the problem might be?

http://gcc.gnu.org/ml/gcc/2006-06/msg00043.html

Let me know if there is anything I can do to try to pin down
this remaining libgcc issue (which appears to be unrelated to
PR 26792).
 Jack

Re: x86 Linux stack alignment requirement

[H. J. Lu]

On Wed, Jun 07, 2006 at 06:38:52PM -0500, Menezes, Evandro wrote:
> > > > > > We have several choices for stack alignment requirement
> > > > > > 
> > > > > > 1. Leave it unchanged. Gcc can do
> > > > > > a. Nothing. Let the program crash.
> > > > > > b. Align stack to 16byte if XMM registers are 
> > used locally and
> > > > > >aren't passed down as function arguments.
> > > > > 
> > > > > Why not so if the XMM registers are passed down as arguments?
> > > > 
> > > > When calling a function with XMM register arguments, 
> > doesn't caller
> > > > have to align stack to 16byte for callee?
> > > 
> > > Not necessarily, I think.  Just like the caller aligned its 
> > stack to 16 bytes, the callee can do the same while still 
> > assuming the 4-byte alignment.  And it's an even lesser 
> > problem with -msseregparm or the sseregparam attribute.
> > 
> > How are XMM arguments passed by default? What happens when there are
> > more 16 XMM parameters?
> > Is XMM supported with variable argument list? 
> 
> I see.  Provided a local is passed in a register to a non-vararg function, it 
> is still OK to align the stack.

Given that we don't support 4 byte aligned stack at all with XMM
regisrers, I would prefer to increase Linux/x86 stack alignment to
16 byte. People can use 4 byte alignment if they want. As for the
existing 4 byte aligned code, -mstackrealign can be used to support
them.


H.J.

SVN branch for current Boehm's GC + GCC code?

[Laurynas Biveinis]

Hi,

One of the SoC requirements is to have public development. So I should
I create a branch of my current Boehm's GC experiments and commit my
code there? I'm not sure, because there exists a posibility that this
branch will be thrown away, if we don't go the Boehm's GC route. And
the current code is very experimental and will have to be mostly
rewritten if we do go this route...

(I will not read email for a few days as I will be offline till Monday)
--
Laurynas

Re: -mno-80387 and MMX autovectorisation

[Andrew Pinski]

On Jun 7, 2006, at 11:13 PM, Uros Bizjak wrote:


Hello!

Current mainline gcc can efficiently disable x87 instruction when
-mno-80387 switch is used. In this case, MMX registers can be used for
the autovectorisation even without emms or femms instructions to
switch back to x87 mode.


I don't think so, because another function could use x87 instructions
even without you knowing it.

-- Pinski

RE: SVN branch for current Boehm's GC + GCC code?

[Dave Korn]

On 08 June 2006 16:34, Laurynas Biveinis wrote:

> One of the SoC requirements is to have public development. So I should
> I create a branch of my current Boehm's GC experiments and commit my
> code there? I'm not sure, because there exists a posibility that this
> branch will be thrown away, if we don't go the Boehm's GC route. And
> the current code is very experimental and will have to be mostly
> rewritten if we do go this route...

  That sounds to me like /exactly/ what branches are for.  AFAIUI the
branching policy is very liberal and there should be no problem with creating
a branch.  Ah, here it is:

http://gcc.gnu.org/svnwrite.html#policies says

"Free for all

The following changes can be made by everyone with SVN write access:

  [ ... SNIP! ... ]

Creating and using a branch for development, including outside the parts of
the compiler one maintains, provided that changes on the branch have copyright
assignments on file. Merging such developments back to the mainline still
needs approval in the usual way. "

  See also 
http://gcc.gnu.org/svnwrite.html#branches



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

[LTO] Flattening memory expressions?

[Diego Novillo]

When I originally thought of flattening the data structures for
representing GIMPLE, I had not really contemplated the idea of totally
lowering the memory expressions represented by ARRAY_REF and COMPONENT_REF.

However, as Kenny pointed out today, it may be useful for us to
completely simplify these expressions to remove their recursive
structure.  Something like:

ARRAY_REF : ID [ VAL ]

COMPONENT_REF : ID . ID
| INDIRECT_REF . ID

INDIRECT_REF : * ID

We would probably need INDIRECT_REFs in COMPONENT_REF nodes to avoid
lots of memory copying.

The rationale is that by removing the recursiveness of these
expressions, it would make it easier to emit the LTO bytecodes without
resorting to a stack machine.

These memory expressions are the only ones that I think would need to be
simplifed.  All the other GIMPLE expressions are already flat enough for
LTO purposes.

This flattening, however, could bring debug code generation issues.  I'm
not sure.

Please don't get too fixated on the above pseudo-code.  I have not
thought about this through in detail.  I just want to bring this up,
particularly for folks doing data dependency.  Perhaps we need different
 expressions altogether, we don't need to stick to the current scheme if
it's not sufficiently useful.

Thoughts?

Re: [LTO] Flattening memory expressions?

[Richard Guenther]

On 6/8/06, Diego Novillo <[EMAIL PROTECTED]> wrote:


When I originally thought of flattening the data structures for
representing GIMPLE, I had not really contemplated the idea of totally
lowering the memory expressions represented by ARRAY_REF and COMPONENT_REF.

However, as Kenny pointed out today, it may be useful for us to
completely simplify these expressions to remove their recursive
structure.  Something like:

ARRAY_REF : ID [ VAL ]

COMPONENT_REF : ID . ID
| INDIRECT_REF . ID

INDIRECT_REF : * ID

We would probably need INDIRECT_REFs in COMPONENT_REF nodes to avoid
lots of memory copying.

The rationale is that by removing the recursiveness of these
expressions, it would make it easier to emit the LTO bytecodes without
resorting to a stack machine.

These memory expressions are the only ones that I think would need to be
simplifed.  All the other GIMPLE expressions are already flat enough for
LTO purposes.

This flattening, however, could bring debug code generation issues.  I'm
not sure.

Please don't get too fixated on the above pseudo-code.  I have not
thought about this through in detail.  I just want to bring this up,
particularly for folks doing data dependency.  Perhaps we need different
 expressions altogether, we don't need to stick to the current scheme if
it's not sufficiently useful.

Thoughts?


We (me and Matz) thought over this as well and concluded it would be
nice to have

- MEM_REF ( base, offset, alias_tag )

with base being either some memory object or an INDIRECT_REF of a pointer and
be done with that tree code.  The MEM_REF would also contain an alias tag for
easy oracle queries, like an integer we get from get_alias_set now.
Sticking that
to the actual MEM_REF sounded particularly nice - also the frontends
can this way
communicate aliasing semantics down to the middle-end in addition to TBAA stuff.

So, yes, we like complete lowering as 90% of optimization passes deal with
base and offset using get_inner_reference or friends anyway.

Richard.

Re: g++ compiler enhancement request

[Joe Buck]

[EMAIL PROTECTED] writes:
> There is a __COUNTER__ macro, supported by Microsoft C++ compiler which
> can help me a lot in the thesis implementation.  This macro expands to
> an integer starting with 0 and incrementing by 1 every time it is
> used  Would you consider it adding it to the official gnu compiler
> if I'll implement it?

On Wed, Jun 07, 2006 at 01:59:45PM -0700, Ian Lance Taylor wrote:
> Yes, we would consider it.
> 
> > What is the standard procedure to do so?
> 
> Short version: Sign a copyright assignment so that we can use your
> code.  Write the patch.  Test the patch.  Send the patch to
> [EMAIL PROTECTED]

We'd need good documentation as well, which is clear enough so that
there is no ambiguity about what the __COUNTER__ value is at any point.

Re: SVN branch for current Boehm's GC + GCC code?

[Richard Guenther]

On 6/8/06, Dave Korn <[EMAIL PROTECTED]> wrote:

On 08 June 2006 16:34, Laurynas Biveinis wrote:

> One of the SoC requirements is to have public development. So I should
> I create a branch of my current Boehm's GC experiments and commit my
> code there? I'm not sure, because there exists a posibility that this
> branch will be thrown away, if we don't go the Boehm's GC route. And
> the current code is very experimental and will have to be mostly
> rewritten if we do go this route...

  That sounds to me like /exactly/ what branches are for.  AFAIUI the
branching policy is very liberal and there should be no problem with creating
a branch.  Ah, here it is:


Though you will probably get more feedback if you post patches and numbers to
the gcc-patches list instead of "silently" working on a branch.  At
least if the changes
are not too big.  At some point a branch is surely the way to go.

Richard.

Re: [LTO] Flattening memory expressions?

[Daniel Berlin]

Richard Guenther wrote:
> On 6/8/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
>> When I originally thought of flattening the data structures for
>> representing GIMPLE, I had not really contemplated the idea of totally
>> lowering the memory expressions represented by ARRAY_REF and COMPONENT_REF.
>>
>> However, as Kenny pointed out today, it may be useful for us to
>> completely simplify these expressions to remove their recursive
>> structure.  Something like:
>>
>> ARRAY_REF : ID [ VAL ]
>>
>> COMPONENT_REF : ID . ID
>> | INDIRECT_REF . ID
>>
>> INDIRECT_REF : * ID
>>
>> We would probably need INDIRECT_REFs in COMPONENT_REF nodes to avoid
>> lots of memory copying.
>>
>> The rationale is that by removing the recursiveness of these
>> expressions, it would make it easier to emit the LTO bytecodes without
>> resorting to a stack machine.
>>
>> These memory expressions are the only ones that I think would need to be
>> simplifed.  All the other GIMPLE expressions are already flat enough for
>> LTO purposes.
>>
>> This flattening, however, could bring debug code generation issues.  I'm
>> not sure.
>>
>> Please don't get too fixated on the above pseudo-code.  I have not
>> thought about this through in detail.  I just want to bring this up,
>> particularly for folks doing data dependency.  Perhaps we need different
>>  expressions altogether, we don't need to stick to the current scheme if
>> it's not sufficiently useful.
>>
>> Thoughts?
> 
> We (me and Matz) thought over this as well and concluded it would be
> nice to have
> 
>  - MEM_REF ( base, offset, alias_tag )
> 
> with base being either some memory object or an INDIRECT_REF of a pointer and
> be done with that tree code. 

So if you have MEM_REF(INDIRECT_REF(a),i,0), you really haven't done any
better in removing recursion :)

> The MEM_REF would also contain an alias tag for
> easy oracle queries

Tag has some meaning in our current structure.
I'd support some sort of generic token that associates the alias info
with it, however.

Re: [LTO] Flattening memory expressions?

[Michael Matz]

Hi,

On Thu, 8 Jun 2006, Richard Guenther wrote:

> > Please don't get too fixated on the above pseudo-code.  I have not
> > thought about this through in detail.  I just want to bring this up,
> > particularly for folks doing data dependency.  Perhaps we need
> > different
> >  expressions altogether, we don't need to stick to the current scheme
> > if it's not sufficiently useful.
> > 
> > Thoughts?
> 
> We (me and Matz) thought over this as well and concluded it would be
> nice to have
> 
> - MEM_REF ( base, offset, alias_tag )
> 
> with base being either some memory object or an INDIRECT_REF of a
> pointer and be done with that tree code.  The MEM_REF would also contain
> an alias tag for easy oracle queries, like an integer we get from
> get_alias_set now. Sticking that to the actual MEM_REF sounded
> particularly nice - also the frontends can this way communicate aliasing
> semantics down to the middle-end in addition to TBAA stuff.

Right.  In particular if you won't emit debug information you can by this
way do away with all references to types in the insns itself.  The
variables would have no complicated type anymore, if anything perhaps a
length.  All aliasing relations would be explicit by dumping the
alias-number graph (I think in the end it would be a graph, not just a
tree), and having an alias number _per memory access_.  That would provide
for a very clear, concise and what's more frontend independend
representation of the intermediate form with aliasing info.

For purposes of merging the aliasing graphs of different compilation units
you still need to emit some type info of course (e.g. a relation of alias
number and (sub)type), but the variables itself don't all need a type
anymore (well, not composite types at least, they still can have scalar
native types, much like RTL modes plus signedness or pointerness).


Ciao,
Michael.

Problem with address reloading

[Juul Vanderspek]

I would appreciate any help in this reload problem
that I have been struggling with for some time:

I completed a gcc back end port to a processor that
supports both displaced and indexed addressing modes
for load, but only displaced for store. For example:

ld.w Rd Rb imm(load from Rb+imm)
ld.w Rd Rb Ri (load from Rb+4*Ri)

st.w Rd Rb imm(store to Rb+imm)
st.w Rd Rb Ri (indexed not allowed for store)
   
This compiler runs fine, but currently without
generating indexed load instructions.

In order to enable indexed loads, I extended
GO_IF_LEGITIMATE_ADDRESS to also match indexed
addresses, added a memory constraint 'R' to match
nonindexed addresses, and used R for stores in the
'mov' rule (see below). This rule now defines an
explicit case for all address modes, except indexed
stores. I understand that the reloader should convert
these by loading the store address into a register.

This appears not to happen: although indexed load
instructions are now indeed being generated, I get the
following error messages on such stores:

(insn 25 14 15 0 (set (mem/s:SI (plus:SI (mult:SI
(reg:SI 11 a11 [ i ])
(const_int 4 [0x4]))
(reg/f:SI 9 a9 [26])) [3 n S4
A32])
(reg:SI 15 a15)) 2 {movsi} (nil)
(nil))
x.c:6: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:393

Tracing all this in find_reloads (reload.c), I see a
call to find_reloads_address, indeed with reload type
RELOAD_FOR_OUTPUT_ADDRESS, but this function
immediately discovers that the address is a
strict_memory_address, and decides to do nothing. This
leads me to believe that I made some error in the
STRICT case of GO_IF_LEGITIMATE_ADDRESS, but everyting
does look ok there.

Is there anything that I am doing obviously wrong?



--
   
   
#define GO_IF_LEGITIMATE_ADDRESS ... \
 -- recognizes register, displaced, and indexed --

#define EXTRA_CONSTRAINT(X, C) \
 (\
 ...
  (C) == 'R' ? ( GET_CODE(X) == MEM   \
  && falcon_non_indexed_p(\
XEXP(X,0), GET_MODE(X)\
   ))   : \
  0)
  
#define EXTRA_MEMORY_CONSTRAINT(X, STR)  ((X) == 'R')



(define_insn "mov"
  [(set
(match_operand:BWD 0 "nonimmediate_operand"
"=r,R,r,r,r,r,r,r,x,r")
(match_operand:BWD 1 "general_operand"  
"m,r,L,I,Q,n,i,x,r,r"))]
  ""
  "@
 %L1 %0 %1;
 %S0 %0 %1;
 xor%0 %0;
 mv %0 %1;
 mv %0 (%1);
 mv %0 [EMAIL PROTECTED](%1);\;sethi %0 [EMAIL PROTECTED](%1);
 mv %0 [EMAIL PROTECTED](%1);\;sethi %0 [EMAIL PROTECTED](%1);
 mv %0 %1;
 mv %0 %1;
 mv  %0 %1;")


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [LTO] Flattening memory expressions?

[Richard Guenther]

On 6/8/06, Daniel Berlin <[EMAIL PROTECTED]> wrote:

Richard Guenther wrote:
> We (me and Matz) thought over this as well and concluded it would be
> nice to have
>
>  - MEM_REF ( base, offset, alias_tag )
>
> with base being either some memory object or an INDIRECT_REF of a pointer and
> be done with that tree code.

So if you have MEM_REF(INDIRECT_REF(a),i,0), you really haven't done any
better in removing recursion :)


Well, unless you allow both pointers and objects as operand 0 of MEM_REF
you either need to build ADDR_EXPRs of objects or INDIRECT_REFs of pointers.
At least if you consider the goal of killing all other tcc_reference
trees and only have
MEM_REF as a way to access memory.  Using ADDR_EXPRs is less nice than
INDIRECT_REFs, because this way you make local aggregates addressable.

Another way of expressing MEM_REF (INDIRECT_REF (a), i, 0) could be of course
to have INDIRECT_MEM_REF (a, i, 0) - but that's just a detail of the
representation.


> The MEM_REF would also contain an alias tag for
> easy oracle queries

Tag has some meaning in our current structure.
I'd support some sort of generic token that associates the alias info
with it, however.


Yes, it is supposed to be a generic token that should be able to handle aliasing
queries of a to-be-invented middle-end aliasing query system, which we
need anyway
for cross-language LTO.

Richard.

Re: [LTO] Flattening memory expressions?

[Michael Matz]

Hi,

On Thu, 8 Jun 2006, Daniel Berlin wrote:

> >>> with base being either some memory object or an INDIRECT_REF of a
> >>> pointer and be done with that tree code.
> >> So if you have MEM_REF(INDIRECT_REF(a),i,0), you really haven't done
> >> any better in removing recursion :)
> > 
> > What type the first operand would be could be a one-bit flag in the
> > MEM_REF itself.  I.e. if there's an implicit INDIRECT_REF around the
> > first operand, or not.  The important part is only that the target
> > address of that memory reference is computable completely trivially,
> > namely by A + i, where A is either a or &a depending on that flag.  
> > And the more important thing anyway is that alias information of this
> > specific mem reference encoded therein.
> 
> Not for data dependence it's not. :)

You mean tests based on the actual index vector, instead of the final 
offset vector?  I still sometimes think that one should be able to 
recover the index vector reasonably well, when given only offsets (and 
perhaps adjusted bases).  It's a tradeoff of having only one way to 
express memory accesses (which I find quite sexy) and having to do a 
bit more work when trying to get at the offsets.


Ciao,
Michael.

Re: [LTO] Flattening memory expressions?

[Daniel Berlin]

Michael Matz wrote:
> Hi,
> 
> On Thu, 8 Jun 2006, Daniel Berlin wrote:
> 
 Thoughts?
>>> We (me and Matz) thought over this as well and concluded it would be
>>> nice to have
>>>
>>>  - MEM_REF ( base, offset, alias_tag )
>>>
>>> with base being either some memory object or an INDIRECT_REF of a
>>> pointer and be done with that tree code.
>> So if you have MEM_REF(INDIRECT_REF(a),i,0), you really haven't done any
>> better in removing recursion :)
> 
> What type the first operand would be could be a one-bit flag in the 
> MEM_REF itself.  I.e. if there's an implicit INDIRECT_REF around the 
> first operand, or not.  The important part is only that the target address 
> of that memory reference is computable completely trivially, namely by A + 
> i, where A is either a or &a depending on that flag.  And the more 
> important thing anyway is that alias information of this specific mem 
> reference encoded therein.

Not for data dependence it's not.
:)

RE: Problem with address reloading

[Dave Korn]

On 08 June 2006 17:44, Juul Vanderspek wrote:


> Tracing all this in find_reloads (reload.c), I see a
> call to find_reloads_address, indeed with reload type
> RELOAD_FOR_OUTPUT_ADDRESS, but this function
> immediately discovers that the address is a
> strict_memory_address, and decides to do nothing. This
> leads me to believe that I made some error in the
> STRICT case of GO_IF_LEGITIMATE_ADDRESS, but everyting
> does look ok there.
> 
> Is there anything that I am doing obviously wrong?
> 
> 
> 
> --
> 
> 
> #define GO_IF_LEGITIMATE_ADDRESS ... \
>  -- recognizes register, displaced, and indexed --


  Oh, yes.  That's not valid C at all.  


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

RE: Problem with address reloading

[Juul Vanderspek]

Um, this just is a collapse of some large macro.
The original compiles into a compiler that refuses to
reload.

> > 
> > #define GO_IF_LEGITIMATE_ADDRESS ... \
> >  -- recognizes register, displaced, and indexed --
> 
> 
>   Oh, yes.  That's not valid C at all.  
> 
> 
> cheers,
>   DaveK
> -- 
> Can't think of a witty .sigline today
> 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [LTO] Flattening memory expressions?

[Zdenek Dvorak]

Hello,

> > >>> with base being either some memory object or an INDIRECT_REF of a
> > >>> pointer and be done with that tree code.
> > >> So if you have MEM_REF(INDIRECT_REF(a),i,0), you really haven't done
> > >> any better in removing recursion :)
> > > 
> > > What type the first operand would be could be a one-bit flag in the
> > > MEM_REF itself.  I.e. if there's an implicit INDIRECT_REF around the
> > > first operand, or not.  The important part is only that the target
> > > address of that memory reference is computable completely trivially,
> > > namely by A + i, where A is either a or &a depending on that flag.  
> > > And the more important thing anyway is that alias information of this
> > > specific mem reference encoded therein.
> > 
> > Not for data dependence it's not. :)
> 
> You mean tests based on the actual index vector, instead of the final 
> offset vector?  I still sometimes think that one should be able to 
> recover the index vector reasonably well, when given only offsets (and 
> perhaps adjusted bases).  It's a tradeoff of having only one way to 
> express memory accesses (which I find quite sexy) and having to do a 
> bit more work when trying to get at the offsets.

by this kind of lowering, you lose quite a lot of information.  For
example, a[i][j] lowers to something like
offset = step1 * i + step2 * j; MEM(a, offset).

1) Recovering the index vector is not easy, as the optimizations may
   change this code a lot.  Even if you find an expression that looks
   like MEM(a, step1 * i + step2 * j), you have no good way to know that
   this was not originally a[i + 1][j - step1/step2].
2) If "a" has constant bounds, before the lowering you could use these
   bounds for example to estimate # of iterations of a loop.  From
   similar reasons as in the last statement, this is impossible after
   lowering.
3) There may be some uses of the fact that we know that the arithmetics
   in step1 * i + step2 * j cannot overflow (which is at the moment
   impossible to remember after lowering), although I cannot think about
   a good example just now.

Zdenek

Re: [LTO] Flattening memory expressions?

[Daniel Berlin]

Zdenek Dvorak wrote:
> Hello,
> 
>> with base being either some memory object or an INDIRECT_REF of a
>> pointer and be done with that tree code.
> So if you have MEM_REF(INDIRECT_REF(a),i,0), you really haven't done
> any better in removing recursion :)
 What type the first operand would be could be a one-bit flag in the
 MEM_REF itself.  I.e. if there's an implicit INDIRECT_REF around the
 first operand, or not.  The important part is only that the target
 address of that memory reference is computable completely trivially,
 namely by A + i, where A is either a or &a depending on that flag.  
 And the more important thing anyway is that alias information of this
 specific mem reference encoded therein.
>>> Not for data dependence it's not. :)
>> You mean tests based on the actual index vector, instead of the final 
>> offset vector?  I still sometimes think that one should be able to 
>> recover the index vector reasonably well, when given only offsets (and 
>> perhaps adjusted bases).  It's a tradeoff of having only one way to 
>> express memory accesses (which I find quite sexy) and having to do a 
>> bit more work when trying to get at the offsets.
> 
> by this kind of lowering, you lose quite a lot of information.  For
> example, a[i][j] lowers to something like
> offset = step1 * i + step2 * j; MEM(a, offset).
> 
> 1) Recovering the index vector is not easy, as the optimizations may
>change this code a lot.  Even if you find an expression that looks
>like MEM(a, step1 * i + step2 * j), you have no good way to know that
>this was not originally a[i + 1][j - step1/step2].

In fact, IIRC, XLC and ICC spend a large amount of time trying to
recover these vectors from already existing code, and concentrate on not
losing the ones they have.

By transforming multiple dimension array accesses into just random
arithmetic, you've make subscript approaches to data dependence very
hard for any real cases.  If you really think you can do a good job of
recovering the index vector, i highly suggest you try it before we
choose this method.  All of our pointer accesses currently look like the
form above, even if they were originall p[i][j], where p is int **.
If you are correct, you should easily be able to write something to
calculate i and j.

The existing data dependence infrastructure would love to have this
information.



Single dimension accesses are of course, just fine with this representation.

Re: Modifying ARM code generator for elimination of 8bit writes - need help

[Rask Ingemann Lambertsen]

On Tue, Jun 06, 2006 at 08:27:10PM +0200, Rask Ingemann Lambertsen wrote:
> On Tue, Jun 06, 2006 at 10:39:46AM +0100, Richard Sandiford wrote:

> > This is just a guess, but the insn above might be an output reload.
> 
> It is, in a peculiar (and not useful) way. Diffing the greg dump against
> the lreg dump shows (using the example code I posted):
> 
> +(insn:HI 25 17 38 2 (set (reg:QI 3 r3)
> +(reg:QI 3 r3 [110])) 158 {*arm_movqi_insn_swp} (nil)
> +(nil))
> 
> -(insn:HI 25 17 36 2 (set (mem/s:QI (plus:SI (reg/v/f:SI 101 [ x ])
> +(insn 38 25 36 2 (set (mem/s:QI (plus:SI (reg/v/f:SI 0 r0 [orig:101 x ]
> + [101])
>  (const_int 5 [0x5])) [0 .c2+0 S1 A8])
> -(subreg:QI (reg:SI 110) 0)) 158 {*arm_movqi_insn_swp} (nil)
> -(expr_list:REG_DEAD (reg:SI 110)
> -(expr_list:REG_DEAD (reg/v/f:SI 101 [ x ])
> -(nil
> +(reg:QI 3 r3)) 158 {*arm_movqi_insn_swp} (nil)
> +(nil))
> 
> I.e. change insn 25 to a nop and then add insn 38 as essentially a duplicate
> of the original insn 25. I don't think reload was supposed to do that.

The reason this happens is because reload decides that the cheapest
alternative is the first one, which is reg->reg. Then of course it has to
make an output reload to copy the value to memory...

I have not yet looked into why reload thinks the reg->reg alternative is the
cheapest one. That'll be tomorrow at the earliest.

Meanwhile, to ensure that reload decides upon the alternative we want,
delete the *arm_movqi_insn_swp pattern and use these two instead:

(define_insn "*arm_movqi_insn_to_reg"
  [(set (match_operand:QI 0 "register_operand" "=r,r,r")
(match_operand:QI 1 "general_operand" "rI,K,m"))]
  "TARGET_ARM && TARGET_SWP_BYTE_WRITES
   && (   register_operand (operands[0], QImode)
   || register_operand (operands[1], QImode))"
  "@
   mov%?\\t%0, %1
   mvn%?\\t%0, #%B1
   ldr%?b\\t%0, %1"
  [(set_attr "type" "*,*,load1")
   (set_attr "predicable" "yes")]
)

(define_insn "*arm_movqi_insn_swp"
  [(set (match_operand:QI 0 "memory_operand" "=Q")
(match_operand:QI 1 "nonmemory_operand" "r"))]
  "TARGET_ARM && TARGET_SWP_BYTE_WRITES
   && (   register_operand (operands[0], QImode)
   || register_operand (operands[1], QImode))"
  "swp%?b\\t%1, %1, %0\;ldr%?b\\t%1, %0"
  [(set_attr "type" "store1")
   (set_attr "predicable" "yes")]
)

Also, undo the change to arm_legitimate_address_p() arm.c.

Btw, why are there calls to register_operand() in the insn conditions?

With the changes above, I now get this (-O2 -swp-byte-writes):

bytewritetest:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldrbr3, [r0, #5]@ zero_extendqisi2
ldrbr2, [r0, #4]@ zero_extendqisi2
eor r1, r3, r2
add r3, r3, r2
add r2, r0, #5
ldr ip, [r0, #0]
swpbr1, r1, [r2, #0]
@ lr needed for prologue
str ip, [r0, #8]
str r3, [r0, #0]
bx  lr

That's a lot better. It is now only one instruction longer than without
-swp-byte-writes.

-- 
Rask Ingemann Lambertsen

RE: Problem with address reloading

[Dave Korn]

On 08 June 2006 18:54, Juul Vanderspek wrote:

> Um, this just is a collapse of some large macro.
> The original compiles into a compiler that refuses to
> reload.


  The point I was making was that if you think there's a problem with that
macro, and you've posted to the list to ask if anyone can help you analyse the
problem with the macro, then leaving out the vital details, such as the macro
itself, is a bit  well ... you know.

  Debugging by guesswork and ESP is not recommended by most textbooks on sound
engineering practice!  Now show us yer code!


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

RE: Problem with address reloading

[Juul Vanderspek]

I collapsed the macro exactly because I am pretty sure
that this macro is ok (I have extensively verified
that it works), and to keep the 
initial message small. I have attached my complete
configuration file this time.

--- Dave Korn <[EMAIL PROTECTED]> wrote:

> On 08 June 2006 18:54, Juul Vanderspek wrote:
> 
> > Um, this just is a collapse of some large macro.
> > The original compiles into a compiler that refuses
> to
> > reload.
> 
> 
>   The point I was making was that if you think
> there's a problem with that
> macro, and you've posted to the list to ask if
> anyone can help you analyse the
> problem with the macro, then leaving out the vital
> details, such as the macro
> itself, is a bit  well ... you know.
> 
>   Debugging by guesswork and ESP is not recommended
> by most textbooks on sound
> engineering practice!  Now show us yer code!
> 
> 
> cheers,
>   DaveK
> -- 
> Can't think of a witty .sigline today
> 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com /* Definitions for GCC.  Part of the machine description for FALCON.
   Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005
   Free Software Foundation, Inc.
   Contributed by Axis Communications.  Written by Hans-Peter Nilsson.

This file is part of GCC.

GCC is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.

GCC is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with GCC; see the file COPYING.  If not, write to
the Free Software Foundation, 51 Franklin Street, Fifth Floor,
Boston, MA 02110-1301, USA.  */

/* After the first "Node:" comment comes all preprocessor directives and
   attached declarations described in the info files, the "Using and
   Porting GCC" manual (uapgcc), in the same order as found in the "Target
   macros" section in the gcc-2.9x CVS edition of 2000-03-17.  FIXME: Not
   really, but needs an update anyway.

   There is no generic copy-of-uapgcc comment, you'll have to see uapgcc
   for that.  If applicable, there is a FALCON-specific comment.  The order
   of macro definitions follow the order in the manual.  Every section in
   the manual (node in the info pages) has an introductory `Node:
   ' comment.  If no macros are defined for a section, only
   the section-comment is present.  */

/* Note that other header files (e.g. config/elfos.h, config/linux.h,
   config/falcon/linux.h and config/falcon/aout.h) are responsible for lots of
   settings not repeated below.  This file contains general FALCON
   definitions and definitions for the falcon-*-elf subtarget.  */

/* We don't want to use gcc_assert for everything, as that can be
   compiled out.  */
#define FALCON_ASSERT(x) \
 do { if (!(x)) internal_error ("FALCON-port assertion failed: " #x); } while 
(0)

/* Last register in main register bank r0..r15.  */
#define FALCON_LAST_GENERAL_REGISTER 15

/* Descriptions of registers used for arguments.  */
/* Note: r15 has a special use in the prologue/epiloque
 *   of vararg functions (an additional temp),
 *   so do not add it to the parameter registers.
 */
#define FALCON_FIRST_ARG_REG 10
#define FALCON_MAX_ARGS_IN_REGS   5
#define FALCON_MAX_ARGS_IN_REGSM1 (FALCON_MAX_ARGS_IN_REGS-1)

#define FALCON_FUNCTION_ARG_SIZE(MODE, TYPE)\
  ((MODE) != BLKmode ? GET_MODE_SIZE (MODE) \
   : (unsigned) int_size_in_bytes (TYPE))

/* Changing the order used to be necessary to put the fourth __make_dp
   argument (a DImode parameter) in registers, to fit with the libfunc
   parameter passing scheme used for intrinsic functions.  FIXME: Check
   performance and maybe remove definition from TARGET_LIBGCC2_CFLAGS now
   that it isn't strictly necessary.  We used to do this through
   TARGET_LIBGCC2_CFLAGS, but that became increasingly difficult as the
   parenthesis (that needed quoting) travels through several layers of
   make and shell invocations.  */
#ifdef IN_LIBGCC2
#define __make_dp(a,b,c,d) __falcon_make_dp(d,a,b,c)
#endif


/* Node: Driver */

/* When using make with defaults.mak for Sun this will handily remove
   any "-target sun*" switches.  */
/* We need to override any previous definitions (linux.h) */
#undef WORD_SWITCH_TAKES_ARG
#define WORD_SWITCH_TAKES_ARG(STR) \
 (DEFAULT_WORD_SWITCH_TAKES_ARG (STR))

/* Also provide canonical vN definitions when user specifies an alias.*/

#define CPP_SPEC "%(cpp_subtarget)"

/* For the falcon-*-elf subtarget.  */
#define FALCON_CPP_SUBTARGET_SPEC ""

/* Remove those Sun-make "target" switches.  */
/* Override previous definition

Re: [LTO] Flattening memory expressions?

[Michael Matz]

Hi,

On Thu, 8 Jun 2006, Daniel Berlin wrote:

> >> Thoughts?
> > 
> > We (me and Matz) thought over this as well and concluded it would be
> > nice to have
> > 
> >  - MEM_REF ( base, offset, alias_tag )
> > 
> > with base being either some memory object or an INDIRECT_REF of a
> > pointer and be done with that tree code.
> 
> So if you have MEM_REF(INDIRECT_REF(a),i,0), you really haven't done any
> better in removing recursion :)

What type the first operand would be could be a one-bit flag in the 
MEM_REF itself.  I.e. if there's an implicit INDIRECT_REF around the 
first operand, or not.  The important part is only that the target address 
of that memory reference is computable completely trivially, namely by A + 
i, where A is either a or &a depending on that flag.  And the more 
important thing anyway is that alias information of this specific mem 
reference encoded therein.

> > The MEM_REF would also contain an alias tag for easy oracle queries
> 
> Tag has some meaning in our current structure. I'd support some sort of
> generic token that associates the alias info with it, however.

All a matter of naming, sure :-)


Ciao,
Michael.

Re: SVN branch for current Boehm's GC + GCC code?

[Daniel Berlin]

Laurynas Biveinis wrote:
> Hi,
> 
> One of the SoC requirements is to have public development. So I should
> I create a branch of my current Boehm's GC experiments and commit my
> code there? 

Sure, if you like (you have a copyright assignment and are write after
approval, so you can create branches).

Otherwise, we'll just publish it some other way.

I'm not sure, because there exists a posibility that this
> branch will be thrown away,

This is not a worry, branches get thrown away all the time :)

 if we don't go the Boehm's GC route. And
> the current code is very experimental and will have to be mostly
> rewritten if we do go this route...

This is also not a significant worry, we can always create a second
branch if necessary.


> 
> (I will not read email for a few days as I will be offline till Monday)

Re: [LTO] Flattening memory expressions?

[Richard Henderson]

On Thu, Jun 08, 2006 at 12:13:50PM -0400, Diego Novillo wrote:
> However, as Kenny pointed out today, it may be useful for us to
> completely simplify these expressions to remove their recursive
> structure.  Something like:
> 
> ARRAY_REF : ID [ VAL ]
> 
> COMPONENT_REF : ID . ID
> | INDIRECT_REF . ID
> 
> INDIRECT_REF : * ID
> 
> We would probably need INDIRECT_REFs in COMPONENT_REF nodes to avoid
> lots of memory copying.

As folks have pointed out down-thread wrt multi-dimensional arrays,
I think this is a rather poor idea.  Both for components and arrays.

> The rationale is that by removing the recursiveness of these
> expressions, it would make it easier to emit the LTO bytecodes without
> resorting to a stack machine.

There are other options for this besides stack machine.


r~

Re: [LTO] Flattening memory expressions?

[Diego Novillo]

Richard Henderson wrote on 06/08/06 16:36:

> As folks have pointed out down-thread wrt multi-dimensional arrays,
> I think this is a rather poor idea.  Both for components and arrays.
> 
Yeah, multi-dimensional arrays are a problem.  I'm not sure I see the
flattening of components as a problem.  Because we would need to take
the address of inner fields?

> There are other options for this besides stack machine.
> 
Cool.  What would those be?

Re: Modifying ARM code generator for elimination of 8bit writes - need help

[Wolfgang Mües]

Rask,

On Thursday 08 June 2006 20:12, Rask Ingemann Lambertsen wrote:

> Also, undo the change to arm_legitimate_address_p() arm.c.

Hmmm

> arm-elf-gcc -g -mswp-byte-writes -Wall -O2 -fomit-frame-pointer
> -ffast-math -mthumb-interwork -isystem
> /usr/lib/devkitpro/libnds/include -mcpu=arm9tdmi -mtune=arm9tdmi
> -DARM9 -S arm9_main.c -o arm9_main.S arm9_main.c: In function 'test':
> arm9_main.c:20: error: unable to generate reloads for:
> (insn:HI 20 21 22 1 arm9_main.c:16 (set (mem/v:QI (post_inc:SI
> (reg/v/f:SI 3 r3 [orig:102 p ] [102])) [0 S1 A8]) (subreg/s/u:QI
> (reg:SI 2 r2 [orig:103 c.36 ] [103]) 0)) 157 {*arm_movqi_insn_swp}
> (nil) (expr_list:REG_INC (reg/v/f:SI 3 r3 [orig:102 p ] [102])
> (nil)))
> arm9_main.c:20: internal compiler error: in find_reloads, at
> reload.c:3720

void test(void)
{
static unsigned char c = 20;
volatile unsigned char * p;
int i;

p = (volatile unsigned char *) 0x0800;
for (i = 0; i < 1000; i++)
*p++ = c;

c = 40;
c = c;
}

Without the change in arm_legitimate_address_p, we get post increment 
pointer into swpb. The non-working 'Q' constraint

regards
Wolfgang
-- 
We're back to the times when men were men 
and wrote their own device drivers.

(Linus Torvalds)

Re: Problem with address reloading

[Jim Wilson]

Juul Vanderspek wrote:

In order to enable indexed loads, I extended
GO_IF_LEGITIMATE_ADDRESS to also match indexed
addresses, added a memory constraint 'R' to match
nonindexed addresses, and used R for stores in the
'mov' rule (see below).


This may be easier if you do it the other way.  I.e. remove indexed 
addresses from GO_IF_LEGITIMATE_ADDRESS, add an 'R' constraint that only 
matches indexed addresses, and then use "mR" for load memory operands, 
and "m" for store memory operands.  With a proper predicate for 
input_operands that accepts memory_operand plus indexed addresses, 
combine can create the indexed loads.


It should be possible to make your approach work.  First thing is that 
you have to fix the predicate.  You can't use nonimmediate_operand here, 
as this will accept invalid indexed addresses.  Define your own 
output_operand predicate that rejects indexed addresses.  It is always 
better to reject an operand than to rely on reload to fix it.  You 
probably also need a mov* expander that fixes a store indexed address if 
one is passed in, since it is a bad idea for the mov* patterns to fail.


Another problem here is that reload knows how to fix simple things like 
'm' and 'r' operands, but it doesn't know how to fix an 'R' operand. 
This means you either have to be careful to only accept operands that 
will never be reloading, or add code to reload it yourself, or add hints 
to help reload.  The last one is the easiest option, see the 
EXTRA_MEMORY_CONSTRAINT documentation.  If you define this, then reload 
will know that it can always fix an 'R' by reloading the address into a 
register.

--
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: TLS on windows (was: Re: Gfortran on Windows (mingw32) with OpenMP)

[Richard Henderson]

On Sun, Jun 04, 2006 at 02:03:05PM +0200, Piotr Wyderski wrote:
> fs:[0x14] is a per-thread 32-bit word available for applications,
> so you can store a pointer to your own TLS array there. 

I don't think we can hijack this.

> fs:[0x2c] points to a Windows-specific TLS array, so you can
> make use of it, too, but you must conform to the limitations of
> the WinAPI constraints related with TLS management.

Given that microsoft's openmp implementation is also limited
in this way, I don't think that's a real problem.

> >Now, for an idea of how much work it represents... perhaps someone  
> >here can tell us?

The biggest piece of work is in the linker, noticing the
existance of the .tls section and setting up the IMAGE_TLS_DIRECTORY
structure, and related activities.  There's a value I'll name
"tls_handle" that is created as part of this; ideally that would
use whatever name vc++ does in its object files.  There's also
arranging for tls symbol references to resolve to the offset of
the symbol in the .tls section, rather than some sort of absolute
address.

On the compiler side, you'd need to replace legitimize_tls_address
with a windows implementation.  You'd need some new patterns, since
you'll be wanting to generate something akin to

movl  %fs:0x2c, %eax// global array base
movl  tls_handle, %edx  // value from TlsAlloc
movl  (%eax, %edx, 4), %eax // local array base

addl  $variable, %eax   // compute address

movl  variable(%eax), %ecx  // when loading/storing a value


r~

Re: TLS on windows

[Richard Henderson]

On Sun, Jun 04, 2006 at 07:05:55AM -0400, Ross Ridge wrote:
> FX Coudert wrote:
> > Now, for an idea of how much work it represents... perhaps someone
> >here can tell us?
> 
> It's not too hard but it requires changing GCC and binutils, plus a
> bit of library support.  In my implementation (more or less finished,
> but I have had time to test it yet), I did the following:
> 
>   - Used the existing __thread support in the front-end.  Silently
> ignore the ELF TLS models, because Windows only has one model.
>   - Added target specific (cygming) support for __attribute__((thread))
> aka __declspec(thread) for MSC compatibility.
>   - Created an legitimize_win32_tls_address() to replace
> legitimize_tls_address() in i386.c.  It outputs RTL like:
>   (set (reg:SI tp) (mem:SI (unspec [(const_int 44)] WIN32_TIB)))
>   (set (reg:SI index) (mem:SI (symbol_ref:SI "__tls_index__")))
>   (set (reg:SI base) (mem:SI (add:SI (reg:SI tp)
>  (mult:SI (reg:SI index)
>   (const_int 4)
>   (plus:SI (reg:SI base)
>(const:SI (unspec:SI [(symbol_ref:SI "foo")]
> SECREL
>   - Handled the WIN32_TIB unspec by outputting "%fs:44" and the
> SECREL unspec by outputting "foo`SECREL".  I couldn't use
> "[EMAIL PROTECTED]" because "@" is valid in identifiers with PECOFF.
>   - Support .tls sections in PECOFF by creating an
> i386_pe_select_section() based on the generic ELF version.
>   - Added an -mfiber-safe-tls target specific option that makes
> the references to the WIN32 TIB non-constant.
>   - Modified gas to handle "foo`SECREL", based on the ELF support
> for "@" relocations
>   - Fixed some problems with TLS handling in the PECOFF linker
> script
>   - Created an object file that defines the __tls_used structure
> (and thus the TLS directory entry) and __tls_index__.

Excellent.  Pretty much exactly what I had in mind.

> Actually, the last one I haven't done yet.  I've just been using a linker
> script to do that, but it should be in a library so the TLS directory
> entry isn't created if the executable doesn't use TLS.

You can also create this in the linker, without a library.
Not too difficult, since you've got to do that to set the
bit in the PE header anyway.


r~

Re: PR 26792

[Geoffrey Keating]

On 08/06/2006, at 7:48 AM, Jack Howarth wrote:


Geoff,
I noticed PR 26792 last night. After reading that it became  
clear what
was causing the massive c++ regressions when I built gcc trunk  
under fink.

Fink sets MACOSX_DEPLOYMENT_TARGET to 10.4 when a package is built in
fink 10.4 branch. They also were applying the rejected patch from...

http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02041.html

to their gcc4 builds as well. That explains why the c++ regressions
suddenly appeared when I stopped applying their gcc4.patch (which
contains that and other changes for building on MacIntel).
The good news is that when I build gcc trunk under fink with
MACOSX_DEPLOYMENT_TARGET unset, the massive c++ regressions now
disappear. The bad news is that the resulting gcc, when used to
build xplor-nih, still results in the c++ regression in the xplor-nih
testsuite which I reported several weeks ago. Did the information
I reported give you any hints as to where the problem might be?

http://gcc.gnu.org/ml/gcc/2006-06/msg00043.html

Let me know if there is anything I can do to try to pin down
this remaining libgcc issue (which appears to be unrelated to
PR 26792).


I don't believe it's a libgcc issue.  I think it's something that's  
happening at link (probably) or load time that just happens to  
involve libgcc.  You may be encountering


 a strong symbol in a dylib should not  
override a weak private extern symbol


or perhaps some not yet known problem.



smime.p7s
Description: S/MIME cryptographic signature

RE: x86 Linux stack alignment requirement

[Menezes, Evandro]

> > I see.  Provided a local is passed in a register to a 
> non-vararg function, it is still OK to align the stack.
> 
> Given that we don't support 4 byte aligned stack at all with XMM
> regisrers, I would prefer to increase Linux/x86 stack alignment to
> 16 byte. People can use 4 byte alignment if they want. As for the
> existing 4 byte aligned code, -mstackrealign can be used to support
> them.

It would still be possible for the function to align its stack to 16 bytes, 
even though it can only assume it to be aligned at 4 bytes upon entry, if it 
needs it.  Much like -mstackrealign, but paying its cost only in functions that 
will benefit from it.

-- 
___
Evandro Menezes   AMDAustin, TX

gcc-4.0-20060608 is now available

[gccadmin]

Snapshot gcc-4.0-20060608 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060608/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

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

You'll find:

gcc-4.0-20060608.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.0-20060608.tar.bz2 C front end and core compiler

gcc-ada-4.0-20060608.tar.bz2  Ada front end and runtime

gcc-fortran-4.0-20060608.tar.bz2  Fortran front end and runtime

gcc-g++-4.0-20060608.tar.bz2  C++ front end and runtime

gcc-java-4.0-20060608.tar.bz2 Java front end and runtime

gcc-objc-4.0-20060608.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.0-20060608.tar.bz2The GCC testsuite

Diffs from 4.0-20060601 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.0
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Wconversion versus Wcoercion

[Manuel López-Ibáñez]

Hi all,

Short version:

I have to choose between:

(a) keep Wconversion only for warnings about prototypes causing a type
conversion different from what would happen to the same argument in
the absence of a prototype, which was its original purpose, and move
everything else to a new option (Wcoercion).

(b)  keep the warnings of conversions that may change a value in
Wconversion and move its original purpose (the warnings about
prototypes causing ... in the absence of a prototype) to a new option
(suggestions are welcome).

Long version:

As my SoC project, I am developing a new warning Wcoercion [1] that
should warn about risky type conversions, that is, conversions that
may change a value. One of the goals is to cleanup Wconversion[2].

The original purpose of Wconversion was to warn if a prototype causes
a type conversion that is different from what would happen to the same
argument in the absence of a prototype [3]. In addition, currently it
has a second feature: "warn if a negative integer constant expression
is implicitly converted to an unsigned type". Just for this latter
feature, many developers use Wconversion getting annoyed with the
results [4]. Thus, Wcoercion will takeover the second feature of
Wconversion, and leave Wconversion for its original purpose (or for a
future change of name, incorporation into another warning or simply
removal from gcc).

Nonetheless, Wconversion actually warns about many more situations
than those described in the manual page [5]. Therefore, it may be too
disruptive to take this functionality away from Wconversion since I
guess that nowadays most of the programs use Wconversion to warn for
"risky conversions" rather than for its original purpose (the
prototype thing). On the other hand, this is undocumented behaviour
and the typical answer to people using Wconversion to warn for "risky
conversions" is that this is not its intended use [3][4] (you can find
more examples in my project proposal [6]).

Conclusion:

Then, which functionality do you want to keep in Wconversion? option
(a) or option (b) ?

I personally don't have a strong opinion on the matter. Although
option (b) will force me to rename my project [1], which is sad since
I think the name was cool. But, hey! don't take that into account! I
will show some adaptability!

Regards,

Manuel.

[1] http://gcc.gnu.org/wiki/Wcoercion

[2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9072

[3] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6614#c5

[4] http://www.gnu.org/software/libc/FAQ.html#s-3.17

[5] Just a few:
trunk/gcc/cp/decl.c:9153:  warning (OPT_Wconversion, "conversion to
%s%s will never use a type "
trunk/gcc/cp/call.c:4230:  warning (OPT_Wconversion, "converting to
non-pointer type %qT from NULL", t);
trunk/gcc/cp/call.c:6129:  warning (OPT_Wconversion, "choosing %qD
over %qD", w->fn, l->fn);
trunk/gcc/cp/cvt.c:1063:  warning (OPT_Wconversion, "converting NULL
to non-pointer type");

[6] http://code.google.com/soc/gcc/appinfo.html?csaid=AE474DACA8C07440

Re: TLS on windows

[Ross Ridge]

Ross Ridge wrote:
> Actually, the last one I haven't done yet.  I've just been using a linker
> script to do that, but it should be in a library so the TLS directory
> entry isn't created if the executable doesn't use TLS.

Richard Henderson wrote:
> You can also create this in the linker, without a library.
> Not too difficult, since you've got to do that to set the
> bit in the PE header anyway.

Fortunately, the linker already supports setting the TLS directory entry
in the PE header if a symbol named "__tls_used" exists.  Section relative
relocations are also already supported (for DWARF, I think), I just
needed to add the syntax to gas.

Ross Ridge

Re: x86 Linux stack alignment requirement

[H. J. Lu]

On Thu, Jun 08, 2006 at 05:25:32PM -0500, Menezes, Evandro wrote:
> > > I see.  Provided a local is passed in a register to a 
> > non-vararg function, it is still OK to align the stack.
> > 
> > Given that we don't support 4 byte aligned stack at all with XMM
> > regisrers, I would prefer to increase Linux/x86 stack alignment to
> > 16 byte. People can use 4 byte alignment if they want. As for the
> > existing 4 byte aligned code, -mstackrealign can be used to support
> > them.
> 
> It would still be possible for the function to align its stack to 16 bytes, 
> even though it can only assume it to be aligned at 4 bytes upon entry, if it 
> needs it.  Much like -mstackrealign, but paying its cost only in functions 
> that will benefit from it.
> 

That is what icc does. It will be very nice if gcc can do that.


H.J.

Help with following RTL

[kernel coder]

hi,
Following is a c code .

int a;
main()
{
a=a+1;
}

This RTL generated for this programe for mips processor is

/***/
; Function main

(note 2 0 3 NOTE_INSN_DELETED)

(note 3 2 4 NOTE_INSN_FUNCTION_BEG)

(note 4 3 5 NOTE_INSN_DELETED)

(note 5 4 6 NOTE_INSN_DELETED)

(note 6 5 8 NOTE_INSN_DELETED)

(insn 8 6 9 (nil) (set (reg:SI 182)
  (mem/f:SI (symbol_ref:SI ("a")) [0 a+0 S4 A32])) -1 (nil)
  (nil))

(insn 9 8 10 (nil) (set (reg:SI 183)
  (plus:SI (reg:SI 182)
  (const_int 1 [0x1]))) -1 (nil)
  (nil))

(insn 10 9 11 (nil) (set (mem/f:SI (symbol_ref:SI ("a")) [0 a+0 S4 A32])
  (reg:SI 183)) -1 (nil)
  (nil))

(note 11 10 15 NOTE_INSN_FUNCTION_END)

(insn 15 11 16 (nil) (clobber (reg/i:SI 2 v0)) -1 (nil)
  (nil))

(insn 16 15 13 (nil) (clobber (reg:SI 181)) -1 (nil)
  (nil))

(code_label 13 16 14 1 "" [0 uses])

(insn 14 13 17 (nil) (set (reg/i:SI 2 v0)
  (reg:SI 181)) -1 (nil)
 (nil))

(insn 17 14 0 (nil) (use (reg/i:SI 2 v0)) -1 (nil)
  (nil))

/*/

I'm a newbie in RTL,so please explain what is happening in lines after
(note 11 10 15 NOTE_INSN_FUNCTION_END)


/**/
(insn 15 11 16 (nil) (clobber (reg/i:SI 2 v0)) -1 (nil)
  (nil))

(insn 16 15 13 (nil) (clobber (reg:SI 181)) -1 (nil)
  (nil))

(code_label 13 16 14 1 "" [0 uses])

(insn 14 13 17 (nil) (set (reg/i:SI 2 v0)
  (reg:SI 181)) -1 (nil)
 (nil))

(insn 17 14 0 (nil) (use (reg/i:SI 2 v0)) -1 (nil)
  (nil))
/***/


thanks,
shahzad

Re: Help with following RTL

[Ian Lance Taylor]

"kernel coder" <[EMAIL PROTECTED]> writes:

This is all just boilerplate which is put at the end of every function
during RTL expansion.

> (insn 15 11 16 (nil) (clobber (reg/i:SI 2 v0)) -1 (nil)
>(nil))

Clobber the hard return register.

> (insn 16 15 13 (nil) (clobber (reg:SI 181)) -1 (nil)
>(nil))

Clobber the pseudo register which was created to hold the return
value.

> (code_label 13 16 14 1 "" [0 uses])

Label to branch to after the pseudo-register return value is set
earlier in the code (in your function this label is not used).

> (insn 14 13 17 (nil) (set (reg/i:SI 2 v0)
>(reg:SI 181)) -1 (nil)
>   (nil))

Set the hard return register to the pseudo-register return value.

> (insn 17 14 0 (nil) (use (reg/i:SI 2 v0)) -1 (nil)
>(nil))

Note that the hard return register is used at the end of the function.

Ian