Re: [PATCH] Fix EQ_ATTR_ALT size calculation (PR bootstrap/87417)

[Richard Sandiford]

Ilya Leoshkevich  writes:
> Bootstrap and regtest running on s390x-redhat-linux.
>
> "r264537: Change EQ_ATTR_ALT to support up to 64 alternatives" changed
> the format of EQ_ATTR_ALT from ii to ww.  This broke the bootstrap on
> 32-bit systems, because the formula for rtx_code_size assumed that only
> certain codes contain HOST_WIDE_INTs.  This did not surface on 64-bit
> systems, because rtunion is 8 bytes anyway, but on 32-bit systems it's
> only 4 bytes.  This resulted in out-of-bounds writes and memory
> corruptions in genattrtab.
>
> gcc/ChangeLog:
>
> 2018-09-24  Ilya Leoshkevich  
>
>   PR bootstrap/87417
>   * rtl.c (rtx_code_size): Take into account that EQ_ATTR_ALT
>   contains HOST_WIDE_INTs when computing its size.

OK.  Thanks for the quick fix.

Richard

> ---
>  gcc/rtl.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/gcc/rtl.c b/gcc/rtl.c
> index f9146afcf2c..ca5c25c422f 100644
> --- a/gcc/rtl.c
> +++ b/gcc/rtl.c
> @@ -110,8 +110,7 @@ const enum rtx_class rtx_class[NUM_RTX_CODE] = {
>  
>  const unsigned char rtx_code_size[NUM_RTX_CODE] = {
>  #define DEF_RTL_EXPR(ENUM, NAME, FORMAT, CLASS)  
> \
> -  (((ENUM) == CONST_INT || (ENUM) == CONST_DOUBLE\
> -|| (ENUM) == CONST_FIXED || (ENUM) == CONST_WIDE_INT)\
> +  ((FORMAT)[0] == 'w'
> \
> ? RTX_HDR_SIZE + (sizeof FORMAT - 1) * sizeof (HOST_WIDE_INT) \
> : (ENUM) == REG   \
> ? RTX_HDR_SIZE + sizeof (reg_info)
> \

Re: [PATCH v4 01/10] Initial TI PRU GCC port

[Dimitar Dimitrov]

On Monday, 9/24/2018 11:38:23 EEST Richard Sandiford wrote:
> Dimitar Dimitrov  writes:
> > On Thursday, 9/13/2018 13:02:21 EEST Richard Sandiford wrote:
> >> Dimitar Dimitrov  writes:
> >> > +/* Callback for walk_gimple_seq that checks TP tree for TI ABI
> >> > compliance.  */ +static tree
> >> > +check_op_callback (tree *tp, int *walk_subtrees, void *data)
> >> > +{
> >> > +  struct walk_stmt_info *wi = (struct walk_stmt_info *) data;
> >> > +
> >> > +  if (RECORD_OR_UNION_TYPE_P (*tp) || TREE_CODE (*tp) ==
> >> > ENUMERAL_TYPE)
> >> > +{
> >> > +  /* Forward declarations have NULL tree type.  Skip them.  */
> >> > +  if (TREE_TYPE (*tp) == NULL)
> >> > +return NULL;
> >> > +}
> >> > +
> >> > +  /* TODO - why C++ leaves INTEGER_TYPE forward declarations around? 
> >> > */
> >> > +  if (TREE_TYPE (*tp) == NULL)
> >> > +return NULL;
> >> > +
> >> > +  const tree type = TREE_TYPE (*tp);
> >> > +
> >> > +  /* Direct function calls are allowed, obviously.  */
> >> > +  if (TREE_CODE (*tp) == ADDR_EXPR && TREE_CODE (type) ==
> >> > POINTER_TYPE)
> >> > +{
> >> > +  const tree ptype = TREE_TYPE (type);
> >> > +  if (TREE_CODE (ptype) == FUNCTION_TYPE)
> >> > +return NULL;
> >> > +}
> >> 
> >> This seems like a bit of a dangerous heuristic.  Couldn't it also cause
> >> 
> >> us to skip things like:
> >>(void *) func
> >> 
> >> ?  (OK, that's dubious C, but we do support it.)
> > 
> > The cast yields a "data pointer", which is 32 bits for both types of ABI.
> > Hence it is safe to skip "(void *) func".
> > 
> > The TI ABI's 16 bit function pointers become a problem when they change
> > the
> > layout of structures and function argument registers.
> 
> OK.  The reason this stood out is that the code doesn't obviously match
> the comment.  If the code is just trying to skip direct function calls,
> I think the gcall sequence I mentioned would be more obvious, and would
> match the existing comment.  If anything that takes the address of a
> function is OK then it might be worth changing the comment to include that.
I will use your suggested gcall snippet since it is safe and obvious. The 
comment matches my original intent.


> >> > +/* Implement TARGET_PREFERRED_RELOAD_CLASS.  */
> >> > +static reg_class_t
> >> > +pru_preferred_reload_class (rtx x ATTRIBUTE_UNUSED, reg_class_t
> >> > regclass)
> >> > +{
> >> > +  return regclass == NO_REGS ? GENERAL_REGS : regclass;
> >> > +}
> >> 
> >> This looks odd: PREFERRED_RELOAD_CLASS should return a subset of the
> >> original class rather than add new registers.  Can you remember why
> >> it was needed?
> > 
> > I'm not sure what target code is supposed to return when NO_REGS is passed
> > here. I saw how other ports handle NO_REGS (c-sky, m32c, nios2, rl78). So
> > I
> > followed suite.
> > 
> > Here is a backtrace of LRA when NO_REGS is passed:
> > 0xf629ae pru_preferred_reload_class
> > 
> > ../../gcc/gcc/config/pru/pru.c:788
> > 
> > 0xa3d6e8 process_alt_operands
> > 
> > ../../gcc/gcc/lra-constraints.c:2600
> > 
> > 0xa3ef7d curr_insn_transform
> > 
> > ../../gcc/gcc/lra-constraints.c:3889
> > 
> > 0xa4301e lra_constraints(bool)
> > 
> > ../../gcc/gcc/lra-constraints.c:4906
> > 
> > 0xa2726c lra(_IO_FILE*)
> > 
> > ../../gcc/gcc/lra.c:2446
> > 
> > 0x9c97a9 do_reload
> > 
> > ../../gcc/gcc/ira.c:5469
> > 
> > 0x9c97a9 execute
> > 
> > ../../gcc/gcc/ira.c:5653
> 
> I think it should just pass NO_REGS through unmodified (which means
> spill to memory).  In some ways it would be good if it didn't have to
> handle this case, but again that's going to be work to fix.
> 
> The RA will pass ALL_REGS if it can handle any register, and wants to
> know what the target would prefer.  But for any input, the hook needs
> to stick within the registers it was given.

Thanks for the clarification. I will remove the PRU hook and will rely on the 
default implementation (i.e. return the given rclass).

> >> > +; LRA cannot cope with clobbered op2, hence the scratch register.
> >> > +(define_insn "ashr3"
> >> > +  [(set (match_operand:QISI 0 "register_operand""=,r")
> >> > +  (ashiftrt:QISI
> >> > +(match_operand:QISI 1 "register_operand""0,r")
> >> > +(match_operand:QISI 2 "reg_or_const_1_operand"  "r,P")))
> >> > +   (clobber (match_scratch:QISI 3   "=r,X"))]
> >> > +  ""
> >> > +  "@
> >> > +   mov %3, %2\;ASHRLP%=:\;qbeq ASHREND%=, %3, 0\; sub %3, %3, 1\;
> >> > lsr\\t%0, %0, 1\; qbbc ASHRLP%=, %0, (%S0 * 8) - 2\; set %0, %0, (%S0 *
> >> > 8) - 1\; jmp ASHRLP%=\;ASHREND%=: +   lsr\\t%0, %1, 1\;qbbc LSIGN%=,
> >> > %0,
> >> > (%S0 * 8) - 2\;set %0, %0, (%S0 * 8) - 1\;LSIGN%=:" +  [(set_attr
> >> > "type"
> >> > "complex,alu")
> >> > +   (set_attr "length" "28,4")])
> >> 
> >> What do you mean by LRA not coping?  What did you try originally and
> >> what went wrong?
> > 
> > Better assembly could 

Re: [PATCH] Cleanup strcpy/stpcpy no nul warning code

[Jeff Law]

On 9/24/18 12:18 PM, Bernd Edlinger wrote:
> On 09/24/18 19:48, Jeff Law wrote:
>> On 9/16/18 1:58 PM, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> this is a cleanup of the recently added strlen/strcpy/stpcpy
>>> no nul warning code.
>>>
>>> Most importantly it moves the SSA_NAME handling from
>>> unterminated_array to string_constant, thereby fixing
>>> another round of xfails in the strlen and stpcpy test cases.
>>>
>>> I need to say that the fix for bug 86622 is relying in
>>> type info on the pointer which is probably not safe in
>>> GIMPLE in the light of the recent discussion.
>>>
>>> I had to add two further exceptions, which should
>>> be safe in general: that is a pointer arithmentic on a string
>>> literal is okay, and arithmetic on a string constant
>>> that is exactly the size of the whole DECL, cannot
>>> access an adjacent member.
>>>
>>>
>>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>>> Is it OK for trunk?
>>>
>>>
>>> Thanks
>>> Bernd.
>>>
>>>
>>> patch-cleanup-no-nul.diff
>>>
>>> gcc:
>>> 2018-09-16  Bernd Edlinger  
>>>
>>> * builtins.h (unterminated_array): Remove prototype.
>>>  * builtins.c (unterminated_array): Simplify.  Make static.
>>>  (expand_builtin_strcpy_args): Don't use TREE_NO_WARNING here.
>>> (expand_builtin_stpcpy_1): Remove warn_string_no_nul without effect.
>>> * expr.c (string_constant): Handle SSA_NAME.  Add more exceptions
>>> where pointer arithmetic is safe.
>>> * gimple-fold.c (get_range_strlen): Handle nonstr like in c_strlen.
>>> (get_max_strlen): Remove the unnecessary mynonstr handling.
>>> (gimple_fold_builtin_strcpy): Simplify.
>>> (gimple_fold_builtin_stpcpy): Simplify.
>>> (gimple_fold_builtin_sprintf): Remove NO_WARNING propagation
>>> without effect.
>>> (gimple_fold_builtin_strlen): Simplify.
>> So my thinking right now is to go forward with the API change to allow
>> c_strlen to fill in a structure with relevant tidbits about the string.
>>
>> That in turn allows us to use simplify unterminated_array in a manner
>> similar to what you've done in your patch -- while carrying forward the
>> capabilities we need for Martin's nul terminator warnings.  This would
>> be combined with the expr.c chunks from your patch.
>>
> 
> Do you want me to elaborate that idea?
No need.  I've already got those bits here.

> 
>> However, most of the changes to drop NO_WARNING stuff should be handled
>> separately.  I don't think they're safe as-is.  I'm also pretty sure the
>> stpcpy changes in builtins.c aren't correct as-is.
>>
>>
> 
> Well, I think you must be referring to this:
> 
> @@ -3984,14 +3964,10 @@ expand_builtin_stpcpy_1 (tree exp, rtx target, mac
>   compile-time, not an expression containing a string.  This is
>   because the latter will potentially produce pessimized code
>   when used to produce the return value.  */
> -  tree nonstr = NULL_TREE;
> if (!c_getstr (src, NULL)
> - || !(len = c_strlen (src, 0, , 1)))
> + || !(len = c_strlen (src, 0)))
>  return expand_movstr (dst, src, target, /*endp=*/2);
> 
> -  if (nonstr && !TREE_NO_WARNING (exp))
> -   warn_string_no_nul (EXPR_LOCATION (exp), "stpcpy", src, nonstr);
> -
> lenp1 = size_binop_loc (loc, PLUS_EXPR, len, ssize_int (1));
> ret = expand_builtin_mempcpy_args (dst, src, lenp1,
>   target, exp, /*endp=*/2);
> 
> 
> My observation is: If that one is necessary and does not only emit some
> duplicated warnings, then the test case must be incomplete, at least it did 
> not
> regress when this code is removed.
I'm pretty sure the test is incomplete.

> 
> Maybe there could a better way than TREE_NO_WARNING to get rid
> of the duplicated warnings.
> 
> Maybe it will be best to concentrate the warnings on a single pass,
> which means expand will it not be, right?
COnceptually getting all the warnings out of the folder is a good start,
but insufficient.  You'd need to look at the thread for the duplicated
warnings due to how the expanders call into each other.

jeff

[PATCH] RISC-V: Fix problems with ilp32e ABI support.

[Jim Wilson]

Using -march=rv32i -mabi=ilp32e causes the high registers to be accidentally
used in the calling convention.  This is a problem with ABI related macros
checking the architecture for RVE support instead of the ABI for ilp32e
support, which is easy to fix.

This was tested with cross riscv32-elf builds using arch/abi combinations of
rv32i/ilp32 and rv32e/ilp32e.  There were no regressions.  This was also tested
by hand on the tescase in the PR to verify the right result.

gcc/
PR target/87391
* config/riscv/riscv.h (STACK_BOUNDARY): Test riscv_abi == ABI_ILP32E
not TARGET_RVE.
(ABI_STACK_BOUNDARY, MAX_ARGS_IN_REGISTERS): Likewise.
---
 gcc/config/riscv/riscv.h | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
index 5651d1727f8..4bbb491ac87 100644
--- a/gcc/config/riscv/riscv.h
+++ b/gcc/config/riscv/riscv.h
@@ -126,10 +126,11 @@ along with GCC; see the file COPYING3.  If not see
 #define FUNCTION_BOUNDARY (TARGET_RVC ? 16 : 32)
 
 /* The smallest supported stack boundary the calling convention supports.  */
-#define STACK_BOUNDARY (TARGET_RVE ? BITS_PER_WORD : 2 * BITS_PER_WORD)
+#define STACK_BOUNDARY \
+  (riscv_abi == ABI_ILP32E ? BITS_PER_WORD : 2 * BITS_PER_WORD)
 
 /* The ABI stack alignment.  */
-#define ABI_STACK_BOUNDARY (TARGET_RVE ? BITS_PER_WORD : 128)
+#define ABI_STACK_BOUNDARY (riscv_abi == ABI_ILP32E ? BITS_PER_WORD : 128)
 
 /* There is no point aligning anything to a rounder boundary than this.  */
 #define BIGGEST_ALIGNMENT 128
@@ -492,7 +493,7 @@ enum reg_class
 #define GP_RETURN GP_ARG_FIRST
 #define FP_RETURN (UNITS_PER_FP_ARG == 0 ? GP_RETURN : FP_ARG_FIRST)
 
-#define MAX_ARGS_IN_REGISTERS (TARGET_RVE ? 6 : 8)
+#define MAX_ARGS_IN_REGISTERS (riscv_abi == ABI_ILP32E ? 6 : 8)
 
 /* Symbolic macros for the first/last argument registers.  */
 
-- 
2.17.1

Merge from trunk to gccgo branch

[Ian Lance Taylor]

I merged trunk revision 264547 to the gccgo branch.

Ian

[Committed] Fix -mcpu=thunderx and -mcpu=thunderx2t99

[Andrew Pinski]

Hi,
  When Naveen committed the following patch:
2017-06-29  Naveen H.S  

* config/aarch64/aarch64.c (aarch_macro_fusion_pair_p): Push the
check for CC usage into AARCH64_FUSE_CMP_BRANCH.
* config/i386/i386.c (ix86_macro_fusion_pair_p): Push the check for
CC usage from generic code to here.
* sched-deps.c (sched_macro_fuse_insns): Move the condition for
CC usage into the target macros.

He made a small mistake and accessed prev before checking it was NULL
in the AARCH64_FUSE_CMP_BRANCH case.  This patch fixes the problem.
Committed to both the trunk and the GCC 8 branch.

Thanks,
Andrew Pinski

ChangeLog:
2018-09-24  Andrew Pinski  
*  config/aarch64/aarch64.c (aarch_macro_fusion_pair_p): Don't access
prev before checking it for NULLness in the AARCH64_FUSE_CMP_BRANCH
case.
Index: config/aarch64/aarch64.c
===
--- config/aarch64/aarch64.c(revision 264547)
+++ config/aarch64/aarch64.c(working copy)
@@ -16510,8 +16510,6 @@ aarch_macro_fusion_pair_p (rtx_insn *pre
   if (aarch64_fusion_enabled_p (AARCH64_FUSE_CMP_BRANCH)
   && any_condjump_p (curr))
 {
-  enum attr_type prev_type = get_attr_type (prev);
-
   unsigned int condreg1, condreg2;
   rtx cc_reg_1;
   aarch64_fixed_condition_code_regs (, );
@@ -16521,6 +16519,8 @@ aarch_macro_fusion_pair_p (rtx_insn *pre
  && prev
  && modified_in_p (cc_reg_1, prev))
{
+ enum attr_type prev_type = get_attr_type (prev);
+
  /* FIXME: this misses some which is considered simple arthematic
 instructions for ThunderX.  Simple shifts are missed here.  */
  if (prev_type == TYPE_ALUS_SREG

Re: [PATCH 08/14] Add D2 Testsuite files.

[Iain Buclaw]

On 24 September 2018 at 20:28, Mike Stump  wrote:
> On Sep 21, 2018, at 2:38 PM, Iain Buclaw  wrote:
>>
>> On 21 September 2018 at 22:54, Mike Stump  wrote:
>>> On Sep 17, 2018, at 5:36 PM, Iain Buclaw  wrote:

 This patch adds part of the D2 testsuite, which includes D source code
 files that are considered compilable; files that are considered
 uncompilable, but should not ICE; and files that should execute on
 targets with crash or assertion failures.
>>>
>>> Ok.  [ not needed, you can self-review things like this no problem ]
>>>
>>> I see you are sneaking in Alice in Wonderland...
>>>
>>
>> I had forgotten about that test.  I recall another project written in
>> D (Dustmite) ran into some trouble with Debian due to the Project
>> Gutenberg small print, which they ended up removing.
>>
>> The "small print" section in the text file says:
>>
>>DISTRIBUTION UNDER "PROJECT GUTENBERG-tm"
>>You may distribute copies of this etext electronically, or by
>>disk, book or any other medium if you either delete this
>>"Small Print!" and all other references to Project Gutenberg,
>>or:
>>[...]
>>
>> I'll look into convincing upstream to also do the same.
>
> Oh, if you know of any reason why a file cannot be distributed, you cannot 
> check that in ever.  So, you must resolve any outstanding issues before 
> committing.   So, if Gutenberg has restrictions on distribution, you have to 
> resolve those first, before it hit git.
>
> If it had hit git, please either remove such for now until resolved, or 
> resolve any issues.  Thanks.

As I said a day later, I've pushed the removal of in upstream and have
propagated it down.  Thanks for noticing though, had you not mentioned
Alice, I would not have had remembered the trouble Dustmite had with
Debian in the first place.

Iain

[libstdc++,doc] doc/xml/manual/codecvt.xml: Move link to "UTF-8 and Unicode FAQ" to https

[Gerald Pfeifer]

Committed.

Gerald

2018-09-25  Gerald Pfeifer  

* doc/xml/manual/codecvt.xml: Move link to "UTF-8 and Unicode FAQ"
to https.

Index: doc/xml/manual/codecvt.xml
===
--- doc/xml/manual/codecvt.xml  (revision 264546)
+++ doc/xml/manual/codecvt.xml  (working copy)
@@ -673,7 +673,7 @@
   
   
http://www.w3.org/1999/xlink;
- xlink:href="http://www.cl.cam.ac.uk/~mgk25/unicode.html;>
+ xlink:href="https://www.cl.cam.ac.uk/~mgk25/unicode.html;>
   UTF-8 and Unicode FAQ for Unix/Linux

   

[wwwdocs] Tweak hierarchy of headings in gcc-5/porting_to.html

[Gerald Pfeifer]

While working on the porting_to.html guides for later versions, I
noticed that the Links heading was at the wrong level ( instead
of ).

Fixed thusly; committed.

Gerald

Index: gcc-5/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/porting_to.html,v
retrieving revision 1.14
diff -u -r1.14 porting_to.html
--- gcc-5/porting_to.html   1 Sep 2018 23:42:06 -   1.14
+++ gcc-5/porting_to.html   24 Sep 2018 21:53:57 -
@@ -428,7 +428,8 @@
 return static_castY(y);.
 
 
-Links
+
+Links
 
 
 Marek Polacek and Jakub Jelinek,

[wwwdocs] Fix a link to intel.com on readings.html

[Gerald Pfeifer]

Committed.

Gerald

Index: readings.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
retrieving revision 1.301
diff -u -r1.301 readings.html
--- readings.html   23 Sep 2018 15:21:34 -  1.301
+++ readings.html   24 Sep 2018 21:51:03 -
@@ -231,7 +231,7 @@
  
  Nios II
   Manufacturer: Intel (formerly Altera)
-  https://www.intel.com/content/www/us/en/programmable/products/processors/support.html/;>Nios
 II Processor Documentation
+  https://www.intel.com/content/www/us/en/programmable/products/processors/support.html;>Nios
 II Processor Documentation
  
  
  pa

[PATCH] Fix EQ_ATTR_ALT size calculation (PR bootstrap/87417)

[Ilya Leoshkevich]

Bootstrap and regtest running on s390x-redhat-linux.

"r264537: Change EQ_ATTR_ALT to support up to 64 alternatives" changed
the format of EQ_ATTR_ALT from ii to ww.  This broke the bootstrap on
32-bit systems, because the formula for rtx_code_size assumed that only
certain codes contain HOST_WIDE_INTs.  This did not surface on 64-bit
systems, because rtunion is 8 bytes anyway, but on 32-bit systems it's
only 4 bytes.  This resulted in out-of-bounds writes and memory
corruptions in genattrtab.

gcc/ChangeLog:

2018-09-24  Ilya Leoshkevich  

PR bootstrap/87417
* rtl.c (rtx_code_size): Take into account that EQ_ATTR_ALT
contains HOST_WIDE_INTs when computing its size.
---
 gcc/rtl.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gcc/rtl.c b/gcc/rtl.c
index f9146afcf2c..ca5c25c422f 100644
--- a/gcc/rtl.c
+++ b/gcc/rtl.c
@@ -110,8 +110,7 @@ const enum rtx_class rtx_class[NUM_RTX_CODE] = {
 
 const unsigned char rtx_code_size[NUM_RTX_CODE] = {
 #define DEF_RTL_EXPR(ENUM, NAME, FORMAT, CLASS)
\
-  (((ENUM) == CONST_INT || (ENUM) == CONST_DOUBLE  \
-|| (ENUM) == CONST_FIXED || (ENUM) == CONST_WIDE_INT)  \
+  ((FORMAT)[0] == 'w'  \
? RTX_HDR_SIZE + (sizeof FORMAT - 1) * sizeof (HOST_WIDE_INT)   \
: (ENUM) == REG \
? RTX_HDR_SIZE + sizeof (reg_info)  \
-- 
2.19.0

libgo patch committed: Update to 1.11 release

[Ian Lance Taylor]

I've committed a patch to update libgo to the 1.11 release.  As usual
for these updates, the patch is too large to attach to this e-mail
message.  I've attached some of the more relevant directories.  This
update required some minor patches to the gotools directory and the Go
testsuite, also included here.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian

2018-09-24  Ian Lance Taylor  

* Makefile.am (mostlyclean-local): Run chmod on check-go-dir to
make sure it is writable.
(check-go-tools): Likewise.
(check-vet): Copy internal/objabi to check-vet-dir.
* Makefile.in: Rebuild.
Index: libgo/MERGE
===
--- libgo/MERGE (revision 264542)
+++ libgo/MERGE (working copy)
@@ -1,4 +1,4 @@
-fe8a0d12b14108cbe2408b417afcaab722b0727c
+41e62b8c49d21659b48a95216e3062032285250f
 
 The first line of this file holds the git revision number of the
 last merge done from the master library sources.
Index: libgo/VERSION
===
--- libgo/VERSION   (revision 264542)
+++ libgo/VERSION   (working copy)
@@ -1 +1 @@
-go1.10.3
+go1.11
Index: libgo/Makefile.am
===
--- libgo/Makefile.am   (revision 264542)
+++ libgo/Makefile.am   (working copy)
@@ -541,6 +541,7 @@ s-objabi: Makefile
echo 'const defaultGO386 = `sse2`' >> objabi.go.tmp
echo 'const defaultGOARM = `5`' >> objabi.go.tmp
echo 'const defaultGOMIPS = `hardfloat`' >> objabi.go.tmp
+   echo 'const defaultGOMIPS64 = `hardfloat`' >> objabi.go.tmp
echo 'const defaultGOOS = runtime.GOOS' >> objabi.go.tmp
echo 'const defaultGOARCH = runtime.GOARCH' >> objabi.go.tmp
echo 'const defaultGO_EXTLINK_ENABLED = ``' >> objabi.go.tmp
@@ -608,7 +609,7 @@ noinst_DATA += zdefaultcc.go
 zstdpkglist.go: s-zstdpkglist; @true
 s-zstdpkglist: Makefile
rm -f zstdpkglist.go.tmp
-   echo 'package build' > zstdpkglist.go.tmp
+   echo 'package goroot' > zstdpkglist.go.tmp
echo "" >> zstdpkglist.go.tmp
echo 'var stdpkg = map[string]bool{' >> zstdpkglist.go.tmp
echo $(libgo_go_objs) 'unsafe.lo' 'runtime/cgo.lo' | sed 
's|[a-z0-9_/]*_c\.lo||g' | sed 's|\([a-z0-9_/]*\)\.lo|"\1": true,|g' >> 
zstdpkglist.go.tmp
@@ -707,6 +708,7 @@ PACKAGES = $(shell cat $(srcdir)/libgo-p
 libgo_go_objs = \
$(addsuffix .lo,$(PACKAGES)) \
bytes/index.lo \
+   internal/bytealg/bytealg.lo \
reflect/makefunc_ffi_c.lo \
strings/index.lo \
$(syscall_lib_clone_lo) \
@@ -718,7 +720,8 @@ libgo_go_objs = \
log/syslog/syslog_c.lo \
$(os_lib_inotify_lo) \
runtime/internal/atomic_c.lo \
-   sync/atomic_c.lo
+   sync/atomic_c.lo \
+   internal/cpu/cpu_gccgo.lo
 
 libgo_ldflags = \
-version-info $(libtool_VERSION) $(PTHREAD_CFLAGS) $(AM_LDFLAGS)
@@ -960,8 +963,8 @@ runtime_pprof_check_GOCFLAGS = -static-l
 extra_go_files_runtime_internal_sys = version.go
 runtime/internal/sys.lo.dep: $(extra_go_files_runtime_internal_sys)
 
-extra_go_files_go_build = zstdpkglist.go
-go/build.lo.dep: $(extra_go_files_go_build)
+extra_go_files_internal_goroot = zstdpkglist.go
+internal/goroot.lo.dep: $(extra_go_files_internal_goroot)
 
 extra_go_files_go_types = gccgosizes.go
 go/types.lo.dep: $(extra_go_files_go_types)
@@ -976,6 +979,16 @@ extra_check_libs_cmd_go_internal_cache =
 extra_check_libs_cmd_go_internal_generate = $(abs_builddir)/libgotool.a
 extra_check_libs_cmd_go_internal_get = $(abs_builddir)/libgotool.a
 extra_check_libs_cmd_go_internal_load = $(abs_builddir)/libgotool.a
+extra_check_libs_cmd_go_internal_imports = $(abs_builddir)/libgotool.a
+extra_check_libs_cmd_go_internal_modconv = $(abs_builddir)/libgotool.a
+extra_check_libs_cmd_go_internal_modfetch = $(abs_builddir)/libgotool.a
+extra_check_libs_cmd_go_internal_modfetch_codehost = 
$(abs_builddir)/libgotool.a
+extra_check_libs_cmd_go_internal_modfile = $(abs_builddir)/libgotool.a
+extra_check_libs_cmd_go_internal_modload = $(abs_builddir)/libgotool.a
+extra_check_libs_cmd_go_internal_module = $(abs_builddir)/libgotool.a
+extra_check_libs_cmd_go_internal_mvs = $(abs_builddir)/libgotool.a
+extra_check_libs_cmd_go_internal_search = $(abs_builddir)/libgotool.a
+extra_check_libs_cmd_go_internal_web2 = $(abs_builddir)/libgotool.a
 extra_check_libs_cmd_go_internal_work = $(abs_builddir)/libgotool.a
 
 extra_check_libs_cmd_vet_internal_cfg = $(abs_builddir)/libgotool.a
@@ -990,6 +1003,9 @@ bytes/index.lo: go/bytes/indexbyte.c run
 strings/index.lo: go/strings/indexbyte.c runtime.inc
@$(MKDIR_P) strings
$(LTCOMPILE) -c -o $@ $(srcdir)/go/strings/indexbyte.c
+internal/bytealg/bytealg.lo: go/internal/bytealg/bytealg.c runtime.inc
+   @$(MKDIR_P) internal/bytealg
+   $(LTCOMPILE) -c -o $@ $(srcdir)/go/internal/bytealg/bytealg.c
 
 # Use a C function with a fixed number 

Re: [PR 87339, testsuite] Fix failure of gcc.dg/warn-abs-1.c on some targets

[Christophe Lyon]

On Mon, 24 Sep 2018 at 20:46, Martin Jambor  wrote:
>
> Hi,
>
> the test added to check whether _Float128 types are handled correctly by
> the new warning about suspicious calls to abs-like functions fails on
> many platforms.  The patch below circumvents the problem by running on
> i686/x86_64 only.  I understand that the proper solution would be to
> come up with a deja-gnu predicate and skip-if it was not provided but I
> think that for one simple test that is a bit of an overkill and testing
> it on x86_64 will provide all the test coverage we need.
>
> Tested on x86_64-linux and aarch64-linux, testing on i686-linux
> pending.  OK for trunk?
>
> Thanks,
>
> Martin
>
>
>
> 2018-09-24  Martin Jambor  
>
> PR testsuite/87339
> * gcc.dg/warn-abs-1.c: Do not test _Float128.  Remove dg-skip-if.
> * gcc.target/i386/warn-abs-3.c: New test.
> ---
>  gcc/testsuite/gcc.dg/warn-abs-1.c  |  4 +---
>  gcc/testsuite/gcc.target/i386/warn-abs-3.c | 12 
>  2 files changed, 13 insertions(+), 3 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/warn-abs-3.c
>
> diff --git a/gcc/testsuite/gcc.dg/warn-abs-1.c 
> b/gcc/testsuite/gcc.dg/warn-abs-1.c
> index 129a3af8ac6..b494b14f4a9 100644
> --- a/gcc/testsuite/gcc.dg/warn-abs-1.c
> +++ b/gcc/testsuite/gcc.dg/warn-abs-1.c
> @@ -1,5 +1,4 @@
>  /* { dg-do compile { target float128 } } */

Don't you want to remove the {target float128} part?

> -/* { dg-skip-if "incomplete long double support" { { newlib } && 
> large_long_double } }  */
>  /* { dg-options "-Wabsolute-value" } */
>
>  #include 
> @@ -41,12 +40,11 @@ tst_notfloat (int *pi, long *pl, complex double *pc)
>  }
>
>  void
> -tst_float_size (double *pd, long double *pld, _Float128 *pf128)
> +tst_float_size (double *pd, long double *pld)
>  {
>*pd = fabsf (*pd);   /* { dg-warning "may cause truncation of value" } */
>*pld = fabs (*pld);  /* { dg-warning "may cause truncation of value" } */
>*pld = fabs ((double) *pld);
> -  *pf128 = fabsl (*pf128); /* { dg-warning "may cause truncation of value" } 
> */
>  }
>
>  void tst_notcomplex (int *pi, long *pl, long double *pld)
> diff --git a/gcc/testsuite/gcc.target/i386/warn-abs-3.c 
> b/gcc/testsuite/gcc.target/i386/warn-abs-3.c
> new file mode 100644
> index 000..21feaff7d8a
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/warn-abs-3.c
> @@ -0,0 +1,12 @@
> +/* { dg-do compile { target float128 } } */
> +/* { dg-options "-Wabsolute-value" } */
> +
> +#include 
> +#include 
> +#include 
> +
> +void
> +tst_float128_size (_Float128 *pf128)
> +{
> +  *pf128 = fabsl (*pf128); /* { dg-warning "may cause truncation of value" } 
> */
> +}
> --
> 2.18.0
>

Re: [PATCH] Do array index calculations in gfc_array_index_type

[Janne Blomqvist]

On Mon, Sep 24, 2018 at 7:48 PM Kyrill Tkachov 
wrote:

> Hi all,
>
> On 24/09/18 14:54, Andreas Schwab wrote:
> > On Sep 22 2018, Janne Blomqvist  wrote:
> >
> > > +! { dg-final { scan-tree-dump-times "_gfortran_caf_lock
> \\(four.token, .*\\(1 - four.dim\\\[0\\\].lbound\\),
> \\(integer\\(kind=4\\)\\) \\(7 - four.dim\\\[1\\\].lbound\\),
> \[0-9\]+, , 0B, 0\\);|_gfortran_caf_lock \\(four.token, 1 -
> four.dim\\\[0\\\].lbound, 7 - four.dim\\\[1\\\].lbound, \[0-9\]+,
> , 0B, 0\\);" 1 "original" } }
> > > +! { dg-final { scan-tree-dump-times "_gfortran_caf_unlock
> \\(four.token, .*\\(2 - four.dim\\\[0\\\].lbound\\),
> \\(integer\\(kind=4\\)\\) \\(8 - four.dim\\\[1\\\].lbound\\), 0B, 0B,
> 0\\);|_gfortran_caf_unlock \\(four.token, 2 - four.dim\\\[0\\\].lbound, 8 -
> four.dim\\\[1\\\].lbound, 0B, 0B, 0\\);" 1 "original" } }
> >
> > This is wrong for ILP32.
> >
>
> To be more concrete, this FAILs on arm-none-linux-gnueabihf:
>
> FAIL: gfortran.dg/coarray_lock_7.f90   -O   scan-tree-dump-times original
> "_gfortran_caf_lock \\(four.token, .*\\(1 - four.dim\\[0\\].lbound\\),
> \\(integer\\(kind=4\\)\\) \\(7 - four.dim\\[1\\].lbound\\),
> [0-9]+, , 0B, 0\\);|_gfortran_caf_lock \\(four.token, 1 -
> four.dim\\[0\\].lbound, 7 - four.dim\\[1\\].lbound, [0-9]+, ,
> 0B, 0\\);" 1
> FAIL: gfortran.dg/coarray_lock_7.f90   -O   scan-tree-dump-times original
> "_gfortran_caf_unlock \\(four.token, .*\\(2 - four.dim\\[0\\].lbound\\),
> \\(integer\\(kind=4\\)\\) \\(8 - four.dim\\[1\\].lbound\\), 0B, 0B,
> 0\\);|_gfortran_caf_unlock \\(four.token, 2 - four.dim\\[0\\].lbound, 8 -
> four.dim\\[1\\].lbound, 0B, 0B, 0\\);" 1
>
>
> Thanks,
> Kyrill
>

Ugh. My 32-bit tree is in a bit of a disarray at the moment (my lxd
container setup didn't survive the upgrade to ubuntu 18.04), can somebody
send me the .original tree dump?

-- 
Janne Blomqvist

Re: [PATCH, libgfortran] Remove recursion check

[Janne Blomqvist]

On Mon, Sep 24, 2018 at 7:48 PM Thomas Koenig  wrote:

> Hi Janne,
>
> > libgfortran has a recursion check in the error handling paths.  This
> > works by checking the value of a static variable, and if it matches,
> > aborting immediately instead of continuing error processing.
> > Unfortunately, in a multi-threaded program, if two threads report an
> > error at the same time, this can trigger this check, and thus the
> > underlying reason for the error is never reported.
>
> I agree that this is a problem that should be addressed.  Hm...
>
> What do you think, would it be desirable / possible to keep the
> recursive error check, but ensure thread safety by a suitable
> locking mechanism?  As a first step, we should probably specify
> what exactly we would like to happen.
>
> Let us assume that the aim is to keep the current behavior for normal
> processes and allow concurrent error processing for multiple threads.
>
> This could be done by making the static variable thread-local.
> I'm not sure that this would work reliably, or if some sort of
> locking mechanism (probably involving PTHREAD_MUTEX_RECURSIVE)
> would be required - only have one thread at a time process
> an error.
>
> Do we actually want to keep the current behavior for non-threaded
> programs?  I'd be in favor, but I do not feel strongly about that.
>

What I briefly was thinking about doing, was to use TLS. Or rather, since
TLS is not supported on all targets, something like I did in
intrinsics/random.c:get_rand_state(). But, since the error handling stuff
should be async-signal-safe, the allocation in the setup path should be
done separately, e.g. as part of library initialization.

In the end I decided against it because

1) It's more complicated, in order to handle a quite unlikely edge case.

2) If recursion happens anyway, it's a bug in our error handling flow which
should be fixed and not be papered over.

Anyway, I'm not massively against this, if people have any particular
opinion lets hear it.

-- 
Janne Blomqvist

Re: [PR 87339, testsuite] Fix failure of gcc.dg/warn-abs-1.c on some targets

[Mike Stump]

On Sep 24, 2018, at 11:45 AM, Martin Jambor  wrote:
> 
> the test added to check whether _Float128 types are handled correctly by
> the new warning about suspicious calls to abs-like functions fails on
> many platforms.  The patch below circumvents the problem by running on
> i686/x86_64 only.  I understand that the proper solution would be to
> come up with a deja-gnu predicate and skip-if it was not provided but I
> think that for one simple test that is a bit of an overkill and testing
> it on x86_64 will provide all the test coverage we need.
> 
> Tested on x86_64-linux and aarch64-linux, testing on i686-linux
> pending.  OK for trunk?

Ok.

Re: [PATCH] PR86957

[Indu Bhagat]

Done. Attached is updated patch.

Patch is tested on x86_64

Thanks


On 09/24/2018 09:37 AM, Martin Sebor wrote:

I would suggest to use the term "remove" or "delete" instead of
the informal "wipe out" when referring to removing files or their
contents.

Martin 


diff --git a/gcc/common.opt b/gcc/common.opt
index ef6a630..53aac19 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -811,6 +811,10 @@ Wcoverage-mismatch
 Common Var(warn_coverage_mismatch) Init(1) Warning
 Warn in case profiles in -fprofile-use do not match.
 
+Wmissing-profile
+Common Var(warn_missing_profile) Init(1) Warning
+Warn in case profiles in -fprofile-use do not exist.
+
 Wvector-operation-performance
 Common Var(warn_vector_operation_performance) Warning
 Warn when a vector operation is compiled outside the SIMD.
diff --git a/gcc/coverage.c b/gcc/coverage.c
index 8f12778..19c696c 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -304,16 +304,23 @@ get_coverage_counts (unsigned counter, unsigned cfg_checksum,
 {
   static int warned = 0;
 
-  if (!warned++ && dump_enabled_p ())
+  if (!warned++)
 	{
-	  dump_user_location_t loc
-	= dump_user_location_t::from_location_t (input_location);
-	  dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, loc,
+	  warning (OPT_Wmissing_profile,
+		   "%qs profile count data file not found",
+		   da_file_name);
+	  if (dump_enabled_p ())
+	{
+	  dump_user_location_t loc
+		= dump_user_location_t::from_location_t (input_location);
+	  dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, loc,
+			   "file %s not found\n",
+			   da_file_name);
+	  dump_printf (MSG_OPTIMIZED_LOCATIONS,
 			   (flag_guess_branch_prob
-			? "file %s not found, execution counts estimated\n"
-			: "file %s not found, execution counts assumed to "
-			"be zero\n"),
-			   da_file_name);
+			? "execution counts estimated\n"
+			: "execution counts assumed to be zero\n"));
+	}
 	}
   return NULL;
 }
@@ -327,10 +334,17 @@ get_coverage_counts (unsigned counter, unsigned cfg_checksum,
   elt.ctr = counter;
   entry = counts_hash->find ();
   if (!entry)
-/* The function was not emitted, or is weak and not chosen in the
-   final executable.  Silently fail, because there's nothing we
-   can do about it.  */
-return NULL;
+{
+  if (counter == GCOV_COUNTER_ARCS)
+	warning_at (DECL_SOURCE_LOCATION (current_function_decl),
+		OPT_Wmissing_profile,
+		"profile for function %qD not found in profile data",
+		current_function_decl);
+  /* The function was not emitted, or is weak and not chosen in the
+	 final executable.  Silently fail, because there's nothing we
+	 can do about it.  */
+  return NULL;
+}
   
   if (entry->cfg_checksum != cfg_checksum)
 {
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index abbd9ec..1b6cd68 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -315,7 +315,7 @@ Objective-C and Objective-C++ Dialects}.
 -Wlogical-op  -Wlogical-not-parentheses  -Wlong-long @gol
 -Wmain  -Wmaybe-uninitialized  -Wmemset-elt-size  -Wmemset-transposed-args @gol
 -Wmisleading-indentation  -Wmissing-attributes -Wmissing-braces @gol
--Wmissing-field-initializers  -Wmissing-include-dirs @gol
+-Wmissing-field-initializers  -Wmissing-include-dirs  -Wmissing-profile @gol
 -Wno-multichar  -Wmultistatement-macros  -Wnonnull  -Wnonnull-compare @gol
 -Wnormalized=@r{[}none@r{|}id@r{|}nfc@r{|}nfkc@r{]} @gol
 -Wnull-dereference  -Wodr  -Wno-overflow  -Wopenmp-simd  @gol
@@ -4218,8 +4218,8 @@ Warn about an invalid memory access that is found by Pointer Bounds Checker
 @opindex Wcoverage-mismatch
 Warn if feedback profiles do not match when using the
 @option{-fprofile-use} option.
-If a source file is changed between compiling with @option{-fprofile-gen} and
-with @option{-fprofile-use}, the files with the profile feedback can fail
+If a source file is changed between compiling with @option{-fprofile-generate}
+and with @option{-fprofile-use}, the files with the profile feedback can fail
 to match the source file and GCC cannot use the profile feedback
 information.  By default, this warning is enabled and is treated as an
 error.  @option{-Wno-coverage-mismatch} can be used to disable the
@@ -4823,6 +4823,23 @@ This warning is enabled by @option{-Wall}.
 @opindex Wno-missing-include-dirs
 Warn if a user-supplied include directory does not exist.
 
+@item -Wmissing-profile
+@opindex Wmissing-profile
+@opindex Wno-missing-profile
+Warn if feedback profiles are missing when using the
+@option{-fprofile-use} option.
+This option diagnoses those cases where a new function or a new file is added
+to the user code between compiling with @option{-fprofile-generate} and with
+@option{-fprofile-use}, without regenerating the profiles.  In these cases, the
+profile feedback data files do not contain any profile feedback information for
+the newly added function or file respectively.  Also, in the case when profile

Re: C++ PATCH: trivial cleanup

[Jason Merrill]

OK.

On Fri, Sep 21, 2018 at 3:51 PM, Marek Polacek  wrote:
> Use the proper type for "complain".
>
> I guess it's obvious, but anyway, bootstrapped/regtested on x86_64-linux, ok
> for trunk?
>
> 2018-09-21  Marek Polacek  
>
> * cp-tree.h (build_noexcept_spec, add_exception_specifier): Adjust
> declarations.
> * except.c (build_noexcept_spec): Change the type of the complain
> parameter to tsubst_flags_t.
> * typeck2.c (add_exception_specifier): Likewise.
>
> diff --git gcc/cp/cp-tree.h gcc/cp/cp-tree.h
> index 2203e92dda8..efbdad83966 100644
> --- gcc/cp/cp-tree.h
> +++ gcc/cp/cp-tree.h
> @@ -6461,7 +6461,7 @@ extern void perform_deferred_noexcept_checks  
> (void);
>  extern bool nothrow_spec_p (const_tree);
>  extern bool type_noexcept_p(const_tree);
>  extern bool type_throw_all_p   (const_tree);
> -extern tree build_noexcept_spec(tree, int);
> +extern tree build_noexcept_spec(tree, 
> tsubst_flags_t);
>  extern void choose_personality_routine (enum languages);
>  extern tree build_must_not_throw_expr  (tree,tree);
>  extern tree eh_type_info   (tree);
> @@ -7415,7 +7415,7 @@ extern tree build_x_arrow (location_t, 
> tree,
>  tsubst_flags_t);
>  extern tree build_m_component_ref  (tree, tree, tsubst_flags_t);
>  extern tree build_functional_cast  (tree, tree, tsubst_flags_t);
> -extern tree add_exception_specifier(tree, tree, int);
> +extern tree add_exception_specifier(tree, tree, tsubst_flags_t);
>  extern tree merge_exception_specifiers (tree, tree);
>
>  /* in mangle.c */
> diff --git gcc/cp/except.c gcc/cp/except.c
> index 2db90eedcf7..3449b59b3cc 100644
> --- gcc/cp/except.c
> +++ gcc/cp/except.c
> @@ -1187,7 +1187,7 @@ type_throw_all_p (const_tree type)
> constant-expression of EXPR.  COMPLAIN is as for tsubst.  */
>
>  tree
> -build_noexcept_spec (tree expr, int complain)
> +build_noexcept_spec (tree expr, tsubst_flags_t complain)
>  {
>/* This isn't part of the signature, so don't bother trying to evaluate
>   it until instantiation.  */
> diff --git gcc/cp/typeck2.c gcc/cp/typeck2.c
> index b13ed2660de..fec1db00ca4 100644
> --- gcc/cp/typeck2.c
> +++ gcc/cp/typeck2.c
> @@ -2215,7 +2215,7 @@ build_functional_cast (tree exp, tree parms, 
> tsubst_flags_t complain)
> know what we're doing.  */
>
>  tree
> -add_exception_specifier (tree list, tree spec, int complain)
> +add_exception_specifier (tree list, tree spec, tsubst_flags_t complain)
>  {
>bool ok;
>tree core = spec;

[PR 87339, testsuite] Fix failure of gcc.dg/warn-abs-1.c on some targets

[Martin Jambor]

Hi,

the test added to check whether _Float128 types are handled correctly by
the new warning about suspicious calls to abs-like functions fails on
many platforms.  The patch below circumvents the problem by running on
i686/x86_64 only.  I understand that the proper solution would be to
come up with a deja-gnu predicate and skip-if it was not provided but I
think that for one simple test that is a bit of an overkill and testing
it on x86_64 will provide all the test coverage we need.

Tested on x86_64-linux and aarch64-linux, testing on i686-linux
pending.  OK for trunk?

Thanks,

Martin



2018-09-24  Martin Jambor  

PR testsuite/87339
* gcc.dg/warn-abs-1.c: Do not test _Float128.  Remove dg-skip-if.
* gcc.target/i386/warn-abs-3.c: New test.
---
 gcc/testsuite/gcc.dg/warn-abs-1.c  |  4 +---
 gcc/testsuite/gcc.target/i386/warn-abs-3.c | 12 
 2 files changed, 13 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/warn-abs-3.c

diff --git a/gcc/testsuite/gcc.dg/warn-abs-1.c 
b/gcc/testsuite/gcc.dg/warn-abs-1.c
index 129a3af8ac6..b494b14f4a9 100644
--- a/gcc/testsuite/gcc.dg/warn-abs-1.c
+++ b/gcc/testsuite/gcc.dg/warn-abs-1.c
@@ -1,5 +1,4 @@
 /* { dg-do compile { target float128 } } */
-/* { dg-skip-if "incomplete long double support" { { newlib } && 
large_long_double } }  */
 /* { dg-options "-Wabsolute-value" } */
 
 #include 
@@ -41,12 +40,11 @@ tst_notfloat (int *pi, long *pl, complex double *pc)
 }
 
 void
-tst_float_size (double *pd, long double *pld, _Float128 *pf128)
+tst_float_size (double *pd, long double *pld)
 {
   *pd = fabsf (*pd);   /* { dg-warning "may cause truncation of value" } */
   *pld = fabs (*pld);  /* { dg-warning "may cause truncation of value" } */
   *pld = fabs ((double) *pld);
-  *pf128 = fabsl (*pf128); /* { dg-warning "may cause truncation of value" } */
 }
 
 void tst_notcomplex (int *pi, long *pl, long double *pld)
diff --git a/gcc/testsuite/gcc.target/i386/warn-abs-3.c 
b/gcc/testsuite/gcc.target/i386/warn-abs-3.c
new file mode 100644
index 000..21feaff7d8a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/warn-abs-3.c
@@ -0,0 +1,12 @@
+/* { dg-do compile { target float128 } } */
+/* { dg-options "-Wabsolute-value" } */
+
+#include 
+#include 
+#include 
+
+void
+tst_float128_size (_Float128 *pf128)
+{
+  *pf128 = fabsl (*pf128); /* { dg-warning "may cause truncation of value" } */
+}
-- 
2.18.0

[PR 87347] Prevent segfaults if TYPE_ARG_TYPES is NULL

[Martin Jambor]

Hi,

the warning for suspicious calls of abs-like functions segfaults if a
user declared their own parameter-less-ish variant of abs like in the
testcase below.  Fixed by looking whether there is any TYPE_ARG_TYPES
before trying to compare the actual argument with it.

Bootstrapped and tested on x86_64-linux and aarch64-linux, the same on
i686-linux is pending.

OK for trunk?

Thanks,

Martin


2018-09-24  Martin Jambor  

PR c/87347
c/
* c-parser.c (warn_for_abs): Bail out if TYPE_ARG_TYPES is NULL.

testsuite/
* gcc.dg/pr87347.c: New test.
---
 gcc/c/c-parser.c   | 7 ---
 gcc/testsuite/gcc.dg/pr87347.c | 6 ++
 2 files changed, 10 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr87347.c

diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 1766a256633..a96d15fef1d 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -9116,9 +9116,10 @@ warn_for_abs (location_t loc, tree fndecl, tree arg)
  -Wint-conversion warnings.  Most other wrong types hopefully lead to type
  mismatch errors.  TODO: Think about what to do with FIXED_POINT_TYPE_P
  types and possibly other exotic types.  */
-  if (!INTEGRAL_TYPE_P (atype)
-  && !SCALAR_FLOAT_TYPE_P (atype)
-  && TREE_CODE (atype) != COMPLEX_TYPE)
+  if ((!INTEGRAL_TYPE_P (atype)
+   && !SCALAR_FLOAT_TYPE_P (atype)
+   && TREE_CODE (atype) != COMPLEX_TYPE)
+  || !TYPE_ARG_TYPES (TREE_TYPE (fndecl)))
 return;
 
   enum built_in_function fcode = DECL_FUNCTION_CODE (fndecl);
diff --git a/gcc/testsuite/gcc.dg/pr87347.c b/gcc/testsuite/gcc.dg/pr87347.c
new file mode 100644
index 000..d0bdf2a9fec
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr87347.c
@@ -0,0 +1,6 @@
+/* {dg-do compile} */
+/* { dg-options "-Wabsolute-value" } */
+
+int a;
+int abs();
+void b() { abs(a); }
-- 
2.18.0

Re: [PATCH 08/14] Add D2 Testsuite files.

[Mike Stump]

On Sep 21, 2018, at 2:38 PM, Iain Buclaw  wrote:
> 
> On 21 September 2018 at 22:54, Mike Stump  wrote:
>> On Sep 17, 2018, at 5:36 PM, Iain Buclaw  wrote:
>>> 
>>> This patch adds part of the D2 testsuite, which includes D source code
>>> files that are considered compilable; files that are considered
>>> uncompilable, but should not ICE; and files that should execute on
>>> targets with crash or assertion failures.
>> 
>> Ok.  [ not needed, you can self-review things like this no problem ]
>> 
>> I see you are sneaking in Alice in Wonderland...
>> 
> 
> I had forgotten about that test.  I recall another project written in
> D (Dustmite) ran into some trouble with Debian due to the Project
> Gutenberg small print, which they ended up removing.
> 
> The "small print" section in the text file says:
> 
>DISTRIBUTION UNDER "PROJECT GUTENBERG-tm"
>You may distribute copies of this etext electronically, or by
>disk, book or any other medium if you either delete this
>"Small Print!" and all other references to Project Gutenberg,
>or:
>[...]
> 
> I'll look into convincing upstream to also do the same.

Oh, if you know of any reason why a file cannot be distributed, you cannot 
check that in ever.  So, you must resolve any outstanding issues before 
committing.   So, if Gutenberg has restrictions on distribution, you have to 
resolve those first, before it hit git.

If it had hit git, please either remove such for now until resolved, or resolve 
any issues.  Thanks.

Re: [PATCH] Remove Pascal-related entries in code and comments.

[Jeff Law]

On 9/24/18 5:17 AM, Martin Liška wrote:
> On 9/21/18 6:47 PM, Joseph Myers wrote:
>> On Fri, 21 Sep 2018, Martin Liška wrote:
>>
>>> Hi.
>>>
>>> This is removal of some Pascal-related comments.
>> There are two different kinds of comments being removed here.  There are 
>> comments relating to GNU Pascal, which has long been a dead project, so 
>> removing those seems reasonable.  But there are also comments / 
>> documentation references referring to Pascal as a language that has some 
>> feature, rather than to the GNU Pascal implementation, and it's much less 
>> clear those should be removed.  And where you change "As in Algol and 
>> Pascal, lexical scoping of functions.", which is one of the latter kind, 
>> I'd think Algol is likely to be more obscure than Pascal to readers of the 
>> manual, so if it changes at all it should probably be to refer to more 
>> modern examples of languages with nested functions that form closures.
>>
> Hi Joseph.
> 
> I agree with that and I address the request in v2 of the patch.
> 
> Martin
> 
> 
> 0001-Remove-Pascal-related-entries-in-code-and-comments.patch
> 
> From 24b257c7bf33a5765801b68ce3c451b7c3b1cc12 Mon Sep 17 00:00:00 2001
> From: marxin 
> Date: Wed, 19 Sep 2018 13:19:47 +0200
> Subject: [PATCH] Remove Pascal-related entries in code and comments.
> 
> gcc/ChangeLog:
> 
> 2018-09-19  Martin Liska  
> 
>   * config/powerpcspe/powerpcspe.c (rs6000_output_function_epilogue):
>   Do not handle "GNU Pascal".
>   * config/rs6000/rs6000.c (rs6000_output_function_epilogue):
>   Likewise.
>   * config/sparc/sparc.c (sparc_pass_by_reference): Remove Pascal
>   from documentation. Likewise.
>   * dbxout.c (dbxout_range_type): Likewise.
>   * doc/cpp.texi: Likewise.
>   * doc/extend.texi: Likewise.
>   * doc/frontends.texi: Likewise.
>   * doc/invoke.texi: Remove Pascal entry.
>   * tree.def (CLEANUP_POINT_EXPR): Likewise.
>   * doc/rtl.texi (MODE_FUNCTION): Remove not used entry.
> 
> gcc/c-family/ChangeLog:
> 
> 2018-09-19  Martin Liska  
> 
>   * c-common.c (c_common_truthvalue_conversion):
>   Remove Pascal from documentation.
OK
jeff

Re: [PATCH] Cleanup strcpy/stpcpy no nul warning code

[Bernd Edlinger]

On 09/24/18 19:48, Jeff Law wrote:
> On 9/16/18 1:58 PM, Bernd Edlinger wrote:
>> Hi,
>>
>> this is a cleanup of the recently added strlen/strcpy/stpcpy
>> no nul warning code.
>>
>> Most importantly it moves the SSA_NAME handling from
>> unterminated_array to string_constant, thereby fixing
>> another round of xfails in the strlen and stpcpy test cases.
>>
>> I need to say that the fix for bug 86622 is relying in
>> type info on the pointer which is probably not safe in
>> GIMPLE in the light of the recent discussion.
>>
>> I had to add two further exceptions, which should
>> be safe in general: that is a pointer arithmentic on a string
>> literal is okay, and arithmetic on a string constant
>> that is exactly the size of the whole DECL, cannot
>> access an adjacent member.
>>
>>
>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>> Is it OK for trunk?
>>
>>
>> Thanks
>> Bernd.
>>
>>
>> patch-cleanup-no-nul.diff
>>
>> gcc:
>> 2018-09-16  Bernd Edlinger  
>>
>>  * builtins.h (unterminated_array): Remove prototype.
>>  * builtins.c (unterminated_array): Simplify.  Make static.
>>  (expand_builtin_strcpy_args): Don't use TREE_NO_WARNING here.
>>  (expand_builtin_stpcpy_1): Remove warn_string_no_nul without effect.
>>  * expr.c (string_constant): Handle SSA_NAME.  Add more exceptions
>>  where pointer arithmetic is safe.
>>  * gimple-fold.c (get_range_strlen): Handle nonstr like in c_strlen.
>>  (get_max_strlen): Remove the unnecessary mynonstr handling.
>>  (gimple_fold_builtin_strcpy): Simplify.
>>  (gimple_fold_builtin_stpcpy): Simplify.
>>  (gimple_fold_builtin_sprintf): Remove NO_WARNING propagation
>>  without effect.
>>  (gimple_fold_builtin_strlen): Simplify.
> So my thinking right now is to go forward with the API change to allow
> c_strlen to fill in a structure with relevant tidbits about the string.
> 
> That in turn allows us to use simplify unterminated_array in a manner
> similar to what you've done in your patch -- while carrying forward the
> capabilities we need for Martin's nul terminator warnings.  This would
> be combined with the expr.c chunks from your patch.
> 

Do you want me to elaborate that idea?

> However, most of the changes to drop NO_WARNING stuff should be handled
> separately.  I don't think they're safe as-is.  I'm also pretty sure the
> stpcpy changes in builtins.c aren't correct as-is.
> 
> 

Well, I think you must be referring to this:

@@ -3984,14 +3964,10 @@ expand_builtin_stpcpy_1 (tree exp, rtx target, mac
  compile-time, not an expression containing a string.  This is
  because the latter will potentially produce pessimized code
  when used to produce the return value.  */
-  tree nonstr = NULL_TREE;
if (!c_getstr (src, NULL)
- || !(len = c_strlen (src, 0, , 1)))
+ || !(len = c_strlen (src, 0)))
 return expand_movstr (dst, src, target, /*endp=*/2);

-  if (nonstr && !TREE_NO_WARNING (exp))
-   warn_string_no_nul (EXPR_LOCATION (exp), "stpcpy", src, nonstr);
-
lenp1 = size_binop_loc (loc, PLUS_EXPR, len, ssize_int (1));
ret = expand_builtin_mempcpy_args (dst, src, lenp1,
  target, exp, /*endp=*/2);


My observation is: If that one is necessary and does not only emit some
duplicated warnings, then the test case must be incomplete, at least it did not
regress when this code is removed.

It is possible that there are cases where this expansion produces a warning
where previous folding steps did not catch the issue, however they
are probably rare, and come at a cost, which means duplicated warnings.

Maybe there could a better way than TREE_NO_WARNING to get rid
of the duplicated warnings.

Maybe it will be best to concentrate the warnings on a single pass,
which means expand will it not be, right?


Bernd.

Re: [PATCH][DOC] Document all param values and remove defaults (PR middle-end/86078).

[Jeff Law]

On 9/24/18 4:18 AM, Martin Liška wrote:
> Hi.
> 
> As mentioned in the PR we miss defaults for quite some param option.
> I agreed with Richi that easiest way how to fix that would be to remove
> that from documentation and use rather --help=param. It's done in the patch.
> 
> Apart from that I remove few unused params and added all not yet documented.
> Description is taken from --help=param (params.def).
> 
> Is it fine to install? Is the community interested in the script I used
> to find for missing/extra params?
> 
> gcc/ChangeLog:
> 
> 2018-09-24  Martin Liska  
> 
>   PR middle-end/86078
>   * doc/invoke.texi: Document all parameters and remove default
>   of the parameters.
OK.
jeff

Re: [PATCH] Cleanup strcpy/stpcpy no nul warning code

[Jeff Law]

On 9/16/18 1:58 PM, Bernd Edlinger wrote:
> Hi,
> 
> this is a cleanup of the recently added strlen/strcpy/stpcpy
> no nul warning code.
> 
> Most importantly it moves the SSA_NAME handling from
> unterminated_array to string_constant, thereby fixing
> another round of xfails in the strlen and stpcpy test cases.
> 
> I need to say that the fix for bug 86622 is relying in
> type info on the pointer which is probably not safe in
> GIMPLE in the light of the recent discussion.
> 
> I had to add two further exceptions, which should
> be safe in general: that is a pointer arithmentic on a string
> literal is okay, and arithmetic on a string constant
> that is exactly the size of the whole DECL, cannot
> access an adjacent member.
> 
> 
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
> 
> 
> Thanks
> Bernd.
> 
> 
> patch-cleanup-no-nul.diff
> 
> gcc:
> 2018-09-16  Bernd Edlinger  
> 
>   * builtins.h (unterminated_array): Remove prototype.
> * builtins.c (unterminated_array): Simplify.  Make static.
> (expand_builtin_strcpy_args): Don't use TREE_NO_WARNING here.
>   (expand_builtin_stpcpy_1): Remove warn_string_no_nul without effect.
>   * expr.c (string_constant): Handle SSA_NAME.  Add more exceptions
>   where pointer arithmetic is safe.
>   * gimple-fold.c (get_range_strlen): Handle nonstr like in c_strlen.
>   (get_max_strlen): Remove the unnecessary mynonstr handling.
>   (gimple_fold_builtin_strcpy): Simplify.
>   (gimple_fold_builtin_stpcpy): Simplify.
>   (gimple_fold_builtin_sprintf): Remove NO_WARNING propagation
>   without effect.
>   (gimple_fold_builtin_strlen): Simplify.
So my thinking right now is to go forward with the API change to allow
c_strlen to fill in a structure with relevant tidbits about the string.

That in turn allows us to use simplify unterminated_array in a manner
similar to what you've done in your patch -- while carrying forward the
capabilities we need for Martin's nul terminator warnings.  This would
be combined with the expr.c chunks from your patch.

However, most of the changes to drop NO_WARNING stuff should be handled
separately.  I don't think they're safe as-is.  I'm also pretty sure the
stpcpy changes in builtins.c aren't correct as-is.


Jeff

Re: [PATCH v4 01/10] Initial TI PRU GCC port

[Jeff Law]

On 9/24/18 4:38 AM, Richard Sandiford wrote:
> Dimitar Dimitrov  writes:
>> On Thursday, 9/13/2018 13:02:21 EEST Richard Sandiford wrote:
>>> Dimitar Dimitrov  writes:
 +(define_insn
 "sub_impl_>>> _zext_op2>" +  [(set (match_operand:EQD 0 "register_operand" "=r,r,r")
 +  (minus:EQD
 +   (zero_extend:EQD
 +(match_operand:EQS0 1 "reg_or_ubyte_operand" "r,r,I"))
 +   (zero_extend:EQD
 +(match_operand:EQS1 2 "reg_or_ubyte_operand" "r,I,r"]
 +  ""
 +  "@
 +   sub\\t%0, %1, %2
 +   sub\\t%0, %1, %2
 +   rsb\\t%0, %2, %1"
 +  [(set_attr "type" "alu")
 +   (set_attr "length" "4")])
>>>
>>> By convention, subtraction patterns shouldn't accept constants for
>>> operand 2.  Constants should instead be subtracted using an addition
>>> of the negative.
>> Understood. I will remove second alternative. But I will leave the third one 
>> since it enables an important optimization:
>>
>>unsigned test(unsigned a)
>>{
>> return 10-a;
>>}
>>
>> RTL:
>> (insn 6 3 7 2 (set (reg:SI 152)
>> (minus:SI (const_int 10 [0xa])
>> (reg/v:SI 151 [ a ]))) "test.c":430 -1
>>  (nil))
>>
>> Assembly:
>> test:
>> rsb r14, r14, 10
>> ret
> 
> Thanks.  And yeah, the final alternative is fine.
> 
 +;; Return true if OP is a text segment reference.
 +;; This is needed for program memory address expressions.  Borrowed from
 AVR. +(define_predicate "text_segment_operand"
 +  (match_code "code_label,label_ref,symbol_ref,plus,minus,const")
 +{
 +  switch (GET_CODE (op))
 +{
 +case CODE_LABEL:
 +  return true;
 +case LABEL_REF :
 +  return true;
 +case SYMBOL_REF :
 +  return SYMBOL_REF_FUNCTION_P (op);
 +case PLUS :
 +case MINUS :
 +  /* Assume canonical format of symbol + constant.
 +   Fall through.  */
 +case CONST :
 +  return text_segment_operand (XEXP (op, 0), VOIDmode);
 +default :
 +  return false;
 +}
 +})
>>>
>>> This probably comes from AVR, but: no spaces before ":".
>>>
>>> Bit surprised that we can get a CODE_LABEL rather than a LABEL_REF here.
>>> Do you know if that triggers in practice, and if so where?
>> Indeed, CODE_LABEL case is never reached. I'll leave gcc_unreachable here.
>>
>>> An IMO neater and slightly more robust way of writing the body is:
>>>   poly_int64 offset:
>>>   rtx base = strip_offset (op, );
>>>   switch (GET_CODE (base))
>>>   
>>> {
>>> 
>>> case LABEL_REF:
>>>   ...as above...
>>> 
>>> case SYMBOL_REF:
>>>   ...as above...
>>> 
>>> default:
>>>   return false;
>>> 
>>> }
>>>
>>> with "plus" and "minus" not in the match_code list (since they should
>>> always appear in consts if they really are text references).
>>
>> The "plus" and "minus" are needed when handling code labels as values. Take 
>> for example the following construct:
>>
>>int x = & - &
>> lab1:
>>   ...
>> lab2:
>>
>>
>> My TARGET_ASM_INTEGER callback uses the text_segment_operand predicate. In 
>> the 
>> above case it is passed the following RTL expression:
>> (minus:SI (label_ref/v:SI 20)
>> (label_ref/v:SI 27))
>>
>> I need to detect text labels so that I annotate them with %pmem:
>> .4byte   %pmem(.L4-(.L2))
>> Instead of the incorrect:
>> .4byte   .L3-(.L2)
> 
> OK, thanks for the explanation.  I think the target-independent code should
> really be passing (const (minus ...)) rather than a plain (minus ...) here,
> but that's going to be difficult to change at this stage.  And like you say,
> the split_offset suggestion wouldn't have handled this anyway.
> 
> So yeah, please keep what you have now.
> 
 +/* Callback for walk_gimple_seq that checks TP tree for TI ABI
 compliance.  */ +static tree
 +check_op_callback (tree *tp, int *walk_subtrees, void *data)
 +{
 +  struct walk_stmt_info *wi = (struct walk_stmt_info *) data;
 +
 +  if (RECORD_OR_UNION_TYPE_P (*tp) || TREE_CODE (*tp) == ENUMERAL_TYPE)
 +{
 +  /* Forward declarations have NULL tree type.  Skip them.  */
 +  if (TREE_TYPE (*tp) == NULL)
 +  return NULL;
 +}
 +
 +  /* TODO - why C++ leaves INTEGER_TYPE forward declarations around?  */
 +  if (TREE_TYPE (*tp) == NULL)
 +return NULL;
 +
 +  const tree type = TREE_TYPE (*tp);
 +
 +  /* Direct function calls are allowed, obviously.  */
 +  if (TREE_CODE (*tp) == ADDR_EXPR && TREE_CODE (type) == POINTER_TYPE)
 +{
 +  const tree ptype = TREE_TYPE (type);
 +  if (TREE_CODE (ptype) == FUNCTION_TYPE)
 +  return NULL;
 +}
>>>
>>> This seems like a bit of a dangerous heuristic.  Couldn't it also cause
>>> us to skip things like:
>>>
>>>(void *) func
>>>
>>> ?  (OK, that's dubious C, but we do support it.)
>> The cast yields a "data 

Re: [PATCH 02/25] Propagate address spaces to builtins.

[Andreas Schwab]

On Sep 24 2018, Andrew Stubbs  wrote:

> What should I have done?

Make sure you have the ILP32 patches for glibc and kernel.  You can get
them from the arm/ilp32 branch on sourceware.org

and the staging/ilp32-4.17 branch of the arm64 kernel tree
.

You can also get pre-built packages from


Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: PING^6: [PATCH] i386: Insert ENDBR before the profiling counter call

[H.J. Lu]

On Mon, Sep 24, 2018 at 10:23 AM, H.J. Lu  wrote:
> On Mon, Sep 24, 2018 at 9:55 AM, Jan Hubicka  wrote:
>>> On Mon, Sep 24, 2018 at 9:50 AM, Jan Hubicka  wrote:
>>> >> On Mon, Sep 24, 2018 at 9:19 AM, Jan Hubicka  wrote:
>>> >> >> >> PING.
>>> >> >> >
>>> >> >> > Hi, Jan Uros,
>>> >> >> >
>>> >> >> > Can you review this patch?
>>> >> >>
>>> >> >> I don't know CET stuff, so I'm not able to review functionality of 
>>> >> >> CET patches.
>>> >> >
>>> >> > My (very partial) understanding is that ENDBR is used to mark places 
>>> >> > where one
>>> >> > can jump/call. So we need to always arrange it first. Normally this is 
>>> >> > done
>>> >> > simply by inserting it very first in the instruction stream, but in 
>>> >> > cases
>>> >> > where profiling code is inserted this breaks because profiling code is
>>> >> > output as string rather than real instructions because it needs the 
>>> >> > code label
>>> >> > to be referred from mloc_count section.
>>> >> >
>>> >> > It is ugly, I wonder how much work would be tu turn profiler insertion 
>>> >> > to also
>>> >> > use RTL representation?
>>> >> >
>>> >>
>>> >> We will investigate it.
>>> > Thanks, do we need to backport this fix into release braches?
>>> > (I think current patch is more suitable for backporting)
>>>
>>> Yes, we need to backport it to GCC 8 branch.
>>
>> OK, then I guess the patch is fine for mainline and for branch after a week
>> (I am not sure how much of practical CET testing we have though). Please 
>> however
>> investigate the cleanup for the profiler code. It is not first time it hit us
>> and it would be nice to have less code output to function bodies that is not
>> visible to RTL passes.
>>
>
> This is the patch I checked into trunk.  I will backport it to GCC 8 branch
> next Monday.  I also opened:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87419
>
> to improve -mfentry.


Oops.  Wrong patch.  Here is the right one.



-- 
H.J.
From 9a6325624e2ffe478c03453f6777abad77969501 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Tue, 24 Oct 2017 08:47:19 -0700
Subject: [PATCH] i386: Insert ENDBR before the profiling counter call

ENDBR must be the first instruction of a function.  This patch queues
ENDBR if we need to put the profiling counter call before the prologue
and generate ENDBR before the profiling counter call.

gcc/

	PR target/82699
	* config/i386/i386.c (rest_of_insert_endbranch): Set
	endbr_queued_at_entrance to true and don't insert ENDBR if
	x86_function_profiler will be called.
	(x86_function_profiler): Insert ENDBR if endbr_queued_at_entrance
	is true.
	* config/i386/i386.h (machine_function): Add
	endbr_queued_at_entrance.

gcc/testsuite/

	PR target/82699
	* gcc.target/i386/pr82699-1.c: New file.
	* gcc.target/i386/pr82699-2.c: Likewise.
	* gcc.target/i386/pr82699-3.c: Likewise.
	* gcc.target/i386/pr82699-4.c: Likewise.
	* gcc.target/i386/pr82699-5.c: Likewise.
	* gcc.target/i386/pr82699-6.c: Likewise.
---
 gcc/config/i386/i386.c| 18 ++
 gcc/config/i386/i386.h|  3 +++
 gcc/testsuite/gcc.target/i386/pr82699-1.c | 11 +++
 gcc/testsuite/gcc.target/i386/pr82699-2.c | 11 +++
 gcc/testsuite/gcc.target/i386/pr82699-3.c | 11 +++
 gcc/testsuite/gcc.target/i386/pr82699-4.c | 11 +++
 gcc/testsuite/gcc.target/i386/pr82699-5.c | 11 +++
 gcc/testsuite/gcc.target/i386/pr82699-6.c | 11 +++
 8 files changed, 83 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr82699-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr82699-2.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr82699-3.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr82699-4.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr82699-5.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr82699-6.c

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 6dd31309495..052ca63e460 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -2593,11 +2593,17 @@ rest_of_insert_endbranch (void)
 			 TYPE_ATTRIBUTES (TREE_TYPE (cfun->decl)))
   && !cgraph_node::get (cfun->decl)->only_called_directly_p ())
 {
-  cet_eb = gen_nop_endbr ();
+  /* Queue ENDBR insertion to x86_function_profiler.  */
+  if (crtl->profile && flag_fentry)
+	cfun->machine->endbr_queued_at_entrance = true;
+  else
+	{
+	  cet_eb = gen_nop_endbr ();
 
-  bb = ENTRY_BLOCK_PTR_FOR_FN (cfun)->next_bb;
-  insn = BB_HEAD (bb);
-  emit_insn_before (cet_eb, insn);
+	  bb = ENTRY_BLOCK_PTR_FOR_FN (cfun)->next_bb;
+	  insn = BB_HEAD (bb);
+	  emit_insn_before (cet_eb, insn);
+	}
 }
 
   bb = 0;
@@ -41203,6 +41209,10 @@ x86_function_profiler (FILE *file, int labelno ATTRIBUTE_UNUSED)
 {
   const char *mcount_name = (flag_fentry ? MCOUNT_NAME_BEFORE_PROLOGUE
 	 : MCOUNT_NAME);
+
+  if (cfun->machine->endbr_queued_at_entrance)
+fprintf (file, "\t%s\n", TARGET_64BIT ? "endbr64" : "endbr32");
+
   if 

Re: PING^6: [PATCH] i386: Insert ENDBR before the profiling counter call

[H.J. Lu]

On Mon, Sep 24, 2018 at 9:55 AM, Jan Hubicka  wrote:
>> On Mon, Sep 24, 2018 at 9:50 AM, Jan Hubicka  wrote:
>> >> On Mon, Sep 24, 2018 at 9:19 AM, Jan Hubicka  wrote:
>> >> >> >> PING.
>> >> >> >
>> >> >> > Hi, Jan Uros,
>> >> >> >
>> >> >> > Can you review this patch?
>> >> >>
>> >> >> I don't know CET stuff, so I'm not able to review functionality of CET 
>> >> >> patches.
>> >> >
>> >> > My (very partial) understanding is that ENDBR is used to mark places 
>> >> > where one
>> >> > can jump/call. So we need to always arrange it first. Normally this is 
>> >> > done
>> >> > simply by inserting it very first in the instruction stream, but in 
>> >> > cases
>> >> > where profiling code is inserted this breaks because profiling code is
>> >> > output as string rather than real instructions because it needs the 
>> >> > code label
>> >> > to be referred from mloc_count section.
>> >> >
>> >> > It is ugly, I wonder how much work would be tu turn profiler insertion 
>> >> > to also
>> >> > use RTL representation?
>> >> >
>> >>
>> >> We will investigate it.
>> > Thanks, do we need to backport this fix into release braches?
>> > (I think current patch is more suitable for backporting)
>>
>> Yes, we need to backport it to GCC 8 branch.
>
> OK, then I guess the patch is fine for mainline and for branch after a week
> (I am not sure how much of practical CET testing we have though). Please 
> however
> investigate the cleanup for the profiler code. It is not first time it hit us
> and it would be nice to have less code output to function bodies that is not
> visible to RTL passes.
>

This is the patch I checked into trunk.  I will backport it to GCC 8 branch
next Monday.  I also opened:

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

to improve -mfentry.

Thanks.

-- 
H.J.
From 267e0f92b0d5f1c7900901b20fe576218fc867fc Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Thu, 19 Jul 2018 14:23:03 -0700
Subject: [PATCH] Add VALID_AVX512FP16_REG_MODE

---
 gcc/config/i386/i386.c | 5 +
 gcc/config/i386/i386.h | 3 +++
 2 files changed, 8 insertions(+)

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index a8530eccc73..ae6b4e1bf06 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -8506,6 +8506,7 @@ function_arg_advance_64 (CUMULATIVE_ARGS *cum, machine_mode mode,
 
   /* Unnamed 512 and 256bit vector mode parameters are passed on stack.  */
   if (!named && (VALID_AVX512F_REG_MODE (mode)
+		 || (TARGET_AVX512FP16 && VALID_AVX512FP16_REG_MODE (mode))
 		 || VALID_AVX256_REG_MODE (mode)))
 return 0;
 
@@ -40286,6 +40287,7 @@ ix86_hard_regno_mode_ok (unsigned int regno, machine_mode mode)
   if (TARGET_AVX512F
 	  && (mode == XImode
 	  || VALID_AVX512F_REG_MODE (mode)
+	  || (TARGET_AVX512FP16 && VALID_AVX512FP16_REG_MODE (mode))
 	  || VALID_AVX512F_SCALAR_MODE (mode)))
 	return true;
 
@@ -40480,6 +40482,7 @@ ix86_set_reg_reg_cost (machine_mode mode)
 case MODE_VECTOR_INT:
 case MODE_VECTOR_FLOAT:
   if ((TARGET_AVX512F && VALID_AVX512F_REG_MODE (mode))
+	  || (TARGET_AVX512FP16 && VALID_AVX512FP16_REG_MODE (mode))
 	  || (TARGET_AVX && VALID_AVX256_REG_MODE (mode))
 	  || (TARGET_SSE2 && VALID_SSE2_REG_MODE (mode))
 	  || (TARGET_SSE && VALID_SSE_REG_MODE (mode))
@@ -44501,6 +44504,8 @@ ix86_vector_mode_supported_p (machine_mode mode)
 return true;
   if (TARGET_AVX && VALID_AVX256_REG_MODE (mode))
 return true;
+  if (TARGET_AVX512FP16 && VALID_AVX512FP16_REG_MODE (mode))
+return true;
   if (TARGET_AVX512F && VALID_AVX512F_REG_MODE (mode))
 return true;
   if (TARGET_MMX && VALID_MMX_REG_MODE (mode))
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 44cf5ac9847..86bff61140c 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -1131,6 +1131,9 @@ extern const char *host_detect_local_cpu (int argc, const char **argv);
 #define VALID_AVX512F_REG_OR_XI_MODE(MODE)\
   (VALID_AVX512F_REG_MODE (MODE) || (MODE) == XImode)
 
+#define VALID_AVX512FP16_REG_MODE(MODE)	\
+  ((MODE) == V32HFmode)
+
 #define VALID_AVX512VL_128_REG_MODE(MODE)\
   ((MODE) == V2DImode || (MODE) == V2DFmode || (MODE) == V16QImode	\
|| (MODE) == V4SImode || (MODE) == V4SFmode || (MODE) == V8HImode	\
-- 
2.17.1

[patch, fortran, committed] Another fallout from the INTENT(OUT) patch

[Thomas Koenig]

Hello world,

another obvious and simple one-line fix for fallout from the INTENT(OUT)
clobber patch.  Committed as r264539, after regression-testing.

It seems our testsuite is not testing as many combinations in the
language as I thought :-)

Regards

Thomas

2018-09-24  Thomas Koenig  

PR fortran/87397
* gfc_conv_procedure_call: Do not add clobber on INTENT(OUT)
for variables in an associate statement.

2018-09-24  Thomas Koenig  

PR fortran/87401
* gfortran.dg/intent_out_12.f90: New test.
Index: trans-expr.c
===
--- trans-expr.c	(Revision 264538)
+++ trans-expr.c	(Arbeitskopie)
@@ -5282,6 +5282,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *
 			&& !e->symtree->n.sym->attr.dummy
 			/* FIXME - PR 87395 and PR 41453  */
 			&& e->symtree->n.sym->attr.save == SAVE_NONE 
+			&& !e->symtree->n.sym->attr.associate_var
 			&& e->ts.type != BT_CHARACTER && e->ts.type != BT_DERIVED
 			&& e->ts.type != BT_CLASS && !sym->attr.elemental;
 
! { dg-do  run }
! PR fortran/87401 - this used to segfault at runtime.
! Test case by Janus Weil.

program assoc_intent_out

   implicit none

   real :: r

   associate(o => r)
  call sub(o)
   end associate

contains

   subroutine sub(out)
  real, intent(out) :: out
  out = 0.0
   end subroutine

end

ping [PATCH 0/4] [MSP430] Add methods to extract MCU data from file

[Jozef Lawrynowicz]

ping for these patches

[PATCH 1/4] [MSP430] Consolidate hard-coded MCU data
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01673.html

[PATCH 2/4] [MSP430] Update hard-coded MCU data
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01674.html

[PATCH 3/4] [MSP430] Search for MCU data file on include paths
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01675.html

[PATCH 4/4] [MSP430] Search for MCU data file using environment variable and in 
a toolchain subdirectory
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01676.html

---

The following series of patches extends MCU device data handling for the msp430
target, allowing an external file to be read which describes the CPU ISA and
hardware multiply supported for different MCUs.
The current hard-coded solution means that new MCUs can only be supported by
updating the GCC itself.

The first patch keeps the hard-coded data as the only way of reading MCU data,
but consolidates it in a single file. Extensions to the spec handling in
msp430.h mean that the hard-coded data is no longer needed in 't-msp430' for
multilib selection, or in the assembler. This is achieved by the driver which
places the corresponding mcpu value for the MCU on its command line.

Some extensions to msp430.exp were necessary to ensure that full test coverage
is achieved when the testsuite is run using "make check".
As the tests for different MCUs result in different ISAs/memory
models being used, the hard-coded libgloss multilib directories on the command
line needed to be fixed up to allow the non-default "430" and "large" multilibs
to be tested.
The tests could be downgraded from link tests to assemble tests, (the mips
testsuite does this), but then we would lose coverage that the spec strings
and multilib selection work as expected.

The second patch updates the hard-coded MCU data to the latest version.

The third patch adds functionality to search the include paths specified with
-I for "devices.csv". If the file is found, and a device name has been passed
to the -mmcu option, then devices.csv is parsed, and the MCU data for the given
device is extracted.

The fourth and final patch adds functionality to search for devices.csv in both
the path specified by the environment variable "MSP430_GCC_INCLUDE_DIR", and
the directory "msp430-elf/include/devices" from the toolchain root. These
locations are searched if devices.csv is not found on an include path.
If devices.csv is found using one of these methods, the directory containing
devices.csv is also registered as an include path and linker library path.

Re: [PATCH] v2: C++: suggestions for misspelled private members (PR c++/84993)

[Martin Sebor]

On 09/21/2018 04:09 PM, David Malcolm wrote:

This is v2 of the patch; I managed to bit-rot my own patch due to my
fix for r264335, which tightened up the "is this meaningful" threshold
on edit distances when finding spelling correction candidates.

The only change in this version is to rename various things in
the testcase so that they continue to be suggested
("colour" vs "m_color" are no longer near enough, so I renamed
"colour" to "m_colour").

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

OK for trunk?

Blurb from v1:

PR c++/84993 identifies a problem with our suggestions for
misspelled member names in the C++ FE for the case where the
member is private.

For example, given:

class foo
{
public:
  double get_ratio() const { return m_ratio; }

private:
  double m_ratio;
};

void test(foo *ptr)
{
  if (ptr->ratio >= 0.5)
;// etc
}

...we currently emit this suggestion:

: In function 'void test(foo*)':
:12:12: error: 'class foo' has no member named 'ratio'; did you mean 
'm_ratio'?
   if (ptr->ratio >= 0.5)
^
m_ratio

...but if the user follows this suggestion, they get:

: In function 'void test(foo*)':
:12:12: error: 'double foo::m_ratio' is private within this context
   if (ptr->m_ratio >= 0.5)
^~~
:7:10: note: declared private here
   double m_ratio;
  ^~~
:12:12: note: field 'double foo::m_ratio' can be accessed via 'double 
foo::get_ratio() const'
   if (ptr->m_ratio >= 0.5)
^~~
get_ratio()

It feels wrong to be emitting a fix-it hint that doesn't compile, so this
patch adds the accessor fix-it hint logic to this case, so that we directly
offer a valid suggestion:

: In function 'void test(foo*)':
:12:12: error: 'class foo' has no member named 'ratio'; did you mean
'double foo::m_ratio'? (accessible via 'double foo::get_ratio() const')
   if (ptr->ratio >= 0.5)
^
get_ratio()


I wonder if suggesting the inaccessible member is at all helpful
if it cannot be used.  Would mentioning only the accessor be
a better approach?

Also, to echo a comment made by someone else in a bug I don't
remember, rather than phrasing the error in the form of
a question ("did you mean x?") it might be better to either
state what we know:

  error: 'class foo' has no member named 'ratio'; the nearest
match is 'double foo::m_ratio' (accessible via 'double
foo::get_ratio() const')

or offer a suggestion:

  error: 'class foo' has no member named 'ratio'; suggest
using 'double foo::get_ratio() const' instead

A different approach altogether to these spelling messages that
occurs to me but that you may have already considered and rejected
would be to do what GCC does for errors due to ambiguous overloads:
i.e., enumerate the available candidates.  This would work well in
cases when multiple members are a close match.  It would also make
it possible to explain, for each candidate member, whether it's
accessible.

Martin

Re: PING^6: [PATCH] i386: Insert ENDBR before the profiling counter call

[Jan Hubicka]

> On Mon, Sep 24, 2018 at 9:50 AM, Jan Hubicka  wrote:
> >> On Mon, Sep 24, 2018 at 9:19 AM, Jan Hubicka  wrote:
> >> >> >> PING.
> >> >> >
> >> >> > Hi, Jan Uros,
> >> >> >
> >> >> > Can you review this patch?
> >> >>
> >> >> I don't know CET stuff, so I'm not able to review functionality of CET 
> >> >> patches.
> >> >
> >> > My (very partial) understanding is that ENDBR is used to mark places 
> >> > where one
> >> > can jump/call. So we need to always arrange it first. Normally this is 
> >> > done
> >> > simply by inserting it very first in the instruction stream, but in cases
> >> > where profiling code is inserted this breaks because profiling code is
> >> > output as string rather than real instructions because it needs the code 
> >> > label
> >> > to be referred from mloc_count section.
> >> >
> >> > It is ugly, I wonder how much work would be tu turn profiler insertion 
> >> > to also
> >> > use RTL representation?
> >> >
> >>
> >> We will investigate it.
> > Thanks, do we need to backport this fix into release braches?
> > (I think current patch is more suitable for backporting)
> 
> Yes, we need to backport it to GCC 8 branch.

OK, then I guess the patch is fine for mainline and for branch after a week
(I am not sure how much of practical CET testing we have though). Please however
investigate the cleanup for the profiler code. It is not first time it hit us
and it would be nice to have less code output to function bodies that is not
visible to RTL passes.

Honza
> 
> -- 
> H.J.

Re: PING^6: [PATCH] i386: Insert ENDBR before the profiling counter call

[H.J. Lu]

On Mon, Sep 24, 2018 at 9:50 AM, Jan Hubicka  wrote:
>> On Mon, Sep 24, 2018 at 9:19 AM, Jan Hubicka  wrote:
>> >> >> PING.
>> >> >
>> >> > Hi, Jan Uros,
>> >> >
>> >> > Can you review this patch?
>> >>
>> >> I don't know CET stuff, so I'm not able to review functionality of CET 
>> >> patches.
>> >
>> > My (very partial) understanding is that ENDBR is used to mark places where 
>> > one
>> > can jump/call. So we need to always arrange it first. Normally this is done
>> > simply by inserting it very first in the instruction stream, but in cases
>> > where profiling code is inserted this breaks because profiling code is
>> > output as string rather than real instructions because it needs the code 
>> > label
>> > to be referred from mloc_count section.
>> >
>> > It is ugly, I wonder how much work would be tu turn profiler insertion to 
>> > also
>> > use RTL representation?
>> >
>>
>> We will investigate it.
> Thanks, do we need to backport this fix into release braches?
> (I think current patch is more suitable for backporting)

Yes, we need to backport it to GCC 8 branch.

-- 
H.J.

Re: [PATCH 02/25] Propagate address spaces to builtins.

[Andrew Stubbs]

On 22/09/18 19:51, Andreas Schwab wrote:

That breaks aarch64 ILP32.


I'm struggling to reproduce this because apparently I don't know how to 
build aarch64 ILP32.


Presumably, in order to be building libgomp this must be an 
aarch64-linux-gnu toolchain, but when I set --with-abi=ilp32 I can't 
build glibc:


In file included from ../nptl/descr.h:24, 




 from ../sysdeps/aarch64/nptl/tls.h:44, 




 from ../sysdeps/unix/sysv/linux/aarch64/sysdep.h:29, 




 from :1: 




../include/setjmp.h:50:3: error: static assertion failed: "offset of 
__saved_mask field of struct __jmp_buf_tag != 184


What should I have done?

Thanks

Andrew

Re: PING^6: [PATCH] i386: Insert ENDBR before the profiling counter call

[Jan Hubicka]

> On Mon, Sep 24, 2018 at 9:19 AM, Jan Hubicka  wrote:
> >> >> PING.
> >> >
> >> > Hi, Jan Uros,
> >> >
> >> > Can you review this patch?
> >>
> >> I don't know CET stuff, so I'm not able to review functionality of CET 
> >> patches.
> >
> > My (very partial) understanding is that ENDBR is used to mark places where 
> > one
> > can jump/call. So we need to always arrange it first. Normally this is done
> > simply by inserting it very first in the instruction stream, but in cases
> > where profiling code is inserted this breaks because profiling code is
> > output as string rather than real instructions because it needs the code 
> > label
> > to be referred from mloc_count section.
> >
> > It is ugly, I wonder how much work would be tu turn profiler insertion to 
> > also
> > use RTL representation?
> >
> 
> We will investigate it.
Thanks, do we need to backport this fix into release braches?
(I think current patch is more suitable for backporting)

Honza
> 
> Thanks.
> 
> -- 
> H.J.

Re: [PATCH] Do array index calculations in gfc_array_index_type

[Kyrill Tkachov]

Hi all,

On 24/09/18 14:54, Andreas Schwab wrote:

On Sep 22 2018, Janne Blomqvist  wrote:

> +! { dg-final { scan-tree-dump-times "_gfortran_caf_lock \\(four.token, .*\\(1 - 
four.dim\\\[0\\\].lbound\\), \\(integer\\(kind=4\\)\\) \\(7 - four.dim\\\[1\\\].lbound\\), \[0-9\]+, 
, 0B, 0\\);|_gfortran_caf_lock \\(four.token, 1 - four.dim\\\[0\\\].lbound, 7 - four.dim\\\[1\\\].lbound, 
\[0-9\]+, , 0B, 0\\);" 1 "original" } }
> +! { dg-final { scan-tree-dump-times "_gfortran_caf_unlock \\(four.token, .*\\(2 - 
four.dim\\\[0\\\].lbound\\), \\(integer\\(kind=4\\)\\) \\(8 - four.dim\\\[1\\\].lbound\\), 0B, 0B, 
0\\);|_gfortran_caf_unlock \\(four.token, 2 - four.dim\\\[0\\\].lbound, 8 - four.dim\\\[1\\\].lbound, 
0B, 0B, 0\\);" 1 "original" } }

This is wrong for ILP32.



To be more concrete, this FAILs on arm-none-linux-gnueabihf:

FAIL: gfortran.dg/coarray_lock_7.f90   -O   scan-tree-dump-times original "_gfortran_caf_lock 
\\(four.token, .*\\(1 - four.dim\\[0\\].lbound\\), \\(integer\\(kind=4\\)\\) \\(7 - 
four.dim\\[1\\].lbound\\), [0-9]+, , 0B, 0\\);|_gfortran_caf_lock \\(four.token, 1 - 
four.dim\\[0\\].lbound, 7 - four.dim\\[1\\].lbound, [0-9]+, , 0B, 0\\);" 1
FAIL: gfortran.dg/coarray_lock_7.f90   -O   scan-tree-dump-times original 
"_gfortran_caf_unlock \\(four.token, .*\\(2 - four.dim\\[0\\].lbound\\), 
\\(integer\\(kind=4\\)\\) \\(8 - four.dim\\[1\\].lbound\\), 0B, 0B, 
0\\);|_gfortran_caf_unlock \\(four.token, 2 - four.dim\\[0\\].lbound, 8 - 
four.dim\\[1\\].lbound, 0B, 0B, 0\\);" 1


Thanks,
Kyrill


Andreas.

--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH, libgfortran] Remove recursion check

[Thomas Koenig]

Hi Janne,


libgfortran has a recursion check in the error handling paths.  This
works by checking the value of a static variable, and if it matches,
aborting immediately instead of continuing error processing.
Unfortunately, in a multi-threaded program, if two threads report an
error at the same time, this can trigger this check, and thus the
underlying reason for the error is never reported.


I agree that this is a problem that should be addressed.  Hm...

What do you think, would it be desirable / possible to keep the
recursive error check, but ensure thread safety by a suitable
locking mechanism?  As a first step, we should probably specify
what exactly we would like to happen.

Let us assume that the aim is to keep the current behavior for normal
processes and allow concurrent error processing for multiple threads.

This could be done by making the static variable thread-local.
I'm not sure that this would work reliably, or if some sort of
locking mechanism (probably involving PTHREAD_MUTEX_RECURSIVE)
would be required - only have one thread at a time process
an error.

Do we actually want to keep the current behavior for non-threaded
programs?  I'd be in favor, but I do not feel strongly about that.

Regards

Thomas

Re: [PATCH] Change EQ_ATTR_ALT to support up to 64 alternatives

[Rainer Orth]

Hi Ilya,

>> Am 24.09.2018 um 13:29 schrieb Richard Sandiford :
>> 
>> Ilya Leoshkevich  writes:
>>> On S/390 there is a need to support more than 32 instruction
>>> alternatives per define_insn.  Currently this is not explicitly
>>> prohibited or unsupported: MAX_RECOG_ALTERNATIVES is equal 35, and,
>>> futhermore, the related code uses uint64_t for bitmaps in most places.
>>> 
>>> However, genattrtab contains the logic to convert (eq_attr "attribute"
>>> "value") RTXs to (eq_attr_alt bitmap) RTXs, where bitmap contains
>>> alternatives, whose "attribute" has the corresponding "value".
>>> Unfortunately, bitmap is only 32 bits.
>>> 
>>> When adding the 33rd alternative, this led to (eq_attr "type" "larl")
>>> becoming (eq_attr_alt -1050625 1), where -1050625 == 0xffeff7ff.  The
>>> cleared bits 12, 21 and 32 correspond to two existing and one newly
>>> added insn of type "larl".  compute_alternative_mask sign extended this
>>> to 0xffeff7ff, which contained non-existent alternatives, and
>>> this made simplify_test_exp fail with "invalid alternative specified".
>>> 
>>> I'm not sure why it didn't fail the same way before, since the top bit,
>>> which led to sign extension, should have been set even with 32
>>> alternatives.  Maybe simplify_test_exp was not called for "type"
>>> attribute for some reason?
>>> 
>>> This patch widens EQ_ATTR_ALT bitmap to 64 bits, making it possible to
>>> gracefully handle up to 64 alternatives.  It eliminates the problem with
>>> the 33rd alternative on S/390.
>> 
>> Could you test this with --enable-checking=yes,rtl , if you haven't already,
>> to check that there are no mossing XINT->XWINT changes?
>> 
>> OK if that passes, thanks.
>
> I used only plain --enable-checking before, so I reran with your flags,
> and it passed too.  I committed the patch as r264537.

your patch broke Solaris/SPARC and Solaris/x86 bootstraps
(sparc-sun-solaris2.11 and i386-pc-solaris2.11).  See PR bootstrap/87417.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] PR86957

[Martin Sebor]

On 09/21/2018 05:27 PM, Indu Bhagat wrote:

Attached is the refreshed patch for trunk.

After commit 264462 (Remove arc profile histogram in non-LTO mode.), the
API
of get_coverage_counts was changed a bit. So the main difference between
the
current version of my patch from the previous one is that :

Now I use
+  if (counter == GCOV_COUNTER_ARCS)
+   warning_at (DECL_SOURCE_LOCATION (current_function_decl),
+   OPT_Wmissing_profile,
+   "profile for function %qD not found in profile data",
+   current_function_decl);

instead of
+  if (summary)
+   warning_at (DECL_SOURCE_LOCATION (current_function_decl),
+   OPT_Wmissing_profile,
+   "profile for function %qD not found in profile data",
+   current_function_decl);

to warn about missing profile of a function only once
(get_coverage_counts is
called from two diff flows : getting exec counts for arc counter and
computing
histogram for other other counters)

I am not sure of any better way to avoid superfluous warnings per function.

Is the patch OK ?



In the text below:

@@ -4823,6 +4823,23 @@
 This warning is enabled by @option{-Wall}.
 @opindex Wno-missing-include-dirs
 Warn if a user-supplied include directory does not exist.

+@item -Wmissing-profile
+@opindex Wmissing-profile
+@opindex Wno-missing-profile
+Warn if feedback profiles are missing when using the
+@option{-fprofile-use} option.
+This option diagnoses those cases where a new function or a new file is 
added
+to the user code between compiling with @option{-fprofile-generate} and 
with
+@option{-fprofile-use}, without regenerating the profiles.  In these 
cases, the
+profile feedback data files do not contain any profile feedback 
information for
+the newly added function or file respectively.  Also, in the case when 
profile
+count data (.gcda) files are wiped out, GCC cannot use any profile 
feedback

+information.

I would suggest to use the term "remove" or "delete" instead of
the informal "wipe out" when referring to removing files or their
contents.

Martin

Re: PING^6: [PATCH] i386: Insert ENDBR before the profiling counter call

[H.J. Lu]

On Mon, Sep 24, 2018 at 9:19 AM, Jan Hubicka  wrote:
>> >> PING.
>> >
>> > Hi, Jan Uros,
>> >
>> > Can you review this patch?
>>
>> I don't know CET stuff, so I'm not able to review functionality of CET 
>> patches.
>
> My (very partial) understanding is that ENDBR is used to mark places where one
> can jump/call. So we need to always arrange it first. Normally this is done
> simply by inserting it very first in the instruction stream, but in cases
> where profiling code is inserted this breaks because profiling code is
> output as string rather than real instructions because it needs the code label
> to be referred from mloc_count section.
>
> It is ugly, I wonder how much work would be tu turn profiler insertion to also
> use RTL representation?
>

We will investigate it.

Thanks.

-- 
H.J.

Re: PING^6: [PATCH] i386: Insert ENDBR before the profiling counter call

[Jan Hubicka]

> >> PING.
> >
> > Hi, Jan Uros,
> >
> > Can you review this patch?
> 
> I don't know CET stuff, so I'm not able to review functionality of CET 
> patches.

My (very partial) understanding is that ENDBR is used to mark places where one
can jump/call. So we need to always arrange it first. Normally this is done
simply by inserting it very first in the instruction stream, but in cases
where profiling code is inserted this breaks because profiling code is
output as string rather than real instructions because it needs the code label
to be referred from mloc_count section.

It is ugly, I wonder how much work would be tu turn profiler insertion to also
use RTL representation?

Honza

> 
> Uros.

Re: PING^6: [PATCH] i386: Insert ENDBR before the profiling counter call

[Uros Bizjak]

On Mon, Sep 24, 2018 at 4:34 PM, H.J. Lu  wrote:
> On Mon, Apr 2, 2018 at 5:08 AM, H.J. Lu  wrote:
>> On Mon, Mar 26, 2018 at 4:09 AM, H.J. Lu  wrote:
>>> On Fri, Jan 26, 2018 at 6:23 AM, H.J. Lu  wrote:
 On Sun, Jan 7, 2018 at 7:11 PM, H.J. Lu  wrote:
> On Tue, Oct 24, 2017 at 10:58 AM, H.J. Lu  wrote:
>> On Tue, Oct 24, 2017 at 10:40 AM, Andi Kleen  
>> wrote:
>>> "H.J. Lu"  writes:
 --- /dev/null
 +++ b/gcc/testsuite/gcc.target/i386/pr82699-4.c
 @@ -0,0 +1,11 @@
 +/* { dg-do compile { target { *-*-linux* && { ! ia32 } } } } */
 +/* { dg-options "-O2 -fpic -fcf-protection -mcet -pg -mfentry 
 -fasynchronous-unwind-tables" } */
 +/* { dg-final { scan-assembler-times {\t\.cfi_startproc\n\tendbr} 1 }
 } */
>>>
>>> Would add test cases for -mnop-mcount and -mrecord-mcount too
>>>
>>
>> Here is the updated patch to add a testcase for -mnop-mcount 
>> -mrecord-mcount.
>> No other changes otherwise.
>>
>
> PING:
>
> https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01741.html
>
>

 PING.
>>>
>>> PING.
>>>
>>
>> PING.
>
> Hi, Jan Uros,
>
> Can you review this patch?

I don't know CET stuff, so I'm not able to review functionality of CET patches.

Uros.

Re: [C++ Patch] PR 85070 ("[8/9 Regression] ICE on C++ code: in lazily_declare_fn, at cp/method.c:2409")

[Nathan Sidwell]

On 9/24/18 3:48 AM, Paolo Carlini wrote:

Hi,

as explained in the audit trail, the gcc_assert added by Nathan triggers 
during error-recovery too, when add_method correctly returns false 
because it failed to add the method. Thus it seems that we should simply 
loosen a bit the assertion. Tested x86_64-linux.


ok


--
Nathan Sidwell

Re: [PATCH] Change EQ_ATTR_ALT to support up to 64 alternatives

[Ilya Leoshkevich]

> Am 24.09.2018 um 13:29 schrieb Richard Sandiford :
> 
> Ilya Leoshkevich  writes:
>> On S/390 there is a need to support more than 32 instruction
>> alternatives per define_insn.  Currently this is not explicitly
>> prohibited or unsupported: MAX_RECOG_ALTERNATIVES is equal 35, and,
>> futhermore, the related code uses uint64_t for bitmaps in most places.
>> 
>> However, genattrtab contains the logic to convert (eq_attr "attribute"
>> "value") RTXs to (eq_attr_alt bitmap) RTXs, where bitmap contains
>> alternatives, whose "attribute" has the corresponding "value".
>> Unfortunately, bitmap is only 32 bits.
>> 
>> When adding the 33rd alternative, this led to (eq_attr "type" "larl")
>> becoming (eq_attr_alt -1050625 1), where -1050625 == 0xffeff7ff.  The
>> cleared bits 12, 21 and 32 correspond to two existing and one newly
>> added insn of type "larl".  compute_alternative_mask sign extended this
>> to 0xffeff7ff, which contained non-existent alternatives, and
>> this made simplify_test_exp fail with "invalid alternative specified".
>> 
>> I'm not sure why it didn't fail the same way before, since the top bit,
>> which led to sign extension, should have been set even with 32
>> alternatives.  Maybe simplify_test_exp was not called for "type"
>> attribute for some reason?
>> 
>> This patch widens EQ_ATTR_ALT bitmap to 64 bits, making it possible to
>> gracefully handle up to 64 alternatives.  It eliminates the problem with
>> the 33rd alternative on S/390.
> 
> Could you test this with --enable-checking=yes,rtl , if you haven't already,
> to check that there are no mossing XINT->XWINT changes?
> 
> OK if that passes, thanks.

I used only plain --enable-checking before, so I reran with your flags,
and it passed too.  I committed the patch as r264537.

[patch,openacc] update fortran nested parallelism error messages

[Cesar Philippidis]

Bernhard noticed a typo in one of the OpenACC parallelism error
messages. The error should have reported that gang loops cannot be
nested inside vector loops, not worker loops.

I'll commit the attached patch to trunk as obvious. I bootstrapped and
regtested it against x86_64 Linux with nvptx offloading.

Cesar
[OpenACC] update fortran nested parallelism error messages

2018-09-24  Bernhard Reuther-Fischer  
	Cesar Philippidis  

	gcc/fortran/
	* openmp.c (resolve_oacc_loop_blocks):

	gcc/testsuite/
	* gfortran.dg/goacc/nested-parallelism.f90: New test.

---
 gcc/fortran/openmp.c  |  2 +-
 .../gfortran.dg/goacc/nested-parallelism.f90  | 51 +++
 2 files changed, 52 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/goacc/nested-parallelism.f90

diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index ac1923ea06b..a046863445d 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -5913,7 +5913,7 @@ resolve_oacc_loop_blocks (gfc_code *code)
 			 >loc);
 		if (c->code->ext.omp_clauses->vector)
 		  gfc_error ("Loop parallelized across gangs is not allowed "
-			 "inside loop parallelized across workers at %L",
+			 "inside loop parallelized across vectors at %L",
 			 >loc);
 	  }
 	if (code->ext.omp_clauses->worker)
diff --git a/gcc/testsuite/gfortran.dg/goacc/nested-parallelism.f90 b/gcc/testsuite/gfortran.dg/goacc/nested-parallelism.f90
new file mode 100644
index 000..6ebef6a4547
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/goacc/nested-parallelism.f90
@@ -0,0 +1,51 @@
+! Verify the invalid gang, worker, vector parallelism error messages.
+
+program np
+  integer, parameter :: n = 100
+  integer :: i, j, k
+
+  !$acc parallel loop gang
+  do i = 1, n
+ !$acc loop gang ! { dg-error "gangs is not allowed inside another loop parallelized across gangs" }
+ do j = 1, n
+ end do
+
+ !$acc loop worker
+ do j = 1, n
+ end do
+
+ !$acc loop vector
+ do j = 1, n
+ end do 
+  end do
+  
+  !$acc parallel loop worker
+  do i = 1, n
+ !$acc loop gang ! { dg-error "gangs is not allowed inside loop parallelized across workers" }
+ do j = 1, n
+ end do
+
+ !$acc loop worker ! { dg-error "workers is not allowed inside another loop parallelized across workers" }
+ do j = 1, n
+ end do
+
+ !$acc loop vector
+ do j = 1, n
+ end do 
+  end do
+
+  !$acc parallel loop vector
+  do i = 1, n
+ !$acc loop gang ! { dg-error "gangs is not allowed inside loop parallelized across vectors" }
+ do j = 1, n
+ end do
+
+ !$acc loop worker ! { dg-error "workers is not allowed inside another loop parallelized across vectors" }
+ do j = 1, n
+ end do
+
+ !$acc loop vector ! { dg-error "vectors is not allowed inside another loop parallelized across vectors" }
+ do j = 1, n
+ end do 
+  end do
+end program np
-- 
2.17.1

Re: [openacc] Teach gfortran to lower OpenACC routine dims

[Cesar Philippidis]

On 09/20/2018 09:10 AM, Bernhard Reutner-Fischer wrote:
> On Thu, 20 Sep 2018 07:41:08 -0700
> Cesar Philippidis  wrote:
> 
>> On 09/19/2018 03:27 PM, Bernhard Reutner-Fischer wrote:
>>> On Wed, 5 Sep 2018 12:52:03 -0700
>>> Cesar Philippidis  wrote:
> 
 diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
 index eea6b81ebfa..eed868f475b 100644
 --- a/gcc/fortran/trans-decl.c
 +++ b/gcc/fortran/trans-decl.c
 @@ -46,6 +46,7 @@ along with GCC; see the file COPYING3.  If not
 see #include "trans-stmt.h"
  #include "gomp-constants.h"
  #include "gimplify.h"
 +#include "omp-general.h"  
>>>
>>> hmz. so the gomp-constants.h include would be redundant, but do we
>>> really need omp-general.h?  
>>
>> Good point. omp-general.h is required for oacc_build_routine_dims.
>>
>>> Doesn't this suggest to move this oacc dims lowering to
>>> trans-openmp.c instead, please?  
>>
>> So something like adding a new gfc_add_omp_offload_attributes to
>> trans-openmp.c and call it from add_attributes_to_decl?
> 
> yes.
> 
>> On a related note, I noticed that I forgot to incorporate this change
>> in gfortran.h:
>>
>> @@ -902,7 +912,7 @@ typedef struct
>>unsigned oacc_declare_link:1;
>>
>>/* This is an OpenACC acclerator function at level N - 1  */
>> -  unsigned oacc_function:3;
>> +  ENUM_BITFIELD (oacc_function) oacc_function:3;
>>
>> It's probably not huge, but I noticed that some other enum bitfields
>> are declared that way.
> 
> yea, some compilers had trouble with enum bitfields (where plain int
> bitfields like here worked fine, IIRC) but i'm not sure if it's
> considered legacy these days. Fine with me to be safe.

I updated the patch by incorporating all of those changes. Is it OK for
trunk?

Thanks,
Cesar
[openacc] Make GFC default to -1 for OpenACC routine dims

2018-09-24  Cesar Philippidis  

	* gfortran.h (enum oacc_function): New enum.
	(gfc_oacc_routine_name): Add locus loc field.
	(symbol_attribute): Update type of oacc_function field.	
	* openmp.c (gfc_oacc_routine_dims): Return oacc_function.
	(gfc_match_oacc_routine): Update routine clause syntax checking.
	Populate oacc_function attribute with dims.
	* trans-decl.c (add_attributes_to_decl): Use oacc_build_routine_dims
	to construct routine dims.
	* trans.h (gfc_add_omp_offload_attributes): Declare.
	* trans-decl.c (add_attributes_to_decl): Use it to set OMP and ACC
	offload function attributes.
	* trans-openmp.c (gfc_add_omp_offload_attributes): New function.

	gcc/testsuite/
	* gfortran.dg/goacc/classify-routine.f95: Adjust test.
	* gfortran.dg/goacc/pr71704.f90: Likewise.
	* gfortran.dg/goacc/routine-6.f90: Likewise.
	* gfortran.dg/goacc/routine-8.f90: Likewise.
	* gfortran.dg/goacc/routine-level-of-parallelism-1.f90: Likewise.

	libgomp/
	* testsuite/libgomp.oacc-fortran/routine-1.f90: Adjust test.
	* testsuite/libgomp.oacc-fortran/routine-2.f90: Likewise.
	* testsuite/libgomp.oacc-fortran/routine-3.f90: Likewise.
	* testsuite/libgomp.oacc-fortran/routine-4.f90: Likewise.
	* testsuite/libgomp.oacc-fortran/routine-5.f90: Likewise.
	* testsuite/libgomp.oacc-fortran/routine-7.f90: Likewise.
	* testsuite/libgomp.oacc-fortran/routine-9.f90: Likewise.
	* libgomp.oacc-fortran/host_data-2.f90: Likewise.
	* libgomp.oacc-fortran/host_data-3.f: Likewise.
	* libgomp.oacc-fortran/host_data-4.f90: Likewise.


diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 04b0024a992..3efd59c95f7 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -316,6 +316,16 @@ enum save_state
 { SAVE_NONE = 0, SAVE_EXPLICIT, SAVE_IMPLICIT
 };
 
+/* Flags to keep track of ACC routine states.  */
+enum oacc_function
+{ OACC_FUNCTION_NONE = 0,
+  OACC_FUNCTION_GANG,
+  OACC_FUNCTION_WORKER,
+  OACC_FUNCTION_VECTOR,
+  OACC_FUNCTION_SEQ,
+  OACC_FUNCTION_AUTO
+};
+
 /* Strings for all symbol attributes.  We use these for dumping the
parse tree, in error messages, and also when reading and writing
modules.  In symbol.c.  */
@@ -902,7 +912,7 @@ typedef struct
   unsigned oacc_declare_link:1;
 
   /* This is an OpenACC acclerator function at level N - 1  */
-  unsigned oacc_function:3;
+  ENUM_BITFIELD (oacc_function) oacc_function:3;
 
   /* Attributes set by compiler extensions (!GCC$ ATTRIBUTES).  */
   unsigned ext_attr:EXT_ATTR_NUM;
@@ -1726,6 +1736,7 @@ typedef struct gfc_oacc_routine_name
   struct gfc_symbol *sym;
   struct gfc_omp_clauses *clauses;
   struct gfc_oacc_routine_name *next;
+  locus loc;
 }
 gfc_oacc_routine_name;
 
diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index 94a7f7eaa50..ac1923ea06b 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -2234,34 +2234,45 @@ gfc_match_oacc_cache (void)
   return MATCH_YES;
 }
 
-/* Determine the loop level for a routine.   */
+/* Determine the loop level for a routine.  Returns OACC_FUNCTION_NONE
+   if any error is detected.  */
 
-static int
+static oacc_function
 gfc_oacc_routine_dims (gfc_omp_clauses *clauses)
 {
   

Re: [PATCH 2/4] Remove unused functions and fields.

[Jeff Law]

On 9/22/18 1:08 PM, marxin wrote:
> 
> gcc/ChangeLog:
> 
> 2018-09-24  Martin Liska  
> 
>   * alias.c (set_dest_equal_p): Remove unused function.
>   * config/i386/i386.c (def_builtin_pure2): Likewise.
>   * diagnostic-show-locus.c (class layout): Remove
>   unused field.
>   (layout::layout): Likewise here.
>   * dump-context.h (class temp_dump_context): Likewise.
>   * dwarf2out.c (add_AT_fde_ref): Remove unused function.
>   (add_AT_loclistsptr): Likewise.
>   (add_AT_offset): Likewise.
>   (get_AT_hi_pc): Likewise.
>   (is_comdat_die): Likewise.
>   (type_is_enum): Likewise.
>   (ceiling): Likewise.
>   (add_AT_vms_delta): Likewise.
>   (is_class_die): Likewise.
>   * edit-context.c (class line_event): Remove unused field.
>   * graphite-sese-to-poly.c (tree_int_to_gmp): Remove
>   unused function.
>   * ipa-cp.c (ipa_get_vr_lat): Likewise.
>   * lra-constraints.c (ok_for_index_p_nonstrict): Likewise.
>   (ok_for_base_p_nonstrict): Likewise.
>   * tree-chrec.c (is_not_constant_evolution): Likewise.
>   (chrec_fold_poly_cst): Likewise.
>   * tree-if-conv.c (has_pred_critical_p): Likewise.
>   * tree-ssa-coalesce.c (print_exprs): Likewise.
>   * tree-ssa-pre.c (bitmap_set_contains_expr): Likewise.
>   * tree-ssa-uninit.c (is_and_or_or_p): Likewise.
>   * tree-vrp.c (value_ranges_intersect_p): Likewise.
>   (value_range_nonnegative_p): Likewise.
> 
> gcc/cp/ChangeLog:
> 
> 2018-09-24  Martin Liska  
> 
>   * name-lookup.c (namespace_scope_ht_size): Remove
>   unused function.
>   * parser.c (cp_lexer_next_token_is_not_keyword): Likewise.
> 
> gcc/fortran/ChangeLog:
> 
> 2018-09-24  Martin Liska  
> 
>   * trans.c (remove_suffix): Remove
>   unused function.
> 
> gcc/go/ChangeLog:
> 
> 2018-09-24  Martin Liska  
> 
>   * gofrontend/escape.cc (Gogo::analyze_escape): Remove
>   usage of a parameter.
>   (Gogo::assign_connectivity): Likewise.
>   (class Escape_analysis_tag): Likewise.
>   (Gogo::tag_function): Likewise.
>   * gofrontend/expressions.cc (Call_expression::do_type): Likewise.
>   * gofrontend/gogo.h (class Gogo): Likewise.
>   * gofrontend/types.cc (class Call_multiple_result_type): Likewise.
>   (Type::make_call_multiple_result_type): Likewise.
>   * gofrontend/types.h (class Type): Likewise.
>   * gofrontend/wb.cc (class Check_escape): Likewise.
>   (Gogo::add_write_barriers): Likewise.
Note that some of these may be used inside conditional code.  For
example the add_AT_vms_delta is used by ia64-vms.  You could argue that
ia64-vms is a zombie and should be removed, but the general concern WRT
conditionally compiled code holds.

Jeff

Re: [PATCH 1/4] Add filter-rtags-warnings.py script.

[Jeff Law]

On 9/23/18 1:16 AM, marxin wrote:
> 
> contrib/ChangeLog:
> 
> 2018-09-24  Martin Liska  
> 
>   * filter-rtags-warnings.py: New file.
> ---
>  contrib/filter-rtags-warnings.py | 71 
>  1 file changed, 71 insertions(+)
>  create mode 100755 contrib/filter-rtags-warnings.py
> 
OK
jeff

Re: [PATCH 4/4] Fix scaling of a sreal number.

[Jeff Law]

On 9/23/18 1:08 AM, marxin wrote:
> 
> The patch is addressing following LLVM warning:
> gcc/ipa-fnsummary.c:2745:54:Value Conversion Issue: implicit conversion from 
> 'double' to 'int64_t' (aka 'long') changes value from 0.99 to 0: 
> -Wliteral-conversion
> 
> Taking look at GIMPLE IR we end up with:
> 
>:
>   D.107433 ={v} {CLOBBER};
>   sreal::sreal (, -1, 0);
>   sreal::sreal (, 0, 0);
>   D.107435 = sreal::operator* (, );
>   D.107436 = sreal::operator- (_time, );
>   _65 = operator>= (, );
>   _66 = ~_65;
>   if (_66 != 0)
> goto ; [INV]
>   else
> goto ; [INV]
> 
>:
>   fancy_abort ("/home/marxin/Programming/gcc/gcc/ipa-fnsummary.c", 2745, 
> &__FUNCTION__);
> 
> which confirms the warning.
> 
> gcc/ChangeLog:
> 
> 2018-09-23  Martin Liska  
> 
>   * ipa-fnsummary.c (estimate_node_size_and_time): Scale by two
>   integers and not by a float value.
OK.
jeff

Re: [PATCH 3/4] Fix small coding style issues (PR fortran/87394).

[Jeff Law]

On 9/22/18 1:17 PM, marxin wrote:
> 
> gcc/ChangeLog:
> 
> 2018-09-24  Martin Liska  
> 
>   PR fortran/87394
>   * dbgcnt.c (dbg_cnt_process_single_pair): Return false
>   instead of NULL.
>   * dumpfile.c (dump_enable_all): Remove extra parenthesis.
>   * gcov-tool.c: Declare the function with ATTRIBUTE_NORETURN.
>   * godump.c (go_format_type): Remove extra parenthesis.
> 
> gcc/fortran/ChangeLog:
> 
> 2018-09-24  Martin Liska  
> 
>   PR fortran/87394
>   * decl.c (add_hidden_procptr_result): Simplify condition
>   as we are in branch witch 'case1 || case2'.
OK.
jeff

PING^6: [PATCH] i386: Insert ENDBR before the profiling counter call

[H.J. Lu]

On Mon, Apr 2, 2018 at 5:08 AM, H.J. Lu  wrote:
> On Mon, Mar 26, 2018 at 4:09 AM, H.J. Lu  wrote:
>> On Fri, Jan 26, 2018 at 6:23 AM, H.J. Lu  wrote:
>>> On Sun, Jan 7, 2018 at 7:11 PM, H.J. Lu  wrote:
 On Tue, Oct 24, 2017 at 10:58 AM, H.J. Lu  wrote:
> On Tue, Oct 24, 2017 at 10:40 AM, Andi Kleen  wrote:
>> "H.J. Lu"  writes:
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.target/i386/pr82699-4.c
>>> @@ -0,0 +1,11 @@
>>> +/* { dg-do compile { target { *-*-linux* && { ! ia32 } } } } */
>>> +/* { dg-options "-O2 -fpic -fcf-protection -mcet -pg -mfentry 
>>> -fasynchronous-unwind-tables" } */
>>> +/* { dg-final { scan-assembler-times {\t\.cfi_startproc\n\tendbr} 1 }
>>> } */
>>
>> Would add test cases for -mnop-mcount and -mrecord-mcount too
>>
>
> Here is the updated patch to add a testcase for -mnop-mcount 
> -mrecord-mcount.
> No other changes otherwise.
>

 PING:

 https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01741.html


>>>
>>> PING.
>>
>> PING.
>>
>
> PING.

Hi, Jan Uros,

Can you review this patch?

Thanks.



-- 
H.J.

Re: [PATCH] Do array index calculations in gfc_array_index_type

[Andreas Schwab]

On Sep 22 2018, Janne Blomqvist  wrote:

> +! { dg-final { scan-tree-dump-times "_gfortran_caf_lock \\(four.token, 
> .*\\(1 - four.dim\\\[0\\\].lbound\\), \\(integer\\(kind=4\\)\\) \\(7 - 
> four.dim\\\[1\\\].lbound\\), \[0-9\]+, , 0B, 
> 0\\);|_gfortran_caf_lock \\(four.token, 1 - four.dim\\\[0\\\].lbound, 7 - 
> four.dim\\\[1\\\].lbound, \[0-9\]+, , 0B, 0\\);" 1 "original" } }
> +! { dg-final { scan-tree-dump-times "_gfortran_caf_unlock \\(four.token, 
> .*\\(2 - four.dim\\\[0\\\].lbound\\), \\(integer\\(kind=4\\)\\) \\(8 - 
> four.dim\\\[1\\\].lbound\\), 0B, 0B, 0\\);|_gfortran_caf_unlock 
> \\(four.token, 2 - four.dim\\\[0\\\].lbound, 8 - four.dim\\\[1\\\].lbound, 
> 0B, 0B, 0\\);" 1 "original" } }

This is wrong for ILP32.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[PATCH 1/2] Check pie_enabled target in PIC tests

[H.J. Lu]

We need to check pie_enabled target in PIC tests to support GCC where
PIE is enabled by default when configured with --enable-default-pie.

PR testsuite/70150
* gcc.dg/20020312-2.c (dg-additional-options): Set to "-no-pie"
for pie_enabled target.
* gcc.dg/uninit-19.c: Check pie_enabled for PIC.
* gcc.target/i386/pr34256.c: Likewise.
---
 gcc/testsuite/gcc.dg/20020312-2.c   | 1 +
 gcc/testsuite/gcc.dg/uninit-19.c| 4 ++--
 gcc/testsuite/gcc.target/i386/pr34256.c | 4 ++--
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/20020312-2.c 
b/gcc/testsuite/gcc.dg/20020312-2.c
index f8be3ce2964..1a8afd81506 100644
--- a/gcc/testsuite/gcc.dg/20020312-2.c
+++ b/gcc/testsuite/gcc.dg/20020312-2.c
@@ -7,6 +7,7 @@
 
 /* { dg-do run } */
 /* { dg-options "-O -fno-pic" } */
+/* { dg-additional-options "-no-pie" { target pie_enabled } } */
 /* { dg-require-effective-target nonlocal_goto } */
 
 extern void abort (void);
diff --git a/gcc/testsuite/gcc.dg/uninit-19.c b/gcc/testsuite/gcc.dg/uninit-19.c
index 094dc0eb73d..3f5f06af540 100644
--- a/gcc/testsuite/gcc.dg/uninit-19.c
+++ b/gcc/testsuite/gcc.dg/uninit-19.c
@@ -12,7 +12,7 @@ fn1 (int p1, float *f1, float *f2, float *f3, unsigned char 
*c1, float *f4,
 {
   if (p1 & 8)
 b[3] = p10[a];
-  /* { dg-warning "may be used uninitialized" "" { target { { nonpic } || { 
hppa*64*-*-* } } } .-1 } */
+  /* { dg-warning "may be used uninitialized" "" { target { { nonpic || 
pie_enabled } || { hppa*64*-*-* } } } .-1 } */
 }
 
 void
@@ -22,5 +22,5 @@ fn2 ()
   if (l & 6)
 n =  + m;
   fn1 (l, , , , , , , n);
-  /* { dg-warning "may be used uninitialized" "" { target { ! { { nonpic } || 
{ hppa*64*-*-* } } } } .-1 } */
+  /* { dg-warning "may be used uninitialized" "" { target { ! { { nonpic || 
pie_enabled } || { hppa*64*-*-* } } } } .-1 } */
 }
diff --git a/gcc/testsuite/gcc.target/i386/pr34256.c 
b/gcc/testsuite/gcc.target/i386/pr34256.c
index 992312a4f26..698745765d8 100644
--- a/gcc/testsuite/gcc.target/i386/pr34256.c
+++ b/gcc/testsuite/gcc.target/i386/pr34256.c
@@ -10,5 +10,5 @@ unsigned long long  foo(__m64 m) {
   return _mm_cvtm64_si64(_mm_add_pi32(x, y));
 }
 
-/* { dg-final { scan-assembler-times "mov" 2 { target nonpic } } } */
-/* { dg-final { scan-assembler-times "mov" 4 { target { ! nonpic } } } } */
+/* { dg-final { scan-assembler-times "mov" 2 { target { nonpic || pie_enabled 
} } } } */
+/* { dg-final { scan-assembler-times "mov" 4 { target { { ! nonpic } && { ! 
pie_enabled } } } } } */
-- 
2.17.1

[PATCH 2/2] Check non-pic/ia32 in stackprotectexplicit2.C

[H.J. Lu]

For ia32, __stack_chk_fail isn't called in PIC.  We need to check
non-pic or non-ia32 before scanning for __stack_chk_fail.

PR testsuite/70150
* g++.dg/stackprotectexplicit2.C: Scanning for __stack_chk_fail
only for non-pic or non-ia32 .
---
 gcc/testsuite/g++.dg/stackprotectexplicit2.C | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/g++.dg/stackprotectexplicit2.C 
b/gcc/testsuite/g++.dg/stackprotectexplicit2.C
index 35d9e886ccf..cd34e4c7cfd 100644
--- a/gcc/testsuite/g++.dg/stackprotectexplicit2.C
+++ b/gcc/testsuite/g++.dg/stackprotectexplicit2.C
@@ -25,4 +25,4 @@ int __attribute__((stack_protect)) c()
 }
 
 
-/* { dg-final { scan-assembler-times "stack_chk_fail" 2 } } */
+/* { dg-final { scan-assembler-times "stack_chk_fail" 2 { target { nonpic || { 
! ia32 } } } } } */
-- 
2.17.1

Re: [rs6000] Do not generate sibling call to nested function

[Kyrill Tkachov]

Hi Eric,

On 18/09/18 15:56, Segher Boessenkool wrote:

Hi!

On Mon, Sep 17, 2018 at 11:11:53AM +0200, Eric Botcazou wrote:
> more precisely, to a nested function that requires a static chain.  The reason
> is that the sibling call epilogue may clobber the static chain register r11.
>
> Tested on PowerPC/Linux, OK for the mainline?
>
>
> 2018-09-17  Eric Botcazou 
>
>* config/rs6000/rs6000.c (rs6000_function_ok_for_sibcall): Return false
>if the call takes a static chain.


> --- config/rs6000/rs6000.c(revision 264342)
> +++ config/rs6000/rs6000.c(working copy)
> @@ -24332,6 +24332,10 @@ rs6000_function_ok_for_sibcall (tree dec
>  {
>tree fntype;
>
> +  /* The sibcall epilogue may clobber the static chain register.  */
> +  if (CALL_EXPR_STATIC_CHAIN (exp))
> +return false;
> +
>if (decl)
>  fntype = TREE_TYPE (decl);
>else

We could probably make sibcalls work with static chain, but that is most
likely not worth it.  Could you change the comment to say something like
that?

Approved for trunk and backports.  Thanks!



I'm seeing a testism on the GCC 7 branch due to the noipa attribute in the 
testcase.
I think it doesn't exist in GCC 7 so we're getting a test for excess errors 
FAIL:

warning: 'noipa' attribute directive ignored [-Wattributes]

Any chance we can adjust the testcase?

Thanks,
Kyrill



Segher

Re: [PATCH v3] S/390: Fix conditional returns on z196+

[Ulrich Weigand]

Ilya Leoshkevich wrote:

> gcc/ChangeLog:
> 
> 2018-09-19  Ilya Leoshkevich  
> 
>   PR target/80080
>   * config/s390/s390.c (s390_emit_epilogue): Do not use PARALLEL
>   RETURN+USE when returning via %r14.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-09-19  Ilya Leoshkevich  
> 
>   PR target/80080
>   * gcc.target/s390/risbg-ll-3.c: Expect conditional returns.
>   * gcc.target/s390/zvector/vec-cmp-2.c: Likewise.

This is OK.

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  ulrich.weig...@de.ibm.com

[PATCH v3] S/390: Fix conditional returns on z196+

[Ilya Leoshkevich]

S/390 epilogue ends with (parallel [(return) (use %r14)]) instead of
the more usual (return) or (simple_return).  This sequence is not
recognized by the conditional return logic in try_optimize_cfg ().

This was introduced for processors older than z196, where it is
sometimes profitable to use call-clobbered register for returning
instead of %r14.  On newer processors we always return via %r14,
for which the fact that it's used is already reflected by
EPILOGUE_USES.  In this case a simple (return) suffices.

This patch changes return_use () to emit simple (return)s when
returning via %r14.  The resulting sequences are recognized by the
conditional return logic in try_optimize_cfg ().

gcc/ChangeLog:

2018-09-19  Ilya Leoshkevich  

PR target/80080
* config/s390/s390.c (s390_emit_epilogue): Do not use PARALLEL
RETURN+USE when returning via %r14.

gcc/testsuite/ChangeLog:

2018-09-19  Ilya Leoshkevich  

PR target/80080
* gcc.target/s390/risbg-ll-3.c: Expect conditional returns.
* gcc.target/s390/zvector/vec-cmp-2.c: Likewise.
---
 gcc/config/s390/s390.c| 20 +---
 gcc/testsuite/gcc.target/s390/risbg-ll-3.c|  6 +--
 .../gcc.target/s390/zvector/vec-cmp-2.c   | 48 +--
 3 files changed, 41 insertions(+), 33 deletions(-)

diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 541b032ac63..71039fe6ce9 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -11082,7 +11082,7 @@ s390_emit_prologue (void)
 void
 s390_emit_epilogue (bool sibcall)
 {
-  rtx frame_pointer, return_reg, cfa_restores = NULL_RTX;
+  rtx frame_pointer, return_reg = NULL_RTX, cfa_restores = NULL_RTX;
   int area_bottom, area_top, offset = 0;
   int next_offset;
   int i;
@@ -11191,10 +11191,6 @@ s390_emit_epilogue (bool sibcall)
 
 }
 
-  /* Return register.  */
-
-  return_reg = gen_rtx_REG (Pmode, RETURN_REGNUM);
-
   /* Restore call saved gprs.  */
 
   if (cfun_frame_layout.first_restore_gpr != -1)
@@ -11284,7 +11280,19 @@ s390_emit_epilogue (bool sibcall)
   s390_restore_gprs_from_fprs ();
 
   if (! sibcall)
-emit_jump_insn (gen_return_use (return_reg));
+{
+  if (!return_reg && !s390_can_use_return_insn ())
+/* We planned to emit (return), be we are not allowed to.  */
+return_reg = gen_rtx_REG (Pmode, RETURN_REGNUM);
+
+  if (return_reg)
+/* Emit (return) and (use).  */
+emit_jump_insn (gen_return_use (return_reg));
+  else
+/* The fact that RETURN_REGNUM is used is already reflected by
+   EPILOGUE_USES.  Emit plain (return).  */
+emit_jump_insn (gen_return ());
+}
 }
 
 /* Implement TARGET_SET_UP_BY_PROLOGUE.  */
diff --git a/gcc/testsuite/gcc.target/s390/risbg-ll-3.c 
b/gcc/testsuite/gcc.target/s390/risbg-ll-3.c
index 838f1ffbd91..2a2db543cd9 100644
--- a/gcc/testsuite/gcc.target/s390/risbg-ll-3.c
+++ b/gcc/testsuite/gcc.target/s390/risbg-ll-3.c
@@ -23,7 +23,7 @@ i64 f1 (i64 v_a, i64 v_b)
 extern i64 f2_foo();
 i64 f2 (i64 v_a, i64 v_b)
 {
-/* { dg-final { scan-assembler "f2:\n\trisbg\t%r2,%r3,60,62,0\n\tje\t" { 
target { lp64 } } } } */
+/* { dg-final { scan-assembler 
"f2:\n\trisbg\t%r2,%r3,60,62,0\n\tbner\t%r14\n\tjg\tf2_foo\n" { target { lp64 } 
} } } */
 /* { dg-final { scan-assembler 
"f2:\n\trisbgn\t%r3,%r2,0,0\\\+32-1,64-0-32\n\trisbg\t%r3,%r5,60,62,0" { target 
{ ! lp64 } } } } */
   i64 v_anda = v_a & -15;
   i64 v_andb = v_b & 14;
@@ -37,8 +37,8 @@ i64 f2 (i64 v_a, i64 v_b)
 void f2_bar ();
 void f2_cconly (i64 v_a, i64 v_b)
 {
-/* { dg-final { scan-assembler "f2_cconly:\n\trisbg\t%r3,%r2,63,59,0\n\tjne\t" 
 { target { lp64 } } } } */
-/* { dg-final { scan-assembler 
"f2_cconly:\n\trisbgn\t%r3,%r2,0,0\\\+32-1,64-0-32\n\trisbg\t%r3,%r5,60,62,0\n\tjne\t"
 { target { ! lp64 } } } } */
+/* { dg-final { scan-assembler 
"f2_cconly:\n\trisbg\t%r3,%r2,63,59,0\n\tber\t%r14\n\tjg\tf2_bar\n" { target { 
lp64 } } } } */
+/* { dg-final { scan-assembler 
"f2_cconly:\n\trisbgn\t%r3,%r2,0,0\\\+32-1,64-0-32\n\trisbg\t%r3,%r5,60,62,0\n\tber\t%r14\n\tjg\tf2_bar\n"
 { target { ! lp64 } } } } */
   if ((v_a & -15) | (v_b & 14))
 f2_bar();
 }
diff --git a/gcc/testsuite/gcc.target/s390/zvector/vec-cmp-2.c 
b/gcc/testsuite/gcc.target/s390/zvector/vec-cmp-2.c
index 1e63defa063..09a15eb25f0 100644
--- a/gcc/testsuite/gcc.target/s390/zvector/vec-cmp-2.c
+++ b/gcc/testsuite/gcc.target/s390/zvector/vec-cmp-2.c
@@ -15,7 +15,7 @@ all_eq_double (vector double a, vector double b)
   if (__builtin_expect (vec_all_eq (a, b), 1))
 g = 2;
 }
-/* { dg-final { scan-assembler-times 
all_eq_double:\n\tvfcedbs\t%v\[0-9\]*,%v24,%v26\n\tjne 1 } } */
+/* { dg-final { scan-assembler-times 
all_eq_double:\n\tvfcedbs\t%v\[0-9\]*,%v24,%v26\n\tbner\t%r14\n 1 } } */
 
 void __attribute__((noinline,noclone))
 all_ne_double (vector double a, vector double b)
@@ -23,7 +23,7 @@ all_ne_double (vector double a, vector double b)
   if (__builtin_expect (vec_all_ne 

Re: [PATCH] Change EQ_ATTR_ALT to support up to 64 alternatives

[Richard Sandiford]

Ilya Leoshkevich  writes:
> On S/390 there is a need to support more than 32 instruction
> alternatives per define_insn.  Currently this is not explicitly
> prohibited or unsupported: MAX_RECOG_ALTERNATIVES is equal 35, and,
> futhermore, the related code uses uint64_t for bitmaps in most places.
>
> However, genattrtab contains the logic to convert (eq_attr "attribute"
> "value") RTXs to (eq_attr_alt bitmap) RTXs, where bitmap contains
> alternatives, whose "attribute" has the corresponding "value".
> Unfortunately, bitmap is only 32 bits.
>
> When adding the 33rd alternative, this led to (eq_attr "type" "larl")
> becoming (eq_attr_alt -1050625 1), where -1050625 == 0xffeff7ff.  The
> cleared bits 12, 21 and 32 correspond to two existing and one newly
> added insn of type "larl".  compute_alternative_mask sign extended this
> to 0xffeff7ff, which contained non-existent alternatives, and
> this made simplify_test_exp fail with "invalid alternative specified".
>
> I'm not sure why it didn't fail the same way before, since the top bit,
> which led to sign extension, should have been set even with 32
> alternatives.  Maybe simplify_test_exp was not called for "type"
> attribute for some reason?
>
> This patch widens EQ_ATTR_ALT bitmap to 64 bits, making it possible to
> gracefully handle up to 64 alternatives.  It eliminates the problem with
> the 33rd alternative on S/390.

Could you test this with --enable-checking=yes,rtl , if you haven't already,
to check that there are no mossing XINT->XWINT changes?

OK if that passes, thanks.

Richard

Re: [PATCH] Remove Pascal-related entries in code and comments.

[Martin Liška]

On 9/21/18 6:47 PM, Joseph Myers wrote:
> On Fri, 21 Sep 2018, Martin Liška wrote:
> 
>> Hi.
>>
>> This is removal of some Pascal-related comments.
> 
> There are two different kinds of comments being removed here.  There are 
> comments relating to GNU Pascal, which has long been a dead project, so 
> removing those seems reasonable.  But there are also comments / 
> documentation references referring to Pascal as a language that has some 
> feature, rather than to the GNU Pascal implementation, and it's much less 
> clear those should be removed.  And where you change "As in Algol and 
> Pascal, lexical scoping of functions.", which is one of the latter kind, 
> I'd think Algol is likely to be more obscure than Pascal to readers of the 
> manual, so if it changes at all it should probably be to refer to more 
> modern examples of languages with nested functions that form closures.
> 

Hi Joseph.

I agree with that and I address the request in v2 of the patch.

Martin
>From 24b257c7bf33a5765801b68ce3c451b7c3b1cc12 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Wed, 19 Sep 2018 13:19:47 +0200
Subject: [PATCH] Remove Pascal-related entries in code and comments.

gcc/ChangeLog:

2018-09-19  Martin Liska  

	* config/powerpcspe/powerpcspe.c (rs6000_output_function_epilogue):
	Do not handle "GNU Pascal".
	* config/rs6000/rs6000.c (rs6000_output_function_epilogue):
	Likewise.
	* config/sparc/sparc.c (sparc_pass_by_reference): Remove Pascal
	from documentation. Likewise.
	* dbxout.c (dbxout_range_type): Likewise.
	* doc/cpp.texi: Likewise.
	* doc/extend.texi: Likewise.
	* doc/frontends.texi: Likewise.
	* doc/invoke.texi: Remove Pascal entry.
	* tree.def (CLEANUP_POINT_EXPR): Likewise.
	* doc/rtl.texi (MODE_FUNCTION): Remove not used entry.

gcc/c-family/ChangeLog:

2018-09-19  Martin Liska  

	* c-common.c (c_common_truthvalue_conversion):
	Remove Pascal from documentation.
---
 gcc/c-family/c-common.c|  2 +-
 gcc/config/powerpcspe/powerpcspe.c |  4 +---
 gcc/config/rs6000/rs6000.c |  4 +---
 gcc/config/sparc/sparc.c   |  5 ++---
 gcc/dbxout.c   |  2 +-
 gcc/doc/cpp.texi   |  2 +-
 gcc/doc/extend.texi|  2 +-
 gcc/doc/frontends.texi |  3 +--
 gcc/doc/invoke.texi|  3 ---
 gcc/doc/rtl.texi   |  5 -
 gcc/tree.def   | 17 ++---
 11 files changed, 15 insertions(+), 34 deletions(-)

diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 4bfb14585e2..10a8bc29bfa 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -3289,7 +3289,7 @@ c_common_truthvalue_conversion (location_t location, tree expr)
  	tree inner = TREE_OPERAND (expr, 0);
 	if (decl_with_nonnull_addr_p (inner))
 	  {
-	/* Common Ada/Pascal programmer's mistake.  */
+	/* Common Ada programmer's mistake.  */
 	warning_at (location,
 			OPT_Waddress,
 			"the address of %qD will always evaluate as %",
diff --git a/gcc/config/powerpcspe/powerpcspe.c b/gcc/config/powerpcspe/powerpcspe.c
index dea1eab1188..325b6ad5223 100644
--- a/gcc/config/powerpcspe/powerpcspe.c
+++ b/gcc/config/powerpcspe/powerpcspe.c
@@ -32024,7 +32024,7 @@ rs6000_output_function_epilogue (FILE *file)
   /* Language type.  Unfortunately, there does not seem to be any
 	 official way to discover the language being compiled, so we
 	 use language_string.
-	 C is 0.  Fortran is 1.  Pascal is 2.  Ada is 3.  C++ is 9.
+	 C is 0.  Fortran is 1.  Ada is 3.  C++ is 9.
 	 Java is 13.  Objective-C is 14.  Objective-C++ isn't assigned
 	 a number, so for now use 9.  LTO, Go and JIT aren't assigned numbers
 	 either, so for now use 0.  */
@@ -32036,8 +32036,6 @@ rs6000_output_function_epilogue (FILE *file)
   else if (! strcmp (language_string, "GNU F77")
 	   || lang_GNU_Fortran ())
 	i = 1;
-  else if (! strcmp (language_string, "GNU Pascal"))
-	i = 2;
   else if (! strcmp (language_string, "GNU Ada"))
 	i = 3;
   else if (lang_GNU_CXX ()
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index a36e6140ecb..2aea649aa6b 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -28403,7 +28403,7 @@ rs6000_output_function_epilogue (FILE *file)
   /* Language type.  Unfortunately, there does not seem to be any
 	 official way to discover the language being compiled, so we
 	 use language_string.
-	 C is 0.  Fortran is 1.  Pascal is 2.  Ada is 3.  C++ is 9.
+	 C is 0.  Fortran is 1.  Ada is 3.  C++ is 9.
 	 Java is 13.  Objective-C is 14.  Objective-C++ isn't assigned
 	 a number, so for now use 9.  LTO, Go and JIT aren't assigned numbers
 	 either, so for now use 0.  */
@@ -28415,8 +28415,6 @@ rs6000_output_function_epilogue (FILE *file)
   else if (! strcmp (language_string, "GNU F77")
 	   || lang_GNU_Fortran ())
 	i = 1;
-  else if (! strcmp (language_string, "GNU Pascal"))
-	i = 2;
   else if (! strcmp (language_string, "GNU 

[libstdc++,doc] update a link in doc/xml/manual/policy_data_structures_biblio.xml

[Gerald Pfeifer]

Both the protocol (https) and the local part of the URL changed;
updates thusly and committed.

Gerald

2018-09-24  Gerald Pfeifer  

* doc/xml/manual/policy_data_structures_biblio.xml: Update link
to "Priority Queues and the STL".
 
Index: doc/xml/manual/policy_data_structures_biblio.xml
===
--- doc/xml/manual/policy_data_structures_biblio.xml(revision 264517)
+++ doc/xml/manual/policy_data_structures_biblio.xml(working copy)
@@ -1139,7 +1139,7 @@
 
   
http://www.w3.org/1999/xlink;
- 
xlink:href="http://marknelson.us/1996/01/01/priority-queues/;>Priority Queues 
and the STL
+ 
xlink:href="https://marknelson.us/posts/1996/01/01/priority-queues.html;>Priority
 Queues and the STL

   
   

Re: OpenCoarrays integration with gfortran

[Alastair McKinstry]

On 23/09/2018 10:46, Toon Moene wrote:

On 09/22/2018 01:23 AM, Jerry DeLisle wrote:

I just installed opencoarrays on my system at home (Debian Testing):

root@moene:~# apt-get install libcoarrays-openmpi-dev
...
Setting up libcaf-openmpi-3:amd64 (2.2.0-3) ...
Setting up libcoarrays-openmpi-dev:amd64 (2.2.0-3) ...
Processing triggers for libc-bin (2.27-6) ...

[ previously this led to apt errors, but not now. ]

and moved my own installation of the OpenCoarrays-2.2.0.tar.gz out of 
the way:


toon@moene:~$ ls -ld *pen*
drwxr-xr-x 6 toon toon 4096 Aug 10 16:01 OpenCoarrays-2.2.0.opzij
drwxr-xr-x 8 toon toon 4096 Sep 15 11:26 opencoarrays-build.opzij
drwxr-xr-x 6 toon toon 4096 Sep 15 11:26 opencoarrays.opzij

and recompiled my stuff:

gfortran -g -fbacktrace -fcoarray=lib random-weather.f90 
-L/usr/lib/x86_64-linux-gnu/open-coarrays/openmpi/lib -lcaf_mpi


[ Yes, the location of the libs is quite experimental, but OK for the 
"Testing" variant of Debian ... ]


I couldn't find cafrun, but mpirun works just fine:

toon@moene:~/src$ echo '  /' | mpirun --oversubscribe --bind-to 
none -np 20 ./a.out
Decomposition information on image    7 is    4 *    5 slabs with   23 
*   18 grid cells on this image.
Decomposition information on image    6 is    4 *    5 slabs with   23 
*   18 grid cells on this image.
Decomposition information on image   11 is    4 *    5 slabs with   23 
*   18 grid cells on this image.
Decomposition information on image   15 is    4 *    5 slabs with   23 
*   18 grid cells on this image.
Decomposition information on image    1 is    4 *    5 slabs with   23 
*   18 grid cells on this image.
Decomposition information on image   13 is    4 *    5 slabs with   23 
*   18 grid cells on this image.
Decomposition information on image   12 is    4 *    5 slabs with   21 
*   18 grid cells on this image.
Decomposition information on image   20 is    4 *    5 slabs with   21 
*   18 grid cells on this image.
Decomposition information on image    9 is    4 *    5 slabs with   23 
*   18 grid cells on this image.
Decomposition information on image   14 is    4 *    5 slabs with   23 
*   18 grid cells on this image.
Decomposition information on image   16 is    4 *    5 slabs with   21 
*   18 grid cells on this image.
Decomposition information on image   17 is    4 *    5 slabs with   23 
*   18 grid cells on this image.
Decomposition information on image   18 is    4 *    5 slabs with   23 
*   18 grid cells on this image.
Decomposition information on image    2 is    4 *    5 slabs with   23 
*   18 grid cells on this image.
Decomposition information on image    4 is    4 *    5 slabs with   21 
*   18 grid cells on this image.
Decomposition information on image    5 is    4 *    5 slabs with   23 
*   18 grid cells on this image.
Decomposition information on image    3 is    4 *    5 slabs with   23 
*   18 grid cells on this image.
Decomposition information on image    8 is    4 *    5 slabs with   21 
*   18 grid cells on this image.
Decomposition information on image   10 is    4 *    5 slabs with   23 
*   18 grid cells on this image.
Decomposition information on image   19 is    4 *    5 slabs with   23 
*   18 grid cells on this image.


... etc. (see http://moene.org/~toon/random-weather.f90).

I presume other Linux distributors will follow shortly (this *is* 
Debian Testing, which can be a bit testy at times - but I do trust my 
main business at home on it for over 15 years now).


Kind regards,


Thanks, good to see it being tested (I'm the Debian/Ubuntu packager).

caf /cafrun has been dropped (for the moment ? ) in favour of mpirun, 
but I've added pkg-config caf packages so that becomes an option.


   $ pkg-config caf-mpich --libs

   -L/usr/lib/x86_64-linux-gnu/open-coarrays/mpich/lib -lcaf_mpich -Wl,-z,relro 
-lmpich -lm -lbacktrace -lpthread -lrt

(My thinking is that for libraries in particular, the user need not know 
whether CAF is being used, and if lib foobar uses CAF, then adding a:


    Requires: caf

into the pkg-config file gives you the correct linking transparently.

The "strange" paths are due to Debians multiarch : it is possible to 
include libraries for multiple architectures simultaneously. This works 
ok with pkg-config and cmake , etc (which allow you to set 
PKG_CONFIG_PATH and have multiple pkgconfig files for different libs 
simultaneously) , but currently break wrappers such as caf / cafrun.


I can add a new package for caf / cafrun but would rather not. (W e 
currently don't do non-MPI CAF builds).


There is currently pkg-config files 'caf-mpich' and 'caf-openmpi' for 
testing, and I'm adding a default alias caf -> caf-$(default-MPI)


regards

Alastair




--
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.

[C++ Patch] PR 85070 ("[8/9 Regression] ICE on C++ code: in lazily_declare_fn, at cp/method.c:2409")

[Paolo Carlini]

Hi,

as explained in the audit trail, the gcc_assert added by Nathan triggers 
during error-recovery too, when add_method correctly returns false 
because it failed to add the method. Thus it seems that we should simply 
loosen a bit the assertion. Tested x86_64-linux.


Thanks, Paolo.

///

/cp
2018-09-24  Paolo Carlini  

PR c++/85070
* method.c (lazily_declare_fn): During error-recovery add_method
may return false.

/testsuite
2018-09-24  Paolo Carlini  

PR c++/85070
* g++.dg/cpp0x/pr85070.C: New.
Index: cp/method.c
===
--- cp/method.c (revision 264524)
+++ cp/method.c (working copy)
@@ -2421,7 +2421,7 @@ lazily_declare_fn (special_function_kind sfk, tree
 
   /* Add it to the class  */
   bool added = add_method (type, fn, false);
-  gcc_assert (added);
+  gcc_assert (added || errorcount);
 
   /* Add it to TYPE_FIELDS.  */
   if (sfk == sfk_destructor
Index: testsuite/g++.dg/cpp0x/pr85070.C
===
--- testsuite/g++.dg/cpp0x/pr85070.C(nonexistent)
+++ testsuite/g++.dg/cpp0x/pr85070.C(working copy)
@@ -0,0 +1,13 @@
+// { dg-do compile { target c++11 } }
+
+struct A;
+
+struct B
+{
+  constexpr A & operator= (const A &);  // { dg-warning "used" "" { target 
c++14_only } }
+};
+
+struct A : B  // { dg-error "cannot be overloaded" "" { target c++14_only } }
+{
+  using B::operator=;
+} a { a = a };

Re: [PATCH v4 01/10] Initial TI PRU GCC port

[Richard Sandiford]

Dimitar Dimitrov  writes:
> On Thursday, 9/13/2018 13:02:21 EEST Richard Sandiford wrote:
>> Dimitar Dimitrov  writes:
>> > +(define_insn
>> > "sub_impl_> > _zext_op2>" +  [(set (match_operand:EQD 0 "register_operand" "=r,r,r")
>> > +  (minus:EQD
>> > +   (zero_extend:EQD
>> > +(match_operand:EQS0 1 "reg_or_ubyte_operand" "r,r,I"))
>> > +   (zero_extend:EQD
>> > +(match_operand:EQS1 2 "reg_or_ubyte_operand" "r,I,r"]
>> > +  ""
>> > +  "@
>> > +   sub\\t%0, %1, %2
>> > +   sub\\t%0, %1, %2
>> > +   rsb\\t%0, %2, %1"
>> > +  [(set_attr "type" "alu")
>> > +   (set_attr "length" "4")])
>> 
>> By convention, subtraction patterns shouldn't accept constants for
>> operand 2.  Constants should instead be subtracted using an addition
>> of the negative.
> Understood. I will remove second alternative. But I will leave the third one 
> since it enables an important optimization:
>
>unsigned test(unsigned a)
>{
> return 10-a;
>}
>
> RTL:
> (insn 6 3 7 2 (set (reg:SI 152)
> (minus:SI (const_int 10 [0xa])
> (reg/v:SI 151 [ a ]))) "test.c":430 -1
>  (nil))
>
> Assembly:
> test:
> rsb r14, r14, 10
> ret

Thanks.  And yeah, the final alternative is fine.

>> > +;; Return true if OP is a text segment reference.
>> > +;; This is needed for program memory address expressions.  Borrowed from
>> > AVR. +(define_predicate "text_segment_operand"
>> > +  (match_code "code_label,label_ref,symbol_ref,plus,minus,const")
>> > +{
>> > +  switch (GET_CODE (op))
>> > +{
>> > +case CODE_LABEL:
>> > +  return true;
>> > +case LABEL_REF :
>> > +  return true;
>> > +case SYMBOL_REF :
>> > +  return SYMBOL_REF_FUNCTION_P (op);
>> > +case PLUS :
>> > +case MINUS :
>> > +  /* Assume canonical format of symbol + constant.
>> > +   Fall through.  */
>> > +case CONST :
>> > +  return text_segment_operand (XEXP (op, 0), VOIDmode);
>> > +default :
>> > +  return false;
>> > +}
>> > +})
>> 
>> This probably comes from AVR, but: no spaces before ":".
>> 
>> Bit surprised that we can get a CODE_LABEL rather than a LABEL_REF here.
>> Do you know if that triggers in practice, and if so where?
> Indeed, CODE_LABEL case is never reached. I'll leave gcc_unreachable here.
>
>> An IMO neater and slightly more robust way of writing the body is:
>>   poly_int64 offset:
>>   rtx base = strip_offset (op, );
>>   switch (GET_CODE (base))
>>   
>> {
>> 
>> case LABEL_REF:
>>   ...as above...
>> 
>> case SYMBOL_REF:
>>   ...as above...
>> 
>> default:
>>   return false;
>> 
>> }
>> 
>> with "plus" and "minus" not in the match_code list (since they should
>> always appear in consts if they really are text references).
>
> The "plus" and "minus" are needed when handling code labels as values. Take 
> for example the following construct:
>
>int x = & - &
> lab1:
>   ...
> lab2:
>
>
> My TARGET_ASM_INTEGER callback uses the text_segment_operand predicate. In 
> the 
> above case it is passed the following RTL expression:
> (minus:SI (label_ref/v:SI 20)
> (label_ref/v:SI 27))
>
> I need to detect text labels so that I annotate them with %pmem:
> .4byte%pmem(.L4-(.L2))
> Instead of the incorrect:
> .4byte   .L3-(.L2)

OK, thanks for the explanation.  I think the target-independent code should
really be passing (const (minus ...)) rather than a plain (minus ...) here,
but that's going to be difficult to change at this stage.  And like you say,
the split_offset suggestion wouldn't have handled this anyway.

So yeah, please keep what you have now.

>> > +/* Callback for walk_gimple_seq that checks TP tree for TI ABI
>> > compliance.  */ +static tree
>> > +check_op_callback (tree *tp, int *walk_subtrees, void *data)
>> > +{
>> > +  struct walk_stmt_info *wi = (struct walk_stmt_info *) data;
>> > +
>> > +  if (RECORD_OR_UNION_TYPE_P (*tp) || TREE_CODE (*tp) == ENUMERAL_TYPE)
>> > +{
>> > +  /* Forward declarations have NULL tree type.  Skip them.  */
>> > +  if (TREE_TYPE (*tp) == NULL)
>> > +  return NULL;
>> > +}
>> > +
>> > +  /* TODO - why C++ leaves INTEGER_TYPE forward declarations around?  */
>> > +  if (TREE_TYPE (*tp) == NULL)
>> > +return NULL;
>> > +
>> > +  const tree type = TREE_TYPE (*tp);
>> > +
>> > +  /* Direct function calls are allowed, obviously.  */
>> > +  if (TREE_CODE (*tp) == ADDR_EXPR && TREE_CODE (type) == POINTER_TYPE)
>> > +{
>> > +  const tree ptype = TREE_TYPE (type);
>> > +  if (TREE_CODE (ptype) == FUNCTION_TYPE)
>> > +  return NULL;
>> > +}
>> 
>> This seems like a bit of a dangerous heuristic.  Couldn't it also cause
>> us to skip things like:
>> 
>>(void *) func
>> 
>> ?  (OK, that's dubious C, but we do support it.)
> The cast yields a "data pointer", which is 32 bits for both types of ABI. 
> Hence it is safe to skip "(void *) func".
>
> The TI ABI's 16 bit function pointers become a 

[Ada] Fix PR ada/87396

[Eric Botcazou]

Enumeration types are unsigned in Ada so use 'unsigned char' instead of 'char' 
for mapping Attribute_Id.

Tested x86-64/Linux, applied on the mainline.


2018-09-24  Eric Botcazou  

PR ada/87396
* fe.h (Get_Attribute_Definition_Clause): Use 'unsigned char' instead
of 'char' as the type of the second parameter.

-- 
Eric BotcazouIndex: fe.h
===
--- fe.h	(revision 264466)
+++ fe.h	(working copy)
@@ -85,7 +85,7 @@ extern void Set_RM_Size			(Entity_Id, Ui
 extern Boolean Is_Entity_Name		(Node_Id);
 
 #define Get_Attribute_Definition_Clause einfo__get_attribute_definition_clause
-extern Node_Id Get_Attribute_Definition_Clause (Entity_Id, char);
+extern Node_Id Get_Attribute_Definition_Clause (Entity_Id, unsigned char);
 
 /* errout: */
 

[PATCH][DOC] Document all param values and remove defaults (PR middle-end/86078).

[Martin Liška]

Hi.

As mentioned in the PR we miss defaults for quite some param option.
I agreed with Richi that easiest way how to fix that would be to remove
that from documentation and use rather --help=param. It's done in the patch.

Apart from that I remove few unused params and added all not yet documented.
Description is taken from --help=param (params.def).

Is it fine to install? Is the community interested in the script I used
to find for missing/extra params?

gcc/ChangeLog:

2018-09-24  Martin Liska  

PR middle-end/86078
* doc/invoke.texi: Document all parameters and remove default
of the parameters.
---
 gcc/doc/invoke.texi | 327 
 1 file changed, 209 insertions(+), 118 deletions(-)


diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index e565f851971..5adf45f20c3 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -10428,19 +10428,22 @@ The names of specific parameters, and the meaning of the values, are
 tied to the internals of the compiler, and are subject to change
 without notice in future releases.
 
+In order to get minimal, maximal and default value of a parameter,
+one can use @option{--help=param -Q} options.
+
 In each case, the @var{value} is an integer.  The allowable choices for
 @var{name} are:
 
 @table @gcctabopt
 @item predictable-branch-outcome
 When branch is predicted to be taken with probability lower than this threshold
-(in percent), then it is considered well predictable. The default is 10.
+(in percent), then it is considered well predictable.
 
 @item max-rtl-if-conversion-insns
 RTL if-conversion tries to remove conditional branches around a block and
 replace them with conditionally executed instructions.  This parameter
 gives the maximum number of instructions in a block which should be
-considered for if-conversion.  The default is 10, though the compiler will
+considered for if-conversion.  The compiler will
 also use other heuristics to decide whether if-conversion is likely to be
 profitable.
 
@@ -10466,12 +10469,11 @@ probably small improvement in executable size.
 The minimum number of instructions that must be matched at the end
 of two blocks before cross-jumping is performed on them.  This
 value is ignored in the case where all instructions in the block being
-cross-jumped from are matched.  The default value is 5.
+cross-jumped from are matched.
 
 @item max-grow-copy-bb-insns
 The maximum code size expansion factor when copying basic blocks
 instead of jumping.  The expansion is relative to a jump instruction.
-The default value is 8.
 
 @item max-goto-duplication-insns
 The maximum number of instructions to duplicate to a block that jumps
@@ -10479,7 +10481,7 @@ to a computed goto.  To avoid @math{O(N^2)} behavior in a number of
 passes, GCC factors computed gotos early in the compilation process,
 and unfactors them as late as possible.  Only computed jumps at the
 end of a basic blocks with no more than max-goto-duplication-insns are
-unfactored.  The default value is 8.
+unfactored.
 
 @item max-delay-slot-insn-search
 The maximum number of instructions to consider when looking for an
@@ -10506,7 +10508,7 @@ optimization is not done.
 @item max-gcse-insertion-ratio
 If the ratio of expression insertions to deletions is larger than this value
 for any expression, then RTL PRE inserts or removes the expression and thus
-leaves partially redundant computations in the instruction stream.  The default value is 20.
+leaves partially redundant computations in the instruction stream.
 
 @item max-pending-list-length
 The maximum number of pending dependencies scheduling allows
@@ -10525,7 +10527,6 @@ This number sets the maximum number of instructions (counted in GCC's
 internal representation) in a single function that the tree inliner
 considers for inlining.  This only affects functions declared
 inline and methods implemented in a class declaration (C++).
-The default value is 400.
 
 @item max-inline-insns-auto
 When you use @option{-finline-functions} (included in @option{-O3}),
@@ -10533,14 +10534,12 @@ a lot of functions that would otherwise not be considered for inlining
 by the compiler are investigated.  To those functions, a different
 (more restrictive) limit compared to functions declared inline can
 be applied.
-The default value is 30.
 
 @item inline-min-speedup
 When estimated performance improvement of caller + callee runtime exceeds this
 threshold (in percent), the function can be inlined regardless of the limit on
 @option{--param max-inline-insns-single} and @option{--param
 max-inline-insns-auto}.
-The default value is 15.
 
 @item large-function-insns
 The limit specifying really large functions.  For functions larger than this
@@ -10548,11 +10547,10 @@ limit after inlining, inlining is constrained by
 @option{--param large-function-growth}.  This parameter is useful primarily
 to avoid extreme compilation time caused by non-linear algorithms used by the
 

Re: [PR87054] fix unaligned access

[Richard Biener]

On Mon, 24 Sep 2018, Alexandre Oliva wrote:

> On Sep 18, 2018, Richard Biener  wrote:
> 
> >> +# ifdef __SSE__
> >> +#  define T __int128
> 
> Rainer reported this didn't work on 32-bit x86 with SSE enabled.
> Here's a patch that fixes it.  Ok to install?  Tested on x86_64,
> including such combinations as -m32, -m32/-msse, and -m32/-mno-sse.

Works for me.

> 
> [PR87054] adjust testcase for 32-bit x86
> 
> From: Alexandre Oliva 
> 
> The test assumed __int128 to be available whenever __SSE__ was
> defined, but this assumption doesn't hold on 32-bit x86.  Fixed.
> 
> for  gcc/testsuite/ChangeLog
> 
>   PR middle-end/87054
>   * gcc.dg/pr87054.c: Adjust for no __int128 on x86.
> ---
>  gcc/testsuite/gcc.dg/pr87054.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/testsuite/gcc.dg/pr87054.c b/gcc/testsuite/gcc.dg/pr87054.c
> index 4ca2b62d2c7c9..3cb3b7dac6586 100644
> --- a/gcc/testsuite/gcc.dg/pr87054.c
> +++ b/gcc/testsuite/gcc.dg/pr87054.c
> @@ -2,7 +2,7 @@
>  // { dg-options "-O2" }
>  
>  #ifndef T
> -# ifdef __SSE__
> +# if __SIZEOF_INT128__ && defined __SSE__
>  #  define T __int128
>  # else
>  #  define T long
> 

[PATCH][GCC][ARM] New helper functions to check atomicity requirements

[Matthew Malcomson]

A few places in the arm and aarch64 backends check whether an atomic
operation needs acquire or release semantics.
This is generally done with a check like

(is_mm_relaxed (model)
  || is_mm_consume (model)
  || is_mm_release (model))

In this patch we introduce two helper functions to make things a little
tidier.

There are a few places in the arm/ backend that check whether an
operation needs memory model semantics with an idiom that can now be
replaced with the new aarch_mm_needs_* functions, so we make that
replacement.

There is also some backslash removal to make things a little tidier.

Full bootstrap and regression test plus cross-compilation regression tests done 
on arm-none-linux-gnueabihf.
Ok for trunk?

gcc/ChangeLog:

2018-09-24  Matthew Malcomson  

* config/arm/arm.c (arm_split_compare_and_swap, arm_split_atomic_op):
Use new helper functions.
* config/arm/sync.md (atomic_load, atomic_store):
Use new helper functions.
* config/arm/aarch-common-protos.h (aarch_mm_needs_acquire,
aarch_mm_needs_release): New declarations.
* config/arm/aarch-common.c (aarch_mm_needs_acquire,
aarch_mm_needs_release): New.


### Attachment also inlined for ease of reply###


diff --git a/gcc/config/arm/aarch-common-protos.h 
b/gcc/config/arm/aarch-common-protos.h
index 
6204482bbb91fc64dbe37f892559d02a6cdf42da..b9a9b0438f6dddb7468e2b3581dcd3202b85b898
 100644
--- a/gcc/config/arm/aarch-common-protos.h
+++ b/gcc/config/arm/aarch-common-protos.h
@@ -28,6 +28,8 @@ extern int aarch_crypto_can_dual_issue (rtx_insn *, rtx_insn 
*);
 extern bool aarch_rev16_p (rtx);
 extern bool aarch_rev16_shleft_mask_imm_p (rtx, machine_mode);
 extern bool aarch_rev16_shright_mask_imm_p (rtx, machine_mode);
+extern bool aarch_mm_needs_acquire (rtx);
+extern bool aarch_mm_needs_release (rtx);
 extern int arm_early_load_addr_dep (rtx, rtx);
 extern int arm_early_load_addr_dep_ptr (rtx, rtx);
 extern int arm_early_store_addr_dep (rtx, rtx);
diff --git a/gcc/config/arm/aarch-common.c b/gcc/config/arm/aarch-common.c
index 
f0675a339f9a1c20ed7206de10359e4798e48ec5..14eb49575480c392a4d872da9ea92633f6f8ca8f
 100644
--- a/gcc/config/arm/aarch-common.c
+++ b/gcc/config/arm/aarch-common.c
@@ -29,6 +29,7 @@
 #include "tm.h"
 #include "rtl.h"
 #include "rtl-iter.h"
+#include "memmodel.h"
 
 /* In ARMv8-A there's a general expectation that AESE/AESMC
and AESD/AESIMC sequences of the form:
@@ -230,6 +231,28 @@ aarch_rev16_p (rtx x)
   return is_rev;
 }
 
+/* Return non-zero if the RTX representing a memory model is a memory model
+   that needs acquire semantics.  */
+bool
+aarch_mm_needs_acquire (rtx const_int)
+{
+  enum memmodel model = memmodel_from_int (INTVAL (const_int));
+  return !(is_mm_relaxed (model)
+  || is_mm_consume (model)
+  || is_mm_release (model));
+}
+
+/* Return non-zero if the RTX representing a memory model is a memory model
+   that needs release semantics.  */
+bool
+aarch_mm_needs_release (rtx const_int)
+{
+  enum memmodel model = memmodel_from_int (INTVAL (const_int));
+  return !(is_mm_relaxed (model)
+  || is_mm_consume (model)
+  || is_mm_acquire (model));
+}
+
 /* Return nonzero if the CONSUMER instruction (a load) does need
PRODUCER's value to calculate the address.  */
 int
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 
6332e68df0506bb980cf55e05e7293b4a44d1e91..c7e6bf7f13467893c409d031a17a86594a2d160b
 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -28626,7 +28626,7 @@ arm_expand_compare_and_swap (rtx operands[])
 void
 arm_split_compare_and_swap (rtx operands[])
 {
-  rtx rval, mem, oldval, newval, neg_bval;
+  rtx rval, mem, oldval, newval, neg_bval, mod_s_rtx;
   machine_mode mode;
   enum memmodel mod_s, mod_f;
   bool is_weak;
@@ -28638,20 +28638,16 @@ arm_split_compare_and_swap (rtx operands[])
   oldval = operands[3];
   newval = operands[4];
   is_weak = (operands[5] != const0_rtx);
-  mod_s = memmodel_from_int (INTVAL (operands[6]));
+  mod_s_rtx = operands[6];
+  mod_s = memmodel_from_int (INTVAL (mod_s_rtx));
   mod_f = memmodel_from_int (INTVAL (operands[7]));
   neg_bval = TARGET_THUMB1 ? operands[0] : operands[8];
   mode = GET_MODE (mem);
 
   bool is_armv8_sync = arm_arch8 && is_mm_sync (mod_s);
 
-  bool use_acquire = TARGET_HAVE_LDACQ
- && !(is_mm_relaxed (mod_s) || is_mm_consume (mod_s)
- || is_mm_release (mod_s));
-   
-  bool use_release = TARGET_HAVE_LDACQ
- && !(is_mm_relaxed (mod_s) || is_mm_consume (mod_s)
- || is_mm_acquire (mod_s));
+  bool use_acquire = TARGET_HAVE_LDACQ && aarch_mm_needs_acquire (mod_s_rtx);
+  bool use_release = TARGET_HAVE_LDACQ && aarch_mm_needs_release (mod_s_rtx);
 
   /* For ARMv8, the load-acquire is too weak for __sync memory orders.  
Instead,
  a full barrier is emitted after the 

Re: [PR87054] fix unaligned access

[Alexandre Oliva]

On Sep 18, 2018, Richard Biener  wrote:

>> +# ifdef __SSE__
>> +#  define T __int128

Rainer reported this didn't work on 32-bit x86 with SSE enabled.
Here's a patch that fixes it.  Ok to install?  Tested on x86_64,
including such combinations as -m32, -m32/-msse, and -m32/-mno-sse.


[PR87054] adjust testcase for 32-bit x86

From: Alexandre Oliva 

The test assumed __int128 to be available whenever __SSE__ was
defined, but this assumption doesn't hold on 32-bit x86.  Fixed.

for  gcc/testsuite/ChangeLog

PR middle-end/87054
* gcc.dg/pr87054.c: Adjust for no __int128 on x86.
---
 gcc/testsuite/gcc.dg/pr87054.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/pr87054.c b/gcc/testsuite/gcc.dg/pr87054.c
index 4ca2b62d2c7c9..3cb3b7dac6586 100644
--- a/gcc/testsuite/gcc.dg/pr87054.c
+++ b/gcc/testsuite/gcc.dg/pr87054.c
@@ -2,7 +2,7 @@
 // { dg-options "-O2" }
 
 #ifndef T
-# ifdef __SSE__
+# if __SIZEOF_INT128__ && defined __SSE__
 #  define T __int128
 # else
 #  define T long


-- 
Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
Be the change, be Free! FSF Latin America board member
GNU Toolchain EngineerFree Software Evangelist

Re: [ARM] Fix ICE during thunk generation with -mlong-calls

[Eric Botcazou]

> Ah!  But that still doesn't explain why you want to skip these passes
> when building thunks.

They simply don't work because there is no CFG for thunks; I can add a blurb 
about that.

> So is the barrier correct, or isn't it?  There's really no two ways
> about this.  I don't like arbitrary changes that are justified solely on
> 'that's what another port does'.

The barrier is required by the arm_reorg pass, but it is optional when the 
pass is not run.  I think that we can consider that it is also correct.

-- 
Eric Botcazou

[PATCH, libgfortran] Remove recursion check

[Janne Blomqvist]

libgfortran has a recursion check in the error handling paths.  This
works by checking the value of a static variable, and if it matches,
aborting immediately instead of continuing error processing.
Unfortunately, in a multi-threaded program, if two threads report an
error at the same time, this can trigger this check, and thus the
underlying reason for the error is never reported.

The downside is that without the recursion check, it might be possible
to get into some infinite recursion in the error handling.  But by my
audit of the code, this shouldn't happen.

Regtested on x86_64-pc-linux-gnu, Ok for trunk?

libgfortran/ChangeLog:

2018-09-24  Janne Blomqvist  

* runtime/error.c (MAGIC): Remove.
(recursion_check): Remove function.
(os_error): Remove recursion_check call.
(runtime_error): Likewise.
(runtime_error_at): Likewise.
(internal_error): Likewise.
(generate_error_common): Likewise.
(notify_std): Likewise.
* runtime/minimal.c (MAGIC): Remove.
(recursion_check): Remove function.
(os_error): Remove recursion_check call.
(runtime_error): Likewise.
(runtime_error_at): Likewise.
(internal_error): Likewise.
---
 libgfortran/runtime/error.c   | 25 -
 libgfortran/runtime/minimal.c | 22 --
 2 files changed, 47 deletions(-)

diff --git a/libgfortran/runtime/error.c b/libgfortran/runtime/error.c
index b07a4c0b12a..b6cbd14ff6d 100644
--- a/libgfortran/runtime/error.c
+++ b/libgfortran/runtime/error.c
@@ -330,25 +330,6 @@ show_locus (st_parameter_common *cmp)
 }
 
 
-/* recursion_check()-- It's possible for additional errors to occur
- * during fatal error processing.  We detect this condition here and
- * exit with code 4 immediately. */
-
-#define MAGIC 0x20DE8101
-
-static void
-recursion_check (void)
-{
-  static int magic = 0;
-
-  /* Don't even try to print something at this point */
-  if (magic == MAGIC)
-sys_abort ();
-
-  magic = MAGIC;
-}
-
-
 #define STRERR_MAXSZ 256
 
 /* os_error()-- Operating system error.  We get a message from the
@@ -360,7 +341,6 @@ os_error (const char *message)
 {
   char errmsg[STRERR_MAXSZ];
   struct iovec iov[5];
-  recursion_check ();
   iov[0].iov_base = (char*) "Operating system error: ";
   iov[0].iov_len = strlen (iov[0].iov_base);
   iov[1].iov_base = gf_strerror (errno, errmsg, STRERR_MAXSZ);
@@ -388,7 +368,6 @@ runtime_error (const char *message, ...)
   va_list ap;
   int written;
 
-  recursion_check ();
   iov[0].iov_base = (char*) "Fortran runtime error: ";
   iov[0].iov_len = strlen (iov[0].iov_base);
   va_start (ap, message);
@@ -417,7 +396,6 @@ runtime_error_at (const char *where, const char *message, 
...)
   struct iovec iov[4];
   int written;
 
-  recursion_check ();
   iov[0].iov_base = (char*) where;
   iov[0].iov_len = strlen (where);
   iov[1].iov_base = (char*) "\nFortran runtime error: ";
@@ -473,7 +451,6 @@ internal_error (st_parameter_common *cmp, const char 
*message)
 {
   struct iovec iov[3];
 
-  recursion_check ();
   show_locus (cmp);
   iov[0].iov_base = (char*) "Internal Error: ";
   iov[0].iov_len = strlen (iov[0].iov_base);
@@ -674,7 +651,6 @@ generate_error_common (st_parameter_common *cmp, int 
family, const char *message
   /* Return code, caller is responsible for terminating
the program if necessary.  */
 
-  recursion_check ();
   show_locus (cmp);
   struct iovec iov[3];
   iov[0].iov_base = (char*) "Fortran runtime error: ";
@@ -766,7 +742,6 @@ notify_std (st_parameter_common *cmp, int std, const char * 
message)
 
   if (!warning)
 {
-  recursion_check ();
   show_locus (cmp);
   iov[0].iov_base = (char*) "Fortran runtime error: ";
   iov[0].iov_len = strlen (iov[0].iov_base);
diff --git a/libgfortran/runtime/minimal.c b/libgfortran/runtime/minimal.c
index b6d26fd2228..44ebd99af07 100644
--- a/libgfortran/runtime/minimal.c
+++ b/libgfortran/runtime/minimal.c
@@ -43,24 +43,6 @@ options_t options;
 static int argc_save;
 static char **argv_save;
 
-/* recursion_check()-- It's possible for additional errors to occur
- * during fatal error processing.  We detect this condition here and
- * exit with code 4 immediately. */
-
-#define MAGIC 0x20DE8101
-
-static void
-recursion_check (void)
-{
-  static int magic = 0;
-
-  /* Don't even try to print something at this point */
-  if (magic == MAGIC)
-sys_abort ();
-
-  magic = MAGIC;
-}
-
 
 /* os_error()-- Operating system error.  We get a message from the
  * operating system, show it and leave.  Some operating system errors
@@ -69,7 +51,6 @@ recursion_check (void)
 void
 os_error (const char *message)
 {
-  recursion_check ();
   printf ("Operating system error: ");
   printf ("%s\n", message);
   exit (1);
@@ -85,7 +66,6 @@ runtime_error (const char *message, ...)
 {
   va_list ap;
 
-  recursion_check ();
   printf ("Fortran runtime error: ");
   va_start (ap, message);
   vprintf (message, 

[RFC PATCH, i386]: Rewrite nearbyint expanders

[Uros Bizjak]

Hello!

Attached patch rewrites nearbyint expanders. The problem with the
current approach is, that setting mask flag of precision interrupt on
x87 only prevents interrupt generation, but the insn still sets
interrupt flag. fclex clears the flag, but it also clears other flags
(e.g. invalid flag, set by sNaN).

This issue can be "solved" by disabling x87 insn for
flag_trapping_math. The flag is considered by other instructions (e.g.
ceil, floor) as "we don't care if insn throws an exception"), so based
on this reasoning, we can as well convert nearbyint to rint (which
doesn't require complex control word set-up).

There is no issue with traps with SSE 4.1 round instruction. This
instruction can suppress generation of precision interrupt by setting
ROUND_NO_EXC bit in its immediate operand.

2018-09-24  Uros Bizjak  

* config/i386/i386.md (frndintxf2_mask_pm): Remove.
(frndintxf2_mask_pm_i387): Ditto.
(nearbyintxf2): Rewrite expander pattern to match rintxf2.
Enable for !flag_trapping_math.
(nearbyint2): Enable x87 modes for !flag_trapping_math.
Enable SSE modes for TARGET_SSE4_1 and expand them with round insn.
Change operand 1 predicate to nonimmediate_operand.
(attr "i387_cw"): Remove mask_pm.
* config/i386/i386.h (enum ix86_stack_slot): Remove SLOT_CW_MASK_PM.
(enum ix86_entity): Remove I387_MASK_PM.
* config/i386/i386.c (ix86_i387_mode_needed): Do not
handle I387_MASK_PM.
(ix86_mode_needed): Ditto.
(ix86_mode_after): Ditto.
(ix86_mode_entry): Ditto.
(ix86_mode_exit): Ditto.
(emit_i387_cw_initialization): Do not handle I387_CW_MASK_PM.

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

I'll wait a bit for possible comments on the approach.

Uros.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 6dd31309495..b627b215c95 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -18874,11 +18874,6 @@ ix86_i387_mode_needed (int entity, rtx_insn *insn)
return mode;
   break;
 
-case I387_MASK_PM:
-  if (mode == I387_CW_MASK_PM)
-   return mode;
-  break;
-
 default:
   gcc_unreachable ();
 }
@@ -18901,7 +18896,6 @@ ix86_mode_needed (int entity, rtx_insn *insn)
 case I387_TRUNC:
 case I387_FLOOR:
 case I387_CEIL:
-case I387_MASK_PM:
   return ix86_i387_mode_needed (entity, insn);
 default:
   gcc_unreachable ();
@@ -18962,7 +18956,6 @@ ix86_mode_after (int entity, int mode, rtx_insn *insn)
 case I387_TRUNC:
 case I387_FLOOR:
 case I387_CEIL:
-case I387_MASK_PM:
   return mode;
 default:
   gcc_unreachable ();
@@ -19015,7 +19008,6 @@ ix86_mode_entry (int entity)
 case I387_TRUNC:
 case I387_FLOOR:
 case I387_CEIL:
-case I387_MASK_PM:
   return I387_CW_ANY;
 default:
   gcc_unreachable ();
@@ -19050,7 +19042,6 @@ ix86_mode_exit (int entity)
 case I387_TRUNC:
 case I387_FLOOR:
 case I387_CEIL:
-case I387_MASK_PM:
   return I387_CW_ANY;
 default:
   gcc_unreachable ();
@@ -19102,12 +19093,6 @@ emit_i387_cw_initialization (int mode)
   slot = SLOT_CW_CEIL;
   break;
 
-case I387_CW_MASK_PM:
-  /* mask precision exception for nearbyint() */
-  emit_insn (gen_iorhi3 (reg, reg, GEN_INT (0x0020)));
-  slot = SLOT_CW_MASK_PM;
-  break;
-
 default:
   gcc_unreachable ();
 }
@@ -19163,7 +19148,6 @@ ix86_emit_mode_set (int entity, int mode, int prev_mode 
ATTRIBUTE_UNUSED,
 case I387_TRUNC:
 case I387_FLOOR:
 case I387_CEIL:
-case I387_MASK_PM:
   if (mode != I387_CW_ANY
  && mode != I387_CW_UNINITIALIZED)
emit_i387_cw_initialization (mode);
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 2fa9f2d53c4..3fa7d00aabc 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -2456,7 +2456,6 @@ enum ix86_stack_slot
   SLOT_CW_TRUNC,
   SLOT_CW_FLOOR,
   SLOT_CW_CEIL,
-  SLOT_CW_MASK_PM,
   SLOT_STV_TEMP,
   MAX_386_STACK_LOCALS
 };
@@ -2468,7 +2467,6 @@ enum ix86_entity
   I387_TRUNC,
   I387_FLOOR,
   I387_CEIL,
-  I387_MASK_PM,
   MAX_386_ENTITIES
 };
 
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index e08b2b7c14b..75e2edb791c 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -144,7 +144,6 @@
   UNSPEC_FRNDINT_FLOOR
   UNSPEC_FRNDINT_CEIL
   UNSPEC_FRNDINT_TRUNC
-  UNSPEC_FRNDINT_MASK_PM
   UNSPEC_FIST_FLOOR
   UNSPEC_FIST_CEIL
 
@@ -775,7 +774,7 @@
 
 ;; Defines rounding mode of an FP operation.
 
-(define_attr "i387_cw" "trunc,floor,ceil,mask_pm,uninitialized,any"
+(define_attr "i387_cw" "trunc,floor,ceil,uninitialized,any"
   (const_string "any"))
 
 ;; Define attribute to classify add/sub insns that consumes carry flag (CF)
@@ -16341,67 +16340,35 @@
   DONE;
 })
 
-;; Rounding mode control word calculation could clobber FLAGS_REG.
-(define_insn_and_split "frndintxf2_mask_pm"
+(define_expand "nearbyintxf2"
   [(set 

Re: [patch, fortran, committed] Another fallout from clobbering INTENT(OUT) variables

[Janus Weil]

Hi Thomas,

I'm seeing some more fallout from your intent(out) patch:

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

Cheers,
Janus

Am So., 23. Sep. 2018 um 22:23 Uhr schrieb Thomas König :
>
> Hello world,
>
> committed as obvious after regression-testing.  Instead of spending
> a lot of work trying to reducing the test case, I used all of it
> (retainging the copyright notice).
>
> Regards
>
> Thomas
>
> 2018-09-23  Thomas Koenig  
>
> PR fortran/87397
> * gfc_conv_procedure_call: Do not add clobber on INTENT(OUT)
> for variables having the dimension attribute.
>
> 2018-09-23  Thomas Koenig  
>
> PR fortran/87397
> * gfortran.dg/intent_out_11.f90: New test.
>

Re: [PATCH] Unpoison variable partition properly (PR sanitizer/85774).

[Jakub Jelinek]

On Mon, Sep 24, 2018 at 09:39:30AM +0200, Martin Liška wrote:
> Hi.
> 
> As always Jakub provided my very nice hint how to fix the issue.
> It's about adding representative of a stack partitioning into
> asan_handled_variables when another variable of the partition
> lies in asan_handled_variables.
> 
> Patch survives testing on ppc64le-linux-gnu.
> Ready for trunk?
> 
> gcc/ChangeLog:
> 
> 2018-09-21  Martin Liska  
> 
>   PR sanitizer/85774
>   * asan.c: Make asan_handled_variables extern.
>   * asan.h: Likewise.
>   * cfgexpand.c (expand_stack_vars): Make sure
>   a representative is unpoison if another
>   variable in the partition is handled by
>   use-after-scope sanitization.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-09-21  Martin Liska  
> 
>   PR sanitizer/85774
>   * g++.dg/asan/pr85774.C: New test.

Ok, thanks.

Jakub

[PATCH] Unpoison variable partition properly (PR sanitizer/85774).

[Martin Liška]

Hi.

As always Jakub provided my very nice hint how to fix the issue.
It's about adding representative of a stack partitioning into
asan_handled_variables when another variable of the partition
lies in asan_handled_variables.

Patch survives testing on ppc64le-linux-gnu.
Ready for trunk?

gcc/ChangeLog:

2018-09-21  Martin Liska  

PR sanitizer/85774
* asan.c: Make asan_handled_variables extern.
* asan.h: Likewise.
* cfgexpand.c (expand_stack_vars): Make sure
a representative is unpoison if another
variable in the partition is handled by
use-after-scope sanitization.

gcc/testsuite/ChangeLog:

2018-09-21  Martin Liska  

PR sanitizer/85774
* g++.dg/asan/pr85774.C: New test.
---
 gcc/asan.c  |  2 +-
 gcc/asan.h  |  2 ++
 gcc/cfgexpand.c | 14 
 gcc/testsuite/g++.dg/asan/pr85774.C | 51 +
 4 files changed, 68 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/asan/pr85774.C


diff --git a/gcc/asan.c b/gcc/asan.c
index e71ab2cc710..235e219479d 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -253,7 +253,7 @@ static tree last_alloca_addr;
 /* Set of variable declarations that are going to be guarded by
use-after-scope sanitizer.  */
 
-static hash_set *asan_handled_variables = NULL;
+hash_set *asan_handled_variables = NULL;
 
 hash_set  *asan_used_labels = NULL;
 
diff --git a/gcc/asan.h b/gcc/asan.h
index 412af220597..2f431b4f938 100644
--- a/gcc/asan.h
+++ b/gcc/asan.h
@@ -110,6 +110,8 @@ extern bool asan_sanitize_stack_p (void);
 
 extern bool asan_sanitize_allocas_p (void);
 
+extern hash_set *asan_handled_variables;
+
 /* Return TRUE if builtin with given FCODE will be intercepted by
libasan.  */
 
diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index c8d7805308c..35ca276e4ad 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -1155,6 +1155,20 @@ expand_stack_vars (bool (*pred) (size_t), struct stack_vars_data *data)
 	  if (repr_decl == NULL_TREE)
 		repr_decl = stack_vars[i].decl;
 	  data->asan_decl_vec.safe_push (repr_decl);
+
+	  /* Make sure a representative is unpoison if another
+		 variable in the partition is handled by
+		 use-after-scope sanitization.  */
+	  if (asan_handled_variables != NULL
+		  && !asan_handled_variables->contains (repr_decl))
+		{
+		  for (j = i; j != EOC; j = stack_vars[j].next)
+		if (asan_handled_variables->contains (stack_vars[j].decl))
+		  break;
+		  if (j != EOC)
+		asan_handled_variables->add (repr_decl);
+		}
+
 	  data->asan_alignb = MAX (data->asan_alignb, alignb);
 	  if (data->asan_base == NULL)
 		data->asan_base = gen_reg_rtx (Pmode);
diff --git a/gcc/testsuite/g++.dg/asan/pr85774.C b/gcc/testsuite/g++.dg/asan/pr85774.C
new file mode 100644
index 000..c033abfd69b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/asan/pr85774.C
@@ -0,0 +1,51 @@
+/* PR sanitizer/85774 */
+/* { dg-do run } */
+
+#include 
+
+void
+DoSomething ()
+{
+}
+
+void
+DoFunc (const std::function )
+{
+  func ();
+}
+
+void
+Setup ()
+{
+  switch (1)
+{
+case 1:
+  {
+	DoFunc ([]() {});
+	break;
+  }
+case 2:
+  {
+	DoFunc ([]() {});
+	break;
+  }
+default:
+  break;
+}
+
+  DoSomething ();
+}
+
+void
+DemostrateBadPoisoning ()
+{
+  DoFunc ([]() {});
+}
+
+int
+main ()
+{
+  Setup ();
+  DemostrateBadPoisoning ();
+  return 0;
+}

[PATCH 1/4] Add filter-rtags-warnings.py script.

[marxin]

contrib/ChangeLog:

2018-09-24  Martin Liska  

* filter-rtags-warnings.py: New file.
---
 contrib/filter-rtags-warnings.py | 71 
 1 file changed, 71 insertions(+)
 create mode 100755 contrib/filter-rtags-warnings.py

diff --git a/contrib/filter-rtags-warnings.py b/contrib/filter-rtags-warnings.py
new file mode 100755
index 000..ee27e7c8942
--- /dev/null
+++ b/contrib/filter-rtags-warnings.py
@@ -0,0 +1,71 @@
+#!/usr/bin/env python3
+#
+# Script to analyze warnings produced by rtags command (using LLVM):
+# rc --diagnose-all --synchronous-diagnostics --json
+#
+# 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 file COPYING3.  If not see
+# .  */
+#
+#
+#
+
+import sys
+import json
+import argparse
+
+def skip_warning(filename, warning):
+ignores = {
+'': ['-Warray-bounds', '-Wmismatched-tags', 'gcc_gfc: -Wignored-attributes', '-Wchar-subscripts',
+'string literal (potentially insecure): -Wformat-security', '-Wdeprecated-register',
+'-Wvarargs', 'keyword is hidden by macro definition', "but the argument has type 'char *': -Wformat-pedantic",
+'-Wnested-anon-types', 'qualifier in explicit instantiation of', 'attribute argument not supported: asm_fprintf'],
+'insn-modes.c': ['-Wshift-count-overflow'],
+'insn-emit.c': ['-Wtautological-compare'],
+'insn-attrtab.c': ['-Wparentheses-equality'],
+'gimple-match.c': ['-Wunused-', '-Wtautological-compare'],
+'generic-match.c': ['-Wunused-', '-Wtautological-compare'],
+}
+
+message = warning['message']
+
+if warning['type'] == 'fixit':
+return True
+
+for name, ignores in ignores.items():
+for i in ignores:
+if name in filename and i in message:
+return True
+
+return False
+
+parser = argparse.ArgumentParser()
+parser.add_argument('json_file', help = 'Rtags JSON file with diagnostics')
+parser.add_argument('-n', '--no-filter', action = 'store_true', help = 'No filter')
+
+args = parser.parse_args()
+
+data = json.load(open(args.json_file))
+file_warnings = data['checkStyle']
+
+total = 0
+for filename, warnings in file_warnings.items():
+if warnings:
+for w in warnings:
+if args.no_filter or not skip_warning(filename, w):
+total += 1
+print('%s:%d:%d:%s' % (filename, w['line'], w['column'], w['message']))
+
+print('Total: %d' % total)

[PATCH 3/4] Fix small coding style issues (PR fortran/87394).

[marxin]

gcc/ChangeLog:

2018-09-24  Martin Liska  

PR fortran/87394
* dbgcnt.c (dbg_cnt_process_single_pair): Return false
instead of NULL.
* dumpfile.c (dump_enable_all): Remove extra parenthesis.
* gcov-tool.c: Declare the function with ATTRIBUTE_NORETURN.
* godump.c (go_format_type): Remove extra parenthesis.

gcc/fortran/ChangeLog:

2018-09-24  Martin Liska  

PR fortran/87394
* decl.c (add_hidden_procptr_result): Simplify condition
as we are in branch witch 'case1 || case2'.
---
 gcc/dbgcnt.c   | 2 +-
 gcc/dumpfile.c | 4 ++--
 gcc/fortran/decl.c | 2 +-
 gcc/gcov-tool.c| 2 +-
 gcc/godump.c   | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/dbgcnt.c b/gcc/dbgcnt.c
index ddb0e8e76d9..1eea65889a8 100644
--- a/gcc/dbgcnt.c
+++ b/gcc/dbgcnt.c
@@ -138,7 +138,7 @@ dbg_cnt_process_single_pair (const char *arg)
   int high, low;
 
   if (value1 == NULL)
-return NULL;
+return false;
 
   if (value2 == NULL)
 {
diff --git a/gcc/dumpfile.c b/gcc/dumpfile.c
index a81ab3ed3c6..54f86237561 100644
--- a/gcc/dumpfile.c
+++ b/gcc/dumpfile.c
@@ -1511,7 +1511,7 @@ dump_enable_all (dump_kind dkind, dump_flags_t flags, const char *filename)
 
   for (i = TDI_none + 1; i < (size_t) TDI_end; i++)
 {
-  if ((dump_files[i].dkind == dkind))
+  if (dump_files[i].dkind == dkind)
 {
   const char *old_filename = dump_files[i].pfilename;
   dump_files[i].pstate = -1;
@@ -1532,7 +1532,7 @@ dump_enable_all (dump_kind dkind, dump_flags_t flags, const char *filename)
 
   for (i = 0; i < m_extra_dump_files_in_use; i++)
 {
-  if ((m_extra_dump_files[i].dkind == dkind))
+  if (m_extra_dump_files[i].dkind == dkind)
 {
   const char *old_filename = m_extra_dump_files[i].pfilename;
   m_extra_dump_files[i].pstate = -1;
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 91a1f34d7f1..7f79811d152 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -6463,7 +6463,7 @@ add_hidden_procptr_result (gfc_symbol *sym)
   gfc_symtree *stree;
   if (case1)
 	gfc_get_sym_tree ("ppr@", gfc_current_ns, , false);
-  else if (case2)
+  else
 	{
 	  gfc_symtree *st2;
 	  gfc_get_sym_tree ("ppr@", gfc_current_ns->parent, , false);
diff --git a/gcc/gcov-tool.c b/gcc/gcov-tool.c
index 88539f9647f..173ed5e5af2 100644
--- a/gcc/gcov-tool.c
+++ b/gcc/gcov-tool.c
@@ -438,7 +438,7 @@ static const struct option overlap_options[] =
 
 /* Print overlap usage and exit.  */
 
-static void
+static void ATTRIBUTE_NORETURN
 overlap_usage (void)
 {
   fnotice (stderr, "Overlap subcomand usage:");
diff --git a/gcc/godump.c b/gcc/godump.c
index 88e1a7782f1..baf21e27eec 100644
--- a/gcc/godump.c
+++ b/gcc/godump.c
@@ -961,7 +961,7 @@ go_format_type (struct godump_container *container, tree type,
 		   unions.  */
 		if (!is_anon_substructure)
 		  {
-		if ((DECL_NAME (field) == NULL))
+		if (DECL_NAME (field) == NULL)
 		  *p_art_i = go_append_artificial_name (ob, *p_art_i);
 		else
 		  go_append_decl_name

[PATCH 4/4] Fix scaling of a sreal number.

[marxin]

The patch is addressing following LLVM warning:
gcc/ipa-fnsummary.c:2745:54:Value Conversion Issue: implicit conversion from 
'double' to 'int64_t' (aka 'long') changes value from 0.99 to 0: 
-Wliteral-conversion

Taking look at GIMPLE IR we end up with:

   :
  D.107433 ={v} {CLOBBER};
  sreal::sreal (, -1, 0);
  sreal::sreal (, 0, 0);
  D.107435 = sreal::operator* (, );
  D.107436 = sreal::operator- (_time, );
  _65 = operator>= (, );
  _66 = ~_65;
  if (_66 != 0)
goto ; [INV]
  else
goto ; [INV]

   :
  fancy_abort ("/home/marxin/Programming/gcc/gcc/ipa-fnsummary.c", 2745, 
&__FUNCTION__);

which confirms the warning.

gcc/ChangeLog:

2018-09-23  Martin Liska  

* ipa-fnsummary.c (estimate_node_size_and_time): Scale by two
integers and not by a float value.
---
 gcc/ipa-fnsummary.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/ipa-fnsummary.c b/gcc/ipa-fnsummary.c
index 62095c6cf6f..9cb7d41ccc5 100644
--- a/gcc/ipa-fnsummary.c
+++ b/gcc/ipa-fnsummary.c
@@ -2742,7 +2742,7 @@ estimate_node_size_and_time (struct cgraph_node *node,
   gcc_checking_assert (time >= 0);
   /* nonspecialized_time should be always bigger than specialized time.
  Roundoff issues however may get into the way.  */
-  gcc_checking_assert ((nonspecialized_time - time * 0.99) >= -1);
+  gcc_checking_assert ((nonspecialized_time - time * 99 / 100) >= -1);
 
   /* Roundoff issues may make specialized time bigger than nonspecialized
  time.  We do not really want that to happen because some heurstics

[PATCH 2/4] Remove unused functions and fields.

[marxin]

gcc/ChangeLog:

2018-09-24  Martin Liska  

* alias.c (set_dest_equal_p): Remove unused function.
* config/i386/i386.c (def_builtin_pure2): Likewise.
* diagnostic-show-locus.c (class layout): Remove
unused field.
(layout::layout): Likewise here.
* dump-context.h (class temp_dump_context): Likewise.
* dwarf2out.c (add_AT_fde_ref): Remove unused function.
(add_AT_loclistsptr): Likewise.
(add_AT_offset): Likewise.
(get_AT_hi_pc): Likewise.
(is_comdat_die): Likewise.
(type_is_enum): Likewise.
(ceiling): Likewise.
(add_AT_vms_delta): Likewise.
(is_class_die): Likewise.
* edit-context.c (class line_event): Remove unused field.
* graphite-sese-to-poly.c (tree_int_to_gmp): Remove
unused function.
* ipa-cp.c (ipa_get_vr_lat): Likewise.
* lra-constraints.c (ok_for_index_p_nonstrict): Likewise.
(ok_for_base_p_nonstrict): Likewise.
* tree-chrec.c (is_not_constant_evolution): Likewise.
(chrec_fold_poly_cst): Likewise.
* tree-if-conv.c (has_pred_critical_p): Likewise.
* tree-ssa-coalesce.c (print_exprs): Likewise.
* tree-ssa-pre.c (bitmap_set_contains_expr): Likewise.
* tree-ssa-uninit.c (is_and_or_or_p): Likewise.
* tree-vrp.c (value_ranges_intersect_p): Likewise.
(value_range_nonnegative_p): Likewise.

gcc/cp/ChangeLog:

2018-09-24  Martin Liska  

* name-lookup.c (namespace_scope_ht_size): Remove
unused function.
* parser.c (cp_lexer_next_token_is_not_keyword): Likewise.

gcc/fortran/ChangeLog:

2018-09-24  Martin Liska  

* trans.c (remove_suffix): Remove
unused function.

gcc/go/ChangeLog:

2018-09-24  Martin Liska  

* gofrontend/escape.cc (Gogo::analyze_escape): Remove
usage of a parameter.
(Gogo::assign_connectivity): Likewise.
(class Escape_analysis_tag): Likewise.
(Gogo::tag_function): Likewise.
* gofrontend/expressions.cc (Call_expression::do_type): Likewise.
* gofrontend/gogo.h (class Gogo): Likewise.
* gofrontend/types.cc (class Call_multiple_result_type): Likewise.
(Type::make_call_multiple_result_type): Likewise.
* gofrontend/types.h (class Type): Likewise.
* gofrontend/wb.cc (class Check_escape): Likewise.
(Gogo::add_write_barriers): Likewise.
---
 gcc/alias.c  |   9 --
 gcc/config/i386/i386.c   |  15 
 gcc/cp/name-lookup.c |  15 
 gcc/cp/parser.c  |   8 --
 gcc/diagnostic-show-locus.c  |   2 -
 gcc/dump-context.h   |   1 -
 gcc/dwarf2out.c  | 141 ---
 gcc/edit-context.c   |   3 +-
 gcc/fortran/trans.c  |  20 -
 gcc/go/gofrontend/escape.cc  |  20 ++---
 gcc/go/gofrontend/expressions.cc |   2 +-
 gcc/go/gofrontend/gogo.h |   2 +-
 gcc/go/gofrontend/types.cc   |  13 +--
 gcc/go/gofrontend/types.h|   2 +-
 gcc/go/gofrontend/wb.cc  |  10 +--
 gcc/graphite-sese-to-poly.c  |   8 --
 gcc/ipa-cp.c |  10 ---
 gcc/lra-constraints.c|  27 --
 gcc/tree-chrec.c |  47 ---
 gcc/tree-if-conv.c   |  13 ---
 gcc/tree-ssa-coalesce.c  |  16 
 gcc/tree-ssa-pre.c   |   6 --
 gcc/tree-ssa-uninit.c|  10 ---
 gcc/tree-vrp.c   |  38 -
 24 files changed, 18 insertions(+), 420 deletions(-)

diff --git a/gcc/alias.c b/gcc/alias.c
index 748da2b6951..7963ece291a 100644
--- a/gcc/alias.c
+++ b/gcc/alias.c
@@ -3270,15 +3270,6 @@ memory_modified_in_insn_p (const_rtx mem, const_rtx insn)
   return memory_modified;
 }
 
-/* Return TRUE if the destination of a set is rtx identical to
-   ITEM.  */
-static inline bool
-set_dest_equal_p (const_rtx set, const_rtx item)
-{
-  rtx dest = SET_DEST (set);
-  return rtx_equal_p (dest, item);
-}
-
 /* Initialize the aliasing machinery.  Initialize the REG_KNOWN_VALUE
array.  */
 
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 0c86303b9fa..e50aa037c49 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -30224,21 +30224,6 @@ def_builtin_const2 (HOST_WIDE_INT mask, const char *name,
   return decl;
 }
 
-/* Like def_builtin, but also marks the function decl "pure".  */
-
-static inline tree
-def_builtin_pure2 (HOST_WIDE_INT mask, const char *name,
-		   enum ix86_builtin_func_type tcode, enum ix86_builtins code)
-{
-  tree decl = def_builtin2 (mask, name, tcode, code);
-  if (decl)
-DECL_PURE_P (decl) = 1;
-  else
-ix86_builtins_isa[(int) code].pure_p = true;
-
-  return decl;
-}
-
 /* Add any new builtin functions for a given ISA that may not have been
declared.  This saves a bit of space compared to adding all of the
declarations to the tree, even if we didn't use them. 

[PATCH 0/4] Clean-up warnings spotted by Rtags

[marxin]

Hello.

For quite some time I've been using Rtags for code completion and other
related stuff. Recently I noticed they provide diagnostics for an entire 
project.
Doing so, one can get quite some extra warning reported by Clang and I consider 
some
of them useful.

So that I would like to install my Python script that filters the warnings and 
few
patches that address the relevant warnings seen.

Patch survives bootstrap and regression tests on ppc64le-linux-gnu machine.

Martin

marxin (4):
  Add filter-rtags-warnings.py script.
  Remove unused functions and fields.
  Fix small coding style issues (PR fortran/87394).
  Fix scaling of a sreal number.

 contrib/filter-rtags-warnings.py |  71 
 gcc/alias.c  |   9 --
 gcc/config/i386/i386.c   |  15 
 gcc/cp/name-lookup.c |  15 
 gcc/cp/parser.c  |   8 --
 gcc/dbgcnt.c |   2 +-
 gcc/diagnostic-show-locus.c  |   2 -
 gcc/dump-context.h   |   1 -
 gcc/dumpfile.c   |   4 +-
 gcc/dwarf2out.c  | 141 ---
 gcc/edit-context.c   |   3 +-
 gcc/fortran/decl.c   |   2 +-
 gcc/fortran/trans.c  |  20 -
 gcc/gcov-tool.c  |   2 +-
 gcc/go/gofrontend/escape.cc  |  20 ++---
 gcc/go/gofrontend/expressions.cc |   2 +-
 gcc/go/gofrontend/gogo.h |   2 +-
 gcc/go/gofrontend/types.cc   |  13 +--
 gcc/go/gofrontend/types.h|   2 +-
 gcc/go/gofrontend/wb.cc  |  10 +--
 gcc/godump.c |   2 +-
 gcc/graphite-sese-to-poly.c  |   8 --
 gcc/ipa-cp.c |  10 ---
 gcc/ipa-fnsummary.c  |   2 +-
 gcc/lra-constraints.c|  27 --
 gcc/tree-chrec.c |  47 ---
 gcc/tree-if-conv.c   |  13 ---
 gcc/tree-ssa-coalesce.c  |  16 
 gcc/tree-ssa-pre.c   |   6 --
 gcc/tree-ssa-uninit.c|  10 ---
 gcc/tree-vrp.c   |  38 -
 31 files changed, 96 insertions(+), 427 deletions(-)
 create mode 100755 contrib/filter-rtags-warnings.py

-- 
2.19.0