[Bug c/71602] [6/7 regression] ICE on __builtin_va_arg in build_va_arg, at c-family/c-common.c:5810

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #2 from vries at gcc dot gnu.org ---
It seems the test-case is illegal. Clang gives an error:
...
$ clang test.c -S
test.c:5:20: error: first argument to 'va_arg' is of type '__builtin_va_list *'
and not 'va_list'
  __builtin_va_arg(pap, int); 
   ^~~
1 error generated.
...

We should give an error instead of ICE-ing.

[Bug c++/71590] G++ template function initialize with wrong type

[markowitz73 at gmail dot com]

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

--- Comment #4 from gliu  ---
(In reply to Martin Sebor from comment #3)
> There is a (subtle) difference between the initialization in "std::string s
> = a;" and the assignment in "std::string s; s = a;"  When valid, the
> initialization invokes a constructor (possibly two), while the assignment
> invokes the assignment operator.  But since std::string doesn't have a
> constructor that takes just a char (or int) argument the initialization is
> invalid.  (As mentioned, it does have an assignment operator that takes a
> char.)
> 
> (For completeness' sake, in C++ 11, std::string has a constructor that takes
> a std::initializer_list, and so with G++ a string object can be constructed
> like so: "std::string s = { a };"  But this is a G++ extension and not a
> valid C++ 11 construct so G++ will give a warning: narrowing conversion of
> ‘a’ from ‘int’ to ‘char’ inside { }.

understood, thanks for your reply.

[Bug c++/71590] G++ template function initialize with wrong type

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
There is a (subtle) difference between the initialization in "std::string s =
a;" and the assignment in "std::string s; s = a;"  When valid, the
initialization invokes a constructor (possibly two), while the assignment
invokes the assignment operator.  But since std::string doesn't have a
constructor that takes just a char (or int) argument the initialization is
invalid.  (As mentioned, it does have an assignment operator that takes a
char.)

(For completeness' sake, in C++ 11, std::string has a constructor that takes a
std::initializer_list, and so with G++ a string object can be constructed like
so: "std::string s = { a };"  But this is a G++ extension and not a valid C++
11 construct so G++ will give a warning: narrowing conversion of ‘a’ from ‘int’
to ‘char’ inside { }.

[Bug c/71602] [6/7 regression] ICE on __builtin_va_arg in build_va_arg, at c-family/c-common.c:5810

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-21
 CC||msebor at gcc dot gnu.org,
   ||tom at codesourcery dot com
Summary|ICE on valid code on|[6/7 regression] ICE on
   |x86_64-linux-gnu (in|__builtin_va_arg in
   |build_va_arg, at|build_va_arg, at
   |c-family/c-common.c:5810)   |c-family/c-common.c:5810
 Ever confirmed|0   |1
  Known to fail||6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
ICE confirmed in 6.1.0 and 7.0 with r223286 as the cause of the ICE:

r223286 | vries | 2015-05-18 04:19:29 -0400 (Mon, 18 May 2015) | 17 lines

Move array-type va_list handling to build_va_arg

2015-05-18  Tom de Vries  

* gimplify.c (gimplify_modify_expr): Remove do_deref handling.
(gimplify_va_arg_expr): Remove do_deref handling.  Remove adding of
address operator to va_list operand.
* tree-stdarg.c (expand_ifn_va_arg_1): Do deref of va_list operand
unconditionally.
* config/i386/i386.c (ix86_gimplify_va_arg): Remove deref on va_list
operand.
* config/rs6000/rs6000.c (rs6000_gimplify_va_arg): Same.
* config/s390/s390.c (s390_gimplify_va_arg): Same.
* config/spu/spu.c (spu_gimplify_va_arg_expr): Same.

* c-common.c (build_va_arg_1): New function.
(build_va_arg): Add address operator to va_list operand if necessary.

[Bug c++/71590] G++ template function initialize with wrong type

[markowitz73 at gmail dot com]

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

--- Comment #2 from gliu  ---
(In reply to Martin Sebor from comment #1)
> It is true that there is no std::string::operator=(int) but the assignment
> in 'x = a' resolves to std::string::operator(char).  The program is valid.

Thanks for explainatation. But I got confused because I got a compile error
when I try:
int a = 1;
std::string s = a;

error: invalid conversion from ‘int’ to ‘const char*’
error:   initializing argument 1 of ‘std::basic_string<_CharT, _Traits,
_Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char,
_Traits = std::char_traits, _Alloc = std::allocator]’

Is that func treated as func instead of func ?

Re: [PING] [PATCH] Fix asm X constraint (PR inline-asm/59155)

[Bernd Edlinger]

On 06/21/16 00:06, Jeff Law wrote:
> On 06/09/2016 10:45 AM, Jakub Jelinek wrote:
>> On Thu, Jun 09, 2016 at 06:43:04PM +0200, Jakub Jelinek wrote:
>>> Yes, I'm all in favor in disabling X constraint for inline asm.
>>> Especially if people actually try to print it as well, rather than
>>> make it
>>> unused.  That is a sure path to ICEs.
>>
>> Though, on the other side, even our documentation mentions
>> asm volatile ("mtfsf 255,%1" : "=X"(sum): "f"(fpenv));
>> So perhaps we need to error just in case such an argument is printed?
> Are you thinking to scan the output string for % for the appropriate
> ?  That shouldn't be too hard.  But that's not sufficient to address
> the problem Bernd is trying to tackle AFAICT.

Correct.

And furthermore, the use case with matching X input & output that Marc
wanted to use, seems to be a valid one.  Because "+X" allows more
registers than "+g" or "+r", it should create less register pressure.
And although it is probably unpredictable if a register of the
class "ALL_REGISTERS" will work for an assembler instruction, it is
still interesting to print it in an assembler comment.


Bernd.

[PATCH,rs6000] Add support for HAVE_AS_POWER9

[Kelvin Nilsen]

A "#define HAVE_AS_POWER9" or "#undef HAVE_AS_POWER9" preprocessor
directive is emitted into the $GCC_BUILD/gcc/auto-host.h file at
configuration time, depending on whether the available assembler
supports the Power9 instruction set.  This patch arranges to disable
Power9-specific compiler features if HAVE_AS_POWER9 is not defined.

The patch includes code to modify the behavior of the compiler along with
directives to adjust the treatment of certain dejagnu tests.  Disable
the Power9-specific tests on aix because of known incompatibilities.

This patch has bootstrapped and regression tested on
powerpc64le-unknown-linux-gnu with both a configuration that has a
Power9 assembler and one that does not have a Power9 assembler.  In
both cases, there were no regressions.  Is this ok for the trunk?  Is
this patch ok for gcc-6 after a few days of burn-in on the trunk?

Thanks.

gcc/ChangeLog:

2016-06-20  Kelvin Nilsen  

* config/rs6000/rs6000.h: Add conditional preprocessing directives
to disable Power9-specific compiler features if HAVE_AS_POWER9 is
not defined.

gcc/testsuite/ChangeLog:

2016-06-20  Kelvin Nilsen  

* gcc.target/powerpc/darn-0.c: Add dejagnu directives to disable
test if effective-target is not powerpc_p9vector_ok, or if a -mcpu
override other than -mcpu=power9 command-line option is specified,
or if the target operating system is aix.
* gcc.target/powerpc/darn-1.c: Likewise.
* gcc.target/powerpc/darn-2.c: Likewise.
* gcc.target/powerpc/vslv-0.c: Add dejagnu directives to disable
test if effective-target is not powerpc_p9vector_ok or if the
target operating system is not defined.
* gcc.target/powerpc/vslv-1.c: Likewise.
* gcc.target/powerpc/vsrv-0.c: Likewise.
* gcc.target/powerpc/vsrv-1.c: Likewise.

Index: gcc/config/rs6000/rs6000.h
===
--- gcc/config/rs6000/rs6000.h  (revision 237530)
+++ gcc/config/rs6000/rs6000.h  (working copy)
@@ -302,6 +302,26 @@ extern const char *host_detect_local_cpu (int argc
 #define TARGET_P8_VECTOR 0
 #endif
 
+/* Define the ISA 3.0 flags as 0 if the target assembler does not support
+   Power9 instructions.  Allow -mpower9-fusion, since it does not add new
+   instructions.  Allow -misel, since it predates ISA 3.0 and does
+   not require any Power9 features.  */
+
+#ifndef HAVE_AS_POWER9
+#undef  TARGET_FLOAT128_HW
+#undef  TARGET_MODULO
+#undef  TARGET_P9_VECTOR
+#undef  TARGET_P9_MINMAX
+#undef  TARGET_P9_DFORM_SCALAR
+#undef  TARGET_P9_DFORM_VECTOR
+#define TARGET_FLOAT128_HW 0
+#define TARGET_MODULO 0
+#define TARGET_P9_VECTOR 0
+#define TARGET_P9_MINMAX 0
+#define TARGET_P9_DFORM_SCALAR 0
+#define TARGET_P9_DFORM_VECTOR 0
+#endif
+
 /* Define TARGET_LWSYNC_INSTRUCTION if the assembler knows about lwsync.  If
not, generate the lwsync code as an integer constant.  */
 #ifdef HAVE_AS_LWSYNC
Index: gcc/testsuite/gcc.target/powerpc/darn-0.c
===
--- gcc/testsuite/gcc.target/powerpc/darn-0.c   (revision 237530)
+++ gcc/testsuite/gcc.target/powerpc/darn-0.c   (working copy)
@@ -1,4 +1,7 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power9" } } */
+/* { dg-require-effective-target powerpc_p9vector_ok } */
+/* { dg-skip-if "" { powerpc*-*-aix* } } */
 /* { dg-options "-mcpu=power9" } */
 
 /* This test should succeed on both 32- and 64-bit configurations.  */
Index: gcc/testsuite/gcc.target/powerpc/darn-1.c
===
--- gcc/testsuite/gcc.target/powerpc/darn-1.c   (revision 237530)
+++ gcc/testsuite/gcc.target/powerpc/darn-1.c   (working copy)
@@ -1,6 +1,9 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power9" } } */
+/* { dg-require-effective-target powerpc_p9vector_ok } */
+/* { dg-require-effective-target lp64 } */
+/* { dg-skip-if "" { powerpc*-*-aix* } } */
 /* { dg-options "-mcpu=power9" } */
-/* { dg-require-effective-target lp64 } */
 
 #include 
 
Index: gcc/testsuite/gcc.target/powerpc/darn-2.c
===
--- gcc/testsuite/gcc.target/powerpc/darn-2.c   (revision 237530)
+++ gcc/testsuite/gcc.target/powerpc/darn-2.c   (working copy)
@@ -1,6 +1,9 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power9" } } */
+/* { dg-require-effective-target powerpc_p9vector_ok } */
+/* { dg-require-effective-target lp64 } */
+/* { dg-skip-if "" { powerpc*-*-aix* } } */
 /* { dg-options "-mcpu=power9" } */
-/* { dg-require-effective-target lp64 } */
 
 #include 
 
Index: 

Re: Return value on MIPS N64 ABI

[Heiher]

Thank you.

On Mon, Jun 13, 2016 at 6:19 PM, Matthew Fortune
 wrote:
> Heiher  writes:
>> Looks the return value of TestNewA is passed on $f0/$f2 from disassembly
>> code.  I don't known why the return value of TestNewB is passed on
>> $v0/$v1? a bug?
>
> I believe this is an area where GNU strays from the N64 ABI definition but
> is defacto standard. TestA is a struct of two floating point fields which
> is passed and returned in FP registers. TestB is a struct of a struct of
> two floating point fields (or at least I think that is the interpretation).
>
> The ABI does say that this should be flattened and be seen as simply two
> floating point fields but GCC does not and passes it in integer registers
> instead. Or at least the ABI says this for arguments but not results.
>
> The relevant bit of the ABI we are not adhering to is 'Structs,unions' on
> page 7 which covers arguments, however the corresponding text for results
> does not include the part about ignoring the struct field structure
> when determining between floating point and integer chunks.
>
> https://dmz-portal.ba.imgtec.org/mw/images/6/6f/007-2816-005-1.pdf
>
> FWIW: Clang/LLVM ABI implementation matches GCC in this regard as we run
> cross linking tests and use GCC as 'correct'.
>
> Thanks,
> Matthew
>
>> 229 00012c40 <_Z8TestNewAv>:
>> 23012c40:   3c030002lui v1,0x2
>> 23112c44:   0079182ddaddu   v1,v1,t9
>> 23212c48:   64638400daddiu  v1,v1,-31744
>> 23312c4c:   dc628050ld  v0,-32688(v1)
>> 23412c50:   67bdffe0daddiu  sp,sp,-32
>> 23512c54:   d4400e68ldc1$f0,3688(v0)
>> 23612c58:   dc628050ld  v0,-32688(v1)
>> 23712c5c:   67bd0020daddiu  sp,sp,32
>> 23812c60:   03e8jr  ra
>> 23912c64:   d4420e70ldc1$f2,3696(v0)
>> 240
>> 241 00012c68 <_Z8TestNewBv>:
>> 24212c68:   3c0307f9lui v1,0x7f9
>> 24312c6c:   3c0207f7lui v0,0x7f7
>> 24412c70:   3463ori v1,v1,0x
>> 24512c74:   3442ori v0,v0,0x
>> 24612c78:   00031cb8dsllv1,v1,0x12
>> 24712c7c:   000214b8dsllv0,v0,0x12
>> 24812c80:   3463cccdori v1,v1,0xcccd
>> 24912c84:   3442cccdori v0,v0,0xcccd
>> 25012c88:   67bdfff0daddiu  sp,sp,-16
>> 25112c8c:   00031c78dsllv1,v1,0x11
>> 25212c90:   00021478dsllv0,v0,0x11
>> 25312c94:   6463999adaddiu  v1,v1,-26214
>> 25412c98:   6442999adaddiu  v0,v0,-26214
>> 25512c9c:   03e8jr  ra
>> 25612ca0:   67bd0010daddiu  sp,sp,16
>>
>> // test.cpp
>> // gcc -march=mips64r2 -mabi=64 -O3 -o test test.cpp #include 
>>
>> class TestA
>> {
>> public:
>> double l;
>> double h;
>>
>> TestA(double l, double h) : l(l), h(h) {} };
>>
>> class TestB : public TestA
>> {
>> public:
>> TestB(const TestA& a) : TestA(a) {} };
>>
>> TestA
>> TestNewA(void)
>> {
>> return TestA(0.1, 0.2);
>> }
>>
>> TestB
>> TestNewB(void)
>> {
>> return TestA(0.1, 0.2);
>> }
>>
>> int
>> main(int argch, char *argv[])
>> {
>> TestA a = TestNewA();
>> printf("%lf, %lf\n", a.l, a.h);
>>
>> TestB b = TestNewB();
>> printf("%lf, %lf\n", b.l, b.h);
>>
>> return 0;
>> }



-- 
Best regards!
Heiher
http://hev.cc

[Bug c/71603] New: pragma diagnostic pop fails to restore warning level

[msebor at gcc dot gnu.org]

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

Bug ID: 71603
   Summary: pragma diagnostic pop fails to restore warning level
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

According to the description of #pragma GCC diagnostic push and #pragma GCC
diagnostic pop in the GCC manual:

Causes GCC to remember the state of the diagnostics as of each push, and
restore to that point at each pop. If a pop has no matching push, the
command-line options are restored.

With that, I would expect the following program to cause exactly two warnings,
one for each of -Wformat and -Wshift-overflow, as mentioned in the comments. 
But GCC issues four diagnostics instead, indicating that the #pragma pop
directive fails to restore the state of the warnings to that at the point of
each corresponding push.

$ cat t.C && /home/msebor/build/gcc-trunk-svn/gcc/xgcc -B
/home/msebor/build/gcc-trunk-svn/gcc -S -xc t.C
void f (const char *s)
{
#pragma GCC diagnostic warning "-Wformat=1"

  __builtin_printf (s, s);   // no -Wformat diagnostic expected

#pragma GCC diagnostic push
#pragma GCC diagnostic warning "-Wformat=2"
  __builtin_printf (s, s);   // -Wformat-nonliteral expected
#pragma GCC diagnostic pop

  __builtin_printf (s, s);   // no diagnostic expected
}

int x;

int g (void)
{
  enum { i = 1 };

#pragma GCC diagnostic warning "-Wshift-overflow=1"

  x = i << 31;   // no -Wshift-overflow expected

#pragma GCC diagnostic push
#pragma GCC diagnostic warning "-Wshift-overflow=2"

  x = i << 31;   // -Wshift-overflow expected

#pragma GCC diagnostic pop
  x = i << 31;   // no warning expected
}
t.C: In function ‘f’:
t.C:9:3: warning: format not a string literal, argument types not checked
[-Wformat-nonliteral]
   __builtin_printf (s, s);   // -Wformat-nonliteral expected
   ^~~~
t.C:12:3: warning: format not a string literal, argument types not checked
[-Wformat-nonliteral]
   __builtin_printf (s, s);   // no diagnostic expected
   ^~~~
t.C: In function ‘g’:
t.C:28:9: warning: result of ‘1 << 31’ requires 33 bits to represent, but ‘int’
only has 32 bits [-Wshift-overflow=]
   x = i << 31;   // -Wshift-overflow expected
 ^~
t.C:31:9: warning: result of ‘1 << 31’ requires 33 bits to represent, but ‘int’
only has 32 bits [-Wshift-overflow=]
   x = i << 31;   // no warning expected
 ^~

[Bug c/71601] ICE on conditional expression between DFP / non-DFP float

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #2 from Joseph S. Myers  ---
Fixed for GCC 7.

Fix ICE on conditional expression between DFP and non-DFP float (PR c/71601)

[Joseph Myers]

A conditional expression between DFP and non-DFP floating-point
produces an ICE.  This patch fixes this by making
build_conditional_expr return early when c_common_type produces an
error.

Bootstrapped with no regressions on x86_64-pc-linux-gnu.  Applied to 
mainline.

gcc/c:
2016-06-20  Joseph Myers  

PR c/71601
* c-typeck.c (build_conditional_expr): Return error_mark_node if
c_common_type returns error_mark_node.

gcc/testsuite:
2016-06-20  Joseph Myers  

PR c/71601
* gcc.dg/dfp/usual-arith-conv-bad-3.c: New test.

Index: gcc/c/c-typeck.c
===
--- gcc/c/c-typeck.c(revision 237589)
+++ gcc/c/c-typeck.c(working copy)
@@ -4846,6 +4846,8 @@ build_conditional_expr (location_t colon_loc, tree
   || code2 == COMPLEX_TYPE))
 {
   result_type = c_common_type (type1, type2);
+  if (result_type == error_mark_node)
+   return error_mark_node;
   do_warn_double_promotion (result_type, type1, type2,
"implicit conversion from %qT to %qT to "
"match other result of conditional",
Index: gcc/testsuite/gcc.dg/dfp/usual-arith-conv-bad-3.c
===
--- gcc/testsuite/gcc.dg/dfp/usual-arith-conv-bad-3.c   (nonexistent)
+++ gcc/testsuite/gcc.dg/dfp/usual-arith-conv-bad-3.c   (working copy)
@@ -0,0 +1,13 @@
+/* Test error for conditional expression between DFP and other
+   floating operand.  */
+/* { dg-do compile } */
+
+_Decimal32 a;
+float b;
+int i;
+
+void
+f (void)
+{
+  (void) (i ? a : b); /* { dg-error "mix operands" } */
+}

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

[Bug c/71601] ICE on conditional expression between DFP / non-DFP float

[jsm28 at gcc dot gnu.org]

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

--- Comment #1 from Joseph S. Myers  ---
Author: jsm28
Date: Mon Jun 20 22:58:20 2016
New Revision: 237622

URL: https://gcc.gnu.org/viewcvs?rev=237622=gcc=rev
Log:
Fix ICE on conditional expression between DFP and non-DFP float (PR c/71601).

A conditional expression between DFP and non-DFP floating-point
produces an ICE.  This patch fixes this by making
build_conditional_expr return early when c_common_type produces an
error.

Bootstrapped with no regressions on x86_64-pc-linux-gnu.

PR c/71601
gcc/c:
* c-typeck.c (build_conditional_expr): Return error_mark_node if
c_common_type returns error_mark_node.

gcc/testsuite:
* gcc.dg/dfp/usual-arith-conv-bad-3.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/dfp/usual-arith-conv-bad-3.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c/71602] New: ICE on valid code on x86_64-linux-gnu (in build_va_arg, at c-family/c-common.c:5810)

[chengniansun at gmail dot com]

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

Bug ID: 71602
   Summary: ICE on valid code on x86_64-linux-gnu (in
build_va_arg, at c-family/c-common.c:5810)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

This is a regression. gcc-5.3 and older versions are okay with the following
test program. 

$: gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160620 (experimental) [trunk revision 237605] (GCC) 
$: 
$: gcc-trunk -c small.c
small.c: In function ‘fn1’:
small.c:3:3: internal compiler error: in build_va_arg, at
c-family/c-common.c:5810
   __builtin_va_arg(pap, double);
   ^~~~
0x7067a2 build_va_arg(unsigned int, tree_node*, tree_node*)
../../gcc-source-trunk/gcc/c-family/c-common.c:5810
0x6a0d23 c_parser_postfix_expression
../../gcc-source-trunk/gcc/c/c-parser.c:7668
0x6a335a c_parser_unary_expression
../../gcc-source-trunk/gcc/c/c-parser.c:6942
0x6a418a c_parser_cast_expression
../../gcc-source-trunk/gcc/c/c-parser.c:6771
0x6a4394 c_parser_binary_expression
../../gcc-source-trunk/gcc/c/c-parser.c:6580
0x6a5045 c_parser_conditional_expression
../../gcc-source-trunk/gcc/c/c-parser.c:6351
0x6a56c0 c_parser_expr_no_commas
../../gcc-source-trunk/gcc/c/c-parser.c:6268
0x6a5dc2 c_parser_expression
../../gcc-source-trunk/gcc/c/c-parser.c:8464
0x6a6829 c_parser_expression_conv
../../gcc-source-trunk/gcc/c/c-parser.c:8497
0x6bcb28 c_parser_statement_after_labels
../../gcc-source-trunk/gcc/c/c-parser.c:5287
0x6be9cb c_parser_compound_statement_nostart
../../gcc-source-trunk/gcc/c/c-parser.c:4861
0x6bf25e c_parser_compound_statement
../../gcc-source-trunk/gcc/c/c-parser.c:4696
0x6c0487 c_parser_declaration_or_fndef
../../gcc-source-trunk/gcc/c/c-parser.c:2105
0x6c9625 c_parser_external_declaration
../../gcc-source-trunk/gcc/c/c-parser.c:1549
0x6c9eb9 c_parser_translation_unit
../../gcc-source-trunk/gcc/c/c-parser.c:1430
0x6c9eb9 c_parse_file()
../../gcc-source-trunk/gcc/c/c-parser.c:17931
0x72c2b2 c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1070
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$: 
$: gcc-5.3 -c small.c
$: 
$: cat small.c
__builtin_va_list *pap;
void fn1() {
  __builtin_va_arg(pap, double); 
}
$:

Re: [PATCH, vec-tails 01/10] New compiler options

[Jeff Law]

On 06/17/2016 04:41 AM, Ilya Enkovich wrote:



1. You've got 3 modes for epilogue vectorization.  Is this an artifact of
not really having good heuristics yet for which mode to apply to a
particular loop at this time?

2. Similarly for cost models.


All three modes are profitable in different situations.  Profitable mode depends
on a loop structure and target capabilities.  Ultimate goal is to have all three
modes enabled by default.  I can't state current heuristics are good enough
for all cases and targets and therefore don't enable epilogues vectorization
by default for now.  This is to be measured, analyzed and tuned in
time for GCC 7.1.




I add cost model simply to have an ability to force epilogue vectorization for
stability testing (force some mode of epilogue vectorization and check nothing
fails) and performance testing/tuning (try to find cases where we may benefit
from epilogue vectorization but don't due to bad cost model).  Also I don't
want to force epilogue vectorization for all loops for which vectorization is
forced using unlimited cost model because that may hurt performance for
simd loops.

Thanks.  That overview helps a lot.

We've done something similar to what you're doing with cost models for 
testing in the scheduler and other places in the past.   The costing 
models seem more geared towards us as developers rather than users.  you 
might consider keep those as local changes and not documenting them.


Understood completely on the modes.




Currently I have numbers collected on various suites for KNL machine.  Masking
mode (-ftree-vectorize-epilogues=mask) shows not bad results (dynamic
cost model,
-Ofast -flto -funroll-loops).  I don't see significant losses and there are few
significant gains.  For combine and nomask modes the result is not good enough
yet - there are several significant performance losses.  My guess is that
current threshold for combine is way too high and for nomask variant we better
choose the smallest vector size for epilogues instead of the next available
(use zmm for body and xmm for epilogue instead of zmmm for body and ymm for
epilogue).

ICC shows better results in these modes which makes me believe we can tune them
as well.  Overall nomask mode shows worse results comparing to options with
masking which is quite expected for KNL.

Unfortunately some big gains demonstrated by ICC are not reproducible
using GCC because we originally can't vectorize required hot loops.  E.g. on
200.sixtrack GCC has nothing and ICC has ~40% for all three modes.
I hadn't pondered that case.  Certainly if GCC isn't vectorizing as 
much, we're not going to have as many opportunities for optimizing the 
vec-tails.


Given the results with ICC, we're probably best off keeping all 3 modes 
and working to get them tuned correctly.





I don't have the whole statistics for Haswell but synthetic tests show the
situation is really different from KNL.  Even for the 'perfect' iterations count
number (VF * 2 - 1) scalar version of epilogue shows the same result as a masked
one.  It means ratio of vector code performance vs. scalar code performance is
not as high as for KNL (KNL is more vector oriented and has weaker
scalar performance,
double vector size also matters here) and masking cost is higher for Haswell.
We still focus on AVX-512 targets more because of their rich masking
capabilities and wider vector.

Understood.

Jeff

Re: [PATCH] PR52665 do not let .ident confuse assembler scan tests

[Jeff Law]

On 06/18/2016 01:31 PM, Bernhard Reutner-Fischer wrote:

A branch with a name matching scan-assembler pattern triggers
inappropriate FAIL.

E.g. branch fixups-testsuite and
- gcc.target/i386/pr65871-?.c (scan-assembler-not "test")
- gcc.target/i386/pr41442.c (scan-assembler-times "test|cmp" 2)
etc.

This is a recurring problem as can be seen by some -fno-ident additions
by commits from e.g. Michael Meissner over the years: builtins-58.c,
powerpc/pr46728-?.c

The patch below adds -fno-ident if a testcase contains one of
scan-assembler, scan-assembler-not or scan-assembler-times.

Regression tested on x86_64-unknown-linux on a fixups-testsuite branch
where it fixes several false FAILs without regressions.

gcc/testsuite/ChangeLog

2016-06-18  Bernhard Reutner-Fischer  

PR testsuite/52665
* lib/gcc-dg.exp (gcc-dg-test-1): Iterate over _required_options.
* lib/target-supports.exp (scan-assembler_required_options,
scan-assembler-not_required_options,
scan-assembler-times_required_options): Add -fno-ident.
* lib/scanasm.exp (scan-assembler-times): Fix error message.
* c-c++-common/ident-0a.c: New test.
* c-c++-common/ident-0b.c: New test.
* c-c++-common/ident-1a.c: New test.
* c-c++-common/ident-1b.c: New test.
* c-c++-common/ident-2a.c: New test.
* c-c++-common/ident-2b.c: New test.

Ok for trunk?

PS: proc force_conventional_output_for would be a bit misnomed by this,
not sure if it should be renamed to maybe set_required_options_for or
the like?

OK.

Changing force_conventional_output to set_required_options_for is 
pre-approved as well.


jeff

Re: [PATCH] Give up instead of ICE on invalid stringops attributes (PR tree-optimization/71588)

[Jeff Law]

On 06/20/2016 12:35 PM, Jakub Jelinek wrote:

Hi!

If users use attributes like const or pure incorrectly on stringops
builtins, the tree-ssa-strlen.c pass can ICE, because it expects it can e.g.
replace a strcpy (which should not be const or pure) with memcpy (which also
shouldn't be const/pure) etc.
The patch just pretends the calls aren't builtins for the purpose of
tree-ssa-strlen.c pass if they have unexpected const/pure-ness.

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

2016-06-20  Jakub Jelinek  

PR tree-optimization/71588
* tree-ssa-strlen.c (valid_builtin_call): New function.
(adjust_last_stmt, handle_builtin_memset, strlen_optimize_stmt): Use
it.

* gcc.dg/pr71558.c: New test.

OK.
jeff

Re: [PING] [PATCH] Fix asm X constraint (PR inline-asm/59155)

[Jeff Law]

On 06/09/2016 10:45 AM, Jakub Jelinek wrote:

On Thu, Jun 09, 2016 at 06:43:04PM +0200, Jakub Jelinek wrote:

Yes, I'm all in favor in disabling X constraint for inline asm.
Especially if people actually try to print it as well, rather than make it
unused.  That is a sure path to ICEs.


Though, on the other side, even our documentation mentions
asm volatile ("mtfsf 255,%1" : "=X"(sum): "f"(fpenv));
So perhaps we need to error just in case such an argument is printed?
Are you thinking to scan the output string for % for the appropriate 
?  That shouldn't be too hard.  But that's not sufficient to address 
the problem Bernd is trying to tackle AFAICT.



Jeff

Re: RFC: pass to warn on questionable uses of alloca().

[Jeff Law]

On 06/18/2016 05:55 PM, Martin Sebor wrote:



I think detecting potentially problematic uses of alloca would
be useful, especially when done in an intelligent way like in
your patch (as opposed to simply diagnosing every call to
the function regardless of the value of its argument).  At
the same time, it seems that an even more reliable solution
than pointing out potentially unsafe calls to the function
and relying on users to modify their code to use malloc for
large/unbounded allocations would be to let GCC do it for
them automatically (i.e., in response to some other option,
emit a call to malloc instead, and insert a call to free when
appropriate).
As Joseph pointed out, this may not be valid in certain contexts. 
THough it is an interesting idea.




I found the "warning: unbounded use of alloca" misleading when
a call to the function was, in fact, bounded but to a limit
that's greater than alloca-max-size as in the program below:

  void f (void*);

  void g (int n)
  {
void *p;
if (n < 4096)
  p = __builtin_alloca (n);
else
  p = __builtin_malloc (n);
f (p);
  }
  t.C: In function ‘g’:
  t.C:7:7: warning: unbounded use of alloca [-Walloca]
   p = __builtin_alloca (n);

I would suggest to rephrase the diagnostic to mention the limit,
e.g.,

  warning: calling alloca with an argument in excess of '4000'
  bytes

Agreed.



As a separate enhancement, since in the (idiomatic) example
above the malloc memory is allowed to leak, issuing a distinct
warning for it would help detect this class of bugs that's
likely to be common as users replace unbounded uses of alloca
with malloc in response to the new option and forget to free
the memory.  Diagnosing freeing the alloca memory would be
a nice touch as well.
Aldy and I have been kicking around additional warnings in this space. 
It's a good idea I'll encourage him to add.


I also think that VLA diagnostics would be better controlled
by a separate option, and emit a different diagnostic (one
that mentions VLA rather than alloca).
Probably wise -- I wouldn't necessarily expect everyone to understand 
the relationship between the VLA language construct and how it's 
implemented in GCC in terms of stack allocations.




 Although again, and

for VLAs even more so than for alloca, providing an option
to have GCC use dynamic allocation, would be an even more
robust solution than issuing warnings.  IIRC, this was the
early implementation of VLAs in GCC so there is a precedent
for it.  (Though this seems complementary to the warnings.)
In addition, I'm of the opinion that potentially unbounded
VLA allocation should be checked at runtime and made trap on
size overflow in C and throw an exception in C++ (e.g., when
int a [A][B] when A * B * sizeof (int) exceeds SIZE_MAX / 2
or some runtime-configurable limit).  My C++ patch for bug
69517 does just that (it needs to be resubmitted with the
runtime configuration limit added).

Right.

Jeff

[Bug middle-end/71581] [5/6/7 Regression] ICE on valid code on x86_64-linux-gnu with -Wuninitialized (Segmentation fault)

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jun 20 21:41:20 2016
New Revision: 237621

URL: https://gcc.gnu.org/viewcvs?rev=237621=gcc=rev
Log:
PR middle-end/71581
* tree-ssa-uninit.c (warn_uninit): If EXPR and VAR are NULL,
see if T isn't anonymous SSA_NAME with COMPLEX_EXPR created
for conversion of scalar user var to complex type and use the
underlying SSA_NAME_VAR in that case.  If EXPR is still NULL,
punt.

* gcc.dg/pr71581.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr71581.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-uninit.c

Re: RFC: pass to warn on questionable uses of alloca().

[Jeff Law]

On 06/20/2016 08:56 AM, Joseph Myers wrote:

On Sat, 18 Jun 2016, Martin Sebor wrote:


the function regardless of the value of its argument).  At
the same time, it seems that an even more reliable solution
than pointing out potentially unsafe calls to the function
and relying on users to modify their code to use malloc for
large/unbounded allocations would be to let GCC do it for
them automatically (i.e., in response to some other option,
emit a call to malloc instead, and insert a call to free when
appropriate).


Note that such an option would not be usable for the original motivating
case of glibc, because in code that's meant to be async-signal-safe,
alloca and VLAs can be used, but malloc cannot.
I've actually considered the other direction more viable.  Define the 
right set of constraints and let the compiler optimize from malloc/free 
to alloca.


For the uses of alloca in glibc that have to be async-signal-safe, we 
should just leave those alone no matter what we may or may not be able 
to prove.


jeff

[Bug rtl-optimization/71591] SIGSEGV in test_uncond_jump (rtl-tests.c:90) with -E -fself-test

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jun 20 21:40:02 2016
New Revision: 237620

URL: https://gcc.gnu.org/viewcvs?rev=237620=gcc=rev
Log:
PR rtl-optimization/71591
* toplev.c (toplev::run_self_tests): If no_backend, complain and
don't run any tests.

* gcc.dg/cpp/pr71591.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/cpp/pr71591.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/toplev.c

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

[howard.hinnant at gmail dot com]

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

--- Comment #15 from Howard Hinnant  ---
To help clarify my proposal, here is a patch:

diff --git a/libstdc++-v3/src/c++11/thread.cc
b/libstdc++-v3/src/c++11/thread.cc
index 906cafa..cfca178 100644
--- a/libstdc++-v3/src/c++11/thread.cc
+++ b/libstdc++-v3/src/c++11/thread.cc
@@ -79,19 +79,7 @@ namespace std _GLIBCXX_VISIBILITY(default)
   thread::__shared_base_type __local;
   __local.swap(__t->_M_this_ptr);

-  __try
-   {
- __t->_M_run();
-   }
-  __catch(const __cxxabiv1::__forced_unwind&)
-   {
- __throw_exception_again;
-   }
-  __catch(...)
-   {
- std::terminate();
-   }
-
+   __t->_M_run();
   return nullptr;
 }
   }

My colleague Miguel Portilla has tested this patch with the following code:

#include 
#include 

void a(int i);
void b(int i);
void c(int i);

int
main()
{
auto t = std::thread{a, 3};
t.join();
}

void
a(int i)
{
b(i-1);
}

void
b(int i)
{
c(i-1);
}

void
c(int i)
{
throw std::runtime_error("A good message");
}

And the stack dump looks like:

Thread 2 (Thread 0x7f090b47c740 (LWP 1865)):
#0  0x7f090b0688ed in pthread_join (threadid=139676803389184,
thread_return=0x0) at pthread_join.c:90
#1  0x7f090ad9c767 in __gthread_join (__value_ptr=0x0,
__threadid=)
at
/home/mickey/gcc-5.4.0/build/x86_64-linux-gnu/libstdc++-v3/include/x86_64-linux-gnu/bits/gthr-default.h:668
#2  std::thread::join (this=0x7ffd1dae6430) at
../../../../../libstdc++-v3/src/c++11/thread.cc:96
#3  0x00400f39 in main ()

Thread 1 (Thread 0x7f090a3fd700 (LWP 1866)):
#0  0x7f090a433267 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:55
#1  0x7f090a434eca in __GI_abort () at abort.c:89
#2  0x7f090ad747dd in __gnu_cxx::__verbose_terminate_handler ()
at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95
#3  0x7f090ad72866 in __cxxabiv1::__terminate (handler=)
at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:47
#4  0x7f090ad728b1 in std::terminate () at
../../../../libstdc++-v3/libsupc++/eh_terminate.cc:57
#5  0x7f090ad72ac8 in __cxxabiv1::__cxa_throw (obj=0x7f0904000940, 
tinfo=0x604360 , 
dest=0x400ce0 ) at
../../../../libstdc++-v3/libsupc++/eh_throw.cc:87
#6  0x00400fdd in c(int) ()
#7  0x00400fa0 in b(int) ()
#8  0x00400f85 in a(int) ()
#9  0x00402574 in void std::_Bind_simple::_M_invoke<0ul>(std::_Index_tuple<0ul>) ()
#10 0x00402493 in std::_Bind_simple::operator()()
()
#11 0x00402432 in std::thread::_Impl::_M_run() ()
#12 0x7f090ad9c820 in std::execute_native_thread_routine (__p=)
at ../../../../../libstdc++-v3/src/c++11/thread.cc:82
#13 0x7f090b0676aa in start_thread (arg=0x7f090a3fd700) at
pthread_create.c:333
#14 0x7f090a504e9d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Re: [PATCH] Don't run -fself-test with -E (PR rtl-optimization/71591)

[Jeff Law]

On 06/20/2016 12:38 PM, Jakub Jelinek wrote:

Hi!

As mentioned in the PR, with -E (C family and Fortran FEs, others don't
preprocess) ask the middle-end not to initialize the backends, so running
e.g. RTL tests leads to ICEs, e.g. pc_rtx and many other things just aren't
initialized.

2016-06-20  Jakub Jelinek  

PR rtl-optimization/71591
* toplev.c (toplev::run_self_tests): If no_backend, complain and
don't run any tests.

* gcc.dg/cpp/pr71591.c: New test.

OK.
jeff

Re: [PATCH] Fix warn uninit ICE with _Complex exprs (PR middle-end/71581)

[Jeff Law]

On 06/20/2016 12:45 PM, Jakub Jelinek wrote:

Hi!

On the following testcase we ICE during warn_uninit.
Normally, has_undefined_value_p returns false for anonymous SSA_NAMEs,
so NULL expr/var aren't a problem.  If t has a COMPLEX_EXPR as def-stmt,
where the first operand is some scalar var's (D) SSA_NAME and the second
operand is 0, which results from gimplification of conversion of scalar
uninitialized var to complex type, t is anonymous SSA_NAME and expr and var
are both NULL.

This patch attempts to deal with that, try to recognize the case and use
the other SSA_NAME's underlying var as expr/var in that case, or punt (in
the unlikely case this wouldn't help).

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

2016-06-20  Jakub Jelinek  

PR middle-end/71581
* tree-ssa-uninit.c (warn_uninit): If EXPR and VAR are NULL,
see if T isn't anonymous SSA_NAME with COMPLEX_EXPR created
for conversion of scalar user var to complex type and use the
underlying SSA_NAME_VAR in that case.  If EXPR is still NULL,
punt.

* gcc.dg/pr71581.c: New test.

OK.
jeff

[Bug c/71601] New: ICE on conditional expression between DFP / non-DFP float

[jsm28 at gcc dot gnu.org]

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

Bug ID: 71601
   Summary: ICE on conditional expression between DFP / non-DFP
float
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

A conditional expression between DFP and non-DFP floating-point produces an
ICE:

_Decimal32 a;
float b;
int i;
void
f (void)
{
  (void) (i ? a : b);
}

(on x86_64-pc-linux-gnu):

t.c: In function 'f':
t.c:7:3: error: can't mix operands of decimal float and other float types
   (void) (i ? a : b);
   ^
t.c:7:3: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in get_qualified_type, at tree.c:6604
0xdbe161 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/scratch/jmyers/fsf/gcc-mainline/gcc/tree.c:9803
0xdd4161 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/scratch/jmyers/fsf/gcc-mainline/gcc/tree.h:3153
0xdd4161 get_qualified_type(tree_node*, int)
/scratch/jmyers/fsf/gcc-mainline/gcc/tree.c:6604
0xddb0ed build_qualified_type(tree_node*, int)
/scratch/jmyers/fsf/gcc-mainline/gcc/tree.c:6626
0x5ffe7a build_conditional_expr(unsigned int, tree_node*, bool, tree_node*,
tree_node*, tree_node*, tree_node*)
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-typeck.c:5028
0x629514 c_parser_conditional_expression
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:6411
0x629970 c_parser_expr_no_commas
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:6268
0x62a0d2 c_parser_expression
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:8464
0x624942 c_parser_postfix_expression
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:7595
0x62760a c_parser_unary_expression
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:6939
0x6283b7 c_parser_cast_expression
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:6771
0x62845f c_parser_cast_expression
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:6760
0x6285d2 c_parser_binary_expression
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:6580
0x6292b5 c_parser_conditional_expression
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:6351
0x629970 c_parser_expr_no_commas
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:6268
0x62a0d2 c_parser_expression
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:8464
0x62ab19 c_parser_expression_conv
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:8497
0x64382c c_parser_statement_after_labels
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:5287
0x645968 c_parser_compound_statement_nostart
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:4861
0x645cde c_parser_compound_statement
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:4696
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I don't know if there was any version where this did not produce an ICE. 
Testing a patch.

Re: [PATCH] x86-64: Load external function address via GOT slot

[H.J. Lu]

On Mon, Jun 20, 2016 at 12:46 PM, Richard Sandiford
 wrote:
> Uros Bizjak  writes:
>> On Mon, Jun 20, 2016 at 9:19 PM, H.J. Lu  wrote:
>>> On Mon, Jun 20, 2016 at 12:13 PM, Uros Bizjak  wrote:
 On Mon, Jun 20, 2016 at 7:05 PM, H.J. Lu  wrote:
> Hi,
>
> This patch implements the alternate code sequence recommended in
>
> https://groups.google.com/forum/#!topic/x86-64-abi/de5_KnLHxtI
>
> to load external function address via GOT slot with
>
> movq func@GOTPCREL(%rip), %rax
>
> so that linker won't create an PLT entry for extern function
> address.
>
> Tested on x86-64.  OK for trunk?

> +  else if (ix86_force_load_from_GOT_p (op1))
> +{
> +  /* Load the external function address via the GOT slot to
> +avoid PLT.  */
> +  op1 = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, op1),
> +   (TARGET_64BIT
> +? UNSPEC_GOTPCREL
> +: UNSPEC_GOT));
> +  op1 = gen_rtx_CONST (Pmode, op1);
> +  op1 = gen_const_mem (Pmode, op1);
> +  /* This symbol must be referenced via a load from the Global
> +Offset Table.  */
> +  set_mem_alias_set (op1, ix86_GOT_alias_set ());
> +  op1 = convert_to_mode (mode, op1, 1);
> +  op1 = force_reg (mode, op1);
> +  emit_insn (gen_rtx_SET (op0, op1));
> +  /* Generate a CLOBBER so that there will be no REG_EQUAL note
> +on the last insn to prevent cse and fwprop from replacing
> +a GOT load with a constant.  */
> +  rtx tmp = gen_reg_rtx (Pmode);
> +  emit_clobber (tmp);
> +  return;

 Jeff, is this the recommended way to prevent CSE, as far as RTL
 infrastructure is concerned? I didn't find any example of this
 approach with other targets.

>>>
>>> FWIW, the similar approach is used in ix86_expand_vector_move_misalign,
>>> ix86_expand_convert_uns_didf_sse and ix86_expand_vector_init_general
>>> as well as other targets:
>>>
>>> frv/frv.c:  emit_clobber (op0);
>>> frv/frv.c:  emit_clobber (op1);
>>> im32c/m32c.c:  /*  emit_clobber (gen_rtx_REG (HImode, R0L_REGNO)); */
>>> s390/s390.c:  emit_clobber (addr);
>>> s390/s390.md:  emit_clobber (reg0);
>>> s390/s390.md:  emit_clobber (reg1);
>>> s390/s390.md:  emit_clobber (reg0);
>>> s390/s390.md:  emit_clobber (reg0);
>>> s390/s390.md:  emit_clobber (reg1);
>>
>> These usages mark the whole register as being "clobbered"
>> (=undefined), before only a part of register is written, e.g.:
>>
>>   emit_clobber (int_xmm);
>>   emit_move_insn (gen_lowpart (DImode, int_xmm), input);
>>
>> They aren't used to prevent unwanted CSE.
>
> Since it's being called in the move expander, I thought the normal
> way of preventing the constant being rematerialised would be to reject
> it in the move define_insn predicates.
>
> FWIW, I agree that using a clobber for this is going to be fragile.
>

Here is the alternative from clobber.


-- 
H.J.
--
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index a68983c..7df 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -2347,7 +2347,7 @@
 (define_insn "*movsi_internal"
   [(set (match_operand:SI 0 "nonimmediate_operand"
  "=r,m ,*y,*y,?rm,?*y,*v,*v,*v,m ,?r ,?r,?*Yi,*k  ,*rm")
- (match_operand:SI 1 "general_operand"
+ (match_operand:SI 1 "ix86_general_operand"
  "g ,re,C ,*y,*y ,rm ,C ,*v,m ,*v,*Yj,*v,r   ,*krm,*k"))]
   "!(MEM_P (operands[0]) && MEM_P (operands[1]))"
 {
@@ -2564,7 +2564,7 @@
 (define_insn "*movqi_internal"
   [(set (match_operand:QI 0 "nonimmediate_operand"
  "=q,q ,q ,r,r ,?r,m ,k,k,r ,m,k")
- (match_operand:QI 1 "general_operand"
+ (match_operand:QI 1 "ix86_general_operand"
  "q ,qn,qm,q,rn,qm,qn,r ,k,k,k,m"))]
   "!(MEM_P (operands[0]) && MEM_P (operands[1]))"
 {
diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index 06a0002..a471deb 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -367,6 +367,12 @@
 }
 })

+;; Return true if OP is general operand representable on ix86
+(define_predicate "ix86_general_operand"
+  (and (match_operand 0 "general_operand")
+   (ior (not (match_code "symbol_ref"))
+(match_test "!ix86_force_load_from_GOT_p (op)"
+
 ;; Return true if size of VALUE can be stored in a sign
 ;; extended immediate field.
 (define_predicate "x86_64_immediate_size_operand"
@@ -1036,6 +1042,9 @@
   struct ix86_address parts;
   int ok;

+  if (ix86_force_load_from_GOT_p (op))
+return false;
+
   if (!CONST_INT_P (op)
   && mode != VOIDmode
   && GET_MODE (op) != mode)

[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash

[hp at gcc dot gnu.org]

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

--- Comment #15 from Hans-Peter Nilsson  ---
(In reply to David B. Robins from comment #12)
> Note that it does still need -fno-inline.

I almost missed.

> I know why it doesn't crash with -O0: there is a text-section constant
> inserted after the thunk, and it's inlined at higher optimization levels.
> The instruction said constant maps to is either harmless or forbidden as a
> delay slot instruction. So the underlying issue still occurs but the crash
> doesn't.

Ah, ok, thanks for the analysis.

> I am OK with my name/email being included in the ChangeLog, thank you.

Great.  BTW, I'm keeping the PR open, pending back-ports to open branches.

Thanks again!

[Bug c/71600] [7 regression] test case gcc.dg/gnu89-const-expr-1.c fails starting with r237581

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Martin Sebor  ---
Thank you.  I fixed this earlier today in r237606:
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01426.html

Re: [PATCH 6/6] loop-iv.c: make cond_list a vec

[Richard Sandiford]

tbsaunde+...@tbsaunde.org writes:
> diff --git a/gcc/loop-iv.c b/gcc/loop-iv.c
> index 57fb8c1..21c3180 100644
> --- a/gcc/loop-iv.c
> +++ b/gcc/loop-iv.c
> @@ -1860,7 +1860,6 @@ simplify_using_initial_values (struct loop *loop, enum 
> rtx_code op, rtx *expr)
>  {
>bool expression_valid;
>rtx head, tail, last_valid_expr;
> -  rtx_expr_list *cond_list;
>rtx_insn *insn;
>rtx neutral, aggr;
>regset altered, this_altered;
> @@ -1936,7 +1935,7 @@ simplify_using_initial_values (struct loop *loop, enum 
> rtx_code op, rtx *expr)
>  
>expression_valid = true;
>last_valid_expr = *expr;
> -  cond_list = NULL;
> +  auto_vec cond_list;
>while (1)
>  {
>insn = BB_END (e->src);

How about using "auto_vec" for some small N, since we expect
cond_list to be used fairly often?

Wish I knew whether there was supposed to be a space before "<"...

> @@ -1988,39 +1988,30 @@ simplify_using_initial_values (struct loop *loop, 
> enum rtx_code op, rtx *expr)
>  
> if (suitable_set_for_replacement (insn, , ))
>   {
> -   rtx_expr_list **pnote, **pnote_next;
> -
> replace_in_expr (expr, dest, src);
> if (CONSTANT_P (*expr))
>   goto out;
>  
> -   for (pnote = _list; *pnote; pnote = pnote_next)
> +   unsigned int len = cond_list.length ();
> +   for (unsigned int i = len - 1; i < len; i--)
>   {
> -   rtx_expr_list *note = *pnote;
> -   rtx old_cond = XEXP (note, 0);
> +   rtx old_cond = cond_list[i];
>  
> -   pnote_next = (rtx_expr_list **) (note, 1);
> -   replace_in_expr ( (note, 0), dest, src);
> +   replace_in_expr (_list[i], dest, src);
>  
> /* We can no longer use a condition that has been simplified
>to a constant, and simplify_using_condition will abort if
>we try.  */
> -   if (CONSTANT_P (XEXP (note, 0)))
> - {
> -   *pnote = *pnote_next;
> -   pnote_next = pnote;
> -   free_EXPR_LIST_node (note);
> - }
> +   if (CONSTANT_P (cond_list[i]))
> + cond_list.ordered_remove (i);

Do we really need ordered removes here and below?  Obviously it turns
the original O(1) operation into O(n), and it wasn't obvious from first
glance that the order of the conditions was relevant.

Thanks,
Richard

[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

Committed, CRIS: fix target/71571, delay-slot nop in PIC MI thunk

[Hans-Peter Nilsson]

Committed to trunk.  Apparently the -fno-inline is key to
keeping the test-case small.
Thanks go to the reporter, David B. Robins.

gcc:
PR target/71571
* config/cris/cris.c (cris_asm_output_mi_thunk): Add missing "ba"
delay-slot "nop" for PIC with CRIS v32.  Also add missing leading
space for PIC with non-v32 and the common non-PIC "jump".

gcc/testsuite:
PR target/71571
* g++.dg/torture/pr71571.C: New test.

Index: gcc/config/cris/cris.c
===
--- gcc/config/cris/cris.c  (revision 235415)
+++ gcc/config/cris/cris.c  (working copy)
@@ -2772,18 +2772,18 @@ cris_asm_output_mi_thunk (FILE *stream,
{
  fprintf (stream, "\tba ");
  assemble_name (stream, name);
- fprintf (stream, "%s\n", CRIS_PLT_PCOFFSET_SUFFIX);
+ fprintf (stream, "%s\n\tnop\n", CRIS_PLT_PCOFFSET_SUFFIX);
}
   else
{
- fprintf (stream, "add.d ");
+ fprintf (stream, "\tadd.d ");
  assemble_name (stream, name);
  fprintf (stream, "%s,$pc\n", CRIS_PLT_PCOFFSET_SUFFIX);
}
 }
   else
 {
-  fprintf (stream, "jump ");
+  fprintf (stream, "\tjump ");
   assemble_name (stream, XSTR (XEXP (DECL_RTL (funcdecl), 0), 0));
   fprintf (stream, "\n");
 
--- /dev/null   Tue Oct 29 15:57:07 2002
+++ pr71571.C   Mon Jun 20 21:50:12 2016
@@ -0,0 +1,43 @@
+// { dg-do run }
+// { dg-options "-fno-inline" { target { ! fpic } } }
+// { dg-options "-fpic -fno-inline" { target fpic } }
+
+class XBase
+{
+public:
+ virtual void FuncA() = 0;
+};
+
+class Y
+{
+protected:
+ virtual void FuncB() {}
+};
+
+class X1 : public Y, public XBase
+{
+public:
+ void FuncA() {}
+};
+
+class X2 : public XBase
+{
+public:
+ X2(XBase ) : m_xb(xb) { }
+ void FuncA()
+ {
+  m_xb.FuncA();
+ }
+
+private:
+ XBase _xb;
+};
+
+
+int main()
+{
+ X1 x1;
+ X2 x2(x1);
+ XBase *pxb = 
+ pxb->FuncA();
+}

brgds, H-P

[Bug libstdc++/71181] Reserving in unordered_map doesn't reserve enough

[fdumont at gcc dot gnu.org]

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

--- Comment #5 from François Dumont  ---
Author: fdumont
Date: Mon Jun 20 20:04:25 2016
New Revision: 237617

URL: https://gcc.gnu.org/viewcvs?rev=237617=gcc=rev
Log:
2016-06-20  François Dumont  

PR libstdc++/71181
* include/tr1/hashtable_policy.h
(_Prime_rehash_policy::_M_next_bkt): Make past-the-end iterator
dereferenceable to avoid check on lower_bound result.
(_Prime_rehash_policy::_M_bkt_for_elements): Call latter.
(_Prime_rehash_policy::_M_need_rehash): Likewise.
* src/c++11/hashtable_c++0x.cc (_Prime_rehash_policy::_M_next_bkt):
Always return a value greater than input value. Set _M_next_resize to
max value when reaching highest prime number.
* src/shared/hashtable-aux.cc (__prime_list): Add comment about
sentinel
being now useless.
* testsuite/23_containers/unordered_set/hash_policy/71181.cc: New.
* testsuite/23_containers/unordered_set/hash_policy/power2_rehash.cc
(test02): New.
* testsuite/23_containers/unordered_set/hash_policy/prime_rehash.cc:
New.
* testsuite/23_containers/unordered_set/hash_policy/rehash.cc:
Fix indentation.

Added:
   
trunk/libstdc++-v3/testsuite/23_containers/unordered_set/hash_policy/71181.cc
   
trunk/libstdc++-v3/testsuite/23_containers/unordered_set/hash_policy/prime_rehash.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/tr1/hashtable_policy.h
trunk/libstdc++-v3/src/c++11/hashtable_c++0x.cc
trunk/libstdc++-v3/src/shared/hashtable-aux.cc
   
trunk/libstdc++-v3/testsuite/23_containers/unordered_set/hash_policy/power2_rehash.cc
   
trunk/libstdc++-v3/testsuite/23_containers/unordered_set/hash_policy/rehash.cc

[Bug c/71600] [7 regression] test case gcc.dg/gnu89-const-expr-1.c fails starting with r237581

[seurer at linux dot vnet.ibm.com]

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

--- Comment #1 from Bill Seurer  ---
Also this test case:

FAIL: gcc.dg/gnu99-static-1.c  (test for errors, line 14)


line 14:
void g0(void) { __alignof__(f0()); } /* { dg-error "__alignof__
\\(expression\\)" } */

Re: [PATCH 5/6] make pattern_regs a vec

[Richard Sandiford]

tbsaunde+...@tbsaunde.org writes:
> @@ -265,18 +261,16 @@ store_ops_ok (const_rtx x, int *regs_set)
>  /* Returns a list of registers mentioned in X.
> FIXME: A regset would be prettier and less expensive.  */
>
> -static rtx_expr_list *
> -extract_mentioned_regs (rtx x)
> +static void
> +extract_mentioned_regs (rtx x, vec *mentioned_regs)
>  {
> -  rtx_expr_list *mentioned_regs = NULL;
>subrtx_var_iterator::array_type array;
>FOR_EACH_SUBRTX_VAR (iter, array, x, NONCONST)
>  {
>rtx x = *iter;
>if (REG_P (x))
> - mentioned_regs = alloc_EXPR_LIST (0, x, mentioned_regs);
> + mentioned_regs->safe_push (x);
>  }
> -  return mentioned_regs;
>  }

The function comment needs to be updated.

Thanks,
Richard

[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash

[hp at gcc dot gnu.org]

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

--- Comment #14 from Hans-Peter Nilsson  ---
Author: hp
Date: Mon Jun 20 20:02:03 2016
New Revision: 237616

URL: https://gcc.gnu.org/viewcvs?rev=237616=gcc=rev
Log:
PR target/71571
* g++.dg/torture/pr71571.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr71571.C   (with props)
Modified:
trunk/gcc/testsuite/ChangeLog

Propchange: trunk/gcc/testsuite/g++.dg/torture/pr71571.C
('svn:executable' added)

[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash

[hp at gcc dot gnu.org]

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

--- Comment #13 from Hans-Peter Nilsson  ---
Author: hp
Date: Mon Jun 20 20:01:20 2016
New Revision: 237615

URL: https://gcc.gnu.org/viewcvs?rev=237615=gcc=rev
Log:
PR target/71571
* config/cris/cris.c (cris_asm_output_mi_thunk): Add missing "ba"
delay-slot "nop" for PIC with CRIS v32.  Also add missing leading
space for PIC with non-v32 and the common non-PIC "jump".

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/cris/cris.c

[Bug c/71600] New: [7 regression] test case gcc.dg/gnu89-const-expr-1.c fails starting with r237581

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 71600
   Summary: [7 regression] test case gcc.dg/gnu89-const-expr-1.c
fails starting with r237581
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

FAIL: gcc.dg/gnu89-const-expr-1.c  (test for errors, line 26)

line 26:
E7 = __alignof__ (a), /* { dg-error "__alignof__ \\(expression\\)" } */


This revision changed things so the __alignof__ expression is now valid.  If
that is correct then this test case needs to be updated.

[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

Re: [PATCH] x86-64: Load external function address via GOT slot

[Richard Sandiford]

Uros Bizjak  writes:
> On Mon, Jun 20, 2016 at 9:19 PM, H.J. Lu  wrote:
>> On Mon, Jun 20, 2016 at 12:13 PM, Uros Bizjak  wrote:
>>> On Mon, Jun 20, 2016 at 7:05 PM, H.J. Lu  wrote:
 Hi,

 This patch implements the alternate code sequence recommended in

 https://groups.google.com/forum/#!topic/x86-64-abi/de5_KnLHxtI

 to load external function address via GOT slot with

 movq func@GOTPCREL(%rip), %rax

 so that linker won't create an PLT entry for extern function
 address.

 Tested on x86-64.  OK for trunk?
>>>
 +  else if (ix86_force_load_from_GOT_p (op1))
 +{
 +  /* Load the external function address via the GOT slot to
 +avoid PLT.  */
 +  op1 = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, op1),
 +   (TARGET_64BIT
 +? UNSPEC_GOTPCREL
 +: UNSPEC_GOT));
 +  op1 = gen_rtx_CONST (Pmode, op1);
 +  op1 = gen_const_mem (Pmode, op1);
 +  /* This symbol must be referenced via a load from the Global
 +Offset Table.  */
 +  set_mem_alias_set (op1, ix86_GOT_alias_set ());
 +  op1 = convert_to_mode (mode, op1, 1);
 +  op1 = force_reg (mode, op1);
 +  emit_insn (gen_rtx_SET (op0, op1));
 +  /* Generate a CLOBBER so that there will be no REG_EQUAL note
 +on the last insn to prevent cse and fwprop from replacing
 +a GOT load with a constant.  */
 +  rtx tmp = gen_reg_rtx (Pmode);
 +  emit_clobber (tmp);
 +  return;
>>>
>>> Jeff, is this the recommended way to prevent CSE, as far as RTL
>>> infrastructure is concerned? I didn't find any example of this
>>> approach with other targets.
>>>
>>
>> FWIW, the similar approach is used in ix86_expand_vector_move_misalign,
>> ix86_expand_convert_uns_didf_sse and ix86_expand_vector_init_general
>> as well as other targets:
>>
>> frv/frv.c:  emit_clobber (op0);
>> frv/frv.c:  emit_clobber (op1);
>> im32c/m32c.c:  /*  emit_clobber (gen_rtx_REG (HImode, R0L_REGNO)); */
>> s390/s390.c:  emit_clobber (addr);
>> s390/s390.md:  emit_clobber (reg0);
>> s390/s390.md:  emit_clobber (reg1);
>> s390/s390.md:  emit_clobber (reg0);
>> s390/s390.md:  emit_clobber (reg0);
>> s390/s390.md:  emit_clobber (reg1);
>
> These usages mark the whole register as being "clobbered"
> (=undefined), before only a part of register is written, e.g.:
>
>   emit_clobber (int_xmm);
>   emit_move_insn (gen_lowpart (DImode, int_xmm), input);
>
> They aren't used to prevent unwanted CSE.

Since it's being called in the move expander, I thought the normal
way of preventing the constant being rematerialised would be to reject
it in the move define_insn predicates.

FWIW, I agree that using a clobber for this is going to be fragile.

Thanks,
Richard

[PATCH, i386, AVX-512ER] vrsqrt28ps auto generation

[Ilya Verbin]

Hi!

This patch emits vrsqrt28ps instruction in ix86_emit_swsqrtsf for recip case and
vrcp28ps(vrsqrt28ps(a)) for !recip.
Regtested using various benchmarks on a AVX-512ER machine.  OK for trunk?


gcc/
* config/i386/i386.c (ix86_emit_swsqrtsf): Emit vrsqrt28ps.
* config/i386/sse.md (define_expand "rsqrtv16sf2"): New.
gcc/testsuite/
* gcc.target/i386/avx512er-vrsqrt28ps-3.c: New test.
* gcc.target/i386/avx512er-vrsqrt28ps-4.c: New test.
* gcc.target/i386/avx512er-vrsqrt28ps-5.c: New test.
* gcc.target/i386/avx512er-vrsqrt28ps-6.c: New test.


diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 8e0bf26..edd3d23 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -48722,6 +48722,24 @@ void ix86_emit_swsqrtsf (rtx res, rtx a, machine_mode 
mode, bool recip)
   e2 = gen_reg_rtx (mode);
   e3 = gen_reg_rtx (mode);
 
+  if (TARGET_AVX512ER && mode == V16SFmode)
+{
+  if (recip)
+   /* res = rsqrt28(a) estimate */
+   emit_insn (gen_rtx_SET (res, gen_rtx_UNSPEC (mode, gen_rtvec (1, a),
+UNSPEC_RSQRT28)));
+  else
+   {
+ /* x0 = rsqrt28(a) estimate */
+ emit_insn (gen_rtx_SET (x0, gen_rtx_UNSPEC (mode, gen_rtvec (1, a),
+ UNSPEC_RSQRT28)));
+ /* res = rcp28(x0) estimate */
+ emit_insn (gen_rtx_SET (res, gen_rtx_UNSPEC (mode, gen_rtvec (1, x0),
+  UNSPEC_RCP28)));
+   }
+  return;
+}
+
   real_from_integer (, VOIDmode, -3, SIGNED);
   mthree = const_double_from_real_value (r, SFmode);
 
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 6056ddc..c1ea04f 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -1559,6 +1559,17 @@
   DONE;
 })
 
+(define_expand "rsqrtv16sf2"
+  [(set (match_operand:V16SF 0 "register_operand")
+   (unspec:V16SF
+ [(match_operand:V16SF 1 "vector_operand")]
+ UNSPEC_RSQRT28))]
+  "TARGET_SSE_MATH && TARGET_AVX512ER"
+{
+  ix86_emit_swsqrtsf (operands[0], operands[1], V16SFmode, true);
+  DONE;
+})
+
 (define_insn "_rsqrt2"
   [(set (match_operand:VF1_128_256 0 "register_operand" "=x")
(unspec:VF1_128_256
diff --git a/gcc/testsuite/gcc.target/i386/avx512er-vrsqrt28ps-3.c 
b/gcc/testsuite/gcc.target/i386/avx512er-vrsqrt28ps-3.c
new file mode 100644
index 000..1ba8172
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/avx512er-vrsqrt28ps-3.c
@@ -0,0 +1,47 @@
+/* { dg-do run } */
+/* { dg-require-effective-target avx512er } */
+/* { dg-options "-O2 -ffast-math -ftree-vectorize -mavx512er" } */
+
+#include 
+#include "avx512er-check.h"
+
+#define MAX 1000
+#define EPS 0.1
+
+__attribute__ ((noinline, optimize (1)))
+void static
+compute_rsqrt_ref (float *a, float *r)
+{
+  for (int i = 0; i < MAX; i++)
+r[i] = 1.0 / sqrtf (a[i]);
+}
+
+__attribute__ ((noinline))
+void static
+compute_rsqrt_exp (float *a, float *r)
+{
+  for (int i = 0; i < MAX; i++)
+r[i] = 1.0 / sqrtf (a[i]);
+}
+
+void static
+avx512er_test (void)
+{
+  float in[MAX];
+  float ref[MAX];
+  float exp[MAX];
+
+  for (int i = 0; i < MAX; i++)
+in[i] = 8765.987 - 8.6756 * i;
+
+  compute_rsqrt_ref (in, ref);
+  compute_rsqrt_exp (in, exp);
+
+  for (int i = 0; i < MAX; i++)
+{
+  float rel_err = (ref[i] - exp[i]) / ref[i];
+  rel_err = rel_err > 0.0 ? rel_err : -rel_err;
+  if (rel_err > EPS)
+   abort ();
+}
+}
diff --git a/gcc/testsuite/gcc.target/i386/avx512er-vrsqrt28ps-4.c 
b/gcc/testsuite/gcc.target/i386/avx512er-vrsqrt28ps-4.c
new file mode 100644
index 000..2f5f73f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/avx512er-vrsqrt28ps-4.c
@@ -0,0 +1,7 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -ffast-math -ftree-vectorize -mavx512er" } */
+
+#include "avx512er-vrsqrt28ps-3.c"
+
+/* { dg-final { scan-assembler-times "vrsqrt28ps\[^\n\r\]*zmm\[0-9\]+(?:\n|\[ 
\\t\]+#)" 1 } } */
+/* { dg-final { scan-assembler-not "vrcp28ps\[^\n\r\]*zmm\[0-9\]+(?:\n|\[ 
\\t\]+#)" } } */
diff --git a/gcc/testsuite/gcc.target/i386/avx512er-vrsqrt28ps-5.c 
b/gcc/testsuite/gcc.target/i386/avx512er-vrsqrt28ps-5.c
new file mode 100644
index 000..e067a81
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/avx512er-vrsqrt28ps-5.c
@@ -0,0 +1,47 @@
+/* { dg-do run } */
+/* { dg-require-effective-target avx512er } */
+/* { dg-options "-O2 -ffast-math -ftree-vectorize -mavx512er" } */
+
+#include 
+#include "avx512er-check.h"
+
+#define MAX 1000
+#define EPS 0.1
+
+__attribute__ ((noinline, optimize (1)))
+void static
+compute_sqrt_ref (float *a, float *r)
+{
+  for (int i = 0; i < MAX; i++)
+r[i] = sqrtf (a[i]);
+}
+
+__attribute__ ((noinline))
+void static
+compute_sqrt_exp (float *a, float *r)
+{
+  for (int i = 0; i < MAX; i++)
+r[i] = sqrtf (a[i]);
+}
+
+void static
+avx512er_test (void)
+{
+  float in[MAX];
+  float ref[MAX];

Re: [PATCH 0/7] remove targets obsoleted in gcc 6

[Jeff Law]

On 06/19/2016 11:47 PM, tbsaunde+...@tbsaunde.org wrote:

From: Trevor Saunders 

Hi,

later than I hoped, but here's the series to remove the targets obsoleted
during gcc 6.

I built and regtested the series as one patch on x86_64-linux-gnu without
regressions, ok?

Trev


Trevor Saunders (7):
  remove support for the interix target
  remove support for targeting openbsd 2 or 3
  remove knetbsd support
  remove h8300-rtems support
  remove m32-rtems support
  remove avr-rtems support
  remove mep-* support

OK for the whole series.

hpux10.* as a host & target would seem ripe for obsoleting as well. 
Though you might check with John first.


Another "special" system we might consider obsoleting would be lynxos. 
I think those have been dead a decade or longer.  I'm not even sure who 
to ask about them anymore.


Jeff

Re: [PATCH, i386, AVX-512ER] vrsqrt28ps auto generation

[Uros Bizjak]

On Mon, Jun 20, 2016 at 9:35 PM, Ilya Verbin  wrote:
> Hi!
>
> This patch emits vrsqrt28ps instruction in ix86_emit_swsqrtsf for recip case 
> and
> vrcp28ps(vrsqrt28ps(a)) for !recip.
> Regtested using various benchmarks on a AVX-512ER machine.  OK for trunk?
>
>
> gcc/
> * config/i386/i386.c (ix86_emit_swsqrtsf): Emit vrsqrt28ps.
> * config/i386/sse.md (define_expand "rsqrtv16sf2"): New.
> gcc/testsuite/
> * gcc.target/i386/avx512er-vrsqrt28ps-3.c: New test.
> * gcc.target/i386/avx512er-vrsqrt28ps-4.c: New test.
> * gcc.target/i386/avx512er-vrsqrt28ps-5.c: New test.
> * gcc.target/i386/avx512er-vrsqrt28ps-6.c: New test.

OK.

Thanks,
Uros.

>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 8e0bf26..edd3d23 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -48722,6 +48722,24 @@ void ix86_emit_swsqrtsf (rtx res, rtx a, 
> machine_mode mode, bool recip)
>e2 = gen_reg_rtx (mode);
>e3 = gen_reg_rtx (mode);
>
> +  if (TARGET_AVX512ER && mode == V16SFmode)
> +{
> +  if (recip)
> +   /* res = rsqrt28(a) estimate */
> +   emit_insn (gen_rtx_SET (res, gen_rtx_UNSPEC (mode, gen_rtvec (1, a),
> +UNSPEC_RSQRT28)));
> +  else
> +   {
> + /* x0 = rsqrt28(a) estimate */
> + emit_insn (gen_rtx_SET (x0, gen_rtx_UNSPEC (mode, gen_rtvec (1, a),
> + UNSPEC_RSQRT28)));
> + /* res = rcp28(x0) estimate */
> + emit_insn (gen_rtx_SET (res, gen_rtx_UNSPEC (mode, gen_rtvec (1, 
> x0),
> +  UNSPEC_RCP28)));
> +   }
> +  return;
> +}
> +
>real_from_integer (, VOIDmode, -3, SIGNED);
>mthree = const_double_from_real_value (r, SFmode);
>
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index 6056ddc..c1ea04f 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -1559,6 +1559,17 @@
>DONE;
>  })
>
> +(define_expand "rsqrtv16sf2"
> +  [(set (match_operand:V16SF 0 "register_operand")
> +   (unspec:V16SF
> + [(match_operand:V16SF 1 "vector_operand")]
> + UNSPEC_RSQRT28))]
> +  "TARGET_SSE_MATH && TARGET_AVX512ER"
> +{
> +  ix86_emit_swsqrtsf (operands[0], operands[1], V16SFmode, true);
> +  DONE;
> +})
> +
>  (define_insn "_rsqrt2"
>[(set (match_operand:VF1_128_256 0 "register_operand" "=x")
> (unspec:VF1_128_256
> diff --git a/gcc/testsuite/gcc.target/i386/avx512er-vrsqrt28ps-3.c 
> b/gcc/testsuite/gcc.target/i386/avx512er-vrsqrt28ps-3.c
> new file mode 100644
> index 000..1ba8172
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/avx512er-vrsqrt28ps-3.c
> @@ -0,0 +1,47 @@
> +/* { dg-do run } */
> +/* { dg-require-effective-target avx512er } */
> +/* { dg-options "-O2 -ffast-math -ftree-vectorize -mavx512er" } */
> +
> +#include 
> +#include "avx512er-check.h"
> +
> +#define MAX 1000
> +#define EPS 0.1
> +
> +__attribute__ ((noinline, optimize (1)))
> +void static
> +compute_rsqrt_ref (float *a, float *r)
> +{
> +  for (int i = 0; i < MAX; i++)
> +r[i] = 1.0 / sqrtf (a[i]);
> +}
> +
> +__attribute__ ((noinline))
> +void static
> +compute_rsqrt_exp (float *a, float *r)
> +{
> +  for (int i = 0; i < MAX; i++)
> +r[i] = 1.0 / sqrtf (a[i]);
> +}
> +
> +void static
> +avx512er_test (void)
> +{
> +  float in[MAX];
> +  float ref[MAX];
> +  float exp[MAX];
> +
> +  for (int i = 0; i < MAX; i++)
> +in[i] = 8765.987 - 8.6756 * i;
> +
> +  compute_rsqrt_ref (in, ref);
> +  compute_rsqrt_exp (in, exp);
> +
> +  for (int i = 0; i < MAX; i++)
> +{
> +  float rel_err = (ref[i] - exp[i]) / ref[i];
> +  rel_err = rel_err > 0.0 ? rel_err : -rel_err;
> +  if (rel_err > EPS)
> +   abort ();
> +}
> +}
> diff --git a/gcc/testsuite/gcc.target/i386/avx512er-vrsqrt28ps-4.c 
> b/gcc/testsuite/gcc.target/i386/avx512er-vrsqrt28ps-4.c
> new file mode 100644
> index 000..2f5f73f
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/avx512er-vrsqrt28ps-4.c
> @@ -0,0 +1,7 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -ffast-math -ftree-vectorize -mavx512er" } */
> +
> +#include "avx512er-vrsqrt28ps-3.c"
> +
> +/* { dg-final { scan-assembler-times 
> "vrsqrt28ps\[^\n\r\]*zmm\[0-9\]+(?:\n|\[ \\t\]+#)" 1 } } */
> +/* { dg-final { scan-assembler-not "vrcp28ps\[^\n\r\]*zmm\[0-9\]+(?:\n|\[ 
> \\t\]+#)" } } */
> diff --git a/gcc/testsuite/gcc.target/i386/avx512er-vrsqrt28ps-5.c 
> b/gcc/testsuite/gcc.target/i386/avx512er-vrsqrt28ps-5.c
> new file mode 100644
> index 000..e067a81
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/avx512er-vrsqrt28ps-5.c
> @@ -0,0 +1,47 @@
> +/* { dg-do run } */
> +/* { dg-require-effective-target avx512er } */
> +/* { dg-options "-O2 -ffast-math -ftree-vectorize -mavx512er" } */
> +
> +#include 
> +#include "avx512er-check.h"
> +
> +#define MAX 1000
> +#define 

Re: _Bool and trap representations

[Martin Sebor]

On 06/17/2016 02:19 PM, Alexander Cherepanov wrote:

On 2016-06-15 17:15, Martin Sebor wrote:

There has been quite a bit of discussion among the committee on
this subject lately (the last part is the subject of DR #451,
though it's discussed in the context of uninitialized objects
with indeterminate values).


Are there notes from these discussions or something?


Notes from discussions during committee meetings are in the meeting
minutes that are posted along with other committee documents on the
public site.   Those that relate to aspects of defect reports are
usually captured in the Committee Discussion and Committee Response
to the DR.  Other than that, committee discussions that take place
on the committee mailing list (such as the recent ones on this topic)
are archived for reference of committee members (unlike C++, the C
archives are not intended to be open to the public).


So it seems the discussion you referred to is not public, that's
unfortunate.

And to clarify what you wrote about stability of valid representations,
is padding expected to be stable when it's not specifically set? I.e. is
the following optimization supposed to be conforming or not?


The standard says that padding bytes take on unspecified values
after an assignment to a structure, so the program isn't strictly
conforming because its output depends on such a value.  At the
same time, unspecified values are, in general, expected to be
stable.  But I think in this case it's only because of the
standard's limited vocabulary.  The distinction between
an unspecified and undefined value was meant to allow for the
latter to be a trap representation.  But lately an undefined
value has also come to mean potentially unstable (some people
call such values "wobbly").  If the standard adopted a term
for unspecified values that don't need not be stable (say
wobbly) I would expect the committee to be comfortable applying
it padding bits and allowing the code in the example to produce
two different lines.  But this is one of the topics still under
active discussion.

Martin



Source code:

--
#include 

int main(int argc, char **argv)
{
   (void)argv;

   struct { char c; int i; } s = {0, 0};

   printf("%d\n", argc ? ((unsigned char *))[1] : 5);
   printf("%d\n", argc ? ((unsigned char *))[1] : 7);
}
--

Results:

--
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
5
7
--

gcc version: gcc (GCC) 7.0.0 20160616 (experimental)

Of course, clang does essentially the same but the testcase is a bit
more involved (I can post it if somebody is interested). OTOH clang is
more predictable in this area because rules for dealing with undefined
values in llvm are more-or-less documented --
http://llvm.org/docs/LangRef.html#undefined-values .

I don't see gcc treating padding in long double as indeterminate in the
same way as in structs but clang seems to treat them equally.

Re: [PATCH] x86-64: Load external function address via GOT slot

[Uros Bizjak]

On Mon, Jun 20, 2016 at 9:19 PM, H.J. Lu  wrote:
> On Mon, Jun 20, 2016 at 12:13 PM, Uros Bizjak  wrote:
>> On Mon, Jun 20, 2016 at 7:05 PM, H.J. Lu  wrote:
>>> Hi,
>>>
>>> This patch implements the alternate code sequence recommended in
>>>
>>> https://groups.google.com/forum/#!topic/x86-64-abi/de5_KnLHxtI
>>>
>>> to load external function address via GOT slot with
>>>
>>> movq func@GOTPCREL(%rip), %rax
>>>
>>> so that linker won't create an PLT entry for extern function
>>> address.
>>>
>>> Tested on x86-64.  OK for trunk?
>>
>>> +  else if (ix86_force_load_from_GOT_p (op1))
>>> +{
>>> +  /* Load the external function address via the GOT slot to
>>> +avoid PLT.  */
>>> +  op1 = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, op1),
>>> +   (TARGET_64BIT
>>> +? UNSPEC_GOTPCREL
>>> +: UNSPEC_GOT));
>>> +  op1 = gen_rtx_CONST (Pmode, op1);
>>> +  op1 = gen_const_mem (Pmode, op1);
>>> +  /* This symbol must be referenced via a load from the Global
>>> +Offset Table.  */
>>> +  set_mem_alias_set (op1, ix86_GOT_alias_set ());
>>> +  op1 = convert_to_mode (mode, op1, 1);
>>> +  op1 = force_reg (mode, op1);
>>> +  emit_insn (gen_rtx_SET (op0, op1));
>>> +  /* Generate a CLOBBER so that there will be no REG_EQUAL note
>>> +on the last insn to prevent cse and fwprop from replacing
>>> +a GOT load with a constant.  */
>>> +  rtx tmp = gen_reg_rtx (Pmode);
>>> +  emit_clobber (tmp);
>>> +  return;
>>
>> Jeff, is this the recommended way to prevent CSE, as far as RTL
>> infrastructure is concerned? I didn't find any example of this
>> approach with other targets.
>>
>
> FWIW, the similar approach is used in ix86_expand_vector_move_misalign,
> ix86_expand_convert_uns_didf_sse and ix86_expand_vector_init_general
> as well as other targets:
>
> frv/frv.c:  emit_clobber (op0);
> frv/frv.c:  emit_clobber (op1);
> im32c/m32c.c:  /*  emit_clobber (gen_rtx_REG (HImode, R0L_REGNO)); */
> s390/s390.c:  emit_clobber (addr);
> s390/s390.md:  emit_clobber (reg0);
> s390/s390.md:  emit_clobber (reg1);
> s390/s390.md:  emit_clobber (reg0);
> s390/s390.md:  emit_clobber (reg0);
> s390/s390.md:  emit_clobber (reg1);

These usages mark the whole register as being "clobbered"
(=undefined), before only a part of register is written, e.g.:

  emit_clobber (int_xmm);
  emit_move_insn (gen_lowpart (DImode, int_xmm), input);

They aren't used to prevent unwanted CSE.

Uros.

Re: [PATCH] config-list.mk AIX update

[Jeff Law]

On 06/20/2016 12:13 PM, David Edelsohn wrote:

This patch removes obsolete AIX 4.3, 5.1 and 5.2 configurations and
adds AIX 7.1 configuration.  GCC does not yet differentiate AIX 7.2,
so I did not include it.

Okay?

Thanks, David

* config-list.mk: Remove rs6000-ibm-aix4.3, rs6000-ibm-aix5.1,
rs6000-ibm-aix5.2.
Rename rs6000-ibm-aix6.0 as rs6000-ibm-aix6.1.  Add rs6000-ibm-aix7.1.
I'd think this falls under aix & ppc maintainership, so you can/should 
self-approve ;-)


jeff

[Bug c++/71599] An extra unrelated move when compiling compare_exchange_strong

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
Dup of bug 66867.

*** This bug has been marked as a duplicate of bug 66867 ***

[Bug middle-end/66713] atomic compare_exchange_strong creates spurious store for x86-64 at -O3

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Andrew Pinski  ---
Dup of bug 66867.

*** This bug has been marked as a duplicate of bug 66867 ***

[Bug middle-end/66867] Suboptimal code generation for atomic_compare_exchange

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||tkoeppe at google dot com

--- Comment #5 from Andrew Pinski  ---
*** Bug 66713 has been marked as a duplicate of this bug. ***

[Bug middle-end/66867] Suboptimal code generation for atomic_compare_exchange

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||dhowells at redhat dot com

--- Comment #4 from Andrew Pinski  ---
*** Bug 70825 has been marked as a duplicate of this bug. ***

[Bug middle-end/66867] Suboptimal code generation for atomic_compare_exchange

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jianjin2016 at fb dot com

--- Comment #6 from Andrew Pinski  ---
*** Bug 71599 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/70825] x86_64: __atomic_compare_exchange_n() accesses stack unnecessarily

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Andrew Pinski  ---
Dup of bug 66867.

*** This bug has been marked as a duplicate of bug 66867 ***

Re: [PATCH] x86-64: Load external function address via GOT slot

[H.J. Lu]

On Mon, Jun 20, 2016 at 12:13 PM, Uros Bizjak  wrote:
> On Mon, Jun 20, 2016 at 7:05 PM, H.J. Lu  wrote:
>> Hi,
>>
>> This patch implements the alternate code sequence recommended in
>>
>> https://groups.google.com/forum/#!topic/x86-64-abi/de5_KnLHxtI
>>
>> to load external function address via GOT slot with
>>
>> movq func@GOTPCREL(%rip), %rax
>>
>> so that linker won't create an PLT entry for extern function
>> address.
>>
>> Tested on x86-64.  OK for trunk?
>
>> +  else if (ix86_force_load_from_GOT_p (op1))
>> +{
>> +  /* Load the external function address via the GOT slot to
>> +avoid PLT.  */
>> +  op1 = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, op1),
>> +   (TARGET_64BIT
>> +? UNSPEC_GOTPCREL
>> +: UNSPEC_GOT));
>> +  op1 = gen_rtx_CONST (Pmode, op1);
>> +  op1 = gen_const_mem (Pmode, op1);
>> +  /* This symbol must be referenced via a load from the Global
>> +Offset Table.  */
>> +  set_mem_alias_set (op1, ix86_GOT_alias_set ());
>> +  op1 = convert_to_mode (mode, op1, 1);
>> +  op1 = force_reg (mode, op1);
>> +  emit_insn (gen_rtx_SET (op0, op1));
>> +  /* Generate a CLOBBER so that there will be no REG_EQUAL note
>> +on the last insn to prevent cse and fwprop from replacing
>> +a GOT load with a constant.  */
>> +  rtx tmp = gen_reg_rtx (Pmode);
>> +  emit_clobber (tmp);
>> +  return;
>
> Jeff, is this the recommended way to prevent CSE, as far as RTL
> infrastructure is concerned? I didn't find any example of this
> approach with other targets.
>

FWIW, the similar approach is used in ix86_expand_vector_move_misalign,
ix86_expand_convert_uns_didf_sse and ix86_expand_vector_init_general
as well as other targets:

frv/frv.c:  emit_clobber (op0);
frv/frv.c:  emit_clobber (op1);
im32c/m32c.c:  /*  emit_clobber (gen_rtx_REG (HImode, R0L_REGNO)); */
s390/s390.c:  emit_clobber (addr);
s390/s390.md:  emit_clobber (reg0);
s390/s390.md:  emit_clobber (reg1);
s390/s390.md:  emit_clobber (reg0);
s390/s390.md:  emit_clobber (reg0);
s390/s390.md:  emit_clobber (reg1);


-- 
H.J.

[Bug target/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jun 20 19:17:12 2016
New Revision: 237614

URL: https://gcc.gnu.org/viewcvs?rev=237614=gcc=rev
Log:
PR target/71559
* config/i386/i386.c (ix86_fp_cmp_code_to_pcmp_immediate): Fix up
returned values and add UN*/LTGT/*ORDERED cases with values matching
D operand modifier on vcmp for AVX.

* gcc.target/i386/sse2-pr71559.c: New test.
* gcc.target/i386/avx-pr71559.c: New test.
* gcc.target/i386/avx512f-pr71559.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx-pr71559.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-pr71559.c
trunk/gcc/testsuite/gcc.target/i386/sse2-pr71559.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

Re: [PATCH] c++/60760 - arithmetic on null pointers should not be allowed in constant expressions

[Martin Sebor]

+  if (TREE_CODE (whole) == INDIRECT_REF
+  && integer_zerop (TREE_OPERAND (whole, 0))
+  && !ctx->quiet)
+error ("dereferencing a null pointer in %qE", orig_whole);



+  if (TREE_CODE (t) == INTEGER_CST
+  && TREE_CODE (TREE_TYPE (t)) == POINTER_TYPE
+  && !integer_zerop (t))
+{
+  if (!ctx->quiet)
+error ("arithmetic involving a null pointer in %qE", t);
+}


These places should all set *non_constant_p, and the second should
return t after doing so.  OK with that change.


Some additional testing exposed a couple of bugs in the patch.
First, adding or subtracting a constant zero to or from a null
pointer is valid (it was rejected with the previous patch).
Second, the code in cxx_eval_constant_expression that tried
to detect invalid conversions didn't handle qualifiers
correctly in all cases, causing conversions that add constness
to be rejected.  Finally, while fixing these issues I decided
that dereferencing and indirecting through null pointers would
be more appropriately handled in the functions that deal with
those expressions rather than in cxx_eval_constant_expression.

Since the updates aren't completely trivial I post the new
version of the patch for another review before committing it.

Thanks
Martin

PR c++/60760 - arithmetic on null pointers should not be allowed in constant
  expressions
PR c++/71091 - constexpr reference bound to a null pointer dereference
   accepted

gcc/cp/ChangeLog:
2016-06-20  Martin Sebor  

	PR c++/60760
	PR c++/71091
	* constexpr.c (cxx_eval_binary_expression): Reject invalid expressions
	involving null pointers.
	(cxx_eval_component_reference): Reject null pointer dereferences.
	(cxx_eval_indirect_ref): Reject indirecting through null pointers.
	(cxx_eval_constant_expression): Reject invalid expressions involving
	null pointers.

gcc/testsuite/ChangeLog:
2016-06-20  Martin Sebor  

	PR c++/60760
	PR c++/71091
	* g++.dg/cpp0x/constexpr-nullptr-2.C: New test.
	* g++.dg/cpp1y/constexpr-sfinae.C: Correct.
	* g++.dg/ubsan/pr63956.C: Correct.

Index: gcc/cp/constexpr.c
===
--- gcc/cp/constexpr.c	(revision 237582)
+++ gcc/cp/constexpr.c	(working copy)
@@ -1811,6 +1811,14 @@ cxx_eval_binary_expression (const constexpr_ctx *c
 		   || null_member_pointer_value_p (rhs)))
 	r = constant_boolean_node (!is_code_eq, type);
 }
+  if (code == POINTER_PLUS_EXPR && !*non_constant_p
+  && tree_int_cst_equal (lhs, null_pointer_node)
+  && !tree_int_cst_equal (rhs, integer_zero_node))
+{
+  if (!ctx->quiet)
+error ("arithmetic involving a null pointer in %qE", lhs);
+  return t;
+}
 
   if (r == NULL_TREE)
 r = fold_binary_loc (loc, code, type, lhs, rhs);
@@ -2151,6 +2159,11 @@ cxx_eval_component_reference (const constexpr_ctx
   tree whole = cxx_eval_constant_expression (ctx, orig_whole,
 	 lval,
 	 non_constant_p, overflow_p);
+  if (TREE_CODE (whole) == INDIRECT_REF
+  && integer_zerop (TREE_OPERAND (whole, 0))
+  && !ctx->quiet)
+error ("dereferencing a null pointer in %qE", orig_whole);
+
   if (TREE_CODE (whole) == PTRMEM_CST)
 whole = cplus_expand_constant (whole);
   if (whole == orig_whole)
@@ -2911,6 +2924,14 @@ cxx_eval_indirect_ref (const constexpr_ctx *ctx, t
   if (*non_constant_p)
 	return t;
 
+  if (integer_zerop (op0))
+	{
+	  if (!ctx->quiet)
+	error ("dereferencing a null pointer");
+	  *non_constant_p = true;
+	  return t;
+	}
+
   r = cxx_fold_indirect_ref (EXPR_LOCATION (t), TREE_TYPE (t), op0,
  _base);
   if (r == NULL_TREE)
@@ -3559,10 +3580,20 @@ cxx_eval_constant_expression (const constexpr_ctx
 	  if (!flag_permissive || ctx->quiet)
 	*overflow_p = true;
 	}
+
+  if (TREE_CODE (t) == INTEGER_CST
+  && TREE_CODE (TREE_TYPE (t)) == POINTER_TYPE
+  && !integer_zerop (t))
+{
+  if (!ctx->quiet)
+error ("arithmetic involving a null pointer in %qE", t);
+}
+
   return t;
 }
 
-  switch (TREE_CODE (t))
+  tree_code tcode = TREE_CODE (t);
+  switch (tcode)
 {
 case RESULT_DECL:
   if (lval)
@@ -3973,7 +4004,6 @@ cxx_eval_constant_expression (const constexpr_ctx
 case NOP_EXPR:
 case UNARY_PLUS_EXPR:
   {
-	enum tree_code tcode = TREE_CODE (t);
 	tree oldop = TREE_OPERAND (t, 0);
 
 	tree op = cxx_eval_constant_expression (ctx, oldop,
@@ -3999,15 +4029,43 @@ cxx_eval_constant_expression (const constexpr_ctx
 		return t;
 	  }
 	  }
-	if (POINTER_TYPE_P (type)
-	&& TREE_CODE (op) == INTEGER_CST
-	&& !integer_zerop (op))
-	  {
-	if (!ctx->quiet)
-	  error_at (EXPR_LOC_OR_LOC (t, input_location),
-			"reinterpret_cast from integer to pointer");
-	*non_constant_p = true;
-	return t;
+	if (POINTER_TYPE_P (type) && TREE_CODE (op) == INTEGER_CST)
+  {
+	if (integer_zerop (op))
+	  

Re: [PATCH] x86-64: Load external function address via GOT slot

[Uros Bizjak]

On Mon, Jun 20, 2016 at 7:05 PM, H.J. Lu  wrote:
> Hi,
>
> This patch implements the alternate code sequence recommended in
>
> https://groups.google.com/forum/#!topic/x86-64-abi/de5_KnLHxtI
>
> to load external function address via GOT slot with
>
> movq func@GOTPCREL(%rip), %rax
>
> so that linker won't create an PLT entry for extern function
> address.
>
> Tested on x86-64.  OK for trunk?

> +  else if (ix86_force_load_from_GOT_p (op1))
> +{
> +  /* Load the external function address via the GOT slot to
> +avoid PLT.  */
> +  op1 = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, op1),
> +   (TARGET_64BIT
> +? UNSPEC_GOTPCREL
> +: UNSPEC_GOT));
> +  op1 = gen_rtx_CONST (Pmode, op1);
> +  op1 = gen_const_mem (Pmode, op1);
> +  /* This symbol must be referenced via a load from the Global
> +Offset Table.  */
> +  set_mem_alias_set (op1, ix86_GOT_alias_set ());
> +  op1 = convert_to_mode (mode, op1, 1);
> +  op1 = force_reg (mode, op1);
> +  emit_insn (gen_rtx_SET (op0, op1));
> +  /* Generate a CLOBBER so that there will be no REG_EQUAL note
> +on the last insn to prevent cse and fwprop from replacing
> +a GOT load with a constant.  */
> +  rtx tmp = gen_reg_rtx (Pmode);
> +  emit_clobber (tmp);
> +  return;

Jeff, is this the recommended way to prevent CSE, as far as RTL
infrastructure is concerned? I didn't find any example of this
approach with other targets.

Uros.

Re: [PATCH] Fix ix86_fp_cmp_code_to_pcmp_immediate (PR target/71559)

[Jakub Jelinek]

On Mon, Jun 20, 2016 at 09:04:26PM +0200, Uros Bizjak wrote:
> OK for mainline and release branches after a week or so without
> problems in mainline.

Ok, thanks.

> (I tried to review usage of all those bits, LGTM, but mistakes can happen...)

I really hope the testcase should double check all that,
ix86_fp_cmp_code_to_pcmp_immediate is run with it on all the listed codes
except LTGT, and the expected results were written independently from the
tables and are also checked with SSE2 and AVX implementations.
When I've limited the testcase to the functions with only
EQ/NE/GT/LE/GE/LT, the testcase doesn't ICE, but aborted under the AVX512F
emulator.

Jakub

[Bug rtl-optimization/65628] valgrind error in improve_allocation

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WORKSFORME  |---

--- Comment #5 from David Binderman  ---
>David, in the future please use an --enable-checking=valgrind compiler
>for valgrind testing.

Righto. I tried a build of today's (20160620) gcc trunk with this flag you
recommend.

I got

==16199== Conditional jump or move depends on uninitialised value(s)
==16199==at 0x89001C: improve_allocation() (ira-color.c:2809)
==16199==by 0x893F3E: color_allocnos (ira-color.c:3140)
==16199==by 0x893F3E: color_pass(ira_loop_tree_node*) (ira-color.c:3249)
==16199==by 0x87D136: ira_traverse_loop_tree(bool, ira_loop_tree_node*,
void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*))
(ira-build.c:1780)

Source code is

  if ((hregno = ALLOCNO_HARD_REGNO (a)) < 0)

So it looks to me like the problem is still there.
Configure line is 

../src/trunk/configure --prefix=/home/dcb/gcc/results \
--disable-bootstrap \
--disable-multilib \
--disable-werror \
--enable-checking=valgrind \
--enable-languages=c,c++,fortran 

And it looks like -O3 needs to be switched on in the build.
At the top level Makefile:

sed 's/-O2/-O3 -march=native -Wall -Wlogical-op/' < Makefile > Makefile.tmp
mv Makefile.tmp Makefile

Although I guess make target bootstrap-O3 would also provoke this valgrind
error.

Re: [PATCH, i386, AVX-512ER] vrcp28ps auto generation

[Uros Bizjak]

On Mon, Jun 20, 2016 at 7:09 PM, Ilya Verbin  wrote:
> Hi!
>
> This patch emits vrcp28ps and vmulps istructions for ix86_emit_swdivsf.
> The relative error is < 2^-23, so no additional iteration is necessary.
> Regtested using various benchmarks on a AVX-512ER machine.  OK for trunk?
>
>
> gcc/
> * config/i386/i386.c (ix86_emit_swdivsf): Emit vrcp28ps.
> gcc/testsuite/
> * gcc.target/i386/avx512er-vrcp28ps-3.c: New test.
> * gcc.target/i386/avx512er-vrcp28ps-4.c: New test.

OK.

Thanks,
Uros.

>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 56a5b9c..8e0bf26 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -48674,8 +48674,19 @@ void ix86_emit_swdivsf (rtx res, rtx a, rtx b, 
> machine_mode mode)
>
>/* x0 = rcp(b) estimate */
>if (mode == V16SFmode || mode == V8DFmode)
> -emit_insn (gen_rtx_SET (x0, gen_rtx_UNSPEC (mode, gen_rtvec (1, b),
> -   UNSPEC_RCP14)));
> +{
> +  if (TARGET_AVX512ER)
> +   {
> + emit_insn (gen_rtx_SET (x0, gen_rtx_UNSPEC (mode, gen_rtvec (1, b),
> + UNSPEC_RCP28)));
> + /* res = a * x0 */
> + emit_insn (gen_rtx_SET (res, gen_rtx_MULT (mode, a, x0)));
> + return;
> +   }
> +  else
> +   emit_insn (gen_rtx_SET (x0, gen_rtx_UNSPEC (mode, gen_rtvec (1, b),
> +   UNSPEC_RCP14)));
> +}
>else
>  emit_insn (gen_rtx_SET (x0, gen_rtx_UNSPEC (mode, gen_rtvec (1, b),
> UNSPEC_RCP)));
> diff --git a/gcc/testsuite/gcc.target/i386/avx512er-vrcp28ps-3.c 
> b/gcc/testsuite/gcc.target/i386/avx512er-vrcp28ps-3.c
> new file mode 100644
> index 000..e08bea4
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/avx512er-vrcp28ps-3.c
> @@ -0,0 +1,50 @@
> +/* { dg-do run } */
> +/* { dg-require-effective-target avx512er } */
> +/* { dg-options "-O2 -ffast-math -ftree-vectorize -mavx512er" } */
> +
> +#include "avx512er-check.h"
> +
> +#define MAX 1000
> +#define EPS 0.1
> +
> +__attribute__ ((noinline, optimize (0)))
> +void static
> +compute_rcp_ref (float *a, float *b, float *r)
> +{
> +  for (int i = 0; i < MAX; i++)
> +r[i] = a[i] / b[i];
> +}
> +
> +__attribute__ ((noinline))
> +void static
> +compute_rcp_exp (float *a, float *b, float *r)
> +{
> +  for (int i = 0; i < MAX; i++)
> +r[i] = a[i] / b[i];
> +}
> +
> +void static
> +avx512er_test (void)
> +{
> +  float a[MAX];
> +  float b[MAX];
> +  float ref[MAX];
> +  float exp[MAX];
> +
> +  for (int i = 0; i < MAX; i++)
> +{
> +  a[i] = 179.345 - 6.5645 * i;
> +  b[i] = 8765.987 - 8.6756 * i;
> +}
> +
> +  compute_rcp_ref (a, b, ref);
> +  compute_rcp_exp (a, b, exp);
> +
> +  for (int i = 0; i < MAX; i++)
> +{
> +  float rel_err = (ref[i] - exp[i]) / ref[i];
> +  rel_err = rel_err > 0.0 ? rel_err : -rel_err;
> +  if (rel_err > EPS)
> +   abort ();
> +}
> +}
> diff --git a/gcc/testsuite/gcc.target/i386/avx512er-vrcp28ps-4.c 
> b/gcc/testsuite/gcc.target/i386/avx512er-vrcp28ps-4.c
> new file mode 100644
> index 000..2c76d96
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/avx512er-vrcp28ps-4.c
> @@ -0,0 +1,6 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -ffast-math -ftree-vectorize -mavx512er" } */
> +
> +#include "avx512er-vrcp28ps-3.c"
> +
> +/* { dg-final { scan-assembler-times "vrcp28ps\[^\n\r\]*zmm\[0-9\]+(?:\n|\[ 
> \\t\]+#)" 1 } } */
>
>
>   -- Ilya

Re: [PATCH] Fix ix86_fp_cmp_code_to_pcmp_immediate (PR target/71559)

[Uros Bizjak]

On Mon, Jun 20, 2016 at 8:31 PM, Jakub Jelinek  wrote:
> Hi!
>
> As discussed in the PR, this function is missing a lot of comparison codes
> that can validly appear there, and gives wrong values for the others
> except for NE.
> This patch makes those values match what %D3 emits for the AVX vcmp*p{s,d},
> there is some controversy on whether UN{GT,GE,LT,LE,EQ} and/or LTGT should
> raise exceptions or not, but that should be handled later on also together
> with the scalar code (where we never raise exceptions), SSE, AVX and this.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/6.2?
>
> 2016-06-20  Jakub Jelinek  
>
> PR target/71559
> * config/i386/i386.c (ix86_fp_cmp_code_to_pcmp_immediate): Fix up
> returned values and add UN*/LTGT/*ORDERED cases with values matching
> D operand modifier on vcmp for AVX.
>
> * gcc.target/i386/sse2-pr71559.c: New test.
> * gcc.target/i386/avx-pr71559.c: New test.
> * gcc.target/i386/avx512f-pr71559.c: New test.

OK for mainline and release branches after a week or so without
problems in mainline.

(I tried to review usage of all those bits, LGTM, but mistakes can happen...)

Thanks,
Uros.

> --- gcc/config/i386/i386.c.jj   2016-06-20 10:36:29.489994876 +0200
> +++ gcc/config/i386/i386.c  2016-06-20 12:07:37.311006144 +0200
> @@ -23622,17 +23622,33 @@ ix86_fp_cmp_code_to_pcmp_immediate (enum
>switch (code)
>  {
>  case EQ:
> -  return 0x08;
> +  return 0x00;
>  case NE:
>return 0x04;
>  case GT:
> -  return 0x16;
> +  return 0x0e;
>  case LE:
> -  return 0x1a;
> +  return 0x02;
>  case GE:
> -  return 0x15;
> +  return 0x0d;
>  case LT:
> -  return 0x19;
> +  return 0x01;
> +case UNLE:
> +  return 0x0a;
> +case UNLT:
> +  return 0x09;
> +case UNGE:
> +  return 0x05;
> +case UNGT:
> +  return 0x06;
> +case UNEQ:
> +  return 0x18;
> +case LTGT:
> +  return 0x0c;
> +case ORDERED:
> +  return 0x07;
> +case UNORDERED:
> +  return 0x03;
>  default:
>gcc_unreachable ();
>  }
> --- gcc/testsuite/gcc.target/i386/sse2-pr71559.c.jj 2016-06-20 
> 12:10:27.621795187 +0200
> +++ gcc/testsuite/gcc.target/i386/sse2-pr71559.c2016-06-20 
> 12:14:44.821457893 +0200
> @@ -0,0 +1,73 @@
> +/* PR target/71559 */
> +/* { dg-do run { target sse2 } } */
> +/* { dg-options "-O2 -ftree-vectorize -msse2" } */
> +
> +#ifndef PR71559_TEST
> +#include "sse2-check.h"
> +#define PR71559_TEST sse2_test
> +#endif
> +
> +#define N 16
> +float a[N] = { 5.0f, -3.0f, 1.0f, __builtin_nanf (""), 9.0f, 7.0f, -3.0f, 
> -9.0f,
> +   -3.0f, -5.0f, -9.0f, __builtin_nanf (""), 0.5f, -0.5f, 0.0f, 
> 0.0f };
> +float b[N] = { -5.0f, 3.0f, 1.0f, 7.0f, 8.0f, 8.0f, -3.0f, __builtin_nanf 
> (""),
> +   -4.0f, -4.0f, -9.0f, __builtin_nanf (""), 0.0f, 0.0f, 0.0f, 
> __builtin_nanf ("") };
> +int c[N], d[N];
> +
> +#define FN(name, op) \
> +void   \
> +name (void)\
> +{  \
> +  int i;   \
> +  for (i = 0; i < N; i++)  \
> +c[i] = (op || d[i] > 37) ? 5 : 32; \
> +}
> +FN (eq, a[i] == b[i])
> +FN (ne, a[i] != b[i])
> +FN (gt, a[i] > b[i])
> +FN (ge, a[i] >= b[i])
> +FN (lt, a[i] < b[i])
> +FN (le, a[i] <= b[i])
> +FN (unle, !__builtin_isgreater (a[i], b[i]))
> +FN (unlt, !__builtin_isgreaterequal (a[i], b[i]))
> +FN (unge, !__builtin_isless (a[i], b[i]))
> +FN (ungt, !__builtin_islessequal (a[i], b[i]))
> +FN (uneq, !__builtin_islessgreater (a[i], b[i]))
> +FN (ordered, !__builtin_isunordered (a[i], b[i]))
> +FN (unordered, __builtin_isunordered (a[i], b[i]))
> +
> +#define TEST(name, GT, LT, EQ, UO) \
> +  name (); \
> +  for (i = 0; i < N; i++)  \
> +{  \
> +  int v;   \
> +  switch (i % 4)   \
> +   {   \
> +   case 0: v = GT ? 5 : 32; break; \
> +   case 1: v = LT ? 5 : 32; break; \
> +   case 2: v = EQ ? 5 : 32; break; \
> +   case 3: v = UO ? 5 : 32; break; \
> +   }   \
> +  if (c[i] != v)   \
> +   __builtin_abort (); \
> +}
> +
> +void
> +PR71559_TEST (void)
> +{
> +  int i;
> +  asm volatile ("" : : "g" (a), "g" (b), "g" (c), "g" (d) : "memory");
> +  TEST (eq, 0, 0, 1, 0)
> +  TEST (ne, 1, 1, 0, 1)
> +  TEST (gt, 1, 0, 0, 0)
> +  TEST (ge, 1, 0, 1, 0)
> +  TEST (lt, 0, 1, 0, 0)
> +  TEST (le, 0, 1, 1, 0)
> +  TEST (unle, 0, 1, 1, 1)
> +  TEST (unlt, 0, 1, 0, 1)
> +  TEST (unge, 1, 0, 1, 1)
> +  TEST (ungt, 1, 0, 0, 1)
> +  TEST (uneq, 0, 0, 1, 1)
> +  TEST (ordered, 1, 1, 1, 0)
> +  TEST (unordered, 0, 0, 0, 1)
> +}
> --- 

[Bug c++/71599] New: An extra unrelated move when compiling compare_exchange_strong

[jianjin2016 at fb dot com]

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

Bug ID: 71599
   Summary: An extra unrelated move when compiling
compare_exchange_strong
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jianjin2016 at fb dot com
  Target Milestone: ---

At high optimizations, for the code below:
bool cas(std::atomic* target, uint64_t expected, uint64_t desired) {
return target->compare_exchange_strong(expected, desired);
}

Gcc gives (link: https://godbolt.org/g/wP8Ah8 ):
movq %rsi, %rax
movq %rsi, -8(%rsp)  ---(Note this spurious move)
lock cmpxchgq %rdx, (%rdi)
sete %al
ret

However,
Clang gives (link: https://godbolt.org/g/UmUO7M ):
movq %rsi, %rax
lock cmpxchgq %rdx, (%rdi)
sete %al
retq


This extra and unrelated move will make a difference in our measurable
benchmark result.

Re: [PATCH] PR target/71549: Convert V1TImode register to TImode in debug insn

[H.J. Lu]

On Mon, Jun 20, 2016 at 10:31 AM, Ilya Enkovich  wrote:
> On 20 Jun 09:45, H.J. Lu wrote:
>> On Mon, Jun 20, 2016 at 7:30 AM, Ilya Enkovich  
>> wrote:
>> > 2016-06-20 16:39 GMT+03:00 Uros Bizjak :
>> >> On Mon, Jun 20, 2016 at 1:55 PM, H.J. Lu  wrote:
>> >>> TImode register referenced in debug insn can be converted to V1TImode
>> >>> by scalar to vector optimization.  We need to convert a debug insn if
>> >>> it has a variable in a TImode register.
>> >>>
>> >>> Tested on x86-64.  OK for trunk?
>> >>
>> >> Ilya, does this approach look good to you? Also, does DImode STV
>> >> conversion need similar handling of debug insns?
>> >
>> > DImode conversion doesn't change register mode (i.e. never calls
>> > PUT_MODE for registers).  That keeps debug instructions valid.
>> >
>> > Overall I don't like the idea of having debug insns in candidates
>> > set and in chains.  Looks like it is possible to have a chain
>> > consisting of a debug insn only which is weird (otherwise I don't
>> > see why we may return false in timode_scalar_chain::convert_insn).
>>
>> Yes, it can happen:
>>
>> (insn 11 8 12 2 (parallel [
>> (set (reg/v:TI 91 [  ])
>> (plus:TI (reg/v:TI 92 [ a ])
>> (reg/v:TI 96 [ b ])))
>> (clobber (reg:CC 17 flags))
>> ]) y.i:5 210 {*addti3_doubleword}
>>  (expr_list:REG_UNUSED (reg:CC 17 flags)
>> (nil)))
>> (debug_insn 12 11 13 2 (var_location:TI w (reg/v:TI 91 [  ])) y.i:5 
>> -1
>>  (nil))
>>
>>
>> > What about other possible register uses?  If debug insns are added
>> > to candidates then NONDEBUG_INSN_P check for uses in
>> > timode_check_non_convertible_regs becomes invalid, right?
>>
>> Debug insn has no impact on STV decision.  We just need to convert
>> register referenced in debug insn from V1TImode to TImode in
>> timode_scalar_chain::convert_insn.
>>
>> > If we have (or want) to fix some register uses then it's probably
>> > would be better to visit register uses when we convert its mode
>> > and make required fix-ups.  It seems better to me to not involve
>> > debug insns in analysis phase.
>>
>> Here is the updated patch to add debug insn, which references the
>> TImode register which will be converted to V1TImode to queue.
>> I am testing it now.
>>
>
> You still count and dump debug insns as optimized ones.  Also we
> try to use virtual functions to cover differences in DI and TI
> optimizations and introducing additional TARGET_64BIT in common
> STV code is undesirable.
>
> Also your conversion now depends on instructions processing order.
> You will fail to process debug insn before non-debug ones. Required
> order is not guaranteed because processing depends on instruction
> UIDs only.
>
> I propose to modify transformation phase only like in the patch
> (untested) below.  I rely on your code which assumes the only
> possible usage in debug insn is VAR_LOCATION.
>
> Thanks,
> Ilya
> --
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index c5e5e12..ec955f0 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -3139,6 +3139,7 @@ class timode_scalar_chain : public scalar_chain
>
>   private:
>void mark_dual_mode_def (df_ref def);
> +  void fix_debug_reg_uses (rtx reg);
>void convert_insn (rtx_insn *insn);
>/* We don't convert registers to difference size.  */
>void convert_registers () {}
> @@ -3790,6 +3791,34 @@ dimode_scalar_chain::convert_insn (rtx_insn *insn)
>df_insn_rescan (insn);
>  }
>
> +/* Fix uses of converted REG in debug insns.  */
> +
> +void
> +timode_scalar_chain::fix_debug_reg_uses (rtx reg)
> +{
> +  df_ref ref;
> +  for (ref = DF_REG_USE_CHAIN (REGNO (reg)); ref; ref = DF_REF_NEXT_REG 
> (ref))
> +{
> +  rtx_insn *insn = DF_REF_INSN (ref);
> +
> +  if (DEBUG_INSN_P (insn))
> +   {
> + /* It must be a debug insn with a TImode variable in register.  */
> + rtx val = PATTERN (insn);
> + gcc_assert (GET_MODE (val) == TImode
> + && GET_CODE (val) == VAR_LOCATION);
> + rtx loc = PAT_VAR_LOCATION_LOC (val);
> + gcc_assert (REG_P (loc)
> + && GET_MODE (loc) == V1TImode);
> + /* Convert V1TImode register, which has been updated by a SET
> + insn before, to SUBREG TImode.  */
> + PAT_VAR_LOCATION_LOC (val) = gen_rtx_SUBREG (TImode, loc, 0);
> + df_insn_rescan (insn);
> + return;
> +   }
> +}
> +}
> +
>  /* Convert INSN from TImode to V1T1mode.  */
>
>  void
> @@ -3806,8 +3835,10 @@ timode_scalar_chain::convert_insn (rtx_insn *insn)
> rtx tmp = find_reg_equal_equiv_note (insn);
> if (tmp)
>   PUT_MODE (XEXP (tmp, 0), V1TImode);
> +   PUT_MODE (dst, V1TImode);
> +   fix_debug_reg_uses (dst);
>}
> -  /* FALLTHRU */
> +  break;
>  case MEM:
>PUT_MODE 

[Bug fortran/71194] ICE on compilation with fcheck=all ; -fcheck=bounds

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
Author: burnus
Date: Mon Jun 20 18:46:43 2016
New Revision: 237612

URL: https://gcc.gnu.org/viewcvs?rev=237612=gcc=rev
Log:
2016-06-20  Tobias Burnus  

fortran/71194
* trans-expr.c (gfc_trans_pointer_assignment): Correctly handle
RHS pointer functions.

2016-06-20  Tobias Burnus  

PR fortran/71194
* gfortran.dg/pointer_remapping_10.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/pointer_remapping_10.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[PATCH] Fix warn uninit ICE with _Complex exprs (PR middle-end/71581)

[Jakub Jelinek]

Hi!

On the following testcase we ICE during warn_uninit.
Normally, has_undefined_value_p returns false for anonymous SSA_NAMEs,
so NULL expr/var aren't a problem.  If t has a COMPLEX_EXPR as def-stmt,
where the first operand is some scalar var's (D) SSA_NAME and the second
operand is 0, which results from gimplification of conversion of scalar
uninitialized var to complex type, t is anonymous SSA_NAME and expr and var
are both NULL.

This patch attempts to deal with that, try to recognize the case and use
the other SSA_NAME's underlying var as expr/var in that case, or punt (in
the unlikely case this wouldn't help).

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

2016-06-20  Jakub Jelinek  

PR middle-end/71581
* tree-ssa-uninit.c (warn_uninit): If EXPR and VAR are NULL,
see if T isn't anonymous SSA_NAME with COMPLEX_EXPR created
for conversion of scalar user var to complex type and use the
underlying SSA_NAME_VAR in that case.  If EXPR is still NULL,
punt.

* gcc.dg/pr71581.c: New test.

--- gcc/tree-ssa-uninit.c.jj2016-05-06 15:09:09.0 +0200
+++ gcc/tree-ssa-uninit.c   2016-06-20 16:13:31.324052992 +0200
@@ -131,6 +131,29 @@ warn_uninit (enum opt_code wc, tree t, t
   if (!has_undefined_value_p (t))
 return;
 
+  /* Anonymous SSA_NAMEs shouldn't be uninitialized, but ssa_undefined_value_p
+ can return true if the def stmt of anonymous SSA_NAME is COMPLEX_EXPR
+ created for conversion from scalar to complex.  Use the underlying var of
+ the COMPLEX_EXPRs real part in that case.  See PR71581.  */
+  if (expr == NULL_TREE
+  && var == NULL_TREE
+  && SSA_NAME_VAR (t) == NULL_TREE
+  && is_gimple_assign (SSA_NAME_DEF_STMT (t))
+  && gimple_assign_rhs_code (SSA_NAME_DEF_STMT (t)) == COMPLEX_EXPR)
+{
+  tree v = gimple_assign_rhs1 (SSA_NAME_DEF_STMT (t));
+  if (TREE_CODE (v) == SSA_NAME
+ && has_undefined_value_p (v)
+ && zerop (gimple_assign_rhs2 (SSA_NAME_DEF_STMT (t
+   {
+ expr = SSA_NAME_VAR (v);
+ var = expr;
+   }
+}
+
+  if (expr == NULL_TREE)
+return;
+
   /* TREE_NO_WARNING either means we already warned, or the front end
  wishes to suppress the warning.  */
   if ((context
--- gcc/testsuite/gcc.dg/pr71581.c.jj   2016-06-20 16:39:18.825817407 +0200
+++ gcc/testsuite/gcc.dg/pr71581.c  2016-06-20 16:28:49.0 +0200
@@ -0,0 +1,24 @@
+/* PR middle-end/71581 */
+/* { dg-do compile } */
+/* { dg-options "-Wuninitialized" } */
+
+_Complex float
+f1 (void)
+{
+  float x;
+  return x;/* { dg-warning "is used uninitialized in this function" } */
+}
+
+_Complex double
+f2 (void)
+{
+  double x;
+  return x;/* { dg-warning "is used uninitialized in this function" } */
+}
+
+_Complex int
+f3 (void)
+{
+  int x;
+  return x;/* { dg-warning "is used uninitialized in this function" } */
+}

Jakub

[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash

[gcc at davidrobins dot net]

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

--- Comment #12 from David B. Robins  ---
Note that it does still need -fno-inline.

I know why it doesn't crash with -O0: there is a text-section constant inserted
after the thunk, and it's inlined at higher optimization levels. The
instruction said constant maps to is either harmless or forbidden as a delay
slot instruction. So the underlying issue still occurs but the crash doesn't.
At higher optimization levels the function is also inlined in the thunk (that
didn't happen on 4.3.1). This also seems somewhat fragile - the crash is
dependent on what's next in the generated code - which is why I wasn't sure
about what sort of test to add.

I am OK with my name/email being included in the ChangeLog, thank you.

[PATCH] Don't run -fself-test with -E (PR rtl-optimization/71591)

[Jakub Jelinek]

Hi!

As mentioned in the PR, with -E (C family and Fortran FEs, others don't
preprocess) ask the middle-end not to initialize the backends, so running
e.g. RTL tests leads to ICEs, e.g. pc_rtx and many other things just aren't
initialized.

2016-06-20  Jakub Jelinek  

PR rtl-optimization/71591
* toplev.c (toplev::run_self_tests): If no_backend, complain and
don't run any tests.

* gcc.dg/cpp/pr71591.c: New test.

--- gcc/toplev.c.jj 2016-06-13 20:45:11.0 +0200
+++ gcc/toplev.c2016-06-20 14:54:07.931667136 +0200
@@ -2047,6 +2047,11 @@ toplev::start_timevars ()
 void
 toplev::run_self_tests ()
 {
+  if (no_backend)
+{
+  error_at (UNKNOWN_LOCATION, "self-tests incompatible with -E");
+  return;
+}
 #if CHECKING_P
   /* Reset some state.  */
   input_location = UNKNOWN_LOCATION;
--- gcc/testsuite/gcc.dg/cpp/pr71591.c.jj   2016-06-20 14:57:19.713187492 
+0200
+++ gcc/testsuite/gcc.dg/cpp/pr71591.c  2016-06-20 14:58:46.014071662 +0200
@@ -0,0 +1,5 @@
+/* PR rtl-optimization/71591 */
+/* { dg-do preprocess } */
+/* { dg-options "-fself-test" } */
+
+/* { dg-message "self-tests incompatible with -E" "" { target *-*-* } 0 } */

Jakub

[PATCH] Give up instead of ICE on invalid stringops attributes (PR tree-optimization/71588)

[Jakub Jelinek]

Hi!

If users use attributes like const or pure incorrectly on stringops
builtins, the tree-ssa-strlen.c pass can ICE, because it expects it can e.g.
replace a strcpy (which should not be const or pure) with memcpy (which also
shouldn't be const/pure) etc.
The patch just pretends the calls aren't builtins for the purpose of
tree-ssa-strlen.c pass if they have unexpected const/pure-ness.

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

2016-06-20  Jakub Jelinek  

PR tree-optimization/71588
* tree-ssa-strlen.c (valid_builtin_call): New function.
(adjust_last_stmt, handle_builtin_memset, strlen_optimize_stmt): Use
it.

* gcc.dg/pr71558.c: New test.

--- gcc/tree-ssa-strlen.c.jj2016-06-08 14:51:25.0 +0200
+++ gcc/tree-ssa-strlen.c   2016-06-20 13:30:23.576556803 +0200
@@ -860,6 +860,66 @@ find_equal_ptrs (tree ptr, int idx)
 }
 }
 
+/* Return true if STMT is a call to a builtin function with the right
+   arguments and attributes that should be considered for optimization
+   by this pass.  */
+
+static bool
+valid_builtin_call (gimple *stmt)
+{
+  if (!gimple_call_builtin_p (stmt, BUILT_IN_NORMAL))
+return false;
+
+  tree callee = gimple_call_fndecl (stmt);
+  switch (DECL_FUNCTION_CODE (callee))
+{
+case BUILT_IN_MEMCMP:
+case BUILT_IN_MEMCMP_EQ:
+case BUILT_IN_STRCHR:
+case BUILT_IN_STRCHR_CHKP:
+case BUILT_IN_STRLEN:
+case BUILT_IN_STRLEN_CHKP:
+  /* The above functions should be pure.  Punt if they aren't.  */
+  if (gimple_vdef (stmt) || gimple_vuse (stmt) == NULL_TREE)
+   return false;
+  break;
+
+case BUILT_IN_CALLOC:
+case BUILT_IN_MALLOC:
+case BUILT_IN_MEMCPY:
+case BUILT_IN_MEMCPY_CHK:
+case BUILT_IN_MEMCPY_CHKP:
+case BUILT_IN_MEMCPY_CHK_CHKP:
+case BUILT_IN_MEMPCPY:
+case BUILT_IN_MEMPCPY_CHK:
+case BUILT_IN_MEMPCPY_CHKP:
+case BUILT_IN_MEMPCPY_CHK_CHKP:
+case BUILT_IN_MEMSET:
+case BUILT_IN_STPCPY:
+case BUILT_IN_STPCPY_CHK:
+case BUILT_IN_STPCPY_CHKP:
+case BUILT_IN_STPCPY_CHK_CHKP:
+case BUILT_IN_STRCAT:
+case BUILT_IN_STRCAT_CHK:
+case BUILT_IN_STRCAT_CHKP:
+case BUILT_IN_STRCAT_CHK_CHKP:
+case BUILT_IN_STRCPY:
+case BUILT_IN_STRCPY_CHK:
+case BUILT_IN_STRCPY_CHKP:
+case BUILT_IN_STRCPY_CHK_CHKP:
+  /* The above functions should be neither const nor pure.  Punt if they
+aren't.  */
+  if (gimple_vdef (stmt) == NULL_TREE || gimple_vuse (stmt) == NULL_TREE)
+   return false;
+  break;
+
+default:
+  break;
+}
+
+  return true;
+}
+
 /* If the last .MEM setter statement before STMT is
memcpy (x, y, strlen (y) + 1), the only .MEM use of it is STMT
and STMT is known to overwrite x[strlen (x)], adjust the last memcpy to
@@ -935,7 +995,7 @@ adjust_last_stmt (strinfo *si, gimple *s
   return;
 }
 
-  if (!gimple_call_builtin_p (last.stmt, BUILT_IN_NORMAL))
+  if (!valid_builtin_call (last.stmt))
 return;
 
   callee = gimple_call_fndecl (last.stmt);
@@ -1811,7 +1871,7 @@ handle_builtin_memset (gimple_stmt_itera
   if (!stmt1 || !is_gimple_call (stmt1))
 return true;
   tree callee1 = gimple_call_fndecl (stmt1);
-  if (!gimple_call_builtin_p (stmt1, BUILT_IN_NORMAL))
+  if (!valid_builtin_call (stmt1))
 return true;
   enum built_in_function code1 = DECL_FUNCTION_CODE (callee1);
   tree size = gimple_call_arg (stmt2, 2);
@@ -2140,7 +2200,7 @@ strlen_optimize_stmt (gimple_stmt_iterat
   if (is_gimple_call (stmt))
 {
   tree callee = gimple_call_fndecl (stmt);
-  if (gimple_call_builtin_p (stmt, BUILT_IN_NORMAL))
+  if (valid_builtin_call (stmt))
switch (DECL_FUNCTION_CODE (callee))
  {
  case BUILT_IN_STRLEN:
--- gcc/testsuite/gcc.dg/pr71558.c.jj   2016-06-20 13:52:15.491591442 +0200
+++ gcc/testsuite/gcc.dg/pr71558.c  2016-06-20 13:51:59.0 +0200
@@ -0,0 +1,17 @@
+/* PR tree-optimization/71588 */
+
+/* strcpy must not be pure, but make sure we don't ICE even when
+   it is declared incorrectly.  */
+char *strcpy (char *, const char *) __attribute__ ((__pure__));
+__SIZE_TYPE__ strlen (const char *);
+void *malloc (__SIZE_TYPE__);
+
+char a[20];
+
+char *
+foo (void)
+{
+  __SIZE_TYPE__ b = strlen (a);
+  char *c = malloc (b);
+  return strcpy (c, a);
+}

Jakub

[PATCH] Fix ix86_fp_cmp_code_to_pcmp_immediate (PR target/71559)

[Jakub Jelinek]

Hi!

As discussed in the PR, this function is missing a lot of comparison codes
that can validly appear there, and gives wrong values for the others
except for NE.
This patch makes those values match what %D3 emits for the AVX vcmp*p{s,d},
there is some controversy on whether UN{GT,GE,LT,LE,EQ} and/or LTGT should
raise exceptions or not, but that should be handled later on also together
with the scalar code (where we never raise exceptions), SSE, AVX and this.

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

2016-06-20  Jakub Jelinek  

PR target/71559
* config/i386/i386.c (ix86_fp_cmp_code_to_pcmp_immediate): Fix up
returned values and add UN*/LTGT/*ORDERED cases with values matching
D operand modifier on vcmp for AVX.

* gcc.target/i386/sse2-pr71559.c: New test.
* gcc.target/i386/avx-pr71559.c: New test.
* gcc.target/i386/avx512f-pr71559.c: New test.

--- gcc/config/i386/i386.c.jj   2016-06-20 10:36:29.489994876 +0200
+++ gcc/config/i386/i386.c  2016-06-20 12:07:37.311006144 +0200
@@ -23622,17 +23622,33 @@ ix86_fp_cmp_code_to_pcmp_immediate (enum
   switch (code)
 {
 case EQ:
-  return 0x08;
+  return 0x00;
 case NE:
   return 0x04;
 case GT:
-  return 0x16;
+  return 0x0e;
 case LE:
-  return 0x1a;
+  return 0x02;
 case GE:
-  return 0x15;
+  return 0x0d;
 case LT:
-  return 0x19;
+  return 0x01;
+case UNLE:
+  return 0x0a;
+case UNLT:
+  return 0x09;
+case UNGE:
+  return 0x05;
+case UNGT:
+  return 0x06;
+case UNEQ:
+  return 0x18;
+case LTGT:
+  return 0x0c;
+case ORDERED:
+  return 0x07;
+case UNORDERED:
+  return 0x03;
 default:
   gcc_unreachable ();
 }
--- gcc/testsuite/gcc.target/i386/sse2-pr71559.c.jj 2016-06-20 
12:10:27.621795187 +0200
+++ gcc/testsuite/gcc.target/i386/sse2-pr71559.c2016-06-20 
12:14:44.821457893 +0200
@@ -0,0 +1,73 @@
+/* PR target/71559 */
+/* { dg-do run { target sse2 } } */
+/* { dg-options "-O2 -ftree-vectorize -msse2" } */
+
+#ifndef PR71559_TEST
+#include "sse2-check.h"
+#define PR71559_TEST sse2_test
+#endif
+
+#define N 16
+float a[N] = { 5.0f, -3.0f, 1.0f, __builtin_nanf (""), 9.0f, 7.0f, -3.0f, 
-9.0f,
+   -3.0f, -5.0f, -9.0f, __builtin_nanf (""), 0.5f, -0.5f, 0.0f, 
0.0f };
+float b[N] = { -5.0f, 3.0f, 1.0f, 7.0f, 8.0f, 8.0f, -3.0f, __builtin_nanf (""),
+   -4.0f, -4.0f, -9.0f, __builtin_nanf (""), 0.0f, 0.0f, 0.0f, 
__builtin_nanf ("") };
+int c[N], d[N];
+
+#define FN(name, op) \
+void   \
+name (void)\
+{  \
+  int i;   \
+  for (i = 0; i < N; i++)  \
+c[i] = (op || d[i] > 37) ? 5 : 32; \
+}
+FN (eq, a[i] == b[i])
+FN (ne, a[i] != b[i])
+FN (gt, a[i] > b[i])
+FN (ge, a[i] >= b[i])
+FN (lt, a[i] < b[i])
+FN (le, a[i] <= b[i])
+FN (unle, !__builtin_isgreater (a[i], b[i]))
+FN (unlt, !__builtin_isgreaterequal (a[i], b[i]))
+FN (unge, !__builtin_isless (a[i], b[i]))
+FN (ungt, !__builtin_islessequal (a[i], b[i]))
+FN (uneq, !__builtin_islessgreater (a[i], b[i]))
+FN (ordered, !__builtin_isunordered (a[i], b[i]))
+FN (unordered, __builtin_isunordered (a[i], b[i]))
+
+#define TEST(name, GT, LT, EQ, UO) \
+  name (); \
+  for (i = 0; i < N; i++)  \
+{  \
+  int v;   \
+  switch (i % 4)   \
+   {   \
+   case 0: v = GT ? 5 : 32; break; \
+   case 1: v = LT ? 5 : 32; break; \
+   case 2: v = EQ ? 5 : 32; break; \
+   case 3: v = UO ? 5 : 32; break; \
+   }   \
+  if (c[i] != v)   \
+   __builtin_abort (); \
+}
+
+void
+PR71559_TEST (void)
+{
+  int i;
+  asm volatile ("" : : "g" (a), "g" (b), "g" (c), "g" (d) : "memory");
+  TEST (eq, 0, 0, 1, 0)
+  TEST (ne, 1, 1, 0, 1)
+  TEST (gt, 1, 0, 0, 0)
+  TEST (ge, 1, 0, 1, 0)
+  TEST (lt, 0, 1, 0, 0)
+  TEST (le, 0, 1, 1, 0)
+  TEST (unle, 0, 1, 1, 1)
+  TEST (unlt, 0, 1, 0, 1)
+  TEST (unge, 1, 0, 1, 1)
+  TEST (ungt, 1, 0, 0, 1)
+  TEST (uneq, 0, 0, 1, 1)
+  TEST (ordered, 1, 1, 1, 0)
+  TEST (unordered, 0, 0, 0, 1)
+}
--- gcc/testsuite/gcc.target/i386/avx-pr71559.c.jj  2016-06-20 
12:10:44.028582301 +0200
+++ gcc/testsuite/gcc.target/i386/avx-pr71559.c 2016-06-20 12:14:32.627616114 
+0200
@@ -0,0 +1,8 @@
+/* PR target/71559 */
+/* { dg-do run { target avx } } */
+/* { dg-options "-O2 -ftree-vectorize -mavx" } */
+
+#include "avx-check.h"
+#define PR71559_TEST avx_test
+
+#include "sse2-pr71559.c"
--- gcc/testsuite/gcc.target/i386/avx512f-pr71559.c.jj  2016-06-20 
12:11:32.812949299 +0200
+++ gcc/testsuite/gcc.target/i386/avx512f-pr71559.c 2016-06-20 

Re: [PATCH] config-list.mk AIX update

[Jan-Benedict Glaw]

Hi David,

On Mon, 2016-06-20 14:13:33 -0400, David Edelsohn  wrote:
> This patch removes obsolete AIX 4.3, 5.1 and 5.2 configurations and
> adds AIX 7.1 configuration.  GCC does not yet differentiate AIX 7.2,
> so I did not include it.
> 
> Okay?

Of course, you're AIX maintainer after all. ;-)

  Just a nitpick: Right now, the old AIX configurations weren't marked
as --enable-obsolete targets in gcc/config.gcc .  So I suggest to add
those there as well.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
 Signature of:If it doesn't work, force it.
 the second  :   If it breaks, it needed replacing anyway.


signature.asc
Description: Digital signature

[PATCH] config-list.mk AIX update

[David Edelsohn]

This patch removes obsolete AIX 4.3, 5.1 and 5.2 configurations and
adds AIX 7.1 configuration.  GCC does not yet differentiate AIX 7.2,
so I did not include it.

Okay?

Thanks, David

* config-list.mk: Remove rs6000-ibm-aix4.3, rs6000-ibm-aix5.1,
rs6000-ibm-aix5.2.
Rename rs6000-ibm-aix6.0 as rs6000-ibm-aix6.1.  Add rs6000-ibm-aix7.1.

Index: config-list.mk
===
--- config-list.mk  (revision 237600)
+++ config-list.mk  (working copy)
@@ -81,8 +81,8 @@
   powerpc-linux_paired powerpc64-linux_altivec \
   powerpc-wrs-vxworks powerpc-wrs-vxworksae powerpc-wrs-vxworksmils \
   powerpc-lynxos powerpcle-elf \
-  powerpcle-eabisim powerpcle-eabi rs6000-ibm-aix4.3 rs6000-ibm-aix5.1.0 \
-  rs6000-ibm-aix5.2.0 rs6000-ibm-aix5.3.0 rs6000-ibm-aix6.0 \
+  powerpcle-eabisim powerpcle-eabi \
+  rs6000-ibm-aix5.3.0 rs6000-ibm-aix6.1 rs6000-ibm-aix7.1 \
   rl78-elf rx-elf s390-linux-gnu s390x-linux-gnu s390x-ibm-tpf sh-elf \
   shle-linux sh-netbsdelf sh-superh-elf \
   sh-rtems sh-wrs-vxworks sparc-elf \

[Bug rtl-optimization/71596] [7 Regression] gcc bootstrap fails due to segv in genrecog

[saguryev.gnu at gmail dot com]

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

--- Comment #2 from Sergey  ---
( may be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70902 ? )

- genrecog crashes with segv if built with gcc@r235523 and later after emitting
first 32k of its output -- stack trace below; 
- it's genrecog.c:init_pattern_use() which is compiled incorrectly at -O2; if
compiled at -O1 ( with all others remaining at -O2 ), the problem vanishes;
- also, the problem shows up with -march= nehalem, sandybridge and newer archs;
if built with -march=nocona or silvermont, it works fine.


build/genrecog ../../gcc/gcc/common.md ../../gcc/gcc/config/i386/i386.md
insn-conditions.md
/* Generated automatically by the program `genrecog' from the target
.
  longest path:   195 (code: 77)
  longest backtrack:   17 (code:156)

Program received signal SIGSEGV, Segmentation fault.
populate_pattern_routine (cpi=cpi@entry=0x7fffd980, sinfo=0x4387040,
news=news@entry=0x4387090, params=...)
at ../../gcc/gcc/genrecog.c:2842
2842  decision *d = sinfo->s->singleton ();
(gdb) p sinfo->s
$3 = (state *) 0x0
(gdb) bt
#0  populate_pattern_routine (cpi=cpi@entry=0x7fffd980, sinfo=0x4387040,
news=news@entry=0x4387090, params=...)
at ../../gcc/gcc/genrecog.c:2842
#1  0x004175e5 in populate_pattern_routine
(cpi=cpi@entry=0x7fffd980, sinfo=0x77208ee0, news=, 
params=...) at ../../gcc/gcc/genrecog.c:2907
#2  0x00417a91 in init_pattern_use (cpi=cpi@entry=0x7fffd980,
sinfo=0x77208ee0, params=...)
at ../../gcc/gcc/genrecog.c:2788
#3  0x0041728f in populate_pattern_routine
(cpi=cpi@entry=0x7fffe190, sinfo=0x771f7348, 
news=news@entry=0x4386b10, params=...) at ../../gcc/gcc/genrecog.c:2912
#4  0x004175e5 in populate_pattern_routine
(cpi=cpi@entry=0x7fffe190, sinfo=0x771e9fe0, 
news=news@entry=0x4386aa0, params=...) at ../../gcc/gcc/genrecog.c:2907
#5  0x004175e5 in populate_pattern_routine
(cpi=cpi@entry=0x7fffe190, sinfo=0x771e0d78, 
news=news@entry=0x4386a30, params=...) at ../../gcc/gcc/genrecog.c:2907
#6  0x004175e5 in populate_pattern_routine
(cpi=cpi@entry=0x7fffe190, sinfo=0x771da6f8, 
news=news@entry=0x43869c0, params=...) at ../../gcc/gcc/genrecog.c:2907
#7  0x004175e5 in populate_pattern_routine
(cpi=cpi@entry=0x7fffe190, sinfo=0x771d7520, 
news=news@entry=0x4386950, params=...) at ../../gcc/gcc/genrecog.c:2907
#8  0x004175e5 in populate_pattern_routine
(cpi=cpi@entry=0x7fffe190, sinfo=0x771d5608, news=, 
params=...) at ../../gcc/gcc/genrecog.c:2907
#9  0x00417a91 in init_pattern_use (cpi=cpi@entry=0x7fffe190,
sinfo=sinfo@entry=0x771d5608, params=...)
at ../../gcc/gcc/genrecog.c:2788
#10 0x004034e1 in use_pattern (sinfo=) at
../../gcc/gcc/genrecog.c:2993
#11 split_out_patterns (states=...) at ../../gcc/gcc/genrecog.c:3243
#12 main (argc=, argv=) at
../../gcc/gcc/genrecog.c:5317

[Bug c/71598] New: Wrong optimization with aliasing enums

[ch3root at openwall dot com]

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

Bug ID: 71598
   Summary: Wrong optimization with aliasing enums
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

Source code:

--
extern void abort (void);

enum e1 { c1 };
enum e2 { c2 };

__attribute__((noinline,noclone))
int f(enum e1 *p, enum e2 *q)
{
  *p = 1;
  *q = 2;
  return *p;
}

int main()
{
  unsigned x;

  if (f(, ) != 2)
abort();
}
--

Results:

--
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
Aborted
--

gcc version: gcc (GCC) 7.0.0 20160616 (experimental)

In gcc such enums are compatible with unsigned int. Hence they could alias. But
gcc seem to (wrongly) assume that *p and *q cannot refer to the same object.

Re: [Patch, testsuite] Mark some more tests as UNSUPPORTED for avr

[Mike Stump]

On Jun 20, 2016, at 2:13 AM, Senthil Kumar Selvaraj 
 wrote:
> 
> This patch fixes some bogus failures for the avr target by requiring
> int32plus or ptr32plus support.
> 
> Ok for trunk?

Ok.

If you feel comfortable making these sort of "obvious" changes, you can post 
and check them in without asking for a formal review.  You can always ask for a 
review, if you'd like one.

> 2016-06-20  Senthil Kumar Selvaraj  
> 
>   * c-c++-common/pr68657-1.c: Require ptr32plus support.
>   * c-c++-common/pr68657-2.c: Likewise.
>   * c-c++-common/pr68657-3.c: Likewise.
>   * gcc.dg/torture/pr69714.c: Require int32plus support.
>   * gcc.dg/torture/pr70025.c: Likewise.
>   * gcc.dg/torture/pr70083.c: Likewise.
>   * gcc.dg/torture/pr70542.c: Likewise.
>   * gcc.dg/torture/pr70935.c: Require ptr32plus support.

Re: Deprecating basic asm in a function - What now?

[Michael Matz]

Hi,

On Mon, 20 Jun 2016, Andrew Haley wrote:

> On 20/06/16 18:36, Michael Matz wrote:
> > I see zero gain by deprecating them and only churn.  What would be the 
> > advantage again?
> 
> Correctness.

As said in the various threads about basic asms, all correctness 
problems can be solved by making GCC more conservative in handling them 
(or better said: not making it less conservative).

If you talk about cases where basic asms diddle registers expecting GCC to 
have placed e.g. local variables into specific ones (without using local 
reg vars, or extended asm) I won't believe any claims ...

> It is very likely that many of these basic asms are not
> robust

... of them being very likely without proof.  They will have stopped 
working with every change in compilation options or compiler version.  In 
contrast I think those that did survive a couple years in software very 
likely _are_ correct, under the then documented (or implicit) assumptions.
Those usually are: clobbers and uses memory, processor state and fixed 
registers.

> in the face of compiler changes because they don't declare their 
> dependencies and therefore work only by accident.

Then the compiler better won't change into less conservative handling of 
basic asms.

You see, the experiment shows that there's a gazillion uses of basic asms 
out there.  Deprecating them means that each and every one of them (for us 
alone that's 540 something, including testsuite and boehm) has to be 
changed from asm("body") into asm("body" : : : "memory") (give and take 
some syntax for also clobbering flags).  Alternatively rewrite the 
body to actually make use of extended asm.  I guarantee you that a 
non-trivial percentage will be wrong _then_ while they work fine now.  
Even if it weren't so it still would be silly if GCC simply could regard 
the former as the latter internally.  It would just be change for the sake 
of it and affecting quite many users without gain.


Ciao,
Michael.

[Bug c/71597] New: Confusing warning for incompatible enums

[ch3root at openwall dot com]

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

Bug ID: 71597
   Summary: Confusing warning for incompatible enums
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

Source code:

--
enum { a } x; // (1)
unsigned x; // (2)
enum { b } x; // (3)

int main()
{
}
--

Results:

--
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
test.c:3:12: error: conflicting types for ‘x’
 enum { b } x; // (3)
^
test.c:2:10: note: previous declaration of ‘x’ was here
 unsigned x; // (2)
  ^
--

gcc version: gcc (GCC) 7.0.0 20160616 (experimental)

It would be better to display the conflicting declaration (1) instead of just
the previous one (2).

[Bug rtl-optimization/71596] [7 Regression] gcc bootstrap fails due to segv in genrecog

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build
   Target Milestone|--- |7.0

[Bug rtl-optimization/71596] [7 Regression] gcc bootstrap fails due to segv in genrecog

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-20
 CC||trippels at gcc dot gnu.org
Summary|gcc bootstrap fails due to  |[7 Regression] gcc
   |segv in genrecog|bootstrap fails due to segv
   ||in genrecog
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Starting program: /home/trippels/gcc_build_dir_/gcc/build/genrecog
../../gcc/gcc/common.md ../../gcc/gcc/config/i386/i386.md insn-conditions.md >|
tmp-recog.c
Statistics for recog:
  Number of decisions:  39371
  longest path:   369 (code:   3694)
  longest backtrack:   24 (code:   4408)
Statistics for split_insns:
  Number of decisions:   2415
  longest path:74 (code:389)
  longest backtrack:   16 (code:400)
Statistics for peephole2_insns:
  Number of decisions:   1387
  longest path:   195 (code: 77)
  longest backtrack:   17 (code:156)

Program received signal SIGSEGV, Segmentation fault.
0x0041351d in populate_pattern_routine(create_pattern_info*,
merge_state_info*, state*, vec const&) ()
(gdb) bt
#0  0x0041351d in populate_pattern_routine(create_pattern_info*,
merge_state_info*, state*, vec const&) ()
#1  0x00414504 in init_pattern_use(create_pattern_info*,
merge_state_info*, vec const&) ()
#2  0x00413922 in populate_pattern_routine(create_pattern_info*,
merge_state_info*, state*, vec const&) ()
#3  0x004137c9 in populate_pattern_routine(create_pattern_info*,
merge_state_info*, state*, vec const&) ()
#4  0x004137c9 in populate_pattern_routine(create_pattern_info*,
merge_state_info*, state*, vec const&) ()
#5  0x004137c9 in populate_pattern_routine(create_pattern_info*,
merge_state_info*, state*, vec const&) ()
#6  0x004137c9 in populate_pattern_routine(create_pattern_info*,
merge_state_info*, state*, vec const&) ()
#7  0x004137c9 in populate_pattern_routine(create_pattern_info*,
merge_state_info*, state*, vec const&) ()
#8  0x00414504 in init_pattern_use(create_pattern_info*,
merge_state_info*, vec const&) ()
#9  0x004046e1 in main ()

Re: Deprecating basic asm in a function - What now?

[Andrew Haley]

On 20/06/16 18:36, Michael Matz wrote:
> I see zero gain by deprecating them and only churn.  What would be the 
> advantage again?

Correctness.  It is very likely that many of these basic asms are not
robust in the face of compiler changes because they don't declare
their dependencies and therefore work only by accident.

There are some correct basic asms.  For example,

  asm("nop")

There are some others too, once we've made the change to have basic
asms clobber memory.  These include syscalls which are implemented
by using named register variables.

Andrew.

Re: [PATCH] PR target/71549: Convert V1TImode register to TImode in debug insn

[Ilya Enkovich]

On 20 Jun 09:45, H.J. Lu wrote:
> On Mon, Jun 20, 2016 at 7:30 AM, Ilya Enkovich  wrote:
> > 2016-06-20 16:39 GMT+03:00 Uros Bizjak :
> >> On Mon, Jun 20, 2016 at 1:55 PM, H.J. Lu  wrote:
> >>> TImode register referenced in debug insn can be converted to V1TImode
> >>> by scalar to vector optimization.  We need to convert a debug insn if
> >>> it has a variable in a TImode register.
> >>>
> >>> Tested on x86-64.  OK for trunk?
> >>
> >> Ilya, does this approach look good to you? Also, does DImode STV
> >> conversion need similar handling of debug insns?
> >
> > DImode conversion doesn't change register mode (i.e. never calls
> > PUT_MODE for registers).  That keeps debug instructions valid.
> >
> > Overall I don't like the idea of having debug insns in candidates
> > set and in chains.  Looks like it is possible to have a chain
> > consisting of a debug insn only which is weird (otherwise I don't
> > see why we may return false in timode_scalar_chain::convert_insn).
> 
> Yes, it can happen:
> 
> (insn 11 8 12 2 (parallel [
> (set (reg/v:TI 91 [  ])
> (plus:TI (reg/v:TI 92 [ a ])
> (reg/v:TI 96 [ b ])))
> (clobber (reg:CC 17 flags))
> ]) y.i:5 210 {*addti3_doubleword}
>  (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil)))
> (debug_insn 12 11 13 2 (var_location:TI w (reg/v:TI 91 [  ])) y.i:5 -1
>  (nil))
> 
> 
> > What about other possible register uses?  If debug insns are added
> > to candidates then NONDEBUG_INSN_P check for uses in
> > timode_check_non_convertible_regs becomes invalid, right?
> 
> Debug insn has no impact on STV decision.  We just need to convert
> register referenced in debug insn from V1TImode to TImode in
> timode_scalar_chain::convert_insn.
> 
> > If we have (or want) to fix some register uses then it's probably
> > would be better to visit register uses when we convert its mode
> > and make required fix-ups.  It seems better to me to not involve
> > debug insns in analysis phase.
> 
> Here is the updated patch to add debug insn, which references the
> TImode register which will be converted to V1TImode to queue.
> I am testing it now.
> 

You still count and dump debug insns as optimized ones.  Also we
try to use virtual functions to cover differences in DI and TI 
optimizations and introducing additional TARGET_64BIT in common
STV code is undesirable.

Also your conversion now depends on instructions processing order.
You will fail to process debug insn before non-debug ones. Required
order is not guaranteed because processing depends on instruction
UIDs only.

I propose to modify transformation phase only like in the patch
(untested) below.  I rely on your code which assumes the only
possible usage in debug insn is VAR_LOCATION.

Thanks,
Ilya
--
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index c5e5e12..ec955f0 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3139,6 +3139,7 @@ class timode_scalar_chain : public scalar_chain
 
  private:
   void mark_dual_mode_def (df_ref def);
+  void fix_debug_reg_uses (rtx reg);
   void convert_insn (rtx_insn *insn);
   /* We don't convert registers to difference size.  */
   void convert_registers () {}
@@ -3790,6 +3791,34 @@ dimode_scalar_chain::convert_insn (rtx_insn *insn)
   df_insn_rescan (insn);
 }
 
+/* Fix uses of converted REG in debug insns.  */
+
+void
+timode_scalar_chain::fix_debug_reg_uses (rtx reg)
+{
+  df_ref ref;
+  for (ref = DF_REG_USE_CHAIN (REGNO (reg)); ref; ref = DF_REF_NEXT_REG (ref))
+{
+  rtx_insn *insn = DF_REF_INSN (ref);
+
+  if (DEBUG_INSN_P (insn))
+   {
+ /* It must be a debug insn with a TImode variable in register.  */
+ rtx val = PATTERN (insn);
+ gcc_assert (GET_MODE (val) == TImode
+ && GET_CODE (val) == VAR_LOCATION);
+ rtx loc = PAT_VAR_LOCATION_LOC (val);
+ gcc_assert (REG_P (loc)
+ && GET_MODE (loc) == V1TImode);
+ /* Convert V1TImode register, which has been updated by a SET
+ insn before, to SUBREG TImode.  */
+ PAT_VAR_LOCATION_LOC (val) = gen_rtx_SUBREG (TImode, loc, 0);
+ df_insn_rescan (insn);
+ return;
+   }
+}
+}
+
 /* Convert INSN from TImode to V1T1mode.  */
 
 void
@@ -3806,8 +3835,10 @@ timode_scalar_chain::convert_insn (rtx_insn *insn)
rtx tmp = find_reg_equal_equiv_note (insn);
if (tmp)
  PUT_MODE (XEXP (tmp, 0), V1TImode);
+   PUT_MODE (dst, V1TImode);
+   fix_debug_reg_uses (dst);
   }
-  /* FALLTHRU */
+  break;
 case MEM:
   PUT_MODE (dst, V1TImode);
   break;

Re: Deprecating basic asm in a function - What now?

[Michael Matz]

Hi,

On Sun, 19 Jun 2016, David Wohlferd wrote:

> All basic asm in trunk: 1,105 instances.
> - Exclude 273 instances with empty strings leaving 832.
> - Exclude 271 instances for boehm-gc project leaving 561.
> - Exclude 202 instances for testsuite project leaving 359.
> - Exclude 282 instances that are (apparently) top-level leaving
> 
> ~77 instances of basic-asm-in-a-function to be fixed for gcc builds.  
> Most of these are in gcc/config or libgcc/config with just a handful per 
> platform. Lists available upon request.

Well, I think this quite clearly shows how bad an idea it would be to 
deprecate basic asm.  We are just one project, and ourself and our 
dependencies already have 77+271 uses of them, not counting the testsuite 
which also reflects some real world usage.

I see zero gain by deprecating them and only churn.  What would be the 
advantage again?


Ciao,
Michael.

[Bug rtl-optimization/71596] New: gcc bootstrap fails due to segv in genrecog

[saguryev.gnu at gmail dot com]

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

Bug ID: 71596
   Summary: gcc bootstrap fails due to segv in genrecog
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: saguryev.gnu at gmail dot com
  Target Milestone: ---

Re: Update probabilities in predict.def to match reality

[Renlin Li]

Hi,

On 08/06/16 11:21, Andreas Schwab wrote:

Jan Hubicka  writes:


Bootstrapped/regtested x86_64-linux, will commit it later today.


FAIL: gcc.dg/tree-ssa/slsr-8.c scan-tree-dump-times optimized " w?* " 7


This fails for all arm and aarch64 targets as well since the commit.

Regards,
Renlin Li



Andreas.

[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash

[hp at gcc dot gnu.org]

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

--- Comment #11 from Hans-Peter Nilsson  ---
(In reply to David B. Robins from comment #10)
> My apologies, I saw the example you pointed at was from torture/ but
> missed/forgot that you had also wanted the new test there. I moved the file
> to torture and removed -O2 -fno-inline and I didn't get the failure. I did
> get it when I added back only -fno-inline, which at least no longer depends
> on a specific optimization level:

Ok, good.  Weird that you don't get it for -O0 but never mind.
Since you verified that it works there I think, I'll put it in torture/ hoping
I won't forget to remove the "-O2 -fno-inline". :)

Just one more question; credits where credits are due: are you ok with me
putting your name and email address, as it appears in here in bugzilla, on the
entry in the testsuite ChangeLog?

[Bug c++/71570] [6/7 regression] ICE on invalid variable capture in cxx_incomplete_type_diagnostic, at cp/typeck2.c:551

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-20
 CC||jason at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
Summary|ICE on invalid C++11 code   |[6/7 regression] ICE on
   |(with invalid variable  |invalid variable capture in
   |capture) on |cxx_incomplete_type_diagnos
   |x86_64-linux-gnu: in|tic, at cp/typeck2.c:551
   |cxx_incomplete_type_diagnos |
   |tic, at cp/typeck2.c:551|
 Ever confirmed|0   |1
  Known to fail||6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
The ICE was introduced into GCC 6.0 in r232436:

r232436 | jason | 2016-01-15 10:57:07 -0500 (Fri, 15 Jan 2016) | 6 lines

PR c++/69257
* typeck.c (decay_conversion): Don't call mark_rvalue_use for
array/function-to-pointer conversion.  Call
complete_type_or_maybe_complain for lvalue-to-rvalue conversion.
* call.c (convert_like_real): Print call context if
decay_conversion errors.

Re: Deprecating basic asm in a function - What now?

[DJ Delorie]

Given how many embedded ports have #defines in external packages for
basic asms for instructions such as nop, enable/disable interrupts,
other system-level opcodes, etc... I think this is a bad idea.  Even
glibc would break.

#define enable() asm("eint")

__asm__ __volatile__ ("fwait");

[PATCH, i386, AVX-512ER] vrcp28ps auto generation

[Ilya Verbin]

Hi!

This patch emits vrcp28ps and vmulps istructions for ix86_emit_swdivsf.
The relative error is < 2^-23, so no additional iteration is necessary.
Regtested using various benchmarks on a AVX-512ER machine.  OK for trunk?


gcc/
* config/i386/i386.c (ix86_emit_swdivsf): Emit vrcp28ps.
gcc/testsuite/
* gcc.target/i386/avx512er-vrcp28ps-3.c: New test.
* gcc.target/i386/avx512er-vrcp28ps-4.c: New test.


diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 56a5b9c..8e0bf26 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -48674,8 +48674,19 @@ void ix86_emit_swdivsf (rtx res, rtx a, rtx b, 
machine_mode mode)
 
   /* x0 = rcp(b) estimate */
   if (mode == V16SFmode || mode == V8DFmode)
-emit_insn (gen_rtx_SET (x0, gen_rtx_UNSPEC (mode, gen_rtvec (1, b),
-   UNSPEC_RCP14)));
+{
+  if (TARGET_AVX512ER)
+   {
+ emit_insn (gen_rtx_SET (x0, gen_rtx_UNSPEC (mode, gen_rtvec (1, b),
+ UNSPEC_RCP28)));
+ /* res = a * x0 */
+ emit_insn (gen_rtx_SET (res, gen_rtx_MULT (mode, a, x0)));
+ return;
+   }
+  else
+   emit_insn (gen_rtx_SET (x0, gen_rtx_UNSPEC (mode, gen_rtvec (1, b),
+   UNSPEC_RCP14)));
+}
   else
 emit_insn (gen_rtx_SET (x0, gen_rtx_UNSPEC (mode, gen_rtvec (1, b),
UNSPEC_RCP)));
diff --git a/gcc/testsuite/gcc.target/i386/avx512er-vrcp28ps-3.c 
b/gcc/testsuite/gcc.target/i386/avx512er-vrcp28ps-3.c
new file mode 100644
index 000..e08bea4
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/avx512er-vrcp28ps-3.c
@@ -0,0 +1,50 @@
+/* { dg-do run } */
+/* { dg-require-effective-target avx512er } */
+/* { dg-options "-O2 -ffast-math -ftree-vectorize -mavx512er" } */
+
+#include "avx512er-check.h"
+
+#define MAX 1000
+#define EPS 0.1
+
+__attribute__ ((noinline, optimize (0)))
+void static
+compute_rcp_ref (float *a, float *b, float *r)
+{
+  for (int i = 0; i < MAX; i++)
+r[i] = a[i] / b[i];
+}
+
+__attribute__ ((noinline))
+void static
+compute_rcp_exp (float *a, float *b, float *r)
+{
+  for (int i = 0; i < MAX; i++)
+r[i] = a[i] / b[i];
+}
+
+void static
+avx512er_test (void)
+{
+  float a[MAX];
+  float b[MAX];
+  float ref[MAX];
+  float exp[MAX];
+
+  for (int i = 0; i < MAX; i++)
+{
+  a[i] = 179.345 - 6.5645 * i;
+  b[i] = 8765.987 - 8.6756 * i;
+}
+
+  compute_rcp_ref (a, b, ref);
+  compute_rcp_exp (a, b, exp);
+
+  for (int i = 0; i < MAX; i++)
+{
+  float rel_err = (ref[i] - exp[i]) / ref[i];
+  rel_err = rel_err > 0.0 ? rel_err : -rel_err;
+  if (rel_err > EPS)
+   abort ();
+}
+}
diff --git a/gcc/testsuite/gcc.target/i386/avx512er-vrcp28ps-4.c 
b/gcc/testsuite/gcc.target/i386/avx512er-vrcp28ps-4.c
new file mode 100644
index 000..2c76d96
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/avx512er-vrcp28ps-4.c
@@ -0,0 +1,6 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -ffast-math -ftree-vectorize -mavx512er" } */
+
+#include "avx512er-vrcp28ps-3.c"
+
+/* { dg-final { scan-assembler-times "vrcp28ps\[^\n\r\]*zmm\[0-9\]+(?:\n|\[ 
\\t\]+#)" 1 } } */


  -- Ilya

Re: [patch, avr] Fix PR30417: Wrap -Tdata into %{!Tdata:...}.

[Denis Chertykov]

2016-06-20 16:36 GMT+03:00 Georg-Johann Lay :
> This patch allows to specify -Tdata and -Ttext on the command line for MCUs
> where the specs file sets these options.  For -mmcu=atmega88 for example,
> the respective specs reads:
>
> *link_data_start:
> -Tdata 0x800100
>
> and the patch changes this to
>
> *link_data_start:
> %{!Tdata:-Tdata 0x800100}
>
> Same for *link_text_start and -Ttext.
>
> Ok for trunk and backport?
>
> Johann
>
>
> PR target/30417
> * config/avr/gen-avr-mmcu-specs.c (print_mcu):
> [*link_data_start]: Wrap -Tdata into %{!Tdata:...}.
> [*link_text_start]: Wrap -Ttext into %{!Ttext:...}.
>

Ok. Please apply.

[Bug target/71103] avr-gcc crashes with unrecognizable insn error

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #10 from Georg-Johann Lay  ---
Unfortunately there are now cases where the subregs pop up during reload and
hence copy_to_mode_reg is prohibited like with strftime from avr-libc :-( 
There are already insns that assume that subregs of constants work to some
degree like xload8_A and xload_A.  Maybe we'll have to support
subregs of constants in their own right...

[PATCH] x86-64: Load external function address via GOT slot

[H.J. Lu]

Hi,

This patch implements the alternate code sequence recommended in

https://groups.google.com/forum/#!topic/x86-64-abi/de5_KnLHxtI

to load external function address via GOT slot with

movq func@GOTPCREL(%rip), %rax

so that linker won't create an PLT entry for extern function
address.

Tested on x86-64.  OK for trunk?


H.J.
--
gcc/

PR target/67400
* config/i386/i386-protos.h (ix86_force_load_from_GOT_p): New.
* config/i386/i386.c (ix86_force_load_from_GOT_p): New function.
(ix86_legitimate_address_p): Allow UNSPEC_GOTPCREL if
ix86_force_load_from_GOT_p returns true.
(ix86_print_operand_address): Support UNSPEC_GOTPCREL if
ix86_force_load_from_GOT_p returns true.
(ix86_expand_move): Load the external function address via the
GOT slot if ix86_force_load_from_GOT_p returns true.
* config/i386/predicates.md (x86_64_immediate_operand): Return
false if ix86_force_load_from_GOT_p returns true.

gcc/testsuite/

PR target/67400
* gcc.target/i386/pr67400-1.c: New test.
* gcc.target/i386/pr67400-2.c: Likewise.
* gcc.target/i386/pr67400-3.c: Likewise.
* gcc.target/i386/pr67400-4.c: Likewise.
* gcc.target/i386/pr67400-5.c: Likewise.
* gcc.target/i386/pr67400-6.c: Likewise.
---
 gcc/config/i386/i386-protos.h |  1 +
 gcc/config/i386/i386.c| 51 +++
 gcc/config/i386/predicates.md |  4 +++
 gcc/testsuite/gcc.target/i386/pr67400-1.c | 13 
 gcc/testsuite/gcc.target/i386/pr67400-2.c | 14 +
 gcc/testsuite/gcc.target/i386/pr67400-3.c | 16 ++
 gcc/testsuite/gcc.target/i386/pr67400-4.c | 13 
 gcc/testsuite/gcc.target/i386/pr67400-5.c | 11 +++
 gcc/testsuite/gcc.target/i386/pr67400-6.c | 13 
 9 files changed, 136 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr67400-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr67400-2.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr67400-3.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr67400-4.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr67400-5.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr67400-6.c

diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
index 9fd14f6..8130161 100644
--- a/gcc/config/i386/i386-protos.h
+++ b/gcc/config/i386/i386-protos.h
@@ -70,6 +70,7 @@ extern bool ix86_expand_set_or_movmem (rtx, rtx, rtx, rtx, 
rtx, rtx,
 extern bool constant_address_p (rtx);
 extern bool legitimate_pic_operand_p (rtx);
 extern bool legitimate_pic_address_disp_p (rtx);
+extern bool ix86_force_load_from_GOT_p (rtx);
 extern void print_reg (rtx, int, FILE*);
 extern void ix86_print_operand (FILE *, rtx, int);
 
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 56a5b9c..c8c5081 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -15182,6 +15182,24 @@ ix86_legitimate_constant_p (machine_mode mode, rtx x)
   return true;
 }
 
+/* True if operand X should be loaded from GOT.  */
+
+bool
+ix86_force_load_from_GOT_p (rtx x)
+{
+  /* External function symbol should be loaded via the GOT slot for
+ -fno-plt.  */
+  return (!flag_plt
+ && !flag_pic
+ && ix86_cmodel != CM_LARGE
+ && TARGET_64BIT
+ && !TARGET_PECOFF
+ && !TARGET_MACHO
+ && GET_CODE (x) == SYMBOL_REF
+ && SYMBOL_REF_FUNCTION_P (x)
+ && !SYMBOL_REF_LOCAL_P (x));
+}
+
 /* Determine if it's legal to put X into the constant pool.  This
is not possible for the address of thread-local symbols, which
is checked above.  */
@@ -15560,6 +15578,10 @@ ix86_legitimate_address_p (machine_mode, rtx addr, 
bool strict)
return false;
 
  case UNSPEC_GOTPCREL:
+   gcc_assert (flag_pic
+   || ix86_force_load_from_GOT_p (XVECEXP (XEXP (disp, 0), 
0, 0)));
+   goto is_legitimate_pic;
+
  case UNSPEC_PCREL:
gcc_assert (flag_pic);
goto is_legitimate_pic;
@@ -18130,6 +18152,12 @@ ix86_print_operand_address_as (FILE *file, rtx addr,
}
   else if (flag_pic)
output_pic_addr_const (file, disp, 0);
+  else if (GET_CODE (disp) == CONST
+  && GET_CODE (XEXP (disp, 0)) == UNSPEC
+  && (XINT (XEXP (disp, 0), 1) == UNSPEC_GOTPCREL
+  || XINT (XEXP (disp, 0), 1) == UNSPEC_GOT)
+  && ix86_force_load_from_GOT_p (XVECEXP (XEXP (disp, 0), 0, 0)))
+   output_pic_addr_const (file, XEXP (disp, 0), code);
   else
output_addr_const (file, disp);
 }
@@ -19448,6 +19476,29 @@ ix86_expand_move (machine_mode mode, rtx operands[])
  op1 = convert_to_mode (mode, op1, 1);
}
}
+   }
+  else if (ix86_force_load_from_GOT_p (op1))
+{
+  /* Load the external function address via the GOT slot to
+avoid PLT.  */
+  op1 = 

[Bug target/71338] [RL78] mulu instruction not used on G10

[dj at redhat dot com]

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

--- Comment #4 from DJ Delorie  ---
Sure, the only dependencies might be on binutils/gdb releases, but they support
it and they're independent of gcc releases anyway.

[Bug c++/71593] initializing array with mixed constant and variable size results in error

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Last reconfirmed||2016-6-20
 CC||msebor at gcc dot gnu.org
 Blocks||16994
 Resolution|--- |DUPLICATE

--- Comment #1 from Martin Sebor  ---
Bug 58646 tracks this problem.

*** This bug has been marked as a duplicate of bug 58646 ***


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994
[Bug 16994] [meta-bug] VLA and C++

[Bug c++/58646] ICE on a multidimensional VLA with an empty initializer list

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||editing101 at aol dot com

--- Comment #7 from Martin Sebor  ---
*** Bug 71593 has been marked as a duplicate of this bug. ***

[Bug c++/16994] [meta-bug] VLA and C++

[msebor at gcc dot gnu.org]

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

Bug 71593 Summary: initializing array with mixed constant and variable size 
results in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71593

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash

[gcc at davidrobins dot net]

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

--- Comment #10 from David B. Robins  ---
My apologies, I saw the example you pointed at was from torture/ but
missed/forgot that you had also wanted the new test there. I moved the file to
torture and removed -O2 -fno-inline and I didn't get the failure. I did get it
when I added back only -fno-inline, which at least no longer depends on a
specific optimization level:

FAIL: g++.dg/torture/pr71571.C   -O2  execution test
FAIL: g++.dg/torture/pr71571.C   -O3 -g  execution test
FAIL: g++.dg/torture/pr71571.C   -Os  execution test
FAIL: g++.dg/torture/pr71571.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: g++.dg/torture/pr71571.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test

I also confirmed that it passed in the new location with the "fix to be
committed" fix.

Re: [PATCH 0/6] remove some usage of rtx_{insn,expr}_list

[Bernd Schmidt]

On 06/20/2016 12:22 PM, tbsaunde+...@tbsaunde.org wrote:

In theory I would expect if anything this helps performance since it isn't
necessary to malloc every time a node is added, however the data is less clear.


Well, we have alloc pools for these lists, so a malloc is not needed for 
every node.



fold const O2 new
real0m5.034s
user0m3.408s
sys 0m0.364s

fold const O2 old
real0m4.012s
user0m3.420s
sys 0m0.340s


So that's a second more in real time - was the machine very busy at the 
time you ran these tests so that these aren't meaningful, or is there a 
need to investigate this?



So a couple got about .3s slower, and others got about .1 faster, I'm not
really sure but inclined to say any change is too small to easily measure.

bootstrapped + regtested patches individually on x86_64-linux-gnu, ok?


Modulo the question about compile times I think patches 1-4 are ok, In 5 
and 6 I see explicit for loops instead of FOR_EACH macros; I'm curious 
as to the reason.



Bernd

Re: [PATCH] PR target/71549: Convert V1TImode register to TImode in debug insn

[H.J. Lu]

On Mon, Jun 20, 2016 at 7:30 AM, Ilya Enkovich  wrote:
> 2016-06-20 16:39 GMT+03:00 Uros Bizjak :
>> On Mon, Jun 20, 2016 at 1:55 PM, H.J. Lu  wrote:
>>> TImode register referenced in debug insn can be converted to V1TImode
>>> by scalar to vector optimization.  We need to convert a debug insn if
>>> it has a variable in a TImode register.
>>>
>>> Tested on x86-64.  OK for trunk?
>>
>> Ilya, does this approach look good to you? Also, does DImode STV
>> conversion need similar handling of debug insns?
>
> DImode conversion doesn't change register mode (i.e. never calls
> PUT_MODE for registers).  That keeps debug instructions valid.
>
> Overall I don't like the idea of having debug insns in candidates
> set and in chains.  Looks like it is possible to have a chain
> consisting of a debug insn only which is weird (otherwise I don't
> see why we may return false in timode_scalar_chain::convert_insn).

Yes, it can happen:

(insn 11 8 12 2 (parallel [
(set (reg/v:TI 91 [  ])
(plus:TI (reg/v:TI 92 [ a ])
(reg/v:TI 96 [ b ])))
(clobber (reg:CC 17 flags))
]) y.i:5 210 {*addti3_doubleword}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(debug_insn 12 11 13 2 (var_location:TI w (reg/v:TI 91 [  ])) y.i:5 -1
 (nil))


> What about other possible register uses?  If debug insns are added
> to candidates then NONDEBUG_INSN_P check for uses in
> timode_check_non_convertible_regs becomes invalid, right?

Debug insn has no impact on STV decision.  We just need to convert
register referenced in debug insn from V1TImode to TImode in
timode_scalar_chain::convert_insn.

> If we have (or want) to fix some register uses then it's probably
> would be better to visit register uses when we convert its mode
> and make required fix-ups.  It seems better to me to not involve
> debug insns in analysis phase.

Here is the updated patch to add debug insn, which references the
TImode register which will be converted to V1TImode to queue.
I am testing it now.

> Also I don't think debug insns should be accounted as optimized
> instructions because we would get different number of optimized
> instructions depending on debug info availability which may be
> inconvenient for dump scans (and it is not a real instruction
> optimization).
>
> Thanks,
> Ilya
>
>>
>> Uros.
>>
>>>
>>> H.J.
>>> 
>>> gcc/
>>>
>>> PR target/71549
>>> * config/i386/i386.c (timode_scalar_to_vector_candidate_p):
>>> Return true if debug insn has a variable in TImode register.
>>> (timode_remove_non_convertible_regs): Skip debug insn.
>>> (scalar_chain::convert_insn): Change return type to bool.
>>> (scalar_chain::add_insn): Don't check registers in debug insn.
>>> (dimode_scalar_chain::convert_insn): Change return type to bool
>>> and always return true.
>>> (timode_scalar_chain::convert_insn): Change return type to bool.
>>> Convert V1TImode register to SUBREG TImode in debug insn.  Return
>>> false if debug insn isn't converted.  Otherwise, return true.
>>> (scalar_chain::convert): Increment converted_insns only if
>>> convert_insn returns true.
>>>



-- 
H.J.
From 4229b304b98dff0190922ddd5270a1389321313b Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Sun, 19 Jun 2016 12:47:45 -0700
Subject: [PATCH] Convert V1TImode register to TImode in debug insn

TImode register referenced in debug insn can be converted to V1TImode
by scalar to vector optimization.  We need to convert a debug insn if
it references TImode register which will be converted to V1TImode.

gcc/

	PR target/71549
	* config/i386/i386.c (scalar_chain::analyze_register_chain): In
	64-bit mode, add debug insn, which references the register, to
	queue.
	(timode_scalar_chain::convert_insn): Convert V1TImode register
	to SUBREG TImode in debug insn.

gcc/testsuite/

	PR target/71549
	* gcc.target/i386/pr71549.c: New test.
---
 gcc/config/i386/i386.c  | 32 +++-
 gcc/testsuite/gcc.target/i386/pr71549.c | 24 
 2 files changed, 55 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr71549.c

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 56a5b9c..cea632c 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3229,8 +3229,22 @@ scalar_chain::analyze_register_chain (bitmap candidates, df_ref ref)
   for (chain = DF_REF_CHAIN (ref); chain; chain = chain->next)
 {
   unsigned uid = DF_REF_INSN_UID (chain->ref);
+  rtx_insn *insn = DF_REF_INSN (chain->ref);
 
-  if (!NONDEBUG_INSN_P (DF_REF_INSN (chain->ref)))
+  if (TARGET_64BIT && DEBUG_INSN_P (insn))
+	{
+	  /* In 64-bit mode, if a variable is put in a TImode register,
+	 which may be converted to V1TImode, we need to convert
+	 this 

[Bug c++/55203] No unused warning for variables of non-trivial types

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #14 from Martin Sebor  ---
(In reply to Marc Glisse from comment #13)

I would also find it preferable to have the warning issued by default without
requiring a special attribute to request it.  (The unused warning can
suppressed by annotating each unused object with attribute unused.  Whether or
not the object's ctor has side-effects seems orthogonal to whether the object
is actually used.)

Please see also bug 71456 and bug 71402 for some additional background and
discussion of the pros and cons of the approaches mentioned there.

[Bug c++/71576] [4.9/5/6/7 Regression] ICE on valid C++11 code (with xvalue and bitfield) on x86_64-linux-gnu: in build_target_expr, at cp/tree.c:385

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
s/properly/.
Anyway, the thing is that we use
cp_lvalue_kind lvalue = real_lvalue_p (expr);
and test the various clk_* bits from it, but this returns clk_none if
lvalue_kind has clk_class or clk_rvalueref set in it.
In this case, lvalue_kind (expr) is clk_bitfield | clk_class, and if we don't
want to ICE, for the creation of the temporary we need the bitfield type to be
widened to the underlying type.
So perhaps:
if (lvalue & clk_bitfield)
  {
expr = convert_bitfield_to_declared_type (expr);
expr = fold_convert (type, expr);
  }
should be if (lvalue_kind (expr) & clk_bitfield) instead, or just
unconditional?
What about the other lvalue & clk_* tests a few lines before?  Do they mean to
ignore clk_bitfield or clk_packed if clk_class (or clk_rvalueref) is also set?
If not, perhaps real_lvalue_p call should be replaced with lvalue_kind.

[Bug tree-optimization/71595] New: ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:704

[su at cs dot ucdavis.edu]

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

Bug ID: 71595
   Summary: ICE on valid code at -O2 and -O3 on x86_64-linux-gnu:
in check_loop_closed_ssa_use, at
tree-ssa-loop-manip.c:704
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-O2 and -O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes. 

It is a regression from 6.1.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160620 (experimental) [trunk revision 237587] (GCC) 
$ 
$ gcc-trunk -Os -c small.c
$ gcc-6.1 -O2 -c small.c
$ 
$ gcc-trunk -O2 -c small.c
small.c: In function ‘fn1’:
small.c:6:1: internal compiler error: in check_loop_closed_ssa_use, at
tree-ssa-loop-manip.c:704
 fn1 ()
 ^~~
0xd2e54c check_loop_closed_ssa_use
../../gcc-source-trunk/gcc/tree-ssa-loop-manip.c:703
0xd31306 check_loop_closed_ssa_stmt
../../gcc-source-trunk/gcc/tree-ssa-loop-manip.c:719
0xd31306 verify_loop_closed_ssa(bool)
../../gcc-source-trunk/gcc/tree-ssa-loop-manip.c:753
0xd1537e tree_unroll_loops_completely(bool, bool)
../../gcc-source-trunk/gcc/tree-ssa-loop-ivcanon.c:1431
0xd1540a execute
../../gcc-source-trunk/gcc/tree-ssa-loop-ivcanon.c:1537
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


-


volatile int a, e;
int c, d[1][5];
long b;

void
fn1 ()
{
  for (; c;)
{
  int f = c = 0;
  for (; c < 3; c++)
{
  c && a;
  if (e)
f = 1;
  b++;
  d[b][b + 1] = 1;
  if (f)
break;
}
}
}

[Bug c++/71590] G++ template function initialize with wrong type

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Martin Sebor  ---
It is true that there is no std::string::operator=(int) but the assignment in
'x = a' resolves to std::string::operator(char).  The program is valid.

Re: [Patch, Fortran] PR71194 - Fix ICE with pointer assignment

[Paul Richard Thomas]

Dear Tobias,

Impeccably done, as always :-) OK for trunk.

Thanks for the patch.

Cheers

Paul

On 20 June 2016 at 14:10, Tobias Burnus
 wrote:
> Dear all,
>
> the issue occurs only if the RHS of a pointer assignment is a function and
> the ICE is only triggered when a rank remapping is needed.
>
> gfc_conv_expr_descriptor calls for a expr2 gfc_conv_procedure_call, which
> sets "se.expr" to NULL_TREE - and the code later tries to access it.
>
> The code correctly sets rse.expr to "tmp", but that does not help as all
> actions were wrongly done on lse before. Solution: Stuff the RHS expr2 into
> rse not into lse.
>
> Build and regtested* on x86-64-gnu-linux.
> OK for the trunk?
>
> Tobias
>
> (* gfortran.dg/graphite/pr68279.f90 fails but is a known PR,
> gfortran.dg/vect/vect-8.f90 fails but not only for me, and
> gfortran.dg/guality/pr41558.f90 never worked on that system)



-- 
The difference between genius and stupidity is; genius has its limits.

Albert Einstein