[Bug sanitizer/80875] [7/8 Regression] UBSAN: compile time crash in fold_binary_loc at fold-const.c:9817

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||rguenth at gcc dot gnu.org

[Bug sanitizer/80875] [7/8 Regression] UBSAN: compile time crash in fold_binary_loc at fold-const.c:9817

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
9810  && negate_expr_p (op0)
9811  && (tem = negate_expr (op1)) != op1

should probaby use negate_expr_p (op1) to guard this.

[Bug tree-optimization/80876] [8 Regression] ICE in verify_loop_structure, at cfgloop.c:1644 (error: loop 1's latch does not have an edge to its header)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |8.0

--- Comment #2 from Richard Biener  ---
I will have a look at this latent issue.  Another expand issue btw.

[Bug target/80880] internal compiler error: in ix86_expand_builtin

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
(gdb) p debug_generic_expr (exp)
__builtin_ia32_bndret (0B)

And sinking does:

Sinking __bound_tmp.0_3 = __builtin_ia32_bndret (_2);
 from bb 2 to bb 3

int* fn1.chkp() ()
{
  __bounds_type __bound_tmp.0;
  int * _2;

   [100.00%]:
  _2 = fn1.chkp ();
  if (_2 == 0B)
goto ; [33.47%]
  else
goto ; [66.53%]

   [33.47%]:
  __bound_tmp.0_3 = __builtin_ia32_bndret (_2);
  return 0B, __bound_tmp.0_3;

   [66.53%]:
  return;

nothing wrong with that.  Now we can do the conditional replacement of _2
with 0.

Thus expansion issue.  We absolutely need to deal with constant pointers here,
even if just in a conservative way.  chkp_get_rtl_bounds suggests that
returning NULL_RTX is ok thus

@@ -37584,8 +37601,10 @@ ix86_expand_builtin (tree exp, rtx targe

 case IX86_BUILTIN_BNDRET:
   arg0 = CALL_EXPR_ARG (exp, 0);
-  gcc_assert (TREE_CODE (arg0) == SSA_NAME);
-  target = chkp_get_rtl_bounds (arg0);
+  if (TREE_CODE (arg0) == SSA_NAME)
+   target = chkp_get_rtl_bounds (arg0);
+  else
+   target = NULL;

   /* If no bounds were specified for returned value,
 then use INIT bounds.  It usually happens when

or simply adjust chkp_get_rtl_bounds as there seems to be a single caller only.

[Bug libgomp/80881] [7 Regression] null pointer access in libgomp.h

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.2
Summary|[7.1 Regression] null   |[7 Regression] null pointer
   |pointer access in libgomp.h |access in libgomp.h

[Bug ipa/80882] [8 regression] test case gfortran.dg/pr48636.f90 fails starting with r248375

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug tree-optimization/80884] [8 regression] test case gcc.target/powerpc/20050830-1.c fails starting with r247886

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug tree-optimization/80844] OpenMP SIMD doesn't know how to efficiently zero a vector (its stores zeros and reloads)

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Fri May 26 07:14:52 2017
New Revision: 248481

URL: https://gcc.gnu.org/viewcvs?rev=248481&root=gcc&view=rev
Log:
2017-05-26  Richard Biener  

PR tree-optimization/80844
* tree-vectorizer.c (adjust_simduid_builtins): Propagate
results.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vectorizer.c

[Bug c++/80859] Performance Problems with OpenMP 4.5 support

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED

--- Comment #23 from Jakub Jelinek  ---
So, the time difference with OMP_NUM_THREADS=1, which means this isn't about
code generation (or at least not something that is significant).
What matters is that there is a parallel inside of the target region and the
target region is invoked many times, and while libgomp uses a thread pool to
cache a set of threads from one (non-nested) host parallel region to another
one (this is effectively required by the OpenMP spec, as threadprivate vars
should survive between parallel regions if the number of threads doesn't
change), target fallback creates a different contention group, so the threads
created there are unrelated to the other host threads, don't have guarantees on
locking with the real host threads etc.
The performance problem on your testcase as well as e.g.
int
main (int argc, const char **argv)
{
  int i, j;
  int a[16] = {};
  if (argc > 1)
for (i = 0; i < 128; i++)
  {
  #pragma omp target teams distribute parallel for simd
for (j = 0; j < 16; j++)
  a[j]++;
  }
  else
for (i = 0; i < 128; i++)
  {
  #pragma omp parallel for simd
for (j = 0; j < 16; j++)
  a[j]++;
  }
  return 0;
}

is the lack of caching of threads (i.e. preserving a thread pool) across
different target host fallback regions, at the end of each target host fallback
the thread pool created for it when encountering parallel construct in it is
destroyed, which means the POSIX threads are let terminate, and the next time
parallel construct in another target host fallback region is encountered,
pthread_create is called again.
I'll try to implement caching of one? thread pool between target host fallback
regions (there can be more of them concurrently, so just probably atomically
exchange with a thread pool sitting in some static variable).  Might take a few
days to implement properly though.

Back to your code,
//determine number of threads and teams
#pragma omp parallel
{
nthreads = omp_get_num_threads();
}
#pragma omp target teams num_teams(NUM_TEAMS)
{
nteams = omp_get_num_teams();
}
#endif
is wrong not just for the reasons I said earlier (missing map(from:nteams)
clause on target teams and (pedantically) data races, but also that it grabs
completely unrelated number of threads (how many host threads would be created)
and uses that to request that many threads in the target region.  Plus
completely unnecessarily spawns all the host threads that will not be used then
at all (but the runtime can't know that and can't reuse them for anything else,
because if you do another #pragma omp parallel on the host, it would need to be
the same threads).  Consider that the host is say a 1s/8c/16t CPU and
accelerator is PTX, with 16 teams, 32 threads, and warp size 32 (i.e. 32 "SIMD"
lanes).  The above if fixed will tell you to request 16 teams, but limit
threads to 16 because that is what the host has, while you could use 32 threads
per team.  And you are not using parallel for simd but just parallel for, so it
wouldn't efficiently use all the accelerator HW, but just 1/32th of it (because
of the thread limitation actually 1/64th).
So, if you really want to query the number of teams and threads upfront (still
don't understand why, if you don't split the distribute vs. parallel for the
way you do and just do target teams distribute parallel for simd as one
construct then it is up to the implementation to split the work in between
"SIMD" lanes (on PTX SIMT threads in a warp), threads and teams and you don't
have to prescribe anything), you should use
#pragma omp target teams map(from:nteams, nthreads)
  {
#pragma omp parallel
#pragma omp master
if (omp_get_team_num () == 0)
  {
nteams = omp_get_num_teams ();
nthreads = omp_get_thread_num ();
  }
  }
or so, that way you query how many threads are there by default inside of the
teams construct.

[Bug tree-optimization/80842] [7/8 Regression] ICE at -O3 on x86_64-linux-gnu in "set_lattice_value"

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Fri May 26 07:19:00 2017
New Revision: 248482

URL: https://gcc.gnu.org/viewcvs?rev=248482&root=gcc&view=rev
Log:
2017-05-26  Richard Biener  

PR tree-optimization/80842
* tree-ssa-ccp.c (set_lattice_value): Always meet with the old
value.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr80842.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c

[Bug tree-optimization/80844] OpenMP SIMD doesn't know how to efficiently zero a vector (its stores zeros and reloads)

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Maybe we can simply set loop->force_vectorize on the prologue / epilogue loops.
Hmm, seems to be generated before we have a CFG ...

[Bug sanitizer/80875] [7/8 Regression] UBSAN: compile time crash in fold_binary_loc at fold-const.c:9817

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
(In reply to Richard Biener from comment #4)
> 9810  && negate_expr_p (op0)
> 9811  && (tem = negate_expr (op1)) != op1
> 
> should probaby use negate_expr_p (op1) to guard this.

Yea, I sent a patch doing exactly that yesterday:
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01971.html

[Bug c++/80857] slow compare_exchange_weak with unintegral type

[sv_91 at inbox dot ru]

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

--- Comment #1 from sv_91 at inbox dot ru ---
A simpler example for demonstrates the problem

struct MyStruct {
int64_t value;
};

inline MyStruct operator+(const MyStruct &first, const MyStruct &second) {
return MyStruct{first.value + second.value};
}

template
inline void atomic_fetch_add(std::atomic &obj, const T& arg) noexcept {
T current = obj;
while (!obj.compare_exchange_weak(current, current + arg));
}

void func1(int n) {
const time_point beginTime(::now());
std::atomic a1(0);
for (int i = 0; i < n; i++) {
atomic_fetch_add(a1, (int64_t)i);
}
const time_point endTime(::now());
std::cout << "Result " << a1.load() << ". Time " <<
std::chrono::duration_cast(endTime - beginTime).count() <<
std::endl;
}

void func3(int n) {
std::cout << std::is_pod::value << std::endl;
const time_point beginTime(::now());
std::atomic a1(MyStruct{0});
for (int i = 0; i < n; i++) {
atomic_fetch_add(a1, MyStruct{i});
}
const time_point endTime(::now());
std::cout << "Result " << a1.load().value << ". Time " <<
std::chrono::duration_cast(endTime - beginTime).count() <<
std::endl;
}

Output:

Result 499500. Time 101
1
Result 499500. Time 158

[Bug target/80885] New: Do not use the opaque _mm256_cmp_ps to produce -1

[glisse at gcc dot gnu.org]

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

Bug ID: 80885
   Summary: Do not use the opaque _mm256_cmp_ps to produce -1
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*

Hello,

in avx2intrin.h, I see a lot of

  __v8sf __src = _mm256_setzero_ps ();
  __v8sf __mask = _mm256_cmp_ps (__src, __src, _CMP_EQ_OQ);

(and variants with double)
Where gcc knows nothing about _mm256_cmp_ps and blindly generates the insn. It
seems to me that it would be better to use some way to let gcc know the
constant (for instance generate it as __v8si then cast), even if in the end it
might decide to generate the constant this way.

Macros (for the -O0 case) have the rather suspicious
 (__v4df)_mm256_set1_pd((double)(long long int) -1)

[Bug target/80846] auto-vectorized AVX2 horizontal sum should narrow to 128b right away, to be more efficient for Ryzen and Intel

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
Hmm, for some reason we end up spilling:

.L2:
vmovdqa -48(%rbp), %ymm3
addq$32, %rdi
vpaddd  -32(%rdi), %ymm3, %ymm2
cmpq%rdi, %rax
vmovdqa %ymm2, -48(%rbp)
jne .L2
vmovdqa -32(%rbp), %xmm5
vpaddd  -48(%rbp), %xmm5, %xmm0
vpsrldq $8, %xmm0, %xmm1
vpaddd  %xmm1, %xmm0, %xmm0
vpsrldq $4, %xmm0, %xmm1
vpaddd  %xmm1, %xmm0, %xmm0
vmovd   %xmm0, %eax

when expanding the epilogue

  _6 = BIT_FIELD_REF ;
  _5 = BIT_FIELD_REF ;
  _29 = _5 + _6;
  vect_sum_11.8_22 = VEC_PERM_EXPR <_29, { 0, 0, 0, 0 }, { 2, 3, 4, 5 }>;
  vect_sum_11.8_21 = vect_sum_11.8_22 + _29;
  vect_sum_11.8_20 = VEC_PERM_EXPR ;
  vect_sum_11.8_19 = vect_sum_11.8_20 + vect_sum_11.8_21;
  stmp_sum_11.7_18 = BIT_FIELD_REF ;
  return stmp_sum_11.7_18;

as

;; _29 = _5 + _6;

(insn 17 16 18 (set (reg:OI 101)
(subreg:OI (reg:V8SI 90 [ vect_sum_11.6 ]) 0)) -1
 (nil))

(insn 18 17 19 (set (reg:OI 102)
(subreg:OI (reg:V8SI 90 [ vect_sum_11.6 ]) 0)) -1
 (nil))

(insn 19 18 0 (set (reg:V4SI 98 [ _29 ])
(plus:V4SI (subreg:V4SI (reg:OI 101) 16)
(subreg:V4SI (reg:OI 102) 0))) -1
 (nil))

before RA:

(insn 19 16 20 4 (set (reg:V4SI 98 [ _29 ])
(plus:V4SI (subreg:V4SI (reg:V8SI 90 [ vect_sum_11.6 ]) 16)
(subreg:V4SI (reg:V8SI 90 [ vect_sum_11.6 ]) 0))) 2990 {*addv4si3}
 (expr_list:REG_DEAD (reg:V8SI 90 [ vect_sum_11.6 ])
(nil)))

so the issue is likely that we do not expose the splitting in separate
instructions but we assume LRA can deal with reloading the above w/o stack?

 Choosing alt 1 in insn 19:  (0) v  (1) v  (2) vm {*addv4si3}
alt=0: Bad operand -- refuse
alt=1: Bad operand -- refuse
  alt=2,overall=0,losers=0,rld_nregs=0

not sure if it would help not to combine the subregs into the plus in the
first place or some reload hook could help here?

With the above issue the patch I have is likely not going to help ;)

[Bug target/80846] auto-vectorized AVX2 horizontal sum should narrow to 128b right away, to be more efficient for Ryzen and Intel

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(define_expand "3"
  [(set (match_operand:VI_AVX2 0 "register_operand")
(plusminus:VI_AVX2
  (match_operand:VI_AVX2 1 "vector_operand")
  (match_operand:VI_AVX2 2 "vector_operand")))]
  "TARGET_SSE2"
  "ix86_fixup_binary_operands_no_copy (, mode, operands);")

so maybe things can be fixed up in ix86_fixup_binary_operands which doesn't
seem to consider subregs in any way.

Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c  (revision 248482)
+++ gcc/config/i386/i386.c  (working copy)
@@ -21270,6 +21270,11 @@ ix86_fixup_binary_operands (enum rtx_cod
   if (MEM_P (src1) && !rtx_equal_p (dst, src1))
 src1 = force_reg (mode, src1);

+  if (SUBREG_P (src1) && SUBREG_BYTE (src1) != 0)
+src1 = force_reg (mode, src1);
+  if (SUBREG_P (src2) && SUBREG_BYTE (src2) != 0)
+src1 = force_reg (mode, src2);
+
   /* Improve address combine.  */
   if (code == PLUS
   && GET_MODE_CLASS (mode) == MODE_INT

doesn't help though.  pre-LRA:

(insn 19 16 20 4 (set (reg:V4SI 103)
(subreg:V4SI (reg:V8SI 90 [ vect_sum_11.6 ]) 16)) 1222
{movv4si_internal}
 (nil))
(insn 20 19 21 4 (set (reg:V4SI 98 [ _29 ])
(plus:V4SI (reg:V4SI 103)
(subreg:V4SI (reg:V8SI 90 [ vect_sum_11.6 ]) 0))) 2990 {*addv4si3}
 (expr_list:REG_DEAD (reg:V4SI 103)
(expr_list:REG_DEAD (reg:V8SI 90 [ vect_sum_11.6 ])
(nil

of course LRA not splitting life ranges when spilling (and thus forcing
to spill inside the loop) doesn't help either.  But we really don't want
to spill...

 Choosing alt 2 in insn 19:  (0) v  (1) vm {movv4si_internal}
2 Non pseudo reload: reject++
  alt=1,overall=1,losers=0,rld_nregs=0
 Choosing alt 1 in insn 20:  (0) v  (1) v  (2) vm {*addv4si3}
  alt=1,overall=0,losers=0,rld_nregs=0

 Choosing alt 2 in insn 19:  (0) v  (1) vm {movv4si_internal}
0 Non-pseudo reload: reject+=2
0 Non input pseudo reload: reject++
alt=0: Bad operand -- refuse
0 Non-pseudo reload: reject+=2
0 Non input pseudo reload: reject++
alt=1: Bad operand -- refuse
0 Non-pseudo reload: reject+=2
0 Non input pseudo reload: reject++
Cycle danger: overall += LRA_MAX_REJECT

 Choosing alt 1 in insn 20:  (0) v  (1) v  (2) vm {*addv4si3}
alt=0: Bad operand -- refuse
alt=1: Bad operand -- refuse
  alt=2,overall=0,losers=0,rld_nregs=0

so we don't seem to handle insn 19 well (why's that movv4si_internal rather
than some pextr?)

[Bug libgomp/80822] libgomp incorrect affinity when OMP_PLACES=threads

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to Nathan Weeks from comment #6)
> Created attachment 41417 [details]
> output from comment #4 code compiled with Intel 17.0.2

Could I ask you for output of additional:
for i in `seq 64`; do echo OMP_PLACES='threads('$i')' ./80822-4.intel;
OMP_PLACES='threads('$i')' ./80822-4.intel; done
for i in `seq 32`; do echo OMP_PLACES='cores('$i')' ./80822-4.intel;
OMP_PLACES='cores('$i')' ./80822-4.intel; done
to see if they do any smarts when the number of requested threads or cores is
limited, or just use the first N elements from what OMP_PLACES=threads or
OMP_PLACES=cores would be?
Thanks.

[Bug target/80846] auto-vectorized AVX2 horizontal sum should narrow to 128b right away, to be more efficient for Ryzen and Intel

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Created attachment 41421
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41421&action=edit
WIP patch

[Bug target/80846] auto-vectorized AVX2 horizontal sum should narrow to 128b right away, to be more efficient for Ryzen and Intel

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Similar with AVX512F I get

.L2:
vmovdqa64   -112(%rbp), %zmm3
addq$64, %rdi
vpaddd  -64(%rdi), %zmm3, %zmm2
cmpq%rdi, %rax
vmovdqa64   %zmm2, -112(%rbp)
jne .L2
vmovdqa -80(%rbp), %ymm0
vpaddd  -112(%rbp), %ymm0, %ymm5
vmovdqa %ymm5, -112(%rbp)
vmovdqa -96(%rbp), %xmm0
vpaddd  -112(%rbp), %xmm0, %xmm0
...

[Bug bootstrap/80867] gnat bootstrap broken on powerpc64le-linux-gnu with -O3

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|powerpc64le-linux-gnu,  |powerpc64le-linux-gnu,
   |x86_64-apple-darwin16   |x86_64-apple-darwin16,
   ||sparc-sun-solaris2.12,
   ||i386-pc-solaris2.12
 CC||ro at gcc dot gnu.org

--- Comment #6 from Rainer Orth  ---
Same on mainline between r248423 and r248462 on Solaris (both sparc and x86).

[Bug target/80885] Do not use the opaque _mm256_cmp_ps to produce -1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-26
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  The macro-case looks like wrong-code.

[Bug testsuite/80557] rewrite absolute line numbers into relative or saved line numbers

[vries at gcc dot gnu.org]

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

--- Comment #13 from Tom de Vries  ---
Author: vries
Date: Fri May 26 09:25:00 2017
New Revision: 248484

URL: https://gcc.gnu.org/viewcvs?rev=248484&root=gcc&view=rev
Log:
Replace absolute line numbers in gcc.dg

2017-05-26  Tom de Vries  

PR testsuite/80557
* gcc.dg/20011021-1.c: Replace absolute line numbers.
* gcc.dg/Wcxx-compat-8.c: Same.
* gcc.dg/Wobjsize-1.c: Same.
* gcc.dg/Wshadow-local-2.c: Same.
* gcc.dg/Wstrict-aliasing-converted-assigned.c: Same.
* gcc.dg/anon-struct-6.c: Same.
* gcc.dg/asm-wide-1.c: Same.
* gcc.dg/builtin-inf-1.c: Same.
* gcc.dg/builtin-redefine.c: Same.
* gcc.dg/c90-array-lval-6.c: Same.
* gcc.dg/c90-array-lval-7.c: Same.
* gcc.dg/c90-fordecl-1.c: Same.
* gcc.dg/c99-fordecl-2.c: Same.
* gcc.dg/cast-lvalue-1.c: Same.
* gcc.dg/cast-lvalue-2.c: Same.
* gcc.dg/compound-lvalue-1.c: Same.
* gcc.dg/cond-lvalue-1.c: Same.
* gcc.dg/cpp/2419-1.c: Same.
* gcc.dg/cpp/backslash.c: Same.
* gcc.dg/cpp/backslash2.c: Same.
* gcc.dg/cpp/macspace1.c: Same.
* gcc.dg/cpp/macspace2.c: Same.
* gcc.dg/cpp/multiline-2.c: Same.
* gcc.dg/cpp/pr2.c: Same.
* gcc.dg/cpp/pr30786.c: Same.
* gcc.dg/cpp/pr34602.c: Same.
* gcc.dg/cpp/redef1.c: Same.
* gcc.dg/cpp/tr-warn1.c: Same.
* gcc.dg/cpp/tr-warn3.c: Same.
* gcc.dg/cpp/tr-warn6.c: Same.
* gcc.dg/cpp/trad/hash.c: Same.
* gcc.dg/cpp/trad/redef1.c: Same.
* gcc.dg/cpp/ucs.c: Same.
* gcc.dg/declspec-10.c: Same.
* gcc.dg/declspec-11.c: Same.
* gcc.dg/declspec-18.c: Same.
* gcc.dg/format/c99-strftime-1.c: Same.
* gcc.dg/format/ext-3.c: Same.
* gcc.dg/format/pr72858.c: Same.
* gcc.dg/gomp/appendix-a/a.24.1.c: Same.
* gcc.dg/init-string-1.c: Same.
* gcc.dg/label-decl-3.c: Same.
* gcc.dg/m-un-2.c: Same.
* gcc.dg/nofixed-point-2.c: Same.
* gcc.dg/noncompile/20020213-1.c: Same.
* gcc.dg/pch/counter-2.c: Same.
* gcc.dg/plugin/diagnostic-test-string-literals-2.c: Same.
* gcc.dg/pr27528.c: Same.
* gcc.dg/pr27953.c: Same.
* gcc.dg/pr35899.c: Same.
* gcc.dg/pr37561.c: Same.
* gcc.dg/pr45461.c: Same.
* gcc.dg/pr45750.c: Same.
* gcc.dg/pr53196-2.c: Same.
* gcc.dg/pr53265.c: Same.
* gcc.dg/redecl-1.c: Same.
* gcc.dg/tls/thr-init-1.c: Same.
* gcc.dg/torture/pr51106-1.c: Same.
* gcc.dg/torture/pr51106-2.c: Same.
* gcc.dg/uninit-19.c: Same.
* gcc.dg/uninit-pr20644.c: Same.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/20011021-1.c
trunk/gcc/testsuite/gcc.dg/Wcxx-compat-8.c
trunk/gcc/testsuite/gcc.dg/Wobjsize-1.c
trunk/gcc/testsuite/gcc.dg/Wshadow-local-2.c
trunk/gcc/testsuite/gcc.dg/Wstrict-aliasing-converted-assigned.c
trunk/gcc/testsuite/gcc.dg/anon-struct-6.c
trunk/gcc/testsuite/gcc.dg/asm-wide-1.c
trunk/gcc/testsuite/gcc.dg/builtin-inf-1.c
trunk/gcc/testsuite/gcc.dg/builtin-redefine.c
trunk/gcc/testsuite/gcc.dg/c90-array-lval-6.c
trunk/gcc/testsuite/gcc.dg/c90-array-lval-7.c
trunk/gcc/testsuite/gcc.dg/c90-fordecl-1.c
trunk/gcc/testsuite/gcc.dg/c99-fordecl-2.c
trunk/gcc/testsuite/gcc.dg/cast-lvalue-1.c
trunk/gcc/testsuite/gcc.dg/cast-lvalue-2.c
trunk/gcc/testsuite/gcc.dg/compound-lvalue-1.c
trunk/gcc/testsuite/gcc.dg/cond-lvalue-1.c
trunk/gcc/testsuite/gcc.dg/cpp/2419-1.c
trunk/gcc/testsuite/gcc.dg/cpp/backslash.c
trunk/gcc/testsuite/gcc.dg/cpp/backslash2.c
trunk/gcc/testsuite/gcc.dg/cpp/macspace1.c
trunk/gcc/testsuite/gcc.dg/cpp/macspace2.c
trunk/gcc/testsuite/gcc.dg/cpp/multiline-2.c
trunk/gcc/testsuite/gcc.dg/cpp/pr2.c
trunk/gcc/testsuite/gcc.dg/cpp/pr30786.c
trunk/gcc/testsuite/gcc.dg/cpp/pr34602.c
trunk/gcc/testsuite/gcc.dg/cpp/redef1.c
trunk/gcc/testsuite/gcc.dg/cpp/tr-warn1.c
trunk/gcc/testsuite/gcc.dg/cpp/tr-warn3.c
trunk/gcc/testsuite/gcc.dg/cpp/tr-warn6.c
trunk/gcc/testsuite/gcc.dg/cpp/trad/hash.c
trunk/gcc/testsuite/gcc.dg/cpp/trad/redef1.c
trunk/gcc/testsuite/gcc.dg/cpp/ucs.c
trunk/gcc/testsuite/gcc.dg/declspec-10.c
trunk/gcc/testsuite/gcc.dg/declspec-11.c
trunk/gcc/testsuite/gcc.dg/declspec-18.c
trunk/gcc/testsuite/gcc.dg/format/c99-strftime-1.c
trunk/gcc/testsuite/gcc.dg/format/ext-3.c
trunk/gcc/testsuite/gcc.dg/format/pr72858.c
trunk/gcc/testsuite/gcc.dg/gomp/appendix-a/a.24.1.c
trunk/gcc/testsuite/gcc.dg/init-string-1.c
trunk/gcc/testsuite/gcc.dg/label-decl-3.c
trunk/gcc/testsuite/gcc.dg/m-un-2.c
trunk/gcc/testsuite/gcc.dg/nofixed-point-2.c
trunk/gcc/testsuite/gcc.dg/noncompile/20020213-1.c
trunk/gcc

[Bug sanitizer/80875] [7/8 Regression] UBSAN: compile time crash in fold_binary_loc at fold-const.c:9817

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Fri May 26 09:31:36 2017
New Revision: 248485

URL: https://gcc.gnu.org/viewcvs?rev=248485&root=gcc&view=rev
Log:
PR sanitizer/80875
* fold-const.c (fold_binary_loc) : Check if OP1
can be negated.

* c-c++-common/ubsan/pr80875.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/pr80875.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/80875] [7 Regression] UBSAN: compile time crash in fold_binary_loc at fold-const.c:9817

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[7/8 Regression] UBSAN: |[7 Regression] UBSAN:
   |compile time crash in   |compile time crash in
   |fold_binary_loc at  |fold_binary_loc at
   |fold-const.c:9817   |fold-const.c:9817

--- Comment #7 from Marek Polacek  ---
Fixed on trunk so far.

[Bug tree-optimization/80632] [8 Regression] error: invalid PHI argument with -O2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed.

[Bug target/80846] auto-vectorized AVX2 horizontal sum should narrow to 128b right away, to be more efficient for Ryzen and Intel

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Note that similar to the vec_init optab not allowing constructing larger
vectors from smaller ones vec_extract doesn't allow extracting smaller vectors
from larger ones.  So I might be forced to go V8SI -> V2TI -> TI -> V4SI to
make the RTL expander happy.

In that case for AVX512 we'll expose 256bit integers into the IL which means
VRP will barf immediately and we may so anyway as if optimization somehow
exposes
a constant that won't fit in widest_int...  Not sure if there's even V2OImode
supported.

For AVX2 we then expand

  _6 = VIEW_CONVERT_EXPR(vect_sum_11.6_14);
  _5 = BIT_FIELD_REF <_6, 128, 0>;
  _29 = VIEW_CONVERT_EXPR(_5);
  _22 = BIT_FIELD_REF <_6, 128, 128>;
  _21 = VIEW_CONVERT_EXPR(_22);
  _20 = _21 + _29;

to

;; _20 = _21 + _29;

(insn 18 17 19 (set (reg:OI 104)
(subreg:OI (reg:V2TI 89 [ _6 ]) 0)) -1
 (nil))

(insn 19 18 20 (set (reg:TI 105)
(subreg:TI (reg:OI 104) 16)) -1
 (nil))

(insn 20 19 21 (set (reg:OI 106)
(subreg:OI (reg:V2TI 89 [ _6 ]) 0)) -1
 (nil))

(insn 21 20 22 (set (reg:TI 107)
(subreg:TI (reg:OI 106) 0)) -1
 (nil))

(insn 22 21 0 (set (reg:V4SI 95 [ _20 ])
(plus:V4SI (subreg:V4SI (reg:TI 105) 0)
(subreg:V4SI (reg:TI 107) 0))) -1
 (nil))

which doesn't seem any better ... (still using subregs rather than going
through vec_extract).

(define_expand "vec_extract"
  [(match_operand: 0 "register_operand")
   (match_operand:VEC_EXTRACT_MODE 1 "register_operand")
   (match_operand 2 "const_int_operand")]
  "TARGET_SSE"
{
  ix86_expand_vector_extract (false, operands[0], operands[1],
  INTVAL (operands[2]));
  DONE;
})

ssescalarmode doesn't include TImode.

Note there's the corresponding bug that says x86 doesn't implement
{ TImode, TImode } vec_init either.

[Bug target/80846] auto-vectorized AVX2 horizontal sum should narrow to 128b right away, to be more efficient for Ryzen and Intel

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Created attachment 41422
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41422&action=edit
adjusted tree-vect-loop.c hunk

[Bug middle-end/80853] [6/7 Regression] OpenMP ICE in build_outer_var_ref with array reduction

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri May 26 10:05:39 2017
New Revision: 248486

URL: https://gcc.gnu.org/viewcvs?rev=248486&root=gcc&view=rev
Log:
Backported from mainline
2017-05-22  Jakub Jelinek  

PR middle-end/80853
* omp-low.c (lower_reduction_clauses): Pass OMP_CLAUSE_PRIVATE
as last argument to build_outer_var_ref for pointer bases of array
section reductions.

* testsuite/libgomp.c/pr80853.c: New test.

Added:
branches/gcc-7-branch/libgomp/testsuite/libgomp.c/pr80853.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/omp-low.c
branches/gcc-7-branch/libgomp/ChangeLog

[Bug middle-end/80809] Multi-free error for variable size array used within OpenMP task

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri May 26 10:13:34 2017
New Revision: 248487

URL: https://gcc.gnu.org/viewcvs?rev=248487&root=gcc&view=rev
Log:
Backported from mainline
2017-05-22  Jakub Jelinek  

PR middle-end/80809
* gimplify.c (omp_add_variable): For GOVD_DEBUG_PRIVATE use
GOVD_SHARED rather than GOVD_PRIVATE with it.
(gimplify_adjust_omp_clauses_1, gimplify_adjust_omp_clauses): Expect
GOVD_SHARED rather than GOVD_PRIVATE with GOVD_DEBUG_PRIVATE.

* testsuite/libgomp.c/pr80809-1.c: New test.

Added:
branches/gcc-7-branch/libgomp/testsuite/libgomp.c/pr80809-1.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/gimplify.c
branches/gcc-7-branch/libgomp/ChangeLog

[Bug middle-end/80809] Multi-free error for variable size array used within OpenMP task

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Fri May 26 10:14:37 2017
New Revision: 248488

URL: https://gcc.gnu.org/viewcvs?rev=248488&root=gcc&view=rev
Log:
Backported from mainline
2017-05-22  Jakub Jelinek  

PR middle-end/80809
* omp-low.c (finish_taskreg_remap): New function.
(finish_taskreg_scan): If unit size of ctx->record_type
is non-constant, unshare the size expression and replace
decls in it with possible outer var refs.

* testsuite/libgomp.c/pr80809-2.c: New test.
* testsuite/libgomp.c/pr80809-3.c: New test.

Added:
branches/gcc-7-branch/libgomp/testsuite/libgomp.c/pr80809-2.c
branches/gcc-7-branch/libgomp/testsuite/libgomp.c/pr80809-3.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/omp-low.c
branches/gcc-7-branch/libgomp/ChangeLog

[Bug c++/80886] New: __builtin_constant_p magic has broken at some point

[q....@rsn-tech.co.uk]

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

Bug ID: 80886
   Summary: __builtin_constant_p magic has broken at some point
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: q@rsn-tech.co.uk
  Target Milestone: ---

I'm using g++ for an embedded system, and as is common with such things,
hardware addresses are provided as hex constants. I want to create pointers
from them, using constexpr because they are known at compile time.

Now the C++ Standard forbids reinterpret_cast<> or the equivalent in a
constexpr so it can't be done directly, which is annoying but that's the
Standard.

However, with older versions of g++, one could solve this with the magic use of
__builtin_constant_p() in a ternary expression. Thus:

test.cpp:
#define CONST(x) (__builtin_constant_p(x) ? x : x)

constexpr void *phardware {CONST ((void *) 0x1000)};

(This is sufficient for a complete test program, BTW)

This use appears to be documented, although it's not 100% clear. It's certainly
very desirable.

My cross-development system recently upgraded from 4.9.2 to 6.2.1 and the magic
has stopped working. The loss of magic holds in other 6.x versions I've tried,
but still works in clang 3.8.1 which is the latest version in my distro (Fedora
24)

Compilation results:

$ <4.9.2>-g++  -c -std=c++14 test.cpp
$

$ <6.2.1>-g++  -c -std=c++14 test.cpp
test.cpp:4:28: error: reinterpret_cast from integer to pointer
 constexpr void *phardware {CONST ((void *) 0x1000)};
^~
test.cpp:2:45: note: in definition of macro 'CONST'
 #define CONST(x) (__builtin_constant_p(x) ? x : x)
$

Has this behaviour changed deliberately? As I say, it is contrary to the
Standard, but it would be disappointing to lose such a useful extension.

[Bug target/80862] [x86] Wrong rounding results for some test cases

[julia.koval at intel dot com]

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

--- Comment #2 from Yulia Koval  ---
Patch posted at https://gcc.gnu.org/ml/gcc-patches/2017-05/msg02013.html

[Bug tree-optimization/80884] [8 regression] test case gcc.target/powerpc/20050830-1.c fails starting with r247886

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |amker at gcc dot gnu.org

--- Comment #1 from amker at gcc dot gnu.org ---
Sorry for breaking it, I will investigate.  Thanks.

[Bug c++/71605] ICE on invalid C++ code (incorrect member access): in pop_binding, at cp/name-lookup.c:368

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||paolo.carlini at oracle dot com

--- Comment #2 from Paolo Carlini  ---
Adding David in CC because, besides the main issue, apparently his Rev. 244715
(in particular the change id_expr_token->location to id_expression.get_location
() in cp_parser_primary_expression) broke the location of the error we emit for
this testcase before crashing.

[Bug libgomp/80881] [7 Regression] null pointer access in libgomp.h

[daniel.f.starke at freenet dot de]

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

--- Comment #2 from Daniel Starke  ---
True, I have rebuild GCC without --enable-tls enabled and the null pointer
access is gone. So I guess there is still no TLS support for mingw-w64 (even
though Windows supports it as far as I know).

[Bug ipa/80663] signed integer overflow in ipa-split.c

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:05:52 2017
New Revision: 248489

URL: https://gcc.gnu.org/viewcvs?rev=248489&root=gcc&view=rev
Log:
Bound partial-inlining-entry-probability param (PR ipa/80663).

2017-05-26  Martin Liska  

PR ipa/80663
* params.def: Bound partial-inlining-entry-probability param.
2017-05-26  Martin Liska  

PR ipa/80663
* g++.dg/ipa/pr80212.C: Remove the test as it does not longer
split at the problematic spot.
* gcc.dg/ipa/pr48195.c: Change 101 to 100 as 101 is no longer
a valid value of the param.

Removed:
trunk/gcc/testsuite/g++.dg/ipa/pr80212.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/params.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/ipa/pr48195.c

[Bug ipa/80663] signed integer overflow in ipa-split.c

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.0
  Known to fail||5.4.0, 6.3.0, 7.1.0

--- Comment #3 from Martin Liška  ---
Fixed on trunk so far.

[Bug sanitizer/80875] [7 Regression] UBSAN: compile time crash in fold_binary_loc at fold-const.c:9817

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Author: mpolacek
Date: Fri May 26 11:15:37 2017
New Revision: 248490

URL: https://gcc.gnu.org/viewcvs?rev=248490&root=gcc&view=rev
Log:
PR sanitizer/80875
* fold-const.c (fold_binary_loc) : Check if OP1
can be negated.

* c-c++-common/ubsan/pr80875.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/c-c++-common/ubsan/pr80875.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/fold-const.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug sanitizer/80659] [7 Regression] -fsanitize=address evokes ICE in in gimplify_switch_expr

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek  ---
Author: mpolacek
Date: Fri May 26 11:17:34 2017
New Revision: 248491

URL: https://gcc.gnu.org/viewcvs?rev=248491&root=gcc&view=rev
Log:
PR sanitizer/80659
* c-decl.c (build_compound_literal): Set DECL_ARTIFICIAL and
DECL_IGNORED_P even for non-static compound literals.

* gcc.dg/asan/pr80659.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/asan/pr80659.c
Modified:
branches/gcc-7-branch/gcc/c/ChangeLog
branches/gcc-7-branch/gcc/c/c-decl.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug libgomp/80881] [7 Regression] null pointer access in libgomp.h

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
There is always an emulated TLS support, but that is not what you ask for if
you --enable-tls.  As for mingw TLS support, you need to ask the mingw
maintainers, I don't have access to that target, nor sufficient knowledge about
it.

[Bug sanitizer/80875] [7 Regression] UBSAN: compile time crash in fold_binary_loc at fold-const.c:9817

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #9 from Marek Polacek  ---
Fixed.

[Bug sanitizer/80659] [7 Regression] -fsanitize=address evokes ICE in in gimplify_switch_expr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #12 from Marek Polacek  ---
Fixed.

[Bug ipa/80104] ICE in initialize_argument_information, at calls.c:1748

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:24:49 2017
New Revision: 248492

URL: https://gcc.gnu.org/viewcvs?rev=248492&root=gcc&view=rev
Log:
Backport r246525

2017-05-26  Martin Liska  

Backport from mainline
2017-03-28  Martin Liska  

PR ipa/80104
* cgraphunit.c (cgraph_node::expand_thunk): Mark argument of a
thunk call as DECL_GIMPLE_REG_P when vector or complex type.
2017-05-26  Martin Liska  

Backport from mainline
2017-03-28  Martin Liska  

PR ipa/80104
* gcc.dg/ipa/pr80104.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/ipa/pr80104.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/cgraphunit.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug ipa/80205] [5/6 Regression] ICE in walk_ssa_copies at ipa-polymorphic-call.c:835

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:25:34 2017
New Revision: 248493

URL: https://gcc.gnu.org/viewcvs?rev=248493&root=gcc&view=rev
Log:
Backport r246530

2017-05-26  Martin Liska  

Backport from mainline
2017-03-28  Richard Biener  

PR ipa/80205
* tree-inline.c (copy_phis_for_bb): Do not create PHI node
without arguments, generate default definition of a SSA name.
2017-05-26  Martin Liska  

Backport from mainline
2017-03-28  Martin Liska  

PR ipa/80205
* g++.dg/ipa/pr80205.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/ipa/pr80205.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-inline.c

[Bug sanitizer/80166] SANITIZER_INTERCEPT_GETGROUPS modifies list when size is 0 Out-of-bounds write

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:26:04 2017
New Revision: 248494

URL: https://gcc.gnu.org/viewcvs?rev=248494&root=gcc&view=rev
Log:
Backport r246730

2017-05-26  Martin Liska  

Backport from mainline
2017-04-06  Martin Liska  

PR sanitizer/80166
* gcc.dg/asan/pr80166.c: New test.
2017-05-26  Martin Liska  

Backport from mainline
2017-04-06  Martin Liska  

PR sanitizer/80166
* sanitizer_common/sanitizer_common_interceptors.inc (INTERCEPTOR):
Cherry-pick upstream r299036.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/asan/pr80166.c
Modified:
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/libsanitizer/ChangeLog
   
branches/gcc-6-branch/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc

[Bug sanitizer/80350] UBSAN changes code semantics when -fno-sanitize-recover=undefined is used

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:26:45 2017
New Revision: 248495

URL: https://gcc.gnu.org/viewcvs?rev=248495&root=gcc&view=rev
Log:
Backport r246799

2017-05-26  Martin Liska  

Backport from mainline
2017-04-10  Martin Liska  

PR sanitizer/80350
* c-ubsan.c (ubsan_instrument_shift): Evaluate RHS before
doing an UBSAN check.
2017-05-26  Martin Liska  

Backport from mainline
2017-04-10  Martin Liska  

PR sanitizer/80350
* c-c++-common/ubsan/pr80350.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/c-c++-common/ubsan/pr80350.c
Modified:
branches/gcc-6-branch/gcc/c-family/ChangeLog
branches/gcc-6-branch/gcc/c-family/c-ubsan.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug gcov-profile/80224] gcov -i crashes with two arguments

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:27:25 2017
New Revision: 248496

URL: https://gcc.gnu.org/viewcvs?rev=248496&root=gcc&view=rev
Log:
Backport r246804

2017-05-26  Martin Liska  

Backport from mainline
2017-04-10  Martin Liska  

PR gcov-profile/80224
* gcov.c (print_usage): Fix usage string.
(get_gcov_intermediate_filename): Remove.
(output_gcov_file): Use both for normal and intermediate format.
(generate_results): Do not initialize special file for
intermediate format.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/gcov.c

[Bug sanitizer/70878] [5/6 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7680

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:28:07 2017
New Revision: 248497

URL: https://gcc.gnu.org/viewcvs?rev=248497&root=gcc&view=rev
Log:
Backport r246837

2017-05-26  Martin Liska  

Backport from mainline
2017-04-11  Martin Liska  

PR sanitizer/70878
* ubsan.c (instrument_object_size): Do not instrument register
variables.
2017-05-26  Martin Liska  

Backport from mainline
2017-04-11  Martin Liska  

PR sanitizer/70878
* gcc.dg/ubsan/pr70878.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/ubsan/pr70878.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/ubsan.c

[Bug ipa/80212] [5/6 Regression] ICE: error: comdat-local function called by virtual

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:28:44 2017
New Revision: 248498

URL: https://gcc.gnu.org/viewcvs?rev=248498&root=gcc&view=rev
Log:
Backport r246847

2017-05-26  Martin Liska  

Backport from mainline
2017-04-11  Martin Liska  

PR ipa/80212
* ipa-cp.c (determine_versionability): Handle calls_comdat_local
flags.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/ipa-cp.c

[Bug ipa/80212] [5/6 Regression] ICE: error: comdat-local function called by virtual

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:29:35 2017
New Revision: 248499

URL: https://gcc.gnu.org/viewcvs?rev=248499&root=gcc&view=rev
Log:
Backport r246848

2017-05-26  Martin Liska  

Backport from mainline
2017-04-11  Martin Liska  

PR ipa/80212
* cgraph.c (cgraph_node::dump): Dump calls_comdat_local.
* ipa-split.c (split_function): Create a local comdat symbol
if caller is in a comdat group.
2017-05-26  Martin Liska  

Backport from mainline
2017-04-11  Martin Liska  

PR ipa/80212
* g++.dg/ipa/pr80212.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/ipa/pr80212.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/cgraph.c
branches/gcc-6-branch/gcc/ipa-split.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug gcov-profile/80413] sanitizer detects undefined behaviour in gcov-io.c using -ftest-coverage

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:30:54 2017
New Revision: 248500

URL: https://gcc.gnu.org/viewcvs?rev=248500&root=gcc&view=rev
Log:
Backport r246903

2017-05-26  Martin Liska  

Backport from mainline
2017-04-13  Martin Liska  

PR gcov-profile/80413
* gcov-io.c (gcov_write_string): Copy to buffer just when
allocated size is greater than zero.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/gcov-io.c

[Bug gcov-profile/78783] gcov-tool fails in gcov_read_counter_mem

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:31:15 2017
New Revision: 248501

URL: https://gcc.gnu.org/viewcvs?rev=248501&root=gcc&view=rev
Log:
Backport r246961

2017-05-26  Martin Liska  

Backport from mainline
2017-04-18  Martin Liska  

PR gcov-profile/78783
* gcov-tool.c (gcov_output_files): Validate that destination
file is either removed by the tool or by a user.
2017-05-26  Martin Liska  

Backport from mainline
2017-04-18  Martin Liska  

PR gcov-profile/78783
* libgcov-driver.c (gcov_get_filename): New function.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/gcov-tool.c
branches/gcc-6-branch/libgcc/ChangeLog
branches/gcc-6-branch/libgcc/libgcov-driver.c

[Bug ipa/65972] ICE after applying a patch to enable verify_ssa with auto-pgo

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:31:52 2017
New Revision: 248503

URL: https://gcc.gnu.org/viewcvs?rev=248503&root=gcc&view=rev
Log:
Backport r246996

2017-05-26  Martin Liska  

Backport from mainline
2017-04-19  Richard Biener  

PR ipa/65972
* auto-profile.c (afdo_vpt_for_early_inline): Update SSA
when needed by AutoPGO.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/auto-profile.c

[Bug lto/50345] Incomplete GCC Internals sentence on LTO

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:31:33 2017
New Revision: 248502

URL: https://gcc.gnu.org/viewcvs?rev=248502&root=gcc&view=rev
Log:
Backport r246995

2017-05-26  Martin Liska  

Backport from mainline
2017-04-19  Paulo J. Matos  

PR lto/50345
* doc/lto.texi: Remove an extra 'that'.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/doc/lto.texi

[Bug ipa/79931] ICE in dump_possible_polymorphic_call_targets with -fdump-ipa-all -O2

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
Author: marxin
Date: Fri May 26 11:32:26 2017
New Revision: 248504

URL: https://gcc.gnu.org/viewcvs?rev=248504&root=gcc&view=rev
Log:
Backport r247097

2017-05-26  Martin Liska  

Backport from mainline
2017-04-24  Jan Hubicka  

PR middle-end/79931
* ipa-devirt.c (dump_possible_polymorphic_call_targets): Fix ICE.
2017-05-26  Martin Liska  

Backport from mainline
2017-04-24  Martin Liska  

PR middle-end/79931
* g++.dg/ipa/pr79931.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/ipa/pr79931.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/ipa-devirt.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug sanitizer/80350] UBSAN changes code semantics when -fno-sanitize-recover=undefined is used

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||6.3.1
  Known to fail|6.3.1   |

--- Comment #7 from Martin Liška  ---
Fixed on GCC 6 branch.

[Bug bootstrap/80887] New: gnat bootstrap fails at s-regpat.o: raised STORAGE_ERROR : stack overflow or erroneous memory access

[redi at gcc dot gnu.org]

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

Bug ID: 80887
   Summary: gnat bootstrap fails at s-regpat.o: raised
STORAGE_ERROR : stack overflow or erroneous memory
access
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

I just got the following building trunk on x86_64-pc-linux-gnu with no special
flags, just $srcdir/configure --enable-languages=c,c++,ada --enable-werror


/home/jwakely/src/gcc/bootstrap/./gcc/xgcc
-B/home/jwakely/src/gcc/bootstrap/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/
-B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include-c -g -O2 -m32 -fpic  -W -Wall
-gnatpg -nostdinc -m32  s-regpat.adb -o s-regpat.o

raised STORAGE_ERROR : stack overflow or erroneous memory access
../gcc-interface/Makefile:296: recipe for target 's-regpat.o' failed


According to Bug 80867 comment 5 and Bug 80867 comment 6 this also happens on
darwin and solaris. It started between r248423 and r248462

[Bug bootstrap/80867] gnat bootstrap broken on powerpc64le-linux-gnu with -O3

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Target|powerpc64le-linux-gnu,  |powerpc64le-linux-gnu
   |x86_64-apple-darwin16,  |
   |sparc-sun-solaris2.12,  |
   |i386-pc-solaris2.12 |

--- Comment #7 from Jonathan Wakely  ---
I've created Bug 80887 for the trunk error affecting all targets, so this can
stay specific to the powerpc64le one on gcc-7-branch

[Bug libgomp/80822] libgomp incorrect affinity when OMP_PLACES=threads

[weeks at iastate dot edu]

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

--- Comment #9 from Nathan Weeks  ---
Created attachment 41423
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41423&action=edit
Code from 80822 comment #4 run as per comment #8

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

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

--- Comment #6 from Alexander Monakov  ---
There's a bit of a misunderstanding here, the -mcx16 option remains supported,
and the compiler remains capable of issuing lock-cmpxchg16b for __sync
builtins, in particular for __sync_val_compare_and_swap. What changed in gcc-7
is that __atomic builtins that would previously get expanded to a sequence
involving cmpxchg16b now always yield a library call on x86, but libatomic
tries to support that efficiently by using cmpxchg16b internally, on CPUs that
have it and on targets that support IFUNC.

No bug here, rather a (non-obvious imho) design change.

[Bug ada/80888] New: Wide_Text_IO defaults to bracket encoding even if -gnatW8 specified

[simon at pushface dot org]

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

Bug ID: 80888
   Summary: Wide_Text_IO defaults to bracket encoding even if
-gnatW8 specified
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
  Target Milestone: ---
  Host: x86_64-apple-darwin15

The GNAT reference manual says in 11.6 Wide_Text_IO
,

   "The default encoding method for the standard files, and for opened
   files for which no WCEM parameter is given in the FORM string matches
   the wide character encoding specified for the main program (the
   default being brackets encoding if no coding method was specified with
   -gnatW)."

This is slightly wrong, in that the UTF-8 coding method is selected
even in the absence of -gnatW8 if the main program's source file has
the appropriate BOM; but the point of this PR is that it is not in
fact true, and even if -gnatW8 is given files are created/opened with
bracket encoding unless the Form parameter is given (Form => "wcem=8").

The attached demonstrator shows this. The file as uploaded begins with
EF BB BF, but compile with -gnatW8 to be sure:

$ gnatmake utf8_encoding -gnatW8
gcc -c -gnatW8 utf8_encoding.adb
gnatbind -x utf8_encoding.ali
gnatlink utf8_encoding.ali
$ ./utf8_encoding 

Two files are created, one without the Form parameter:

   $ od -tx1 -c -N32 file_without_form 
   0005b  22  30  33  43  30  22  5d  72  b2  68  0a
  [   "   0   3   C   0   "   ]   r 262   h  \n
   014

and one with:

   $ od -tx1 -c -N32 file_with_form 
   000cf  80  72  c2  b2  68  0a
  π  **   r   ²  **   h  \n
   007

[Bug ada/80888] Wide_Text_IO defaults to bracket encoding even if -gnatW8 specified

[simon at pushface dot org]

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

--- Comment #1 from simon at pushface dot org ---
Created attachment 41424
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41424&action=edit
Demonstrator

[Bug sanitizer/80350] UBSAN changes code semantics when -fno-sanitize-recover=undefined is used

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
As the patch can't be easily ported to GCC 5, I'm not planning to backport to
the branch. Thus closing as resolved.

[Bug fortran/80889] New: [8 Regression] Bootstrap broken on all targets due to rev 248472

[wilco at gcc dot gnu.org]

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

Bug ID: 80889
   Summary: [8 Regression] Bootstrap broken on all targets due to
rev 248472
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilco at gcc dot gnu.org
  Target Milestone: ---

As reported in https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01995.html all
bootstraps fail:

configure: error: conditional "HAVE_AVX128" was never defined.
Usually this means the macro was only invoked conditionally.
Makefile:19843: recipe for target 'configure-target-libgfortran' failed
make[1]: *** [configure-target-libgfortran] Error 1
make[1]: *** Waiting for unfinished jobs

Even if you disable this error, bootstrap fails due to trying to build x86
specific files:

gcc/libgfortran/generated/matmulavx128_i1.c  -fPIC -DPIC -o
.libs/matmulavx128_i1.o
xgcc: error: unrecognized command line option ‘-mprefer-avx128’
make[3]: *** [matmulavx128_i1.lo] Error 1

[Bug c++/80890] New: Qualified class member access in a member initialization

[sergi.mateo at bsc dot es]

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

Bug ID: 80890
   Summary: Qualified class member access in a member
initialization
   Product: gcc
   Version: 5.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sergi.mateo at bsc dot es
  Target Milestone: ---

The following C++11 code doesn't compile with g++ 5.4.1, although it compiles
fine with g++ 6:

template < typename _K, typename _V >
class  A
{
int x;
int *px = &x; // OK
int *qx = &this->x;   // OK
int *rx = &(*this).x; // OK
int *sx = &((*this).::A<_K, _V>::x); // OK
int *tx = &(*this).::A<_K, _V>::x;   // KO
};

The error message is the following one:

g++ -c t1.cc -std=c++11

t1.cc:9:36: error: expected ‘;’ at end of member declaration
 int *tx = &(*this).::A<_K, _V>::x;   // KO
^
t1.cc:9:36: error: declaration of ‘int A<_K, _V>::_V’
t1.cc:1:25: error:  shadows template parm ‘class _V’
 template < typename _K, typename _V >
 ^
t1.cc:9:38: error: expected unqualified-id before ‘>’ token
 int *tx = &(*this).::A<_K, _V>::x;   // KO
  ^
t1.cc:9:32: error: wrong number of template arguments (1, should be 2)
 int *tx = &(*this).::A<_K, _V>::x;   // KO
^
t1.cc:2:8: note: provided for ‘template class A’
 class  A


Best regards,
Sergi

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Since this makes libatomic required for DCAS on x86_64 it should probably have
been documented at https://gcc.gnu.org/gcc-7/changes.html

[Bug middle-end/80815] wrong code because of broken runtime alias check in vectorizer

[amker at gcc dot gnu.org]

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

--- Comment #5 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri May 26 14:18:26 2017
New Revision: 248512

URL: https://gcc.gnu.org/viewcvs?rev=248512&root=gcc&view=rev
Log:
PR tree-optimization/80815
* tree-data-ref.c (prune_runtime_alias_test_list): Simplify condition
for merging runtime alias checks.  Handle negative DR_STEPs.
gcc/testsuite
* gcc.dg/vect/pr80815-1.c: New test.
* gcc.dg/vect/pr80815-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr80815-1.c
trunk/gcc/testsuite/gcc.dg/vect/pr80815-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-data-ref.c

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247848

[boger at us dot ibm.com]

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

--- Comment #16 from boger at us dot ibm.com ---
After further investigation I found the original testcase failures started
happening with an earlier commit, which I have verified as 247497.  That commit
caused 7 new libgo testcase failures, but at the time, it didn't cause the
error log to grow excessively so went unnoticed.  When the large gofrontend
change went in, then the same failures occurred but it was at that point when
the information written to the error log grew to an excessive size.  Probably
due to the random nature of the original bug.

One additional note, when debugging a few other failures, I found that when
calling runtime.typedmemmove from reflect.typedmemmove, the second argument is
not being initialized, which results in a SEGV for some tests (reflect,
archive/tar, mime/multipart).  It might be easier to compile the file
containing reflect.typedmemmove and dump out the intermediate output?

[Bug c++/80859] Performance Problems with OpenMP 4.5 support

[thorstenkurth at me dot com]

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

--- Comment #24 from Thorsten Kurth  ---
Hello Jakub,

I know that the section you mean is racey and gets the wrong number of threads
is not right but I put this in in order to see if I get the correct numbers on
a CPU (I am not working on a GPU yet, that will be next). Most of the defines
for setting number of teams and threads in outer loop are for playing around
with that and see what works best, in the end this will be removed. This code
is not finished by any means, it is a moving target and under active
development. Only the OpenMP3 version is considered done and works well.

You said that SIMD pragmas is missing, and this is for a reason. First of all,
the code is memory bandwidth bound, so it has a rather low AI so that
vectorization does not help a lot. Of course vectorization helps in the sense
that the loads and stores are vectorized and the prefetcher works more
efficiently. But we made sure that the (Intel) compiler vectorizes the inner
loops automatically nicely. Putting in explicit SIMD pragmas made the code
performance worse, because in that case the (Intel) compiler generates worse
code in some cases (according to some Intel compiler guys, this is because if
the compiler sees a SIMD statement it will not try to partially unroll loops
etc. and might generate more masks than necessary). So auto vectorization works
fine here so we have not revisited this issue. The GNU compiler might be
different and I did not look at what the auto-vectorizer did.

The more important questions I have are the following:
1) as you see the codes has two levels of parallelism. On the CPU, it is most
efficient to tile the boxes (this is the loop with the target distribute) and
then let one thread work on a box. I added another level of parallelism inside
that box, because on the GPU you have more thread and might want to exploit
more parallelism. Talking to folks from IBM at an OpemMP 4.5 hackathon at least
this is what they suggested. 
So my question is: when you have a target teams distribute, will be one team
equal to a CUDA WARP or will it be something bigger? In that case, I would like
to have one WARP working on a box and not letting different ptx threads working
on individual boxes. To summarize: on the CPU the OpenMP threading should be
such that one threads gets a box and the vectorization works on the inner loop
(which is fine, that works), and in the CUDA case one team/WARP should work on
a box and then SIMT parallelize the work on the box.

2) related to this: how does ptx behave when it sees a SIMD statement in a
target region? Is that ignored or somehow interpreted? In any case, how does
OpenMP do the mapping between CUDA WARP <-> OpenMP CPU thread, because this is
the closest equivalence I would say. I would guess it ignores SIMD pragmas and
just acts on thread level, where in the CUDA world one thread more or less acts
like a SIMD lane on the CPU.

3) this device mapping business is extremely verbose for C++ classes. For
example the MFIter class amfi, comfy, solnLmfi whatever are not correctly
mapped yet and would cause trouble on the GPU (the intel compiler complains
that the stuff is not bitwise copyable, GNU complies it though). These are
classes containing other class pointers. So in order to map that properly I
would technically need to map the dereferenced data member of the member class
of the first class, correct? As an example, you have a class with
std::vector * vector data member. You technically need to map the
vector.data() member to the device, right? That however tells you that you need
to be able to access that guy, i.e. it should not be a protected class member.
So what happens when you have a class which you cannot change but need to map
private/protected members of it? The example at hand is the MFIter class which
has this:

protected:

const FabArrayBase& fabArray;

IntVect tile_size;

unsigned char flags;
int   currentIndex;
int   beginIndex;
int   endIndex;
IndexType typ;

const Array* index_map;
const Array* local_index_map;
const Array* tile_array;

void Initialize ();

It has these array pointers. So technically this is (to my knowledge, I do not
know the code fully) an array of indices which determines which global indices
the iterator is in fact iterating over. This stuff can be shared among the
threads and it is only read and never written. Nevertheless, it needs to know
the indices on the device so the index_map etc. needs to be mapped. Now, Array
is just a class with a public member of std::vector. But in order to map the
index_map class member I would need to have access to it, so that I can map the
underlying std::vector data member. Do you know what I mean? How is this done
in the most elegant way in OpenMP?

[Bug c++/80859] Performance Problems with OpenMP 4.5 support

[jakub at gcc dot gnu.org]

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

--- Comment #25 from Jakub Jelinek  ---
In the GCC implementation of offloading to PTX, all HW threads in a warp (i.e.
32 of them) are a single OpenMP thread, and one needs to use a simd region
(effectively SIMT) to get useful work done by all all the threads of a warp
rather than just one.
Right now GCC doesn't do auto-SIMTization (but does auto-vectorization on the
host or XeonPhi accelerator etc., but only with -O3 or -O2 -ftree-vectorize;
while with simd constructs you get it even with just -O2 -fopenmp for those
regions), so simd construct is important to get the right performance.  Threads
within a team are the warp groups of threads within a PTX CTA, and different
teams are the CTAs in a CTA grid (in PTX terms).

[Bug fortran/80889] [8 Regression] Bootstrap broken on all targets due to rev 248472

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-05-26
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Koenig  ---
I broke it, so I'll fix it.

[Bug fortran/35339] Improve translation of implied do loop in transfer

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
(In reply to Nicolas Koenig from comment #7)
> Created attachment 41420 [details]
> Early patch for simplifying impl do loops - 2
> 
> Sorry, wrong patch _and_ wrong testcase... Still fails for mysterious
> reasons, though.

I was thinking the whole change would be in trans-io.c. This was before
frontend-passes.c existed.

[Bug c++/80859] Performance Problems with OpenMP 4.5 support

[thorstenkurth at me dot com]

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

--- Comment #26 from Thorsten Kurth  ---
Hello Jakub,

thanks for the clarification. So a team maps to a CTA which is somewhat
equivalent to a block in CUDA language, correct? And it is good to have some
categorical equivalency between GPU and CPU code (SIMD units <> WARPS) instead
of mapping SIMT threads to OpenMP threads, that makes it easier for making it
portable. 

About my mapping "problem" is there an elegant way for doing this or does only
brute force work, i.e. by writing additional member functions returning
pointers etc.?
In general, the OpenMP mapping business is very verbose (not your fault, I
know), it makes the code very annoying to read.

Best
Thorsten

[Bug libgomp/80822] libgomp incorrect affinity when OMP_PLACES=threads

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-05-26
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #10 from Jakub Jelinek  ---
Created attachment 41425
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41425&action=edit
gcc8-pr80822.patch

So far untested patch that should implement what from the above dumps Intel
runtime seems to implement, i.e. always walk process all (available) OS cpus
from each socket and within each socket all (available) OS cpus for each core,
just depending on threads/cores/sockets choose what to put together into
individual places vs. when to start a new place.

[Bug libgomp/80822] libgomp incorrect affinity when OMP_PLACES=threads

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Should apply cleanly against 6.x, 7.x as well as current trunk.

[Bug bootstrap/80887] gnat bootstrap fails at s-regpat.o: raised STORAGE_ERROR : stack overflow or erroneous memory access

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
For me r248443 works (well, I had to add 0 && in
maybe_warn_about_cast_ignoring_quals because there are two different bootstrap
failures caused by that), while r248453 fails.  As the ICE is in wide_int
handling from const_binop from match.pd, and the closest match.pd line is 1308
in gimple-match.c in the backtrace, I suspect r248448.

[Bug c++/80890] Qualified class member access in a member initialization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Dup of Bug 52595, fixed by 224152

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

[Bug c++/52595] [DR 325] commas and non-static data member initializers don't mix

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||sergi.mateo at bsc dot es

--- Comment #15 from Jonathan Wakely  ---
*** Bug 80890 has been marked as a duplicate of this bug. ***

[Bug bootstrap/80887] gnat bootstrap fails at s-regpat.o: raised STORAGE_ERROR : stack overflow or erroneous memory access

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Trying to print captures in the frame that calls gimple_simplify_135 I see it
oscillating between:
parse_pos.474_23
4294967295
4294967295

and

_78
1
4294967294

(captures[0..2]).

  _76 = CHAIN.552_67(D)->parse_pos;
  _78 = _76 + 1;
...
  _115 = CHAIN.552_67(D)->parse_pos;
  parse_pos.474_23 = (sizetype) _115;
  _24 = parse_pos.474_23 + 4294967295;

[Bug fortran/80889] [8 Regression] Bootstrap broken on all targets due to rev 248472

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Author: tkoenig
Date: Fri May 26 17:16:35 2017
New Revision: 248519

URL: https://gcc.gnu.org/viewcvs?rev=248519&root=gcc&view=rev
Log:
2017-05-26  Thomas Koenig  

PR boostrap/80889
* acinclude.m4: Also set HAVE_AVX128 on the false
branch of LIBGFOR_CHECK_AVX128.
* configure:  Regenerated.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/acinclude.m4
trunk/libgfortran/configure

[Bug c++/80891] New: [8 Regression] Three new ICEs

[trippels at gcc dot gnu.org]

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

Bug ID: 80891
   Summary: [8 Regression] Three new ICEs
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
  Target Milestone: ---

1)

 % cat chi_square_std_dev_test.ii
namespace std {
struct A {
  void operator<<(A(A));
};
template  _CharT endl(_Traits);
A a;
}
using std::endl;
void chi_squared_sample_sized() {
  using namespace std;
  a << endl;
}

 % g++ -c chi_square_std_dev_test.ii
chi_square_std_dev_test.ii: In function ‘void chi_squared_sample_sized()’:
chi_square_std_dev_test.ii:11:8: internal compiler error: in get_bindings, at
cp/pt.c:21559
   a << endl;
^~~~
0x7b3a35 get_bindings
../../gcc/gcc/cp/pt.c:21559
0x7b3af5 more_specialized_inst
../../gcc/gcc/cp/pt.c:21692
0x7b3c31 most_specialized_instantiation(tree_node*)
../../gcc/gcc/cp/pt.c:21732
0x5eef43 resolve_address_of_overloaded_function
../../gcc/gcc/cp/class.c:8251
0x5ccdf6 standard_conversion
../../gcc/gcc/cp/call.c:1123
0x5daef8 implicit_conversion
../../gcc/gcc/cp/call.c:1839
0x5dc896 add_function_candidate
../../gcc/gcc/cp/call.c:2196
0x5de6b7 add_candidates
../../gcc/gcc/cp/call.c:5479
0x5e6269 add_candidates
../../gcc/gcc/cp/call.c:5379
0x5e6269 build_new_op_1
../../gcc/gcc/cp/call.c:5653
0x5e6b3e build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
../../gcc/gcc/cp/call.c:6009
0x815de2 build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
../../gcc/gcc/cp/typeck.c:3957
0x72e894 cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9051
0x72efe4 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9184
0x732e28 cp_parser_expression
../../gcc/gcc/cp/parser.c:9353
0x73b698 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:10912
0x7208e6 cp_parser_statement
../../gcc/gcc/cp/parser.c:10728
0x7219ad cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11054
0x721a7f cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11008
0x722198 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21445

2)

 % cat ptr_vector.ii
void swap();
namespace boost {   
void swap();
}   
using namespace boost;  
template  void reversible_container_test() {
  using namespace boost;
  C a;  
  swap(a);  
}   
namespace boost {   
struct A {};
template  void swap();
}   
void test_ptr_vector() { reversible_container_test; } 

 % g++ -c ptr_vector.ii
ptr_vector.ii: In instantiation of ‘void reversible_container_test() [with C =
boost::A;  = int;  = int]’: 
ptr_vector.ii:15:64:   required from here   
ptr_vector.ii:9:7: internal compiler error: in ovl_copy, at cp/tree.c:2142  
   swap(a); 
   ^~~
0x7f7812 ovl_copy   
../../gcc/gcc/cp/tree.c:2142
0x7fc4e7 lookup_maybe_add(tree_node*, tree_node*)   
../../gcc/gcc/cp/tree.c:2383
0x6f951a name_lookup::add_fns(tree_node*)   
../../gcc/gcc/cp/name-lookup.c:688  
0x6f98ff name_lookup::adl_namespace(tree_node*) 
../../gcc/gcc/cp/name-lookup.c:714  
0x6f98ff name_lookup::adl_class_only(tree_node*)
../../gcc/gcc/cp/name-lookup.c:740  
0x6f9c3e name_lookup::adl_bases(tree_node*) 
../../gcc/gcc/cp/name-lookup.c:774  
0x6fa094 name_lookup::adl_class(tree_node*) 
../../gcc/gcc/cp/name-lookup.c:817  
0x6fae3c name_lookup::search_adl(tree_node*, vec*) 
../../gcc/gcc/cp/name-lookup.c:1001 
0x6faef4 lookup_arg_dependent(tree_node*, tree_node*, vec*) 
../../gcc/gcc/cp/name-lookup.c:1026 
0x7d6786 perform_koenig_lookup(cp_expr, vec*, int) 
../../gcc/gcc/cp/semantics.c:2270   
0x7903c0 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)  
../../gcc/gcc/cp/pt.c:17253 
0x77ec33 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) 
../../gcc/gcc/cp/pt.c:16514 
0x77d3ae tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) 
../../gcc/gcc/cp/pt.c:15778 
0x77c751 tsubst_expr(tree_node*, tree_node*, int, tree_node*, b

[Bug fortran/80889] [8 Regression] Bootstrap broken on all targets due to rev 248472

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #3 from Thomas Koenig  ---
Fixed, closing.

[Bug c++/80891] [8 Regression] Three new ICEs

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-26
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c/80892] New: [8 regression] -Wfloat-conversion now warns about non-floats

[egall at gwmail dot gwu.edu]

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

Bug ID: 80892
   Summary: [8 regression] -Wfloat-conversion now warns about
non-floats
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egall at gwmail dot gwu.edu
CC: msebor at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-apple-darwin10.8.0
Target: i386-apple-darwin10.8.0
 Build: i386-apple-darwin10.8.0

Previously, it was possible to request warnings about just conversions
involving floating point types by specifying -Wfloat-conversion. However, with
my latest build from trunk, -Wfloat-conversion seems to have become an alias
for -Wconversion, meaning that it now warns on things like:

/usr/local/bin/gcc -c -DHAVE_CONFIG_H -g -O2 -arch i386  -I. -I./../include
-D_DARWIN_UNLIMITED_STREAMS -mmacosx-version-min=10.5 -Wall -Wextra
-Wwrite-strings -Wc++-compat -Wodr -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-parameter-type -Wmissing-declarations -Wnested-externs -Wundef
-Wshadow -Wformat=2 -Wformat-overflow=2 -Wformat-truncation=2
-Wstringop-overflow=2 -Walloc-zero -Wrestrict -Wold-style-definition
-Wold-style-declaration -Wfloat-conversion -Wabi -Wc99-c11-compat
-Wmisleading-indentation -Wnull-dereference -Wpointer-compare -Wbool-operation
-pedantic  ./cp-demangle.c -o cp-demangle.o
./cp-demangle.c: In function 'd_print_java_identifier':
./cp-demangle.c:3473:27: warning: conversion from 'long unsigned int' to 'char'
may change value [-Wfloat-conversion]
d_append_char(dpi, c);
   ^

This means I now have a bunch of new warnings in my build where I previously
didn't, because I'm only using -Wfloat-conversion and not the full
-Wconversion. cc-ing Martin Sebor since he was the last one I remember seeing
posting patches touching the -Wconversion code.

gcc version info:
$ /usr/local/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin10.8.0/8.0.0/lto-wrapper
Target: i386-apple-darwin10.8.0
Configured with: ../configure --disable-werror --disable-werror-always
--enable-languages=c,c++,objc,obj-c++,lto --enable-stage1-checking=release,rtl
-C --with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-debug --without-isl --disable-host-shared --enable-maintainer-mode
--disable-default-pie --with-ld64 --without-pic --enable-target-optspace
--disable-nls --with-system-zlib --with-libiconv-prefix=/opt/local
--with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --enable-lto
--enable-libstcxx-time --with-build-config=bootstrap-debug
--with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --enable-objc-gc --enable-libada --enable-libssp
CC='/usr/bin/gcc-4.2 -arch i386 -arch x86_64' CXX='/usr/bin/g++-4.2 -arch
x86_64' AR_FOR_TARGET=/opt/local/bin/ar AS_FOR_TARGET=/opt/local/bin/as
LD_FOR_TARGET=/opt/local/bin/ld NM_FOR_TARGET=/opt/local/bin/nm
RANLIB_FOR_TARGET=/opt/local/bin/ranlib STRIP_FOR_TARGET=/opt/local/bin/strip
OTOOL=/opt/local/bin/otool OTOOL64=/opt/local/bin/otool
AUTOCONF=/opt/local/bin/autoconf264 AUTOHEADER=/opt/local/bin/autoheader264
AUTOM4TE=/opt/local/bin/autom4te264 AUTORECONF=/opt/local/bin/autoreconf264
AUTOSCAN=/opt/local/bin/autoscan264 AUTOUPDATE=/opt/local/bin/autoupdate264
IFNAMES=/opt/local/bin/ifnames264 ACLOCAL=/sw/bin/aclocal-1.11
PERL=/opt/local/bin/perl CFLAGS='-pipe -g -Os' CXXFLAGS='-pipe -g -Os
-fcheck-new' CPP='/usr/bin/gcc-4.2 -E' CXXCPP='/usr/bin/g++-4.2 -E'
M4=/opt/local/bin/gm4
Thread model: posix
gcc version 8.0.0 20170525 (experimental) (GCC)

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[boger at us dot ibm.com]

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

--- Comment #17 from boger at us dot ibm.com ---
Here's more info on the failures and how to reproduce them.  Starting with
commit 247497 there are 7 new failures in the libgo testsuite.

There are 4 that fail with a SEGV at runtime: reflect, archive/tar,
mime/multipart, and net/mail. I looked at 2 and their stacks look similar but
not quite the same.  The SEGV happens because a 0 is passed as the address of
the src argument.

archive/tar shows a stack like this at the point of the SEGV:
Program received signal SIGSEGV, Segmentation fault.
__memcpy_power7 () at ../sysdeps/powerpc/powerpc64/power7/memcpy.S:219
219 ../sysdeps/powerpc/powerpc64/power7/memcpy.S: No such file or
directory.
(gdb) bt
#0  __memcpy_power7 () at ../sysdeps/powerpc/powerpc64/power7/memcpy.S:219
#1  0x3fffb6350918 in __GI_memmove (dest=0xc208086600, src=,
len=) at ../sysdeps/powerpc/memmove.c:54
#2  0x3fffb71567bc in runtime.memmove (p1=, p2=, len=)
at ../../../src/libgo/runtime/go-memmove.c:15
#3  0x3fffb7620fd8 in runtime.typedmemmove (typ=,
dst=, src=)
at ../../../src/libgo/go/runtime/stubs.go:298
#4  0x3fffb76215bc in reflect.typedmemmove (typ=,
dst=, src=)
at ../../../src/libgo/go/runtime/stubs.go:304
#5  0x3fffb75c8384 in reflect.packEface (v=...) at
../../../src/libgo/go/reflect/value.go:113
#6  reflect.valueInterface (param=..., safe=true) at
../../../src/libgo/go/reflect/value.go:821
#7  0x3fffb75c8760 in reflect.Interface.N13_reflect.Value
(pointer=) at ../../../src/libgo/go/reflect/value.go:781
#8  0x3fffb72e570c in fmt.printValue.pN6_fmt.pp (p=,
param=..., verb=, depth=)
at ../../../src/libgo/go/fmt/print.go:694
#9  0x3fffb72e623c in fmt.printValue.pN6_fmt.pp (p=,
param=..., verb=, depth=)

With gdb I found that when reflect.typedmemmove calls runtime.typedmemmove, it
is passing a bad argument for the src.

Something similar happens in the reflect test, although that SEGV stack looks
like this:
288 ../sysdeps/powerpc/powerpc64/power7/memcpy.S: No such file or
directory.
(gdb) bt
#0  __memcpy_power7 () at ../sysdeps/powerpc/powerpc64/power7/memcpy.S:288
#1  0x3fffb6350918 in __GI_memmove (dest=0xc20800b6d0, src=,
len=) at ../sysdeps/powerpc/memmove.c:54
#2  0x3fffb71567bc in runtime.memmove (p1=, p2=, len=)
at ../../../src/libgo/runtime/go-memmove.c:15
#3  0x3fffb762165c in runtime.typedslicecopy (typ=, dst=...,
src=...) at ../../../src/libgo/go/runtime/stubs.go:329
#4  0x3fffb76216cc in reflect.typedslicecopy (elemType=,
dst=..., src=...) at ../../../src/libgo/go/runtime/stubs.go:336
#5  0x10052c6c in reflect.Copy (param=..., param=...) at value.go:1747
#6  0x100529f4 in reflect.AppendSlice (param=..., param=...) at
value.go:1702
#7  0x10069514 in reflect_test.TestAppend (t=) at
all_test.go:534

And the bad address is passed for the src argument for the call from
reflect.typedslicecopy to runtime.typedslicecopy.

The tests for fmt, net, and debug/dwarf fail when processing code that calls
reflect.DeepEqual followed by a call to Errorf, something like this:

if out := ParseIP(tt.in); !reflect.DeepEqual(out, tt.out) {
  t.Errorf("ParseIP(%q) = %v, want %v", tt.in, out, tt.out)
}

The argument for tt.out is passed incorrectly to DeepEqual, causing it to
return false when it shouldn't, and then passes bad information to the Errorf
function.

I've tried to reproduce this in a smaller testcase but haven't been able to.  I
run these tests after a build by first editing the src/libgo/testsuite/gotest
to set keep=true and trace=true.  Then I go to my bld directory:

cd bld/powerpc64le-linux/libgo
make fmt/check

That should give you output with the full gccgo command to build the test, the
directory containing the a.out and files from the test.  The name of the
directory is gotestx.

FAIL
Keeping gotest32163
FAIL: fmt
Makefile:3331: recipe for target 'fmt/check' failed

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[ian at airs dot com]

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

--- Comment #18 from Ian Lance Taylor  ---
Lynn, thanks for the detailed investigation.

Martin, Lynn is saying that these problems started with the SRA patch for PR
78687 committed on 2017-05-02.

It's odd that this problem only shows up on PPC64LE, not on x86_64.

In this case we have a three element struct, and we are passing the address of
the struct to a function.  Somehow the writes to two of the fields of the
struct are being dropped.  But since we are taking the address anyhow, I'm not
sure precisely where SRA is kicking in.

[Bug libstdc++/80893] New: std::vector creation dereferences null pointer

[terra at gnome dot org]

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

Bug ID: 80893
   Summary: std::vector creation dereferences null pointer
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: terra at gnome dot org
  Target Milestone: ---

Created attachment 41426
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41426&action=edit
g++ -E output, just in case it's needed

It looks like copying a pristine vector or initializing one
with an explicit length of zero involves dereferencing a null pointer
although nothing is actually done with the result.  -fsanitize is unhappy
with that.


# cat test.C
#include 

int main() {
  // OK
  std::vector a;

  // Fails.
  std::vector b(a);

  // Fails.
  std::vector c(0);

  (void)a;
  (void)b;
  (void)c;
  return 0;
}


# /usr/local/products/gcc/7.1.0/bin/g++ -v -D_GLIBCXX_DEBUG
-fsanitize=undefined -O test.C -Wl,-rpath,/usr/local/products/gcc/7.1.0/lib64
-fsanitize=undefined
Using built-in specs.
COLLECT_GCC=/usr/local/products/gcc/7.1.0/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/products/gcc/7.1.0/lib/gcc/x86_64-suse-linux/7.1.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../../gcc-7.1.0/configure --enable-languages=c,c++,fortran
--enable-targets=x86_64-suse-linux,i686-suse-linux
--prefix=/usr/local/products/gcc/7.1.0 --with-gnu-as
--with-as=/usr/local/products/gcc/binutils-2.26/bin/as --with-gnu-ld
--with-ld=/usr/local/products/gcc/binutils-2.26/bin/ld.bfd
--with-gmp=/usr/local/products/gcc/gmp-6.1.0
--with-mpfr=/usr/local/products/gcc/mpfr-3.1.4
--with-mpc=/usr/local/products/gcc/mpc-1.0.3 --enable-threads=posix
--enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=pool
x86_64-suse-linux
Thread model: posix
gcc version 7.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-D' '_GLIBCXX_DEBUG' '-fsanitize=undefined' '-O'
'-fsanitize=undefined' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/products/gcc/7.1.0/lib/gcc/x86_64-suse-linux/7.1.0/cc1plus -quiet
-v -D_GNU_SOURCE -D _GLIBCXX_DEBUG test.C -quiet -dumpbase test.C
-mtune=generic -march=x86-64 -auxbase test -O -version -fsanitize=undefined
-fsanitize=undefined -o /tmp/ccjJFQr4.s
GNU C++14 (GCC) version 7.1.0 (x86_64-suse-linux)
compiled by GNU C version 7.1.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version none
warning: MPFR header version 3.1.4 differs from library version 3.1.3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/products/gcc/7.1.0/lib64/gcc/x86_64-suse-linux/7.1.0/../../../../x86_64-suse-linux/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/products/gcc/7.1.0/lib64/gcc/x86_64-suse-linux/7.1.0/../../../../include/c++/7.1.0

/usr/local/products/gcc/7.1.0/lib64/gcc/x86_64-suse-linux/7.1.0/../../../../include/c++/7.1.0/x86_64-suse-linux

/usr/local/products/gcc/7.1.0/lib64/gcc/x86_64-suse-linux/7.1.0/../../../../include/c++/7.1.0/backward
 /usr/local/products/gcc/7.1.0/lib64/gcc/x86_64-suse-linux/7.1.0/include
 /usr/local/include
 /usr/local/products/gcc/7.1.0/include
 /usr/local/products/gcc/7.1.0/lib64/gcc/x86_64-suse-linux/7.1.0/include-fixed
 /usr/include
End of search list.
GNU C++14 (GCC) version 7.1.0 (x86_64-suse-linux)
compiled by GNU C version 7.1.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version none
warning: MPFR header version 3.1.4 differs from library version 3.1.3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2b9455e910d94e4d2b3b828bd090b81a
COLLECT_GCC_OPTIONS='-v' '-D' '_GLIBCXX_DEBUG' '-fsanitize=undefined' '-O'
'-fsanitize=undefined' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/products/gcc/binutils-2.26/bin/as -v --64 -o /tmp/ccJ4ZfpM.o
/tmp/ccjJFQr4.s
GNU assembler version 2.26 (x86_64-suse-linux) using BFD version (GNU Binutils)
2.26.20160125
COMPILER_PATH=/usr/local/products/gcc/7.1.0/lib/gcc/x86_64-suse-linux/7.1.0/:/usr/local/products/gcc/7.1.0/lib/gcc/x86_64-suse-linux/7.1.0/:/usr/local/products/gcc/7.1.0/lib/gcc/x86_64-suse-linux/:/usr/local/products/gcc/7.1.0/lib64/gcc/x86_64-suse-linux/7.1.0/:/usr/local/products/gcc/7.1.0/lib64/gcc/x86_64-suse-linux/
LIBRARY_PATH=/usr/local/products/gcc/7.1.0/lib64/gcc/x86_64-suse-linux/7.1.0/:/usr/local/products/gcc/7.1.0/lib64/gcc/x86_64-suse-linux/7.1.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/local/products/gcc/7.1.0/lib64/gcc/x86_64-suse-linux/7.1.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-D' '_GLIBCXX_DEBUG' '-fsanitize=undefined' '-O'
'-fsanitize=undefined' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/products/gcc/7.1.0/lib/gcc/x86_64-suse-linux/7.1.0/collect2 -plugin
/usr/local/products/gcc/7.1.0/lib/gcc/x86_64-suse-linux/7.1.0/li

[Bug libgcc/80037] Bad .eh_frame data in crtend.o

[rth at gcc dot gnu.org]

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

--- Comment #3 from Richard Henderson  ---
Author: rth
Date: Fri May 26 18:45:59 2017
New Revision: 248522

URL: https://gcc.gnu.org/viewcvs?rev=248522&root=gcc&view=rev
Log:
PR libgcc/80037

 * config/alpha/t-alpha (CRTSTUFF_T_CFLAGS): New.

Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config/alpha/t-alpha

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[boger at us dot ibm.com]

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

--- Comment #19 from boger at us dot ibm.com ---
Is someone building and testing gccgo on x86_64 on a regular basis?  If I look
at the gcc-testresults output for x86_64 I don't see the go or libgo test
results like I do for ppc64le.  Maybe it does fail there too.

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

[amonakov at gcc dot gnu.org]

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

--- Comment #8 from Alexander Monakov  ---
Well, at least it's not too late to update the compiler manual, so I've
submitted a patch: https://gcc.gnu.org/ml/gcc-patches/2017-05/msg02080.html

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[pinskia at gcc dot gnu.org]

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

--- Comment #20 from Andrew Pinski  ---
(In reply to boger from comment #19)
> Is someone building and testing gccgo on x86_64 on a regular basis?  If I
> look at the gcc-testresults output for x86_64 I don't see the go or libgo
> test results like I do for ppc64le.  Maybe it does fail there too.

I am testing go on both x86_64 and aarch64:
latest results for go on x86_64 from me:
https://gcc.gnu.org/ml/gcc-testresults/2017-05/msg02832.html

latest results on aarch64 from me:
https://gcc.gnu.org/ml/gcc-testresults/2017-05/msg02770.html

[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer

[liakhdi at ornl dot gov]

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

--- Comment #2 from DIL  ---
I have fixed all issues reported by VALGRIND so the code now is valgrind-clean.
However, the problem I reported still shows up from time to time (only when the
code is compiled with -g and no optimization: BUILD_TYPE = DEV). The test which
fails depends on a number of source files, so I do not really see a clear way
to localize the problem in a small code snippet. In fact, the ALLOCATE()
statement which fails works just fine when called from other places. I thought
you might have some tools to inspect the ALLOCATE() code to see why it sees a
NULLIFIED pointer as ALLOCATED when the error message is triggered (the exact
location of the ALLOCATE statement is specified in the previous message). But I
am not sure how hard this would be. Also, I haven't had a chance to try the new
7.1 compiler.
Thanks,
Dmitry

[Bug c/80892] [8 regression] -Wfloat-conversion now warns about non-floats

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-05-26
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed:

$ cat t.c && gcc -S -Wfloat-conversion t.c
void f (char);

void g (unsigned long x)
{
  f (x);
}
t.c: In function ‘g’:
t.c:5:6: warning: conversion from ‘long unsigned int’ to ‘char’ may change
value [-Wfloat-conversion]
   f (x);
  ^

The conversion changes were committed in r248431.  They weren't intended to
change how warnings are controlled so this is a bug.

[Bug libgcc/80037] Bad .eh_frame data in crtend.o

[rth at gcc dot gnu.org]

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

--- Comment #4 from Richard Henderson  ---
Author: rth
Date: Fri May 26 19:29:46 2017
New Revision: 248525

URL: https://gcc.gnu.org/viewcvs?rev=248525&root=gcc&view=rev
Log:
PR libgcc/80037

 Backport from mainline
 * config/alpha/t-alpha (CRTSTUFF_T_CFLAGS): New.


Modified:
branches/gcc-7-branch/libgcc/ChangeLog
branches/gcc-7-branch/libgcc/config/alpha/t-alpha

[Bug libgcc/80037] Bad .eh_frame data in crtend.o

[rth at gcc dot gnu.org]

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

--- Comment #5 from Richard Henderson  ---
Author: rth
Date: Fri May 26 19:33:19 2017
New Revision: 248526

URL: https://gcc.gnu.org/viewcvs?rev=248526&root=gcc&view=rev
Log:
PR libgcc/80037

 Backport from mainline
 * config/alpha/t-alpha (CRTSTUFF_T_CFLAGS): New.


Modified:
branches/gcc-6-branch/libgcc/ChangeLog
branches/gcc-6-branch/libgcc/config/alpha/t-alpha

[Bug libgcc/80037] Bad .eh_frame data in crtend.o

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.5

--- Comment #6 from Richard Henderson  ---
Fixed.

[Bug libgcc/80037] Bad .eh_frame data in crtend.o

[stilor at att dot net]

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

--- Comment #7 from Alexey Neyman  ---
Can you close 80848 as a duplicate of this one?

[Bug libgcc/80037] Bad .eh_frame data in crtend.o

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 CC||mitalis at iiitd dot ac.in

--- Comment #8 from Richard Henderson  ---
*** Bug 80848 has been marked as a duplicate of this bug. ***

[Bug target/80848] /crtend.o(.eh_frame); no .eh_frame_hdr table will be created

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||rth at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Richard Henderson  ---
Dup.

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

[Bug target/80880] internal compiler error: in ix86_expand_builtin

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

 CC||ienkovich at gcc dot gnu.org

--- Comment #2 from Ilya Enkovich  ---
It would be more preferable to avoid conditional replacement for bndret calls
but making such exception may require unintuitive fixes in various propagators.
We can loose returned bounds in some cases anyway, so I agree with proposed
patch.

Also it might make sense to handle NULL case because it is likely to be the
most popular propagated conditional value for pointers.