Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Sat, Feb 20, 2016 at 10:48 PM, Richard Smith wrote: > On 20 Feb 2016 10:01 p.m., "H.J. Lu" wrote: >> >> 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". > > That's correct. Whether a type is trivially copyable is unrelated to whether > it is empty. Let get me what you were suggesting. The x86 psABIs define the empty type as 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++. As for what other C++ types, which aren't empty type as defined by x86 psABIs, can be passed and returned without memory slot nor register belong to C++ ABI. Am I correct? -- H.J.
Re: Need suggestion about bug 68425
On 21 February 2016 at 12:32, Prasad Ghangal wrote:
> 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, ...)
You can't just forward arguments to pedwarn() from pedwarn_init() that way.
You will need to wrap them in va_list.
Perhaps write a version of pedwarn() taking va_list or replicate body of
pedwarn() in pedwarn_init()
> {
>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 ?
It would be nice if we can avoid warning multiple times.
It appears to me the warning is emitted multiple times because
process_init_element is called from c_parser_initval, which is called from
c_parser_initelt, which is called in a loop from c_parser_braced_init.
I attached an untested patch that prevents multiple warnings.
eg:
void foo(void)
{
int a[2] = { 1, 2, 3, 4, 5 };
}
c-test.c: In function 'foo':
c-test.c:3:22: warning: excess elements in array initializer
int a[2] = { 1, 2, 3, 4, 5 };
^
c-test.c:3:22: note: (near initialization for 'a')
It uses a flag (warn_extra_init) to see if warning for extra initializer
has already been emitted. Perhaps you can try modifying it to emit
array sizes. There could also be a better way to avoid multiple warnings.
Thanks,
Prathamesh
>
>
>
> 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
gcc-6-20160221 is now available
Snapshot gcc-6-20160221 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160221/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 233594 You'll find: gcc-6-20160221.tar.bz2 Complete GCC MD5=14045e26e96afd53036499e35aa826cd SHA1=fdfa35fd933d756213ae3e51d3a14073e7a566f7 Diffs from 6-20160214 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: How to use _Generic with bit-fields
I've tried you hack, but it doesn't work with "long bit fields". Also,
I've run into another problem. Instead of using unsigned char for
the bit field I changed it to a long unsigned int:33 and now I can't
print it without a warning.
Here is my Makefile:
CC = gcc
O = 3
X = c
STD = c11
CFLAGS = -m64 -Wall -std=$(STD)
all: test
test.o: test.c
$(CC) -x $(X) -O$(O) $(CFLAGS) -o test.o -c test.c
objdump -d test.o > test.txt
test: test.o
$(CC) $(CFLAGS) test.o -o test
clean:
rm -f test test.o test.txt
Here is the test:
#include
struct big_bit_fields {
long unsigned int b33:33;
} __attribute__((__packed__));
_Static_assert(sizeof(struct big_bit_fields) == 5,
L"big_bit_fields is not 5 bytes");
#define type_to_str(__x) _Generic((0)?(__x):(__x), \
_Bool : "_Bool", \
char : "char", \
signed char : "unsigned char", \
unsigned char : "unsigned char", \
short int : "short int", \
unsigned short int: "unsigned short int", \
int : "int", \
unsigned int : "unsigned int", \
long int : "long int", \
long unsigned int : "long unsigned int", \
long long int : "long long int", \
long long unsigned int : "long long unsigned int", \
default : "unknown type")
int main(void) {
struct big_bit_fields bbf = { .b33 = 0x1 };
printf("bbf.b33=0x%lx\n", bbf.b33);
printf(" type=%s\n", type_to_str(bbf.b33));
printf(" <<1 =0x%016lx\n", bbf.b33 << 1);
printf(" (ull)<<1 =0x%016lx\n", (long unsigned int)bbf.b33 << 1);
return 0;
}
Here the compile and run:
$ make clean ; make ; ./test
rm -f test test.o test.txt
gcc -x c -O3 -m64 -Wall -std=c11 -o test.o -c test.c
test.c: In function ‘main’:
test.c:44:10: warning: format ‘%lx’ expects argument of type ‘long
unsigned int’, but argument 2 has type ‘long unsigned int:33’
[-Wformat=]
printf("bbf.b33=0x%lx\n", bbf.b33);
^
test.c:46:10: warning: format ‘%lx’ expects argument of type ‘long
unsigned int’, but argument 2 has type ‘long unsigned int:33’
[-Wformat=]
printf(" <<1 =0x%016lx\n", bbf.b33 << 1);
^
objdump -d test.o > test.txt
gcc -m64 -Wall -std=c11 test.o -o test
bbf.b33=0x1
type=unknown type
<<1 =0x0001fffe
(ull)<<1 =0x0003fffe
On Fri, Feb 19, 2016 at 1:35 PM, Martin Sebor wrote:
> On 02/19/2016 11:25 AM, Wink Saville wrote:
>>
>> I'm using gcc 5.3.0:
>>
>> $ gcc --version
>> gcc (GCC) 5.3.0
>> Copyright (C) 2015 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions. There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>> PURPOSE.
>>
>>
>> And I've tried to use _Generic to print the type of a bit field but
>> the compiler fails with:
>>
>> $ make
>> gcc -Wall -std=c11 -o test.o -c test.c
>> test.c: In function ‘main’:
>> test.c:8:35: error: ‘_Generic’ selector of type ‘unsigned char:2’ is
>> not compatible with any association
>> #define type_to_str(__x) _Generic((__x), \
>> ^
>> test.c:17:18: note: in expansion of macro ‘type_to_str’
>> printf("%s\n", type_to_str(b.f1));
>>^
>> Makefile:7: recipe for target 'test.o' failed
>> make: *** [test.o] Error 1
>> bash: ./test: No such file or directory
>>
>>
>> The test program is:
>>
>> $ cat test.c
>> #include
>>
>> struct bits {
>>unsigned char f0;
>>unsigned char f1:2;
>> };
>>
>> #define type_to_str(__x) _Generic((__x), \
>>unsigned char : "unsigned char")
>>
>> int main(void) {
>>struct bits b = { .f0 = 255, .f1 = 3 };
>>
>>printf("%d\n", b.f0);
>>printf("%s\n", type_to_str(b.f0));
>>printf("%d\n", b.f1);
>>printf("%s\n", type_to_str(b.f1));
>>
>>return 0;
>> }
>>
> ...
>>
>> How do I create a type association for a bit field?
>
>
> I suspect this falls under the set of issues that fall under bug
> 65471 - type interpretation in _Generic. The C language rules
> for _Generic aren't completely clear about what conversions are
> to take place. It would be helpful if you could your test case
> to the bug to make sure the bitfield case is considered when
> the issue is discussed by the C committee.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65471
>
> The only idea for a workaround that comes to mind is to trick GCC
> into forgetting that it's a bit-field. This hack seems to work:
>
> #define type_to_str(__x) _Generic((0)?(__x):(__x), \
>
> Martin
>
