Za 24 sata mozete imati svoju Internet prezentaciju

[vasweb]

Za 24 sata mozete imati svoju Internet prezentaciju 
 
po PROMOTIVNOJ CENI OD 
 
4499 DINARA 
 
Placanje u DVE (2) mesecne rate! 
 
Zasto Vam je potrebna Internet prezentacija? 
 
1. Da bi ste bili ispred konkurencije !!! 
2. Svi mogu videti Vas Internet IZLOG !!! 
3. SVI vAS MOGU BRZO I LAKO NACI !!! 
4. Jeftinije je i efikasnija od bilo kog drugog marketinga !!! 
 
 
Sta dobijate: 
 
 
1. Registracija 1 internacionalnog domena na 1 godinu (com, net, org, info, 
biz)  
 
2. 250 MB Hosting memorijskog prostora 
 
3. NEOGRANICEN protok  
 
4. Dizajn Internet prezentacije je na Srpskom jeziku sa sledecim podstranama:  
 
4.1. Naslovna - prva strana (Home Page) 
4.2. Proizvodi i usluge 
4.3. O nama 
4.4. Kontakt 
4.5. Mapa 
 
5. Graficko i Web stilizovanje Vasih fotografija (maksimalno 20 fotografija). 
 
6. do 10 e-mail adresa 
 
7. Podrska 24 sata dnevno! 
 
8. 10 CD-ova sa Vasom Internet prezentacijom na CD-u (CD Vizit karta) 
 
 
 
Za sve informacije mozete nas u svako doba dana pozvati na: 
 
062-543-818 
  
Detaljne informacije na: http://vasweb.blogspot.com/

Re: GCC 4.3.0 Status Report (2007-08-09)

[Joern Rennecke]

We have a lot of patches to the ARC port, but I suppose that would not really
be a problem for phase three, as the current arc port in the gcc mainline
is not really useful for end users - it doesn't support any of the cores
that have been released in recent years.

Some patches belong logically to the arc port, but are in common files, so
they have to go in sufficiently early before the release freeze to allow
to verify that no other configurations are affected by typos etc; these files
are:
config-ml.in config.gcc doc/invoke.texi

There remain two issues that require patches to the common code.
Our Copyright Assignment is still not sorted out, so I will refer here
to patches only by Changelog entry, without posting any actual code.

There is an issue with precompiled headers that shows up specifically with the
arc configuration.  Some GTY data structures point to malloced strings in the
arc port.

2007-05-14  J"orn Rennecke  <[EMAIL PROTECTED]>

Make section xmalloced:
* c-pch.c (c_common_write_pch): Call pickle_in_section and
unpickle_in_section.
(c_common_read_pch): Call unpickle_in_section.
* varasm.c (unnamed_sections): Remove GTY marker.
(get_unnamed_section, get_noswitch_section): xmalloc section.
(pickled_in_section): New static variable.
(pickle_in_section, unpickle_in_section): New functions.
* output.h (struct unnamed_section): Mark as GTY((skip)).
(union section): Mark members unnamed_section and noswitch_section
as GTY((skip)).
(text_section, data_section, readonly_data_section): Remove GTY marker.
(sdata_section, ctors_section, dtors_section, bss_section): Likewise.
(sbss_section, tls_comm_section, comm_section): Likewise.
(lcomm_section, bss_noswitch_section, in_section): Likewise.
(pickle_in_section, unpickle_in_section): Declare.

The following patch should be reworked to avoid code duplication, which will
likely require patches to the frontend and middle-end:

2007-05-29  J"orn Rennecke  <[EMAIL PROTECTED]>

* config/arc/arc.c (arc_decl_anon_ns_mem_p): New function, copied from
cp/tree.c .
(arc_in_small_data_p): Use default_binds_local_p_1 and
arc_decl_anon_ns_mem_p to determine if a symbol binds locally.

Re: reload question

[Pat Haugen]

Ian Lance Taylor <[EMAIL PROTECTED]> wrote on 08/10/2007 07:17:21 PM:
>
> I'm not entirely clear: how do you propose changing the code?
>

I was thinking of reordering the if tests such that we check if op0 is
already ok_for_base or op1 is ok_for_index before we check the inverse
conditions (which result in swapping the classes of the operands). I would
also change the default else leg such that it keeps op0 as the base reg and
op1 as an index reg.


Example diff (not tested)

(See attached file: reload.diff)



reload.diff
Description: Binary data

Re: RFC: Simplify rules for ctz/clz patterns and RTL

[Joern Rennecke]

> The score, sh and sparc instructions may or may not display canonical
> behavior; their ports do not define CLZ_DEFINED_VALUE_AT_ZERO and I was
> not able to find documentation of the relevant instruction.

The operation the nsb instruction of the SHmedia instruction set performs
is 'count number of sign bit copies'.

For the 32 bit ffs, first a mask for the least significant bit is computed.
Thus, the upper 32 bit of the 64 bit registers are all zero, so we merely
have to subtract the result of nsb from 63.
So this is more or less what you describe as canonical behaviour.

For the 64 bit ffs, the input is shifted right by one to obtain an unsigned
value.  This has the effect that the value obtained for zero input is the
same as the one for one input, which is compensated for with a conditional
move.  In this sense, for 64 bit operation you have 'non-canonical'
behaviour.

The ARC700 has a NORM instruction, which again counts the number of
sign bit copies.  There is a variant NORM.F which sets the N flag if the
input is negative.

Thus,
  __asm__ ("norm.f\t%0,%1\n\tmov.mi\t%0,-1" : "=r" (c_) : "r" (x) : "cc");
performs a 'canonical' count leading zeros operation, except that you have
to add one to the result.

Re: When does this page update ?

[Janis Johnson]

On Sun, 2007-08-12 at 17:55 -0400, Dennis Clarke wrote:
> http://gcc.gnu.org/gcc-4.2/buildstat.html
> 
> It seems stuck at 4.2.0 only.
> 
> If I search around I cna find reports from Joe Buck that seem to help my
> work but there is nothing linked on the build status page.

That would be my fault, I'll update it soon.

Janis

Re: When does this page update ?

[Dennis Clarke]

> On Sun, 2007-08-12 at 17:55 -0400, Dennis Clarke wrote:
>> http://gcc.gnu.org/gcc-4.2/buildstat.html
>>
>> It seems stuck at 4.2.0 only.
>>
>> If I search around I cna find reports from Joe Buck that seem to help my
>> work but there is nothing linked on the build status page.
>
> That would be my fault, I'll update it soon.

Thank you very much.  I use that page to check my testsuite results against
other people and thus far I can not find much for gcc 4.2.1 on solaris 8
sparc.

I'll watch for updates.

Dennis

Why does __tls_get_addr call require @PLT for global-dynamic without -fpic?

[H.J. Lu]

Is there a particular reason for x86 and x86-64 global-dynamic TLS
model to require @PLT when calling __tls_get_addr when PIC isn't
required? See

http://sources.redhat.com/bugzilla/show_bug.cgi?id=4918

Right now, gcc doesn't generate PLT when calling __tls_get_addr
without -fpic. Assert in x86/x86-64 linkers fail because of it.
The only thing I can think of is it is used to make sure that it is
a call instruction.  I may have missed something. If not, I'd like to
change it to check for R_X86_64_32/R_X86_64_PLT32 and call
__tls_get_addr explicitly.


H.J.

Re: reload question

[Ian Lance Taylor]

Pat Haugen <[EMAIL PROTECTED]> writes:

> I was thinking of reordering the if tests such that we check if op0 is
> already ok_for_base or op1 is ok_for_index before we check the inverse
> conditions (which result in swapping the classes of the operands). I would
> also change the default else leg such that it keeps op0 as the base reg and
> op1 as an index reg.

That patch would probably be fine.  Ideally you would do some
performance testing on a couple of primary platforms.

Ian

MPFR 2.3.0 Release Candidate 2

[Vincent Lefevre]

The release of MPFR 2.3.0 is still imminent. Thanks very much to
those who tested the first release candidate. As there have been
significant changes, a second release candidate is necessary. You
can download it here:

http://www.mpfr.org/mpfr-2.3.0/mpfr-2.3.0-rc2.tar.bz2
http://www.mpfr.org/mpfr-2.3.0/mpfr-2.3.0-rc2.tar.gz
http://www.mpfr.org/mpfr-2.3.0/mpfr-2.3.0-rc2.zip

The MD5's:
28df2b1d3bd0e0cb2fefdf3c5dede78e  mpfr-2.3.0-rc2.tar.bz2
39648dcd7160a3bda1ce581e0a0c8158  mpfr-2.3.0-rc2.tar.gz
991923b7a5223246ed9d6a59e1a7ff59  mpfr-2.3.0-rc2.zip

Changes from versions 2.2.* to version 2.3.0:
- The mpfr.info file is now installed in the share subdirectory
  (as required by the Filesystem Hierarchy Standard); see output
  of "./configure --help".
- The shared library is now enabled by default. If the MPFR build
  fails on your platform, try the --disable-shared configure option
  to disable the shared library.
- New functions mpfr_j0, mpfr_j1, mpfr_jn, mpfr_y0, mpfr_y1, mpfr_yn,
  mpfr_lgamma, mpfr_remainder, mpfr_remquo, mpfr_fms, mpfr_signbit,
  mpfr_setsign, mpfr_copysign, mpfr_get_patches.
- Functions mpfr_sin, mpfr_cos and mpfr_sin_cos improved (argument
  reduction).
- More detailed MPFR manual.
- Improved tests (make check).
- Bug fixes.

Please send success and failure reports to <[EMAIL PROTECTED]>.

If no problems are found, MPFR 2.3.0 should be released in about 3 weeks.

Detailed changes from the RC1 to the RC2:
- New function mpfr_get_patches, to track patches that will be applied.
- New functions mpfr_signbit, mpfr_setsign, mpfr_copysign. The
  mpfr_copysign function was already existing, but was not documented
  (thus regarded as internal, though declared in mpfr.h) and slightly
  incompatible with IEEE 754; it has been changed to be similar to
  the IEEE-754 (and ISO C99) copysign function.
- Bug fixes.

Internal changes from the RC1 to the RC2:
- Support for tests of fixed values in the tests/data directory. This
  directory is not included in the archives as it would make them much
  bigger (2 to 3 times as large, depending on what values one chooses
  to include). As a consequence, "make check" doesn't return an error
  if these test files are missing.
- Moved mpfr-test.h into the tests directory (to make testing old MPFR
  versions with new tests easier).
- The mpfr_get_str function computed some constants at run time and
  cached them. This led to various problems. These constants are now
  hardcoded into get_str.c (and checked with "make check").

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

Re: [CFG] what are class 3 edges ?

[Sunzir Deepur]

On 8/12/07, Dave Korn <[EMAIL PROTECTED]> wrote:
> On 11 August 2007 08:42, Emmanuel Fleury wrote:
> > Sunzir Deepur wrote:
> >> so why are those class 3 edges created at all ?
> > I didn't see any 3-edges blocks at all in your example.
>  Not 3-edge blocks; class 3 edges = the green lines.
>
>  They appear to be showing where the fall-through path /would have/ gone in
> those BBs which end with an unconditional jump if there had been no jump.
>
>  Edge class in the vcg output is determined by the 'class' arg passed by
> print_rtl_graph_with_bb to the draw_edge routine in graph.c.  The only place
> that generates class 3 edges is the catch-all if (!edge_printed) clause at the
> end of the for (tmp_rtx) loop.  The FOR_EACH_EDGE loop above will output all
> the 'real' edges that represent possible code flow paths, so it looks to me
> like gcc is using class 3 as a catch-all for things like EDGE_FAKE,
> EDGE_CROSSING, and any other of the kinds of edges (basic-block.h) that the
> compiler maintains for structural reasons that aren't real edges.
>
>  You'd have to ask someone other than me for the details of what kinds of
> things other than real edges the compiler stores edge structs for, but that's
> what ends up being drawn as class 3.

so do you think it's a safe bet to say that all class 3 edges do not represent
a possible flow of code ?

thank you
sunzir

Re: Sign extension by expr.c convert_move()

[Ian Lance Taylor]

Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes:

>In expr.c, convert_move() tries to synthesize sign extension in modes
> larger than those directly supported by the target. There are two strategies
> for generating the sign bit copies:
> 
> 1) Compare with 0 and use "slt" if STORE_FLAG_VALUE == -1.
> 2) Use a signed right shift of one bit less than the operand width.
> 
>   /* Compute the value to put in each remaining word.  */
>   if (unsignedp)
>   fill_value = const0_rtx;
>   else
>   {
> #ifdef HAVE_slt
> if (HAVE_slt
> && insn_data[(int) CODE_FOR_slt].operand[0].mode == word_mode
> && STORE_FLAG_VALUE == -1)
>   {
> emit_cmp_insn (lowfrom, const0_rtx, NE, NULL_RTX,
>lowpart_mode, 0);
> fill_value = gen_reg_rtx (word_mode);
> emit_insn (gen_slt (fill_value));
>   }
> else
> #endif
>   {
> fill_value
>   = expand_shift (RSHIFT_EXPR, lowpart_mode, lowfrom,
>   size_int (GET_MODE_BITSIZE (lowpart_mode) - 1),
>   NULL_RTX, 0);
> fill_value = convert_to_mode (word_mode, fill_value, 1);
>   }
>   }
> 
>My questions center around the first aproach:
> 
> 1) Shouldn't it check that the comparison is directly supported by the
> target rather than implemented by a library call?

The condition code handling in gcc is more complex than it needs to
be.  The way to generate an slt instruction is what you see above:
emit_cmp_insn followed by gen_slt.  The gen_slt needs to figure out
which operands to compare.  If you have a gen_slt which works in
word_mode, then the comparison instruction is presumed to exist.

There is probably a bug here when lowpart_mode != word_mode.  For most
targets that case can never arise, because there are not two different
sizes of signed integers both of which are larger than word_mode.

> 2) How does it handle failure of gen_slt?

It clearly doesn't.  That is a different bug.

Ian

Post constructor/Pre destructor hooks

[David Orchard]

Hi,

Some base classes (specifically thread base classes) would benefit from 
being able to execute a function after the object is constructed and before 
it is destructed. For a thread class the thread can't start until after the 
object is constructed and must stop before the object is destructed.

Does such a (probably non-standard) feature already exist or am I missing 
something.

   My idea was something like :-

#pragma hooks
class thread
{
private:
static void start_hook(thread*);
static void stop_hook(thread*);
};

a) There can be only one class in any class hierarchy with the 'hooks' 
property.

// The following class definition is illegal
#pragma hooks
class my_thread : public thread
{
};

This removes any ordering issues for multiple hooks since there can only be 
one set of hooks. All though the base class could implement a mechanism for 
derived classes to have hooks. But this is an application issue.

b) Any object with a 'hooks' class in its class hierarchy has '::start_hook(ptr);' inserted after its constructor is complete (stack 
or new) and '::stop_hook(ptr)' before its destructor (stack or 
delete). For example :

class runit : public thread
{
};

void fred()
{
runit a;
//thread::start_hook(&a);  <== Inserted by compiler
runit *b = new runit;
//thread::start_hook(b); <== Inserted by compiler
runit c[2];
//thread::start_hook(c+0); <== Inserted by compiler
//thread::start_hook(c+1); <== Inserted by compiler


// Do the work


//if (NULL != b) thread::stop_hook(b); <== Inserted by compiler
delete b;

//thread::stop_hook(c+0); <== Inserted by compiler
//thread::stop_hook(c+1); <== Inserted by compiler
// Implicit destruction of c

//thread::stop_hook(&a); <== Inserted by compiler
// Implicit destruction of a
}

c) It is not manditory but advisable to disable the copy constructor for all 
'hook' classes.
-- 

David Orchard   [EMAIL PROTECTED]

gcc-4.1-20070813 is now available

[gccadmin]

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

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

You'll find:

gcc-4.1-20070813.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20070813.tar.bz2 C front end and core compiler

gcc-ada-4.1-20070813.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20070813.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20070813.tar.bz2  C++ front end and runtime

gcc-java-4.1-20070813.tar.bz2 Java front end and runtime

gcc-objc-4.1-20070813.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20070813.tar.bz2The GCC testsuite

Diffs from 4.1-20070806 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
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.