[Bug fortran/102043] Wrong array types used for negative stride accesses

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Richard Biener  ---
So to clarify the ARRAY_REF constraints - there is currently no way to
construct a valid ARRAY_REF where an index does an access to memory before the
supplied
base object.  TREE_OPERAND (array_ref, 0) needs to always be the array,
it's address needs to be the address of the _first_ element.  For negative
strides gfortran seems to construct the array object in a way so its
address points to the _last_ element of the array.  That's not supported.

I realize the complication is that with array descriptors we do not know
statically whether the stride is positive or negative and the data
pointer is already set up "wrong" in there so we'd have to go and
undo the biasing which might or might not be easily possible but it will
be costly.

Is there any case where the frontend would make 'data' point into the
middle of the array and iteration over the array would end up accessing
elements on "both sides"?  Can somebody write a short testcase where that
would happen?

[Bug tree-optimization/103181] [9/10/11/12 Regression] wrong code at -O1 due to conditional division by 0 being executed

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Mine

[Bug tree-optimization/103182] [12 Regression] Recent change causes code correctness regression

[hubicka at gcc dot gnu.org via Gcc-bugs]

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

Jan Hubicka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-11-11

--- Comment #3 from Jan Hubicka  ---
mine.
Concerning the ICE in libstdc++ it is somewhat overactive sanity check which is
harmless code correctness wise. I will look into it first.

[Bug preprocessor/103165] [12 Regression] ICE unspellable token PRAGMA since r12-4797-g0078a058a5693871

[burnus at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Tobias Burnus  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584035.html

 * * *

Note the remark in
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584042.html regarding
preserving spacing with the stringified _Pragma.
This is not handled by the patch, nor are strings with prefixes like L"...".

Currently, _cpp_do__Pragma calls get__Pragma_string – and the latter strips off
all padding, but still keeps the prefix info via CPP_{,W,UTF8}STRING{,16,32}.
Of course after evaluating that string via destringize_and_run -> do_pragma,
the string and, hence, its type is gone.

The question is – for this issue and also for PR90400 – whether the string
should be kept for longer as string and only later destringize_and_run (or used
as is); at least when the pragma space/name is not registered, this seems to
make sense - such that it is properly handled with '-E' (→ PR90400). Now that
CPP_PRAGMA supports 'flags & PRAGMA_OP', it can be distinguished from
CPP_PRAGMA in macro.c and it could be workable? — Note: Requires to check
whether there are any issues with delaying it – or whether that's actually the
proper way of doing it.

[Bug tree-optimization/103181] [9/10/11/12 Regression] wrong code at -O1 due to conditional division by 0 being executed

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Richard Biener  ---
The issue is rather

  if (!TREE_CONSTANT (divisor) || integer_zerop (divisor))
return true;
  return false;

for division handling where here we have { 3, 0 } for the divisor.

[Bug c++/103183] New: ind[arr] produces an lvalue when arr is an array xvalue

[de34 at live dot cn via Gcc-bugs]

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

Bug ID: 103183
   Summary: ind[arr] produces an lvalue when arr is an array
xvalue
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: de34 at live dot cn
  Target Milestone: ---

With gcc 10 and later versions, the following program compiles in C++11/14
modes, but fails to compile in C++17 and later modes. It compiles in C++17 and
later modes if "int&&" is replaced with "int&" (which is wrong according to
[expr.sub]/2).

#include 
#include 

int main()
{
int arr[]{0};
static_assert(std::is_same::value, "");
}

It seems that arr[ind] doesn't suffer from this bug.

Gcc 9 correctly produced an xvalue in this case.

wandbox links (rejected valid code):
gcc 12.0 (-std=c++17): https://wandbox.org/permlink/HvNaq9T4J7oeYflt
gcc 12.0 (-std=c++14): https://wandbox.org/permlink/S3dhGvKr3aD5OeOW
gcc 10.1 (-std=c++17): https://wandbox.org/permlink/NzqYCtytSUW4oZjR
gcc 10.1 (-std=c++14): https://wandbox.org/permlink/LviIophRujplHx6o
gcc  9.3 (-std=c++17): https://wandbox.org/permlink/JkCQHBdc3xqDSG9s

wandbox links (accepted invalid code, with "int&&" replaced with "int&"):
gcc 12.0 (-std=c++17): https://wandbox.org/permlink/JkCQHBdc3xqDSG9s
gcc 10.1 (-std=c++17): https://wandbox.org/permlink/Yr3Vl2mbeDzGi02v

[Bug target/103184] New: ICE caused by r12-5102

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 103184
   Summary: ICE  caused by  r12-5102
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-linux-gnu

Created attachment 51763
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51763&action=edit
reproduce ICE with -O2

test.i is from glibc pthread_cancel.c

> [TCWG CI] Regression caused by gcc: Improve integer bit test on 
> __atomic_fetch_[or|and]_* returns:
> commit fb161782545224f55ba26ba663889c5e6e9a04d1
> Author: liuhongt 
>
> Improve integer bit test on __atomic_fetch_[or|and]_* returns
>
> Results regressed to
> # reset_artifacts:
> -10
> # true:
> 0
> # build_abe binutils:
> 1
> # build_abe stage1:
> 2
> # build_abe linux:
> 3
> # First few build errors in logs:
> # 00:00:51 pthread_cancel.c:60:1: error: type mismatch in binary expression
> # 00:00:51 pthread_cancel.c:60:1: internal compiler error: verify_gimple 
> failed
> # 00:00:51 make[2]: *** [../o-iterator.mk:9: 
> /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/aarch64-linux-gnu/glibc-glibc.git~master/nptl/pthread_cancel.o]
>  Error 1
> # 00:00:52 make[1]: *** [Makefile:483: nptl/subdir_lib] Error 2
> # 00:00:52 make: *** [Makefile:9: all] Error 2

[Bug c++/103185] New: ind[arr] is rejected when arr is an array prvalue

[de34 at live dot cn via Gcc-bugs]

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

Bug ID: 103185
   Summary: ind[arr] is rejected when arr is an array prvalue
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: de34 at live dot cn
  Target Milestone: ---

With gcc 10 and later versions, the following program compiles in C++11/14
modes, but fails to compile in C++17 and later modes.

#include 

int main()
{
using intarr = int[];
static_assert(std::is_same::value, "");
}

It seems that arr[ind]("intarr{0}[0]") doesn't suffer from this bug.

Gcc 9 correctly accepted this code.

wandbox links:
gcc 12.0 (-std=c++17): https://wandbox.org/permlink/AQGr8pUXHQkPrJ9m
gcc 12.0 (-std=c++14): https://wandbox.org/permlink/aYpBwLVK8tsDHTl3
gcc 10.1 (-std=c++17): https://wandbox.org/permlink/nnWuZAawBZnrmHvN
gcc 10.1 (-std=c++14): https://wandbox.org/permlink/4fNJLiqU5VaMZPfm
gcc  9.3 (-std=c++17): https://wandbox.org/permlink/vugrP8zIzBSPiVup

Perhaps this bug is related to bug 94264 and bug 103183.

[Bug target/103184] ICE caused by r12-5102

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Hongtao.liu  ---
Small testcase reprodce it.

#include 

int
tbit0 (_Atomic int* a)
{
#define BIT (0x01 << 3)
  return atomic_fetch_or(a, BIT) & BIT;
#undef BIT 
}

aarch64-linux-gnu-gcc test.c -O2 -S
test.c: In function ‘tbit0’:
test.c:4:1: error: type mismatch in binary expression
4 | tbit0 (_Atomic int* a)
  | ^
int

unsigned int

int

_7 = _1 & 8;
during GIMPLE pass: fab
test.c:4:1: internal compiler error: verify_gimple failed
0xf99c2d verify_gimple_in_cfg(function*, bool)
   
/export/users2/liuhongt/gcc/intel-innersource/master/gcc/tree-cfg.c:5577
0xe618df execute_function_todo
/export/users2/liuhongt/gcc/intel-innersource/master/gcc/passes.c:2042
0xe622cc execute_todo
/export/users2/liuhongt/gcc/intel-innersource/master/gcc/passes.c:2096
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/102376] [aarch64] using target("sve") attribute without a + is not very helpful on what is wrong

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Prathamesh Kulkarni
:

https://gcc.gnu.org/g:145be5efaf5674a7d25c723dc5684392a6276834

commit r12-5147-g145be5efaf5674a7d25c723dc5684392a6276834
Author: Prathamesh Kulkarni 
Date:   Thu Nov 11 14:37:22 2021 +0530

[aarch64] PR102376 - Emit better diagnostic for arch extensions in target
attr.

gcc/ChangeLog:
PR target/102376
* config/aarch64/aarch64.c (aarch64_process_target_attr): Check if
token is arch extension without leading '+' and emit appropriate
diagnostic for the same.

gcc/testsuite/ChangeLog:
PR target/102376
* gcc.target/aarch64/pr102376.c: New test.

[Bug tree-optimization/103168] Value numbering for PRE of pure functions can be improved

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2021-11-11
Summary|Value numbering of pure |Value numbering for PRE of
   |functions can be improved   |pure functions can be
   ||improved
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Richard Biener  ---
loop invariant motion can only move const calls right now.  Not sure what
value-numbering has to do with this?  There is probably a duplicate somewhere. 
The odd thing is that PRE doesn't handle it - it fails to discover that on the
backedge
the value is the same.  Ah, that's because ao_ref_init_from_vn_reference does
not handle calls - hmm, yeah we can't represent calls in an ao_ref, at least
not easily.  I suppose for a 'pure' call an ao_ref could be a dereference of
a pointer to global memory, but we'd have to build a fake SSA for the pointer
and fake points-to-info for this.

So let's have this PR track the lack of PRE of pure calls.

[Bug tree-optimization/103169] [12 Regression] ICE: verify_ssa failed (error: definition in block 3 does not dominate use in block 4) since r12-4785-ged3de62ac949c92ad41ef6de7cc926fbb2a510ce

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/103173] strncpy output may be truncated copying 32 bytes from a string of length 1439 (bogus) [-Werror=stringop-truncation]

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Richard Biener  ---
&MEM  [(void *)&data] should have been folded to &data btw

[Bug tree-optimization/103175] [12 Regression] internal compiler error: in handle_call_arg, at tree-ssa-structalias.c:4139

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug debug/101378] Negative DW_AT_data_member_location

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:10db7573014008ff867098206f51012d501ab57b

commit r12-5148-g10db7573014008ff867098206f51012d501ab57b
Author: Jakub Jelinek 
Date:   Thu Nov 11 10:14:04 2021 +0100

dwarf2out: Fix up field_byte_offset [PR101378]

For PCC_BITFIELD_TYPE_MATTERS field_byte_offset has quite large code
to deal with it since many years ago (see it e.g. in GCC 3.2, although it
used to be on HOST_WIDE_INTs, then on double_ints, now on offset_ints).
But that code apparently isn't able to cope with members with empty class
types with [[no_unique_address]] attribute, because the empty classes have
non-zero type size but zero decl size and so one can end up from the
computation with negative offset or offset 1 byte smaller than it should
be.
For !PCC_BITFIELD_TYPE_MATTERS, we just use
tree_result = byte_position (decl);
which seems exactly right even for the empty classes or anything which is
not a bitfield (and for which we don't add DW_AT_bit_offset attribute).
So, instead of trying to handle those no_unique_address members in the
current already very complicated code, this limits it to bitfields.

stor-layout.c PCC_BITFIELD_TYPE_MATTERS handling also affects only
bitfields, twice it checks DECL_BIT_FIELD and once DECL_BIT_FIELD_TYPE.

As discussed, this patch uses DECL_BIT_FIELD_TYPE check, because
DECL_BIT_FIELD might be cleared for some bitfields with bitsizes
multiple of BITS_PER_UNIT and e.g.
struct S { int e; int a : 1, b : 7, c : 8, d : 16; } s;
struct T { int a : 1, b : 7; long long c : 8; int d : 16; } t;

int
main ()
{
  s.c = 0x55;
  s.d = 0x;
  t.c = 0x55;
  t.d = 0x;
  s.e++;
}
has different debug info with DECL_BIT_FIELD check.

2021-11-11  Jakub Jelinek  

PR debug/101378
* dwarf2out.c (field_byte_offset): Do the PCC_BITFIELD_TYPE_MATTERS
handling only for DECL_BIT_FIELD_TYPE decls.

* g++.dg/debug/dwarf2/pr101378.C: New test.

[Bug testsuite/103179] [12 regression] Excess errors in gfortran.dg/do_subscript_3.f90 after r12-5126

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |12.0

[Bug tree-optimization/103181] [9/10/11/12 Regression] wrong code at -O1 due to conditional division by 0 being executed

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/103182] [12 Regression] Recent change causes code correctness regression

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/103184] [12 Regression] ICE caused by r12-5102

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

  Component|target  |tree-optimization
   Priority|P3  |P1
   Target Milestone|--- |12.0
Summary|ICE  caused by  r12-5102|[12 Regression] ICE  caused
   ||by  r12-5102

[Bug tree-optimization/103181] [9/10/11/12 Regression] wrong code at -O1 due to conditional division by 0 being executed

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r12-5149-ga5fed4063f428a14f5b91533d5954b9bf4e3e7db
Author: Richard Biener 
Date:   Thu Nov 11 09:40:36 2021 +0100

middle-end/103181 - fix operation_could_trap_p for vector division

For integer vector division we only checked for all zero vector
constants rather than checking whether any element in the constant
vector is zero.

2021-11-11  Richard Biener  

PR middle-end/103181
* tree-eh.c (operation_could_trap_helper_p): Properly
check vector constants for a zero element for integer
division.  Separate floating point and integer division code.

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

[Bug c++/103183] ind[arr] produces an lvalue when arr is an array xvalue

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
There has to be C++ defect report about this.  Because clang has the behavior
you are requesting but ICC, MSVC all act the same as GCC.

[Bug tree-optimization/103184] [12 Regression] ICE caused by r12-5102

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
When mask is integer_cst, it not safe to replace_uses_by (use_lhs, lhs); since
integer_cst has type signed int, but lhs has type unsigned int, and will issue
ICE for type mismatch
_7 = _1 & 8;

_1 is signed int, and 8 is unsigged int CST.


The problem is exposed only on aarch64 since the backend doesn't have
corresponding optab and failed, but the original gimple has been changed.

  switch (fn)
{
case IFN_ATOMIC_BIT_TEST_AND_SET:
  optab = atomic_bit_test_and_set_optab;
  break;
case IFN_ATOMIC_BIT_TEST_AND_COMPLEMENT:
  optab = atomic_bit_test_and_complement_optab;
  break;
case IFN_ATOMIC_BIT_TEST_AND_RESET:
  optab = atomic_bit_test_and_reset_optab;
  break;
default:
  return;
}

  if (optab_handler (optab, TYPE_MODE (TREE_TYPE (lhs))) == CODE_FOR_nothing)

[Bug c++/103183] ind[arr] produces an lvalue when arr is an array xvalue

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
Found it PR 79832.

[Bug c++/103183] ind[arr] produces an lvalue when arr is an array xvalue

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> Found it PR 79832.

Well DR 1213, http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1213

[Bug tree-optimization/103184] [12 Regression] ICE caused by r12-5102

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #2)
> When mask is integer_cst, it not safe to replace_uses_by (use_lhs, lhs);
Similar ICE for variable mask.

int
tbit0 (_Atomic int* a, int n)
{
#define BIT (0x01 << n)
  return atomic_fetch_or(a, BIT) & BIT;
#undef BIT 
}

[Bug c++/103186] New: redefinition of template symbol error with strange error diagnostic

[dl.soluz at gmx dot net via Gcc-bugs]

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

Bug ID: 103186
   Summary: redefinition of template symbol error with strange
error diagnostic
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dl.soluz at gmx dot net
  Target Milestone: ---

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

How to reproduce

use the attached test.cpp - i reduced it as much as possible while keeping the
error(s) intact

good case - problematik parts are disabled:

gcc -Wall -Wextra -std=c++17 test.cpp

test 1: (https://gcc.godbolt.org/z/WvqbWq1e5)

gcc -Wall -Wextra -std=c++17 test.cpp -DTEST=1 
est.cpp:77:12: error: redefinition of ‘const char
_ZTSZN12GetSetHelperIaE3setESt8functionIFvvEEEd_UlDpOT_E_ []’
   77 | int main(){}
  |^
test.cpp:77:12: note: ‘const char
_ZTSZN12GetSetHelperIaE3setESt8functionIFvvEEEd_UlDpOT_E_ [54]’ previously
defined here

test 2:
gcc -Wall -Wextra -std=c++17 test.cpp -DTEST=2

/usr/bin/ld:
/tmp/ccCdRNNd.o:(.data.rel.ro._ZTIZN12GetSetHelperIhE3setESt8functionIFvvEEEd_UlDpOT_E_[_ZTIZN12GetSetHelperIhE3setESt8functionIFvvEEEd_UlDpOT_E_]+0x0):
undefined reference to `vtable for __cxxabiv1::__class_type_info'
/usr/bin/ld:
/tmp/ccCdRNNd.o:(.data.rel.ro._ZTIZN12GetSetHelperIaE3setESt8functionIFvvEEEd_UlDpOT_E_[_ZTIZN12GetSetHelperIaE3setESt8functionIFvvEEEd_UlDpOT_E_]+0x0):
undefined reference to `vtable for __cxxabiv1::__class_type_info'
/usr/bin/ld:
/tmp/ccCdRNNd.o:(.data.rel.local.DW.ref.__gxx_personality_v0[DW.ref.__gxx_personality_v0]+0x0):
undefined reference to `__gxx_personality_v0'
collect2: error: ld returned 1 exit status

this linker problem does not occure on gcc.godbolt - maybe a Ubuntu ld only
problem

Test with other versions, compilers:

error occures also with gcc.godbolt trunk/11.2/11.1, does not happen with gcc
10.3 or lower

does not happen with Clang versions down to 8.x and further
does not happen with VS2017/2019(up to date versions)

System:

using up-to-date(11.11.2021) Ubuntu 21.10 x64 with default gcc 11.2.0, clang
13.x and default ld 2.37

$ uname -a
Linux linux 5.13.0-20-generic #20-Ubuntu SMP Fri Oct 15 14:21:35 UTC 2021
x86_64 x86_64 x86_64 GNU/Linux

$ gcc -v

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.2.0-7ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-ZPT0kp/gcc-11-11.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-ZPT0kp/gcc-11-11.2.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Ubuntu 11.2.0-7ubuntu2) 

$ ld -v
GNU ld (GNU Binutils for Ubuntu) 2.37

[Bug c++/103186] redefinition of template symbol error with strange error diagnostic

[dl.soluz at gmx dot net via Gcc-bugs]

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

--- Comment #1 from dennis luehring  ---
Created attachment 51765
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51765&action=edit
ii-file

output of "gcc -Wall -Wextra -std=c++17 test.cpp -DTEST=1 -save-temps"

[Bug c++/103186] redefinition of template symbol error with strange error diagnostic

[dl.soluz at gmx dot net via Gcc-bugs]

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

--- Comment #2 from dennis luehring  ---
Created attachment 51766
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51766&action=edit
s-file

output of "gcc -Wall -Wextra -std=c++17 test.cpp -DTEST=1 -save-temps"

[Bug tree-optimization/103169] [12 Regression] ICE: verify_ssa failed (error: definition in block 3 does not dominate use in block 4) since r12-4785-ged3de62ac949c92ad41ef6de7cc926fbb2a510ce

[tnfchris at gcc dot gnu.org via Gcc-bugs]

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #2 from Tamar Christina  ---
looking at the tree it looks like with the new SLP layout the complex MUL is
detected but complex MUL re-arranges the nodes.  The nodes are

/app/example.c:6:7: note:   op: VEC_PERM_EXPR
/app/example.c:6:7: note:   { }
/app/example.c:6:7: note:   lane permutation { 0[0] 1[1] }
/app/example.c:6:7: note:   children 0x32b1ce0 0x32b2820
/app/example.c:6:7: note:   node 0x32b1ce0 (max_nunits=2, refcnt=1)
/app/example.c:6:7: note:   op template: _15 = PHI <_10(7), _13(3)>
/app/example.c:6:7: note:   stmt 0 _15 = PHI <_10(7), _13(3)>
/app/example.c:6:7: note:   stmt 1 _16 = PHI <_11(7), _14(3)>
/app/example.c:6:7: note:   children 0x32b1d70 0x32b2280

where 0x32b2820 is some externals.  By only selecting one of the phi nodes as
it re-orders it breaks the dominance. So I guess this transformation should
happen when any of the operands to the MUL is a phi node.

This I think happens because is_linear_load is punting for this node and we
return PERM_TOP where I think PERM_UNKNOWN is better here.

[Bug c++/103186] redefinition of template symbol error with strange error diagnostic

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
>gcc -Wall -Wextra -std=c++17 test.cpp -DTEST=2


This is wrong, you should use g++ to link as you need to link against libstdc++
which gcc does not do which is why you are not seeing it on gcc.godbolt.

[Bug c++/103186] redefinition of template symbol error with strange error diagnostic

[dl.soluz at gmx dot net via Gcc-bugs]

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

--- Comment #4 from dennis luehring  ---
(In reply to Andrew Pinski from comment #3)
> >gcc -Wall -Wextra -std=c++17 test.cpp -DTEST=2
> 
> 
> This is wrong, you should use g++ to link as you need to link against
> libstdc++ which gcc does not do which is why you are not seeing it on
> gcc.godbolt.

stupid me - my cmake scripts uses g++, accidentally switched to gcc - thanks
so the -DTEST=2 is NOT a bug

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.2.0-7ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-ZPT0kp/gcc-11-11.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-ZPT0kp/gcc-11-11.2.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Ubuntu 11.2.0-7ubuntu2)

[Bug c++/103186] redefinition of template symbol error with strange error diagnostic

[dl.soluz at gmx dot net via Gcc-bugs]

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

--- Comment #5 from dennis luehring  ---
-DTEST=1 compiles under Ubuntu 21.04 with g++ 10.3.0

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 10.3.0-1ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-10-gDeRY6/gcc-10-10.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-gDeRY6/gcc-10-10.3.0/debian/tmp-gcn/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1)

[Bug c++/103186] redefinition of template symbol error with strange error diagnostic

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Andrew Pinski  ---
Reduced testcase for the first issue (note it is a different error but the
problem is the same):
using Callback = void();
template 
struct GetSetHelper
{
static void set( Callback callback_ = []() {}  ){}
};
template 
void m()
{
GetSetHelper::set();
}
template 
void n( )
{
( ( m( ) ), ... );
}
int main()
{
GetSetHelper::set();
n( );
}

[Bug c++/103186] [11/12 Regression] redefinition of template symbol error with strange error diagnostic

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords|link-failure|assemble-failure
   Target Milestone|--- |11.3
 Ever confirmed|0   |1
   Last reconfirmed||2021-11-11

--- Comment #7 from Andrew Pinski  ---
The ICE with reduced testcase:
:21:1: error: Two symbols with same comdat_group are not linked by the
same_comdat_group list.
   21 | }
  | ^

But this is with checking turned on only.
Without checking we get an assembler failure:
/tmp/ccBw63Kh.s: Assembler messages:
/tmp/ccBw63Kh.s:147: Error: symbol
`_ZZN12GetSetHelperIiE3setEPFvvEEd_NKUlvE_clEv' is already defined
/tmp/ccBw63Kh.s:168: Error: symbol
`_ZZN12GetSetHelperIiE3setEPFvvEEd_NUlvE_4_FUNEv' is already defined
/tmp/ccBw63Kh.s:190: Error: symbol
`_ZZN12GetSetHelperIiE3setEPFvvEEd_NKUlvE_cvS2_Ev' is already defined

[Bug libstdc++/103187] New: std::counting_semaphore::try_acquire_for does not unblock during wait duration

[s.zvyagin83 at gmail dot com via Gcc-bugs]

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

Bug ID: 103187
   Summary: std::counting_semaphore::try_acquire_for does not
unblock during wait duration
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s.zvyagin83 at gmail dot com
  Target Milestone: ---

According to C++ standart https://eel.is/c++draft/thread.sema.cnt#18.2
try_acquire_for/until should block until counter is greater than zero or until
timeout expires. 

But semaphores implemented with atomic_wait blocks for whole timeout even if
semaphore released during wait. 

minimal repoduce code:
g++ -std=c++20 -lpthread

#include 
#include 
#include 
#include 

using namespace std::chrono_literals;

int main()
{
  std::binary_semaphore sem{0};
  auto begin = std::chrono::steady_clock::now();
  auto time = [&begin] {
  return
std::chrono::duration_cast(std::chrono::steady_clock::now()-begin).count();
  };
  std::jthread jthr(
  [&sem, &time] {
printf("[%ld] thread start\n", time());
std::this_thread::sleep_for(1s);
printf("[%ld] sem.release\n", time());
sem.release();
  });
  printf("[%ld] sem.try_acquire_for\n", time());
  if (sem.try_acquire_for(10s))
printf("[%ld] sem.acquired\n", time());
  else
printf("[%ld] failed to acquire sem\n", time());
}

output:
[0] sem.try_acquire_for
[0] thread start
[1000] sem.release
[1] sem.acquired

POSIX semaphores with same code work correctly and unblock immediately when
semaphore released
g++ -std=c++20 -lpthread -D_GLIBCXX_USE_POSIX_SEMAPHORE=1

output:
[0] sem.try_acquire_for
[0] thread start
[1000] sem.release
[1000] sem.acquired

[Bug tree-optimization/103184] [12 Regression] ICE caused by r12-5102

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-11-11
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||pinskia at gcc dot gnu.org

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

[Bug tree-optimization/103188] New: ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 103188
   Summary: ICE on valid code at -O2 and -O3 on x86_64-linux-gnu:
Segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

[635] % gcctk -O2 small.c
gcctk: internal compiler error: Segmentation fault signal terminated program
cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
[636] %
[636] %
[636] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 2021 (experimental) [master r12-5143-ga97fdde627e] (GCC)
[637] %
[637] % gcctk -O1 small.c; ./a.out
[638] %
[638] % gcctk -O2 small.c
gcctk: internal compiler error: Segmentation fault signal terminated program
cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
[639] %
[639] % cat small.c
int a, b, c, d = 10, e = 1, f, g, h, i;
int main() {
  int j = -1;
k:
  h = c;
l:
  c = ~c;
  if (e)
  m:
a = 0;
  if (j > 1)
goto m;
  if (!e)
goto l;
  if (c)
goto p;
n:
  goto m;
o:
  if (f) {
if (g)
  goto k;
j = 0;
  p:
if (d)
  goto o;
goto n;
  }
  if (i)
goto l;
  for (; a < 1; a++)
while (a > d)
  b++;
  return 0;
}

[Bug libstdc++/103187] std::counting_semaphore::try_acquire_for does not unblock during wait duration

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to fail||11.2.1
  Known to work||12.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-11-11
   Target Milestone|--- |11.3
 CC||rodgertq at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
Already fixed on trunk, I think we just need a backport.

[Bug libstdc++/103187] std::counting_semaphore::try_acquire_for does not unblock during wait duration

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jonathan Wakely  ---
The relevant commit seems to be g:aeaea265cea3a2b2e772af7825351a4ceef29aac but
that *should* only be an optimization to use futexes when available. The fact
it times out without that change suggests the non-futex code has a bug, and
it's probably still there on trunk.

[Bug tree-optimization/103188] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault

[acoplan at gcc dot gnu.org via Gcc-bugs]

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

Alex Coplan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code
  Known to fail||12.0
 Ever confirmed|0   |1
 CC||acoplan at gcc dot gnu.org
   Last reconfirmed||2021-11-11

--- Comment #1 from Alex Coplan  ---
Confirmed with an x864 -> aarch64-linux-gnu cross. Looks like a stack overflow
in SCEV:

#0  0x00d05c54 in ei_container (i=) at
/home/alecop01/toolchain/src/gcc/gcc/basic-block.h:381
#1  0x00d05d05 in ei_end_p (i=...) at
/home/alecop01/toolchain/src/gcc/gcc/basic-block.h:418
#2  0x00d05de9 in ei_cond (ei=..., p=0x7bfff098) at
/home/alecop01/toolchain/src/gcc/gcc/basic-block.h:468
#3  0x00d0aa4e in loop_preheader_edge (loop=0x764d5d40) at
/home/alecop01/toolchain/src/gcc/gcc/cfgloop.c:1763
#4  0x0158d479 in block_before_loop (loop=0x764d5d40) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.h:52
#5  0x01591a72 in analyze_scalar_evolution (loop=0x764d5d40,
var=0x76344870) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.c:2027
#6  0x0159064f in interpret_rhs_expr (loop=0x764d5d40,
at_stmt=0x764c8108, type=0x764dd5e8, rhs1=0x76344870,
code=PLUS_EXPR, rhs2=0x764e11b0) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.c:1714
#7  0x0159174b in interpret_gimple_assign (loop=0x764d5d40,
stmt=0x764c8108) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.c:1920
#8  0x015918c0 in analyze_scalar_evolution_1 (loop=0x764d5d40,
var=0x76344558) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.c:1969
#9  0x01591ad2 in analyze_scalar_evolution (loop=0x764d5d40,
var=0x76344558) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.c:2038
#10 0x0158fe73 in interpret_condition_phi (loop=0x764d5d40,
condition_phi=0x76386500) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.c:1602
#11 0x01591918 in analyze_scalar_evolution_1 (loop=0x764d5d40,
var=0x76344870) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.c:1976
#12 0x01591ad2 in analyze_scalar_evolution (loop=0x764d5d40,
var=0x76344870) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.c:2038
#13 0x0159064f in interpret_rhs_expr (loop=0x764d5d40,
at_stmt=0x764c8108, type=0x764dd5e8, rhs1=0x76344870,
code=PLUS_EXPR, rhs2=0x764e11b0) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.c:1714
#14 0x0159174b in interpret_gimple_assign (loop=0x764d5d40,
stmt=0x764c8108) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.c:1920
#15 0x015918c0 in analyze_scalar_evolution_1 (loop=0x764d5d40,
var=0x76344558) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.c:1969
[...]

[Bug testsuite/103042] gcc.dg/vect/complex/bb-slp-complex-add-pattern-unsigned-long.c etc. FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #7 from Tamar Christina  ---
>> gcc/testsuite/gcc.dg/vect/complex/fast-math-bb-slp-complex-add-pattern-double.c
>
> This one running is odd, it's guarded by vect_double which doesn't match
> sparc-*-*-*.  That should be unresolved now.

Those failures existed until 20211103 and were gone by 20211105
(UNSUPPORTED; UNRESOLVED would also be bad).

[Bug testsuite/103042] gcc.dg/vect/complex/bb-slp-complex-add-pattern-unsigned-long.c etc. FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #8 from CVS Commits  ---
[...]
> testsuite: change vect_long to vect_long_long in complex tests.
>
> These tests are still failing on SPARC and it looks like this is because I
> need
> to use vect_long_long instead of vect_long.

Indeed: as of last night, all those tests are UNSUPPORTED on 32 and
64-bit SPARC.  Thanks.

[Bug tree-optimization/102880] [12 Regression] Dead Code Elimination Regression at -O3

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Richard Biener  ---
So interestingly as a band-aid fix I bootstrapped and tested

diff --git a/gcc/tree-cfgcleanup.c b/gcc/tree-cfgcleanup.c
index a016ee47a02..c2a0555dd78 100644
--- a/gcc/tree-cfgcleanup.c
+++ b/gcc/tree-cfgcleanup.c
@@ -351,6 +351,7 @@ tree_forwarder_block_p (basic_block bb, bool phi_wanted)
   /* If PHI_WANTED is false, BB must not have any PHI nodes.
 Otherwise, BB must have PHI nodes.  */
   || gimple_seq_empty_p (phi_nodes (bb)) == phi_wanted
+  || single_pred_p (bb) == phi_wanted
   /* BB may not be a predecessor of the exit block.  */
   || single_succ (bb) == EXIT_BLOCK_PTR_FOR_FN (cfun)
   /* Nor should this be an infinite loop.  */

which makes the forwarder block removal of CFG cleanup only remove forwarders
with a single predecessor (formerly it handled multiple predecessors if they
did not have PHIs).

There's no testsuite fallout from this patch but the testcase is fixed.

IMHO we should handle degenerate PHIs with a single predecessor here
and yank the PHI node restriction if we go with this.

It will still not catch all CD-DCE opportunities since that's of course not
a reliable way to have common arguments factored.  We talked a bit about
recovering the control dependence info of a virtuall inserted forwarder
but if possible it isn't anything trivial so I'd tend to go with explicit
factoring before running CD-DCE.

[Bug tree-optimization/103188] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |12.0
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

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

[Bug tree-optimization/103189] New: [12 regression] g++.dg/tree-ssa/pta-delete-1.C etc. FAIL

[ro at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 103189
   Summary: [12 regression] g++.dg/tree-ssa/pta-delete-1.C etc.
FAIL
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org
  Target Milestone: ---
Target: sparc*-sun-solaris2.11

Between 20211109 (78dd0de956cbc5a021d3c5e3eb39308c3207936e) and 2020
(86ffc845b2d0bff59832dcf3cf6518f1358e30ac),
several tests regressed on Solaris/SPARC (32 and 64-bit):

+FAIL: g++.dg/tree-ssa/pta-delete-1.C  -std=gnu++14 execution test
+FAIL: g++.dg/tree-ssa/pta-delete-1.C  -std=gnu++17 execution test
+FAIL: g++.dg/tree-ssa/pta-delete-1.C  -std=gnu++2a execution test
+FAIL: g++.dg/tree-ssa/pta-delete-1.C  -std=gnu++98 execution test

+FAIL: gcc.dg/torture/pr45967-2.c   -O2  execution test
+FAIL: gcc.dg/torture/pr45967-2.c   -O2 -flto  execution test
+FAIL: gcc.dg/torture/pr45967-2.c   -O2 -flto -flto-partition=none  execution
test
+FAIL: gcc.dg/torture/pr45967-2.c   -Os  execution test
+FAIL: gcc.dg/torture/pr45967-3.c   -O2  execution test
+FAIL: gcc.dg/torture/pr45967-3.c   -O2 -flto  execution test
+FAIL: gcc.dg/torture/pr45967-3.c   -O2 -flto -flto-partition=none  execution
test
+FAIL: gcc.dg/torture/pr45967-3.c   -Os  execution test
+FAIL: gcc.dg/torture/pr45967.c   -O2  execution test
+FAIL: gcc.dg/torture/pr45967.c   -O2 -flto  execution test
+FAIL: gcc.dg/torture/pr45967.c   -O2 -flto -flto-partition=none  execution
test
+FAIL: gcc.dg/torture/pr45967.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
+FAIL: gcc.dg/torture/pr45967.c   -O3 -g  execution test
+FAIL: gcc.dg/torture/pr45967.c   -Os  execution test

In both cases, the tests abort, but running under gdb this makes no sense:

* pta-delete-1.C:

Thread 2 received signal SIGABRT, Aborted.
[Switching to Thread 1 (LWP 1)]
0xfec5344c in __lwp_sigqueue () from /lib/libc.so.1
(gdb) where
#0  0xfec5344c in __lwp_sigqueue () from /lib/libc.so.1
#1  0xfeb9028c in raise () from /lib/libc.so.1
#2  0xfeb60578 in abort () from /lib/libc.so.1
#3  0x00010e1c in main () at
/vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/tree-ssa/pta-delete-1.C:23

  yet gdb shows that y = 2 at this point.

* pr45967.c:

Thread 2 received signal SIGABRT, Aborted.
[Switching to Thread 1 (LWP 1)]
0xfec5344c in __lwp_sigqueue () from /lib/libc.so.1
(gdb) where
#0  0xfec5344c in __lwp_sigqueue () from /lib/libc.so.1
#1  0xfeb9028c in raise () from /lib/libc.so.1
#2  0xfeb60578 in abort () from /lib/libc.so.1
#3  0x00010c94 in main () at
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/torture/pr45967.c:19

  Again, the test aborts although gdb shows i = 1.

Unless someone has an idea what might have caused this, I'll have to run a
reghunt.

[Bug tree-optimization/103189] [12 regression] g++.dg/tree-ssa/pta-delete-1.C etc. FAIL

[ro at gcc dot gnu.org via Gcc-bugs]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug tree-optimization/103188] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
Caused by g:e82c382971664d6fd138cc36020db4b1a91885c6, the call tree roots at

#666394 0x015f2170 in should_duplicate_loop_header_p (
header=, loop=0x766aa9f0, 
limit=0x7fffd97c, query=0x3fccb70)
at /home/rguenther/src/gcc3/gcc/tree-ssa-loop-ch.c:83
83&& !entry_loop_condition_is_static (loop, query))

likely ranger is confused by the intermediate IL (from other loops header
copying), the IL is kept partly not in up-to-date SSA form (because running
update_ssa is costly so we run it once after doing all header copying in
a function).

In this case we applied loop header copying to loop 4 containing loop 5
which we are now processing.

Not up-to-date SSA form means that while SSA defs are copied, the SSA uses
in a stmt are still old and _not_ replaced with their current definition.
There's only so much you can do with such IL, in particular invoking SCEV
isn't among that.

You can actually check whether a SSA name may be affected by checking
name_registered_for_update_p.  SCEV doesn't do that.

In the end that means that we'd have to do the ranger analysis before
actually applying the header copying.

Note that the current place of the

  /* Avoid loop header copying when optimizing for size unless we can
 determine that the loop condition is static in the first
 iteration.  */
  if (optimize_loop_for_size_p (loop)
  && !loop->force_vectorize
  && !entry_loop_condition_is_static (loop, query))
{

is off in any case, since we iterate on blocks to copy, instead it should
be done exactly once per loop.  So we can do the "head", up until this
and the very first should_duplicate_loop_header_p first for each loop,
recording candidates in a vector and in a second loop process them all,
not doing the already done entry_loop_condition_is_static.

Let me cook up a patch to do that.

[Bug bootstrap/80047] fixincludes/fixincl.c: PVS-Studio: Improper Release of Memory Before Removing Last Reference (CWE-401)

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||bkorb at gnu dot org,
   ||xry111 at mengyan1223 dot wang

--- Comment #6 from Eric Gallager  ---
new patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583820.html

[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||bkorb at gnu dot org,
   ||xry111 at mengyan1223 dot wang

--- Comment #6 from Eric Gallager  ---
There's a patch for related bug 80047 that would make this worse:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583820.html

[Bug tree-optimization/103188] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Richard Biener  ---
Created attachment 51767
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51767&action=edit
patch I am testing

[Bug testsuite/103042] gcc.dg/vect/complex/bb-slp-complex-add-pattern-unsigned-long.c etc. FAIL

[tnfchris at gcc dot gnu.org via Gcc-bugs]

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

Tamar Christina  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Tamar Christina  ---
Cheers thanks for confirming

[Bug c++/103186] [11/12 Regression] ICE with fold-expression and lambdas as default

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/103189] [12 regression] g++.dg/tree-ssa/pta-delete-1.C etc. FAIL

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P1
 CC||hubicka at gcc dot gnu.org

[Bug tree-optimization/103189] [12 regression] g++.dg/tree-ssa/pta-delete-1.C etc. FAIL

[hubicka at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Jan Hubicka  ---
I wonder if you can attach .optimized dumps of valid revision and broken one. 
It may be related to modref/PTA changes.

[Bug tree-optimization/103188] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 Blocks||26163

--- Comment #5 from Martin Liška  ---
This breaks some SPEC benchmark builds:
warning: 447.dealII(peak; CE) benchmark build failed!
warning: 454.calculix(peak; CE) benchmark build failed!
warning: 464.h264ref(peak; CE) benchmark build failed!


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug tree-optimization/103188] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Martin Liška  ---
And reproduces with: gcc gcc/testsuite/gcc.dg/guality/pr89892.c -Os
-ftree-vectorize

[Bug tree-optimization/103190] New: [12 Regression] ICE in insert_stmt_after, at tree-ssa-reassoc.c:1452 since r12-431-ga310bb73edc9548e

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 103190
   Summary: [12 Regression] ICE in insert_stmt_after, at
tree-ssa-reassoc.c:1452 since
r12-431-ga310bb73edc9548e
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

The options are crazy, but still, it leads to a crash:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/slp-perm-8.c
-fno-tree-vrp -Ofast -fno-tree-forwprop -fnon-call-exceptions -fno-tree-ccp
-fsanitize=thread -fno-tree-fre -mavx512bw -fnon-call-exceptions -fexceptions
during GIMPLE pass: reassoc
In file included from
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/slp-perm-8.c:4:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/tree-vect.h: In function
'check_vect':
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/tree-vect.h:24:1:
internal compiler error: in insert_stmt_after, at tree-ssa-reassoc.c:1521
   24 | check_vect (void)
  | ^~
0x7b5bcc insert_stmt_after
/home/marxin/Programming/gcc/gcc/tree-ssa-reassoc.c:1521
0x10e283b build_and_add_sum
/home/marxin/Programming/gcc/gcc/tree-ssa-reassoc.c:1586
0x10eec3b eliminate_redundant_comparison
/home/marxin/Programming/gcc/gcc/tree-ssa-reassoc.c:2309
0x10eec3b optimize_ops_list
/home/marxin/Programming/gcc/gcc/tree-ssa-reassoc.c:2447
0x10f46ab reassociate_bb
/home/marxin/Programming/gcc/gcc/tree-ssa-reassoc.c:6631
0x10f4d1b reassociate_bb
/home/marxin/Programming/gcc/gcc/tree-ssa-reassoc.c:6793
0x10f709e do_reassoc
/home/marxin/Programming/gcc/gcc/tree-ssa-reassoc.c:6905
0x10f709e execute_reassoc
/home/marxin/Programming/gcc/gcc/tree-ssa-reassoc.c:6994
0x10f709e execute
/home/marxin/Programming/gcc/gcc/tree-ssa-reassoc.c:7035
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/103190] [12 Regression] ICE in insert_stmt_after, at tree-ssa-reassoc.c:1452 since r12-431-ga310bb73edc9548e

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-11-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |12.0

[Bug other/79872] document placeholder %K in gcc-internal-format

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #5 from Thomas Schwinge  ---
This one has been "resolved" via commit
r12-2089-g4f6e181181a48c341e524653cae0885fd170131e "Remove support for %G and
%K".

[Bug tree-optimization/83336] [meta-bug] Issues with displaying inlining chain for middle-end warnings

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

Bug 79872 Summary: document placeholder %K in gcc-internal-format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79872

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

[Bug tree-optimization/103188] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:8865133614f09caadf48c0b7d05f0331959b3bc1

commit r12-5155-g8865133614f09caadf48c0b7d05f0331959b3bc1
Author: Richard Biener 
Date:   Thu Nov 11 14:05:49 2021 +0100

tree-optimization/103188 - avoid running ranger on not-up-to-date SSA

The following splits loop header copying into an analysis phase
that uses ranger and a transform phase that can do without to avoid
running ranger on IL that has SSA form not updated.

2021-11-11  Richard Biener  

PR tree-optimization/103188
* tree-ssa-loop-ch.c (should_duplicate_loop_header_p):
Remove query parameter, split out check for size
optimization.
(ch_base::m_ranger, cb_base::m_query): Remove.
(ch_base::copy_headers): Split processing loop into
analysis around which we allocate and use ranger and
transform where we do not.
(pass_ch::execute): Do not allocate/free ranger here.
(pass_ch_vect::execute): Likewise.

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

[Bug tree-optimization/103188] [12 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

Summary|ICE on valid code at -O2|[12 Regression] ICE on
   |and -O3 on  |valid code at -O2 and -O3
   |x86_64-linux-gnu:   |on x86_64-linux-gnu:
   |Segmentation fault  |Segmentation fault
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Priority|P3  |P1
   Target Milestone|--- |12.0

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

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Bug 103188 Summary: [12 Regression] ICE on valid code at -O2 and -O3 on 
x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103188

   What|Removed |Added

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

[Bug libstdc++/103191] New: vector doesn't have any checks enabled by _GLIBCXX_ASSERTIONS

[redi at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 103191
   Summary: vector doesn't have any checks enabled by
_GLIBCXX_ASSERTIONS
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

We should consider this change:

diff --git a/libstdc++-v3/include/bits/stl_bvector.h
b/libstdc++-v3/include/bits/stl_bvector.h
index 1425877a5ea..32e22f5a056 100644
--- a/libstdc++-v3/include/bits/stl_bvector.h
+++ b/libstdc++-v3/include/bits/stl_bvector.h
@@ -1057,12 +1057,18 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
   reference
   operator[](size_type __n)
-  { return begin()[__n]; }
+  {
+   __glibcxx_requires_subscript(__n);
+   return begin()[__n];
+  }

   _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
   const_reference
   operator[](size_type __n) const
-  { return begin()[__n]; }
+  {
+   __glibcxx_requires_subscript(__n);
+   return begin()[__n];
+  }

 protected:
   _GLIBCXX20_CONSTEXPR
@@ -1106,22 +1112,34 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
   reference
   front()
-  { return *begin(); }
+  {
+   __glibcxx_requires_nonempty();
+   return *begin();
+  }

   _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
   const_reference
   front() const
-  { return *begin(); }
+  {
+   __glibcxx_requires_nonempty();
+   return *begin();
+  }

   _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
   reference
   back()
-  { return *(end() - 1); }
+  {
+   __glibcxx_requires_nonempty();
+   return *(end() - 1);
+  }

   _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
   const_reference
   back() const
-  { return *(end() - 1); }
+  {
+   __glibcxx_requires_nonempty();
+   return *(end() - 1);
+  }

   // _GLIBCXX_RESOLVE_LIB_DEFECTS
   // DR 464. Suggestion for new member functions in standard containers.

[Bug tree-optimization/103176] -foptimize-strlen causes stringop-overflow warning

[josiah_vanderzee at mediacombb dot net via Gcc-bugs]

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

--- Comment #3 from Josiah VanderZee  
---
Created attachment 51768
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51768&action=edit
Test case to reproduce strange -Wstringop-overflow warning

I'm worried this test case is too large to conveniently go through and
investigate. I tried to make a much smaller test case, but removing any part of
the attached code seems to completely break it. I read through the subString
implementation with great care, and I believe the warning is wrong, it is
impossible to access a -1 offset, unless there is undefined behavior going on.

The warning can be fixed by declaring a temporary variable temp in place of the
expression length + 1, and using temp - 1 to set the null terminator at the
end. I thought this meant that the warning simply saw the array[length] = 0 as
a common "wrong" pattern, but that was not enough to reproduce it, so clearly
something stranger is afoot.

[Bug tree-optimization/103190] [12 Regression] ICE in insert_stmt_after, at tree-ssa-reassoc.c:1452 since r12-431-ga310bb73edc9548e

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
eliminate_redundant_comparison still associates asm defs in this case, and it's
not an asm goto but the asm alters control flow because stmt_can_throw_internal
() returns true for it.  I'm not exactly sure why, but I suppose it's because
of the 'volatile'.  Anyway, the fix is quite obvious.

[Bug c++/95982] [10 Regression] ICE with non-type template parameter that is itself the instantiation of a template

[bence.kodaj at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Bence Kodaj  ---
For what it's worth, the bug is no longer present in gcc 11.1.

[Bug tree-optimization/103192] New: [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 103192
   Summary: [12 Regression] ICE on libgomp
target-in-reduction-2.{C,c}
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

I see ICE when compiling these testcases in a bootstrapped compiler:
../configure --enable-languages=default,ada,obj-c++,lto,go,d
--enable-checking=yes,rtl,extra && make -j32 bootstrap
cd x86_64-*/libgomp
make check RUNTESTFLAGS='c.exp=target-in-reduction-2.c
c++.exp=target-in-reduction-2*'
FAIL: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c (internal
compiler error)
FAIL: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c (test for
excess errors)
UNRESOLVED: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c
compilation failed to produce executable
FAIL: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c (internal
compiler error)
FAIL: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c (test for
excess errors)
UNRESOLVED: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c
compilation failed to produce executable
FAIL: libgomp.c++/target-in-reduction-2.C (internal compiler error)
FAIL: libgomp.c++/target-in-reduction-2.C (test for excess errors)
UNRESOLVED: libgomp.c++/target-in-reduction-2.C compilation failed to produce
executable
but can't reproduce that with stage1 gcc.
The ICE is in omp_add_variable being called with NULL first argument, but the
source code has:
  omp_add_variable (ctx, decl, flags);
  if ((OMP_CLAUSE_CODE (c) == OMP_CLAUSE_REDUCTION
   || OMP_CLAUSE_CODE (c) == OMP_CLAUSE_IN_REDUCTION
   || OMP_CLAUSE_CODE (c) == OMP_CLAUSE_TASK_REDUCTION)
  && OMP_CLAUSE_REDUCTION_PLACEHOLDER (c))
{
  struct gimplify_omp_ctx *pctx
= code == OMP_TARGET ? outer_ctx : ctx;
  if (pctx)
omp_add_variable (pctx, OMP_CLAUSE_REDUCTION_PLACEHOLDER (c),
  GOVD_LOCAL | GOVD_SEEN);
 Inside of the above call
  if (pctx
  && OMP_CLAUSE_REDUCTION_DECL_PLACEHOLDER (c)
  && walk_tree (&OMP_CLAUSE_REDUCTION_INIT (c),
find_decl_expr,
OMP_CLAUSE_REDUCTION_DECL_PLACEHOLDER (c),
NULL) == NULL_TREE)
omp_add_variable (pctx,
  OMP_CLAUSE_REDUCTION_DECL_PLACEHOLDER (c),
  GOVD_LOCAL | GOVD_SEEN);
outer_ctx can be NULL, ctx may not, but the source really should guarantee that
when code is OMP_TARGET (this case) and outer_ctx is NULL, then
omp_add_variable is not called.
In *.strlen1 dump I still see
   [local count: 22959172]:
  [../../gcc/gimplify.c:10067:33] # DEBUG pctx => iftmp.2373_1469
  [../../gcc/gimplify.c:10069:8] # DEBUG BEGIN_STMT
  [../../gcc/gimplify.c:10069:8] if (iftmp.2373_1469 != 0B)
goto ; [70.00%]
  else
goto ; [30.00%]

   [local count: 38024558]:
  [../../gcc/gimplify.c:10067:33] # DEBUG pctx => NULL
  [../../gcc/gimplify.c:10070:3] # DEBUG BEGIN_STMT
  [../../gcc/gimplify.c:10070:51] _761 = omp_clause_range_check (c_4680, 5, 7,
[../../gcc/gimplify.c:10070:51] "../../gcc/gimplify.c", 10070,
[../../gcc/gimplify.c:10070:51] "gimplify_scan_omp_clauses");
  [../../gcc/gimplify.c:10070:51] _762 = omp_clause_elt_check (_761, 3,
[../../gcc/gimplify.c:10070:51] "../../gcc/gimplify.c", 10070,
[../../gcc/gimplify.c:10070:51] "gimplify_scan_omp_clauses");
  [../../gcc/gimplify.c:10070:20] _763 = [../../gcc/gimplify.c:10070:20] *_762;
  [../../gcc/gimplify.c:10070:20] omp_add_variable (iftmp.2373_1469, _763,
129);
but in threadfull2 dump I see:
  [../../gcc/gimplify.c:10065:12] _3356 = [../../gcc/gimplify.c:10065:12]
MEM[(union tree_node * *)c_4680 + 80B];
  [../../gcc/gimplify.c:10065:8] if (_3356 != 0B)
goto ; [70.00%]
  else
goto ; [30.00%]
...
   [local count: 38024558]:
  [../../gcc/gimplify.c:10067:8] # DEBUG BEGIN_STMT
  [../../gcc/gimplify.c:10067:33] # DEBUG pctx => NULL
  [../../gcc/gimplify.c:10067:33] # DEBUG pctx => NULL
  [../../gcc/gimplify.c:10070:3] # DEBUG BEGIN_STMT
  [../../gcc/gimplify.c:10070:51] _761 = omp_clause_range_check (c_4680, 5, 7,
[../../gcc/gimplify.c:10070:51] "../../gcc/gimplify.c", 10070,
[../../gcc/gimplify.c:10070:51] "gimplify_scan_omp_clauses");
  [../../gcc/gimplify.c:10070:51] _762 = omp_clause_elt_check (_761, 3,
[../../gcc/gimplify.c:10070:51] "../../gcc/gimplify.c", 10070,
[../../gcc/gimplify.c:10070:51] "gimplify_scan_omp_clauses");
  [../../gcc/gimplify.c:10070:20] _763 = [../../gcc/gimplify.c:10070:20] *_762;
  [../../gcc/gimplify.c:10070:20] omp_

[Bug tree-optimization/103182] [12 Regression] Recent change causes code correctness regression

[law at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Jeffrey A. Law  ---
And just to be clear, Andrew's c#1 is correct.  It's 45967-2.c.

[Bug tree-optimization/103188] [12 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault

[aldyh at redhat dot com via Gcc-bugs]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at redhat dot com,
   ||amacleod at redhat dot com

--- Comment #9 from Aldy Hernandez  ---
(In reply to Richard Biener from comment #3)
> Caused by g:e82c382971664d6fd138cc36020db4b1a91885c6, the call tree roots at
> 
> #666394 0x015f2170 in should_duplicate_loop_header_p (
> header=, loop=0x766aa9f0, 
> limit=0x7fffd97c, query=0x3fccb70)
> at /home/rguenther/src/gcc3/gcc/tree-ssa-loop-ch.c:83
> 83&& !entry_loop_condition_is_static (loop, query))
> 
> likely ranger is confused by the intermediate IL (from other loops header
> copying), the IL is kept partly not in up-to-date SSA form (because running
> update_ssa is costly so we run it once after doing all header copying in
> a function).

Ughh, yeah.  Ranger won't do well with in-flight SSA.  I think we can do ok
with minimally changing IL like what evrp does with the substitute and fold
engine, but we expect things quite sane.

When working on this patch I saw the call to gimple_duplicate_sese_region would
increase the number of BBs, which caused problems in the cache and Andrew
fixed.  I thought that was it for issues, obviously not.

> 
> In this case we applied loop header copying to loop 4 containing loop 5
> which we are now processing.
> 
> Not up-to-date SSA form means that while SSA defs are copied, the SSA uses
> in a stmt are still old and _not_ replaced with their current definition.
> There's only so much you can do with such IL, in particular invoking SCEV
> isn't among that.
> 
> You can actually check whether a SSA name may be affected by checking
> name_registered_for_update_p.  SCEV doesn't do that.

Hmmm, useful.

> 
> In the end that means that we'd have to do the ranger analysis before
> actually applying the header copying.
> 
> Note that the current place of the
> 
>   /* Avoid loop header copying when optimizing for size unless we can
>  determine that the loop condition is static in the first
>  iteration.  */
>   if (optimize_loop_for_size_p (loop)
>   && !loop->force_vectorize
>   && !entry_loop_condition_is_static (loop, query))
> {
> 
> is off in any case, since we iterate on blocks to copy, instead it should
> be done exactly once per loop.  So we can do the "head", up until this
> and the very first should_duplicate_loop_header_p first for each loop,
> recording candidates in a vector and in a second loop process them all,
> not doing the already done entry_loop_condition_is_static.
> 
> Let me cook up a patch to do that.

Thanks for fixing this!

[Bug fortran/103174] ICE in gfc_match_varspec, at fortran/primary.c:2154 since r6-1958-g4668d6f9c00d4767

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
   Last reconfirmed||2021-11-11
 Ever confirmed|0   |1
Summary|ICE in gfc_match_varspec,   |ICE in gfc_match_varspec,
   |at fortran/primary.c:2154   |at fortran/primary.c:2154
   ||since
   ||r6-1958-g4668d6f9c00d4767

--- Comment #2 from Martin Liška  ---
Started with r6-1958-g4668d6f9c00d4767.

[Bug tree-optimization/103190] [12 Regression] ICE in insert_stmt_after, at tree-ssa-reassoc.c:1452 since r12-431-ga310bb73edc9548e

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r12-5158-gfac4c4bdab1735bd8a87e37c519f0260e4769f2a
Author: Richard Biener 
Date:   Thu Nov 11 15:12:32 2021 +0100

tree-optimization/103190 - fix assert in reassoc stmt placement with asm

This makes sure to only assert we don't run into a asm goto when
inserting a stmt in reassoc, matching the condition in
can_reassociate_p.  We can handle EH edges from an asm just like
EH edges from any other stmt.

2021-11-11  Richard Biener  

PR tree-optimization/103190
* tree-ssa-reassoc.c (insert_stmt_after): Only assert on asm goto.

[Bug tree-optimization/103190] [12 Regression] ICE in insert_stmt_after, at tree-ssa-reassoc.c:1452 since r12-431-ga310bb73edc9548e

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c/103193] New: gcc for x86_64: wrong code generation: ucomiss instead of comiss

[pavel.morozkin at gmail dot com via Gcc-bugs]

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

Bug ID: 103193
   Summary: gcc for x86_64: wrong code generation: ucomiss instead
of comiss
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pavel.morozkin at gmail dot com
  Target Milestone: ---

This code:
#pragma STDC FENV_ACCESS ON
float f;
_Bool b;
f = NAN;
b = f >= f; // ucomiss (wrong), comiss (correct)

results in:
ucomiss xmm0, DWORD PTR [rbp-4]


Per IEEE 754-2008 the ">=" is compareSignalingGreaterEqual, which can be
implemented using comiss.

Notes:
1. Yes, the #pragma STDC FENV_ACCESS ON is not yet supported. Just wanted to
point out that under #pragma STDC FENV_ACCESS ON gcc needs to generate comiss
(not ucomiss).
2. Adding volatile to float f; results in generation of comiss (expected).

[Bug d/103044] d: Use __builtin_clear_padding for zeroing objects before set.

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Segher Boessenkool :

https://gcc.gnu.org/g:8d71d3a317236ab4a69f441cf867a43aeb448150

commit r12-5160-g8d71d3a317236ab4a69f441cf867a43aeb448150
Author: Raphael Moreira Zinsly 
Date:   Thu Nov 11 11:40:10 2021 -0300

libgcc: Fix backtrace fallback on PowerPC Big-endian

At the end of the backtrace stream _Unwind_Find_FDE() may not be able
to find the frame unwind info and will later call the backtrace fallback
instead of finishing. This occurs when using an old libc on ppc64 due to
dl_iterate_phdr() not being able to set the fde in the last trace.
When this occurs the cfa of the trace will be behind of context's cfa.
Also, libgoâs probestackmaps() calls the backtrace with a null pointer
and can get to the backchain fallback with the same problem, in this case
we are only interested in find a stack map, we don't need nor can do a
backchain.
_Unwind_ForcedUnwind_Phase2() can hit the same issue as it uses
uw_frame_state_for(), so we need to treat _URC_NORMAL_STOP.

libgcc/ChangeLog:
PR libgcc/103044
* config/rs6000/linux-unwind.h (ppc_backchain_fallback): Check if
it's
called with a null argument or at the end of the backtrace and
return.
* unwind.inc (_Unwind_ForcedUnwind_Phase2): Treat _URC_NORMAL_STOP.

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

--- Comment #1 from Jakub Jelinek  ---
Seems to have started with r12-4790-g4b3a325f07acebf47e82de227ce1d5ba62f5bcae
(note, I was bisecting just the gimplify.ii dump with
-fpreprocessed gimplify.ii -quiet -dumpbase gimplify.c -dumpbase-ext .c
-mtune=generic -march=x86-64 -g -O2 -Wextra -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wsuggest-attribute=format
-Woverloaded-virtual -Wpedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -Wimplicit-fallthrough=0 -version -fno-PIE
-fchecking=1 -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fno-common
-o gimplify.s -fdump-tree-optimized-lineno
looking for line 10070 omp_add_variable call and the guarding condition.

[Bug libgcc/103004] [12 regression] r12-4416 breaks backtrace on PPC64 Big-endian

[segher at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Segher Boessenkool  ---
Bah, I typoed the PR id:

commit 8d71d3a317236ab4a69f441cf867a43aeb448150
Author: Raphael Moreira Zinsly 
Date:   Thu Nov 11 11:40:10 2021 -0300

libgcc: Fix backtrace fallback on PowerPC Big-endian

At the end of the backtrace stream _Unwind_Find_FDE() may not be able
to find the frame unwind info and will later call the backtrace fallback
instead of finishing. This occurs when using an old libc on ppc64 due to
dl_iterate_phdr() not being able to set the fde in the last trace.
When this occurs the cfa of the trace will be behind of context's cfa.
Also, libgo<80><99>s probestackmaps() calls the backtrace with a null
po
and can get to the backchain fallback with the same problem, in this case
we are only interested in find a stack map, we don't need nor can do a
backchain.
_Unwind_ForcedUnwind_Phase2() can hit the same issue as it uses
uw_frame_state_for(), so we need to treat _URC_NORMAL_STOP.

libgcc/ChangeLog:
PR libgcc/103044
* config/rs6000/linux-unwind.h (ppc_backchain_fallback): Check if it's
called with a null argument or at the end of the backtrace and return.
* unwind.inc (_Unwind_ForcedUnwind_Phase2): Treat _URC_NORMAL_STOP.

[Bug target/55610] cc1 is calling munmap() on part of itself on darwin

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||zhaixiang at loongson dot cn

--- Comment #9 from Eric Gallager  ---
Is this still an issue now that dragonegg isn't really a thing anymore? Last
update to it was years ago...

[Bug other/83520] format string bug in libvtv

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to Touma Hatano from comment #3)
> Sorry for misleading.
> My point was that if we can replace
>   snprintf (program_name, sizeof (program_name), program_invocation_name);
> with
>   snprintf (program_name, sizeof (program_name), "%s",
> program_invocation_name);
> , the program won't crash when program_invocation_name contains format
> specifiers.
> 
> How do you think?

Shouldn't -Wformat-security catch this? If it doesn't, that's a bug, IMO...

[Bug target/55610] cc1 is calling munmap() on part of itself on darwin

[iains at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Iain Sandoe  ---
(In reply to Eric Gallager from comment #9)
> Is this still an issue now that dragonegg isn't really a thing anymore? Last
> update to it was years ago...

oddly, the changes to support PIE might well squash this too 
- I agree dragonegg is not a thing, but other compiler plugins exist.

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

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #11 from Eric Gallager  ---
related to bug 17898

[Bug other/17898] Incorrect usage of isdigit, etc.

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #7 from Eric Gallager  ---
bug 95177 is similar

[Bug c/90843] pragma diagnostic doesn't affect warnings controlled by extra_warnings and pedantic

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
(In reply to Martin Sebor from comment #0)
> I thought there was a bug about this but I can't find it so let me open this
> one for reference...

bug 53075? bug 65505? bug 7651? bug 44209? Any of the others related to one of
those?

[Bug c/90843] pragma diagnostic doesn't affect warnings controlled by extra_warnings and pedantic

[egallager at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Eric Gallager  ---
(In reply to Eric Gallager from comment #1)
> (In reply to Martin Sebor from comment #0)
> > I thought there was a bug about this but I can't find it so let me open this
> > one for reference...
> 
> bug 53075? bug 65505? bug 7651? bug 44209? Any of the others related to one
> of those?

Oops wait that second one was a typo; I meant bug 66505

[Bug fortran/103043] gfortran can not write to files (macOS Monterey GCC 11.2.0)

[tkoenig at gcc dot gnu.org via Gcc-bugs]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #4 from Thomas Koenig  ---
You can flush the output before program end.

gfortran uses unit 6 as its standard output number, so
inserting the statement

  flush 6

should do the trick.

[Bug testsuite/103051] [12 regression] new test case gcc.dg/vect/tsvc/vect-tsvc-s112.c fails in r12-4840

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Martin Liška  ---
All right, so something like this should work, right?

diff --git a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s112.c
b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s112.c
index 3c6ae49f212..851b54e68b1 100644
--- a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s112.c
+++ b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s112.c
@@ -36,4 +36,4 @@ int main (int argc, char **argv)
   return 0;
 }

-/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
\ No newline at end of file
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target {
!powerpc*-*-* || has_arch_pwr8  } } } } */

[Bug gcov-profile/96092] Should --coverage respect -ffile-prefix-map?

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-Novembe
   ||r/584166.html

--- Comment #7 from Martin Liška  ---
Patch candidate was sent.

[Bug c/103194] New: ice in optimize_atomic_bit_test_and, at tree-ssa-ccp.c:3626

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 103194
   Summary: ice in optimize_atomic_bit_test_and, at
tree-ssa-ccp.c:3626
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C code:

long pscc_a_2_3;
int pscc_a_1_4;
void pscc()
{
pscc_a_1_4 = __sync_fetch_and_and(&pscc_a_2_3, 1);
}

compiled by recent gcc trunk, does this:

$ /home/dcb/gcc/results/bin/gcc -c -O1 bug771.c
during GIMPLE pass: fab
bug771.c: In function ‘pscc’:
bug771.c:3:6: internal compiler error: in optimize_atomic_bit_test_and, at
tree-ssa-ccp.c:3626
3 | void pscc()
  |  ^~~~
0xee6020 optimize_atomic_bit_test_and(gimple_stmt_iterator*, internal_fn, bool,
bool)
../../trunk.git/gcc/tree-ssa-ccp.c:3626
0xee389a (anonymous namespace)::pass_fold_builtins::execute(function*)
../../trunk.git/gcc/tree-ssa-ccp.c:0

The bug first seems to occur sometime between git hash f2572a398d21fd52
and a97fdde627e64202,a distance of some 60 commits.

In that range, commit fb161782545224f55ba26ba663889c5e6e9a04d1
looks a likely candidate.

[Bug c/103194] ice in optimize_atomic_bit_test_and, at tree-ssa-ccp.c:3626

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #1 from David Binderman  ---
Adding HJ. I hope I have the correct email account.

[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

--- Comment #7 from Xi Ruoyao  ---
New patch, for both PR 80047 and this one.

[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

--- Comment #8 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #7)
> New patch, for both PR 80047 and this one.

https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584164.html

[Bug bootstrap/80047] fixincludes/fixincl.c: PVS-Studio: Improper Release of Memory Before Removing Last Reference (CWE-401)

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

--- Comment #7 from Xi Ruoyao  ---
New patch for PR 21823 and this one:

https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584164.html

[Bug libgcc/103004] [12 regression] r12-4416 breaks backtrace on PPC64 Big-endian

[segher at gcc dot gnu.org via Gcc-bugs]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #6 from Segher Boessenkool  ---
Fixed.

[Bug other/103129] gcc/diagnostic-show-locus.c:692:18: warning: unused variable 'def_tabstop' [-Wunused-const-variable] since g:bd5e882cf6e0def3dd1bc106075d59a303fe0d1e

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r12-5176-gabdff441a07f55d16e3d0e5ced3123c83d210a0a
Author: David Malcolm 
Date:   Wed Nov 10 17:37:11 2021 -0500

diagnostic: fix unused variable 'def_tabstop' [PR103129]

gcc/ChangeLog:
PR other/103129
* diagnostic-show-locus.c (def_policy): Use def_tabstop.

Signed-off-by: David Malcolm 

[Bug other/103129] gcc/diagnostic-show-locus.c:692:18: warning: unused variable 'def_tabstop' [-Wunused-const-variable] since g:bd5e882cf6e0def3dd1bc106075d59a303fe0d1e

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #2 from David Malcolm  ---
Should be fixed by the above commit.

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ice in  |[12 Regression] ice in
   |optimize_atomic_bit_test_an |optimize_atomic_bit_test_an
   |d, at tree-ssa-ccp.c:3626   |d with __sync_fetch_and_and
  Component|c   |tree-optimization
   Target Milestone|--- |12.0
   Keywords||ice-on-valid-code
   Severity|normal  |blocker

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||pinskia at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-11-11
   Keywords||ice-on-valid-code,
   ||wrong-code

--- Comment #2 from Andrew Pinski  ---
Confirmed.

[Bug target/103193] gcc for x86_64: wrong code generation: ucomiss instead of comiss

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #1 from joseph at codesourcery dot com  ---
See bug 52451 and bug 91323 for previous cases of unordered comparisons 
being wrongly used on x86.

[Bug tree-optimization/103175] [12 Regression] internal compiler error: in handle_call_arg, at tree-ssa-structalias.c:4139

[seurer at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from seurer at gcc dot gnu.org ---
Also this one which fails but doesn't ICE

g:d70ef65692fced7ab72e0aceeff7407e5a34d96d, r12-5113
make  -k check-gcc-fortran
RUNTESTFLAGS="dg.exp=gfortran.dg/inline_matmul_17.f90"
FAIL: gfortran.dg/inline_matmul_17.f90   -O   scan-tree-dump-times optimized
"matmul_r4" 2

[Bug tree-optimization/103195] New: tfft2 text grows by 70% with -Ofast between g:52fa771758635d9c53cddb9116e5a66fae592230...a97fdde627e64202940112009d45d17f85e4cc61

[hubicka at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 103195
   Summary: tfft2 text grows by 70% with -Ofast between
g:52fa771758635d9c53cddb9116e5a66fae592230...a97fdde62
7e64202940112009d45d17f85e4cc61
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

This is seen at LTN here

https://lnt.opensuse.org/db_default/v4/CPP/24179
https://lnt.opensuse.org/db_default/v4/CPP/graph?highlight_run=24179&plot.0=14.799.4

and similarly on other testers.  Performance is not improved so it looks like
bit extreme even for -Ofast. It would be nice to know why such growth happens.