Re: [RFC] Formation of vector function name
2015-06-16 17:23 GMT+03:00 Joseph Myers : > On Mon, 15 Jun 2015, Andrew Pinski wrote: > >> > results in asm redirection for log to __log_finite and final vector >> > function name becomes _ZGVbN2v___log_finite. >> > >> > With point of view from C Library side, it reflects in addition of asm >> > redirections _ZGVbN2v___log_finite = _ZGVbN2v_log in the headers. >> > >> > May be the cleaner way is to base vector name on original name of >> > declaration, not asm declaration name (use DECL_NAME instead of >> > DECL_ASSEMBLER_NAME)? >> >> >> I don't think this would be useful really because if you have a >> function say logl where you have two options of long double, you want >> to support both you would name one logl and the other logl128 and then >> using DECL_ASSEMBLER_NAME to from the SIMD name would be useful to use >> the one with logl128 in it rather than logl. > > The point is that the vector versions may not be in one-to-one > correspondence with the scalar versions - you might have several different > scalar versions depending on compiler options, all of which correspond to > a single vector version. Lets come to agreement to change vector function name formation in future GCC versions? Patch to fix it looks quite simple. I am going to regtest it. diff --git a/gcc/omp-low.c b/gcc/omp-low.c index d41688b..8d9de76 100644 --- a/gcc/omp-low.c +++ b/gcc/omp-low.c @@ -18687,7 +18687,7 @@ simd_clone_mangle (struct cgraph_node *node, } pp_underscore (&pp); - const char *str = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (node->decl)); + const char *str = IDENTIFIER_POINTER (DECL_NAME (node->decl)); if (*str == '*') ++str; pp_string (&pp, str); -- WBR, Andrew
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Fri, Feb 19, 2016 at 1:07 PM, Richard Smith wrote:
> On Fri, Feb 19, 2016 at 5:35 AM, Michael Matz wrote:
>> Hi,
>>
>> On Thu, 18 Feb 2016, Richard Smith wrote:
>>
>>> >> An empty type is a type where it and all of its subobjects
>>> >> (recursively) are of class, structure, union, or array type. No
>>> >> memory slot nor register should be used to pass or return an object
>>> >> of empty type.
>>> >
>>> > The trivially copyable is gone again. Why is it not necessary?
>>>
>>> The C++ ABI doesn't defer to the C psABI for types that aren't
>>> trivially-copyable. See
>>> http://mentorembedded.github.io/cxx-abi/abi.html#normal-call
>>
>> Hmm, yes, but we don't want to define something for only C and C++, but
>> language independend (so far as possible). And given only the above
>> language I think this type:
>>
>> struct S {
>> S() {something();}
>> };
>>
>> would be an empty type, and that's not what we want.
>
> Yes it is. Did you mean to give S a copy constructor, copy assignment
> operator, or destructor instead?
>
>> "Trivially copyable"
>> is a reasonably common abstraction (if in doubt we could even define it in
>> the ABI), and captures the idea that we need well (namely that a bit-copy
>> is enough).
In this case:
struct dummy0
{
};
struct dummy
{
dummy0 d[20];
dummy0 * foo (int i);
};
dummy0 *
dummy::foo (int i)
{
return &d[i];
}
dummy0 *
bar (dummy d, int i)
{
return d.foo (i);
}
dummy shouldn't be passed as empty type. We need to have a clear
definition for what kinds of member functions are allowed in an empty
type.
--
H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Sat, 20 Feb 2016, H.J. Lu wrote:
On Fri, Feb 19, 2016 at 1:07 PM, Richard Smith wrote:
On Fri, Feb 19, 2016 at 5:35 AM, Michael Matz wrote:
Hi,
On Thu, 18 Feb 2016, Richard Smith wrote:
An empty type is a type where it and all of its subobjects
(recursively) are of class, structure, union, or array type. No
memory slot nor register should be used to pass or return an object
of empty type.
The trivially copyable is gone again. Why is it not necessary?
The C++ ABI doesn't defer to the C psABI for types that aren't
trivially-copyable. See
http://mentorembedded.github.io/cxx-abi/abi.html#normal-call
Hmm, yes, but we don't want to define something for only C and C++, but
language independend (so far as possible). And given only the above
language I think this type:
struct S {
S() {something();}
};
would be an empty type, and that's not what we want.
Yes it is. Did you mean to give S a copy constructor, copy assignment
operator, or destructor instead?
"Trivially copyable"
is a reasonably common abstraction (if in doubt we could even define it in
the ABI), and captures the idea that we need well (namely that a bit-copy
is enough).
In this case:
struct dummy0
{
};
struct dummy
{
dummy0 d[20];
dummy0 * foo (int i);
};
dummy0 *
dummy::foo (int i)
{
return &d[i];
}
dummy0 *
bar (dummy d, int i)
{
return d.foo (i);
}
dummy shouldn't be passed as empty type.
Why not?
We need to have a clear definition for what kinds of member functions
are allowed in an empty type.
--
Marc Glisse
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 20 February 2016 at 18:55, H.J. Lu wrote:
> struct dummy0
> {
> };
>
> struct dummy
> {
> dummy0 d[20];
>
> dummy0 * foo (int i);
> };
>
> dummy0 *
> dummy::foo (int i)
> {
> return &d[i];
> }
>
> dummy0 *
> bar (dummy d, int i)
> {
> return d.foo (i);
> }
1. This has undefined behaviour due to returning a pointer to a local variable
2. There's still no need for the reference to the original argument
since copying it is a nop.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Sat, Feb 20, 2016 at 10:50 AM, Matthijs van Duin
wrote:
> On 20 February 2016 at 18:55, H.J. Lu wrote:
>> struct dummy0
>> {
>> };
>>
>> struct dummy
>> {
>> dummy0 d[20];
>>
>> dummy0 * foo (int i);
>> };
>>
>> dummy0 *
>> dummy::foo (int i)
>> {
>> return &d[i];
>> }
>>
>> dummy0 *
>> bar (dummy d, int i)
>> {
>> return d.foo (i);
>> }
>
> 1. This has undefined behaviour due to returning a pointer to a local variable
> 2. There's still no need for the reference to the original argument
> since copying it is a nop.
Given:
An empty type is a type where it and all of its subobjects (recursively)
are of class, structure, union, or array type. No memory slot nor register
should be used to pass or return an object of empty type.
Footnote: Array of empty type can only passed by reference in C and C++.
Is there a class, which meets the above definition, with a member function
which can't be passed without a memory slot or a register?
--
H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 20 February 2016 at 20:34, H.J. Lu wrote: > Is there a class, which meets the above definition, with a member function > which can't be passed without a memory slot or a register? The EmptyInt class in my first post in this thread. It has no non-static data members, has standard layout, and has a trivial default constructor, but it has a non-trivial copy constructor and non-trivial destructor. Matthijs van Duin
Re: [isocpp-parallel] Proposal for new memory_order_consume definition
On Fri, Feb 19, 2016 at 09:15:16PM -0500, Tony V E wrote: > There's at least one easy answer in there: > > > If implementations must support annotation, what form should that > annotation take? P0190R0 recommends the [[carries_dependency]] > attribute, but I am not picky as long as it can be (1) applied > to all relevant pointer-like objects and (2) used in C as well > as C++. ;-) > > If an implementation must support it, then it is not an annotation but a > keyword. So no [[]] I would be good with that approach, especially if the WG14 continues to stay away from annotations. For whatever it is worth, the introduction of intrinsics for comparisons that avoid breaking dependencies enables the annotation to remain optional. Thanx, Paul > Sent from my BlackBerry portable Babbage Device > Original Message > From: Paul E. McKenney > Sent: Thursday, February 18, 2016 4:58 AM > To: paral...@lists.isocpp.org; linux-ker...@vger.kernel.org; > linux-a...@vger.kernel.org; gcc@gcc.gnu.org; llvm-...@lists.llvm.org > Reply To: paral...@lists.isocpp.org > Cc: pet...@infradead.org; j.algl...@ucl.ac.uk; will.dea...@arm.com; > dhowe...@redhat.com; ramana.radhakrish...@arm.com; luc.maran...@inria.fr; > a...@linux-foundation.org; peter.sew...@cl.cam.ac.uk; > torva...@linux-foundation.org; mi...@kernel.org > Subject: [isocpp-parallel] Proposal for new memory_order_consume definition > > Hello! > > A proposal (quaintly identified as P0190R0) for a new memory_order_consume > definition may be found here: > > http://www2.rdrop.com/users/paulmck/submission/consume.2016.02.10b.pdf > > As requested at the October C++ Standards Committee meeting, this > is a follow-on to P0098R1 that picks one alternative and describes > it in detail. This approach focuses on existing practice, with the > goal of supporting existing code with existing compilers. In the last > clang/LLVM patch I saw for basic support of this change, you could count > the changed lines and still have lots of fingers and toes left over. > Those who have been following this story will recognize that this is > a very happy contrast to work that would be required to implement the > definition in the current standard. > > I expect that P0190R0 will be discussed at the upcoming C++ Standards > Committee meeting taking place the week of February 29th. Points of > discussion are likely to include: > > o May memory_order_consume dependency ordering be used in > unannotated code? I believe that this must be the case, > especially given that this is our experience base. P0190R0 > therefore recommends this approach. > > o If memory_order_consume dependency ordering can be used in > unannotated code, must implementations support annotation? > I believe that annotation support should be required, at the very > least for formal verification, which can be quite difficult to > carry out on unannotated code. In addition, it seems likely > that annotations can enable much better diagnostics. P0190R0 > therefore recommends this approach. > > o If implementations must support annotation, what form should that > annotation take? P0190R0 recommends the [[carries_dependency]] > attribute, but I am not picky as long as it can be (1) applied > to all relevant pointer-like objects and (2) used in C as well > as C++. ;-) > > o If memory_order_consume dependency ordering can be used in > unannotated code, how best to define the situations where > the compiler can determine the exact value of the pointer in > question? (In current defacto implementations, this can > defeat dependency ordering. Interestingly enough, this case > is not present in the Linux kernel, but still needs to be > defined.) > > Options include: > > o Provide new intrinsics that carry out the > comparisons, but guarantee to preserve dependencies, > as recommended by P0190R0 (std::pointer_cmp_eq_dep(), > std::pointer_cmp_ne_dep(), std::pointer_cmp_gt_dep(), > std::pointer_cmp_ge_dep(), std::pointer_cmp_lt_dep(), > and std::pointer_cmp_le_dep()). > > o State that -any- comparison involving an unannotated > pointer loses the dependency. > > o How is the common idiom of marking pointers by setting low-order > bits to be supported when those pointers carry dependencies? > At the moment, I believe that setting bits in pointers results in > undefined behavior even without dependency ordering, so P0190R0 > kicks this particular can down the road. One option that > has been suggested is to provide intrinsics for this purpose. > (Sorry, but I forget who suggested this.) > > Thoughts? > > Thanx, Paul > > ___ > Parallel mailing list > paral...@lists.isocpp.org > Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/parallel > Link to this post: http://lists.isocpp.org/parallel/2016/02/0040.php > ___ > Paralle
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Sat, Feb 20, 2016 at 11:40 AM, Matthijs van Duin wrote: > On 20 February 2016 at 20:34, H.J. Lu wrote: >> Is there a class, which meets the above definition, with a member function >> which can't be passed without a memory slot or a register? > > The EmptyInt class in my first post in this thread. It has no > non-static data members, has standard layout, and has a trivial > default constructor, but it has a non-trivial copy constructor and > non-trivial destructor. > Can a compiler tell if a copy constructor or destructor is trivial from the class declaration without function body? -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 20 February 2016 at 23:35, H.J. Lu wrote: > Can a compiler tell if a copy constructor or destructor is trivial > from the class declaration without function body? Yes, the mere presence of the declaration suffices to render it non-trivial (unless explicitly declared "= default" like I did with the default constructor, in which case there's no function body).
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Sat, Feb 20, 2016 at 4:57 PM, Matthijs van Duin wrote: > On 20 February 2016 at 23:35, H.J. Lu wrote: >> Can a compiler tell if a copy constructor or destructor is trivial >> from the class declaration without function body? > > Yes, the mere presence of the declaration suffices to render it > non-trivial (unless explicitly declared "= default" like I did with > the default constructor, in which case there's no function body). How about this? An empty type is a type where it and all of its subobjects (recursively) are of class, structure, union, or array type. An empty type may only have static member functions, default constructor, default copy constructor, default copy assignment operator or default destructor. No memory slot nor register should be used to pass or return an object of empty type. -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Sat, Feb 20, 2016 at 9:47 PM, Richard Smith wrote: > On 20 Feb 2016 6:54 p.m., "H.J. Lu" wrote: >> >> On Sat, Feb 20, 2016 at 4:57 PM, Matthijs van Duin >> wrote: >> > On 20 February 2016 at 23:35, H.J. Lu wrote: >> >> Can a compiler tell if a copy constructor or destructor is trivial >> >> from the class declaration without function body? >> > >> > Yes, the mere presence of the declaration suffices to render it >> > non-trivial (unless explicitly declared "= default" like I did with >> > the default constructor, in which case there's no function body). >> >> How about this? >> >> An empty type is a type where it and all of its subobjects (recursively) >> are of class, structure, union, or array type. An empty type may only >> have static member functions, default constructor, default copy >> constructor, default copy assignment operator or default destructor. > > No, that's the wrong rule still. Please leave the C++ rule here to the C++ > ABI rather than trying to reinvent it. Whether a type is empty is completely > orthogonal to whether it must be passed through memory for C++ ABI / > semantics reasons. What is the correct wording? The last one: An empty type is a type where it and all of its subobjects (recursively) are of class, structure, union, or array type. doesn't cover "trivially-copyable". -- H.J.
Re: Need suggestion about bug 68425
I was working on PR68425,
my untested patch :
diff --git a/trunk/gcc/c/c-typeck.c b/trunk/gcc/c/c-typeck.c
--- a/trunk/gcc/c/c-typeck.c(revision 232768)
+++ b/trunk/gcc/c/c-typeck.c(working copy)
@@ -5856,7 +5856,7 @@
component name is taken from the spelling stack. */
static void
-pedwarn_init (location_t location, int opt, const char *gmsgid)
+pedwarn_init (location_t location, int opt, const char *gmsgid, ...)
{
char *ofwhat;
bool warned;
@@ -9269,8 +9269,10 @@
&& (tree_int_cst_lt (constructor_max_index, constructor_index)
|| integer_all_onesp (constructor_max_index)))
{
- pedwarn_init (loc, 0,
-"excess elements in array initializer");
+ pedwarn_init (loc, 0, "excess elements in array initializer "
+ "(%lu elements, expected %lu)",
+ tree_to_uhwi (constructor_index) + 1,
+ tree_to_uhwi (constructor_max_index) + 1);
break;
}
for test case:
const int array[2] = { 1, 2, 3};
const int array1[3] = { 1, 2, 3 ,6};
const int array2[4] = { 1, 2, 3 ,6 ,89};
const int array3[5] = { 1, 2, 3 ,6 ,89 ,193};
It gives :
68425.c: In function ‘main’:
68425.c:3:34: warning: excess elements in array initializer (3
elements, expected 2)
const int array[2] = { 1, 2, 3};
^
68425.c:3:34: note: (near initialization for ‘array’)
68425.c:4:38: warning: excess elements in array initializer (4
elements, expected 3)
const int array1[3] = { 1, 2, 3 ,6};
^
68425.c:4:38: note: (near initialization for ‘array1’)
68425.c:5:41: warning: excess elements in array initializer (5
elements, expected 4)
const int array2[4] = { 1, 2, 3 ,6 ,89};
^~
68425.c:5:41: note: (near initialization for ‘array2’)
68425.c:6:45: warning: excess elements in array initializer (6
elements, expected 5)
const int array3[5] = { 1, 2, 3 ,6 ,89 ,193};
^~~
68425.c:6:45: note: (near initialization for ‘array3’)
Which is as described on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68425
But as we discussed in this thread,
for test case like :
int array[3] = { 1, 2, 3 ,6 ,89 ,193};
It gives:
68425_1.c: In function ‘main’:
68425_1.c:3:31: warning: excess elements in array initializer (4
elements, expected 3)
int array[3] = { 1, 2, 3 ,6 ,89 ,193};
^
68425_1.c:3:31: note: (near initialization for ‘array’)
68425_1.c:3:34: warning: excess elements in array initializer (4
elements, expected 3)
int array[3] = { 1, 2, 3 ,6 ,89 ,193};
^~
68425_1.c:3:34: note: (near initialization for ‘array’)
68425_1.c:3:38: warning: excess elements in array initializer (4
elements, expected 3)
int array[3] = { 1, 2, 3 ,6 ,89 ,193};
^~~
68425_1.c:3:38: note: (near initialization for ‘array’)
Should I submit the patch ?
On 20 February 2016 at 01:20, Manuel López-Ibáñez wrote:
> On 19 February 2016 at 19:13, David Malcolm wrote:
>>> 68425.c:3:34: warning: excess elements in array initializer (6
>>> elements,
>>> expected 2)
>>>const int array[2] = { 1, 2, 3 ,6 ,89 ,193};
>>> ^
>>
>> Yes, that would be ideal. Unfortunately, not every tree expression
>> node has a location stored for it, so implementing the underlined range
>> might be tricky to do. (in particular, INTEGER_CST doesn't. I hope to
>> look into that for gcc 7, perhaps with a wrapper node to provide
>> locations for expr nodes that don't have them).
>
> Do you think that would be better than storing the locations in the
> parent expression? That is, instead of adding extra wrapper nodes,
> with all those tree nodes wasting space just to provide a location,
> add extra location slots to every tree that may have an operand. Or
> perhaps you are thinking about adding some lighter wrapper which is
> just a loc+tree* or something like that.
>
> In the case above (for C), struct constructor_stack could keep track
> of token locations passed by the parser (all tokens have locations,
> but those locations are not saved in all trees). In fact, I see that
> there is already a lot of location passing in the corresponding code,
> but probably all of them refer to input_location or some such.
>
> Cheers,
>
> Manuel.
--
Thanks and Regards,
Prasad Ghangal
