Ada gcc compiler for ia64-hp-openvms
Dear GCC Steering Committee, I am David, founder of AdaLabs Ltd, a software engineering startup having expertise in Ada programming language technologies. As a summary, we would like to know if gcc has interest in an assignment of copyright to FSF from our work. We are not used to this process, and are kindly soliciting your support on this task. Our work is about Ada compiler support on GCC for OpenVMS. AdaLabs Ltd (http://adalabs.com) and PIA-SOFER SARL (http://pia-sofer.fr) have worked hard to make Ada available again on OpenVMs using GCC (ia64-hp-openvms). Both entities share ownership, while AdaLabs is also the author of the work. Our work is based on gcc-4.7.4, and consists in building a gcc compiler for openvms ia64 (through native, cross and canadian build, starting from x86_64-linux-gnu to finally reach ia64-hp-openvms). The modifications are of two flavours: - patches to make the builds successful (in native, cross and canadian builds) - patches/backports to implement Ada/VMS related features, that are present in gcc version after gcc-4.7.4 (in native, cross and canadian builds). In the case you are interested in our copyright assignment proposal, we would be pleased to continue this process. In the case you are not interested in our copyright assignment proposal, we would be pleased if you could advise us on the best way to make our work available to the GNU/FSF community, especially concerning the licenses and copyrights management. I am at your disposal concerning any information you may need to take a stand concerning this proposal. Best Regards, -- David SAUVAGE Software Agile Architect, Director AdaLabs Ltd - Mauritius http://adalabs.com +230 542 818 32 skype sauvaged BRN C10097052
Re: suggestion: c compiler warning for failure to test result
On 04/25/2017 05:02 PM, Martin Sebor wrote: On 04/25/2017 02:35 PM, Joe Perches wrote: A possibly useful addition similar to: __attribute__((warn_unused_result)) might be __attribute__((warn_untested_result)) for things like allocation failures that are not verified before use. I agree that this would be a useful feature. In fact, I've been thinking about implementing something like it, though not quite as general. (My initial thought was to key the warning off an existing attribute like alloc_size for functions that aren't also decorated with returns_nonnull.) With warn_untested_result even non-allocation functions (such as fopen) could be decorated, so that seems like a better approach. Can you please open an enhancement request in Bugzilla? Yea, I like it as well. jeff
[C++ Patch] Remove is_auto_or_concept, etc (Was: Re: [C++, concepts] Two slightly obscure pt.c functions?)
Hi again,
On 26/04/2017 12:32, Paolo Carlini wrote:
Hi,
in 2013 (2013-09-16) Adam added two slightly obscure functions and I
can't find much around in terms of rationale, etc:
/* Returns true iff TYPE is a TEMPLATE_TYPE_PARM representing 'auto',
'decltype(auto)' or a concept. */
bool
is_auto_or_concept (const_tree type)
{
return is_auto (type); // or concept
}
/* Returns the TEMPLATE_TYPE_PARM in TYPE representing a generic type
(`auto' or
a concept identifier) iff TYPE contains a use of a generic type.
Returns
NULL_TREE otherwise. */
tree
type_uses_auto_or_concept (tree type)
{
return find_type_usage (type, is_auto_or_concept);
}
The latter seems completely unused (it's meant for debugging
purposes?); the former evidently simply forwards to is_auto, and we
end up in the front-end with uses of both, which in fact are
equivalent, which seems weird: IMHO, if they are actually equivalent
in our implementation we should clearly explain that in the comment
and have only one. Or what?
... replying to myself, in practice we could do the below, which
certainly passes testing, and in fact now seems to me even more obvious
than I thought a couple of days ago...
Thanks,
Paolo.
/
2017-04-27 Paolo Carlini
* pt.c (is_auto_or_concept): Remove.
(type_uses_auto_or_concept): Remove, unused.
(find_parameter_packs_r, extract_autos_r, is_auto_r): Adjust.
* parser.c (tree_type_is_auto_or_concept): Remove, unused.
* cp-tree.h (is_auto_or_concept): Remove.
Index: cp-tree.h
===
--- cp-tree.h (revision 247347)
+++ cp-tree.h (working copy)
@@ -6161,7 +6161,6 @@ extern void append_type_to_template_for_access_che
extern tree convert_generic_types_to_packs (tree, int, int);
extern tree splice_late_return_type(tree, tree);
extern bool is_auto(const_tree);
-extern bool is_auto_or_concept (const_tree);
extern tree process_template_parm (tree, location_t, tree,
bool, bool);
extern tree end_template_parm_list (tree);
Index: parser.c
===
--- parser.c(revision 247347)
+++ parser.c(working copy)
@@ -38791,16 +38791,6 @@ make_generic_type_name ()
return get_identifier (buf);
}
-/* Predicate that behaves as is_auto_or_concept but matches the parent
- node of the generic type rather than the generic type itself. This
- allows for type transformation in add_implicit_template_parms. */
-
-static inline bool
-tree_type_is_auto_or_concept (const_tree t)
-{
- return TREE_TYPE (t) && is_auto_or_concept (TREE_TYPE (t));
-}
-
/* Add an implicit template type parameter to the CURRENT_TEMPLATE_PARMS
(creating a new template parameter list if necessary). Returns the newly
created template type parm. */
Index: pt.c
===
--- pt.c(revision 247347)
+++ pt.c(working copy)
@@ -3489,7 +3489,7 @@ find_parameter_packs_r (tree *tp, int *walk_subtre
parameter pack (14.6.3), or the type-specifier-seq of a type-id that
is a pack expansion, the invented template parameter is a template
parameter pack. */
- if (ppd->type_pack_expansion_p && is_auto_or_concept (t))
+ if (ppd->type_pack_expansion_p && is_auto (t))
TEMPLATE_TYPE_PARAMETER_PACK (t) = true;
if (TEMPLATE_TYPE_PARAMETER_PACK (t))
parameter_pack_p = true;
@@ -24806,7 +24806,7 @@ static int
extract_autos_r (tree t, void *data)
{
hash_table &hash = *(hash_table*)data;
- if (is_auto_or_concept (t))
+ if (is_auto (t))
{
/* All the autos were built with index 0; fix that up now. */
tree *p = hash.find_slot (t, INSERT);
@@ -25530,7 +25530,7 @@ is_auto (const_tree type)
int
is_auto_r (tree tp, void */*data*/)
{
- return is_auto_or_concept (tp);
+ return is_auto (tp);
}
/* Returns the TEMPLATE_TYPE_PARM in TYPE representing `auto' iff TYPE contains
@@ -25556,26 +25556,6 @@ type_uses_auto (tree type)
return find_type_usage (type, is_auto);
}
-/* Returns true iff TYPE is a TEMPLATE_TYPE_PARM representing 'auto',
- 'decltype(auto)' or a concept. */
-
-bool
-is_auto_or_concept (const_tree type)
-{
- return is_auto (type); // or concept
-}
-
-/* Returns the TEMPLATE_TYPE_PARM in TYPE representing a generic type (`auto'
or
- a concept identifier) iff TYPE contains a use of a generic type. Returns
- NULL_TREE otherwise. */
-
-tree
-type_uses_auto_or_concept (tree type)
-{
- return find_type_usage (type, is_auto_or_concept);
-}
-
-
/* For a given template T, return the vector of typedefs referenced
in T for which access check is needed at T instantiation time.
T is either a FUNCTION_DECL or a RECORD_TYPE.
GCC loop structure question
I have a question about the GCC loop structure. I am trying to identify the
induction variable for a for loop and I don't see how to do that.
For example, if I have:
int foo(int *a, int *b, int *c, int *d, int *e, int *f, int n)
{
int i;
for (i = 0; i < n; i++) {
a[i] = b[i] + c[i];
d[i] = e[i] * f[i];
}
}
I basically want to identify 'i' as the IV and look at its uses inside the
loop.
I can look at the control_ivs in the loop structure and I see:
base is:
constant 1>
step is:
constant 1>
But it doesn't say what is being set to base or what is being increased by
step in each loop iteration. (I am also not sure why base is 1 and not 0.)
Does this refer to a psuedo-IV or something instead of a real SSA variable
that appears in the tree? How would I identify 'i' as the IV for this
loop? Do I need to look at the loop header and latch and see what the
header sets and what the latch checks to identify the variable?
Steve Ellcey
sell...@cavium.com
Re: GCC loop structure question
On April 27, 2017 8:47:18 PM GMT+02:00, Steve Ellcey wrote:
>I have a question about the GCC loop structure. I am trying to
>identify the
>induction variable for a for loop and I don't see how to do that.
>
>For example, if I have:
>
>int foo(int *a, int *b, int *c, int *d, int *e, int *f, int n)
>{
> int i;
> for (i = 0; i < n; i++) {
> a[i] = b[i] + c[i];
> d[i] = e[i] * f[i];
> }
>}
>
>I basically want to identify 'i' as the IV and look at its uses inside
>the
>loop.
>
>I can look at the control_ivs in the loop structure and I see:
>
>base is:
>
>constant 1>
>step is:
>
>constant 1>
>
>But it doesn't say what is being set to base or what is being increased
>by
>step in each loop iteration. (I am also not sure why base is 1 and not
>0.)
>
>Does this refer to a psuedo-IV or something instead of a real SSA
>variable
>that appears in the tree? How would I identify 'i' as the IV for this
>loop? Do I need to look at the loop header and latch and see what the
>header sets and what the latch checks to identify the variable?
I think you want to look at all loop header PHIs. The PHI results that satisfy
simple_iv should be those you are interested in.
Richard.
>Steve Ellcey
>sell...@cavium.com
Re: suggestion: c compiler warning for failure to test result
On Thu, 2017-04-27 at 10:42 -0600, Jeff Law wrote: > On 04/25/2017 05:02 PM, Martin Sebor wrote: > > On 04/25/2017 02:35 PM, Joe Perches wrote: > > > A possibly useful addition similar to: > > > > > > __attribute__((warn_unused_result)) > > > > > > might be > > > > > > __attribute__((warn_untested_result)) > > > > > > for things like allocation failures that > > > are not verified before use. > > > > I agree that this would be a useful feature. In fact, I've been > > thinking about implementing something like it, though not quite > > as general. (My initial thought was to key the warning off > > an existing attribute like alloc_size for functions that aren't > > also decorated with returns_nonnull.) With warn_untested_result > > even non-allocation functions (such as fopen) could be decorated, > > so that seems like a better approach. > > > > Can you please open an enhancement request in Bugzilla? > > Yea, I like it as well. Here's the bugzilla entry: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80522
gcc-7-20170427 is now available
Snapshot gcc-7-20170427 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170427/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 247353 You'll find: gcc-7-20170427.tar.bz2 Complete GCC SHA256=5a7b413d2843bb89290947dccf0b16f3cf9e0ba33e99fe9b37d78b43e7cc2e81 SHA1=99d9e68d3e31205024d9e171d81f892b33b4534e Diffs from 7-20170420 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
