[Bug target/87928] [7/8/9 Regression] ICE in ix86_compute_frame_layout, at config/i386/i386.c:11161 since r228607

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
One more similar back-trace:

$ gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-1.c
-Ofast -mcall-ms2sysv-xlogues -mandroid -mavx512vpopcntdq
during RTL pass: reload
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-1.c:
In function ‘func_cross’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-1.c:20:1:
internal compiler error: in ix86_compute_frame_layout, at
config/i386/i386.c:11169
   20 | }
  | ^
0x73bae0 ix86_compute_frame_layout
/home/marxin/Programming/gcc/gcc/config/i386/i386.c:11169
0xc268af update_reg_eliminate
/home/marxin/Programming/gcc/gcc/lra-eliminations.c:1207
0xc28f97 lra_eliminate(bool, bool)
/home/marxin/Programming/gcc/gcc/lra-eliminations.c:1460
0xc2058a lra_constraints(bool)
/home/marxin/Programming/gcc/gcc/lra-constraints.c:4716
0xc0d2a0 lra(_IO_FILE*)
/home/marxin/Programming/gcc/gcc/lra.c:2446
0xbbe87c do_reload
/home/marxin/Programming/gcc/gcc/ira.c:5469
0xbbe87c execute
/home/marxin/Programming/gcc/gcc/ira.c:5653

[Bug target/87928] New: ICE in ix86_compute_frame_layout, at config/i386/i386.c:11161 since r228607

[marxin at gcc dot gnu.org]

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

Bug ID: 87928
   Summary: ICE in ix86_compute_frame_layout, at
config/i386/i386.c:11161 since r228607
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Following causes ICE:

$ gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/aggregate-ret4.c
-mabi=ms -O1 -mstackrealign
during RTL pass: pro_and_epilogue
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/aggregate-ret4.c: In
function ‘bar’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/aggregate-ret4.c:24:1:
internal compiler error: in ix86_compute_frame_layout, at
config/i386/i386.c:11161
   24 | }
  | ^
0x73ba80 ix86_compute_frame_layout
/home/marxin/Programming/gcc/gcc/config/i386/i386.c:11161
0x111ef6f ix86_finalize_stack_frame_flags
/home/marxin/Programming/gcc/gcc/config/i386/i386.c:12925
0x11255e4 ix86_expand_prologue()
/home/marxin/Programming/gcc/gcc/config/i386/i386.c:13035
0x145df8a gen_prologue()
/home/marxin/Programming/gcc/gcc/config/i386/i386.md:12984
0x1107728 target_gen_prologue
/home/marxin/Programming/gcc/gcc/config/i386/i386.md:18928
0xab61c1 make_prologue_seq
/home/marxin/Programming/gcc/gcc/function.c:5713
0xab6367 thread_prologue_and_epilogue_insns()
/home/marxin/Programming/gcc/gcc/function.c:5830
0xab6a96 rest_of_handle_thread_prologue_and_epilogue
/home/marxin/Programming/gcc/gcc/function.c:6321
0xab6a96 execute
/home/marxin/Programming/gcc/gcc/function.c:6363

[Bug rtl-optimization/86438] [8/9 Regression] wrong code at -Os

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva  ---
The candidate patch regresses the regression test added along with the fix for
bug 49095.  At first I thought it should, but there seems to be logic in place
to adjust the compare for the flags-clobbering insn.

Re: [PATCH v3 1/6, Committed] [MIPS] Split Loongson (MMI) from loongson3a

[Paul Hua]

On Wed, Nov 7, 2018 at 5:12 PM Paul Hua  wrote:
>
> Hi, Matthew:
>
> I committed the patch. Thanks for your review.
>

After committed this patch some test failure under
with-arch=mips64r2(i only test under -with-arch=loongson3a).

  664 FAIL: gcc.target/mips/insn-casesi.c   -O0  (test for excess
errors)
  665 FAIL: gcc.target/mips/insn-casesi.c   -O1  (test for excess
errors)
  666 FAIL: gcc.target/mips/insn-casesi.c   -O2  (test for excess
errors)
  667 FAIL: gcc.target/mips/insn-casesi.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  (test for excess errors)
  668 FAIL: gcc.target/mips/insn-casesi.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  (test for excess errors)
  669 FAIL: gcc.target/mips/insn-casesi.c   -O3 -g  (test for excess
errors)
  670 FAIL: gcc.target/mips/insn-casesi.c   -Os  (test for excess errors)

The error message is " /usr/bin/as: unrecognized option '-mno-loongson-mmi' "

Those error come from follow options.
>   mips_option_dependency options "-mips16" "-mno-loongson-mmi"
>   mips_option_dependency options "-mmicromips" "-mno-loongson-mmi"
>   mips_option_dependency options "-msoft-float" "-mno-loongson-mmi"
>   mips_option_dependency options "-mmicromips" "-mno-loongson-ext"

We should add those dependency only config with
--with-arch=loongson3a/gs464/gs464e/gs246e.
I committed the attached patch as obvious.

Paul Hua
From 11a0bec83b3a0f2765d35b6aa84263016836f86e Mon Sep 17 00:00:00 2001
From: Chenghua Xu 
Date: Thu, 8 Nov 2018 15:01:35 +0800
Subject: [PATCH] Add mips option dependency only config with loongson target.

gcc/testsuite/
	* gcc.target/mips/mips.exp (mips-dg-options):
	Add mips_option_dependency msoft-float vs no-mmi and
	mips16/micromips vs no-mmi/ext/ext2 only gcc
	config with Loongson target.
---
 gcc/testsuite/gcc.target/mips/mips.exp | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/gcc.target/mips/mips.exp b/gcc/testsuite/gcc.target/mips/mips.exp
index e70d416d0dd..002cc280e30 100644
--- a/gcc/testsuite/gcc.target/mips/mips.exp
+++ b/gcc/testsuite/gcc.target/mips/mips.exp
@@ -1054,10 +1054,19 @@ proc mips-dg-options { args } {
 mips_option_dependency options "-mno-plt" "addressing=unknown"
 mips_option_dependency options "-mabicalls" "-G0"
 mips_option_dependency options "-mno-gpopt" "-mexplicit-relocs"
-mips_option_dependency options "-mips16" "-mno-loongson-mmi"
-mips_option_dependency options "-mmicromips" "-mno-loongson-mmi"
-mips_option_dependency options "-msoft-float" "-mno-loongson-mmi"
-mips_option_dependency options "-mmicromips" "-mno-loongson-ext"
+
+if { [check_configured_with "with-arch=loongson3a"] 
+	 || [check_configured_with "with-arch=gs464"]
+	 || [check_configured_with "with-arch=gs464e"]
+	 || [check_configured_with "with-arch=gs264e"] } {
+	mips_option_dependency options "-msoft-float" "-mno-loongson-mmi"
+	mips_option_dependency options "-mips16" "-mno-loongson-mmi"
+	mips_option_dependency options "-mips16" "-mno-loongson-ext"
+	mips_option_dependency options "-mips16" "-mno-loongson-ext2"
+	mips_option_dependency options "-mmicromips" "-mno-loongson-mmi"
+	mips_option_dependency options "-mmicromips" "-mno-loongson-ext"
+	mips_option_dependency options "-mmicromips" "-mno-loongson-ext2"
+}
 
 # Work out information about the current ABI.
 set abi_test_option_p [mips_test_option_p options abi]
-- 
2.18.0

Re: [PATCH] Fix PR87906

[Richard Biener]

On November 7, 2018 7:47:43 PM GMT+01:00, Rainer Orth 
 wrote:
>Hi Richard,
>
>> This adds a workaround for LTO decl merging prevailing a
>> non-ultimate origin decl, breaking invariants of the middle-end.
>> In the future (GCC 10) I hope to have DIE references here so
>> this will not be an issue there anymore.
>>
>> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
>>
>> Richard.
>>
>> From ff035da8314ea8e0889b99bb338e67dd5dae455b Mon Sep 17 00:00:00
>2001
>> From: Richard Guenther 
>> Date: Wed, 7 Nov 2018 08:56:52 +0100
>> Subject: [PATCH] fix-pr87906
>>
>> 2018-11-07  Richard Biener  
>>
>>  PR lto/87906
>>  * tree-streamer-in.c (lto_input_ts_block_tree_pointers): Fixup
>>  BLOCK_ABSTRACT_ORIGIN to be the ultimate origin.
>>
>>  * g++.dg/lto/pr87906_0.C: New testcase.
>>  * g++.dg/lto/pr87906_1.C: Likewise.
>>
>> diff --git a/gcc/testsuite/g++.dg/lto/pr87906_0.C
>b/gcc/testsuite/g++.dg/lto/pr87906_0.C
>> new file mode 100644
>> index 000..08e7ed3ba07
>> --- /dev/null
>> +++ b/gcc/testsuite/g++.dg/lto/pr87906_0.C
>> @@ -0,0 +1,35 @@
>> +// { dg-lto-do link }
>> +// { dg-lto-options { { -O -fPIC -flto } } }
>> +// { dg-extra-ld-options "-shared -nostdlib" }
>> +
>> +namespace com {
>> +namespace sun {
>> +namespace star {}
>> +} // namespace sun
>> +} // namespace com
>> +namespace a = com::sun::star;
>> +namespace com {
>> +namespace sun {
>> +namespace star {
>> +namespace uno {
>
>the new testcase FAILs on Solaris:
>
>+FAIL: g++.dg/lto/pr87906 cp_lto_pr87906_0.o assemble,  -O -fPIC -flto 
>+UNRESOLVED: g++.dg/lto/pr87906 cp_lto_pr87906_0.o-cp_lto_pr87906_1.o
>execute  -O -fPIC -flto 
>+UNRESOLVED: g++.dg/lto/pr87906 cp_lto_pr87906_0.o-cp_lto_pr87906_1.o
>link  -O -fPIC -flto 
>+FAIL: g++.dg/lto/pr87906 cp_lto_pr87906_1.o assemble,  -O -fPIC -flto 
>
>/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/lto/pr87906_0.C:6:11:
>error: expected identifier before numeric constant
>/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/lto/pr87906_0.C:6:11:
>error: expected unqualified-id before numeric constant
>
>and several more due to the -Dsun default.  How about
>sed -e 's/sun/moon/g' instead ;-)

Argh. Works for me. 

Richard. 

>   Rainer

Re: [patches] Re: [PATCH] Update soft-fp from glibc.

[Kito Cheng]

Hi Joseph:

I don't have commit right, could you help me to commit that, thanks :)

On Thu, Nov 8, 2018 at 1:14 AM Joseph Myers  wrote:
>
> This patch is OK.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

[Bug sanitizer/81902] new -fsanitize=pointer-overflow option undocumented

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||sandra at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from sandra at gcc dot gnu.org ---
Closing this issue as it has been fixed.

[Bug sanitizer/80998] Implement -fsanitize=pointer-overflow

[sandra at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80998
Bug 80998 depends on bug 81902, which changed state.

Bug 81902 Summary: new -fsanitize=pointer-overflow option undocumented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81902

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug middle-end/42726] -fno-common documentation inaccuracy

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||sandra at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from sandra at gcc dot gnu.org ---
This has (finally) been fixed on trunk.

[Bug rtl-optimization/86438] [8/9 Regression] wrong code at -Os

[aoliva at gcc dot gnu.org]

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

--- Comment #4 from Alexandre Oliva  ---
Created attachment 44970
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44970=edit
candidate patch

[doc, committed] clarify -fno-common behavior

[Sandra Loosemore]

I've checked in this patch to fix a minor but long-standing bug in the 
description of -fno-common, PR 42726.


-Sandra
2018-11-07  Sandra Loosemore  

	PR middle-end/42726

	gcc/
	* doc/invoke.texi (Code Gen Options): Clarify -fno-common behavior.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi	(revision 265904)
+++ gcc/doc/invoke.texi	(working copy)
@@ -13294,7 +13294,7 @@ C, and on some targets may carry a speed
 variable references.
 
 The @option{-fno-common} option specifies that the compiler should instead
-place uninitialized global variables in the data section of the object file.
+place uninitialized global variables in the BSS section of the object file.
 This inhibits the merging of tentative definitions by the linker so
 you get a multiple-definition error if the same 
 variable is defined in more than one compilation unit.

[Bug middle-end/42726] -fno-common documentation inaccuracy

[sandra at gcc dot gnu.org]

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

--- Comment #1 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Thu Nov  8 03:37:32 2018
New Revision: 265906

URL: https://gcc.gnu.org/viewcvs?rev=265906=gcc=rev
Log:
2018-11-07  Sandra Loosemore  

PR middle-end/42726

gcc/
* doc/invoke.texi (Code Gen Options): Clarify -fno-common behavior.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi

[Bug rtl-optimization/86438] [8/9 Regression] wrong code at -Os

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||aoliva at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |aoliva at gcc dot 
gnu.org

--- Comment #3 from Alexandre Oliva  ---
Mine

[Bug driver/80828] Command line option -e not documented

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||sandra at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from sandra at gcc dot gnu.org ---
Documentation for this option has been added on trunk.

There are several driver options, including this one, that don't include any
documentation for the --help output.  I'm not sure if that was deliberate or
not, but if it's a problem, it would be worth doing a review to see what else
is missing.

[doc, committed] remove leading dash from @opindex entries

[Sandra Loosemore]

I noticed this buglet when working on the PR80828 fix:

The introductory paragraph to the Option Index appendix says: "GCC’s 
command line options are indexed here without any initial ‘-’ or ‘--’." 
Indeed, that was mostly true, but there were ~20 index entries that 
incorrectly included the leading dash.  Fixed thusly.


-Sandra
2018-11-07  Sandra Loosemore  

	gcc/
	* doc/invoke.texi: Remove leading dash from @opindex entries
	throughout the file.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi	(revision 265903)
+++ gcc/doc/invoke.texi	(working copy)
@@ -2934,7 +2934,7 @@ union U @{
 
 @item -Wabi-tag @r{(C++ and Objective-C++ only)}
 @opindex Wabi-tag
-@opindex -Wabi-tag
+@opindex Wabi-tag
 Warn when a type with an ABI tag is used in a context that does not
 have that ABI tag.  See @ref{C++ Attributes} for more information
 about ABI tags.
@@ -3845,7 +3845,7 @@ a left margin is printed, showing line n
 left margin.
 
 @item -fdiagnostics-minimum-margin-width=@var{width}
-@opindex -fdiagnostics-minimum-margin-width
+@opindex fdiagnostics-minimum-margin-width
 This option controls the minimum width of the left margin printed by
 @option{-fdiagnostics-show-line-numbers}.  It defaults to 6.
 
@@ -5734,8 +5734,8 @@ larger.
 This option warns on all uses of @code{alloca} in the source.
 
 @item -Walloca-larger-than=@var{byte-size}
-@opindex -Walloca-larger-than=
-@opindex -Wno-alloca-larger-than
+@opindex Walloca-larger-than=
+@opindex Wno-alloca-larger-than
 This option warns on calls to @code{alloca} with an integer argument whose
 value is either zero, or that is not bounded by a controlling predicate
 that limits its value to at most @var{byte-size}.  It also warns for calls
@@ -6661,8 +6661,8 @@ real to lower precision real values.  Th
 @option{-Wconversion}.
 
 @item -Wno-scalar-storage-order
-@opindex -Wno-scalar-storage-order
-@opindex -Wscalar-storage-order
+@opindex Wno-scalar-storage-order
+@opindex Wscalar-storage-order
 Do not warn on suspicious constructs involving reverse scalar storage order.
 
 @item -Wsized-deallocation @r{(C++ and Objective-C++ only)}
@@ -7263,8 +7263,8 @@ Warn if a variable-length array is used
 the variable-length array.
 
 @item -Wvla-larger-than=@var{byte-size}
-@opindex -Wvla-larger-than=
-@opindex -Wno-vla-larger-than
+@opindex Wvla-larger-than=
+@opindex Wno-vla-larger-than
 If this option is used, the compiler will warn for declarations of
 variable-length arrays whose size is either unbounded, or bounded
 by an argument that allows the array size to exceed @var{byte-size}
@@ -8942,13 +8942,13 @@ it may significantly increase code size
 This flag is enabled by default at @option{-O3}.
 
 @item -fipa-bit-cp
-@opindex -fipa-bit-cp
+@opindex fipa-bit-cp
 When enabled, perform interprocedural bitwise constant
 propagation. This flag is enabled by default at @option{-O2}. It
 requires that @option{-fipa-cp} is enabled.
 
 @item -fipa-vrp
-@opindex -fipa-vrp
+@opindex fipa-vrp
 When enabled, perform interprocedural propagation of value
 ranges. This flag is enabled by default at @option{-O2}. It requires
 that @option{-fipa-cp} is enabled.
@@ -12559,7 +12559,7 @@ object file names should not be used as
 Options}.
 
 @item -flinker-output=@var{type}
-@opindex -flinker-output
+@opindex flinker-output
 This option controls the code generation of the link time optimizer.  By
 default the linker output is determined by the linker plugin automatically. For
 debugging the compiler and in the case of incremental linking to non-lto object
@@ -15105,8 +15105,8 @@ single precision and to 32 bits for doub
 
 @item -mlow-precision-sqrt
 @itemx -mno-low-precision-sqrt
-@opindex -mlow-precision-sqrt
-@opindex -mno-low-precision-sqrt
+@opindex mlow-precision-sqrt
+@opindex mno-low-precision-sqrt
 Enable or disable the square root approximation.
 This option only has an effect if @option{-ffast-math} or
 @option{-funsafe-math-optimizations} is used as well.  Enabling this reduces
@@ -15116,8 +15116,8 @@ If enabled, it implies @option{-mlow-pre
 
 @item -mlow-precision-div
 @itemx -mno-low-precision-div
-@opindex -mlow-precision-div
-@opindex -mno-low-precision-div
+@opindex mlow-precision-div
+@opindex mno-low-precision-div
 Enable or disable the division approximation.
 This option only has an effect if @option{-ffast-math} or
 @option{-funsafe-math-optimizations} is used as well.  Enabling this reduces
@@ -18109,11 +18109,11 @@ Specify the C-SKY target processor.  Val
 @item -mbig-endian
 @opindex mbig-endian
 @itemx -EB
-@opindex -EB
+@opindex EB
 @itemx -mlittle-endian
 @opindex mlittle-endian
 @itemx -EL
-@opindex -EL
+@opindex EL
 
 Select big- or little-endian code.  The default is little-endian.
 
@@ -27950,7 +27950,7 @@ preferred alignment to @option{-mpreferr
 @opindex mvaes
 @need 200
 @itemx -mwaitpkg
-@opindex -mwaitpkg
+@opindex mwaitpkg
 @need 200
 @itemx -mvpclmulqdq
 @opindex mvpclmulqdq
@@ -28536,7 

Re: [RFC][PATCH LRA] WIP patch to fix one part of PR87507

[Peter Bergner]

On 11/7/18 11:36 AM, Jeff Law wrote:
> OK with this change.

Before I commit, how about I add the following test cases to test
both valid and invalid asm constraints?  I think I have the reg
numbers for the other architectures defined correctly. 

Peter


gcc/testsuite/
PR rtl-optimization/87600
* gcc.dg/pr87600.h: New.
* gcc.dg/pr87600-1.c: Likewise.
* gcc.dg/pr87600-2.c: Likewise.

Index: gcc/testsuite/gcc.dg/pr87600.h
===
--- gcc/testsuite/gcc.dg/pr87600.h  (nonexistent)
+++ gcc/testsuite/gcc.dg/pr87600.h  (working copy)
@@ -0,0 +1,19 @@
+#if defined (__aarch64__)
+# define REG1 "x0"
+# define REG2 "x1"
+#elif defined (__arm__)
+# define REG1 "r0"
+# define REG2 "r1"
+#elif defined (__i386__)
+# define REG1 "%eax"
+# define REG2 "%edx"
+#elif defined (__powerpc__)
+# define REG1 "r3"
+# define REG2 "r4"
+#elif defined (__s390__)
+# define REG1 "0"
+# define REG2 "1"
+#elif defined (__x86_64__)
+# define REG1 "rax"
+# define REG2 "rdx"
+#endif
Index: gcc/testsuite/gcc.dg/pr87600-1.c
===
--- gcc/testsuite/gcc.dg/pr87600-1.c(nonexistent)
+++ gcc/testsuite/gcc.dg/pr87600-1.c(working copy)
@@ -0,0 +1,52 @@
+/* PR rtl-optimization/87600  */
+/* { dg-do compile { target aarch64*-*-* arm*-*-* i?86-*-* powerpc*-*-* 
s390*-*-* x86_64-*-* } } */
+/* { dg-options "-O2" } */
+
+#include "pr87600.h"
+
+/* The following are all valid uses of local register variables.  */
+
+long
+test0 (long arg)
+{
+  register long var asm (REG1);
+  asm ("blah %0 %1" : "+" (var) : "r" (arg));
+  return var;
+}
+
+long
+test1 (long arg0, long arg1)
+{
+  register long var asm (REG1);
+  asm ("blah %0, %1, %2" : "=" (var) : "r" (arg0), "0" (arg1));
+  return var + arg1;
+}
+
+long
+test2 (void)
+{
+  register long var1 asm (REG1);
+  register long var2 asm (REG1);
+  asm ("blah %0 %1" : "=" (var1) : "0" (var2));
+  return var1;
+}
+
+long
+test3 (void)
+{
+  register long var1 asm (REG1);
+  register long var2 asm (REG2);
+  long var3;
+  asm ("blah %0 %1" : "=" (var1), "=r" (var3) : "1" (var2));
+  return var1 + var3;
+}
+
+long
+test4 (void)
+{
+  register long var1 asm (REG1);
+  register long var2 asm (REG2);
+  register long var3 asm (REG2);
+  asm ("blah %0 %1" : "=" (var1), "=r" (var2) : "1" (var3));
+  return var1;
+}
Index: gcc/testsuite/gcc.dg/pr87600-2.c
===
--- gcc/testsuite/gcc.dg/pr87600-2.c(nonexistent)
+++ gcc/testsuite/gcc.dg/pr87600-2.c(working copy)
@@ -0,0 +1,44 @@
+/* PR rtl-optimization/87600  */
+/* { dg-do compile { target aarch64*-*-* arm*-*-* i?86-*-* powerpc*-*-* 
s390*-*-* x86_64-*-* } } */
+/* { dg-options "-O2" } */
+
+#include "pr87600.h"
+
+/* The following are all invalid uses of local register variables.  */
+
+long
+test0 (void)
+{
+  register long var1 asm (REG1);
+  register long var2 asm (REG1);
+  asm ("blah %0 %1" : "=r" (var1), "=r" (var2)); /* { dg-error "invalid hard 
register usage between output operands" } */
+  return var1;
+}
+
+long
+test1 (void)
+{
+  register long var1 asm (REG1);
+  register long var2 asm (REG2);
+  asm ("blah %0 %1" : "=r" (var1) : "0" (var2)); /* { dg-error "invalid hard 
register usage between output operand and matching constraint operand" } */
+  return var1;
+}
+
+long
+test2 (void)
+{
+  register long var1 asm (REG1);
+  register long var2 asm (REG1);
+  asm ("blah %0 %1" : "=" (var1) : "r" (var2)); /* { dg-error "invalid hard 
register usage between earlyclobber operand and input operand" } */
+  return var1;
+}
+
+long
+test3 (void)
+{
+  register long var1 asm (REG1);
+  register long var2 asm (REG1);
+  long var3;
+  asm ("blah %0 %1" : "=" (var1), "=r" (var3) : "1" (var2)); /* { dg-error 
"invalid hard register usage between earlyclobber operand and input operand" } 
*/
+  return var1 + var3;
+}

Re: [PATCH] Add sinh(tanh(x)) and cosh(tanh(x)) rules

[Segher Boessenkool]

On Wed, Nov 07, 2018 at 10:34:30PM +, Wilco Dijkstra wrote:
> Hi Jeff,
> 
> > So if we're going from 0->2 ULPs in some cases, do we want to guard it
> > with one of the various options, if so, which?  Giuliano's follow-up
> > will still have the potential for 2ULPs.
> 
> The ULP difference is not important since the individual math functions 
> already have ULP of 3 or higher. Changing ULP error for some or all inputs
> (like we did with the rewritten math functions) is not considered an issue as
> long as worst-case ULP error doesn't increase.

But the max. error in sinh/cosh/atanh is less than 2 ULP, with some math
libraries.  It could be < 1 ULP, in theory, so sinh(atanh(x)) less than
2 ULP even.

> The question is more like whether errno and trapping/exception behaviour
> is identical - I guess it is not so I would expect this to be fastmath only.
> Which particular flag one uses is a detail given there isn't a clear 
> definition
> for most of them.

And signed zeroes.  Yeah.  I think it would have to be
flag_unsafe_math_optimizations + some more.


Segher

[Bug target/87927] ICE: segmentation fault with patchable_function_entry attribute for msp430-elf -mlarge

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Patches should be sent to gcc-patches@ after reading
https://gcc.gnu.org/contribute.html .

[doc, committed] document -e and --entry

[Sandra Loosemore]

Trying to knock off some easy documentation bugs from bugzilla...

I've checked in this patch to fix PR driver/80828, about missing 
documentation for these options that are passed through to the linker.


-Sandra

2018-11-07  Sandra Loosemore  

	PR driver/80828

	gcc/
	* doc/invoke.texi (Option Summary): Add -e and --entry.
	(Link Options): Likewise.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi	(revision 265902)
+++ gcc/doc/invoke.texi	(working copy)
@@ -524,6 +524,7 @@ Objective-C and Objective-C++ Dialects}.
 @xref{Link Options,,Options for Linking}.
 @gccoptlist{@var{object-file-name}  -fuse-ld=@var{linker}  -l@var{library} @gol
 -nostartfiles  -nodefaultlibs  -nolibc  -nostdlib @gol
+-e @var{entry}  --entry=@var{entry} @gol
 -pie  -pthread  -r  -rdynamic @gol
 -s  -static -static-pie -static-libgcc  -static-libstdc++ @gol
 -static-libasan  -static-libtsan  -static-liblsan  -static-libubsan @gol
@@ -12712,6 +12713,15 @@ library subroutines.
 constructors are called; @pxref{Collect2,,@code{collect2}, gccint,
 GNU Compiler Collection (GCC) Internals}.)
 
+@item -e @var{entry}
+@itemx --entry=@var{entry}
+@opindex e
+@opindex entry
+
+Specify that the program entry point is @var{entry}.  The argument is
+interpreted by the linker; the GNU linker accepts either a symbol name
+or an address.
+
 @item -pie
 @opindex pie
 Produce a dynamically linked position independent executable on targets

[Bug driver/80828] Command line option -e not documented

[sandra at gcc dot gnu.org]

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

--- Comment #2 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Thu Nov  8 01:26:28 2018
New Revision: 265903

URL: https://gcc.gnu.org/viewcvs?rev=265903=gcc=rev
Log:
2018-11-07  Sandra Loosemore  

PR driver/80828

gcc/
* doc/invoke.texi (Option Summary): Add -e and --entry.
(Link Options): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi

Re: [PATCH 4/6] [RS6000] Remove constraints on call rounded_stack_size_rtx arg

[Segher Boessenkool]

On Wed, Nov 07, 2018 at 04:09:06PM +1030, Alan Modra wrote:
> This call arg is unused on rs6000.

This is fine.  Okay for trunk.  Thank you!


Segher


>   * config/rs6000/darwin.md (call_indirect_nonlocal_darwin64,
>   call_nonlocal_darwin64, call_value_indirect_nonlocal_darwin64,
>   call_value_nonlocal_darwin64): Remove constraints from second call
>   arg, the rounded_stack_size_rtx arg.
>   * config/rs6000/rs6000.md (tls_gd_aix, tls_gd_sysv,
>   tls_gd_call_aix, tls_gd_call_sysv, tls_ld_aix, tls_ld_sysv,
>   tls_ld_call_aix, tls_ld_call_sysv, call_local32, call_local64,
>   call_value_local32, call_value_local64, call_indirect_nonlocal_sysv,
>   call_nonlocal_sysv, call_nonlocal_sysv_secure,
>   call_value_indirect_nonlocal_sysv, call_value_nonlocal_sysv,
>   call_value_nonlocal_sysv_secure, call_local_aix,
>   call_value_local_aix, call_nonlocal_aix, call_value_nonlocal_aix,
>   call_indirect_aix, call_value_indirect_aix, call_indirect_elfv2,
>   call_value_indirect_elfv2, sibcall_local32, sibcall_local64,
>   sibcall_value_local32, sibcall_value_local64, sibcall_aix,
>   sibcall_value_aix): Likewise.

Re: [PATCH 3/6] [RS6000] Replace TLSmode with P, and correct tls call mems

[Segher Boessenkool]

On Wed, Nov 07, 2018 at 04:08:26PM +1030, Alan Modra wrote:
> There is really no need to define a TLSmode mode iterator that is
> identical (since !TARGET_64BIT == TARGET_32BIT) to the much used P
> mode iterator.

Nice :-)

> It's nonsense to think we might ever want to support
> 32-bit TLS on 64-bit or vice versa!  The patch also fixes a minor
> error in the call mems.  All other direct calls use (call (mem:SI ..)).

You can also replace  with ,  with
, and l with .  Also, was "TLSmode:"
needed anywhere?  I don't see any other iterator used in those patterns.

>   * config/rs6000/rs6000.md (TLSmode): Delete mode iterator.  Replace
>   with P throughout except for call mems which should use SI.

Approved for trunk.  Further cleanup as above pre-approved.  Thanks!


Segher

[PATCH] minor FDO profile related fixes

[Indu Bhagat]

I have been looking at -fdump-ipa-profile dump with an intention to sanitize
bits of information so that one may use it to judge the "quality of a profile"
in FDO.

The overall question I want to address is - are there ways to know which
functions were not run in the training run, i.e. have ZERO profile ?
(This patch corrects some dumped info; in a subsequent patch I would like to add
some more explicit information/diagnostics.)

Towards that end, I noticed that there are a couple of misleading bits of
information (so I think) in the symbol table dump listing all functions in the
compilation unit :
   --- "globally 0" appears even when profile data has not been fed by feedback
profile (not the intent as the documentation of profile_guessed_global0
 in profile-count.h suggests).
   --- "unlikely_executed" should appear only when there is profile feedback or
   a function attribute is specified (as per documentation of
   node_frequency in coretypes.h). "unlikely_executed" in case of STALE or
   NO profile is misleading in my opinion.

Summary of changes :

1. This patch makes some adjustments around how x_profile_status of a function
is set - x_profile_status should be set to PROFILE_READ only when there is a
profile for a function read from the .gcda file. So, instead of relying on
profile_info (set whenever the gcda feedback file is present, even if the
function does not have a profile available in the file), use exec_counts
(non null when function has a profile (the latter may or may not be zero)). In
essence, x_profile_status and profile_count::m_quality
are set consistent to the stated intent (in code comments.)

2. A minor change in coverage.c is for more precise location of the message

Following -fdump-ipa-profile dump excerpts show the effect :


 -O1, -O2, -O3


0. APPLICABLE PROFILE
Trunk : Function flags: count:224114269 body hot
After Patch : Function flags: count:224114269 (precise) body hot

1. STALE PROFILE
(i.e., those cases covered by Wcoverage-mismatch; when control flow changes
 between profile-generate and profile-use)
Trunk : Function flags: count:224114269 body hot
After Patch : Function flags: count:224114269 (precise) body hot

2. NO PROFILE
(i.e., those cases covered by Wmissing-profile; when function has no profile
 available in the .gcda file)
Trunk (missing .gcda file) : Function flags: count:1073741824 (estimated 
locally) body
Trunk (missing function) : Function flags: count: 1073741824 (estimated 
locally, globally 0) body unlikely_executed
After Patch (missing .gcda file) : Function flags: count:1073741824 (estimated 
locally) body
After Patch (missing function) : Function flags: count:1073741824 (estimated 
locally) body

3. ZERO PROFILE (functions not run in training run)
Trunk : Function flags: count: 1073741824 (estimated locally, globally 0) body 
unlikely_executed
After Patch (remains the same) : count: 1073741824 (estimated locally, globally 
0) body unlikely_executed

--
O0
--
In O0, flag_guess_branch_prob is not set. This makes the profile_quality set to
(precise) for most of the above cases.

0. APPLICABLE PROFILE
Trunk : Function flags: count:224114269 body hot
After Patch : Function flags: count:224114269 (precise) body hot

1. STALE PROFILE
(i.e., those cases covered by Wcoverage-mismatch; when control flow changes
 between profile-generate and profile-use)
Trunk : Function flags: count:224114269 body hot
After Patch : Function flags: count:224114269 (precise) body hot

2. NO PROFILE
(i.e., those cases covered by Wmissing-profile; when function has no profile
 available in the .gcda file)
Trunk (missing file) : Function flags: body
Trunk (missing function) : Function flags: count:0 body unlikely_executed
After Patch (missing file) :  Function flags: body
*** After Patch (missing function) : Function flags: count:0 (precise) body
(*** This remains misleading, and I do not have a solution for this; as use of 
heuristics
 to guess branch probability is not allowed in O0)

3. ZERO PROFILE (functions not run in training run)
Trunk : Function flags: count:0 body unlikely_executed
After Patch : Function flags: count:0 (precise) body

--

make check-gcc on x86_64 shows no new failures.

(A related PR was https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86957 where we 
added diagnostics for the NO PROFILE case.)

diff --git a/gcc/coverage.c b/gcc/coverage.c
index 599a3bb..7595e6c 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -358,7 +358,7 @@ get_coverage_counts (unsigned counter, unsigned 
cfg_checksum,
   if (warning_printed && dump_enabled_p ())
{
  dump_user_location_t loc
-   = dump_user_location_t::from_location_t (input_location);
+   = 

[Bug c/87927] ICE: segmentation fault with patchable_function_entry attribute for msp430-elf -mlarge

[jozef.l at mittosystems dot com]

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

Jozef Lawrynowicz  changed:

   What|Removed |Added

  Attachment #44968|0   |1
is obsolete||

--- Comment #2 from Jozef Lawrynowicz  ---
Created attachment 44969
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44969=edit
proposed patch (fixed)

Fixed wrong ordering of new elements in "struct asm_int_op"

[Bug target/87690] [RISCV][ABI] GCC fails to sign-extend floats passed in the lp64 ABI

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Jim Wilson  ---
The proposed psABI change was accepted, so no gcc change is necessary.

Re: [PATCH 1/6] [RS6000] rs6000_output_call for external call insn assembly output

[Segher Boessenkool]

On Wed, Nov 07, 2018 at 04:07:15PM +1030, Alan Modra wrote:
> +extern const char *rs6000_output_call (rtx *, unsigned int, bool, const char 
> *);

Maybe have a separate rs6000_output_call and rs6000_output_sibcall?  Bare
boolean function parameters aren't great.  (They can of course both call
rs6000_output_call_1 or whatever, if that makes sense).

> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -21380,6 +21380,37 @@ rs6000_assemble_integer (rtx x, unsigned int size, 
> int aligned_p)
>return default_assemble_integer (x, size, aligned_p);
>  }
>  
> +/* Return a template string for assembly to emit when making an
> +   external call.  FUN is the %z argument, ARG is either NULL or
> +   a @TLSGD or @TLSLD __tls_get_addr argument specifier.  */
> +
> +const char *
> +rs6000_output_call (rtx *operands, unsigned int fun, bool sibcall,
> + const char *arg)
> +{
> +  /* -Wformat-overflow workaround, without which gcc thinks that %u
> +  might produce 10 digits.  FUN is 0 or 1 as of 2018-03.  */
> +  gcc_assert (fun <= 6);

So "fun" is the operand number.  Rename it, and use MAX_RECOG_OPERANDS
instead of 6?  And allow for it to take 2 or 3 chars to print :-)

"operands" is unused here, compiling this will warn.

"output" is a lie, this function doesn't output anything.  Hardly the
only case of this in the rs6000 port, but it is annoying.  What would be
a good name for this...  "rs6000_template_for_call"?


Are there some patterns that can be collapsed to one after this?


Segher

[Bug c/87927] ICE: segmentation fault with patchable_function_entry attribute for msp430-elf -mlarge

[jozef.l at mittosystems dot com]

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

--- Comment #1 from Jozef Lawrynowicz  ---
Created attachment 44968
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44968=edit
proposed patch

In default_print_patchable_function_entry, integer_asm_op is passed
POINTER_SIZE_UNITS. For msp430-elf -mlarge, this is 3, which is not handled in
integer_asm_op, so it returns NULL.
fputs is directly writing out the return value of integer_asm_op, so when this
is NULL we are segfaulting.

Attached is a proposed patch which implements
TARGET_ASM_{,UN}ALIGNED_P{S,D,T}I_OP, so integer_asm_op will not return NULL
for values < 16.

This fixes the c-c++-common/patchable_function_entry* tests but is otherwise
untested.

[Bug c/87927] New: ICE: segmentation fault with patchable_function_entry attribute for msp430-elf -mlarge

[jozef.l at mittosystems dot com]

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

Bug ID: 87927
   Summary: ICE: segmentation fault with patchable_function_entry
attribute for msp430-elf -mlarge
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jozef.l at mittosystems dot com
  Target Milestone: ---

Use of the patchable_function_entry attribute with msp430-elf in the large
memory model causes a segfault on trunk.

For example in c-c++-common/patchable_function_entry-decl.c:

> extern int a;
> 
> int f3 (void) __attribute__((patchable_function_entry(2)));
> 
> int
> __attribute__((noinline))
> f3 (void)
> {
>   return 5*a;
> }

> gcc -mlarge -fpatchable-function-entry=3,1 -S 
> gcc/testsuite/c-c++-common/patchable_function_entry-decl.c

> gcc/testsuite/c-c++-common/patchable_function_entry-decl.c: In function 'f3':
> gcc/testsuite/c-c++-common/patchable_function_entry-decl.c:18:1: internal 
> compiler error: Segmentation fault
> 0xb5e4af crash_signal
>   ../../gcc/toplev.c:325
> 0xb59d41 default_print_patchable_function_entry(_IO_FILE*, unsigned long, 
> bool)
>   ../../gcc/targhooks.c:1816
> 0xe94d2c assemble_start_function(tree_node*, char const*)
>   ../../gcc/varasm.c:1903
> 0x84188f rest_of_handle_final
>   ../../gcc/final.c:4645
> 0x84188f execute
>   ../../gcc/final.c:4723

[Bug c++/79393] [7/8/9 Regression] cc1plus rejects valid code with noexcept

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|SUSPENDED   |ASSIGNED

--- Comment #11 from Nathan Sidwell  ---
Is 2336 now has a proposed solution.

Re: [PATCH] combine: Do not combine moves from hard registers

[Segher Boessenkool]

Hi!

On Mon, Nov 05, 2018 at 06:16:16PM +, Renlin Li wrote:
> Sorry, this is not correct. Instructions scheduled between x and x+1 
> directly use hard register r1.
> It is not IRA/LRA assigning r1 to the operands.
> 
> 
> To reproduce this particular case, you could use:
> cc1  -O3 -marm -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp 
> gcc.c-torture/execute/builtins/memcpy-chk.c
> 
> This insn is been splitted.
> 
> (insn 152 150 154 11 (set (mem/c:QI (plus:SI (reg/f:SI 266)
> (const_int 24 [0x18])) [0 MEM[(void *) + 20B]+4 S1 A32])
> (reg:QI 1 r1)) "memcpy-chk-reduce.c":48:3 189 {*arm_movqi_insn}
>  (expr_list:REG_DEAD (reg:QI 1 r1)
> (nil)))

Okay, I see what is going on.  The arm port often expands movmem to use
hard registers (so that it can use load/store multiple?).  This does not
work well with scheduling and RA, and this combine feature makes it worse.

I don't know what to do about it in combine.


Segher

[Bug tree-optimization/87926] bad array-index warning breaks --disable-checking bootstrap

[nathan at gcc dot gnu.org]

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

--- Comment #1 from Nathan Sidwell  ---
Author: nathan
Date: Wed Nov  7 22:50:20 2018
New Revision: 265899

URL: https://gcc.gnu.org/viewcvs?rev=265899=gcc=rev
Log:
[PR/87936] --disable-checking bootstrap break

https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00502.html
PR 87926
* Makefile.in (bitmap.o-warn): Add -Wno-error to unbreak
--disable-checking bootstrap.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in

Re: [PATCH] Verify that last argument of __builtin_expect_with_probability is a real cst (PR c/87811).

[Jeff Law]

On 11/7/18 2:36 AM, Martin Liška wrote:
> On 11/5/18 7:00 PM, Martin Sebor wrote:
>> On 11/01/2018 07:45 AM, Martin Liška wrote:
>>> On 11/1/18 1:15 PM, Jakub Jelinek wrote:
 On Thu, Nov 01, 2018 at 01:09:16PM +0100, Martin Liška wrote:
> -range 0.0 to 1.0, inclusive.
> +range 0.0 to 1.0, inclusive.  The @var{probability} argument must be
> +a compiler time constant.
 When you say must, I think error_at should be used rather than warning_at.
 If others disagree I'm open for leaving it as is.
>>> Error is fine for me as well.
>>>
> @@ -2474,6 +2481,11 @@ expr_expected_value_1 (tree type, tree op0, enum 
> tree_code code,
>    *predictor = PRED_BUILTIN_EXPECT_WITH_PROBABILITY;
>    *probability = probi;
>  }
> +  else
> +  warning_at (gimple_location (def), 0,
> +  "probability argument %qE must be a in the "
> +  "range 0.0 to 1.0", prob);
 Wrong indentation.

 And, no diagnostics for -O0 (which should also be covered by a testcase).
>>> Test for that added.
>>>
> +/* { dg-options "-O2 -fdump-tree-profile_estimate -frounding-math" } */
 Why the -frounding-math options?
>>> I remember I had some issue with:
>>>   tree r = fold_build2_initializer_loc (UNKNOWN_LOCATION,
>>>     MULT_EXPR, t, prob, base);
>>>
>>> on targets with a non-IEEE floating point arithmetics (s390?).
>>>
>>>  I think test
 coverage should handle both that and when that option is not used
 if that option makes any difference.
>>> It will eventually pop up if we install new tests w/o rounding math.
>>>
 Jakub

>>>
>>> Martin
>>>
>> I noticed a few minor issues in the hunks below:
>>
>> --- a/gcc/doc/extend.texi
>> +++ b/gcc/doc/extend.texi
>> @@ -12046,7 +12046,8 @@
>>  when testing pointer or floating-point values.
>>
>>  This function has the same semantics as @code{__builtin_expect},
>>  but the caller provides the expected probability that @var{exp} == @var{c}.
>>  The last argument, @var{probability}, is a floating-point value in the
>> -range 0.0 to 1.0, inclusive.
>> +range 0.0 to 1.0, inclusive.  The @var{probability} argument must be
>> +a compiler time constant.
>>
>> The term is "compile-time constant" but please see below.
>>
>> --- a/gcc/predict.c
>> +++ b/gcc/predict.c
>> @@ -2467,6 +2467,13 @@
>>  expr_expected_value_1 (tree type, tree op0, enum tree_code code,
>>    base = build_real_from_int_cst (t, base);
>>    tree r = fold_build2_initializer_loc (UNKNOWN_LOCATION,
>>  MULT_EXPR, t, prob, base);
>> +  if (TREE_CODE (r) != REAL_CST)
>> +    {
>> +  error_at (gimple_location (def),
>> +    "probability argument %qE must be a compile "
>> +    "time constant", prob);
>> +  return NULL;
>>     }
>>
>> According to GCC coding conventions, when used as an adjective
>> the term "compile-time" should be hyphenated.  But the term used
>> in other diagnostics is either "constant integer" or "constant
>> integer expressions" so I would suggest to use it instead, here
>> and in the manual.
>>
>> @@ -2474,6 +2481,11 @@
>>  expr_expected_value_1 (tree type, tree op0, enum tree_code code,
>>    *predictor = PRED_BUILTIN_EXPECT_WITH_PROBABILITY;
>>    *probability = probi;
>>  }
>> +  else
>> +    error_at (gimple_location (def),
>> +  "probability argument %qE must be a in the "
>> +  "range 0.0 to 1.0", prob);
>> +
>>
>> There's a stray 'a' in the text of the error.
>>
>> But it's not really meaningful to say
>>
>>   3.14 must be in the range 0.0 to 1.0
>>
>> because that simply cannot happen.  We could say "argument 2 must
>> be in the range" but I would instead suggest to rephrase the error
>> along the same lines as other similar messages GCC already issues:
>>
>>   "probability %qE is outside the range [0.0, 1.0]"
>>
>> Martin
> Hi Martin.
> 
> Thanks for help with the wording. Please take a look at attached patch
> candidate.
> 
> Martin
> 
> 
> 0001-Change-wording-of-__builtin_expect_with_probability-.patch
> 
> From 94b61505be171b6b16f7a85c62c722d3c9e13c2f Mon Sep 17 00:00:00 2001
> From: marxin 
> Date: Wed, 7 Nov 2018 10:27:00 +0100
> Subject: [PATCH] Change wording of __builtin_expect_with_probability errors.
> 
> gcc/ChangeLog:
> 
> 2018-11-07  Martin Liska  
> 
>   * doc/extend.texi: Reword.
>   * predict.c (expr_expected_value_1): Likewise.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-11-07  Martin Liska  
> 
>   * gcc.dg/pr87811.c: Update scanned pattern.
>   * gcc.dg/pr87811-2.c: Likewise.
OK.
jeff

Re: [PR87793] reject non-toplevel unspecs in debug loc exprs on x86

[Jeff Law]

On 11/7/18 12:42 AM, Alexandre Oliva wrote:
> Before revision 254025, we'd reject UNSPECs in debug loc exprs.
> TARGET_CONST_NOT_OK_FOR_DEBUG_P still rejects that by default, on all
> ports that override it, except for x86, that accepts @gotoff unspecs.
> We can indeed accept them in top-level expressions, but not as
> subexpressions: the assembler rejects the difference between two
> @gotoff symbols, for example.
> 
> We could simplify such a difference and drop the @gotoffs, provided
> that the symbols are in the same section; we could also accept
> @gotoffs plus literal constants.  However, accepting those but
> rejecting such combinations as subexpressions would be ugly, and most
> likely not worth the trouble: sym@gotoff+litconst hardly makes sense
> as a standalone expression, and the difference between @gotoffs should
> be avoided to begin with, as follows.
> 
> Ideally, the debug loc exprs would use the symbolic data in
> REG_EQUIV/REG_EQUAL notes, or delegitimized addresses, instead of
> simplifying the difference between two legitimized addresses so that
> the occurrences of the GOT register cancel each other.  That would
> require some more elaborate surgery in var-tracking and cselib than
> would be appropriate at this stage.
> 
> Regstrapped on x86_64- and i686-linux-gnu.  Ok to install?
> 
> 
> for  gcc/ChangeLog
> 
>   PR target/87793
>   * config/i386/i386.c (ix86_const_not_ok_for_debug_p): Reject
>   non-toplevel UNSPEC.
> 
> for  gcc/testsuite/ChangeLog
> 
>   PR target/87793
>   * gcc.dg/pr87793.c: New.
OK.
jeff

Re: [PATCH][RFC] Sanitize equals and hash functions in hash-tables.

[Jakub Jelinek]

On Wed, Nov 07, 2018 at 03:23:55PM -0700, Jeff Law wrote:
> > @@ -882,8 +883,12 @@ hash_table
> >if (insert == INSERT && m_size * 3 <= m_n_elements * 4)
> >  expand ();
> >  
> > -  m_searches++;
> > +#if ENABLE_EXTRA_CHECKING
> > +if (insert == INSERT)
> > +  verify (comparable, hash);
> > +#endif

Plus formatting, the above is indented too much.

Jakub

[PR/87936] --disable-checking bootstrap break

[Nathan Sidwell]

I'm committing this to unbreak a --disable-checking bootstrap build 
failure.  As documented in the PR we think there's an out of bound array 
access.


nathan
--
Nathan Sidwell
2018-11-07  Nathan Sidwell  

	PR 87926
	* Makefile.in (bitmap.o-warn): Add -Wno-error to unbreak
	--disable-checking bootstrap.

Index: Makefile.in
===
--- Makefile.in	(revision 265883)
+++ Makefile.in	(working copy)
@@ -221,6 +221,7 @@ libgcov-merge-tool.o-warn = -Wno-error
 gimple-match.o-warn = -Wno-unused
 generic-match.o-warn = -Wno-unused
 dfp.o-warn = -Wno-strict-aliasing
+bitmap.o-warn = -Wno-error # PR 87926
 
 # All warnings have to be shut off in stage1 if the compiler used then
 # isn't gcc; configure determines that.  WARN_CFLAGS will be either

Re: PING [PATCH] use MAX_OFILE_ALIGNMENT to validate attribute aligned (PR 87795)

[Jeff Law]

On 11/6/18 5:06 PM, Martin Sebor wrote:
> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg02081.html
I thought I'd already ACK's this one...


OK.

Jeff

Re: Small typo in iconv.m4

[Jeff Law]

On 11/6/18 9:37 AM, Hafiz Abid Qadeer wrote:
> Hi All,
> I was investigating a character set related problem with windows hosted
> GDB and I tracked it down to a typo in iconv.m4. This typo caused
> libiconv detection to fail and related support was not built into gdb.
> 
> The problem is with the following line.
> CPPFLAGS="$LIBS $INCICONV"
> which should have been
> CPPFLAGS="$CPPFLAGS $INCICONV"
> 
> OK to commit the attached patch?
> 
> 2018-11-06  Hafiz Abid Qadeer  
> 
>   * config/iconv.m4 (AM_ICONV_LINK): Don't overwrite CPPFLAGS.
>   Append $INCICONV to it.
>   * gcc/configure: Regenerate.
>   * libcpp/configure: Likewise.
>   * libstdc++-v3/configure: Likewise.
>   * intl/configure: Likewise.
> 
> Thanks,
> 
THanks.  I wasn't sure if you had commit privs, so I went ahead and
installed the patch.

Jeff

[Bug tree-optimization/87926] New: bad array-index warning breaks --disable-checking bootstrap

[nathan at gcc dot gnu.org]

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

Bug ID: 87926
   Summary: bad array-index warning breaks --disable-checking
bootstrap
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44967
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44967=edit
cc1plus bug.ii -O2 -W -Wall -quiet

x86_64-linux --disable-checking bootstrap fails with:
../../../src/gcc/bitmap.c: In function ‘unsigned int
bitmap_last_set_bit(const_bitmap)’:
../../../src/gcc/bitmap.c:1191:26: error: array subscript -1 is below array
bounds of ‘const BITMAP_WORD [2]’ {aka ‘const long unsigned int [2]’}
[-Werror=array-bounds]
  1191 |   word = elt->bits[ix];
   |  ^

Attached is a reduced testcase

Adding:
bitmap.o-warn = -Wno-error
to gcc/Makefile.in works around the problem.

Re: [PATCH] Add sinh(tanh(x)) and cosh(tanh(x)) rules

[Wilco Dijkstra]

Hi Jeff,

> So if we're going from 0->2 ULPs in some cases, do we want to guard it
> with one of the various options, if so, which?  Giuliano's follow-up
> will still have the potential for 2ULPs.

The ULP difference is not important since the individual math functions 
already have ULP of 3 or higher. Changing ULP error for some or all inputs
(like we did with the rewritten math functions) is not considered an issue as
long as worst-case ULP error doesn't increase.

The question is more like whether errno and trapping/exception behaviour
is identical - I guess it is not so I would expect this to be fastmath only.
Which particular flag one uses is a detail given there isn't a clear definition
for most of them.

Wilco

Re: [PATCH AutoFDO/4]Fix profile count computation/propagation.

[Jeff Law]

On 10/31/18 12:34 AM, bin.cheng wrote:
> Hi,
> This patch fixes AutoFDO breakage on trunk.  The main reason for breakage is 
> AutoFDO
> relies on standalone edge count computing and propagating profile 
> count/probability info
> on CFG, but in new infra, edge count is actually computed from probability, 
> which leads
> to chicken-egg problem and corrupted profile count.  This patch fixes the 
> issue by using
> explicit edge count.
> 
> There is another issue not touched yet that, in quite common case, profiled 
> samples are
> not enough and profile info computed for lots of blocks is ZERO.  In the 
> future, we may
> add some heuristics checking quality of sampled counts and reverting to 
> guessed profile
> count if necessary.  I think change made in this patch is also needed for 
> that.
> 
> Package mysql server is used in test of this patch set.  It can't be compiled 
> with autofdo
> on trunk, even with compilation issues worked-around, there isn't performance 
> improvement.
> I local experiments, with this patch set it's improved by 12.3%, 4.3% 
> irrespectively for
> read-only/write-heavy benchmarks.  Unfortunately,  this patch set was written 
> against
> GCC 8 branch a while ago, improvement gets worse on trunk and I haven't 
> investigated
> the reason yet.  I guess there are still other issues which need to be fixed 
> in the future.
> 
> Bootstrap and test on x86_64 in patch set.  Is it OK?
> 
> Thanks,
> bin
> 2018-10-31  Bin Cheng  
> 
>   * auto-profile.c (AFDO_EINFO): New macro.
>   (struct edge_info): New structure.
>   (is_edge_annotated, set_edge_annotated): Delete.
>   (afdo_propagate_edge, afdo_propagate_circuit, afdo_propagate): Remove
>   parameter.  Adjust edge count computation and annotation using struct
>   edge_info.
>   (afdo_calculate_branch_prob): Ditto.
>   (afdo_annotate_cfg): Simplify code setting basic block profile count.
> 
> 
> 0004-Fix-AutoFDO-breakage-after-profile-count-rewriting.patch
> 
> From 6506c12d1b633b6d1bfae839b3633a4f99b3a481 Mon Sep 17 00:00:00 2001
> From: chengbin 
> Date: Mon, 20 Aug 2018 15:25:02 +0800
> Subject: [PATCH 4/4] Fix AutoFDO breakage after profile count rewriting.
> 
> ---
>  gcc/auto-profile.c | 190 
> ++---
>  1 file changed, 95 insertions(+), 95 deletions(-)
> 
> diff --git a/gcc/auto-profile.c b/gcc/auto-profile.c
> index cde4f41c1d9..ff3ea23d830 100644
> --- a/gcc/auto-profile.c
> +++ b/gcc/auto-profile.c
> @@ -101,6 +101,17 @@ along with GCC; see the file COPYING3.  If not see
>  namespace autofdo
>  {
>  
> +/* Intermediate edge info used when propagating AutoFDO profile information.
> +   We can't edge->count() directly since it's computed from edge's 
> probability
> +   while probability is yet not decided during propagation.  */
> +#define AFDO_EINFO(e) ((struct edge_info *) e->aux)
> +struct edge_info
> +{
> +  edge_info () : count (profile_count::zero ().afdo ()), annotated_p (false) 
> {}
> +  profile_count count;
> +  bool annotated_p;
> +};
edge_info isn't POD, so make it a class rather than a struct.

OK with that change assuming it does not have a hard dependency on prior
patches in this series.

jeff

[committed] Fix type of "num" argument to memcpy in gcc.c-torture/compile/pr65595.c

[Jozef Lawrynowicz]

The test uses "unsigned long" as the "num" argument to memcpy, but it should be
size_t, and these types are not equivalent on all targets.

Committed to trunk.


>From 3ebbb8102bd9b984c6f1a1eaf0bca45fe4fd23e1 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Tue, 6 Nov 2018 12:49:00 +
Subject: [PATCH 04/12] [TESTSUITE] size_type memcpy

2018-11-07  Jozef Lawrynowicz  

	gcc/testsuite/ChangeLog:
  
	* gcc.c-torture/compile/pr65595.c: Change type of "num" argument to
	memcpy from "unsigned long" to __SIZE_TYPE__.
---
 gcc/testsuite/gcc.c-torture/compile/pr65595.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.c-torture/compile/pr65595.c b/gcc/testsuite/gcc.c-torture/compile/pr65595.c
index 0ab7161..b6a0aa4 100644
--- a/gcc/testsuite/gcc.c-torture/compile/pr65595.c
+++ b/gcc/testsuite/gcc.c-torture/compile/pr65595.c
@@ -1,4 +1,4 @@
-extern void *memcpy(void *, const void *, unsigned long);
+extern void *memcpy(void *, const void *, __SIZE_TYPE__);
 struct in6_addr {
   struct {
 int u6_addr32[4];
-- 
2.7.4

Re: PR fortran/87919 patch for -fno-dec-structure

[Jakub Jelinek]

On Wed, Nov 07, 2018 at 05:05:13PM -0500, Fritz Reese wrote:

--- a/gcc/fortran/options.c
+++ b/gcc/fortran/options.c
@@ -32,6 +32,20 @@ along with GCC; see the file COPYING3.  If not see
 
 gfc_option_t gfc_option;
 
+#define _expand(m) m

I think it would be better to avoid names like _expand, too generic
name and starts with underscore, name it e.g. SET_BITFLAG_1 or something
similar.  And it isn't mentioned in the ChangeLog.

@@ -62,14 +75,30 @@ set_dec_flags (int value)
 }

What about the
  /* Allow legacy code without warnings.  */
  gfc_option.allow_std |= GFC_STD_F95_OBS | GFC_STD_F95_DEL
| GFC_STD_GNU | GFC_STD_LEGACY;
  gfc_option.warn_std &= ~(GFC_STD_LEGACY | GFC_STD_F95_DEL);
that is done for value, shouldn't set_dec_flags remove those
flags again?  Maybe not the allow_std ones, because those are set already by
default, perhaps just the warn_std flags?

   /* Set other DEC compatibility extensions.  */
-  flag_dollar_ok |= value;
-  flag_cray_pointer |= value;
-  flag_dec_structure |= value;
-  flag_dec_intrinsic_ints |= value;
-  flag_dec_static |= value;
-  flag_dec_math |= value;
+  SET_BITFLAG (flag_dollar_ok, value, value);
+  SET_BITFLAG (flag_cray_pointer, value, value);
+  SET_BITFLAG (flag_dec_structure, value, value);
+  SET_BITFLAG (flag_dec_intrinsic_ints, value, value);
+  SET_BITFLAG (flag_dec_static, value, value);
+  SET_BITFLAG (flag_dec_math, value, value);
 }
 
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/array_temporaries_5.f90
@@ -0,0 +1,20 @@
+! { dg-do run }
+! { dg-options "-fcheck-array-temporaries -fno-check-array-temporaries" }
+!
+! PR fortran/87919
+!
+! Ensure -fno-check-array-temporaries disables array temporary checking.
+! Copied from array_temporaries_2.f90.

For tests where you expect no errors and that are just copies of other
testcases, perhaps
include 'array_temporaries_2.f90'
or similar instead?

Jakub

[Bug rtl-optimization/87925] Missed optimization: Distinct-value if-then-else chains treated differently than switch statements

[eyalroz at technion dot ac.il]

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

Eyal Rozenberg  changed:

   What|Removed |Added

Version|unknown |9.0

--- Comment #1 from Eyal Rozenberg  ---
See also: 
https://stackoverflow.com/questions/53198276/do-compilers-optimize-switches-differently-than-long-if-then-else-chains

Re: [PATCH][RFC] Sanitize equals and hash functions in hash-tables.

[Jeff Law]

On 10/30/18 6:28 AM, Martin Liška wrote:
> On 10/30/18 11:03 AM, Jakub Jelinek wrote:
>> On Mon, Oct 29, 2018 at 04:14:21PM +0100, Martin Liška wrote:
>>> +hashtab_chk_error ()
>>> +{
>>> +  fprintf (stderr, "hash table checking failed: "
>>> +  "equal operator returns true for a pair "
>>> +  "of values with a different hash value");
>> BTW, either use internal_error here, or at least if using fprintf
>> terminate with \n, in your recent mail I saw:
>> ...different hash valueduring RTL pass: vartrack
>> ^^
> Sure, fixed in attached patch.
> 
> Martin
> 
>>> +  gcc_unreachable ();
>>> +}
>>  Jakub
>>
> 
> 0001-Sanitize-equals-and-hash-functions-in-hash-tables.patch
> 
> From 0d9c979c845580a98767b83c099053d36eb49bb9 Mon Sep 17 00:00:00 2001
> From: marxin 
> Date: Mon, 29 Oct 2018 09:38:21 +0100
> Subject: [PATCH] Sanitize equals and hash functions in hash-tables.
> 
> ---
>  gcc/hash-table.h | 40 +++-
>  1 file changed, 39 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/hash-table.h b/gcc/hash-table.h
> index bd83345c7b8..694eedfc4be 100644
> --- a/gcc/hash-table.h
> +++ b/gcc/hash-table.h
> @@ -503,6 +503,7 @@ private:
>  
>value_type *alloc_entries (size_t n CXX_MEM_STAT_INFO) const;
>value_type *find_empty_slot_for_expand (hashval_t);
> +  void verify (const compare_type , hashval_t hash);
>bool too_empty_p (unsigned int);
>void expand ();
>static bool is_deleted (value_type )
> @@ -882,8 +883,12 @@ hash_table
>if (insert == INSERT && m_size * 3 <= m_n_elements * 4)
>  expand ();
>  
> -  m_searches++;
> +#if ENABLE_EXTRA_CHECKING
> +if (insert == INSERT)
> +  verify (comparable, hash);
> +#endif
>  
> +  m_searches++;
>value_type *first_deleted_slot = NULL;
>hashval_t index = hash_table_mod1 (hash, m_size_prime_index);
>hashval_t hash2 = hash_table_mod2 (hash, m_size_prime_index);
> @@ -930,6 +935,39 @@ hash_table
>return _entries[index];
>  }
>  
> +#if ENABLE_EXTRA_CHECKING
> +
> +/* Report a hash table checking error.  */
> +
> +ATTRIBUTE_NORETURN ATTRIBUTE_COLD
> +static void
> +hashtab_chk_error ()
> +{
> +  fprintf (stderr, "hash table checking failed: "
> +"equal operator returns true for a pair "
> +"of values with a different hash value\n");
> +  gcc_unreachable ();
> +}
I think an internal_error here is probably still better than a simple
fprintf, even if the fprintf is terminated with a \n :-)

The question then becomes can we bootstrap with this stuff enabled and
if not, are we likely to soon?  It'd be a shame to put it into
EXTRA_CHECKING, but then not be able to really use EXTRA_CHECKING
because we've got too many bugs to fix.

> +
> +/* Verify that all existing elements in th hash table which are
s/th/the/


Jeff

[Bug rtl-optimization/87925] New: Missed optimization: Single-value if-then-else chains treated differently than switch'es

[eyalroz at technion dot ac.il]

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

Bug ID: 87925
   Summary: Missed optimization: Single-value if-then-else chains
treated differently than switch'es
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eyalroz at technion dot ac.il
  Target Milestone: ---

Have a look at this GodBolt example: https://gcc.godbolt.org/z/zR03rA

On one hand, we have:

void foo(int i) {
switch (i) {
case 1: boo<1>(); break;
case 2: boo<2>(); break;
case 3: boo<3>(); break;
case 4: boo<4>(); break;
// etc. etc.
}
}

on the other hand we have the same, but using an if-then-else chain:

void bar(int i) {
if  (i == 1) boo<1>();
else if (i == 2) boo<2>();
else if (i == 3) boo<3>();
else if (i == 4) boo<4>();
// etc. etc.
}

The switch statement gets a jump table; the if-then-else chain - does not. At
the link, there are 20 cases; g++ starts using a jump table with 4 switch
values.

This is not just a matter of programmers needing to remember to prefer switch
statements (which it's better not to require of them), but rather that
if-then-else chains are sometimes generated by expansion of templated code,
e.g. this example for checking for membership in a set of values (= all values
of an enum):

https://stackoverflow.com/a/53191264/1593077

while switch() statements of variable do not get generated AFAICT. It would
thus be quite useful if such generated code would not result in
highly-inefficient long chains of comparisons.

Re: [PATCH] Add sinh(tanh(x)) and cosh(tanh(x)) rules

[Jeff Law]

On 10/23/18 3:17 AM, Richard Biener wrote:
> On Mon, Oct 22, 2018 at 10:09 PM Jeff Law  wrote:
>>
>> On 10/20/18 9:47 AM, Giuliano Augusto Faulin Belinassi wrote:
>>> So I did some further investigation comparing the ULP error.
>>>
>>> With the formula that Wilco Dijkstra provided, there are cases where
>>> the substitution is super precise.
>>> With floats:
>>> with input  :  = 9.9940395355224609375000e-01
>>> sinh: before:  = 2.89631005859375e+03
>>> sinh: after :  = 2.896309326171875000e+03
>>> sinh: mpfr  :  = 2.89630924626497842670468162463283783344599446025119e+03
>>> ulp err befr:  = 3
>>> ulp err aftr:  = 0
>>>
>>> With doubles:
>>> with input  :  = 9.99888977697537484345957636833190917969e-01
>>> sinh: before:  = 6.710886400029802322387695312500e+07
>>> sinh: after :  = 6.71088632549419403076171875e+07
>>> sinh: mpfr  :  = 6.710886344120645523071287770030292885894208e+07
>>> ulp err befr:  = 3
>>> ulp err aftr:  = 0
>>>
>>> *However*, there are cases where some error shows up. The biggest ULP
>>> error that I could find was 2.
>>>
>>> With floats:
>>> with input  :  = 9.99968349933624267578125000e-01
>>> sinh: before:  = 1.2568613433837890625000e+02
>>> sinh: after :  = 1.2568614959716796875000e+02
>>> sinh: mpfr  :  = 1.25686137592274042266452526368087062890399889097864e+02
>>> ulp err befr:  = 0
>>> ulp err aftr:  = 2
>>>
>>> With doubles:
>>> with input  :  = 9.999463651256803586875321343541145324707031e-01
>>> sinh: before:  = 9.65520209507428342476487159729003906250e+05
>>> sinh: after :  = 9.6552020950742810964584350585937500e+05
>>> sinh: mpfr  :  = 9.65520209507428288553227922831618987450806468855883e+05
>>> ulp err befr:  = 0
>>> ulp err aftr:  = 2
>>>
>>> And with FMA we have the same results showed above. (super precise
>>> cases, and maximum ULP error equal 2).
>>>
>>> So maybe update the patch with the following rules?
>>>* If FMA is available, then compute 1 - x*x with it.
>>>* If FMA is not available, then do the dijkstra substitution when |x| > 
>>> 0.5.
>> So I think the runtime math libraries shoot for .5 ULP (yes, they don't
>> always make it, but that's their goal).  We should probably have the
>> same goal.  Going from 0 to 2 ULPs would be considered bad.
> 
> But we do that everywhere (with -funsafe-math-optimizations or
> -fassociative-math).
So if we're going from 0->2 ULPs in some cases, do we want to guard it
with one of the various options, if so, which?  Giuliano's follow-up
will still have the potential for 2ULPs.

jeff

Re: Extracting live registers

[Segher Boessenkool]

On Wed, Nov 07, 2018 at 09:49:02PM +0100, Paulo Matos wrote:
> On 07/11/2018 20:27, Segher Boessenkool wrote:
> > Sure, it shows the register information at the edges of basic blocks
> > only.  This is what you asked for btw ;-)
> 
> True, but I need a way to map that information to the assembly
> instructions in the basic block. :)

With -dp you have the insn uids in the .s file, so you can match them up
with the RTL dumps.  You can use -dP as well if you like that better.

> I think it's not impossible with all
> that gcc provides, but there's certainly a fair amount of parsing of
> these files, which is not ideal given their format might change under my
> feet.

Yes, the dump files are not meant for this.  They aren't completely
parsable even.


Segher

Re: [PATCH] handle attribute positional arguments consistently (PR 87541, 87542)

[Jeff Law]

On 10/24/18 8:02 PM, Martin Sebor wrote:

>> No camel case.  Make the enum type lower case and its values upper case.
> 
> Done.
> 
> As an aside, I almost thought that after nearly fours years
> I've adjusted to most reviewers' preferences but I'm clearly
> not quite there yet.  As usual, this is not mentioned in
> the coding conventions (except for C++ template parameters
> where it is the preferred spelling), and there are also
> examples of different styles in GCC, including the one
> I chose. For instance, in c-format.c the format_type enum
> uses all lowercase enumerators.  There are also quite a few
> (over a hundred in fact) examples of CamelCase enums in
> various front-ends, back-ends, and other parts of GCC.
It happens.  Avoiding camel case is more important than the upper vs
lower case on the enum constants (and I thought avoiding camel case was
mentioned somewhere, but I could be wrong).  It it wasn't for the  camel
case I probably wouldn't have said anything about the enum constants.

Jeff


> 
>>> @@ -326,17 +331,18 @@ static bool
>>>  }
>>>  }
>>>
>>> -  if (!get_constant (format_num_expr, >format_num, validated_p))
>>> -    {
>>> -  error ("format string has invalid operand number");
>>> -  return false;
>>> -    }
>>> +  if (tree val = get_constant (fntype, atname, *format_num_expr,
>>> +   2, >format_num, 0, validated_p))
>>> +    *format_num_expr = val;
>>> +  else
>>> +    return false;
>> Is it really a good idea to be modifying something inside of ARGS like
>> this?  At the very least the function comments neeed updating.
> 
> That's what the code does.  My patch doesn't change it, it just
> adds a new variable.  I added a comment to mention it nonetheless.
Ah.  Must have missed that in the original.  In that case ignore my
comment.  Similarly for the other instance.
.
> 
>>
>>> +{
>>> +  /* Treat zero the same as an out-of-bounds argument number.  */
>>> +  if (!argno)
>>> +    return void_type_node;
>>> +
>>> +  unsigned i = 1;
>>> +
>>> +  for (tree t = TYPE_ARG_TYPES (type); ; t = TREE_CHAIN (t), ++i)
>> There's already iterators to walk over TYPE_ARG_TYPES.  See
>> FOREACH_FUNCTION_ARGS
> 
> As I explained above, I just copied another function just above
> the one I added.
> 
> Besides the one in the function I copied there are six other
> loops in this file and just one use of FOREACH_FUNCTION_ARGS.
> I also think the macro is harder to understand and poor style.
> It requires declaring an extra variable outside the scope of
> the loop even if it isn't used.  So I kept the loop as is.
We're generally trying to use iterators more than open coding loops all
the time.  The existence of code that doesn't use iterators (when
iterators exist) isn't a justification for adding new open coded loops.

Please use the iterator.  OK with that change.

jeff

[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT

[jozefl at gcc dot gnu.org]

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

--- Comment #10 from jozefl at gcc dot gnu.org ---
Author: jozefl
Date: Wed Nov  7 22:06:26 2018
New Revision: 265894

URL: https://gcc.gnu.org/viewcvs?rev=265894=gcc=rev
Log:
2018-11-07  Jozef Lawrynowicz  

PR c/87691

gcc/ChangeLog:
* stor-layout.c (compute_record_mode): Set TYPE_MODE of UNION_TYPE
to the mode of the widest field iff the widest field has mode class
MODE_INT, or MODE_PARTIAL_INT and the union would be passed by
reference.

gcc/testsuite/ChangeLog:
* gcc.target/msp430/pr87691.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/msp430/pr87691.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/stor-layout.c
trunk/gcc/testsuite/ChangeLog

Re: PR fortran/87919 patch for -fno-dec-structure

[Fritz Reese]

On 11/7/18, Jakub Jelinek  wrote:
> On Wed, Nov 07, 2018 at 03:07:04PM +, Mark Eggleston wrote:
>
>>  PR fortran/87919
>>  * options.c (gfc_handle_option): Removed case OPT_fdec_structure
>>  as it breaks the handling of -fno-dec-structure.
>
> No entries for the tests, i.e.
>   * gfortran.dg/pr87919-dec-structure-1.f: New test.
>   * gfortran.dg/pr87919-dec-structure-2.f: New test.
>   * gfortran.dg/pr87919-dec-structure-3.f: New test.
>   * gfortran.dg/pr87919-dec-structure-4.f: New test.
>
>> diff --git a/gcc/fortran/options.c b/gcc/fortran/options.c
>> index 73f5389361d9..3b7c2d40fe8a 100644
>> --- a/gcc/fortran/options.c
>> +++ b/gcc/fortran/options.c
>> @@ -761,10 +761,6 @@ gfc_handle_option (size_t scode, const char *arg,
>> HOST_WIDE_INT value,
>>/* Enable all DEC extensions.  */
>>set_dec_flags (1);
>>break;
>> -
>> -case OPT_fdec_structure:
>> -  flag_dec_structure = 1;
>> -  break;
>>  }
>>
>>Fortran_handle_option_auto (_options, _options_set,
>
> LGTM, but I'll defer the final review to Fortran maintainers.

Thanks for the patch Mark, I concur with Jakub that it is correct for
what it does. However, I have a few comments in addition to the fixes
recommended by Jakub regarding the test cases.

First, I would prefer to name these test cases as "dec_structure_*.f"
to align with the other (23) -fdec-structure test cases. Second, the
third case (*dec-structure-3.f) is unnecessary because it is identical
in function to dec_structure_1.f90. I concur with the remaining test
cases, as well as Jakub's suggestion to cover "-fdec-structure
-fno-dec-structure" with an additional test. I would name the final
four (= 4 - 1 + 1) tests as "dec_structure_[24-27].f".


I have taken the liberty of extending this patch to cover the
remainder of PR 87919. That is, to fix -fno-* for -fno-dec,
-fno-check-array-temporaries and -fno-init-local-zero. In the extended
patch, the 'value' set for the aforementioned options is no longer
ignored, so that value=1 truly means set and value=0 truly means
"unset". Previously, the aforementioned flags effectively ignored the
value=0 condition. Similarly to the tests Mark provided with
-fdec-structure, I've provided new tests for the various facets of
-fno-dec, -fno-check-array-temporaries, and -fno-init-local-zero.

Below is the changelog. Bootstraps and regtests fine for me on
x86_64-redhat-linux. If it looks OK I'll commit to trunk (and probably
backport to 8-branch and 7-branch since the affected code appears to
be the same for those branches).


>From 2d9e39bbf4a179ae433f33f4e7039b85078ba72f Mon Sep 17 00:00:00 2001
From: Fritz Reese 
Date: Wed, 7 Nov 2018 15:13:50 -0500
Subject: [PATCH] PR fortran/87919

Fix handling -fno-* prefix for init-local-zero, check-array-temporaries and dec.

gcc/fortran/
* options.c (SET_FLAG, SET_BITFLAG): New macros.
(set_dec_flags): Unset DEC flags with value==0.
(set_init_local_zero): New helper for -finit-local-zero flag group.
(gfc_init_options): Fix disabling of init flags, array temporaries
check, and dec flags when value is zero (from -fno-*).

gcc/testsuiste/
* gfortran.dg/array_temporaries_5.f90: New test.
* gfortran.dg/dec_bitwise_ops_3.f90: Ditto.
* gfortran.dg/dec_d_lines_3.f: Ditto.
* gfortran.dg/dec_exp_4.f90: Ditto.
* gfortran.dg/dec_exp_5.f90: Ditto.
* gfortran.dg/dec_io_7.f90: Ditto.
* gfortran.dg/dec_structure_24.f: Ditto.
* gfortran.dg/dec_structure_25.f: Ditto.
* gfortran.dg/dec_structure_26.f: Ditto.
* gfortran.dg/dec_structure_27.f: Ditto.
* gfortran.dg/dec_type_print_3.f90: Ditto.
* gfortran.dg/init_flag_20.f90: Ditto.
---
 gcc/fortran/options.c | 70 +++
 gcc/testsuite/gfortran.dg/array_temporaries_5.f90 | 20 +++
 gcc/testsuite/gfortran.dg/dec_bitwise_ops_3.f90   | 19 ++
 gcc/testsuite/gfortran.dg/dec_d_lines_3.f | 10 
 gcc/testsuite/gfortran.dg/dec_exp_4.f90   | 13 +
 gcc/testsuite/gfortran.dg/dec_exp_5.f90   | 15 +
 gcc/testsuite/gfortran.dg/dec_io_7.f90| 22 +++
 gcc/testsuite/gfortran.dg/dec_structure_24.f  | 21 +++
 gcc/testsuite/gfortran.dg/dec_structure_25.f  | 22 +++
 gcc/testsuite/gfortran.dg/dec_structure_26.f  | 22 +++
 gcc/testsuite/gfortran.dg/dec_structure_27.f  | 20 +++
 gcc/testsuite/gfortran.dg/dec_type_print_3.f90| 29 ++
 gcc/testsuite/gfortran.dg/init_flag_20.f90| 62 
 13 files changed, 320 insertions(+), 25 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/array_temporaries_5.f90
 create mode 100644 gcc/testsuite/gfortran.dg/dec_bitwise_ops_3.f90
 create mode 100644 gcc/testsuite/gfortran.dg/dec_d_lines_3.f
 create mode 100644 gcc/testsuite/gfortran.dg/dec_exp_4.f90
 create mode 100644 

Re: [PATCH] detect attribute mismatches in alias declarations (PR 81824)

[Jeff Law]

On 10/23/18 7:50 PM, Martin Sebor wrote:
> On 10/23/2018 03:53 PM, Joseph Myers wrote:
>> On Mon, 22 Oct 2018, Martin Sebor wrote:
>>
>>> between aliases and ifunc resolvers.  With -Wattribute-alias=1
>>> that reduced the number of unique instances of the warnings for
>>> a Glibc build to just 27.  Of those, all but one of
>>> the -Wattributes instances are of the form:
>>>
>>>   warning: ‘leaf’ attribute has no effect on unit local functions
>>
>> What do the macro expansions look like there?  All the places where you're
>>
>> adding "copy" attributes are for extern declarations, not static ones,
>> whereas your list of warnings seems to indicate this is appearing for
>> ifunc resolvers (which are static, but should not be copying attributes
>> from anywhere).
> 
> These must have been caused by the bug in the patch (below).
> They have cleared up with it fixed.  I'm down to just 18
> instances of a -Wmissing-attributes warning, all for string
> functions.  The cause of those is described below.
> 
>>
>>> All the -Wmissing-attributes instances are due to a missing
>>> nonnull attribute on the __EI__ kinds of functions, like:
>>>
>>>   warning: ‘__EI_vfprintf’ specifies less restrictive attribute than its
>>> target ‘vfprintf’: ‘nonnull’
>>
>> That looks like a bug in the GCC patch to me; you appear to be adding copy
>>
>> attributes in the correct place.  Note that __EI_* gets declared twice
>> (first with __asm__, second with an alias attribute), so anything related
>> to handling of such duplicate declarations might be a cause for such a
>> bug (and an indication of what you need to add a test for when fixing such
>>
>> a bug).
> 
> There was a bug in the patch, but there is also an issue in Glibc
> that made it tricky to see the problem.
> 
> The tests I had in place were too simple to catch the GCC bug:
> the problem there was that when the decl didn't have an attribute
> the type of the "template" did the check would fail without also
> considering the decl's type.  Tricky stuff!  I've added tests to
> exercise this.
> 
> The Glibc issue has to do with the use of __hidden_ver1 macro
> to declare string functions.  sysdeps/x86_64/multiarch/strcmp.c
> for instance has:
> 
>   __hidden_ver1 (strcmp, __GI_strcmp, __redirect_strcmp)
> __attribute__ ((visibility ("hidden")));
> 
> and __redirect_strcmp is missing the nonnull attribute because
> it's #undefined in include/sys/cdefs.h.  An example of one of
> these warnings is attached.
> 
> Using strcmp instead of __redirect_strcmp would solve this but
> __redirect_strcmp should have all the same attributes as strcmp.
> But nonnull is removed from the declaration because the __nonnull
> macro that controls it is undefined in include/sys/cdefs.h.  There
> is a comment above the #undef in the header that reads:
> 
> /* The compiler will optimize based on the knowledge the parameter is
>    not NULL.  This will omit tests.  A robust implementation cannot allow
>    this so when compiling glibc itself we ignore this attribute.  */
> # undef __nonnull
> # define __nonnull(params)
> 
> I don't think this is actually true for recent versions of GCC.
> The nonnull optimization is controlled by
> -fisolate-erroneous-paths-attribute and according to the manual
> and common.opt the option is disabled by default.
> 
> But if you do want to avoid the attribute on declarations of
> these functions regardless it should be safe to add it after
> the declaration in the .c file, like so:
> 
> __hidden_ver1 (strcmp, __GI_strcmp, __redirect_strcmp)
>   __attribute__ ((visibility ("hidden"), copy (strcmp)));
> 
> That should make it straightforward to adopt the enhancement
> and experiment with -Wattribute-alias=2 to see if it does what
> you had  in mind.
> 
> The latest GCC patch with the fix mentioned above is attached.
> 
> Martin
> 
> gcc-81824.diff
> 
> PR middle-end/81824 - Warn for missing attributes with function aliases
> 
> gcc/c-family/ChangeLog:
> 
>   PR middle-end/81824
>   * c-attribs.c (handle_copy_attribute_impl): New function.
>   (handle_copy_attribute): Same.
> 
> gcc/cp/ChangeLog:
> 
>   PR middle-end/81824
>   * pt.c (warn_spec_missing_attributes): Move code to attribs.c.
>   Call decls_mismatched_attributes.
> 
> gcc/ChangeLog:
> 
>   PR middle-end/81824
>   * attribs.c (has_attribute): New helper function.
>   (decls_mismatched_attributes, maybe_diag_alias_attributes): Same.
>   * attribs.h (decls_mismatched_attributes): Declare.
>   * cgraphunit.c (handle_alias_pairs): Call maybe_diag_alias_attributes.
>   (maybe_diag_incompatible_alias): Use OPT_Wattribute_alias_.
>   * common.opt (-Wattribute-alias): Take an argument.
>   (-Wno-attribute-alias): New option.
>   * doc/extend.texi (Common Function Attributes): Document copy.
>   (Common Variable Attributes): Same.
>   * doc/invoke.texi (-Wmissing-attributes): Document enhancement.
>   (-Wattribute-alias): Document new option 

Re: [PATCH] Fix PR87691: transparent_union attribute does not work with MODE_PARTIAL_INT

[Marek Polacek]

On Tue, Oct 23, 2018 at 08:49:26PM +0100, Jozef Lawrynowicz wrote:
> msp430-elf uses the partial int type __int20 for pointers in the large memory
> model. __int20 has PSImode, with bitsize of 20.
> 
> A few DejaGNU tests fail when built with -mlarge for msp430-elf, when
> transparent unions are used containing pointers.
> These are:
> - gcc.c-torture/compile/pr34885.c
> - gcc.dg/transparent-union-{1,2,3,4,5}.c
> 
> The issue is that the union is considered to have size of 32 bits (the
> in-memory size of __int20), so unless mode_for_size as called by
> compute_record_mode (both in stor-layout.c) is explicitly told to look for a
> mode of class MODE_PARTIAL_INT, then a size of 32 will always return MODE_INT.
> In this case, the union will have TYPE_MODE of SImode, but its field is
> PSImode, so transparent_union has no effect.
> 
> The attached patch fixes the issue by allowing the TYPE_MODE of a union to be
> set to the DECL_MODE of the widest field, if the mode is of class
> MODE_PARTIAL_INT and the union would be passed by reference.
> 
> Some target ABIs mandate that unions be passed in integer registers, so to
> avoid any potential ABI violations, the mode of the union is only changed if
> it would be passed by reference.
> 
> Successfully bootstrapped and regstested trunk for x86_64-pc-linux-gnu, and
> msp430-elf with -mlarge. For msp430-elf with -mlarge, the above DejaGNU tests
> are also fixed.
> 
> Ok for trunk?
> 

> From cc1ccfcc0d8adf7b0e1ca95a47a8a8e7e12fc99c Mon Sep 17 00:00:00 2001
> From: Jozef Lawrynowicz 
> Date: Mon, 22 Oct 2018 21:02:10 +0100
> Subject: [PATCH] Allow union TYPE_MODE to be set to the mode of the widest
>  element if the union would be passed by reference
> 
> 2018-10-23  Jozef Lawrynowicz  
> 
>   PR c/87691
>   * gcc/stor-layout.c (compute_record_mode): Set TYPE_MODE of UNION_TYPE
>   to the mode of the widest field iff the widest field has mode class
>   MODE_INT, or MODE_PARTIAL_INT and the union would be passed by
>   reference.
>   * gcc/testsuite/gcc.target/msp430/pr87691.c: New test.

I'll just point out that you should drop the gcc/ and gcc/testsuite/ prefixes;
the first entry will go to gcc/ChangeLog while the pr87691.c one to
gcc/testsuite/ChangeLog.

Marek

[PATCH] [aarch64] Correct the maximum shift amount for shifted operands.

[christoph . muellner]

From: Christoph Muellner 

The aarch64 ISA specification allows a left shift amount to be applied
after extension in the range of 0 to 4 (encoded in the imm3 field).

This is true for at least the following instructions:

 * ADD (extend register)
 * ADDS (extended register)
 * SUB (extended register)

The result of this patch can be seen, when compiling the following code:

uint64_t myadd(uint64_t a, uint64_t b)
{
return a+(((uint8_t)b)<<4);
}

Without the patch the following sequence will be generated:

 :
   0:   d37c1c21ubfiz   x1, x1, #4, #8
   4:   8b20add x0, x1, x0
   8:   d65f03c0ret

With the patch the ubfiz will be merged into the add instruction:

 :
   0:   8b211000add x0, x0, w1, uxtb #4
   4:   d65f03c0ret

*** gcc/ChangeLog ***

2018-xx-xx  Christoph Muellner 

* gcc/config/aarch64/aarch64.c: Correct the maximum shift amount
for shifted operands.
* gcc/testsuite/gcc.target/aarch64/extend.c: Adjust the
testcases to cover the changed shift amount.

Signed-off-by: Christoph Muellner 
Signed-off-by: Philipp Tomsich 
---
 gcc/config/aarch64/aarch64.c  |  2 +-
 gcc/testsuite/gcc.target/aarch64/extend.c | 16 
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index c82c7b6..c85988a 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -8190,7 +8190,7 @@ aarch64_output_casesi (rtx *operands)
 int
 aarch64_uxt_size (int shift, HOST_WIDE_INT mask)
 {
-  if (shift >= 0 && shift <= 3)
+  if (shift >= 0 && shift <= 4)
 {
   int size;
   for (size = 8; size <= 32; size *= 2)
diff --git a/gcc/testsuite/gcc.target/aarch64/extend.c 
b/gcc/testsuite/gcc.target/aarch64/extend.c
index f399e55..7986c5b 100644
--- a/gcc/testsuite/gcc.target/aarch64/extend.c
+++ b/gcc/testsuite/gcc.target/aarch64/extend.c
@@ -32,8 +32,8 @@ ldr_sxtw0 (char *arr, int i)
 unsigned long long
 adddi_uxtw (unsigned long long a, unsigned int i)
 {
-  /* { dg-final { scan-assembler "add\tx\[0-9\]+,.*uxtw #?3" } } */
-  return a + ((unsigned long long)i << 3);
+  /* { dg-final { scan-assembler "add\tx\[0-9\]+,.*uxtw #?4" } } */
+  return a + ((unsigned long long)i << 4);
 }
 
 unsigned long long
@@ -46,8 +46,8 @@ adddi_uxtw0 (unsigned long long a, unsigned int i)
 long long
 adddi_sxtw (long long a, int i)
 {
-  /* { dg-final { scan-assembler "add\tx\[0-9\]+,.*sxtw #?3" } } */
-  return a + ((long long)i << 3);
+  /* { dg-final { scan-assembler "add\tx\[0-9\]+,.*sxtw #?4" } } */
+  return a + ((long long)i << 4);
 }
 
 long long
@@ -60,8 +60,8 @@ adddi_sxtw0 (long long a, int i)
 unsigned long long
 subdi_uxtw (unsigned long long a, unsigned int i)
 {
-  /* { dg-final { scan-assembler "sub\tx\[0-9\]+,.*uxtw #?3" } } */
-  return a - ((unsigned long long)i << 3);
+  /* { dg-final { scan-assembler "sub\tx\[0-9\]+,.*uxtw #?4" } } */
+  return a - ((unsigned long long)i << 4);
 }
 
 unsigned long long
@@ -74,8 +74,8 @@ subdi_uxtw0 (unsigned long long a, unsigned int i)
 long long
 subdi_sxtw (long long a, int i)
 {
-  /* { dg-final { scan-assembler "sub\tx\[0-9\]+,.*sxtw #?3" } } */
-  return a - ((long long)i << 3);
+  /* { dg-final { scan-assembler "sub\tx\[0-9\]+,.*sxtw #?4" } } */
+  return a - ((long long)i << 4);
 }
 
 long long
-- 
2.9.5

[Bug fortran/87919] Incorrect fortran handling of -fno-* options

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
The -fdec-structure part has been posted in
https://gcc.gnu.org/ml/fortran/2018-11/msg00029.html

Re: [PATCH] Fix PR87691: transparent_union attribute does not work with MODE_PARTIAL_INT

[Jeff Law]

On 10/23/18 1:49 PM, Jozef Lawrynowicz wrote:
> msp430-elf uses the partial int type __int20 for pointers in the large memory
> 
> model. __int20 has PSImode, with bitsize of 20.
> 
> A few DejaGNU tests fail when built with -mlarge for msp430-elf, when
> transparent unions are used containing pointers.
> These are:
> - gcc.c-torture/compile/pr34885.c
> - gcc.dg/transparent-union-{1,2,3,4,5}.c
> 
> The issue is that the union is considered to have size of 32 bits (the
> in-memory size of __int20), so unless mode_for_size as called by
> compute_record_mode (both in stor-layout.c) is explicitly told to look for a
> 
> mode of class MODE_PARTIAL_INT, then a size of 32 will always return MODE_INT.
> 
> In this case, the union will have TYPE_MODE of SImode, but its field is
> PSImode, so transparent_union has no effect.
> 
> The attached patch fixes the issue by allowing the TYPE_MODE of a union to be
> 
> set to the DECL_MODE of the widest field, if the mode is of class
> MODE_PARTIAL_INT and the union would be passed by reference.
> 
> Some target ABIs mandate that unions be passed in integer registers, so to
> avoid any potential ABI violations, the mode of the union is only changed if
> 
> it would be passed by reference.
> 
> Successfully bootstrapped and regstested trunk for x86_64-pc-linux-gnu, and
> msp430-elf with -mlarge. For msp430-elf with -mlarge, the above DejaGNU tests
> 
> are also fixed.
> 
> Ok for trunk?
> 
> 
> 0001-Allow-union-TYPE_MODE-to-be-set-to-the-mode-of-the-w.patch
> 
> From cc1ccfcc0d8adf7b0e1ca95a47a8a8e7e12fc99c Mon Sep 17 00:00:00 2001
> From: Jozef Lawrynowicz 
> Date: Mon, 22 Oct 2018 21:02:10 +0100
> Subject: [PATCH] Allow union TYPE_MODE to be set to the mode of the widest
>  element if the union would be passed by reference
> 
> 2018-10-23  Jozef Lawrynowicz  
> 
>   PR c/87691
>   * gcc/stor-layout.c (compute_record_mode): Set TYPE_MODE of UNION_TYPE
>   to the mode of the widest field iff the widest field has mode class
>   MODE_INT, or MODE_PARTIAL_INT and the union would be passed by
>   reference.
>   * gcc/testsuite/gcc.target/msp430/pr87691.c: New test.
OK.  SOrry for the delay.

jeff

Supply Chain Managers Contacts

[Lauren White]

Hi

 

I wanted to check if you'd be interested in acquiring Supply Chain Managers
Contacts for your sales and marketing campaigns?

 

Each Contact Contains: LinkedIn Profile, Company Name, Contact name, Title,
Address, Phone, Fax, City, State, Zip codes, Country, Industry, Employee
size, Revenue size, Sic Code, Website and verified email address.

 

Let me know if you are interested and I will get back to you with the counts
and pricing for your review. 

  

NOTE: If the above industry in not relevant to you then please revert back
with your relevant target audience. 

 

Regards,

Lauren White

Manager - Demand Generation

Santa Clara - 95054, CA.

 

_

To stop receiving future emails, please reply with UNSUBSCRIBE in the
Subject Line.

 

[Bug fortran/85982] ICE in resolve_component, at fortran/resolve.c:13696

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2018-05-31 00:00:00 |2018-11-7
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org
  Known to fail||6.4.0, 9.0

[Bug fortran/87919] Incorrect fortran handling of -fno-* options

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-07
 CC||foreese at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org
   Target Milestone|--- |7.4
 Ever confirmed|0   |1

Re: [PATCH] avoid warning on constant strncpy until next statement is reachable (PR 87028)

[Jeff Law]

On 10/20/18 6:01 PM, Martin Sebor wrote:


> 
> The warning only triggers when the bound is less than or equal
> to the length of the constant source string (i.e, when strncpy
> truncates).  So IIUC, your suggestion would defer folding only
> such strncpy calls and let gimple_fold_builtin_strncpy fold
> those with a constant bound that's greater than the length of
> the constant source string.  That would be fine with me, but
> since strncpy calls with a bound that's greater than the length
> of the source are pointless I don't think they are important
> enough to worry about folding super early.  The constant ones
> that serve any purpose (and that are presumably important to
> optimize) are those that truncate.
I was focused exclusively on the case where we have to look for a
subsequent statement that handled termination.  The idea was to only
leave in the cases that we might need to warn for because we couldn't
search subsequent statement for the termination.

Splitting up was primarily meant to get the warning out of the folder
with a minimal impact on code generation.  But if the common case would
result in deferral of folding, then I'd fully expect Richi to object.

> 
> That said, when optimization isn't enabled, I don't think users
> expect calls to library functions to be transformed to calls to
> other  functions, or inlined.  Yet that's just what GCC does.
> For example, besides triggering the warning, the following:
I don't think we should drag this into the issue at hand.  Though I do
generally agree that folding this stuff into low level memory operations
is not what most would expect at -O0.


Jeff

Re: [PATCH] Add option to control warnings added through attribure "warning"

[Jeff Law]

On 10/15/18 9:21 AM, Nikolai Merinov wrote:
> Hi Martin,
> 
> On 10/15/18 6:20 PM, Martin Sebor wrote:
>> On 10/15/2018 01:55 AM, Nikolai Merinov wrote:
>>> Hi Martin,
>>>
>>> On 10/12/18 9:58 PM, Martin Sebor wrote:
 On 10/12/2018 04:14 AM, Nikolai Merinov wrote:
> Hello,
>
> In https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01795.html mail I
> suggested patch to have ability to control behavior of
> "__attribute__((warning))" in case when option "-Werror" enabled.
> Usage
> example:
>
>> #include 
>> int a() __attribute__((warning("Warning: `a' was used")));
>> int a() { return 1; }
>> int main () { return a(); }
>
>> $ gcc -Werror test.c
>> test.c: In function ‘main’:
>> test.c:4:22: error: call to ‘a’ declared with attribute warning:
>> Warning: `a' was used [-Werror]
>>  int main () { return a(); }
>>   ^
>> cc1: all warnings being treated as errors
>> $ gcc -Werror -Wno-error=warning-attribute test.c
>> test.c: In function ‘main’:
>> test.c:4:22: warning: call to ‘a’ declared with attribute warning:
>> Warning: `a' was used
>>  int main () { return a(); }
>>   ^
> Can you provide any feedback on suggested changes?

 It seems like a useful feature and in line with the philosophy
 that distinct warnings should be controlled by their own options.

 I would only suggest to consider changing the name to
 -Wattribute-warning, because it applies specifically to that
 attribute (as opposed to warnings about attributes in general).

 There are many attributes in GCC and diagnosing problems that
 are unique to each, under the same -Wattributes option, is
 becoming too coarse and overly limiting.  To make it more
 flexible, I expect new options will need to be introduced,
 such as -Wattribute-alias (to control aspects of the alias
 attribute and others related to it), or -Wattribute-const
 (to control diagnostics about functions declared with
 attribute const that violate the attribute's constraints).

 An alternative might be to introduce a single -Wattribute=
  option where the  gives
 the names of all the distinct attributes whose unique
 diagnostics one might need to control.

 Martin
>>>
>>> Currently there is several styles already in use:
>>>
>>> -Wattribute-alias where "attribute" word used as prefix for name of
>>> attribute,
>>> -Wsuggest-attribute=[pure|const|noreturn|format|malloc] where name of
>>> attribute passed as possible argument,
>>> -Wmissing-format-attribute where "attribute" word used as suffix,
>>> -Wdeprecated-declarations where "attribute" word not used at all even
>>> if this warning option was created especially for "deprecated"
>>> attribute.
>>>
>>> I changed name to "-Wattribute-warning" as you suggested, but
>>> unifying style for all attribute related warning looks like separate
>>> activity. Please check new patch in attachments.
>>>
>>
>> Thanks for survey!  I agree that making the existing options
>> consistent (if that's what we want) should be done separately.
>>
>> Martin
>>
>> PS It doesn't look like your latest attachments made it to
>> the list.
>>
> Thank you for mentioning. There was my mistake. Now it's attached
>>
>>> Updated changelog:
>>>
>>> gcc/Changelog
>>>
>>> 2018-10-14  Nikolai Merinov 
>>>
>>>  * gcc/common.opt: Add -Wattribute-warning.
>>>  * gcc/doc/invoke.texi: Add documentation for
>>> -Wno-attribute-warning.
>>>  * gcc/testsuite/gcc.dg/Wno-attribute-warning.c: New test.
>>>  * gcc/expr.c (expand_expr_real_1): Add new attribute to
>>> warning_at
>>>  call to allow user configure behavior of "warning" attribute
I split up the ChangeLog and fixed a very minor whitespace issue in the
docs and installed the patch.

I went round and round over whether or not to change the doc text.  It
discusses the attribute and the warning and it's easy to mix up the two.
 But ultimately I decided not to change it.

Thanks and sorry for the long delays.

Jeff
> 

[Bug middle-end/87854] [9 Regression] gcc.c-torture/compile/pr46534.c ICE for 16-bit size_t

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  ---
(In reply to Jozef Lawrynowicz from comment #0)
> Rather than ICE'ing should there be some error message about object size
> being too large?

Yes.  In any case, there should be no ICE whatever code you provide.

[Bug middle-end/78707] [6 Regression] internal compiler error: in push_reload, at reload.c:1349

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|6.5 |7.0

--- Comment #4 from Jakub Jelinek  ---
Thus fixed in 7.x.

[Bug other/56183] [meta-bug][avr] Problems with register allocation

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183
Bug 56183 depends on bug 78707, which changed state.

Bug 78707 Summary: [6 Regression] internal compiler error: in push_reload, at 
reload.c:1349
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78707

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug middle-end/78707] [6 Regression] internal compiler error: in push_reload, at reload.c:1349

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

  Known to work||7.1.1, 8.0.1

--- Comment #3 from Georg-Johann Lay  ---
(In reply to Jakub Jelinek from comment #2)
> Does this fail also with 7.x and later?

The test case passes fine for me with 7.1.1 and 8.0.1.

[Bug fortran/87922] ICE in gfc_wide_strlen, at fortran/scanner.c:142

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-07
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/io.c
===
--- gcc/fortran/io.c(revision 265885)
+++ gcc/fortran/io.c(working copy)
@@ -2232,6 +2232,21 @@ gfc_match_open (void)
   if (!is_char_type ("ASYNCHRONOUS", open->asynchronous))
goto cleanup;

+  if (open->asynchronous->ts.kind != 1)
+   {
+ gfc_error ("ASYNCHRONOUS= specifier at %L must have be of default "
+"CHARACTER kind", >asynchronous->where);
+ return MATCH_ERROR;
+   }
+
+  if (open->asynchronous->expr_type == EXPR_ARRAY
+ || open->asynchronous->expr_type == EXPR_STRUCTURE)
+   {
+ gfc_error ("ASYNCHRONOUS= specifier at %L must have be scalar",
+>asynchronous->where);
+ return MATCH_ERROR;
+   }
+
   if (open->asynchronous->expr_type == EXPR_CONSTANT)
{
  static const char * asynchronous[] = { "YES", "NO", NULL };
@@ -3792,6 +3807,21 @@ if (condition) \

   if (!is_char_type ("ASYNCHRONOUS", dt->asynchronous))
return MATCH_ERROR;
+
+  if (dt->asynchronous->ts.kind != 1)
+   {
+ gfc_error ("ASYNCHRONOUS= specifier at %L must have be of default "
+"CHARACTER kind", >asynchronous->where);
+ return MATCH_ERROR;
+   }
+
+  if (dt->asynchronous->expr_type == EXPR_ARRAY
+ || dt->asynchronous->expr_type == EXPR_STRUCTURE)
+   {
+ gfc_error ("ASYNCHRONOUS= specifier at %L must have be scalar",
+>asynchronous->where);
+ return MATCH_ERROR;
+   }

   if (!compare_to_allowed_values
("ASYNCHRONOUS", asynchronous, NULL, NULL,

Re: Extracting live registers

[Paulo Matos]

On 07/11/2018 20:27, Segher Boessenkool wrote:
> 
> Sure, it shows the register information at the edges of basic blocks
> only.  This is what you asked for btw ;-)
> 
> 

True, but I need a way to map that information to the assembly
instructions in the basic block. :) I think it's not impossible with all
that gcc provides, but there's certainly a fair amount of parsing of
these files, which is not ideal given their format might change under my
feet.

-- 
Paulo Matos

[gomp5] Merge from trunk

[Jakub Jelinek]

Hi!

I've merged trunk into gomp-5_0-branch.  atomic-5.C testcase needed some
adjustments for recent C++ FE changes and the taskloop-reduction-1.c
testcase wasn't correct for 32-bit targets.

Tested on x86_64-linux and on i686-linux (the latter libgomp only),
committed to gomp-5_0-branch.

2018-11-07  Jakub Jelinek  

* g++.dg/gomp/atomic-5.C (f1): Adjust expected lines of read-only
variable messages.

* testsuite/libgomp.c-c++-common/taskloop-reduction-1.c (S): Change
type of s and t members from unsigned long int to
unsigned long long int.

--- gcc/testsuite/g++.dg/gomp/atomic-5.C(revision 265885)
+++ gcc/testsuite/g++.dg/gomp/atomic-5.C(working copy)
@@ -12,12 +12,12 @@ void f1(void)
 x = x + 1;
   #pragma omp atomic
 x = 1; /* { dg-error "invalid form" } */
-  #pragma omp atomic
+  #pragma omp atomic   /* { dg-error "read-only variable" } */
 ++y;   /* { dg-error "read-only variable" } */
-  #pragma omp atomic
+  #pragma omp atomic   /* { dg-error "read-only variable" } */
 y--;   /* { dg-error "read-only variable" } */
-  #pragma omp atomic
-y += 1;/* { dg-error "read-only variable" } */
+  #pragma omp atomic   /* { dg-error "read-only variable" } */
+y += 1;
   #pragma omp atomic
 bar(); /* { dg-error "invalid operator" } */
   #pragma omp atomic
--- libgomp/testsuite/libgomp.c-c++-common/taskloop-reduction-1.c   
(revision 265885)
+++ libgomp/testsuite/libgomp.c-c++-common/taskloop-reduction-1.c   
(working copy)
@@ -4,7 +4,7 @@ extern
 #endif
 void abort (void);
 
-struct S { unsigned long int s, t; };
+struct S { unsigned long long int s, t; };
 
 void
 rbar (struct S *p, struct S *o)

Jakub

Re: Running the C++ library tests in the GCC testsuite

[Joseph Myers]

On Wed, 7 Nov 2018, Steve Ellcey wrote:

> I copied unix.exp to unix-sysroot.exp and added this to it:
> 
> if {[info exists env(DEJAGNU_UNIX_SYSROOT_FLAGS)]} {
> set_board_info ldflags "$env(DEJAGNU_UNIX_SYSROOT_FLAGS)"
> }
> 
> I figured I would deal with LOCPATH and GCONV_PATH later.  When
> I do a partial testrun, I don't get any failures but I do get some
> new unresolved tests like this:
> 
> Download of ./2108-1.exe to unix-sysroot failed.
> UNRESOLVED: gcc.dg/2108-1.c execution test
> 
> Have ever seen this error?

By using a different name from unix.exp (and you don't want to have your 
own file called unix.exp - too much risk of confusion), you're probably 
making DejaGnu think it's remote, and so try to copy files to a host 
called unix-sysroot.  You'll need to set isremote for the board to 0 to 
avoid that, if it's not in fact remote (or set hostname if it is remote).

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

[Bug c++/69348] alias declarations can not be used inside qualifiers of declarators

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-07
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

Re: Free TYPE_VALUES of enums

[Bernhard Reutner-Fischer]

On Wed, 7 Nov 2018 14:09:24 +0100
Richard Biener  wrote:

> On Wed, Nov 7, 2018 at 1:34 PM Jan Hubicka  wrote:

> > Bootstrapped/regtested x86_64-linux, will commit it after
> > lto-bootstrapping uneless there are complains.  

> > +/* Save some WPA->ltrans streaming by freeing enum values.  */
> > +
> > +static void
> > +free_enum_values ()
> > +{
> > +  static bool enum_values_freed = false;
> > +  if (enum_values_freed || !flag_wpa || !odr_types_ptr)
> > +return;
> > +  enum_values_freed = true;
[]
> > +  enum_values_freed = true;
> >  }

Short of a "verytrue" choice for boolean, i think setting it to true
once should be enough though.

cheers,

Re: Extracting live registers

[Segher Boessenkool]

On Wed, Nov 07, 2018 at 08:52:15AM +0100, Paulo Matos wrote:
> On 07/11/2018 00:40, Segher Boessenkool wrote:
> > -fdump-rtl-alignments[-all] is the last dump with all that information I
> > think.  This one also has all this info without -all it seems.  With -all
> > it shows it interleaving the RTL dump as well, which may or may not be
> > handy for you.
> 
> Thanks, however it provides no correspondence to the set of asm
> instructions in the basic block. After you mentioned
> -fdump-rtl-alignments, I tried a few related flags and hit upon what I
> thought would work: -dA and -dP, but unfortunately these don't output
> live out information per basic block so it's not helpful for my
> application. It would be great if -dA or -dP would show live out info as
> well, but that doesn't seem to be the case at the moment.

Sure, it shows the register information at the edges of basic blocks
only.  This is what you asked for btw ;-)

(The per-instruction info isn't readily available, and none of this is
available in the final passes).


Segher

Re: [PATCH, OpenACC] Properly handle wait clause with no arguments

[Jakub Jelinek]

On Wed, Nov 07, 2018 at 08:13:29PM +0100, Thomas Schwinge wrote:
> Isn't that sufficient for the ABI compatibility that we promise, which is
> (unless I'm confused now?) that old (existing) executables continue to
> run correctly when dynamically linking against a new libgomp.  Or do we
> also have to care about the case that an executable built with a new
> version of GCC has to work when dynamically linked against an old
> libgomp?

Only old executables/libraries need to continue running correctly when
linking against new libgomp.  New programs against old libgomp might work,
or might not.

Jakub

Re: [PATCH, OpenACC] Properly handle wait clause with no arguments

[Thomas Schwinge]

Hi Chung-Lin!

On Thu, 30 Aug 2018 21:27:22 +0800, Chung-Lin Tang  
wrote:
> Hi, this patch properly handles OpenACC 'wait' clauses without arguments, 
> making it an equivalent of "wait all".

Thanks!

> (current trunk basically discards and ignores such argument-less wait
> clauses)

Bugs should be filed, for later reference.  Now done:
 "OpenACC wait clauses without
async-arguments".  (I couldn't put you in CC because "clt...@gcc.gnu.org
did not match anything"?)

> This adds additional handling in
> the pack/unpack of the wait argument across the compiler/libgomp interface, 
> but is done in a matter that
> doesn't affect binary compatibility.

Hmm.  See below.  (Jakub, could you please review the last paragraph of
this email?)

> This patch was part of the OpenACC async re-work that was done on the gomp4 
> branch (later merged to OG7/OG8), see [1].
> I'm separating this part out and submitting it first because it's logically 
> independent.
> 
> [1] https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01842.html

Thanks for splitting it out!

> Re-tested with offloading to ensure no regressions, is this okay for trunk?

A few comments.

No test cases included.  I'm working on a few, will post/commit later.

>  gcc/c/
>  * c-parser.c (c_parser_oacc_clause_wait): Add representation of wait
>  clause without argument as 'wait (GOMP_ASYNC_NOVAL)', adjust 
> comments.
> 
>  gcc/cp/
>  * parser.c (cp_parser_oacc_clause_wait): Add representation of wait
>  clause without argument as 'wait (GOMP_ASYNC_NOVAL)', adjust 
> comments.
> 
>  gcc/fortran/
>  * trans-openmp.c (gfc_trans_omp_clauses_1): Add representation of 
> wait
>  clause without argument as 'wait (GOMP_ASYNC_NOVAL)'.
> 
>  gcc/
>  * omp-low.c (expand_omp_target): Add middle-end support for handling
>  OMP_CLAUSE_WAIT clause with a GOMP_ASYNC_NOVAL(-1) as the argument.
> 
>  include/
>  * gomp-constants.h (GOMP_LAUNCH_OP_MASK): Define.
>  (GOMP_LAUNCH_PACK): Add bitwise-and of GOMP_LAUNCH_OP_MASK.
>  (GOMP_LAUNCH_OP): Likewise.
> 
>  libgomp/
>  * oacc-parallel.c (GOACC_parallel_keyed): Interpret launch op as
>  signed 16-bit field, adjust num_waits handling.
>  (GOACC_enter_exit_data): Adjust num_waits handling.
>  (GOACC_update): Adjust num_waits handling.

> --- gcc/c/c-parser.c  (revision 263981)
> +++ gcc/c/c-parser.c  (working copy)
> @@ -12719,7 +12719,7 @@ c_parser_oacc_clause_tile (c_parser *parser, tree
>  }
>  
>  /* OpenACC:
> -   wait ( int-expr-list ) */
> +   wait [( int-expr-list )] */
>  
>  static tree
>  c_parser_oacc_clause_wait (c_parser *parser, tree list)
> @@ -12728,7 +12728,15 @@ c_parser_oacc_clause_wait (c_parser *parser, tree
>  
>if (c_parser_peek_token (parser)->type == CPP_OPEN_PAREN)
>  list = c_parser_oacc_wait_list (parser, clause_loc, list);
> +  else
> +{
> +  tree c = build_omp_clause (clause_loc, OMP_CLAUSE_WAIT);
>  
> +  OMP_CLAUSE_DECL (c) = build_int_cst (integer_type_node, 
> GOMP_ASYNC_NOVAL);
> +  OMP_CLAUSE_CHAIN (c) = list;
> +  list = c;
> +}
> +
>return list;
>  }

ACK.

> --- gcc/cp/parser.c   (revision 263981)
> +++ gcc/cp/parser.c   (working copy)
> @@ -32137,7 +32137,7 @@ cp_parser_oacc_wait_list (cp_parser *parser, locat
>  }
>  
>  /* OpenACC:
> -   wait ( int-expr-list ) */
> +   wait [( int-expr-list )] */
>  
>  static tree
>  cp_parser_oacc_clause_wait (cp_parser *parser, tree list)
> @@ -32144,10 +32144,16 @@ cp_parser_oacc_clause_wait (cp_parser *parser, tre
>  {
>location_t location = cp_lexer_peek_token (parser->lexer)->location;
>  
> -  if (cp_lexer_peek_token (parser->lexer)->type != CPP_OPEN_PAREN)
> -return list;
> +  if (cp_lexer_peek_token (parser->lexer)->type == CPP_OPEN_PAREN)
> +list = cp_parser_oacc_wait_list (parser, location, list);
> +  else
> +{
> +  tree c = build_omp_clause (location, OMP_CLAUSE_WAIT);
>  
> -  list = cp_parser_oacc_wait_list (parser, location, list);
> +  OMP_CLAUSE_DECL (c) = build_int_cst (integer_type_node, 
> GOMP_ASYNC_NOVAL);
> +  OMP_CLAUSE_CHAIN (c) = list;
> +  list = c;
> +}
>  
>return list;
>  }

ACK.

> --- gcc/fortran/trans-openmp.c(revision 263981)
> +++ gcc/fortran/trans-openmp.c(working copy)
> @@ -2922,6 +2922,13 @@ gfc_trans_omp_clauses (stmtblock_t *block, gfc_omp
> omp_clauses = c;
>   }
>  }
> +  else if (clauses->wait)
> +{
> +  c = build_omp_clause (where.lb->location, OMP_CLAUSE_WAIT);
> +  OMP_CLAUSE_DECL (c) = build_int_cst (integer_type_node, 
> GOMP_ASYNC_NOVAL);
> +  OMP_CLAUSE_CHAIN (c) = omp_clauses;
> +  omp_clauses = c;
> +}
>if (clauses->num_gangs_expr)
>  {
>tree num_gangs_var

NACK.  Instead let's do the following, similar to C, C++, and also
similar to Fortran's OpenACC async 

Re: [PATCH] Implement std::pmr::unsynchronized_pool_resource

[Jonathan Wakely]

On 07/11/18 19:55 +0100, Rainer Orth wrote:

Hi Jonathan,


Implement std::pmr::unsynchronized_pool_resource
* config/abi/pre/gnu.ver: Add new symbols.
* include/std/memory_resource (std::pmr::__pool_resource): New class.
(std::pmr::unsynchronized_pool_resource): New class.
* src/c++17/Makefile.am: Add -fimplicit-templates to flags for
memory_resource.cc
* src/c++17/Makefile.in: Regenerate.
* src/c++17/memory_resource.cc (bitset, chunk, big_block): New
internal classes.
(__pool_resource::_Pool): Define new class.
(munge_options, pool_index, select_num_pools): New internal functions.
(__pool_resource::__pool_resource, __pool_resource::~__pool_resource)
(__pool_resource::allocate, __pool_resource::deallocate)
(__pool_resource::_M_alloc_pools): Define member functions.
(unsynchronized_pool_resource::unsynchronized_pool_resource)
(unsynchronized_pool_resource::~unsynchronized_pool_resource)
(unsynchronized_pool_resource::release)
(unsynchronized_pool_resource::_M_find_pool)
(unsynchronized_pool_resource::do_allocate)
(unsynchronized_pool_resource::do_deallocate): Define member
functions.
* testsuite/20_util/unsynchronized_pool_resource/allocate.cc: New
test.
* testsuite/20_util/unsynchronized_pool_resource/is_equal.cc: New
test.
* testsuite/20_util/unsynchronized_pool_resource/options.cc: New
test.
* testsuite/20_util/unsynchronized_pool_resource/release.cc: New
test.

The new tests being added here are pretty minimal, because we can't
assume machines running the testsuite will be able to allocate large
amounts of memory. I've tested it more thoroughly with much larger
tests though, and will try to get some of them in shape for the
testsuite/performance/20_util directory.

Tested powerpc64le-linux. Committed to trunk.


two of the new tests FAIL on 32-bit targets (seen on
i386-pc-solaris2.11, but there are other reports as well):

+FAIL: 20_util/unsynchronized_pool_resource/allocate.cc (test for excess errors)
+UNRESOLVED: 20_util/unsynchronized_pool_resource/allocate.cc compilation 
failed to produce executable

Excess errors:
Undefined   first referenced
symbol in file
std::pmr::unsynchronized_pool_resource::do_deallocate(void*, unsigned int, 
unsigned int) /var/tmp//ccUR6CSd.o
std::pmr::unsynchronized_pool_resource::do_allocate(unsigned int, unsigned int) 
/var/tmp//ccUR6CSd.o
ld: fatal: symbol referencing errors

+FAIL: 20_util/unsynchronized_pool_resource/release.cc (test for excess errors)
+UNRESOLVED: 20_util/unsynchronized_pool_resource/release.cc compilation failed 
to produce executable

Excess errors:
Undefined   first referenced
symbol in file
std::pmr::unsynchronized_pool_resource::do_allocate(unsigned int, unsigned int) 
/var/tmp//ccrQoKEb.o
ld: fatal: symbol referencing errors


Sorry about that, should be fixed by this patch. Committed to trunk.


commit f36c97256c4173516116f4c64c39c81ffec98d70
Author: Jonathan Wakely 
Date:   Wed Nov 7 19:07:26 2018 +

Fix linker script to use [jmy] to match size_t parameters

* config/abi/pre/gnu.ver: Fix patterns for size_t parameters.

diff --git a/libstdc++-v3/config/abi/pre/gnu.ver b/libstdc++-v3/config/abi/pre/gnu.ver
index b55038b8845..9d66f908e1a 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -2061,8 +2061,8 @@ GLIBCXX_3.4.26 {
 _ZNSt3pmr28unsynchronized_pool_resourceC[12]ERKNS_12pool_optionsEPNS_15memory_resourceE;
 _ZNSt3pmr28unsynchronized_pool_resourceD[12]Ev;
 _ZNSt3pmr28unsynchronized_pool_resource7releaseEv;
-_ZNSt3pmr28unsynchronized_pool_resource11do_allocateEmm;
-_ZNSt3pmr28unsynchronized_pool_resource13do_deallocateEPvmm;
+_ZNSt3pmr28unsynchronized_pool_resource11do_allocateE[jmy][jmy];
+_ZNSt3pmr28unsynchronized_pool_resource13do_deallocateEPv[jmy][jmy];
 
 } GLIBCXX_3.4.25;
 

[Bug c/87924] New: OpenACC wait clauses without async-arguments

[tschwinge at gcc dot gnu.org]

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

Bug ID: 87924
   Summary: OpenACC wait clauses without async-arguments
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc, patch
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

As reported in ,
we're currently not taking any action for OpenACC wait clauses without
async-arguments.

Re: [PATCH] Implement std::pmr::unsynchronized_pool_resource

[Rainer Orth]

Hi Jonathan,

>   Implement std::pmr::unsynchronized_pool_resource
>   * config/abi/pre/gnu.ver: Add new symbols.
>   * include/std/memory_resource (std::pmr::__pool_resource): New class.
>   (std::pmr::unsynchronized_pool_resource): New class.
>   * src/c++17/Makefile.am: Add -fimplicit-templates to flags for
>   memory_resource.cc
>   * src/c++17/Makefile.in: Regenerate.
>   * src/c++17/memory_resource.cc (bitset, chunk, big_block): New
>   internal classes.
>   (__pool_resource::_Pool): Define new class.
>   (munge_options, pool_index, select_num_pools): New internal functions.
>   (__pool_resource::__pool_resource, __pool_resource::~__pool_resource)
>   (__pool_resource::allocate, __pool_resource::deallocate)
>   (__pool_resource::_M_alloc_pools): Define member functions.
>   (unsynchronized_pool_resource::unsynchronized_pool_resource)
>   (unsynchronized_pool_resource::~unsynchronized_pool_resource)
>   (unsynchronized_pool_resource::release)
>   (unsynchronized_pool_resource::_M_find_pool)
>   (unsynchronized_pool_resource::do_allocate)
>   (unsynchronized_pool_resource::do_deallocate): Define member
>   functions.
>   * testsuite/20_util/unsynchronized_pool_resource/allocate.cc: New
>   test.
>   * testsuite/20_util/unsynchronized_pool_resource/is_equal.cc: New
>   test.
>   * testsuite/20_util/unsynchronized_pool_resource/options.cc: New
>   test.
>   * testsuite/20_util/unsynchronized_pool_resource/release.cc: New
>   test.
>
> The new tests being added here are pretty minimal, because we can't
> assume machines running the testsuite will be able to allocate large
> amounts of memory. I've tested it more thoroughly with much larger
> tests though, and will try to get some of them in shape for the
> testsuite/performance/20_util directory.
>
> Tested powerpc64le-linux. Committed to trunk.

two of the new tests FAIL on 32-bit targets (seen on
i386-pc-solaris2.11, but there are other reports as well):

+FAIL: 20_util/unsynchronized_pool_resource/allocate.cc (test for excess errors)
+UNRESOLVED: 20_util/unsynchronized_pool_resource/allocate.cc compilation 
failed to produce executable

Excess errors:
Undefined   first referenced
 symbol in file
std::pmr::unsynchronized_pool_resource::do_deallocate(void*, unsigned int, 
unsigned int) /var/tmp//ccUR6CSd.o
std::pmr::unsynchronized_pool_resource::do_allocate(unsigned int, unsigned int) 
/var/tmp//ccUR6CSd.o
ld: fatal: symbol referencing errors

+FAIL: 20_util/unsynchronized_pool_resource/release.cc (test for excess errors)
+UNRESOLVED: 20_util/unsynchronized_pool_resource/release.cc compilation failed 
to produce executable

Excess errors:
Undefined   first referenced
 symbol in file
std::pmr::unsynchronized_pool_resource::do_allocate(unsigned int, unsigned int) 
/var/tmp//ccrQoKEb.o
ld: fatal: symbol referencing errors

Rainer

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

Re: [PATCH] Fix PR87906

[Rainer Orth]

Hi Richard,

> This adds a workaround for LTO decl merging prevailing a
> non-ultimate origin decl, breaking invariants of the middle-end.
> In the future (GCC 10) I hope to have DIE references here so
> this will not be an issue there anymore.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
>
> Richard.
>
> From ff035da8314ea8e0889b99bb338e67dd5dae455b Mon Sep 17 00:00:00 2001
> From: Richard Guenther 
> Date: Wed, 7 Nov 2018 08:56:52 +0100
> Subject: [PATCH] fix-pr87906
>
> 2018-11-07  Richard Biener  
>
>   PR lto/87906
>   * tree-streamer-in.c (lto_input_ts_block_tree_pointers): Fixup
>   BLOCK_ABSTRACT_ORIGIN to be the ultimate origin.
>
>   * g++.dg/lto/pr87906_0.C: New testcase.
>   * g++.dg/lto/pr87906_1.C: Likewise.
>
> diff --git a/gcc/testsuite/g++.dg/lto/pr87906_0.C 
> b/gcc/testsuite/g++.dg/lto/pr87906_0.C
> new file mode 100644
> index 000..08e7ed3ba07
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/lto/pr87906_0.C
> @@ -0,0 +1,35 @@
> +// { dg-lto-do link }
> +// { dg-lto-options { { -O -fPIC -flto } } }
> +// { dg-extra-ld-options "-shared -nostdlib" }
> +
> +namespace com {
> +namespace sun {
> +namespace star {}
> +} // namespace sun
> +} // namespace com
> +namespace a = com::sun::star;
> +namespace com {
> +namespace sun {
> +namespace star {
> +namespace uno {

the new testcase FAILs on Solaris:

+FAIL: g++.dg/lto/pr87906 cp_lto_pr87906_0.o assemble,  -O -fPIC -flto 
+UNRESOLVED: g++.dg/lto/pr87906 cp_lto_pr87906_0.o-cp_lto_pr87906_1.o execute  
-O -fPIC -flto 
+UNRESOLVED: g++.dg/lto/pr87906 cp_lto_pr87906_0.o-cp_lto_pr87906_1.o link  -O 
-fPIC -flto 
+FAIL: g++.dg/lto/pr87906 cp_lto_pr87906_1.o assemble,  -O -fPIC -flto 

/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/lto/pr87906_0.C:6:11: error: 
expected identifier before numeric constant
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/lto/pr87906_0.C:6:11: error: 
expected unqualified-id before numeric constant

and several more due to the -Dsun default.  How about
sed -e 's/sun/moon/g' instead ;-)

Rainer

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

Re: [PATCH], Remove power9 fusion support

[Michael Meissner]

On Mon, Nov 05, 2018 at 04:09:23PM -0600, Segher Boessenkool wrote:
> Hi Mike,
> 
> On Fri, Nov 02, 2018 at 02:37:34PM -0400, Michael Meissner wrote:
> > This patch removes all of the so-called power9 fusion support for the GCC
> > compiler.  It leaves -mpower9-fusion as a deprecated switch in case somebody
> > used it (the switch was never documented).
> 
> As Mike Stump says, please just remove it.  The option was never documented,
> most likely zero people use it, and those that do shouldn't have and can
> easily adjust.
> 
> > [gcc]
> > 2018-11-02  Michael Meissner  
> > 
> > * config/rs6000/constraints.md (wF constraint): Only document the
> > wF constraint for power8 fusion.  Remove documentation for power9
> > fusion.
> 
> It wasn't documented as being anything for p8 before.  So that was wrong?

The switch wasn't documented.  In the constraint (which is what I'm changing
here), the constraint mentioned p9 fusion in the documentation string.

> > (rs6000_option_override_internal): Delete power9 fusion option
> > support.  If we do -mcpu=power8 -mtune=power9, turn off power8
> > fusion.
> 
> That doesn't sound right.  Either the -mcpu= or the -mtune= should turn
> it on, but neither should turn it off.  It sounds like you want -mtune
> to say whether fusion is enabled or not?  That sounds fine, but this
> should be implemented more directly (or more generically).

Ok, I will look at it.

> >  mpower9-fusion
> > -Target Undocumented Report Mask(P9_FUSION) Var(rs6000_isa_flags)
> > -Fuse certain operations together for better performance on power9.
> > +Target Undocumented Mask(P9_FUSION) Var(rs6000_isa_flags) Deprecated
> 
> Yeah just delete this please.

Ok.
 
> > @@ -1692,11 +1650,7 @@ (define_predicate "fusion_gpr_addis"
> >  return 0;
> >  
> >/* Power8 currently will only do the fusion if the top 11 bits of the 
> > addis
> > - value are all 1's or 0's.  Ignore this restriction if we are testing
> > - advanced fusion.  */
> > -  if (TARGET_P9_FUSION)
> > -return 1;
> > -
> > + value are all 1's or 0's.  */
> >return (IN_RANGE (value >> 16, -32, 31));
> >  })
> 
> I think this is top 12 bits equal, not 11, so [-16..15].

It is 11 bits, check section 12.1.12 in the  power8 book IV.

addis(SI) first 11 bits must be all 0’s or all 1’s

> > @@ -1762,14 +1718,13 @@ (define_predicate "fusion_gpr_mem_load"
> >  ;; Match a GPR load (lbz, lhz, lwz, ld) that uses a combined address in the
> >  ;; memory field with both the addis and the memory offset.  Sign extension
> >  ;; is not handled here, since lha and lwa are not fused.
> > -;; With P9 fusion, also match a fpr/vector load and float_extend
> >  (define_predicate "fusion_addis_mem_combo_load"
> >(match_code "mem,zero_extend,float_extend")
> 
> So float_extend should be deleted here?

Yes.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: Running the C++ library tests in the GCC testsuite

[Steve Ellcey]

On Wed, 2018-11-07 at 17:39 +, Joseph Myers wrote:
> External Email
> 
> On Wed, 7 Nov 2018, Steve Ellcey wrote:
> 
> > 
> > I have a question about the C++ library testsuite.  I built and
> > installed
> > a complete toolchain with GCC, binutils, and glibc in a directory
> > ($T) and
> > then I run the GCC testsuite with this command:
> > 
> > # cd to GCC object directory
> > make -j50 check RUNTESTFLAGS="--tool_opts  '--sysroot=$T -Wl,
> > --dynamic-linker=$T/lib/ld-linux-aarch64.so.1 -Wl,-rpath=$T/lib64
> > -Wl,-rpath=$T/usr/lib64'"
> I advise instead putting those options in your board file.
> 
> set_board_info ldflags "-Wl,whatever"
> 
> Note that you also need to make your board file set LOCPATH and GCONV_PATH
> appropriately (pointing the $sysroot/usr/lib/locale and
> $sysroot/usr/lib64/gconv respectively) for libstdc++ locale tests to work
> correctly with such a non-default glibc.  That would be code in your
> _load procedure in the board file (or in such a procedure in a
> file it loads via load_generic_config, etc.).

I copied unix.exp to unix-sysroot.exp and added this to it:

if {[info exists env(DEJAGNU_UNIX_SYSROOT_FLAGS)]} {
set_board_info ldflags "$env(DEJAGNU_UNIX_SYSROOT_FLAGS)"
}

I figured I would deal with LOCPATH and GCONV_PATH later.  When
I do a partial testrun, I don't get any failures but I do get some
new unresolved tests like this:

Download of ./2108-1.exe to unix-sysroot failed.
UNRESOLVED: gcc.dg/2108-1.c execution test

Have ever seen this error?

Steve Ellcey
sell...@cavium.com

[Bug c++/87921] [7/8/9 Regression] Incorrect error "storage size of [array] isn't known (when it is)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |7.4
Summary|Incorrect error "storage|[7/8/9 Regression]
   |size of [array] isn't known |Incorrect error "storage
   |(when it is)|size of [array] isn't known
   ||(when it is)

[Bug c++/87921] Incorrect error "storage size of [array] isn't known (when it is)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-07
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Probably started with r241143.

[Bug gcov-profile/87442] Add options to filter files we want to instrument for code coverage

[cdenizet at mozilla dot com]

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

--- Comment #9 from calixte  ---
(In reply to Martin Liška from comment #8)
> Ok, I've got a patch prototype and I hope I'll be able to sent it before
> the end of this stage1.
> 
> > The idea is to add two options to easily include/exclude some files from
> > being instrumented.
> > Here are two use cases:
> >  1) -coverage-exclude=/usr/include/*: typically we remove the data for such
> > files when post-processing the gcno/gcda so we don't need to instrument them
> > and so we could reduce the overhead due to instrumentation.
> >  2) -coverage-filter=.*/foo.cpp:.*/bar.cpp: here we want to only instrument
> > these two files (for example, to display code coverage data for files
> > appearing in a patch at review phase)
> 
> However, calixte can you please explain me difference in between those two
> options.
> More precisely, one is a white list and the second one is a black list. Will
> you
> mix these together or they will be used exclusively?

Few things:
 i) I use ';' as regex separator (to avoid issues under windows with C:\...)
 ii) if exclude is empty and filename is matching any of the regexes in filter
then instrument it.
 iii) if filter is empty and filename is not matching any of the regexes in
exclude then instrument it.
 iv) if both are not empty and filename is matching any of the regexes in
filter AND is not matching any of the regexes in exclude then instrument it. 

Few examples:
 i) exclude="^/usr/include/;^/usr/local/include/" => a file is instrumented if
and only if it isn't in /usr/include/ nor in /usr/local/include/
 ii) filter="^/home/foo/dev/.*\.cpp;^/home/foo/ved/.*\.cpp" => a file is
instrumented if and only if it's a cpp file somewhere under /home/foo/dev/ or
/home/foo/ved/
 iii) exclude="^/usr/include/.*$" and filter="^/usr/.*$" => a file is
instrumented if and only if it's somewhere under /usr/ but not under
/usr/include

My patch for llvm is here:
https://reviews.llvm.org/D52033

If you see something wrong or have idea to improve, please ping me.

[PATCH, arm] Backport -- Fix ICE during thunk generation with -mlong-calls

[Mihail Ionescu]

Hi All,

This is a backport from trunk for GCC 8 and 7.

SVN revision: r264595.

Regression tested on arm-none-eabi.


gcc/ChangeLog

2018-11-02  Mihail Ionescu  

Backport from mainiline
2018-09-26  Eric Botcazou  

* config/arm/arm.c (arm_reorg): Skip Thumb reorg pass for thunks.
(arm32_output_mi_thunk): Deal with long calls.

gcc/testsuite/ChangeLog

2018-11-02  Mihail Ionescu  

Backport from mainiline
2018-09-17  Eric Botcazou  

* g++.dg/other/thunk2a.C: New test.
* g++.dg/other/thunk2b.C: Likewise.


If everything is ok, could someone commit it on my behalf?

Best regards,
   Mihail
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 
2ece668219f3ca34883cd882431b0a3c390d4d3c..c68311e0fa192c350d03eb2dd37eca92ae7b3cfa
 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -17663,7 +17663,11 @@ arm_reorg (void)
 
   if (use_cmse)
 cmse_nonsecure_call_clear_caller_saved ();
-  if (TARGET_THUMB1)
+
+  /* We cannot run the Thumb passes for thunks because there is no CFG.  */
+  if (cfun->is_thunk)
+;
+  else if (TARGET_THUMB1)
 thumb1_reorg ();
   else if (TARGET_THUMB2)
 thumb2_reorg ();
@@ -26737,6 +26741,8 @@ static void
 arm32_output_mi_thunk (FILE *file, tree, HOST_WIDE_INT delta,
   HOST_WIDE_INT vcall_offset, tree function)
 {
+  const bool long_call_p = arm_is_long_call_p (function);
+
   /* On ARM, this_regno is R0 or R1 depending on
  whether the function returns an aggregate or not.
   */
@@ -26774,9 +26780,22 @@ arm32_output_mi_thunk (FILE *file, tree, HOST_WIDE_INT 
delta,
   TREE_USED (function) = 1;
 }
   rtx funexp = XEXP (DECL_RTL (function), 0);
+  if (long_call_p)
+{
+  emit_move_insn (temp, funexp);
+  funexp = temp;
+}
   funexp = gen_rtx_MEM (FUNCTION_MODE, funexp);
-  rtx_insn * insn = emit_call_insn (gen_sibcall (funexp, const0_rtx, 
NULL_RTX));
+  rtx_insn *insn = emit_call_insn (gen_sibcall (funexp, const0_rtx, NULL_RTX));
   SIBLING_CALL_P (insn) = 1;
+  emit_barrier ();
+
+  /* Indirect calls require a bit of fixup in PIC mode.  */
+  if (long_call_p)
+{
+  split_all_insns_noflow ();
+  arm_reorg ();
+}
 
   insn = get_insns ();
   shorten_branches (insn);
diff --git a/gcc/testsuite/g++.dg/other/thunk2a.C 
b/gcc/testsuite/g++.dg/other/thunk2a.C
new file mode 100644
index 
..8e5ebd4960df758fa77ff08b019e104870f36b45
--- /dev/null
+++ b/gcc/testsuite/g++.dg/other/thunk2a.C
@@ -0,0 +1,15 @@
+// { dg-do compile { target arm*-*-* } }
+// { dg-options "-mlong-calls -ffunction-sections" }
+
+class a {
+public:
+  virtual ~a();
+};
+
+class b : virtual a {};
+
+class c : b {
+  ~c();
+};
+
+c::~c() {}
diff --git a/gcc/testsuite/g++.dg/other/thunk2b.C 
b/gcc/testsuite/g++.dg/other/thunk2b.C
new file mode 100644
index 
..c8f4570923d8bde71547dd343de45edc0efeb2c7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/other/thunk2b.C
@@ -0,0 +1,16 @@
+// { dg-do compile { target arm*-*-* } }
+// { dg-options "-mlong-calls -ffunction-sections" }
+// { dg-additional-options "-fPIC" { target fpic } }
+
+class a {
+public:
+  virtual ~a();
+};
+
+class b : virtual a {};
+
+class c : b {
+  ~c();
+};
+
+c::~c() {}
diff --git a/gcc/testsuite/g++.dg/other/vthunk1.C 
b/gcc/testsuite/g++.dg/other/thunk1.C
similarity index 100%
rename from gcc/testsuite/g++.dg/other/vthunk1.C
rename to gcc/testsuite/g++.dg/other/thunk1.C

Re: [PATCH, ARM] Clean up arm backend using the @ construct for MD patterns

[Mihail Ionescu]

On 10/09/2018 09:52 AM, Ramana Radhakrishnan wrote:

On 09/10/2018 09:27, Mihail Ionescu wrote:

Hi all,

This patch removes some of the machine mode checks from the arm backend when
emitting instructions by using the '@' construct (Parameterized Names[2]). It
is based on the previous AArch64 patch[1].

[1]https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00673.html
[2]https://gcc.gnu.org/onlinedocs/gccint/Parameterized-Names.html#Parameterized-Names

Ran the tests on arm-none-eabi.


Thanks for the patch - It would be good to split this into 2 patches,
one for the cleanup with the permute instructions and the other for the
atomics. That makes life easier with reviews and it's logically grouped
as well.

Testing on just arm-none-eabi for the atomic_compare_and_swap changes
are not sufficient. I would prefer a bootstrap and test run on
arm-none-linux-gnueabihf with (--with-arch=armv7-a --with-fpu=vfpv3-d16
--with-float=hard as your configure options).

Alternatively I'd be happy if you could ensure that the libraries built
for arm-none-eabi show no difference in code generation for your change
? That will give us some more confidence that nothing else is wrong here.






gcc/ChangeLog:
2018-10-03  Mihail 
Ionescu

  * config/arm/arm.c (arm_expand_compare_and_swap): Use 
gen_atomic_compare_and_swap_1
  instead of explicit mode checks.


Simplify and call gen_atomic_compare_swap_1.


  (arm_evpc_neon_vuzp): Likewise gen_neon_vuzp_internal.


Simplify and call gen_neon_vuzp_internal..


  (arm_evpc_neon_vtrn): Likewise gen_neon_vtrn_internal.
  (arm_evpc_neon_vext): Likewise gen_neon_vext.
  (arm_evpc_neon_vzip): Likewise gen_neon_vzip_internal.
  (arm_evpc_neon_vrev): Replaced the function pointer and simplified 
the mode
  checks.


and so on...


  * config/arm/arm.md (neon_vext)
  (neon_vrev64, neon_vrev32)
  (neon_vrev16, neon_vtrn_internal)
  (neon_vzip_internal, neon_vuzp_internal): Add an 
'@'character
  before the pattern name.


Separate all pattern names across lines with ,'s .


  * config/arm/sync.md:
  (atomic_compare_and_swap_1)
  (atomic_compare_and_swap_1): Likewise.


Same as above.



If everything is ok for trunk, can someone commit it on my behalf?

Best regards,
  Mihail


diff.txt

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 
8810df53aa34798b5e3e1eb3a870101d530702e4..51441efa934f5f2a5963750fcd7e077951406d5a
 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -28539,8 +28539,7 @@ void
   arm_expand_compare_and_swap (rtx operands[])
   {
 rtx bval, bdst, rval, mem, oldval, newval, is_weak, mod_s, mod_f, x;
-  machine_mode mode;
-  rtx (*gen) (rtx, rtx, rtx, rtx, rtx, rtx, rtx, rtx);
+  machine_mode mode, arch_mode;


s/arch_mode/compare_mode

The mode here is the mode for the comparison , whether we use SImode as
for Thumb1 or a CC_Zmode in !TARGET_THUMB1 cases. arch_mode doesn't tell
me much on reading the name.

   
 bval = operands[0];

 rval = operands[1];
@@ -28588,32 +28587,13 @@ arm_expand_compare_and_swap (rtx operands[])
   }
   
 if (TARGET_THUMB1)

-{
-  switch (mode)
-   {
-   case E_QImode: gen = gen_atomic_compare_and_swapt1qi_1; break;
-   case E_HImode: gen = gen_atomic_compare_and_swapt1hi_1; break;
-   case E_SImode: gen = gen_atomic_compare_and_swapt1si_1; break;
-   case E_DImode: gen = gen_atomic_compare_and_swapt1di_1; break;
-   default:
- gcc_unreachable ();
-   }
-}
+arch_mode = E_SImode;
 else
-{
-  switch (mode)
-   {
-   case E_QImode: gen = gen_atomic_compare_and_swap32qi_1; break;
-   case E_HImode: gen = gen_atomic_compare_and_swap32hi_1; break;
-   case E_SImode: gen = gen_atomic_compare_and_swap32si_1; break;
-   case E_DImode: gen = gen_atomic_compare_and_swap32di_1; break;
-   default:
- gcc_unreachable ();
-   }
-}
+arch_mode = CC_Zmode;
   
 bdst = TARGET_THUMB1 ? bval : gen_rtx_REG (CC_Zmode, CC_REGNUM);

-  emit_insn (gen (bdst, rval, mem, oldval, newval, is_weak, mod_s, mod_f));
+  emit_insn (gen_atomic_compare_and_swap_1 (arch_mode, mode, bdst, rval, mem, 
oldval,
+  newval, is_weak, mod_s, mod_f));
   
 if (mode == QImode || mode == HImode)

   emit_move_insn (operands[1], gen_lowpart (mode, rval));
@@ -28979,7 +28959,6 @@ arm_evpc_neon_vuzp (struct expand_vec_perm_d *d)
   {
 unsigned int i, odd, mask, nelt = d->perm.length ();
 rtx out0, out1, in0, in1;
-  rtx (*gen)(rtx, rtx, rtx, rtx);
 int first_elem;
 int swap_nelt;
   
@@ -29013,22 +28992,6 @@ arm_evpc_neon_vuzp (struct expand_vec_perm_d *d)

 if (d->testing_p)
   return true;
   
-  switch (d->vmode)

-{
-case E_V16QImode: gen = gen_neon_vuzpv16qi_internal; break;
-case E_V8QImode:  

Re: [RFC][PATCH LRA] WIP patch to fix one part of PR87507

[Peter Bergner]

On 11/7/18 11:36 AM, Jeff Law wrote:
> I was referring to a more fundamental check in the IL checkers.

Yes, I understood that.  I was just replying to Segher's specific issue
with this code.  I do plan on looking at adding IL verifier checks for
subregs of subregs like you requested.


> Segher may have been referring to this specific code.  This is obviously
> safe to do as well.
> 
> OK with this change.

He was.  Thanks, I'll do one more bootstrap and then commit.  Thanks!

Peter

[Bug fortran/87923] New: ICE in gfc_widechar_to_char, at fortran/scanner.c:198

[gs...@t-online.de]

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

Bug ID: 87923
   Summary: ICE in gfc_widechar_to_char, at fortran/scanner.c:198
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With option -fdec and versions 7 to 9 :


$ cat z1.f90
program p
   open (1, carriagecontrol=char(1000,4))
   open (2, share=char(1000,4))
end


$ gfortran-9-20181104 -c z1.f90 -fdec
f951: internal compiler error: in gfc_widechar_to_char, at
fortran/scanner.c:198
0x694556 gfc_widechar_to_char(unsigned int const*, int)
../../gcc/fortran/scanner.c:198
0x638784 compare_to_allowed_values
../../gcc/fortran/io.c:2091
0x63dcd0 gfc_match_open()
../../gcc/fortran/io.c:2276
0x66a3c1 match_word
../../gcc/fortran/parse.c:65
0x66e335 decode_statement
../../gcc/fortran/parse.c:531
0x66e72a next_free
../../gcc/fortran/parse.c:1234
0x66e72a next_statement
../../gcc/fortran/parse.c:1466
0x670a94 parse_spec
../../gcc/fortran/parse.c:3674
0x672807 parse_progunit
../../gcc/fortran/parse.c:5671
0x673e89 gfc_parse_file()
../../gcc/fortran/parse.c:6211
0x6bc03f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

Re: Running the C++ library tests in the GCC testsuite

[Joseph Myers]

On Wed, 7 Nov 2018, Steve Ellcey wrote:

> I have a question about the C++ library testsuite.  I built and installed
> a complete toolchain with GCC, binutils, and glibc in a directory ($T) and
> then I run the GCC testsuite with this command:
> 
> # cd to GCC object directory
> make -j50 check RUNTESTFLAGS="--tool_opts  '--sysroot=$T 
> -Wl,--dynamic-linker=$T/lib/ld-linux-aarch64.so.1 -Wl,-rpath=$T/lib64 
> -Wl,-rpath=$T/usr/lib64'"

I advise instead putting those options in your board file.

set_board_info ldflags "-Wl,whatever"

Note that you also need to make your board file set LOCPATH and GCONV_PATH 
appropriately (pointing the $sysroot/usr/lib/locale and 
$sysroot/usr/lib64/gconv respectively) for libstdc++ locale tests to work 
correctly with such a non-default glibc.  That would be code in your 
_load procedure in the board file (or in such a procedure in a 
file it loads via load_generic_config, etc.).

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

[Bug fortran/87922] New: ICE in gfc_wide_strlen, at fortran/scanner.c:142

[gs...@t-online.de]

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

Bug ID: 87922
   Summary: ICE in gfc_wide_strlen, at fortran/scanner.c:142
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With a non-scalar-default-char-constant-expr since at least gfortran-5 :


$ cat z1.f90
program p
   read (1, asynchronous=['no'])
   read (1, asynchronous=[character::])
end

$ cat z2.f90
program p
   write (1, asynchronous=['no'])
   write (1, asynchronous=[character::])
end


$ gfortran-9-20181104 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb205df crash_signal
../../gcc/toplev.c:325
0x694450 gfc_wide_strlen(unsigned int const*)
../../gcc/fortran/scanner.c:142
0x638587 compare_to_allowed_values
../../gcc/fortran/io.c:2008
0x63b7ca check_io_constraints
../../gcc/fortran/io.c:3797
0x63b7ca match_io
../../gcc/fortran/io.c:4301
0x66a3c1 match_word
../../gcc/fortran/parse.c:65
0x66e1a0 decode_statement
../../gcc/fortran/parse.c:549
0x66e72a next_free
../../gcc/fortran/parse.c:1234
0x66e72a next_statement
../../gcc/fortran/parse.c:1466
0x670a94 parse_spec
../../gcc/fortran/parse.c:3674
0x672807 parse_progunit
../../gcc/fortran/parse.c:5671
0x673e89 gfc_parse_file()
../../gcc/fortran/parse.c:6211
0x6bc03f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

Re: [RFC][PATCH LRA] WIP patch to fix one part of PR87507

[Jeff Law]

On 11/7/18 9:29 AM, Peter Bergner wrote:
> On 11/6/18 6:14 PM, Segher Boessenkool wrote:
>> Or more general, that what is inside the subreg is a reg, because the
>> code does rely on that.
> 
> I think you mean to beef up the following from:
> 
> + if (HARD_REGISTER_P (nop_reg)
> + && REG_USERVAR_P (nop_reg)
> + && HARD_REGISTER_P (m_reg)
> + && REG_USERVAR_P (m_reg))
> +   break;
> 
> to:
> 
> +   if (REG_P (nop_reg)
> +   && HARD_REGISTER_P (nop_reg)
> +   && REG_USERVAR_P (nop_reg)
> +   && REG_P (m_reg)
> +   && HARD_REGISTER_P (m_reg)
> +   && REG_USERVAR_P (m_reg))
> + break;
> 
> ...correct?  I can add that.  I don't think we need to modify
> the other patch hunks, since we know operand_reg[x] is already
> a reg.
I was referring to a more fundamental check in the IL checkers.  Segher
may have been referring to this specific code.  This is obviously safe
to do as well.

OK with this change.
jeff

[Bug fortran/69654] ICE in gfc_trans_structure_assign

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #6 from G. Steinmetz  ---

Update, reduced a bit :


$ cat z1.f90
module m
   type t
  class(*), pointer :: z => null()
   end type
end
program p
contains
   subroutine s1
  use m
  type(t) :: x
  call s2(x)
   end
   subroutine s2(x)
  use m
  type(t) :: x
   end
end


$ gfortran-9-20181104 -c z1.f90
z1.f90:12:0:

   12 |end
  |
internal compiler error: Segmentation fault
0xb205df crash_signal
../../gcc/toplev.c:325
0x6f3735 gfc_trans_structure_assign(tree_node*, gfc_expr*, bool, bool)
../../gcc/fortran/trans-expr.c:7814
0x6f3282 gfc_trans_subcomponent_assign
../../gcc/fortran/trans-expr.c:7659
0x6f375a gfc_trans_structure_assign(tree_node*, gfc_expr*, bool, bool)
../../gcc/fortran/trans-expr.c:7824
0x6edf0f gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc/fortran/trans-expr.c:7891
0x6ee14c gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8059
0x6fc779 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10248
0x6dd90d gfc_init_default_dt(gfc_symbol*, stmtblock_t*, bool)
../../gcc/fortran/trans-decl.c:4067
0x6e4f30 gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*)
../../gcc/fortran/trans-decl.c:4792
0x6e6ef8 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6614
0x6e6c14 gfc_generate_contained_functions
../../gcc/fortran/trans-decl.c:5524
0x6e6c14 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6441
0x6740a6 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x6740a6 gfc_parse_file()
../../gcc/fortran/parse.c:6328
0x6bc03f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204


---

The ICE also goes away when all "use m" are moved to top level :

$ cat z7.f90
module m
   type t
  class(*), pointer :: z => null()
   end type
end
program p
   use m
   call s1
contains
   subroutine s1
  type(t) :: x
  call s2(x)
   end
   subroutine s2(x)
  type(t) :: x
   end
end

Running the C++ library tests in the GCC testsuite

[Steve Ellcey]

I have a question about the C++ library testsuite.  I built and installed
a complete toolchain with GCC, binutils, and glibc in a directory ($T) and
then I run the GCC testsuite with this command:

# cd to GCC object directory
make -j50 check RUNTESTFLAGS="--tool_opts  '--sysroot=$T 
-Wl,--dynamic-linker=$T/lib/ld-linux-aarch64.so.1 -Wl,-rpath=$T/lib64 
-Wl,-rpath=$T/usr/lib64'"

When I look at the gcc.log, g++.log, gfortran.log files I see the -Wl options
that I specified being used when the tests are compiled, but when I look at
the C++ library test log file
(aarch64-linux-gnu/libstdc++-v3/testsuite/libstdc++.log) I do not see
the --rpath or other flags getting used.  Is this expected?  I have a
few tests that fail because of this and die with:

./check_nan.exe: /lib/aarch64-linux-gnu/libm.so.6: version `GLIBC_2.27' not 
found (required by ./check_nan.exe)

If I rerun by hand and add the --rpath, etc. flags the test works but I
am not sure why the test harness did not add them itself.

Steve Ellcey
sell...@cavium.com

[Bug c++/87921] New: Incorrect error "storage size of [array] isn't known (when it is)

[cuzdav at gmail dot com]

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

Bug ID: 87921
   Summary: Incorrect error "storage size of [array] isn't known
(when it is)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

I'm getting an error for what I believe to be valid code.  Here's a complete,
minimal example to reproduce it:

// 
template
struct X {
static constexpr long Ary[] = { 1L };
long foo() { return Ary[0]; }
};

void f() {
class L{};
X foo{};
}
// 
https://godbolt.org/z/2tGwxo

#1 with x86-64 gcc (trunk)
:3:27: error: storage size of 'X::Ary' isn't known
3  static constexpr long Ary[] = { 1L };
 ^~~
Clearly the size of the array should be known.

- locally, on both mac and linux I see same results
- in g++6.3, C++17 mode it compiles
- in 7.3 and all versions up through 8.2 and the trunk, in C++ 17 mode it does
not compile.
- in clang++, it compiles.
- moving the function-local class L to file-scope fixes it.
- moving the array outside of the template class fixes it.
- explicitly providing a size to the array declaration fixes it.

Re: [PATCH] Update soft-fp from glibc.

[Joseph Myers]

This patch is OK.

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

Re: Cortex M0 Floating Point Library

[Daniel Engel]

On Tue, Nov 6, 2018, at 9:28 PM, Joel Sherrill wrote:
> 
> On Tue, Nov 6, 2018, 10:32 PM Daniel Engel > Hi, 
>>  
>>  Over the past couple of years, I have hand-assembled a new floating point 
>> library for the ARM Cortex M0 architecture.  I know the M0 is not generally 
>> regarded as a number-crunching machine, but I felt it deserved at least some 
>> of the attention that has previously been bestowed on the AVR architecture.  
>> As this work has been incidental to my employer's line of business, they 
>> have tentatively agreed to assign the copyright and facilitate a release of 
>> this library as open source.  
> 
> This sounds like a nice body of work. Congratukations.
> 
> Does paranoia pass? 

I haven't run paranoia, as it doesn't claim to be a comprehensive test suite.  

Per the allowance of the AEABI, my library only supports round-to-nearest, ties 
to even.  For the basic operations, I tested the applicable cases of the UCB 
and ieeeCC754 , plus estensive random testing with the Berkeley 
TestFloat/SoftFloat implementation.  All of these tests passed in an STM32F0 
target environment.  




For other operations not covered by UCB or ieeeCC754, I developed my own cases 
using the C# floating point library for the reference operations.  Typically, I 
tested 50 - 500 cases per function, covering both general and special case 
arguments.  All functions have complete, tested support for INF, NAN, +/-0, and 
subnormals.  On-target testing was typically limited to about 64kb per group of 
test cases (the flash memory of the STM32F0). 

Additionally, while an assembly language implementation is typically difficult 
enough by itself, the logf() and sincosf() functions embody somewhat novel 
algorithms (as far as I can tell).  For these, I proved correctness with an 
equivalent C implementation and exhaustive simulation on a PC.   The simulation 
compared the result for each argument with an equivalent double precision 
calculation using the standard C library where possible, and the ttmath library 
otherwise.  
 


>>  * Add everything into the base libgcc, 
>>  * Add everything into libm (newlib?) and rely on link order to supersede 
>> libgcc, 
> 
> This will almost certainly break at some point, for someone, and be hard to 
> even figure out it happened because the code will work but just be bigger or 
> slower.
> 
>> * Split the implementation with some magic to ensure that libm functions 
>> only link in the presence of the correct libgcc,
> 
> I think this is the proper solution. It just puts better implementations in 
> the place the infrastructure already supports having a target specific option.

There would be some difficult cases in splitting the library, and I haven't yet 
quantified all the costs.  One problem point might be tanf(), which relies on a 
routine shared with divsf3() to calculate the sin/cos ratio with >24 bits of 
precision.  Splitting the library would require exposing such internal 
routines, which don't naturally conform to any procedure call conventions.  
Also, loss of control of linking order would require all short branches in the 
libm section to be replaced with long branches.  This particularly impacts the 
exception handling in almost every function.  

> 
>> * Establish an independent library specific to the Cortex M0 architecture, or
> 
> This is likely to get you the smallest number of users.  People have to find 
> it and then integrate it on their own. Don't make it hard for folks to find 
> and use your work.

Agreed.  Plus, I don't have the resources or experience to be a long-term 
library maintainer.  It's not as if basic math functions require constant 
maintenance and updating.  The original Cortex M3 library by Nicolas Pitre has 
only seen a small handful of changes in past decade.  

> 
>> * Something else entirely...
>>  
>>  If there is any interest in incorporating this work into GCC, please 
>> advise.  
> 
> I think so but I am just one voice from the RTEMS community. But I think any 
> M0 user would be pleased.
> 
> --joel
>> 
>> Thanks,
>>  Daniel Engel

Re: [PATCH v2] MIPS: Default to --with-llsc for the R5900 Linux target as well

[Fredrik Noring]

Hello global GCC reviewers,

Would it be possible to apply the reviewed patch below?

Thank you,
Fredrik

On Fri, Oct 19, 2018 at 08:33:33PM +0200, Fredrik Noring wrote:
> The Linux kernel requires and emulates LL and SC for the R5900 too.  The
> special --without-llsc default for the R5900 is therefore not applicable
> in that case.
> 
> Reviewed-by: Maciej W. Rozycki 
> ---
> Changes in v2:
> - Double spacing instead of single spacing in commit message
> 
> ---
>  gcc/config.gcc | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 720e6a7373d..68c34b16123 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -3711,14 +3711,14 @@ fi
>  # Infer a default setting for --with-llsc.
>  if test x$with_llsc = x; then
>case ${target} in
> -mips64r5900-*-* | mips64r5900el-*-* | mipsr5900-*-* | mipsr5900el-*-*)
> -  # The R5900 doesn't support LL(D) and SC(D).
> -  with_llsc=no
> -  ;;
>  mips*-*-linux*)
># The kernel emulates LL and SC where necessary.
>with_llsc=yes
>;;
> +mips64r5900-*-* | mips64r5900el-*-* | mipsr5900-*-* | mipsr5900el-*-*)
> +  # The R5900 doesn't support LL(D) and SC(D).
> +  with_llsc=no
> +  ;;
>esac
>  fi
>  
> -- 
> 2.18.1
> 

[Bug c++/87904] [9 Regression] ICE in lookup_mark, at cp/tree.c:2322 since r265679

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Nathan Sidwell  ---
Fixed r265879.

[Bug c++/87904] [9 Regression] ICE in lookup_mark, at cp/tree.c:2322 since r265679

[nathan at gcc dot gnu.org]

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

--- Comment #1 from Nathan Sidwell  ---
Author: nathan
Date: Wed Nov  7 16:28:46 2018
New Revision: 265879

URL: https://gcc.gnu.org/viewcvs?rev=265879=gcc=rev
Log:
[PR C++/87904] lookup ICE

https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00468.html
PR c++/87904
* cp-tree.h (struct tree_overload): Fix comment.
* tree.c (ovl_iterator::reveal_node): Propagate OVL_DEDUP_P.

PR c++/87904
* g++.dg/lookup/pr87904.C: New.

Added:
trunk/gcc/testsuite/g++.dg/lookup/pr87904.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

Re: [RFC][PATCH LRA] WIP patch to fix one part of PR87507

[Peter Bergner]

On 11/6/18 6:14 PM, Segher Boessenkool wrote:
> Or more general, that what is inside the subreg is a reg, because the
> code does rely on that.

I think you mean to beef up the following from:

+   if (HARD_REGISTER_P (nop_reg)
+   && REG_USERVAR_P (nop_reg)
+   && HARD_REGISTER_P (m_reg)
+   && REG_USERVAR_P (m_reg))
+ break;

to:

+   if (REG_P (nop_reg)
+   && HARD_REGISTER_P (nop_reg)
+   && REG_USERVAR_P (nop_reg)
+   && REG_P (m_reg)
+   && HARD_REGISTER_P (m_reg)
+   && REG_USERVAR_P (m_reg))
+ break;

...correct?  I can add that.  I don't think we need to modify
the other patch hunks, since we know operand_reg[x] is already
a reg.

Peter

[Bug ipa/86395] add support of -fopt-info-inline in inliner

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2018-11/msg00463.ht
   ||ml

--- Comment #4 from David Malcolm  ---
Candidate patches: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00463.html

[PATCH] MIPS: Add `-mfix-r5900' option for the R5900 short loop erratum

[Fredrik Noring]

The short loop bug under certain conditions causes loops to
execute only once or twice, due to a hardware bug in the R5900 chip.

`-march=r5900' already enables the R5900 short loop workaround.
However, the R5900 ISA and most other MIPS ISAs are mutually
exclusive since R5900-specific instructions are generated as well.

The `-mfix-r5900' option can be used in combination with e.g.
`-mips2' or `-mips3' to generate generic MIPS binaries that also
work with the R5900 target.  The workaround is implemented by GAS
rather than by GCC.

The following small `shortloop.c' file has been used as a test
with GCC 8.2.0:

void shortloop(void)
{
__asm__ __volatile__ (
"   li $3, 300\n"
"loop:\n"
"   addi $3, -1\n"
"   addi $4, -1\n"
"   bne $3, $0, loop\n"
"   li $4, 3\n"
::);
}

The following six combinations have been tested:

% mipsr5900el-unknown-linux-gnu-gcc -O1 -c shortloop.c
% mipsr5900el-unknown-linux-gnu-gcc -O1 -c shortloop.c -mfix-r5900
% mipsr5900el-unknown-linux-gnu-gcc -O1 -c shortloop.c -mno-fix-r5900

% mipsr4000el-unknown-linux-gnu-gcc -O1 -c shortloop.c
% mipsr4000el-unknown-linux-gnu-gcc -O1 -c shortloop.c -mfix-r5900
% mipsr4000el-unknown-linux-gnu-gcc -O1 -c shortloop.c -mno-fix-r5900

The R5900 short loop erratum is corrected in exactly three cases:

1. for the target `mipsr5900el' by default;

2. for the target `mipsr5900el' with `-mfix-r5900';

3. for any other MIPS target (e.g. `mipsr4000el') with `-mfix-r5900'.

In all other cases the correction is not made.

* gcc/config/mips/mips.c (mips_reorg_process_insns)
  (mips_option_override): Default to working around R5900
  errata only if the processor was selected explicitly.
* gcc/config/mips/mips.h: Declare `mfix-r5900' and
  `mno-fix-r5900'.
* gcc/config/mips/mips.opt: Define MASK_FIX_R5900.
* gcc/doc/invoke.texi: Document the R5900, `mfix-r5900' and
  `mno-fix-r5900'.
---
 gcc/config/mips/mips.c   | 14 ++
 gcc/config/mips/mips.h   |  1 +
 gcc/config/mips/mips.opt |  4 
 gcc/doc/invoke.texi  | 14 +-
 4 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index ea2fae1d6db..5763ce21427 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -18881,13 +18881,13 @@ mips_reorg_process_insns (void)
   if (crtl->profile)
 cfun->machine->all_noreorder_p = false;
 
-  /* Code compiled with -mfix-vr4120, -mfix-rm7000 or -mfix-24k can't be
- all noreorder because we rely on the assembler to work around some
- errata.  The R5900 too has several bugs.  */
+  /* Code compiled with -mfix-vr4120, -mfix-r5900, -mfix-rm7000 or
+ -mfix-24k can't be all noreorder because we rely on the assembler
+ to work around some errata.  The R5900 target has several bugs.  */
   if (TARGET_FIX_VR4120
   || TARGET_FIX_RM7000
   || TARGET_FIX_24K
-  || TARGET_MIPS5900)
+  || TARGET_FIX_R5900)
 cfun->machine->all_noreorder_p = false;
 
   /* The same is true for -mfix-vr4130 if we might generate MFLO or
@@ -20244,6 +20244,12 @@ mips_option_override (void)
   && strcmp (mips_arch_info->name, "r4400") == 0)
 target_flags |= MASK_FIX_R4400;
 
+  /* Default to working around R5900 errata only if the processor
+ was selected explicitly.  */
+  if ((target_flags_explicit & MASK_FIX_R5900) == 0
+  && strcmp (mips_arch_info->name, "r5900") == 0)
+target_flags |= MASK_FIX_R5900;
+
   /* Default to working around R1 errata only if the processor
  was selected explicitly.  */
   if ((target_flags_explicit & MASK_FIX_R1) == 0
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index 32a88edc910..7dd19fc6f2d 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -1363,6 +1363,7 @@ struct mips_cpu_info {
 %{mmsa} %{mno-msa} \
 %{msmartmips} %{mno-smartmips} \
 %{mmt} %{mno-mt} \
+%{mfix-r5900} %{mno-fix-r5900} \
 %{mfix-rm7000} %{mno-fix-rm7000} \
 %{mfix-vr4120} %{mfix-vr4130} \
 %{mfix-24k} \
diff --git a/gcc/config/mips/mips.opt b/gcc/config/mips/mips.opt
index 5a9f255fe20..427ac4913fc 100644
--- a/gcc/config/mips/mips.opt
+++ b/gcc/config/mips/mips.opt
@@ -165,6 +165,10 @@ mfix-r4400
 Target Report Mask(FIX_R4400)
 Work around certain R4400 errata.
 
+mfix-r5900
+Target Report Mask(FIX_R5900)
+Work around the R5900 short loop erratum.
+
 mfix-rm7000
 Target Report Var(TARGET_FIX_RM7000)
 Work around certain RM7000 errata.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index e290128f535..c9846d96304 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -939,6 +939,7 @@ Objective-C and Objective-C++ Dialects}.
 -mmad  -mno-mad  -mimadd  -mno-imadd  -mfused-madd  -mno-fused-madd  -nocpp 
@gol
 -mfix-24k  -mno-fix-24k @gol
 -mfix-r4000  -mno-fix-r4000  -mfix-r4400  -mno-fix-r4400 @gol
+-mfix-r5900  -mno-fix-r5900 @gol
 -mfix-r1