[Bug c++/68372] [concepts] invalid use of pack expansion expression in member function template declaration

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #6 from Arseny Solokha  ---
gcc 9 ICEs on both testcases, but newer versions accept it.

[Bug c++/82531] ICE: Segmentation fault (-std=c++1z -fconcepts)

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #4 from Arseny Solokha  ---
The "ice" testcase in comment 3 ICEs on 9 branch, while gcc 10 and master
accept it.

[Bug lto/95190] Documentation for -Wstringop-overflow

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
> "writing 1 bytes into a region of size 0 -Wstringop-overflow=". Yet
> -Wno-stringop-overflow is passed to the compiler.  I tried disabling the
> warning with #pragma diagnostic, no luck there.

I must confirm that '#pragma diagnostic' is completely unsupported by LTO and I
spent some time tweaking into it. Eventually, I bailed out.

[Bug middle-end/94635] [OpenMP][Offloading] mapping with alloc/delete followed by map(from/tofrom:) fails

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Tobias Burnus
:

https://gcc.gnu.org/g:a7c5803d4e56c6f6c84a9c5b08adffb0cfe1d79f

commit r10-8156-ga7c5803d4e56c6f6c84a9c5b08adffb0cfe1d79f
Author: Tobias Burnus 
Date:   Tue May 19 10:10:21 2020 +0200

[OpenMP] Fix 'omp exit data' for Fortran arrays (PR 94635)

Backport from mainline
2020-05-15  Tobias Burnus  

gcc/
PR middle-end/94635
* gimplify.c (gimplify_scan_omp_clauses): For MAP_TO_PSET with
OMP_TARGET_EXIT_DATA, use 'release:' unless the associated
item is 'delete:'.

gcc/testsuite
PR middle-end/94635
* gfortran.dg/gomp/target-exit-data.f90: New.

[Bug libstdc++/95200] user-defined hash function is not copied correctly if unordered_map is declared using an incomplete type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to jevgenijsz1 from comment #0)
> however I couldn't find a reason for why this should not work as expected.

[res.on.functions] paragraph 2:

In particular, the effects are undefined in the following cases:
- [...]
- If an incomplete type ([basic.types]) is used as a template argument when
instantiating a template component or evaluating a concept, unless specifically
allowed for that component.

[Bug libstdc++/95200] user-defined hash function is not copied correctly if unordered_map is declared using an incomplete type

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Although the actual cause of the behaviour you see is due to violating a
different requirement. The explicit specialization hash is not
declared in map_obj.h which means it gets implicitly instantiated using the
default definition of std::hash for enumeration types. An explicit
specialization needs to be declared before any use that would cause the
implicit instantiation to happen.

[Bug libstdc++/95200] user-defined hash function is not copied correctly if unordered_map is declared using an incomplete type

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
That's [temp.expl.spec] paragraph 7:

If a template, a member template or a member of a class template is explicitly
specialized then that specialization shall be declared before the first use of
that specialization that would cause an implicit instantiation to take place,
in every translation unit in which such a use occurs; no diagnostic is
required.

[Bug fortran/94361] Memory leak in nested types with final

[antony at cosmologist dot info]

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

--- Comment #3 from Antony Lewis  ---
On Windows 8.1.0 does not leak, and on NERSC 8.3.0 20190222 (Cray Inc.) also
does not (but 9.2.0 does)... so not exactly sure what this means about when it
was introduced.

[Bug target/92658] x86 lacks vector extend / truncate

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:f6e40195ec3d3b402a5f6c58dbf359479bc4cbfa

commit r11-485-gf6e40195ec3d3b402a5f6c58dbf359479bc4cbfa
Author: Uros Bizjak 
Date:   Tue May 19 11:25:46 2020 +0200

i386: Add missing vector zero/sign extend expanders [PR92658]

2020-05-19  Uroš Bizjak  

gcc/ChangeLog:
PR target/92658
* config/i386/sse.md (v16qiv16hi2): New expander.
(v32qiv32hi2): Ditto.
(v8qiv8hi2): Ditto.
(v16qiv16si2): Ditto.
(v8qiv8si2): Ditto.
(v4qiv4si2): Ditto.
(v16hiv16si2): Ditto.
(v8hiv8si2): Ditto.
(v4hiv4si2): Ditto.
(v8qiv8di2): Ditto.
(v4qiv4di2): Ditto.
(v2qiv2di2): Ditto.
(v8hiv8di2): Ditto.
(v4hiv4di2): Ditto.
(v2hiv2di2): Ditto.
(v8siv8di2): Ditto.
(v4siv4di2): Ditto.
(v2siv2di2): Ditto.

gcc/testsuite/ChangeLog:
PR target/92658
* gcc.target/i386/pr92658-sse4.c: New test.
* gcc.target/i386/pr92658-avx2.c: New test.
* gcc.target/i386/pr92658-avx512bw.c: New test.

[Bug target/92658] x86 lacks vector extend / truncate

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Keywords||easyhack
   Assignee|ubizjak at gmail dot com   |unassigned at gcc dot 
gnu.org
 CC||ubizjak at gmail dot com
 Status|ASSIGNED|NEW

--- Comment #15 from Uroš Bizjak  ---
I will leave truncations (Down Converts in Intel speak) which are AVX512F
instructions to someone else. It should be easy to add missing patterns and
tests following the example of committed patch.

[Bug tree-optimization/88398] vectorization failure for a small loop to do byte comparison

[guojiufu at gcc dot gnu.org]

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

Jiu Fu Guo  changed:

   What|Removed |Added

 CC||guojiufu at gcc dot gnu.org

--- Comment #25 from Jiu Fu Guo  ---
(In reply to Jakub Jelinek from comment #10)
> If the compiler knew say from PGO that pos is usually a multiple of certain
> power of two and that the loop usually iterates many times (I guess the
> latter can be determined from comparing the bb count of the loop itself and
> its header), it could emit something like:
> static int func2(int max, int pos, unsigned char *cur)
> {
>   unsigned char *p = cur + pos;
>   int len = 0;
>   if (max > 32 && (pos & 7) == 0)
> {
>   int l = ((1 - ((uintptr_t) cur)) & 7) + 1;
>   while (++len != l)
> if (p[len] != cur[len])
>   goto end;
>   unsigned long long __attribute__((may_alias)) *p2 = (unsigned long
> long *) &p[len];
>   unsigned long long __attribute__((may_alias)) *cur2 = (unsigned long
> long *) &cur[len];
>   while (len + 8 < max)
> {
>   if (*p2++ != *cur2++)
> break;
>   len += 8;
> }
>   --len;
> }
>   while (++len != max)
> if (p[len] != cur[len])
>   break;
> end:
>   return cur[len];
> }
> 
> or so (untested).  Of course, it could be done using SIMD too if there is a
> way to terminate the loop if any of the elts is different and could be done
> in that case at 16 or 32 or 64 characters at a time etc.
> But, without knowing that pos is typically some power of two this would just
> waste code size, dealing with the unaligned cases would be more complicated
> (one can't read the next elt until proving that the current one is all
> equal), so it would need to involve some rotations (or permutes for SIMD).

With this kind of widening,  we can see ~5% performance improvement for xz on
some platforms.

[Bug tree-optimization/95201] New: Some x86 vector-extend patterns are not exercised.

[ubizjak at gmail dot com]

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

Bug ID: 95201
   Summary: Some x86 vector-extend patterns are not exercised.
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Some of x86 vector extend patterns are not exercised by middle end. Currently,
they are XFAILed in gcc.target/i386/pr92658-*.c:


pr92658-avx2.c:/* { dg-final { scan-assembler-times "pmovzxbq" 2 { xfail *-*-*
} } } */
pr92658-sse4.c:/* { dg-final { scan-assembler-times "pmovzxbd" 2 { xfail *-*-*
} } } */
pr92658-sse4.c:/* { dg-final { scan-assembler-times "pmovzxbq" 2 { xfail *-*-*
} } } */
pr92658-sse4.c:/* { dg-final { scan-assembler-times "pmovzxwq" 2 { xfail *-*-*
} } } */

These correspond to:

-O2 -ftree-vectorize -mavx2 is required:

--cut here--
typedef unsigned char v32qi __attribute__((vector_size (32)));
typedef unsigned short v16hi __attribute__((vector_size (32)));
typedef unsigned int v8si __attribute__((vector_size (32)));
typedef unsigned long long v4di __attribute__((vector_size (32)));

void
foo_u8_u64 (v4di * dst, v32qi * __restrict src)
{
  unsigned long long tem[4];
  tem[0] = (*src)[0];
  tem[1] = (*src)[1];
  tem[2] = (*src)[2];
  tem[3] = (*src)[3];
  dst[0] = *(v4di *) tem;
}

void
bar_u8_u64 (v4di * dst, v32qi src)
{
  unsigned long long tem[4];
  tem[0] = src[0];
  tem[1] = src[1];
  tem[2] = src[2];
  tem[3] = src[3];
  dst[0] = *(v4di *) tem;
}

/* { dg-final { scan-assembler-times "pmovzxbq" 2 { xfail *-*-* } } } */
--cut here--

-O2 -ftree-vectorize -msse4.1 is required:

--cut here--
void
foo_u8_u32 (v4si * dst, v16qi * __restrict src)
{
  unsigned int tem[4];
  tem[0] = (*src)[0];
  tem[1] = (*src)[1];
  tem[2] = (*src)[2];
  tem[3] = (*src)[3];
  dst[0] = *(v4si *) tem;
}

void
bar_u8_u32 (v4si * dst, v16qi src)
{
  unsigned int tem[4];
  tem[0] = src[0];
  tem[1] = src[1];
  tem[2] = src[2];
  tem[3] = src[3];
  dst[0] = *(v4si *) tem;
}

/* { dg-final { scan-assembler-times "pmovzxbd" 2 { xfail *-*-* } } } */

void
foo_u8_u64 (v2di * dst, v16qi * __restrict src)
{
  unsigned long long tem[2];
  tem[0] = (*src)[0];
  tem[1] = (*src)[1];
  dst[0] = *(v2di *) tem;
}

void
bar_u8_u64 (v2di * dst, v16qi src)
{
  unsigned long long tem[2];
  tem[0] = src[0];
  tem[1] = src[1];
  dst[0] = *(v2di *) tem;
}

/* { dg-final { scan-assembler-times "pmovzxbq" 2 { xfail *-*-* } } } */

void
foo_u16_u64 (v2di * dst, v8hi * __restrict src)
{
  unsigned long long tem[2];
  tem[0] = (*src)[0];
  tem[1] = (*src)[1];
  dst[0] = *(v2di *) tem;
}

void
bar_u16_u64 (v2di * dst, v8hi src)
{
  unsigned long long tem[2];
  tem[0] = src[0];
  tem[1] = src[1];
  dst[0] = *(v2di *) tem;
}

/* { dg-final { scan-assembler-times "pmovzxwq" 2 { xfail *-*-* } } } */

Please note that these testcases fail to vectorize also in their loop forms,
e.g.:

--cut here--
void
foo_u8_u64 (v4di * dst, v32qi * __restrict src)
{
  unsigned long long tem[4];

  for (int i = 0; i < 4; i++)
tem[i] = (*src)[i];

  dst[0] = *(v4di *) tem;
}

void
bar_u8_u64 (v4di * dst, v32qi src)
{
  unsigned long long tem[4];

  for (int i = 0; i < 4; i++)
tem[i] = src[i];

  dst[0] = *(v4di *) tem;
}
--cut here--

Please see also PR 92658#c8 for some analysis.

[Bug libstdc++/71133] msp430-elf -mlarge FTBFS in libstdc++-v3

[jozefl at gcc dot gnu.org]

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

jozefl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from jozefl at gcc dot gnu.org ---
Fixed by

Support unsigned __int20 in checks for size_t mangling

2017-01-20  Joe Seymour  

* acinclude.m4 (GLIBCXX_CHECK_SIZE_T_MANGLING): Support uint20_t.
* configure: Regenerate.

[Bug rtl-optimization/66156] [msp430] wrong code generated with -O2 -mlarge (zero extension HI -> SI)

[jozefl at gcc dot gnu.org]

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

jozefl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from jozefl at gcc dot gnu.org ---
Fixed since GCC 6.

[Bug target/82261] x86: missing peephole for SHLD / SHRD

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to Michael Clark from comment #2)
> Just refreshing this issue. I found it while testing some code-gen on
> Godbolt:

The combiner creates:

Failed to match this instruction:
(parallel [
(set (reg:SI 89)
(ior:SI (ashift:SI (reg:SI 94)
(subreg:QI (reg/v:SI 88 [ n ]) 0))
(lshiftrt:SI (reg:SI 95)
(minus:QI (subreg:QI (reg:SI 91) 0)
(subreg:QI (reg/v:SI 88 [ n ]) 0)
(clobber (reg:CC 17 flags))
])

This is *almost* matched by:

(define_insn "x86_shld"
  [(set (match_operand:SI 0 "nonimmediate_operand" "+r*m")
(ior:SI (ashift:SI (match_dup 0)
  (match_operand:QI 2 "nonmemory_operand" "Ic"))
(lshiftrt:SI (match_operand:SI 1 "register_operand" "r")
  (minus:QI (const_int 32) (match_dup 2)
   (clobber (reg:CC FLAGS_REG))]

but RTL combiner doesn't propagate (const_int 32) into the pattern.

I wonder if tree combiner can help here.

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[iains at gcc dot gnu.org]

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

--- Comment #10 from Iain Sandoe  ---
It seems that the ubsan complaints look all rather similar.
At least for the following case, ubsan seems to cause a change which introduces
a bogus temporary use.

class-00-co-ret.C u=is a very simple coroutine - this is the output of
-fdump-tree-gimple for the main body of the actor function.

without ubsan.

_7 = &frame_ptr->__p;
frame_ptr->__aw_s.is = coro1::promise_type::initial_suspend (_7);
[return slot optimization]
_8 = &frame_ptr->__aw_s.is;
_9 = coro1::suspend_always_prt::await_ready (_8);
retval.0 = ~_9;
if (retval.0 != 0) goto ; else goto ;
:
frame_ptr->__resume_at = 2;
_10 = &frame_ptr->__aw_s.is;
coro1::suspend_always_prt::await_suspend (_10,
frame_ptr->__self_h);
D.11053 = .CO_YIELD (2, 0, &resume.2, &destroy.2, frame_ptr);
retval.1 = D.11053;
switch (retval.1) , case 0: , case 1:
>
:
.CO_SUSPN (&actor.suspend.ret);
:
goto resume.2;
:
goto destroy.2;
destroy.2:
_11 = &frame_ptr->__aw_s.is;
coro1::suspend_always_prt::~suspend_always_prt (_11);
goto coro.delete.promise;
:
resume.2:
frame_ptr->__i_a_r_c = 1;
_12 = &frame_ptr->__aw_s.is;
coro1::suspend_always_prt::await_resume (_12);
_13 = &frame_ptr->__aw_s.is;
coro1::suspend_always_prt::~suspend_always_prt (_13);
{
  puts ("coro1: about to return");
  _14 = &frame_ptr->__p;
  coro1::promise_type::return_value (_14, 42);
  goto final.suspend;


with ubsan
_7 = &frame_ptr->__p;
frame_ptr->__aw_s.is = coro1::promise_type::initial_suspend (_7);
[return slot optimization]
D.11410 = &frame_ptr->__aw_s.is;
.UBSAN_NULL (D.11410, 4B, 0);
_8 = coro1::suspend_always_prt::await_ready (D.11410);
retval.0 = ~_8;
if (retval.0 != 0) goto ; else goto ;
:
frame_ptr->__resume_at = 2;
D.11413 = &frame_ptr->__aw_s.is;
.UBSAN_NULL (D.11413, 4B, 0);
coro1::suspend_always_prt::await_suspend (D.11413,
frame_ptr->__self_h);
D.11322 = .CO_YIELD (2, 0, &resume.2, &destroy.2, frame_ptr);
retval.1 = D.11322;
switch (retval.1) , case 0: , case 1:
>
:
.CO_SUSPN (&actor.suspend.ret);
:
goto resume.2;
:
goto destroy.2;
destroy.2:
D.11415 = &frame_ptr->__aw_s.is;
.UBSAN_NULL (D.11415, 4B, 0);
coro1::suspend_always_prt::~suspend_always_prt (D.11415);
goto coro.delete.promise;
:
resume.2:
frame_ptr->__i_a_r_c = 1;
D.11416 = &frame_ptr->__aw_s.is;
.UBSAN_NULL (D.11416, 4B, 0);
coro1::suspend_always_prt::await_resume (D.11416);
.UBSAN_NULL (D.11415, 4B, 0);
^^^ this is not correct D.11415 is not valid here, (D.11416 would be).
coro1::suspend_always_prt::~suspend_always_prt (D.11415);
{
  puts ("coro1: about to return");
  D.11417 = &frame_ptr->__p;
  .UBSAN_NULL (D.11417, 4B, 4);
  coro1::promise_type::return_value (D.11417, 42);
  goto final.suspend;
}

[Bug tree-optimization/89386] Generation of vectorized MULHRS (Multiply High with Round and Scale) instruction

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #3 from Uroš Bizjak  ---
Fixed also for x86 targets.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[ubizjak at gmail dot com]

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

Bug 89386 Summary: Generation of vectorized MULHRS (Multiply High with Round 
and Scale) instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89386

   What|Removed |Added

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

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe  ---
perhaps I have some invalid sharing of trees that only causes an issue for
ubsan - will try build independent dtor trees for the two cases.

[Bug c++/95202] New: Assignment to a member is wrongly optimized away by g++ with -fstrict-aliasing

[syomalina at gmail dot com]

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

Bug ID: 95202
   Summary: Assignment to a member is wrongly optimized away by
g++ with -fstrict-aliasing
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: syomalina at gmail dot com
  Target Milestone: ---

Created attachment 48559
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48559&action=edit
the preprocessed file (*.i*) that triggers the bug

The following code produces a wrong ERROR print with -fstrict-aliasing enabled.
It sounds like a commonly reported false-positive bug with aliasing rules
violation from the FAQ, but it's not (imho :-)), as no type-casting and memory
manipulations are involved. 

The problem could be related to the following bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93246, as "the symptoms" are quite
similar and type aliases are involved also here. But for the code below
-fno-ipa-sra doesn't help, only -fno-strict-aliasing does. 

The problem appears with GCC 9.2.0, 9.1.0. It doesn't appear with GCC 9.3 and
10.1. The reason I've thought it would be still useful to report the bug is: a
very fragile code constellation which allows to reproduce the problem. I've
marked in comments below what could be done to prevent the problem from
appearing. It looks like that even a slight change in the optimizer could
"hide" the problem back, what could have happened in the later versions of GCC.
So, it would be great to check what is the root cause of the problem, and if it
was actually fixed in later GCC versions. 

The code below models variable sized array allocated on stack. Then 2x
dimension  array is created with sizes 32 and 4 respectively. The bug happens
in this line:
outerArrItem.innerArray.setSize(innerArraySize);
body.numElements is not updated with the new size (4) for the inner array, and
following access to an element [0] of the inner array raises the error. 

// 
#include 

template 
class VariableSizedArray
{
public:
void setSize(uint32_t num) { body.numElements = num; }

T& operator[](uint32_t idx)
{
if (idx >= CAPACITY or idx >= body.numElements)
{
raiseIndexErr("", 42, "ERROR: Invalid idx: ", idx, 42,
body.numElements);
}
return body.elems[idx];
}

// Changes in parameters make the problem to disappear
static void raiseIndexErr(const char*, uint32_t, const char* error,
uint32_t idx, uint32_t, uint32_t num)
{
// If printf is used, problem disappears
std::cerr << error << idx << "! Capacity: " << CAPACITY << ", number
elements: " << num << ::std::endl;
}

// private: // If private -- problem disappears
struct Data
{
uint32_t numElements;
T elems[CAPACITY];
};
using Body = Data; 
Body body; // If Data is used directly here w/o "using", problem disappears
};

static constexpr int outerArraySize = 32;
static constexpr int innerArraySize = 4;

class InnerArrayItem
{
public:
void use(){};
uint8_t dummy[1]{}; // when removed or not an array, problem disappears
};

class OuterArrayItem
{
public:
uint8_t dummy{0}; // When removed, problem disappears
VariableSizedArray innerArray{};
};

struct TestProblem
{
// When parameter removed (its always 0) -- problem disappears
static void run(const uint8_t index0)
{
VariableSizedArray outerArray{};

outerArray.setSize(outerArraySize);
auto& outerArrItem = outerArray[index0];
outerArrItem.innerArray.setSize(innerArraySize);

// ERROR: invalid idx is reported for outerArray[0].innerArray[0]
access!
outerArrItem.innerArray[index0].use();
}
};

int main()
{
TestProblem::run(0);
std::cout << "Test finished." << std::endl;
return 0;
}

/*
Execution results:

$ g++ --version # same happens for 9.1.0 as well
g++ (GCC) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.

# Just -O1
$ rm gccBug; g++ -o gccBug -Wall -Werror -O1 TestGccBug.cpp && ./gccBug
Test finished.

# -O1 with -fstrict-aliasing
$ rm gccBug; g++ -o gccBug -Wall -Werror -O1 -fstrict-aliasing TestGccBug.cpp
&& ./gccBug 
ERROR: Invalid idx: 0! Capacity: 4, number elements: 0
Test finished.

# Just -O2
$ rm gccBug; g++ -o gccBug -Wall -Werror -O2 TestGccBug.cpp && ./gccBug
ERROR: Invalid idx: 0! Capacity: 4, number elements: 0
Test finished.

# Just -O3
$ rm gccBug; g++ -o gccBug -Wall -Werror -O3 TestGccBug.cpp && ./gccBug
ERROR: Invalid idx: 0! Capacity: 4, number elements: 0
Test finished.

# -O3 with -fno-ipa-sra as recommended in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93246
$ rm gccBug; g++ -o gccBug -Wall -Werror -O3 -fno-ipa-sra TestGccBug.cpp &&
./gccBug
ERROR: Invalid idx: 0! Capacity: 4, number elements: 0
Test finished.

# -O3 with -fno-ipa-s

[Bug libgomp/95203] New: OpenACC 2.6 deep copy: attach/detach API routines: no-op behavior

[tschwinge at gcc dot gnu.org]

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

Bug ID: 95203
   Summary: OpenACC 2.6 deep copy: attach/detach API routines:
no-op behavior
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48560
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48560&action=edit
'mdc-attach-nop-1-r.c'

The "OpenACC 2.6 deep copy: attach/detach API routines" added in r279624 do not
implement the required no-op behavior; see the test cases I'm attaching.

[Bug libgomp/95203] OpenACC 2.6 deep copy: attach/detach API routines: no-op behavior

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Created attachment 48561
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48561&action=edit
'mdc-attach-nop-2-r.c'

[Bug bootstrap/95204] New: patch commit, and making gcc error.

[chengcongxiu at huawei dot com]

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

Bug ID: 95204
   Summary: patch commit, and making gcc error.
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengcongxiu at huawei dot com
  Target Milestone: ---

when i patch this commit
(https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1ce87609c91e51d7eee8284c5fe000c7d5b240db),
make gcc error:

You should edit
/home/ccx/test2/SDK_CPU_HCC/build/hcc_arm64be/../../open_source/hcc_arm64be_build_src/gcc-7.3.0/gcc/doc/tm.texi.in
rather than
/home/ccx/test2/SDK_CPU_HCC/build/hcc_arm64be/../../open_source/hcc_arm64be_build_src/gcc-7.3.0/gcc/doc/tm.texi
.
Makefile:2447: recipe for target 's-tm-texi' failed
make[2]: *** [s-tm-texi] Error 1
make[2]: *** Waiting for unfinished jobs
echo timestamp > s-options-h

any one know what's wrong?

[Bug bootstrap/95205] New: patch commit, and making gcc error.

[chengcongxiu at huawei dot com]

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

Bug ID: 95205
   Summary: patch commit, and making gcc error.
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengcongxiu at huawei dot com
  Target Milestone: ---

when i patch this commit
(https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1ce87609c91e51d7eee8284c5fe000c7d5b240db),
make gcc error:

You should edit
/home/ccx/test2/SDK_CPU_HCC/build/hcc_arm64be/../../open_source/hcc_arm64be_build_src/gcc-7.3.0/gcc/doc/tm.texi.in
rather than
/home/ccx/test2/SDK_CPU_HCC/build/hcc_arm64be/../../open_source/hcc_arm64be_build_src/gcc-7.3.0/gcc/doc/tm.texi
.
Makefile:2447: recipe for target 's-tm-texi' failed
make[2]: *** [s-tm-texi] Error 1
make[2]: *** Waiting for unfinished jobs
echo timestamp > s-options-h

any one know what's wrong?

[Bug libgomp/95203] OpenACC 2.6 deep copy: attach/detach API routines: no-op behavior

[tschwinge at gcc dot gnu.org]

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

--- Comment #2 from Thomas Schwinge  ---
Created attachment 48562
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48562&action=edit
'mdc-detach-nop-1-r.c'

[Bug libgomp/95203] OpenACC 2.6 deep copy: attach/detach API routines: no-op behavior

[tschwinge at gcc dot gnu.org]

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

--- Comment #3 from Thomas Schwinge  ---
Created attachment 48563
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48563&action=edit
'mdc-detach-nop-2-r.c'

I have similar test cases for OpenACC directives (which are to exhibit similar
behavior), but for avoidance of doubt, let's first address this for the OpenACC
runtime library routines.

[Bug target/95151] [9/10/11 Regression] Add cmpmemM pattern for -minline-all-stringops

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

Summary|Add cmpmemM pattern for |[9/10/11 Regression] Add
   |-minline-all-stringops  |cmpmemM pattern for
   ||-minline-all-stringops
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-19

--- Comment #1 from H.J. Lu  ---
We used to expand memcmp to "repz cmpsb" via cmpstrnsi.  It was changed
by

commit 9b0f6f5e511ca512e4faeabc81d2fd3abad9b02f
Author: Nick Clifton 
Date:   Fri Aug 12 16:26:11 2011 +

    builtins.c (expand_builtin_memcmp): Do not use cmpstrnsi pattern.

            * builtins.c (expand_builtin_memcmp): Do not use cmpstrnsi
            pattern.
            * doc/md.texi (cmpstrn): Note that the comparison stops if both
            fetched bytes are zero.
            (cmpstr): Likewise.
            (cmpmem): Note that the comparison does not stop if both of the
            fetched bytes are zero.

[Bug bootstrap/95205] patch commit, and making gcc error.

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
read the full message, you need to copy gcc/tm.texi to $src/gcc/doc/

[Bug c++/66439] Diagnostic on failed function template lookup is missing a line

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 11.

[Bug other/94182] Improve -Wchar-subscripts documentation

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||egallager at gcc dot gnu.org
Summary|Document -Wchar-subscripts  |Improve -Wchar-subscripts
   ||documentation
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-19
 Status|UNCONFIRMED |NEW

--- Comment #4 from Eric Gallager  ---
retitling to clarify what exactly the issue is, and confirming

[Bug libfortran/95177] error: array subscript has type char

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   Keywords||build, diagnostic
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=94182

--- Comment #3 from Eric Gallager  ---
(In reply to Roland Illig from comment #2)
> >--- Comment #1 from kargl at gcc dot gnu.org ---
> >Why cast to unsigned char?  The prototypes for tolower(), toupper(),
> >isdigit(), etc show that the type of the argument is int.
> 
> See https://stackoverflow.com/a/60696378 for a detailed explanation.

...which in turn led to bug 94182

[Bug bootstrap/95205] patch commit, and making gcc error.

[chengcongxiu at huawei dot com]

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

--- Comment #2 from chengcongxiu at huawei dot com  ---
(In reply to Richard Biener from comment #1)
> read the full message, you need to copy gcc/tm.texi to $src/gcc/doc/

thanks you! now making is ok!

[Bug c++/41437] No access control for classes in template functions

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug target/95182] Change the definition of Pmode

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

https://gcc.gnu.org/g:a641d6d3e631e523e8cf0cfc8b8e324da118dff2

commit r11-496-ga641d6d3e631e523e8cf0cfc8b8e324da118dff2
Author: Nathan Sidwell 
Date:   Tue May 19 06:11:22 2020 -0700

preprocessor: Fix ICE with EOF in macro args [pr95182]

This was another latent case of us losing an EOF token, but succeeding
anyway.  Since my patch to make us pay more attention to EOFs it came
to light.  We also need to keep the EOF if we fall off the end of the
main file.  Forced includes look like regular nested includes at this
point.

PR preprocessor/95182
libcpp/
* macro.c (collect_args): Preserve EOFif we fell out of the main
file.
(cpp_get_token_1): Reformat a couple of short lines.

[Bug preprocessor/95183] [11 Regression] ICE: Segmentation fault (in _cpp_lex_direct)

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell  ---
Fixed a641d6d3e63

[Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Liška  ---
I was able to reproduce that on tramp3d as well. I bet the problem is that the
inline expansion does not clear:
**SavedFlagPtr(FakeStack) = 0

as LLVM does:
https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp#L3279-L3292

Let me take a look.

[Bug c++/95206] New: internal compiler error: in sign_mask, at wide-int.h:855

[danny.schneider at posteo dot de]

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

Bug ID: 95206
   Summary: internal compiler error: in sign_mask, at
wide-int.h:855
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danny.schneider at posteo dot de
  Target Milestone: ---

Created attachment 48564
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48564&action=edit
intermediate file which contains failing code example

compile (which worded fine with 9.3 and lower) now with gcc 10.1.0 reports 
" internal compiler error: in sign_mask, at wide-int.h:855"
when the template type is an unsigned char (u8)

This is the Compiler Output:

g++ -c -pipe -g -std=c++11 -Wall -Wextra -O0 -Wcpp -save-temps=obj -Wall
-Wextra -fPIC -DQT_QML_DEBUG -I../test_gcc10_bug -I.
-I/usr/lib/qt/mkspecs/linux-g++ -o main.o ../test_gcc10_bug/main.cpp
g++ -c -pipe -g -std=c++11 -Wall -Wextra -O0 -Wcpp -save-temps=obj -Wall
-Wextra -fPIC -DQT_QML_DEBUG -I../test_gcc10_bug -I.
-I/usr/lib/qt/mkspecs/linux-g++ -o utest_countbitsset.o
../test_gcc10_bug/utest_countbitsset.cpp
g++: warning: ‘-pipe’ ignored because ‘-save-temps’ specified
g++: warning: ‘-pipe’ ignored because ‘-save-temps’ specified
In file included from ../test_gcc10_bug/main.cpp:8:
../test_gcc10_bug/countbitsset.h:38: warning: ignoring ‘#pragma GCC
diagnosTc’ [-Wunknown-pragmas]
   38 | #pragma GCC diagnosTc push
  | 
../test_gcc10_bug/countbitsset.h:39: warning: ignoring ‘#pragma GCC
diagnosTc’ [-Wunknown-pragmas]
   39 | #pragma GCC diagnosTc ignored "-Wshift-count-overflow"
  | 
../test_gcc10_bug/countbitsset.h:42: warning: ignoring ‘#pragma GCC
diagnosTc’ [-Wunknown-pragmas]
   42 | #pragma GCC diagnosTc pop
  | 
../test_gcc10_bug/countbitsset.h: In instantiation of ‘u8 countbitsset(const
T&) [with T = unsigned char; u8 = unsigned char]’:
../test_gcc10_bug/main.cpp:14:34:   required from here
../test_gcc10_bug/countbitsset.h:36:23: internal compiler error: in sign_mask,
at wide-int.h:855
   36 |   c = ((c >> S[2]) + c) & B[2];  //Bucket of size 8
  |~~~^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make: *** [Makefile:780: main.o] Error 1

[Bug analyzer/95207] New: the papers about gcc optimized

[chengcongxiu at huawei dot com]

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

Bug ID: 95207
   Summary: the papers about gcc optimized
   Product: gcc
   Version: analyzer branch
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: chengcongxiu at huawei dot com
  Target Milestone: ---

someone can introduces some papers about gcc optimize!

[Bug analyzer/95207] the papers about gcc optimized

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug middle-end/95208] New: missed switch optimization as bit test

[nathan at gcc dot gnu.org]

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

Bug ID: 95208
   Summary: missed switch optimization as bit test
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48565
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48565&action=edit
The if case is optimized better

This comes from libcpp/lex.c's raw string lexer.  We're testing whether a
character falls into a particular set of values.  The switch is emitted as the
usual dispatch table.  The if case, after range checking, turns into
'if ((1ul << (c - BASE)) & MAGIC_VALUE)'  Which is somewhat better.  Why
doesn't the switch form do that?

_Z3bazc:
.LFB1:
.cfi_startproc
leal-97(%rdi), %eax
cmpb$29, %al
jbe .L7
subl$33, %edi
cmpb$62, %dil
ja  .L6
movabsq $8646911282403868279, %rax
btq %rdi, %rax
jc  .L7
.L6:
ret
.p2align 4,,10
.p2align 3
.L7:
jmp _Z3barv
.cfi_endproc

[Bug libstdc++/95209] New: std::filesystem::path::lexically_normal mangles "//foo"

[terra at gnome dot org]

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

Bug ID: 95209
   Summary: std::filesystem::path::lexically_normal mangles
"//foo"
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: terra at gnome dot org
  Target Milestone: ---

Created attachment 48566
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48566&action=edit
test program

lexically_normal transforms "//foo" into "/foo".  It should leave
two initial slashes (an alternate root) alone.

Output of upcoming program is "/foo" when it should be "//foo".

[Bug libstdc++/95209] std::filesystem::path::lexically_normal mangles "//foo"

[terra at gnome dot org]

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

--- Comment #1 from M Welinder  ---
Created attachment 48567
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48567&action=edit
preprocessed test program

[Bug target/95182] Change the definition of Pmode

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #4 from Nathan Sidwell  ---
That patch was aiming for 95183, but missed :)

[Bug c/95210] New: internal compiler error: in prepare_copy_insn, at gcse.c:1988

[zhongyunde at tom dot com]

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

Bug ID: 95210
   Summary: internal compiler error: in prepare_copy_insn, at
gcse.c:1988
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhongyunde at tom dot com
  Target Milestone: ---

rtx_insn *
prepare_copy_insn (rtx reg, rtx exp)
{
  ... 
  else
{
  rtx_insn *insn = emit_insn (gen_rtx_SET (reg, exp));

  if (insn_invalid_p (insn, false))
gcc_unreachable ();  // here is the ICE ...
}

  pat = get_insns ();
  end_sequence ();  

  return pat;
}

As the function can_assign_to_reg_without_clobbers_p, we try to check an
temporary insn with regno 'FIRST_PSEUDO_REGISTER * 2'. So in some corner case,
such as a pattern with inout operand, the regno 'FIRST_PSEUDO_REGISTER * 2' is
just equal to the the regno in the REG_EQUAL （FIRST_PSEUDO_REGISTER = 117）,
then the temporary insn is valid, but it come fail when alloc another regno for
it, here is this issue.

(set (reg/v:V8HF16 236 )
  (unspec: V8HF18 [ (reg: V8HF18 150)
(reg: V8HF18 236)] UNSPEC_MOVTVFM）) 
   (expr_list:REG_EQUAL (unspec: V8HF18 [ (reg: V8HF18 150)
  (reg: V8HF18 234)] UNSPEC_MOVTVFM ))

bool
can_assign_to_reg_without_clobbers_p (rtx x, machine_mode mode)
{
   

  /* Otherwise, check if we can make a valid insn from it.  First initialize
 our test insn if we haven't already.  */
  if (test_insn == 0)
{
  test_insn
= make_insn_raw (gen_rtx_SET (gen_rtx_REG (word_mode,
   FIRST_PSEUDO_REGISTER * 2),
  const0_rtx));
  SET_NEXT_INSN (test_insn) = SET_PREV_INSN (test_insn) = 0;
  INSN_LOCATION (test_insn) = UNKNOWN_LOCATION;
}

  /* Now make an insn like the one we would make when GCSE'ing and see if
 valid.  */
  PUT_MODE (SET_DEST (PATTERN (test_insn)), mode);
  SET_SRC (PATTERN (test_insn)) = x;

  icode = recog (PATTERN (test_insn), test_insn, &num_clobbers);

[Bug preprocessor/95183] [11 Regression] ICE: Segmentation fault (in _cpp_lex_direct)

[nathan at gcc dot gnu.org]

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

--- Comment #5 from Nathan Sidwell  ---
patch got attached to p95182, because reasons

[Bug rtl-optimization/95211] New: [11 Regression] ICE in emit_unop_insn, at optabs.c:3622

[asolokha at gmx dot com]

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

Bug ID: 95211
   Summary: [11 Regression] ICE in emit_unop_insn, at
optabs.c:3622
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

gcc-11.0.0-alpha20200517 snapshot (g:2b9a271b2d0ba340234a138b7f8289bd7dca2fc5)
ICEs when compiling the following testcase w/ -march=skylake-avx512 -O3:

% x86_64-unknown-linux-gnu-gcc-11.0.0 -march=skylake-avx512 -O3 -c pvhda4vr.c
during RTL pass: expand
pvhda4vr.c: In function 'ml':
pvhda4vr.c:11:12: internal compiler error: in emit_unop_insn, at optabs.c:3622
   11 | tp[cm] = ha[cm] + 1.0f;
  | ~~~^~~
0x681295 emit_unop_insn(insn_code, rtx_def*, rtx_def*, rtx_code)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/optabs.c:3622
0x681dee emit_unop_insn(insn_code, rtx_def*, rtx_def*, rtx_code)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/optabs.c:4933
0x681dee expand_float(rtx_def*, rtx_def*, int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/optabs.c:4803
0xa1d278 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/expr.c:9151
0xa2352a expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/expr.c:10054
0xa2c184 expand_expr
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/expr.h:282
0xa2c184 expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/expr.c:7954
0xa1b878 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/expr.c:8850
0xa2352a expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/expr.c:10054
0xa1d19d expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/expr.c:8358
0xa1d19d expand_normal
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/expr.h:288
0xa1d19d expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/expr.c:9136
0xa2352a expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/expr.c:10054
0xa3056a expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/expr.c:8358
0xa3056a expand_expr
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/expr.h:282
0xa3056a expand_assignment(tree_node*, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/expr.c:5090
0x8fdf17 expand_gimple_stmt_1
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cfgexpand.c:3749
0x8fdf17 expand_gimple_stmt
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cfgexpand.c:3847
0x903b11 expand_gimple_basic_block
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cfgexpand.c:5887
0x9055f6 execute
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cfgexpand.c:6571

[Bug libstdc++/95200] user-defined hash function is not copied correctly if unordered_map is declared using an incomplete type

[jevgenijsz1 at verifone dot com]

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

--- Comment #4 from jevgenijsz1 at verifone dot com ---
Jonathan,

Thank you for looking into this. I guess what confused me was copy assignment
requirements in 26.2.7 that explicitly say hash function is copied and the hash
function is available at the time of copy

[Bug middle-end/60479] convert_move assert failed

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #2 from Arseny Solokha  ---
gcc 4.9 seems to be the last affected branch.

[Bug c/95210] internal compiler error: in prepare_copy_insn, at gcse.c:1988

[zhongyunde at tom dot com]

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

--- Comment #1 from zhongyunde at tom dot com  ---
patch for this issue.

@ linux-9z2e in ~/software/gcc/gcc on git:master o [23:02:26] 
$ git diff
diff --git a/gcc/gcse.c b/gcc/gcse.c
index 8b9518e..65982ec 100644
--- a/gcc/gcse.c
+++ b/gcc/gcse.c
@@ -853,7 +853,7 @@ can_assign_to_reg_without_clobbers_p (rtx x, machine_mode
mode)
 {
   test_insn
= make_insn_raw (gen_rtx_SET (gen_rtx_REG (word_mode,
-  FIRST_PSEUDO_REGISTER * 2),
+  max_regno + 1),
  const0_rtx));

[Bug libfortran/95177] error: array subscript has type char

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Tue, May 19, 2020 at 04:38:32AM +, roland.illig at gmx dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95177
> 
> --- Comment #2 from Roland Illig  ---
> >--- Comment #1 from kargl at gcc dot gnu.org ---
> >Why cast to unsigned char?  The prototypes for tolower(), toupper(),
> >isdigit(), etc show that the type of the argument is int.
> 
> See https://stackoverflow.com/a/60696378 for a detailed explanation.
> 

Ah, yeah, so?

There are no subscripts in the code you are changing.
Why does -Werror=char-subscripts trigger if there are
no subscripts?  Is the error flag misnamed?

If you're going to fix unbroken code, why not cast the
argument to the declared type of the ctype functions?

[Bug target/95212] New: enum processor_features is out of sync

[hjl.tools at gmail dot com]

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

Bug ID: 95212
   Summary: enum processor_features is out of sync
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: i386, x86-64

libgcc has

enum processor_features
{
  FEATURE_CMOV = 0,
...
  FEATURE_AVX512BITALG,
  FEATURE_AVX512BF16
};

i386-builtins.c has

/* This is the order of bit-fields in __processor_features in cpuinfo.c */
enum processor_features
{
...
  F_AVX512BITALG,
  F_AVX512VP2INTERSECT,  <<< Missing from libgcc.
  F_AVX512BF16,
  F_MAX
};

[Bug c/95213] New: GCC -Werror=conversion error when assigning to a bitfield (when mixing constants and variables)

[in-gcc at baka dot org]

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

Bug ID: 95213
   Summary: GCC -Werror=conversion error when assigning to a
bitfield (when mixing constants and variables)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: in-gcc at baka dot org
  Target Milestone: ---

When trying to assign to a bitfield with -Werror=conversion, having a constant
mix with a variable causes a "conversion from 'unsigned int' to 'unsigned
int:24' may change value", where as alternate formulations with two constants
or two variables work fine.  This error seems to be present on every version of
gcc ever (the ones I tried since 4.9.1, at least one in each major version, all
did the same thing).

Watch it fail on godbolt: https://gcc.godbolt.org/z/vavr-e


struct foo { unsigned int a:8; unsigned int b:24; };
void bar(struct foo num, unsigned int x) {
num.b = (5U << 1) | (1 & 1);
unsigned int z = 5U;
num.b = ((z << 1) | (x & 1)) & 0xffU;
num.b = ((5U << 1) | (x & 1)) & 0xffU;
num.a = (unsigned char)x;
}


In the above example, the last assignment of num.b fails to compile where the
other two succeed.  Note in the last example, casting the bit (x&1) to _Bool
will fix the problem, but is obviously not portable to larger expressions (e.g.
x&7).

[Bug c/95213] GCC -Werror=conversion error when assigning to a bitfield (when mixing constants and variables)

[in-gcc at baka dot org]

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

--- Comment #1 from Seth Robertson  ---
FYI, discussion on
https://stackoverflow.com/questions/61877799/son-of-gcc-conversion-warning-when-assigning-to-a-bitfield

[Bug libstdc++/95200] user-defined hash function is not copied correctly if unordered_map is declared using an incomplete type

[jevgenijsz1 at verifone dot com]

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

--- Comment #5 from jevgenijsz1 at verifone dot com ---
Moreover if I was to put a breakpoint in struct hash I can see that
it is being used 4 times in the code example posted: twice to hash the EnumType
on insertion and twice on access (however the second access attempt throws an
exception)

[Bug fortran/95214] New: ICE on assumed-rank character array with select rank

[jrfsousa at gmail dot com]

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

Bug ID: 95214
   Summary: ICE on assumed-rank character array with select rank
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jrfsousa at gmail dot com
  Target Milestone: ---

Created attachment 48568
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48568&action=edit
Fortran code demonstrating problems.

Hi All!

ICE with 10 and 11 on assumed-rank character array with select rank block.

using:

GNU Fortran (GCC) 10.1.1 20200518
GNU Fortran (GCC) 11.0.0 20200518 (experimental)

This is very likely related to Bug 67938 and Bug 66833.

Thank you very much.

Best regards,
José Rui

[Bug bootstrap/95205] patch commit, and making gcc error.

[pinskia at gcc dot gnu.org]

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

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

[Bug bootstrap/95204] patch commit, and making gcc error.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
.

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

[Bug bootstrap/95205] patch commit, and making gcc error.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Not a bug.

[Bug libstdc++/95200] user-defined hash function is not copied correctly if unordered_map is declared using an incomplete type

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
It's undefined behaviour so anything can happen.

[Bug libstdc++/95209] std::filesystem::path::lexically_normal mangles "//foo"

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
You didn't provide the requested information when creating a new bug report,
please see https://gcc.gnu.org/bugs/


(In reply to M Welinder from comment #0)
> lexically_normal transforms "//foo" into "/foo".  It should leave
> two initial slashes (an alternate root) alone.

That's implementation defined. This implementation only gives special handling
to paths starting with "//" for Cygwin. The path "//foo" has no special meaning
for other platforms.

[Bug libstdc++/71133] msp430-elf -mlarge FTBFS in libstdc++-v3

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug libfortran/95177] error: array subscript has type char

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
Calling toupper() or any other character classification function declared in
 with a negative value other than EOF is undefined.  When char is a
signed type, using any value outside the 7-bit ASCII set runs the risk of
accessing the char classification array, commonly used to implement the
functions, outside its bounds due to sign extension.  The Stack Overflow post
describes the technique in the abstract.  An example of a real implementation
is Glibc (see for instance its __isctype macro in ).

Glibc uses casts or other conversions from char to a signed type before using
the character value which suppresses GCC's -Wchar-subscripts, but the problem
still exists.

To avoid the out-of-bounds access the argument to these functions should be
cast to unsigned char first.  This is described in some detail in the CERT C
Secure Coding Standard rule STR37-C. Arguments to character-handling functions
must be representable as an unsigned char:
https://wiki.sei.cmu.edu/confluence/x/BNcxBQ.

[Bug lto/95190] Documentation for -Wstringop-overflow

[stayprivate at gmail dot com]

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

--- Comment #4 from Mario Charest  ---
On Mon, May 18, 2020 at 1:09 PM msebor at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95190
>
> Martin Sebor  changed:
>
>What|Removed |Added
>
> 
>Last reconfirmed||2020-05-18
>  Status|UNCONFIRMED |WAITING
>   Component|c++ |lto
>  Ever confirmed|0   |1
>  CC||marxin at gcc dot gnu.org
> ,
>||msebor at gcc dot gnu.org
>Keywords||documentation
>
> --- Comment #1 from Martin Sebor  ---
> Which part do you find surprising?  That the warning is issued during the
> LTO
> stage at all or that -Wno-stringop-overflow can be used during the LTO
> stage to
> suppress it?
>

Mostly the LTO stage. I got bitten because I assumed warning came from the
compiler. If the LTO stage would have handle #pragma diagnostic i would
have never noticed where it came from.


>
> During LTO the same compiler options should be implicitly enabled as during
> ordinary compilation, including warnings.  (This presents some challenges
> when
> the compilation was done with different options for different files.)
>

Most project with cmake using lto will required tweaking.  Typically
warning options are specified with add_compiler_options(). Now every
warning flags must also be passed to the linker, impossible to know which
flag has an effect on the LTO stage or not.


> It also means that all the same warnings should be expected to be
> implicitly
> enabled during LTO that were explicitly enabled during the compilation
> stage.
> I'd expect to see only "late" warnings during LTO, i.e., those that depend
> on
> optimization.  (I understand this doesn't work completely consistently yet
> but
> I believe that's the goal.)
>
> So this effect isn't specific to -Wstringop-overflow, but perhaps it would
> be
> worth mentioning under -flto?
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug libfortran/95177] error: array subscript has type char

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
See also pr78155 for a request to get GCC to warn for some instances of this
problem.

[Bug lto/95190] Documentation for -Wstringop-overflow

[stayprivate at gmail dot com]

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

--- Comment #5 from Mario Charest  ---
On Tue, May 19, 2020 at 2:35 AM rguenth at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95190
>
> --- Comment #2 from Richard Biener  ---
> This is new behavior for warnings in GCC 10 and now how all other
> optimization
> options behave - the option state is fixed per function at compile-time and
> carried over to link-time.
>
> Indeed warning options are not mentioned in the docs, let me fix that.
>

Great! Thanks, may I suggest adding it the changes and portings web page.
This new behavior may required tweaking of build files.


> --
> You are receiving this mail because:
> You reported the bug.

[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))

[n...@self-evident.org]

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

--- Comment #7 from Nemo  ---
(In reply to Hongtao.liu from comment #6)
>
> vmovdqa xmm0, xmm0 is not redundant here, it would clear up 128-256 bit
> which is the meaning of `zext`.

No, it is redundant because "vpcmpeqd xmm0, xmm0, xmm0" already zeroes out the
high lane of ymm0.

[Bug fortran/95215] New: internal compiler error: in gimplify_expr, at gimplify.c:14079

[john.donners at atos dot net]

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

Bug ID: 95215
   Summary: internal compiler error: in gimplify_expr, at
gimplify.c:14079
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.donners at atos dot net
  Target Milestone: ---

Created attachment 48569
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48569&action=edit
internal compiler error: in gimplify_expr, at gimplify.c:14079

Hello,

I attached another ICE. 

Command: gfortran -g -fopenmp -O3 ice_gcc10_g_fopenmp_O3.f90

Output:

during GIMPLE pass: ompdevlow
ice_gcc10_g_fopenmp_O3.f90: In function ‘thermodynamics_._omp_fn.1’:
ice_gcc10_g_fopenmp_O3.f90:42: internal compiler error: in gimplify_expr, at
gimplify.c:14079
   42 |  call therm_ice
  | 
0x7727cf gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:14079
0x77deab gimple_regimplify_operands(gimple*, gimple_stmt_iterator*)
../../gcc/gcc/gimplify-me.c:247
0x89fb57 execute_omp_device_lower
../../gcc/gcc/omp-offload.c:1975
0x89fb57 execute
../../gcc/gcc/omp-offload.c:2011
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
mkoffload: fatal error: x86_64-pc-linux-gnu-accel-nvptx-none-gcc returned 1
exit
status
compilation terminated.
lto-wrapper: fatal error:
/software/compilers/gcc-offload/10.1.0/gnu-9.2.0/libexec/gcc/x86_64-pc-linux-nu/10.1.0//accel/nvptx-none/mkoffload
returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status


Cheers,
John

[Bug target/95216] New: Extra space in __builtin_ia32_vec_pack_sfix256 definition

[andrey.vihrov at gmail dot com]

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

Bug ID: 95216
   Summary: Extra space in __builtin_ia32_vec_pack_sfix256
definition
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.vihrov at gmail dot com
  Target Milestone: ---

See
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/i386-builtin.def;h=fa123788a8e49a023ea17c69f7cd56ecd3acca47#l1105:

  BDESC (OPTION_MASK_ISA_AVX, 0, CODE_FOR_vec_pack_sfix_v4df,
"__builtin_ia32_vec_pack_sfix256 ", IX86_BUILTIN_VEC_PACK_SFIX256, UNKNOWN,
(int) V8SI_FTYPE_V4DF_V4DF)

There is an extraneous space in the builtin name. Indeed,

  echo '__has_builtin(__builtin_ia32_vec_pack_sfix256)' | cpp -mavx

prints "0".


gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.1.0 (GCC)

[Bug c++/95206] internal compiler error: in sign_mask, at wide-int.h:855

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Dup, fixed on trunk already.  Will be fixed in GCC 10.2 too.

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

[Bug c++/94955] [10 Regression] ICE in to_wide

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||danny.schneider at posteo dot 
de

--- Comment #8 from Marek Polacek  ---
*** Bug 95206 has been marked as a duplicate of this bug. ***

[Bug target/95216] Extra space in __builtin_ia32_vec_pack_sfix256 definition

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I believe that may be intentional, we use spaces or similar chars to avoid them
user accessible.  More recently we use internal functions, but internal
functions aren't target specific.

[Bug rtl-optimization/95210] internal compiler error: in prepare_copy_insn, at gcse.c:1988

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
testcase?

[Bug target/95211] [11 Regression] ICE in emit_unop_insn, at optabs.c:3622

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug c/95217] New: missing -Wunused-but-set-parameter for compound assignment

[msebor at gcc dot gnu.org]

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

Bug ID: 95217
   Summary: missing -Wunused-but-set-parameter for compound
assignment
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC issues -Wunused-but-set-parameter for function arguments used only as the
left operand of ordinary assignment expressions but it fails to diagnose any
other equivalent forms of modifications whose result is unused, including
compound assignment and increment.  It should diagnose all such expressions.

$ cat x.c && gcc -S -Wall -Wextra -Wunused-but-set-parameter x.c
void f8 (int *p)
{
  p = 0;   // -Wunused-but-set-parameter (expected)
}

void f1 (int *p)
{
  p += 1;  // missing warning
}

void f2 (int *p)
{
  p = p + 1;   // missing warning
}

void f3 (int *p)
{
  ++p; // missing warning
}

x.c: In function ‘f8’:
x.c:1:15: warning: parameter ‘p’ set but not used [-Wunused-but-set-parameter]
1 | void f8 (int *p)
  |  ~^

[Bug c++/95202] Assignment to a member is wrongly optimized away by g++ with -fstrict-aliasing

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #1 from Richard Biener  ---
bisection might find the fix

[Bug c/64639] missing warning by -Wunused-value in compound expressions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

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

[Bug c/95217] missing -Wunused-but-set-parameter for compound assignment

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Blocks||89180
 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Martin Sebor  ---
This should probably be handled at the same time as pr64639, so making it a
dupe.

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


Referenced Bugs:

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

[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings

[msebor at gcc dot gnu.org]

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

Bug 95217 Summary: missing -Wunused-but-set-parameter for compound assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95217

   What|Removed |Added

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

[Bug target/95216] Extra space in __builtin_ia32_vec_pack_sfix256 definition

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Yeah, it is intentional.
https://gcc.gnu.org/legacy-ml/gcc-patches/2011-11/msg01027.html

[Bug target/95216] Extra space in __builtin_ia32_vec_pack_sfix256 definition

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
This is an internal only builtin which is created only via the vectorizer.

[Bug c/44677] Warn for variables incremented but not used

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2010-06-28 00:34:58 |2020-5-19

--- Comment #10 from Martin Sebor  ---
See pr95217 for other cases to handle (-Wunused-but-set-parameter).  For the
test case there, Clang's static analyzer diagnoses two out of the four cases:

$ cat pr95217.c && clang -S -Wall -Wextra --analyze pr95217.c
void f0 (int *p)
{
  p = 0;   // -Wunused-but-set-parameter (expected)
}

void f1 (int *p)
{
  p += 1;  // missing warning
}

void f2 (int *p)
{
  p = p + 1;   // missing warning
}

void f3 (int *p)
{
  ++p; // missing warning
}

pr95217.c:8:3: warning: Value stored to 'p' is never read
  p += 1;  // missing warning
  ^~
pr95217.c:13:3: warning: Value stored to 'p' is never read
  p = p + 1;   // missing warning
  ^   ~
2 warnings generated.

[Bug target/95216] Extra space in __builtin_ia32_vec_pack_sfix256 definition

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #4 from Andrew Pinski  ---
.

[Bug target/95218] New: [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test

[msebor at gcc dot gnu.org]

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

Bug ID: 95218
   Summary: [11 Regression] FAIL:
gcc.target/i386/fma_run_double_1.c execution test
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

With yesterday's top of trunk I see the following test failures on
x86_64-linux:

$ grep FAIL gcc/testsuite/gcc/gcc.log | grep fma_run_double
FAIL: gcc.target/i386/fma_run_double_1.c execution test
FAIL: gcc.target/i386/fma_run_double_2.c execution test
FAIL: gcc.target/i386/fma_run_double_3.c execution test
FAIL: gcc.target/i386/fma_run_double_4.c execution test
FAIL: gcc.target/i386/l_fma_run_double_1.c execution test
FAIL: gcc.target/i386/l_fma_run_double_2.c execution test
FAIL: gcc.target/i386/l_fma_run_double_3.c execution test
FAIL: gcc.target/i386/l_fma_run_double_4.c execution test
FAIL: gcc.target/i386/l_fma_run_double_5.c execution test
FAIL: gcc.target/i386/l_fma_run_double_6.c execution test
FAIL: gcc.target/i386/fma_run_double_5.c execution test
FAIL: gcc.target/i386/fma_run_double_6.c execution test

[Bug target/95219] New: [11 Regression] FAIL: gcc.dg/vect/costmodel/x86_64/costmodel-pr30843.c

[msebor at gcc dot gnu.org]

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

Bug ID: 95219
   Summary: [11 Regression] FAIL:
gcc.dg/vect/costmodel/x86_64/costmodel-pr30843.c
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

With yesterday's top of trunk I see the following test failure on x86_64-linux:

spawn -ignore SIGHUP /ssd/test/build/gcc-94923/gcc/xgcc
-B/ssd/test/build/gcc-94923/gcc/
/ssd/test/src/gcc/94923/gcc/testsuite/gcc.dg/vect/costmodel/x86_64/costmodel-pr30843.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O2 -ftree-vectorize
-fvect-cost-model=dynamic -msse2 -fdump-tree-vect-details -S -o
costmodel-pr30843.s
PASS: gcc.dg/vect/costmodel/x86_64/costmodel-pr30843.c (test for excess errors)
gcc.dg/vect/costmodel/x86_64/costmodel-pr30843.c: pattern found 0 times
FAIL: gcc.dg/vect/costmodel/x86_64/costmodel-pr30843.c scan-tree-dump-times
vect "vectorization not profitable" 1

Also seen here:
https://gcc.gnu.org/pipermail/gcc-testresults/2020-May/561528.html

[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Failures also reported here:
https://gcc.gnu.org/pipermail/gcc-testresults/2020-May/561528.html

See also pr95219 for other x86 test regressions seen in the same build.

[Bug c++/95149] lex.c:1729:8: warning: result of comparison against a string literal is unspecified (use an explicit string comparison function instead) [-Wstring-compare]

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell  ---
Fixed ed63c387aa0

[Bug fortran/95109] [11 regression] ICE in gfortran.dg/gomp/target1.f90 after r11-349

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Host|powerpc64*-linux-gnu|powerpc64*-linux-gnu
   ||x86_64-linux
   Last reconfirmed||2020-05-19
 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
Confirmed.  Also reported on x86_64-linux here:
https://gcc.gnu.org/pipermail/gcc-testresults/2020-May/561528.html

[Bug c++/94923] False positive -Wclass-memaccess with trivially copyable std::optional

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:c0d8623ce5aa6d92c2e6c62e1bee66272a011f59

commit r11-499-gc0d8623ce5aa6d92c2e6c62e1bee66272a011f59
Author: Martin Sebor 
Date:   Tue May 19 12:46:37 2020 -0600

PR c++/94923 - False positive -Wclass-memaccess with trivially copyable
std::optional

gcc/cp/ChangeLog:

PR c++/94923
* call.c ((maybe_warn_class_memaccess): Use is_byte_access_type.
* cp-tree.h (is_dummy_object): Return bool.
(is_byte_access_type): Declare new function.
* tree.c (is_dummy_object): Return bool.
(is_byte_access_type): Define new function.

gcc/testsuite/ChangeLog:

PR c++/94923
* g++.dg/Wclass-memaccess.C: Add tests for std::byte.

[Bug c++/95149] lex.c:1729:8: warning: result of comparison against a string literal is unspecified (use an explicit string comparison function instead) [-Wstring-compare]

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
(In reply to Nathan Sidwell from comment #4)
> Fixed ed63c387aa0

g:ed63c387aa0

[Bug target/95211] [11 Regression] ICE in emit_unop_insn, at optabs.c:3622

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-19
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Martin Liška  ---
-EMISSING_TEST_CASE ;)

[Bug target/94591] [8/9/10/11 Regression] Assembler messages: Error: operand mismatch -- `rev64 v0.2d,v0.2d' (or `rev32 v0.2s,v0.2s')

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Alex Coplan :

https://gcc.gnu.org/g:98452668d362bb9e6358f7eb5cff69f4f5ab1d45

commit r11-502-g98452668d362bb9e6358f7eb5cff69f4f5ab1d45
Author: Alex Coplan 
Date:   Tue May 19 20:33:20 2020 +0100

[aarch64] PR target/94591: Don't generate invalid REV64 insns

This fixes PR94591. The problem was the function aarch64_evpc_rev_local()
matching vector permutations that were not reversals. In particular, prior
to
this patch, this function matched the identity permutation which led to
generating bogus REV64 insns which were rejected by the assembler.

gcc/
PR target/94591
* config/aarch64/aarch64.c (aarch64_evpc_rev_local): Don't match
identity permutation.

gcc/testsuite/
PR target/94591
* gcc.c-torture/execute/pr94591.c: New test.

[Bug libgcc/95220] New: Incorrect GFNI dectection

[hjl.tools at gmail dot com]

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

Bug ID: 95220
   Summary: Incorrect GFNI dectection
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: i386, x86-64

get_available_features in libgcc/config/i386/cpuinfo.c has

 if (avx512_usable)
{
...
  if (ecx & bit_GFNI)
set_feature (FEATURE_GFNI);

But GFNI is independent of A X512.  There are processors with SSE, AVX and
AVX512 versions of GFNI:


const wide_int_bitmask PTA_TREMONT = PTA_GOLDMONT_PLUS | PTA_CLWB
  | PTA_GFNI;

[Bug middle-end/24786] Missing warning on questionable use of parameter to initialize static

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=82520,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=69433
 Blocks||90556
 CC||msebor at gcc dot gnu.org
   Last reconfirmed|2015-09-18 00:00:00 |2020-5-19

--- Comment #4 from Martin Sebor  ---
Reconfirming that a warning for this and other similar cases (e.g., pr82520 and
pr69433) would be valuable.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90556
[Bug 90556] [meta-bug] bogus/missing -Wreturn-local-addr

[Bug middle-end/31279] Uninitialized warning for call-by-reference arguments with known intent(in)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
In conjunction with attribute access (read_only) (which I presume is the moral
equivalent of INTENT(IN)), the patch I submitted for pr10138 puts in place the
infrastructure to implement this warning for FORTRAN as well.  All that it
should need is mapping INTENT(IN) to the attribute.

https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545856.html

[Bug c++/95221] New: g++.dg/ubsan/vptr-12.C fails with -fstrong-eval-order=all

[mpolacek at gcc dot gnu.org]

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

Bug ID: 95221
   Summary: g++.dg/ubsan/vptr-12.C fails with
-fstrong-eval-order=all
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

It's this code:

struct MyClass
{
  virtual ~MyClass () {}
  virtual void Doit () {}
};

int
main ()
{
  MyClass *c = new MyClass;
  c->~MyClass ();
  c->Doit ();

  return 0;
}

$ g++ vptr-12.C -fsanitize=vptr -fno-sanitize-recover=vptr
-fstrong-eval-order=some; ./a.out
vptr-12.C:16:11: runtime error: member call on address 0x00a25eb0 which
does not point to an object of type 'MyClass'
0x00a25eb0: note: object has invalid vptr
 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00
00 00 00  41 f1 00 00
  ^~~
  invalid vptr

but

$ g++ vptr-12.C -fsanitize=vptr -fno-sanitize-recover=vptr
-fstrong-eval-order=all; ./a.out
Segmentation fault (core dumped)

This is important because C++17 implies -fstrong-eval-order=all.

[Bug testsuite/39353] Linker warning causing tests to fail (960218 and 20030913)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-19
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #2 from Martin Sebor  ---
I suspect this is too old to be relevant anymore.  If it's still a problem can
you please update the report with fresh details?

[Bug target/94591] [8/9/10/11 Regression] Assembler messages: Error: operand mismatch -- `rev64 v0.2d,v0.2d' (or `rev32 v0.2s,v0.2s')

[acoplan at gcc dot gnu.org]

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

Alex Coplan  changed:

   What|Removed |Added

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

--- Comment #4 from Alex Coplan  ---
This is now fixed on master, although the fix will need backporting.

[Bug c++/95221] g++.dg/ubsan/vptr-12.C fails with -fstrong-eval-order=all

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
It is caused by this code:

 853   if (flag_strong_eval_order == 2
 854   && CALL_EXPR_FN (*expr_p)
 855   && cp_get_callee_fndecl_nofold (*expr_p) == NULL_TREE)
 856 {
 857   tree fnptrtype = TREE_TYPE (CALL_EXPR_FN (*expr_p));
 858   enum gimplify_status t
 859 = gimplify_to_rvalue (&CALL_EXPR_FN (*expr_p), pre_p, NULL,
 860   is_gimple_call_addr);
 861   if (t == GS_ERROR)
 862 ret = GS_ERROR;
 863   /* GIMPLE considers most pointer conversion useless, but for
 864  calls we actually care about the exact function pointer type.
 */
 865   else if (TREE_TYPE (CALL_EXPR_FN (*expr_p)) != fnptrtype)
 866 CALL_EXPR_FN (*expr_p)
 867   = build1 (NOP_EXPR, fnptrtype, CALL_EXPR_FN (*expr_p));
 868 }

and causes this difference:

--- 1g  2020-05-19 11:42:32.123168379 -0400
+++ 2g  2020-05-19 11:42:41.254133594 -0400
@@ -18,21 +18,21 @@
 operator delete (D.2725, 8);
   }
 c = D.2725;
+_1 = c->_vptr.MyClass;
+_2 = *_1;
 c.0 = c;
-_1 = c.0->_vptr.MyClass;
-_2 = (long unsigned int) _1;
-.UBSAN_VPTR (c.0, _2, 2968783897514143607, &_ZTI7MyClass, 4B);
-_3 = c->_vptr.MyClass;
-_4 = *_3;
-OBJ_TYPE_REF(_4;(struct MyClass)c->0) (c.0);
+_3 = c.0->_vptr.MyClass;
+_4 = (long unsigned int) _3;
+.UBSAN_VPTR (c.0, _4, 2968783897514143607, &_ZTI7MyClass, 4B);
+OBJ_TYPE_REF(_2;(struct MyClass)c->0) (c.0);
+_5 = c->_vptr.MyClass;
+_6 = _5 + 16;
+_7 = *_6;
 c.1 = c;
-_5 = c.1->_vptr.MyClass;
-_6 = (long unsigned int) _5;
-.UBSAN_VPTR (c.1, _6, 2968783897514143607, &_ZTI7MyClass, 4B);
-_7 = c->_vptr.MyClass;
-_8 = _7 + 16;
-_9 = *_8;
-OBJ_TYPE_REF(_9;(struct MyClass)c->2) (c.1);
+_8 = c.1->_vptr.MyClass;
+_9 = (long unsigned int) _8;
+.UBSAN_VPTR (c.1, _9, 2968783897514143607, &_ZTI7MyClass, 4B);
+OBJ_TYPE_REF(_7;(struct MyClass)c->2) (c.1);
 D.2751 = 0;
 return D.2751;
   }

[Bug middle-end/24786] Missing warning on questionable use of parameter to initialize static

[dank at kegel dot com]

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

dank at kegel dot com changed:

   What|Removed |Added

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

--- Comment #5 from dank at kegel dot com ---
Methinks it's been fixed:

$ gcc --version
gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0

$ gcc -c blah.c
blah.c: In function ‘blah1’:
blah.c:3:11: warning: function returns address of local variable
[-Wreturn-local-addr]
3 |return &x;
  |   ^~
blah.c: In function ‘blah2’:
blah.c:8:36: error: initializer element is not constant
8 |static const char *names[1] = { &x };
  |^
blah.c:8:36: note: (near initialization for ‘names[0]’)

Also fixed with:

gcc-6 (Ubuntu 6.5.0-2ubuntu1) 6.5.0 20181026

Marking fixed.

But see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69433

[Bug other/90556] [meta-bug] bogus/missing -Wreturn-local-addr

[dank at kegel dot com]

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

Bug 24786 Summary: Missing warning on questionable use of parameter to 
initialize static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24786

   What|Removed |Added

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