Kinh gui quy Ong/Ba chu doanh nghiep,
Chung toi xin gui toi quy Ong/Ba Dich vu quang cao qua e-mail hieu qua
nhat, gia hop ly. Voi hon 1.800.000 dia chi e-mail cua cac to chuc, don vi,
ca nhan trong va ngoai nuoc, chung toi khang dinh se quang ba rong rai ten
tuoi cua doanh nghiep do quy Ong/Ba
Kinh gui quy Ong/Ba chu doanh nghiep,
Chung toi xin gui toi quy Ong/Ba Dich vu quang cao qua e-mail hieu qua
nhat, gia hop ly. Voi hon 1.800.000 dia chi e-mail cua cac to chuc, don vi,
ca nhan trong va ngoai nuoc, chung toi khang dinh se quang ba rong rai ten
tuoi cua doanh nghiep do quy Ong/Ba
I've reviewed the GCC 4.2 projects on the Wiki.
It certainly looks like some exciting stuff is in the pipeline.
For 4.2, I'm not going to try to be too fine-grained about scheduling
the individual projects; in 4.1, I don't think I added much value by
doing that. Also, a lot of the project pages
Mark Mitchell wrote:
> I am still working through the remainder of the branch checklist.
I believe that I have now completed the checklist, with the exception of:
# Generate the next mainline snapshot manually, using the -p option of
the gcc_release script. For that single run, adjust the script
> (B) What bits of GCC would we be bypassing, and how badly would we miss
> them?
>
> Presumably, many of the shiny new tree optimizers. Ow. But GCC was
> not in any state to do this sort of surgery a year ago, I think.
>
Probably true on both counts, but that wouldn't bother me, speaking as
s
Daniel Jacobowitz writes:
As describe above, we won't support every target that GCC currently
does. Three options are possible:
Chris tells me that an LLVM->GIMPLE translator wouldn't have target
dependencies. I'm not 100% sure I buy that, but I'll take it as given
for now (if not they shou
I have created the GCC 4.1 branch, so any future commits for bug-fixes
destined for 4.1 should go on the branch as well as on the mainline.
I am still working through the remainder of the branch checklist.
Please treat the mainline as if it were still in 4.1 Stage 3 until I
have a chance to comple
On Fri, Nov 18, 2005 at 05:50:52PM -0800, Chris Lattner wrote:
> * This will not support !
>
> As describe above, we won't support every target that GCC currently
> does. Three options are possible:
>
> 1. We (the GCC community) could build an LLVM to GIMPLE translator.
> This would probabl
On Fri, Nov 18, 2005 at 05:48:26PM -0800, Richard Henderson wrote:
> > _Jv_FreeMethodCache function, and now my simple test cases work. Like so:
> > void
> > _Jv_FreeMethodCache ()
> > {/*
> > #ifdef HAVE_TLS
> > if (method_cache != NULL)
>
> I will say that staticly linked linuxthrea
On Fri, Nov 18, 2005 at 08:12:32PM -0500, Richard Kenner wrote:
> What about the other cases where this would apply? I can't think of any
> cases where checking the lang hook directly is correct. Can you?
Deciding if one can replace one object with another, or one
pointer with another in an actu
Hi Everyone,
At the request of several members of the GCC community, I'm writing
this email to describe some of my short-term plans with GCC and
describe an alternative to the recent link-time optimization [1] and
code generator rewrite [2] proposals.
For those who are not familiar with m
On Fri, Nov 18, 2005 at 06:17:49PM -0500, Scott Gilbertson wrote:
> - if (last_cache_entry != NULL)
> + if (prev_cache_entry != NULL && last_cache_entry != NULL)
This one looks like it may be a legitimate problem with the list
manipulation, though this isn't the proper fix.
> Looking a
> if (!is_gimple_reg_type (TREE_TYPE (param))
> ! || !tree_ssa_useless_type_conversion_1 (TREE_TYPE
(param),
> ! TREE_TYPE
(arg)))
Seems reasonable. These are the conversions we strip acr
Aldy Hernandez wrote:
> Either way is fine by me. Just to make sure I understand things;
> you want me to hack the front-end to fill the hash table every time
> it parses a cast or enum type?
Yes.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Andrew Pinski <[EMAIL PROTECTED]> writes:
>>
>> Hello Everyone
>>
>> I noticed some thing strange recently. This code (under g++ (GCC) 3.2.3
>> 20030502 (Red Hat Linux 3.2.3-53)), provides this output with -O0 flag:
>> int main(int argc, char **argv) {
>> std::cout << f1() << f2() << std::end
I originally posted this on the java list, but the suggestion was made that
I post it here to see if somebody can help.
My previous related posts to the java list (I was originally thinking I had
two separate problems):
http://gcc.gnu.org/ml/java/2005-11/msg00230.html
http://gcc.gnu.org/ml/
> Although the compiler's executable is composed of 32-bit code, it can
> generate 32 or 64 bit code, which is what I meant by "both compilers".
Ah! Indeed, but you're going to further confuse the readers. :-)
I think the best terminology is "32-bit multilib compiler" for
sparc-sun-solaris and
Two thoughts:
1) Post this on gcc@ as undoubtedly RTH will have an opinion about it.
2) Perhaps your glibc build is somehow screwed up. As it is some of the
startup files in glibc that add the end of eh table markers.
David Daney
Scott Gilbertson wrote:
I wonder if someone reasonably famil
On Fri, Nov 18, 2005 at 09:35:28PM +0100, Eric Botcazou wrote:
> > Also, sparc-sun-solaris2.9 doesn't mean "32-bit compiler", it means
> > "build both compilers, defaulting to 32 bits".
>
> No, the compiler is purely 32-bit, only the libraries are of both flavors.
We are using the term in a diffe
POTREBAN VAM JE NOVAC???
IMATE 2-3 h DNEVNO SLOBODNOG VREMENA???
KORISTITE MOC INTERNETA??? STA CEKATE???
Pitajte me: "KAKO USPETI?" na [EMAIL PROTECTED] i otkricu Vam tajnu uspeha!
Korak po korak i uspeh ne moze izostati. Bogatstvo ostvaruju oni
koje motivise zelja za uspehom!!! Mislite
Laurent GUERBY wrote:
On Fri, 2005-11-18 at 15:14 -0600, Joel Sherrill wrote:
+ No PR - The Ada tools mangle target names like arm-rtems4.7.
Apparently they don't like the version part. Laurent is working on
this.
To be accurate I promised to work on this once Paolo configure
patch is
Thanks Andrew. That answers it.
Pankaj
On Fri, 18 Nov 2005, Andrew Pinski wrote:
Hello Everyone
I noticed some thing strange recently. This code (under g++ (GCC) 3.2.3
20030502 (Red Hat Linux 3.2.3-53)), provides this output with -O0 flag:
int main(int argc, char **argv) {
std::cout << f1
On Fri, 2005-11-18 at 15:14 -0600, Joel Sherrill wrote:
> + No PR - The Ada tools mangle target names like arm-rtems4.7.
>Apparently they don't like the version part. Laurent is working on
>this.
To be accurate I promised to work on this once Paolo configure
patch is in, because I'm curr
>
> Hello Everyone
>
> I noticed some thing strange recently. This code (under g++ (GCC) 3.2.3
> 20030502 (Red Hat Linux 3.2.3-53)), provides this output with -O0 flag:
> int main(int argc, char **argv) {
> std::cout << f1() << f2() << std::endl;
> }
>
>
> I'm pretty sure that I am depending
Hello Everyone
I noticed some thing strange recently. This code (under g++ (GCC) 3.2.3
20030502 (Red Hat Linux 3.2.3-53)), provides this output with -O0 flag:
-f2() called
-f1() called-
12
And with -O3 flag:
-f1() called-
-f2() called
12
Here's the code:
#include
#include
int f1() {
fp
On Fri, Nov 18, 2005 at 08:42:43AM -0500, Richard Kenner wrote:
> if (!is_gimple_reg_type (TREE_TYPE (param))
> ! || !tree_ssa_useless_type_conversion_1 (TREE_TYPE (param),
> ! TREE_TYPE (arg)))
Seems reasonable. Thes
Mark Mitchell wrote:
The number of open serious regressions against 4.1 is a respectable 87,
quite a few of which are P3s, waiting for me to categorize them. We
still have some work to do before the release, but we will branch on
2005-11-18, as previously announced, at some point late Friday eve
On Fri, Nov 18, 2005 at 02:22:16PM +0100, Jan Hoogerbrugge wrote:
> Gcc will encounter this text after the #pragma
> is handled. Is this possible?
Nope, at least not this way.
With the rewritten pragma handing on the gomp branch you have
a bit more control in the front ends about what happens wh
> Also, sparc-sun-solaris2.9 doesn't mean "32-bit compiler", it means
> "build both compilers, defaulting to 32 bits".
No, the compiler is purely 32-bit, only the libraries are of both flavors.
--
Eric Botcazou
On Fri, Nov 18, 2005 at 09:17:11PM +0100, Eric Botcazou wrote:
> > > mkdir objectdir;cd objectdir
> > > CC="cc -xildoff -xarch=v9"
> > > export CC
> >
> > Why are you choosing those flags?
>
> Probably because they are advertised on:
> http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2
>
> > mkdir objectdir;cd objectdir
> > CC="cc -xildoff -xarch=v9"
> > export CC
>
> Why are you choosing those flags?
Probably because they are advertised on:
http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2
> Just do CC=cc, you will get both a 32-bit and a 64-bit compiler. What
> seems
On Thu, Nov 17, 2005 at 10:24:21PM -0800, Mark Mitchell wrote:
> Richard Henderson wrote:
>
> > A solution that comes to mind is to have the front-end add dummy
> > TYPE_DECL nodes to the BLOCK_VARS list of the function's outer-most
> > BLOCK. If the TYPE_DECL node were marked DECL_ARTIFICIAL and
On Fri, Nov 18, 2005 at 01:48:57PM -0500, Douglas B. Jones wrote:
> I am on:
>
> SunOS hostname 5.9 Generic_118558-14 sun4u sparc SUNW,Sun-Blade-1500.
> I try to do a bootstrap with the following using gnu make 3.80:
>
> mkdir objectdir;cd objectdir
> CC="cc -xildoff -xarch=v9"
> export CC
Why a
GCC 4.0.2 has been successfully built on Fedora Core 3
config.guess returned:
> i686-pc-linux-gnu
gcc -v returned:
> Using built-in specs.
> Target: i686-pc-linux-gnu
> Configured with: /home/devel/gcc/gcc- 4.0.2/configure --program-suffix=-4.0.2
> Thread model: posix
> gcc version 4.0.2
built f
Hi,
Thanks for looking at this problem.
The points-to set says :
D.2383 = { ANYTHING ANYOFFSET }
Here is the shortened .alias1 dump. If you need the whole thing (its
2000 lines), I can send that as well.
Please grep for D.2383, to see all info about it.
Dereferences pointers doesnot show D.23
(NOTE: I originally posted this to gcc-help, but only got
one response that the sender said they had posted a similar
posting a while back and got no responses. So, I am reposting
the below to gcc in hopes that this might be a better place
to post this question.)
I am on:
SunOS hostname 5.9 Gene
On Nov 17, 2005, at 6:33 PM, Dale Johannesen wrote:
When I arrived at Apple around 5 years ago, I was told of some recent
measurements that showed the assembler took around 5% of the time.
Yeah, it's been sped up actually.
On Nov 17, 2005, at 6:13 PM, Daniel Jacobowitz wrote:
Also, please keep in mind that generating and then assembling debug
info takes a huge amount of I/O relative to code size. I'd expect
much
more than 1% saving the write-out and write-in on -g.
I'd hope that we can contribute code to elim
On Nov 17, 2005, at 3:09 PM, Robert Dewar wrote:
I never like arguments which have loaded words like "lot" without
quantification. Just how long *is* spent in this step, is it really
significant?
as is 2-3% as I recall (Finder_FE C++) of total build time.
On Nov 18, 2005, at 8:24 AM, Mark Mitchell wrote:
I'd like to have a look at the C++ bits before they go in, but I'll
not
be looking to make life difficult. :-)
There was one thing I saw that was bad, as I recall, but I didn't
mention it as I thought it'd be cleaned up on the branch. And n
Diego Novillo wrote:
> Yes. The mental model is something like this:
Makes sense.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Compiler version: 4.1.0 20051112 (experimental)
Platform: ia64-unknown-linux-gnu
configure flags:
- --prefix=/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install
- --with-gnu-as
- --with-as=/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install/bin
On 11/18/05, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-11-18 at 11:40 +, Andrew Haley wrote:
> > A nightmare scenario is debugging the compiler when its behaviour
> > changes due to using "-S". Assembly source is something that we
> > maintainers use more than anyone else.
>
> I
* Joel Sherrill <[EMAIL PROTECTED]>, 2005-11-17 :
> I hope the explanation above helps make it clearer.
Yes, thanks for the clarification. In light of this explanation the
proposed fix seems appropriate; maybe a comment could be added along
with the extern declaration to note that it is necessary
Hi,
On Fri, 18 Nov 2005, Steven Bosscher wrote:
> On Friday 18 November 2005 17:31, Michael Matz wrote:
> > Perhaps even a merger of both
> > approaches is sensible, three address form for most simple gimple
> > statements with falling back to stack encoding for deeply nested operands.
>
> That
Kenneth Zadeck wrote:
The stack machine that we have in mind will be as stripped down as
possible. The idea is just to get the trees in and get them back out.
When I first read the proposal, I too wondered if a register machine would be
better here. I've come to the conclusion that it would
On Friday 18 November 2005 17:31, Michael Matz wrote:
> Perhaps even a merger of both
> approaches is sensible, three address form for most simple gimple
> statements with falling back to stack encoding for deeply nested operands.
That would be a bad violation of the KISS principle.
Gr.
Steven
On Friday 18 November 2005 11:24, Mark Mitchell wrote:
> Great news. (The GOMP entry on the projects list was just a link to the
> project page; it didn't have this data.)
>
Yeah, we hadn't updated the status section yet. I added a paragraph
earlier today.
> It seems like it makes sense to do
Hi,
On Thu, 17 Nov 2005, Kenneth Zadeck wrote:
> A stack machine representation was chosen for the same reason. Tree
> gimple is a series of statements each statement being a tree.
IMHO we should follow that path of thinking. The representation of GIMPLE
where we do most optimizations on (i.e
Diego Novillo wrote:
> On Friday 18 November 2005 03:48, Mark Mitchell wrote:
>
>
>>I would like to better understand the status of GOMP; is it going to be
>>ready for 4.2 within a couple of months?
>>
> Most definitely. We have been essentially waiting for 4.1 to branch.
> There are 5 modules
On Fri, 2005-11-18 at 10:53 +0100, Giovanni Bajo wrote:
> Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> 1) Do you believe there will be sub-parts of this project which could be
> carried on succesfully and efficiently by programmers without previous RTL
> experience? IIUC, the optimizers will be bas
Be careful, tree_ssa_useless_type_conversion_1 strips CV qualifiers
from pointers, f.i. See various different cleanup-patches I posted
long time ago.
Right, but the point is that whatever it does, at least that code (and
perhaps other current callers of the lang hook) have to duplicat
On 11/18/05, Richard Kenner <[EMAIL PROTECTED]> wrote:
> I sent email about this a few months ago (I can't find it since I'm having
> a problem getting a browser to work on gcc.gnu.org) and thought I'd raise
> it again since it would be good to get this into 4.1
>
> Currently, tail call detected is
I sent email about this a few months ago (I can't find it since I'm having
a problem getting a browser to work on gcc.gnu.org) and thought I'd raise
it again since it would be good to get this into 4.1
Currently, tail call detected is almost completely disabled for Ada due
to confusion as to which
Hi,
I need to handle certain pragmas such that something special is generated in
the assembly output roughly at the place that corresponds to the place of
the pragma in the source code. Doing this in gcc in a clean way is not
possible I guess, so I have to apply a hack. The hack that I want to
>> Basic testing done on i686-linux (built with --languages=c,fortran and
>> a shared libgmp in /foo/bar, and regtested). Extended testing (which
>> takes ages on my computer) in progress.
>>
>> OK for mainline? OK for 4.0?
>
> *ping*
>
> This patch has both a toplevel part and a part in gcc/, so I
I am working on a portable low-level library of atomic operations,
so I need to detect the exact type of the target processor, which is
specified by -mcpu or -march. However, there are two problems.
On a sparc-based platform (Sun Fire 880, Solaris 2.8, 4x UltraSparc III)
this program
#if defined(_
On Fri, 2005-11-18 at 11:40 +, Andrew Haley wrote:
> A nightmare scenario is debugging the compiler when its behaviour
> changes due to using "-S". Assembly source is something that we
> maintainers use more than anyone else.
If we go the direct generation route, I think it would be more
effi
On Friday 18 November 2005 04:13, Prateek Saxena wrote:
> At this point, the stmt:
>
> # VUSE ;
> *D.2383 = __taint_addr.11D.3119_323;
>
> _doesnot_ show any used op like,
>
> D.2383.
>
> why is this happening?
>
D.2383 is virtual (see the VUSE). Show me the points-to set for D.2383?
That sto
Richard Earnshaw writes:
> - Then, incrementally, we can bypass the parse layer to call routines
> directly in the assembler. This can be done both for directives and for
> assembly of instructions. *but it can all be done incrementally*.
>
> The main difficulty is preserving -S output in
On Fri, 2005-11-18 at 09:29, Bernd Schmidt wrote:
> > Also, please keep in mind that generating and then assembling debug
> > info takes a huge amount of I/O relative to code size. I'd expect much
> > more than 1% saving the write-out and write-in on -g.
>
> So, maybe a simpler strategy could be
On Friday 18 November 2005 03:48, Mark Mitchell wrote:
> I would like to better understand the status of GOMP; is it going to be
> ready for 4.2 within a couple of months?
>
Most definitely. We have been essentially waiting for 4.1 to branch.
There are 5 modules to merge: library, C, C++, Fortr
Bernd Schmidt wrote:
So, maybe a simpler strategy could be to make minor modifications to gas
and gcc so that the former is linked in and the latter can pass strings
to it? Maybe that could get us a performance improvement without the
need for a massive overhaul of all backends, and the need
Richard Henderson wrote:-
> On Thu, Nov 17, 2005 at 03:18:00PM -0800, Ian Lance Taylor wrote:
> > I don't think you should get a warning for not using the return value of a
> > function, at least not under -Wunused.
>
> For this, I agree. Except that we're not talking about the
> return value of
Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> It is my intention over the next few months to do some of the initial
> underlying infrastructure bits upon which the entire document is
> based. Presuming that proceeds OK and I can build up the data
> structures I am looking for, I'll move on from ther
Daniel Jacobowitz wrote:
On Thu, Nov 17, 2005 at 03:42:29PM -0800, Ian Lance Taylor wrote:
I just tried a simple unoptimized compile. -ftime-report said that
final took 5% of the time (obviously final does more than formatting),
and the assembler took 4% of the total user time, and system time
Hello,
I am doing some code instrumentation for program memory access
validation using gcc-4.1 head.
For every assignment, p=q
I pass the address of the operands, "&p" and "&q" to an external
library function.
This works fine at O0, but at O1, some legitimate code gets optimized
away. In the dum
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
testsuite fails with the following message:
Running target unix/-m32
Using /usr/share/dejagnu/baseboards/unix.exp as board description file
for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for
target.
Using
/raid/tecosim/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Compiler version: 4.1.0 20051112 (experimental)
Platform: x86_64-unknown-linux-gnu
configure flags:
- --prefix=/SCRATCH/gcc-build/Linux/x86_64-unknown-linux-gnu/install
- --with-gnu-as
- --with-as=/SCRATCH/gcc-build/Linux/x86_64-unknown-linux-gnu/insta
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Compiler version: 4.1.0 20051112 (experimental)
Platform: i686-pc-linux-gnu
configure flags:
- --prefix=/SCRATCH/gcc-build/Linux/i686-pc-linux-gnu/install
- --with-gnu-as
- --with-as=/SCRATCH/gcc-build/Linux/i686-pc-linux-gnu/install/bin/as
- --with-gn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Compiler version: 4.1.0 20051112 (experimental)
Platform: mips-sgi-irix6.5
configure flags:
- --prefix=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install
- --with-gnu-as
- --with-as=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/as
- --with-gnu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Compiler version: 4.1.0 20051112 (experimental)
Platform: hppa2.0w-hp-hpux11.00
configure flags:
- --prefix=/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install
- --with-gnu-as
- --with-as=/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install/bin/as
The number of open serious regressions against 4.1 is a respectable 87,
quite a few of which are P3s, waiting for me to categorize them. We
still have some work to do before the release, but we will branch on
2005-11-18, as previously announced, at some point late Friday evening.
Thank you for be
73 matches
Mail list logo
