headers
Phil Edwards | 1 Jan 2004 01:19

Re: Request for help performing CVS branch trick

On Wed, Dec 31, 2003 at 05:57:26PM -0500, Nathanael Nerode wrote:
> I have a branch on which I did some work.  I want to abandon that work and
> rebranch from mainline, starting over with a new set of work.  But I don't
> want to have to bother to change the branch name.  :-)
> 
> Is this possible or reasonable?  If so, how?

Delete the branch and then rebranch from the same branchpoint, perhaps.

--

-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
    - Brian W. Kernighan
Permalink | Reply | 0 comments |
headers
Alex Rosenberg | 1 Jan 2004 03:34

Re: Altivec discussion summary, future direction

On Dec 31, 2003, at 2:33 PM, Zack Weinberg wrote:

> Aldy Hernandez <aldyh <at> redhat.com> writes:
>
>> WRT the comma initializer discussion, it was my understanding that 
>> Motorola
>> had added the curly brace initializer to the PIM, in addition to the
>> brain dead comma initializer scheme-- and that other compiler vendors
>> were moving towards the curly brace implementation.
>
> This was also my understanding.

Can somebody please point to this changed PIM?

I've seen nothing of the kind.

+------------------------------------------------------------+
| Alexander M. Rosenberg           <mailto:alexr <at> _spies.com> |
| Nobody cares what I say. Remove the underscore to mail me. |
Permalink | Reply | 2 comments |
headers
Hans-Peter Nilsson | 1 Jan 2004 04:30

Re: trouble with porting architecture

On Tue, 30 Dec 2003 tm_gccmail <at> kloo.net wrote:
> "Page zero" is an implementation artifact on the 6502 and derivatives
> where addresses in the first 256 bytes can be accessed via a two-byte
> instruction rather than a three-byte instruction.
>
> This feature is specific to the 6502 and is not a generally supported
> feature on 8-bit processors.
>
> So using "page zero" only has an advantage on the 6502.

The 6809 *does* have a similar short addressing mode ("direct";
saving a whole byte) *and* the implied high byte "page" is a
settable register (DP); not necessarily zero, that is.

Not that short addressing modes are necessary for "faking"
registers, still facts are facts...

brgds, H-P
PS.  Wow, so many google hits for "6809 reference card"!
Permalink | Reply | 0 comments |
headers
harpreet singh | 1 Jan 2004 09:20
Picon
Favicon

download of c compiler for Sun Solaris 8 O/S

Dear Sir/Madam,
I want to download the C compiler so that i can use C
language on Sun Solaris 8 O/S.
Please guide me in this respect.
Harpreet Singh

__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
Permalink | Reply | 1 comment |
headers
Joseph S. Myers | 1 Jan 2004 12:24
Picon

malloc attributes and realloc

Can __attribute__((__malloc__)) safely be used on realloc-type functions?  
glibc's <stdlib.h> has

extern void *realloc (void *__ptr, size_t __size) __THROW __attribute_malloc__;

while libiberty.h has

/* Reallocate memory without fail.  This works like xmalloc.  Note,
   realloc type functions are not suitable for attribute malloc since
   they may return the same address across multiple calls. */

extern PTR xrealloc PARAMS ((PTR, size_t));

- which is correct?  (Although the same value can be returned by realloc,
the program can't compare the values as values without undefined behavior,
only as bit patterns - and using them as bit patterns (a) involves taking
the address of one of the pointers involved (possibly inhibiting
optimization that way), (b) gets into the territory of DR#260.)

--

-- 
Joseph S. Myers
jsm <at> polyomino.org.uk
Permalink | Reply | 20 comments |
headers
J. Grant | 1 Jan 2004 14:06

Determine the target of a build in gcc

Hello,

Is it possible to determine the target of a build when compiling with gcc?
Perhaps it is possible to see something like the target architecture? I
was interested in doing some different code within a pre-processor #if
style construct.

Kind regards

JG
Permalink | Reply | 1 comment |
headers
Dorit Naishlos | 1 Jan 2004 15:20
Picon
Favicon

Re: [tree-ssa] vdefs question (to make vectorizer pass verify ssa)


> As it should.  You have seemingly removed all references to variable
> 'a', but have not marked it for renaming.  In the current scheme, we do
> not manipulate virtual operands directly.  These are added/removed by
> get_stmt_operands when a statement is marked modified.
>
> Question: is your transformation removing *all* references to variable
> 'a'?  If so, then all you need to do is mark 'a' for renaming and call
> rewrite_into_ssa, which will DTRT.
>
> If 'a' is still referenced somewhere in the code, then you ought to add
> 'a' to the may-alias set for the memory tag of _vect_a.117 (I assume it
> has one, right?).

I managed to pass verify_ssa doing the following:

- when creating a pointer T0 in the vectorizer:

    T0 = create_tmp_var (ptr_type, new_name);
    add_referenced_tmp_var (T0);
#if 0
->  if (STMT_VINFO_TYPE (stmt_info) == store_vec_info_type)
->    var_ann (T0)->is_dereferenced_store = 1;
->  else if (STMT_VINFO_TYPE (stmt_info) == load_vec_info_type)
->    var_ann (T0)->is_dereferenced_load = 1;
#endif
*   bitmap_set_bit (vars_to_rename, var_ann (array_base)->uid);

- in tree-optimize.c:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel Berlin | 1 Jan 2004 15:46

Re: [tree-ssa] vdefs question (to make vectorizer pass verify ssa)

>
> The lines marked with '*' are the new source lines I added that solved 
> the
> problem and allowed the vectorized code to pass the verifiers.
>
> The lines marked with '->' are not required in order to successfully 
> pass
> verify_ssa, but update the may-aliases and result in vector 
> loads/stores
> that have vdefs/vuses. However, I did not find an API exposed out side 
> of
> tree-dfa.c that lets you create new mem-tags and compute may-aliases on
> demand; so for now I called compute_may_aliases(), which resulted in 
> over
> conservative vdefs/vuses - the pointers I created ended-up aliasing 
> all the
> arrays in the function,

Yeah, you'd need to enable flag_tree_points_to = PTA_ANDERSEN to get 
better results (because TBAA is type based, obviously).

> whereas if I could explicitely set their may-alias
> set in the vectorizer I would make each pointer alias only the array it
> points to. Is there an API that lets you do that?

You'll probably have to expose parts of the aliasing API in order to do 
this, since it's all internal ATM.
If they all share the same aliasing properties, you only need to create 
a memory tag and set the variables to use that memory tag.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Sturm | 1 Jan 2004 16:31

Re: malloc attributes and realloc

On Thu, 1 Jan 2004, Joseph S. Myers wrote:
> Can __attribute__((__malloc__)) safely be used on realloc-type functions?

My non-expert understanding is "no"...

> /* Reallocate memory without fail.  This works like xmalloc.  Note,
>    realloc type functions are not suitable for attribute malloc since
>    they may return the same address across multiple calls. */

This comment is misleading.  The pointer address returned by a malloc-type
function isn't significant to alias analysis.  What *is* significant is
that malloc returns memory initialized with zeros, so that it cannot
alias anything.  (Moreover, malloc itself can return the same address
twice if a call to free intervenes between calls to malloc.)

Since the return value of realloc() aliases whatever its first argument
aliases, a literal reading of the documentation of the malloc attribute
indicates that it is inappropriate for the declaration of realloc.

Jeff
Permalink | Reply | 18 comments |
headers
Ian Lance Taylor | 1 Jan 2004 16:38

Re: malloc attributes and realloc

Jeff Sturm <jsturm <at> one-point.com> writes:

> What *is* significant is
> that malloc returns memory initialized with zeros, so that it cannot
> alias anything.

That's not true, though.  malloc() returns an uninitialized block of
memory.

The return value of malloc() can not alias any valid pointer.

If realloc() returns non-NULL, then the return value can not alias any
valid pointer, because it is no longer valid to use the pointer which
was passed to it (if realloc() returns NULL, on the other hand, then
it is still valid to use the pointer which was passed to it).  So I
think it is OK to give realloc() __attribute__((malloc)).

Ian
Permalink | Reply | 1 comment |

Gmane