Re: Manipulating bit fields is behaving inconsistently

2016-02-19 Thread Richard Biener 
On Thu, Feb 18, 2016 at 5:31 PM, Wink Saville  wrote:
> You've convinced me that this isn't a bug, but I assume you'd agree
> its weird at best. I tested it with clang and it works as I'd expect:
>
> $ make
> clang -x c -m64 -O3 -Wall -o test.o -c test.c
> objdump -d test.o > test.txt
> clang -m64 -O3 -Wall test.o -o test
> wink@wink-desktop:~/prgs/large_fields_are_odd
> $ ./test
> x.f0=0xfff
>   g0=0x1ffe expect 0x1ffe
> x.f1=0xf
>   g1=0x1e expect 0x1e
>
> Here is the make file:
>
> CC = clang
> CFLAGS = -m64 -O3 -Wall
>
> all: test
>
> test.o: test.c
> $(CC) -x c $(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
>
>
> Do you think gcc should change?


No, clang should.  GCC behaved this way since forever.

> On Thu, Feb 18, 2016 at 2:52 AM, Bernd Edlinger
>  wrote:
>> Hi,
>>
>>> struct fields {
>>>   long long unsigned f0:12;
>>>   long long unsigned f1:52;
>>> } __attribute__((__packed__));
>>
>> the C99 standard ISO/IEC 9899 forbids this type:
>>
>> 6.7.2.1 Structure and union specifiers
>>
>> 4 A bit-field shall have a type that is a qualified or unqualified version 
>> of _Bool, signed int,
>>unsigned int, or some other implementation-defined type.
>>
>> The C standard simply does not promote the bit-field value to any type 
>> larger than int or
>> unsigned int.
>>
>> GCC chooses to do the larger than int computations in an artificial 52-bit 
>> type, but it is a
>> non-standard extension.
>>
>> And if you compile your example with -Wall you'll see the problem:
>>
>> gcc -m32 -O3 -Wall  test.c
>> test.c: In function 'main':
>> test.c:17:21: warning: format '%llx' expects argument of type 'long long 
>> unsigned int', but argument 2 has type 'int' [-Wformat=]
>>printf("x.f0=0x%llx\n", x.f0);
>>  ^
>> test.c:19:21: warning: format '%llx' expects argument of type 'long long 
>> unsigned int', but argument 2 has type 'long long unsigned int:52' 
>> [-Wformat=]
>>printf("x.f1=0x%llx\n", x.f1);
>>  ^
>>
>> so especially the first warning is no joke:
>>
>> ./a.out
>> x.f0=0x80497b40fff
>>   g0=0x1ffe expect 0x1ffe
>> x.f1=0xf
>>   g1=0xe expect 0x1e
>>
>>
>> OTOH that is perfectly OK for C++:
>>
>> gcc -x c++ -m32 -O3 -Wall  test.c
>>
>> ./a.out
>> x.f0=0xfff
>>   g0=0x1ffe expect 0x1ffe
>> x.f1=0xf
>>   g1=0x1e expect 0x1e
>>
>>
>> Regards
>> Bernd.

Re: How to efficiently unpack 8 bytes from a 64-bit integer?

2016-02-19 Thread Richard Biener 
On Fri, Feb 19, 2016 at 7:24 AM, Phil Ruffwind  wrote:
> Hello all,
>
> I am trying to analyze the optimized results of following code.  The
> intent is to unpack a 64-bit integer into a struct containing eight
> 8-bit integers.  The optimized result was very promising at first, but
> I then discovered that whenever the unpacking function gets inlined
> into another function, the optimization no longer works.
>
> /* a struct of eight 8-bit integers */
> struct alpha {
> int8_t a;
> int8_t b;
> ...
> int8_t h;
> };
>
> struct alpha unpack(uint64_t x)
> {
> struct alpha r;
> memcpy(&r, &x, 8);
> return r;
> }
>
> struct alpha wrapper(uint64_t y)
> {
> return unpack(y);
> }
>
> The code was compiled with gcc 5.3.0 on Linux 4.4.1 with -O3 on x86-64.
>
> The `unpack` function optimizes fine.  It produces the following
> assembly as expected:
>
> mov rax, rdi
> ret
>
> Given that `wrapper` is a trivial wrapper around `unpack`, I would
> expect the same.  But in reality this is what I got from gcc:
>
> mov eax, edi
> xor ecx, ecx
> mov esi, edi
> shr ax, 8
> mov cl, dil
> shr esi, 24
> mov ch, al
> mov rax, rdi
> movzx edx, sil
> and eax, 16711680
> and rcx, -16711681
> sal rdx, 24
> movabs rsi, -4278190081
> or rcx, rax
> mov rax, rcx
> movabs rcx, -1095216660481
> and rax, rsi
> or rax, rdx
> movabs rdx, 1095216660480
> and rdx, rdi
> and rax, rcx
> movabs rcx, -280375465082881
> or rax, rdx
> movabs rdx, 280375465082880
> and rdx, rdi
> and rax, rcx
> movabs rcx, -71776119061217281
> or rax, rdx
> movabs rdx, 71776119061217280
> and rdx, rdi
> and rax, rcx
> shr rdi, 56
> or rax, rdx
> sal rdi, 56
> movabs rdx, 72057594037927935
> and rax, rdx
> or rax, rdi
> ret
>
> This seems quite strange.  Somehow the inlining process seems to have
> screwed up the potential optimizations.  Is there a someway to prevent
> this from happening short of disabling inlining?  Or perhaps there is
> a better way to write this code so that gcc would optimize more
> predictably?

It seems to be SRA "optimizing" the copy it sees in unpack ()

unpack (uint64_t x)
{
  struct alpha r;
  struct alpha D.2276;
  long unsigned int _2;

  :
  _2 = x_6(D);
  MEM[(char * {ref-all})&r] = x_6(D);
  D.2276 = r;  <--  this one
  r ={v} {CLOBBER};
  return D.2276;

when inlined into wrapper:

wrapper (uint64_t y)
{
  struct alpha D.2286;
  struct alpha r;
  struct alpha D.2279;

  :
  MEM[(char * {ref-all})&r] = y_2(D);
  D.2286 = r;
  r ={v} {CLOBBER};
  D.2279 = D.2286;
  return D.2279;

while this results in removing the redundant aggregate D.2286 it
also results in implementing the copy byte-wise (for no good reason).

Note that it cannot simply use bigger accesses as struct alpha is
only aligned to 1 byte.

Richard.


> I would appreciate any advice, thanks.
>
> Phil

Re: How to efficiently unpack 8 bytes from a 64-bit integer?

2016-02-19 Thread Phil Ruffwind 
I tried to look for a workaround for this.  It seemed that using a
union instead of memcpy was enough to convince GCC to optimize into a
single "mov".

struct alpha unpack(uint64_t x)
{
union {
struct alpha r;
uint64_t i;
} u;
u.i = x;
return u.r;
}

But that trick turned out to be short-lived.  If I wrap the wrapper
with another function:

struct alpha wrapperwrapper(uint64_t y)
{
return wrapper(y);
}

I get the same 37-line assembly generated for this function.  What's
even more strange is that if I just define two identical wrappers in
the same translation unit:

struct alpha wrapper(uint64_t y)
{
return unpack(y);
}

struct alpha wrapper2(uint64_t y)
{
return unpack(y);
}

One of them gets optimized perfectly, while the other fails, even
though the bodies of the two functions are completely identical!

Re: How to efficiently unpack 8 bytes from a 64-bit integer?

2016-02-19 Thread Richard Biener 
On Fri, Feb 19, 2016 at 10:44 AM, Phil Ruffwind  wrote:
> I tried to look for a workaround for this.  It seemed that using a
> union instead of memcpy was enough to convince GCC to optimize into a
> single "mov".
>
> struct alpha unpack(uint64_t x)
> {
> union {
> struct alpha r;
> uint64_t i;
> } u;
> u.i = x;
> return u.r;
> }
>
> But that trick turned out to be short-lived.  If I wrap the wrapper
> with another function:
>
> struct alpha wrapperwrapper(uint64_t y)
> {
> return wrapper(y);
> }
>
> I get the same 37-line assembly generated for this function.  What's
> even more strange is that if I just define two identical wrappers in
> the same translation unit:
>
> struct alpha wrapper(uint64_t y)
> {
> return unpack(y);
> }
>
> struct alpha wrapper2(uint64_t y)
> {
> return unpack(y);
> }
>
> One of them gets optimized perfectly, while the other fails, even
> though the bodies of the two functions are completely identical!

Yes, as said GCC tries to optimize the copy that results from copying
the return value aggregate to the caller return value slot.  GCC hopes
for followup optimization opportunities here but obviously there are none
in this case.

Can you please open a bugreport?  We eventually can tweak SRA
heuristics in some way here.  Note that you only get good code because
the aggregate is passed and returned in a register (and thus "alignment"
doesn't matter here) - something which is exposed too late to GCC
to make use of that fact in SRA (well, easily at least).

Richard.

Re: How to efficiently unpack 8 bytes from a 64-bit integer?

2016-02-19 Thread Phil Ruffwind 
> Can you please open a bugreport?

Done: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69871

Re: Manipulating bit fields is behaving inconsistently

2016-02-19 Thread Richard Biener 
On Fri, Feb 19, 2016 at 12:14 PM, Wink Saville  wrote:
> Can you point me to previous discussions, or maybe some search terms? I'm
> curious about the rationale for the odd behavior.

I don't remember discussions about a specific decision how to implement the GCC
extension but I remember when fixing bugs that it was pointed out how
the standard
does not say those types promote.  Of course those types don't exist in the
standard.

Richard.

>
> On Fri, Feb 19, 2016, 12:37 AM Richard Biener 
> wrote:
>>
>> On Thu, Feb 18, 2016 at 5:31 PM, Wink Saville  wrote:
>> > You've convinced me that this isn't a bug, but I assume you'd agree
>> > its weird at best. I tested it with clang and it works as I'd expect:
>> >
>> > $ make
>> > clang -x c -m64 -O3 -Wall -o test.o -c test.c
>> > objdump -d test.o > test.txt
>> > clang -m64 -O3 -Wall test.o -o test
>> > wink@wink-desktop:~/prgs/large_fields_are_odd
>> > $ ./test
>> > x.f0=0xfff
>> >   g0=0x1ffe expect 0x1ffe
>> > x.f1=0xf
>> >   g1=0x1e expect 0x1e
>> >
>> > Here is the make file:
>> >
>> > CC = clang
>> > CFLAGS = -m64 -O3 -Wall
>> >
>> > all: test
>> >
>> > test.o: test.c
>> > $(CC) -x c $(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
>> >
>> >
>> > Do you think gcc should change?
>>
>>
>> No, clang should.  GCC behaved this way since forever.
>>
>> > On Thu, Feb 18, 2016 at 2:52 AM, Bernd Edlinger
>> >  wrote:
>> >> Hi,
>> >>
>> >>> struct fields {
>> >>>   long long unsigned f0:12;
>> >>>   long long unsigned f1:52;
>> >>> } __attribute__((__packed__));
>> >>
>> >> the C99 standard ISO/IEC 9899 forbids this type:
>> >>
>> >> 6.7.2.1 Structure and union specifiers
>> >>
>> >> 4 A bit-field shall have a type that is a qualified or unqualified
>> >> version of _Bool, signed int,
>> >>unsigned int, or some other implementation-defined type.
>> >>
>> >> The C standard simply does not promote the bit-field value to any type
>> >> larger than int or
>> >> unsigned int.
>> >>
>> >> GCC chooses to do the larger than int computations in an artificial
>> >> 52-bit type, but it is a
>> >> non-standard extension.
>> >>
>> >> And if you compile your example with -Wall you'll see the problem:
>> >>
>> >> gcc -m32 -O3 -Wall  test.c
>> >> test.c: In function 'main':
>> >> test.c:17:21: warning: format '%llx' expects argument of type 'long
>> >> long unsigned int', but argument 2 has type 'int' [-Wformat=]
>> >>printf("x.f0=0x%llx\n", x.f0);
>> >>  ^
>> >> test.c:19:21: warning: format '%llx' expects argument of type 'long
>> >> long unsigned int', but argument 2 has type 'long long unsigned int:52'
>> >> [-Wformat=]
>> >>printf("x.f1=0x%llx\n", x.f1);
>> >>  ^
>> >>
>> >> so especially the first warning is no joke:
>> >>
>> >> ./a.out
>> >> x.f0=0x80497b40fff
>> >>   g0=0x1ffe expect 0x1ffe
>> >> x.f1=0xf
>> >>   g1=0xe expect 0x1e
>> >>
>> >>
>> >> OTOH that is perfectly OK for C++:
>> >>
>> >> gcc -x c++ -m32 -O3 -Wall  test.c
>> >>
>> >> ./a.out
>> >> x.f0=0xfff
>> >>   g0=0x1ffe expect 0x1ffe
>> >> x.f1=0xf
>> >>   g1=0x1e expect 0x1e
>> >>
>> >>
>> >> Regards
>> >> Bernd.

Re: Manipulating bit fields is behaving inconsistently

2016-02-19 Thread Wink Saville 
What is the process for a patch with a new option to allow a different behavior?

Re: Manipulating bit fields is behaving inconsistently

2016-02-19 Thread Richard Biener 
On Fri, Feb 19, 2016 at 12:43 PM, Wink Saville  wrote:
> What is the process for a patch with a new option to allow a different 
> behavior?

Write one (with testcases), test it and then post it here for review.

Richard.

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-19 Thread Michael Matz 
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.  "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).


Ciao,
Michael.

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-19 Thread Michael Matz 
Hi,

On Thu, 18 Feb 2016, H.J. Lu 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?
> 
> I think we want to cover
> 
> struct
> {
>   unsigned int : 8;
> };
> 
> but not
> 
> struct
> {
>   unsigned int  i :8;
> };
> 
> " trivially copyable" applies to both.

Correct, but I'm not suggesting to use only the trivially copyable 
definition, I want to have it added as condition for not requiring a 
register or memory slot.  I.e. "an object of empty type that's trivially 
copyable".


Ciao,
Michael.

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-19 Thread H.J. Lu 
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();}
> };


Does "a type where it and all of its subobjects  (recursively) are of
class, structure, union, or array type." exclude the above?  If not,
we need better
wording.  We want to include static member functions and exclude
non-static member functions.

> would be an empty type, and that's not what we want.  "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).
>
>
> Ciao,
> Michael.



-- 
H.J.

Re: Manipulating bit fields is behaving inconsistently

2016-02-19 Thread Joseph Myers 
See the references I gave in 
.

-- 
Joseph S. Myers
jos...@codesourcery.com

How to use _Generic with bit-fields

2016-02-19 Thread Wink Saville 
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;
}

And the Makefile is:

$ cat Makefile
CC = gcc
CFLAGS = -Wall -std=c11

all: test

test.o: test.c
$(CC) $(CFLAGS) -o test.o -c test.c

test: test.o
$(CC) $(CFLAGS) test.o -o test

clean:
rm -f test test.o test.txt


My type_to_str macro seems correct, as all is well if I comment out the last
printf:

$ 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;
}


It then compiles and runs successfully:

$ make
gcc -Wall -std=c11 -o test.o -c test.c
gcc -Wall -std=c11 test.o -o test
$ ./test
255
unsigned char
3


How do I create a type association for a bit field?

Re: Manipulating bit fields is behaving inconsistently

2016-02-19 Thread Wink Saville 
The two links in msg00156.html point to single emails and the
formatting is odd, such as in 13560.txt:

  i =3D =5FGeneric(st.bf,

Is there a way to look at the actual email thread using a browser or
some other means?


On Fri, Feb 19, 2016 at 9:30 AM, Joseph Myers  wrote:
> See the references I gave in
> .
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-19 Thread Matthijs van Duin 
On 19 February 2016 at 16:27, H.J. Lu  wrote:
> We want to include static member functions and exclude non-static member
> functions.

There's no reason to disallow non-static member functions in general; they
have no impact on being trivially copyable or not, only the presence of a
non-trivial copy constructor or destructor does.

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-19 Thread Matthijs van Duin 
On 19 February 2016 at 14:35, Michael Matz  wrote:
> struct S {
>   S() {something();}
> };
>
> would be an empty type, and that's not what we want.

Why not? The default constructor is never invoked as part of passing
such an object around. Its copy constructor is a nop and requires no
reference to the original object.

Matthijs van Duin

Re: Need suggestion about bug 68425

2016-02-19 Thread David Malcolm 
On Thu, 2016-02-18 at 14:28 +, Manuel López-Ibáñez wrote:
> On 18/02/16 11:40, Prasad Ghangal wrote:
> > Wouldn't it be nice instead of multiple warnings if gcc gives
> > single
> > warning like :
> > 
> > 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! Perhaps even (now that we have ranges!):
> 
> 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).

> But even without ranges, your suggestion would be a great
> improvement.

Agreed.

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-19 Thread H.J. Lu 
On Fri, Feb 19, 2016 at 11:03 AM, Matthijs van Duin
 wrote:
> On 19 February 2016 at 14:35, Michael Matz  wrote:
>> struct S {
>>   S() {something();}
>> };
>>
>> would be an empty type, and that's not what we want.
>
> Why not? The default constructor is never invoked as part of passing
> such an object around. Its copy constructor is a nop and requires no
> reference to the original object.
>

Do you have a precise wording to describe it?

-- 
H.J.

Re: Need suggestion about bug 68425

2016-02-19 Thread Manuel López-Ibáñez 
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.

Re: gnu-gabi group

2016-02-19 Thread H.J. Lu 
On Mon, Feb 15, 2016 at 10:20 AM, Jose E. Marchesi
 wrote:
>
> > Great. I'll ask overseers to create a mailinglist. [...]
>
> Done [1] [2].  If y'all need a wiki too, just ask.
>
> [1] gnu-g...@sourceware.org
> [2] https://sourceware.org/ml/gnu-gabi/
>
> The link to the "GNU GABI project web page" in
> https://sourceware.org/ml/gnu-gabi is broken.

How do I subscribe gnu-abi mailing list?  The project page just
points to the mailing list archive.  There is no option to subscribe
it.

-- 
H.J.

Re: gnu-gabi group

2016-02-19 Thread Markus Trippelsdorf 
On 2016.02.19 at 12:57 -0800, H.J. Lu wrote:
> On Mon, Feb 15, 2016 at 10:20 AM, Jose E. Marchesi
>  wrote:
> >
> > > Great. I'll ask overseers to create a mailinglist. [...]
> >
> > Done [1] [2].  If y'all need a wiki too, just ask.
> >
> > [1] gnu-g...@sourceware.org
> > [2] https://sourceware.org/ml/gnu-gabi/
> >
> > The link to the "GNU GABI project web page" in
> > https://sourceware.org/ml/gnu-gabi is broken.
> 
> How do I subscribe gnu-abi mailing list?  The project page just
> points to the mailing list archive.  There is no option to subscribe
> it.

https://sourceware.org/lists.html#ml-requestor

-- 
Markus

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-19 Thread Richard Smith 
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).
>
>
> Ciao,
> Michael.

Re: gnu-gabi group

2016-02-19 Thread Mark Wielaard 
On Fri, Feb 19, 2016 at 12:57:34PM -0800, H.J. Lu wrote:
> How do I subscribe gnu-abi mailing list?  The project page just
> points to the mailing list archive.  There is no option to subscribe
> it.

To subscribe sent email to gnu-abi-subscr...@sourceware.org
Or use the subscribe form at https://sourceware.org/lists.html#ml-requestor

Note I set the Reply-To: gnu-g...@sourceware.org so we don't keep
spamming all the GNU toolchain project lists. We should get at least
one representative from each GNU toolchain project on the gnu-gabi
list to make sure we have a process that makes sure we only document
abi that is actually supportable.

Thanks,

Mark

Re: How to use _Generic with bit-fields

2016-02-19 Thread Martin Sebor 

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

Re: gnu-gabi group

2016-02-19 Thread H.J. Lu 
On Fri, Feb 19, 2016 at 1:00 PM, Markus Trippelsdorf
 wrote:
> On 2016.02.19 at 12:57 -0800, H.J. Lu wrote:
>> On Mon, Feb 15, 2016 at 10:20 AM, Jose E. Marchesi
>>  wrote:
>> >
>> > > Great. I'll ask overseers to create a mailinglist. [...]
>> >
>> > Done [1] [2].  If y'all need a wiki too, just ask.
>> >
>> > [1] gnu-g...@sourceware.org
>> > [2] https://sourceware.org/ml/gnu-gabi/
>> >
>> > The link to the "GNU GABI project web page" in
>> > https://sourceware.org/ml/gnu-gabi is broken.
>>
>> How do I subscribe gnu-abi mailing list?  The project page just
>> points to the mailing list archive.  There is no option to subscribe
>> it.
>
> https://sourceware.org/lists.html#ml-requestor

Doesn't work:

Hi. This is the qmail-send program at sourceware.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

:
Sorry, no mailbox here by that name. (#5.1.1)

--- Below this line is a copy of the message.


-- 
H.J.

Re: gnu-gabi group

2016-02-19 Thread H.J. Lu 
On Fri, Feb 19, 2016 at 1:16 PM, Mark Wielaard  wrote:
> On Fri, Feb 19, 2016 at 12:57:34PM -0800, H.J. Lu wrote:
>> How do I subscribe gnu-abi mailing list?  The project page just
>> points to the mailing list archive.  There is no option to subscribe
>> it.
>
> To subscribe sent email to gnu-abi-subscr...@sourceware.org
> Or use the subscribe form at https://sourceware.org/lists.html#ml-requestor

Have you tried?  It doesn't works for me.

Hi. This is the qmail-send program at sourceware.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

:
Sorry, no mailbox here by that name. (#5.1.1)

--- Below this line is a copy of the message.

Return-Path: 
Received: (qmail 45923 invoked by uid 89); 19 Feb 2016 21:51:27 -
Authentication-Results: sourceware.org; auth=none
X-Virus-Checked: by ClamAV 0.99 on sourceware.org
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.4 required=5.0
tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS
autolearn=ham version=3.3.2 spammy=
X-Spam-Status: No, score=-2.4 required=5.0
tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS
autolearn=ham version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org
X-Spam-Level:
X-HELO: mail-qg0-f51.google.com
Received: from mail-qg0-f51.google.com (HELO mail-qg0-f51.google.com)
(209.85.192.51)
 by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with
(AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 19 Feb 2016 21:51:26 +
Received: by mail-qg0-f51.google.com with SMTP id y89so72346223qge.2
for ; Fri, 19 Feb 2016
13:51:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=eZC3LtZL7BXxfyIFtklb/yLCrPguGar0iu8XP/9UuyU=;
b=se5z8Q6PBBZxlt9AGx5aQY6dZhG0ksLTMm3tPhsKq9RFsP6r9bpoR9sLJbv+BnMoAu
 M8hD6qclE47HF1x54w23yGrx7CpbZMUdXiwa+9n/Q6ZQIQRgsbGrWrd4QohsGGyZaCrz
 t53H9J4NykEZyNwNCGgn5+jhW80KC2QKFYcDmCUdsA+59OjF+u2VavrVC+QUmSeoD9S1
 0ZNiR9grsoX7cuHi2H2LLefY1mgki7dI/aQMC/mReqEIfJVU24CXXLXvUSLkF/jqLlQS
 vmK+uFMr1S4L4L8aFoTZmxQUhEv4U7dGVyc9HduLZsTygt8/EyS4Sgzp8O5w4RuihkXK
 FxIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:date:message-id:subject:from:to
 :content-type;
bh=eZC3LtZL7BXxfyIFtklb/yLCrPguGar0iu8XP/9UuyU=;
b=HwhJg/b727DM0KPtKbwcgRM8tlamj8wWLwxxc6fV9Z4bUdSKn/RCaciMaCar4f6FFl
 wr+vNsi8FP+2MbubOnpjrVvLIlwlbPPoTi23BP/vKzqJgkJ/WivaY4Pwc7wOhpOp7WmG
 W2UmxFNCX7YGEzPx3XVxXDygarKYGtxCM7VO2l0VOka1ryex0K/w1ElOeqO7QBVD3ljH
 07qSDt5Aaije9ZuuxOmkPOAOUdGNmmNB66AQ6MTCl6pI0WpHM2EWp+NJ/4xBTJ2APOZ5
 3GXZrHo89Hcl0OtS2iKkFDl0uN4+om+YSkbE/UOMfHp1sX2vU8K6FyWUQJd1avB3BRo4
 9wFA==
X-Gm-Message-State:
AG10YOSm8MzPqGT7Hia24HueQfxd0gM5xkxsrG+f6o1b7AVRiZxgGE155J9XNhmo8PT9XiJyJv3Ur0GuNQ8wkQ==
MIME-Version: 1.0
X-Received: by 10.140.19.52 with SMTP id 49mr19058993qgg.103.1455918684746;
 Fri, 19 Feb 2016 13:51:24 -0800 (PST)
Received: by 10.55.15.216 with HTTP; Fri, 19 Feb 2016 13:51:24 -0800 (PST)
Date: Fri, 19 Feb 2016 13:51:24 -0800
Message-ID: 
Subject: Subscribe
From: "H.J. Lu" 
To: gnu-abi-subscr...@sourceware.org
Content-Type: text/plain; charset=UTF-8

-- 
H.J.

Re: gnu-gabi group

2016-02-19 Thread Ian Lance Taylor 
On Fri, Feb 19, 2016 at 1:16 PM, Mark Wielaard  wrote:
> On Fri, Feb 19, 2016 at 12:57:34PM -0800, H.J. Lu wrote:
>> How do I subscribe gnu-abi mailing list?  The project page just
>> points to the mailing list archive.  There is no option to subscribe
>> it.
>
> To subscribe sent email to gnu-abi-subscr...@sourceware.org

It's actually gnu-gabi.  Send mail to gnu-gabi-subscr...@sourceware.org.

Ian

Re: How to use _Generic with bit-fields

2016-02-19 Thread Joseph Myers 
On Fri, 19 Feb 2016, Wink Saville wrote:

> And I've tried to use _Generic to print the type of a bit field but
> the compiler fails with:

Indeed, bit-field types cannot match any type name, only default.  The 
only conversions applied to the controlling expression are those involved 
in lvalue to rvalue conversion (at least, that's what's currently 
implemented, and is the current direction on DR#481).  In particular, the 
integer promotions (which would convert this bit-field to int) are not 
applied.

You can of course use unary + (or various other constructs depending on 
the set of possible types) to cause some promotions.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Manipulating bit fields is behaving inconsistently

2016-02-19 Thread Joseph Myers 
On Fri, 19 Feb 2016, Wink Saville wrote:

> The two links in msg00156.html point to single emails and the
> formatting is odd, such as in 13560.txt:
> 
>   i =3D =5FGeneric(st.bf,
> 
> Is there a way to look at the actual email thread using a browser or
> some other means?

I'm not aware of any WG14 reflector archive other than that one providing 
the raw MIME form of the emails at URLs based on the individual message 
numbers as they were distributed by the reflector.  You'll need to keep 
adding 1 to the number to get successive messages to the reflector.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [isocpp-parallel] Proposal for new memory_order_consume definition

2016-02-19 Thread Tony V E 
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 [[]] 



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