Re: Caused by unknown alignment, was: Re: On the x86_64, does one have to zero a vector register before filling it completely ?
> Steven Bosscher > Sent by: gcc-ow...@gcc.gnu.org > > 30/11/2009 09:01 > > To > > Daniel Berlin > > cc > > Richard Guenther , Toon Moene > , gcc mailing list > > Subject > > Re: Caused by unknown alignment, was: Re: On the x86_64, does one > have to zero a vector register before filling it completely ? > > On Mon, Nov 30, 2009 at 12:40 AM, Daniel Berlin wrote: > > This pass may even be on the lno branch or something. > > It used to be, at least, see http://gcc.gnu.org/ml/gcc-cvs/2004-08/ > msg00470.html > > Happy hacking, Toon :-) > Maybe this is more/also relevant: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01405.html dorit > Ciao! > Steven
Re: Caused by unknown alignment, was: Re: On the x86_64, does one have to zero a vector register before filling it completely ?
Dorit Nuzman wrote: Steven Bosscher On Mon, Nov 30, 2009 at 12:40 AM, Daniel Berlin wrote: This pass may even be on the lno branch or something. It used to be, at least, see http://gcc.gnu.org/ml/gcc-cvs/2004-08/ msg00470.html Happy hacking, Toon :-) Maybe this is more/also relevant: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01405.html dorit Jeepers creepers - why has this never been included in the trunk (it might be quite a bit of work to get it going again, and I certainly do not have time before the Christmas holidays ) -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html
Re: Caused by unknown alignment, was: Re: On the x86_64, does one have to zero a vector register before filling it completely ?
On Mon, Nov 30, 2009 at 11:02 AM, Toon Moene wrote: >> Maybe this is more/also relevant: >> http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01405.html >> >> dorit > > Jeepers creepers - why has this never been included in the trunk (it might > be quite a bit of work to get it going again, and I certainly do not have > time before the Christmas holidays ) Many reasons, let's see... The pass didn't bring any benefit at the time for any benchmark, because there were no passes who could use the result of the analysis. The vectorizer was still very primitive back then (already 5 years ago!). The analysis as implemented is intraprocedural only, and most of the benefit is expected from intraprocedural alignment propagation (FWIW: http://webhome.cs.uvic.ca/~nigelh/Publications/align_MSP5.pdf for a primitive implementation). There was no infrastructure for interprocedural analysis at the time. LNO was more-or-less abandoned in favor of Graphite. I'll see if I can make the intraprocedural version work again before Christmass. It shouldn't be that much work, actually. But it's be nice to have some test cases to demonstrate that the intraprocedural version would do any good. Ciao! Steven
Announce: GNU MPFR 2.4.2 is released
GNU MPFR 2.4.2 ("andouillette sauce moutarde", patch level 2) is now
available for download from the MPFR web site:
http://www.mpfr.org/mpfr-2.4.2/
It will also be uploaded to INRIAGforge and to ftp.gnu.org in the
next few hours.
Thanks very much to those who sent us bug reports and/or tested
the release candidates.
The MD5's:
89e59fe665e2b3ad44a6789f40b059a0 mpfr-2.4.2.tar.bz2
0e3dcf9fe2b6656ed417c89aa9159428 mpfr-2.4.2.tar.gz
f61da10945c3de6962749a5eb70dafd3 mpfr-2.4.2.tar.xz
a21eab985b5f67064295b024072a380c mpfr-2.4.2.zip
Changes from version 2.4.1 to version 2.4.2:
- Security fix in formatted output functions (buffer overflow).
- Formatted output functions: 6 is now the default value for
empty precision field with %Rf.
- Better portability of configure script.
- Detection of intmax_t and uintmax_t types.
- Improved documentation: mpfr_get_z_exp, mpfr_strtofr, mpfr_get_str and
formatted output functions.
- Improved message in case of assertion failure.
- Test coverage: 97.0% lines of code.
- Updated tcmp_ld test to really test the long double.
- Some documentation files are installed in $docdir.
- Removed mpfr_init_cache (unused and undocumented function).
- Fixed the way $CC / $CFLAGS are got from gmp.h (__GMP_CC / __GMP_CFLAGS).
- Bug fixes.
- Also note that GCC 4.4.0 (only this obsolete version) does not build
MPFR 2.4.2 correctly; this is detected by "make check" (failures in
tget_z and tpow_all).
You can send success and failure reports to , and give
us the canonical system name (by running the "./config.guess" script),
the processor and the compiler version, in order to complete the
"Platforms Known to Support MPFR" section of the MPFR 2.4.2 web page.
Regards,
--
Vincent Lefèvre - Web:
Re: Caused by unknown alignment, was: Re: On the x86_64, does one have to zero a vector register before filling it completely ?
Steven Bosscher wrote: I'll see if I can make the intraprocedural version work again before Christmass. It shouldn't be that much work, actually. But it's be nice to have some test cases to demonstrate that the intraprocedural version would do any good. That would be very nice ! To help to boost the incentive, compare the code I attach, when compiled separately with gfortran -O3 -S main.f sum.f and what happens when you inline the loop in sum.f manually into main.f and compile the resulting file with -O3 -S. Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html integer i real a(10), b(10), c(10) a = 0. b = 1. print '(3(1x,z16))', loc(a), loc(b), loc(c) call sum(a, b, c, 10) print *, c(5) end subroutine sum(a, b, c, n) integer i, n real a(n), b(n), c(n) do i = 1, n c(i) = a(i) + b(i) enddo end
Graphite and Loop fusion.
Sebastian, I saw you updated the Graphite Wiki page, and I wondered if there are any concrete plans on loop fusion. The reason I ask is because in Fortran (as of Fortran 90) one often sees assignments like: REAL, ALLOCATABLE :: A(:,:), B(:,:), C(:,:), D(:,:), E(:,:), F(:,:) ! ... READ IN EXTEND OF ARRAYS ... READ*,N ! ... ALLOCATE ARRAYS ALLOCATE(A(N,N),B(N,N),C(N,N),D(N,N),E(N,N),F(N,N)) ! ... READ IN ARRAYS READ*,A,B C = A + B D = A * C E = B * EXP(D) F = C * LOG(E) where the four assignments all have the structure of loops like: DO I = 1, N DO J = 1, N X(J,I) = OP(A(J,I), B(J,I)) ENDDO ENDDO Obviously, this could benefit from loop fusion, by combining the four assignments in one loop. Is that on the horizon ? Thanks in advance, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html
Re: MPC required in one week.
On Mon, Nov 30, 2009 at 12:04 AM, Kaveh R. GHAZI wrote: > The patch which makes the MPC library a hard requirement for GCC > bootstrapping has been approved today. Out of curiosity and ignorance: Why, specifically, is MPC going to be a hard requirement? On the prerequisites page, MPC is currently described with: "Having this library will enable additional optimizations on complex numbers." Does that mean that such optimizations are now an important requirement? or is MPC being used for something else?
Re: Graphite and Loop fusion.
Toon Moene wrote: REAL, ALLOCATABLE :: A(:,:), B(:,:), C(:,:), D(:,:), E(:,:), F(:,:) ! ... READ IN EXTEND OF ARRAYS ... READ*,N ! ... ALLOCATE ARRAYS ALLOCATE(A(N,N),B(N,N),C(N,N),D(N,N),E(N,N),F(N,N)) ! ... READ IN ARRAYS READ*,A,B C = A + B D = A * C E = B * EXP(D) F = C * LOG(E) where the four assignments all have the structure of loops like: DO I = 1, N DO J = 1, N X(J,I) = OP(A(J,I), B(J,I)) ENDDO ENDDO Obviously, this could benefit from loop fusion, by combining the four assignments in one loop. Provided that it were still possible to vectorize suitable portions, or N is known to be so large that cache locality outweighs vectorization. This raises the question of progress on vector math functions, as well as the one about relative alignments (or ignoring them in view of recent CPU designs).
Re: Graphite and Loop fusion.
Hi Toon, On Mon, Nov 30, 2009 at 13:51, Toon Moene wrote: > Sebastian, > > I saw you updated the Graphite Wiki page, and I wondered if there are any > concrete plans on loop fusion. > > The reason I ask is because in Fortran (as of Fortran 90) one often sees > assignments like: > > REAL, ALLOCATABLE :: A(:,:), B(:,:), C(:,:), D(:,:), E(:,:), F(:,:) > > ! ... READ IN EXTEND OF ARRAYS ... > > READ*,N > > ! ... ALLOCATE ARRAYS > > ALLOCATE(A(N,N),B(N,N),C(N,N),D(N,N),E(N,N),F(N,N)) > > ! ... READ IN ARRAYS > > READ*,A,B > > C = A + B > D = A * C > E = B * EXP(D) > F = C * LOG(E) > > where the four assignments all have the structure of loops like: > > DO I = 1, N > DO J = 1, N > X(J,I) = OP(A(J,I), B(J,I)) > ENDDO > ENDDO > > Obviously, this could benefit from loop fusion, by combining the four > assignments in one loop. > > Is that on the horizon ? > Yes, that's for gcc-4.6. We just need a good heuristic based on temporal locality: i.e. Graphite could code generate this loop fusion already in 4.5 but there is no driver that would ask for these stmts to be part of the same loop nest, so we need a good heuristic for it. The idea behind the heuristic is simple: detect the connected components of the data dependence graph, and then reduce the distance in between the members of the same component. Sebastian
IRA memory cost calculation
I've run into a situation where assign_hard_reg() decides that there are no registers available. This results in a memory reference being substituted for a pseudo-register. There's no check to see if the modified instruction is valid, which it isn't. There are a lot of live registers and it is possible that there are no unused register. assign_hard_reg() is finding that the cost of using any of the registers it checks is higher than the cost of a memory reference. I looked at record_operand_costs() and record_reg_classes(). This is supposed to calculate the cost of using memory or a hard reg for an insn's operands. Since none of the constraints permit a memory reference, I would expect that the mem_cost calculated for each operand would be a high value; instead it is low. If I force the mem_cost value to be high, then assign_hard_reg() does assign a register. record_operand_costs() does initialize op_costs[] to high values, both for memory and registers. This is reset in record_reg_classes() to the value from ira_memory_move_cost[] in the following code: /* If the alternative actually allows memory, make things a bit cheaper since we won't need an extra insn to load it. */ pp->mem_cost = ((recog_data.operand_type[i] != OP_IN ? ira_memory_move_cost[mode][classes[i]][0] : 0) + (recog_data.operand_type[i] != OP_OUT ? ira_memory_move_cost[mode][classes[i]][1] : 0) - allows_mem[i]) * frequency; The alternative doesn't allow memory, so I'm unclear why mem_cost is being set. allows_mem[] is zero for all operands in the insn. Can anyone give me some guidance here? -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Question about filling multi delay slots
On 11/25/09 07:34, Amker.Cheng wrote: Hi All : It's possible to define multi delay slots for branch insns by using define_delay, and different slot should satisfy its own attribute test "delay-n". Here comes question, in function "fill_simple_delay_slots", seems it only uses slots_filled to record how many slots needs to fill, and puts slot insns already found in delay_list. I can't find any codes keeping the information about which insn in delay_list belongs to which slot(defined in "define_delay"). So, how does gcc make sure that insns in delay_list go into right delay slot? First, it's worth noting very few targets support multiple delay slots and as a result that code isn't tested nearly as well as handling of single delay slots. I'm pretty sure we assume that the first insn we add to the delay list always goes in the first slot, 2nd insn in the 2nd slot and so-on. Jeff
Re: IRA memory cost calculation
On 11/30/09 14:17, Michael Eager wrote: I've run into a situation where assign_hard_reg() decides that there are no registers available. That can certainly happen. It's also the case that assign_hard_reg may decide that memory is cheaper than a register and refuse to assign a register for certain allocnos. This results in a memory reference being substituted for a pseudo-register. There's no check to see if the modified instruction is valid, which it isn't. reload performs this action, not IRA. Reload is allowed to replace a pseudo with its equivalent memory location, then emit whatever reloads are necessary to fix up the resulting insn. So what you need to do is debug the generated reloads for the insn in question. Often this kind of failure is a predicate, constraint or secondary reload problem. Jeff
Re: IRA memory cost calculation
Jeff Law wrote: On 11/30/09 14:17, Michael Eager wrote: I've run into a situation where assign_hard_reg() decides that there are no registers available. That can certainly happen. It's also the case that assign_hard_reg may decide that memory is cheaper than a register and refuse to assign a register for certain allocnos. This results in a memory reference being substituted for a pseudo-register. There's no check to see if the modified instruction is valid, which it isn't. reload performs this action, not IRA. Reload is allowed to replace a pseudo with its equivalent memory location, then emit whatever reloads are necessary to fix up the resulting insn. So what you need to do is debug the generated reloads for the insn in question. Often this kind of failure is a predicate, constraint or secondary reload problem. Thanks. I did step through reload and it looked like everything it was doing was OK. I'll look at reload again and re-check constraints. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: MPC required in one week.
From: "Michael Witten" On Mon, Nov 30, 2009 at 12:04 AM, Kaveh R. GHAZI wrote: The patch which makes the MPC library a hard requirement for GCC bootstrapping has been approved today. Out of curiosity and ignorance: Why, specifically, is MPC going to be a hard requirement? Some of the benefits are noted here: http://gcc.gnu.org/gcc-4.5/changes.html#mpcopts
Re: IRA memory cost calculation
On 11/30/09 14:48, Michael Eager wrote: Jeff Law wrote: On 11/30/09 14:17, Michael Eager wrote: I've run into a situation where assign_hard_reg() decides that there are no registers available. That can certainly happen. It's also the case that assign_hard_reg may decide that memory is cheaper than a register and refuse to assign a register for certain allocnos. This results in a memory reference being substituted for a pseudo-register. There's no check to see if the modified instruction is valid, which it isn't. reload performs this action, not IRA. Reload is allowed to replace a pseudo with its equivalent memory location, then emit whatever reloads are necessary to fix up the resulting insn. So what you need to do is debug the generated reloads for the insn in question. Often this kind of failure is a predicate, constraint or secondary reload problem. Thanks. I did step through reload and it looked like everything it was doing was OK. I'll look at reload again and re-check constraints. Also double check your predicates and look at secondary reload issues. It's not uncommon to need to define secondary reloads for oddball cases. If you described more attributes of your target we might be able to point you at another target with similar attributes and describe how it handles these situations. jeff
Re: Graphite and Loop fusion.
Sebastian Pop wrote: Hi Toon, On Mon, Nov 30, 2009 at 13:51, Toon Moene wrote: Sebastian, Obviously, this could benefit from loop fusion, by combining the four assignments in one loop. Is that on the horizon ? Yes, that's for gcc-4.6. Thanks ! -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html
Delay loaded shared objects
Hi All, I am not sure whether this is the right list. Please let me know if there is a more appropriate list for this question. Does gcc/g++ (on a typical Linux platform) supports delayed loaded shared objects similar to the /DELAYLOAD option of MSVC [1]? The Win32 delay load implementation hides the LoadLibrary and GetProcAddress logic from the programmer (those are similar calls to dlopen/dlsym on Unix). Dependent DLLs are only loaded into library until the first function in this library is called. Many thanks, Robert [1] http://msdn.microsoft.com/en-us/library/151kt790.aspx
Re: Understanding IRA
On 11/19/09 08:40, Ian Bolton wrote:
Jeff Law wrote:
On 11/16/09 10:33, Ian Bolton wrote:
The question is: how to fix this? I have initially put the
REG_ALLOC_ORDER
back to how it was and changed the operand constraints in our MD
file,
so each of the "apathetic" instructions, will either take a 't'
(TOP_CREG)
or '?b' (BOTTOM_REG). The '?' shows that this alternative is
slightly more
costly than using 't'. On the benchmark that benefitted the most
from
the new REG_ALLOC_ORDER, these constraints are almost achieving the
same
thing. It is only "almost" there because I am struggling with how to
show
two alternatives for loads and stores, which currently have an 'm'
constraint.
I'm not aware of any way to describe this to IRA. In theory I guess
IRA
could be twiddled to use TARGET_ADDRESS_COST to derive some kind of
cost difference based on the registers used in the MEM, but it seems
rather hackish.
I found somewhere in record_address_reg to achieve what I needed:
for (k = 0; k< cost_classes_num; k++)
{
i = cost_classes[k];
pp->cost[k]
+= (ira_get_may_move_cost (Pmode, i, rclass, true) * scale) / 2;
/* Slightly nudge memory addresses away from using BOTTOM_REGS and
C_REGS, so they take TOP_CREGS instead - should this pseudo later
need BOTTOM_REGS, there will be a higher cost to use TOP_CREGS
and it will still get BOTTOM_REGS. This is equivalent to adding a
?b on each instruction that currently has a 'm' constraint.
Writing this generically might look something like:
pp->cost[k] += TARGET_ADDRESS_EXTRA_COST_P(cost_classes[k])
? (scale/2) : 0;
*/
if (cost_classes[k] == BOTTOM_REGS || cost_classes[k] == C_REGS)
pp->cost[k] += (scale) / 2;
}
Right. My point was that I wasn't aware of an _existing_ way to handle
this. I'm seeing similar issues with costing model problems on x86_64
where it is _sometimes_ more costly to use the new GPRs.
I don't have a good handle on how to model this for x86_64 right now
(and that problem is several deep on my queue).
I was then able to alter all our register-agnostic instructions in our
.md file to take either a 't' for TOP_CREGS for a '?b' for BOTTOM_REGS.
Sounds right.
Initial results showed that IRA was moving input arguments out of their
BOTTOM_REGS (e.g. $c1) into TOP_CREGS to do work on them, since it
thought TOP_CREGS were less costly to use, despite the cost of the move
instruction to get the input argument into a TOP_CREG.
That may indicate a cost scaling issue or more general weaknesses in
IRA's cost modeling.
I addressed this problem by splitting my register bank a little
differently: instead of making a distinction between BOTTOM_REGS and
TOP_CREGS, I made it so there was only a penalty if you used one of the
non-argument BOTTOM_REGS (i.e. a callee-save BOTTOM_REG). This meant
that IRA was happy to leave input arguments in their BOTTOM_REGS but
erred towards using TOP_CREGS once the caller-save BOTTOM_REGS had run
out. This was an improvement, but there was still a case where these
'?' penalties were not aligned with reality:
T1 = A + B; // can use any register, TOP_CREGS appears cheaper
T2 = A - C; // can use any register, TOP_CREGS appears cheaper
T3 = A& D; // must use BOTTOM_REGS
The constraints for the first two instructions show that TOP_CREGS is
cheaper, but then you have to plant a move to get A into a BOTTOM_REG
to do the AND; in reality, we know it cheaper to have A in a BOTTOM_REG
all along, but the '?' constraint suggests there is a cost in doing this
for the ADD and SUB and so IRA will put A in a TOP_CREG at first and
incur the cost of the move because it is still cheaper than the costs I
have defined in with my constraints. I don't believe there is a way to
communicate a conditional cost, so I'm thinking that constraints are not
the solution for me at this time. What are your thoughts?
See above. This might be a problem with scaling or weaknesses in IRA's
costing model. In theory IRA accumulates the cost of using each class
over the set of insns using a particular pseudo.
You might try something like this:
1. Crank up the callee-saved register cost adjustment in
assign_hard_reg so that it's scaled based on REG_FREQ. That will
probably lead to some regressions based on my experiments.
2. Then add a check that completely avoids the cost adjustment in
cases where we pushed a MAY_SPILL_P allocno. This was on my todo list,
but I haven't got to it yet.
If you wanted to get fancy, you could track the maximum number of
neighbors in each class as allocnos are pushed and use that to adjust
how many registers are cost adjusted in assign_hard_reg. The idea
being
the more neighbors the allocno has, the more callee-saved regsiters
we'
Re: Delay loaded shared objects
On 11/30/2009 02:53 PM, Robert Huo wrote: Does gcc/g++ (on a typical Linux platform) supports delayed loaded shared objects similar to the /DELAYLOAD option of MSVC [1]? No. The glibc elf.h file defines (and thus presumably reserves) the DF_P1_LAZYLOAD interface used on Solaris, but does not actually implement lazy loading in the glibc dynamic linker. Nor does the binutils linker provide a mechanism for setting this bit. r~
Re: IRA memory cost calculation
Jeff Law wrote: On 11/30/09 14:48, Michael Eager wrote: Jeff Law wrote: On 11/30/09 14:17, Michael Eager wrote: I've run into a situation where assign_hard_reg() decides that there are no registers available. That can certainly happen. It's also the case that assign_hard_reg may decide that memory is cheaper than a register and refuse to assign a register for certain allocnos. This results in a memory reference being substituted for a pseudo-register. There's no check to see if the modified instruction is valid, which it isn't. reload performs this action, not IRA. Reload is allowed to replace a pseudo with its equivalent memory location, then emit whatever reloads are necessary to fix up the resulting insn. So what you need to do is debug the generated reloads for the insn in question. Often this kind of failure is a predicate, constraint or secondary reload problem. Thanks. I did step through reload and it looked like everything it was doing was OK. I'll look at reload again and re-check constraints. Also double check your predicates and look at secondary reload issues. It's not uncommon to need to define secondary reloads for oddball cases. If you described more attributes of your target we might be able to point you at another target with similar attributes and describe how it handles these situations. Xilinx MicroBlaze. Not too odd a processor -- RISC, 3-addr. It was working OK with the IAR register allocator until I removed some of the branch instruction templates which should no longer be necessary. AFAIK, this should not have changed constraints or predicates. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Medical Doctor List in the USA
Currently in Practice: Medical Doctors in America 788,7[3
Support for VLE code in PowerPC
Hi, Based on the following conversations in binutils and gcc mailing list, we understand that there is no support for VLE code for PowerPC port. http://sourceware.org/ml/binutils/2008-05/msg00153.html http://gcc.gnu.org/ml/gcc-help/2009-04/msg00201.html We are planning to support the same in binutils, gcc and newlib. Please let us know if you have any suggestions to implement this support for easier FSF approval. Thanks, Kaushik Phatak
�� ������� �������� ����� MTZ
äÃÃæà ááÃäÃãÃã Ãáà ÃÃÃà ÃáãÃÃÃÃÃä MasTerZ ááÃÃÃãà ÃáÃÃãáà æäÃã ÃáÃÃÃÃá ÃÃÃÃá ÃÃÃÃÃà ãæÃÃäÃÃáà : www.team-mtz.org ÃÃà ÃáãæÃÃÃà : 4u downlaod áÃÃãÃá Ãà ÃÃÃÃæ ÃÃÃÃà ãä youtube http://team-mtz.org/phpBB3/viewtopic.php?f=11&t=346 -- Ããá ãä ÃÃÃÃÃÃÃà ÃÃÃÃà ÃÃÃà ãà Rapidshare Downloader http://team-mtz.org/phpBB3/viewtopic.php?f=11&t=320 -- Microsoft Office 2010 v14.0.4536.1000 x86/x64 Beta ENG http://team-mtz.org/phpBB3/viewtopic.php?f=11&t=315 - ÃÃÃæÃäà ÃáÃÃÃäà ÃáÃÃáãÃà Hirens Boot CD V10.01 http://team-mtz.org/phpBB3/viewtopic.php?f=11&t=301 - ÃÃÃà äÃÃà Ãáà ÃáÃäÃÃäà æÃÃÃà ÃÃãÃä Real Hide IP 3.5 http://team-mtz.org/phpBB3/viewtopic.php?f=40&t=321 - ÃÃäÃãà ÃáÃÃÃã Ãà ÃáÃÃÃÃ¥ æãÃÃÃÃÃåà ClassRoom Spy Pro http://team-mtz.org/phpBB3/viewtopic.php?f=40&t=201 æÃáãÃÃÃãä ÃáÃÃÃãà ÃáÃÃãáà æÃáãæÃæÃÃà ÃáããÃÃÃ
