Is ada's "make install" parallel-safe?
Hi list, Running "make -j8 install" in a fresh build of head, I saw loads of the following error messages coming out in the log: > cp: cannot create regular file > `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a-ztmoau.adb': > File exists cp: cannot create regular file > `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a-ztmoio.adb': > File exists cp: cannot create regular file > `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a-zttest.ads': > File exists cp: cannot create regular file > `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a-zzboio.ads': > File exists cp: cannot create regular file > `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/ada.ads': > File exists cp: cannot create regular file > `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/directio.ads': > File exists [ ... snip ... ] Sure enough, all the files did exist, so I guess it must have been trying to install them twice. Before I try digging deeper, I thought I'd quickly ask: Does anyone else see this? (Is it perhaps something that wouldn't show up on a different host, such as linux, owing to differing filesystem semantics?) cheers, DaveK
Re: volatile correctness: combine vs. target.md
On Sat, Dec 3, 2011 at 12:42 AM, Richard Henderson wrote:
> On 12/02/2011 06:35 AM, Richard Guenther wrote:
>> I see. As we do not explicitely model this dependency we probably
>> get lucky by the if (gimple_has_volatile_ops ()) bail-out; most
>> passes do.
>
> What are you talking about? Of course we do.
>
>> int
>> read_dependence (const_rtx mem, const_rtx x)
>> {
>> return MEM_VOLATILE_P (x) && MEM_VOLATILE_P (mem);
>> }
>
> et al.
Not if you look at the respective gimple level dependency routines
in tree-ssa-alias.c, OTOH tree-data-ref.c simply refuses to handle
volatile references at all.
Richard.
>
> r~
Re: volatile correctness: combine vs. target.md
On 12/03/2011 06:30 AM, Richard Guenther wrote: > Not if you look at the respective gimple level dependency routines > in tree-ssa-alias.c, OTOH tree-data-ref.c simply refuses to handle > volatile references at all. That's something we'd better fix, then, regardless of whether some pass currently refuses to handle them. r~
gcc-4.7-20111203 is now available
Snapshot gcc-4.7-20111203 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20111203/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 181975 You'll find: gcc-4.7-20111203.tar.bz2 Complete GCC MD5=229576f4cead16c8c29a356bae69dd88 SHA1=e2547126460407521a2827b13e30b15203eb881c Diffs from 4.7-2026 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 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.
Re: Creating a structure at compile time.
On Fri, Dec 2, 2011 at 3:38 PM, Matt Davis wrote: > I am working on a gcc-plugin where I need to create a structure at compile > time. > I have gleaned over one of the front ends to learn more about creating > structures at compile time. What I have thus far is a type node for my > struct. > > I now need to create an instance of this struct. For exemplary purposes we > will > call this type 'struct T' and we will call the instance of T, 'my_T' By using > the build_constructor() routine in GCC I create an instance, my_T, which I > need > to pass the address of to a function. So, I take this decl, my_T, and pass > it to > build_fold_addr_expr(). The result of the latter is what I pass to the > function 'fn()'. > > Yes, the function I am passing the reference to is expecting the proper type, > that of address-to-T. Running this presents me with an error in > expand_expr_real_1() where "Variables inherited from containing functions > should > have been lowered by this point." > > So, I figure, if I create a temp variable, 'V', of type pointer-to-T, and run > make_ssa_name() on that temp. And then insert an assignment before the call > to > fn, so I get: 'V = &my_T;' After looking at the GIMPLE dump, I see, 'V = > &my_T; > fn(V);' Which is correct, however, in the type list of the caller, I only > see: > 'struct * V;' Now, this concerns me, I would expect to see "struct T *V;" As > above, this case also fails. > > I am baffled, do I need to even be creating the ssa_name instance to pass to > 'fn()', which is 'V' in the case above? Or, will the build_constructor() > produce a tree node that I can treat as a variable, that I can pass to 'fn()' > ? > > -Matt Well, I have successfully created and used an initialized structure. Note that I do not need to run the make_ssa_name. I can declare the struct as TREE_STATIC and work from there. Now, my problem with the expand_expr_real_1 check failing is because some of the values I initialize in my compile-time created struct can be different at runtime. Is there a way I can take this constructor tree node, and have all of the values in it set in the middle of my function, where those values are defined? I do not need the structure initialized upon function entry. What I need is to have all of the values, which I already setup when I am in the middle of the function being processed. I need these values actually filled-out in the middle of function instead at function entry. I am unsure how to do this. The constructor node exists, and I'm in the middle of an IPA pass. I assume I can call gimplify_expr() but I am thinking I need to pass it something different than just a constructor tree node. Thanks for any help -Matt
