Re: [PATCH] PR target/71549: Convert V1TImode register to TImode in debug insn
On 06/20/16 04:55:16, H.J. Lu wrote: > TImode register referenced in debug insn can be converted to V1TImode > by scalar to vector optimization. We need to convert a debug insn if > it has a variable in a TImode register. Hello, We have a situation on a few of the UPC tests, where they ICE on this gcc_assert(). 3820 gcc_assert (REG_P (loc) 3821 && GET_MODE (loc) == V1TImode); (gdb) p val $2 = (rtx) 0x7fffef6d3978 (gdb) pr warning: Expression is not an assignment (and might have no effect) (var_location:TI newval (subreg:TI (reg/v/f:V1TI 307 [ newval ]) 0)) (gdb) p loc $1 = (rtx) 0x7fffef409210 (gdb) pr warning: Expression is not an assignment (and might have no effect) (subreg:TI (reg/v/f:V1TI 307 [ newval ]) 0) As you can see, 'loc' is already a TI mode subreg based upon a V1TI mode reg. I didn't try tracking down how we end up with 'loc' as a subreg, but will note that in UPC the pointer-to-shared representation is a 16 byte struct, aligned on 16 bytes, so the generated code will frequently deal with TImode values in registers. Given the code that follows this assert, 3822 /* Convert V1TImode register, which has been updated by a SET 3823 insn before, to SUBREG TImode. */ 3824 PAT_VAR_LOCATION_LOC (val) = gen_rtx_SUBREG (TImode, loc, 0); 3825 df_insn_rescan (insn); converts the V1TImode register into a TImode subreg, and we already have that situation, I tried the following patch: --- /a/gcc-trunk/gcc/config/i386/i386.c 2016-06-26 19:01:12.099740515 -0700 +++ config/i386/i386.c 2016-06-28 11:17:26.323396045 -0700 @@ -3814,6 +3814,9 @@ continue; gcc_assert (GET_CODE (val) == VAR_LOCATION); rtx loc = PAT_VAR_LOCATION_LOC (val); + /* If already a SUBREG, skip. */ + if (SUBREG_P (loc)) + continue; gcc_assert (REG_P (loc) && GET_MODE (loc) == V1TImode); /* Convert V1TImode register, which has been updated by a SET Can the patch be amended to include this fix? Let me know if you need additional information, or would like me to try something else.
Re: [UPC 07/22] lowering, pointer-to-shared ops
On 12/01/15 12:42:48, Richard Biener wrote:
> On Mon, 30 Nov 2015, Gary Funck wrote:
> [...]
> > + get_lc_mode_name (mname, (op_mode));
> > + sprintf (libfunc_name, "__get%s%s%s%s",
> > + strict_mode ? "s" : "",
> > + doprofcall ? "g" : "",
> > + mname,
> > + (op_mode == BLKmode)
> > +? (doprofcall ? "5" : "3")
> > +: (doprofcall ? "3" : "2"));
> > + libfunc = identifier_global_value (get_identifier (libfunc_name));
> > + if (!libfunc)
> > +internal_error ("UPC runtime function %s not found", libfunc_name);
>
> I think for all these you should use builtins. You definitely shouldn't
> ICE here if it is an error to not include upc.h (or whatever is required
> to make above lookup succeed).
For UPC, although a reference via a pointer-to-shared will often
access data on another node, fairly often the reference will be
on node or will be local to the current process. It is a worthwhile
optimization to inline the runtime call because the number of instructions
to test if a reference is on-node or local and to then load/store
directly to that location is small/short relative to the overhead of
making the call. On some micro-benchmarks, inlining is 30% faster
for get/put accesses.
Inlining is implemented with a pre-include of "gcc-upc.h", which
in turn includes "gcc-upc-lib.h", which defines the API to
the libgupc runtime library. At optimization levels greater than 0,
gcc-upc-lib.h will implement many UPC runtime procedures as
inline procedures. This inlining can be disabled with -fupc-no-inline-lib.
The pre-include can be disabled with -fupc-no-pre-include, but
this is typically only done by certain tests. The pre-include
will be enabled by default if -fupc is asserted.
Thus,
- We need to bring in the inlined runtime procedures via
the pre-include.
- If we're compiling UPC, then the runtime header file
will be pre-included, unless explicitly disabled via
-fupc-no-pre-include (which is ill-advised for regular users).
It is effectively an internal error, if we can't find
the runtime procedures.
Regarding builtins, if we were to contemplate generating
code that makes this locality check and then issuing
a direct access for local/on-node accesses, it would
likely be impractical because different runtime libraries
will implement this locality check and local reference
differently.
- Gary
Re: [UPC 07/22] lowering, pointer-to-shared ops
On 12/01/15 12:42:48, Richard Biener wrote:
> On Mon, 30 Nov 2015, Gary Funck wrote:
> [...]
> > + if (bitpos)
> > +{
> > + t_offset = size_int (bitpos / BITS_PER_UNIT);
> > + if (offset)
> > + t_offset = fold (build_binary_op (loc, PLUS_EXPR,
> > + offset, t_offset, 0));
>
> Don't use fold (). If you want a simplified tree don't go
> through build_binary_op but use fold_build2. In this case
> it looks you want to use size_binop anyway.
OK
Regarding size_binop(), I'll need to review the code.
There are places that we need to retain sign and use
signed size types for example.
> > +}
> > + else
> > +t_offset = offset;
> > + {
> > +const tree base_addr_type = TREE_TYPE (base_addr);
> > +const enum tree_code cvt_op =
> > + lang_hooks.types_compatible_p (upc_char_pts_type_node, base_addr_type)
> > + ? NOP_EXPR : CONVERT_EXPR;
>
> NOP and CONVERT are the same.
I haven't followed every GCC changes/re-org closely, but my impression
is that there has been a move to make NOP and CONVERT the same.
Is that correct?
We retain CONVERT's between UPC pointer-to-shared that are not
equivalent and that require some special logic to inter-operate
or convert them. The UPC lowering pass handles those special cases.
Those conversions are not NOP's. For example, a floating point
to integer conversion isn't a no-op.
Could use some additional guidance here.
Re: [UPC 14/22] constant folding changes
On 12/01/15 12:46:01, Richard Biener wrote: > On Mon, 30 Nov 2015, Gary Funck wrote: > > UPC pointers-to-shared (aka shared pointers) are not interchangeable > > with integers as they are in regular "C". Therefore, additions > > and subtraction operations which involve UPC shared pointers > > should not be further simplified. > > This looks worrysome. I suppose this applies to simplifications > done before lowering only? If so I wonder if not using regular > plus/minus/convert/nop for operations on UPC shared pointers is > better than introducing this kind of checks. I suppose that is a possibility. We could introduce UPC_POINTER_PLUS, UPC_POINTER_CONVERT, and so-on as needed. Just not sure how many places that for example, UPC_POINTER_PLUS will keep showing up alongside POINTER_PLUS and similarly UPC_POINTER_CONVERT and CONVERT. After lowering, All UPC-specific operations have been replaced with the GENERIC code that implements them. We still retain the UPC pointer-to-shared types in the tree, rather than lowering everything to the internal representation of the pointer-to-shared type. I recall trying to replace pointers-to-shared with their internal representation and ran into some issues. I think one of them is that procedures accepting pointers-to-shared as parameters would have an apparent type mis-match. It might have impacted debug info. generation as well. Just don't recall. - Gary
Re: [UPC 02/22] tree-related changes
On 12/03/15 12:07:35, Richard Biener wrote: > On Wed, 2 Dec 2015, Gary Funck wrote: > > OK. As I mentioned in a previous reply, originally we prefixed > > all "UPC" specific tree node fields and functions with UPC_ or upc_, > > but as we transitioned away from UPC as a separate language > > (ala ObjC) and made compilation conditional upon -fupc, an > > observation was made off list that since the base tree nodes > > are generic that naming UPC-related fields with "UPC" prefixes > > didn't make sense, so we removed those prefixes. There might > > be a middle ground, however, whee UPC_SHARED_TYPE_P() is preferred > > to SHARED_TYPE_P() because as you/others have mentioned, > > the term "shared" gets used in a lot of contexts. > > Yes, specifically for predicates/functions used in the middle-end. OK > > > > + outer_is_pts_p = (POINTER_TYPE_P (outer_type) > > > > +&& SHARED_TYPE_P (TREE_TYPE (outer_type))); > > > > + inner_is_pts_p = (POINTER_TYPE_P (inner_type) > > > > +&& SHARED_TYPE_P (TREE_TYPE (inner_type))); > > > > + > > > > + /* Pointer-to-shared types have special > > > > + equivalence rules that must be checked. */ > > > > + if (outer_is_pts_p && inner_is_pts_p > > > > + && lang_hooks.types_compatible_p) > > > > +return lang_hooks.types_compatible_p (outer_type, inner_type); > > > > > > Sorry, but that can't fly with LTO. > > > > Can you elaborate? I'm not familiar with LTO or its requirements. > > With LTO the langhooks from the frontends are no longer available > so you'd need to implement the same logic in the LTO "frontend" > which means it wouldn't need a langhook at all because all information > would be contained in the middle-end representations. Still not quite understanding this one. Will need to take a more detailed look at LTO. > > We would also still need to make sure that the parts of the > > compiler that think that pointers are interchangeable with > > integers doesn't do that with UPC pointers-to-shared. > > I'm not very familiar with address-spaces but at least they > can be used to distinguish different pointer kinds (and prevent > conversions). Not sure if it would allow different behavior > for a simple plus. > > Note that I belive you should lower your "pointer" representation > when you lower the rest (I suppose you lower this now only during > RTL generation?) We lower all *operations* (plus/minus, get/put, conversions) in the UPC lowering pass, which runs just before c_genericize(). We retain the pointer-to-shared-qualified type in the tree, often wrapped by a conversion to the internal representation type. As I mentioned previously, we ran into some issues try to lower to just the representation type, but I don't recall the specifics. I can try and check on that. The RTL will see the pointer-to-shared types, but won't see things like indirections through them, addition/subtraction and so on, because that was handled in the lowering pass. We could probably lower most all things in the front-end when the program is being parsed, but it would make the initial tree difficult to understand and would push the lowering logic into front-end/parser which makes the implementation less modular. > > > Use a function please. No such unwiedlingly large macros. > > > > OK. Are static inline's OK here? > > Implementations in non-headers are prefered, but yes. I doubt that performance will be impacted much by making the call out-of-line. Will take a look into whether that is feasible. > > > > +/* UPC pointer to shared qualified object representation */ > > > > +#define upc_pts_rep_type_node global_trees[TI_UPC_PTS_REP_TYPE] > > > > +#define upc_char_pts_type_node global_trees[TI_UPC_CHAR_PTS_TYPE] > > > > +#define upc_phase_field_node global_trees[TI_UPC_PHASE_FIELD] > > > > +#define upc_thread_field_node global_trees[TI_UPC_THREAD_FIELD] > > > > +#define upc_vaddr_field_node global_trees[TI_UPC_VADDR_FIELD] > > > > +#define upc_null_pts_node global_trees[TI_UPC_NULL_PTS] > > > > + > > > > > > Ugh. Please no further global tree nodes. > > > Do you really need all of them in middle-end code? > [...] > After gimplification. I realize the global trees are in a messy > state already and most of them should be moved to frontend specific > places. It would be a start if you do that. And lowering your > pointer representation earlier will probably make that easier. I will review the code to see if they can be moved to front-end specific procedures/files.
Re: RFC: Merge the GUPC branch into the GCC 6.0 trunk
On 12/02/15 10:40:50, Richard Biener wrote: > On Tue, 1 Dec 2015, Gary Funck wrote: > > The main change recommended to reduce tree space was moving the > > "layout factor" (blocking factor) out of the tree node, and using > > only two bits there, one bit for a relatively common case of 0, > > and the other for > 1. It was suggested that we use a hash > > table to map tree nodes to layout qualifiers for the case they > > are > 1. This necessitated using a garbage collected tree map, > > which unfortunately meant that tree nodes needed special garbage > > collection logic. > > I still don't see why it needs special garbage collection logic. > We have many tree -> X maps that just get away without. > [...] > As said, I don't see why you need a special GC collection logic > at all. Please explain. The problem we ran into is that we had a tree map which mapped a tree node to its UPC layout qualifier, which is an integral constant (CST). Tree nodes for CST's are made unique by hashing them into an integer->tree map. What happened is that the GC would free up entries in the CST table that were being used by the layout qualifier map. It seems that the new tree map logic fixes this problem (as you've noted). I backed out the custom GC logic and re-ran a large test that extensively exercises the use case that triggers the issue -- works like a charm. thanks, - Gary
Re: [UPC 01/22] front-end changes
On 12/01/15 09:12:44, Eric Botcazou wrote: > > All languages (c, c++, fortran, go, lto, objc, obj-c++) have been > > bootstrapped; no test suite regressions were introduced, > > relative to the GCC trunk. > > That's not all languages though, Ada and Java are missing. Full bootstrap, no regressions relative to trunk for: ada,c,c++,fortran,go,java,lto,objc,obj-c++ Didn't do jit in this build, will add it in.
Re: [UPC 02/22] tree-related changes
On 12/01/15 12:26:32, Richard Biener wrote:
> On Mon, 30 Nov 2015, Gary Funck wrote:
> > -struct GTY(()) tree_type_common {
> > +struct GTY((user)) tree_type_common {
> >struct tree_common common;
> >tree size;
> >tree size_unit;
> > @@ -1441,10 +1458,10 @@ struct GTY(()) tree_type_common {
> >tree pointer_to;
> >tree reference_to;
> >union tree_type_symtab {
> > -int GTY ((tag ("TYPE_SYMTAB_IS_ADDRESS"))) address;
> > -const char * GTY ((tag ("TYPE_SYMTAB_IS_POINTER"))) pointer;
> > -struct die_struct * GTY ((tag ("TYPE_SYMTAB_IS_DIE"))) die;
> > - } GTY ((desc ("debug_hooks->tree_type_symtab_field"))) symtab;
> > +int address;
> > +const char *pointer;
> > +struct die_struct *die;
> > + } symtab;
>
> Err, you don't have debug info for this? What is address?
Not sure what you mean. The 'die' field is retained.
Is there something in the semantics of "GTY(( ((tag "
that relates to debug information?
> I do not like the explict GC of tree_type_common.
I'm not a fan either.
The gist is that we needed a map from tree nodes to tree nodes
to record the "layout qualifier" for layout qualifiers with
a value greater than one. But when the garbage collector ran
over the hash table that maps integer constants to tree nodes,
it didn't know that the constant was being referenced by the
layout qualifier tree map.
We described the issue here:
https://gcc.gnu.org/ml/gcc-patches/2011-10/msg00800.html
The conclusion that we reached is that when tree nodes
were walked, we needed to check if there was a
tree node -> integer constant mapping, the integer constant map
(used to make tree nodes used to hold CST's unique)
needed to be marked to keep the CST mapping from going away.
This led to the conclusion that a custom GC routine was
needed for tree nodes. Maybe that conclusion is wrong or
there is a better way to do things?
> > ===
> > --- gcc/tree-pretty-print.c (.../trunk) (revision 231059)
> > +++ gcc/tree-pretty-print.c (.../branches/gupc) (revision 231080)
> > @@ -1105,6 +1105,25 @@ dump_block_node (pretty_printer *pp, tre
> > }
> >
> >
> > +static void
> > +dump_upc_type_quals (pretty_printer *buffer, tree type, int quals)
>
> Functions need comments.
OK. Missed that one. Will check on others.
> > Index: gcc/tree-sra.c
> > ===
> > --- gcc/tree-sra.c (.../trunk) (revision 231059)
> > +++ gcc/tree-sra.c (.../branches/gupc) (revision 231080)
> > @@ -3882,6 +3882,7 @@ find_param_candidates (void)
> >
> > if (TREE_CODE (type) == FUNCTION_TYPE
> > || TYPE_VOLATILE (type)
> > + || SHARED_TYPE_P (type)
>
> UPC_SHARED_TYPE_P ()
OK. As I mentioned in a previous reply, originally we prefixed
all "UPC" specific tree node fields and functions with UPC_ or upc_,
but as we transitioned away from UPC as a separate language
(ala ObjC) and made compilation conditional upon -fupc, an
observation was made off list that since the base tree nodes
are generic that naming UPC-related fields with "UPC" prefixes
didn't make sense, so we removed those prefixes. There might
be a middle ground, however, whee UPC_SHARED_TYPE_P() is preferred
to SHARED_TYPE_P() because as you/others have mentioned,
the term "shared" gets used in a lot of contexts.
> > @@ -4381,6 +4422,7 @@ build1_stat (enum tree_code code, tree t
> >/* Whether a dereference is readonly has nothing to do with whether
> > its operand is readonly. */
> >TREE_READONLY (t) = 0;
> > + TREE_SHARED (t) = SHARED_TYPE_P (type);
>
> This is frontend logic and should reside in FEs.
[... several other similar actions taken contingent
upon SHARED_TYPE_P() elided ...]
OK, will take a look.
> > + outer_is_pts_p = (POINTER_TYPE_P (outer_type)
> > +&& SHARED_TYPE_P (TREE_TYPE (outer_type)));
> > + inner_is_pts_p = (POINTER_TYPE_P (inner_type)
> > +&& SHARED_TYPE_P (TREE_TYPE (inner_type)));
> > +
> > + /* Pointer-to-shared types have special
> > + equivalence rules that must be checked. */
> > + if (outer_is_pts_p && inner_is_pts_p
> > + && lang_hooks.types_compatible_p)
> > +return lang_hooks.types_compatible_p (outer_type, inner_type);
>
> Sorry, but that can't fly with LTO.
Can you elaborate? I'm not familiar with LTO or its requirements.
> I wonder why you didn't use address-spaces for whatever
> UP
Re: RFC: Merge the GUPC branch into the GCC 6.0 trunk
On 12/01/15 12:19:48, Bernd Schmidt wrote:
> On 12/01/2015 06:31 AM, Gary Funck wrote:
> >At this time, we would like to re-submit the UPC patches for comment
> >with the goal of introducing these changes into GCC 6.0.
>
> This has missed stage 1 by a few weeks, we'd have to make an exception to
> include it at this late stage.
Based upon the feedback, it looks like GCC 6.0 is not feasible.
>
> >@@ -857,9 +875,14 @@ struct GTY(()) tree_base {
> >unsigned user_align : 1;
> >unsigned nameless_flag : 1;
> >unsigned atomic_flag : 1;
> >- unsigned spare0 : 3;
> >-
> >- unsigned spare1 : 8;
> >+ unsigned shared_flag : 1;
> >+ unsigned strict_flag : 1;
> >+ unsigned relaxed_flag : 1;
> >+
> >+ unsigned threads_factor_flag : 1;
> >+ unsigned block_factor_0 : 1;
> >+ unsigned block_factor_x : 1;
> >+ unsigned spare1 : 5;
>
> That's a lot of bits used up at once.
I provided some additional background in my reply to Richard.
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00136.html
> Does this solve anything that cannot be done with OpenMP, which we already
> support?
UPC's target use is similar to that of Co-Array Fortran (CAF),
mainly multi-node computations in addition to multi-core.
Also, in the sense that UPC makes syntactic extensions
it is arguably easier to write and to understand UPC programs
than the pragma based approach used by OpenMP and Cilk, or
library based solutions like MPI.
Here is an example application, parallel merge sort,
written in MPI, OpenMP, UPC, hybrid MPI/OpenMP,
and hybrid UPC/OpenMP which illustrates how they
compare in terms of expressivity. In general, the
bulks synchronous UPC implementation out-performs
the others.
https://github.com/gary-funck/parallel-merge-sort
> Can you show us any users of this that demonstrate that this is
> actually in use by anyone outside the universities responsible for UPC?
It is primarily used in universities and research labs.
Cray, IBM, and HP offer their own commercial compilers on
their HPC platforms. Berkeley has an open UPC-to-C translator
and we have separately built a Clang-based compiler and
source-to-source translator.
> The language standard is apparently from 2005 [...]
The spec was updated in 2013.
http://upc.lbl.gov/publications/upc-spec-1.3.pdf
> but I've never heard of it and
> googling "upc" does not give any sensible results. The gccupc mailing list
> seems to have been dead for years judging by the archives. I'm worried we'll
> end up carrying something around as a burden that is of no practical use
> (considering we already support the more widespread OpenMP).
UPC is more similar to Co-Array Fortran (CAF) than OpenMP.
I don't keep up with developments in the OpenMP or OpenACC standards,
so am unaware of proposals to generalize them for multi-node
HPC applications. As mentioned, IMO, UPC is more expressive
than OpenMP (which is pragma based). Their programming
models are also different. UPC is SIMD, and OpenMP uses
dynamic task dispatching.
Regarding a possible "burden", we have tried to modularize
the changes to minimize impact on the compiler.
We floated the idea of including UPC in GCC a few years back;
there were no objections at that time. In the mean time,
we have been implementing changes based upon feedback,
porting the runtime to other communication layers
and implementing the changes needed to conform
to the 2013 UPC specification.
thanks,
- Gary
Re: [UPC 15/22] RTL changes
On 12/02/15 13:10:44, Richard Guenther wrote: > On Tue, Dec 1, 2015 at 7:02 AM, Gary Funck <g...@intrepid.com> wrote: > > UPC pointers-to-shared have an internal representation which is > > defined as a 'struct' with three fields. Special logic is > > needed in promote_mode() to handle this case. > > Errr - but how are 'struct's ever REFERENCE_TYPE or POINTER_TYPE? UPC pointers-to-shared types are pointer types, but they typically have a mode that is 2x the size of the normal pointer mode. Currently, 'upc_pts_type_node' is a global tree mode that describes the internal representation of a UPC pointer-to-shared. The code shown below takes the mode of 'upc_pts_type_node' (TIMode, typically on 64 bit targets) and returns that. As noted in an earlier reply, this mode could be saved in a global somewhere (similar to pointer_mode) which could be used to avoid the reference to 'upc_pts_type_node' below. > > +++ gcc/explow.c(.../branches/gupc) (revision 231080) > > @@ -794,6 +794,8 @@ promote_mode (const_tree type ATTRIBUTE_ > > case REFERENCE_TYPE: > > case POINTER_TYPE: > >*punsignedp = POINTERS_EXTEND_UNSIGNED; > > + if (SHARED_TYPE_P (TREE_TYPE (type))) > > +return TYPE_MODE (upc_pts_type_node); > >return targetm.addr_space.address_mode > >(TYPE_ADDR_SPACE (TREE_TYPE (type))); > >break; Asked in previous email: Can an address space be used for UPC pointers-to-shared? Yes, if TIMode were allowed, for example (on 64-bit targets), and that was the mode associated with th special UPC reserved address space number, it would take care of returning the proper mode for UPC pointers-to-shared types. Address spaces are insufficient however to handle the situations where the semantics of pointer arithmetic for UPC pointers-to-shared differs from those of regular "C" pointers, or for conversions, and situations where optimizations of operations involving "C" pointers do not apply to "UPC" shared pointers. So, we can't just dedicate an address space for UPC pointers-to-shared and be done with it. thanks, - Gary
Re: [UPC 01/22] front-end changes
On 12/01/15 09:12:44, Eric Botcazou wrote: > > All languages (c, c++, fortran, go, lto, objc, obj-c++) have been > > bootstrapped; no test suite regressions were introduced, > > relative to the GCC trunk. > > That's not all languages though, Ada and Java are missing. OK. I'll bootstrap and run tests on those as well, and report back in a day/two. thanks, - Gary
Re: RFC: Merge the GUPC branch into the GCC 6.0 trunk
On 12/01/15 12:12:29, Richard Biener wrote: > On Mon, 30 Nov 2015, Gary Funck wrote: > > At this time, we would like to re-submit the UPC patches for comment > > with the goal of introducing these changes into GCC 6.0. > > First of all let me say that it is IMNSHO now too late for GCC 6. I realize that stage 1 recently closed, and that if UPC were accepted for inclusion, it would be an exception. To offset potential risk, we perform weekly merges and run a large suite of tests and apps. on differing hosts/cpu architectures. We have also tried to follow the sorts of re-factoring and C++ changes made over the course of the last year/so. I'd just ask that the changes be given some further consideration for 6.0. > You claim bits in tree_base - are those bits really used for > all tree kinds? The qualifiers look type specific where > eventually FE specific flags in type-lang-specific parts could > have been used (yeah, there are no spare bits in tree_type_*). > Similar the _factor stuff should not be on all tree kinds. When we first started building the gupc branch, it was suggested that UPC be implemented as a separate language ala ObjC. In that case, we used "language bits". Over time, this approach fell out of favor, and we were asked to move everything into the C front-end and middle-end, making compilation contingent upon -fupc, which is the way it is now. Also, over the past couple of years, there has been work to minimize the number of bits used by tree nodes, so some additional changes were needed. The main change recommended to reduce tree space was moving the "layout factor" (blocking factor) out of the tree node, and using only two bits there, one bit for a relatively common case of 0, and the other for > 1. It was suggested that we use a hash table to map tree nodes to layout qualifiers for the case they are > 1. This necessitated using a garbage collected tree map, which unfortunately meant that tree nodes needed special garbage collection logic. It is worth noting that the "layout qualifier" is an integral constant, currently represented as a tree node reference. It might be possible to represent it as a "wide int" instead. I did give that a go once, but it rippled through the code making some things awkward. Perhaps not as awkward as a custom tree node GC routine; this could be re-visited. > I find the names used a bit unspecific, please consider > prefixing them with upc_ (esp. shared_flag may be confused > with the similar private_flag). When we previously asked for a review, it was noted that if the UPC bits were moved into what amounts to common/generic tree node fields that we should drop UPC_ or upc_ from the related node names and functions. That's what we did. There is some middle ground, for example, where only TYPE_SHARED_P() is renamed to UPC_SHARED_TYPE_P() and the rest remain as is. Since renames are straight forward, we can make any recommended changes quickly. Originally, we were keeping the door open for UPC++, but there are complications with generalizing C++ into a multi-node environment, and that idea has been tabled for now. Therefore, the current structure/implementation is C only, with most of the new front-end/middle-end logic under the c/ directory. > Are these and the new tree codes below living beyond the time > the frontend is in control? That is, do they need to survive > throughout the middle-end? I'm not sure where the line is drawn for the front-end and middle-end. After upc_genericize() runs (just before c_genericize()) all operations on tree nodes that are UPC-specific are lowered into operations on the internal representation of a pointer-to-shared and/or runtime calls that operate on the internal representation. The pointer-to-shared values/types still show up in the tree, but only as containers (pointers-to-shared are typically 2x the size of a regular "C" pointer). The places where SHARED_TYPE_P() is referenced in 'c/' and 'c-family/' are: c/c-convert.c c/c-objc-common.c c/c-upc-pts-ops.c c/c-parser.c c/c-typeck.c c/c-upc-low.c c/c-upc-lang.c c/c-decl.c c/c-upc.c c-family/c-common.c The places in the gcc top-level where SHARED_TYPE_P() is referenced are: convert.c explow.c fold-const.c function.c gimple-expr.c match.pd tree.c tree.h tree-sra.c The target-specific references are here: config/rs6000/rs6000.c config/i386/i386.c All of the references outside of c/ and c-family/ and tree.[ch] are to differentiate operations on UPC pointers-to-shared from regular "C" pointers. (Some/all of those references might be mitigated by defining new language hooks. We haven't looked into that.) It may be the case that in the current design, that only the "shared" bit is needed in the common (base?) tree node, as long as there is som
[UPC 08/22] target - Darwin
Background
--
An overview email, describing the UPC-related changes is here:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html
The GUPC branch is described here:
http://gcc.gnu.org/projects/gupc.html
The UPC-related source code differences are summarized here:
http://gccupc.org/gupc-changes
All languages (c, c++, fortran, go, lto, objc, obj-c++) have been
bootstrapped; no test suite regressions were introduced,
relative to the GCC trunk.
If you are on the cc-list, your name was chosen either
because you are listed as a maintainer for the area that
applies to the patches described in this email, or you
were a frequent contributor of patches made to files listed
in this email.
In the change log entries included in each patch, the directory
containing the affected files is listed, followed by the files.
When the patches are applied, the change log entries will be
distributed to the appropriate ChangeLog file.
Overview
For Darwin, if -fupc is given, then define various UPC-specific spec's.
Also, override default section names for the UPC-related linker sections.
2015-11-30 Gary Funck <g...@intrepid.com>
gcc/config/
* darwin.h (LINK_COMMAND_SPEC_A): If -fupc is asserted:
add UPC start/end files, add include of libgupc.spec
(UPC_SHARED_SECTION_NAME, UPC_PGM_INFO_SECTION_NAME,
UPC_INIT_ARRAY_SECTION_NAME): New. Override default section names.
Index: gcc/config/darwin.h
===
--- gcc/config/darwin.h (.../trunk) (revision 231059)
+++ gcc/config/darwin.h (.../branches/gupc) (revision 231080)
@@ -176,16 +176,19 @@ extern GTY(()) int darwin_ms_struct;
%{e*} %{r} \
%{o*}%{!o:-o a.out} \
%{!nostdlib:%{!nostartfiles:%S}} \
+
%{!nostdlib:%{!nostartfiles:%{fupc:%:include(upc-crtbegin.spec)%(upc_crtbegin)}}}\
%{L*} %(link_libgcc) %o
%{fprofile-arcs|fprofile-generate*|coverage:-lgcov} \
%{fopenacc|fopenmp|ftree-parallelize-loops=*: \
%{static|static-libgcc|static-libstdc++|static-libgfortran: libgomp.a%s;
: -lgomp } } \
%{fgnu-tm: \
%{static|static-libgcc|static-libstdc++|static-libgfortran: libitm.a%s;
: -litm } } \
+%{fupc:%:include(libgupc.spec)%(link_upc)} \
%{!nostdlib:%{!nodefaultlibs:\
%{%:sanitize(address): -lasan } \
%{%:sanitize(undefined): -lubsan } \
%(link_ssp) %(link_gcc_c_sequence)\
}}\
+
%{!nostdlib:%{!nostartfiles:%{fupc:%:include(upc-crtend.spec)%(upc_crtend)}}}\
%{!nostdlib:%{!nostartfiles:%E}} %{T*} %{F*} }}}"
#define DSYMUTIL "\ndsymutil"
@@ -922,6 +925,11 @@ extern void darwin_driver_init (unsigned
#undef SUPPORTS_INIT_PRIORITY
#define SUPPORTS_INIT_PRIORITY 0
+/* UPC section names */
+#define UPC_SHARED_SECTION_NAME "__DATA,upc_shared"
+#define UPC_PGM_INFO_SECTION_NAME "__DATA,upc_pgm_info"
+#define UPC_INIT_ARRAY_SECTION_NAME "__DATA,upc_init_array"
+
/* When building cross-compilers (and native crosses) we shall default to
providing an osx-version-min of this unless overridden by the User.
10.5 is the only version that fully supports all our archs so that's the
[UPC 06/22] target hooks
Background
--
An overview email, describing the UPC-related changes is here:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html
The GUPC branch is described here:
http://gcc.gnu.org/projects/gupc.html
The UPC-related source code differences are summarized here:
http://gccupc.org/gupc-changes
All languages (c, c++, fortran, go, lto, objc, obj-c++) have been
bootstrapped; no test suite regressions were introduced,
relative to the GCC trunk.
If you are on the cc-list, your name was chosen either
because you are listed as a maintainer for the area that
applies to the patches described in this email, or you
were a frequent contributor of patches made to files listed
in this email.
In the change log entries included in each patch, the directory
containing the affected files is listed, followed by the files.
When the patches are applied, the change log entries will be
distributed to the appropriate ChangeLog file.
Overview
Four new target hooks are defined for UPC. They relate to naming
the various linker sections used by UPC as well as testing for
the availability of the "UPC linker script" feature.
2015-11-30 Gary Funck <g...@intrepid.com>
gcc/
* defaults.h (UPC_SHARED_SECTION_NAME): New macro.
(UPC_PGM_INFO_SECTION_NAME): New macro.
(UPC_INIT_ARRAY_SECTION_NAME): New macro.
* target.def (upc): New hook prefix.
(link_script_p, shared_section_name,
pgm_info_section_name, init_array_section_name):
New target hook definitions.
* targhooks.c (default_upc_link_script_p,
default_upc_shared_section_name, default_upc_pgm_info_section_name,
default_upc_init_array_section_name): New default target hooks.
* targhooks.h (default_upc_link_script_p,
default_upc_shared_section_name, default_upc_pgm_info_section_name,
default_upc_init_array_section_name): New target hook prototypes.
Index: gcc/defaults.h
===
--- gcc/defaults.h (.../trunk) (revision 231059)
+++ gcc/defaults.h (.../branches/gupc) (revision 231080)
@@ -1488,4 +1488,23 @@ see the files COPYING3 and COPYING.RUNTI
#endif /* GCC_INSN_FLAGS_H */
+/* UPC section names. */
+
+/* Name of section used to assign addresses to shared data items. */
+#ifndef UPC_SHARED_SECTION_NAME
+#define UPC_SHARED_SECTION_NAME "upc_shared"
+#endif
+
+/* Name of section used to hold info. describing how
+ a UPC source file was compiled. */
+#ifndef UPC_PGM_INFO_SECTION_NAME
+#define UPC_PGM_INFO_SECTION_NAME "upc_pgm_info"
+#endif
+
+/* Name of section that holds an array of addresses that points to
+ the UPC initialization routines. */
+#ifndef UPC_INIT_ARRAY_SECTION_NAME
+#define UPC_INIT_ARRAY_SECTION_NAME "upc_init_array"
+#endif
+
#endif /* ! GCC_DEFAULTS_H */
Index: gcc/target.def
===
--- gcc/target.def (.../trunk) (revision 231059)
+++ gcc/target.def (.../branches/gupc) (revision 231080)
@@ -5496,6 +5496,41 @@ DEFHOOK
HOOK_VECTOR_END (cxx)
+/* Functions and data for UPC support. */
+#undef HOOK_PREFIX
+#define HOOK_PREFIX "TARGET_UPC_"
+HOOK_VECTOR (TARGET_UPC, upc)
+
+DEFHOOK
+(link_script_p,
+"This hook returns true if a linker script will be used to\
+ origin the UPC shared section at 0.",
+ bool, (void),
+ default_upc_link_script_p)
+
+DEFHOOK
+(shared_section_name,
+"This hook returns the name of the section used to assign addresses to\
+ UPC shared data items.",
+ const char *, (void),
+ default_upc_shared_section_name)
+
+DEFHOOK
+(pgm_info_section_name,
+"This hook returns the name of the section used to hold information\
+ describing how a UPC source file was compiled.",
+ const char *, (void),
+ default_upc_pgm_info_section_name)
+
+DEFHOOK
+(init_array_section_name,
+"This hook returns the name of the section used to hold an array\
+ of addresses of UPC initialization routines.",
+ const char *, (void),
+ default_upc_init_array_section_name)
+
+HOOK_VECTOR_END (upc)
+
/* Functions and data for emulated TLS support. */
#undef HOOK_PREFIX
#define HOOK_PREFIX "TARGET_EMUTLS_"
Index: gcc/targhooks.c
===
--- gcc/targhooks.c (.../trunk) (revision 231059)
+++ gcc/targhooks.c (.../branches/gupc) (revision 231080)
@@ -1955,4 +1955,32 @@ can_use_doloop_if_innermost (const wides
return loop_depth == 1;
}
+bool
+default_upc_link_script_p (void)
+{
+#ifdef HAVE_UPC_LINK_SCRIPT
+ return true;
+#else
+ return false;
+#endif
+}
+
+const char *
+default_upc_shared_section_name (void)
+{
+ return UPC_SHARED_SECTION_NAME;
+}
+
+const char *
+default_upc_pgm_info_section_name (void)
+{
+ return UPC_PGM_INFO_SECTION_NAME;
+}
+
+const char *
+default_upc_init
[UPC 09/22] target - x86
Background
--
An overview email, describing the UPC-related changes is here:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html
The GUPC branch is described here:
http://gcc.gnu.org/projects/gupc.html
The UPC-related source code differences are summarized here:
http://gccupc.org/gupc-changes
All languages (c, c++, fortran, go, lto, objc, obj-c++) have been
bootstrapped; no test suite regressions were introduced,
relative to the GCC trunk.
If you are on the cc-list, your name was chosen either
because you are listed as a maintainer for the area that
applies to the patches described in this email, or you
were a frequent contributor of patches made to files listed
in this email.
In the change log entries included in each patch, the directory
containing the affected files is listed, followed by the files.
When the patches are applied, the change log entries will be
distributed to the appropriate ChangeLog file.
Overview
UPC pointers-to-shared use a struct to describe their internal
representation. For efficiency and correctness, ensure that if the struct's
mode is TIMode that a pointer-to-shared parameter is passed in registers.
Note that the parameter passing logic forces "C" pointer type parameters
to be 'word mode', but that rule doesn't apply to UPC pointers-to-shared
due to their "fat" struct representation.
2015-11-30 Gary Funck <g...@intrepid.com>
gcc/config/i386/
* i386.c (classify_argument): check for UPC pointer-to-shared,
on 64-bit target.
(function_value_64): Do not force UPC pointers-to-shared
to be returned in word mode.
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (.../trunk) (revision 231059)
+++ gcc/config/i386/i386.c (.../branches/gupc) (revision 231080)
@@ -7943,6 +7943,15 @@ classify_argument (machine_mode mode, co
&& targetm.calls.must_pass_in_stack (mode, type))
return 0;
+ /* Special case check for pointer to shared, on 64-bit target. */
+ if (TARGET_64BIT && mode == TImode
+ && type && TREE_CODE (type) == POINTER_TYPE
+ && SHARED_TYPE_P (TREE_TYPE (type)))
+{
+ classes[0] = classes[1] = X86_64_INTEGER_CLASS;
+ return 2;
+}
+
if (type && AGGREGATE_TYPE_P (type))
{
int i;
@@ -9536,7 +9545,8 @@ function_value_64 (machine_mode orig_mod
return gen_rtx_REG (mode, regno);
}
- else if (POINTER_TYPE_P (valtype))
+ else if (POINTER_TYPE_P (valtype)
+ && !SHARED_TYPE_P (TREE_TYPE (valtype)))
{
/* Pointers are always returned in word_mode. */
mode = word_mode;
@@ -9680,6 +9690,11 @@ ix86_promote_function_mode (const_tree t
{
if (type != NULL_TREE && POINTER_TYPE_P (type))
{
+ if (SHARED_TYPE_P (TREE_TYPE (type)))
+{
+ *punsignedp = 1;
+ return TYPE_MODE (upc_pts_rep_type_node);
+ }
*punsignedp = POINTERS_EXTEND_UNSIGNED;
return word_mode;
}
[UPC 15/22] RTL changes
Background -- An overview email, describing the UPC-related changes is here: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html The GUPC branch is described here: http://gcc.gnu.org/projects/gupc.html The UPC-related source code differences are summarized here: http://gccupc.org/gupc-changes All languages (c, c++, fortran, go, lto, objc, obj-c++) have been bootstrapped; no test suite regressions were introduced, relative to the GCC trunk. If you are on the cc-list, your name was chosen either because you are listed as a maintainer for the area that applies to the patches described in this email, or you were a frequent contributor of patches made to files listed in this email. In the change log entries included in each patch, the directory containing the affected files is listed, followed by the files. When the patches are applied, the change log entries will be distributed to the appropriate ChangeLog file. Overview UPC pointers-to-shared have an internal representation which is defined as a 'struct' with three fields. Special logic is needed in promote_mode() to handle this case. 2015-11-30 Gary Funck <g...@intrepid.com> gcc/ * explow.c (promote_mode): For UPC pointer-to-shared values, return the mode of the UPC PTS representation type. Index: gcc/explow.c === --- gcc/explow.c(.../trunk) (revision 231059) +++ gcc/explow.c(.../branches/gupc) (revision 231080) @@ -794,6 +794,8 @@ promote_mode (const_tree type ATTRIBUTE_ case REFERENCE_TYPE: case POINTER_TYPE: *punsignedp = POINTERS_EXTEND_UNSIGNED; + if (SHARED_TYPE_P (TREE_TYPE (type))) +return TYPE_MODE (upc_pts_type_node); return targetm.addr_space.address_mode (TYPE_ADDR_SPACE (TREE_TYPE (type))); break;
[UPC 04/22] Make, Config changes
Background
--
An overview email, describing the UPC-related changes is here:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html
The GUPC branch is described here:
http://gcc.gnu.org/projects/gupc.html
The UPC-related source code differences are summarized here:
http://gccupc.org/gupc-changes
All languages (c, c++, fortran, go, lto, objc, obj-c++) have been
bootstrapped; no test suite regressions were introduced,
relative to the GCC trunk.
If you are on the cc-list, your name was chosen either
because you are listed as a maintainer for the area that
applies to the patches described in this email, or you
were a frequent contributor of patches made to files listed
in this email.
In the change log entries included in each patch, the directory
containing the affected files is listed, followed by the files.
When the patches are applied, the change log entries will be
distributed to the appropriate ChangeLog file.
Overview
UPC introduces a new runtime library, libgupc and a new compiler driver, gupc.
These are defined in the top-level Makefile.def and Makefile.tpl files.
The top-level configure script will disable building the libgupc runtime
library on unsupported targets. For builds where the target is the
same as the host, configure will check if "UPC linker scripts" can be
supported; this check can be over-ridden by the --enable-upc-linker-script
switch. This check runs a 'perl' script, it will only be run if the
host has perl installed.
2015-11-30 Gary Funck <g...@intrepid.com>
* Makefile.def (libgupc): New. Define libgupc module.
* Makefile.in: Re-generate.
* Makefile.tpl (BUILD_EXPORTS, EXTRA_TARGET_FLAGS):
Add GUPC and GUPCFLAGS.
(BASE_TARGET_EXPORTS, EXTRA_HOST_FLAGS): Add GUPC.
(GUPC_FOR_BUILD, GUPCFLAGS,
GUPC_FOR_TARGET, GUPCFLAGS_FOR_TARGET): New.
* configure: Re-generate.
* configure.ac (target_libraries): Add target-libgupc.
Disable libgupc on unsupported systems.
Add check for 'gupc' as target tool.
(GUPC_FOR_BUILD): New. Define 'gupc' as a target tool.
contrib/
* gcc_update (libgupc/aclocal.m4, libgupc/config.h.in,
libgupc/configure, libgupc/Makefile.in,
libgupc/testsuite/Makefile.in): New. Define libgupc targets.
* update-copyright.py: Add libgupc library to copyright scan list.
(skip_extensions): Add .upc.
(GCCCopyright): Add external authors for
contributors to UPC-related additions.
gcc/
* config.in (HAVE_UPC_LINK_SCRIPT): New. Re-generate.
* configure: Re-generate.
* configure.ac (enable-upc-link-script): Add check for UPC
linker script support.
* Makefile.in (INFOFILES): Add doc/gupc.info.
(MANFILES): Add doc/gupc.1.
gcc/c/
* Make-lang.in (gupc): Add rules to build and install the
'gupc' executable. Add rule to symlink 'upc' to 'gupc' executable.
* config-lang.in (gtfiles): Add UPC garbage collection
support files to gtfiles.
Index: Makefile.def
===
--- Makefile.def(.../trunk) (revision 231059)
+++ Makefile.def(.../branches/gupc) (revision 231080)
@@ -154,6 +154,7 @@ target_modules = { module= libbacktrace;
target_modules = { module= libquadmath; };
target_modules = { module= libgfortran; };
target_modules = { module= libobjc; };
+target_modules = { module= libgupc; };
target_modules = { module= libgo; };
target_modules = { module= libtermcap; no_check=true;
missing=mostlyclean;
@@ -284,6 +285,8 @@ flags_to_pass = { flag= GCJ_FOR_TARGET ;
flags_to_pass = { flag= GFORTRAN_FOR_TARGET ; };
flags_to_pass = { flag= GOC_FOR_TARGET ; };
flags_to_pass = { flag= GOCFLAGS_FOR_TARGET ; };
+flags_to_pass = { flag= GUPC_FOR_TARGET ; };
+flags_to_pass = { flag= GUPCFLAGS_FOR_TARGET ; };
flags_to_pass = { flag= LD_FOR_TARGET ; };
flags_to_pass = { flag= LIPO_FOR_TARGET ; };
flags_to_pass = { flag= LDFLAGS_FOR_TARGET ; };
@@ -561,6 +564,8 @@ dependencies = { module=all-target-libja
dependencies = { module=all-target-libjava; on=all-target-libffi; };
dependencies = { module=configure-target-libobjc;
on=configure-target-boehm-gc; };
dependencies = { module=all-target-libobjc; on=all-target-boehm-gc; };
+dependencies = { module=all-target-libgupc; on=all-target-libbacktrace; };
+dependencies = { module=all-target-libgupc; on=all-target-libatomic; };
dependencies = { module=configure-target-libstdc++-v3;
on=configure-target-libgomp; };
dependencies = { module=configure-target-liboffloadmic;
on=configure-target-libgomp; };
dependencies = { module=configure-target-libsanitizer;
on=all-target-libstdc++-v3; };
@@ -569,6 +574,9 @@ dependencies = { module=configure-target
// generated by the libgomp configure. Unfortunately, due to the use of
// recursiv
[UPC 07/22] lowering, pointer-to-shared ops
Background -- An overview email, describing the UPC-related changes is here: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html The GUPC branch is described here: http://gcc.gnu.org/projects/gupc.html The UPC-related source code differences are summarized here: http://gccupc.org/gupc-changes All languages (c, c++, fortran, go, lto, objc, obj-c++) have been bootstrapped; no test suite regressions were introduced, relative to the GCC trunk. If you are on the cc-list, your name was chosen either because you are listed as a maintainer for the area that applies to the patches described in this email, or you were a frequent contributor of patches made to files listed in this email. In the change log entries included in each patch, the directory containing the affected files is listed, followed by the files. When the patches are applied, the change log entries will be distributed to the appropriate ChangeLog file. Overview The UPC lowering pass traverses the current function tree and rewrites UPC related statements and operations into GENERIC. The resulting GENERIC tree code will retain UPC pointers-to-shared (PTS) types, but all operations such as 'get' and 'put' which indirect through a pointer-to-shared have been lowered to use the internal representation type. Most of these operations on UPC pointers-to-shared is implemented in c/c-upc-pts-ops.c. The UPC lowering pass is implemented by upc_genericize() in c/c-upc-low.c. upc_genericize() is called from finish_function() in c/c-decl.c. It is called just prior to calling c_genericize(), if -fupc has been asserted. The file c/c-upc-rts-names.h defines the names of the UPC runtime entry points and variables that implement the runtime ABI. To date, there has been no need to implement target dependent names, perhaps partly because UPC is supported primarily on POSIX-compliant targets. UPC requires some special logic for handling file scoped initializations. This is due to the fact that UPC shared addresses are not known until runtime and therefore cannot be statically initialized in the usual way. For example, 'addr_x' below must be initialized at runtime. shared int x; shared int *addr_x = The routine, upc_check_decl_init(), checks an initialization statement to determine if it needs special handling. It is called from store_init_value(). If an initialization refers to UPC-related constructs that require initialization at runtime, then upc_decl_init() is called to save the initialization statement on a list. This list is processed by upc_write_global_declarations(), which is called via a UPC-specific language hook from c_common_parse_file(), just after calling c_parse_file(). 2015-11-30 Gary Funck <g...@intrepid.com> gcc/c-family/ * c-upc-pts.h: New. Define the sizes and types of fields in the UPC pointer-to-shared representation. gcc/c/ * c-upc-low.c: New. Lower UPC constructs to GENERIC. * c-upc-low.h: New. Prototypes for c-upc-low.c. * c-upc-pts-ops.c: New. Implement UPC pointer-to-shared-operations. * c-upc-pts-ops.h: New. Prototypes for c-upc-pts-ops.c. * c-upc-rts-names.h: New. Names of some functions in the UPC runtime. Index: gcc/c-family/c-upc-pts.h === --- gcc/c-family/c-upc-pts.h(.../trunk) (revision 0) +++ gcc/c-family/c-upc-pts.h(.../branches/gupc) (revision 231080) @@ -0,0 +1,40 @@ +/* Define UPC pointer-to-shared representation characteristics. + Copyright (C) 2008-2015 Free Software Foundation, Inc. + Contributed by Gary Funck <g...@intrepid.com> + and Nenad Vukicevic <ne...@intrepid.com>. + +This file is part of GCC. + +GCC is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 3, or (at your option) +any later version. + +GCC is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GCC; see the file COPYING3. If not see +<http://www.gnu.org/licenses/>. */ + +#ifndef GCC_C_FAMILY_UPC_PTS_H +#define GCC_C_FAMILY_UPC_PTS_H 1 + +#define UPC_PTS_SIZE(LONG_TYPE_SIZE + POINTER_SIZE) +#define UPC_PTS_PHASE_SIZE (LONG_TYPE_SIZE / 2) +#define UPC_PTS_THREAD_SIZE (LONG_TYPE_SIZE / 2) +#define UPC_PTS_VADDR_SIZE POINTER_SIZE +#define UPC_PTS_PHASE_TYPE ((LONG_TYPE_SIZE == 64) \ + ? "uint32_t" : "uint16_t") +#define UPC_PTS_THREAD_TYPE ((LONG_TYPE_SIZE == 64) \ + ? "uint32_t" : "uint16_t") +#define UPC_PTS_VADDR_TYPE
[UPC 21/22] gcc.dg test suite
Background -- An overview email, describing the UPC-related changes is here: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html The GUPC branch is described here: http://gcc.gnu.org/projects/gupc.html The UPC-related source code differences are summarized here: http://gccupc.org/gupc-changes All languages (c, c++, fortran, go, lto, objc, obj-c++) have been bootstrapped; no test suite regressions were introduced, relative to the GCC trunk. If you are on the cc-list, your name was chosen either because you are listed as a maintainer for the area that applies to the patches described in this email, or you were a frequent contributor of patches made to files listed in this email. In the change log entries included in each patch, the directory containing the affected files is listed, followed by the files. When the patches are applied, the change log entries will be distributed to the appropriate ChangeLog file. Overview The test suite additions under gcc/testsuite/gcc.dg/gupc test most of the "negative" front-end errors generated by GNU UPC. These are compile-only tests and can be safely run as part of the gcc.dg test suite. There are also some tests which test code generation for 'gets' and 'puts' to UPC shared memory. These code generation tests scan the '.original' tree dump for expected UPC runtime calls. A new gupc.exp file is introduced under gcc/testsuite/gcc.dg/gupc. It checks that the compiler supports the -fupc switch; if not then tests will not be run. gupc.exp sets the compilation flags to -fno-upc-pre-include by default. This removes any dependency upon the libgupc runtime library, but requires that the tests declare various runtime API's and variables exported by the UPC runtime library that would have otherwise been declared in the gcc-upc.h file built under libgupc/include. 2015-11-30 Gary Funck <g...@intrepid.com> gcc/testsuite/gcc.dg/gupc/ * addr-of-shared-bit-field.upc: New. * assign-local-ptr-to-pts.upc: New. * assign-pts-to-local-ptr.upc: New. * assign-pts-with-diff-block-factors-no-cast.upc: New. * barrier-notify-wait.upc: New. * block-factor-applied-to-void-type.upc: New. * block-factor-incompatible-with-ref-type.upc: New. * block-factor-not-int-constant.upc: New. * cast-int-to-pts.upc: New. * cast-local-ptr-to-pts.upc: New. * cmp-pts-and-local-ptr.upc: New. * cmp-pts-eq-diff-block-factor-1.upc: New. * cmp-pts-eq-diff-block-factor-2.upc: New. * cmp-pts-eq-diff-block-factor-3.upc: New. * cmp-pts-gt-diff-block-factor-1.upc: New. * cmp-pts-gt-diff-block-factor-2.upc: New. * cmp-pts-gt-diff-block-factor-3.upc: New. * decl-multiple-layout-quals.upc: New. * deprecated-barrier-notify-stmt.upc: New. * deprecated-barrier-stmt.upc: New. * deprecated-barrier-wait-stmt.upc: New. * diff-pts-and-local-ptr.upc: New. * dyn-array-decl-threads-more-than-once.upc: New. * dyn-array-dim-not-simple-multiple-of-threads.upc: New. * dyn-star-layout-dim-not-multiple-of-threads.upc: New. * dyn-threads-more-than-once.upc: New. * dyn-threads-with-indef-block-size.upc: New. * field-decl-with-shared-qual.upc: New. * func-decl-has-shared_qual.upc: New. * get-blk-relaxed.upc: New. * get-blk-strict.upc: New. * get-df-relaxed.upc: New. * get-df-strict.upc: New. * get-di-relaxed.upc: New. * get-di-strict.upc: New. * get-hi-relaxed.upc: New. * get-hi-strict.upc: New. * get-qi-relaxed.upc: New. * get-qi-strict.upc: New. * get-sf-relaxed.upc: New. * get-sf-strict.upc: New. * get-si-relaxed.upc: New. * get-si-strict.upc: New. * get-tf-relaxed.upc: New. * get-tf-strict.upc: New. * get-ti-relaxed.upc: New. * get-ti-strict.upc: New. * getaddr.upc: New. * gupc.exp: New. Compile all *.upc tests in this directory. * init-makes-pts-from-int.upc: New. * invalid-local-ptr-to-void-arith.upc: New. * invalid-sizeof-shared-void.upc: New. * invalid-sizeof-void.upc: New. * lt-pts-and-local-ptr.upc: New. * max-block-size-exceeded.upc: New. * no-closing-layout-qual-bracket.upc: New. * parm-decl-with-shared-qual.upc: New. * passing-arg-makes-pts-from-int.upc: New. * pts-to-void-in-arith.upc: New. * put-blk-relaxed.upc: New. * put-blk-strict.upc: New. * put-df-relaxed.upc: New. * put-df-strict.upc: New. * put-di-relaxed.upc: New. * put-di-strict.upc: New. * put-hi-relaxed.upc: New. * put-hi-strict.upc: New. * put-qi-relaxed.upc: New. * put-qi-strict.upc: New. * put-sf-relaxed.upc: New. * put-sf-strict.upc: New.
[UPC 11/22] documentation
Background
--
An overview email, describing the UPC-related changes is here:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html
The GUPC branch is described here:
http://gcc.gnu.org/projects/gupc.html
The UPC-related source code differences are summarized here:
http://gccupc.org/gupc-changes
All languages (c, c++, fortran, go, lto, objc, obj-c++) have been
bootstrapped; no test suite regressions were introduced,
relative to the GCC trunk.
If you are on the cc-list, your name was chosen either
because you are listed as a maintainer for the area that
applies to the patches described in this email, or you
were a frequent contributor of patches made to files listed
in this email.
In the change log entries included in each patch, the directory
containing the affected files is listed, followed by the files.
When the patches are applied, the change log entries will be
distributed to the appropriate ChangeLog file.
Overview
For UPC, a new gupc.texi file is introduced to describe the
stand-alone 'gupc' command, which is a driver similar to gfortran
that will invoke 'gcc', asserting the -fupc switch and will
compile any .c files on the command line as if they were .upc files.
In addition, it describes how to run UPC programs, along with details
on the command line switches processed by the UPC runtime.
2015-11-30 Gary Funck <g...@intrepid.com>
gcc/doc/
* gupc.texi: New.
* install.texi (disable-libgupc, enable-upc-link-script):
New. Describe UPC-specific configure options.
* invoke.texi (fupc, fupc-threads, fupc-pthreads-model-tls,
fupc-inline-lib, fupc-pre-include, fupc-debug, dwarf-2-upc,
fupc-instrument, fupc-instrument-functions):
New. Describe UPS-specific compiler options.
* passes.texi: Describe the UPC lowering pass.
* sourcebuild.texi (libgupc): Add libgupc to list of libraries.
Also make note that target support for UPC is enabled via -fupc.
* tm.texi: Re-generate.
* tm.texi.in (TARGET_UPC_LINK_SCRIPT_P,
TARGET_UPC_SHARED_SECTION_NAME, TARGET_UPC_PGM_INFO_SECTION_NAME,
TARGET_UPC_INIT_ARRAY_SECTION_NAME): Refer to new UPC target hooks.
libgupc/
* libgupc.texi: New.
Index: gcc/doc/gupc.texi
===
--- gcc/doc/gupc.texi (.../trunk) (revision 0)
+++ gcc/doc/gupc.texi (.../branches/gupc) (revision 231080)
@@ -0,0 +1,394 @@
+\input texinfo @c -*-texinfo-*-
+@setfilename gupc
+@settitle GNU project UPC compiler
+
+@c Merge the standard indexes into a single one.
+@syncodeindex fn cp
+@syncodeindex vr cp
+@syncodeindex ky cp
+@syncodeindex pg cp
+@syncodeindex tp cp
+
+@include gcc-common.texi
+
+@c Copyright (C) 2001-2015 Free Software Foundation, Inc.
+@c Contributed by Gary Funck <g...@intrepid.com>
+@c and Nenad Vukicevic <ne...@intrepid.com>.
+@c Based on original implementation
+@c by Jesse M. Draper <jdra...@super.org>
+@c and William W. Carlson <w...@super.org>.
+
+@copying
+@c man begin COPYRIGHT
+Copyright @copyright{} 2001-2015 Free Software Foundation, Inc.
+
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the GNU Free Documentation License, Version 1.3 or
+any later version published by the Free Software Foundation; with the
+Invariant Sections being ``GNU General Public License'' and ``Funding
+Free Software'', the Front-Cover texts being (a) (see below), and with
+the Back-Cover Texts being (b) (see below). A copy of the license is
+included in the
+@c man end
+section entitled ``GNU Free Documentation License''.
+@ignore
+@c man begin COPYRIGHT
+man page gfdl(7).
+@c man end
+@end ignore
+@c man begin COPYRIGHT
+
+(a) The FSF's Front-Cover Text is:
+
+ A GNU Manual
+
+(b) The FSF's Back-Cover Text is:
+
+ You have freedom to copy and modify this GNU Manual, like GNU
+ software. Copies published by the Free Software Foundation raise
+ funds for GNU development.
+@c man end
+@end copying
+@c Set file name and title for the man page.
+
+@ifinfo
+@dircategory Software development
+@direntry
+* GNU UPC: (gupc). A GCC-based compiler for the UPC language
+@end direntry
+
+@insertcopying
+@end ifinfo
+
+@titlepage
+@title The GNU UPC Compiler
+@versionsubtitle
+@author Gary Funck and Nenad Vukicevic
+
+@page
+@vskip 0pt plus 1filll
+Published by the Free Software Foundation @*
+51 Franklin Street, Fifth Floor@*
+Boston, MA 02110-1301, USA@*
+@sp 1
+@insertcopying
+@end titlepage
+@contents
+@page
+
+@node Top
+@chapter @command{gupc}--- UPC compiler for parallel computers
+
+@command{gupc} provides a compilation and execution environment for
+programs written in the UPC (Unified Parallel C) language.
+
+@menu
+* GUPC Intro:: Introduction to gupc.
+* Threads::Number of Execution Threads.
+* Invoking GUPC:: How to use gupc.
+* GUP
[UPC 16/22] gimple/gimplify changes
Background
--
An overview email, describing the UPC-related changes is here:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html
The GUPC branch is described here:
http://gcc.gnu.org/projects/gupc.html
The UPC-related source code differences are summarized here:
http://gccupc.org/gupc-changes
All languages (c, c++, fortran, go, lto, objc, obj-c++) have been
bootstrapped; no test suite regressions were introduced,
relative to the GCC trunk.
If you are on the cc-list, your name was chosen either
because you are listed as a maintainer for the area that
applies to the patches described in this email, or you
were a frequent contributor of patches made to files listed
in this email.
In the change log entries included in each patch, the directory
containing the affected files is listed, followed by the files.
When the patches are applied, the change log entries will be
distributed to the appropriate ChangeLog file.
Overview
In gimple-expr.c, logic is added to useless_type_conversion_p() to
handle conversions involving UPC pointers-to-shared.
lang_hooks.types_compatible_p() is called to check conversions
between UPC pointers-to-shared. This will in turn call c_types_compatible_p()
which will call upc_types_compatible_p() if -fupc is asserted.
The hook is needed here because the gimple-related routines are
defined at the top-level of the GCC tree and can be linked with
other front-ends.
In gimplify.c, flag_instrument_functions_exclude_p() is exported
as an external function rather than being defined as a static function.
It is called from upc_genericize_function() defined in c/c-upc-low.c,
when -fupc-instrument-functions is asserted.
2015-11-30 Gary Funck <g...@intrepid.com>
gcc/
* gimple-expr.c: #include "langhooks.h".
(useless_type_conversion_p): Retain conversions from UPC
pointer-to-shared and a regular C pointer.
Retain conversions between incompatible UPC pointers-to-shared.
Call lang_hooks.types_compatible_p() to check type
compatibility between UPC pointers-to-shared.
* gimplify.c (flag_instrument_functions_exclude_p): Make it into
an external function.
* gimplify.h (flag_instrument_functions_exclude_p): New prototype.
Index: gcc/gimple-expr.c
===
--- gcc/gimple-expr.c (.../trunk) (revision 231059)
+++ gcc/gimple-expr.c (.../branches/gupc) (revision 231080)
@@ -29,6 +29,7 @@ along with GCC; see the file COPYING3.
#include "gimple-ssa.h"
#include "fold-const.h"
#include "tree-eh.h"
+#include "langhooks.h"
#include "gimplify.h"
#include "stor-layout.h"
#include "demangle.h"
@@ -67,6 +68,19 @@ useless_type_conversion_p (tree outer_ty
if (POINTER_TYPE_P (inner_type)
&& POINTER_TYPE_P (outer_type))
{
+ int i_shared = SHARED_TYPE_P (TREE_TYPE (inner_type));
+ int o_shared = SHARED_TYPE_P (TREE_TYPE (outer_type));
+
+ /* Retain conversions from a UPC shared pointer to
+ a regular C pointer. */
+ if (!o_shared && i_shared)
+return false;
+
+ /* Retain conversions between incompatible UPC shared pointers. */
+ if (o_shared && i_shared
+ && !lang_hooks.types_compatible_p (inner_type, outer_type))
+return false;
+
/* Do not lose casts between pointers to different address spaces. */
if (TYPE_ADDR_SPACE (TREE_TYPE (outer_type))
!= TYPE_ADDR_SPACE (TREE_TYPE (inner_type)))
Index: gcc/gimplify.c
===
--- gcc/gimplify.c (.../trunk) (revision 231059)
+++ gcc/gimplify.c (.../branches/gupc) (revision 231080)
@@ -11269,7 +11269,7 @@ typedef char *char_p; /* For DEF_VEC_P.
/* Return whether we should exclude FNDECL from instrumentation. */
-static bool
+bool
flag_instrument_functions_exclude_p (tree fndecl)
{
vec *v;
Index: gcc/gimplify.h
===
--- gcc/gimplify.h (.../trunk) (revision 231059)
+++ gcc/gimplify.h (.../branches/gupc) (revision 231080)
@@ -77,6 +77,7 @@ extern enum gimplify_status gimplify_exp
extern void gimplify_type_sizes (tree, gimple_seq *);
extern void gimplify_one_sizepos (tree *, gimple_seq *);
extern gbind *gimplify_body (tree, bool);
+extern bool flag_instrument_functions_exclude_p (tree);
extern enum gimplify_status gimplify_arg (tree *, gimple_seq *, location_t);
extern void gimplify_function_tree (tree);
extern enum gimplify_status gimplify_va_arg_expr (tree *, gimple_seq *,
[UPC 05/22] language hooks changes
Background
--
An overview email, describing the UPC-related changes is here:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html
The GUPC branch is described here:
http://gcc.gnu.org/projects/gupc.html
The UPC-related source code differences are summarized here:
http://gccupc.org/gupc-changes
All languages (c, c++, fortran, go, lto, objc, obj-c++) have been
bootstrapped; no test suite regressions were introduced,
relative to the GCC trunk.
If you are on the cc-list, your name was chosen either
because you are listed as a maintainer for the area that
applies to the patches described in this email, or you
were a frequent contributor of patches made to files listed
in this email.
In the change log entries included in each patch, the directory
containing the affected files is listed, followed by the files.
When the patches are applied, the change log entries will be
distributed to the appropriate ChangeLog file.
Overview
Two new UPC-specific 'decl' language hooks are defined and then called from
layout_decl() in stor-layout.c. The layout_decl_p() function tests if
this is a UPC shared array declaration that requires special handling.
If it does, then layout_decl() is called.
A few new UPC-specific language hooks are defined in a 'upc' sub-structure
of the language hooks structure. They are defined as
hooks because they are called from code in the 'c-family/' directory,
but are implemented in the 'c/' directory.
2015-11-30 Gary Funck <g...@intrepid.com>
gcc/
* langhooks-def.h (lhd_do_nothing_b, lhd_do_nothing_t_t):
New do nothing hook prototypes.
(LANG_HOOKS_UPC_TOGGLE_KEYWORDS,
LANG_HOOKS_UPC_PTS_INIT_TYPE, LANG_HOOKS_UPC_BUILD_INIT_FUNC,
LANG_HOOKS_UPC_WRITE_GLOBAL_DECLS): New default UPC hooks.
* langhooks-def.h (LANG_HOOKS_LAYOUT_DECL_P, LANG_HOOKS_LAYOUT_DECL):
New language hook defaults.
(LANG_HOOKS_UPC): New. Define UPC hooks structure.
* langhooks.c (lhd_do_nothing_b, lhd_do_nothing_t_t):
New do nothing hooks.
* langhooks.h (layout_decl_p, layout_decl): New language hooks.
(lang_hooks_for_upc): New UPC language hooks structure.
* stor-layout.c (layout_decl): Call the layout_decl_p() and
and layout_decl() hooks.
gcc/c/
* c-lang.c: #include "c-upc-lang.h".
#include "c-upc-low.h".
(LANG_HOOKS_UPC_TOGGLE_KEYWORDS, LANG_HOOKS_UPC_PTS_INIT_TYPE,
LANG_HOOKS_UPC_BUILD_INIT_FUNC, LANG_HOOKS_UPC_WRITE_GLOBAL_DECLS,
LANG_HOOKS_LAYOUT_DECL_P, LANG_HOOKS_LAYOUT_DECL):
Override defaults. Define UPC-specific hook routines.
* c-upc-lang.c: New. Implement UPC-specific hook routines.
* c-upc-lang.h: New. Define UPC-specific hook prototypes.
Index: gcc/langhooks-def.h
===
--- gcc/langhooks-def.h (.../trunk) (revision 231059)
+++ gcc/langhooks-def.h (.../branches/gupc) (revision 231080)
@@ -35,7 +35,9 @@ struct diagnostic_info;
/* See langhooks.h for the definition and documentation of each hook. */
extern void lhd_do_nothing (void);
+extern void lhd_do_nothing_b (bool);
extern void lhd_do_nothing_t (tree);
+extern void lhd_do_nothing_t_t (tree, tree);
extern void lhd_do_nothing_f (struct function *);
extern tree lhd_pass_through_t (tree);
extern bool lhd_post_options (const char **);
@@ -175,6 +177,10 @@ extern tree lhd_make_node (enum tree_cod
#define LANG_HOOKS_GET_SUBRANGE_BOUNDS NULL
#define LANG_HOOKS_DESCRIPTIVE_TYPENULL
#define LANG_HOOKS_RECONSTRUCT_COMPLEX_TYPE reconstruct_complex_type
+#define LANG_HOOKS_UPC_TOGGLE_KEYWORDS lhd_do_nothing_b
+#define LANG_HOOKS_UPC_PTS_INIT_TYPE lhd_do_nothing
+#define LANG_HOOKS_UPC_BUILD_INIT_FUNC lhd_do_nothing_t
+#define LANG_HOOKS_UPC_WRITE_GLOBAL_DECLS lhd_do_nothing
#define LANG_HOOKS_ENUM_UNDERLYING_BASE_TYPE lhd_enum_underlying_base_type
#define LANG_HOOKS_FOR_TYPES_INITIALIZER { \
@@ -219,6 +225,8 @@ extern tree lhd_make_node (enum tree_cod
#define LANG_HOOKS_OMP_CLAUSE_LINEAR_CTOR NULL
#define LANG_HOOKS_OMP_CLAUSE_DTOR hook_tree_tree_tree_null
#define LANG_HOOKS_OMP_FINISH_CLAUSE lhd_omp_finish_clause
+#define LANG_HOOKS_LAYOUT_DECL_P hook_bool_tree_tree_false
+#define LANG_HOOKS_LAYOUT_DECL lhd_do_nothing_t_t
#define LANG_HOOKS_DECLS { \
LANG_HOOKS_GLOBAL_BINDINGS_P, \
@@ -243,7 +251,9 @@ extern tree lhd_make_node (enum tree_cod
LANG_HOOKS_OMP_CLAUSE_ASSIGN_OP, \
LANG_HOOKS_OMP_CLAUSE_LINEAR_CTOR, \
LANG_HOOKS_OMP_CLAUSE_DTOR, \
- LANG_HOOKS_OMP_FINISH_CLAUSE \
+ LANG_HOOKS_OMP_FINISH_CLAUSE, \
+ LANG_HOOKS_LAYOUT_DECL_P, \
+ LANG_HOOKS_LAYOUT_DECL \
}
/* LTO hooks. */
@@ -261,6 +271,13 @@ extern void lhd_end_section (void);
LANG_HOOKS_END_SECTION \
}
+#define LANG_HOOKS_UPC { \
+ LANG_HOOKS_UPC_TOGGLE_KEYWORDS, \
+ LANG_HOOKS_UPC_PTS_INIT_TYPE, \
+ LANG
[UPC 13/22] C++ changes
Background
--
An overview email, describing the UPC-related changes is here:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html
The GUPC branch is described here:
http://gcc.gnu.org/projects/gupc.html
The UPC-related source code differences are summarized here:
http://gccupc.org/gupc-changes
All languages (c, c++, fortran, go, lto, objc, obj-c++) have been
bootstrapped; no test suite regressions were introduced,
relative to the GCC trunk.
If you are on the cc-list, your name was chosen either
because you are listed as a maintainer for the area that
applies to the patches described in this email, or you
were a frequent contributor of patches made to files listed
in this email.
In the change log entries included in each patch, the directory
containing the affected files is listed, followed by the files.
When the patches are applied, the change log entries will be
distributed to the appropriate ChangeLog file.
Overview
Although UPC is an extension to "C" and not "C++", these changes
are needed to accommodate changes to the common tree-related
code that handles qualified types, and to accommodate UPC's
"layout qualifier" (blocking factor).
In tree.h, check_qualified_type() was changed to accept an
extra argument, block_factor.
/* Check whether CAND is suitable to be returned from get_qualified_type
(BASE, TYPE_QUALS, BLOCK_FACTOR). */
extern bool check_qualified_type (const_tree cand, const_tree base,
int type_quals, tree block_factor);
and the c_build_qualified_type() procedure was renamed to
c_build_qualified_type_1(). c_build_qualified_type was changed
into a macro.
/* Return a version of the TYPE, qualified as indicated by the
TYPE_QUALS and BLOCK_FACTOR, if one exists.
If no qualified version exists yet, return NULL_TREE. */
extern tree get_qualified_type_1 (tree type, int type_quals,
tree block_factor);
#define get_qualified_type(TYPE, QUALS) \
get_qualified_type_1 (TYPE, QUALS, 0)
This patch adjusts the C++ front-end so that it works with
the changes described above.
2015-11-30 Gary Funck <g...@intrepid.com>
gcc/cp/
* lex.c (init_reswords): Disable UPC keywords.
* tree.c (c_build_qualified_type_1): Rename.
Was: c_build_qualified_type.
(cp_check_qualified_type): Adjust call to check_qualified_type
to pass a null UPC blocking factor.
Index: gcc/cp/lex.c
===
--- gcc/cp/lex.c(.../trunk) (revision 231059)
+++ gcc/cp/lex.c(.../branches/gupc) (revision 231080)
@@ -179,6 +179,9 @@ init_reswords (void)
/* The Objective-C keywords are all context-dependent. */
mask |= D_OBJC;
+ /* UPC constructs are not supported in C++. */
+ mask |= D_UPC;
+
ridpointers = ggc_cleared_vec_alloc ((int) RID_MAX);
for (i = 0; i < num_c_common_reswords; i++)
{
Index: gcc/cp/tree.c
===
--- gcc/cp/tree.c (.../trunk) (revision 231059)
+++ gcc/cp/tree.c (.../branches/gupc) (revision 231080)
@@ -995,7 +995,8 @@ move (tree expr)
the C version of this function does not properly maintain canonical
types (which are not used in C). */
tree
-c_build_qualified_type (tree type, int type_quals)
+c_build_qualified_type_1 (tree type, int type_quals,
+ tree ARG_UNUSED (layout_qualifier))
{
return cp_build_qualified_type (type, type_quals);
}
@@ -1867,7 +1868,7 @@ static bool
cp_check_qualified_type (const_tree cand, const_tree base, int type_quals,
cp_ref_qualifier rqual, tree raises)
{
- return (check_qualified_type (cand, base, type_quals)
+ return (check_qualified_type (cand, base, type_quals, NULL_TREE)
&& comp_except_specs (raises, TYPE_RAISES_EXCEPTIONS (cand),
ce_exact)
&& type_memfn_rqual (cand) == rqual);
[UPC 14/22] constant folding changes
Background
--
An overview email, describing the UPC-related changes is here:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html
The GUPC branch is described here:
http://gcc.gnu.org/projects/gupc.html
The UPC-related source code differences are summarized here:
http://gccupc.org/gupc-changes
All languages (c, c++, fortran, go, lto, objc, obj-c++) have been
bootstrapped; no test suite regressions were introduced,
relative to the GCC trunk.
If you are on the cc-list, your name was chosen either
because you are listed as a maintainer for the area that
applies to the patches described in this email, or you
were a frequent contributor of patches made to files listed
in this email.
In the change log entries included in each patch, the directory
containing the affected files is listed, followed by the files.
When the patches are applied, the change log entries will be
distributed to the appropriate ChangeLog file.
Overview
UPC pointers-to-shared (aka shared pointers) are not interchangeable
with integers as they are in regular "C". Therefore, additions
and subtraction operations which involve UPC shared pointers
should not be further simplified.
2015-11-30 Gary Funck <g...@intrepid.com>
gcc/
* fold-const.c (fold_unary_loc): Do not perform this simplification
if either of the types are UPC pointer-to-shared types.
(fold_binary_loc): Disable optimizations involving UPC
pointers-to-shared because integers are not interoperable
with UPC pointers-to-shared.
* match.pd: Do not simplify POINTER_PLUS operations which
involve UPC pointers-to-shared. Do not simplify integral
conversions involving UPC pointers-to-shared. For a chain
of two conversions, do not simplify conversions involving
UPC pointers-to-shared unless they meet specific criteria.
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(.../trunk) (revision 231059)
+++ gcc/fold-const.c(.../branches/gupc) (revision 231080)
@@ -7805,10 +7805,16 @@ fold_unary_loc (location_t loc, enum tre
/* Convert (T1)(X p+ Y) into ((T1)X p+ Y), for pointer type, when the new
cast (T1)X will fold away. We assume that this happens when X itself
-is a cast. */
+is a cast.
+
+Do not perform this simplification if either of the types
+are UPC pointer-to-shared types. */
if (POINTER_TYPE_P (type)
&& TREE_CODE (arg0) == POINTER_PLUS_EXPR
- && CONVERT_EXPR_P (TREE_OPERAND (arg0, 0)))
+ && CONVERT_EXPR_P (TREE_OPERAND (arg0, 0))
+ && !SHARED_TYPE_P (TREE_TYPE (type))
+ && !SHARED_TYPE_P (TREE_TYPE (
+ TREE_TYPE (TREE_OPERAND (arg0, 0)
{
tree arg00 = TREE_OPERAND (arg0, 0);
tree arg01 = TREE_OPERAND (arg0, 1);
@@ -9271,6 +9277,14 @@ fold_binary_loc (location_t loc,
return NULL_TREE;
case PLUS_EXPR:
+ /* Disable further optimizations involving UPC shared pointers,
+ because integers are not interoperable with shared pointers. */
+ if ((TREE_TYPE (arg0) && POINTER_TYPE_P (TREE_TYPE (arg0))
+ && SHARED_TYPE_P (TREE_TYPE (TREE_TYPE (arg0
+ || (TREE_TYPE (arg1) && POINTER_TYPE_P (TREE_TYPE (arg1))
+ && SHARED_TYPE_P (TREE_TYPE (TREE_TYPE (arg1)
+return NULL_TREE;
+
if (INTEGRAL_TYPE_P (type) || VECTOR_INTEGER_TYPE_P (type))
{
/* X + (X / CST) * -CST is X % CST. */
@@ -9679,6 +9693,16 @@ fold_binary_loc (location_t loc,
return NULL_TREE;
case MINUS_EXPR:
+
+ /* Disable further optimizations involving UPC shared pointers,
+ because integers are not interoperable with shared pointers.
+(The test below also detects pointer difference between
+shared pointers, which cannot be folded. */
+
+ if (TREE_TYPE (arg0) && POINTER_TYPE_P (TREE_TYPE (arg0))
+ && SHARED_TYPE_P (TREE_TYPE (TREE_TYPE (arg0
+return NULL_TREE;
+
/* (-A) - B -> (-B) - A where B is easily negated and we can swap. */
if (TREE_CODE (arg0) == NEGATE_EXPR
&& negate_expr_p (op1)
Index: gcc/match.pd
===
--- gcc/match.pd(.../trunk) (revision 231059)
+++ gcc/match.pd(.../branches/gupc) (revision 231080)
@@ -931,10 +931,13 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(if (!fail && wi::bit_and (@1, zero_mask_not) == 0)
(inner_op @2 { wide_int_to_tree (type, cst_emit); }))
-/* Associate (p +p off1) +p off2 as (p +p (off1 + off2)). */
-(simplify
- (pointer_plus (pointer_plus:s @0 @1) @3)
- (pointer_plus @0 (plus @1 @3)))
+/* Associa
[UPC 03/22] options processing, driver
Background
--
An overview email, describing the UPC-related changes is here:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html
The GUPC branch is described here:
http://gcc.gnu.org/projects/gupc.html
The UPC-related source code differences are summarized here:
http://gccupc.org/gupc-changes
All languages (c, c++, fortran, go, lto, objc, obj-c++) have been
bootstrapped; no test suite regressions were introduced,
relative to the GCC trunk.
If you are on the cc-list, your name was chosen either
because you are listed as a maintainer for the area that
applies to the patches described in this email, or you
were a frequent contributor of patches made to files listed
in this email.
In the change log entries included in each patch, the directory
containing the affected files is listed, followed by the files.
When the patches are applied, the change log entries will be
distributed to the appropriate ChangeLog file.
Overview
UPC language support requires some extensions to the GCC driver.
Most of the new UPC-specific spec's will be triggered by the presence
of -fupc on the gcc command line. Further, -fupc, will be asserted
when source files ending in .upc are compiled.
The linker spec, LINK_COMMAND_SPEC, is extended to bring in
UPC start/end files and to link with libgupc when -fupc is asserted.
Some new UPC-specific command line options are defined in c.opt.
These new UPC-specific options will only have an effect when -fupc
is asserted, and will be detected as an error otherwise.
c_common_parse_file() will call the UPC-specific language hook,
lang_hooks.upc.write_global_declarations() just after
parsing the source file via c_parse_file(). It is called
there to generate an initialization routine
within the scope of the current compilation unit.
This initialization routine will initialize file scope
UPC shared variables, and initialize pointers-to-shared
as needed. The address of this initialization routine
is placed in a special linker section named by
targetm.upc.init_array_section_name().
A new UPC-specific driver program called 'gupc' is implemented by
gcc/c/gupcspec.c. It will be installed as both a 'gupc' and 'upc'
executable ('upc' is a symlink to 'gupc'). This is a convenience
driver similar to gfortran. It asserts -fupc and
will cause .c source files to be compiled as UPC source files.
This implicit handling of .c files as .upc files provides compatibility
with other UPC compilers.
2015-11-30 Gary Funck <g...@intrepid.com>
gcc/
* gcc.c (upc_crtbegin_spec, link_upc_spec, upc_crtend_spec,
upc_options): New. Define UPC-related spec's.
(default_compilers): Add support for .upc files.
(static_specs): Initialize UPC-specific spec's.
(LINK_COMMAND_SPEC): Add UPC-specific linker spec's.
* timevar.def (TV_TREE_UPC_GENERICIZE): New. Define a new
time variable for the 'UPC genericize' pass.
gcc/c-family/
* c-opts.c: #include "c-upc-pts.h" to bring in UPC_MAX_THREADS.
(upc_init_options, upc_handle_option): New.
(c_common_init_options):
Call upc_init_options() if -fupc is asserted.
(c_common_handle_option): Call upc_handle_option
to handle UPC-specific options.
(c_common_parse_file):
Call lang_hooks.upc.write_global_declarations() if -fupc is asserted.
* c.opt (dwarf-2-upc, fupc, fupc-debug, fupc-inline-lib,
fupc-pre-include, fupc-pthreads-model-tls, fupc-threads,
fupc-instrument, fupc-instrument-functions): New.
Define UPS-specific command line options.
gcc/c/
* gupcspec.c: New. Implement the 'gupc' driver program.
Index: gcc/gcc.c
===
--- gcc/gcc.c (.../trunk) (revision 231059)
+++ gcc/gcc.c (.../branches/gupc) (revision 231080)
@@ -1016,16 +1016,20 @@ proper position among the other output f
%{flto} %{fno-lto} %{flto=*} %l " LINK_PIE_SPEC \
"%{fuse-ld=*:-fuse-ld=%*} " LINK_COMPRESS_DEBUG_SPEC \
"%X %{o*} %{e*} %{N} %{n} %{r}\
-%{s} %{t} %{u*} %{z} %{Z} %{!nostdlib:%{!nostartfiles:%S}} \
+%{s} %{t} %{u*} %{z} %{Z}\
+
%{!nostdlib:%{!nostartfiles:%{fupc:%:include(upc-crtbegin.spec)%(upc_crtbegin)}}}\
+%{!nostdlib:%{!nostartfiles:%S}} \
%{static:} %{L*} %(mfwrap) %(link_libgcc) " \
VTABLE_VERIFICATION_SPEC " " SANITIZER_EARLY_SPEC " %o " CHKP_SPEC " \
%{fopenacc|fopenmp|%:gt(%{ftree-parallelize-loops=*} 1):\
%:include(libgomp.spec)%(link_gomp)}\
%{fcilkplus:%:include(libcilkrts.spec)%(link_cilkrts)}\
%{fgnu-tm:%:include(libitm.spec)%(link_itm)}\
+%{fupc:%:include(libgupc.spec)%(link_upc)}\
%(mflib) " STACK_SPLIT_SPEC "\
%{fprofile-arcs|fprofile-generate*|coverage:-lgcov} " SANITIZER_SPEC " \
%{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link
[UPC 18/22] libatomic changes
Background -- An overview email, describing the UPC-related changes is here: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html The GUPC branch is described here: http://gcc.gnu.org/projects/gupc.html The UPC-related source code differences are summarized here: http://gccupc.org/gupc-changes All languages (c, c++, fortran, go, lto, objc, obj-c++) have been bootstrapped; no test suite regressions were introduced, relative to the GCC trunk. If you are on the cc-list, your name was chosen either because you are listed as a maintainer for the area that applies to the patches described in this email, or you were a frequent contributor of patches made to files listed in this email. In the change log entries included in each patch, the directory containing the affected files is listed, followed by the files. When the patches are applied, the change log entries will be distributed to the appropriate ChangeLog file. Overview The UPC language specification defines atomic operations on UPC shared data, implemented by a set of library routines. The UPC runtime library, targeting SMP (symmetric multiprocessor) systems, uses GCC builtin atomic operations to implement atomic operations on UPC shared values. GCC's builtin atomic operations use libatomic to handle various situations where direct hardware support is unavailable. During testing, we noticed that when some operations or types are unsupported that the library will call an internal lock routine and this lock routine calls pthread_mutex(). That doesn't work well for UPC because by default a UPC "thread" maps to an OS process. We discussed this issue in this bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60790. To work around this locking issue, we build a statically linked "convenience" library, libatomic_convenience_no_lock.a. This is the same as the libatomic_convenience library built for libgo, except it doesn't include lock.o. In libgupc/smp, the source file upc_libat_lock.c defines the same entry points as lock.c, but implements them using a spin lock. 2015-11-30 Gary Funck <g...@intrepid.com> libatomic/ * Makefile.am (LIBAT_SRC_NO_LOCK, libatomic_convenience_no_lock*): New. Add rules to build libatomic_convenience_no_lock.a, used by libgupc. * Makefile.in: Re-generate. Index: libatomic/Makefile.am === --- libatomic/Makefile.am (.../trunk) (revision 231059) +++ libatomic/Makefile.am (.../branches/gupc) (revision 231080) @@ -40,7 +40,8 @@ AM_CCASFLAGS = $(XCFLAGS) AM_LDFLAGS = $(XLDFLAGS) $(SECTION_LDFLAGS) $(OPT_LDFLAGS) toolexeclib_LTLIBRARIES = libatomic.la -noinst_LTLIBRARIES = libatomic_convenience.la +noinst_LTLIBRARIES = libatomic_convenience.la \ + libatomic_convenience_no_lock.la if LIBAT_BUILD_VERSIONED_SHLIB if LIBAT_BUILD_VERSIONED_SHLIB_GNU @@ -67,8 +68,9 @@ endif libatomic_version_info = -version-info $(libtool_VERSION) libatomic_la_LDFLAGS = $(libatomic_version_info) $(libatomic_version_script) $(lt_host_flags) -libatomic_la_SOURCES = gload.c gstore.c gcas.c gexch.c glfree.c lock.c init.c \ +LIBAT_SRC_NO_LOCK = gload.c gstore.c gcas.c gexch.c glfree.c 0 init.c \ fenv.c fence.c flag.c +libatomic_la_SOURCES = $(LIBAT_SRC_NO_LOCK) lock.c SIZEOBJS = load store cas exch fadd fsub fand fior fxor fnand tas SIZES = @SIZES@ @@ -139,3 +141,9 @@ endif libatomic_convenience_la_SOURCES = $(libatomic_la_SOURCES) libatomic_convenience_la_LIBADD = $(libatomic_la_LIBADD) + +# The "no lock" convenience library is used by libgupc to +# avoid lock.c's use of pthread_mutex, which won't work +# for processes using atomics on shared memory. +libatomic_convenience_no_lock_la_SOURCES = $(LIBAT_SRC_NO_LOCK) +libatomic_convenience_no_lock_la_LIBADD = $(libatomic_la_LIBADD)
[UPC 12/22] DWARF support
Background
--
An overview email, describing the UPC-related changes is here:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html
The GUPC branch is described here:
http://gcc.gnu.org/projects/gupc.html
The UPC-related source code differences are summarized here:
http://gccupc.org/gupc-changes
All languages (c, c++, fortran, go, lto, objc, obj-c++) have been
bootstrapped; no test suite regressions were introduced,
relative to the GCC trunk.
If you are on the cc-list, your name was chosen either
because you are listed as a maintainer for the area that
applies to the patches described in this email, or you
were a frequent contributor of patches made to files listed
in this email.
In the change log entries included in each patch, the directory
containing the affected files is listed, followed by the files.
When the patches are applied, the change log entries will be
distributed to the appropriate ChangeLog file.
Overview
The Dwarf4 specification defines extensions which add support for UPC.
See: http://dwarfstd.org/doc/DWARF4.pdf for details. These extensions
are defined in /include/dwarf2.def. The patch below
implements UPC debugging support. This support is enabled via
the -dwarf-2-upc compilation switch. It is not enabled by default,
because some older versions of GDB will abort when encountering
the UPC-related DWARF extensions.
A few years back, we added support to GDB for UPC, though that
support was experimental and not pushed back into the mainline.
A couple of commercial parallel debuggers implemented support
for GNU UPC, utilizing these DWARF extensions.
2015-11-30 Gary Funck <g...@intrepid.com>
gcc/
* dwarf2out.c (modified_type_die): If the type is shared qualified,
generate UPC debugging information as defined in
the DWARF4 specification.
(add_subscript_info): If the array index is "THREADS scaled",
add the DW_AT_upc_threads_scaled attribute to the subrange DIE.
(gen_compile_unit_die): If -fupc is asserted,
set the language to DW_LANG_Upc.
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (.../trunk) (revision 231059)
+++ gcc/dwarf2out.c (.../branches/gupc) (revision 231080)
@@ -10899,6 +10899,50 @@ modified_type_die (tree type, int cv_qua
mod_type_die = d;
}
}
+ else if (use_upc_dwarf2_extensions
+ && (cv_quals & TYPE_QUAL_SHARED))
+{
+ HOST_WIDE_INT block_factor = 1;
+
+ /* Inside the compiler,
+ "shared int x;" TYPE_BLOCK_FACTOR is null.
+ "shared [] int *p;" TYPE_BLOCK_FACTOR is zero.
+ "shared [10] int x[50];" TYPE_BLOCK_FACTOR is 10 * bitsize(int)
+ The DWARF2 encoding is as follows:
+ "shared int x;" DW_AT_count: 1
+ "shared [] int *p;"
+ "shared [10] int x[50];" DW_AT_count: 10
+ The logic below handles thse various contingencies. */
+
+ mod_type_die = new_die (DW_TAG_upc_shared_type,
+ comp_unit_die (), type);
+
+ if (TYPE_HAS_BLOCK_FACTOR (type))
+block_factor = TREE_INT_CST_LOW (TYPE_BLOCK_FACTOR (type));
+
+ if (block_factor != 0)
+add_AT_unsigned (mod_type_die, DW_AT_count, block_factor);
+
+ sub_die = modified_type_die (type,
+ cv_quals & ~TYPE_QUAL_SHARED,
+ context_die);
+}
+ else if (use_upc_dwarf2_extensions && cv_quals & TYPE_QUAL_STRICT)
+{
+ mod_type_die = new_die (DW_TAG_upc_strict_type,
+ comp_unit_die (), type);
+ sub_die = modified_type_die (type,
+ cv_quals & ~TYPE_QUAL_STRICT,
+ context_die);
+}
+ else if (use_upc_dwarf2_extensions && cv_quals & TYPE_QUAL_RELAXED)
+{
+ mod_type_die = new_die (DW_TAG_upc_relaxed_type,
+ comp_unit_die (), type);
+ sub_die = modified_type_die (type,
+ cv_quals & ~TYPE_QUAL_RELAXED,
+ context_die);
+}
else if (code == POINTER_TYPE || code == REFERENCE_TYPE)
{
dwarf_tag tag = DW_TAG_pointer_type;
@@ -16992,6 +17036,12 @@ add_subscript_info (dw_die_ref type_die,
if (!subrange_die)
subrange_die = new_die (DW_TAG_subrange_type, type_die, NULL);
+
+ if (use_upc_dwarf2_extensions && TYPE_HAS_THREADS_FACTOR (type))
+{
+ add_AT_flag (subrange_die, DW_AT_upc_threads_scaled, 1);
+ }
+
if (domain)
{
/* We have an array type with specified bounds. */
@@ -20279,6 +20329,10 @@ gen_compile_unit_die (const char *filena
if (dwarf_version >= 5 /* || !dwarf_strict */)
if (strcmp (language_strin
[UPC 10/22] target - rs6000
Background
--
An overview email, describing the UPC-related changes is here:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html
The GUPC branch is described here:
http://gcc.gnu.org/projects/gupc.html
The UPC-related source code differences are summarized here:
http://gccupc.org/gupc-changes
All languages (c, c++, fortran, go, lto, objc, obj-c++) have been
bootstrapped; no test suite regressions were introduced,
relative to the GCC trunk.
If you are on the cc-list, your name was chosen either
because you are listed as a maintainer for the area that
applies to the patches described in this email, or you
were a frequent contributor of patches made to files listed
in this email.
In the change log entries included in each patch, the directory
containing the affected files is listed, followed by the files.
When the patches are applied, the change log entries will be
distributed to the appropriate ChangeLog file.
Overview
UPC pointers-to-shared have an internal representation that is a 'struct'.
GCC generally assumes that pointers can be targeted into registers.
However, various ABI's will special case how struct's are passed.
In order to insure that UPC pointers-to-shared can be passed to
the UPC runtime, which is written in "C", the convention used
to pass the UPC pointer-to-shared must agree with that of a struct,
because the runtime will describe the internal representation
as a struct.
The code below checks for UPC pointers-to-shared that are
represented as an aggregate type and insures that these
pointers are passed as struct's.
2015-11-30 Gary Funck <g...@intrepid.com>
gcc/config/rs6000/
* rs6000.c (rs6000_return_in_memory):
If TYPE is a UPC PTS type with a "struct" internal representation,
handle it as an aggregate type.
(rs6000_function_arg_boundary): For UPC pointers-to-shared with
alignment > 64 that have an internal "struct" representation,
return 128 and skip the ABI warning.
(rs6000_pass_by_reference): If TYPE is a UPC PTS type with
a "struct" internal representation, handle it as an aggregate type.
(rs6000_pass_by_reference): Exclude UPC pointers-to-shared
from the logic that returns pointers in either SImode or DImode.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (.../trunk) (revision 231059)
+++ gcc/config/rs6000/rs6000.c (.../branches/gupc) (revision 231080)
@@ -9709,12 +9709,21 @@ rs6000_return_in_memory (const_tree type
NULL, NULL))
return false;
+ /* TRUE if TYPE is a UPC pointer-to-shared type
+ and its underlying representation is an aggregate. */
+ bool upc_struct_pts_p = (POINTER_TYPE_P (type)
+&& SHARED_TYPE_P (TREE_TYPE (type)))
+ && AGGREGATE_TYPE_P (upc_pts_rep_type_node);
+ /* If TYPE is a UPC struct PTS type, handle it as an aggregate type. */
+ bool aggregate_p = AGGREGATE_TYPE_P (type)
+ || upc_struct_pts_p;
+
/* The ELFv2 ABI returns aggregates up to 16B in registers */
- if (DEFAULT_ABI == ABI_ELFv2 && AGGREGATE_TYPE_P (type)
+ if (DEFAULT_ABI == ABI_ELFv2 && aggregate_p
&& (unsigned HOST_WIDE_INT) int_size_in_bytes (type) <= 16)
return false;
- if (AGGREGATE_TYPE_P (type)
+ if (aggregate_p
&& (aix_struct_return
|| (unsigned HOST_WIDE_INT) int_size_in_bytes (type) > 8))
return true;
@@ -10040,6 +10049,18 @@ rs6000_function_arg_boundary (machine_mo
|| DEFAULT_ABI == ABI_ELFv2)
&& type && TYPE_ALIGN (type) > 64)
{
+
+ /* If the underlying UPC pointer-to-shared representation
+ is an aggregate, and TYPE is either a pointer-to-shared
+or the PTS representation type, then return 16-byte
+alignment and skip the ABI warning. */
+ if (upc_pts_rep_type_node
+ && AGGREGATE_TYPE_P (upc_pts_rep_type_node)
+ && ((POINTER_TYPE_P (type)
+ && SHARED_TYPE_P (TREE_TYPE (type)))
+ || (TYPE_MAIN_VARIANT (type) == upc_pts_rep_type_node)))
+ return 128;
+
/* "Aggregate" means any AGGREGATE_TYPE except for single-element
or homogeneous float/vector aggregates here. We already handled
vector aggregates above, but still need to check for float here. */
@@ -11320,7 +11341,16 @@ rs6000_pass_by_reference (cumulative_arg
return 1;
}
- if (DEFAULT_ABI == ABI_V4 && AGGREGATE_TYPE_P (type))
+ /* TRUE if TYPE is a UPC pointer-to-shared type
+ and its underlying representation is an aggregate. */
+ bool upc_struct_pts_p = (POINTER_TYPE_P (type)
+ && SHARE
[UPC 17/22] misc/common changes
Background
--
An overview email, describing the UPC-related changes is here:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html
The GUPC branch is described here:
http://gcc.gnu.org/projects/gupc.html
The UPC-related source code differences are summarized here:
http://gccupc.org/gupc-changes
All languages (c, c++, fortran, go, lto, objc, obj-c++) have been
bootstrapped; no test suite regressions were introduced,
relative to the GCC trunk.
If you are on the cc-list, your name was chosen either
because you are listed as a maintainer for the area that
applies to the patches described in this email, or you
were a frequent contributor of patches made to files listed
in this email.
In the change log entries included in each patch, the directory
containing the affected files is listed, followed by the files.
When the patches are applied, the change log entries will be
distributed to the appropriate ChangeLog file.
Overview
Given that UPC pointers-to-shared (PTS's) have special arithmetic rules
and their internal representation is a structure with
three separate fields, they are not meaningfully convertible to integers
and pointer arithmetic involving PTS's cannot be optimized in
the same fashion as normal "C" pointer arithmetic. Further,
the representation of a NULL pointer-to-shared is different from
a "C" null pointer. Logic has been added to convert.c and jump.c
to handle operations involving UPC PTS's. In function.c,
UPC pointers-to-shared which have an internal representation that
is a 'struct' are treated as aggregates. Also in function.c
logic is added that prevents marking them as potential
pointer register values.
In varasm.c, a check is added for the linker section used by
UPC to coalesce file scoped UPC shared variables. This section
is used only to assign offsets into UPC's shared data area for
the UPC shared variables. When UPC linker scripts are supported,
this shared section is not loaded and has an origin of 0.
2015-11-30 Gary Funck <g...@intrepid.com>
gcc/
* convert.c (convert_to_pointer): Add check for null
UPC pointer-to-shared.
(convert_to_integer): Do not optimize pointer
subtraction for UPC pointers-to-shared.
(convert_to_integer): Issue error for an attempt
to convert a UPC pointer-to-shared to an integer.
* dojump.c (do_jump): If a UPC pointer-to-shared conversion
can change representation, it must be compared in the result type.
* function.c (aggregate_value_p): Handle 'struct' pointer-to-shared
values as an aggregate when passing them as a return value.
(assign_parm_setup_reg): Do not target UPC pointers-to-shared that are
represented as a 'struct' into a pointer register.
* varasm.c (default_section_type_flags): Handle UPC's shared
section as BSS, and if a UPC link script is supported,
make it a non-loadable, read-only section.
Index: gcc/convert.c
===
--- gcc/convert.c (.../trunk) (revision 231059)
+++ gcc/convert.c (.../branches/gupc) (revision 231080)
@@ -53,6 +53,14 @@ convert_to_pointer_1 (tree type, tree ex
if (TREE_TYPE (expr) == type)
return expr;
+ if (integer_zerop (expr) && POINTER_TYPE_P (type)
+ && SHARED_TYPE_P (TREE_TYPE (type)))
+{
+ expr = copy_node (upc_null_pts_node);
+ TREE_TYPE (expr) = build_unshared_type (type);
+ return expr;
+}
+
switch (TREE_CODE (TREE_TYPE (expr)))
{
case POINTER_TYPE:
@@ -437,6 +445,16 @@ convert_to_integer_1 (tree type, tree ex
return error_mark_node;
}
+ /* Can't optimize the conversion of UPC shared pointer difference. */
+ if (ex_form == MINUS_EXPR
+ && POINTER_TYPE_P (TREE_TYPE (TREE_OPERAND (expr, 0)))
+ && POINTER_TYPE_P (TREE_TYPE (TREE_OPERAND (expr, 1)))
+ && SHARED_TYPE_P (TREE_TYPE (TREE_TYPE (TREE_OPERAND (expr, 0
+ && SHARED_TYPE_P (TREE_TYPE (TREE_TYPE (TREE_OPERAND (expr, 1)
+ {
+ return build1 (CONVERT_EXPR, type, expr);
+ }
+
if (ex_form == COMPOUND_EXPR)
{
tree t = convert_to_integer_1 (type, TREE_OPERAND (expr, 1), dofold);
@@ -581,6 +599,12 @@ convert_to_integer_1 (tree type, tree ex
{
case POINTER_TYPE:
case REFERENCE_TYPE:
+ if (SHARED_TYPE_P (TREE_TYPE (intype)))
+{
+ error ("invalid conversion from a UPC pointer-to-shared "
+"to an integer");
+ expr = integer_zero_node;
+}
if (integer_zerop (expr))
return build_int_cst (type, 0);
Index: gcc/dojump.c
===
--- gcc/dojump.c(.../trunk) (revision 231059)
+++ gcc/dojump.c(.../branches/gupc) (revision 231080)
@@ -468,6 +468,10 @@ do_jump
RFC: Merge the GUPC branch into the GCC 6.0 trunk
Some time ago, we submitted an RFC for the introduction of
UPC support into GCC. During the intervening time period,
we have continued to keep the 'gupc' (GNU UPC) branch in sync
with the GCC trunk and have incorporated feedback and contributions from
various GCC developers (Joseph Myers, Tom Tromey, Jakub Jelinek,
Richard Henderson, Meador Inge, and others). We have also implemented
various bug fixes and improvements.
At this time, we would like to re-submit the UPC patches for comment
with the goal of introducing these changes into GCC 6.0.
This email provides an overview of UPC and summarizes the
impact of UPC changes on the GCC front-end.
Subsequent emails will include various patch sets which are grouped
by the area of GCC that they impact (front-end, generic, documentation,
build, test, target-specific, and so on), so that they can receive
a more focused review by their respective maintainers.
The main review-related changes are:
* GUPC is no longer implemented as a separate language
(e.g., Objective-C or C++) compiler. Rather, a new -fupc switch
has been added, which enables UPC support in the C compiler.
* The UPC blocking factor now only uses two of the tree's
"spare" bits. If the UPC blocking factor is not the default
value of 1 or the "indefinite" value of 0, then it is recorded
in a separate hash table, indexed by the tree node.
* UPC-specific tree support has been integrated into
gcc/c-family/c-common.def and gcc/c-family/c-common.h.
* The number of UPC-specific configuration options
have been reduced.
* The UPC pointer-to-shared format per-target configuration
has been simplified. Before, both a "packed" and a "struct"
pointer-to-shared representation was supported. Now, only
the "struct" format is supported and various configuration
options for tweaking field sizes and such have been removed.
* In keeping with current GCC development guidelines
target macros are no longer used. Rather, where needed,
target hooks are defined and used.
* FIXME's and TODO's were either fixed or cleaned up.
* The copyright and license notices were updated.
* The code was reviewed for conformance to coding standards and updated.
* Diagnostics now use appropriate format strings rather than building
up the strings with sprintf().
* Files in c-family/ no longer include c-tree.h to conform with modularization
improvements.
* Most of the #ifdef conditionals have been removed. Some target hooks
have been defined and documented in tm.texi.
* The code was reviewed to verify that it conforms with
current GCC coding practices and that it incorporates cleanups
done in the past several years.
* Comments were added to most new functions, and typos and
spelling errors in comments were fixed.
* Changes that appeared in the diff's that were unrelated to UPC
were removed or incorporated into the trunk.
* The linkage to the libgupc library was changed to use the newly
defined method (used in libgomp/libgo for example) of including
library 'spec' files. This led to a simplification where we no
longer needed to add UPC-specific spec. files in various
target-specific config. directories.
Introduction: UPC-related Changes
-
Below, various UPC-related changes are summarized.
This introduction is provided as background for review of the UPC
changes implemented in the GUPC branch. Each individual change will be
discussed in more detail in the patch sets found in the following emails.
The current GUPC branch is based upon a recent version of the GCC trunk
and has been bootstrapped on x86_64/i686 Linux, x86_64
Darwin, IA64/Altix Linux, PowerPC Power7 (big endian), and Power8
(little endian). Also some testing has been done on various flavors
of BSD and Solaris and in the past MIPS was tested and supported.
All languages (c, c++, fortran, go, lto, objc, obj-c++) have been
bootstrapped; no test suite regressions were introduced,
relative to the GCC trunk.
The GUPC branch is described here:
http://gcc.gnu.org/projects/gupc.html
The UPC-related source code differences are summarized here:
http://gccupc.org/gupc-changes
In the discussion below, some changes are excerpted in order to
highlight important aspects of the changes.
UPC's Shared Qualifier and Layout Qualifier
---
The UPC language specification describes
the language syntax and semantics:
http://upc.lbl.gov/publications/upc-spec-1.3.pdf
UPC introduces a new qualifier, "shared" that indicates that the
qualified object is located in a global shared address space that is
accessible by all UPC threads. Additional qualifiers ("strict" and
"relaxed") further specify the semantics of accesses to
UPC shared objects.
In UPC, a shared qualified array can optionally specify a "layout
qualifier" that indicates how the shared data is blocked and
distributed across UPC threads.
There are two language pre-defined identifiers that indicate the
number of threads that will be
[UPC 02/22] tree-related changes
blocking factor of 1. If the blocking factor is 0
(known as "indefinite") then 'block_factor_0' is set. If the blocking
factor is neither 0 nor 1, then 'block_factor_x' is set and the
actual blocking factor is found in a 'tree map' hash table called
'block_factor_htab' which is managed in tree.c.
This use of a garbage collected hash table which maps tree nodes to
a UPC blocking factor leads to a need to implement custom garbage
collection logic for all tree nodes. This custom garbage collection
logic is implemented in gt_ggc_mx(). PCH support is implemented
in gt_pch_nx(). This custom garbage collector is defined in tree-core.h
as follows:
-struct GTY(()) tree_type_common {
+struct GTY((user)) tree_type_common {
struct tree_common common;
tree size;
tree size_unit;
[...]
tree pointer_to;
tree reference_to;
union tree_type_symtab {
-int GTY ((tag ("TYPE_SYMTAB_IS_ADDRESS"))) address;
-const char * GTY ((tag ("TYPE_SYMTAB_IS_POINTER"))) pointer;
-struct die_struct * GTY ((tag ("TYPE_SYMTAB_IS_DIE"))) die;
- } GTY ((desc ("debug_hooks->tree_type_symtab_field"))) symtab;
+ int address;
+const char *pointer;
+struct die_struct *die;
+ } symtab;
tree canonical;
tree next_variant;
Above, 'tree_type_symtab' has to be explicitly traversed by
the garbage collection routine.
2015-11-30 Gary Funck <g...@intrepid.com>
gcc/
* expr.c (tree_expr_size): Move to tree.c and make it an
extern function.
* print-tree.c (print_node): Print UPC "shared" qualifier
and blocking factor (if present). Indicate THREADS scaling,
if present.
* tree-core.h (cv_qualifier): Add UPC type qualifiers:
TYPE_QUAL_SHARED, TYPE_QUAL_RELAXED, and TYPE_QUAL_STRICT.
(tree_index): Add UPC tree indexes:
TI_UPC_PTS_TYPE, TI_UPC_PTS_REP_TYPE, TI_UPC_CHAR_PTS_TYPE,
TI_UPC_PHASE_FIELD, TI_UPC_THREAD_FIELD, TI_UPC_VADDR_FIELD,
TI_UPC_NULL_PTS.
(tree_base): Add UPC-specific flags:
shared_flag, strict_flag, relaxed_flag, threads_factor_flag,
block_factor_0, block_factor_x.
(tree_type_common): Remove ggc tag type descriptions in
tree_type_symtab fields to accommodate UPC-related garbage collection
changes.
(gt_ggc_mx, gt_pch_nx, gt_pch_nx): New prototypes.
Add custom garbage collection and PCH support for tree_type_common.
* tree-dump.c (dequeue_and_dump): Add qualifier tags for
UPC language qualifier (shared, strict, relaxed).
* tree-pretty-print.c (dump_upc_type_quals): Print UPC language
qualifiers and blocking factor.
(dump_generic_node): Call dump_upc_type_quals()
if the type asserts the "shared" qualifier.
Print UPC qualifiers if applied to a tree node.
Print type name for the UPC pointer-to-shared representation type.
* tree-sra.c (find_param_candidates):
Exclude UPC pointer-to-shared types.
* tree.c: #include "debug.h". Needed for access to symtab
definition in the tree node garbage collection logic.
(tm_block_factor_hasher, block_factor_htab): New.
Define a garbage-collected mapping from tree node to
UPC blocking factor.
(init_ttree): Call block_factor_lookup_init().
(copy_node_stat): Call SET_TYPE_BLOCK_FACTOR if
type has a UPC blocking factor.
(tree_expr_size): Move from expr.c and make it an
'extern' function.
(stabilize_reference_1): Copy UPC qualifiers to result.
(build1_stat): Copy shared qualifier from type node.
(build1_stat, build2_stat): For unary and binary operations,
remove UPC "shared" qualifiers from the result type.
(build3_stat): For reference expressions, ensure that
the result node preserves the UPC qualifiers applied to the
first argument.
(set_type_quals): Add a 'tree' argument for the
UPC layout qualifier (blocking factor). Set the blocking factor
if the type asserts the "shared" qualifier.
(check_qualified_type): Add a 'tree' argument for the
UPC layout qualifier (blocking factor). Include the blocking factor
into the type check.
(check_aligned_type): Include the blocking factor
into the type check.
(get_qualified_type_1): Rename get_qualified_type()
to get_qualified_type_1() and add a blocking factor argument.
A #define of get_qualified_type is added to tree.h;
it will call get_qualified_type_1() with a null layout qualifier.
(build_qualified_type): Adjust calls to
get_qualified_type_1() and set_type_quals().
(build_pointer_type): For UPC pointer-to-shared types
ensure that the resulting pointer type is compatible with the
UPC pointer-to-shared representation typ
[UPC 20/22] libgupc runtime library [4/9]
[NOTE: Due to email list size limits, this patch is broken into 9 parts.] Background -- An overview email, describing the UPC-related changes is here: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html The GUPC branch is described here: http://gcc.gnu.org/projects/gupc.html The UPC-related source code differences are summarized here: http://gccupc.org/gupc-changes All languages (c, c++, fortran, go, lto, objc, obj-c++) have been bootstrapped; no test suite regressions were introduced, relative to the GCC trunk. If you are on the cc-list, your name was chosen either because you are listed as a maintainer for the area that applies to the patches described in this email, or you were a frequent contributor of patches made to files listed in this email. In the change log entries included in each patch, the directory containing the affected files is listed, followed by the files. When the patches are applied, the change log entries will be distributed to the appropriate ChangeLog file. Overview Libgupc is the UPC runtime library, for GUPC. The configuration, makefile, and documentation related changes have been broken out into separate patches. As noted in the ChangeLog entry below, this is all new code. Two communication layers are supported: (1) SMP, via 'mmap' or (2) the Portals4 library API, which supports multi-node operation. Libgupc generally requires a POSIX-compliant target OS. The 'smp' runtime is the default runtime. The 'portals4' runtime is experimental; it supports multi-node operation using the Portals4 communications library. Most of the libgupc/include/ directory contains standard headers defined by the UPC language specification. 'make install' will install these headers in the directory where other "C" header files are located. 2015-11-30 Gary Funck <g...@intrepid.com> libgupc/collectives/ * upc_coll.h: New. * upc_coll_broadcast.upc: New. * upc_coll_err.upc: New. * upc_coll_exchange.upc: New. * upc_coll_gather.upc: New. * upc_coll_gather_all.upc: New. * upc_coll_init.upc: New. Index: libgupc/collectives/upc_coll.h === --- libgupc/collectives/upc_coll.h (.../trunk) (revision 0) +++ libgupc/collectives/upc_coll.h (.../branches/gupc) (revision 231080) @@ -0,0 +1,67 @@ +/* Copyright (C) 2012-2015 Free Software Foundation, Inc. + This file is part of the UPC runtime library. + Written by Gary Funck <g...@intrepid.com> + and Nenad Vukicevic <ne...@intrepid.com> + +This file is part of GCC. + +GCC is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 3, or (at your option) +any later version. + +GCC is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +Under Section 7 of GPL version 3, you are granted additional +permissions described in the GCC Runtime Library Exception, version +3.1, as published by the Free Software Foundation. + +You should have received a copy of the GNU General Public License and +a copy of the GCC Runtime Library Exception along with this program; +see the files COPYING3 and COPYING.RUNTIME respectively. If not, see +<http://www.gnu.org/licenses/>. */ + +/*/ +/* */ +/* Copyright (c) 2004, Michigan Technological University*/ +/* All rights reserved. */ +/* */ +/* Redistribution and use in source and binary forms, with or without */ +/* modification, are permitted provided that the following conditions */ +/* are met: */ +/* */ +/* * Redistributions of source code must retain the above copyright */ +/* notice, this list of conditions and the following disclaimer.*/ +/* * Redistributions in binary form must reproduce the above*/ +/* copyright notice, this list of conditions and the following */ +/* disclaimer in the documentation and/or other materials provided */ +/* with the distribution. */ +/* * Neither the name of the Michigan Technological University */ +/* nor the names of its contributors may be used to endorse or promote */ +/* products derived from this softw
[UPC 20/22] libgupc runtime library [1/9]
[NOTE: Due to email list size limits, this patch is broken into 9 parts.] Background -- An overview email, describing the UPC-related changes is here: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html The GUPC branch is described here: http://gcc.gnu.org/projects/gupc.html The UPC-related source code differences are summarized here: http://gccupc.org/gupc-changes All languages (c, c++, fortran, go, lto, objc, obj-c++) have been bootstrapped; no test suite regressions were introduced, relative to the GCC trunk. If you are on the cc-list, your name was chosen either because you are listed as a maintainer for the area that applies to the patches described in this email, or you were a frequent contributor of patches made to files listed in this email. In the change log entries included in each patch, the directory containing the affected files is listed, followed by the files. When the patches are applied, the change log entries will be distributed to the appropriate ChangeLog file. Overview Libgupc is the UPC runtime library, for GUPC. The configuration, makefile, and documentation related changes have been broken out into separate patches. As noted in the ChangeLog entry below, this is all new code. Two communication layers are supported: (1) SMP, via 'mmap' or (2) the Portals4 library API, which supports multi-node operation. Libgupc generally requires a POSIX-compliant target OS. The 'smp' runtime is the default runtime. The 'portals4' runtime is experimental; it supports multi-node operation using the Portals4 communications library. Most of the libgupc/include/ directory contains standard headers defined by the UPC language specification. 'make install' will install these headers in the directory where other "C" header files are located. 2015-11-30 Gary Funck <g...@intrepid.com> libgupc/ * upc-crtstuff.c: New. libgupc/include/ * gasp.h: New. * gasp_upc.h: New. * gcc-upc.h: New. * pupc.h: New. * upc.h: New. * upc_atomic.h: New. * upc_castable.h: New. * upc_collective.h: New. * upc_nb.h: New. * upc_relaxed.h: New. * upc_strict.h: New. * upc_tick.h: New. * upc_types.h: New. Index: libgupc/upc-crtstuff.c === --- libgupc/upc-crtstuff.c (.../trunk) (revision 0) +++ libgupc/upc-crtstuff.c (.../branches/gupc) (revision 231080) @@ -0,0 +1,66 @@ +/* upc-crtstuff.c: UPC specific "C Runtime Support" + Copyright (C) 2009-2015 Free Software Foundation, Inc. + Contributed by Gary Funck <g...@intrepid.com> + and Nenad Vukicevic <ne...@intrepid.com>. + +This file is part of GCC. + +GCC is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 3, or (at your option) +any later version. + +GCC is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GCC; see the file COPYING3. If not see +<http://www.gnu.org/licenses/>. */ + +#include "config.h" +#include "upc-crt-config.h" +#include "upc-crt-begin-end.h" + +/* Only define section start/end if no link script is used. */ + +#ifdef CRT_BEGIN + +/* Shared begin is always defined in order to allocate space + at the beginning of the section. */ +#ifdef UPC_SHARED_SECTION_BEGIN +/* Establish a symbol at the beginning of the data section. */ +UPC_SHARED_SECTION_BEGIN +#endif /* UPC_SHARED_SECTION_BEGIN */ + +#ifndef HAVE_UPC_LINK_SCRIPT +#ifdef UPC_PGM_INFO_SECTION_BEGIN +/* Establish a symbol at the beginning of the program info data section. */ +UPC_PGM_INFO_SECTION_BEGIN +#endif /* UPC_PGM_INFO_SECTION_BEGIN */ +#ifdef UPC_INIT_ARRAY_SECTION_BEGIN +/* Establish a symbol at the beginning of the initialization array section. */ +UPC_INIT_ARRAY_SECTION_BEGIN +#endif /* UPC_INIT_ARRAY_SECTION_BEGIN */ +#endif /* !HAVE_UPC_LINK_SCRIPT */ + +#elif defined(CRT_END) /* ! CRT_BEGIN */ + +#ifndef HAVE_UPC_LINK_SCRIPT +#ifdef UPC_SHARED_SECTION_END +/* Establish a symbol at the end of the shared data section. */ +UPC_SHARED_SECTION_END +#endif /* UPC_SHARED_SECTION_END */ +#ifdef UPC_PGM_INFO_SECTION_END +/* Establish a symbol at the end of the program info data section. */ +UPC_PGM_INFO_SECTION_END +#endif /* UPC_PGM_INFO_SECTION_END */ +#ifdef UPC_INIT_ARRAY_SECTION_END +/* Establish a symbol at the end of the initialization array section. */ +UPC_INIT_ARRAY_SECTION_END +#endif /* UPC_INIT_ARRAY_SECTION_END */ +#endif /* !HAVE_UPC_LINK_SCRIPT */ +#else /* ! CRT_BEGIN &
[UPC 20/22] libgupc runtime library [6/9]
[NOTE: Due to email list size limits, this patch is broken into 9 parts.] Background -- An overview email, describing the UPC-related changes is here: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html The GUPC branch is described here: http://gcc.gnu.org/projects/gupc.html The UPC-related source code differences are summarized here: http://gccupc.org/gupc-changes All languages (c, c++, fortran, go, lto, objc, obj-c++) have been bootstrapped; no test suite regressions were introduced, relative to the GCC trunk. If you are on the cc-list, your name was chosen either because you are listed as a maintainer for the area that applies to the patches described in this email, or you were a frequent contributor of patches made to files listed in this email. In the change log entries included in each patch, the directory containing the affected files is listed, followed by the files. When the patches are applied, the change log entries will be distributed to the appropriate ChangeLog file. Overview Libgupc is the UPC runtime library, for GUPC. The configuration, makefile, and documentation related changes have been broken out into separate patches. As noted in the ChangeLog entry below, this is all new code. Two communication layers are supported: (1) SMP, via 'mmap' or (2) the Portals4 library API, which supports multi-node operation. Libgupc generally requires a POSIX-compliant target OS. The 'smp' runtime is the default runtime. The 'portals4' runtime is experimental; it supports multi-node operation using the Portals4 communications library. Most of the libgupc/include/ directory contains standard headers defined by the UPC language specification. 'make install' will install these headers in the directory where other "C" header files are located. 2015-11-30 Gary Funck <g...@intrepid.com> libgupc/collectives/ * upc_coll_reduce.upc: New. * upc_coll_scatter.upc: New. * upc_coll_sort.upc: New. Index: libgupc/collectives/upc_coll_reduce.upc === --- libgupc/collectives/upc_coll_reduce.upc (.../trunk) (revision 0) +++ libgupc/collectives/upc_coll_reduce.upc (.../branches/gupc) (revision 231080) @@ -0,0 +1,4296 @@ +/* Copyright (C) 2012-2015 Free Software Foundation, Inc. + This file is part of the UPC runtime library. + Written by Gary Funck <g...@intrepid.com> + and Nenad Vukicevic <ne...@intrepid.com> + +This file is part of GCC. + +GCC is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 3, or (at your option) +any later version. + +GCC is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +Under Section 7 of GPL version 3, you are granted additional +permissions described in the GCC Runtime Library Exception, version +3.1, as published by the Free Software Foundation. + +You should have received a copy of the GNU General Public License and +a copy of the GCC Runtime Library Exception along with this program; +see the files COPYING3 and COPYING.RUNTIME respectively. If not, see +<http://www.gnu.org/licenses/>. */ + +/*/ +/* */ +/* Copyright (c) 2004, Michigan Technological University*/ +/* All rights reserved. */ +/* */ +/* Redistribution and use in source and binary forms, with or without */ +/* modification, are permitted provided that the following conditions */ +/* are met: */ +/* */ +/* * Redistributions of source code must retain the above copyright */ +/* notice, this list of conditions and the following disclaimer.*/ +/* * Redistributions in binary form must reproduce the above*/ +/* copyright notice, this list of conditions and the following */ +/* disclaimer in the documentation and/or other materials provided */ +/* with the distribution. */ +/* * Neither the name of the Michigan Technological University */ +/* nor the names of its contributors may be used to endorse or promote */ +/* products derived from this software without specific prio
Re: top-level configure.ac: factor the libgomp check for posix-like OS
Ended up using the same approach as libatomic,
moving the checking logic into libgupc/configure.tgt.
+# Disable libgupc on unsupported systems.
+if test -d ${srcdir}/libgupc; then
+if test x$enable_libgupc = x; then
+ AC_MSG_CHECKING([for libgupc support])
+ if (srcdir=${srcdir}/libgupc; \
+ . ${srcdir}/configure.tgt; \
+ test -n $UNSUPPORTED)
+ then
+ AC_MSG_RESULT([no])
+ noconfigdirs=$noconfigdirs target-libgupc
+ else
+ AC_MSG_RESULT([yes])
+ fi
+fi
+fi
+
Thanks,
- Gary
Re: top-level configure.ac: factor the libgomp check for posix-like OS
On 08/18/15 08:52:31, Thomas Schwinge wrote: Even if applicable regarding the libgomp configuration (because nvptx-none has its own libgomp port: libgomp/config/nvptx/), it seems a bit strange to qualify nvptx-none as a POSIX-like system. Hmm... + +# Enable libgomp by default on POSIX hosted systems. +if test x$enable_libgomp = x test $posix_like_os = no ; then +# Disable libgomp on non POSIX hosted systems. +noconfigdirs=$noconfigdirs target-libgomp fi So, we'll have to see whether that applies to libgupc for nvptx-none, too. http://www.phoronix.com/scan.php?page=news_itempx=MTgzNTM At the moment, I'd say nvptx is out-of-scope for GUPC. I guess it is more complicated than I thought. It just seems a bit odd to replicate that case statement, sans nvptx, for libgupc. thanks, - Gary
top-level configure.ac: factor the libgomp check for posix-like OS
I'm working on a patch set for GUPC, and as part of that work,
I may have a couple changes to trunk that will improve the fit
with the GUPC changes. Here's one in configure.ac.
At the moment, there is a check to see if $enable_libgom
is not set, followed by a case statement which adds
libgomp to $noconfigdirs on non POSIX-like OS's.
We'd like to re-use that logic for libgupc,
which has a similar requirement and propose this
re-factoring for trunk.
2015-08-17 Gary Funck g...@intrepid.com
* configure.ac (noconfigdirs): Factor libgomp logic testing for
POSIX-like host OS.
* configure: Re-generate.
Index: configure.ac
===
--- configure.ac(revision 226928)
+++ configure.ac(working copy)
@@ -529,9 +529,8 @@ if test x$enable_static_libjava != xyes
fi
AC_SUBST(EXTRA_CONFIGARGS_LIBJAVA)
-# Enable libgomp by default on hosted POSIX systems, and a few others.
-if test x$enable_libgomp = x ; then
-case ${target} in
+posix_like_os=yes
+case ${target} in
*-*-linux* | *-*-gnu* | *-*-k*bsd*-gnu | *-*-kopensolaris*-gnu)
;;
*-*-netbsd* | *-*-freebsd* | *-*-openbsd* | *-*-dragonfly*)
@@ -543,9 +542,14 @@ if test x$enable_libgomp = x ; then
nvptx*-*-*)
;;
*)
- noconfigdirs=$noconfigdirs target-libgomp
- ;;
-esac
+posix_like_os=no
+;;
+esac
+
+# Enable libgomp by default on POSIX hosted systems.
+if test x$enable_libgomp = x test $posix_like_os = no ; then
+# Disable libgomp on non POSIX hosted systems.
+noconfigdirs=$noconfigdirs target-libgomp
fi
# Disable libatomic on unsupported systems.
Re: c-family/c-pretty-print.c - fix for 'restrict' quliafiers
On 08/17/15 12:06:08, Marek Polacek wrote: No, I don't think this assignment is missing here. The restrict qualifier is printed last so we don't need to mark that we've printed something. Actually, the whole previous flag seems to be redundant; pp_c_ws_string calls pp_c_maybe_whitespace so it prints a whitespace if necessary. OK. I'm not familiar with this code, so please go ahead and make the changes as needed. - Gary
c-family/c-pretty-print.c - fix for 'restrict' quliafiers
While reviewing some code, I noticed that the logic for
pretty-printing 'restrict' qualifiers is likely missing a
statement that sets 'previous'.
OK to commit?
2015-08-l6 Gary Funck g...@intrepid.com
* c-pretty-print.c (pp_c_cv_qualifiers):
Set 'previous' for restrict qualifiers.
Index: c-pretty-print.c
===
--- c-pretty-print.c(revision 226928)
+++ c-pretty-print.c(working copy)
@@ -207,16 +207,17 @@ pp_c_cv_qualifiers (c_pretty_printer *pp
}
if (qualifiers TYPE_QUAL_RESTRICT)
{
if (previous)
pp_c_whitespace (pp);
pp_c_ws_string (pp, (flag_isoc99 !c_dialect_cxx ()
? restrict : __restrict__));
+ previous = true;
}
}
/* Pretty-print T using the type-cast notation '( type-name )'. */
static void
pp_c_type_cast (c_pretty_printer *pp, tree t)
{
[PATCH] Fix PR middle-end/66984 - mis-optimization of CEIL_DIV_EXPR and FLOOR_DIV_EXPR
See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66984 Confirmed that GCC trunk bootstraps without issue and that this patch fixes the issue noted in the GUPC branch. 2015-07-24 Gary Funck g...@intrepid.com PR middle-end/66984 * fold-const.c (fold_binary_loc): Call fold_convert on arguments to fold_build2 for CEIL_DIV_EXPR and FLOOR_DIV_EXPR optimization. Index: fold-const.c === --- fold-const.c(revision 226135) +++ fold-const.c(working copy) @@ -10804,7 +10804,9 @@ fold_binary_loc (location_t loc, after the last round to changes to the DIV code in expmed.c. */ if ((code == CEIL_DIV_EXPR || code == FLOOR_DIV_EXPR) multiple_of_p (type, arg0, arg1)) - return fold_build2_loc (loc, EXACT_DIV_EXPR, type, arg0, arg1); + return fold_build2_loc (loc, EXACT_DIV_EXPR, type, + fold_convert (type, arg0), + fold_convert (type, arg1)); strict_overflow_p = false; if (TREE_CODE (arg1) == INTEGER_CST
Re: [PATCH] Fix PR middle-end/66984 - mis-optimization of CEIL_DIV_EXPR and FLOOR_DIV_EXPR
On 07/24/15 08:43:05, Gary Funck wrote: See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66984 Confirmed that GCC trunk bootstraps without issue and that this patch fixes the issue noted in the GUPC branch. 2015-07-24 Gary Funck g...@intrepid.com PR middle-end/66984 * fold-const.c (fold_binary_loc): Call fold_convert on arguments to fold_build2 for CEIL_DIV_EXPR and FLOOR_DIV_EXPR optimization. Committed, pre-approved. Author: gfunck Date: Fri Jul 24 16:10:39 2015 New Revision: 226168 URL: https://gcc.gnu.org/viewcvs?rev=226168root=gccview=rev
Re: Copy TYPE_NO_FORCE_BLK in finalize_type_size
On 05/22/15 17:44:23, Jan Hubicka wrote: PR 66181 is about ICE in verify_type that complains that type and its variant differs by TYPE_NO_FORCE_BLK. Also PR 66283, on IA64. Has a small test case.
Re: libgo patch committed: Merge from revision 18783 of master
On 06/04/14 18:28:17, Ian Lance Taylor wrote:
I have committed a patch to libgo to merge from revision
18783:00cce3a34d7e of the master library.
Based on trunk rev. 211365, we're seeing this warning:
libgo/runtime/chan.c:484:7: error: ‘received’ may be used uninitialized
in this function [-Werror=maybe-uninitialized]
bool received;
^
Here:
481 _Bool
482 runtime_chanrecv2(ChanType *t, Hchan* c, byte* v)
483 {
484 bool received;
485
486 chanrecv(t, c, v, true, received);
487 return received;
488 }
Re: libgo patch committed: Merge from revision 18783 of master
On Mon, Jun 9, 2014 at 5:36 PM, Ian Lance Taylor i...@google.com wrote: There is no bug here, the control flow is just too complicated for the compiler to sort out. I don't know why I'm not seeing the warning [...] We have these compilation flags set: CFLAGS='-g3 -O3' CFLAGS_FOR_BUILD='-g3 -O3' CFLAGS_FOR_TARGET='-g3 -O3' I tried make CFLAGS='-g3 -O2' chan.lo (the default) and it compiled without complaint.
Re: Symtab cleanups 4/17 - ICE in GUPC due to use of init section
On 06/18/13 16:37:04, Gary Funck wrote:
The initialization function is currently generated in tree form in the
usual way (it will be gimplified when the gimple pass is run).
The code that is being generated is roughly equivalent to:
static void
__upc_init_decls (void)
{
/* Compiler generated:
Initialize data related to UPC shared variables. */
}
static void (*const __upc_init_addr) (void)
__attribute__ ((section (upc_init_array))) = __upc_init_decls;
I tried building a variable declaration along the
lines of __upc_init_addr above, by defining this function:
/* Create a static variable of type 'type'.
This routine mimics the behavior of 'objc_create_temporary_var'
with the change that it creates a static (file scoped) variable.
If we continue to need this function, the two implementations
should be unified. */
static tree
upc_create_static_var (tree type, const char *name)
{
tree id = (name != NULL) ? get_identifier (name) : NULL;
tree decl = build_decl (input_location, VAR_DECL, id, type);
TREE_USED (decl) = 1;
TREE_EXTERNAL (decl) = 0;
TREE_STATIC (decl) = 1;
TREE_READONLY (decl) = 1;
TREE_THIS_VOLATILE (decl) = 0;
TREE_ADDRESSABLE (decl) = 0;
DECL_PRESERVE_P (decl) = 1;
DECL_ARTIFICIAL (decl) = 1;
DECL_IGNORED_P (decl) = 1;
DECL_CONTEXT (decl) = NULL;
return decl;
}
and then using it as follows:
init_func_ptr_type = build_pointer_type (TREE_TYPE (init_func));
init_func_addr = upc_create_static_var (init_func_ptr_type, NULL);
DECL_INITIAL (init_func_addr) = build_unary_op (loc, ADDR_EXPR,
init_func, 0);
DECL_SECTION_NAME (init_func_addr) = build_string (
strlen (UPC_INIT_ARRAY_SECTION_NAME),
UPC_INIT_ARRAY_SECTION_NAME);
The variable declaration tree node looks about right to me.
However, it never makes it into the output assembler file.
What is the recommended method for making sure that the
static variable created above is associated with the current
translation unit and that its initialization makes it into
the assembler output file?
Thanks,
- Gary
Re: Symtab cleanups 4/17 - ICE in GUPC due to use of init section
On 06/19/13 09:26:30, Gary Funck wrote: The variable declaration tree node looks about right to me. However, it never makes it into the output assembler file. What is the recommended method for making sure that the static variable created above is associated with the current translation unit and that its initialization makes it into the assembler output file? Adding this call to the upc_create_static_var() routine implemented the necessary binding: pushdecl_top_level (decl); pushdecl_top_level() is defined in c/c-decl.c: /* Record X as belonging to file scope. This is used only internally by the Objective-C front end, and is limited to its needs. duplicate_decls is not called; if there is any preexisting decl for this identifier, it is an ICE. */ tree pushdecl_top_level (tree x) [...] This also required that the temporary variable being created needs to be named (have a non-null DECL_NAME()). This doesn't seem ideal, but does generate the desired code.
Re: Symtab cleanups 4/17 - ICE in GUPC due to use of init section
On 06/05/13 16:18:52, Jan Hubicka wrote:
Hi,
this patch deals with C++ keyed methods and explicit instantiations.
Currently C++ calls mark_used that ultimately sets force_output
on the functions. This is equivalent to attribute ((used))
on the function/variable and it is bit too strong.
[...]
This patch leads to in ICE on the GUPC branch after attempting
a merge from the trunk. This may be because GUPC is attempting
to write to the (assembler) output too early, or because
some additional tree meta data needs to be set before the
cgraph-related pass is run.
I'd appreciate your suggestions on how to best make this work
within the new scheme of things.
As background, in certain situations GUPC generates initialization
code that is run before main() is called. This initialization code
is run after the UPC runtime has set up things like shared memory.
The actual program initial entry point (main) is in the runtime.
GCC's constructors won't do the job here because constructors are
run _before_ the runtime's main() entry point is called.
The ICE (in debug builds with checks enabled) is shown below.
test25.upc:91:1: internal compiler error: in decide_is_symbol_needed, at
cgraphunit.c:230
This failure occurs in tests that require active initialization of shared
variables or static variables that are initialized with expressions involving
the addresses of UPC shared variables.
This assertion is failing:
227 /* Double check that no one output the function into assembly file
228 early. */
229 gcc_checking_assert (!DECL_ASSEMBLER_NAME_SET_P (decl)
230 || !TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME
The failure is a result of this patch:
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00240.html [^]
It was committed as:
r199695 | hubicka | 2013-06-05 07:15:31 -0700 (Wed, 05 Jun 2013)
The reason that this fails is that GNU UPC has the following code in
gcc/upc/upc-act.c:
/* Build a function that will be called by the UPC runtime
to initialize UPC shared variables. STMT_LIST is a
list of initialization statements. */
static void
upc_build_init_func (const tree stmt_list)
{
[...]
finish_function ();
gcc_assert (DECL_RTL (init_func));
mark_decl_referenced (init_func);
DECL_PRESERVE_P (init_func) = 1;
upc_init_array_section =
get_section (UPC_INIT_ARRAY_SECTION_NAME, 0, NULL);
init_func_symbol = XEXP (DECL_RTL (init_func), 0);
assemble_addr_to_section (init_func_symbol, upc_init_array_section);
}
See:
http://gcc.gnu.org/viewcvs/gcc/branches/gupc/gcc/upc/upc-act.c?revision=197503view=markup
(near line 1448).
The function upc_build_init_func() is called after the entire compilation unit
has been compiled. It is called from upc_write_global_declarations() which is
called from c_common_parse_file(), just after parsing the main source file.
1054 void
1055 c_common_parse_file (void)
1056 {
1057 unsigned int i;
1058
1059 i = 0;
1060 for (;;)
1061 {
1062 c_finish_options ();
1063 pch_init ();
1064 push_file_scope ();
1065 c_parse_file ();
1066 /* Generate UPC global initialization code, if required. */
1067 if (c_dialect_upc ())
1068 upc_write_global_declarations ();
1069 pop_file_scope ();
See:
http://gcc.gnu.org/viewcvs/gcc/branches/gupc/gcc/c-family/c-opts.c?revision=198453view=markup
(near line 1068).
It seems that GUPC may be calling assemble_addr_to_section() too early and that
some other method of locating the UPC shared data related initialization into
the UPC upc_init_array section needs to be implemented. Either that,
or something needs to be set in the function's tree node to indicate
that no further special handling is needed. Please advise.
Thanks,
- Gary
Re: Symtab cleanups 4/17 - ICE in GUPC due to use of init section
On 06/18/13 22:27:51, Steven Bosscher wrote:
The advice would have to be that the front end should not write out
anything to the assembler file.
Why not just emit the function as GIMPLE (even if your stmt_list is
empty) and let your main() call it?
The initialization function is currently generated in tree form in the
usual way (it will be gimplified when the gimple pass is run).
The code that is being generated is roughly equivalent to:
static void
__upc_init_decls (void)
{
/* Compiler generated:
Initialize data related to UPC shared variables. */
}
static void (*const __upc_init_addr) (void)
__attribute__ ((section (upc_init_array))) = __upc_init_decls;
The __upc_init_decls() function is generated on a per file (compilation unit)
basis, if there is UPC related data that needs to be initialized.
Thus, calling it from main() will not be sufficient. The address
of this function is added to the section named upc_init_array.
Sentinel symbols are added to the section by the inclusion of
a upcrtbegin.o and upcrtend.o file. This is done by the gupc
command line driver. The UPC runtime traverses this table
and calls each per file initialization function.
Would you happen to know of any code in GCC that creates a
file scoped variable and initializes, perhaps along the lines
of that shown above? I should be able to eventually figure
something out, but any pointers/suggestions would be appreciated.
Note that in the longer term it be better not to create a
uniquely named section for this purpose, but that will
require some re-work of the UPC runtime. For now, I'd like
to find a method that of generating code along the lines
of that shown above.
Thanks,
- Gary
Re: patch to fix PR55106
On 10/28/12 20:43:05, Vladimir Makarov wrote:
The following patch fixes PR55106. A value in GENERAL_REGS is
inherited into a move with destination pseudo of SSE_REGS. It
results into secondary move for which inheritance is tried again an
again. It means cycling LRA passes.
The patch was successfully bootstrapped on x86/x86-64.
This patch fails on IA64, due to unused variables on an #ifndef path.
This fix, or something like it is needed.
Index: gcc/lra-constraints.c
===
--- gcc/lra-constraints.c (revision 192988)
+++ gcc/lra-constraints.c (working copy)
@@ -3591,7 +3591,8 @@ skip_usage_debug_insns (rtx usage_insns)
USAGE_INSNS after inserting inherited pseudo of class INHER_CL
into the insn. */
static bool
-check_secondary_memory_needed_p (enum reg_class inher_cl, rtx usage_insns)
+check_secondary_memory_needed_p (enum reg_class inher_cl ATTRIBUTE_UNUSED,
+rtx usage_insns ATTRIBUTE_UNUSED)
{
#ifndef SECONDARY_MEMORY_NEEDED
return false;
Re: RFC: Merge the GUPC branch into the GCC 4.8 trunk (patch 01 of 16)
Joseph, In this rather long reply, I have attempted to collect all your recent feedback, and to provide a response where possible. JSM: On Mon, 15 Oct 2012, Gary Funck wrote: JSM: GF: Various UPC language related checks and operations JSM: GF: are called in the C front-end and middle-end. JSM: GF: To insure that these operations are defined, JSM: GF: when linked with the other language front-ends JSM: GF: and compilers, these functions are stub-ed, JSM: GF: in a fashion similar to Objective C: JSM: JSM: Is there a reason you chose this approach rather than the -fcilkplus JSM: approach of enabling an extension in the C front end given a command-line JSM: option? (If you don't want to support e.g. the ObjC / UPC combination, JSM: you can always give an error in such cases.) In general I think such JSM: conditionals are preferable to linking in stub variants of functions - and JSM: I'm sure people doing all-languages LTO bootstraps will appreciate not JSM: having to do link-time optimization of the language-independent parts of JSM: the compiler yet more times because of yet another binary like cc1, JSM: cc1plus, ... that links in much the same code. The functions you stub out JSM: would then all start with assertions that they are only ever called in UPC JSM: mode - or if they are meant to be called in C mode but do nothing in that JSM: case, with appropriate checks that return early for C (if needed). JSM: JSM: On Mon, 15 Oct 2012, Gary Funck wrote: JSM: GF: Back when we began to develop GUPC, it was recommended that we JSM: GF: introduce the UPC capability as a language dialect, similar to JSM: GF: Objective C. That is the approach that we have taken. JSM: JSM: Recommended where? I think that approach has been a bad idea for a long JSM: time and the approach of building into cc1, as taken by the cilkplus JSM: patches, is better (and that really most objc/ code should be like JSM: c-family/, built once and linked into both cc1 and cc1plus, though in its JSM: present state that's much harder to achieve). JSM: JSM: GF: I agree that there is no de facto reason that cc1upc is built JSM: GF: other than the fact we use a similar approach to Objective C. JSM: GF: However, I think that re-working this aspect of how GUPC is JSM: GF: implemented will require a fair amount of time/effort. If we JSM: JSM: I'd expect it to be a fairly straightforward rework (as would making ObjC JSM: a mode of cc1, if ObjC++ didn't exist). GUPC (then called GCC/UPC) dates back to the GCC 2.7 and GCC 2.95 days. The GCC 2.7 based implementation was a prototype, and the GCC 2.95 version was a first attempt to implement a UPC compiler that fits within the GCC build framework. At the time, we had discussions with Mark Mitchell, Mike Stump and perhaps others regarding the best method for introducing a UPC compiler into GCC. The consensus recommendation at the time was to implement GCC/UPC as a language dialect, similar to Objective-C. Thus, much of the initial work was patterned after ObjC; it used stubs and built a distinct front-end, so that is what we did. I will note that even back in those days that Mark indicated he didn't particularly like the language dialect approach, but it seemed the best way to go at the time. For Clang UPC, we have built the UPC capability into the Clang C/C++ compiler. This just turned out to be an easier way to go given Clang's build structure. My main issue with entertaining large re-structuring of GUPC at the moment is that I would like to see if we can introduce GUPC into GCC 4.8. As you point out, there are a lot of other things that we need to do to align the GUPC changes with the GCC trunk. Ideally, I'd like to see if we can phase those changes; dealing with the critical changes now prior to the merge and then implementing the rest of the changes over time. Is that feasible or likely? JSM: GF: Some UPC-specific configuration options are added to JSM: GF: the top-level configure.ac and gcc/configure.ac scripts. JSM: JSM: Any patch that includes new configure options should include the JSM: documentation for those options in install.texi. Also please include JSM: ChangeLog entries with each patch submission, and a more detailed JSM: description of the changes involved and the rationale for them and JSM: implementation choices made. OK, thanks. JSM: The changes to darwin.c, darwin.h, i386.c, rs6000.c should definitely be JSM: given their own rationale and called to the attention of relevant target JSM: maintainers, possibly through extracting them into separate patches in the JSM: series with meaningful subject lines mentioning the relevant targets, not JSM: mixed into what's ostensibly a build-system patch. OK. JSM: The configure options need justification for their existence and (given JSM: that they exist) for working using #if, given that (as I said before, in JSM: the above referenced 2010 message, in JSM: http://gcc.gnu.org/ml/gcc-patches/2011-07
Re: Propagate profile counts during switch expansion
On 10/08/12 17:46:03, Easwaran Raman wrote:
I have attached a revised patch. The updated ChangeLog is given below
and I have responded to your comments inline:
2012-10-08 Easwaran Raman era...@google.com
* optabs.c (emit_cmp_and_jump_insn_1): Add a new parameter to
specificy the probability of taking the jump.
Typo above: specificy
* except.c (sjlj_emit_function_enter): Pass probability to
emit_cmp_and_jump_insns.
On some targets (e. g., IA64), the following patch leads to an unused
variable warning-as-error:
Index: except.c
===
--- except.c (revision 191879)
+++ except.c (working copy)
@@ -1161,13 +1161,7 @@ sjlj_emit_function_enter (rtx dispatch_label)
emit_cmp_and_jump_insns (x, const0_rtx, NE, 0,
TYPE_MODE (integer_type_node), 0,
-dispatch_label);
- last = get_last_insn ();
- if (JUMP_P (last) any_condjump_p (last))
- {
- gcc_assert (!find_reg_note (last, REG_BR_PROB, 0));
- add_reg_note (last, REG_BR_PROB, GEN_INT (REG_BR_PROB_BASE / 100));
- }
+dispatch_label, REG_BR_PROB_BASE / 100);
#else
expand_builtin_setjmp_setup (plus_constant (Pmode, XEXP (fc, 0),
sjlj_fc_jbuf_ofs),
[...] gcc-trunk/src/gcc/except.c:1156:14: error: unused variable ‘last’
[-Werror=unused-variable]
rtx x, last;
^
cc1plus: all warnings being treated as errors
RFC: Merge the GUPC branch into the GCC 4.8 trunk (patch 0 of 16)
We have maintained the gupc (GNU Unified Parallel C) branch for a couple of years now, and would like to merge these changes into the GCC trunk. It is our goal to integrate the GUPC changes into the GCC 4.8 trunk, in order to provide a UPC (Unified Parallel C) capability in the subsequent GCC 4.8 release. The purpose of this note is to introduce the GUPC project, provide an overview of the UPC-related changes and to introduce the subsequent sets of patches which merge the GUPC branch into GCC 4.8. For reference, The GUPC project page is here: http://gcc.gnu.org/projects/gupc.html The current GUPC release is distributed here: http://gccupc.org Roughly a year ago, we described the front-end related changes at the time: http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00081.html We merge the GCC trunk into the gupc branch on approximately a weekly basis. The current GUPC branch is based upon a recent version of the GCC trunk (192449 dated 2012-10-15), and has been bootstrapped on x86_64/i686 Linux, PPC/POWER7/Linux and IA64/Altix Linux. In earlier versions, GUPC was successfully ported to SGI/MIPS (big endian) and SciCortex/MIPS (little endian). The UPC-related source code differences can be viewed here in various formats: http://gccupc.org/gupc-changes In the discussion below, the changes are excerpted in order to highlight important aspects of the UPC-related changes. The version used in this presentation is 190707. UPC's Shared Qualifier and Layout Qualifier --- The UPC language specification describes the language syntax and semantics: http://upc.gwu.edu/docs/upc_specs_1.2.pdf UPC introduces a new qualifier, shared that indicates that the qualified object is located in a global shared address space that is accessible by all UPC threads. Additional qualifiers (strict and relaxed) further specify the semantics of accesses to UPC shared objects. In UPC, a shared qualified array can further specify a layout qualifier that indicates how the shared data is blocked and distributed. There are two language pre-defined identifiers that indicate the number of threads that will be created when the program starts (THREADS) and the current (zero-based) thread number (MYTHREAD). Typically, a UPC thread is implemented as an operating system process. Access to UPC shared memory may be implemented locally via OS provided facilities (for example, mmap), or across nodes via a high speed network inter-connect (for example, Infiniband). GUPC provides a runtime (libgupc) that targets an SMP-based system and uses mmap() to implement global shared memory. Optionally, GUPC can use the more general and more capable Berkeley UPCR runtime: http://upc.lbl.gov/download/source.shtml#runtime The UPCR runtime supports a number of network topologies, and has been ported to most of the current High Performance Computing (HPC) systems. The following example illustrates the use of the UPC shared qualifier combined with a layout qualifier. #define BLKSIZE 5 #define N_PER_THREAD (4 * BLKSIZE) shared [BLKSIZE] double A[N_PER_THREAD*THREADS]; Above the [BLKSIZE] construct is the UPC layout factor; this specifies that the shared array, A, distributes its elements across each thread in blocks of 5 elements. If the program is run with two threads, then A is distributed as shown below: Thread 0Thread 1 - A[ 0.. 4] A[ 5.. 9] A[10..14] A[15..19] A[20..24] A[25..29] A[30..34] A[35..39] Above, the elements shown for thread 0 are defined as having affinity to thread 0. Similarly, those elements shown for thread 1 have affinity to thread 1. In UPC, a pointer to a shared object can be cast to a thread local pointer (a C pointer), when the designated shared object has affinity to the referencing thread. A UPC pointer-to-shared (PTS) is a pointer that references a UPC shared object. A UPC pointer-to-shared is a fat pointer with the following logical fields: (virt_addr, thread, offset) The virtual address (virt_addr) field is combined with the thread number (thread) and offset within the block (offset), to derive the location of the referenced object within the UPC shared address space. GUPC implements pointer-to-shared objects using either a packed representation or a struct representation. The user can select the pointer-to-shared representation with a configure parameter. The packed representation is the default. The packed pointer-to-shared representation limits the range of the various fields within the pointer-to-shared in order to gain efficiency. Packed pointer-to-shared values encode the three part shared address (described above) as a 64-bit value (on both 64-bit and 32-bit platforms). The struct representation provides a wider addressing range at the expense of requiring twice the number of bits (128) needed to encode the pointer-to-shared value. UPC-Related Front-End Changes
Re: RFC: Merge the GUPC branch into the GCC 4.8 trunk (patch 0 of 16)
On 10/15/12 17:51:14, Richard Guenther wrote: On Mon, Oct 15, 2012 at 5:47 PM, Gary Funck g...@intrepid.com wrote: [...] UPC-Related Front-End Changes - GCC's internal tree representation is extended to record the UPC shared, strict, relaxed qualifiers, and the layout qualifier. [...] What immediately comes to my mind is that apart from parsing the core machinery should be shareable with Cilk+, no? I haven't looked at Cilk in detail, but my understanding is that Cilk and UPC have different runtime models, and clearly different language syntax and semantics. Perhaps those knowledgeable in the Cilk implementation can comment further. - Gary
Re: RFC: Merge the GUPC branch into the GCC 4.8 trunk (patch 0 of 16)
On 10/15/12 17:06:28, Joseph S. Myers wrote: On Mon, 15 Oct 2012, Gary Funck wrote: Various UPC language related checks and operations are called in the C front-end and middle-end. To insure that these operations are defined, when linked with the other language front-ends and compilers, these functions are stub-ed, in a fashion similar to Objective C: Is there a reason you chose this approach rather than the -fcilkplus approach of enabling an extension in the C front end given a command-line option? (If you don't want to support e.g. the ObjC / UPC combination, you can always give an error in such cases.) Back when we began to develop GUPC, it was recommended that we introduce the UPC capability as a language dialect, similar to Objective C. That is the approach that we have taken. In general I think such conditionals are preferable to linking in stub variants of functions - and I'm sure people doing all-languages LTO bootstraps will appreciate not having to do link-time optimization of the language-independent parts of the compiler yet more times because of yet another binary like cc1, cc1plus, ... that links in much the same code. I agree that there is no de facto reason that cc1upc is built other than the fact we use a similar approach to Objective C. However, I think that re-working this aspect of how GUPC is implemented will require a fair amount of time/effort. If we can find a way to make that happen in the GCC 4.8 time frame, or if other GCC contributors are willing to help on this, then perhaps such a change is feasible. - Gary
RFC: Merge the GUPC branch into the GCC 4.8 trunk (patch 01 of 16)
)
$(LIBDEPS)
+cc1obj$(exeext): $(OBJC_OBJS) $(C_AND_OBJC_OBJS) \
+ c-family/stub-upc.o cc1obj-checksum.o \
+$(BACKEND) $(LIBDEPS)
+$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
- $(OBJC_OBJS) $(C_AND_OBJC_OBJS) cc1obj-checksum.o \
+ $(OBJC_OBJS) $(C_AND_OBJC_OBJS) \
+ c-family/stub-upc.o cc1obj-checksum.o \
$(BACKEND) $(LIBS) $(BACKENDLIBS)
# Objective C language specific files.
Index: gcc/upc/config-lang.in
===
--- gcc/upc/config-lang.in (.../trunk) (revision 0)
+++ gcc/upc/config-lang.in (.../branches/gupc) (revision 192459)
@@ -0,0 +1,48 @@
+# upc/config-lang.in: GNU UPC runtime library top-level configure fragment
+
+# Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008,
+# 2009, 2010, 2011
+# Free Software Foundation, Inc.
+# Contributed by Gary Funck g...@intrepid.com
+# and Nenad Vukicevic ne...@intrepid.com.
+# Based on original implementation
+# by Jesse M. Draper jdra...@super.org
+# and William W. Carlson w...@super.org.
+# Derived from objc/config-lang.in
+
+# This file is part of GCC.
+
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3. If not see
+# http://www.gnu.org/licenses/.
+
+# Configure looks for the existence of this file to auto-config each language.
+# We define several parameters used by configure:
+#
+# language - name of language as it would appear in $(LANGUAGES)
+# compilers- value to add to $(COMPILERS)
+# stagestuff - files to add to $(STAGESTUFF)
+
+language=upc
+
+build_by_default=no
+
+compilers=cc1upc\$(exeext)
+
+stagestuff=cc1upc\$(exeext)
+
+target_libs=target-libgupc
+
+gtfiles=\$(srcdir)/c/c-lang.h \$(srcdir)/c/c-tree.h
\$(srcdir)/c-family/c-common.h \$(srcdir)/c-family/c-pragma.h
\$(srcdir)/c-family/c-upc.h \$(srcdir)/upc/upc-act.h
\$(srcdir)/upc/upc-genericize.h \$(srcdir)/c/c-decl.c
\$(srcdir)/c-family/c-common.c \$(srcdir)/c-family/c-cppbuiltin.c
\$(srcdir)/c-family/c-pragma.c \$(srcdir)/c/c-objc-common.c
\$(srcdir)/c/c-parser.c \$(srcdir)/upc/upc-act.c
\$(srcdir)/upc/upc-genericize.c
+
+extra_parts=${extra_parts} ${upc_extra_parts}
Index: gcc/upc/Makefile.in
===
--- gcc/upc/Makefile.in (.../trunk) (revision 0)
+++ gcc/upc/Makefile.in (.../branches/gupc) (revision 192459)
@@ -0,0 +1,82 @@
+# Makefile.in: GNU UPC front-end Makefile
+
+#Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009,
+#2010, 2011
+#Free Software Foundation, Inc.
+#Contributed by Gary Funck g...@intrepid.com
+# and Nenad Vukicevic ne...@intrepid.com.
+#Based on original implementation
+# by Jesse M. Draper jdra...@super.org
+# and William W. Carlson w...@super.org.
+#Derived from objc/Makefile.in
+
+# This file is part of GCC.
+
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3. If not see
+# http://www.gnu.org/licenses/.
+
+# The Makefile built from this file lives in the upc language subdirectory.
+# Its purpose is to provide support for:
+#
+# 1. recursion where necessary, and only then (building .o's), and
+# 2. building and debugging cc1upcc from the language subdirectory.
+#
+# The parent Makefile handles all other chores, with help from the language
+# Makefile fragment.
+#
+# The targets for external use are `all' and `mostlyclean'.
+
+SHELL=/bin/sh
+
+OPTIMIZE= -O
+
+srcdir = .
+VPATH = $(srcdir)
+
+AR = ar
+AR_FLAGS = rc
+
+# Define this as to perform parallel make on a Sequent.
+# Note that this has some bugs, and it seems currently necessary
+# to compile all the gen* files first by hand to avoid erroneous results.
+P =
+
+# Definition of `all' is here so that new rules inserted by sed
+# do not specify the default target.
+all: all.indirect
+
+# sed inserts variable overrides after the following line
RFC: Merge the GUPC branch into the GCC 4.8 trunk (patch 02 of 16)
Attached, patch 02 of 16.
This patch set lists the small set of changes required
in the C++ and Objective C front-end to accommodate
changes needed for UPC.
gcc/c/c-decl.c is also included here, to illustrate
both the UPC front-end changes and to motivate the introduction of
c_build_qualified_type_1() which accepts an additional argument
which is the layout qualifier (blocking factor) that is unique to UPC.
- Gary
Other Languages (patch 02 of 16)
gcc/cp/lex.c
gcc/cp/tree.c
gcc/c/c-decl.c
gcc/c/c-objc-common.h
Index: gcc/cp/lex.c
===
--- gcc/cp/lex.c(.../trunk) (revision 192449)
+++ gcc/cp/lex.c(.../branches/gupc) (revision 192459)
@@ -183,6 +183,9 @@ init_reswords (void)
/* The Objective-C keywords are all context-dependent. */
mask |= D_OBJC;
+ if (!c_dialect_upc ())
+mask |= D_UPC;
+
ridpointers = ggc_alloc_cleared_vec_tree ((int) RID_MAX);
for (i = 0; i num_c_common_reswords; i++)
{
Index: gcc/cp/tree.c
===
--- gcc/cp/tree.c (.../trunk) (revision 192449)
+++ gcc/cp/tree.c (.../branches/gupc) (revision 192459)
@@ -900,7 +900,7 @@ move (tree expr)
the C version of this function does not properly maintain canonical
types (which are not used in C). */
tree
-c_build_qualified_type (tree type, int type_quals)
+c_build_qualified_type_1 (tree type, int type_quals, tree
ARG_UNUSED(layout_qualiefier))
{
return cp_build_qualified_type (type, type_quals);
}
@@ -1849,7 +1849,7 @@ build_exception_variant (tree type, tree
type_quals = TYPE_QUALS (type);
for (v = TYPE_MAIN_VARIANT (type); v; v = TYPE_NEXT_VARIANT (v))
-if (check_qualified_type (v, type, type_quals)
+if (check_qualified_type (v, type, type_quals, 0)
comp_except_specs (raises, TYPE_RAISES_EXCEPTIONS (v), ce_exact))
return v;
Index: gcc/c/c-decl.c
===
--- gcc/c/c-decl.c (.../trunk) (revision 192449)
+++ gcc/c/c-decl.c (.../branches/gupc) (revision 192459)
@@ -46,6 +46,7 @@ along with GCC; see the file COPYING3.
#include timevar.h
#include c-family/c-common.h
#include c-family/c-objc.h
+#include c-family/c-upc.h
#include c-family/c-pragma.h
#include c-lang.h
#include langhooks.h
@@ -570,6 +571,8 @@ c_build_pointer_type (tree to_type)
: TYPE_ADDR_SPACE (to_type);
enum machine_mode pointer_mode;
+ if (upc_shared_type_p (to_type))
+return build_pointer_type (to_type);
if (as != ADDR_SPACE_GENERIC || c_default_pointer_mode == VOIDmode)
pointer_mode = targetm.addr_space.pointer_mode (as);
else
@@ -2236,6 +2239,13 @@ merge_decls (tree newdecl, tree olddecl,
if (TREE_THIS_VOLATILE (newdecl))
TREE_THIS_VOLATILE (olddecl) = 1;
+ if (TREE_SHARED (newdecl))
+{
+ TREE_SHARED (olddecl) = 1;
+ if (TREE_CODE (newdecl) == VAR_DECL)
+ TREE_THIS_VOLATILE (newdecl) = 1;
+}
+
/* Merge deprecatedness. */
if (TREE_DEPRECATED (newdecl))
TREE_DEPRECATED (olddecl) = 1;
@@ -2872,6 +2882,8 @@ pushdecl_top_level (tree x)
static void
implicit_decl_warning (tree id, tree olddecl)
{
+ if (upc_diagnose_deprecated_stmt (input_location, id))
+return;
if (warn_implicit_function_declaration)
{
bool warned;
@@ -3011,6 +3023,8 @@ undeclared_variable (location_t loc, tre
}
else
{
+ if (upc_diagnose_deprecated_stmt (loc, id))
+return;
if (!objc_diagnose_private_ivar (id))
error_at (loc, %qE undeclared (first use in this function), id);
if (!already)
@@ -3830,6 +3844,9 @@ quals_from_declspecs (const struct c_dec
int quals = ((specs-const_p ? TYPE_QUAL_CONST : 0)
| (specs-volatile_p ? TYPE_QUAL_VOLATILE : 0)
| (specs-restrict_p ? TYPE_QUAL_RESTRICT : 0)
+ | (specs-shared_p ? TYPE_QUAL_SHARED : 0)
+ | (specs-strict_p ? TYPE_QUAL_STRICT : 0)
+ | (specs-relaxed_p ? TYPE_QUAL_RELAXED : 0)
| (ENCODE_QUAL_ADDR_SPACE (specs-address_space)));
gcc_assert (!specs-type
!specs-decl_attr
@@ -4359,7 +4376,23 @@ finish_decl (tree decl, location_t init_
constant_expression_warning (DECL_SIZE (decl));
else
{
- error (storage size of %q+D isn%'t constant, decl);
+ if (upc_shared_type_p (TREE_TYPE (decl)))
+ {
+ gcc_assert (!flag_upc_threads);
+ if (TYPE_HAS_THREADS_FACTOR (TREE_TYPE (decl)))
+ error (in the UPC dynamic translation environment,
THREADS may not appear in declarations
+ of shared arrays with indefinite block size;
+
Re: RFC: Merge the GUPC branch into the GCC 4.8 trunk (patch 01 of 16)
On 10/15/12 21:59:34, Joseph S. Myers wrote: On Mon, 15 Oct 2012, Gary Funck wrote: Some UPC-specific configuration options are added to the top-level configure.ac and gcc/configure.ac scripts. Any patch that includes new configure options should include the documentation for those options in install.texi. Also please include ChangeLog entries with each patch submission, and a more detailed description of the changes involved and the rationale for them and implementation choices made. Also please see the review comments I sent previously in http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02136.html (at least, this patch has a license notice in obsolete form, referring to GPLv2 and giving an FSF postal address instead of a URL). Joseph, Back in 2010, we posted an initial RFC: http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00628.html which received some review feedback. We attempted to incorporate the suggested changes and posted a follow up about a year later. It didn't take a year to make the changes; other development progressed and it just took us that long to get back to implementing the feedback. http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00081.html We tried to make the recommended changes, but it is possible that some were missed, or that there are other issues such as the ones that you point out that (still) need to be fixed. Regarding ChangeLog entries, I can add them to each change set, if that is needed. However, I was hoping to wait on that until the patches are generally approved, in principle. I will break out the ABI-related changes in darwin.c, darwin.h, i386.c, and rs6000.c for separate review along with an explanation. However, for this go around, I would like to patch all the current change sets, in case there is quick feedback that can be provided which will help us get things right more quickly. Regarding additional configure options, I will add justification per your recommendation. We did try to avoid #if's to the degree possible, and are open to suggestions on how to make further changes along those lines. I mentioned some of our remaining questions/issues here in our previous patch discussion. http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00138.html Per your recommendation, we will mention previous feedback and how we adjusted our patch, in future submittals. Regarding gcc/upc/Makefile.in, as you note it is likely un-used and un-needed and a left over that dates back to the time that we derived the initial gcc/upc directory structure from the gcc/objc structure at that time. We will remove it. The ACX_BUGURL is a left over from earlier GUPC packaging and is unique to the current GUPC branch. We will remove or adjust that change. My apologies for not catching those spurious changes. Regarding making adjustments that agree with current recommendations on the GCC patches list, we do try to make those changes as we merge in the trunk. However, we don't have the overview or experience in various areas that you and other GCC contributors have. We hope that those changes can be pointed out during the review process. Some other changes may be a matter of weighing development time versus priority. For example, I could see a situation where the current method of doing things in GUPC (with #if's) is accepted in this phase with a plan to upgrade that approach in future patch. This is similar in approach to the way that the GCC infrastructure has improved over time. Some of these choices will be more obvious based on review/discussion. Thanks, - Gary
RFC: Merge the GUPC branch into the GCC 4.8 trunk
We have maintained the gupc (GNU Unified Parallel C) branch for a couple of years now, and would like to merge these changes into the GCC trunk. The purpose of this note is to ask for suggestions on the best way to proceed through the GUPC review and merge process. For reference, The GUPC project page is here: http://gcc.gnu.org/projects/gupc.html The current GUPC release is distributed here: http://gccupc.org Roughly a year ago, we described the front-end related changes at the time: http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00081.html Status: We merge the trunk into the gupc branch on approximately a weekly basis. The current set of changes relative to the GCC trunk are shown here: http://gccupc.org/gupc-changes In order to make the changes easier to review, we are planning to present the changes in the following groups. - Configure and Make - Other Languages - C Pre-processor - Front-End/Parser - Options/Command Processing - Documentation - Maintenance and Support - Debugging Information (DWARF) - GCC, Trees, Declarations, Types, Statements - UPC Language Specific, Front-end, Middle-end - UPC language header files - UPC Runtime Library Configure/Make - UPC Runtime library - UPC Runtime Library: collectives - UPC Testsuite A detailed list of files in each category is attached. Does this sound like a workable plan? Are there any planned/ongoing current GCC trunk development activities that we should be aware of for planning and integration purposes? Thanks, - Gary Configure and Make -- configure.ac contrib/gcc_update gcc/c-family/stub-upc.c gcc/c/Make-lang.in gcc/config/darwin.c gcc/config/darwin.h gcc/config/i386/i386.c gcc/config.in gcc/config/rs6000/rs6000.c gcc/configure.ac gcc/cp/Make-lang.in gcc/fortran/Make-lang.in gcc/java/Make-lang.in gcc/lto/Make-lang.in gcc/Makefile.in gcc/objc/Make-lang.in gcc/upc/config-lang.in gcc/upc/Makefile.in gcc/upc/Make-lang.in Makefile.def Makefile.in Makefile.tpl Other Languages --- gcc/cp/lex.c gcc/cp/tree.c gcc/c/c-decl.c gcc/c/c-objc-common.h C Pre-processor --- gcc/c-family/c-cppbuiltin.c libcpp/include/cpplib.h libcpp/init.c Front-End/Parser gcc/c/c-parser.c gcc/c-family/c-lex.c gcc/c-family/c-pragma.c Options/Command Processing -- gcc/c-family/c.opt gcc/c-family/c-opts.c gcc/flags.h gcc/gcc.c gcc/upc/gupcspec.c gcc/upc/lang-specs.h Documentation - gcc/doc/tm.texi gcc/doc/tm.texi.in gcc/upc/gupc.texi Maintenance and Support --- gcc/c-family/c-pretty-print.c gcc/ChangeLog.upc gcc/DATESTAMP gcc/DEV-PHASE gcc/print-tree.c gcc/timevar.def gcc/tree-dump.c gcc/tree-pretty-print.c gcc/upc/ChangeLog libgupc/ChangeLog Debugging Information (DWARF) - gcc/dwarf2out.c GCC, Trees, Declarations, Types, Statements --- gcc/c/c-convert.c gcc/c/c-tree.h gcc/c/c-typeck.c gcc/c-family/c-common.c gcc/c-family/c-common.h gcc/convert.c gcc/defaults.h gcc/dojump.c gcc/explow.c gcc/fold-const.c gcc/function.c gcc/gimple.h gcc/gimplify.c gcc/stor-layout.c gcc/tree.c gcc/tree.h gcc/tree-sra.c gcc/tree-ssa.c gcc/varasm.c UPC Language Specific, Front-end, Middle-end gcc/langhooks-def.h gcc/c-family/c-upc.h gcc/langhooks.h gcc/upc/upc-act.c gcc/upc/upc-act.h gcc/upc/upc-gasp.c gcc/upc/upc-gasp.h gcc/upc/upc-genericize.c gcc/upc/upc-genericize.h gcc/upc/upc-lang.c gcc/upc/upc-pts.h gcc/upc/upc-pts-packed.c gcc/upc/upc-pts-struct.c gcc/upc/upc-rts-names.h gcc/upc/upc-tree.def gcc/upc/upc-tree.h UPC Runtime Library Configure/Make -- libgupc/acinclude.m4 libgupc/aclocal.m4 libgupc/config/darwin/upc-crt-config.h libgupc/config/default/upc-crt-config.h libgupc/config/default/upc-crtstuff.mak libgupc/config.h.in libgupc/configure libgupc/configure.ac libgupc/configure.tgt libgupc/gen-inline-libgupc.pl libgupc/gen-upc-ld-script.pl libgupc/libgupc.spec.in libgupc/libgupc.texi libgupc/Makefile.am libgupc/Makefile.in libgupc/smp/gcc-upc-lib.in libgupc/upc-crtbegin.spec.in libgupc/upc-crtend.spec.in libgupc/upc-crtstuff.c UPC language header files - libgupc/include/gasp.h libgupc/include/gasp_upc.h libgupc/include/gcc-upc.h libgupc/include/pupc.h libgupc/include/upc_collective.h libgupc/include/upc.h libgupc/include/upc_relaxed.h libgupc/include/upc_strict.h UPC Runtime library --- libgupc/smp/upc_access.c libgupc/smp/upc_accessg.c libgupc/smp/upc_access.h libgupc/smp/upc_addr.c libgupc/smp/upc_affinity.c libgupc/smp/upc_affinity.h libgupc/smp/upc_affinity_stub.c libgupc/smp/upc_allocg.upc libgupc/smp/upc_alloc.upc libgupc/smp/upc_backtrace.c libgupc/smp/upc_backtrace.h libgupc/smp/upc_backtrace_sup.c libgupc/smp/upc_barrier.upc libgupc/smp/upc_config.h libgupc/smp/upc_debug.h libgupc/smp/upc_defs.h libgupc/smp/upc_gasp.c libgupc/smp/upc_gum.c libgupc/smp/upc_libg.c
Re: [SH] PR 54089 - Add support for rotcr insn
On 08/20/12 01:02:39, Oleg Endo wrote:
Hello,
This adds support for SH's rotcr insn.
Tested on rev 190459 with
make -k check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
and no new failures.
OK?
Cheers,
Oleg
ChangeLog:
PR target/50489
Above: that should be: PR target/54089.
* config/sh/sh.md (rotcr, *rotcr, shar, shlr): New insns and
splits.
(ashrdi3_k, lshrdi3_k): Rewrite as insn_and_split.
* config/sh/sh.c (sh_lshrsi_clobbers_t_reg_p): New function.
* config/sh/sh-protos.h (sh_lshrsi_clobbers_t_reg_p): Declare
it.
testsuite/ChangeLog:
PR target/50489
Here also.
* gcc.target/sh/pr54089-1.c: New.
This is OK.
For a sec. I thought my long-standing bug report
got some attention. :)
- Gary
Re: CXX conversion: min g++ version pre-requisite?
I filed two bug reports: GCC install document does not list minimum required g++ version http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54324 GCC does not build with G++ version 3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54326 Re: the latter bug report (54326), it might be further divided into two bug reports: one documenting the failure to build with g++ 3.4.0 and the other having to do with the use of casts in genoutput.c. Let me know if you recommend that I separate the bug reports. - Gary
Re: CXX conversion: min g++ version pre-requisite?
On 08/18/12 09:51:43, Richard Guenther wrote: The code is clearly buggy and should use CONST_CAST - well, or now, finally, const_cast to cast const char * to char *. It is interesting that an old version of g++ caught this but a newer version didn't? - Gary
CXX conversion: min g++ version pre-requisite?
Paul Hargrove noted the following build failure on an older x86-32 Linux (Redhat 8.0) system. g++ -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/build -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../include -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libcpp/include -I/usr/local/pkg/gmp-4.2.4/include -I/usr/local/pkg/mpfr-2.4.2/include -I/usr/local/pkg/mpc-0.8/include -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libdecnumber -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libdecnumber/bid -I../libdecnumber\ -o build/genoutput.o /usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c /usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c: In function `void note_constraint(rtx_def*, int)': /usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c:1178: error: reinterpret_cast from type `const char (*)[1]' to type `char*' casts away constness make[2]: *** [build/genoutput.o] Error 1 make[2]: Leaving directory `/usr/local/pkg/upc/nightly/compiler/bld/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/usr/local/pkg/upc/nightly/compiler/bld' make: *** [all] Error 2 The g++ version is: g++ (GCC) 3.4.0 Currently, install.texi states: @heading Tools/packages necessary for building GCC @table @asis @item ISO C90 compiler Necessary to bootstrap GCC, although versions of GCC prior to 3.4 also allow bootstrapping with a traditional (KR) C compiler. To build all languages in a cross-compiler or other configuration where 3-stage bootstrap is not performed, you need to start with an existing GCC binary (version 2.95 or later) because source code for language frontends other than C might use GCC extensions. This appears to be out-of-date with respect to new C++ stage 1 build requirement. Please advise. Thanks, - Gary
Interaction between first stage build with g++ and $PATH
1. I have . on $PATH. 2. In one build of the latest GCC trunk, I specify CC=/usr/bin/gcc and CXX=/usr/bin/g++ and everything works. 3. In another build, I don't specify CC or CXX. Therefore they default to 'gcc' and 'g++'. This fails: g++: error trying to exec 'cc1plus': execvp: No such file or directory If I remove . from $PATH then the configuration in 3 will build. The problem is that there is a g++ executable under the built gcc directory, but cc1plus and other g++ component parts haven't been built yet. I can file a bug reported if necessary, but am wondering if it is a known requirement not to have . on $PATH or to explicitly set CC and CXX? thanks, - Gary
Re: PATCH [x86_64] PR20020 - 128 bit structs not targeted to TImode
On 08/14/12 08:30:59, Jakub Jelinek wrote:
On Mon, Aug 13, 2012 at 09:20:32PM -0700, Gary Funck wrote:
--- gcc/testsuite/gcc.dg/pr20020-1.c(revision 0)
+++ gcc/testsuite/gcc.dg/pr20020-1.c(revision 0)
@@ -0,0 +1,25 @@
+/* Target is restricted to x86_64 type architectures,
+ to check that 128-bit struct's are represented
+ as TImode values. */
+/* { dg-require-effective-target int128 } */
+/* { dg-do compile { target { x86_64-*-* } } } */
Given this all the testcases should go into gcc/testsuite/gcc.target/i386/
OK.
Note: It might be possible to leave only dg-require-effective-target int128
and use this as a regression test for other targets, such as
PPC64, S390, and IA64. However, I was uncertain if the RTL would
be similar enough, and know that in at least one case the
RTL scan would have to be adjusted. Also, I don't have access
to a S390. If there is interest in generalizing the test,
let me know. Otherwise, I'll move the tests to gcc.target/i386.
- Gary
Re: PATCH [x86_64] PR20020 - 128 bit structs not targeted to TImode
On 08/14/12 15:33:10, Joseph S. Myers wrote:
On Tue, 14 Aug 2012, Jakub Jelinek wrote:
On Mon, Aug 13, 2012 at 09:20:32PM -0700, Gary Funck wrote:
--- gcc/testsuite/gcc.dg/pr20020-1.c (revision 0)
+++ gcc/testsuite/gcc.dg/pr20020-1.c (revision 0)
@@ -0,0 +1,25 @@
+/* Target is restricted to x86_64 type architectures,
+ to check that 128-bit struct's are represented
+ as TImode values. */
+/* { dg-require-effective-target int128 } */
+/* { dg-do compile { target { x86_64-*-* } } } */
Given this all the testcases should go into gcc/testsuite/gcc.target/i386/
And restricting the target to x86_64-*-* is wrong anyway, since any such
test should also be run for i?86-*-* -m64. Use { target { ! { ia32 } } }
instead if you want to disable just -m32 testing, { target lp64 } if you
only want -m64 testing but not -m32 or -mx32.
How about:
1. Move the test to gcc/testsuite/gcc.target/i386/
2. The comment is amended to read:
/* Check that 128-bit struct's are represented as TImode values. */
3. This test is retained:
/* { dg-require-effective-target int128 } */
4. This target test is removed:
/* { dg-do compile } */
It is possible that dg-require-effective-target int128 is
too restrictive (in the sense that some x86 target might in
theory support TImode, but not __int128_t), but at least
some reasonable test coverage is guaranteed.
- Gary
Re: PATCH [x86_64] PR20020 - 128 bit structs not targeted to TImode
Attached, is an updated patch (with change logs).
The test cases are now in gcc.target/i386 and the
target selection is dg-require-effective-target int128 only.
Verified that the tests correctly detect the presence/lack
of TImode support.
- Gary
Index: gcc/config/i386/i386.h
===
--- gcc/config/i386/i386.h (revision 190398)
+++ gcc/config/i386/i386.h (working copy)
@@ -1816,6 +1816,10 @@ do {
\
#define BRANCH_COST(speed_p, predictable_p) \
(!(speed_p) ? 2 : (predictable_p) ? 0 : ix86_branch_cost)
+/* An integer expression for the size in bits of the largest integer machine
+ mode that should actually be used. We allow pairs of registers. */
+#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (TARGET_64BIT ? TImode : DImode)
+
/* Define this macro as a C expression which is nonzero if accessing
less than a word of memory (i.e. a `char' or a `short') is no
faster than accessing a word of memory, i.e., if such access
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 190398)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2012-08-14 Gary Funck g...@intrepid.com
+
+ PR target/20020
+ * config/i386/i386.h (MAX_FIXED_MODE_SIZE): Allow use of TImode
+ for use with appropriately sized structures and unions
+ on 64-bit (x86) targets.
+
2012-08-14 Uros Bizjak ubiz...@gmail.com
* config/i386/i386.md (enabled): Add comment with explanation
Index: gcc/testsuite/gcc.target/i386/pr20020-1.c
===
--- gcc/testsuite/gcc.target/i386/pr20020-1.c (revision 0)
+++ gcc/testsuite/gcc.target/i386/pr20020-1.c (revision 0)
@@ -0,0 +1,23 @@
+/* Check that 128-bit struct's are represented as TImode values. */
+/* { dg-require-effective-target int128 } */
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-rtl-expand } */
+
+struct shared_ptr_struct
+{
+ unsigned long long phase:48;
+ unsigned short thread:16;
+ void *addr;
+};
+typedef struct shared_ptr_struct sptr_t;
+
+sptr_t S;
+
+sptr_t
+sptr_result (void)
+{
+ return S;
+}
+/* { dg-final { scan-rtl-dump \\\(set \\\(reg:TI \[0-9\]* \\\[ retval
\\\]\\\) expand } } */
+/* { dg-final { scan-rtl-dump \\\(set \\\(reg/i:TI 0 ax\\\) expand } } */
+/* { dg-final { cleanup-rtl-dump expand } } */
Index: gcc/testsuite/gcc.target/i386/pr20020-2.c
===
--- gcc/testsuite/gcc.target/i386/pr20020-2.c (revision 0)
+++ gcc/testsuite/gcc.target/i386/pr20020-2.c (revision 0)
@@ -0,0 +1,21 @@
+/* Check that 128-bit struct's are represented as TImode values. */
+/* { dg-require-effective-target int128 } */
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-rtl-expand } */
+
+struct shared_ptr_struct
+{
+ unsigned long long phase:48;
+ unsigned short thread:16;
+ void *addr;
+};
+typedef struct shared_ptr_struct sptr_t;
+
+void
+copy_sptr (sptr_t *dest, sptr_t src)
+{
+ *dest = src;
+}
+
+/* { dg-final { scan-rtl-dump \\\(set \\\(reg:TI \[0-9\]* expand } } */
+/* { dg-final { cleanup-rtl-dump expand } } */
Index: gcc/testsuite/gcc.target/i386/pr20020-3.c
===
--- gcc/testsuite/gcc.target/i386/pr20020-3.c (revision 0)
+++ gcc/testsuite/gcc.target/i386/pr20020-3.c (revision 0)
@@ -0,0 +1,24 @@
+/* Check that 128-bit struct's are represented as TImode values. */
+/* { dg-require-effective-target int128 } */
+/* { dg-do compile } */
+/* { dg-options -O2 -fdump-rtl-expand } */
+
+struct shared_ptr_struct
+{
+ unsigned long long phase:48;
+ unsigned short thread:16;
+ void *addr;
+};
+typedef struct shared_ptr_struct sptr_t;
+
+sptr_t sptr_1, sptr_2;
+
+void
+copy_sptr (void)
+{
+ sptr_1 = sptr_2;
+}
+
+/* { dg-final { scan-rtl-dump \\\(set \\\(reg:TI \[0-9\]* expand } } */
+/* { dg-final { scan-rtl-dump \\\(set \\\(mem/c:TI expand } } */
+/* { dg-final { cleanup-rtl-dump expand } } */
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 190398)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2012-08-14 Gary Funck g...@intrepid.com
+
+ PR target/20020
+ * gcc.target/i386/pr20020-1.c: New.
+ * gcc.target/i386/pr20020-2.c: New.
+ * gcc.target/i386/pr20020-3.c: New.
+
2012-08-14 Oleg Endo olege...@gcc.gnu.org
PR target/52933
PATCH [x86_64] PR20020 - 128 bit structs not targeted to TImode
Attached, is a patch to fix PR20020, and three test cases.
This patch improves the code generated for structs that
can be represented in a TImode value on an x86_64 target.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
The test cases scan the generated RTL and verify
that TImode operations are present.
Note that this patch will uncover a new test
regression, described here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020#c9
Index: gcc/config/i386/i386.h
===
--- gcc/config/i386/i386.h (revision 190336)
+++ gcc/config/i386/i386.h (working copy)
@@ -1820,6 +1820,10 @@ do {
\
#define BRANCH_COST(speed_p, predictable_p) \
(!(speed_p) ? 2 : (predictable_p) ? 0 : ix86_branch_cost)
+/* An integer expression for the size in bits of the largest integer machine
+ mode that should actually be used. We allow pairs of registers. */
+#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (TARGET_64BIT ? TImode : DImode)
+
/* Define this macro as a C expression which is nonzero if accessing
less than a word of memory (i.e. a `char' or a `short') is no
faster than accessing a word of memory, i.e., if such access
Index: gcc/testsuite/gcc.dg/pr20020-1.c
===
--- gcc/testsuite/gcc.dg/pr20020-1.c(revision 0)
+++ gcc/testsuite/gcc.dg/pr20020-1.c(revision 0)
@@ -0,0 +1,25 @@
+/* Target is restricted to x86_64 type architectures,
+ to check that 128-bit struct's are represented
+ as TImode values. */
+/* { dg-require-effective-target int128 } */
+/* { dg-do compile { target { x86_64-*-* } } } */
+/* { dg-options -O2 -fdump-rtl-expand } */
+
+struct shared_ptr_struct
+{
+ unsigned long long phase:48;
+ unsigned short thread:16;
+ void *addr;
+};
+typedef struct shared_ptr_struct sptr_t;
+
+sptr_t S;
+
+sptr_t
+sptr_result (void)
+{
+ return S;
+}
+/* { dg-final { scan-rtl-dump \\\(set \\\(reg:TI \[0-9\]* \\\[ retval
\\\]\\\) expand } } */
+/* { dg-final { scan-rtl-dump \\\(set \\\(reg/i:TI 0 ax\\\) expand } } */
+/* { dg-final { cleanup-rtl-dump expand } } */
Index: gcc/testsuite/gcc.dg/pr20020-2.c
===
--- gcc/testsuite/gcc.dg/pr20020-2.c(revision 0)
+++ gcc/testsuite/gcc.dg/pr20020-2.c(revision 0)
@@ -0,0 +1,23 @@
+/* Target is restricted to x86_64 type architectures,
+ to check that 128-bit struct's are represented
+ as TImode values. */
+/* { dg-require-effective-target int128 } */
+/* { dg-do compile { target { x86_64-*-* } } } */
+/* { dg-options -O2 -fdump-rtl-expand } */
+
+struct shared_ptr_struct
+{
+ unsigned long long phase:48;
+ unsigned short thread:16;
+ void *addr;
+};
+typedef struct shared_ptr_struct sptr_t;
+
+void
+copy_sptr (sptr_t *dest, sptr_t src)
+{
+ *dest = src;
+}
+
+/* { dg-final { scan-rtl-dump \\\(set \\\(reg:TI \[0-9\]* expand } } */
+/* { dg-final { cleanup-rtl-dump expand } } */
Index: gcc/testsuite/gcc.dg/pr20020-3.c
===
--- gcc/testsuite/gcc.dg/pr20020-3.c(revision 0)
+++ gcc/testsuite/gcc.dg/pr20020-3.c(revision 0)
@@ -0,0 +1,26 @@
+/* Target is restricted to x86_64 type architectures,
+ to check that 128-bit struct's are represented
+ as TImode values. */
+/* { dg-require-effective-target int128 } */
+/* { dg-do compile { target { x86_64-*-* } } } */
+/* { dg-options -O2 -fdump-rtl-expand } */
+
+struct shared_ptr_struct
+{
+ unsigned long long phase:48;
+ unsigned short thread:16;
+ void *addr;
+};
+typedef struct shared_ptr_struct sptr_t;
+
+sptr_t sptr_1, sptr_2;
+
+void
+copy_sptr (void)
+{
+ sptr_1 = sptr_2;
+}
+
+/* { dg-final { scan-rtl-dump \\\(set \\\(reg:TI \[0-9\]* expand } } */
+/* { dg-final { scan-rtl-dump \\\(set \\\(mem/c:TI expand } } */
+/* { dg-final { cleanup-rtl-dump expand } } */
RFA: update comment in dwarf2.def re: UPC extensions
In the past, the UPC extensions to the DWARF2 debugging information format were described in a proposal. That proposal was subsequently accepted and documented in the DWARF4 specification. Index: include/dwarf2.def === --- include/dwarf2.def (revision 187674) +++ include/dwarf2.def (working copy) @@ -167,7 +167,7 @@ DW_TAG (DW_TAG_GNU_formal_parameter_pack are properly part of DWARF 5. */ DW_TAG (DW_TAG_GNU_call_site, 0x4109) DW_TAG (DW_TAG_GNU_call_site_parameter, 0x410a) -/* Extensions for UPC. See: http://upc.gwu.edu/~upc. */ +/* Extensions for UPC. See: http://dwarfstd.org/doc/DWARF4.pdf. */ DW_TAG (DW_TAG_upc_shared_type, 0x8765) DW_TAG (DW_TAG_upc_strict_type, 0x8766) DW_TAG (DW_TAG_upc_relaxed_type, 0x8767) The change above updates the URL. Alternatively, the URL can be dropped completely? thanks, - Gary
Re: RFA: update comment in dwarf2.def re: UPC extensions
On 05/19/12 20:37:19, Jason Merrill wrote: OK. Done. Thanks.
Re: [RFC]: Add support for pragma pointer_size
On 03/06/12 14:09:23, Tristan Gingold wrote:
The patch is simple: the C front-end will now calls
c_build_pointer_type (instead of build_pointer_type), which in
turn calls build_pointer_type_for_mode using the right mode.
[...]
Joining this discussion a bit late ... I have a few questions.
This change impacts the GUPC branch, mainly because UPC introduces
pointers that are generally larger than conventional C pointers,
and thus some changes were needed in the build pointer area,
and that logic needed to be adjusted to work with this patch.
Here is the new c_build_pointer_type. It a static function
constrained to be called from within the c-decl.c file wehre
it resides.
static tree
c_build_pointer_type (tree to_type)
{
addr_space_t as = to_type == error_mark_node? ADDR_SPACE_GENERIC
: TYPE_ADDR_SPACE (to_type);
enum machine_mode pointer_mode;
if (as != ADDR_SPACE_GENERIC || c_default_pointer_mode == VOIDmode)
pointer_mode = targetm.addr_space.pointer_mode (as);
else
pointer_mode = c_default_pointer_mode;
return build_pointer_type_for_mode (to_type, pointer_mode, false);
}
Here is the old build_pointer_type() in tree.c. It is external/public
and is called from various places.
tree
build_pointer_type (tree to_type)
{
addr_space_t as = to_type == error_mark_node? ADDR_SPACE_GENERIC
: TYPE_ADDR_SPACE (to_type);
enum machine_mode pointer_mode = targetm.addr_space.pointer_mode (as);
return build_pointer_type_for_mode (to_type, pointer_mode, false);
}
c_build_pointer_type () introduces c_default_pointer_mode
and uses it as long as:
as == ADDR_SPACE_GENERIC c_default_pointer_mode != VOIDmode
but build_pointer_type will not use c_default_pointer_mode.
My first question is: are there still contexts where build_pointer_type()
is called to compile C statements/expressions for cases not
covered by the calls within c-decl.c? I ask, because we tried
moving our checks for UPC pointer-to-shared types from
build_pointer_type() into only c_build_pointer_type() and
ran into calls to build_pointer_type() that still passed
in UPC pointer-to-shared typed objects. What this may
indicate is that there are situations where the new
c_default_pointer_mode may need to be applied when
build_pointer_type() is called. I don't recall off-hand
when these situations came up, but it might be easy enough
to put some assertions in build_pointer_type() and then
run the C test suite and see what turns up.
Thus, I wonder if it might not be best to generalize
build_pointer_type() instead of introducing c_build_pointer_type()
and dealing with any C specific checks (somehow) there?
Thanks,
- Gary
Re: [PING] PR33919/preprocessor fix __BASE_FILE__ when included from the command line
On 01/06/12 08:34:52, Tom Tromey wrote: The patch is ok with either that change or with those 2 lines removed. Applied as svn version 183003.
Re: [PING] PR33919/preprocessor fix __BASE_FILE__ when included from the command line
On 01/09/12 12:08:22, Tobias Burnus wrote: I get the build failure: libcpp/macro.c:220:26: error: variable 'map' set but not used [-Werror=unused-but-set-variable] Tobias, thanks. Will fix. - Gary
Re: [PING] PR33919/preprocessor fix __BASE_FILE__ when included from the command line
On 01/09/12 06:04:28, Gary Funck wrote: On 01/09/12 12:08:22, Tobias Burnus wrote: I get the build failure: libcpp/macro.c:220:26: error: variable 'map' set but not used [-Werror=unused-but-set-variable] Richard, thanks. 2012-01-09 Richard Guenther rguent...@suse.de libcpp/ * macro.c (_cpp_builtin_macro_text): Remove unused variable map.
Re: [PING] PR33919/preprocessor fix __BASE_FILE__ when included from the command line
On 01/06/12 08:34:52, Tom Tromey wrote:
Tom The patch is ok with either that change or with those 2 lines removed.
Tom, thanks for the review. Another question ...
The test case tries to sanity check the __FILE__ value
by comparing the 'basename' part.
#define BASE_NAME pr33919.c
int
main ()
{
size_t file_len = strlen (__FILE__);
size_t basename_len = strlen (BASE_NAME);
if (file_len basename_len)
abort ();
if (strcmp (__FILE__ + file_len - basename_len, BASE_NAME))
abort ();
[...]
which probably works fine on most systems, but perhaps
not so well if the OS upper cases all file names?
I can either remove the check, or change it so
that it just compares to make sure that __BASE_FILE__
isn't equal to command line, which is the
problem documented in the bug report.
- Gary
[PING] PR33919/preprocessor fix __BASE_FILE__ when included from the command line
Attached is a suggested fix for a long-standing C pre-processor bug.
Ref: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33919
Ref: http://gcc.gnu.org/ml/gcc/2004-10/msg00534.html
The patch implements the approach suggested by Harald van Dijk
in the cited bug report.
I am not familiar with the subtleties of the C pre-processor,
and do not know if there may be some surprises or special
cases not covered. The fix does appear to provide the
expected result as demonstrated by the included test case.
I have a specific question re: this new code.
+ name = _cpp_get_file_name (pfile-main_file);
+ if (!name)
+ name = unknown;
I wasn't sure whether 'name' can have a NULL value, and handled
that case as shown above. Would a gcc_assert() be more
appropriate, or is it safe to simply assume that the name
value is not NULL?
Please review.
Thanks,
- Gary
Index: gcc/testsuite/gcc.dg/pr33919-2.h
===
--- gcc/testsuite/gcc.dg/pr33919-2.h(revision 0)
+++ gcc/testsuite/gcc.dg/pr33919-2.h(revision 0)
@@ -0,0 +1 @@
+char *nested_inc_base_file = __BASE_FILE__;
Index: gcc/testsuite/gcc.dg/pr33919.c
===
--- gcc/testsuite/gcc.dg/pr33919.c (revision 0)
+++ gcc/testsuite/gcc.dg/pr33919.c (revision 0)
@@ -0,0 +1,35 @@
+/* PR preprocessor/pr33919 */
+/* { dg-do run } */
+/* { dg-options -I . -include ${srcdir}/gcc.dg/pr33919-0.h } */
+
+#include pr33919-1.h
+
+typedef __SIZE_TYPE__ size_t;
+
+const char *base_file = __BASE_FILE__;
+
+extern int strcmp (const char *, const char *);
+extern size_t strlen (const char *);
+extern void abort (void);
+
+#define BASE_NAME pr33919.c
+
+int
+main ()
+{
+ size_t file_len = strlen (__FILE__);
+ size_t basename_len = strlen (BASE_NAME);
+ if (file_len basename_len)
+abort ();
+ if (strcmp (__FILE__ + file_len - basename_len, BASE_NAME))
+abort ();
+ if (strcmp (pre_inc_base_file, __FILE__))
+abort ();
+ if (strcmp (base_file, __FILE__))
+abort ();
+ if (strcmp (inc_base_file, __FILE__))
+abort ();
+ if (strcmp (nested_inc_base_file, __FILE__))
+abort ();
+ return 0;
+}
Index: gcc/testsuite/gcc.dg/pr33919-0.h
===
--- gcc/testsuite/gcc.dg/pr33919-0.h(revision 0)
+++ gcc/testsuite/gcc.dg/pr33919-0.h(revision 0)
@@ -0,0 +1 @@
+char *pre_inc_base_file = __BASE_FILE__;
Index: gcc/testsuite/gcc.dg/pr33919-1.h
===
--- gcc/testsuite/gcc.dg/pr33919-1.h(revision 0)
+++ gcc/testsuite/gcc.dg/pr33919-1.h(revision 0)
@@ -0,0 +1,2 @@
+#include pr33919-2.h
+char *inc_base_file = __BASE_FILE__;
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 182805)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,11 @@
+2012-01-02 Gary Funck g...@intrepid.com
+
+ PR preprocessor/33919
+ * gcc.dg/pr33919.c: New test.
+ * gcc.dg/pr33919-0.h: New test header file.
+ * gcc.dg/pr33919-1.h: Ditto.
+ * gcc.dg/pr33919-2.h: Ditto.
+
2012-01-02 Paolo Carlini paolo.carl...@oracle.com
PR c++/20140
Index: libcpp/macro.c
===
--- libcpp/macro.c (revision 182805)
+++ libcpp/macro.c (working copy)
@@ -1,7 +1,7 @@
/* Part of CPP library. (Macro and #define handling.)
Copyright (C) 1986, 1987, 1989, 1992, 1993, 1994, 1995, 1996, 1998,
1999, 2000, 2001, 2002, 2003, 2004, 2005,
- 2006, 2007, 2008, 2009, 2010, 2011 Free Software Foundation, Inc.
+ 2006, 2007, 2008, 2009, 2010, 2011, 2012 Free Software Foundation, Inc.
Written by Per Bothner, 1994.
Based on CCCP program by Paul Rubin, June 1986
Adapted to ANSI C, Richard Stallman, Jan 1987
@@ -278,10 +278,9 @@ _cpp_builtin_macro_text (cpp_reader *pfi
pfile-line_table-highest_line);
else
{
- map = linemap_lookup (pfile-line_table,
pfile-line_table-highest_line);
- while (! MAIN_FILE_P (map))
- map = INCLUDED_FROM (pfile-line_table, map);
- name = ORDINARY_MAP_FILE_NAME (map);
+ name = _cpp_get_file_name (pfile-main_file);
+ if (!name)
+ name = unknown;
}
len = strlen (name);
buf = _cpp_unaligned_alloc (pfile, len * 2 + 3);
Index: libcpp/files.c
===
--- libcpp/files.c (revision 182805)
+++ libcpp/files.c (working copy)
@@ -1,7 +1,7 @@
/* Part of CPP library. File handling.
Copyright (C) 1986, 1987, 1989, 1992, 1993, 1994, 1995, 1998,
- 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011
- Free Software Foundation, Inc.
+ 1999, 2000
[PATCH] PR33919/preprocessor fix __BASE_FILE__ when included from the command line
Attached is a suggested fix for a long-standing C pre-processor bug.
Ref: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33919
Ref: http://gcc.gnu.org/ml/gcc/2004-10/msg00534.html
The patch implements the approach suggested by Harald van Dijk
in the cited bug report.
I am not familiar with the subtleties of the C pre-processor,
and do not know if there may be some surprises or special
cases not covered. The fix does appear to provide the
expected result as demonstrated by the included test case.
I have a specific question re: this new code.
+ name = _cpp_get_file_name (pfile-main_file);
+ if (!name)
+ name = unknown;
I wasn't sure whether 'name' can have a NULL value, and handled
that case as shown above. Would a gcc_assert() be more
appropriate, or is it safe to simply assume that the name
value is not NULL?
Please review.
Thanks,
- Gary
Index: gcc/testsuite/gcc.dg/pr33919-2.h
===
--- gcc/testsuite/gcc.dg/pr33919-2.h(revision 0)
+++ gcc/testsuite/gcc.dg/pr33919-2.h(revision 0)
@@ -0,0 +1 @@
+char *nested_inc_base_file = __BASE_FILE__;
Index: gcc/testsuite/gcc.dg/pr33919.c
===
--- gcc/testsuite/gcc.dg/pr33919.c (revision 0)
+++ gcc/testsuite/gcc.dg/pr33919.c (revision 0)
@@ -0,0 +1,20 @@
+/* PR preprocessor/pr33919 */
+/* { dg-do run } */
+/* { dg-options -I . -include ${srcdir}/gcc.dg/pr33919-0.h } */
+
+#include pr33919-1.h
+
+extern int strcmp (const char *, const char *);
+extern void abort(void);
+
+int
+main ()
+{
+ if (strcmp (base_file, __FILE__))
+abort ();
+ if (strcmp (inc_base_file, __FILE__))
+abort ();
+ if (strcmp (nested_inc_base_file, __FILE__))
+abort ();
+ return 0;
+}
Index: gcc/testsuite/gcc.dg/pr33919-0.h
===
--- gcc/testsuite/gcc.dg/pr33919-0.h(revision 0)
+++ gcc/testsuite/gcc.dg/pr33919-0.h(revision 0)
@@ -0,0 +1 @@
+char *base_file = __BASE_FILE__;
Index: gcc/testsuite/gcc.dg/pr33919-1.h
===
--- gcc/testsuite/gcc.dg/pr33919-1.h(revision 0)
+++ gcc/testsuite/gcc.dg/pr33919-1.h(revision 0)
@@ -0,0 +1,2 @@
+#include pr33919-2.h
+char *inc_base_file = __BASE_FILE__;
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 182601)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,11 @@
+2011-12-21 Gary Funck g...@intrepid.com
+
+ PR preprocessor/pr33919
+ * gcc.dg/pr33919.c: New test.
+ * gcc.dg/pr33919-0.h: New test header file.
+ * gcc.dg/pr33919-1.h: Ditto.
+ * gcc.dg/pr33919-2.h: Ditto.
+
2011-12-21 Paolo Carlini paolo.carl...@oracle.com
PR c++/51305
Index: libcpp/macro.c
===
--- libcpp/macro.c (revision 182601)
+++ libcpp/macro.c (working copy)
@@ -278,10 +278,9 @@ _cpp_builtin_macro_text (cpp_reader *pfi
pfile-line_table-highest_line);
else
{
- map = linemap_lookup (pfile-line_table,
pfile-line_table-highest_line);
- while (! MAIN_FILE_P (map))
- map = INCLUDED_FROM (pfile-line_table, map);
- name = ORDINARY_MAP_FILE_NAME (map);
+ name = _cpp_get_file_name (pfile-main_file);
+ if (!name)
+ name = unknown;
}
len = strlen (name);
buf = _cpp_unaligned_alloc (pfile, len * 2 + 3);
Index: libcpp/files.c
===
--- libcpp/files.c (revision 182601)
+++ libcpp/files.c (working copy)
@@ -1370,6 +1370,13 @@ _cpp_pop_file_buffer (cpp_reader *pfile,
}
}
+/* Return the file name associated with FILE. */
+const char *
+_cpp_get_file_name (_cpp_file *file)
+{
+ return file-name;
+}
+
/* Inteface to file statistics record in _cpp_file structure. */
struct stat *
_cpp_get_file_stat (_cpp_file *file)
Index: libcpp/ChangeLog
===
--- libcpp/ChangeLog(revision 182601)
+++ libcpp/ChangeLog(working copy)
@@ -1,3 +1,12 @@
+2011-12-21 Gary Funck g...@intrepid.com
+
+ PR preprocessor/pr33919
+ * files.c (_cpp_get_file_name): New. Implement file name
+ access function.
+ * internal.h (_cpp_get_file_name): New prototype.
+ * macro.c (_cpp_builtin_macro_text): Call _cpp_get_file_name()
+ in lieu of traversing INCLUDED_FROM chain.
+
2011-12-20 Joseph Myers jos...@codesourcery.com
* include/cpplib.h (CLK_GNUC1X): Change to CLK_GNUC11.
Index: libcpp/internal.h
===
--- libcpp/internal.h (revision 182601)
+++ libcpp/internal.h
Re: building trunk fails due to C++
On 11/09/11 14:22:22, Steve Kargl wrote: Besides bootstrapping, you could use --disable-libitm or it might also work to specify --disable-build-poststage1-with-cxx which also saves you from building the C++ compiler if you don't want it. Doing a full bootstrap adds 3+ hours on my laptop. Oh well, I guess this is the price of progress. It gots much worse, with --enable-checking=all in combination with --enable-build-poststage1-with-cxx (the default, if c++ is built, and --enable-bootstrap is asserted). In fact, a build started last night on fast server hardware has yet to finish. This particular compilation (insn-emit.c) has been running for 5.5 hours. Typically, a full bootstrap (with minimal checks) would finish in much less than 30 minutes on this server. Has anyone tried a full bootstrap with c,c++ and --enable-checking=all? Were you successful? How long did it take to complete? I haven't looked into this in detail, however, I wonder that if the C++ compiler is used for final build, whether the build/make will honor CFLAGS or CXXFLAGS? Presumably the latter (CXXFLAGS). This seems like a potentially surprising side effect, if true.
Re: PATCH RFA: Build stages 2 and 3 with C++
A comment on the documentation:
Index: gcc/doc/install.texi
===
--- gcc/doc/install.texi (revision 176348)
+++ gcc/doc/install.texi (working copy)
@@ -1286,6 +1286,13 @@ will try to guess whether the @code{.ini
Build GCC using a C++ compiler rather than a C compiler. This is an
experimental option which may become the default in a later release.
+@item --enable-build-poststage1-with-cxx
+When bootstrapping, build stages 2 and 3 of GCC using a C++ compiler
+rather than a C compiler. Stage 1 is still built with a C compiler.
+This is an experimental option which may become the default in a later
+release. This is enabled by default and may be disabled using
+@option{--disable-build-poststage1-with-cxx}.
+
The document says This is an experimental option which may become the
default in a later release and then says This is enabled by default.
The latter statement is true.
Re: building trunk fails due to C++
On 11/22/11 18:19:55, Michael Matz wrote: This particular compilation (insn-emit.c) has been running for 5.5 hours. Typically, a full bootstrap (with minimal checks) would finish in much less than 30 minutes on this server. Yes, don't use --enable-checking=all for bootstraps. =all enables some _extremely_ slow checking, you should usually just use =yes (which is the default for non-release branches). This doesn't have to do with C vs C++ as bootstrap compiler, though. Michael, Thanks for the tip. Typically, we don't build with --enable-checking=all, however ... We build with --enable-checking=all when we're testing major changes, moving GUPC to a new target architecture, etc. In the past, it may have been slower, and certainly the final compiler is slower (probably 3x-5x on average), but the extra checking did help catch some bugs. If --enable-checking=all is deemed currently unusable, perhaps it can be re-designed so that the useful and not impractically expensive checks are enabled but some other switch values are defined to perform checks that are needed only in very specific circumstances. This almost infinite compilation time seems like a new behavior to me, and is potentially a side-effect of building with the g++ in the final stage. FYI, on the *very* long running compilations that I checked, the cc1plus compiler appeared to be stuck in the garbage collector. #1 0x009e838e in gt_ggc_mx_lang_tree_node (x_p=0x7fff268282d0) at ./gt-cp-tree.h:154 #2 0x009e98fc in gt_ggc_mx_lang_tree_node (x_p=0x7ffef042ad00) at ./gt-cp-tree.h:381 #3 0x00acf2be in gt_ggc_mx_cp_binding_level (x_p=0x717878c0) at ./gt-cp-name-lookup.h:80 #4 0x00acf4c8 in gt_ggc_mx_cxx_binding (x_p=0x7fffec638f78) at ./gt-cp-name-lookup.h:105 [...] #10 0x009e984e in gt_ggc_mx_lang_tree_node (x_p=0x7ffee794f100) at ./gt-cp-tree.h:375 #11 0x0177eeac in gt_ggc_mx_cgraph_node (x_p=0x7ffef402ca20) at gtype-desc.c:693 #12 0x01785fc9 in gt_ggc_m_P11cgraph_node4htab (x_p=0x7fffefbec3f0) at gtype-desc.c:2774 #13 0x015c48cb in ggc_mark_root_tab (rt=0x4dbce40) at src/gupc/gcc/ggc-common.c:142 #14 0x015c4967 in ggc_mark_roots () at src/gupc/gcc/ggc-common.c:161 [this was compiling insn_emit.c. It racked up 5 hours of cpu time before I canceled the job.] This sort of thing would appear to be unrelated to --enable-checking=all, or at least it is surprising to me that --enable-checking=all would end up causing the compiler to spend a lot of time in the garbage collector. I only checked two/three long-running compilations, but each of them demonstrated a similar backtrace to that shown above. I will try rebuilding with --disable-build-poststage1-with-cxx and --enable-checking=all to try to determine if this is g++ specific behavior. - Gary
Re: PATCH RFA: Build stages 2 and 3 with C++
On 07/15/11 23:52:46, Ian Lance Taylor wrote: [...] @@ -444,6 +448,9 @@ STAGE1_LANGUAGES = @stage1_languages@ # the last argument when conflicting --enable arguments are passed. # * Likewise, we force-disable coverage flags, since the installed # compiler probably has never heard of them. +# * Don't remove this, because above we added +# POSTSTAGE1_CONFIGURE_FLAGS to STAGE[+id+]_CONFIGURE_FLAGS, which +# we don't want for STAGE1_CONFIGURE_FLAGS. STAGE1_CONFIGURE_FLAGS = --disable-intermodule $(STAGE1_CHECKING) \ --disable-coverage --enable-languages=$(STAGE1_LANGUAGES) When g++ is used to compile gcc in stages 2 and 3, which compilation flags (CFLAGS or CXXFLAGS) are in force? If CXXFLAGS, is this a potentially surprising departure from previous configure behavior? thanks, - Gary
Re: PATCH RFA: Build stages 2 and 3 with C++
On 11/22/11 11:32:03, Ian Lance Taylor wrote: If CXXFLAGS, is this a potentially surprising departure from previous configure behavior? Perhaps. I don't see how we could reasonably make any other choice,though. Agreed. Just wondering if there might be potential documentation impact, re: configure/build.
--enable-checking=all results in long running compiles, where the compiler spends long periods of time in the garbage collector (GC)
On 11/22/11 12:57:38, Diego Novillo wrote: --enable-checking=all enables GC checking, so I am not really surprised at the behaviour you observe. Good to know. Thanks. I will try rebuilding with --disable-build-poststage1-with-cxx and --enable-checking=all to try to determine if this is g++ specific behavior. Yes, that will be an interesting piece of data to gather. Thanks. Early indications are that this is _not_ strictly a g++ related issue. Some compiles with cc1 have been running 90 mins. so far, and inspection via gdb indicates they're spending a lot of time in the garbage collector. At this point, I'm going to stop the test build, and rebuild with --enable-checking only. - Gary
Re: int_cst_hash_table mapping persistence and the garbage collector
On 10/13/11 06:15:31, Laurynas Biveinis wrote: [...] In your case (correct me if I misunderstood something) you have one hash table, marking of which will mark more objects which are required for the correct marking of the second hash table. GC might be simply walking the second one first. Yes, I think that this accurately summarizes the situation, and the result. Any suggestions on how to fix this? It seems that one fix might be to use a non garbage-collected hash table for the hash map. - Gary
Re: int_cst_hash_table mapping persistence and the garbage collector
On 10/11/11 11:05:18, Eric Botcazou wrote:
One easy way to address the current issue is to call
tree_int_cst_equal() if the integer constant tree pointers
do not match:
if ((c1 != c2) !tree_int_cst_equal (c1, c2))
/* integer constants aren't equal. */
You have two objects C1 and C2 for the same constant and you're comparing
them. One was created first, say C1. If C1 was still live when C2 was
created, why was C2 created in the first class? If C1 wasn't live
anymore when C2 was created, why are you still using C1 here?
Eric, this note provides some more detail in addition to my
earlier reply to Richard.
The problem is that the references to object C1 and C2 live in
a hash table, and that although the referenced nodes will be retained
by the garbage collector, their mapping in int_cst_hash_table is
deleted by the GC.
Thus, if we follow the diagram:
tree (type) - [ upc_block_factor_for_type ]
- tree (integer constant)
tree (integer constant) - [ int_cst_hash_table ] {unique map}
- tree (integer constant)
Given two tree nodes, P (prototype) and F (function) they declare
a parameter that is pointer to a UPC shared object and this pointer
is declared with a UPC blocking factor of 1000. Without garbage
collection, the mappings look like this:
P.param - C1, F.param - C1 where C1 is an integer constant of
the form (sizetype, 1000).
but when GC kicks in, it decides that the hash table entry
in int_cst_hash_table can be deleted because it doesn't think
that C1 is live. Therefore the next attempt to map (sizetype, 1000)
will yield a new integral constant tree node, C2. Then the mapping
changes to: P.param - C1, F.param - C2, and we can no longer use
TYPE_UPC_BLOCKING_FACTOR (P.param) == TYPE_UPC_BLOCKING_FACTOR (F.param)
to check that the blocking factors of P.param and F.param are equal.
For the GC to know that int_cst_hash_table
entry is needed, perhaps the upc_block_factor_for_type needs
to be traversed, and then each integer constant needs to be
marked, or the constant has to be hashed into int_cst_hash_table
and the actual hash table entry has to be marked.
I am not familiar with the details of garbage collection and
pretty much just try use existing code as a model. Apparently,
this sequence of statements is insufficient to tell the GC that it should
mark the integer constants referenced in this hash table as in use.
static GTY ((if_marked (tree_map_marked_p),
param_is (struct tree_map)))
htab_t upc_block_factor_for_type;
[...]
upc_block_factor_for_type = htab_create_ggc (512, tree_map_hash
tree_map_eq, 0);
Reading the GC code:
static int
ggc_htab_delete (void **slot, void *info)
{
const struct ggc_cache_tab *r = (const struct ggc_cache_tab *) info;
if (! (*r-marked_p) (*slot))
htab_clear_slot (*r-base, slot);
else
(*r-cb) (*slot);
return 1;
}
It appears that the int_cst_hash_table entry for C1 needs to be
marked or it will be cleared. I don't know how to set things
up so that so that the garbage collecting mechanisms are in
place to do that, and was hoping that tree_map_hash table
would provide the required mechanisms. Apparently, this is
not the case.
I had hoped that this declaration would be sufficient to convince
the GC to consider all mapped integer constant nodes to be live.
If not, then perhaps I need a GC hook associated with
upc_block_factor_for_type that does something like the following:
for t (each used upc_block_factor_for_type entry):
c = t.to # the mapped integer constant
if is_integer_constant (c):
h = int_cst_hash_table.hash(c)
gc_mark_htab (int_cst_hash_table, h)
or perhaps this is sufficient?
for t (each used upc_block_factor_for_type entry):
c = t.to
gc_mark_tree_node (c)
However, I thought that this would already have been done
automatically by the GC hash tree implementation.
If either of those methods are required, I would appreciate
suggestions/pointers/code that would help me make sure that
this approach is implemented correctly.
thanks,
- Gary
Re: int_cst_hash_table mapping persistence and the garbage collector
On 10/12/11 14:00:54, Richard Guenther wrote: I think there is an issue when two cache htabs refer to each other with respect to GC, you might search the list to find out more. Richard, thanks. I thought that might be the case, but I don't understand the GC well enough to make this determination. - Gary
Re: int_cst_hash_table mapping persistence and the garbage collector
On 10/11/11 10:24:52, Richard Guenther wrote:
GF: 1. Is it valid to assume that pointer equality is sufficient
GF: to compare two integer constants for equality as long as they
GF: have identical type and value?
Yes, if both constants are live
The upc blocking factor hash table is declared as follows:
static GTY ((if_marked (tree_map_marked_p),
param_is (struct tree_map)))
htab_t upc_block_factor_for_type;
[...]
upc_block_factor_for_type = htab_create_ggc (512, tree_map_hash,
tree_map_eq, 0);
I had hoped that this would be sufficient to ensure that all
integer constant references recorded in this hash table would
be considered live by the GC. Reading the code in tree_map_marked_p(),
however, I see the following:
#define tree_map_marked_p tree_map_base_marked_p
[...]
/* Return true if this tree map structure is marked for garbage collection
purposes. We simply return true if the from tree is marked, so that this
structure goes away when the from tree goes away. */
int
tree_map_base_marked_p (const void *p)
{
return ggc_marked_p (((const struct tree_map_base *) p)-from);
}
This takes care of recycling an entry when the '-from' reference
goes away, but it doesn't make sure that the '-to' reference is
considered live. I don't understand the GC well enough to
know when/where the '-to' entry should be marked as live.
(note: in the cited test case, the -from pointers in question
are known to be live and did survive garbage collection.)
Given that the declaration above tells the GC that the nodes
in the blocking factor hash table are of type 'struct tree_map',
struct GTY(()) tree_map_base {
tree from;
};
/* Map from a tree to another tree. */
struct GTY(()) tree_map {
struct tree_map_base base;
unsigned int hash;
tree to;
};
I thought that the GC would mark the -to nodes as
live automatically? (note: probably the only direct
reference to the integer constant that is the focus of
this discussion is in the upc_block_factor_for_type hash table.
Therefore, if it isn't seen as live there, it won't be seen
as live anywhere else.)
I suppose that I could declare a linear tree list of mapped integer
constants and let the GC walk that, but that is more of a hack than a solution.
- Gary
int_cst_hash_table mapping persistence and the garbage collector
Recently, a few UPC test programs failed to compile
due to mis-matches of parameters in a prototype and its
corresponding function definition. The mis-match was
based upon the apparent inequality of UPC layout qualifiers
(blocking factors).
UPC blocking factors are integer constants. They are
recorded in a hash table indexed by the type tree node
that they correspond to.
Currently, the test for equality of blocking factors
tests only the pointer to the tree node defining the constant.
All blocking factors are recorded as sizetype type'd nodes.
Given that integer constants are hashed by type/value, it seemed
safe to assume that a given blocking factor would map to
a single tree node due to the underlying hash method that is used
when integral constants are created.
Is it valid to assume that pointer equality is sufficient
to ensure that two integer constants are equal as long
as their type and values are equal?
The bug that we ran into occurred because a garbage collection
pass was run between the point that the function prototype
tree node was created and the point at which the function declaration
was processed. The garbage collector decided that the integer
constant representing the blocking factor was no longer in use,
because it had not been marked.
In fact, the integer constant was needed because it appeared
in the blocking factor hash table, but not via a direct pointer.
Rather it was referenced by nature of the fact that
the blocking factor hash table referenced the integer constant
that is mapped in the integer constant hash table.
Here's a rough diagram:
tree (type) - [ blocking factor hash ] - tree (integer constant)
tree (integer constant) - [ integer constant hash ] {unique map}
- tree (integer constant)
When the garbage collector deleted the entry from the
integer constant hash, it forced a new integer constant tree
node to be created for the same (type, value) integral constant
blocking factor.
One easy way to address the current issue is to call
tree_int_cst_equal() if the integer constant tree pointers
do not match:
if ((c1 != c2) !tree_int_cst_equal (c1, c2))
/* integer constants aren't equal. */
This may be necessary if 'int_cst_hash_table' is viewed as
a cache rather than a persistent, unique mapping.
Another approach, would be to somehow mark the node
in int_cst_hash_table as in use when the blocking factor
hash table is traversed by the garbage collector, or
to add logic the hash table delete function associated
with int_cst_hash_table; to dis-allow the delete if the
integer constant is present in the UPC blocking factor
hash table.
To effect this change in a modular way probably the hash table
delete function associated with 'int_cst_hash_table' would have
to be daisy-chained, where the UPC blocking factor check is made
first. The difficulty with implementing the daisy chaining is that
int_cst_hash_table needs to exist before the UPC-related initialization
code is run. One way to handle this might be yet another language
hook, called from the code that creates 'int_cst_hash_table'.
That seems overly complex.
For reference, the current blocking factor mapping table
is created as follows:
upc_block_factor_for_type = htab_create_ggc (512, tree_map_hash,
tree_map_eq, 0);
Summary:
1. Is it valid to assume that pointer equality is sufficient
to compare two integer constants for equality as long as they
have identical type and value?
2. Should 'int_cst_hash_table' be viewed as a cache, where
the mapping of a given (type, value) integer constant may
vary over time?
3. If the answer to 1. is yes and the answer to 2. is no
then what is the recommended way to ensure that nodes in
'int_cst_hash_table' are not removed if the integer constant
is being referenced via the 'upc_block_factor_for_type'
hash table?
thanks,
- Gary
Re: [Patch, C] options generation and language count
On 09/02/11 13:42:32, Joseph S. Myers wrote:
[..] you should just generate #if/#error in the output [...]
OK, take two, attached. (Confirmed that the #if works for
the (, ==, ) relationships between n_langs and the max.
number of languages supported.)
- Gary
2011-09-02 Gary Funck g...@intrepid.com
* opts.c (print_specific_help): Fix off-by-one compare in
assertion check.
* opts.h (CL_PARAMS, CL_WARNING, CL_OPTIMIZATION, CL_DRIVER,
CL_TARGET, CL_COMMON, CL_JOINED, CL_SEPARATE, CL_UNDOCUMENTED):
Increase by +5 to allow for more languages.
* optc-gen.awk: Generate #if that ensures that the number of
languages is within the implementation-defined limit.
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 178389)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,13 @@
+2011-09-02 Gary Funck g...@intrepid.com
+
+ * opts.c (print_specific_help): Fix off-by-one compare in
+ assertion check.
+ * opts.h (CL_PARAMS, CL_WARNING, CL_OPTIMIZATION, CL_DRIVER,
+ CL_TARGET, CL_COMMON, CL_JOINED, CL_SEPARATE, CL_UNDOCUMENTED):
+ Increase by +5 to allow for more languages.
+ * optc-gen.awk: Generate #if that ensures that the number of
+ languages is within the implementation-defined limit.
+
2011-08-31 Richard Sandiford rdsandif...@googlemail.com
* config/i386/i386.md: Use (match_test ...) for attribute tests.
Index: gcc/opts.c
===
--- gcc/opts.c (revision 178389)
+++ gcc/opts.c (working copy)
@@ -1125,7 +1125,7 @@ print_specific_help (unsigned int includ
/* Sanity check: Make sure that we do not have more
languages than we have bits available to enumerate them. */
- gcc_assert ((1U cl_lang_count) CL_MIN_OPTION_CLASS);
+ gcc_assert ((1U cl_lang_count) = CL_MIN_OPTION_CLASS);
/* If we have not done so already, obtain
the desired maximum width of the output. */
Index: gcc/opts.h
===
--- gcc/opts.h (revision 178389)
+++ gcc/opts.h (working copy)
@@ -127,12 +127,12 @@ extern const unsigned int cl_options_cou
extern const char *const lang_names[];
extern const unsigned int cl_lang_count;
-#define CL_PARAMS (1U 11) /* Fake entry. Used to display
--param info with --help. */
-#define CL_WARNING (1U 12) /* Enables an (optional) warning
message. */
-#define CL_OPTIMIZATION(1U 13) /* Enables an (optional)
optimization. */
-#define CL_DRIVER (1U 14) /* Driver option. */
-#define CL_TARGET (1U 15) /* Target-specific option. */
-#define CL_COMMON (1U 16) /* Language-independent. */
+#define CL_PARAMS (1U 16) /* Fake entry. Used to display
--param info with --help. */
+#define CL_WARNING (1U 17) /* Enables an (optional) warning
message. */
+#define CL_OPTIMIZATION(1U 18) /* Enables an (optional)
optimization. */
+#define CL_DRIVER (1U 19) /* Driver option. */
+#define CL_TARGET (1U 20) /* Target-specific option. */
+#define CL_COMMON (1U 21) /* Language-independent. */
#define CL_MIN_OPTION_CLASSCL_PARAMS
#define CL_MAX_OPTION_CLASSCL_COMMON
@@ -142,9 +142,9 @@ extern const unsigned int cl_lang_count;
This distinction is important because --help will not list options
which only have these higher bits set. */
-#define CL_JOINED (1U 17) /* If takes joined argument. */
-#define CL_SEPARATE(1U 18) /* If takes a separate argument. */
-#define CL_UNDOCUMENTED(1U 19) /* Do not output with
--help. */
+#define CL_JOINED (1U 22) /* If takes joined argument. */
+#define CL_SEPARATE(1U 23) /* If takes a separate argument. */
+#define CL_UNDOCUMENTED(1U 24) /* Do not output with
--help. */
/* Flags for an enumerated option argument. */
#define CL_ENUM_CANONICAL (1 0) /* Canonical for this value. */
Index: gcc/optc-gen.awk
===
--- gcc/optc-gen.awk(revision 178389)
+++ gcc/optc-gen.awk(working copy)
@@ -169,6 +169,9 @@ for (i = 0; i n_langs; i++) {
print 0\n};\n
print const unsigned int cl_options_count = N_OPTS;\n
+print #if (1U n_langs ) CL_MIN_OPTION_CLASS
+print #error the number of languages exceeds the implementation limit
+print #endif
print const unsigned int cl_lang_count = n_langs ;\n
print const struct cl_option cl_options[] =\n{
[Patch, C] options generation and language count
2011-09-01 Gary Funck g...@intrepid.com
* opts.c (print_specific_help): Fix off-by-one compare in
assertion check.
* opts.h (CL_PARAMS, CL_WARNING, CL_OPTIMIZATION, CL_DRIVER,
CL_TARGET, CL_COMMON, CL_JOINED, CL_SEPARATE, CL_UNDOCUMENTED):
Increase by +5 to allow for more languages.
* Makefile.in (options.c): Extract max. number of languages value
from opts.h, and pass to optc-gen.awk script.
* optc-gen.awk: Use max_lang value and issue error if number of
languages exceeds implementation-defined limit.
This patch extracts the shift count used in the definition of
CL_PARAMS to determine the maximum number of language supported
by the implementation. optc-gen.awk implements the check and
will exit with an error if the number of languages exceeds the limit.
Patch, attached. Please review.
Thanks,
- Gary
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 178389)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,15 @@
+2011-09-01 Gary Funck g...@intrepid.com
+
+ * opts.c (print_specific_help): Fix off-by-one compare in
+ assertion check.
+ * opts.h (CL_PARAMS, CL_WARNING, CL_OPTIMIZATION, CL_DRIVER,
+ CL_TARGET, CL_COMMON, CL_JOINED, CL_SEPARATE, CL_UNDOCUMENTED):
+ Increase by +5 to allow for more languages.
+ * Makefile.in (options.c): Extract max. number of languages value
+ from opts.h, and pass to optc-gen.awk script.
+ * optc-gen.awk: Use max_lang value and issue error if number of
+ languages exceeds implementation-defined limit.
+
2011-08-31 Richard Sandiford rdsandif...@googlemail.com
* config/i386/i386.md: Use (match_test ...) for attribute tests.
Index: gcc/opts.c
===
--- gcc/opts.c (revision 178389)
+++ gcc/opts.c (working copy)
@@ -1125,7 +1125,7 @@ print_specific_help (unsigned int includ
/* Sanity check: Make sure that we do not have more
languages than we have bits available to enumerate them. */
- gcc_assert ((1U cl_lang_count) CL_MIN_OPTION_CLASS);
+ gcc_assert ((1U cl_lang_count) = CL_MIN_OPTION_CLASS);
/* If we have not done so already, obtain
the desired maximum width of the output. */
Index: gcc/opts.h
===
--- gcc/opts.h (revision 178389)
+++ gcc/opts.h (working copy)
@@ -127,12 +127,12 @@ extern const unsigned int cl_options_cou
extern const char *const lang_names[];
extern const unsigned int cl_lang_count;
-#define CL_PARAMS (1U 11) /* Fake entry. Used to display
--param info with --help. */
-#define CL_WARNING (1U 12) /* Enables an (optional) warning
message. */
-#define CL_OPTIMIZATION(1U 13) /* Enables an (optional)
optimization. */
-#define CL_DRIVER (1U 14) /* Driver option. */
-#define CL_TARGET (1U 15) /* Target-specific option. */
-#define CL_COMMON (1U 16) /* Language-independent. */
+#define CL_PARAMS (1U 16) /* Fake entry. Used to display
--param info with --help. */
+#define CL_WARNING (1U 17) /* Enables an (optional) warning
message. */
+#define CL_OPTIMIZATION(1U 18) /* Enables an (optional)
optimization. */
+#define CL_DRIVER (1U 19) /* Driver option. */
+#define CL_TARGET (1U 20) /* Target-specific option. */
+#define CL_COMMON (1U 21) /* Language-independent. */
#define CL_MIN_OPTION_CLASSCL_PARAMS
#define CL_MAX_OPTION_CLASSCL_COMMON
@@ -142,9 +142,9 @@ extern const unsigned int cl_lang_count;
This distinction is important because --help will not list options
which only have these higher bits set. */
-#define CL_JOINED (1U 17) /* If takes joined argument. */
-#define CL_SEPARATE(1U 18) /* If takes a separate argument. */
-#define CL_UNDOCUMENTED(1U 19) /* Do not output with
--help. */
+#define CL_JOINED (1U 22) /* If takes joined argument. */
+#define CL_SEPARATE(1U 23) /* If takes a separate argument. */
+#define CL_UNDOCUMENTED(1U 24) /* Do not output with
--help. */
/* Flags for an enumerated option argument. */
#define CL_ENUM_CANONICAL (1 0) /* Canonical for this value. */
Index: gcc/optc-gen.awk
===
--- gcc/optc-gen.awk(revision 178389)
+++ gcc/optc-gen.awk(working copy)
@@ -30,6 +30,15 @@
# Dump that array of options into a C file.
END {
+# MAX_LANG is the maximum number of languages that can be defined.
+# Its value is extracted from the value of CL_PARAMS in opts.h
+# and is passed on the command line as '-v max_lang=...'.
+if (n_langs max_lang) {
+ print Error: the number of defined
Re: options generation and language count
On 08/30/11 15:52:12, Joseph S. Myers wrote: Please send a patch. [... on points 1, 2, and 3]0 OK, will do. GF: Also, the use of fixed masks is problematic. Perhaps the AWK script GF: could be changed to also generate values for CL_PARAMS, etc., ensuring GF: that will not conflict with the language mask values? That sounds riskier (and does everywhere using opts.h actually need the generated options.h as well?) It looks like many files include opts.h, but do not include options.h. although in principle it ought to be possible to assign this automatically (and actually only CL_DRIVER, CL_TARGET and CL_COMMON should really need bits assigned, though avoiding the others would require a --help rework). An alternative might be to move the fixed assignments (CL_DRIVER, CL_TARGET, CL_COMMON ...) down to start at the beginning of the range, (leaving room for a few more) and to start the auto-generated language mask bits above that? - Gary
Re: tree hash maps and 'discards qualifiers' warnings?
On 08/17/11 08:38:44, Gary Funck wrote: I have been looking at changing UPC's method of recording the blocking factor so that it uses less space in the tree type node. The suggested method for achieving this space reduction is to use a hash table to map pointers to type nodes into UPC blocking factors (for less commonly used blocking factor values). [...] The issue that I'm running into, however, is that the re-implementation of UPC_TYPE_BLOCK_FACTOR() is not plug-and-play with its previous version that used a tree pointer in the node to record the blocking factor. [...] As a follow up, I wasn't able to find an alternative method that preserved the const'ness of the API's involved in the change, so ended up reverting them back to regular tree pointers. The following change was committed to the GUPC branch. 2011-08-30 Gary Funck g...@intrepid.com * tree.h (check_qualified_type): Change 'const_tree' argument types back to 'tree' to avoid complaints of assignment drops qualifiers for invocations of the newly implemented TYPE_BLOCK_FACTOR() macro, which invokes hash functions with 'tree' pointer values that are not const qualified. * tree.c (check_qualified_type, check_aligned_type): Ditto. * c-typeck.c (comptypes_internal): Ditto.
options generation and language count
Recently, we ran make check on the GCC built from the GUPC branck and compared it against make check run against the GCC trunk version of the most recent merge with the trunk. The following failure was detected on the GUPC branch. cc1: internal compiler error: in print_specific_help, at opts.c:1128 The following command generates the error. gcc/xgcc -Bgcc/ test-18810.c --help=optimizers -lm -o test-18810.x The assertion check is here: 1126 /* Sanity check: Make sure that we do not have more 1127 languages than we have bits available to enumerate them. */ 1128 gcc_assert ((1U cl_lang_count) CL_MIN_OPTION_CLASS); The value of 'cl_lang_count' is calculated by an AWK script that processes the .opt files and generates .c and .h files. The value of CL_MIN_OPTION_CLASS is defined in opts.h. 130 #define CL_PARAMS (1U 11) /* Fake entry. Used to display --param info with --help. */ 131 #define CL_WARNING (1U 12) /* Enables an (optional) warning message. */ 132 #define CL_OPTIMIZATION (1U 13) /* Enables an (optional) optimization. */ 133 #define CL_DRIVER (1U 14) /* Driver option. */ 134 #define CL_TARGET (1U 15) /* Target-specific option. */ 135 #define CL_COMMON (1U 16) /* Language-independent. */ 136 137 #define CL_MIN_OPTION_CLASS CL_PARAMS 138 #define CL_MAX_OPTION_CLASS CL_COMMON Above, we can see that CL_MIN_OPTION_CLASS is equal to CL_PARAMS, which is a fixed value: (1U 11). The options.h file is generated by the AWK scripts and is present in the 'gcc' build directory. Here's the relevant values. #define CL_UPC (1U 10) #define CL_LANG_ALL ((1U 11) - 1) The cl_lang_count value is in the generated options.c file. const unsigned int cl_lang_count = 11; Although I haven't reviewed the source code in detail it looks to me like there might be two issues here: 1) The sanity check should probably read: gcc_assert ((1U cl_lang_count) = CL_MIN_OPTION_CLASS); In other words, it is off-by-one. 2) The fixed shift counts starting at CL_PARAMS probably need to be adjusted upwards to allow for more languages. A third problem, is that this sort of error would be better detected at build time rather than waiting to run a DejaGNU test to find it. Also, the use of fixed masks is problematic. Perhaps the AWK script could be changed to also generate values for CL_PARAMS, etc., ensuring that will not conflict with the language mask values? - Gary
Re: Add __builtin_complex to construct complex values (C1X CMPLX* macros)
On 08/19/11 15:55:12, Joseph S. Myers wrote: Index: gcc/c-family/c-common.h === --- gcc/c-family/c-common.h (revision 177894) +++ gcc/c-family/c-common.h (working copy) @@ -103,7 +103,7 @@ enum rid /* C extensions */ RID_ASM, RID_TYPEOF, RID_ALIGNOF, RID_ATTRIBUTE, RID_VA_ARG, RID_EXTENSION, RID_IMAGPART, RID_REALPART, RID_LABEL, RID_CHOOSE_EXPR, - RID_TYPES_COMPATIBLE_P, + RID_TYPES_COMPATIBLE_P, RID_BUILTIN_COMPLEX, RID_DFLOAT32, RID_DFLOAT64, RID_DFLOAT128, RID_FRACT, RID_ACCUM, Joseph, Does this comment also need to be adjusted? /* Reserved identifiers. This is the union of all the keywords for C, C++, and Objective-C. All the type modifiers have to be in one block at the beginning, because they are used as mask bits. There are 28 type modifiers; if we add many more we will have to redesign the mask mechanism. */ That is: 28 - 29? BTW, unfortunately for GUPC, this will bump the number of bits it uses to *32*. Thus, any subsequent addition of RID's will cause GUPC to exceed the 32-bit barrier. Is it time to consider increasing the bit range of this set of flag bits? - Gary
Re: Add __builtin_complex to construct complex values (C1X CMPLX* macros)
On 08/22/11 22:39:04, Joseph S. Myers wrote: [...] This isn't a type modifier; neither is __builtin_types_compatible_p. It's not within the first 28. [...] I don't believe the comment is accurate; I'm not aware of any code for any C-family front end that uses these values as mask bits at all. OK, thanks for the clarification. - Gary
tree hash maps and 'discards qualifiers' warnings?
I have been looking at changing UPC's method of
recording the blocking factor so that it uses less space
in the tree type node. The suggested method for
achieving this space reduction is to use a hash table to
map pointers to type nodes into UPC blocking factors
(for less commonly used blocking factor values).
In UPC, the default blocking factor for arrays is one,
and for UPC shared scalar/struct variables it is zero.
Therefore, the current approach is to only record
blocking factors greater than one in a hash table.
The basics are in place (in tree.h):
/* Non-zero if the UPC shared type refers to THREADS
in its array dimension. */
#define UPC_TYPE_HAS_THREADS_FACTOR(TYPE) TYPE_LANG_FLAG_3 (TYPE)
/* Non-zero if the UPC blocking factor is 0. */
#define UPC_TYPE_HAS_BLOCK_FACTOR_0(TYPE) TYPE_LANG_FLAG_4 (TYPE)
/* Non-zero if the UPC blocking factor is greater than 1.
In this case, the blocking factor value is stored in a hash table. */
#define UPC_TYPE_HAS_BLOCK_FACTOR_X(TYPE) TYPE_LANG_FLAG_5 (TYPE)
extern void upc_block_factor_insert (tree, tree);
extern tree upc_block_factor_lookup (tree);
/* Return the UPC blocking factor of the type given by NODE.
The default block factor is one. The additional flag bits
over-ride the default. */
#define UPC_TYPE_BLOCK_FACTOR(NODE) \
(UPC_TYPE_HAS_BLOCK_FACTOR_0 (NODE) ? size_zero_node \
: UPC_TYPE_HAS_BLOCK_FACTOR_X (NODE) ? upc_block_factor_lookup (NODE) \
: size_one_node)
Note above, that the bits used are the TYPE_LANG_FLAG bits.
This should be acceptable for UPC, because it is built as
a language variant.
Interestingly, if additional bits were allocated just for UPC,
they would likely increase the size of the tree node, because
there are no spare bits here:
struct GTY(()) tree_type_common {
[]
unsigned int precision : 10;
[...]
unsigned lang_flag_6 : 1;
The bit field sizes in the interval shown above total to 32 bits.
Therefore, it seems that any attempt to add new flag bits will
likely increase the size of a tree_type_common node.
The issue that I'm running into, however, is that the
re-implementation of UPC_TYPE_BLOCK_FACTOR() is not
plug-and-play with its previous version that used
a tree pointer in the node to record the blocking factor.
Here's why:
gcc/tree.c|5681 col 27| warning: passing argument 1 of
‘upc_block_factor_lookup’ discards qualifiers from pointer target type
gcc/tree.h|1196 col 13| note: expected ‘tree’ but argument is of type
‘const_tree’
The code referenced above is:
bool
check_qualified_type (const_tree cand, const_tree base, int type_quals)
{
return (TYPE_QUALS (cand) == type_quals
[...]
/* For UPC, the blocking factors have to be equal. */
tree_int_cst_equal (UPC_TYPE_BLOCK_FACTOR (cand),
UPC_TYPE_BLOCK_FACTOR (base))
[...]
}
The prototype for upc_block_factor_lookup() accepts a 'tree', not
a 'const_tree'. If the parameter is changed to 'const_tree',
then the body of the procedure will encounter another 'const' clash
because a tree_map is defined as having nodes of type 'tree',
not 'const_tree'. For example,
struct GTY(()) tree_map_base {
tree from;
};
NOTE: I looked at calls to DECL_VALUE_EXPR() to see if it ran
into this issue, however, only 'tree' nodes appear to be passed
to this function macro.
Any suggestions on how to work around this 'const' clash warning?
Thanks,
- Gary
Re: RFC: [GUPC] UPC-related front-end changes
On 07/02/11 00:06:07, Jakub Jelinek wrote: Yes, look at DECL_VALUE_EXPR/SET_DECL_VALUE_EXPR/DECL_HAS_VALUE_EXPR_P or DECL_DEBUG_EXPR/SET_DECL_DEBUG_EXPR/DEBUG_EXPR_IS_FROM. OK, thanks. The UPC front end will be changed use a similar method to encode UPC's block size.
Re: RFC: [GUPC] UPC-related front-end changes
On 07/01/11 16:39:55, Mike Stump wrote: You can use that to allocate additional data for the frontend's exclusive use. See the C++ frontend, it uses language specific data. :-) Heh. It sounds like this language-specific hook works well for language front-ends that aren't sharing the logic of the C front end. Therefore, a no-go for UPC.
Re: RFC: [GUPC] UPC-related front-end changes
On 07/02/11 15:21:32, Joseph S. Myers wrote: [...] In general configure options aren't really a good idea in many cases: * If something is always best on a particular architecture, maybe you want a target hook (not macro) rather than a configure option, with the target hook being set appropriately for each target and no option for the person configuring GCC to override. With UPC, the packed pointer-to-shared (PTS) representation takes less space and is generally useful for most applications. However, it is sometimes necessary to allocate more bits for the number of threads, and less for the block offset for example, which makes it possible to continue to use the packed PTS representation in certain applications. This motivates the 'configure' setting. The 'struct' PTS has essentially no limitations but the pointers-to-shared are bigger and accessing the sub-fields of this fat pointer is somewhat slower. Also, passing 'struct' based PTS's as arguments (to the runtime for example) can be slower on some architectures. The difficulty with making this representation choice a compile-time selection is that the runtime needs to be aware of the pointer-to-shared layout. Perhaps we could build two separate runtimes (packed PTS and struct PTS) and parameterize the packed PTS based runtime to calculate the shifts and masks it needs rather than compiling them as constants, but that will probably impact performance on various commonly called paths through the runtime. Even if you need a configure option for the default, the command-line options may still be useful in some cases for testing and debugging purposes. Yes, that would be useful.
Re: RFC: [GUPC] UPC-related front-end changes
Off list, Mike S. pointed out that the Objective C front-end uses the lang-specific extensions to GCC's tree node, and it shares logic with the C and C++ front ends. Therefore, the lang-specific extensions might offer an alternative approach for storing UPC's layout qualifier. The current plan, however, is to use a hash table.
Re: RFC: [GUPC] UPC-related front-end changes
On 07/01/11 19:28:34, Joseph S. Myers wrote: On Fri, 1 Jul 2011, Gary Funck wrote: GF: * Most of the #ifdef conditionals have been removed. Some target macros GF: have been defined and documented in tm.texi. We still have some questions For each target macro, what is the justification requiring it to be a macro rather than a hook documented in target.def with just an @hook line in tm.texi.in? The justification should be one of: [...] Joseph, thanks for the follow up. I have several questions on the best method of documenting and packaging UPC's configuration (and target) specific definition. I will describe those questions and some potential solutions in an email, to follow. - Gary
