Bootstrap broken - treelang: error: ‘treelang_expand_function’ defined but not used
bootstrap with current svn head fails for me on Linux/x86-64: /abuild/aj/gcc/./prev-gcc/xgcc -B/abuild/aj/gcc/./prev-gcc/ -B/opt/gcc/4.3-devel/x86_64-suse-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -Itreelang -I/cvs/gcc-svn/trunk/gcc -I/cvs/gcc-svn/trunk/gcc/treelang -I/cvs/gcc-svn/trunk/gcc/../include -I/cvs/gcc-svn/trunk/gcc/../libcpp/include -I/cvs/gcc-svn/trunk/gcc/../libdecnumber -I/cvs/gcc-svn/trunk/gcc/../libdecnumber/bid -I../libdecnumber /cvs/gcc-svn/trunk/gcc/treelang/treetree.c -o treelang/treetree.o cc1: warnings being treated as errors /cvs/gcc-svn/trunk/gcc/treelang/treetree.c:1191: error: ‘treelang_expand_function’ defined but not used make[3]: *** [treelang/treetree.o] Error 1 Any ideas? Andreas -- Andreas Jaeger, Director Platform / openSUSE, [EMAIL PROTECTED] SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpt4a4HJRGOQ.pgp Description: PGP signature
Re: [RFC] Marking C++ new operator as malloc?
On 11 Sep 2007 18:14:21 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> "Richard Guenther" <[EMAIL PROTECTED]> writes:
>
> > On 9/9/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > >
> > > Which brings back the fact that you cannot implement malloc in C
> > > (you certainly remember the discussions about C++ placement new
> > > handling wrt aliasing). To re-use the machinery we invented there
> > > we would need to place a CHANGE_DYNAMIC_TYPE_EXPR for
> > > the pointer assignment resulting from inlining a function with
> > > attribute malloc set. As you say, unless we are inlining such functions
> > > we are safe in practice.
> >
> > Actually this looks nice in general. We could implement placement
> > new in C this way:
> >
> > extern inline T * __attribute__((malloc)) placement_new (void *p)
> > { return p; }
> >
> > if we can somehow encode the target type here. Note that only
> > type-based aliasing is a problem with this discussion - PTA will
> > be obviously fine if new is inlined as it will see that both pointers
> > are related and we loose the 'malloc' attribution on the target pointer
> > during inlining.
>
> CHANGE_DYNAMIC_TYPE_EXPR has the target type, of course. So perhaps
> we need __attribute__ ((change_dynamic_type))?
>
> Or actually of course __attribute__ ((malloc)) is fine but we could
> throw in a CHANGE_DYNAMIC_TYPE_EXPR after any call to such a
> function. That ought to do the right thing for C malloc
> implementations as well, I think.
We should need this only if inlining malloc functions in C.
Richard.
Re: Bootstrap broken - treelang: error: 'treelang_expand_function' defined but not used
Andreas Jaeger <[EMAIL PROTECTED]> writes: > bootstrap with current svn head fails for me on Linux/x86-64: ... > cc1: warnings being treated as errors > /cvs/gcc-svn/trunk/gcc/treelang/treetree.c:1191: error: > ‘treelang_expand_function’ defined but not used > make[3]: *** [treelang/treetree.o] Error 1 > > Any ideas? Just remove that function, it is not used anymore.
Re: Bootstrap broken - treelang: error: 'treelang_expand_function' defined but not used
> Andreas Jaeger <[EMAIL PROTECTED]> writes: > > > bootstrap with current svn head fails for me on Linux/x86-64: > ... > > cc1: warnings being treated as errors > > /cvs/gcc-svn/trunk/gcc/treelang/treetree.c:1191: error: > > ???treelang_expand_function??? defined but not used > > make[3]: *** [treelang/treetree.o] Error 1 > > > > Any ideas? > > Just remove that function, it is not used anymore. I've just comitted the fix. Honza
Re: SImode and PSImode question
On 9/11/07, Jim Wilson <[EMAIL PROTECTED]> wrote: > It does look like loop-iv.c is broken though. Every > simplify_gen_relational call uses SImode. That probably should be > word_mode instead. You might want to submit a bug report for that. I think even using word_mode there is wrong. An example where is the case is spu-elf where word_mode is TImode but int (and long and Pmode) is SImode. Thanks, Andrew Pinski
Re: GCC 4.3.0 Status Report (2007-09-04)
I have two patch may be worth to enter into 4.3 at stage 2.
Jan and I tried to ping the first part now about some time and we didn't
got a comment or approval for them.
See
http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-MS-ABI-attributes-in-backend-tf4414541.html
http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI-attributes-in-i386-may-before-stage--3-tf4428449.html
Cheers,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
--
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
Handelsregister: HRA 6744, Amtsgericht Regensburg
Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer:
Ulrike Döhler, Manuela Kluger
Is Sun putting much effort into supporting the gcc/binutils toolchain on sparc64 ?
I have to make buying decisions, and having tested a Sun T1000 for a while I am impressed with Suns hardware. But, we are 100% gnu/linux and it disturbs me that David Miller seems to be a (very impressive) team of 1 on the sparclinux ML (My impression; perhaps I am wrong?) So I wonder, is Sun putting any more effort into developing and supporting the gcc/binutils toolchain? [Apologies for slightly off-topic post] Andrew Walrond
Re: Is Sun putting much effort into supporting the gcc/binutils toolchain on sparc64 ?
From: Andrew Walrond <[EMAIL PROTECTED]> Date: Wed, 12 Sep 2007 12:37:03 +0100 > I have to make buying decisions, and having tested a Sun T1000 for a > while I am impressed with Suns hardware. But, we are 100% gnu/linux and > it disturbs me that David Miller seems to be a (very impressive) team of > 1 on the sparclinux ML (My impression; perhaps I am wrong?) > > So I wonder, is Sun putting any more effort into developing and > supporting the gcc/binutils toolchain? They are sending me specs and systems very early these days, so in that perspective it's been great. I do also have contacts which I use to report firmware and hypervisor issues I'd like fixed or clarified, so that's great too. I tend to do the processor specific gcc instruction scheduler and costs entries, and adding the new instruction support to binutils as well. So no, Sun really isn't helping with any actual development.
Re: GCC 4.3.0 Status Report (2007-09-04)
Hi, I apologize for the late response to your mail but I sort of did these patches up recently . I have a couple of patches that I submitted / intend to submit . One of them was submitted today regarding a small improvement to the auto-increment pass. I am not sure if this is suitable for stage3 if it is approved. http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01060.html The other patch that we have for submission is relatively trivial and tries to be more precise with size costs for builtins while inlining. I guess that should be alright for stage3 . cheers Ramana > We are closing in on Stage 3, previously announced for September 10th. > At this point, I'm not aware of any reason to delay that date. Are > there any Stage 2 patches that people don't think will be submitted by > that point? > > Are there Stage 1 or Stage 2 patches in need of review? I'll do my best > to either (a) convince someone to review them, or (b) review them myself. > > Quality > === > > Priority # > --- > P1 43 > P2118 > P3 4 > Total 165 > > Obviously, that's rather more P1s than we'd like. As I mentioned in my > previous status report, of particular concern is that we've got a lot of > 4.3-only P1s. I'm sure many of those won't be too hard to fix, but we > still need to go and fix them. > > I'm concerned about getting into a situation where we say "well, 4.2 has > some bugs, but all of those are fixed in 4.3" and then realize that "oh, > well, 4.3 has different bugs too, but those are all fixed in 4.4" and so > forth. > > Previous Report > === > > http://gcc.gnu.org/ml/gcc/2007-08/msg00181.html > > -- > Mark Mitchell > CodeSourcery > [EMAIL PROTECTED] > (650) 331-3385 x713 > -- Ramana Radhakrishnan
Re: Is Sun putting much effort into supporting the gcc/binutils toolchain on sparc64 ?
David Miller wrote: > > So no, Sun really isn't helping with any actual development. > I don't know what to say. Incredible work David, but quite frankly, I'm speechless. I'm sure I can't be the only hardware purchaser asking these questions. I really like the Niagra and the successors sound even better, but I can't recommend buying into the platform without solid support for the OS and toolchain from Sun. I'm trying to conceive a valid business reason for Sun to be so dismissive of the (surely massive?) gnu/linux hardware market, (even if they would rather we used Solaris), but it eludes me completely. Andrew Walrond
Re: Is Sun putting much effort into supporting the gcc/binutils toolchain on sparc64 ?
On Wed, 12 Sep 2007, Andrew Walrond wrote: David Miller wrote: So no, Sun really isn't helping with any actual development. I don't know what to say. Incredible work David, but quite frankly, I'm speechless. I'm sure I can't be the only hardware purchaser asking these questions. I really like the Niagra and the successors sound even better, but I can't recommend buying into the platform without solid support for the OS and toolchain from Sun. Sun have their own, compiler, though. I'm trying to conceive a valid business reason for Sun to be so dismissive of the (surely massive?) gnu/linux hardware market, (even if they would rather we used Solaris), but it eludes me completely. Because given the price of their hardware, the only people who can afford it are enterprise customers, and Solaris is a more "enterprisey" solution. If I had to guess, that is... Gordan
Re: Is Sun putting much effort into supporting the gcc/binutils toolchain on sparc64 ?
Andrew Walrond wrote: > > I'm trying to conceive a valid business reason for Sun to be so > dismissive of the (surely massive?) gnu/linux hardware market, (even if > they would rather we used Solaris), but it eludes me completely. They are putting a lot of effort into linux on Intel and AMD. 18 years ago, SPARC was their one true way, but a few years have passed.
Re: [RFC] Marking C++ new operator as malloc?
"Richard Guenther" <[EMAIL PROTECTED]> writes: > > CHANGE_DYNAMIC_TYPE_EXPR has the target type, of course. So perhaps > > we need __attribute__ ((change_dynamic_type))? > > > > Or actually of course __attribute__ ((malloc)) is fine but we could > > throw in a CHANGE_DYNAMIC_TYPE_EXPR after any call to such a > > function. That ought to do the right thing for C malloc > > implementations as well, I think. > > We should need this only if inlining malloc functions in C. Which we will presumably do at some point. After all, it's not just malloc--it's any function with __attribute__ ((malloc)), which can include user functions. Ian
Re: [RFC] Marking C++ new operator as malloc?
On 12 Sep 2007 08:13:31 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > "Richard Guenther" <[EMAIL PROTECTED]> writes: > > > > CHANGE_DYNAMIC_TYPE_EXPR has the target type, of course. So perhaps > > > we need __attribute__ ((change_dynamic_type))? > > > > > > Or actually of course __attribute__ ((malloc)) is fine but we could > > > throw in a CHANGE_DYNAMIC_TYPE_EXPR after any call to such a > > > function. That ought to do the right thing for C malloc > > > implementations as well, I think. > > > > We should need this only if inlining malloc functions in C. > > Which we will presumably do at some point. After all, it's not just > malloc--it's any function with __attribute__ ((malloc)), which can > include user functions. Btw, I filed PR33407 to hint that we need the CHANGE_DYNAMIC_TYPE_EXPR trick for the usual operator new as well. And yes, we would need to fix all __attribute__((malloc)) functions in C with the same thing - the problem I see in C is that we don't know the type we are "converting" to ;) Richard.
Re: [RFC] Improve Tree-SSA if-conversion - convergence of efforts
Tehila asked me a while ago to comment based on my experience with the RTL if convert pass and the discussions some of us had at the GCC summit. Sorry it took me so long to respond. The target I care about (Cell SPU) has some things that make an aggressive if convert very useful and profitable. It has conditional moves for every mode (there is a single, unified register file), never traps on illegal addresses (addresses always wrap to the 256KB address space), and branches are expensive (there is no hardware cache). The main limitation with the RTL if-convert pass is that it only recognizes specific patterns. It is easy to write a complicated if statement (just using normal C with &&/||) that would never get converted because it ends up with basic blocks that have many in edges that if-convert generally doesn't handle. (In our internal tree we modified the RTL pass to handle some cases of multiple in-edges, and can handle any number of insns in a basic block.) I haven't looked at the tree-SSA if-convert code yet, but based on what was described to me at the summit it seemed to be taking the same approach as the RTL pass. Recognize certain patterns and convert it. I would like to see an approach that is able to take an arbitrary flow graph without backedges and convert it to straight line code, limited only by the cost model and impossible cases (e.g., inline asm). I'm not sure how that would be achieved in a target neutral way. Trevor * Tehila Meyzels <[EMAIL PROTECTED]> [2007-07-31 06:50]: > > Hi, > > I'd like to bring up on the list a discussion that a bunch of people (most > of those CC-ed above) started at the GCC Summit: > > Lately, there were few efforts, that are not necessarily related to each > other, but are all relevant to if-conversion. > Each of them has its own restriction, like a specific control-flow, target > dependent information, permission to transform speculative loads, etc. > > Few patches that I'm aware of are: > 1. Conditional store sinking, by Michael Matz: > http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00724.html > > 2. If -conversion for multiple IF_THEN_ELSE clauses, by Victor Kaplansky: > http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00265.html > Also mentioned here: http://gcc.gnu.org/wiki/AutovectBranchOptimizations > (2.3.3) > > 3. (unconditional) Store sinking (4.1.1 based), by Revital Eres and Victor > Kaplansky: > http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00265.html (same patch as > previous) > Also mentioned here: http://gcc.gnu.org/wiki/AutovectBranchOptimizations > (2.3.2) > > 4. Conditional load hoisting (4.1.1 based), by myself: > http://gcc.gnu.org/ml/gcc-patches/2007-07/msg02168.html > > 5. Maybe more? > > You're welcome to share your/others related works here... > > > I'd like to suggest to converge all these efforts into a single improved > tree-level if-conversion pass (i.e., on the top of tree-if-conv.c). > Currently, the tree-level if-conversion pass is quite limited in several > ways, and mostly with respect to handling of loads/stores (it basically > doesn't handle them), but not only. > > There are several reasons why to store-sinking and load-hoisting should be > combined with the if-conversion pass: > 1. Store-sinking/load hoisting effect one another and they both can create > new opportunities for if-conversion (not only in vectorizable loops, for > example). > Currently, load-store motion pass happens too late and thus don't help > the (tree-ssa) if-converter. > 2. Store-sinking/load hoisting may have an overhead and may degrade > performance unless the relevant conditional branch gets if-converted. > > Issues/Questions to be considered and discussed: > 1. Cost model and machine dependency issues: > - When is it profitable to perform these motions? What is the algorithm > to decide whether there is a good chance for if-conversion? > - Target dependency - What to check? > A. Are there scalar select/cmove/predicated instructions (like in > SPU)? > B. Are there vector select/cmove/predicated instructions (like in > PowerPC)? + will the loop be vectorized? > C. Are speculative loads allowed? Do memory accesses trap? > D. More? > > 2. Which transformations we want to take care of in this pass? >A. Conditional/unconditional loads/stores. >B. PHI nodes with operands that are neither constants nor SSA NAMES > (Currently, this is not supported in tree-if-conv.c). >C. PHIOPT transformations (i.e., merge the PHIOPT pass into this pass > maybe)? >D More? > 3. New control-flow graphs we want to support (besides the regular > IF_THEN_ELSE, diamond-based): > A. Nested diamonds. > B. Sequential diamonds. > C. More? > 4. After we complete this pass, will the RTL-level ifcvt be needed? > I guess the answer is yes, but I would like to hear more opinions. > > Any comments/ideas/thoughts are really appreciated. > > Thanks, > Tehila. > >
Re: GCC 4.3.0 Status Report (2007-09-04)
Kai Tietz wrote: > See > http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-MS-ABI-attributes-in-backend-tf4414541.html > http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI-attributes-in-i386-may-before-stage--3-tf4428449.html Thanks for letting me know. I'm going to leave this to the x86 back-end maintainers. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Is Sun putting much effort into supporting the gcc/binutils toolchain on sparc64 ?
Maybe you would find what you want at the following URL: http://www.sun.com/download/products.xml?id=46448222 gccfss means 'GCC for SPARC System' 2007/9/12, Andrew Walrond <[EMAIL PROTECTED]>: > I have to make buying decisions, and having tested a Sun T1000 for a > while I am impressed with Suns hardware. But, we are 100% gnu/linux and > it disturbs me that David Miller seems to be a (very impressive) team of > 1 on the sparclinux ML (My impression; perhaps I am wrong?) > > So I wonder, is Sun putting any more effort into developing and > supporting the gcc/binutils toolchain? > > [Apologies for slightly off-topic post] > > Andrew Walrond > -- Best wishes! Yours, Lijuan Hai _ _ (_)(_) (,,) =()= ((__)\ _|L\___/
