[PATCH, i386]: Some further improvements to patterns with embedded zero-extract RTXes

[Uros Bizjak]

Hello!

While we still don't allow memory operands for x86_64, we can improve
generated code by allowing memory operands until reload. This way,
combine is free to create complex patterns, illustrated by following
test:

--cut here--
struct S1
{
  unsigned char pad1;
  unsigned char val;
  unsigned short pad2;
};

extern struct S1 t;

struct S1 test_add (struct S1 a, struct S1 b)
{
  a.val += t.val;

  return a;
}
--cut here--

Unpatched x86_64 compiler generates (-O2):

movl%edi, %eax
movzbl  %ah, %edx
addbt+1(%rip), %dl
movb%dl, %ah

while patched compiler generates:

movzbl  t+1(%rip), %edx
movl%edi, %eax
addb%dl, %ah

Ideally, the memory operand would be merged to the operation, but high
registers can't be used with REX prefix, so we have to take care there
is no REX registers in the address.

FWIW, define_memory_constraint can't be used to solve the above
limitation, since reload converts memory operand to the form involving
BASE_REG_CLASS, which on x86_64 includes REX registers as well.

2016-12-27  Uros Bizjak  

PR target/78904
* config/i386/i386.md (*cmpqi_ext_1, *extvqi, *extzvqi): Use
nonimmediate_operand instead of nonimmediate_x64nomem_operand.
(*cmpqi_ext_3, insv_1, addqi_ext_1, *testqi_ext_1, andqi_ext_1)
(*qi_ext_1, *xorqi_ext_1_cc): Use general_operand
instead of general_x64nomem_operand.
* config/i386/predicates.md (nonimmediate_x64nomem_operand): Remove.
(general_x64nomem_operand): Ditto.

testsuite/ChangeLog:

2016-12-27  Uros Bizjak  

PR target/78904
* gcc.target/i386/pr78904-2.c: New test.

Patch was bootstrapped and regression tested on x86_64-linux-gnu.

Committed to mainline SVN.

Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 243929)
+++ config/i386/i386.md (working copy)
@@ -1295,7 +1295,7 @@
 (define_insn "*cmpqi_ext_1"
   [(set (reg FLAGS_REG)
(compare
- (match_operand:QI 0 "nonimmediate_x64nomem_operand" "Q,m")
+ (match_operand:QI 0 "nonimmediate_operand" "Q,m")
  (subreg:QI
(zero_extract:SI
  (match_operand 1 "ext_register_operand" "Q,Q")
@@ -1340,7 +1340,7 @@
  (match_operand 0 "ext_register_operand" "Q,Q")
  (const_int 8)
  (const_int 8)) 0)
- (match_operand:QI 1 "general_x64nomem_operand" "Qn,m")))]
+ (match_operand:QI 1 "general_operand" "Qn,m")))]
   "ix86_match_ccmode (insn, CCmode)"
   "cmp{b}\t{%1, %h0|%h0, %1}"
   [(set_attr "isa" "*,nox64")
@@ -2781,7 +2781,7 @@
(set_attr "mode" "SI")])
 
 (define_insn "*extvqi"
-  [(set (match_operand:QI 0 "nonimmediate_x64nomem_operand" "=Q,?R,m")
+  [(set (match_operand:QI 0 "nonimmediate_operand" "=Q,?R,m")
 (sign_extract:QI (match_operand 1 "ext_register_operand" "Q,Q,Q")
  (const_int 8)
  (const_int 8)))]
@@ -2836,7 +2836,7 @@
(set_attr "mode" "SI")])
 
 (define_insn "*extzvqi"
-  [(set (match_operand:QI 0 "nonimmediate_x64nomem_operand" "=Q,?R,m")
+  [(set (match_operand:QI 0 "nonimmediate_operand" "=Q,?R,m")
 (subreg:QI
  (zero_extract:SI (match_operand 1 "ext_register_operand" "Q,Q,Q")
   (const_int 8)
@@ -2897,7 +2897,7 @@
   [(set (zero_extract:SWI248 (match_operand 0 "ext_register_operand" "+Q,Q")
 (const_int 8)
 (const_int 8))
-   (match_operand:SWI248 1 "general_x64nomem_operand" "Qn,m"))]
+   (match_operand:SWI248 1 "general_operand" "Qn,m"))]
   ""
 {
   if (CONST_INT_P (operands[1]))
@@ -6087,7 +6087,7 @@
  (zero_extract:SI (match_operand 1 "ext_register_operand" "0,0")
   (const_int 8)
   (const_int 8)) 0)
-   (match_operand:QI 2 "general_x64nomem_operand" "Qn,m")) 0))
+   (match_operand:QI 2 "general_operand" "Qn,m")) 0))
(clobber (reg:CC FLAGS_REG))]
   ""
 {
@@ -7889,7 +7889,7 @@
  (zero_extract:SI (match_operand 0 "ext_register_operand" "Q,Q")
   (const_int 8)
   (const_int 8)) 0)
-   (match_operand:QI 1 "general_x64nomem_operand" "Qn,m"))
+   (match_operand:QI 1 "general_operand" "Qn,m"))
  (const_int 0)))]
   "ix86_match_ccmode (insn, CCNOmode)"
   "test{b}\t{%1, %h0|%h0, %1}"
@@ -8417,7 +8417,7 @@
  (zero_extract:SI (match_operand 1 "ext_register_operand" "0,0")
   (const_int 8)
   (const_int 8)) 0)
-   (match_operand:QI 2 "general_x64nomem_operand" "Qn,m")) 0))
+   (match_operand:QI 2 "general_operand" "Qn,m")) 0))
(clobber (reg:CC FLAGS_REG))]
   ""
   "and{b}\t{%2, %h0|%h0, %2}"
@@ -8803,7 +8803,7 @@
  (zero_extract:SI (match_operand 1 "ext_register_operand" 

Re: [PATCH] PR 78534 Change character length from int to size_t

[Andre Vehreschild]

Hi Janne,

sorry for being late in voicing my opinion, but I personally would prefer to
have this patch in a separately. That way bisecting for performance
regressions points only to the offending code and not to the change of the
character length (the latter might add a tiny bit of cost, too).

Regards,
Andre


On Fri, 23 Dec 2016 11:27:10 +0200
Janne Blomqvist  wrote:

> On Wed, Dec 21, 2016 at 3:14 PM, Andre Vehreschild  wrote:
> >> Now when I think about this some more, I have a vague recollection
> >> that a long time ago it used to be something like that.  The problem
> >> is that MIN_EXPR will of course be
> >> NON-CONSTANT, so the memcpy call can't be inlined. Hence it was
> >> changed to two separate __builtin_memmove() calls to have better
> >> opportunity to inline. So probably a no-go to change it back. :(  
> >
> > I don't get that. From the former only one of the memmove's could have been
> > inlined assuming that only CONSTANT sizes are inlined.  
> 
> Yes. Which is better than not being able to inline, assuming the
> inlined branch is more likely to be taken, no?
> 
> > The other one had a
> > NON-CONSTANT as long as pointer following and constant propagation was not
> > effective together. In our case the "NON-CONSTANT branch" would have been
> > used, which is resolved by constant propagation (of the size of constant
> > memory p points to). I assume the warning is triggered, because dead-code
> > elimination has not removed the else part.  
> 
> Probably yes, in this case. My performance worries were more about the
> general case. But perhaps they are unfounded, IDK really. Does anybody
> have a battery of string operation benchmarks that mirrors how real
> Fortran code does string handling?
> 
> Anyway, the attached patch accomplishes that. It turns the tree dump I
> showed two days ago into something like
> 
>   {
> integer(kind=8) D.3484;
> unsigned long D.3485;
> 
> D.3484 = *_p;
> D.3485 = (unsigned long) D.3484 + 18446744073709551608;
> if (D.3484 != 0)
>   {
> __builtin_memmove ((void *) *p, (void *) &"12345679"[1]{lb: 1
> sz: 1}, MIN_EXPR <(unsigned long) D.3484, 8>);
> if ((unsigned long) D.3484 > 8)
>   {
> __builtin_memset ((void *) *p + 8, 32, D.3485);
>   }
>   }
>   }
> 
> and gets rid of the -Wstringop-overflow warning. (It causes a two new
> testsuite failures (gfortran.dg/dependency_49.f90 and
> gfortran.dg/transfer_intrinsic_1.f90), but those are just tests that
> grep for patterns in the .original dump and need to be adjusted).
> 
> If that is Ok, do you prefer it as part of the charlen-size_t patch,
> or would you (GFortran maintainers in general) prefer that it's a
> separate patch?
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Re: [PATCH] PR 78534 Change character length from int to size_t

[Janne Blomqvist]

On Mon, Dec 26, 2016 at 12:32 PM, FX  wrote:
> Hi Janne,
>
> Thanks for the patch, it is hard and tedious work. Here is the formal review. 
> I don’t want to be a pain, but I have several questions about the patch, and 
> given its size and the importance I think we should be double-sure :)

Thanks for the in-depth review, I appreciate it!

>> I also changed the _size member in vtables from int to size_t, as
>> there were some cases where character lengths and sizes were
>> apparently mixed up and caused regressions otherwise. Although I
>> haven't tested, this might enable very large derived types as well.
>
> Regarding that one, why are you making it an explicit size_t and not a 
> charlen type? I know the two will be the same, at least for now, but given 
> that it’s explicitly a character length we should use that variable type. 
> This is a preexisting issue with the front-end and library, where we 
> generally use a mix of types (because they end up being the same anyway, such 
> as C int and GFC_INTEGER_4).

The _size member is the size of the object; for polymorphic objects
the size isn't known at compile time, so it is to be stored in the
vtable (in principle, since the vtable tells the exact class of a
polymorphic object, it should be possible to figure out the size
without an explicit _size member, but I'll let the OOP experts handle
that, if they want). There is another vtable member _len which is used
for character lengths, and that is indeed of type
gfc_charlen_type_node.

I think when the dust settles, I might make sense to get rid of
gfc_charlen_type_node/gfc_charlen_type and just use
size_type_node/size_t also for string lengths, but at least for now I
think it's clearer to use separate names.

> Regarding the introduction of is_charlen in gfc_typespec, I am unclear as to 
> why it is needed. It is used exclusively in arith.c, which is not where we 
> should be checking character lengths I think. It is visible by the fact that 
> we normally shouldn’t need access to middle-end headers (tree.h and 
> trans-types.h) at that level. So, can’t we make the check where we currently 
> do it, i.e. later when we translate the constant string? That sounds more 
> reasonable that introducing a new special-cased entity.

This is, well, a leftover from my attempts to make
gfc_charlen_type_node an alias for size_type_node, an unsigned type.
Since the gfc_typespec doesn't understand unsigned integers, it had to
be extended in some fashion.  You can see that the check in arith.c
checks that the charlen is in the range [0,
TYPE_MAX_VALUE(gfc_charlen_type_node)], which the "normal" check isn't
able to do.

So strictly speaking it's not necessary, as long as
gfc_charlen_type_node is a signed integer.

OTOH, if/when one wants to make gfc_charlen_type_node unsigned,
perhaps some more far-reaching changes are needed and that work is not
necessary anymore. Say, introducing BT_UNSIGNED_INTEGER (??) and
teaching gfc_typespec to handle unsigned integers? Or maybe it's
better to put a tree node specifying the type in the typespec and use
that instead of the bt type + kind to tell what type it is?

Do you want me to remove that for the time being?

> There are other cases (resolve.c, simplify.c) where you introduce a 
> dependency on middle-end entities (tree.h, trans-types.h) in what are pure 
> Fortran front-end stages. This breaks the separation that currently exists, 
> and which I strongly think we should keep.

These changes are similar to the above, i.e. a check that uses
get_type_static_bounds() and works also if gfc_charlen_type_node is
changed to be an unsigned type.

> ** libgfortran **
>
> - in io/write.c, the “for” clauses in in namelist_write() have weird spacing 
> around their semicolons (i.e. space should be after, not before)

Ah, I hadn't noticed that. As one can see, it's a pre-existing issue,
but I might as well fix it when I'm changing that line. Will do.

> - in intrinsics/extends_type_of.c, use gfc_charlen_type instead of size_t 
> vtype->size

As I explained earlier, this is because the size member is the size of
the object rather than the charlen, so I think it should stay a
size_t.

> ** front-end **
>
> - class.c: use gfc_charlen_int_kind instead of gfc_size_kind

Same here.

> - class.c, in find_intrinsic_vtab(): in the call to gfc_get_int_expr, the 
> third argument cannot be cast from (size_t) to (long), as this would fail on 
> LLP64 hosts

Yes, but... the issue is that gfc_get_int_expr uses mpz_set_si, so
can't handle more than long anyway. But hmm, maybe that typecast
should be removed anyway, so that when/if gfc_get_int_expr is fixed
this would be automatically fixed as well.

> - expr.c, regarding gfc_extract_long(): we could definitely extract an host 
> wide int or an mpz value. This new function is called twice: once in 
> resolve_charlen() where we could use the GMP function mpz_sgn() to check if 
> the constant value is negative; the second time in gfc_simplify_repeat, where 

Re: [PATCH] PR 78534 Change character length from int to size_t

[Janne Blomqvist]

On Tue, Dec 27, 2016 at 12:47 PM, Andre Vehreschild  wrote:
> Hi Janne,
>
> sorry for being late in voicing my opinion, but I personally would prefer to
> have this patch in a separately. That way bisecting for performance
> regressions points only to the offending code and not to the change of the
> character length (the latter might add a tiny bit of cost, too).

No worries. I included this in the updated charlen-size_t patch I
posted and which FX reviewed, but I can certainly commit this part
separately.

>
> Regards,
> Andre
>
>
> On Fri, 23 Dec 2016 11:27:10 +0200
> Janne Blomqvist  wrote:
>
>> On Wed, Dec 21, 2016 at 3:14 PM, Andre Vehreschild  wrote:
>> >> Now when I think about this some more, I have a vague recollection
>> >> that a long time ago it used to be something like that.  The problem
>> >> is that MIN_EXPR will of course be
>> >> NON-CONSTANT, so the memcpy call can't be inlined. Hence it was
>> >> changed to two separate __builtin_memmove() calls to have better
>> >> opportunity to inline. So probably a no-go to change it back. :(
>> >
>> > I don't get that. From the former only one of the memmove's could have been
>> > inlined assuming that only CONSTANT sizes are inlined.
>>
>> Yes. Which is better than not being able to inline, assuming the
>> inlined branch is more likely to be taken, no?
>>
>> > The other one had a
>> > NON-CONSTANT as long as pointer following and constant propagation was not
>> > effective together. In our case the "NON-CONSTANT branch" would have been
>> > used, which is resolved by constant propagation (of the size of constant
>> > memory p points to). I assume the warning is triggered, because dead-code
>> > elimination has not removed the else part.
>>
>> Probably yes, in this case. My performance worries were more about the
>> general case. But perhaps they are unfounded, IDK really. Does anybody
>> have a battery of string operation benchmarks that mirrors how real
>> Fortran code does string handling?
>>
>> Anyway, the attached patch accomplishes that. It turns the tree dump I
>> showed two days ago into something like
>>
>>   {
>> integer(kind=8) D.3484;
>> unsigned long D.3485;
>>
>> D.3484 = *_p;
>> D.3485 = (unsigned long) D.3484 + 18446744073709551608;
>> if (D.3484 != 0)
>>   {
>> __builtin_memmove ((void *) *p, (void *) &"12345679"[1]{lb: 1
>> sz: 1}, MIN_EXPR <(unsigned long) D.3484, 8>);
>> if ((unsigned long) D.3484 > 8)
>>   {
>> __builtin_memset ((void *) *p + 8, 32, D.3485);
>>   }
>>   }
>>   }
>>
>> and gets rid of the -Wstringop-overflow warning. (It causes a two new
>> testsuite failures (gfortran.dg/dependency_49.f90 and
>> gfortran.dg/transfer_intrinsic_1.f90), but those are just tests that
>> grep for patterns in the .original dump and need to be adjusted).
>>
>> If that is Ok, do you prefer it as part of the charlen-size_t patch,
>> or would you (GFortran maintainers in general) prefer that it's a
>> separate patch?
>>
>
>
> --
> Andre Vehreschild * Email: vehre ad gmx dot de



-- 
Janne Blomqvist

New Spanish PO file for 'gcc' (version 6.2.0)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Spanish team of translators.  The file is available at:

http://translationproject.org/latest/gcc/es.po

(This file, 'gcc-6.2.0.es.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH][x86_64] Enable AVX512 VPOPCNTD/VPOPCNTQ instructions

[Uros Bizjak]

Hello!

> this patch enables AVX512 VPOPCNTD/VPOPCNTQ instructions recently
> added in Instruction Set Extensions
> (https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf).

@@ -265,6 +268,9 @@
 (define_mode_iterator VF_512
   [V16SF V8DF])

+(define_mode_iterator VI_AVX512F
+  [V16SI V8DI])

Please name this iterator VI_512.

@@ -19881,3 +19887,44 @@
[(set_attr ("type") ("ssemuladd"))
 (set_attr ("prefix") ("evex"))
 (set_attr ("mode") ("TI"))])
+
+(define_insn "vpopcount"
+  [(set (match_operand:VI_AVX512F 0 "register_operand" "=v, v")
+ (popcount:VI_AVX512F
+  (match_operand:VI_AVX512F 1 "nonimmediate_operand" "v, m")))]
+  "TARGET_AVX512VPOPCNTDQ"
+  "vpopcnt\t{%1, %0|%0, %1}")
+
+(define_insn "vpopcountv16si_mask"
+  [(set (match_operand:V16SI 0 "register_operand" "=v, v")
+ (unspec:V16SI
+  [(match_operand:V16SI 1 "nonimmediate_operand" "v, m")
+   (match_operand:HI 2 "register_operand" "Yk, Yk")
+   (match_operand:V16SI 3 "nonimmediate_operand" "0, 0")] UNSPEC_VPOPCNTDQ))]
+  "TARGET_AVX512VPOPCNTDQ"
+  "vpopcntd\t{%1, %0%{%2%}|%{%2%}%0, %1}")
+
+(define_insn "vpopcountv16si_maskz"
+  [(set (match_operand:V16SI 0 "register_operand" "=v, v")
+ (unspec:V16SI
+  [(match_operand:HI 1 "register_operand" "Yk, Yk")
+   (match_operand:V16SI 2 "nonimmediate_operand" "v, m")] UNSPEC_VPOPCNTDQ))]
+  "TARGET_AVX512VPOPCNTDQ"
+  "vpopcntd\t{%2, %0%{%1%}%{z%}|%{%1%}%{z%}%0, %2}")
+
+(define_insn "vpopcountv8di_mask"
+  [(set (match_operand:V8DI 0 "register_operand" "=v, v")
+ (unspec:V8DI
+  [(match_operand:V8DI 1 "nonimmediate_operand" "v, m")
+   (match_operand:QI 2 "register_operand" "Yk, Yk")
+   (match_operand:V8DI 3 "nonimmediate_operand" "0, 0")] UNSPEC_VPOPCNTDQ))]
+  "TARGET_AVX512VPOPCNTDQ"
+  "vpopcntq\t{%1, %0%{%2%}|%{%2%}%0, %1}")
+
+(define_insn "vpopcountv8di_maskz"
+  [(set (match_operand:V8DI 0 "register_operand" "=v, v")
+ (unspec:V8DI
+  [(match_operand:QI 1 "register_operand" "Yk, Yk")
+   (match_operand:V8DI 2 "nonimmediate_operand" "v, m")] UNSPEC_VPOPCNTDQ))]
+  "TARGET_AVX512VPOPCNTDQ"
+  "vpopcntq\t{%2, %0%{%1%}%{z%}|%{%1%}%{z%}%0, %2}")

You should use (=v,vm) or (=v,vm,Yk) constraints. No need for separate
alternatives when they are handled in the same way.

Also, insn patterns with mask operands can use mode iterators. Use
avx512fmaskmode mode attribute for mask operand.

OTOH, the above patterns should probably use define_subst
infrastructure. Please see config/i386/subst.md for available
substitutions.

Uros.

Re: [PATCH][x86_64] Enable AVX512 VPOPCNTD/VPOPCNTQ instructions

[Andrew Senkevich]

2016-12-27 16:35 GMT+03:00 Uros Bizjak :
> Hello!
>
>> this patch enables AVX512 VPOPCNTD/VPOPCNTQ instructions recently
>> added in Instruction Set Extensions
>> (https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf).
>
> @@ -265,6 +268,9 @@
>  (define_mode_iterator VF_512
>[V16SF V8DF])
>
> +(define_mode_iterator VI_AVX512F
> +  [V16SI V8DI])
>
> Please name this iterator VI_512.

But there are already VI_512 :)

;; All 512bit vector integer modes
(define_mode_iterator VI_512
  [(V64QI "TARGET_AVX512BW")
   (V32HI "TARGET_AVX512BW")
   V16SI V8DI])


--
WBR,
Andrew

Re: Pointer Bounds Checker and trailing arrays (PR68270)

[Alexander Ivchenko]

Committed as r243936.

Thank you,
Alexander

2016-12-22 2:47 GMT+03:00 Ilya Enkovich :
> 2016-12-21 22:18 GMT+03:00 Alexander Ivchenko :
>> Right.. here is this updated chunk (otherwise no difference in the patch)
>>
>> diff --git a/gcc/tree-chkp.c b/gcc/tree-chkp.c
>> index 2769682..6c7862c 100644
>> --- a/gcc/tree-chkp.c
>> +++ b/gcc/tree-chkp.c
>> @@ -3272,6 +3272,9 @@ chkp_may_narrow_to_field (tree field)
>>  {
>>return DECL_SIZE (field) && TREE_CODE (DECL_SIZE (field)) == INTEGER_CST
>>  && tree_to_uhwi (DECL_SIZE (field)) != 0
>> +&& !(flag_chkp_flexible_struct_trailing_arrays
>> + && TREE_CODE(TREE_TYPE(field)) == ARRAY_TYPE
>> + && !DECL_CHAIN (field))
>>  && (!DECL_FIELD_OFFSET (field)
>>   || TREE_CODE (DECL_FIELD_OFFSET (field)) == INTEGER_CST)
>>  && (!DECL_FIELD_BIT_OFFSET (field)
>
> OK.
>
>>
>> 2016-12-21 21:00 GMT+03:00 Ilya Enkovich :
>>> 2016-12-20 17:44 GMT+03:00 Alexander Ivchenko :
 2016-11-26 0:28 GMT+03:00 Ilya Enkovich :
> 2016-11-25 15:47 GMT+03:00 Alexander Ivchenko :
>> Hi,
>>
>> The patch below addresses PR68270. could you please take a look?
>>
>> 2016-11-25  Alexander Ivchenko  
>>
>>* c-family/c.opt (flag_chkp_flexible_struct_trailing_arrays):
>>Add new option.
>>* tree-chkp.c (chkp_parse_array_and_component_ref): Forbid
>>narrowing when chkp_parse_array_and_component_ref is used and
>>the ARRAY_REF points to an array in the end of the struct.
>>
>>
>>
>> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
>> index 7d8a726..e45d6a2 100644
>> --- a/gcc/c-family/c.opt
>> +++ b/gcc/c-family/c.opt
>> @@ -1166,6 +1166,11 @@ C ObjC C++ ObjC++ LTO RejectNegative Report
>> Var(flag_chkp_narrow_to_innermost_ar
>>  Forces Pointer Bounds Checker to use bounds of the innermost arrays in 
>> case of
>>  nested static arryas access.  By default outermost array is used.
>>
>> +fchkp-flexible-struct-trailing-arrays
>> +C ObjC C++ ObjC++ LTO RejectNegative Report
>> Var(flag_chkp_flexible_struct_trailing_arrays)
>> +Allow Pointer Bounds Checker to treat all trailing arrays in structures 
>> as
>> +possibly flexible.
>
> Words 'allow' and 'possibly' are confusing here. This option is about to 
> force
> checker to do something, not to give him a choice.

 Fixed

> New option has to be documented in invoke.texi. It would also be nice to 
> reflect
> changes on GCC MPX wiki page.

 Done
> We have an attribute to change compiler behavior when this option is not 
> set.
> But we have no way to make exceptions when this option is used. Should we
> add one?
 Something like "bnd_fixed_size" ? Could work. Although the customer
 request did not mention the need for that.
 Can I add it in a separate patch?

>>>
>>> Yes.
>>>

>> +
>>  fchkp-optimize
>>  C ObjC C++ ObjC++ LTO Report Var(flag_chkp_optimize) Init(-1)
>>  Allow Pointer Bounds Checker optimizations.  By default allowed
>> diff --git a/gcc/tree-chkp.c b/gcc/tree-chkp.c
>> index 2769682..40f99c3 100644
>> --- a/gcc/tree-chkp.c
>> +++ b/gcc/tree-chkp.c
>> @@ -3425,7 +3425,9 @@ chkp_parse_array_and_component_ref (tree node, 
>> tree *ptr,
>>if (flag_chkp_narrow_bounds
>>&& !flag_chkp_narrow_to_innermost_arrray
>>&& (!last_comp
>> -  || chkp_may_narrow_to_field (TREE_OPERAND (last_comp, 1
>> +  || (chkp_may_narrow_to_field (TREE_OPERAND (last_comp, 1))
>> +  && !(flag_chkp_flexible_struct_trailing_arrays
>> +   && array_at_struct_end_p (var)
>
> This is incorrect place for fix. Consider code
>
> struct S {
>   int a;
>   int b[10];
> };
>
> struct S s;
> int *p = s.b;
>
> Here you need to compute bounds for p and you want your option to take 
> effect
> but in this case you won't event reach your new check because there is no
> ARRAY_REF. And even if we change it to
>
> int *p = s.b[5];
>
> then it still would be narrowed because s.b would still be written
> into 'comp_to_narrow'
> variable. Correct place for fix is in chkp_may_narrow_to_field.

 Done

> Also you should consider fchkp-narrow-to-innermost-arrray option. Should 
> it
> be more powerfull or not? I think fchkp-narrow-to-innermost-arrray 
> shouldn't
> narrow to variable sized fields. BTW looks like right now 
> bnd_variable_size
> attribute is ignored by fchkp-narrow-to-innermost-arrray. This is another
> problem and may be fixed in another patch though.
 The way code works in chkp_parse_array_and_component_ref seems to be
 exactly like you say:  fchkp-narrow-to-innermost-arrray won't narrow
 to variable sized fields. I will create a separate bug for
 bnd_variable_size+ fchkp-n

[X86 PATCH] Fix up i386 option translations (PR translation/78922)

[Jakub Jelinek]

Hi!

r201645 apparently added a useless file that nothing sources in
in a format incompatible with all other *.opt files (comments in *.opt
files start with ;, and no preprocessing is performed), the only thing that
it affects  is that all *.opt files from the tree are parsed to extract
translations from it, so we have stuff like:
#: config/i386/stringop.opt:8
msgid "the Free Software Foundation; either version 3, or (at your option)"
msgstr ""

#: config/i386/stringop.opt:13
msgid "MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the"
msgstr ""

#: config/i386/stringop.opt:18
msgid "see .  */"
msgstr ""

The following patch just removes it.  Bootstrapped/regtested on x86_64-linux
and i686-linux, ok for trunk/branches?

2016-12-27  Jakub Jelinek  

PR translation/78922
* config/i386/stringop.opt: Remove.

--- gcc/config/i386/stringop.opt.jj 2016-01-04 14:55:55.0 +0100
+++ gcc/config/i386/stringop.opt2016-12-26 10:45:57.548373327 +0100
@@ -1,31 +0,0 @@
-/* Definitions for stringop option handling for IA-32.
-   Copyright (C) 2013-2016 Free Software Foundation, Inc.
-
-This file is part of GCC.
-
-GCC is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 3, or (at your option)
-any later version.
-
-GCC is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with GCC; see the files COPYING3.  If not,
-see .  */
-
-Enum(stringop_alg) String(rep_byte) Value(rep_prefix_1_byte)
-
-#undef DEF_ENUM
-#define DEF_ENUM EnumValue
-
-#undef DEF_ALG
-#define DEF_ALG(alg, name) Enum(stringop_alg) String(name) Value(alg)
-
-#include "stringop.def"
-
-#undef DEF_ENUM
-#undef DEF_ALG

Jakub

Re: [PATCH][x86_64] Enable AVX512 VPOPCNTD/VPOPCNTQ instructions

[Uros Bizjak]

On Tue, Dec 27, 2016 at 2:40 PM, Andrew Senkevich
 wrote:
> 2016-12-27 16:35 GMT+03:00 Uros Bizjak :
>> Hello!
>>
>>> this patch enables AVX512 VPOPCNTD/VPOPCNTQ instructions recently
>>> added in Instruction Set Extensions
>>> (https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf).
>>
>> @@ -265,6 +268,9 @@
>>  (define_mode_iterator VF_512
>>[V16SF V8DF])
>>
>> +(define_mode_iterator VI_AVX512F
>> +  [V16SI V8DI])
>>
>> Please name this iterator VI_512.
>
> But there are already VI_512 :)
>
> ;; All 512bit vector integer modes
> (define_mode_iterator VI_512
>   [(V64QI "TARGET_AVX512BW")
>(V32HI "TARGET_AVX512BW")
>V16SI V8DI])

Eh, this one is duplicate of VI_AVX512BW and should be removed.

Uros.

Re: [PATCH, Fortran] Allow warnings given through gfc_error to associate with warning flags

[Jakub Jelinek]

On Tue, Nov 01, 2016 at 11:10:39AM -0400, Fritz Reese wrote:
> Currently warnings given by the GNU Fortran front-end typically
> indicate which flag controls the warning, if any, as given by the
> first argument to gfc_warning. However, there is no support for
> controlling warnings which are emitted by gfc_error when
> warnings_not_errors is set. Herein I propose a patch such that when a
> call to gfc_error may cause a warning, suppression of the warning can
> be controlled with a -W* warning flag, as with other warnings.
> 
> The simple patch extends the gfc_error interface to also accept an
> additional 'opt' arg, which is passed as the same first argument to
> gfc_warning if warnings_not_errors causes a warning instead of an
> error. The old interface remains, so that a default 'opt' of 0 is
> passed when gfc_error is called with no 'opt' argument. This minimizes
> the impact of the interface change on existing code. Note also that if
> the call to gfc_error would actually cause an error, the warning flag
> will not suppress the error.
> 
> See the patch for details. Bootstraps and regtests on x86_64-redhat-linux.
> 
> Another patch proposal will follow which utilizes this functionality
> to introduce a new warning -W[no-]argument-mismatch, assuming this one
> is OK.

Unfortunately this broke translation handling.  While C++ allows function
overloading, xgettext requires that for a specific function name there is
just a single position of the formatting string in its argument list and a
single position and kind of the arguments (va_list vs. ...).

So, make gcc.pot is right now broken because of this, so it wouldn't be
possible to get GCC 7 translated.

The following patch fixes that (or I'm open for a better name, but it just
can't be called gfc_error).

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2016-12-27  Jakub Jelinek  

* gfortran.h (gfc_error): Rename overload with OPT argument to...
(gfc_error_opt): ... this.
* error.c (gfc_error): Rename overloads with OPT argument to...
(gfc_error_opt): ... this.  Adjust callers.
(gfc_notify_std, gfc_error): Adjust callers.
* resolve.c (resolve_structure_cons, resolve_global_procedure): Use
gfc_error_opt instead of gfc_error.
* interface.c (argument_rank_mismatch, compare_parameter,
gfc_check_typebound_override): Likewise.  Fix up formatting.

--- gcc/fortran/gfortran.h.jj   2016-12-16 11:24:34.0 +0100
+++ gcc/fortran/gfortran.h  2016-12-27 10:08:56.543172428 +0100
@@ -2793,7 +2793,7 @@ bool gfc_warning_now_at (location_t loc,
 void gfc_clear_warning (void);
 void gfc_warning_check (void);
 
-void gfc_error (int opt, const char *, ...) ATTRIBUTE_GCC_GFC(2,3);
+void gfc_error_opt (int opt, const char *, ...) ATTRIBUTE_GCC_GFC(2,3);
 void gfc_error (const char *, ...) ATTRIBUTE_GCC_GFC(1,2);
 void gfc_error_now (const char *, ...) ATTRIBUTE_GCC_GFC(1,2);
 void gfc_fatal_error (const char *, ...) ATTRIBUTE_NORETURN 
ATTRIBUTE_GCC_GFC(1,2);
--- gcc/fortran/error.c.jj  2016-12-12 22:46:52.0 +0100
+++ gcc/fortran/error.c 2016-12-27 10:18:06.182182585 +0100
@@ -67,7 +67,7 @@ gfc_push_suppress_errors (void)
 }
 
 static void
-gfc_error (int opt, const char *gmsgid, va_list ap)  ATTRIBUTE_GCC_GFC(2,0);
+gfc_error_opt (int opt, const char *gmsgid, va_list ap)  
ATTRIBUTE_GCC_GFC(2,0);
 
 static bool
 gfc_warning (int opt, const char *gmsgid, va_list ap) ATTRIBUTE_GCC_GFC(2,0);
@@ -902,7 +902,7 @@ gfc_notify_std (int std, const char *gms
   if (warning)
 gfc_warning (0, buffer, argp);
   else
-gfc_error (0, buffer, argp);
+gfc_error_opt (0, buffer, argp);
   va_end (argp);
 
   return (warning && !warnings_are_errors) ? true : false;
@@ -1252,7 +1252,7 @@ gfc_warning_check (void)
 /* Issue an error.  */
 
 static void
-gfc_error (int opt, const char *gmsgid, va_list ap)
+gfc_error_opt (int opt, const char *gmsgid, va_list ap)
 {
   va_list argp;
   va_copy (argp, ap);
@@ -1308,11 +1308,11 @@ gfc_error (int opt, const char *gmsgid,
 
 
 void
-gfc_error (int opt, const char *gmsgid, ...)
+gfc_error_opt (int opt, const char *gmsgid, ...)
 {
   va_list argp;
   va_start (argp, gmsgid);
-  gfc_error (opt, gmsgid, argp);
+  gfc_error_opt (opt, gmsgid, argp);
   va_end (argp);
 }
 
@@ -1322,7 +1322,7 @@ gfc_error (const char *gmsgid, ...)
 {
   va_list argp;
   va_start (argp, gmsgid);
-  gfc_error (0, gmsgid, argp);
+  gfc_error_opt (0, gmsgid, argp);
   va_end (argp);
 }
 
--- gcc/fortran/resolve.c.jj2016-12-14 20:28:15.0 +0100
+++ gcc/fortran/resolve.c   2016-12-27 10:15:56.877825156 +0100
@@ -1312,10 +1312,10 @@ resolve_structure_cons (gfc_expr *expr,
  if (s2 && !gfc_compare_interfaces (comp->ts.interface, s2, name, 0, 1,
 err, sizeof (err), NULL, NULL))
{
- gfc_error (OPT_Wargument_mismatch,
-"Interface mismatch for procedure

Re: Use aligned SSE movs for re-aligned MS ABI pro/epilogues

[Uros Bizjak]

Hello!

> According to the Microsoft 64-bit ABI specification, registers RDI, RSI and 
> XMM6-15 are
> non-volatile and the stack alignment is 16 bytes. In practice, the Windows 
> implementation
> appears to not be so picky about the 16-byte alignment requirement, probably 
> because it never
> to save SSE registers and instead just never uses them. This led to a large 
> list
> (https://bugs.winehq.org/show_bug.cgi?id=27680) of Win64 programs violating 
> the ABI with
> impunity, but crashing in Wine until force_align_arg_pointer was added to gcc 
> and used in Wine.
>
> Stack re-alignment was originally done prior to int register saves, but was 
> moved to after SSE
> saves in 2010 to better facilitate parallelization, and for simplicity's 
> sake, the stack pointer was
> considered invalid after stack re-alignment and SSE movs were emitted 
> unaligned relative to the
> frame pointer. But now that forced stack re-alignment is the new normal for 
> Wine64, it means that
> it always gets the unaligned movs in Wine. This patch set fixes the problem 
> while preserving the
> improved parallelization of int register saves of Richard Henderson's patch 
> in 2010.

I have looked briefly through the patchset, and the approach looks good to me.

However, this patch is touching somehow delicate part of the compiler,
where lots of code-paths cross each other (and we have had quite some
hard-to-fix bugs in this area).

IMO, the patch is not appropriate for inclusion at the current stage
of the compiler development, and should wait for early stage 1. Please
resubmit it later for inclusion.

Thanks,
Uros.

Re: [PATCH][x86_64] Enable AVX512 VPOPCNTD/VPOPCNTQ instructions

[Uros Bizjak]

On Tue, Dec 27, 2016 at 2:47 PM, Uros Bizjak  wrote:
> On Tue, Dec 27, 2016 at 2:40 PM, Andrew Senkevich
>  wrote:
>> 2016-12-27 16:35 GMT+03:00 Uros Bizjak :
>>> Hello!
>>>
 this patch enables AVX512 VPOPCNTD/VPOPCNTQ instructions recently
 added in Instruction Set Extensions
 (https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf).
>>>
>>> @@ -265,6 +268,9 @@
>>>  (define_mode_iterator VF_512
>>>[V16SF V8DF])
>>>
>>> +(define_mode_iterator VI_AVX512F
>>> +  [V16SI V8DI])
>>>
>>> Please name this iterator VI_512.
>>
>> But there are already VI_512 :)
>>
>> ;; All 512bit vector integer modes
>> (define_mode_iterator VI_512
>>   [(V64QI "TARGET_AVX512BW")
>>(V32HI "TARGET_AVX512BW")
>>V16SI V8DI])
>
> Eh, this one is duplicate of VI_AVX512BW and should be removed.

Actually, you should use existing VI48_512 mode iterator.

Uros.

[PING**3] [PATCH, ARM] Further improve stack usage on sha512 (PR 77308)

[Bernd Edlinger]

Ping...

On 12/19/16 06:49, Bernd Edlinger wrote:
> Ping...
>
> On 12/12/16 06:59, Bernd Edlinger wrote:
>> Ping...
>>
>> On 12/05/16 14:41, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> this was the latest version of my patch:
>>> https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02796.html
>>>
>>>
>>> Thanks
>>> Bernd.

[PATCH, i386]: Allow constant memory for x86_64 operations involving high registers

[Uros Bizjak]

Hello!

While we can't allow only non-REX memory operands in patterns
involving high registers, we can at least allow constant memory
operands here.

2016-12-27  Uros Bizjak  

PR target/78904
* config/i386/constraints.md (Bc): New special memory constraint.
* config/i386/i386.md (*cmpqi_ext_1, *extvqi, *extzvqi): Use Bc
constraint with nonimmediate_operand to allow constant memory operands.
(*cmpqi_ext_3, insv_1, addqi_ext_1, *testqi_ext_1, andqi_ext_1)
(*qi_ext_1, *xorqi_ext_1_cc): Use Bc constraint
with general_operand to allow constant memory operands.

testsuite/ChangeLog:

2016-12-27  Uros Bizjak  

PR target/78904
* gcc.target/i386/pr78904-3.c: New test.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainline SVN.

Uros.
Index: config/i386/constraints.md
===
--- config/i386/constraints.md  (revision 243932)
+++ config/i386/constraints.md  (working copy)
@@ -168,6 +168,7 @@
 ;;  f  FLAGS_REG
 ;;  g  GOT memory operand.
 ;;  m  Vector memory operand
+;;  c  Constant memory operand
 ;;  s  Sibcall memory operand, not valid for TARGET_X32
 ;;  w  Call memory operand, not valid for TARGET_X32
 ;;  z  Constant call address operand.
@@ -185,6 +186,11 @@
   "@internal Vector memory operand."
   (match_operand 0 "vector_memory_operand"))
 
+(define_special_memory_constraint "Bc"
+  "@internal Constant memory operand."
+  (and (match_operand 0 "memory_operand")
+   (match_test "constant_address_p (XEXP (op, 0))")))
+
 (define_constraint "Bs"
   "@internal Sibcall memory operand."
   (ior (and (not (match_test "TARGET_X32"))
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 243934)
+++ config/i386/i386.md (working copy)
@@ -1295,7 +1295,7 @@
 (define_insn "*cmpqi_ext_1"
   [(set (reg FLAGS_REG)
(compare
- (match_operand:QI 0 "nonimmediate_operand" "Q,m")
+ (match_operand:QI 0 "nonimmediate_operand" "QBc,m")
  (subreg:QI
(zero_extract:SI
  (match_operand 1 "ext_register_operand" "Q,Q")
@@ -1340,7 +1340,7 @@
  (match_operand 0 "ext_register_operand" "Q,Q")
  (const_int 8)
  (const_int 8)) 0)
- (match_operand:QI 1 "general_operand" "Qn,m")))]
+ (match_operand:QI 1 "general_operand" "QnBc,m")))]
   "ix86_match_ccmode (insn, CCmode)"
   "cmp{b}\t{%1, %h0|%h0, %1}"
   [(set_attr "isa" "*,nox64")
@@ -2781,7 +2781,7 @@
(set_attr "mode" "SI")])
 
 (define_insn "*extvqi"
-  [(set (match_operand:QI 0 "nonimmediate_operand" "=Q,?R,m")
+  [(set (match_operand:QI 0 "nonimmediate_operand" "=QBc,?R,m")
 (sign_extract:QI (match_operand 1 "ext_register_operand" "Q,Q,Q")
  (const_int 8)
  (const_int 8)))]
@@ -2836,7 +2836,7 @@
(set_attr "mode" "SI")])
 
 (define_insn "*extzvqi"
-  [(set (match_operand:QI 0 "nonimmediate_operand" "=Q,?R,m")
+  [(set (match_operand:QI 0 "nonimmediate_operand" "=QBc,?R,m")
 (subreg:QI
  (zero_extract:SI (match_operand 1 "ext_register_operand" "Q,Q,Q")
   (const_int 8)
@@ -2897,7 +2897,7 @@
   [(set (zero_extract:SWI248 (match_operand 0 "ext_register_operand" "+Q,Q")
 (const_int 8)
 (const_int 8))
-   (match_operand:SWI248 1 "general_operand" "Qn,m"))]
+   (match_operand:SWI248 1 "general_operand" "QnBc,m"))]
   ""
 {
   if (CONST_INT_P (operands[1]))
@@ -6087,7 +6087,7 @@
  (zero_extract:SI (match_operand 1 "ext_register_operand" "0,0")
   (const_int 8)
   (const_int 8)) 0)
-   (match_operand:QI 2 "general_operand" "Qn,m")) 0))
+   (match_operand:QI 2 "general_operand" "QnBc,m")) 0))
(clobber (reg:CC FLAGS_REG))]
   ""
 {
@@ -7889,7 +7889,7 @@
  (zero_extract:SI (match_operand 0 "ext_register_operand" "Q,Q")
   (const_int 8)
   (const_int 8)) 0)
-   (match_operand:QI 1 "general_operand" "Qn,m"))
+   (match_operand:QI 1 "general_operand" "QnBc,m"))
  (const_int 0)))]
   "ix86_match_ccmode (insn, CCNOmode)"
   "test{b}\t{%1, %h0|%h0, %1}"
@@ -8417,7 +8417,7 @@
  (zero_extract:SI (match_operand 1 "ext_register_operand" "0,0")
   (const_int 8)
   (const_int 8)) 0)
-   (match_operand:QI 2 "general_operand" "Qn,m")) 0))
+   (match_operand:QI 2 "general_operand" "QnBc,m")) 0))
(clobber (reg:CC FLAGS_REG))]
   ""
   "and{b}\t{%2, %h0|%h0, %2}"
@@ -8435,7 +8435,7 @@
  (zero_extract:SI (match_operand 1 "ext_register_operand" "0,0")
   (const_int 8)
   (const_int 8)) 0)
-   (match_operand:Q

Re: [X86 PATCH] Fix up i386 option translations (PR translation/78922)

[Uros Bizjak]

On Tue, Dec 27, 2016 at 2:46 PM, Jakub Jelinek  wrote:
> Hi!
>
> r201645 apparently added a useless file that nothing sources in
> in a format incompatible with all other *.opt files (comments in *.opt
> files start with ;, and no preprocessing is performed), the only thing that
> it affects  is that all *.opt files from the tree are parsed to extract
> translations from it, so we have stuff like:
> #: config/i386/stringop.opt:8
> msgid "the Free Software Foundation; either version 3, or (at your option)"
> msgstr ""
>
> #: config/i386/stringop.opt:13
> msgid "MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the"
> msgstr ""
>
> #: config/i386/stringop.opt:18
> msgid "see .  */"
> msgstr ""
>
> The following patch just removes it.  Bootstrapped/regtested on x86_64-linux
> and i686-linux, ok for trunk/branches?
>
> 2016-12-27  Jakub Jelinek  
>
> PR translation/78922
> * config/i386/stringop.opt: Remove.

OK everywhere as obvious.

Thanks,
Uros.

> --- gcc/config/i386/stringop.opt.jj 2016-01-04 14:55:55.0 +0100
> +++ gcc/config/i386/stringop.opt2016-12-26 10:45:57.548373327 +0100
> @@ -1,31 +0,0 @@
> -/* Definitions for stringop option handling for IA-32.
> -   Copyright (C) 2013-2016 Free Software Foundation, Inc.
> -
> -This file is part of GCC.
> -
> -GCC is free software; you can redistribute it and/or modify
> -it under the terms of the GNU General Public License as published by
> -the Free Software Foundation; either version 3, or (at your option)
> -any later version.
> -
> -GCC is distributed in the hope that it will be useful,
> -but WITHOUT ANY WARRANTY; without even the implied warranty of
> -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> -GNU General Public License for more details.
> -
> -You should have received a copy of the GNU General Public License
> -along with GCC; see the files COPYING3.  If not,
> -see .  */
> -
> -Enum(stringop_alg) String(rep_byte) Value(rep_prefix_1_byte)
> -
> -#undef DEF_ENUM
> -#define DEF_ENUM EnumValue
> -
> -#undef DEF_ALG
> -#define DEF_ALG(alg, name) Enum(stringop_alg) String(name) Value(alg)
> -
> -#include "stringop.def"
> -
> -#undef DEF_ENUM
> -#undef DEF_ALG
>
> Jakub

Re: [PATCH, Fortran] Allow warnings given through gfc_error to associate with warning flags

[FX]

> 2016-12-27  Jakub Jelinek  
> 
>   * gfortran.h (gfc_error): Rename overload with OPT argument to...
>   (gfc_error_opt): ... this.
>   * error.c (gfc_error): Rename overloads with OPT argument to...
>   (gfc_error_opt): ... this.  Adjust callers.
>   (gfc_notify_std, gfc_error): Adjust callers.
>   * resolve.c (resolve_structure_cons, resolve_global_procedure): Use
>   gfc_error_opt instead of gfc_error.
>   * interface.c (argument_rank_mismatch, compare_parameter,
>   gfc_check_typebound_override): Likewise.  Fix up formatting.

OK. Thanks for taking care of that.

FX

Re: PR78631 fix

[Alexander Ivchenko]

Committed as r243942 with the ChangeLog entries


thanks,
Alexander

2016-12-23 21:48 GMT+03:00 Ilya Enkovich :
> Hi,
>
> ChangeLog? Otherwise OK.
>
> Ilya
>
> 2016-12-23 14:02 GMT+03:00 Alexander Ivchenko :
>> Hi Ilya,
>>
>> Would that patch be OK to submit? (it is HJ's one with added testcase)
>>
>> diff --git a/gcc/testsuite/gcc.target/i386/mpx/memcpy-1.c
>> b/gcc/testsuite/gcc.target/i386/mpx/memcpy-1.c
>> new file mode 100644
>> index 000..1691348
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/i386/mpx/memcpy-1.c
>> @@ -0,0 +1,23 @@
>> +/* { dg-do run } */
>> +/* { dg-shouldfail "bounds violation" } */
>> +/* { dg-options "-fcheck-pointer-bounds -mmpx" } */
>> +
>> +/* Fix for PR78631 */
>> +
>> +#define SHOULDFAIL
>> +
>> +#include 
>> +#include 
>> +
>> +char s[10];
>> +char d[10];
>> +__attribute__((noinline))
>> +
>> +char* foo(char* dst, char* src, size_t size) {
>> +  return memcpy(dst, src, size);
>> +}
>> +int main() {
>> +  char* r = foo(d, s, 11);
>> +  printf("r = %p\n", r);
>> +  return 0;
>> +}
>> diff --git a/libmpx/mpxwrap/libtool-version b/libmpx/mpxwrap/libtool-version
>> index fab30fb..e241350 100644
>> --- a/libmpx/mpxwrap/libtool-version
>> +++ b/libmpx/mpxwrap/libtool-version
>> @@ -3,4 +3,4 @@
>>  # a separate file so that version updates don't involve re-running
>>  # automake.
>>  # CURRENT:REVISION:AGE
>> -2:0:0
>> +2:1:0
>> diff --git a/libmpx/mpxwrap/mpx_wrappers.c b/libmpx/mpxwrap/mpx_wrappers.c
>> index 171a780..aea0346 100644
>> --- a/libmpx/mpxwrap/mpx_wrappers.c
>> +++ b/libmpx/mpxwrap/mpx_wrappers.c
>> @@ -30,14 +30,20 @@
>>  #include 
>>  #include "mpxrt/mpxrt.h"
>>
>> -void *
>> -__mpx_wrapper_malloc (size_t size)
>> +/* Since internal MPX wrapper calls must avoid PLT which will clear bound
>> +   registers, we make them static with an external alias.  */
>> +#define EXTERN_ALIAS(f) \
>> +  __typeof (f) __##f __attribute__((alias(#f)));
>> +
>> +static void *
>> +mpx_wrapper_malloc (size_t size)
>>  {
>>void *p = (void *)malloc (size);
>>if (!p) return __bnd_null_ptr_bounds (p);
>>return __bnd_set_ptr_bounds (p, size);
>>  }
>>
>> +EXTERN_ALIAS (mpx_wrapper_malloc)
>>
>>  void *
>>  __mpx_wrapper_mmap (void *addr, size_t length, int prot, int flags,
>> @@ -52,7 +58,7 @@ void *
>>  __mpx_wrapper_realloc (void *ptr, size_t n)
>>  {
>>if (!ptr)
>> -return __mpx_wrapper_malloc (n);
>> +return mpx_wrapper_malloc (n);
>>
>>/* We don't kwnow how much data is copied by realloc
>>   and therefore may check only lower bounds.  */
>> @@ -74,8 +80,8 @@ __mpx_wrapper_calloc (size_t n_elements, size_t 
>> element_size)
>>return __bnd_set_ptr_bounds (p, n_elements * element_size);
>>  }
>>
>> -void *
>> -__mpx_wrapper_memset (void *dstpp, int c, size_t len)
>> +static void *
>> +mpx_wrapper_memset (void *dstpp, int c, size_t len)
>>  {
>>if (len > 0)
>>  {
>> @@ -85,10 +91,12 @@ __mpx_wrapper_memset (void *dstpp, int c, size_t len)
>>return dstpp;
>>  }
>>
>> +EXTERN_ALIAS (mpx_wrapper_memset)
>> +
>>  void
>>  __mpx_wrapper_bzero (void *dst, size_t len)
>>  {
>> -  __mpx_wrapper_memset (dst, 0, len);
>> +  mpx_wrapper_memset (dst, 0, len);
>>  }
>>
>>  /* The mpx_pointer type is used for getting bits
>> @@ -484,8 +492,8 @@ move_bounds (void *dst, const void *src, size_t n)
>>return;
>>  }
>>
>> -void *
>> -__mpx_wrapper_memmove (void *dst, const void *src, size_t n)
>> +static void *
>> +mpx_wrapper_memmove (void *dst, const void *src, size_t n)
>>  {
>>if (n == 0)
>>  return dst;
>> @@ -513,17 +521,20 @@ __mpx_wrapper_memmove (void *dst, const void
>> *src, size_t n)
>>return dst;
>>  }
>>
>> +EXTERN_ALIAS (mpx_wrapper_memmove)
>>
>> -void *
>> -__mpx_wrapper_memcpy (void *dst, const void *src, size_t n)
>> +static void *
>> +mpx_wrapper_memcpy (void *dst, const void *src, size_t n)
>>  {
>> -  return __mpx_wrapper_memmove (dst, src, n);
>> +  return mpx_wrapper_memmove (dst, src, n);
>>  }
>>
>> +EXTERN_ALIAS (mpx_wrapper_memcpy)
>> +
>>  void *
>>  __mpx_wrapper_mempcpy (void *dst, const void *src, size_t n)
>>  {
>> -  return (char *)__mpx_wrapper_memcpy (dst, src, n) + n;
>> +  return (char *)mpx_wrapper_memcpy (dst, src, n) + n;
>>  }
>>
>>  char *

[PATCH] Add RejectNegative for a c option.

[Martin Liška]

Without RejectNegative one can cause an ICE in the compiler.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?
Martin
>From e005f69008daf6ad7705a2f9c3d0242e426c168f Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 27 Dec 2016 15:35:03 +0100
Subject: [PATCH] Add RejectNegative for a c option.

gcc/testsuite/ChangeLog:

2016-12-27  Martin Liska  

	* g++.dg/pr78933.C: New test.

gcc/c-family/ChangeLog:

2016-12-27  Martin Liska  

	* c.opt (strong-eval-order): Add RejectNegative keyword.
---
 gcc/c-family/c.opt | 2 +-
 gcc/testsuite/g++.dg/pr78933.C | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/pr78933.C

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index a5333a35e41..ba5c39d4f1c 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1649,7 +1649,7 @@ Follow the C++17 evaluation order requirements for assignment expressions,
 shift, member function calls, etc.
 
 fstrong-eval-order=
-C++ ObjC++ Common Var(flag_strong_eval_order) Joined Enum(strong_eval_order) Init(-1)
+C++ ObjC++ Common Var(flag_strong_eval_order) Joined Enum(strong_eval_order) RejectNegative Init(-1)
 Follow the C++17 evaluation order requirements for assignment expressions,
 shift, member function calls, etc.
 
diff --git a/gcc/testsuite/g++.dg/pr78933.C b/gcc/testsuite/g++.dg/pr78933.C
new file mode 100644
index 000..91a3a511711
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr78933.C
@@ -0,0 +1,3 @@
+// PR c/78933
+// { dg-do compile }
+// { dg-options "-fno-strong-eval-order" }
-- 
2.11.0

Re: Use aligned SSE movs for re-aligned MS ABI pro/epilogues

[Daniel Santos]

On 12/27/2016 07:56 AM, Uros Bizjak wrote:

Hello!


According to the Microsoft 64-bit ABI specification, registers RDI, RSI and 
XMM6-15 are
non-volatile and the stack alignment is 16 bytes. In practice, the Windows 
implementation
appears to not be so picky about the 16-byte alignment requirement, probably 
because it never
to save SSE registers and instead just never uses them. This led to a large list
(https://bugs.winehq.org/show_bug.cgi?id=27680) of Win64 programs violating the 
ABI with
impunity, but crashing in Wine until force_align_arg_pointer was added to gcc 
and used in Wine.

Stack re-alignment was originally done prior to int register saves, but was 
moved to after SSE
saves in 2010 to better facilitate parallelization, and for simplicity's sake, 
the stack pointer was
considered invalid after stack re-alignment and SSE movs were emitted unaligned 
relative to the
frame pointer. But now that forced stack re-alignment is the new normal for 
Wine64, it means that
it always gets the unaligned movs in Wine. This patch set fixes the problem 
while preserving the
improved parallelization of int register saves of Richard Henderson's patch in 
2010.

I have looked briefly through the patchset, and the approach looks good to me.

However, this patch is touching somehow delicate part of the compiler,
where lots of code-paths cross each other (and we have had quite some
hard-to-fix bugs in this area).

IMO, the patch is not appropriate for inclusion at the current stage
of the compiler development, and should wait for early stage 1. Please
resubmit it later for inclusion.

Thanks,
Uros.

Thank you for the review. Yes, this is a very delicate code path indeed. 
For the purposes of the 64-bit Microsoft ABI function calling a System V 
function, I've written a fairly exhaustive test program (although 
probably not fully comprehensive) for testing pro/epilogues under 
various conditions. I'm completely new to dejagnu however, so I still 
need to figure out how to properly integrate it. Maybe when I re-submit 
this patch set I can submit the new tests with it.


Thanks,
Daniel

[PATCH, i386]: Remove VI_512 mode iterator ...

[Uros Bizjak]

... and use equivalent VI_AVX512BW mode iterator instead.

No functional changes.

2016-12-27  Uros Bizjak  

* config/i386/i386.md (VI_512): Remove.
(vcond): Use VI_AVX512BW
mode iterator instead of VI_512.
(vcondu): Ditto.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainline SVN.

Uros.
Index: config/i386/sse.md
===
--- config/i386/sse.md  (revision 243932)
+++ config/i386/sse.md  (working copy)
@@ -521,12 +521,6 @@
 ;; All 256bit vector integer modes
 (define_mode_iterator VI_256 [V32QI V16HI V8SI V4DI])
 
-;; All 512bit vector integer modes
-(define_mode_iterator VI_512
-  [(V64QI "TARGET_AVX512BW")
-   (V32HI "TARGET_AVX512BW")
-   V16SI V8DI])
-
 ;; Various 128bit vector integer mode combinations
 (define_mode_iterator VI12_128 [V16QI V8HI])
 (define_mode_iterator VI14_128 [V16QI V4SI])
@@ -11249,17 +11243,17 @@
(set_attr "prefix" "orig,vex")
(set_attr "mode" "TI")])
 
-(define_expand "vcond"
+(define_expand "vcond"
   [(set (match_operand:V_512 0 "register_operand")
(if_then_else:V_512
  (match_operator 3 ""
-   [(match_operand:VI_512 4 "nonimmediate_operand")
-(match_operand:VI_512 5 "general_operand")])
+   [(match_operand:VI_AVX512BW 4 "nonimmediate_operand")
+(match_operand:VI_AVX512BW 5 "general_operand")])
  (match_operand:V_512 1)
  (match_operand:V_512 2)))]
   "TARGET_AVX512F
&& (GET_MODE_NUNITS (mode)
-   == GET_MODE_NUNITS (mode))"
+   == GET_MODE_NUNITS (mode))"
 {
   bool ok = ix86_expand_int_vcond (operands);
   gcc_assert (ok);
@@ -11315,17 +11309,17 @@
   DONE;
 })
 
-(define_expand "vcondu"
+(define_expand "vcondu"
   [(set (match_operand:V_512 0 "register_operand")
(if_then_else:V_512
  (match_operator 3 ""
-   [(match_operand:VI_512 4 "nonimmediate_operand")
-(match_operand:VI_512 5 "nonimmediate_operand")])
+   [(match_operand:VI_AVX512BW 4 "nonimmediate_operand")
+(match_operand:VI_AVX512BW 5 "nonimmediate_operand")])
  (match_operand:V_512 1 "general_operand")
  (match_operand:V_512 2 "general_operand")))]
   "TARGET_AVX512F
&& (GET_MODE_NUNITS (mode)
-   == GET_MODE_NUNITS (mode))"
+   == GET_MODE_NUNITS (mode))"
 {
   bool ok = ix86_expand_int_vcond (operands);
   gcc_assert (ok);

Re: [PATCH] PR 78534 Change character length from int to size_t

[FX]

> The _size member is the size of the object; for polymorphic objects
> the size isn't known at compile time, so it is to be stored in the
> vtable (in principle, since the vtable tells the exact class of a
> polymorphic object, it should be possible to figure out the size
> without an explicit _size member, but I'll let the OOP experts handle
> that, if they want). There is another vtable member _len which is used
> for character lengths, and that is indeed of type
> gfc_charlen_type_node.

Understood, thanks.


> I think when the dust settles, I might make sense to get rid of
> gfc_charlen_type_node/gfc_charlen_type and just use
> size_type_node/size_t also for string lengths, but at least for now I
> think it's clearer to use separate names.

I agree with keeping them for now.


> So strictly speaking it's not necessary, as long as
> gfc_charlen_type_node is a signed integer.
> 
> OTOH, if/when one wants to make gfc_charlen_type_node unsigned,
> perhaps some more far-reaching changes are needed and that work is not
> necessary anymore. Say, introducing BT_UNSIGNED_INTEGER (??) and
> teaching gfc_typespec to handle unsigned integers? Or maybe it's
> better to put a tree node specifying the type in the typespec and use
> that instead of the bt type + kind to tell what type it is?
> 
> Do you want me to remove that for the time being?

Let’s remove that, at least for now.


>> There are other cases (resolve.c, simplify.c) where you introduce a 
>> dependency on middle-end entities (tree.h, trans-types.h) in what are pure 
>> Fortran front-end stages. This breaks the separation that currently exists, 
>> and which I strongly think we should keep.
> 
> These changes are similar to the above, i.e. a check that uses
> get_type_static_bounds() and works also if gfc_charlen_type_node is
> changed to be an unsigned type.

OK then let’s remove them too.



> - Should I remove the so-far preliminary work to handle
> gfc_charlen_type_node being unsigned?

I think it makes more sense.


> - Should I fix the uses of mpz_{get,set}_{s,u}i?

I think so, otherwise there is little reason to break the ABI and not support 
long strings :)


>> - trans-types.h: why do we now need to include trans.h?
> 
> IIRC this was due to some of the new .c files including trans-types.h
> but not trans.h and failing to compile. AFAIU the convention is that
> headers should include whatever is necessary to use said header. So
> this is some latent bug that has been exposed by my other changes.

If, with the final version of the patch, you can remove it, please do. And if 
you don’t, please remove the trans.h includes from source files that already 
include trans-types.h

FX

Re: [PATCH] Add RejectNegative for a c option.

[Sandra Loosemore]

On 12/27/2016 09:26 AM, Martin Liška wrote:

Without RejectNegative one can cause an ICE in the compiler.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?
Martin


Any chance you can also fix the manual to fully document the
-fstrong-eval-order= form of the option?  It doesn't currently list
that or what the possible enum values are.  I assume
-fno-strong-eval-order is a synonym for -fstrong-eval-order=none ?

-Sandra

Re: [PATCH] Add support for Fuchsia (OS)

[Josh Conner via gcc-patches]

Ping^2?


On 12/19/16 10:05 AM, Josh Conner wrote:

Ping?


On 12/12/16 1:31 PM, Josh Conner wrote:

On 12/10/16 3:26 AM, Richard Earnshaw wrote:

On 08/12/16 22:55, Josh Conner wrote:

+arm*-*-fuchsia*)
+  tm_file="${tm_file} fuchsia.h arm/fuchsia-elf.h glibc-stdint.h"
+  tmake_file="${tmake_file} arm/t-bpabi"
+  ;;


This will leave the default cpu as arm7tdmi.  Is that what you want?
It's fine if it is, but if not, you should consider setting
target_cpu_cname here as well.


Mmm, probably not. Thanks for pointing that out.
I've attached an updated patch addressing all of the concerns so far.

OK for mainline?

Thanks -

Josh


2016-12-08  Joshua Conner

* config/arm/fuchsia-elf.h: New file.
* config/fuchsia.h: New file.
* config.gcc (*-*-fuchsia*): Set native_system_header_dir.
(aarch64*-*-fuchsia*, arm*-*-fuchsia*, x86_64-*-fuchsia*): Add to
targets.
* config.host: (aarch64*-*-fuchsia*, arm*-*-fuchsia*): Add to hosts.

[doc, committed] preprocessor documentation cleanup, part 3/n

[Sandra Loosemore]

This patch takes care of a leftover from the last installment of this 
series -- I'd missed that there was a duplicate entry for -x in 
cppopts.texi.  I've also moved -fno-show-column out of the preprocessor 
options and into the "Diagnostic Message Formatting Options" section, 
where people will be more likely to find it.


More shuffling around and refactoring of include files coming in the 
next installment.


-Sandra

2016-12-27  Sandra Loosemore  

	gcc/
	* doc/cppopts.texi: Delete redundant documentation for -x.  Move
	-fno-show-column documentation to...
	* doc/invoke.texi (Diagnostic Message Formatting Options):  ...here.
	Update the option summary.
Index: doc/cppopts.texi
===
--- doc/cppopts.texi	(revision 243928)
+++ doc/cppopts.texi	(working copy)
@@ -297,25 +297,6 @@ location.  The filename may be absolute
 current directory.
 
 @end ifclear
-@item -x c
-@itemx -x c++
-@itemx -x objective-c
-@itemx -x assembler-with-cpp
-@opindex x
-Specify the source language: C, C++, Objective-C, or assembly.  This has
-nothing to do with standards conformance or extensions; it merely
-selects which base syntax to expect.  If you give none of these options,
-cpp will deduce the language from the extension of the source file:
-@samp{.c}, @samp{.cc}, @samp{.m}, or @samp{.S}.  Some other common
-extensions for C++ and assembly are also recognized.  If cpp does not
-recognize the extension, it will treat the file as C; this is the most
-generic mode.
-
-@emph{Note:} Previous versions of cpp accepted a @option{-lang} option
-which selected both the language and the standards conformance level.
-This option has been removed, because it conflicts with the @option{-l}
-option.
-
 @item -I-
 @opindex I-
 Split the include path.  Any directories specified with @option{-I}
@@ -564,12 +545,6 @@ form @option{-fno-working-directory}.  I
 present in the command line, this option has no effect, since no
 @code{#line} directives are emitted whatsoever.
 
-@item -fno-show-column
-@opindex fno-show-column
-Do not print column numbers in diagnostics.  This may be necessary if
-diagnostics are being scanned by a program that does not understand the
-column numbers, such as @command{dejagnu}.
-
 @item -A @var{predicate}=@var{answer}
 @opindex A
 Make an assertion with the predicate @var{predicate} and answer
Index: doc/invoke.texi
===
--- doc/invoke.texi	(revision 243928)
+++ doc/invoke.texi	(working copy)
@@ -250,7 +250,8 @@ Objective-C and Objective-C++ Dialects}.
 -fdiagnostics-show-location=@r{[}once@r{|}every-line@r{]}  @gol
 -fdiagnostics-color=@r{[}auto@r{|}never@r{|}always@r{]}  @gol
 -fno-diagnostics-show-option -fno-diagnostics-show-caret @gol
--fdiagnostics-parseable-fixits -fdiagnostics-generate-patch}
+-fdiagnostics-parseable-fixits -fdiagnostics-generate-patch @gol
+-fno-show-column}
 
 @item Warning Options
 @xref{Warning Options,,Options to Request or Suppress Warnings}.
@@ -3546,6 +3547,12 @@ are printed.  For example:
 The diff may or may not be colorized, following the same rules
 as for diagnostics (see @option{-fdiagnostics-color}).
 
+@item -fno-show-column
+@opindex fno-show-column
+Do not print column numbers in diagnostics.  This may be necessary if
+diagnostics are being scanned by a program that does not understand the
+column numbers, such as @command{dejagnu}.
+
 @end table
 
 @node Warning Options

[PATCH, i386]: Require QImode intermediate for QImode mask register spill only for !TARGET_AVX512DQ.

[Uros Bizjak]

The patch also cleans relevant part of ix86_secondary_reload a bit.
true_regno does everything needed to determine if the operand is in
memory.

2016-12-27  Uros Bizjak  

* config/i386/i386.c (ix86_secondary_reload): Require QImode
intermediate for QImode mask register spill only for !TARGET_AVX512DQ.
Always use true_regnum to determine operand regno.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainline SVN.

Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 243932)
+++ config/i386/i386.c  (working copy)
@@ -39752,24 +39752,19 @@ ix86_secondary_reload (bool in_p, rtx x, reg_class
   /* QImode spills from non-QI registers require
  intermediate register on 32bit targets.  */
   if (mode == QImode
-  && (MAYBE_MASK_CLASS_P (rclass)
- || (!TARGET_64BIT && !in_p
- && INTEGER_CLASS_P (rclass)
- && MAYBE_NON_Q_CLASS_P (rclass
+  && ((!TARGET_64BIT && !in_p
+  && INTEGER_CLASS_P (rclass)
+  && MAYBE_NON_Q_CLASS_P (rclass))
+ || (!TARGET_AVX512DQ
+ && MAYBE_MASK_CLASS_P (rclass
 {
-  int regno;
+  int regno = true_regnum (x);
 
-  if (REG_P (x))
-   regno = REGNO (x);
-  else
-   regno = -1;
-
-  if (regno >= FIRST_PSEUDO_REGISTER || SUBREG_P (x))
-   regno = true_regnum (x);
-
   /* Return Q_REGS if the operand is in memory.  */
   if (regno == -1)
return Q_REGS;
+
+  return NO_REGS;
 }
 
   /* This condition handles corner case where an expression involving

Re: [PATCH] Fix late dwarf generated early from optimized out globals

[Andreas Tobler]

On 16.09.16 13:30, Richard Biener wrote:

On Thu, 15 Sep 2016, Richard Biener wrote:



This addresses sth I needed to address with the early LTO debug patches
(you might now figure I'm piecemail merging stuff from that patch).

When the cgraph code optimizes out a global we call the late_global_decl
debug hook to eventually add a DW_AT_const_value to its DIE (we don't
really expect a location as that will be invalid after optimizing out
and will be pruned).

With the early LTO debug patches I have introduced a early_dwarf_finished
flag (mainly for consistency checking) and I figured I can use that to
detect the call to the late hook during the early phase and provide
the following cleaned up variant of avoiding to create locations that
require later pruning (which doesn't work with emitting the early DIEs).

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

I verified it does the correct thing for a unit like

static const int i = 2;

(but ISTR we do have at least one testcase in the testsuite as well).

Will commit if testing finishes successfully.


Ok, so it showed issues when merging that back to early-LTO-debug.
Turns out in LTO we never call early_finish and thus early_dwarf_finished
was never set.  Also dwarf2out_late_global_decl itself is a better
place to constrain generating locations.

The following variant is in very late stage of testing.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
LTO bootstrap on x86_64-unknown-linux-gnu in stage3.  LTO bootstrap
with early-LTO-debug in stage3, bootstraped with early-LTO-debug,
testing in progress.


Any chance to backport this commit (r240228) to 6.x?
It fixes a bootstrap comparison issue on aarch64-*-freebsd*.
The aarch64-*-freebsd* port is not yet merged to 6.x and 5.4.x due to 
the bootstrap comparison failure I faced.


I did a bootstrap with a backport of this revision to 6.x on 
amd64-*-freebsd* and I did not see any issues.


TIA,
Andreas


2016-09-16  Richard Biener  

* dwarf2out.c (early_dwarf_finished): New global.
(set_early_dwarf::set_early_dwarf): Assert early_dwarf_finished
is false.
(dwarf2out_early_finish): Set early_dwarf_finished at the end,
if called from LTO exit early.
(dwarf2out_late_global_decl): When being during the early
debug phase do not add locations but only const value attributes.
Adjust the way we generate early DIEs for LTO.

lto/
* lto.c (lto_main): Invoke early_finish debug hook.

[PATCH] gcc-dg.exp: support more than one digit in relative line number notation

[David Malcolm]

In r240391 Jakub added relative line number notation (.+4 or .-1 etc)
for DejaGnu messages.

This patch tweaks the regex to allow relative line numbers containing
more than one digit (I ran into this with a test for a diagnostic
that issues multiple notes, for which I wanted to verify the
diagnostic_show_locus output, hence I had offsets > 9).

Successfully regression-tested (and bootstrapped) on x86_64-pc-linux-gnu;
adds 2 PASS results to gcc.sum.

OK for trunk?

gcc/testsuite/ChangeLog:
* gcc.dg/dg-test-1.c: Add tests of relative line specifications
with more than one digit.
* lib/gcc-dg.exp (process-message): Support more than one digit
in relative line specifications.
---
 gcc/testsuite/gcc.dg/dg-test-1.c | 24 
 gcc/testsuite/lib/gcc-dg.exp |  2 +-
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/dg-test-1.c b/gcc/testsuite/gcc.dg/dg-test-1.c
index ad67b24..c67f93b 100644
--- a/gcc/testsuite/gcc.dg/dg-test-1.c
+++ b/gcc/testsuite/gcc.dg/dg-test-1.c
@@ -16,3 +16,27 @@ void /* { dg-warning "unused 
parameter 'f'" "warn2" { target *-*-* } .+1 } */
 bar (int e, int f, int g, int h)/* { dg-warning "unused parameter 'g'" "warn3" 
{ target *-*-* } . } */
 {  /* { dg-warning "unused parameter 'h'" "warn4" 
{ target *-*-* } .-1 } */
 }
+
+
+/* Ensure that relative line numbers with more than one digit are supported.  
*/
+/* { dg-warning "unused parameter 'i'" "warn5" { target *-*-* } .+10 } */
+
+
+
+
+
+
+
+
+void
+baz (int i, int j)
+{
+}
+
+
+
+
+
+
+
+/* { dg-warning "unused parameter 'j'" "warn6" { target *-*-* } .-10 } */
diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index 6217272..a12357d 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -988,7 +988,7 @@ proc process-message { msgproc msgprefix dgargs } {
 
 # Handle relative line specification, .+1 or .-1 etc.
 if { [llength $dgargs] == 5
-&& [regsub "^\.\[+-\](\[0-9\])$" [lindex $dgargs 4] "\\1" num] } {
+&& [regsub "^\.\[+-\](\[0-9\]+)$" [lindex $dgargs 4] "\\1" num] } {
set num [expr [lindex $dgargs 0] [string index [lindex $dgargs 4] 1] 
$num]
set dgargs [lreplace $dgargs 4 4 $num]
 }
-- 
1.8.5.3

Re: [PATCH] gcc-dg.exp: support more than one digit in relative line number notation

[Mike Stump]

On Dec 27, 2016, at 2:51 PM, David Malcolm  wrote:
> 
> In r240391 Jakub added relative line number notation (.+4 or .-1 etc)
> for DejaGnu messages.
> 
> This patch tweaks the regex to allow relative line numbers containing
> more than one digit (I ran into this with a test for a diagnostic
> that issues multiple notes, for which I wanted to verify the
> diagnostic_show_locus output, hence I had offsets > 9).
> 
> Successfully regression-tested (and bootstrapped) on x86_64-pc-linux-gnu;
> adds 2 PASS results to gcc.sum.
> 
> OK for trunk?

Ok.

Re: [PATCH], Fix PowerPC ISA 3.0 word extract/insert thinkos

[Michael Meissner]

On Fri, Dec 23, 2016 at 04:34:10PM -0600, Segher Boessenkool wrote:
> On Fri, Dec 23, 2016 at 04:47:22PM -0500, Michael Meissner wrote:
> > I had two thinkos in my previous patches for ISA 3.0 (power9) support that 
> > both
> > relate to word extraction and insertion.
> > 
> > The first thinko was that I thought the index for the first byte in the 4 
> > bytes
> > to be extracted should be 0..11, when it should be 0..12.  If it isn't 
> > allowed
> > to be 12, you cannot extract the 32-bit word at the bottom of the vector
> > register.
> > 
> > The second thinko is where I was doing zeo extending of a 32-bit value 
> > within
> > a vector register, I used xxextractuw with a byte offset of 1 instead of 4.
> > 
> > I have done the usual bootstrap and make check with no regressions on these
> > patches.  Can I install them into the trunk?
> 
> Yes please.  It sounds like we need a few more testcases though?

Actually, since the test case was written at the time I made the thinko, the
original test case tested if 12 was illegal instead of 13.  I have adjusted the
test case.  I also forgot to adjust the check in rs6000.c for the bounds being
0..12 instead of 0..11.  I fixed that as well.  This is the patch that was
checked in:

[gcc]
2016-12-27  Michael Meissner  

* config/rs6000/predicates.md (const_0_to_12_operand): Rename
predicate and change test from 0..11 to 0..12 to match the
semantics of the word extract/insert instructions.  Change all
callers.
(const_0_to_11_operand): Likewise.
* config/rs6000/rs6000.c (altivec_expand_builtin): Likewise.
* config/rs6000/vsx.md (vextract4b): Likewise.
(vextract4b_internal): Likewise.
(vinsert4b): Likewise.
(vinsert4b_internal): Likewise.
(vinsert4b_di): Likewise.
(vinsert4b_di_internal): Likewise.
* config/rs6000/rs6000.md (zero_extendsi2): Fix offset used
in xxextractuw to zero extend the word in the vector registers.
(lfiwzx): Likewise.

[gcc/testsuite]
2016-12-27  Michael Meissner  

* gcc.target/powerpc/p9-vinsert4b-2.c: Update test to test for 13
being out of bounds instead of 12.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/predicates.md
===
--- gcc/config/rs6000/predicates.md (revision 243943)
+++ gcc/config/rs6000/predicates.md (working copy)
@@ -211,9 +211,9 @@ (define_predicate "const_0_to_7_operand"
(match_test "IN_RANGE (INTVAL (op), 0, 7)")))
 
 ;; Match op = 0..11
-(define_predicate "const_0_to_11_operand"
+(define_predicate "const_0_to_12_operand"
   (and (match_code "const_int")
-   (match_test "IN_RANGE (INTVAL (op), 0, 11)")))
+   (match_test "IN_RANGE (INTVAL (op), 0, 12)")))
 
 ;; Match op = 0..15
 (define_predicate "const_0_to_15_operand"
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 243943)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -15839,9 +15839,9 @@ altivec_expand_builtin (tree exp, rtx ta
   if (arg1 == error_mark_node)
return expand_call (exp, target, false);
 
-  if (TREE_CODE (arg1) != INTEGER_CST || TREE_INT_CST_LOW (arg1) > 11)
+  if (TREE_CODE (arg1) != INTEGER_CST || TREE_INT_CST_LOW (arg1) > 12)
{
- error ("second argument to vec_vextract4b must 0..11");
+ error ("second argument to vec_vextract4b must 0..12");
  return expand_call (exp, target, false);
}
   break;
@@ -15856,9 +15856,9 @@ altivec_expand_builtin (tree exp, rtx ta
   if (arg2 == error_mark_node)
return expand_call (exp, target, false);
 
-  if (TREE_CODE (arg2) != INTEGER_CST || TREE_INT_CST_LOW (arg2) > 11)
+  if (TREE_CODE (arg2) != INTEGER_CST || TREE_INT_CST_LOW (arg2) > 12)
{
- error ("third argument to vec_vinsert4b must 0..11");
+ error ("third argument to vec_vinsert4b must 0..12");
  return expand_call (exp, target, false);
}
   break;
Index: gcc/config/rs6000/vsx.md
===
--- gcc/config/rs6000/vsx.md(revision 243943)
+++ gcc/config/rs6000/vsx.md(working copy)
@@ -3813,7 +3813,7 @@ (define_insn "vextuwrx"
 (define_expand "vextract4b"
   [(set (match_operand:DI 0 "gpc_reg_operand")
(unspec:DI [(match_operand:V16QI 1 "vsx_register_operand")
-   (match_operand:QI 2 "const_0_to_11_operand")]
+   (match_operand:QI 2 "const_0_to_12_operand")]
   UNSPEC_XXEXTRACTUW))]
   "TARGET_P9_VECTOR"
 {
@@ -3824,7 +3824,7 @@ (define_expand "vextract4b"
 (define_insn_and_split "*vextract4b_internal"
   [(set (match_operand:DI 0 "gpc_reg_operand" "=wj,r")
(unspec:DI [(ma

Re: [wwwdocs] Remove Java

[Gerald Pfeifer]

On Mon, 5 Dec 2016, Gerald Pfeifer wrote:
> Applied now, and more changes to follow later.

Applied.

Gerald

Remove further GCJ related pages, including how to use GCJ, how to
contribute, how to debug it, references to docs and projects done
with it, and open projects.

Index: java/compile.html
===
RCS file: java/compile.html
diff -N java/compile.html
--- java/compile.html   31 Oct 2002 14:47:43 -  1.6
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,168 +0,0 @@
-
-
-
-Compiling with GCJ
-
-
-
-
-Compiling with GCJ
-
-Introduction
-
-GCJ works in three ways: First GCJ can take .java files as
-  input and compile architecture-specific object files. Second, by
-  using the -C option, GCJ can take .java files as input, and
-  generate .class files. Third, GCJ can take .class files as input
-  to create architecture-specific object files.
-
-GCJ offers two run-time support libraries, libgcj and libgcjgc.
-  libgcj is a clean-room implementation of the core Java
-  libraries.  libgcjgc is the garbage collector, which is
-  responsible for automatic memory management. This collector is
-  based on the Boehm-Weiser conservative collector, but it scans
-  Java objects precisely and has changes to work with the
-  cooperative threads-package. It uses a basic mark-sweep
-  algorithm to perform the actual collections, stopping all
-  threads as it works.
-
-Compiling Java Programs
-
-If you are working with Java, we recommend you use the gcj program
-instead of using GCC directly.
-
-Java-specific file extensions
-
-GCJ (GNU Compiler for Java) deals with the following Java-specific
-file extensions, and you can specify any of these as an input file:
-
-
-  .java
-  A source file in the Java language, consisting of one or more class 
-   definitions.
-
-  .class
-A binary file containing bytecode instructions and information
-pertaining to a single class. It can be loaded into and executed by a
-Java Virtual Machine. Compiling a .java source file results in one or
-more .class files, one for each class definition in the source
-file. The .class file format was designed as a portable and secure
-representation of Java classes, but there also exist tools for
-compiling program written in other languages (such as Ada, Scheme, and
-ML) into .class files.
-
-.zip
-The .zip file format is a file archival and compression format popular
-in the PC world. In the Java world it is mainly used to bundle a
-collection of .class files. When specified on the gcj command line,
-gcj compiles all the .class files in the .zip archive. The result is a
-single assembly file, object file, or executable, depending on the
-options you specify.
-
-.jar
-A .jar (Java ARchive) file is in .zip format, but following
-certainly extra conventions. (Certain extra files should also be
-included.)  GCJ treats it the same as a .zip file.
-
-
-
-GCJ command-line options
-
-In addition to the normal GCC options, GCJ recognizes the following
-options:
-
-
--C
-The input file(s) must all be .java source files. They are compiled
-into portable .class files. No machine code (.o files or executable)
-is generated.
-
---output-class-dir=OUTPUTDIR
-When used with -C, specifies which directory the generated .class
-should be written to. A class A.B (whose input file is usually
-A/B.java) would be written to OUTPUTDIR/A/B.class.
-
--d OUTPUTDIR
-Synonym for --output-class-directory, for compatibility with Suns
-javac.
-
---bounds-check
-When compiling to machine code, emit instructions to check that array
-indexes are within bounds, and to throw an exception if they are
-not. This is the default.
-
---no-bounds-check
-When compiling to machine code, do not emit instructions to check that
-array indexes are within bounds.
-
--M
--MM
--MD
--MMD
-These options work as with the C compiler. For GCJs purposes, a system
-header is any .zip file installed as part of the compiler system.
-
---main=CLASSNAME
-When linking an application, generate a stub so the application starts
-executing with the main method of the class named. (This option is
-ignored if you are only compiling and not linking.)
-
-
-
-Path searching options
-
-At compile time, GCJ uses a list of paths to search for classes and
-packages that it needs to find. This list is called the
-classpath. Each element of the classpath can be either a directory or
-the name of a .zip or .jar file. In the latter case, GCJ searches the
-contents of the file for the required information.  GCJ has a built-in
-classpath, which includes the directory ., and the system libgcj.zip
-file, which holds classes from the standard Java class libraries, such
-as java.lang.  There are several ways to set or augment the
-classpath.
-
-
--I directory
-A directory (or file) specified using -I are prepended to the
-classpath. -I options are never overridden by the other options listed
-below.

[wwwdocs] Remove GCJ / java/ reference from frontends.html

[Gerald Pfeifer]

Applied.

Gerald

Index: frontends.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/frontends.html,v
retrieving revision 1.39
diff -u -r1.39 frontends.html
--- frontends.html  3 Dec 2013 01:04:41 -   1.39
+++ frontends.html  28 Dec 2016 00:54:27 -
@@ -9,8 +9,7 @@
 
 Currently the main GCC distribution contains front ends for C
 (gcc), C++ (g++), Objective C,
-Fortran, Java (GCJ), Ada (GNAT), and Go.
+Fortran, Ada (GNAT), and Go.
 
 There are several more front ends for different languages that have
 been written for GCC but not yet integrated into the main distribution

[wwwdocs] Remove GCJ/libgcj link from news/javaannounce.html

[Gerald Pfeifer]

Applied.

Gerald

Index: news/javaannounce.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/news/javaannounce.html,v
retrieving revision 1.6
diff -u -r1.6 javaannounce.html
--- news/javaannounce.html  3 Jul 2014 19:02:10 -   1.6
+++ news/javaannounce.html  28 Dec 2016 01:35:09 -
@@ -29,8 +29,7 @@
 suite of free software tools for compiled Java.
 
 For instructions on downloading and installation, and for more
-information on gcj and libgcj in general, see the
-Gcj and Libgcj homepage.
+information on gcj and libgcj in general, see the homepage.
 
 
 

[wwwdocs] en.wikibooks.org now uses https

[Gerald Pfeifer]

Applied.

Gerald

Index: readings.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
retrieving revision 1.253
diff -u -r1.253 readings.html
--- readings.html   23 Aug 2016 07:21:36 -  1.253
+++ readings.html   28 Dec 2016 01:53:13 -
@@ -23,7 +23,7 @@
   http://www.network-theory.co.uk/gcc/intro/";>An Introduction
   to GCC by Brian J. Gough.
 
-  http://en.wikibooks.org/wiki/GNU_C_Compiler_Internals";>GNU C 
Compiler Internals (Wikibook), numerous contributors.
+  https://en.wikibooks.org/wiki/GNU_C_Compiler_Internals";>GNU C 
Compiler Internals (Wikibook), numerous contributors.
 
   http://www.immerundewig.at/thesis/";>Compilation
   of Functional Programming Languages using GCC -- Tail Calls

[doc, committed] split up cppopts.texi

[Sandra Loosemore]

This patch splits up cppopts.texi into 3 pieces. Moving the include path 
options and warning options into separate files allows those parts to be 
included in more appropriate places in the GCC manual.  Previously, for 
instance, some of the include path options were listed as preprocessor 
options, some were listed as directory options (and only in the GCC 
manual), and some were listed in both places; now they all appear as 
directory options in the GCC manual, and all appear in the CPP manual 
too.  I've corrected the option summary lists to add many missing 
options, and sorted the list of preprocessor options.


This is the last piece of reorganization/refactoring I've been planning 
in this series, although as I've been working on moving things around 
I've realized that the descriptive text for several of the options needs 
cleanup and correction as well.  So there will be more installments coming.


-Sandra

2016-12-27  Sandra Loosemore  

	gcc/
	* doc/cppdiropts.texi, doc/cppwarnopts.texi:  New files, split from...
	* doc/cppopts.texi:  here.
	* doc/cpp.texi (Invocation): Adjust includes.
	* doc/invoke.texi (Option Summary): Add missing preprocesor-related
	options.  Adjust sorting and formatting.
	(Warning Options): Include cppwarnopts.texi.
	(Preprocessor Options): Add pointers and list the specific 
	preprocessor options from cppopts.texi first instead of last.
	(Directory Options): Move/merge documentation of -I, -iquote, and
	-I- to cppdiropts.texi.  Include that file here.
Index: gcc/doc/cppdiropts.texi
===
--- gcc/doc/cppdiropts.texi	(nonexistent)
+++ gcc/doc/cppdiropts.texi	(working copy)
@@ -0,0 +1,135 @@
+@c Copyright (C) 1999-2016 Free Software Foundation, Inc.
+@c This is part of the CPP and GCC manuals.
+@c For copying conditions, see the file gcc.texi.
+
+@c -
+@c Options affecting include directory search in the preprocessor
+@c -
+
+@c If this file is included with the flag ``cppmanual'' set, it is
+@c formatted for inclusion in the CPP manual; otherwise the main GCC manual.
+
+@item -I @var{dir}
+@opindex I
+Add the directory @var{dir} to the list of directories to be searched
+for header files.
+@ifset cppmanual
+@xref{Search Path}.
+@end ifset
+If you use more than
+one @option{-I} option, the directories are scanned in left-to-right
+order; the standard system directories come after.
+
+This can be used to override a system header
+file, substituting your own version, since these directories are
+searched before the system header file directories.  However, you should
+not use this option to add directories that contain vendor-supplied
+system header files (use @option{-isystem} for that).
+
+If a standard system include directory, or a directory specified with
+@option{-isystem}, is also specified with @option{-I}, the @option{-I}
+option is ignored.  The directory is still searched but as a
+system directory at its normal position in the system include chain.
+This is to ensure that GCC's procedure to fix buggy system headers and
+the ordering for the @code{include_next} directive are not inadvertently changed.
+If you really need to change the search order for system directories,
+use the @option{-nostdinc} and/or @option{-isystem} options.
+@ifset cppmanual
+@xref{System Headers}.
+@end ifset
+
+If @var{dir} begins with @code{=}, then the @code{=} is replaced
+by the sysroot prefix; see @option{--sysroot} and @option{-isysroot}.
+
+@item -iquote @var{dir}
+@opindex iquote
+Search @var{dir} only for header files requested with
+@code{@w{#include "@var{file}"}}; they are not searched for
+@code{@w{#include <@var{file}>}}, before all directories specified by
+@option{-I} and before the standard system directories.
+@ifset cppmanual
+@xref{Search Path}.
+@end ifset
+If @var{dir} begins with @code{=}, then the @code{=} is replaced
+by the sysroot prefix; see @option{--sysroot} and @option{-isysroot}.
+
+@item -isystem @var{dir}
+@opindex isystem
+Search @var{dir} for header files, after all directories specified by
+@option{-I} but before the standard system directories.  Mark it
+as a system directory, so that it gets the same special treatment as
+is applied to the standard system directories.
+@ifset cppmanual
+@xref{System Headers}.
+@end ifset
+If @var{dir} begins with @code{=}, then the @code{=} is replaced
+by the sysroot prefix; see @option{--sysroot} and @option{-isysroot}.
+
+@item -I-
+@opindex I-
+Split the include path.
+This option has been deprecated.  Please use @option{-iquote} instead for
+@option{-I} directories before the @option{-I-} and remove the @option{-I-}
+option.
+
+Any directories specified with @option{-I}
+options before @option{-I-} are searched only for headers requested with
+@code{@w{#include "@var{file}"}}; they are not searched for
+@code{@w