[Bug target/71460] Copying structs can trap (on x86-32) due to SNaN to QNaN

[rguenther at suse dot de]

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

--- Comment #17 from rguenther at suse dot de  ---
On Thu, 9 Jun 2016, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460
> 
> --- Comment #13 from Uroš Bizjak  ---
> (In reply to Richard Biener from comment #7)
> 
> > Oh - I hope TYPE_MODE does not affect the ABI here ;)  You might want to
> > double-check that (struct-layout tests plus call ABI)
> The patch introduces one testsuite failure with -m32:
> 
> FAIL: g++.dg/torture/pr67581.C
> 
> where:
> 
> /home/uros/gcc-svn/trunk/gcc/testsuite/g++.dg/torture/pr67581.C:2:7: error:
> type transparent 'union U' cannot be made transparent because the type of the
> first field has a different ABI from the class overall
> 
> I don't know if this is c++ frontend issue, where BLKmode should be allowed.

But this also hints at the ABI for

void foo (union U { int x; float y; });

changing with the patch, no?  Or ultimatively at the FE using a bogus
check to verify ABI compatibility (just looking at TYPE_MODE).

[Bug tree-optimization/71485] g++ ICE on x86_64-linux-gnu in “gimplify_expr”

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-checking,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-10
 Ever confirmed|0   |1
  Known to fail||4.3.5, 4.8.5, 6.1.0, 7.0

--- Comment #1 from Richard Biener  ---
It also ICEs with 4.8 and 4.3 (you need checking enabled).  With 4.3 it also
ICEs w/o -m32 (and errors).

Confirmed.

[Bug tree-optimization/71483] [7 Regression] g++ ICE at -O3 on valid code on x86_64-linux-gnu with “Floating point exception”

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||alan.hayward at arm dot com
   Target Milestone|--- |7.0
Summary|g++ ICE at -O3 on valid |[7 Regression] g++ ICE at
   |code on x86_64-linux-gnu|-O3 on valid code on
   |with “Floating point|x86_64-linux-gnu with
   |exception”  |“Floating point exception”

[Bug c++/71482] Add -Wglobal-constructors warning option

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-10
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug tree-optimization/71477] [7 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu with “seg fault”

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-10
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |7.0
Summary|gcc ICE at -O3 on valid |[7 Regression] gcc ICE at
   |code on x86_64-linux-gnu|-O3 on valid code on
   |with “seg fault”|x86_64-linux-gnu with “seg
   ||fault”
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

#4  0x011666b3 in vect_transform_loop (loop_vinfo=0x27db8b0)
at /space/rguenther/src/svn/trunk/gcc/tree-vect-loop.c:6951
6951= wi::udiv_floor (loop->nb_iterations_likely_upper_bound + 1,
(gdb) l
6946}
6947  loop->nb_iterations_upper_bound
6948= wi::udiv_floor (loop->nb_iterations_upper_bound + 1,
6949  vectorization_factor) - 1;
6950  loop->nb_iterations_likely_upper_bound
6951= wi::udiv_floor (loop->nb_iterations_likely_upper_bound + 1,
6952  vectorization_factor) - 1;

(gdb) p loop->nb_iterations_likely_upper_bound
$2 = {> = {val = {0, 0, 0, 0}, len = 0}, 
  static is_sign_extended = }

so likely_upper_bound is not initialized.  I have an obvious patch.

[Bug c/71475] Optimization of copying into long double looses bytes

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-10
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I will have a look.

[Bug target/71460] Copying structs can trap (on x86-32) due to SNaN to QNaN

[ubizjak at gmail dot com]

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

--- Comment #18 from Uroš Bizjak  ---
(In reply to rguent...@suse.de from comment #17)
> But this also hints at the ABI for
> 
> void foo (union U { int x; float y; });
> 
> changing with the patch, no?  Or ultimatively at the FE using a bogus
> check to verify ABI compatibility (just looking at TYPE_MODE).

No, there is no ABI violation. The testcase:

--cut here--
union U { int x; float y; };

void foo (union U);

void test (void)
{
  union U t;

  t.y = 1.0f;
  foo (t);

  t.x = 1;
  foo (t);
}
--cut here--

results in (-O2 -mfpmath=387 -m32):

pushl   $1065353216
callfoo
movl$1, (%esp)
callfoo

The asm is also correct with -mregparm=1:

movl$1065353216, %eax
callfoo
movl$1, %eax
callfoo

[Bug tree-optimization/71477] [7 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu with “seg fault”

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Fixed.

[Bug tree-optimization/71477] [7 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu with “seg fault”

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Fri Jun 10 07:30:45 2016
New Revision: 237287

URL: https://gcc.gnu.org/viewcvs?rev=237287&root=gcc&view=rev
Log:
2016-06-10  Richard Biener  

PR middle-end/71477
* cfgloop.c (alloc_loop): Initialize nb_iterations_likely_upper_bound.

* gcc.dg/torture/pr71477.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr71477.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgloop.c
trunk/gcc/testsuite/ChangeLog

[Bug target/71460] Copying structs can trap (on x86-32) due to SNaN to QNaN

[ubizjak at gmail dot com]

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

--- Comment #19 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #18)
> (In reply to rguent...@suse.de from comment #17)
> > But this also hints at the ABI for
> > 
> > void foo (union U { int x; float y; });
> > 
> > changing with the patch, no?  Or ultimatively at the FE using a bogus
> > check to verify ABI compatibility (just looking at TYPE_MODE).

Following test doesn't compile with patched compiler:

--cut here--
union U { int x; float y; } __attribute__ ((transparent_union));

void foo (union U);

void test (void)
{
  union U t;

  foo (1.0f);

  foo (1);
}
--cut here--

-O2 -mfpmath=387 -m32:

union.c:1:7: warning: union cannot be made transparent
 union U { int x; float y; } __attribute__ ((transparent_union));

but does compile OK with:

-msse -O2 -mfpmath=sse -m32

[Bug target/71460] Copying structs can trap (on x86-32) due to SNaN to QNaN

[rguenther at suse dot de]

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

--- Comment #20 from rguenther at suse dot de  ---
On Fri, 10 Jun 2016, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460
> 
> --- Comment #19 from Uroš Bizjak  ---
> (In reply to Uroš Bizjak from comment #18)
> > (In reply to rguent...@suse.de from comment #17)
> > > But this also hints at the ABI for
> > > 
> > > void foo (union U { int x; float y; });
> > > 
> > > changing with the patch, no?  Or ultimatively at the FE using a bogus
> > > check to verify ABI compatibility (just looking at TYPE_MODE).
> 
> Following test doesn't compile with patched compiler:
> 
> --cut here--
> union U { int x; float y; } __attribute__ ((transparent_union));
> 
> void foo (union U);
> 
> void test (void)
> {
>   union U t;
> 
>   foo (1.0f);
> 
>   foo (1);
> }
> --cut here--
> 
> -O2 -mfpmath=387 -m32:
> 
> union.c:1:7: warning: union cannot be made transparent
>  union U { int x; float y; } __attribute__ ((transparent_union));
> 
> but does compile OK with:
> 
> -msse -O2 -mfpmath=sse -m32

So another way to avoid the issue in this PR is to not change the
types mode but avoid using TYPE_MODE when expanding aggregate copies
and those modes would be "bad" (not sure if we can somehow use the
same target hook for this).  But it really seems the hook was designed
for this ...

[Bug c/68657] [6 Regression] "gcc -Werror=sign-conversion test.i" shows invalid: -Wsign-conversion is not an option that controls warnings

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Created attachment 38672
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38672&action=edit
gcc7-pr68657.patch

Untested fix.  With -Werror we even suggest in diagnostic -Werror=psabi, which
doesn't actually work.  That said, this should have been filed as a separate
PR, rather than hijacking an already fixed one.

[Bug target/71475] [6/7 Regression] Optimization of copying into long double looses bytes

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||i?86-*-*
 Status|ASSIGNED|NEW
  Component|c   |target
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
   Target Milestone|--- |6.2
Summary|Optimization of copying |[6/7 Regression]
   |into long double looses |Optimization of copying
   |bytes   |into long double looses
   ||bytes

--- Comment #2 from Richard Biener  ---
Ok, so we arrive (slowly) at

  MEM[(char * {ref-all})&d0] = 0x41414141414141414141414141414141;
  d0.3_6 = d0;
  d = d0.3_6;
  d.4_7 = d;
  printf ("after memcpy: %Lf\n", d.4_7);

which is then optimized by CSE to

  MEM[(char * {ref-all})&d0] = 0x41414141414141414141414141414141;
  d = 4.35573826932891467758901725805789285479666446831741854231e+96;
  printf ("after memcpy: %Lf\n",
4.35573826932891467758901725805789285479666446831741854231e+96);

and thus the issue must be that FP literal passing to printf is broken somehow.

The first call is expanded to:

;; printf ("after memset: %Lf\n", d0.0_1);

(insn 28 27 29 (set (mem:XF (pre_dec:DI (reg/f:DI 7 sp)) [1  S16 A128])
(reg:XF 99 [ d0.0_1 ])) t.c:11 -1
 (expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil)))

(insn 29 28 30 (set (reg:DI 5 di)
(symbol_ref/f:DI ("*.LC0") [flags 0x2]  )) t.c:11 -1
 (nil))

(insn 30 29 31 (set (reg:QI 0 ax)
(const_int 0 [0])) t.c:11 -1
 (nil))

(call_insn 31 30 0 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:DI ("printf") [flags 0x41]  ) [0 __builtin_printf S1 A8])
(const_int 16 [0x10]))) t.c:11 -1
 (expr_list:REG_CALL_DECL (symbol_ref:DI ("printf") [flags 0x41] 
)
(nil))

while the second:

;; printf ("after memcpy: %Lf\n",
4.35573826932891467758901725805789285479666446831741854231e+96);

(insn 53 52 54 (set (reg:XF 116)
(mem/u/c:XF (symbol_ref/u:DI ("*.LC2") [flags 0x2]) [1  S16 A128]))
t.c:20 -1
 (nil))

(insn 54 53 55 (set (mem:XF (pre_dec:DI (reg/f:DI 7 sp)) [1  S16 A128])
(reg:XF 116)) t.c:20 -1
 (expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil)))

(insn 55 54 56 (set (reg:DI 5 di)
(symbol_ref/f:DI ("*.LC3") [flags 0x2]  )) t.c:20 -1
 (nil))

(insn 56 55 57 (set (reg:QI 0 ax)
(const_int 0 [0])) t.c:20 -1
 (nil))
(call_insn 57 56 0 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:DI ("printf") [flags 0x41]  ) [0 __builtin_printf S1 A8])
(const_int 16 [0x10]))) t.c:20 -1
 (expr_list:REG_CALL_DECL (symbol_ref:DI ("printf") [flags 0x41] 
)
(nil))

with assembly:

movabsq $4702111234474983745, %rax
...
movq%rax, 16(%rsp)
movq%rax, 24(%rsp)
xorl%eax, %eax
fldt16(%rsp)
fld %st(0)
fstpt   32(%rsp)
fstpt   (%rsp)
callprintf

vs.

fldt.LC2(%rip)
movabsq $4702111234474983745, %rdx
movabsq $4702111234474983745, %rax
subq$16, %rsp
.cfi_def_cfa_offset 80
movq%rax, 16(%rsp)
movq%rdx, 24(%rsp)
movl$.LC3, %edi
xorl%eax, %eax
fld %st(0)
fstpt   32(%rsp)
fstpt   (%rsp)
callprintf

So confirmed, but it looks like an RTL optimization / target (regstack related)
issue.  The testcase itself is a GCC 6 regression but I guess that using
a FP literal (if one can express that value...) would produce the same issue?

[Bug target/71460] Copying structs can trap (on x86-32) due to SNaN to QNaN

[ubizjak at gmail dot com]

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

--- Comment #21 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #19)
> Following test doesn't compile with patched compiler:

BTW: This is preexisting problem, on 64bit target we can trigger the issue with
transparent unions with:

--cut here--
union U { __int128 x; long double y; }  __attribute__ ((transparent_union));

void foo (union U);

void test (void)
{
  union U t;

  foo (1.0L);

  foo ( (__int128) 1);
}
--cut here--

-O2:

union.c:1:7: warning: union cannot be made transparent
 union U { __int128 x; long double y; }  __attribute__ ((transparent_union));

[Bug libstdc++/71107] wstring_convert::from_bytes produces wide chars with the wrong byte order

[cantabile.desu at gmail dot com]

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

--- Comment #4 from Bitterblue  ---
So, uh, any idea why this is happening?

[Bug sanitizer/71480] ASan should align string constants to shadow granularity.

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
It most likely affects powerpc* too.  Anyway, patch LGTM, preapproved for trunk
with proper ChangeLog and if possible some reduced testcase (e.g. remove all
headers, replace mkstemp/unlink/fstat functions with (differently named)
noinline/noclone functions that just return/fill in what you need, without any
fs access etc., and define your own struct stat (again, rename it).

[Bug target/71475] [6/7 Regression] Optimization of copying into long double looses bytes

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I think the testcase is just flawed.  long doubles have padding inside of them,
you are copying those through long double assignment, why do you think it
should preserve the padding bits?  It of course does not.
Already the
d = 4.35573826932891467758901725805789285479666446831741854231e+96;
doesn't have any particular values for the padding bits.

[Bug target/71486] New: Transparent union doesn't work with long double for x86_64

[ubizjak at gmail dot com]

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

Bug ID: 71486
   Summary: Transparent union doesn't work with long double for
x86_64
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Following testcase:

--cut here--
union U { __int128 x; long double y; }  __attribute__ ((transparent_union));

void foo (union U);

void test (void)
{
  union U t;

  foo (1.0L);

  foo ( (__int128) 1);
}
--cut here--

gcc -O2:

union.c:1:7: warning: union cannot be made transparent
 union U { __int128 x; long double y; }  __attribute__ ((transparent_union));
   ^
 test
union.c: In function ‘test’:
union.c:9:3: error: incompatible type for argument 1 of ‘foo’
   foo (1.0L);
   ^
union.c:3:6: note: expected ‘union U’ but argument is of type ‘long double’
 void foo (union U);
  ^
union.c:11:3: error: incompatible type for argument 1 of ‘foo’
   foo ( (__int128) 1);
   ^
union.c:3:6: note: expected ‘union U’ but argument is of type ‘__int128’
 void foo (union U);
  ^

However, the test without transparent union:

--cut here--
union U { __int128 x; long double y; };

void foo (union U);

void test (void)
{
  union U t;

  t.y = 1.0L;
  foo (t);

  t.x = (__int128) 1;
  foo (t);
}
--cut here--

compiles OK.

[Bug sanitizer/71480] ASan should align string constants to shadow granularity.

[m.ostapenko at samsung dot com]

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

--- Comment #3 from Maxim Ostapenko  ---
Thanks, will post the fix in ML soon.

[Bug target/71460] Copying structs can trap (on x86-32) due to SNaN to QNaN

[rguenth at gcc dot gnu.org]

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

--- Comment #22 from Richard Biener  ---
(In reply to Alexander Cherepanov from comment #12)
> On 2016-06-09 11:22, rguenth at gcc dot gnu.org wrote:
> > Would be nice to have a testcase for the SRA case as well.
> 
> Source code:
> 
> --
> #define _GNU_SOURCE
> #include 
> 
> struct s { double d; char c; };
> 
> __attribute__((noinline,noclone))
> void copy(struct s *q, struct s *p)
> {
>struct s tmp = *p;
>*q = tmp;
> }
> 
> int main()
> {
>feenableexcept(FE_INVALID);
> 
>struct s x = {0}, y;
>((unsigned char *)&x.d)[7] = 0x7f;
>((unsigned char *)&x.d)[6] = 0xf0; // sNaN
>((unsigned char *)&x.d)[0] = 0x01;
> 
>copy(&y, &x);
> }
> --
> 
> Results:
> 
> --
> $ gcc -std=c11 -pedantic -Wall -Wextra -fsignaling-nans -lm -m32 -O3 
> test.c && ./a.out
> Floating point exception
> --
> 
> gcc version: gcc (GCC) 7.0.0 20160608 (experimental)

So for this one the following would work together with the proposed backend
fix (but not for the array case).  It also makes me think using this target
hook is not really the thing to test here given its docs:

"
@deftypefn {Target Hook} bool TARGET_MEMBER_TYPE_FORCES_BLK (const_tree
@var{field}, machine_mode @var{mode})
Return true if a structure, union or array containing @var{field} should
be accessed using @code{BLKMODE}.

If @var{field} is the only field in the structure, @var{mode} is its
mode, otherwise @var{mode} is VOIDmode.  @var{mode} is provided in the
case where structures of one field would require the structure's mode to
retain the field's mode.

Normally, this is not needed.
"

another thing to test here would be MODE_HAS_NANS, but that's too general
I think.  It seems we lack sth to query from the target, like
MODE_ACCESS_CAN_TRAP or so (just thinking of IA64 NaT stuff).  At least
the following points out the place in SRA to put the fix in - it guards
the case artificial accesses are created for a struct copy (though not
all of them are ultimatively used - SRA works too "local" for them).  We
need to be careful to be not too conservative and disable too much of SRA.
The hook seems to be used to avoid various issues, not only trapping.

Index: gcc/tree-sra.c
===
--- gcc/tree-sra.c  (revision 237286)
+++ gcc/tree-sra.c  (working copy)
@@ -969,6 +969,9 @@ scalarizable_type_p (tree type)
  if (DECL_BIT_FIELD (fld))
return false;

+ if (targetm.member_type_forces_blk (fld, TYPE_MODE (ft)))
+   return false;
+
  if (!is_gimple_reg_type (ft)
  && !scalarizable_type_p (ft))
return false;
@@ -994,6 +997,10 @@ scalarizable_type_p (tree type)
return false;

   tree elem = TREE_TYPE (type);
+
+  if (targetm.member_type_forces_blk (elem, TYPE_MODE (elem)))
+   return false;
+
   if (!is_gimple_reg_type (elem)
 && !scalarizable_type_p (elem))
return false;

[Bug c/71479] error on __builtin_add_overflow with bool or enum pointer as last argument

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
I see that in __builtin_*_overflow_p I'm actually checking just INTEGRAL_TYPE_P
rather than INTEGER_TYPE for the last argument.
But, I think I'm in favor of tweaking the documentation and only allowing for
*_overflow pointer to T, for *_overflow_p T, where T is integral type other
than boolean or enumeration type.
While for _Bool/bool, it is not that hard to define what exactly it would mean
(check if the infinite precision result is 0 or 1 or not), for enums, would we
check if it fits into the underlying type, or fits into the strict precision of
the enum, have different behavior based on -fstrict-enums, or check if there is
any enumerator at that point, ... ?

[Bug c++/71487] New: sorry, unimplemented: mangling offset_ref

[lemonedo at gmail dot com]

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

Bug ID: 71487
   Summary: sorry, unimplemented: mangling offset_ref
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lemonedo at gmail dot com
  Target Milestone: ---

The following C++ code does not compile with GCC 5.3.1.

#include 
#include 

template T& declval() { return *static_cast(0); }

template
struct PropertyMatcher {
   F memfun;
   T expected;

   PropertyMatcher(F memfun, T expected) : memfun(memfun), expected(expected)
{}

   template
   void operator()(U actual) {
 std::cout << ((actual.*memfun)() == expected) << std::endl;
   }
};

template
PropertyMatcher Property(F memfun, T expected) {
  return PropertyMatcher(memfun, expected);
}

template
auto HasLength(T expected) -> decltype(Property(&std::string::size,
declval())) {
  return Property(&std::string::size, expected);
}

int main() {
  HasLength(3)(std::string("hel"));
}

[Bug target/71460] Copying structs can trap (on x86-32) due to SNaN to QNaN

[ubizjak at gmail dot com]

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

--- Comment #23 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #21)
> BTW: This is preexisting problem, on 64bit target we can trigger the issue
> with transparent unions with:

Followup in PR71486.

[Bug c++/71487] sorry, unimplemented: mangling offset_ref

[lemonedo at gmail dot com]

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

--- Comment #1 from Chungmin Lee  ---
You might say that in the above scenario HasLength does not have to be a
template, but it is just a simplified example.

[Bug target/71488] New: Wrong code on GCC trunk with ivybridge and westmere targets

[anton.mitrokhin at phystech dot edu]

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

Bug ID: 71488
   Summary: Wrong code on GCC trunk with ivybridge and westmere
targets
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton.mitrokhin at phystech dot edu
  Target Milestone: ---

Created attachment 38673
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38673&action=edit
Reproducer

It looks like the result on -O3 is incorrect

Reproduce:
> g++ -std=c++11 -static-libgcc -static-libstdc++ -O0 -march=westmere -o out 
> crash.cpp

Output: -5386832788153059297

> g++ -std=c++11 -static-libgcc -static-libstdc++ -O3 -march=westmere -o out 
> crash.cpp
Output: -5386832788153059298

> g++ -std=c++11 -static-libgcc -static-libstdc++ -O0 -march=ivybridge -o out 
> crash.cpp
Output: -5386832788153059297

> g++ -std=c++11 -static-libgcc -static-libstdc++ -O3 -march=ivybridge -o out 
> crash.cpp
Output: -5386832788153059298


> gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/export/users/amitrokh/gcc_trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /export/users/gnutester/stability/svn/trunk/configure
--with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld --enable-cloog-backend=isl
--with-fpmath=sse --with-pkgversion=Revision=237240/svn-rev:237241/
--prefix=/export/users/gnutester/stability/work/trunk/64/install
--enable-languages=c,c++,fortran,java,lto
Thread model: posix
gcc version 7.0.0 20160608 (experimental) (Revision=237240/svn-rev:237241/)

[Bug c++/71487] sorry, unimplemented: mangling offset_ref

[lemonedo at gmail dot com]

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

--- Comment #2 from Chungmin Lee  ---
Command: g++ -std=c++11 a.cpp

[Bug target/71281] [7 Regression] ICE on gcc trunk on knl, wsm, ivb and bdw targets (tree-ssa-reassoc)

[anton.mitrokhin at phystech dot edu]

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

--- Comment #8 from Anton Mitrokhin  ---
Is this fixed?

[Bug testsuite/71489] [7 regression] gcc.dg/tree-ssa/attr-hotcold-2.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug testsuite/71489] New: [7 regression] gcc.dg/tree-ssa/attr-hotcold-2.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 71489
   Summary: [7 regression] gcc.dg/tree-ssa/attr-hotcold-2.c FAILs
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-pc-solaris2.*, sparc-sun-solaris2.*
Target: i386-pc-solaris2.*, sparc-sun-solaris2.*
 Build: i386-pc-solaris2.*, sparc-sun-solaris2.*

Between 20160606 and 20160609, the gcc.dg/tree-ssa/attr-hotcold-2.c test
started
to error out:

+ERROR: gcc.dg/tree-ssa/attr-hotcold-2.c: error executing dg-final: syntax
error in target selector "profile_estimate"
+UNRESOLVED: gcc.dg/tree-ssa/attr-hotcold-2.c: error executing dg-final: syntax
error in target selector "profile_estimate"

This is due to a syntax error in Jan's last change:

/* { dg-final { scan-tree-dump-times 1 "hot label heuristics" 1
"profile_estimat
e" } } */
/* { dg-final { scan-tree-dump-times 1 "cold label heuristics" 1
"profile_estima
te" } } */

The first arg to scan-tree-dump times is supposed to be a regexp, not a count.
But even with that fixed, the testcase FAILs:

FAIL: gcc.dg/tree-ssa/attr-hotcold-2.c scan-tree-dump-times profile_estimate
"block 4, loop depth 0, count 0, freq [1-4][^0-9]" 1

;; basic block 4, loop depth 0, count 0, freq 2, maybe hot
;;   basic block 4, loop depth 0, count 0, freq 2, maybe hot
;;   basic block 4, loop depth 0, count 0, freq 2

FAIL: gcc.dg/tree-ssa/attr-hotcold-2.c scan-tree-dump-times profile_estimate
"block 5, loop depth 0, count 0, freq [6-9][0-9][0-9][0-9]" 1

;; basic block 5, loop depth 0, count 0, freq 7660, maybe hot
;;   basic block 5, loop depth 0, count 0, freq 7660, maybe hot
;;   basic block 5, loop depth 0, count 0, freq 7660, maybe hot

This is a regression from the gcc-6 branch.

  Rainer

[Bug tree-optimization/71407] [7 Regression] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (verify_gimple: integral result type precision does not match field size of BIT_FIELD_REF)

[alahay01 at gcc dot gnu.org]

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

--- Comment #8 from alahay01 at gcc dot gnu.org ---
Author: alahay01
Date: Fri Jun 10 08:46:55 2016
New Revision: 237288

URL: https://gcc.gnu.org/viewcvs?rev=237288&root=gcc&view=rev
Log:
2016-06-10  Alan Hayward  

gcc/
PR tree-optimization/71407
PR tree-optimization/71416
* tree-vect-loop.c (vectorizable_live_operation): Use vectype for
BIT_FIELD_REF type.

testsuite/
PR tree-optimization/71407
PR tree-optimization/71416
* gcc.dg/vect/pr71407.c: New
* gcc.dg/vect/pr71416-1.c: New
* gcc.dg/vect/pr71416-2.c: New


Added:
trunk/gcc/testsuite/gcc.dg/vect/pr71407.c
trunk/gcc/testsuite/gcc.dg/vect/pr71416-1.c
trunk/gcc/testsuite/gcc.dg/vect/pr71416-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug tree-optimization/71416] [7 Regression] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (vectorizable_live_operation)

[alahay01 at gcc dot gnu.org]

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

--- Comment #5 from alahay01 at gcc dot gnu.org ---
Author: alahay01
Date: Fri Jun 10 08:46:55 2016
New Revision: 237288

URL: https://gcc.gnu.org/viewcvs?rev=237288&root=gcc&view=rev
Log:
2016-06-10  Alan Hayward  

gcc/
PR tree-optimization/71407
PR tree-optimization/71416
* tree-vect-loop.c (vectorizable_live_operation): Use vectype for
BIT_FIELD_REF type.

testsuite/
PR tree-optimization/71407
PR tree-optimization/71416
* gcc.dg/vect/pr71407.c: New
* gcc.dg/vect/pr71416-1.c: New
* gcc.dg/vect/pr71416-2.c: New


Added:
trunk/gcc/testsuite/gcc.dg/vect/pr71407.c
trunk/gcc/testsuite/gcc.dg/vect/pr71416-1.c
trunk/gcc/testsuite/gcc.dg/vect/pr71416-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug target/71281] [7 Regression] ICE on gcc trunk on knl, wsm, ivb and bdw targets (tree-ssa-reassoc)

[kugan at gcc dot gnu.org]

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

--- Comment #9 from kugan at gcc dot gnu.org ---
(In reply to Anton Mitrokhin from comment #8)
> Is this fixed?

Yes. Is this still not working for you?

[Bug tree-optimization/71407] [7 Regression] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (verify_gimple: integral result type precision does not match field size of BIT_FIELD_REF)

[alahay01 at gcc dot gnu.org]

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

alahay01 at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from alahay01 at gcc dot gnu.org ---
Fixed.

[Bug tree-optimization/71490] New: [7 regression] gcc.dg/tree-ssa/slsr-8.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 71490
   Summary: [7 regression] gcc.dg/tree-ssa/slsr-8.c FAILs
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-pc-solaris2.*, sparc-sun-solaris2.*
Target: i386-pc-solaris2.*, sparc-sun-solaris2.*
 Build: i386-pc-solaris2.*, sparc-sun-solaris2.*

Between 20160606 and 20160606, the gcc.dg/tree-ssa/slsr-8.c testcase started to
FAIL:

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

Before, we had

f (int s, int * c)
 int * x3;
  int * x2;
  int * x1;
  int * iftmp.3_10;
  a1_12 = s_11(D) * 2;
  _2 = a1.0_1 * 4;

in the dump, now there's

f (int s, int * c)
  int * x3;
  int * x2;
  int * x1;
  int * iftmp.3_10;
  a1_12 = s_11(D) * 2;
  _2 = a1.0_1 * 4;
  slsr_20 = s_11(D) * -16;
  x3_18 = (int *) slsr_20;

i.e. a change from 7 to 9 matches.

This is a regression from the gcc-6 branch.

  Rainer

[Bug tree-optimization/71490] [7 regression] gcc.dg/tree-ssa/slsr-8.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug tree-optimization/71491] gcc.dg/vect/slp-43.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug tree-optimization/71491] New: gcc.dg/vect/slp-43.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 71491
   Summary: gcc.dg/vect/slp-43.c FAILs
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: sparc*-sun-solaris2.*
Target: sparc*-sun-solaris2.*
 Build: sparc*-sun-solaris2.*

Created attachment 38674
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38674&action=edit
slp-43.c.149t.vect

The new gcc.dg/vect/slp-43.c testcase FAILs on Solaris/SPARC:

+FAIL: gcc.dg/vect/slp-43.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"
vectorized 1 loops" 13
+FAIL: gcc.dg/vect/slp-43.c scan-tree-dump-times vect "vectorized 1 loops" 13

both 32 and 64-bit.

There are only 2 matching lines in the dump, and several instances each of

/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/slp-43.c:35:1: note: not
vectorized: unsupported unaligned load.*in_1

/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/slp-43.c:73:3: note: not
v
ectorized: control flow in loop.

/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/slp-43.c:55:3: note: not
vectorized: loop contains function calls or data references that cannot be
analyzed

I'm attaching the dump.

  Rainer

[Bug c/71479] error on __builtin_add_overflow with bool or enum pointer as last argument

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
BTW, for __builtin_add_overflow_p with _Bool as last argument (which isn't
rejected, going to fix that momentarily) we don't emit the expected test
whether the result is 0/1, but whether it fits 8 bits unsigned.  Also, _Complex
_Bool
or _Complex enum ... is something way too weird for the middle-end.

[Bug tree-optimization/71439] [7 Regression] wrong code at -O3 in 32-bit and 64-bit mode on x86_64-linux-gnu

[alahay01 at gcc dot gnu.org]

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

alahay01 at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #2 from alahay01 at gcc dot gnu.org ---
This is due to a loop having a live PHI which we allow in the vectorisation. We
then fail to replace the PHI with a vectorised version.

The bug is only triggered because the vectorised loop runs exactly once.

[Bug c/71381] C/C++ OpenACC cache directive rejects valid syntax

[tschwinge at gcc dot gnu.org]

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

--- Comment #2 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Jun 10 09:22:38 2016
New Revision: 237290

URL: https://gcc.gnu.org/viewcvs?rev=237290&root=gcc&view=rev
Log:
[PR c/71381] C/C++ OpenACC cache directive rejects valid syntax

gcc/c/
PR c/71381
* c-parser.c (c_parser_omp_variable_list) :
Loosen checking.
gcc/cp/
PR c/71381
* parser.c (cp_parser_omp_var_list_no_open) :
Loosen checking.
gcc/fortran/
PR c/71381
* openmp.c (gfc_match_oacc_cache): Add comment.
gcc/testsuite/
PR c/71381
* c-c++-common/goacc/cache-1.c: Update.  Move invalid usage tests
to...
* c-c++-common/goacc/cache-2.c: ... this new file.
* gfortran.dg/goacc/cache-1.f95: Move invalid usage tests to...
* gfortran.dg/goacc/cache-2.f95: ... this new file.
* gfortran.dg/goacc/coarray.f95: Update OpenACC cache directive
usage.
* gfortran.dg/goacc/cray.f95: Likewise.
* gfortran.dg/goacc/loop-1.f95: Likewise.
libgomp/
PR c/71381
* testsuite/libgomp.oacc-c-c++-common/cache-1.c: #include
"../../../gcc/testsuite/c-c++-common/goacc/cache-1.c".
* testsuite/libgomp.oacc-fortran/cache-1.f95: New file.

gcc/
* omp-low.c (scan_sharing_clauses): Don't expect
OMP_CLAUSE__CACHE_.

Added:
trunk/gcc/testsuite/c-c++-common/goacc/cache-2.c
  - copied, changed from r237289,
trunk/gcc/testsuite/c-c++-common/goacc/cache-1.c
trunk/gcc/testsuite/gfortran.dg/goacc/cache-2.f95
trunk/libgomp/testsuite/libgomp.oacc-fortran/cache-1.f95
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/openmp.c
trunk/gcc/omp-low.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/cache-1.c
trunk/gcc/testsuite/gfortran.dg/goacc/cache-1.f95
trunk/gcc/testsuite/gfortran.dg/goacc/coarray.f95
trunk/gcc/testsuite/gfortran.dg/goacc/cray.f95
trunk/gcc/testsuite/gfortran.dg/goacc/loop-1.f95
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/cache-1.c

[Bug middle-end/71373] Handle more OMP_CLAUSE_* in nested function decomposition

[tschwinge at gcc dot gnu.org]

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

--- Comment #2 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Jun 10 09:22:51 2016
New Revision: 237291

URL: https://gcc.gnu.org/viewcvs?rev=237291&root=gcc&view=rev
Log:
[PR middle-end/71373] Handle more OMP_CLAUSE_* in nested function decomposition

gcc/
* gimplify.c (gimplify_adjust_omp_clauses): Discard
OMP_CLAUSE_TILE.
* omp-low.c (scan_sharing_clauses): Don't expect OMP_CLAUSE_TILE.
gcc/testsuite/
* c-c++-common/goacc/combined-directives.c: XFAIL tree scanning
for OpenACC tile clauses.
* gfortran.dg/goacc/combined-directives.f90: Likewise.

gcc/
PR middle-end/71373
* tree-nested.c (convert_nonlocal_omp_clauses)
(convert_local_omp_clauses): Handle OMP_CLAUSE_ASYNC,
OMP_CLAUSE_WAIT, OMP_CLAUSE_INDEPENDENT, OMP_CLAUSE_AUTO,
OMP_CLAUSE__CACHE_, OMP_CLAUSE_TILE.
gcc/testsuite/
PR middle-end/71373
* gcc.dg/goacc/nested-function-1.c: New file.
* gcc.dg/goacc/nested-function-2.c: Likewise.
* gcc.dg/goacc/pr71373.c: Likewise.
* gfortran.dg/goacc/cray-2.f95: Likewise.
* gfortran.dg/goacc/loop-1-2.f95: Likewise.
* gfortran.dg/goacc/loop-3-2.f95: Likewise.
* gfortran.dg/goacc/cray.f95: Update.
* gfortran.dg/goacc/loop-1.f95: Likewise.
* gfortran.dg/goacc/loop-3.f95: Likewise.
* gfortran.dg/goacc/subroutines.f90: Update, and rename to...
* gfortran.dg/goacc/nested-function-1.f90: ... this new file.
libgomp/testsuite/
PR middle-end/71373
* libgomp.oacc-c/nested-function-1.c: New file.
* libgomp.oacc-c/nested-function-2.c: Likewise.
* libgomp.oacc-fortran/nested-function-1.f90: Likewise.
* libgomp.oacc-fortran/nested-function-2.f90: Likewise.
* libgomp.oacc-fortran/nested-function-3.f90: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/goacc/nested-function-1.c
trunk/gcc/testsuite/gcc.dg/goacc/nested-function-2.c
trunk/gcc/testsuite/gcc.dg/goacc/pr71373.c
trunk/gcc/testsuite/gfortran.dg/goacc/cray-2.f95
  - copied, changed from r237290,
trunk/gcc/testsuite/gfortran.dg/goacc/cray.f95
trunk/gcc/testsuite/gfortran.dg/goacc/loop-1-2.f95
  - copied, changed from r237290,
trunk/gcc/testsuite/gfortran.dg/goacc/loop-1.f95
trunk/gcc/testsuite/gfortran.dg/goacc/loop-3-2.f95
  - copied, changed from r237290,
trunk/gcc/testsuite/gfortran.dg/goacc/loop-3.f95
trunk/gcc/testsuite/gfortran.dg/goacc/nested-function-1.f90
trunk/libgomp/testsuite/libgomp.oacc-c/nested-function-1.c
trunk/libgomp/testsuite/libgomp.oacc-c/nested-function-2.c
trunk/libgomp/testsuite/libgomp.oacc-fortran/nested-function-1.f90
trunk/libgomp/testsuite/libgomp.oacc-fortran/nested-function-2.f90
trunk/libgomp/testsuite/libgomp.oacc-fortran/nested-function-3.f90
Removed:
trunk/gcc/testsuite/gfortran.dg/goacc/subroutines.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/omp-low.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/combined-directives.c
trunk/gcc/testsuite/gfortran.dg/goacc/combined-directives.f90
trunk/gcc/testsuite/gfortran.dg/goacc/cray.f95
trunk/gcc/testsuite/gfortran.dg/goacc/loop-1.f95
trunk/gcc/testsuite/gfortran.dg/goacc/loop-3.f95
trunk/gcc/tree-nested.c
trunk/libgomp/ChangeLog

[Bug target/71460] Copying structs can trap (on x86-32) due to SNaN to QNaN

[rguenther at suse dot de]

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

--- Comment #24 from rguenther at suse dot de  ---
On Fri, 10 Jun 2016, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460
> 
> --- Comment #21 from Uroš Bizjak  ---
> (In reply to Uroš Bizjak from comment #19)
> > Following test doesn't compile with patched compiler:
> 
> BTW: This is preexisting problem, on 64bit target we can trigger the issue 
> with
> transparent unions with:
> 
> --cut here--
> union U { __int128 x; long double y; }  __attribute__ ((transparent_union));
> 
> void foo (union U);
> 
> void test (void)
> {
>   union U t;
> 
>   foo (1.0L);
> 
>   foo ( (__int128) 1);
> }
> --cut here--
> 
> -O2:
> 
> union.c:1:7: warning: union cannot be made transparent
>  union U { __int128 x; long double y; }  __attribute__ ((transparent_union));

But __int128 and long double are not passed the same way (rdi/rsi vs. on 
the stack).

[Bug middle-end/71492] New: Read from volatile pointer is removed

[stettberger at dokucode dot de]

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

Bug ID: 71492
   Summary: Read from volatile pointer is removed
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stettberger at dokucode dot de
  Target Milestone: ---

In the latest GCC (6.1) we observed a regression in our student operating
system. The following minimal working example reproduces the behavior:


int addr = 0x;

int checker() {
int c = *((volatile int *)addr);
int f = *((volatile int *)addr);
return f - c;
}


This compiles with -O1 -m32 -Wall -Wextra (without warnings) to:

checker():
movl$0, %eax
ret
addr:
.long   65535

Is such a cast undefined behavior?

Here the Compiler Explorer link:  https://godbolt.org/g/HBdxip

[Bug target/71493] New: [6/7 regression] accidental ABI change for structure return on PowerPC

[ebotcazou at gcc dot gnu.org]

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

Bug ID: 71493
   Summary: [6/7 regression] accidental ABI change for structure
return on PowerPC
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Keywords: ABI
  Severity: major
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ebotcazou at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-elf

Created attachment 38675
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38675&action=edit
Testcase

r225631 introduced an accidental ABI change for 32-bit SVR4 targets that don't
define DRAFT_V4_STRUCT_RET (in particular not Linux):

@@ -32144,7 +32168,7 @@ rs6000_function_value (const_tree valtyp
   if (DECIMAL_FLOAT_MODE_P (mode) && TARGET_HARD_FLOAT && TARGET_FPRS)
 /* _Decimal128 must use an even/odd register pair.  */
 regno = (mode == TDmode) ? FP_ARG_RETURN + 1 : FP_ARG_RETURN;
-  else if (SCALAR_FLOAT_TYPE_P (valtype) && TARGET_HARD_FLOAT && TARGET_FPRS
+  else if (SCALAR_FLOAT_MODE_NOT_VECTOR_P (mode) && TARGET_HARD_FLOAT &&
TARGET_FPRS
   && ((TARGET_SINGLE_FLOAT && (mode == SFmode)) ||
TARGET_DOUBLE_FLOAT))
 regno = FP_ARG_RETURN;
   else if (TREE_CODE (valtype) == COMPLEX_TYPE

Previously structures containing a single FP field were returned in r3/r4, now
they are returned in fp1 instead (unless -msoft-float).

[Bug tree-optimization/71490] [7 regression] gcc.dg/tree-ssa/slsr-8.c FAILs

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-10
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Already noticed at https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00563.html.
AFAICT it affects all the *86* platforms, see
https://gcc.gnu.org/ml/gcc-testresults/2016-06/msg01003.html.

[Bug c/71494] New: label as value in nested function

[mike.osipov at gmail dot com]

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

Bug ID: 71494
   Summary: label as value in nested function
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mike.osipov at gmail dot com
  Target Milestone: ---

Created attachment 38676
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38676&action=edit
sample source

"goto *label" leads to the internal compiler error when used in nested function

$ gcc main.c
main.c: In function ‘test’:
main.c:7:3: internal compiler error: in expand_expr_real_1, at expr.c:9651
   goto *label;
   ^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug middle-end/71492] Read from volatile pointer is removed

[stettberger at dokucode dot de]

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

--- Comment #1 from Christian Dietrich  ---
Bug in Compiler explorer the correct link is: https://godbolt.org/g/dqdVWR

[Bug target/71486] Transparent union doesn't work with long double for x86_64

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
I thought the ABI for transparent unions was that of passing its members.

But int128 and long double are passed differently.

[Bug middle-end/71494] [4.9/5/6/7 Regression] label as value in nested function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.3.6
   Keywords||ice-on-valid-code
   Last reconfirmed||2016-06-10
  Component|c   |middle-end
 Ever confirmed|0   |1
Summary|label as value in nested|[4.9/5/6/7 Regression]
   |function|label as value in nested
   ||function
   Target Milestone|--- |7.0
  Known to fail||4.4.7

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug target/71493] [6/7 regression] accidental ABI change for structure return on PowerPC

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |6.2
  Known to fail||6.1.0

[Bug target/71486] Transparent union doesn't work with long double for x86_64

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #1)
> I thought the ABI for transparent unions was that of passing its members.
> 
> But int128 and long double are passed differently.

Similar case compiles OK (value in int reg vs. value in XMM reg):

--cut here--
union U { long x; double y; } __attribute__ ((transparent_union));

void foo (union U);

void test (void)
{
  union U t;

  foo (1.0);
  foo (1L);
}
--cut here--

-O2:

movabsq $4607182418800017408, %rdi
callfoo
movl$1, %edi
callfoo

and even following for 32bit target, value in int reg vs. memory:

--cut here--
union U { int x; float y; } __attribute__ ((transparent_union));

void foo (union U);

void test (void)
{
  union U t;

  foo (1.0f);
  foo (1);
}
--cut here--

-O2 -m32 -mregparm=1:

movl$1065353216, %eax
callfoo
movl$1, %eax
callfoo

[Bug c/71381] C/C++ OpenACC cache directive rejects valid syntax

[tschwinge at gcc dot gnu.org]

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

--- Comment #3 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Jun 10 09:46:04 2016
New Revision: 237295

URL: https://gcc.gnu.org/viewcvs?rev=237295&root=gcc&view=rev
Log:
[PR c/71381] C/C++ OpenACC cache directive rejects valid syntax

Backport trunk r237290:

gcc/c/
PR c/71381
* c-parser.c (c_parser_omp_variable_list) :
Loosen checking.
gcc/cp/
PR c/71381
* parser.c (cp_parser_omp_var_list_no_open) :
Loosen checking.
gcc/fortran/
PR c/71381
* openmp.c (gfc_match_oacc_cache): Add comment.
gcc/testsuite/
PR c/71381
* c-c++-common/goacc/cache-1.c: Update.  Move invalid usage tests
to...
* c-c++-common/goacc/cache-2.c: ... this new file.
* gfortran.dg/goacc/cache-1.f95: Move invalid usage tests to...
* gfortran.dg/goacc/cache-2.f95: ... this new file.
* gfortran.dg/goacc/coarray.f95: Update OpenACC cache directive
usage.
* gfortran.dg/goacc/cray.f95: Likewise.
* gfortran.dg/goacc/loop-1.f95: Likewise.
libgomp/
PR c/71381
* testsuite/libgomp.oacc-c-c++-common/cache-1.c: #include
"../../../gcc/testsuite/c-c++-common/goacc/cache-1.c".
* testsuite/libgomp.oacc-fortran/cache-1.f95: New file.

gcc/
* omp-low.c (scan_sharing_clauses): Don't expect
OMP_CLAUSE__CACHE_.

Added:
branches/gcc-6-branch/gcc/testsuite/c-c++-common/goacc/cache-2.c
  - copied, changed from r237294,
branches/gcc-6-branch/gcc/testsuite/c-c++-common/goacc/cache-1.c
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/cache-2.f95
branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-fortran/cache-1.f95
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/c/ChangeLog
branches/gcc-6-branch/gcc/c/c-parser.c
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/parser.c
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/openmp.c
branches/gcc-6-branch/gcc/omp-low.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/c-c++-common/goacc/cache-1.c
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/cache-1.f95
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/coarray.f95
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/cray.f95
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/loop-1.f95
branches/gcc-6-branch/libgomp/ChangeLog
branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/cache-1.c

[Bug middle-end/71373] Handle more OMP_CLAUSE_* in nested function decomposition

[tschwinge at gcc dot gnu.org]

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

--- Comment #3 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Jun 10 09:46:18 2016
New Revision: 237296

URL: https://gcc.gnu.org/viewcvs?rev=237296&root=gcc&view=rev
Log:
[PR middle-end/71373] Handle more OMP_CLAUSE_* in nested function decomposition

Backport trunk r237291:

gcc/
* gimplify.c (gimplify_adjust_omp_clauses): Discard
OMP_CLAUSE_TILE.
* omp-low.c (scan_sharing_clauses): Don't expect OMP_CLAUSE_TILE.
gcc/testsuite/
* c-c++-common/goacc/combined-directives.c: XFAIL tree scanning
for OpenACC tile clauses.
* gfortran.dg/goacc/combined-directives.f90: Likewise.

gcc/
PR middle-end/71373
* tree-nested.c (convert_nonlocal_omp_clauses)
(convert_local_omp_clauses): Handle OMP_CLAUSE_ASYNC,
OMP_CLAUSE_WAIT, OMP_CLAUSE_INDEPENDENT, OMP_CLAUSE_AUTO,
OMP_CLAUSE__CACHE_, OMP_CLAUSE_TILE.
gcc/testsuite/
PR middle-end/71373
* gcc.dg/goacc/nested-function-1.c: New file.
* gcc.dg/goacc/nested-function-2.c: Likewise.
* gcc.dg/goacc/pr71373.c: Likewise.
* gfortran.dg/goacc/cray-2.f95: Likewise.
* gfortran.dg/goacc/loop-1-2.f95: Likewise.
* gfortran.dg/goacc/loop-3-2.f95: Likewise.
* gfortran.dg/goacc/cray.f95: Update.
* gfortran.dg/goacc/loop-1.f95: Likewise.
* gfortran.dg/goacc/loop-3.f95: Likewise.
* gfortran.dg/goacc/subroutines.f90: Update, and rename to...
* gfortran.dg/goacc/nested-function-1.f90: ... this new file.
libgomp/testsuite/
PR middle-end/71373
* libgomp.oacc-c/nested-function-1.c: New file.
* libgomp.oacc-c/nested-function-2.c: Likewise.
* libgomp.oacc-fortran/nested-function-1.f90: Likewise.
* libgomp.oacc-fortran/nested-function-2.f90: Likewise.
* libgomp.oacc-fortran/nested-function-3.f90: Likewise.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/goacc/nested-function-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/goacc/nested-function-2.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/goacc/pr71373.c
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/cray-2.f95
  - copied, changed from r237295,
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/cray.f95
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/loop-1-2.f95
  - copied, changed from r237295,
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/loop-1.f95
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/loop-3-2.f95
  - copied, changed from r237295,
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/loop-3.f95
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/nested-function-1.f90
branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-c/nested-function-1.c
branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-c/nested-function-2.c
   
branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-fortran/nested-function-1.f90
   
branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-fortran/nested-function-2.f90
   
branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-fortran/nested-function-3.f90
Removed:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/subroutines.f90
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/gimplify.c
branches/gcc-6-branch/gcc/omp-low.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
   
branches/gcc-6-branch/gcc/testsuite/c-c++-common/goacc/combined-directives.c
   
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/combined-directives.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/cray.f95
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/loop-1.f95
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/loop-3.f95
branches/gcc-6-branch/gcc/tree-nested.c
branches/gcc-6-branch/libgomp/ChangeLog

[Bug c++/71372] [6/7 Regression] C++ FE drops TREE_THIS_VOLATILE in cp_fold on all tcc_reference trees

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||stettberger at dokucode dot de

--- Comment #19 from Richard Biener  ---
*** Bug 71492 has been marked as a duplicate of this bug. ***

[Bug middle-end/71492] Read from volatile pointer is removed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Duplicate.

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

[Bug testsuite/71491] [7 Regression] gcc.dg/vect/slp-43.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-10
  Component|tree-optimization   |testsuite
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
Summary|gcc.dg/vect/slp-43.c FAILs  |[7 Regression]
   ||gcc.dg/vect/slp-43.c FAILs
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I will have a look at some point.

[Bug testsuite/71489] [7 regression] gcc.dg/tree-ssa/attr-hotcold-2.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target|i386-pc-solaris2.*, |i386-pc-solaris2.*,
   |sparc-sun-solaris2.*|sparc-sun-solaris2.*
   ||x86_64-linux
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-10
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed also on x86_64-linux.

[Bug c++/71472] Wlogical-op misses exhaustive-or case (... || A) || B

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
That is because we do this warning only when building each single || or && or |
or &.
And, we do this during parsing, where we don't know yet if the current
expression will appear in yet another identical operation or not.
If we extend the current warn_logical_operator so that for the range tests
it recurses over identical code suboperands, then either we'd have to limit the
walk to fixed number of operands we check and punt if you have say over 30 ||
expressions, or we'd risk exponential compile time.
Another possibility might be to remove this part of warn_logical_operator, and
perform it later, e.g. during c_fully_fold* and cp_fold, where we should have
the whole expressions already built and somehow signal to the recursive calls
that we want to handle it only on the outermost ||/&&/|/& (i.e. not perform it
if the parent code is the same as current code).
Then we could detect even e != ENUM_A || i != 42 || e != ENUM_B.  Of course
for ||/&& we'd need to pay attention to side-effects in between,
e != ENUM_A || foo (&e) || e != ENUM_B should not be warned about.
If we do that at that spot, we should basically try to virtually linearize the
trees combined with the same truth/logical binary operator, for all of them
perform the various checks warn_logical_operator does:
from_macro_expansion_at
TREE_NO_WARNING
CONSTANT_CLASS_P (fold_for_warn (...))
!(truth_value_p (TREE_CODE (...)) || INTEGRAL_TYPE_P (TREE_TYPE (...))
VECTOR_TYPE_P
make_range
build_range_check + integer_zerop (tem)
and stick the locations/make_range result/in*_p/low*/high* into a vector.
For operands with side-effects split the vector, then qsort each part without
side effects, so that we get records with the same make_range result next to
each other, and then perform the actual final checks and warnings.

[Bug target/71486] Transparent union doesn't work with long double for x86_64

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
Completely disabling TARGET_MEMBER_TYPE_FORCES_BLK, the testcase compiles OK:

-O2

movabsq $-9223372036854775808, %rdi
movl$16383, %esi
callfoo
movl$1, %edi
xorl%esi, %esi
callfoo

which suggests that the fix for PR20020 that introduced XFmode handling to
TARGET_MEMBER_TYPE_FORCES_BLK is wrong or at least incomplete...

... or there is an issue with BLKmode handling in the middle-end.

[Bug c/71381] C/C++ OpenACC cache directive rejects valid syntax

[tschwinge at gcc dot gnu.org]

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

--- Comment #4 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Jun 10 10:12:22 2016
New Revision: 237299

URL: https://gcc.gnu.org/viewcvs?rev=237299&root=gcc&view=rev
Log:
[PR c/71381] C/C++ OpenACC cache directive rejects valid syntax

libgomp/
PR c/71381
* testsuite/libgomp.oacc-fortran/cache-1.f90: Remove file.

Backport trunk r237290:

gcc/c/
PR c/71381
* c-parser.c (c_parser_omp_variable_list) :
Loosen checking.
gcc/cp/
PR c/71381
* parser.c (cp_parser_omp_var_list_no_open) :
Loosen checking.
gcc/fortran/
PR c/71381
* openmp.c (gfc_match_oacc_cache): Add comment.
gcc/testsuite/
PR c/71381
* c-c++-common/goacc/cache-1.c: Update.  Move invalid usage tests
to...
* c-c++-common/goacc/cache-2.c: ... this new file.
* gfortran.dg/goacc/cache-1.f95: Move invalid usage tests to...
* gfortran.dg/goacc/cache-2.f95: ... this new file.
* gfortran.dg/goacc/coarray.f95: Update OpenACC cache directive
usage.
* gfortran.dg/goacc/cray.f95: Likewise.
* gfortran.dg/goacc/loop-1.f95: Likewise.
libgomp/
PR c/71381
* testsuite/libgomp.oacc-c-c++-common/cache-1.c: #include
"../../../gcc/testsuite/c-c++-common/goacc/cache-1.c".
* testsuite/libgomp.oacc-fortran/cache-1.f95: New file.

gcc/
* omp-low.c (scan_sharing_clauses): Don't expect
OMP_CLAUSE__CACHE_.

Added:
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/cache-2.c
  - copied, changed from r237298,
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/cache-1.c
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/cache-2.f95
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-fortran/cache-1.f95
Removed:
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-fortran/cache-1.f90
Modified:
branches/gomp-4_0-branch/gcc/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/c/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/c/c-parser.c
branches/gomp-4_0-branch/gcc/cp/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/cp/parser.c
branches/gomp-4_0-branch/gcc/fortran/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/fortran/openmp.c
branches/gomp-4_0-branch/gcc/omp-low.c
branches/gomp-4_0-branch/gcc/testsuite/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/cache-1.c
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/cache-1.f95
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/coarray.f95
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/cray.f95
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/loop-1.f95
branches/gomp-4_0-branch/libgomp/ChangeLog.gomp
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/cache-1.c

[Bug middle-end/71373] Handle more OMP_CLAUSE_* in nested function decomposition

[tschwinge at gcc dot gnu.org]

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

--- Comment #4 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Jun 10 10:12:36 2016
New Revision: 237300

URL: https://gcc.gnu.org/viewcvs?rev=237300&root=gcc&view=rev
Log:
[PR middle-end/71373] Handle more OMP_CLAUSE_* in nested function decomposition

Backport trunk r237291:

gcc/
* gimplify.c (gimplify_adjust_omp_clauses): Discard
OMP_CLAUSE_TILE.
* omp-low.c (scan_sharing_clauses): Don't expect OMP_CLAUSE_TILE.
gcc/testsuite/
* c-c++-common/goacc/combined-directives.c: XFAIL tree scanning
for OpenACC tile clauses.
* gfortran.dg/goacc/combined-directives.f90: Likewise.

gcc/
PR middle-end/71373
* tree-nested.c (convert_nonlocal_omp_clauses)
(convert_local_omp_clauses): Handle OMP_CLAUSE_ASYNC,
OMP_CLAUSE_WAIT, OMP_CLAUSE_INDEPENDENT, OMP_CLAUSE_AUTO,
OMP_CLAUSE__CACHE_, OMP_CLAUSE_TILE.
gcc/testsuite/
PR middle-end/71373
* gcc.dg/goacc/nested-function-1.c: New file.
* gcc.dg/goacc/nested-function-2.c: Likewise.
* gcc.dg/goacc/pr71373.c: Likewise.
* gfortran.dg/goacc/cray-2.f95: Likewise.
* gfortran.dg/goacc/loop-1-2.f95: Likewise.
* gfortran.dg/goacc/loop-3-2.f95: Likewise.
* gfortran.dg/goacc/cray.f95: Update.
* gfortran.dg/goacc/loop-1.f95: Likewise.
* gfortran.dg/goacc/loop-3.f95: Likewise.
* gfortran.dg/goacc/subroutines.f90: Update, and rename to...
* gfortran.dg/goacc/nested-function-1.f90: ... this new file.
libgomp/testsuite/
PR middle-end/71373
* libgomp.oacc-c/nested-function-1.c: New file.
* libgomp.oacc-c/nested-function-2.c: Likewise.
* libgomp.oacc-fortran/nested-function-1.f90: Likewise.
* libgomp.oacc-fortran/nested-function-2.f90: Likewise.
* libgomp.oacc-fortran/nested-function-3.f90: Likewise.

Added:
branches/gomp-4_0-branch/gcc/testsuite/gcc.dg/goacc/nested-function-1.c
branches/gomp-4_0-branch/gcc/testsuite/gcc.dg/goacc/nested-function-2.c
branches/gomp-4_0-branch/gcc/testsuite/gcc.dg/goacc/pr71373.c
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/cray-2.f95
  - copied, changed from r237299,
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/cray.f95
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/loop-1-2.f95
  - copied, changed from r237299,
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/loop-1.f95
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/loop-3-2.f95
  - copied, changed from r237299,
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/loop-3.f95
   
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/nested-function-1.f90
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c/nested-function-1.c
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c/nested-function-2.c
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-fortran/nested-function-1.f90
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-fortran/nested-function-2.f90
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-fortran/nested-function-3.f90
Removed:
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/subroutines.f90
Modified:
branches/gomp-4_0-branch/gcc/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/gimplify.c
branches/gomp-4_0-branch/gcc/omp-low.c
branches/gomp-4_0-branch/gcc/testsuite/ChangeLog.gomp
   
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/combined-directives.c
   
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/combined-directives.f90
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/cray.f95
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/loop-1.f95
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/loop-3.f95
branches/gomp-4_0-branch/gcc/tree-nested.c
branches/gomp-4_0-branch/libgomp/ChangeLog.gomp

[Bug target/71475] [5/6/7 Regression] Optimization of copying into long double looses bytes

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7 Regression]|[5/6/7 Regression]
   |Optimization of copying |Optimization of copying
   |into long double looses |into long double looses
   |bytes   |bytes

--- Comment #4 from Jakub Jelinek  ---
Ah, actually if you don't just talk about the undefined bytes in the padding,
but those part of the XFmode value, this is something that regressed with
r213045.

[Bug target/71475] [5/6/7 Regression] Optimization of copying into long double looses bytes

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Jakub Jelinek  ---
So you're trying to construct Intel extended double with 0x4141414141414141LL
mantissa, 0 MSB of mantissa, exponent 0x4141 and sign bit of 0.
E.g. https://en.wikipedia.org/wiki/Extended_precision says on this:
Unnormal. Only generated on the 8087 and 80287. The 80387 and later treat this
as an invalid operand. 
I think you are just in the teritory of undefined behavior this, glibc probably
doesn't check carefully enough that the value you're passing to it the first
time is invalid, and in the second time, the compiler when it sees invalid
value as it transforms it into its internal representation and back, it
transforms it into something valid.

[Bug preprocessor/71183] [7 Regression] gcc -E always gives __DATE__ and __TIME__ as Jan 1 1970 00:00:00

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from Jakub Jelinek  ---
r237001 fixed this.

[Bug bootstrap/71013] [7 Regression] c-common.c:12810:37: error: 'LLONG_MAX' was not declared in this scope

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
LLONG_MAX is no longer used in the code.  Is this fixed now?

[Bug tree-optimization/71179] [7 Regression] ice fold_convert_loc, at fold-const.c:2360

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
So fixed?

[Bug c/69558] [6/7 Regression] glib2 warning pragmas stopped working

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
David, do we consider this fixed for real now with r233637, or is some further
work planed?

[Bug c++/71495] New: [6 Regression] Spurious "note: initializing argument ... of ..." without any warning/error

[yury.zaytsev at traveltainment dot de]

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

Bug ID: 71495
   Summary: [6 Regression] Spurious "note: initializing argument
... of ..." without any warning/error
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yury.zaytsev at traveltainment dot de
  Target Milestone: ---

Created attachment 38677
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38677&action=edit
Pre-processed class with GCC 5

Unfortunately, I couldn't easily reduce the samples any further, but, at least,
I'm able to provide a reliable reproducer.

$ g++-5 -v
gcc version 5.3.0 20151204 (Ubuntu 5.3.0-3ubuntu1~14.04) 

$ g++-6 -v
gcc version 6.1.1 20160511 (Ubuntu 6.1.1-3ubuntu11~14.04.1) 

$ g++-5 -c -std=c++14 cstring-g++-5.i 
$ g++-5 -c -std=c++14 cstring-g++-6.i 

$ g++-6 -c cstring-g++-5.i 
In file included from
lib/boost/install/include/boost/iterator/interoperable.hpp:13:0,
 from
lib/boost/install/include/boost/iterator/iterator_facade.hpp:12,
 from
lib/boost/install/include/boost/range/iterator_range_core.hpp:27,
 from
lib/boost/install/include/boost/range/iterator_range.hpp:13,
 from lib/boost/install/include/boost/range/as_literal.hpp:22,
 from
lib/boost/install/include/boost/algorithm/string/classification.hpp:17,
 from cpp/cstring.hh:12,
 from cpp/cstring.cc:8:
lib/boost/install/include/boost/type_traits/is_convertible.hpp: In substitution
of ‘template static decltype
((test_aux(declval()),
boost_1_60_0::detail::is_convertible_basic_impl::one()))
boost_1_60_0::detail::is_convertible_basic_impl::test(int)
[with From1 = tt::dbind::CString; To1 = tt::dbind::CString]’:
lib/boost/install/include/boost/type_traits/is_convertible.hpp:92:54:  
required from ‘const bool
boost_1_60_0::detail::is_convertible_basic_impl::value’
lib/boost/install/include/boost/type_traits/is_convertible.hpp:361:56:  
required from ‘const bool
boost_1_60_0::detail::is_convertible_impl::value’
lib/boost/install/include/boost/type_traits/is_convertible.hpp:477:8:  
required from ‘struct boost_1_60_0::is_convertible’
lib/boost/install/include/boost/mpl/aux_/nested_type_wknd.hpp:26:31:   required
from ‘struct
boost_1_60_0::mpl::aux::nested_type_wknd >’
lib/boost/install/include/boost_1_60_0/mpl/aux_/preprocessed/gcc/and.hpp:23:8: 
 required from ‘struct boost_1_60_0::mpl::aux::and_impl,
mpl_::bool_, mpl_::bool_, mpl_::bool_ >’
lib/boost/install/include/boost_1_60_0/mpl/aux_/preprocessed/gcc/and.hpp:48:8: 
 [ skipping 6 instantiation contexts, use -ftemplate-backtrace-limit=0 to
disable ]
lib/boost/install/include/boost/mpl/eval_if.hpp:38:31:   required from ‘struct
boost_1_60_0::mpl::eval_if,
boost_1_60_0::mpl::identity,
boost_1_60_0::iterators::detail::facade_iterator_category_impl >’
lib/boost/install/include/boost/iterator/detail/facade_iterator_category.hpp:180:8:
  required from ‘struct
boost_1_60_0::iterators::detail::facade_iterator_category’
lib/boost/install/include/boost/iterator/iterator_facade.hpp:117:17:   required
from ‘struct
boost_1_60_0::iterators::detail::iterator_facade_types’
lib/boost/install/include/boost/iterator/iterator_facade.hpp:641:11:   required
from ‘class
boost_1_60_0::iterators::detail::iterator_facade_base’
lib/boost/install/include/boost/iterator/iterator_facade.hpp:772:9:   required
from ‘class
boost_1_60_0::iterators::iterator_facade’
cpp/cstring.hh:40:23:   required from here
lib/boost/install/include/boost/type_traits/is_convertible.hpp:83:19: note:  
initializing argument 1 of ‘static void
boost_1_60_0::detail::is_convertible_basic_impl::test_aux(To1)
[with To1 = tt::dbind::CString; From = tt::dbind::CString; To =
tt::dbind::CString]’

$ g++-6 -c cstring-g++-6.i 
In file included from
lib/boost/install/include/boost/iterator/interoperable.hpp:13:0,
 from
lib/boost/install/include/boost/iterator/iterator_facade.hpp:12,
 from
lib/boost/install/include/boost/range/iterator_range_core.hpp:27,
 from
lib/boost/install/include/boost/range/iterator_range.hpp:13,
 from lib/boost/install/include/boost/range/as_literal.hpp:22,
 from
lib/boost/install/include/boost/algorithm/string/classification.hpp:17,
 from cpp/cstring.hh:12,
 from cpp/cstring.cc:8:
lib/boost/install/include/boost/type_traits/is_convertible.hpp: In substitution
of ‘template static decltype
((test_aux(declval()),
boost_1_60_0::detail::is_convertible_basic_impl::one()))
boost_1_60_0::detail::is_convertible_basic_impl::test(int)
[with From1 = tt::dbind::CString; To1 = tt::dbind::CString]’:
lib/boost/install/include/boost/type_traits/is_convertible.hpp:92:54:  
required from ‘const bool
boost_1_60_0::detail::is_convertible_basi

[Bug c++/71495] [6 Regression] Spurious "note: initializing argument ... of ..." without any warning/error

[yury.zaytsev at traveltainment dot de]

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

--- Comment #1 from Yury V. Zaytsev  ---
Created attachment 38678
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38678&action=edit
Pre-processed class with GCC 6

[Bug rtl-optimization/71496] New: Two picbase loads created for libjava code on powerpc-darwin after rev 22022.

[iains at gcc dot gnu.org]

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

Bug ID: 71496
   Summary: Two picbase loads created for libjava code on
powerpc-darwin after rev 22022.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

Created attachment 38679
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38679&action=edit
cut-down .java, .class, .s and rtl files for StringBuffer.java

After 22022 for O2 and O3 (m32 and m64) with PIC code, two picbase loads are
created on powerpc-darwin.  This prevents bootstrap with Java.

The attached files include a cut-down version of StringBuffer.java and the
.class file.

$ /GCC/gcc-trunk-apple/gcc/gcj StringBuffer.class --encoding=UTF-8
-Wno-deprecated -fbootstrap-classes
-B/GCC/gcc-trunk-apple/powerpc-apple-darwin9/ppc64/libjava/
-B/GCC/gcc-trunk-apple/powerpc-apple-darwin9/ppc64/libjava/
-B/GCC/gcc-trunk-apple/./gcc/
-B/compilers/gcc-trunk-ni/powerpc-apple-darwin9/bin/
-B/compilers/gcc-trunk-ni/powerpc-apple-darwin9/lib/ -isystem
/compilers/gcc-trunk-ni/powerpc-apple-darwin9/include -isystem
/compilers/gcc-trunk-ni/powerpc-apple-darwin9/sys-include -fclasspath=
-fbootclasspath=/GCC/gcc-trunk/libjava/classpath/lib -c -g -O2 -m64 -save-temps
-dapA
StringBuffer.s:784:FATAL:Symbol L2$pb already defined

$ ../../../gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=../../../gcc/xgcc
Target: powerpc-apple-darwin9
Configured with: /GCC/gcc-trunk/configure --prefix=/compilers/gcc-trunk-ni
--target=powerpc-apple-darwin9 --host=powerpc-apple-darwin9
--build=powerpc-apple-darwin9 --enable-checking=yes --disable-nls
--with-cctools-as --with-as=/usr/local/bootstrap/bin/as --with-ld64
--with-ld=/usr/local/bootstrap/bin/ld --with-pkgversion='iains trunk test'
--enable-version-specific-runtime-libs
--with-sysroot=/usr/local/bootstrap/SDKs/darwin9
--with-gmp=/usr/local/tools/gcc-2016 --enable-languages=c,c++,java
--disable-libstdcxx-pch

[Bug c++/68581] ICE in build_conditional_expr_1 upon instantiation of a templated function with Cilk+ directives (valid code)

[yury.zaytsev at traveltainment dot de]

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

Yury V. Zaytsev  changed:

   What|Removed |Added

Version|5.2.1   |6.1.1

--- Comment #1 from Yury V. Zaytsev  ---
$ g++-6 -v
gcc version 6.1.1 20160511 (Ubuntu 6.1.1-3ubuntu11~14.04.1) 

$ g++-6 -std=c++11 -fcilkplus ice.cpp
ice.cpp: In instantiation of ‘void parallel() [with  =
x]’:
ice.cpp:13:17:   required from here
ice.cpp:8:10: internal compiler error: Segmentation fault
 true ? lambda() : cilk_spawn lambda();
 ~^~~~
0xaa43bf crash_signal
../../src/gcc/toplev.c:333
0x5b58c2 build_conditional_expr_1
../../src/gcc/cp/call.c:4791
0x5b683c build_conditional_expr(unsigned int, tree_node*, tree_node*,
tree_node*, int)
../../src/gcc/cp/call.c:5197
0x65c3b0 build_x_conditional_expr(unsigned int, tree_node*, tree_node*,
tree_node*, int)
../../src/gcc/cp/typeck.c:6272
0x5e6eb1 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:1
0x5e1d18 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:15801
0x5e18be tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:15117
0x5e1494 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:15103
0x5e1bb3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:15289
0x5e03af instantiate_decl(tree_node*, int, bool)
../../src/gcc/cp/pt.c:22013
0x5fcc0b instantiate_pending_templates(int)
../../src/gcc/cp/pt.c:22130
0x61af7d c_parse_final_cleanups()
../../src/gcc/cp/decl2.c:4599
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/71496] Two picbase loads created for libjava code on powerpc-darwin after rev 22022.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
 Target||powerpc-darwin

--- Comment #1 from Richard Biener  ---
bogus rev?

[Bug driver/69028] ICE on *any* valid Cilk+ code C/C++: -fcilkplus is incompatible with -fprofile-arcs

[yury.zaytsev at traveltainment dot de]

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

Yury V. Zaytsev  changed:

   What|Removed |Added

Version|5.3.0   |6.1.1

--- Comment #2 from Yury V. Zaytsev  ---
$ g++-6 -v
gcc version 6.1.1 20160511 (Ubuntu 6.1.1-3ubuntu11~14.04.1)

$ g++-6 -fcilkplus ice.cpp 

$ g++-6 -fcilkplus -fprofile-arcs ice.cpp 
ice.cpp:9:1: internal compiler error: Segmentation fault
 }
 ^
0xaa43bf crash_signal
../../src/gcc/toplev.c:333
0x79f770 coverage_checksum_string
../../src/gcc/coverage.c:500
0x7a0956 coverage_compute_profile_id(cgraph_node*)
../../src/gcc/coverage.c:583
0xca9f3e init_node_map(bool)
../../src/gcc/value-prof.c:1240
0xb3c3ee tree_profiling
../../src/gcc/tree-profile.c:516
0xb3c3ee execute
../../src/gcc/tree-profile.c:642
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/71495] [6/7 Regression] Spurious "note: initializing argument ... of ..." without any warning/error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |6.2
Summary|[6 Regression] Spurious |[6/7 Regression] Spurious
   |"note: initializing |"note: initializing
   |argument ... of ..."|argument ... of ..."
   |without any warning/error   |without any warning/error

[Bug rtl-optimization/71496] Two picbase loads created for libjava code on powerpc-darwin after rev 22022.

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-10
 CC||dominiq at lps dot ens.fr,
   ||segher at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Iain Sandoe  ---
added CCs
indeed typoed the rev it's 228022.

[Bug c++/70824] [6/7 Regression] cc1plus consumes all available memory on specific template code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.2

[Bug c++/71092] [6/7 Regression] ICE: in cxx_eval_call_expression, at cp/constexpr.c:1449; only with -Os

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.2

[Bug fortran/70959] [6/7 Regression] Invalid type determination due to expression in a type declaration statement

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.2

[Bug c++/70977] [6/7 Regression] Out of memory during compilation of facebook/wangle (flag c++0x works, flag c++14 fails).

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.2

[Bug target/71342] [6/7 Regression][RL78] set1 / clr1 with !addr16 sometimes doesn't work

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.2

[Bug libstdc++/70845] [6/7 Regression] inherited piecewise_construct_t constructor from std::pair by "using-declarations" is missing

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.2

[Bug fortran/70748] [6/7 Regression] ICE with debug in gfc_trans_block_construct

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.2

[Bug c++/70942] [6/7 Regression] [c++14] Incorrect deduction of generic lambda `auto&&` parameter

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.2

[Bug c++/71227] [6/7 Regression] template friend function cannot be resolved

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.2

[Bug lto/66295] [5/6/7 Regression] LTO generates incorrect resolver call for function multiversioning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.5

[Bug c++/71121] [6/7 Regression] Spurious warning: "the address of [...] will never be NULL [-Waddress]"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.2

[Bug fortran/70673] [5/6/7 Regression] ICE with module containing functions with allocatable character scalars

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.5

[Bug target/71216] [4.9/5/6/7 Regression] Incorrect PPC assembly due to inserted .machine pseudo-op

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4
Summary|[4.8/4.9/5/6/7 Regression]  |[4.9/5/6/7 Regression]
   |Incorrect PPC assembly due  |Incorrect PPC assembly due
   |to inserted .machine|to inserted .machine
   |pseudo-op   |pseudo-op

[Bug middle-end/71494] [4.9/5/6/7 Regression] label as value in nested function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 38680
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38680&action=edit
gcc7-pr71494.patch

Your testcase is IMNSHO invalid, you can't combine non-local goto with computed
goto together, there is either computed goto, which can branch only to labels
in the same function, or non-local goto, which needs to have a non-local label
as goto operand, not *expression.  But, I've changed it into a valid testcase.
And with the fix even the invalid testcase doesn't ICE anymore.

[Bug fortran/70842] [4.9/5/6/7 Regression] internal compiler error with character members within a polymorphic pointer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

[Bug bootstrap/71013] [7 Regression] c-common.c:12810:37: error: 'LLONG_MAX' was not declared in this scope

[dave.anglin at bell dot net]

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

--- Comment #8 from dave.anglin at bell dot net ---
On 2016-06-10, at 6:44 AM, jakub at gcc dot gnu.org wrote:

> LLONG_MAX is no longer used in the code.  Is this fixed now?

It probably is but I haven't tested.  I had updated patch to use int64_t when
LLONG_MAX 
was removed.

Dave
--
John David Anglin   dave.ang...@bell.net

[Bug bootstrap/71013] [7 Regression] c-common.c:12810:37: error: 'LLONG_MAX' was not declared in this scope

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Assuming fixed then.  Feel free to reopen if it is not.

[Bug tree-optimization/71408] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
So fixed?

[Bug target/64516] [4.9/5/6/7 Regression] arm: wrong unaligned load generated

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |4.9.4
Summary|[4.x Regression] arm: wrong |[4.9/5/6/7 Regression] arm:
   |unaligned load generated|wrong unaligned load
   ||generated

--- Comment #4 from Richard Biener  ---
get16_unaligned should work.  Confirmed on trunk.

(insn 6 5 7 (set (reg:SI 114)
(zero_extend:SI (mem:HI (reg/v/f:SI 111 [ p ]) [1 MEM[(const struct TU2
*)p_2(D)]+0 S2 A16]))) t.c:7 -1
 (nil))

This is because the MEM_REF has a wrong type/alignment on it.  Ah, and it's
one folding I know is wrong for a long time ... :/

case VIEW_CONVERT_EXPR:
  if (TREE_CODE (op0) == MEM_REF)
{
  tem = fold_build2_loc (loc, MEM_REF, type,
 TREE_OPERAND (op0, 0), TREE_OPERAND (op0, 1));
  REF_REVERSE_STORAGE_ORDER (tem) = REF_REVERSE_STORAGE_ORDER (op0);
  return tem;
}

this drops alignment info.

Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 237286)
+++ gcc/fold-const.c(working copy)
@@ -7964,6 +7974,8 @@ fold_unary_loc (location_t loc, enum tre
 case VIEW_CONVERT_EXPR:
   if (TREE_CODE (op0) == MEM_REF)
 {
+ if (TYPE_ALIGN (TREE_TYPE (op0)) != TYPE_ALIGN (type))
+   type = build_aligned_type (type, TYPE_ALIGN (TREE_TYPE (op0)));
  tem = fold_build2_loc (loc, MEM_REF, type,
 TREE_OPERAND (op0, 0), TREE_OPERAND (op0, 1));
  REF_REVERSE_STORAGE_ORDER (tem) = REF_REVERSE_STORAGE_ORDER (op0);

then generates

get16_unaligned:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldrbr3, [r0]@ zero_extendqisi2
ldrbr0, [r0, #1]@ zero_extendqisi2
orr r0, r3, r0, lsl #8
mov pc, lr

[Bug inline-asm/68843] ICE with "u" input constraint

[edlinger at gcc dot gnu.org]

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

--- Comment #9 from Bernd Edlinger  ---
Author: edlinger
Date: Fri Jun 10 12:22:21 2016
New Revision: 237303

URL: https://gcc.gnu.org/viewcvs?rev=237303&root=gcc&view=rev
Log:
gcc:
2016-06-10  Bernd Edlinger  

PR inline-asm/68843
* reg-stack.c (check_asm_stack_operands): Explicit input arguments
must be grouped on top of stack.  Don't force early clobber
on ordinary reg outputs.

testsuite:
2016-06-10  Bernd Edlinger  

PR inline-asm/68843
* gcc.target/i386/pr68843-1.c: New test.
* gcc.target/i386/pr68843-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr68843-1.c
trunk/gcc/testsuite/gcc.target/i386/pr68843-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/reg-stack.c
trunk/gcc/testsuite/ChangeLog

[Bug inline-asm/68843] ICE with "u" input constraint

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

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

--- Comment #10 from Bernd Edlinger  ---
fixed on trunk.

[Bug tree-optimization/71323] [7 Regression] ice in verify_ssa failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Jakub Jelinek  ---
Fixed with r236877.

[Bug tree-optimization/71252] [7 Regression] ICE: verify_ssa failed : definition in block 7 does not dominate use in block 6

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #23 from Jakub Jelinek  ---
Is this fixed now?

[Bug tree-optimization/71170] [7 Regression] ICE in rewrite_expr_tree, at tree-ssa-reassoc.c:3898

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek  ---
Is it still broken?

[Bug tree-optimization/64716] Missed vectorization in a hot code of SPEC2000 ammp

[vekumar at gcc dot gnu.org]

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

vekumar at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vekumar at gcc dot gnu.org

--- Comment #4 from vekumar at gcc dot gnu.org ---
Tried to see if there is improvement when allowing splitting the group stores
based at VF boundary.

Small improvement noted with slightly older trunk 
gcc version 7.0.0 20160524 (experimental) (GCC)

rectmm.c:520:2: note: Basic block will be vectorized using SLP


(Snip)
a1-> px = a1->x + lambda*a1->dx;
a1-> py = a1->y + lambda*a1->dy;
a1-> pz = a1->z + lambda*a1->dz;
(Snip)

---SLP dump---
rectmm.c:520:2: note: Detected interleaving load a1_944->xD.4701 and
a1_944->yD.4702
rectmm.c:520:2: note: Detected interleaving load a1_944->xD.4701 and
a1_944->zD.4703
rectmm.c:520:2: note: Detected interleaving load a1_944->xD.4701 and
a1_944->dxD.4721
rectmm.c:520:2: note: Detected interleaving load a1_944->xD.4701 and
a1_944->dyD.4722
rectmm.c:520:2: note: Detected interleaving load a1_944->xD.4701 and
a1_944->dzD.4723
rectmm.c:520:2: note: Detected interleaving store a1_944->pxD.4728 and
a1_944->pyD.4729
rectmm.c:520:2: note: Detected interleaving store a1_944->pxD.4728 and
a1_944->pzD.4730

rectmm.c:520:2: note: Split group into 2 and 1

rectmm.c:520:2: note: Basic block will be vectorized using SLP
rectmm.c:520:2: note: SLPing BB part
rectmm.c:520:2: note: -->vectorizing SLP node starting from: # VUSE
<.MEM_1752>
_672 = a1_944->dxD.4721;
---SLP dump---