Re: Fixing m68hc11 reorg after dataflow merge

On Sat, Jun 16, 2007 at 11:36:00PM -0400, Kenneth Zadeck wrote: > > > > Try: > > > > df_note_add_problem (); > > df_analyze (); > > -- > > #pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com"; > > What Seongbae said is correct. However, what Seongbae failed to say is > that you

Re: RFC: Make dllimport/dllexport imply default visibility

On Jun 16, 2007, at 11:52 AM, Mark Mitchell wrote: Daniel Jacobowitz wrote: This doesn't make a lick of sense to me. If the type is hidden, how on earth can it get a member function _of that type_ from another library? That library would, by definition, have to have a type of the same name.

Re: Fixing m68hc11 reorg after dataflow merge

> On 6/16/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote: > >I need some help making m68hc11_reorg() work after the dataflow merge, in > > particular this bit: > > > > /* Re-create the REG_DEAD notes. These notes are used in the machine > > description to use the best assembly d

Re: Incorrect bitfield aliasing with Tree SSA

On 6/16/07, Richard Kenner <[EMAIL PROTECTED]> wrote: > You guys have come up with a very weird idea of what > non-addressability means. These fields are all addressable, they > are just not directly addressable. Terminology is always tricky here. "addressable" in this context means that no po

Re: Incorrect bitfield aliasing with Tree SSA

On 6/16/07, Eric Botcazou <[EMAIL PROTECTED]> wrote: > If that was really true, we would get this right. Well, this is true, I really don't understand why you keep denying that. Because it wouldn't be pruning it if the alias sets conflicted! Just grep the RTL expanders for MEM_KEEP_ALIAS_SE

Re: I'm sorry, but this is unacceptable (union members and ctors)

Ross Ridge wrote: I completely disagree. Standards should primarily standardize existing practice, not inventing new features. New features should be created by people who actually want and will use the features, not by some disinterested committee. First of all, I think you mean unintereste

Re: Incorrect bitfield aliasing with Tree SSA

> You guys have come up with a very weird idea of what > non-addressability means. These fields are all addressable, they > are just not directly addressable. Terminology is always tricky here. "addressable" in this context means that no pointer can point directly to the field. So if I have

Re: I'm sorry, but this is unacceptable (union members and ctors)

Joe Buck wrote: > > On Sat, Jun 16, 2007 at 12:08:40PM -0700, michael.a wrote: >> As for "placement new", from what I can find, it is unsafe to use with >> any >> memory that isn't part of the heap. > > You do have to concern yourself with alignment. But often an allocator > that hands out me

RE: I'm sorry, but this is unacceptable (union members and ctors)

Any advice on compiling gcc? That is the chicken and egg problem. If I install a binary version of GCC, then use it to build and install a custom GCC (which I want to become the system wide GCC) ...then how is this commonly done? --of course I would like the non custom GCC to do any future rebuild

Re: Some thoughts about steerring commitee work

[EMAIL PROTECTED] wrote: On Sat, Jun 16, 2007 at 06:54:46PM +0300, Dorit Nuzman wrote: There are quite a few known simple cases which vectorizer fails to vectorize. by "known" you mean there are open missed-optimization PRs for them? (if Yes, that is what I meant. I'd be happy to file some

Re: I'm sorry, but this is unacceptable (union members and ctors)

On Sat, Jun 16, 2007 at 12:08:40PM -0700, michael.a wrote: > As for "placement new", from what I can find, it is unsafe to use with any > memory that isn't part of the heap. You do have to concern yourself with alignment. But often an allocator that hands out memory that is filled in by placement

Re: Some thoughts about steerring commitee work

On Sat, Jun 16, 2007 at 06:54:46PM +0300, Dorit Nuzman wrote: > > There are quite a few known simple cases which vectorizer fails to > > vectorize. > > by "known" you mean there are open missed-optimization PRs for them? (if > Yes, that is what I meant. H.J.

Re: PR other/32351 [Was: Re: GCC Status Report (2007-06-15)]

On Sat, Jun 16, 2007 at 05:22:25PM +0200, Uros Bizjak wrote: > Hello! > > >BTW, an x86 DFP configure bug was reported 3 months ago. But it still > >hasn't benen fixed. I opened a DFP bug report: > > > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32351 > > > >with a patch. I hope it will be fixed

Re: Some thoughts about steerring commitee work

H. J. Lu wrote: > Why don't we turn on vectorizer at -O3 or even -O2, depending on > ISA? I added -ftree-vectorize to BOOT_CFLAGS on x86-64. According to > -ftree-vectorizer-verbose=1, there are 82 loops vectorized in > gcc source. There are no regressions. There are not much changes > in bootstra

Re: GCC Status Report (2007-06-15)

H. J. Lu wrote: > Who are those relevant maintainers? Since Intel BID patches only > affects DFP intrinsics, which is only supported on Linux/PPC, > Linux/ia32 and Linux/x86-64 while Linux/PPC uses DPD encoding, not > BID encoding, I assume the relevant maintainers are maintainers for > DFP, libgc

Re: GCC Status Report (2007-06-15)

Kaveh R. GHAZI wrote: > On Fri, 15 Jun 2007, Mark Mitchell wrote: > >> GCC 4.3 Stage 1 is now closed. >> [...] >> As previously discussed, the mainline will be in "lockdown" for 1-2 >> weeks, starting midnight tonight. Other then the merges mentioned >> above, and documentation improvements, the

RE: RFC: Make dllimport/dllexport imply default visibility

> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Mark Mitchell > Sent: Saturday, 16 June 2007 11:47 a.m. > > Chris Lattner wrote: > > > This construct seems like it should be rejected by the C++ > front-end. > > The source is making two contradi

Re: init-regs pass initializes virtual-stack-vars?

On Sat, Jun 16, 2007 at 08:11:18PM +0200, Uros Bizjak wrote: > Hello! > > There is something strange going on, it looks that initialization of > virtual-stack-vars register in init-regs pass confuses greg. In > 154r.regclass we have this sequence: It should have disappeared in the vregs pass

Re: Incorrect bitfield aliasing with Tree SSA

> If that was really true, we would get this right. Well, this is true, I really don't understand why you keep denying that. Just grep the RTL expanders for MEM_KEEP_ALIAS_SET_P for example: `MEM_KEEP_ALIAS_SET_P (X)' In `mem' expressions, 1 if we should keep the alias set for this mem

Re: Incorrect bitfield aliasing with Tree SSA

On 6/16/07, Eric Botcazou <[EMAIL PROTECTED]> wrote: > HMm, i'd just record it for all of them, since the [fields] are accessible > through a pointer to the structure. They are indeed accessible this way... > Just because you can't directly take the address of a bitfield doesn't > mean you can'

Re: Fixing m68hc11 reorg after dataflow merge

On 6/16/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote: I need some help making m68hc11_reorg() work after the dataflow merge, in particular this bit: /* Re-create the REG_DEAD notes. These notes are used in the machine description to use the best assembly directives. */ if

RE: I'm sorry, but this is unacceptable (union members and ctors)

On 16 June 2007 19:54, michael.a wrote: > used to aide the compiler for further robustness. In the meantime, I would > very much appreciate it if you could share any specific directions towards > minimally hacking the g++ frontend to let the code through. The way I tend > to use these unions, is a

Re: I'm sorry, but this is unacceptable (union members and ctors)

David Fang wrote: > > > ... And when the said constructor is trivial (e.g. for POD), then you pay > nothing, zilch, nada. (same with placement delete) In C++, some things > you write (od don't write) are merely abstractions for what should happen, > which can represent 'nothing'. Only if yo

Re: I'm sorry, but this is unacceptable (union members and ctors)

Andrew Pinski-2 wrote: > > Huh? It can be used with stack variables, we have tests in the > testsuite where we use it with such. Thats not what google told me, I believe from every source I took a look at. > >> As for the discussion of unions, placement new is way too much overhead. >

Re: I'm sorry, but this is unacceptable (union members and ctors)

> On 6/16/07, michael.a <[EMAIL PROTECTED]> wrote: > > > > As for "placement new", from what I can find, it is unsafe to use with any > > memory that isn't part of the heap. > Huh? It can be used with stack variables, we have tests in the > testsuite where we use it with such. > > > As for the

Re: I'm sorry, but this is unacceptable (union members and ctors)

On 6/16/07, michael.a <[EMAIL PROTECTED]> wrote: As for "placement new", from what I can find, it is unsafe to use with any memory that isn't part of the heap. Huh? It can be used with stack variables, we have tests in the testsuite where we use it with such. As for the discussion of uni

Re: I'm sorry, but this is unacceptable (union members and ctors)

Joe Buck wrote: > > On Fri, Jun 15, 2007 at 08:00:24PM -0700, michael.a wrote: >> I've actually never seen "placement new" before I think. Its a useful way >> to >> "reconstruct" heaped memory, but not useful in anyway in the situation I >> described (which is really broader than any single fix

Re: Some thoughts about steerring commitee work

On Sat, Jun 16, 2007 at 04:02:39AM +0200, J.C. Pizarro wrote: > Please, to see > > 1. "The LLVM Compiler System" by Chris Lattner You have posted essentially the same message three times on three different threads. Chris Lattner himself has asked you to stop. If you'd prefer to use or work on L

Re: I'm sorry, but this is unacceptable (union members and ctors)

Brooks Moses-3 wrote: > > michael.a wrote: >> It would be interesting for someone to try to make a practical argument >> that >> is anything but a nest of technicalities, as to why ctors and unions >> shouldn't be mixable. > > The Fortran language specification allows essentially this, althoug

Re: RFC: Make dllimport/dllexport imply default visibility

Daniel Jacobowitz wrote: > This doesn't make a lick of sense to me. If the type is hidden, how > on earth can it get a member function _of that type_ from another > library? That library would, by definition, have to have a type of > the same name... but it would be a "different" type. You and

Re: I'm sorry, but this is unacceptable (union members and ctors)

On Fri, Jun 15, 2007 at 08:00:24PM -0700, michael.a wrote: > I've actually never seen "placement new" before I think. Its a useful way to > "reconstruct" heaped memory, but not useful in anyway in the situation I > described (which is really broader than any single fix) I disagree; placement new i

init-regs pass initializes virtual-stack-vars?

Hello! There is something strange going on, it looks that initialization of virtual-stack-vars register in init-regs pass confuses greg. In 154r.regclass we have this sequence: (insn 326 325 327 46 1804.c:1981 (clobber (mem/s/c:BLK (plus:DI (reg/f:DI 54 virtual-stack-vars) (co

Re: Status of simulator targets after dataflow merge

On Sat, Jun 16, 2007 at 05:31:02PM +0200, Rask Ingemann Lambertsen wrote: The following targets worked as of "4.3.0 20070609" but don't any longer (going by my own attempts to them build as well as missing postings to gcc-testresults by mstein): m68hc11-unknown-none http://gcc.gnu.org/ml/gcc

Re: I'm sorry, but this is unacceptable (union members and ctors)

Robert Dewar writes: >The only time that it is reasonable to extend is when there are clear >signals from the standards committee that it is likely that a feature >will be added, in which case there may be an argument for adding the >feature "prematurely". I completely disagree. Standards should

Re: I'm sorry, but this is unacceptable (union members and ctors)

David Fang wrote: > > <$.02> > It's not highly techinical to see the fundamental difficulty with > mixing ctor/dtors and unions. At the core of C++ is the association with > constructors as initialization actions at the beginning of an object's > lifetime, and likewise destructors associ

Re: I'm sorry, but this is unacceptable (union members and ctors)

michael.a wrote: Extensions are harmless as long as authors clearly understand the pitfalls they offer and mandatory compile options are required to enact them. The line should be drawn somewhere naturally, granted the philosophy of a particular implementation. GCC being the premier compiler for

Re: I'm sorry, but this is unacceptable (union members and ctors)

Robert Dewar wrote: > > > I think there is a lot of merit in > > a) C++ programmers writing in C++ and not idiosyncratic dialects > b) C++ compilers implementing C++ and not idiosyncratic dialects > > Certainly if you are interested in porting code, as seems to be the > case here, following

Re: Some thoughts about steerring commitee work

On 6/16/07, Dorit Nuzman <[EMAIL PROTECTED]> wrote: > H. J. Lu wrote: > > >On Fri, Jun 15, 2007 at 06:21:53PM -0700, Ian Lance Taylor wrote: > Vectorizer is a big a project and may be we will see more improvements > in future. They promissed implement SLP two years ago and now I see it > happ

Re: Some thoughts about steerring commitee work

> On Fri, Jun 15, 2007 at 11:33:52PM -0400, Vladimir N. Makarov wrote: > > H. J. Lu wrote: > > ... > > > > > > > > A mount ago I did some measurements of the effect of the vectorizer for > > Core2 in 64-bit mode. Unfortunately, I saw small improvement (as I > > remember less than 1% for SPECInt20

Re: Some thoughts about steerring commitee work

> H. J. Lu wrote: > > >On Fri, Jun 15, 2007 at 06:21:53PM -0700, Ian Lance Taylor wrote: > > > > > >>This is hardly a new thought, but I believe that for the i386 gcc is > >>handicapped by reload. No matter how smart we are before reload, it > >>just take one poor decision by reload in an inner lo

Re: Access to raw repositories

Bernardo Innocenti <[EMAIL PROTECTED]> writes: > Andreas Schwab wrote: >> Bernardo Innocenti <[EMAIL PROTECTED]> writes: >> >>> I'm a GCC maintainer, but I don't have a full shell account on >>> sources.redhat.com. Anything that would provide rsync access >>> would suffice. >> >> See

Status of simulator targets after dataflow merge

The following targets worked as of "4.3.0 20070609" but don't any longer (going by my own attempts to them build as well as missing postings to gcc-testresults by mstein): m68hc11-unknown-nonehttp://gcc.gnu.org/ml/gcc/2007-06/msg00455.html m32c-unknown-elfhttp://gcc.gnu.org/bugzilla

PR other/32351 [Was: Re: GCC Status Report (2007-06-15)]

Hello! BTW, an x86 DFP configure bug was reported 3 months ago. But it still hasn't benen fixed. I opened a DFP bug report: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32351 with a patch. I hope it will be fixed before gcc 4.3 is released :-). So, is this bug a configure bug, DFP bug or x

Re: Some thoughts about steerring commitee work

> On Fri, Jun 15, 2007 at 06:21:53PM -0700, Ian Lance Taylor wrote: > > > > This is hardly a new thought, but I believe that for the i386 gcc is > > handicapped by reload. No matter how smart we are before reload, it > > just take one poor decision by reload in an inner loop and we've lost > > all

Re: Access to raw repositories

Andreas Schwab wrote: Bernardo Innocenti <[EMAIL PROTECTED]> writes: I'm a GCC maintainer, but I don't have a full shell account on sources.redhat.com. Anything that would provide rsync access would suffice. See . Great. Is there anything similar for the src

Re: Some thoughts about steerring commitee work

Richard Kenner wrote: The second, it was a bit suspicious to me that in one day two Google guys got global maintainership although as I wrote Diego did not work on rtl for a long time. One the other hand, I see Google has a good developers and may be I was a bit paranoid. Right. A fe

Re: Some thoughts about steerring commitee work

On Fri, Jun 15, 2007 at 11:33:52PM -0400, Vladimir N. Makarov wrote: > H. J. Lu wrote: > > >On Fri, Jun 15, 2007 at 06:21:53PM -0700, Ian Lance Taylor wrote: > > > > > >>This is hardly a new thought, but I believe that for the i386 gcc is > >>handicapped by reload. No matter how smart we are bef

Re: Some thoughts about steerring commitee work

On Fri, Jun 15, 2007 at 07:17:22PM -0700, Andrew Pinski wrote: > On 6/15/07, H. J. Lu <[EMAIL PROTECTED]> wrote: > > > >Why don't we turn on vectorizer at -O3 or even -O2, depending on > >ISA? I added -ftree-vectorize to BOOT_CFLAGS on x86-64. According to > >-ftree-vectorizer-verbose=1, there are

Re: GCC Status Report (2007-06-15)

On Fri, Jun 15, 2007 at 03:39:49PM -0700, Mark Mitchell wrote: > in the relatively near future. I am also considering the Intel BID > patches for 4.3, as those have arrived just under the wire. I would > appreciate comments from relevant maintainers about those patches. > Who are those relevant

Re: I'm sorry, but this is unacceptable (union members and ctors)

michael.a wrote: My general opinion is it serves no one to be regressive about extensions. I think there is a lot of merit in a) C++ programmers writing in C++ and not idiosyncratic dialects b) C++ compilers implementing C++ and not idiosyncratic dialects Certainly if you are interested in p

Fixing m68hc11 reorg after dataflow merge

I need some help making m68hc11_reorg() work after the dataflow merge, in particular this bit: /* Re-create the REG_DEAD notes. These notes are used in the machine description to use the best assembly directives. */ if (optimize) { /* Before recomputing the REG_DEAD notes,

Re: Incorrect bitfield aliasing with Tree SSA

> HMm, i'd just record it for all of them, since the [fields] are accessible > through a pointer to the structure. They are indeed accessible this way... > Just because you can't directly take the address of a bitfield doesn't > mean you can't access one through a pointer, which is the entire > p

Re: RFC: Make dllimport/dllexport imply default visibility

On Jun 15, 2007, at 4:47 PM, Mark Mitchell wrote: Chris Lattner wrote: This construct seems like it should be rejected by the C++ front-end. The source is making two contradictory claims: the struct is not visible outside this library, but part of it is implemented outside of it. I don't th