Re: increase alignment of global structs in increase_alignment pass

[Prathamesh Kulkarni]

On 23 February 2016 at 22:11, Marek Polacek  wrote:
> On Tue, Feb 23, 2016 at 09:49:37PM +0530, Prathamesh Kulkarni wrote:
>
>> diff --git a/gcc/tree-vectorizer.c b/gcc/tree-vectorizer.c
>> index 2b25b45..a6af535 100644
>> --- a/gcc/tree-vectorizer.c
>> +++ b/gcc/tree-vectorizer.c
>> @@ -794,6 +794,75 @@ make_pass_slp_vectorize (gcc::context *ctxt)
>>   This should involve global alignment analysis and in the future also
>>   array padding.  */
>>
>> +static unsigned get_vec_alignment_for_decl (tree);
>
> Why the forward decl?  Better to topologically sort the functions.
The functions get_vec_alignment_for_{record,array}_decl and
get_vec_alignment_for_decl()
call each other mutually so I suppose I would need to have a forward decl ?
>
> Also, the functions are missing comments.
Thanks, done in this patch.

Thanks,
Prathamesh
>
>> +static unsigned
>> +get_vec_alignment_for_array_decl (tree array_decl)
>> +{
>> +  tree type = TREE_TYPE (array_decl);
>> +  gcc_assert (TREE_CODE (type) == ARRAY_TYPE);
>> +
>> +  tree vectype = get_vectype_for_scalar_type (strip_array_types (type));
>> +  return (vectype) ? TYPE_ALIGN (vectype) : 0;
>> +}
>> +
>> +static unsigned
>> +get_vec_alignment_for_record_decl (tree record_decl)
>> +{
>> +  tree type = TREE_TYPE (record_decl);
>> +  gcc_assert (TREE_CODE (type) == RECORD_TYPE);
>> +  unsigned max_align = 0, alignment;
>> +  HOST_WIDE_INT offset;
>> +
>> +  if (DECL_ARTIFICIAL (record_decl) || TYPE_PACKED (type))
>> +return 0;
>> +
>> +  for (tree field = first_field (type);
>> +   field != NULL_TREE;
>> +   field = DECL_CHAIN (field))
>> +{
>> +  /* C++FE puts node "._0" of code TYPE_DECL. skip that.  */
>> +  if (TREE_CODE (field) != FIELD_DECL)
>> + continue;
>> +
>> +  offset = int_byte_position (field);
>> +  alignment = get_vec_alignment_for_decl (field);
>> +  if (alignment
>> +   && (offset % (alignment / BITS_PER_UNIT) == 0)
>> +   && (alignment > max_align))
>> + max_align = alignment;
>> +}
>> +
>> +  return max_align;
>> +}
>> +
>> +static unsigned
>> +get_vec_alignment_for_decl (tree decl)
>> +{
>> +  if (decl == NULL_TREE)
>> +return 0;
>> +
>> +  gcc_assert (DECL_P (decl));
>> +
>> +  static unsigned alignment = 0;
>> +  tree type = TREE_TYPE (decl);
>> +
>> +  switch (TREE_CODE (type))
>> +{
>> +  case ARRAY_TYPE:
>> + alignment = get_vec_alignment_for_array_decl (decl);
>> + break;
>> +  case RECORD_TYPE:
>> + alignment = get_vec_alignment_for_record_decl (decl);
>> + break;
>> +  default:
>> + alignment = 0;
>> + break;
>> +}
>> +
>> +  return (alignment > DECL_ALIGN (decl)) ? alignment : 0;
>> +}
>> +
>>  static unsigned int
>>  increase_alignment (void)
>>  {
>> @@ -804,23 +873,14 @@ increase_alignment (void)
>>/* Increase the alignment of all global arrays for vectorization.  */
>>FOR_EACH_DEFINED_VARIABLE (vnode)
>>  {
>> -  tree vectype, decl = vnode->decl;
>> -  tree t;
>> +  tree decl = vnode->decl;
>>unsigned int alignment;
>>
>> -  t = TREE_TYPE (decl);
>> -  if (TREE_CODE (t) != ARRAY_TYPE)
>> -continue;
>> -  vectype = get_vectype_for_scalar_type (strip_array_types (t));
>> -  if (!vectype)
>> -continue;
>> -  alignment = TYPE_ALIGN (vectype);
>> -  if (DECL_ALIGN (decl) >= alignment)
>> -continue;
>> +  alignment = get_vec_alignment_for_decl (decl);
>>
>> -  if (vect_can_force_dr_alignment_p (decl, alignment))
>> +  if (alignment && vect_can_force_dr_alignment_p (decl, alignment))
>>  {
>> -   vnode->increase_alignment (TYPE_ALIGN (vectype));
>> +   vnode->increase_alignment (alignment);
>>dump_printf (MSG_NOTE, "Increasing alignment of decl: ");
>>dump_generic_expr (MSG_NOTE, TDF_SLIM, decl);
>>dump_printf (MSG_NOTE, "\n");
>
>
> Marek
diff --git a/gcc/tree-vectorizer.c b/gcc/tree-vectorizer.c
index 2b25b45..d490287 100644
--- a/gcc/tree-vectorizer.c
+++ b/gcc/tree-vectorizer.c
@@ -794,6 +794,87 @@ make_pass_slp_vectorize (gcc::context *ctxt)
  This should involve global alignment analysis and in the future also
  array padding.  */
 
+static unsigned get_vec_alignment_for_decl (tree);
+
+/* Return alignment of array's vector type corresponding to scalar type.
+   0 if no vector type exists.  */
+static unsigned
+get_vec_alignment_for_array_decl (tree array_decl)
+{
+  tree type = TREE_TYPE (array_decl);
+  gcc_assert (TREE_CODE (type) == ARRAY_TYPE);
+
+  tree vectype = get_vectype_for_scalar_type (strip_array_types (type));
+  return (vectype) ? TYPE_ALIGN (vectype) : 0;
+}
+
+/* Return alignment of field having maximum alignment of vector type
+   corresponding to it's scalar type. For now, we only consider fields whose
+   offset is a multiple of it's vector alignment.
+   0 if no suitable field is found.  */
+static unsigned
+get_vec_alignment_for_record_decl (tree reco

Re: Order Conf. 3360069

[Mohamed Mediouni]

We thank you for spreading malware via Office VBA macros.

Sincerly,

Le 24/02/2016 12:07, Abigail Jones a écrit :
   
Please see attached

Re: Importance of transformations that turn data dependencies into control dependencies?

[Richard Biener]

On Tue, Feb 23, 2016 at 8:38 PM, Torvald Riegel  wrote:
> I'd like to know, based on the GCC experience, how important we consider
> optimizations that may turn data dependencies of pointers into control
> dependencies.  I'm thinking about all optimizations or transformations
> that guess that a pointer might have a specific value, and then create
> (specialized) code that assumes this value that is only executed if the
> pointer actually has this value.  For example:
>
> int d[2] = {23, compute_something()};
>
> int compute(int v) {
>   if (likely(v == 23)) return 23;
>   else ;
> }
>
> int bar() {
>   int *p = ptr.load(memory_order_consume);
>   size_t reveal_that_p_is_in_d = p - d[0];
>   return compute(*p);
> }
>
> Could be transformed to (after inlining compute(), and specializing for
> the likely path):
>
> int bar() {
>   int *p = ptr.load(memory_order_consume);
>   if (p == d) return 23;
>   else ;
> }

Note that if a user writes

  if (p == d)
   {
 ... do lots of stuff via p ...
   }

GCC might rewrite accesses to p as accesses to d and thus expose
those opportunities.  Is that a transform that isn't valid then or is
the code written by the user (establishing the equivalency) to blame?

There's a PR where this kind of equivalencies lead to unexpected (wrong?)
points-to results for example.

> Other potential examples that come to mind are de-virtualization, or
> feedback-directed optimizations that has observed at runtime that a
> certain pointer is likely to be always equal to some other pointer (eg.,
> if p is almost always d[0], and specializing for that).

That's the cases that are quite important in practice.

> Also, it would be interesting to me to know how often we may turn data
> dependencies into control dependencies in cases where this doesn't
> affect performance significantly.

I suppose we try to avoid that but can we ever know for sure?  Like
speculative devirtualization does this (with the intent that it _does_ matter,
of course).

I suppose establishing non-dependence isn't an issue, like with the
vectorizer adding runtime dependence checks and applying versioning
to get a vectorized and a not vectorized loop (in case there are dependences)?

> The background for this question is Paul McKenney's recently updated
> proposal for a different memory_order_consume specification:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0190r0.pdf
>
> In a nutshell, this requires a compiler to either prove that a pointer
> value is not carrying a dependency (simplified, its value somehow
> originates from a memory_order_consume load), or it has to
> conservatively assume that it does; if it does, the compiler must not
> turn data dependencies into control dependencies in generated code.
> (The data dependencies, in contrast to control dependencies, enforce
> memory ordering on archs such as Power and ARM; these orderings than
> allow for not having to use an acquire HW barrier in the generated
> code.)
>
> Given that such a proof will likely be hard for a compiler (dependency
> chains propagate through assignments to variables on the heap and stack,
> chains are not marked in the code, and points-to analysis can be hard),
> a compiler faces a trade-off between either:
> (1) trying to support this memory_order_consume specification and likely
> disallowing all transformations that change data dependencies into
> control dependencies, or
> (2) not support the proposal by simply emitting memory_order_acquire
> code, but get no new constraints on transformations in return (ie, what
> we do for memory_order_consume today).
>
> A compiler could let users make this choice, but this will be hard for
> users too, and the compiler would still have to pick a default.
>
> Therefore, it would be good to know how important such transformations
> or optimizations are in practice.  If they are, it either means somewhat
> slower code everywhere (or at least having to change much in todays
> compilers), or not supporting the new memory_order_consume (at least not
> in the default setting of the compiler).

IMHO all the memory order semantics are too complicated already so what's
the reason to complicate it even more...?  See for example how our alias
analysis (which is supposed to also honor barriers) gives up completely
on atomics.

Richard.

> Thanks for any opinions.
>

Re: Need suggestion about bug 68425

[Prasad Ghangal]

Thanks Prathamesh and Joseph for your suggestions.

Here is my updated patch :

for test cases:

const int array[5] = {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};
const int array4[3] = {1, 2, 3, 6, 89, 193};
const int array5[1] = {1, 2, 3, 6, 89, 193};
const int array6[3] = {1, 2, 3, 6, 89, 193;
const int array7[5] = {1, 2, 3, 6, 89, 193}
const int array8[5] = {1, 2, 3, 6, 89, 193



It gives:

68425.c: In function ‘main’:
68425.c:4:37: warning: excess elements in array initializer (4
elements, expected 3)
 const int array1[3] = {1, 2, 3, 6};
   ^
68425.c:4:37: note: (near initialization for ‘array1’)
68425.c:5:40: warning: excess elements in array initializer (5
elements, expected 4)
 const int array2[4] = {1, 2, 3, 6, 89};
   ^~
68425.c:5:40: note: (near initialization for ‘array2’)
68425.c:6:44: warning: excess elements in array initializer (6
elements, expected 5)
 const int array3[5] = {1, 2, 3, 6, 89, 193};
 ^~~
68425.c:6:44: note: (near initialization for ‘array3’)
68425.c:7:37: warning: excess elements in array initializer (6
elements, expected 3)
 const int array4[3] = {1, 2, 3, 6, 89, 193};
   ^
68425.c:7:37: note: (near initialization for ‘array4’)
68425.c:8:31: warning: excess elements in array initializer (6
elements, expected 1)
 const int array5[1] = {1, 2, 3, 6, 89, 193};
   ^
68425.c:8:31: note: (near initialization for ‘array5’)
68425.c:9:37: warning: excess elements in array initializer (6
elements, expected 3)
 const int array6[3] = {1, 2, 3, 6, 89, 193;
   ^
68425.c:9:37: note: (near initialization for ‘array6’)
68425.c:9:47: error: expected ‘}’ before ‘;’ token
 const int array6[3] = {1, 2, 3, 6, 89, 193;
   ^
68425.c:14:1: error: expected declaration or statement at end of input
 }
 ^


Any suggestions?


-- 
Thanks and Regards,
Prasad Ghangal
Index: gcc/c/c-parser.c
===
diff --git a/trunk/gcc/c/c-parser.c b/trunk/gcc/c/c-parser.c
--- a/trunk/gcc/c/c-parser.c	(revision 233263)
+++ b/trunk/gcc/c/c-parser.c	(working copy)
@@ -1264,6 +1264,7 @@
   NUM_PRECS
 };
 
+extern void pedwarn_init (location_t, int, const char *, ...);
 static void c_parser_external_declaration (c_parser *);
 static void c_parser_asm_definition (c_parser *);
 static void c_parser_declaration_or_fndef (c_parser *, bool, bool, bool,
@@ -1294,9 +1295,11 @@
 static struct c_type_name *c_parser_type_name (c_parser *);
 static struct c_expr c_parser_initializer (c_parser *);
 static struct c_expr c_parser_braced_init (c_parser *, tree, bool);
-static void c_parser_initelt (c_parser *, struct obstack *);
+static void c_parser_initelt (c_parser *, struct obstack *, bool *, location_t *, 
+			  HOST_WIDE_INT *, HOST_WIDE_INT *);
 static void c_parser_initval (c_parser *, struct c_expr *,
-			  struct obstack *);
+			  struct obstack *, bool *, location_t *, HOST_WIDE_INT *, 
+			  HOST_WIDE_INT *);
 static tree c_parser_compound_statement (c_parser *);
 static void c_parser_compound_statement_nostart (c_parser *);
 static void c_parser_label (c_parser *);
@@ -4347,9 +4350,14 @@
 {
   /* Parse a non-empty initializer list, possibly with a trailing
 	 comma.  */
+  bool to_warn = false;
+  location_t warn_loc = 0;
+  HOST_WIDE_INT warn_extra_elements = 0;
+  HOST_WIDE_INT warn_expected_elements = 0;
   while (true)
 	{
-	  c_parser_initelt (parser, &braced_init_obstack);
+	  c_parser_initelt (parser, &braced_init_obstack, &to_warn,
+			&warn_loc, &warn_extra_elements, &warn_expected_elements);
 	  if (parser->error)
 	break;
 	  if (c_parser_next_token_is (parser, CPP_COMMA))
@@ -4359,6 +4367,13 @@
 	  if (c_parser_next_token_is (parser, CPP_CLOSE_BRACE))
 	break;
 	}
+  if(to_warn == true && !(parser->error))
+	{
+	pedwarn_init (warn_loc, 0, "excess elements in array initializer "
+			"(%wu elements, expected %wu)",
+			warn_expected_elements + warn_extra_elements,
+			warn_expected_elements);
+	}
 }
   c_token *next_tok = c_parser_peek_token (parser);
   if (next_tok->type != CPP_CLOSE_BRACE)
@@ -4382,7 +4397,9 @@
 /* Parse a nested initializer, including designators.  */
 
 static void
-c_parser_initelt (c_parser *parser, struct obstack * braced_init_obstack)
+c_parser_initelt (c_parser *parser, struct obstack * braced_init_obstack,
+		  bool *to_warn, location_t *warn_loc, HOST_WIDE_INT *warn_extra_elements, 
+		  HOST_WIDE_INT *warn_expected_elements)
 {
   /* Parse any design

[WWWDocs] Deprecate support for non-thumb ARM devices

[Richard Earnshaw (lists)]

After discussion with the ARM port maintainers we have decided that now
is probably the right time to deprecate support for versions of the ARM
Architecture prior to ARMv4t.  This will allow us to clean up some of
the code base going forwards by being able to assume:
- Presence of half-word data accesses
- Presence of Thumb and therefore of interworking instructions.

This patch records the status change in the GCC-6 release notes.

I propose to commit this patch later this week.

R.
Index: htdocs/gcc-6/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v
retrieving revision 1.61
diff -u -r1.61 changes.html
--- htdocs/gcc-6/changes.html   19 Feb 2016 05:00:54 -  1.61
+++ htdocs/gcc-6/changes.html   19 Feb 2016 14:47:31 -
@@ -340,7 +340,14 @@
 ARM

  
-   The arm port now supports target attributes and pragmas.  Please
+   Support for revisions of the ARM architecture prior to ARMv4t has
+   been deprecated and will be removed in a future GCC release.
+   This affects ARM6, ARM7 (but not ARM7TDMI), ARM8, StrongARM, and
+   Faraday fa526 and fa626 devices, which do not have support for
+   the Thumb execution state.
+ 
+ 
+   The ARM port now supports target attributes and pragmas.  Please
refer to the https://gcc.gnu.org/onlinedocs/gcc/ARM-Function-Attributes.html#ARM-Function-Attributes";>
documentation for details of available attributes and
pragmas as well as usage instructions.

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

[Joseph Myers]

On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote:

> After discussion with the ARM port maintainers we have decided that now
> is probably the right time to deprecate support for versions of the ARM
> Architecture prior to ARMv4t.  This will allow us to clean up some of

Should this include -march=armv5 and -march=armv5e (the theoretical 
no-Thumb versions of v5, which may never have had any corresponding 
processors)?

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

who owns stack args?

[DJ Delorie]

Consider this example (derived from gcc.c-torture/execute/920726-1.c):

  extern int a(int a, int b, int c, int d, int e, int f, const char *s1, const 
char *s2) __attribute__((pure));

  int
  foo()
  {
if (a(0,0,0,0,0,0,"abc","def") || a(0,0,0,0,0,0,"abc","ghi"))
  return 0;
return 1;
  }

On rl78-elf I'm seeing a bug that only happens if a() is declared
"pure".  When the bug triggers, the address of "abc" in the second
call is *not* written to the stack.  Instead, the move is deleted by
DCE in postreload.  It's not deleted if you remove the "pure".  The
bug was exposed when strcmp() became able to increment incoming stack
arguments in-place, instead of copying them to registers.

The example was intended to reproduce the bug on intel or arm, but it
doesn't.  If there's an obvious fix for this, I'm all ears, but...

The real question is: are stack arguments call-clobbered or
call-preserved?  Does the answer depend on the "pure" attribute?

Re: How to use _Generic with bit-fields

[Martin Sebor]

$ cat z.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc -Wall -Wextra -Wpedantic -xc z.c
struct S { unsigned i: 31; } s;
int i = _Generic (s.i, unsigned: 1);
z.c:2:19: error: ‘_Generic’ selector of type ‘unsigned int:31’ is not
compatible with any association
  int i = _Generic (s.i, unsigned: 1);
^


That can be avoided simply by using unary + in the controlling expression
of _Generic (just as using unary + will avoid an error from sizeof, if you
want to be able to apply that to expressions that might be bit-fields) -
or any of the other techniques for achieving promotions of selected types.


Unfortunately, the + n trick is far too limited to be generally
usable.  Since GCC allows bit-fields of other integers types
besides those described by the standard (e.g., long long), the
plus expression would have to be converted to the widest possible
type (e.g., by (x + 0LL)) which would defeat the purpose of
_Generic.  The trick of course work at all for type-generic
macro intended to also accept non- scalar arguments.



You can't use bit-fields with sizeof, or with unary &, or in GNU C with
typeof.  I think extending this constraint to _Generic - meaning you need
to use a trick such as unary + when a bit-field might occur there - is
consistent with the peculiar position of bit-fields in C as not quite
normal objects or types (and consistent with how _Generic is intended for
certain limited kinds of overloading such as ,


GCC's handling of bit-fields in __typeof__  is also a problem
and causes bugs in .  For example, the following is
rejected by GCC (with not just one but 42 errors) as a result:

  struct S { unsigned b: 31; } s;
  carg (s.b);

even though this is accepted:

  _Complex double cd = s.b;


not for
arbitrarily expressive logic on types, cf. the rejection of overloading on
qualifiers).  If someone uses e.g. unsigned int:8 as the controlling
expression of _Generic, it's hardly clear whether a selection for unsigned
char (a type with the same set of values), unsigned int (the declared type
ignoring width) or int (the type resulting from the integer promotions)
would be the most useful selection.


If it isn't clear it should be brought up in WG14 and clarified.
It's clear enough in C++ for bit-fields to be used as arguments
to overloaded functions or function templates.  I can't imagine
a good reason for not nailing it down in C.  Especially since
existing practice shows that it can be made to work in
unsurprising ways (all 5 GCC-compatible compilers that I've
tested accept bit-fields in __typeof__ and, those that support
it, also in _Generic).

Martin

Re: who owns stack args?

[Alexander Monakov]

On Wed, 24 Feb 2016, DJ Delorie wrote:
> The real question is: are stack arguments call-clobbered or
> call-preserved?  Does the answer depend on the "pure" attribute?

Stack area holding stack arguments should belong to the callee for tail-calls
to work (the callee will trash that area when laying out arguments for the
tail call; thanks to Rich Felker for pointing that out to me).

Thus it cannot depend on attribute-pure.

Alexander

Re: who owns stack args?

[Jeff Law]

On 02/24/2016 01:42 PM, Alexander Monakov wrote:

On Wed, 24 Feb 2016, DJ Delorie wrote:

The real question is: are stack arguments call-clobbered or
call-preserved?  Does the answer depend on the "pure" attribute?


Stack area holding stack arguments should belong to the callee for tail-calls
to work (the callee will trash that area when laying out arguments for the
tail call; thanks to Rich Felker for pointing that out to me).

Thus it cannot depend on attribute-pure.
Which would imply that the outgoing argument stack slots must always be 
considered clobbered by a call.


FWIW, I'm fine with that interpretation ;-)

jeff

Re:VPN Users

[Allan Webber]

Hi,

A quick note to see if you would be interested in a discussion about RSA List 
and the benefits it can bring your organization for your Marketing Initiatives.

Every contact will include: Company Name, Web Address, Contact Name, Verified 
Email, Job Title, Application Type, Complete Mailing Address, Phone Number, FAX 
Number, Total Employees, SIC Code, and Industry details.

Few Technology Specific Lists:-  Citrix, VMware, NetApp, Desktop 
Virtualization, Cloud Computing, IT Management Companies, Salesforce, 
Xendesktop, XenApp, XenClient, NetScaler, GoToAssist, XenServer, RSA and More.

Please let me know your target criteria so that we can provide you the counts 
and samples.

Look forward to hearing from you.

Regards,
Allan Webber
Marketing Executive

If you do not wish to receive further emails kindly reply with "Leave Out"


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: How to use _Generic with bit-fields

[Joseph Myers]

On Wed, 24 Feb 2016, Martin Sebor wrote:

> > That can be avoided simply by using unary + in the controlling expression
> > of _Generic (just as using unary + will avoid an error from sizeof, if you
> > want to be able to apply that to expressions that might be bit-fields) -
> > or any of the other techniques for achieving promotions of selected types.
> 
> Unfortunately, the + n trick is far too limited to be generally
> usable.  Since GCC allows bit-fields of other integers types
> besides those described by the standard (e.g., long long), the
> plus expression would have to be converted to the widest possible
> type (e.g., by (x + 0LL)) which would defeat the purpose of
> _Generic.  The trick of course work at all for type-generic
> macro intended to also accept non- scalar arguments.

There are lots of variants of the trick (including the conditional 
expression one), depending on which types you care about distinguishing 
and which are valid arguments to the macro.  If you want, you can even 
distinguish each bit-field width wider than int individually using typeof, 
via writing expressions with typeof to determine the width of the type.

I suspect many attempts to use _Generic with non-arithmetic types would 
run into usability problems in practice because every expression in the 
generic association list must still pass the Constraints whatever the type 
of the controlling expression - so you can select a function name based on 
that type, but putting more complicated expressions directly inside 
_Generic would be problematic in many cases if a wide range of types is to 
be allowed.

There is a basic question: is _Generic supposed to be arbitrarily 
expressive, or is it meant to cover cases like ?  The answer in 
the context of questions about qualifiers and array-to-pointer decay was 
that it is meant to cover cases like , not to be arbitrarily 
expressive for hypothetical cases.  Maximal expressiveness would allow 
distinguishing all bit-field widths, but that would fall down on 
usability.

Integer types narrower than int are effectively second-class entities in 
C; you can't write constants of those types, for example, and they get 
promoted before used in arithmetic or being passed in variable arguments; 
while you *can* select on them with _Generic, the utility of doing so may 
be limited.  Bit-fields are effectively third-class entities, and 
bit-fields with implementation-defined declared types other than int or 
signed int or unsigned int are fourth-class (not required by the standard 
at all, and have their own problems of specification - and the final 
choice for DR#315 was to leave pretty much everything about such 
bit-fields implementation-defined - see the minutes for Portland 2006, 
London 2007, Kona 2007).

> GCC's handling of bit-fields in __typeof__  is also a problem
> and causes bugs in .  For example, the following is
> rejected by GCC (with not just one but 42 errors) as a result:
> 
>   struct S { unsigned b: 31; } s;
>   carg (s.b);

That should be reported as an ordinary bug in , that can easily 
be addressed by using unary + so that typeof isn't applied to a bit-field 
( treats all integer types the same and non-arithmetic types are 
irrelevant to it, so unary + is absoletely fine there).

> If it isn't clear it should be brought up in WG14 and clarified.
> It's clear enough in C++ for bit-fields to be used as arguments
> to overloaded functions or function templates.  I can't imagine

C++ has long diverged from C regarding bit-fields (allowing other declared 
types, allowing widths wider than the width of the underlying type, now 
requiring plain int bit-fields to be signed, ...).  Whereas C has its line 
of textual history going back to various C90 DRs and showing that:

(a) whether a bit-field width counts of part of the type doesn't generally 
matter within the standard except for integer promotions, so can safely be 
left unspecified with just special wording for promotions (modulo the new 
_Generic issue);

(b) everything about such matters for bit-fields of nonstandard types can 
be left implementation-defined;

(c) nothing defines semantics of conversion of out-of-range values to 
bit-fields other than treating the width as part of the type (or in the 
case of _Bool bit-fields, having the special wording to make it explicit 
that those have the semantics of _Bool not the semantics of an ordinary 
unsigned integer type with the specified number of bits).

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

gcc-4.9-20160224 is now available

[gccadmin]

Snapshot gcc-4.9-20160224 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20160224/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch 
revision 233685

You'll find:

 gcc-4.9-20160224.tar.bz2 Complete GCC

  MD5=ca404abce194db9178d99051f45d65db
  SHA1=45a59ad9ba816d5c77231a42726cd4295aeca1aa

Diffs from 4.9-20160217 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.9
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

[Wink Saville]

See comment on (c) below

On Wed, Feb 24, 2016 at 1:53 PM Joseph Myers  wrote:
>
> On Wed, 24 Feb 2016, Martin Sebor wrote:
>
> > > That can be avoided simply by using unary + in the controlling expression
> > > of _Generic (just as using unary + will avoid an error from sizeof, if you
> > > want to be able to apply that to expressions that might be bit-fields) -
> > > or any of the other techniques for achieving promotions of selected types.
> >
> > Unfortunately, the + n trick is far too limited to be generally
> > usable.  Since GCC allows bit-fields of other integers types
> > besides those described by the standard (e.g., long long), the
> > plus expression would have to be converted to the widest possible
> > type (e.g., by (x + 0LL)) which would defeat the purpose of
> > _Generic.  The trick of course work at all for type-generic
> > macro intended to also accept non- scalar arguments.
>
> There are lots of variants of the trick (including the conditional
> expression one), depending on which types you care about distinguishing
> and which are valid arguments to the macro.  If you want, you can even
> distinguish each bit-field width wider than int individually using typeof,
> via writing expressions with typeof to determine the width of the type.
>
> I suspect many attempts to use _Generic with non-arithmetic types would
> run into usability problems in practice because every expression in the
> generic association list must still pass the Constraints whatever the type
> of the controlling expression - so you can select a function name based on
> that type, but putting more complicated expressions directly inside
> _Generic would be problematic in many cases if a wide range of types is to
> be allowed.
>
> There is a basic question: is _Generic supposed to be arbitrarily
> expressive, or is it meant to cover cases like ?  The answer in
> the context of questions about qualifiers and array-to-pointer decay was
> that it is meant to cover cases like , not to be arbitrarily
> expressive for hypothetical cases.  Maximal expressiveness would allow
> distinguishing all bit-field widths, but that would fall down on
> usability.
>
> Integer types narrower than int are effectively second-class entities in
> C; you can't write constants of those types, for example, and they get
> promoted before used in arithmetic or being passed in variable arguments;
> while you *can* select on them with _Generic, the utility of doing so may
> be limited.  Bit-fields are effectively third-class entities, and
> bit-fields with implementation-defined declared types other than int or
> signed int or unsigned int are fourth-class (not required by the standard
> at all, and have their own problems of specification - and the final
> choice for DR#315 was to leave pretty much everything about such
> bit-fields implementation-defined - see the minutes for Portland 2006,
> London 2007, Kona 2007).
>
> > GCC's handling of bit-fields in __typeof__  is also a problem
> > and causes bugs in .  For example, the following is
> > rejected by GCC (with not just one but 42 errors) as a result:
> >
> >   struct S { unsigned b: 31; } s;
> >   carg (s.b);
>
> That should be reported as an ordinary bug in , that can easily
> be addressed by using unary + so that typeof isn't applied to a bit-field
> ( treats all integer types the same and non-arithmetic types are
> irrelevant to it, so unary + is absoletely fine there).
>
> > If it isn't clear it should be brought up in WG14 and clarified.
> > It's clear enough in C++ for bit-fields to be used as arguments
> > to overloaded functions or function templates.  I can't imagine
>
> C++ has long diverged from C regarding bit-fields (allowing other declared
> types, allowing widths wider than the width of the underlying type, now
> requiring plain int bit-fields to be signed, ...).  Whereas C has its line
> of textual history going back to various C90 DRs and showing that:
>
> (a) whether a bit-field width counts of part of the type doesn't generally
> matter within the standard except for integer promotions, so can safely be
> left unspecified with just special wording for promotions (modulo the new
> _Generic issue);
>
> (b) everything about such matters for bit-fields of nonstandard types can
> be left implementation-defined;
>
> (c) nothing defines semantics of conversion of out-of-range values to
> bit-fields other than treating the width as part of the type (or in the
> case of _Bool bit-fields, having the special wording to make it explicit
> that those have the semantics of _Bool not the semantics of an ordinary
> unsigned integer type with the specified number of bits).


I don't see where in the standard it says the width of a bit field is
part of the type.
I see In Section 6.7.2.1 paragraphs 9, 10, 11, 12 requires the compiler to know
the width, but I don't see where the width is part of the type.

Could you point me to the appropriate paragraph(s)?

-- wink

>
>
> --
> Joseph S. Myers
> jo

Re: How to use _Generic with bit-fields

[Joseph Myers]

On Wed, 24 Feb 2016, Wink Saville wrote:

> > (c) nothing defines semantics of conversion of out-of-range values to
> > bit-fields other than treating the width as part of the type (or in the
> > case of _Bool bit-fields, having the special wording to make it explicit
> > that those have the semantics of _Bool not the semantics of an ordinary
> > unsigned integer type with the specified number of bits).
> 
> 
> I don't see where in the standard it says the width of a bit field is
> part of the type.
> I see In Section 6.7.2.1 paragraphs 9, 10, 11, 12 requires the compiler to 
> know
> the width, but I don't see where the width is part of the type.
> 
> Could you point me to the appropriate paragraph(s)?

If you look at the London 2007 minutes 
 you'll see 
that at that time this was intended to be deliberately ambiguous, to 
support both C++ practice and the longstanding C intent as expressed in 
the responses to various C90 DRs (the difference, at that time, only 
mattering for implementation-defined bit-field types).

The "interpreted as having a signed or unsigned integer type consisting of 
the specified number of bits" (paragraph 10), if applied for the purposes 
of interpreting other references to types in C11, has consequences 
including: (i) conversions to store a value in a bit-field follow the same 
rules as conversions to a normal integer type, (ii) a bit-field with width 
less than that of int also has integer conversion rank less than that of 
int, and so promotes to int under the integer promotions (even if the 
declared type is wider than int).  (It also has the less intuitive 
consequences regarding bit-field types escaping from their bit-field 
context, as discussed in the present thread and elsewhere.)

Without it being part of the type, making long:1 promote to int (as in 
C++) not long would require changes to the wording on promotions, and 
separate wording would be needed to make the results of assignments clear 
(and I'm not convinced that C++ has such wording in all cases where it is 
needed).

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

Re: How to use _Generic with bit-fields

[Wink Saville]

On Wed, Feb 24, 2016 at 3:38 PM, Joseph Myers  wrote:
> On Wed, 24 Feb 2016, Wink Saville wrote:
>
>> > (c) nothing defines semantics of conversion of out-of-range values to
>> > bit-fields other than treating the width as part of the type (or in the
>> > case of _Bool bit-fields, having the special wording to make it explicit
>> > that those have the semantics of _Bool not the semantics of an ordinary
>> > unsigned integer type with the specified number of bits).
>>
>>
>> I don't see where in the standard it says the width of a bit field is
>> part of the type.
>> I see In Section 6.7.2.1 paragraphs 9, 10, 11, 12 requires the compiler to 
>> know
>> the width, but I don't see where the width is part of the type.
>>
>> Could you point me to the appropriate paragraph(s)?
>
> If you look at the London 2007 minutes
>  you'll see
> that at that time this was intended to be deliberately ambiguous, to
> support both C++ practice and the longstanding C intent as expressed in
> the responses to various C90 DRs (the difference, at that time, only
> mattering for implementation-defined bit-field types).
>
> The "interpreted as having a signed or unsigned integer type consisting of
> the specified number of bits" (paragraph 10), if applied for the purposes
> of interpreting other references to types in C11, has consequences
> including: (i) conversions to store a value in a bit-field follow the same
> rules as conversions to a normal integer type, (ii) a bit-field with width
> less than that of int also has integer conversion rank less than that of
> int, and so promotes to int under the integer promotions (even if the
> declared type is wider than int).

I found this very surprising, but the standard does seem to require this.

>  (It also has the less intuitive
> consequences regarding bit-field types escaping from their bit-field
> context, as discussed in the present thread and elsewhere.)
>
> Without it being part of the type, making long:1 promote to int (as in
> C++) not long would require changes to the wording on promotions, and
> separate wording would be needed to make the results of assignments clear
> (and I'm not convinced that C++ has such wording in all cases where it is
> needed).

Clang doesn't seem to need to have the width as part of the type. And by not
having it as part of the type _Generic works as expected on clang but doesn't
work on gcc.

Further more things like printing of "big" bit fields such as
unsigned long long int b:33 doesn't issue any warnings with -Wall on clang
but does on gcc. Also, the shifting weirdness doesn't occur on clang.
>From my perspective, as a user, I think these behaviors are gcc bugs.

If someone were to supply a patch that changed the behavior to match
what clang and apparently other compilers are doing, would you be likely
to accept it?

-- Wink

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