[Bug gcov-profile/88994] [GCOV] encoding (or unicode) error with gcov/gcc9 when generating filename

[moussu.robin at pm dot me]

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

--- Comment #2 from Robin  ---
Nice :)
Feel free to ask me any additionnal things if it may help.

[Bug gcov-profile/88994] [GCOV] encoding (or unicode) error with gcov/gcc9 when generating filename

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-01-23
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #1 from Martin Liška  ---
Confirmed, I'm working on that.

[Bug c/88993] GCC 9 -Wformat-overflow=2 should reflect real libc limits

[fw at gcc dot gnu.org]

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

--- Comment #4 from Florian Weimer  ---
(In reply to Jakub Jelinek from comment #3)
> Rather than warning about this the bugs should be fixed, there is no reason
> why glibc needs to malloc memory for these cases.

I completely agree.  The warning is bogus.  In any case, the trigger point is
much too low.

> For "%.65535s" I don't
> actually see where it would allocate memory, I see memory allocations when
> it has to convert between wide and narrow strings or vice versa, for either
> of these cases it is enough to put a max cap on the buffer size and just
> handle it piecewise rather than all in one go.

There's a patch for that: https://patchwork.sourceware.org/patch/21106/

It needs to be rebased to current master (and perhaps adjusted to use an
overflow-checking builtin).

[Bug d/89004] mtype.c:2329:33: error: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Werror=sign-compare]

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Fixed on trunk in r268167.

[Bug d/89004] mtype.c:2329:33: error: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Werror=sign-compare]

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-23
 CC||ibuclaw at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1
  Known to fail||9.0

[Bug d/89004] New: mtype.c:2329:33: error: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Werror=sign-compare]

[marxin at gcc dot gnu.org]

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

Bug ID: 89004
   Summary: mtype.c:2329:33: error: comparison of integer
expressions of different signedness: ‘int’ and
‘size_t’ {aka ‘long unsigned int’}
[-Werror=sign-compare]
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Started with merge from upstream dmd r268124. Full warning:

In file included from ../../gcc/d/d-system.h:23,
 from ../../gcc/d/dmd/root/dsystem.h:24,
 from ../../gcc/d/dmd/mtype.c:11:
../../gcc/d/dmd/mtype.c: In member function ‘Identifier*
Type::getTypeInfoIdent()’:
../../gcc/d/dmd/mtype.c:2329:33: error: comparison of integer expressions of
different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’}
[-Werror=sign-compare]
 2329 | assert(0 < length && length < namelen); // don't overflow the
buffer
  |  ~~~^
../../gcc/system.h:742:14: note: in definition of macro ‘gcc_assert’
  742 |((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0
: 0))
  |  ^~~~
../../gcc/d/dmd/mtype.c:2329:5: note: in expansion of macro ‘assert’
 2329 | assert(0 < length && length < namelen); // don't overflow the
buffer
  | ^~

Patch candidate:
diff --git a/gcc/d/dmd/mtype.c b/gcc/d/dmd/mtype.c
index 09161a313ee..2a23cab74fd 100644
--- a/gcc/d/dmd/mtype.c
+++ b/gcc/d/dmd/mtype.c
@@ -2326,7 +2326,7 @@ Identifier *Type::getTypeInfoIdent()

 int length = sprintf(name, "_D%lluTypeInfo_%s6__initZ", (unsigned long
long) 9 + len, buf.data);
 //printf("%p, deco = %s, name = %s\n", this, deco, name);
-assert(0 < length && length < namelen); // don't overflow the buffer
+assert(0 < length && (size_t)length < namelen); // don't overflow the
buffer

 Identifier *id = Identifier::idPool(name, length);

[Bug c/88993] GCC 9 -Wformat-overflow=2 should reflect real libc limits

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Rather than warning about this the bugs should be fixed, there is no reason why
glibc needs to malloc memory for these cases.  For "%.65535s" I don't actually
see where it would allocate memory, I see memory allocations when it has to
convert between wide and narrow strings or vice versa, for either of these
cases it is enough to put a max cap on the buffer size and just handle it
piecewise rather than all in one go.  For integral numbers with high precision,
again, it is trivial to estimate how many characters you really need, the rest
is just padding which can be handled differently.

[Bug target/88998] bad codegen with mmx instructions for unordered_map

[dpzmick at gmail dot com]

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

David Zmick  changed:

   What|Removed |Added

 CC||dpzmick at gmail dot com

--- Comment #2 from David Zmick  ---
I'd like to add that we are seeing assertion fail because of the interaction
between MMX and the "long double" used in unordered_map's _M_need_rehash.

long double is forcing the use of the FPU, but the MMX instructions emitted are
wiping out the state of the FPU registers. Adding the an explicit _mm_empty (or
disabling MMX) solves the problem because it eliminates the bad interaction
with the long double in _M_need_rehash.

I'm not sure if there's a good way for developers to know when they need to add
(potentially expensive) calls to _mm_empty to vector code like this, so I feel
like I'd be less surprised if the compiler cleaned up after itself if it uses
MMX for code like this (and leave me with a performance problem to debug) than
if I ended up with the polluted FPU unexpectedly.

[Bug ipa/88985] [9 Regression] ICE in estimate_edge_devirt_benefit, at ipa-fnsummary.c:2585

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Then it's mine.

[Bug fortran/40598] Some missed optimizations in array assignment

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #13 from Jürgen Reuter  ---
This seems to have been forgotten, it is still assigned. Is there any progress
on this one?

[Bug tree-optimization/88713] Vectorized code slow vs. flang

[glisse at gcc dot gnu.org]

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

--- Comment #33 from Marc Glisse  ---
(In reply to Chris Elrod from comment #32)
> (In reply to Marc Glisse from comment #31)
> > What we need to understand is why gcc doesn't try to generate rsqrt

Without -mavx512er, we do not have an expander for rsqrtv16sf2, and without
that I don't know how the machinery can guess how to use rsqrt (there are
probably ways).

> The approximate sqrt, and then approximate reciprocal approximations were
> slower on my computer than just vsqrt followed by div.

We can probably split that into the speed of sqrt vs its approximation and
inverse (div) vs its approximation. At least one of them seems to be a
pessimization on that platform.

[Bug tree-optimization/88713] Vectorized code slow vs. flang

[elrodc at gmail dot com]

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

--- Comment #32 from Chris Elrod  ---
(In reply to Marc Glisse from comment #31)
> (In reply to Chris Elrod from comment #30)
> > gcc caclulates the rsqrt directly
> 
> No, vrsqrt14ps is just the first step in calculating sqrt here (slightly
> different formula than rsqrt). vrcp14ps shows that it is computing an
> inverse later. What we need to understand is why gcc doesn't try to generate
> rsqrt (which would also have vrsqrt14ps, but a slightly different formula
> without the comparison with 0 and masking, and without needing an inversion
> afterwards).

Okay, I think I follow you. You're saying instead of doing this (from
rguenther), which we want (also without the comparison to 0 and masking, as you
note):

 /* rsqrt(a) = -0.5 * rsqrtss(a) * (a * rsqrtss(a) * rsqrtss(a) - 3.0) */

it is doing this, which also uses the rsqrt instruction:

 /* sqrt(a)  = -0.5 * a * rsqrtss(a) * (a * rsqrtss(a) * rsqrtss(a) - 3.0) */

and then calculating an inverse approximation of that?

The approximate sqrt, and then approximate reciprocal approximations were
slower on my computer than just vsqrt followed by div.

[Bug c++/89003] New: Return inside a statement expression while initializing a static local variable fails to cleanup cxa_guard

[wilkey at drive dot ai]

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

Bug ID: 89003
   Summary: Return inside a statement expression while
initializing a static local variable fails to cleanup
cxa_guard
   Product: gcc
   Version: 5.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilkey at drive dot ai
  Target Milestone: ---

consider the following:

void f() {
  static int i = ({
if (true) return;
42;
  });
}

g++ -g yields:
   0x00400606 <+0>: push   %rbp
   0x00400607 <+1>: mov%rsp,%rbp
   0x0040060a <+4>: mov$0x601040,%eax
   0x0040060f <+9>: movzbl (%rax),%eax
   0x00400612 <+12>:test   %al,%al
   0x00400614 <+14>:jne0x40062a 
   0x00400616 <+16>:mov$0x601040,%edi
   0x0040061b <+21>:callq  0x4004e0 <__cxa_guard_acquire@plt>
   0x00400620 <+26>:test   %eax,%eax
   0x00400622 <+28>:setne  %al
   0x00400625 <+31>:test   %al,%al
   0x00400627 <+33>:je 0x40062a 
   0x00400629 <+35>:nop
   0x0040062a <+36>:pop%rbp
   0x0040062b <+37>:retq   


Note that nothing is emitted to release the guard (neither
__cxa_guard_release() nor __cxa_guard_abort()).

The next caller of the function will either SIGABRT if on the same thread
(deadlock detection algorithm) or block forever if another thread.

Slightly more complex examples include __cxa_guard_release for cases that don't
return early, but if the early return path is taken, the emitted code will
still just JMP right over it.

[Bug target/88998] bad codegen with mmx instructions for unordered_map

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-23
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
Indeed. Constructing {a,b,0,0} is done by constructing {a,b}, {0,0}, and
concatenating them. _mm_cvtepi32_pd starts with selecting the initial V2SI of a
V4SI. Naturally, the compiler tries to combine them, and finds sse2_cvtpi2pd to
convert directly from V2SI to V2DF. Without this simplification, everything
would have used SSE.

[Bug tree-optimization/88713] Vectorized code slow vs. flang

[glisse at gcc dot gnu.org]

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

--- Comment #31 from Marc Glisse  ---
(In reply to Chris Elrod from comment #30)
> gcc caclulates the rsqrt directly

No, vrsqrt14ps is just the first step in calculating sqrt here (slightly
different formula than rsqrt). vrcp14ps shows that it is computing an inverse
later. What we need to understand is why gcc doesn't try to generate rsqrt
(which would also have vrsqrt14ps, but a slightly different formula without the
comparison with 0 and masking, and without needing an inversion afterwards).

[Bug tree-optimization/88713] Vectorized code slow vs. flang

[elrodc at gmail dot com]

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

--- Comment #30 from Chris Elrod  ---
gcc still (In reply to Marc Glisse from comment #29)
> The main difference I can see is that clang computes rsqrt directly, while
> gcc first computes sqrt and then computes the inverse. Also gcc seems afraid
> of getting NaN for sqrt(0) so it masks out this value. ix86_emit_swsqrtsf in
> gcc/config/i386/i386.c seems like a good place to look at.

gcc caclulates the rsqrt directly with funsafe-math-optimizations and a couple
other flags (or just -ffast-math):

vmovups (%rsi), %zmm0
vxorps  %xmm1, %xmm1, %xmm1
vcmpps  $4, %zmm0, %zmm1, %k1
vrsqrt14ps  %zmm0, %zmm1{%k1}{z}

[Bug tree-optimization/88713] Vectorized code slow vs. flang

[glisse at gcc dot gnu.org]

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

--- Comment #29 from Marc Glisse  ---
The main difference I can see is that clang computes rsqrt directly, while gcc
first computes sqrt and then computes the inverse. Also gcc seems afraid of
getting NaN for sqrt(0) so it masks out this value. ix86_emit_swsqrtsf in
gcc/config/i386/i386.c seems like a good place to look at.

[Bug tree-optimization/89002] New: ICE in scan_omp_1_op, at omp-low.c:3166

[asolokha at gmx dot com]

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

Bug ID: 89002
   Summary: ICE in scan_omp_1_op, at omp-low.c:3166
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

1.

gcc-9.0.0-alpha20190120 snapshot (r268107) ICEs when compiling the following
testcase w/ -fopenmp:

void
bl (int j4)
{
  int lh;
  int *u4 = 

#pragma omp parallel
#pragma omp taskloop lastprivate (lh)
  for (lh = 0; lh < j4; ++lh)
{
}
}

% gcc-9.0.0-alpha20190120 -fopenmp -c ydeu3h7i.c
during GIMPLE pass: omplower
ydeu3h7i.c: In function 'bl':
ydeu3h7i.c:8:9: internal compiler error: in scan_omp_1_op, at omp-low.c:3166
8 | #pragma omp taskloop lastprivate (lh)
  | ^~~
0x6630f7 scan_omp_1_op
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/omp-low.c:3166
0x1046ea2 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/tree.c:12064
0xadaa5e walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/gimple-walk.c:221
0xadacc1 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/gimple-walk.c:586
0xadae60 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/gimple-walk.c:51
0xc40501 scan_omp
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/omp-low.c:3368
0xc476f7 scan_sharing_clauses
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/omp-low.c:1609
0xc49aca scan_omp_for
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/omp-low.c:2337
0xc4a815 scan_omp_1_stmt
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/omp-low.c:3291
0xadac8f walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/gimple-walk.c:568
0xadae60 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/gimple-walk.c:51
0xadad41 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/gimple-walk.c:675
0xadae60 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/gimple-walk.c:51
0xc40501 scan_omp
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/omp-low.c:3368
0xc4a5e5 scan_omp_task
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/omp-low.c:1974
0xc4a5e5 scan_omp_1_stmt
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/omp-low.c:3280
0xadac8f walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/gimple-walk.c:568
0xadae60 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/gimple-walk.c:51
0xadad41 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/gimple-walk.c:675
0xadae60 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
   

[Bug tree-optimization/88975] ICE: Segmentation fault (in verify_ssa or gimple_code)

[asolokha at gmx dot com]

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

--- Comment #1 from Arseny Solokha  ---
--- xsihfn9u.c  2019-01-23 09:46:02.954589253 +0700
+++ msyweyyj.c  2019-01-23 09:46:13.439477032 +0700
@@ -4,7 +4,7 @@
   int ij[gy];
   int sk;

-#pragma omp taskloop reduction(+:ij)
+#pragma omp taskloop simd reduction(+:ij)
   for (sk = 0; sk < 1; ++sk)
 {
 }

% gcc-9.0.0-alpha20190120 -fopenmp -c msyweyyj.c
during GIMPLE pass: ssa
msyweyyj.c: In function 'mr._omp_fn.0':
msyweyyj.c:11:1: internal compiler error: Segmentation fault
   11 | }
  | ^
0xd701df crash_signal
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/toplev.c:326
0x98a4d8 dominated_by_p(cdi_direction, basic_block_def const*, basic_block_def
const*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/dominance.c:1124
0xf8acd3 verify_use
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/tree-ssa.c:872
0xf92117 verify_ssa(bool, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/tree-ssa.c:1141
0xc89d0d execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/passes.c:1984
0xc8ab0e execute_todo
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/passes.c:2031

[Bug c++/88986] [7/8/9 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in member_vec_binary_search, at cp/name-lookup.c:1136

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Started with r244246.

[Bug c++/88986] [7/8/9 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in member_vec_binary_search, at cp/name-lookup.c:1136

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-23
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |7.5
Summary|[9 Regression] ICE: tree|[7/8/9 Regression] ICE:
   |check: expected tree that   |tree check: expected tree
   |contains 'decl minimal' |that contains 'decl
   |structure, have |minimal' structure, have
   |'error_mark' in |'error_mark' in
   |member_vec_binary_search,   |member_vec_binary_search,
   |at cp/name-lookup.c:1136|at cp/name-lookup.c:1136
 Ever confirmed|0   |1

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

[Bug c++/88987] [9 Regression] ICE: unexpected expression '(bool)sm' of kind implicit_conv_expr

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Started with r266874.

[Bug c++/88987] [9 Regression] ICE: unexpected expression '(bool)sm' of kind implicit_conv_expr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-23
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

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

[Bug c++/89001] New: g++ uses wrong mangling for lifetime-extended temporaries

[richard-gccbugzilla at metafoo dot co.uk]

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

Bug ID: 89001
   Summary: g++ uses wrong mangling for lifetime-extended
temporaries
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

Consider:

inline int & = 0;
int *p = 

GCC mangles the lifetime-extended temporary as _ZGR1r0, which doesn't match the
ABI mangling rule
(http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-special-temporaries).
The mangling required by the ABI (and produced by Clang) is _ZGR1r_

[Bug ipa/88985] [9 Regression] ICE in estimate_edge_devirt_benefit, at ipa-fnsummary.c:2585

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-23
 CC||msebor at gcc dot gnu.org
  Known to work||8.2.0
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  Bisection points to r261744:

r261744 | marxin | 2018-06-19 10:31:20 -0400 (Tue, 19 Jun 2018) | 75 lines

Clean-up usage of ipa_fn_summary and ipa_call_summary summaries.

The result of the following call is null, and so the dereference in the return
statement below crashes:

  isummary = ipa_fn_summaries->get (callee);
  return isummary->inlinable;

[Bug libstdc++/88996] Implement P0439R0 - Make std::memory_order a scoped enumeration.

[emsr at gcc dot gnu.org]

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

--- Comment #6 from emsr at gcc dot gnu.org ---
Created attachment 45502
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45502=edit
New patch, C++20 only, several fixes, no memory_order ops.

Retesting.

[Bug libstdc++/88996] Implement P0439R0 - Make std::memory_order a scoped enumeration.

[emsr at gcc dot gnu.org]

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

--- Comment #5 from emsr at gcc dot gnu.org ---
I was a bit surprised I "needed" these. There are apparently some uses of
these.
I'll roll back and show you...

/home/ed/obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/atomic_base.h:104:7:
error: no match for ‘operator|’ (operand types are ‘std::memory_order’ and
‘std::memory_order’)
  103 | return memory_order(__cmpexch_failure_order2(__m &
__memory_order_mask)
  |
~~~
  | |
  | std::memory_order
  104 |   | (__m & __memory_order_modifier_mask));
  |   ^ 
  |  |
  |  std::memory_order

Ok, I'm casting:
  | __memory_order_modifier(__m & __memory_order_modifier_mask));

This will work without the operators.
Those are sequatial flags.
Killed the ops, fix some more sadness and retest.

[Bug gcov-profile/89000] New: gcov --function-summaries says No branches/No calls, only the File summary is correct

[steven.w.carmer at lmco dot com]

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

Bug ID: 89000
   Summary: gcov --function-summaries says No branches/No calls,
only the File summary is correct
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: steven.w.carmer at lmco dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

gcc -v output
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/appl/lucy_local_sde/Linux-RHEL7-x86_64/gcc-8.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/appl/lucy_local_sde/src/gcc/gcc-8.2.0/x86_64-Linux-3.10/gcc-8.2.0-obj/../gcc-8.2.0/configure
--prefix=/usr/local/sde/gcc-8.2.0 --disable-nls --enable-shared --enable-static
--enable-multilib --with-multilib-list=m32,m64 --enable-languages=c,c++,fortran
Thread model: posix
gcc version 8.2.0 (GCC) 

When using the -f (--function-summaries) option with gcov, it does not provide
the branch/call statistics for the functions. The file summary is correct, and
the *gcov output file that gets created shows it has the branch/call
information that the -f option relies upon, but the gcov -f output just shows
"No branches/No calls" for all the function summaries.

A trivial example source code file gcov_test.c that produces these results:

#include 
#include 
#include 

void foo(void);
void foo(void)
{
  static bool firstPass = true;

  if (firstPass)
  {
firstPass = false;
printf ("First Pass\n");
  }
  else
  {
printf ("Not First Pass\n");
  }
}

int main (int argc, char *argv[])
{

  foo();
  foo();
  foo();

  return 0;
}

Compile that C file with the following:
gcc -fprofile-arcs -ftest-coverage gcov_test.c

Run the executable to produce the gcov artifacts
./a.out

And then run the following to view the coverage report
gcov -b gcov_test.c -f

Function 'main'
Lines executed:100.00% of 5
No branches
No calls

Function 'foo'
Lines executed:100.00% of 6
No branches
No calls

File 'gcov_test.c'
Lines executed:100.00% of 11
Branches executed:100.00% of 2
Taken at least once:100.00% of 2
Calls executed:100.00% of 5
Creating 'gcov_test.c.gcov'

Note the "No branches" and "No calls" output. With gcc/gcov 7.4 (and older),
the output looks like this:

Function 'main'
Lines executed:100.00% of 5
No branches
Calls executed:100.00% of 3

Function 'foo'
Lines executed:100.00% of 6
Branches executed:100.00% of 2
Taken at least once:100.00% of 2
Calls executed:100.00% of 2

File 'gcov_test.c'
Lines executed:100.00% of 11
Branches executed:100.00% of 2
Taken at least once:100.00% of 2
Calls executed:100.00% of 5
Creating 'gcov_test.c.gcov'

[Bug tree-optimization/88713] Vectorized code slow vs. flang

[elrodc at gmail dot com]

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

--- Comment #28 from Chris Elrod  ---
Created attachment 45501
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45501=edit
Minimum working example of the rsqrt problem. Can be compiled with: gcc -Ofast
-S -march=skylake-avx512 -mprefer-vector-width=512 -shared -fPIC rsqrt.c -o
rsqrt.s

I attached a minimum working example, demonstrating the problem of excessive
code generation for reciprocal square root, in the file rsqrt.c.
You can compile with:

gcc -Ofast -S -march=skylake-avx512 -mprefer-vector-width=512 -shared -fPIC
rsqrt.c -o rsqrt.s

clang -Ofast -S -march=skylake-avx512 -mprefer-vector-width=512 -shared -fPIC
rsqrt.c -o rsqrt.s

Or compare the asm of both on Godbolt: https://godbolt.org/z/c7Z0En

For gcc:

vmovups (%rsi), %zmm0
vxorps  %xmm1, %xmm1, %xmm1
vcmpps  $4, %zmm0, %zmm1, %k1
vrsqrt14ps  %zmm0, %zmm1{%k1}{z}
vmulps  %zmm0, %zmm1, %zmm2
vmulps  %zmm1, %zmm2, %zmm0
vmulps  .LC1(%rip), %zmm2, %zmm2
vaddps  .LC0(%rip), %zmm0, %zmm0
vmulps  %zmm2, %zmm0, %zmm0
vrcp14ps%zmm0, %zmm1
vmulps  %zmm0, %zmm1, %zmm0
vmulps  %zmm0, %zmm1, %zmm0
vaddps  %zmm1, %zmm1, %zmm1
vsubps  %zmm0, %zmm1, %zmm0
vmovups %zmm0, (%rdi)

for Clang:

vmovups (%rsi), %zmm0
vrsqrt14ps  %zmm0, %zmm1
vmulps  %zmm1, %zmm0, %zmm0
vfmadd213ps .LCPI0_0(%rip){1to16}, %zmm1, %zmm0 # zmm0 = (zmm1 *
zmm0) + mem
vmulps  .LCPI0_1(%rip){1to16}, %zmm1, %zmm1
vmulps  %zmm0, %zmm1, %zmm0
vmovups %zmm0, (%rdi)

Clang looks like it is is doing
 /* rsqrt(a) = -0.5 * rsqrtss(a) * (a * rsqrtss(a) * rsqrtss(a) - 3.0)
*/

where .LCPI0_0(%rip) = -3.0 and LCPI0_1(%rip) = -0.5.
gcc is doing much more, and fairly different.

[Bug libstdc++/88999] New: [9 Regression] testcases using in_avail() fail on nios2-elf

[sandra at gcc dot gnu.org]

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

Bug ID: 88999
   Summary: [9 Regression] testcases using in_avail() fail on
nios2-elf
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

I'm seeing some libstdc++ test regressions on nios2-elf testing on mainline. 
The symptoms are assertion failures about the results of calls to in_avail().

# Assertion 'strmsz_1 > strmsz_2' failed.
FAIL: 27_io/basic_filebuf/sgetn/char/1-in.cc execution test
FAIL: 27_io/basic_filebuf/sgetn/char/1-io.cc execution test
FAIL: 27_io/basic_filebuf/sgetn/char/2-in.cc execution test
FAIL: 27_io/basic_filebuf/sgetn/char/2-io.cc execution test

# Assertion 'i != 0' failed.
FAIL: 27_io/basic_istream/readsome/char/6746-2.cc execution test
FAIL: 27_io/basic_istream/readsome/wchar_t/6746-2.cc execution test

I see that these tests are xfailed for bare-metal ARM targets with a note that
ARM semihosting doesn't support the underlying fstat call, but that is not true
of nios2.  These tests all passed on nios2-elf with GCC 8.

I realize it is hard for other people to test this target, but I'd be happy to
test a patch or do some debugging to try to track it down given some clues
about where to look.  (Maybe this failure rings a bell with someone already
familiar with the code?)

[Bug c++/88998] New: bad codegen with mmx instructions for unordered_map

[barry.revzin at gmail dot com]

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

Bug ID: 88998
   Summary: bad codegen with mmx instructions for unordered_map
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

This program should be valid:

#include 
#include 
#include 

[[gnu::noinline]]
double prepare(int a, int b)
{
__m128i is = _mm_setr_epi32(a, b, 0, 0);
__m128d ds =_mm_cvtepi32_pd(is);
return ds[0] + ds[1];
}

int main(int, char**) {
double d = prepare(1, 2);

std::unordered_map m;
m.insert({0, 0});
m.insert({1, 1});
assert(m.load_factor() <= m.max_load_factor());

return d;
}


But if I use MMX instructions, the assertion triggers:

$ g++ -std=c++11 -march=haswell -mtune=haswell -mavx -O3 foo.cxx && ./a.out
a.out: foo.cxx:19: int main(int, char**): Assertion `m.load_factor() <=
m.max_load_factor()' failed.
Aborted (core dumped)

Whereas it does not if I explicitly remove them:

$ g++ -std=c++11 -march=haswell -mtune=haswell -mavx -mno-mmx -O3 foo.cxx &&
./a.out
$ 

Additionally, adding a call to _mm_empty() right before the return statement in
prepare() fixes the issue. 

If you look at the load_factor(), it returns 2 (and then 3 on the next insert,
etc.)

[Bug libstdc++/88996] Implement P0439R0 - Make std::memory_order a scoped enumeration.

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
+  inline constexpr memory_order
+  operator&(memory_order __m1, memory_order __m2)
+  { return memory_order(int(__m1) & int(__m2)); }
+
+  inline constexpr memory_order
+  operator|(memory_order __m1, memory_order __m2)
+  { return memory_order(int(__m1) | int(__m2)); }

What are these operators for? One of the main points of P0439 was that this
isn't a bitmask type, and combining the values doesn't make sense. Quoting the
paper:

> a scoped enumeration is more strongly typed, disallowing implicit
> conversion to integers, and preventing nonsensical expressions such as
> memory_order_acquire|memory_order_release (which could be mistakenly
> assumed to be equivalent to memory_order_acq_rel) or ~memory_order_relaxed.

[Bug c++/88997] New: Implicit constructors created with line numbers

[jg at jguk dot org]

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

Bug ID: 88997
   Summary: Implicit constructors created with line numbers
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Created attachment 45500
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45500=edit
test case

Hello

Could the implicit copy constructor be created with line numbers? Maybe also
source code saved as a temp file?

Or alternatively the struct could be used (example output below)

Test case attached. It is clearer to know which variable the runtime error
relates

e.g. expected output something like:

$ ./undef
undef.cpp:9:10: runtime error: load of value 112, which is not a valid value
for type 'bool'
undef.cpp:10:10: runtime error: load of value 102, which is not a valid value
for type 'bool'
undef.cpp:11:10: runtime error: load of value 172, which is not a valid value
for type 'bool'



Actual output:

$ export UBSAN_OPTIONS=print_stacktrace=1

$ ./undef
undef.cpp:6:16: runtime error: load of value 112, which is not a valid value
for type 'bool'
#0 0x55e6f8f5fa63 in testt::testt(testt const&)
/home/jonny/code/sanitize_undefined/undef.cpp:6
#1 0x55e6f8f5fd85 in void __gnu_cxx::new_allocator::construct(testt*, testt const&) /usr/include/c++/8/ext/new_allocator.h:136
#2 0x55e6f8f5e911 in void std::allocator_traits
>::construct(std::allocator&, testt*, testt const&)
/usr/include/c++/8/bits/alloc_traits.h:475
#3 0x55e6f8f5eecc in void std::vector
>::_M_realloc_insert(__gnu_cxx::__normal_iterator > >, testt const&)
/usr/include/c++/8/bits/vector.tcc:436
#4 0x55e6f8f5e551 in std::vector
>::push_back(testt const&) /usr/include/c++/8/bits/stl_vector.h:1085
#5 0x55e6f8f5dd97 in main /home/jonny/code/sanitize_undefined/undef.cpp:18
#6 0x7fcbbf157b96 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#7 0x55e6f8f5dc09 in _start
(/home/jonny/code/sanitize_undefined/undef+0x7c09)

undef.cpp:6:16: runtime error: load of value 76, which is not a valid value for
type 'bool'
#0 0x55e6f8f5fb61 in testt::testt(testt const&)
/home/jonny/code/sanitize_undefined/undef.cpp:6
#1 0x55e6f8f5fd85 in void __gnu_cxx::new_allocator::construct(testt*, testt const&) /usr/include/c++/8/ext/new_allocator.h:136
#2 0x55e6f8f5e911 in void std::allocator_traits
>::construct(std::allocator&, testt*, testt const&)
/usr/include/c++/8/bits/alloc_traits.h:475
#3 0x55e6f8f5eecc in void std::vector
>::_M_realloc_insert(__gnu_cxx::__normal_iterator > >, testt const&)
/usr/include/c++/8/bits/vector.tcc:436
#4 0x55e6f8f5e551 in std::vector
>::push_back(testt const&) /usr/include/c++/8/bits/stl_vector.h:1085
#5 0x55e6f8f5dd97 in main /home/jonny/code/sanitize_undefined/undef.cpp:18
#6 0x7fcbbf157b96 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#7 0x55e6f8f5dc09 in _start
(/home/jonny/code/sanitize_undefined/undef+0x7c09)

undef.cpp:6:16: runtime error: load of value 22, which is not a valid value for
type 'bool'
#0 0x55e6f8f5fc64 in testt::testt(testt const&)
/home/jonny/code/sanitize_undefined/undef.cpp:6
#1 0x55e6f8f5fd85 in void __gnu_cxx::new_allocator::construct(testt*, testt const&) /usr/include/c++/8/ext/new_allocator.h:136
#2 0x55e6f8f5e911 in void std::allocator_traits
>::construct(std::allocator&, testt*, testt const&)
/usr/include/c++/8/bits/alloc_traits.h:475
#3 0x55e6f8f5eecc in void std::vector
>::_M_realloc_insert(__gnu_cxx::__normal_iterator > >, testt const&)
/usr/include/c++/8/bits/vector.tcc:436
#4 0x55e6f8f5e551 in std::vector
>::push_back(testt const&) /usr/include/c++/8/bits/stl_vector.h:1085
#5 0x55e6f8f5dd97 in main /home/jonny/code/sanitize_undefined/undef.cpp:18
#6 0x7fcbbf157b96 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#7 0x55e6f8f5dc09 in _start
(/home/jonny/code/sanitize_undefined/undef+0x7c09)

[Bug libstdc++/88996] Implement P0439R0 - Make std::memory_order a scoped enumeration.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-22
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
The ABI says the mangling is the same for scoped and unscoped enumeration
types. There are some corner cases with decltype expressions in function
template declarations, where the enumerator names show up, but I don't expect
them to happen in real code.

I'm not sure if we want to do this for older standards though, it wasn't a DR.

[Bug c/88993] GCC 9 -Wformat-overflow=2 should reflect real libc limits

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #2 from Martin Sebor  ---
Quoting my response in a private discussion:

The warning was prompted by a limitation in Glibc(*) where its sprintf would
fail for some directives that produced more output than 4k.  I don't know if
any other implementations have similar limitations and the warning doesn't try
to adjust to specific implementations.

The warning is handled by a pass that both detects possible bugs and optimizes
calls to formatted I/O functions.  GCC needs to avoid optimizing results of
calls to these functions on the assumption that the library calls succeed under
these conditions.  So the warning is both a reminder that the code may be
unportable (i.e., it could fail and result in unexpected truncation of output)
and less efficient.  This is more relevant to the string I/O functions like
sprintf than to file I/O where output truncation may happen under all sorts of
conditions, and that GCC doesn't for the most part attempt to optimize.

At the same time, level 2 of the -Wformat-overflow warning is designed to be
strict even at the cost of some false positives.  When the warning doesn't know
whether a call is safe, at level 2 it errs on the side of caution and triggers.
 There are many other cases when the warning is issued even for safe code, so
this one doesn't seem any worse to me.  But if it is causing hardship (e.g.,
too many instances) we might want to think about adjusting it somehow.  (For
instance, we could limit the warning to the string formatting functions and
avoid issuing it for printf/fprintf; or we could only issue it when -Wpedantic
is also specified; or we could add a new warning, say -Wportability, for these
kinds of problems.)

The Glibc limitation/bug still exists in current versions:

  https://bugzilla.redhat.com/show_bug.cgi?id=441945
  https://sourceware.org/bugzilla/show_bug.cgi?id=21127

It affects directives that produce lots of output, usually because of very
large width or precision.  In very simple tests the threshold where it starts
to dynamically allocate memory is around 64k, like in this call:

  snprintf (0, 0, "%.65505i", 1);

or this one:

  snprintf (0, 0, "%65505s", "");

Depending on when malloc fails, either the call fails or crashes.

[Bug tree-optimization/88916] [x86] suboptimal code generated for integer comparisons joined with boolean operators

[wojciech_mula at poczta dot onet.pl]

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

--- Comment #3 from Wojciech Mula  ---
A similar case:

---sign.c---
int different_sign(long a, long b) {
return (a >= 0 && b < 0) || (a < 0 && b >= 0);
}
---eof--

This is compiled into:

different_sign:
notq%rdi
movq%rdi, %rax
notq%rsi
shrq$63, %rax
shrq$63, %rsi
xorl%esi, %eax
movzbl  %al, %eax
ret

When expressed as difference of the sign bits

((unsigned long)a ^ (unsigned long)b) >> 63

the code is way shorter:

different_sign:
xorq%rsi, %rdi
movq%rdi, %rax
shrq$63, %rax

BTW, I looked at ARM assembly, and GCC also emits
two shifts, so the observed behaviour is not limited
by a target.

[Bug d/88989] ICE in resolvePropertiesX, at d/dmd/expression.c:251

[ibuclaw at gdcproject dot org]

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

--- Comment #2 from Iain Buclaw  ---
I thought that the test case looked familiar.

https://issues.dlang.org/show_bug.cgi?id=18057

I had fixed this before in the D implementation branch.

[Bug target/88965] powerpc64le vector builtin hits ICE in verify_gimple

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug middle-end/88968] [8 Regression] Stack overflow in gimplify_expr

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9 Regression] Stack  |[8 Regression] Stack
   |overflow in gimplify_expr   |overflow in gimplify_expr

--- Comment #6 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/88965] powerpc64le vector builtin hits ICE in verify_gimple

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 22 22:30:44 2019
New Revision: 268166

URL: https://gcc.gnu.org/viewcvs?rev=268166=gcc=rev
Log:
PR target/88965
* config/rs6000/rs6000.c: Include tree-vrp.h and tree-ssanames.h.
(rs6000_gimple_fold_builtin): If MEM_REF address doesn't satisfy
is_gimple_mem_ref_addr predicate, force it into a SSA_NAME first.

* gcc.target/powerpc/pr88965.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr88965.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/88968] [8/9 Regression] Stack overflow in gimplify_expr

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 22 22:28:42 2019
New Revision: 268165

URL: https://gcc.gnu.org/viewcvs?rev=268165=gcc=rev
Log:
PR middle-end/88968
* gimplify.c (gimplify_omp_atomic): Handle bitfield atomics with
non-integral DECL_BIT_FIELD_REPRESENTATIVEs.

* c-omp.c (c_finish_omp_atomic): For bitfield atomics, update type
variable after using BIT_FIELD_REF.

* c-c++-common/gomp/atomic-23.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/gomp/atomic-23.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-omp.c
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug target/87064] [9 regression] libgomp.oacc-fortran/reduction-3.f90 fails starting with r263751

[jakub at gcc dot gnu.org]

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

--- Comment #24 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 22 22:27:32 2019
New Revision: 268164

URL: https://gcc.gnu.org/viewcvs?rev=268164=gcc=rev
Log:
PR target/87064
* config/rs6000/vsx.md (*vsx_reduc__v2df_scalar):
Disable for little endian.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/vsx.md

[Bug c++/88995] [8/9 Regression] internal compiler error: in lookup_template_class_1, at cp/pt.c:9471

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Known to work||8.2.0
   Target Milestone|--- |8.3

[Bug libstdc++/88996] Implement P0439R0 - Make std::memory_order a scoped enumeration.

[emsr at gcc dot gnu.org]

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

--- Comment #2 from emsr at gcc dot gnu.org ---
Still testing BTW.

[Bug libstdc++/88996] Implement P0439R0 - Make std::memory_order a scoped enumeration.

[emsr at gcc dot gnu.org]

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

emsr at gcc dot gnu.org changed:

   What|Removed |Added

 CC||emsr at gcc dot gnu.org

--- Comment #1 from emsr at gcc dot gnu.org ---
Created attachment 45499
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45499=edit
Patch that just does the thing for C++11 onwards.

I did

ed@bad-horse:~/bin$ nm  lib64/libstdc++.so | grep memory_order
000a9120 T _ZNSt9__atomic011atomic_flag12test_and_setESt12memory_order
000a9170 T _ZNSt9__atomic011atomic_flag5clearESt12memory_order
000a9120 T
_ZNVSt9__atomic011atomic_flag12test_and_setESt12memory_order@@GLIBCXX_3.4.11

and

ed@bad-horse:~/bin$ nm  lib32/libstdc++.so | grep memory_order
0008ae00 T _ZNSt9__atomic011atomic_flag12test_and_setESt12memory_order
0008ae70 T _ZNSt9__atomic011atomic_flag5clearESt12memory_order
0008ae00 T
_ZNVSt9__atomic011atomic_flag12test_and_setESt12memory_order@@GLIBCXX_3.4.11
0008ae70 T _ZNVSt9__atomic011atomic_flag5clearESt12memory_order@@GLIBCXX_3.4.11

on x96_64-linux.

This is what all teh abi files have.
We'll need to check this on all the targets.

[Bug target/88981] [nvptx, openacc, libgomp] How to handle async regions without corresponding wait

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
Thomas,

any comments to add from OpenACC perspective? What is correct or desirable
behaviour?

Thanks,
- Tom

[Bug libstdc++/88996] New: Implement P0439R0 - Make std::memory_order a scoped enumeration.

[emsr at gcc dot gnu.org]

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

Bug ID: 88996
   Summary: Implement P0439R0 - Make std::memory_order a scoped
enumeration.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: emsr at gcc dot gnu.org
  Target Milestone: ---

Basically make memory_order an enum class and make constexpr aliases to teh old
names.
Without breaking ABI.

[Bug c++/88995] New: [8/9 Regression] internal compiler error: in lookup_template_class_1, at cp/pt.c:9471

[hjl.tools at gmail dot com]

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

Bug ID: 88995
   Summary: [8/9 Regression] internal compiler error: in
lookup_template_class_1, at cp/pt.c:9471
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: nathan at gcc dot gnu.org
  Target Milestone: ---

On gcc-8-branch, r268029 caused

/builddir/build/BUILD/dldt-2018_R3/inference-engine/thirdparty/mkl-dnn/src/cpu/simple_reorder.hpp:1393:67:
internal compiler error: in lookup_template_class_1, at cp/pt.c:9471
0xad14be lookup_template_class_1
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:9471
0xad2db0 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:9683
0xadf026 tsubst_aggr_type
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:12686
0xaee57b tsubst_copy
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:15462
0xb0308c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:19060
0xafce36 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:17756
0xae73dc tsubst_decl
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:13779
0xaee8a2 tsubst_copy
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:15507
0xb0423b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:19259
0xafe978 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:18169
0xaff5d9 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:18348
0xaff9f8 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:18381
0xaff633 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:18349
0xaff5d9 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:18348
0xafce36 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:17756
0xaeddf0 tsubst_init
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:15350
0xaf7052 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:16997
0xaf5eca tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:16862
0xaf7366 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:17027
0xaf5eca tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:16862
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I am working on a smaller testcase.

[Bug fortran/88579] Calculating power of powers of two

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Jan 22 21:23:57 2019
New Revision: 268163

URL: https://gcc.gnu.org/viewcvs?rev=268163=gcc=rev
Log:
2019-01-22  Harald Anlauf  

PR fortran/88579
* trans-expr.c (gfc_conv_power_op): Handle cases of (2**e) ** integer
and (- 2**e) ** integer.

2019-01-22  Harald Anlauf  

PR fortran/88579
* gfortran.dg/power_8.f90: New test.


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

[Bug fortran/57553] [F08] Valid use of STORAGE_SIZE rejected, bad error message for invalid use

[anlauf at gmx dot de]

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

--- Comment #7 from Harald Anlauf  ---
Patch submitted for review:

https://gcc.gnu.org/ml/fortran/2019-01/msg00201.html

[Bug gcov-profile/88994] New: [GCOV] encoding (or unicode) error with gcov/gcc9 when generating filename

[moussu.robin at pm dot me]

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

Bug ID: 88994
   Summary: [GCOV] encoding (or unicode) error with gcov/gcc9 when
generating filename
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: moussu.robin at pm dot me
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Hello,

I filled first a bug on gcovr bug-tracker, and they eventually redirected me
here.

https://github.com/gcovr/gcovr/issues/292

All steps to reproduce the bug (and a lot of details on the output of the
various commands I run is present on the above link.

gcov is trying to create a filename with an extremely strange name: '
pn+\x89\x7f' (with a leading space, and invalid unicode sequence).

Here is a sum-up of what I think is relevant to gcov. Fell free to ask me any
additional details.

```
➜  $ gcov --version
gcov (GCC) 9.0.0 20190107 (experimental)
➜  $ gcc --version
gcc (GCC) 9.0.0 20190107 (experimental)

➜  $ locale
LANG=fr_FR.UTF-8
LC_CTYPE=fr_FR.UTF-8
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=
```

```
➜  $ gcov
/home/robin/dev/meson-sample-project/build/third_party/src/baz/6798489@@baz@sta/baz.cc.gcno
--branch-counts --branch-probabilities --preserve-paths --object-directory
/home/robin/dev/meson-sample-project/build/third_party/src/baz/6798489@@baz@sta
/home/robin/dev/meson-sample-project/build/third_party/src/baz/6798489@@baz@sta/baz.cc.gcda:
ne peut ouvrir le fichier de données, supposé non exécuté
File « ../third_party/src/baz/baz.cc »
Lignes exécutées: 0.00% sur 1
Pas de branchement
Pas d'appel
Impossible d'ouvrir le fichier de sortie «  »

File « /usr/include/c++/9.0.0/iostream »
Aucune ligne exécutable
Pas de branchement
Pas d'appel
Suppression de «  »
```

Notice the difference when I'm using `LANG=C` in the filename.

```
➜  $ LANG=C gcov
/home/robin/dev/meson-sample-project/build/third_party/src/baz/6798489@@baz@sta/baz.cc.gcno
--branch-counts --branch-probabilities --preserve-paths --object-directory
/home/robin/dev/meson-sample-project/build/third_party/src/baz/6798489@@baz@sta
/home/robin/dev/meson-sample-project/build/third_party/src/baz/6798489@@baz@sta/baz.cc.gcda:cannot
open data file, assuming not executed
File '../third_party/src/baz/baz.cc'
Lines executed:0.00% of 1
No branches
No calls
Creating '@�ٮ'
Cannot open source file ../third_party/src/baz/baz.cc

File '/usr/include/c++/9.0.0/iostream'
No executable lines
No branches
No calls
Removing '�ٮ'
```

[Bug c++/87999] Constexpr eval. in static_assert makes string_view comparison non constexpr

[wieichdashasse at gmail dot com]

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

Justin Meyer  changed:

   What|Removed |Added

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

--- Comment #2 from Justin Meyer  ---
This seems to be fixed in trunk. can't seem to find the commit that fixed it
though.

[Bug c/88993] GCC 9 -Wformat-overflow=2 should reflect real libc limits

[rjones at redhat dot com]

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

--- Comment #1 from Richard W.M. Jones  ---
Sorry, forgot the version.  It's:

gcc-9.0.0-0.3.fc30.x86_64

[Bug c/88993] New: GCC 9 -Wformat-overflow=2 should reflect real libc limits

[rjones at redhat dot com]

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

Bug ID: 88993
   Summary: GCC 9 -Wformat-overflow=2 should reflect real libc
limits
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rjones at redhat dot com
  Target Milestone: ---

-Wformat-overflow=2 is the default when using gnulib manywarnings.m4, and
so is used by a bunch of GNU projects.  I've found with GCC 9 it is very
aggressive warning about any string it statically determine could be
longer than 4095 characters (see
https://stackoverflow.com/questions/8119914/printf-fprintf-maximum-size-according-to-c99?rq=1
for the presumed origin of that limit).

I am using a libc which does not have such a small limit (in fact, I believe
it's unlimited) and I think this warning should warn about the real
toolchain limit, not some peculiar corner of the C99 standard that vanishingly
small number of libcs are really limited by (and if they are - fix your libc).

Example below:

#include 
#include 
#include 

int
main (void)
{
  char s[4097];

  fgets (s, sizeof s, stdin);
  printf ("%.*s", (int) strlen (s), s);

//test.c:11:12: warning: ‘%.*s’ directive output between 0 and 4096 bytes may
exceed minimum required size of 4095 [-Wformat-overflow=]
//   11 |   printf ("%.*s", (int) strlen (s), s);
//  |^~~~ ~

  printf ("%s", s);

//test.c:12:12: warning: ‘%s’ directive output between 0 and 4096 bytes may
exceed minimum required size of 4095 [-Wformat-overflow=]
//   12 |   printf ("%s", s);
//  |^~   ~

  exit (0);
}

[Bug target/88497] Improve Accumulation in Auto-Vectorized Code

[kelvin at gcc dot gnu.org]

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

--- Comment #7 from kelvin at gcc dot gnu.org ---
Here is the original program that motivated my simplified reproducer:

extern void first_dummy ();
extern void dummy (double sacc, int n);
extern void other_dummy ();

extern float opt_value;
extern char *opt_desc;

#define M 128
#define N 512

double x [N];
double y [N];

int main (int argc, char *argv []) {
  double sacc;

  first_dummy ();
  for (int j = 0; j < M; j++) {

sacc = 0.00;
for (unsigned long long int i = 0; i < N; i++) {
  sacc += x[i] * y[i];
}
dummy (sacc, N);
  }
  opt_value = ((float) N) * 2 * ((float) M);
  opt_desc = "flops";
  other_dummy ();
}

[Bug d/88989] ICE in resolvePropertiesX, at d/dmd/expression.c:251

[ibuclaw at gdcproject dot org]

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

--- Comment #1 from Iain Buclaw  ---
Thanks.

Out of curiosity, are you fuzz testing?

[Bug rtl-optimization/88347] ICE in begin_move_insn, at sched-ebb.c:175

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Segher's fix appears superior to mine; am testing it now...

[Bug target/88963] gcc generates terrible code for vectors of 64+ length which are not natively supported

[husseydevin at gmail dot com]

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

--- Comment #10 from Devin Hussey  ---
I also want to add that aarch64 shouldn't even be spilling; it has 32 NEON
registers and with 128 byte vectors it should only use 24.

[Bug c++/88984] [9 Regression] ICE in genericize_switch_stmt, at cp/cp-gimplify.c:377

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 45498
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45498=edit
gcc9-pr88984.patch

Untested fix.

[Bug rtl-optimization/88347] ICE in begin_move_insn, at sched-ebb.c:175

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
*** Bug 88423 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/88423] [9 Regression] ICE in begin_move_insn, at sched-ebb.c:175

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from David Malcolm  ---
(In reply to Segher Boessenkool from comment #6)
> Is this a dup of PR88347?

Looks like it, and your fix there looks better (it fixes both).  I'm trying a
bootstrap of your fix.

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

[Bug middle-end/88991] missing warning on a strcpy and strlen from a zero-length array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||88443

--- Comment #2 from Martin Sebor  ---
The most appropriate warning in all these cases is probably -Wstringop-overflow
rather than -Warray-bounds, since the former is meant to diagnose both writing
and reading past the end of an array by string functions.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[Bug middle-end/88992] New: missing -Warray-bounds indexing into a zero-length array

[msebor at gcc dot gnu.org]

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

Bug ID: 88992
   Summary: missing -Warray-bounds indexing into a zero-length
array
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Also while adding a test for the fix for bug 88956 I noticed that GCC doesn't
diagnose indexing into zero-length arrays.  The out-of-bounds accesses to the
global zero-length arrays are folded to zero while those to the local ones are
emitted.

$ gcc -O2 -S -Wall t.c
const char s1[1] = { };
int f1 (void)
{
  return s1[3];   // -Warray-bounds (good)
}

const char s0[0] = { };
int f0 (void)
{
  return s0[3];   // missing warning
}


int g1 (void)
{
  const char s1[1] = { };
  return s1[3];   // -Warray-bounds (good)
}

int g0 (void)
{
  const char s0[0] = { };
  return s0[3];   // missing warning
}

t.c: In function ‘f1’:
t.c:4:12: warning: array subscript 3 is above array bounds of ‘const char[1]’
[-Warray-bounds]
4 |   return s1[3];   // -Warray-bounds (good)
  |  ~~^~~
t.c:1:12: note: while referencing ‘s1’
1 | const char s1[1] = { };
  |^~
t.c: In function ‘g1’:
t.c:17:12: warning: array subscript 3 is above array bounds of ‘const char[1]’
[-Warray-bounds]
   17 |   return s1[3];   // -Warray-bounds (good)
  |  ~~^~~
t.c:16:14: note: while referencing ‘s1’
   16 |   const char s1[1] = { };
  |  ^~

[Bug c++/88979] [C++20] P0634R3 not working for constructor parameter types

[19Sebastian95 at gmx dot de]

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

--- Comment #2 from 19Sebastian95 at gmx dot de ---
I'm sorry if I'm misinterpreting this, but the program I wrote does compile
with gcc 9.0, as the "error" part is commented out, so I'll just write what to
do to get the descriped error: 

If my constructor is:

A(typename T::type a) : mA{a} {} 

it is working, but if I remove the typename it'll give me The "error: expected
')' before 'a'" error. (As far as I know it should detect that it is only a
missing typename, so for versions before c++20 it should be "error: need
'typename' [...]" and for c++20 it shouldn't be an error).

So right now this won't compile:
A(T::type a) : mA{a} {} 

But if I'd define the constructor out-of-line it won't give me an error:

template
A::A(T::type a) : mA{a} {} 

As GCC is detecting that there can only be a type at this position, which it
doesn't with the "header-only"-version.

I hope this will help.

[Bug middle-end/88991] missing warning on a strcpy and strlen from a zero-length array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=88956

--- Comment #1 from Martin Sebor  ---
This was noticed while adding a test case for the fix for bug 88956.

[Bug middle-end/88991] New: missing warning on a strcpy and strlen from a zero-length array

[msebor at gcc dot gnu.org]

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

Bug ID: 88991
   Summary: missing warning on a strcpy and strlen from a
zero-length array
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC diagnoses the undefined behavior in function f() in the test case below but
fails to diagnose the same bug in g() or h().

However, the warning issued for f() should be (also) for the call to strlen(s)
which is also undefined.  Worse, in g() neither the call to strlen(s) nor
memcpy() is diagnosed.

$ cat t.c && gcc -O2 -S -Wall t.c

void f (char *d)
{
  __builtin_memcpy (d, s, __builtin_strlen (s) + 1);
}

void g (char *d)
{
  unsigned n = __builtin_strlen (s) + 1;   // missing warning
  __builtin_memcpy (d, s, n);  // same here
}

void h (char *d)
{
  __builtin_strcpy (d, s); // missing warning here too
}
t.c: In function ‘f’:
t.c:5:3: warning: ‘__builtin_memcpy’ forming offset [1, 9223372036854775805] is
out of the bounds [0, 0] of object ‘s’ with type ‘const char[]’
[-Warray-bounds]
5 |   __builtin_memcpy (d, s, __builtin_strlen (s) + 1);
  |   ^
t.c:1:12: note: ‘s’ declared here
1 | const char s[0] = { };
  |^

[Bug c++/88967] [9 regression] openmp default(none) broken

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
firstprivate is that each thread will have its own copy of the variable,
initialized from the original.
shared means there is just one copy.
E.g. if you take the address of the variable within the region, for
firstprivate each thread will have different, typically it will be a stack slot
in the outlined function, while for shared it will need to live either in the
structure used to pass data around, or worse address of that variable will be
passed in that structure.  While e.g. some recent versions of gcc try to
optimize
certain cases of shared into firstprivate, see e.g. PR68128 (or for
non-addressable non-reference const vars it was done even much earlier), that
is just an optimization not every compiler will do for you.

[Bug target/88469] [7/8 regression] AAPCS - Struct with 64-bit bitfield may be passed in wrong registers

[rearnsha at gcc dot gnu.org]

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

--- Comment #8 from Richard Earnshaw  ---
Author: rearnsha
Date: Tue Jan 22 17:56:02 2019
New Revision: 268160

URL: https://gcc.gnu.org/viewcvs?rev=268160=gcc=rev
Log:
[arm] Further fixes for PR88469

A bitfield that is exactly the same size as an integral type and
naturally aligned will have DECL_BIT_FIELD cleared.  So we need to
check DECL_BIT_FIELD_TYPE to be sure whether or not the underlying
type was declared with a bitfield declaration.

I've also added a test for bitfields that are based on overaligned types.

PR target/88469
gcc:
* config/arm/arm.c (arm_needs_double_word_align): Check
DECL_BIT_FIELD_TYPE.

gcc/testsuite:
* gcc.target/arm/aapcs/bitfield2.c: New test.
* gcc.target/arm/aapcs/bitfield3.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/aapcs/bitfield2.c
trunk/gcc/testsuite/gcc.target/arm/aapcs/bitfield3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog

aGO提//供//税%%栗//

[hpefmjdkv]

gcc-bugs@gcc.gnu.org
+
氏瑚优 惠 办 理 正 规 税 票，认 证 后 付 款。
 详 电：李 生，136—6075— 4190，
 业 q：157— 533— 2698
---

[Bug fortran/39795] Support round-to-zero in Fortran front-end

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Dominique d'Humieres  ---
No feedback, closing as WONTFIX.

[Bug fortran/57297] FAIL: gfortran.dg/select_type_4.f90 -O2 execution test

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #12 from Dominique d'Humieres  ---
No feedback, closing as WORKSFORME.

[Bug fortran/80257] Cygwin test fail: pointer_check_1.f90 output test

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #6 from Dominique d'Humieres  ---
No feedback, closing as WORKSFORME.

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

[wilco at gcc dot gnu.org]

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

--- Comment #23 from Wilco  ---
Author: wilco
Date: Tue Jan 22 17:49:46 2019
New Revision: 268159

URL: https://gcc.gnu.org/viewcvs?rev=268159=gcc=rev
Log:
Fix vect-nop-move.c test

Fix a failing test - changes in Combine mean the test now fails
eventhough the generated code is the same.  Given there are several
AArch64-specific tests for vec-select, remove the scanning of Combine
output.  Committed as trivial fix.

testsuite/
PR rtl-optimization/87763
* gcc.dg/vect/vect-nop-move.c: Fix testcase on AArch64.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-nop-move.c

[Bug target/88981] [nvptx, openacc, libgomp] How to handle async regions without corresponding wait

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
A good thing to note here, when adding #pragma acc wait, the program (compiled
with -O0) takes ~10 seconds to finish on my quadro 1200m.

Without the pragma acc wait, it still takes 10 seconds.

When inspecting with a debugger where it's waiting (since there's no wait
reponsible for this), we're hanging on either cuMemFree or cuCtxDestroy.  I
can't find documentation of this hanging behaviour, so this behaviour may be
specific to the driver version or card or architecture.

[Bug d/88990] New: ICE in get_symbol_decl, at d/decl.cc:1097

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

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

Bug ID: 88990
   Summary: ICE in get_symbol_decl, at d/decl.cc:1097
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With an invalid qualifier :


$ cat z1.d
class A
{
  extern
  {
void f() { }
  }
}


$ gdc-9-20190120 -c z1.d
z1.d: In function 'f':
z1.d:1:1: internal compiler error: in get_symbol_decl, at d/decl.cc:1097
1 | class A
  | ^
0x777318 get_symbol_decl(Declaration*)
../../gcc/d/decl.cc:1097
0x77957d get_symbol_decl(Declaration*)
../../gcc/d/decl.cc:904
0x77957d DeclVisitor::visit(FuncDeclaration*)
../../gcc/d/decl.cc:798
0x7788b7 DeclVisitor::visit(AttribDeclaration*)
../../gcc/d/decl.cc:222
0x779b27 DeclVisitor::visit(ClassDeclaration*)
../../gcc/d/decl.cc:436
0x7765b1 build_decl_tree(Dsymbol*)
../../gcc/d/decl.cc:949
0x782a30 build_module_tree(Module*)
../../gcc/d/modules.cc:717
0x7789eb DeclVisitor::visit(Module*)
../../gcc/d/decl.cc:142
0x7765b1 build_decl_tree(Dsymbol*)
../../gcc/d/decl.cc:949
0x773990 d_parse_file()
../../gcc/d/d-lang.cc:1278

[Bug libstdc++/86164] std::regex crashes when matching long lines

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-22
 Ever confirmed|0   |1

[Bug d/88989] New: ICE in resolvePropertiesX, at d/dmd/expression.c:251

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

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

Bug ID: 88989
   Summary: ICE in resolvePropertiesX, at d/dmd/expression.c:251
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With following test :


$ cat z1.d
struct A
{
  int i = A();
};


$ gdc-9-20190120 -c z1.d
d21: internal compiler error: Segmentation fault
0xb821cf crash_signal
../../gcc/toplev.c:326
0x6ac417 resolvePropertiesX(Scope*, Expression*, Expression*)
../../gcc/d/dmd/expression.c:251
0x6ace7f resolveProperties(Scope*, Expression*)
../../gcc/d/dmd/expression.c:496
0x6b5490 preFunctionParameters
../../gcc/d/dmd/expressionsem.c:97
0x6c64ad preFunctionParameters
../../gcc/d/dmd/expressionsem.c:89
0x6c64ad ExpressionSemanticVisitor::visit(CallExp*)
../../gcc/d/dmd/expressionsem.c:2930
0x6b57a5 semantic(Expression*, Scope*)
../../gcc/d/dmd/expressionsem.c:8166
0x6e5b9d InitializerSemanticVisitor::visit(ExpInitializer*)
../../gcc/d/dmd/initsem.c:348
0x6e583b semantic(Initializer*, Scope*, Type*, NeedInterpret)
../../gcc/d/dmd/initsem.c:520
0x65c57c VarDeclaration::getConstInitializer(bool)
../../gcc/d/dmd/declaration.c:1966
0x683c46 AggregateDeclaration::fill(Loc, Array*, bool)
../../gcc/d/dmd/dstruct.c:726
0x6b8bf4 ExpressionSemanticVisitor::visit(StructLiteralExp*)
../../gcc/d/dmd/expressionsem.c:776
0x6c805b StructLiteralExp::accept(Visitor*)
../../gcc/d/dmd/expression.h:490
0x6c805b semantic(Expression*, Scope*)
../../gcc/d/dmd/expressionsem.c:8166
0x6c805b ExpressionSemanticVisitor::visit(CallExp*)
../../gcc/d/dmd/expressionsem.c:3006
0x6b57a5 semantic(Expression*, Scope*)
../../gcc/d/dmd/expressionsem.c:8166
0x6e5b9d InitializerSemanticVisitor::visit(ExpInitializer*)
../../gcc/d/dmd/initsem.c:348
0x6e583b semantic(Initializer*, Scope*, Type*, NeedInterpret)
../../gcc/d/dmd/initsem.c:520
0x659133 VarDeclaration::semantic2(Scope*)
../../gcc/d/dmd/declaration.c:1619
0x683187 AggregateDeclaration::semantic2(Scope*)
../../gcc/d/dmd/dstruct.c:267

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

[wilco at gcc dot gnu.org]

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

--- Comment #22 from Wilco  ---
(In reply to Steve Ellcey from comment #21)
> If I look at this specific example:
> 
> int f2 (int x, int y)
> {
>   return (x & ~0x0ff000) | ((y & 0x0ff) << 12);
> }
> 

> Is this because of x0 (a hard register) at the destination in insn 15?

Yes, the hard reg change affects the rtl shape in these tests so it fails to
match in combine. I have a simple fix for the tst_5 and tst_6 failures.

You can check this by ensuring there are no hard registers in the test:

int f2a (int x, int y)
{
   x++;
   y++;
   return (x & ~0x0ff000) | ((y & 0x0ff) << 12);
}

This also fails to match before r265398.

[Bug libstdc++/83754] Segmentation fault in regex_search

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-22
 Ever confirmed|0   |1

[Bug c/88985] New: [9 Regression] ICE in estimate_edge_devirt_benefit, at ipa-fnsummary.c:2585

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

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

Bug ID: 88985
   Summary: [9 Regression] ICE in estimate_edge_devirt_benefit, at
ipa-fnsummary.c:2585
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20180610 and 20180624, at -O0 on x86_64 GNU/Linux :


$ cat z1.c
void f (void)
{
}
__attribute__((__optimize__("O2")))
void g (void f())
{
  f();
}
__attribute__((__optimize__("O2")))
void h (void)
{
  g(f);
}


$ gcc-9-20180610 -c z1.c -O0
$
$ gcc-9-20190120 -c z1.c -O2
$
$ gcc-9-20190120 -c z1.c -O0
during IPA pass: inline
z1.c:13:1: internal compiler error: Segmentation fault
   13 | }
  | ^
0xa8afef crash_signal
../../gcc/toplev.c:326
0x8bb89e estimate_edge_devirt_benefit
../../gcc/ipa-fnsummary.c:2585
0x8be869 estimate_edge_size_and_time
../../gcc/ipa-fnsummary.c:2608
0x8be869 estimate_calls_size_and_time
../../gcc/ipa-fnsummary.c:2674
0x8bfc1b estimate_node_size_and_time(cgraph_node*, unsigned int, unsigned int,
vec, vec, vec, int*, int*, sreal*,
sreal*, int*, vec)
../../gcc/ipa-fnsummary.c:2733
0x8cce81 do_estimate_edge_size(cgraph_edge*)
../../gcc/ipa-inline-analysis.c:209
0x8cd14f estimate_edge_size
../../gcc/ipa-inline.h:75
0x8cd14f estimate_edge_growth
../../gcc/ipa-inline.h:86
0x8cd14f do_estimate_growth_1
../../gcc/ipa-inline-analysis.c:312
0x8cd1fe cgraph_node::call_for_symbol_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool)
../../gcc/cgraph.h:3241
0x8cd1fe estimate_growth(cgraph_node*)
../../gcc/ipa-inline-analysis.c:326
0x11f9758 inline_small_functions
../../gcc/ipa-inline.c:1792
0x11f9758 ipa_inline
../../gcc/ipa-inline.c:2528
0x11f9758 execute
../../gcc/ipa-inline.c:2936

[Bug c++/88987] New: [9 Regression] ICE: unexpected expression '(bool)sm' of kind implicit_conv_expr

[asolokha at gmx dot com]

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

Bug ID: 88987
   Summary: [9 Regression] ICE: unexpected expression '(bool)sm'
of kind implicit_conv_expr
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-9.0.0-alpha20190120 snapshot (r268107) ICEs when compiling the following
testcase:

int sm;

template  T
pk () noexcept (sm)
{
  return 0;
}

% g++-9.0.0-alpha20190120 -c b6bdwqbi.cpp
b6bdwqbi.cpp:4:17: error: the value of 'sm' is not usable in a constant
expression
4 | pk () noexcept (sm)
  | ^~
b6bdwqbi.cpp:1:5: note: 'int sm' is not const
1 | int sm;
  | ^~
b6bdwqbi.cpp:4:19: internal compiler error: unexpected expression '(bool)sm' of
kind implicit_conv_expr
4 | pk () noexcept (sm)
  |   ^
0x8cf4fb cxx_eval_constant_expression
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/constexpr.c:4983
0x8d2672 cxx_eval_outermost_constant_expr
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/constexpr.c:5095
0x93ed98 build_noexcept_spec(tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/except.c:1292
0x9b32c5 cp_parser_exception_specification_opt
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:25149
0x9acfca cp_parser_direct_declarator
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:20751
0x9acfca cp_parser_declarator
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:20582
0x9bb4ff cp_parser_init_declarator
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:20092
0x9bf6c4 cp_parser_single_declaration
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:28096
0x9bf82e cp_parser_template_declaration_after_parameters
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:27688
0x9c019e cp_parser_explicit_template_declaration
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:27934
0x9c019e cp_parser_template_declaration_after_export
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:27953
0x9c2d39 cp_parser_declaration
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:13122
0x9c33a0 cp_parser_translation_unit
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:4698
0x9c33a0 c_parse_file()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:41003
0xaccdab c_common_parse_file()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/c-family/c-opts.c:1155

[Bug c++/88986] New: [9 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in member_vec_binary_search, at cp/name-lookup.c:1136

[asolokha at gmx dot com]

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

Bug ID: 88986
   Summary: [9 Regression] ICE: tree check: expected tree that
contains 'decl minimal' structure, have 'error_mark'
in member_vec_binary_search, at cp/name-lookup.c:1136
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-9.0.0-alpha20190120 snapshot (r268107) ICEs when compiling the following
testcase extracted from test/SemaTemplate/cxx1z-using-declaration.cpp from the
clang 7.0.1 testsuite:

template struct C : T... {
  using typename T::type ...;
  void f() { type value; }
};

% g++-9.0.0-alpha20190120 -std=c++17 -c fw9hmgfi.cpp
fw9hmgfi.cpp:1:32: error: 'T ...' is not a class
1 | template struct C : T... {
  |^
fw9hmgfi.cpp:1:32: error: 'T ...' is not a class
fw9hmgfi.cpp: In member function 'void C::f()':
fw9hmgfi.cpp:3:12: internal compiler error: tree check: expected tree that
contains 'decl minimal' structure, have 'error_mark' in
member_vec_binary_search, at cp/name-lookup.c:1136
3 |   void f() { type value; }
  |^
0x7c442d tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/tree.c:9985
0x615e3d contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/tree.h:3290
0x615e3d member_vec_binary_search
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/name-lookup.c:1136
0x615e3d get_class_binding_direct(tree_node*, tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/name-lookup.c:1233
0xa1e9f6 lookup_field_r
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/search.c:980
0xa1dc7d dfs_walk_all(tree_node*, tree_node* (*)(tree_node*, void*), tree_node*
(*)(tree_node*, void*), void*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/search.c:1420
0xa1de56 lookup_member(tree_node*, tree_node*, int, bool, int,
access_failure_info*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/search.c:1137
0x96f9e5 get_class_binding
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/name-lookup.c:4449
0x97470f outer_binding(tree_node*, cxx_binding*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/name-lookup.c:6327
0x97495f innermost_non_namespace_value(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/name-lookup.c:6364
0x9ca857 check_template_shadow(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/pt.c:4135
0x97bc77 do_pushdecl
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/name-lookup.c:3072
0x97bc77 pushdecl(tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/name-lookup.c:3162
0x90234e store_parm_decls
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/decl.c:15640
0x90234e start_preparsed_function(tree_node*, tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/decl.c:15514
0x9bc36f cp_parser_late_parsing_for_member
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:28497
0x99aaf2 cp_parser_class_specifier_1
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:23509
0x99bb18 cp_parser_class_specifier
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:23535
0x99bb18 cp_parser_type_specifier
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:17356
0x99cad0 cp_parser_decl_specifier_seq
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:14049

[Bug c++/88988] New: [8/9 Regression] ICE: Segmentation fault (in lookup_name_real_1)

[asolokha at gmx dot com]

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

Bug ID: 88988
   Summary: [8/9 Regression] ICE: Segmentation fault (in
lookup_name_real_1)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, openmp
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-9.0.0-alpha20190120 snapshot (r268107) ICEs when compiling the following
testcase w/ -fopenmp:

template 
class k6 {
public:
  k6 () : y2 ()
  {
[&] ()
{
#pragma omp parallel firstprivate (y2)
  ++ (this)->y2;
} ();
  }

  T y2;
};

k6 v6;

% g++-9.0.0-alpha20190120 -fopenmp -c fsbqsi9o.cpp
fsbqsi9o.cpp: In instantiation of 'k6::k6() [with T = int]':
fsbqsi9o.cpp:16:9:   required from here
fsbqsi9o.cpp:8:39: internal compiler error: Segmentation fault
8 | #pragma omp parallel firstprivate (y2)
  |   ^
0xf9cc9f crash_signal
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/toplev.c:326
0x97af4c tree_check(tree_node*, char const*, int, char const*, tree_code)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/tree.h:3175
0x97af4c lookup_name_real_1
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/name-lookup.c:6395
0x97af4c lookup_name_real(tree_node*, int, int, bool, int, int)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/name-lookup.c:6529
0x9e1757 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/pt.c:16918
0x9ddfe7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/pt.c:16862
0x9de50e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/pt.c:17163
0x9ddfe7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/pt.c:16862
0x9de50e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/pt.c:17163
0x9f9d55 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/pt.c:16847
0x9f9d55 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/pt.c:18023
0x9e89c8 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/pt.c:19346
0x9e673f tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/pt.c:18640
0x9dcb5f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/pt.c:17756
0x9dcf9b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/pt.c:16876
0x9ddfe7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/pt.c:16862
0x9de50e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/pt.c:17163
0x9ddfe7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/pt.c:16862
0x9de50e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/pt.c:17163
0x9dc54e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/pt.c:16847

[Bug c++/88967] [9 regression] openmp default(none) broken

[lebedev.ri at gmail dot com]

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

--- Comment #9 from Roman Lebedev  ---
(In reply to Jakub Jelinek from comment #8)
> Well, in your case firstprivate is really what you want, unless the compiler
> figures that out for you magically you want to firstprivatize these
> variables.

Hm, i understand that this is going further off-topic, but can you
explain/point to some reading material as to why firstprivate() is the thing i
want,
instead of shared()? The variables are already const, i won't be modifying them
in any case. How is it better to make a copy of them for each thread, instead
of using the same single variable?

Perhaps that was the motivational reason for that OpenMP spec change,
and i'm missing something very subtle yet important?

Anyway, thank you for replying.

[Bug tree-optimization/84774] [meta-bug] bogus/missing -Wrestrict

[msebor at gcc dot gnu.org]

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

Bug 88973 Summary: [8/9 Regression] New -Wrestrict warning since r268048
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

[Bug tree-optimization/88973] [8/9 Regression] New -Wrestrict warning since r268048

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Martin Sebor  ---
I've created a test case using the canonicalize_pathname function showing that
it does, in fact, cause an overlap to take place.  The following line in the
output of the test case

  strcpy (0x217f265 = "//bar", 0x217f267 = "bar"): 3

shows that strcpy is being called to copy the 4 bytes "bar\0" from 0x217f267 to
0x217f265, with the last two bytes of the copy overlapping its first two bytes.

$ cat canonicalize_pathname.c && gcc -DPATHNAME='"/foo///bar"' -O2 -Wall
canonicalize_pathname.c && ./a.out
char*
strcpy (char *d, const char *s)
{
  unsigned n = __builtin_strlen (s);
  __builtin_printf ("%s (%p = \"%s\", %p = \"%s\"): %u\n",
__func__, d, d, s, s, n);
  __builtin_memcpy (d, s, n + 1);
  return d;
}

char *
canonicalize_pathname (char *path)
{
  int i, start;
  char stub_char, *result;

  result = __builtin_strdup( path );

  stub_char = (*path == '/') ? '/' : '.';

  i = 0;
  while (result[i]) {
while (result[i] != '\0' && result[i] != '/')
  i++;

start = i++;

if (!result[start])
  break;

while (result[i] == '/')
  i++;

if ((start + 1) != i)
  {
strcpy( result + start + 1, result + i );
i = start + 1;
  }

if (start > 0 && result[start - 1] == '\\')
  continue;

if ((start && !result[i])
|| (result[i] == '.' && !result[i+1])) {
  result[--i] = '\0';
  break;
}

if (result[i] == '.') {

  if (result[i + 1] == '/') {
strcpy( result + i, result + i + 1 );
i = (start < 0) ? 0 : start;
continue;
  }

  if (result[i + 1] == '.' &&
  (result[i + 2] == '/' || !result[i + 2])) {
while (--start > -1 && result[start] != '/')
  ;
strcpy( result + start + 1, result + i + 2 );
i = (start < 0) ? 0 : start;
continue;
  }
}
  }

  if (!*result) {
*result = stub_char;
result[1] = '\0';
  }

  return result;
}


int main (void)
{
  char *p = canonicalize_pathname (PATHNAME);
  __builtin_printf ("%s\n", p);
}
canonicalize_pathname.c: In function ‘canonicalize_pathname’:
canonicalize_pathname.c:61:2: warning: ‘strcpy’ accessing 1 byte at offsets [0,
9223372036854775807] and [0, 9223372036854775807] may overlap 1 byte at offset
0 [-Wrestrict]
   61 |  strcpy( result + start + 1, result + i + 2 );
  |  ^~~~
strcpy (0x217f265 = "//bar", 0x217f267 = "bar"): 3
/foo/bar

[Bug c++/88967] [9 regression] openmp default(none) broken

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Well, in your case firstprivate is really what you want, unless the compiler
figures that out for you magically you want to firstprivatize these variables. 
A different thing is of course if you have a large const aggregate, then it
might not be always a win.  But for an integral/pointer variable or similar, it
is definitely a win.

[Bug c++/88967] [9 regression] openmp default(none) broken

[lebedev.ri at gmail dot com]

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

--- Comment #7 from Roman Lebedev  ---
(In reply to Jakub Jelinek from comment #6)
> No, gcc always implements just one OpenMP version, the latest one that has
> support written.
E.g. because of this everyone affected will need to either just completely drop
"default(none)", or litter the code with "OMP4SHARED()" which will expand
to nothing for older gcc, and to "shared()" for gcc9.

That does look 'weird' too :)

> Defaulting to almost 8 years old OpenMP version is weird.

[Bug c++/88294] [9 Regression] ICE on (invalid) C++11 code: in tsubst_copy, at cp/pt.c:15391

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
I can try.  Unfortunately, the patch for 86476 doesn't fix this.

[Bug driver/88911] No "did you mean" for incorrect -dumpspecs option

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01311.html

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

[sje at gcc dot gnu.org]

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

--- Comment #21 from Steve Ellcey  ---
If I look at this specific example:

int f2 (int x, int y)
{
  return (x & ~0x0ff000) | ((y & 0x0ff) << 12);
}


Before the combine change, I see in x.c.260r.combine:

Trying 8, 9 -> 15:
8: r98:SI=x1:SI<<0xc&0xff000
  REG_DEAD x1:SI
9: r99:SI=x0:SI&0xfff00fff
  REG_DEAD x0:SI
   15: x0:SI=r98:SI|r99:SI
  REG_DEAD r98:SI
  REG_DEAD r99:SI
Successfully matched this instruction:
(set (zero_extract:SI (reg/i:SI 0 x0)
(const_int 8 [0x8])
(const_int 12 [0xc]))
(zero_extend:SI (reg:QI 1 x1 [ y ])))
allowing combination of insns 8, 9 and 15
original costs 4 + 4 + 4 = 12
replacement cost 4
deferring deletion of insn with uid = 9.


Immediately after the combine change, I get:

Trying 8, 9 -> 15:
8: r98:SI=r101:SI<<0xc&0xff000
  REG_DEAD r101:SI
9: r99:SI=r100:SI&0xfff00fff
  REG_DEAD r100:SI
   15: x0:SI=r98:SI|r99:SI
  REG_DEAD r98:SI
  REG_DEAD r99:SI
Failed to match this instruction:
(set (reg/i:SI 0 x0)
(ior:SI (and:SI (reg:SI 100)
(const_int -1044481 [0xfff00fff]))
(and:SI (ashift:SI (reg:SI 101)
(const_int 12 [0xc]))
(const_int 1044480 [0xff000]
Successfully matched this instruction:
(set (reg:SI 99)
(ashift:SI (reg:SI 101)
(const_int 12 [0xc])))
Failed to match this instruction:
(set (reg/i:SI 0 x0)
(ior:SI (and:SI (reg:SI 100)
(const_int -1044481 [0xfff00fff]))
(and:SI (reg:SI 99)
(const_int 1044480 [0xff000]


Is this because of x0 (a hard register) at the destination in insn 15?

[Bug c++/88967] [9 regression] openmp default(none) broken

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
No, gcc always implements just one OpenMP version, the latest one that has
support written.
Defaulting to almost 8 years old OpenMP version is weird.

[Bug c++/88979] [C++20] P0634R3 not working for constructor parameter types

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-01-22
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
I'll look though I'm not sure yet if there's an actual bug.  Is there a version
with 'typename's included that compiles?

[Bug tree-optimization/88973] [8/9 Regression] New -Wrestrict warning since r268048

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Created attachment 45497
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45497=edit
canonicalize_pathname function extracted from the translation unit.

Attached is the canonicalize_pathname function extracted from the translation
unit that triggers the -Wrestrict warning.

[Bug target/88909] struct builtin_description doesn't support ix86_isa_flags2

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
Fixed for GCC 9.

[Bug tree-optimization/88973] [8/9 Regression] New -Wrestrict warning since r268048

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||84774

--- Comment #2 from Martin Sebor  ---
I feel like I have seen this translation unit before.  The warning is by
design: for calls to strcpy with the same destination and source arrays, where
the algorithm cannot prove that an overlap doesn't occur it issues a "may
overlap" kind of a warning.  The offset ranges make it clear (to me at least)
that the warning algorithm thinks the overlap is possible but not inevitable. 
For example, this triggers it:

  void f (char *p, int i)
  {
if (i < 0)
  i = 0;

char *q = p + i;

__builtin_strcpy (q, p);
  }

  t.c:10:3: warning: ‘__builtin_strcpy’ accessing 1 byte at offsets [0,
2147483647] and 0 may overlap 1 byte at offset 0 [-Wrestrict]
 10 |   __builtin_strcpy (q, p);
|   ^~~

The logic behind the decision is that since using strcpy to copy within the
same array is only safe when one knows the length of the source string (in
addition to the distance between the offsets into the array), using a "bounded"
function such as memcpy or even strncpy would be more appropriate: it would
make the constraints explicit without sacrificing efficiency or readability.

GCC 8 doesn't issue the warning here because the bug fixed in r268048 on the
trunk but not yet backported to gcc-8-branch gets in the way: the offset in the
POINTER_PLUS_EXPR is in the anti-range ~[INT_MAX + 1, INT_MIN] which GCC 8
doesn't handle correctly.  I haven't backported r268048 to GCC 8 yet but I
don't think this warning is a reason not to.  Richard, let me know if you feel
otherwise.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
[Bug 84774] [meta-bug] bogus/missing -Wrestrict

[Bug c++/88967] [9 regression] openmp default(none) broken

[lebedev.ri at gmail dot com]

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

--- Comment #5 from Roman Lebedev  ---
(In reply to Jakub Jelinek from comment #1)
> I've asked the ifort/clang maintainers about why they keep violating the
> standard, but haven't heard back from them.  And I must say I was trying
> hard to readd the above rule + exception, but haven't succeeded.
Uhm, apparently clang does implement it correctly:
https://godbolt.org/z/_HFUki
the default OpenMP version used is still 3.1, thus it is not noticeable.

This begs the question, does gcc have a similar switch?

[Bug libstdc++/88947] regex_match doesn't fail early when given a non-matching pattern with a start-of-input anchor

[tom at kera dot name]

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

--- Comment #7 from Tomalak Geret'kal  ---
(In reply to Tim Shen from comment #5)
> For the original test case, have you tried regex_match() with "what.*"?

That behaves as I'd expect
(http://quick-bench.com/AKdMnnhA03T1vwfN9sf53xlbD6s).

> Do you have any non-trivial testcase in mind that is still unexpectedly slow
> with regex_match()?

The original real-world pattern that led to me discovering this was:

/^[\x02-\x7f]\0..[\x01-\x0c]\0..\0\0/

Switching to regex_match() for that pattern also yields the expected result
(http://quick-bench.com/g6lZj00gBswzvd-rjO7QwRE0Exg), so that's a good
workaround here.

But, adapting your earlier example to "(^abc|xyz)", this would require chaining
a regex_match with a regex_search, which gets unwieldy quite quickly.

Well, okay, I suppose in that example we could regex_match on
"(?:(abc).*|.*(xyz).*)", but I really don't think we should have to rewrite
patterns like this in order to get the behaviour that's common in other
ecosystems' regex impls. So, although I'm open to being convinced otherwise, I
still think we would reasonably expect regex_search to fail fast.

[Bug target/88938] ICE in extract_insn, at recog.c:2304

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #6 from Uroš Bizjak  ---
Fixed.

[Bug c++/88984] [9 Regression] ICE in genericize_switch_stmt, at cp/cp-gimplify.c:377

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-01-22
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with my r255218 (C++ only), let me have a look.