[Bug c++/95226] Faulty aggregate initialization of vector with struct with float

[fboranek at gmail dot com]

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

--- Comment #1 from Frantisek Boranek  ---
Luckily, the behaviour is the same on old stable Stretch as on Buster. So this
version is also affected, but it is probably not serious as was my first
impression.

gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516

[Bug lto/95224] -flto -save-temps uses very unusual name for resolution file, looks arbitrary

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
ISTR seeing dups about this.  We seem to be happy to pick anything remotely
resembling a linker output as basename (-lm here).

Alex, do your patches change anything here?

[Bug c++/95222] [10/11 Regression] GCC 10.1 x86 issue with function pointers with calling convention attribute and template specialization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|GCC 10.1 x86 issue with |[10/11 Regression] GCC 10.1
   |function pointers with  |x86 issue with function
   |calling convention  |pointers with calling
   |attribute and template  |convention attribute and
   |specialization  |template specialization
   Target Milestone|--- |10.2
 Target||x86_64-*-* i?86-*-*
   Keywords||needs-bisection,
   ||rejects-valid

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

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Coalesce list: (4)ivtmp.15_4 & (22)ivtmp.15_22 [map: 2, 9] : Success -> 2
Coalesce list: (1)vect_vec_iv_.7_1 & (19)_19 [map: 0, 7] : Success -> 0
Coalesce list: (17)_17 & (18)vect_vec_iv_.8_18 [map: 5, 6] : Success -> 5
Coalesce list: (1)vect_vec_iv_.7_1 & (10)vect_vec_iv_.7_10 [map: 0, 4] : Fail
due to conflict
Coalesce list: (2)vect_vec_iv_.8_2 & (18)_17 [map: 1, 5] : Fail due to conflict
Coalesce list: (4)ivtmp.15_4 & (21)ivtmp.15_21 [map: 2, 8] : Success -> 2

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  ivtmp.15_21 = (unsigned long) pBuffer_5(D);
  _12 = ivtmp.15_21 + 8192;
;;succ:   3

;;   basic block 3, loop depth 1
;;pred:   2
;;3
  # vect_vec_iv_.7_1 = PHI <{ 0, 0 }(2), _19(3)>
  # vect_vec_iv_.8_18 = PHI <{ 0, 0 }(2), _17(3)>
  # ivtmp.15_4 = PHI 
  vect_vec_iv_.7_10 = vect_vec_iv_.7_1;
  _19 = vect_vec_iv_.7_1 + { 16843009, 16843009 };
  vect_vec_iv_.8_2 = vect_vec_iv_.8_18;
  _17 = vect_vec_iv_.8_18 + { 16843009, 16843009 };
  _20 = (void *) ivtmp.15_4;
  MEM[base: _20, offset: 0B] = vect_vec_iv_.7_10;
  MEM[base: _20, offset: 16B] = vect_vec_iv_.8_2;
  ivtmp.15_22 = ivtmp.15_4 + 32;
  if (_12 != ivtmp.15_22)
goto ; [99.00%]
  else
goto ; [1.00%]
;;succ:   3
;;4

ah, so coalescing is hindered by "scheduling" here.  -fschedule-insns
gets rid of one of the copies.

Not vectorized code looks like

.L2:
movq%rax, (%rdi)
addq$32, %rdi
movq%rax, -24(%rdi)
movq%rax, -16(%rdi)
movq%rax, -8(%rdi)
addq$16843009, %rax
cmpq%rdx, %rax
jne .L2

btw. which is likely slower (so the testcase itself is easy to fix).

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-20
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Richard Biener  ---
I think this one is a bit older though (IIRC it was disabled before due to a
testsuite bug).  Vectorization _is_ clearly profitable - we're now using SLP
(possibly since that got induction support):

  Vector inside of loop cost: 24
  Vector prologue cost: 0
  Vector epilogue cost: 0
  Scalar iteration cost: 48
  Scalar outside cost: 0
  Vector outside cost: 0
  prologue iterations: 0
  epilogue iterations: 0
  Calculated minimum iters for profitability: 0

vectorized to

.L2:
movdqa  %xmm0, %xmm4
movdqa  %xmm1, %xmm3
paddq   %xmm2, %xmm0
addq$32, %rdi
movups  %xmm4, -32(%rdi)
paddq   %xmm2, %xmm1
movups  %xmm3, -16(%rdi)
cmpq%rdi, %rax
jne .L2

there's a missed optimization in that we choose two (identical) IVs for
the induction (late FRE is in "simple" mode and thus does not get rid of those
as equivalent) and that we have odd IVs (the extra moves), possibly
out-of-SSA cannot coalesce because of the constants:

  # vect_vec_iv_.7_1 = PHI <{ 0, 0 }(2), _19(3)>
  # vect_vec_iv_.8_18 = PHI <{ 0, 0 }(2), _17(3)>

and tricks maybe do not apply because of vector types.  I'll take this bug.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-20
 Ever confirmed|0   |1
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW

--- Comment #2 from Richard Biener  ---
Confirmed, also see this.

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

[roland.illig at gmx dot de]

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

--- Comment #10 from Roland Illig  ---
(In reply to Steve Kargl from comment #9)
> That could work.  I'm still trying to understand how an
> option names -Werror=char-subscripts could trigger an
> error.  There are no subscripts.

The C standard allows every library function to also be defined as a macro.
This also applies to the functions from .

The typical implementation of the  functions is:

extern int __ctype_classes[1 /* for EOF */ + UCHAR_MAX];

int isalpha(int ch) {
  return (__ctype_classes + 1)[ch] & 0x0008;
}

The corresponding macro is defined like this:

#define isalpha(ch) ((__ctype_classes + 1)[(ch)] & 0x0008)

That's where the subscript comes from.

The macro has no implicit type conversion (at least on NetBSD; the GNU libc may
differ) and thus produces the warning.

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

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-05-20
 Status|UNCONFIRMED |NEW

--- Comment #6 from Jason Merrill  ---
(In reply to Marek Polacek from comment #2)
> I think the thing is that we have a CALL_EXPR, something like
> 
>   OBJ_TYPE_REF (...) (.UBSAN_VPTR ())
> 
> and now we first evaluate the OBJ_TYPE_REF.

Yep, that's the problem.

We're currently sanitizing the vtable when determining the 'this' argument to
the function, separately from looking at the vtable in order to determine which
function to call.  In C++14 we evaluate 'this' first, in C++17 we evaluate the
function first.  build_over_call tries to share any side-effects between the
'this' and the OBJ_TYPE_REF with a save_expr, but then
cp_ubsan_maybe_instrument_member_call adds the sanitization only to the 'this'
argument, breaking that sharing and introducing a fragile order dependency.

A simple fix might be to not preevaluate when CALL_EXPR_FN is an OBJ_TYPE_REF,
as the sharing above should mean that side-effects happen when the object
argument is evaluated, which should be what we want.  It occurs to me that the
current preevaluation is wrong for a virtual assignment when
CALL_EXPR_REVERSE_ARGS is set.

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

[crazylht at gmail dot com]

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

--- Comment #16 from Hongtao.liu  ---
(In reply to Uroš Bizjak from comment #15)
> 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.

I'll take a look.

[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 #9 from Steve Kargl  ---
On Wed, May 20, 2020 at 04:10:50AM +, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95177
> 
> Thomas Koenig  changed:
> 
>What|Removed |Added
> 
>  Ever confirmed|0   |1
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2020-05-20
> 
> --- Comment #8 from Thomas Koenig  ---
> Alternatively, it might make sense to change some variable types to
> GFC_UINTEGER_1 aka unsigned char.
> 

That could work.  I'm still trying to understand how an
option names -Werror=char-subscripts could trigger an
error.  There are no subscripts.  AFAIK, the patched 
routines are not general purpose routines, so the char
arguments can only take on values from the Fortran
character set, which is a subset of the 7-bit ASCII
set.  

Just commit the patch.  I've wasted too much time trying
to get an answer about how the option works.  Nothing
like cluttering working code.

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

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-05-20

--- Comment #8 from Thomas Koenig  ---
Alternatively, it might make sense to change some variable types to
GFC_UINTEGER_1 aka unsigned char.

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

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #7 from Thomas Koenig  ---
As a matter of style, I do not like random casts, they clutter the code and
make
adhering to the 80 character line limit even more of a pain.

A macro might be better here, or a function safe_toupper.

[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value

[ppalka at gcc dot gnu.org]

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

--- Comment #5 from Patrick Palka  ---
Candidate patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546106.html

[Bug tree-optimization/95199] Remove extra variable created for memory reference in loop vectorization.

[zhoukaipeng3 at huawei dot com]

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

--- Comment #2 from Kaipeng Zhou  ---
It seems that IVOPTs has no ability to handle the case where TREE_CODE(iv_step)
is SSA_NAME.

[Bug target/95228] New: Failure to optimize register allocation around atomic loads/stores

[gabravier at gmail dot com]

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

Bug ID: 95228
   Summary: Failure to optimize register allocation around atomic
loads/stores
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

int x;
int y;

int f()
{
int ret;
__atomic_load(&y, &ret, 0);
int val = 0;
__atomic_store(&y, &val, 5);
return ret;
}

With -O3, GCC outputs this :

f():
  mov r8d, DWORD PTR y[rip]
  xor eax, eax
  xchg eax, DWORD PTR y[rip]
  mov eax, r8d
  ret

LLVM outputs this :

f(): # @f()
  mov eax, dword ptr [rip + .Ly$local]
  xor ecx, ecx
  xchg dword ptr [rip + .Ly$local], ecx
  ret

eax can be replaced with ecx in the store to avoid having to store the load of
y into a seperate register.

[Bug target/95227] New: vec_extract doesn't mark input as used in C++ mode

[e...@coeus-group.com]

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

Bug ID: 95227
   Summary: vec_extract doesn't mark input as used in C++ mode
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: e...@coeus-group.com
  Target Milestone: ---

Pretty straightforward.  With -maltivec -Wunused-but-set-parameter, this works
in C but emits a diagnostic in C++:

  #include 
  int f(vector int b) {
return vec_extract(b, 0);
  }

FWIW, the same problem happens if b is a local variable not a parameter, though
of course it will emit an unused-but-set-variable diagnostic instead.

[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value

[seurer at linux dot vnet.ibm.com]

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

--- Comment #4 from Bill Seurer  ---
It was definitely r11-477.  I see this causing an ICE when building gcc albeit
only on power 9.

[Bug c++/95226] New: Faulty aggregate initialization of vector with struct with float

[fboranek at atlas dot cz]

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

Bug ID: 95226
   Summary: Faulty aggregate initialization of vector with struct
with float
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fboranek at atlas dot cz
  Target Milestone: ---

# Steps to reproduce

//prog.cc

#include 
#include 

struct T {
uint32_t a;
float b {.8};
};

int main()
{
T t = {1};
std::vector tt = {{1}, {2}};

std::cout << t.a << ", " << t.b << std::endl;
std::cout << tt[0].a << ", " << tt[0].b << std::endl;
std::cout << tt[1].a << ", " << tt[1].b << std::endl;
}

// g++ prog.cc -Wall -Wextra -std=c++17

For gcc 9.3.0, 9.2.0, 9.1.0, 8.1.0 the behavior is correct and output of the
program is:

1, 0.8
1, 0.8
1, 0.8

For gcc 8.3.0, 8.2.0 the output of the program is:

1, 0.8
1, -1.58819e-23
1072273817, 2.8026e-45

The second object in the vector is wrongly initialized.

The code can be fixed by changing of initialization of float T::b to {.8f}, {0}
or {}. It seems that only initialization by double is affected.
I used wandbox.org to test diffrent version of gcc and prevous and newer
version are OK. It sound like regression in 8.3.0 and 8.2.0, but 8.3.0 is in a
current stable Debian, which worried me.


# Used gcc from Debina Buster (current stable)
gcc (Debian 8.3.0-6) 8.3.0

[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug libgcc/95220] Incorrect GFNI dectection

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
Fixed for GCC 11, GCC 10.2 and GCC 9.4.

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

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #3 from H.J. Lu  ---
Fixed for GCC 11 and 10.2.

[Bug libgcc/95220] Incorrect GFNI dectection

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-10 branch has been updated by H.J. Lu :

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

commit r10-8158-ge54fa81e16eb5633ed09c816311135ecc434f105
Author: H.J. Lu 
Date:   Tue May 19 14:42:12 2020 -0700

x86: Add FEATURE_AVX512VP2INTERSECT and update GFNI check

Add FEATURE_AVX512VP2INTERSECT to libgcc so that enum processor_features
in libgcc matches enum processor_features in i386-builtins.c.  Update
GFNI check to support processors with SSE and AVX versions of GFNI.

Backport from master
PR target/95212
PR target/95220
* config/i386/cpuinfo.c (get_available_features): Fix
FEATURE_GFNI check.  Also check FEATURE_AVX512VP2INTERSECT.
* config/i386/cpuinfo.h (processor_features): Add
FEATURE_AVX512VP2INTERSECT.

[Bug libgcc/95220] Incorrect GFNI dectection

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-9 branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:2c7b747995a687d513dddfeafa54c6af4d10dc17

commit r9-8606-g2c7b747995a687d513dddfeafa54c6af4d10dc17
Author: H.J. Lu 
Date:   Tue May 19 14:42:12 2020 -0700

x86: Update GFNI check

Update GFNI check to support processors with SSE and AVX versions of GFNI.

Backport from master
PR target/95220
* config/i386/cpuinfo.c (get_available_features): Fix
FEATURE_GFNI check.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-10 branch has been updated by H.J. Lu :

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

commit r10-8158-ge54fa81e16eb5633ed09c816311135ecc434f105
Author: H.J. Lu 
Date:   Tue May 19 14:42:12 2020 -0700

x86: Add FEATURE_AVX512VP2INTERSECT and update GFNI check

Add FEATURE_AVX512VP2INTERSECT to libgcc so that enum processor_features
in libgcc matches enum processor_features in i386-builtins.c.  Update
GFNI check to support processors with SSE and AVX versions of GFNI.

Backport from master
PR target/95212
PR target/95220
* config/i386/cpuinfo.c (get_available_features): Fix
FEATURE_GFNI check.  Also check FEATURE_AVX512VP2INTERSECT.
* config/i386/cpuinfo.h (processor_features): Add
FEATURE_AVX512VP2INTERSECT.

[Bug c++/86142] hard error for bad delete-expression in SFINAE context

[ensadc at mailnesia dot com]

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

ensadc at mailnesia dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||10.1.0
  Known to fail||9.3.0
 Resolution|--- |FIXED

--- Comment #3 from ensadc at mailnesia dot com ---
Fixed in GCC 10

[Bug target/94087] std::random_device often fails when used from multiple threads

[cvs-commit at gcc dot gnu.org]

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

--- Comment #24 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r11-506-ga2d196e75cef95c2b70734ad02e94f9da0e769fe
Author: Jonathan Wakely 
Date:   Tue May 19 16:49:21 2020 +0100

libstdc++: Use RDRAND as fallback if RDSEED keeps failing (PR 94087)

It's not difficult for multiple threads to drain the entropy available
to the RDSEED instruction, at which point we throw an exception. This
change will try to use RDRAND after RDSEED fails repeatedly, and only
throw if RDRAND also fails repeatedly. This doesn't guarantee a random
value can always be read, but reduces the likelihood of failure when
using the RDSEED instruction.

PR libstdc++/94087
* src/c++11/random.cc (__x86_rdseed): Allow fallback function to be
passed in.
(__x86_rdseed_rdrand): New function that uses rdseed with rdrand
fallback.
(random_device::_M_init): Use __x86_rdseed_rdrand when both
instructions are available.
* testsuite/26_numerics/random/random_device/94087.cc: New test.

[Bug c++/95225] [11 regression] build failure (ICE) starting with r11-477

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
.

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

[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||seurer at linux dot 
vnet.ibm.com

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

[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW
 CC||ppalka at gcc dot gnu.org
   Last reconfirmed||2020-05-19
   Keywords||ice-checking
 Ever confirmed|0   |1

--- Comment #2 from Patrick Palka  ---
Confirmed.  Very likely caused by my r11-477.

[Bug c++/95225] New: [11 regression] build failure (ICE) starting with r11-477

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 95225
   Summary: [11 regression] build failure (ICE) starting with
r11-477
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

g:573e5f0500968dcf4025b8fc0ae5fb367f9c70d9, r11-477 

r11-476 worked fine.

While building the compiler:

/bin/sh ../../libtool --tag CXX --tag disable-shared   --mode=compile
/home/spectester/build/nightly/build-gcc-trunk/./gcc/xgcc -shared-libgcc
-B/home/spectester/build/nightly/build-gcc-trunk/./gcc -nostdinc++
-L/home/spectester/build/nightly/build-gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/src
-L/home/spectester/build/nightly/build-gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/spectester/build/nightly/build-gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/opt/gcc-spec-nightly/trunk/powerpc64le-unknown-linux-gnu/bin/
-B/opt/gcc-spec-nightly/trunk/powerpc64le-unknown-linux-gnu/lib/ -isystem
/opt/gcc-spec-nightly/trunk/powerpc64le-unknown-linux-gnu
/include -isystem
/opt/gcc-spec-nightly/trunk/powerpc64le-unknown-linux-gnu/sys-include   
-I/home/spectester/gcc_trunk_git/gcc/libstdc++-v3/../libgcc
-I/home/spectester/build/nightly/build-gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/spectester/build/nightly/build-gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/spectester/gcc_trunk_git/gcc/libstdc++-v3/libsupc++   -std=gnu++98
-prefer-pic -D_GLIBCXX_SHARED -fno-implicit-templates  -Wall -Wextra
-Wwrite-strings -Wcast-qual -Wabi=2  -fdiagnostics-show-location=once  
-ffunction-sections -fdata-sections  -frandom-seed=tree.lo -g -O2 -D_GNU_SOURCE
 -c -o tree.lo
/home/spectester/gcc_trunk_git/gcc/libstdc++-v3/src/c++98/tree.cc
libtool: compile:  /home/spectester/build/nightly/build-gcc-trunk/./gcc/xgcc
-shared-libgcc -B/home/spectester/build/nightly/build-gcc-trunk/./gcc
-nostdinc++
-L/home/spectester/build/nightly/build-gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/src
-L/home/spectester/build/nightly/build-gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/spectester/build/nightly/build-gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/opt/gcc-spec-nightly/trunk/powerpc64le-unknown-linux-gnu/bin/
-B/opt/gcc-spec-nightly/trunk/powerpc64le-unknown-linux-gnu/lib/ -isystem
/opt/gcc-spec-nightly/trunk/powerpc64le-unknown-linux-gnu/include -isystem
/opt/gcc-spec-nightly/trunk/powerpc64le-unknown-linux-gnu/sys-include
-I/home/spectester/gcc_trunk_git/gcc/libstdc++-v3/../libgcc
-I/home/spectester/build/nightly/build-gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/spectester/build/nightly/build-gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/spectester/gcc_trunk_git/gcc/libstdc++-v3/libsupc++ -std=gnu++98
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=tree.lo -g -O2 -D_GNU_SOURCE -c
/home/spectester/gcc_trunk_git/gcc/libstdc++-v3/src/c++98/tree.cc  -fPIC -DPIC
-D_GLIBCXX_SHARED -o tree.o
hash table checking failed: equal operator returns true for a pair of values
with a different hash value
In file included from
/home/spectester/gcc_trunk_git/gcc/libstdc++-v3/src/c++98/tree.cc:53:
/home/spectester/build/nightly/build-gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/stl_tree.h:2092:49:
internal compiler error: in hashtab_chk_error, at hash-table.c:137
 2092 | _M_get_insert_unique_pos(const key_type& __k)
  | ^
0x1027c2e7 hashtab_chk_error()
/home/spectester/gcc_trunk_git/gcc/gcc/hash-table.c:137
0x105a1da7 hash_table::verify(spec_entry*
const&, unsigned int)
/home/spectester/gcc_trunk_git/gcc/gcc/hash-table.h:1033
0x105a1fbf hash_table::find_with_hash(spec_entry* const&, unsigned int)
/home/spectester/gcc_trunk_git/gcc/gcc/hash-table.h:934
0x10538ccf lookup_template_class_1
/home/spectester/gcc_trunk_git/gcc/gcc/cp/pt.c:9776
0x10538ccf lookup_template_class(tree_node*, tree_node*, tree_node*,
tree_node*, int, int)
/home/spectester/gcc_trunk_git/gcc/gcc/cp/pt.c:10115
0x1053c897 tsubst_aggr_type
/home/spectester/gcc_trunk_git/gcc/gcc/cp/pt.c:13369
0x1054a1b7 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/spectester/gcc_trunk_git/gcc/gcc/cp/pt.c:15250
0x1054dae3 maybe_update_decl_type(tree_node*, tree_node*)
/home/spectester/gcc_trunk_git/gcc/gcc/cp/pt.c:4858
0x104eec4f cp_parser_init_declarator
/home/spectester/gcc_trunk_git/gcc/gcc/cp/parser.c:2059

[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 #5 from Marek Polacek  ---
You're not wrong, but here we're dealing with the undefined behavior sanitizer
whose point is to detect broken code like the above.

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

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||jakub at gcc dot gnu.org

--- Comment #3 from Uroš Bizjak  ---
Confirmed.

sse.md includes a named pattern defined with non-conforming operands:

(define_expand "floatv2div2sf2"
  [(set (match_operand:V4SF 0 "register_operand" "=v")
(vec_concat:V4SF
(any_float:V2SF (match_operand:V2DI 1 "nonimmediate_operand" "vm"))
(match_dup 2)))]
  "TARGET_AVX512DQ && TARGET_AVX512VL"
  "operands[2] = CONST0_RTX (V2SFmode);")

V2SF vectorization now triggers this expander.

CC author.

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

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
Is this code even defined?
We call a method after calling the deconstructor on the object?
If we do:
 c->~MyClass ();
 new(c) MyClass();
 c->Doit ();

Then it is defined.

Or am I wrong about that?

[Bug lto/95224] New: -flto -save-temps uses very unusual name for resolution file, looks arbitrary

[slyfox at inbox dot ru]

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

Bug ID: 95224
   Summary: -flto -save-temps uses very unusual name for
resolution file, looks arbitrary
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at inbox dot ru
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org,
rguenth at gcc dot gnu.org
  Target Milestone: ---

Encountered when was debugging lto/95194.

Reproducer:

  # good
  $ rm -- *; echo 'int main(){}' | gcc -c -x c -flto - -o main.o; gcc main.o -o
main -flto -save-temps; ls -- *.res
  main.res

  # unexpected
  $ rm -- *; echo 'int main(){}' | gcc -c -x c -flto - -o main.o; gcc main.o -o
main -flto -save-temps -lm; ls -- *.res
  -lm.res

Expected behaviour: always get 'main.res' resolution file.

In real scenario I was building 'genmatch' and got '-lm.res'. It confused me
quite a bit: I explored very strange possibilities: driver did not recognize
-lm as a library, '-lm.res' is not the only response file out there, etc.

Would it be reasonable for response file to always use the same basename as
'-o' paramemter?

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:453954451be68d22462442268a29f54809182d2b

commit r11-505-g453954451be68d22462442268a29f54809182d2b
Author: H.J. Lu 
Date:   Tue May 19 14:42:12 2020 -0700

x86: Add FEATURE_AVX512VP2INTERSECT and update GFNI check

Add FEATURE_AVX512VP2INTERSECT to libgcc so that enum processor_features
in libgcc matches enum processor_features in i386-builtins.c.  Update
GFNI check to support processors with SSE and AVX versions of GFNI.

PR target/95212
PR target/95220
* config/i386/cpuinfo.c (get_available_features): Fix
FEATURE_GFNI check.  Also check FEATURE_AVX512VP2INTERSECT.
* config/i386/cpuinfo.h (processor_features): Add
FEATURE_AVX512VP2INTERSECT.

[Bug libgcc/95220] Incorrect GFNI dectection

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:453954451be68d22462442268a29f54809182d2b

commit r11-505-g453954451be68d22462442268a29f54809182d2b
Author: H.J. Lu 
Date:   Tue May 19 14:42:12 2020 -0700

x86: Add FEATURE_AVX512VP2INTERSECT and update GFNI check

Add FEATURE_AVX512VP2INTERSECT to libgcc so that enum processor_features
in libgcc matches enum processor_features in i386-builtins.c.  Update
GFNI check to support processors with SSE and AVX versions of GFNI.

PR target/95212
PR target/95220
* config/i386/cpuinfo.c (get_available_features): Fix
FEATURE_GFNI check.  Also check FEATURE_AVX512VP2INTERSECT.
* config/i386/cpuinfo.h (processor_features): Add
FEATURE_AVX512VP2INTERSECT.

[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|libstdc++   |c++

--- Comment #1 from Jonathan Wakely  ---
This is a compiler crash, so it's not a libstdc++ bug.

[Bug c++/69433] missing -Wreturn-local-addr assigning address of a local to a static

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||dank at kegel dot com

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

[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

 Resolution|FIXED   |DUPLICATE

--- Comment #6 from Martin Sebor  ---
Not fixed yet.  There is no warning for blah2() returning the address of the
local variable.  pr69433 includes a test case for the same thing:

  const char* f2 () {
const char a[] = "abc";
static const char *s = a;
return s;
  }

so this report can be resolved as a duplicate of that one.

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

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

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

Bug 53890 Summary: bogus array bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53890

   What|Removed |Added

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

[Bug middle-end/53890] bogus array bounds warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||4.8.5
  Known to work||5.5.0
 Blocks||56456
 Status|UNCONFIRMED |RESOLVED
   Keywords||diagnostic
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Martin Sebor  ---
Fixed by commit f101c4b47a98c98238bbf31a7ee79b1b2e4cce7b

Author: Richard Biener 
Date:   Tue Jan 27 09:49:29 2015 +

re PR tree-optimization/56273 (Bogus -Warray-bounds warning)

2015-01-27  Richard Biener  

PR tree-optimization/56273
PR tree-optimization/59124
PR tree-optimization/64277
* tree-vrp.c (vrp_finalize): Emit array-bound warnings only
from the first VRP pass.

* g++.dg/warn/Warray-bounds-6.C: New testcase.
* gcc.dg/Warray-bounds-12.c: Likewise.
* gcc.dg/Warray-bounds-13.c: Likewise.

From-SVN: r220157


Referenced Bugs:

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

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

[rafael at espindo dot la]

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

--- Comment #8 from Rafael Avila de Espindola  ---
I can confirm that the proposed patch fixes the issue for me.

Thank you so much!

[Bug libstdc++/95223] New: [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value

[dimhen at gmail dot com]

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

Bug ID: 95223
   Summary: [11 regression] hash table checking failed: equal
operator returns true for a pair of values with a
different hash value
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
  Target Milestone: ---

r11-459 PASS
r11-495 FAIL

$ cat x.cpp
struct s { } a;
struct b;
#include 
#include 

$ g++ -std=c++98 x.cpp
hash table checking failed: equal operator returns true for a pair of values
with a different hash value
In file included from
/home/dimhen/arch-gcc/gcc_current/include/c++/11.0.0/map:60,
 from x.cpp:4:
/home/dimhen/arch-gcc/gcc_current/include/c++/11.0.0/bits/stl_tree.h:2149:37:
internal compiler error: in hashtab_chk_error, at hash-table.c:137
 2149 | _M_insert_unique(const _Val& __v)
  | ^
0xab76f2 hashtab_chk_error()
/home/dimhen/src/gcc_current/gcc/hash-table.c:137
0xc7b73d hash_table::verify(spec_entry*
const&, unsigned int)
/home/dimhen/src/gcc_current/gcc/hash-table.h:1033
0xc7b889 hash_table::find_with_hash(spec_entry* const&, unsigned int)
/home/dimhen/src/gcc_current/gcc/hash-table.h:934
0xc62f0d lookup_template_class_1
/home/dimhen/src/gcc_current/gcc/cp/pt.c:9776
0xc65213 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/home/dimhen/src/gcc_current/gcc/cp/pt.c:10115
0xc65213 tsubst_aggr_type
/home/dimhen/src/gcc_current/gcc/cp/pt.c:13369
0xc5f7f1 maybe_update_decl_type(tree_node*, tree_node*)
/home/dimhen/src/gcc_current/gcc/cp/pt.c:4858
0xc18263 cp_parser_init_declarator
/home/dimhen/src/gcc_current/gcc/cp/parser.c:20595
0xc1f8d4 cp_parser_single_declaration
/home/dimhen/src/gcc_current/gcc/cp/parser.c:29490
0xc1fa4b cp_parser_template_declaration_after_parameters
/home/dimhen/src/gcc_current/gcc/cp/parser.c:29062
0xc201a0 cp_parser_explicit_template_declaration
/home/dimhen/src/gcc_current/gcc/cp/parser.c:29328
0xc231e9 cp_parser_declaration
/home/dimhen/src/gcc_current/gcc/cp/parser.c:13388
0xc22dd2 cp_parser_toplevel_declaration
/home/dimhen/src/gcc_current/gcc/cp/parser.c:13467
0xc22dd2 cp_parser_declaration_seq_opt
/home/dimhen/src/gcc_current/gcc/cp/parser.c:13315
0xc22dd2 cp_parser_namespace_body
/home/dimhen/src/gcc_current/gcc/cp/parser.c:19723
0xc22dd2 cp_parser_namespace_definition
/home/dimhen/src/gcc_current/gcc/cp/parser.c:19701
0xc231d8 cp_parser_declaration
/home/dimhen/src/gcc_current/gcc/cp/parser.c:13419
0xc2381a cp_parser_translation_unit
/home/dimhen/src/gcc_current/gcc/cp/parser.c:4725
0xc2381a c_parse_file()
/home/dimhen/src/gcc_current/gcc/cp/parser.c:43976
0xd384ab c_common_parse_file()
/home/dimhen/src/gcc_current/gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/95222] GCC 10.1 x86 issue with function pointers with calling convention attribute and template specialization

[raptorfactor at raptorfactor dot com]

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

--- Comment #1 from raptorfactor at raptorfactor dot com ---
$ g++ -v
Using built-in specs.
COLLECT_GCC=C:\Redacted\msys2-x86_64-rolling\mingw32\bin\g++.exe
COLLECT_LTO_WRAPPER=C:/Redacted/msys2-x86_64-rolling/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.1.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc-10.1.0/configure --prefix=/mingw32
--with-local-prefix=/mingw32/local --build=i686-w64-mingw32
--host=i686-w64-mingw32 --target=i686-w64-mingw32
--with-native-system-header-dir=/mingw32/i686-w64-mingw32/include
--libexecdir=/mingw32/lib --enable-bootstrap --with-arch=i686
--with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++
--enable-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check
--enable-lto --enable-libgomp --disable-multilib --enable-checking=release
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --disable-plugin --with-libiconv --with-system-zlib
--with-gmp=/mingw32 --with-mpfr=/mingw32 --with-mpc=/mingw32
--with-isl=/mingw32 --with-pkgversion='Rev2, Built by MSYS2 project'
--with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as
--with-gnu-ld --disable-sjlj-exceptions --with-dwarf2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.1.0 (Rev2, Built by MSYS2 project)

[Bug c/50584] No warning for passing small array to C99 static array declarator

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2015-07-03 00:00:00 |2020-5-19
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #15 from Martin Sebor  ---
GCC 10 introduced attribute access to associate a pointer argument with a size
of the object it points to.  Although the GCC 10 implementation of the
attribute cannot express the same relationship for VLA arguments, conceptually,
it should only take a small extension to do it.  I plan to work on it for GCC
11.

[Bug c++/95222] New: GCC 10.1 x86 issue with function pointers with calling convention attribute and template specialization

[raptorfactor at raptorfactor dot com]

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

Bug ID: 95222
   Summary: GCC 10.1 x86 issue with function pointers with calling
convention attribute and template specialization
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raptorfactor at raptorfactor dot com
  Target Milestone: ---

The following code (which is a simplified repro from a much larger function
introspection library) used to work with GCC 9.x, but does not with the update
to 10.1. Is this a compiler/toolchain bug or is there something incorrect about
the code that I'm missing (obviously it's non-standard and relying on the
behavior of vendor extensions)?

>>>

#if defined(_MSC_VER)
#define CC_FASTCALL __fastcall
#define CC_STDCALL __stdcall
#else
#define CC_FASTCALL __attribute__((fastcall))
#define CC_STDCALL __attribute__((stdcall))
#endif

template 
struct FuncResult;

template 
struct FuncResult
{
using type = R;
};

template 
struct FuncResult
{
using type = R;
};

template 
struct FuncResult
{
using type = R;
};

template 
auto wrap(FuncT f) -> typename FuncResult::type
{
return f(1, 2, 3);
}

int CC_FASTCALL func1(int x, int y, int z)
{
return x + y + z;
}

int CC_STDCALL func2(int x, int y, int z)
{
return x + y + z;
}

int main()
{
return wrap(&func1) + wrap(&func2);
}

>>>

With the calling convention specific specialization:

>>>

main.cpp:19:8: error: redefinition of 'struct FuncResult'
   19 | struct FuncResult
  |^~~~
main.cpp:13:8: note: previous definition of 'struct FuncResult'
   13 | struct FuncResult
  |^

>>>

Without the calling convention specific specialization:

>>>

main.cpp:50:23: error: no matching function for call to 'wrap(int
(__attribute__((fastcall)) *)(int, int, int))'
   50 | return wrap(&func1) + wrap(&func2);
  |   ^
main.cpp:33:6: note: candidate: 'template typename
FuncResult::type wrap(FuncT)'
   33 | auto wrap(FuncT f) -> typename FuncResult::type
  |  ^~~~
main.cpp:33:6: note:   template argument deduction/substitution failed:
main.cpp: In substitution of 'template typename
FuncResult::type wrap(FuncT) [with FuncT = int
(__attribute__((fastcall)) *)(int, int, int)]':
main.cpp:50:23:   required from here
main.cpp:33:6: error: invalid use of incomplete type 'struct FuncResult'
main.cpp:10:8: note: declaration of 'struct FuncResult'
   10 | struct FuncResult;
  |^~

>>>

Damned if you do, damned if you don't. Is anyone aware of a workaround for
this? It's blocking my build and I can't figure out an easy workaround.

Thanks.

[Bug target/95211] [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

--- Comment #2 from Arseny Solokha  ---
Uh-oh…

int s6;

void
ml (long int *ha, int dz)
{
  int iy[dz];
  int *tp;
  int cm;

  for (cm = 0; cm < 3; ++cm)
tp[cm] = ha[cm] + 1.0f;

  if (s6 == 0)
return;
}

[Bug tree-optimization/49657] array subscript warnings when building gcc with -O2

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
I suspect this is no longer a problem with current releases.  They all build
with -O2 and -Werror.

[Bug c/48091] No warning when given function arguments mismatch earlier function definition which GCC assumes to be K&R, even with --std=c99 -pedantic

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2017-01-23 00:00:00 |2020-5-19
 CC||msebor at gcc dot gnu.org

--- Comment #9 from Martin Sebor  ---
The problem with calls to K&R function definitions is isolated to the single
translation unit that defines those functions.

The problem with the same declarations (i.e., functions without a prototype) is
much bigger but harder to do something about.  The one thing GCC could do is
use the type of the first call to such a function to match all subsequent calls
against, and issue warnings for mismatches.  That would detect a subset of the
bugs.

[Bug c++/46513] Request: Warning for use of unsafe string handling functions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
Resolved as Won't Fix per comment #1 and others.

[Bug middle-end/44300] Spurious array subscript warning, &b[0] == &a[1] is not folded

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #12 from Martin Sebor  ---
Resolving as Won't Fix for the reasons explained in comment #2, comment #4, and
others.

The test case in comment #9 compiles without warnings in GCC 6 (and later).

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

[rafael at espindo dot la]

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

--- Comment #12 from Rafael Avila de Espindola  ---
(In reply to Martin Liška from comment #6)
> Thank you, can you please attach a pre-processed file (-E) so that one
> doesn't need to clone seastar repository?

The testcase that is attached doesn't require any seastar headers, just linking
with libseastar.a.

I will try to reduce it to a self contained test.

[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 #3 from Marek Polacek  ---
And for completeness, the asm for the -fstrong-eval-order=all case:

movq%rbx, %rdi
call*%r12
movq-24(%rbp), %rax
movq(%rax), %rax
addq$16, %rax
movq(%rax), %r12 # crash here

Any ideas what as to we want to do here?

[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 #2 from Marek Polacek  ---
I think the thing is that we have a CALL_EXPR, something like

  OBJ_TYPE_REF (...) (.UBSAN_VPTR ())

and now we first evaluate the OBJ_TYPE_REF.  In this case this is what seems to
happen here:

1) we evaluate OBJ_TYPE_REF before the arguments:

 OBJ_TYPE_REF(_2;(struct MyClass)c->0) (c.0);

   I think this calls the destructor of 'c', and that clears up the vptr:

 this->_vptr.MyClass = 0B;

2) then we fetch the vptr:

  _5 = c->_vptr.MyClass; // _5 == null

3) we add the offset to the vtable for Doit:

  _6 = _5 + 16;  // _6 == 16

4) we deref the pointer and crash

  _7 = *_6;


With -fstrong-eval-order=some we instead do this

_3 = c->_vptr.MyClass;
_4 = *_3;
OBJ_TYPE_REF(_4;(struct MyClass)c->0) (c.0);

so there's no crash, and the subsequent call to the ubsan routine:

_5 = c.1->_vptr.MyClass;
_6 = (long unsigned int) _5; 
.UBSAN_VPTR (c.1, _6, 2968783897514143607, &_ZTI7MyClass, 4B);

reports the error, because it sees that _6 is null.

[Bug c++/68160] Can bind packed field if it's packed with #pragma pack(push, 1)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||10.1.0, 11.0, 5.5.0, 6.4.0,
   ||7.5.0, 8.3.0, 9.2.0
   Last reconfirmed|2017-08-25 00:00:00 |2020-5-19
   Keywords||diagnostic
 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
Reconfirmed with GCC 11.

[Bug c/41809] escaping address of packed field should trigger warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to work||10.1.0, 9.2.0
 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=68160

--- Comment #8 from Martin Sebor  ---
Let me resolve the attribute subset of the problem as fixed.  The outstanding 
#pragma pack subset is the subject of pr68160.

[Bug c/41809] escaping address of packed field should trigger warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #7 from Martin Sebor  ---
Starting with version 9 GCC diagnoses both calls in the test case in comment #0
(the test case with #pragma pack in comment #3 is not diagnosed):

$ cat pr41809.c && gcc -O2 -S -Wall pr41809.c
void f(int *);

struct s {
int x;
char c;
} __attribute__((__packed__));

struct s A[10];

int main(void)
{
for (int i = 0; i != sizeof(A)/sizeof(A[0]); ++i) {
f(&A[i].x);
f((int*)(char*)&A[i].x);
}
}
pr41809.c: In function ‘main’:
pr41809.c:13:11: warning: taking address of packed member of ‘struct s’ may
result in an unaligned pointer value [-Waddress-of-packed-member]
   13 | f(&A[i].x);
  |   ^~~
pr41809.c:14:11: warning: taking address of packed member of ‘struct s’ may
result in an unaligned pointer value [-Waddress-of-packed-member]
   14 | f((int*)(char*)&A[i].x);
  |   ^~~~

[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

[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 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 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 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 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 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 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 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 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 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 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 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++/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 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 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] 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/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 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

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

[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 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 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/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++/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/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 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 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 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] 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 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/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 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 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 #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

 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 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 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++/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 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.