[Bug libgomp/106894] New: [13 regression] multiple libgomp failures after r13-2545-g9f2fca56593a2b

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

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

Bug ID: 106894
   Summary: [13 regression] multiple libgomp failures after
r13-2545-g9f2fca56593a2b
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

g:9f2fca56593a2b87026b399d26adcdca90705685, r13-2545-g9f2fca56593a2b: 62
failures

FAIL: libgomp.c++/../libgomp.c-c++-common/display-affinity-1.c execution test
FAIL: libgomp.c++/../libgomp.c-c++-common/icv-6.c execution test
FAIL: libgomp.c/../libgomp.c-c++-common/display-affinity-1.c execution test
FAIL: libgomp.c/../libgomp.c-c++-common/icv-6.c execution test
FAIL: libgomp.c/affinity-2.c execution test
FAIL: libgomp.fortran/affinity1.f90   -O2  execution test
FAIL: libgomp.fortran/affinity2.f90   -O2  execution test
FAIL: libgomp.fortran/display-affinity-1.f90   -O  execution test

I am not sure what the execution failures are reporting.  Here are two
examples:

spawn [open ...]^M
L:0%0>rain6p1.aus.stglabs.ibm.com rain6p1.aus.stglabs.ibm.com 
Date:   Thu Sep 8 10:01:33 2022 -0700

OpenMP, libgomp: Environment variable syntax extension

[Bug c++/106893] [12/13 Regression] auto deduces wrong type for function pointer

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Target Milestone|--- |12.3
Summary|auto deduces wrong type for |[12/13 Regression] auto
   |function pointer|deduces wrong type for
   ||function pointer
   Last reconfirmed||2022-09-08

--- Comment #1 from Andrew Pinski  ---
Reduced testcase:
template 
struct CoordTraits
{
static auto GetX(T const ) { return 1; }
};
typedef CoordTraits Traits;
static constexpr auto GetX = Traits::GetX;

[Bug c/106892] Wrong code at -O3 on x86_64-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
This is UB, isn't it?
g() <= 7 when g implicitly returns int, but doesn't return anything, falls
through to the end instead.

[Bug c++/106893] New: auto deduces wrong type for function pointer

[dan at stahlke dot org via Gcc-bugs]

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

Bug ID: 106893
   Summary: auto deduces wrong type for function pointer
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dan at stahlke dot org
  Target Milestone: ---

This works in 11.3.0 but not in 12.2.0.

struct IntegerCoordinate {
int x() const;
int y() const;
};

template 
struct CoordTraits
{
static auto GetX(T const ) { return p.x(); }
static auto GetY(T const ) { return p.y(); }
using Ordinate = decltype(GetX(T{}));
};

template 
struct Node {
static constexpr auto GetX = Traits::GetX; // works because of the `using
Ordinate = ...`
static constexpr auto GetY = Traits::GetY; // compilation error
// This compiles
//static constexpr auto GetX = ::GetX;
//static constexpr auto GetY = ::GetY;
// This compiles
//using fptr = int(*)(IntegerCoordinate const &);
//static constexpr fptr GetX = Traits::GetX;
//static constexpr fptr GetY = Traits::GetY;

// Not needed for minimal test case
auto x(auto const ) const { return GetX(p); }
auto y(auto const ) const { return GetY(p); }
};

int main() {
Node> node;
// Not needed for minimal test case
node.x(IntegerCoordinate{});
node.y(IntegerCoordinate{});
}


$ g++ -std=c++20 gcc-function-ptr-bug.cpp -c -o gcc-function-ptr-bug.o

gcc-function-ptr-bug.cpp: In instantiation of ‘constexpr auto (* const
Node >::GetY)(const IntegerCoordinate&)’:
gcc-function-ptr-bug.cpp:17:27:   required from ‘struct
Node >’
gcc-function-ptr-bug.cpp:32:42:   required from here
gcc-function-ptr-bug.cpp:17:27: error: invalid conversion from ‘int (*)(const
IntegerCoordinate&)’ to ‘auto (*)(const IntegerCoordinate&)’ [-fpermissive]
   17 | static constexpr auto GetY = Traits::GetY; // compilation error
  |   ^~~~
  |   |
  |   int (*)(const IntegerCoordinate&)
gcc-function-ptr-bug.cpp: In instantiation of ‘auto Node::y(const
auto:2&) const [with auto:2 = IntegerCoordinate; Traits =
CoordTraits]’:
gcc-function-ptr-bug.cpp:35:11:   required from here
gcc-function-ptr-bug.cpp:28:46: error: use of
‘Node >::GetY’ before deduction of ‘auto’
   28 | auto y(auto const ) const { return GetY(p); }
  |  ^~~

[Bug c/106892] New: Wrong code at -O3 on x86_64-linux-gnu

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 106892
   Summary: Wrong code at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
  Target Milestone: ---

$ gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-75f59441cd63a1d07e86d70d59c518049f53904f/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-75f59441cd63a1d07e86d70d59c518049f53904f
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220830 (experimental) (GCC)
$
$ gcc-tk -w -O0 simple.c && ./a.out
0
$ gcc-tk -w -O0 simple.c && ./a.out
3
$ 
$ cat simple.c
a, b, c, d, e;
f[8];
g() {
  while (a)
a >>= 4;
}
h(i) {
  if (i >= '0')
return i - '0';
}
j(i) {
  b = 2;
  for (; g() <= 7; b++)
if (i) {
  for (; e <= 7; e++) {
c = 1;
for (; c <= 7; c++) {
  d = h(b + 48);
  f[-d + 4] ^= 3;
}
  }
  return;
}
}
main() {
  j(1);
  printf("%d\n", f[2]);
}
$

[Bug preprocessor/106874] [10/11/12/13 Regression] out of memory allocating 9223372036854453969 bytes after a total of 462848 bytes

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
I suspect this is a dup of bug 78581.

[Bug c/89549] [10/11/12/13 Regression] -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers

[dblaikie at gmail dot com via Gcc-bugs]

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

David Blaikie  changed:

   What|Removed |Added

 CC||dblaikie at gmail dot com

--- Comment #23 from David Blaikie  ---
FWIW, the inability to disable this note has caused Clang to disable the
warning due to the noise. ( https://reviews.llvm.org/D132914 )

It'd be nice to have a way to enable the warning as "best effort" - knowing
that some files are too long to get checking.

(but also - it'd be nice if the warning were implemented in such a way that it
could scale up to indefinitely long files - it seems like that should be
possible to have a scalable implementation of the warning? (at least a version
that's linear in the number of lines in the file/or the number of lines in long
nested scopes?))

[Bug fortran/106670] [OpenMP][5.2] Warn for unknown '!$ompx' (!$omx') sentinels

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #2 from Tobias Burnus  ---
FIXED.

[Bug fortran/106670] [OpenMP][5.2] Warn for unknown '!$ompx' (!$omx') sentinels

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:264deecb16abcfc8ca8efe9b94b0ad55febd55cc

commit r13-2552-g264deecb16abcfc8ca8efe9b94b0ad55febd55cc
Author: Tobias Burnus 
Date:   Thu Sep 8 21:03:21 2022 +0200

OpenMP: Document ompx warnings + add Fortran omx warning [PR106670]

omp/ompx sentinels are for vendor extensions; as they might be required for
the correctness of the program, a warning should be printable. This patch
documents in the OpenMP 5.2 table the existing warnings, including the new
warning for for fixed source form Fortran.

PR fortran/106670

gcc/fortran/ChangeLog:

* scanner.cc (skip_fixed_omp_sentinel): Add -Wsurprising warning
for 'omx' sentinels with -fopenmp.
* invoke.texi (-Wsurprising): Document additional warning case.

libgomp/ChangeLog:

* libgomp.texi (OpenMP 5.2): Add comment to ompx/omx entry.

gcc/testsuite/ChangeLog:

* c-c++-common/gomp/ompx-1.c: New test.
* c-c++-common/gomp/ompx-2.c: New test.
* g++.dg/gomp/ompx-attrs-1.C: New test.
* gfortran.dg/gomp/ompx-1.f90: New test.
* gfortran.dg/gomp/omx-1.f: New test.
* gfortran.dg/gomp/omx-2.f: New test.

[Bug target/98862] Complex reduction support in offload region

[xw111luoye at gmail dot com via Gcc-bugs]

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

Ye Luo  changed:

   What|Removed |Added

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

--- Comment #4 from Ye Luo  ---
No fix needed.

[Bug libstdc++/88322] Implement C++20 library features.

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

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

Bug 88101 Summary: Implement P0528R3, C++20 cmpxchg and padding bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101

   What|Removed |Added

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

[Bug c++/88323] implement C++20 language features.

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

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

Bug 88101 Summary: Implement P0528R3, C++20 cmpxchg and padding bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101

   What|Removed |Added

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

[Bug libstdc++/88101] Implement P0528R3, C++20 cmpxchg and padding bits

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #14 from Jonathan Wakely  ---
With r13-2548-g157236dbd62164 the library side is done, so this is complete.

[Bug c++/106838] Built-in traits have wrong preconditions

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #10 from Jonathan Wakely  ---
Fixed on trunk.

[Bug c++/106838] Built-in traits have wrong preconditions

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

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

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

https://gcc.gnu.org/g:30c811f2bac73e63e0b461ba7ed3805b77898798

commit r13-2550-g30c811f2bac73e63e0b461ba7ed3805b77898798
Author: Jonathan Wakely 
Date:   Tue Sep 6 13:21:09 2022 +0100

c++: Fix type completeness checks for type traits [PR106838]

The check_trait_type function is used for a number of different type
traits that have different requirements on their arguments. For example,
__is_constructible allows arrays of unknown bound even if the array
element is an incomplete type, but __is_aggregate does not, it always
requires the array element type to be complete. Other traits have
different requirements again, e.g. __is_empty allows incomplete unions,
and arrays (of known or unknown bound) of incomplete types.

This alters the check_trait_type function to take an additional KIND
parameter which indicates which set of type trait requirements to check.

As noted in a comment, the requirements for __is_aggregate deviate from
the ones for std::is_aggregate in the standard. It's not necessary for
the elements of an array to be complete types, because arrays are always
aggregates.

The type_has_virtual_destructor change is needed to avoid an ICE.
Previously it could never be called for incomplete union types as they
were (incorrectly) rejected by check_trait_type.

This change causes some additional diagnostics in some libstdc++ tests,
where the front end was not previously complaining about invalid types
that the library assertions diagnosed. We should consider removing the
library assertions from traits where the front end implements the
correct checks now.

PR c++/106838

gcc/cp/ChangeLog:

* class.cc (type_has_virtual_destructor): Return false for
union types.
* semantics.cc (check_trait_type): Add KIND parameter to support
different sets of requirements.
(finish_trait_expr): Pass KIND argument for relevant traits.

gcc/ChangeLog:

* doc/extend.texi (Type Traits): Fix requirements. Document
__is_aggregate and __is_final.

gcc/testsuite/ChangeLog:

* g++.dg/ext/array4.C: Fix invalid use of __is_constructible.
* g++.dg/ext/unary_trait_incomplete.C: Fix tests for traits with
different requirements.

libstdc++-v3/ChangeLog:

* testsuite/20_util/is_complete_or_unbounded/memoization_neg.cc:
Prune additional errors from front-end.
* testsuite/20_util/is_move_constructible/incomplete_neg.cc:
Likewise.
* testsuite/20_util/is_nothrow_swappable/incomplete_neg.cc:
Likewise.
* testsuite/20_util/is_nothrow_swappable_with/incomplete_neg.cc:
Likewise.
* testsuite/20_util/is_swappable_with/incomplete_neg.cc:
Likewise.

[Bug c++/106889] __builtin_strlen fails for some constexpr constructs

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #2)
> I think std::strlen isn't constexpr even in latest C++, so all of this is
> permitted by the standard...

Right, which is why I recommend using char_traits::length instead.

[Bug analyzer/106625] RFE: support some symbolic values in -Wanalyzer-out-of-bounds

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Tim Lange :

https://gcc.gnu.org/g:7a6564c9b277d9f93582605758d57457de696deb

commit r13-2546-g7a6564c9b277d9f93582605758d57457de696deb
Author: Tim Lange 
Date:   Wed Sep 7 17:41:28 2022 +0200

analyzer: support for symbolic values in the out-of-bounds checker
[PR106625]

This patch adds support for reasoning about the inequality of two symbolic
values in the special case specifically suited for reasoning about
out-of-bounds past the end of the buffer. With this patch, the analyzer
catches off-by-one errors and more even when the offset and capacity is
symbolic.

Regrtested on Linux x86_64 and tested on coreutils, curl, httpd and
openssh as usual.

2022-09-07  Tim Lange  

gcc/analyzer/ChangeLog:

PR analyzer/106625
* analyzer.h (region_offset): Eliminate m_is_symbolic member.
* region-model-impl-calls.cc (region_model::impl_call_realloc):
Refine implementation to be more precise.
* region-model.cc (class symbolic_past_the_end):
Abstract diagnostic class to complain about accesses past the end
with symbolic values.
(class symbolic_buffer_overflow):
Concrete diagnostic class to complain about buffer overflows with
symbolic values.
(class symbolic_buffer_overread):
Concrete diagnostic class to complain about buffer overreads with
symbolic values.
(region_model::check_symbolic_bounds): New function.
(maybe_get_integer_cst_tree): New helper function.
(region_model::check_region_bounds):
Add call to check_symbolic_bounds if offset is not concrete.
(region_model::eval_condition_without_cm):
Add support for EQ_EXPR and GT_EXPR with binaryop_svalues.
(is_positive_svalue): New hleper function.
(region_model::symbolic_greater_than):
New function to handle GT_EXPR comparisons with symbolic values.
(region_model::structural_equality): New function to compare
whether two svalues are structured the same, i.e. evaluate to
the same value.
(test_struct): Reflect changes to region::calc_offset.
(test_var): Likewise.
(test_array_2): Likewise and add selftest with symbolic i.
* region-model.h (class region_model): Add check_symbolic_bounds,
symbolic_greater_than and structural_equality.
* region.cc (region::get_offset):
Reflect changes to region::calc_offset.
(region::calc_offset):
Compute the symbolic offset if the offset is not concrete.
(region::get_relative_symbolic_offset): New function to return the
symbolic offset in bytes relative to its parent.
(field_region::get_relative_symbolic_offset): Likewise.
(element_region::get_relative_symbolic_offset): Likewise.
(offset_region::get_relative_symbolic_offset): Likewise.
(bit_range_region::get_relative_symbolic_offset): Likewise.
* region.h: Add get_relative_symbolic_offset.
* store.cc (binding_key::make):
Reflect changes to region::calc_offset.
(binding_map::apply_ctor_val_to_range): Likewise.
(binding_map::apply_ctor_pair_to_child_region): Likewise.
(binding_cluster::bind_compound_sval): Likewise.
(binding_cluster::get_any_binding): Likewise.
(binding_cluster::maybe_get_compound_binding): Likewise.

gcc/ChangeLog:

PR analyzer/106625
* doc/invoke.texi:
State that the checker also reasons about symbolic values.

gcc/testsuite/ChangeLog:

PR analyzer/106625
* gcc.dg/analyzer/data-model-1.c: Change expected result.
* gcc.dg/analyzer/out-of-bounds-5.c: New test.
* gcc.dg/analyzer/out-of-bounds-realloc-grow.c: New test.
* gcc.dg/analyzer/symbolic-gt-1.c: New test.

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

[luto at kernel dot org via Gcc-bugs]

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

--- Comment #16 from Andy Lutomirski  ---
(In reply to Andrew Pinski from comment #13)
> Patient: Doctor it hurts when I do this.
> Doctor: then don't do that and if you read the instructions I gave you I
> told you I would hurt this way.

I think this analogy is off.  Maybe for most questionable optimization or
codegen options it would apply, but -ffast-math is more like:

Patient: Doctor, it hurts me when my neighbor does this.
Doctor: Then tell your neighbor not to read that and to read the fine print on
the box.

If nitroglycerin pills have side effects and patients need to read the label,
maybe fine.  But if they start exploding and breaking other peoples' windows,
that's a whole different problem.

[Bug c++/106889] __builtin_strlen fails for some constexpr constructs

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
__builtin_strlen like many other string/memory builtins simply tries the
middle-end folding and gives up otherwise.  So if it is called on a string
literal, it is folded, but if it would require reading the bytes of the string
one by one, it will most likely fail.
This has been discussed in some other PR that we should have a helper that
allows constexpr.cc to read a single character and as fallback for the string
builtins call those in a loop and essentially evaluate the builtins as a
non-optimized trivial C++ implementation of those builtins.
I think std::strlen isn't constexpr even in latest C++, so all of this is
permitted by the standard...

[Bug c++/106889] __builtin_strlen fails for some constexpr constructs

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

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

--- Comment #1 from Jonathan Wakely  ---
You can either use char_traits::length (which is actually required to
work in constexpr) or use __builtin_is_constant_evaluated() instead of your
workaround.

[Bug c++/106485] Can't use heap pointer in `static_assert`

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Johel Ernesto Guerrero Peña  ---
I think that's different. Actually, I think it's Clang that's wrong. As
mentioned at
https://cpplang.slack.com/archives/C21PKDHSL/p1656857369259539?thread_ts=1656856509.892079=C21PKDHSL:
> The expression of the `static_assert` is not an
> [immediate function 
> context](https://eel.is/c++draft/expr.const#def:immediate_function_context).
> Wrapping it in `[]() consteval { return s().empty(); }()` 
> [works](https://godbolt.org/z/PKTE7zofW),
> whereas removing that `consteval` causes Clang to also complain.

See https://godbolt.org/z/4GMxo13vv.
```C++
#include 
consteval auto s() { return std::string(); }
static_assert(s().empty()); // Only Clang accepts.
// static_assert([]() consteval { return s().empty(); }()); // All accept.
// static_assert([]() { return s().empty(); }()); // All reject.
```

Opened https://github.com/llvm/llvm-project/issues/57627 for that.

[Bug tree-optimization/106886] [13 Regression] ICE in vect_schedule_slp_node since r13-2348-gd2694766dcfff027

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Fixed.

[Bug tree-optimization/106886] [13 Regression] ICE in vect_schedule_slp_node since r13-2348-gd2694766dcfff027

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

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

--- Comment #5 from CVS Commits  ---
The trunk branch has been updated by Richard Sandiford :

https://gcc.gnu.org/g:338a5b0d7da84ef1f6c01dd96abf2c6bc830f403

commit r13-2544-g338a5b0d7da84ef1f6c01dd96abf2c6bc830f403
Author: Richard Sandiford 
Date:   Thu Sep 8 16:18:28 2022 +0100

vect: Fix scalar stmt typo in vect_optimize_slp_pass [PR106886]

Fix a stupid typo in my vect_optimize_slp_pass patch.

gcc/
PR tree-optimization/106886
* tree-vect-slp.cc
(vect_optimize_slp_pass::get_result_with_layout):
Fix copying of scalar stmts.

gcc/testsuite/
PR tree-optimization/106886
* gcc.dg/vect/bb-slp-layout-21.c: New test.

[Bug tree-optimization/106881] [13 Regression] ice in init_from_control_deps, at gimple-predicate-analysis.cc:1740 since r13-2500-g0a4a2667dc115ca7

[sbergman at redhat dot com via Gcc-bugs]

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

Stephan Bergmann  changed:

   What|Removed |Added

 CC||sbergman at redhat dot com

--- Comment #9 from Stephan Bergmann  ---
*** Bug 106891 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/106891] internal compiler error: in init_from_control_deps, at gimple-predicate-analysis.cc:1740

[sbergman at redhat dot com via Gcc-bugs]

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

Stephan Bergmann  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Stephan Bergmann  ---
(In reply to Richard Biener from comment #2)
> I believe this was fixed with r13-2537-gc8d3b44dfa2851, aka duplicate of
> PR106881

Yes, thanks, a fresh pull fixed my issue.

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

[Bug c++/99209] lambdas in function template signatures instantiated with wrong semantic context

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=105652
   Target Milestone|--- |12.2
 Resolution|--- |FIXED
 CC||ppalka at gcc dot gnu.org

--- Comment #4 from Patrick Palka  ---
This appears to be fixed for GCC 12.2/trunk by the fix for PR105652.

[Bug c++/99209] lambdas in function template signatures instantiated with wrong semantic context

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r13-2542-gf7280b04714c24af2854cf020b6e7b6ad3b7fba8
Author: Patrick Palka 
Date:   Thu Sep 8 10:49:04 2022 -0400

c++: Add testcase for already fixed PR [PR99209]

This was incidentally fixed by r13-806-g221acd67ca50f8.

PR c++/99209

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/lambda-uneval17.C: New test.

[Bug tree-optimization/106891] internal compiler error: in init_from_control_deps, at gimple-predicate-analysis.cc:1740

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-09-08
 Status|UNCONFIRMED |WAITING

--- Comment #2 from Richard Biener  ---
I believe this was fixed with r13-2537-gc8d3b44dfa2851, aka duplicate of
PR106881

[Bug tree-optimization/106891] internal compiler error: in init_from_control_deps, at gimple-predicate-analysis.cc:1740

[sbergman at redhat dot com via Gcc-bugs]

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

--- Comment #1 from Stephan Bergmann  ---
Created attachment 53553
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53553=edit
preprocessed source, gzipped to avoid bugzilla size limit

[Bug middle-end/106870] ctrl_altering flag is not set correctly

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

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

--- Comment #3 from Richard Biener  ---
This fixes some cases but leaves others not fixed.

[Bug middle-end/106870] ctrl_altering flag is not set correctly

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

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

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

https://gcc.gnu.org/g:78ef801b7263606d27a6a752a40cbeecc584fb3d

commit r13-2541-g78ef801b7263606d27a6a752a40cbeecc584fb3d
Author: Richard Biener 
Date:   Wed Sep 7 12:01:34 2022 +0200

Fix some gimple_ctrl_altering_p mistakes

CFG cleanup resets the control altering flag for noreturn functions
when they are ECF_LEAF (like __builtin_unreachable ()).  The
.ABNORMAL_DISPATCHER call built during CFG construction is not
marked as control altering.  Several passes inserting traps or
unreachables fail to set the flag.  And more.

PR middle-end/106870
* gimple-harden-conditionals.cc (insert_check_and_trap):
Set the control-altering flag on the built IFN_TRAP.
* gimple.cc (gimple_build_builtin_unreachable): Likewise.
* tree-cfg.cc (handle_abnormal_edges): Set the control-altering
flag on the .ABNORMAL_DISPATCHER call.
* tree-cfgcleanup.cc (cleanup_call_ctrl_altering_flag): Avoid
resetting the control altering flag for ECF_NORETURN calls.
(cleanup_control_flow_bb): Set the control altering flag on
discovered noreturn calls.
* symtab-thunks.cc (expand_thunk): Set the control altering
flag for the noreturn tailcall case.
* tree-eh.cc (lower_resx): Likewisw for trap and unwind_resume
calls.

[Bug tree-optimization/106891] New: internal compiler error: in init_from_control_deps, at gimple-predicate-analysis.cc:1740

[sbergman at redhat dot com via Gcc-bugs]

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

Bug ID: 106891
   Summary: internal compiler error: in init_from_control_deps, at
gimple-predicate-analysis.cc:1740
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

Bisecting shows this started with

"tree-optimization/106754 - fix compute_control_dep_chain defect":

> $ CCACHE_CPP2=1  /home/sbergman/gcc/trunk/inst/bin/g++ 
> -fdiagnostics-color=always -DBOOST_ERROR_CODE_HEADER_ONLY 
> -DBOOST_SYSTEM_NO_DEPRECATED -DCPPU_ENV=gcc3 -DDBG_UTIL -DLINUX 
> -DOSL_DEBUG_LEVEL=1 -DSAL_LOG_INFO -DSAL_LOG_WARN -DUNIX -DUNX -DX86_64 
> -D_DEBUG -D_GLIBCXX_DEBUG -D_PTHREADS -D_REENTRANT   -fvisibility=hidden 
> -Werror   -Wall -Wno-missing-braces -Wnon-virtual-dtor -Wendif-labels -Wextra 
> -Wundef -Wunreachable-code -Wshadow -Wunused-macros  -finput-charset=UTF-8 
> -fmessage-length=0 -fno-common -pipe -fstack-protector-strong  
> -Wdeprecated-copy-dtor -Wduplicated-cond -Wlogical-op -Wshift-overflow=2 
> -Wunused-const-variable=1 -Wno-cast-function-type -fvisibility-inlines-hidden 
> -fPIC -Wshadow -Woverloaded-virtual -std=c++23 -pthread  -O2 -ggdb2 
> -gsplit-dwarf -gdwarf-4 -ggnu-pubnames  -DEXCEPTIONS_ON -fexceptions
> -DLIBO_INTERNAL_ONLY  -c $S/configmgr/source/xcsparser.cxx -o 
> $W/CxxObject/configmgr/source/xcsparser.o -MMD -MT 
> $W/CxxObject/configmgr/source/xcsparser.o -MP -MF 
> $W/Dep/CxxObject/configmgr/source/xcsparser.d_ -I$S/external/boost/include 
> -I$W/UnpackedTarball/boost -I$S/include -I/usr/lib/jvm/java-17/include 
> -I/usr/lib/jvm/java-17/include/linux -I$S/config_host   -I/usr/include/dconf 
> -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include 
> -I/usr/include/sysprof-4 -I/usr/include/libmount -I/usr/include/blkid 
> -pthread   -I$W/UnoApiHeadersTarget/udkapi/normal 
> -I$W/UnoApiHeadersTarget/offapi/normal -freport-bug
> during GIMPLE pass: uninit
> /home/sbergman/lo2/core/configmgr/source/xcsparser.cxx: In member function 
> ‘void configmgr::XcsParser::handleProp(xmlreader::XmlReader&)’:
> /home/sbergman/lo2/core/configmgr/source/xcsparser.cxx:415:6: internal 
> compiler error: in init_from_control_deps, at 
> gimple-predicate-analysis.cc:1740
>   415 | void XcsParser::handleProp(xmlreader::XmlReader & reader) {
>   |  ^
> 0x94a678 predicate::init_from_control_deps(vec 
> const*, unsigned int, bool)
>   ../../src/gcc/gimple-predicate-analysis.cc:1740
> 0x1f65eaf predicate::init_from_control_deps(vec 
> const*, unsigned int, bool)
>   ../../src/gcc/gimple-predicate-analysis.cc:1715
> 0x1f65eaf uninit_analysis::init_use_preds(predicate&, basic_block_def*, 
> basic_block_def*)
>   ../../src/gcc/gimple-predicate-analysis.cc:1986
> 0x1f68fbf uninit_analysis::is_use_guarded(gimple*, basic_block_def*, gphi*, 
> unsigned int, hash_set >*)
>   ../../src/gcc/gimple-predicate-analysis.cc:2136
> 0x1f695d8 uninit_analysis::is_use_guarded(gimple*, basic_block_def*, gphi*, 
> unsigned int)
>   ../../src/gcc/gimple-predicate-analysis.cc:2177
> 0x1409ccc find_uninit_use
>   ../../src/gcc/tree-ssa-uninit.cc:1238
> 0x140a5fe warn_uninitialized_phi
>   ../../src/gcc/tree-ssa-uninit.cc:1308
> 0x140a5fe execute_late_warn_uninitialized
>   ../../src/gcc/tree-ssa-uninit.cc:1429
> 0x140a5fe execute
>   ../../src/gcc/tree-ssa-uninit.cc:1446
> Please submit a full bug report, with preprocessed source.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> Preprocessed source stored into /tmp/ccFZ1yef.out file, please attach this to 
> your bugreport.

[Bug tree-optimization/106878] [11/12/13 Regression] ICE: verify_gimple failed at -O2 with pointers and bitwise caluclation

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

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 53552
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53552=edit
gcc13-pr106878-3.patch

Or we can revert parts of Andrew's change and allow BIT_NOT_EXPR on pointers
and OFFSET_TYPE, because it is just weird if the 3 BIT_*_EXPR are inconsitent
with it.
Except this ICEs in the ranger, which wants to treat BIT_NOT_EXPR as
~X is simply -1 - X except that MINUS_EXPR isn't supported on pointers.

[Bug tree-optimization/106878] [11/12/13 Regression] ICE: verify_gimple failed at -O2 with pointers and bitwise caluclation

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

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 53551
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53551=edit
gcc13-pr106878-2.patch

Or we can instead just tweak my r11-35-g496f4f884716ae06 change and avoid
creating pointer BIT_*_EXPR in that case.  That fixes the testcase, but makes
all this stuff latent...

[Bug tree-optimization/106878] [11/12/13 Regression] ICE: verify_gimple failed at -O2 with pointers and bitwise caluclation

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

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 53550
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53550=edit
gcc13-pr106878-1.patch

Ugh, this is a mess.  The verifiers do allow BIT_AND_EXPR (intentionally for
realignment) and BIT_{I,X}OR_EXPR (just because it is similar) on pointer
types,
but since r12-1608-g2f1686ff70b25f BIT_NOT_EXPR is rejected on pointers.

I'm afraid allowing just BIT_AND_EXPR and disallowing BIT_{I,X}OR_EXPR or
BIT_NOT_EXPR would be a lot of work, this patch is what I spotted during
skimming of match.pd to make BIT_{AND,IOR,XOR}_EXPR work on pointer types and
not BIT_NOT_EXPR.

[Bug c++/99130] variable template in unevaluated context is instantiated when should not be

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|NEW |RESOLVED
   Target Milestone|--- |13.0
 CC||ppalka at gcc dot gnu.org

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 13, thanks for the bug report.

[Bug c++/99130] variable template in unevaluated context is instantiated when should not be

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:4db3cb781c355341fa041e6b5bbbfc495c6a0fdb

commit r13-2540-g4db3cb781c355341fa041e6b5bbbfc495c6a0fdb
Author: Patrick Palka 
Date:   Thu Sep 8 09:45:45 2022 -0400

c++: unnecessary instantiation of constexpr var [PR99130]

Here the use of 'value' from within an unevaluated context causes us
to overeagerly instantiate it, via maybe_instantiate_decl called from
mark_used, despite the use occurring in a context that doesn't require
a definition.

This seems to only affect constexpr variable specializations, though
we used to have the same issue for constexpr function specializations
until r6-1309-g81371eff9bc7ef made us delay their instantiation until
necessary during constexpr evaluation.

This patch expands upon the r6-1309 fix to make mark_used avoid
unnecessarily instantiating constexpr variable specializations too,
by pulling out from maybe_instantiate_decl the condition

  (decl_maybe_constant_var_p (decl)
   || (TREE_CODE (decl) == FUNCTION_DECL
   && DECL_OMP_DECLARE_REDUCTION_P (decl))
   || undeduced_auto_decl (decl))

into each of its three callers (including mark_used), removing the
problematic first test from mark_used, and simplifying accordingly.
The net result is that only mark_used is changed because the other two
callers, resolve_address_of_overloaded_function and decl_constant_var_p,
already guard the call appropriately.  (This relaxation of mark_used
seems to be safe because during constexpr evaluation we already take
care to instantiate a constexpr variable as necessary via
decl_constant_value etc).

PR c++/99130

gcc/cp/ChangeLog:

* decl2.cc (maybe_instantiate_decl): Adjust function comment.
Check VAR_OR_FUNCTION_DECL_P.  Pull out the disjunction into ...
(mark_used): ... here, removing the decl_maybe_constant_var_p
part of it.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-decltype5.C: New test.

[Bug tree-optimization/106878] [11/12/13 Regression] ICE: verify_gimple failed at -O2 with pointers and bitwise caluclation

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

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

--- Comment #3 from Jakub Jelinek  ---
Adjusted testcase that ICEs also on x86_64:
typedef __INTPTR_TYPE__ intptr_t;
typedef __UINTPTR_TYPE__ uintptr_t;
int a;

int
foo (const int *c)
{
  uintptr_t d = ((intptr_t) c | (intptr_t) ) & 65535 << 16;
  intptr_t e = (intptr_t) c;
  if (d != (e & 65535 << 16))
return 1;
  return 0;
}

[Bug tree-optimization/106886] [13 Regression] ICE in vect_schedule_slp_node since r13-2348-gd2694766dcfff027

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Oops, looks like a silly typo.  Testing a patch.

[Bug gcov-profile/93680] [GCOV] "do-while" structure in case statement leads to incorrect code coverage

[yangyibiao at nju dot edu.cn via Gcc-bugs]

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

Yibiao Yang  changed:

   What|Removed |Added

 CC||yangyibiao at nju dot edu.cn

--- Comment #3 from Yibiao Yang  ---
(In reply to Sunil Kumar from comment #2)
> I have executed same code in gcc 7.4.0 and i do not see the same behaviour.
> The case labels are properly marked as executed 5 times. please can you
> confirm this behaviour. And also the issues which are open items in gcov
> bugzilla list and reported in later gcc 7.4.0 version will those are
> applicable to gcc 7.4.0 ?

I do not check whether this problem is in gcc 7.4.0. This problem is found in
gcc version 9.2.0 (GCC). I re-check it in the trunk version and have the same
behavior as in gcc 9.2.0.

[Bug gcov-profile/97923] [GCOV]Wrong code coverage for multiple expressions with Logical OR Operator at multiple lines

[yangyibiao at nju dot edu.cn via Gcc-bugs]

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

--- Comment #4 from Yibiao Yang  ---
(In reply to Martin Liška from comment #3)
> Really, I see still the same:
> 
> $ gcc --version
> gcc (GCC) 13.0.0 20220908 (experimental)
> $ gcc -O0 --coverage test.c; ./a.out; gcov a-test.c; cat test.c.gcov
> File 'test.c'
> Lines executed:80.00% of 5
> Creating 'test.c.gcov'
> 
> Lines executed:80.00% of 5
> -:0:Source:test.c
> -:0:Graph:a-test.gcno
> -:0:Data:a-test.gcda
> -:0:Runs:1
> 1:1:int foo(int c)
> -:2:{
> #:3:  return ((c >= 'A' && c <= 'Z')
>1*:4:   || (c >= 'a' && c <= 'z')
>2*:5:   || (c >= '0' && c <= '0'));
> -:6:}
> -:7:
> 1:8:int main() { foo(0); }

Indeed, still the same. Sorry for this misleading info.

[Bug tree-optimization/106881] [13 Regression] ice in init_from_control_deps, at gimple-predicate-analysis.cc:1740 since r13-2500-g0a4a2667dc115ca7

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
Interesting, we have

 [count: 0]:
resx 3

 [count: 0]:
:
goto ; [100.00%]

with an EH edge from 10 to 11.  That looks like a missed optimization,
eliding the RESX and turning the EH edge into a fallthru.

[Bug tree-optimization/106881] [13 Regression] ice in init_from_control_deps, at gimple-predicate-analysis.cc:1740 since r13-2500-g0a4a2667dc115ca7

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

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

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

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

commit r13-2537-gc8d3b44dfa2851659f966627835497667c5fed6c
Author: Richard Biener 
Date:   Thu Sep 8 12:22:26 2022 +0200

tree-optimization/106881 - constrain uninit control edge add

The following avoids adding fallthru edges to the control chain from
the post-dominator walk.

PR tree-optimization/106881
* gimple-predicate-analysis.cc (compute_control_dep_chain_pdom):
Add only non-fallthru edges and avoid the same set of edges
as the caller does.

* gcc.dg/uninit-pr106881.c: New testcase.

[Bug testsuite/106872] [13 regression] gcc.dg/uninit-pred-12.c fails after r13-2500-g0a4a2667dc115c

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

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

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

https://gcc.gnu.org/g:794a01d7dcf306578bc5d0d147895c58a91506de

commit r13-2536-g794a01d7dcf306578bc5d0d147895c58a91506de
Author: Richard Biener 
Date:   Thu Sep 8 13:00:45 2022 +0200

testsuite/106872 - fix uninit predicate dump scan

On ppc we see a doloop temp rather than ivtmp.

PR testsuite/106872
* gcc.dg/uninit-pred-12.c: Adjust.

[Bug testsuite/106872] [13 regression] gcc.dg/uninit-pred-12.c fails after r13-2500-g0a4a2667dc115c

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug testsuite/106872] [13 regression] gcc.dg/uninit-pred-12.c fails after r13-2500-g0a4a2667dc115c

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

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

--- Comment #2 from Richard Biener  ---
Meh.

After normalization [USE]:
_3 = PHI 
  is conditional on:
((v_8(D) != 1) AND (w_13(D) != 0) AND (NOT (doloop.5_18 != 0)))

who decided to use 'doloop' here ... :/  I'll fix the pattern.

[Bug tree-optimization/106884] ifcombine may move shift so it shifts more than bitwidth

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

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

--- Comment #2 from Krister Walfridsson  ---
This optimization is invalid if (int)1 << 33 is _not_ undefined behavior in
GIMPLE!

Consider an architecture where (int)1 << 33 evaluates to 0. foo(2, 1, 33)
evaluates to 0 for the original GIMPLE, but it evaluates to 2 in the optimized
IR.

[Bug c++/106890] [10/11/12/13 Regression] virtual inheritance triggers compiler error when instatiating derived class with in-class initialization since r8-2709-g12659e10c7820071

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |10.5

[Bug c++/106890] [10/11/12/13 Regression] virtual inheritance triggers compiler error when instatiating derived class with in-class initialization since r8-2709-g12659e10c7820071

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|virtual inheritance |[10/11/12/13 Regression]
   |triggers compiler error |virtual inheritance
   |when instatiating derived   |triggers compiler error
   |class with in-class |when instatiating derived
   |initialization  |class with in-class
   ||initialization since
   ||r8-2709-g12659e10c7820071
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-09-08

--- Comment #1 from Martin Liška  ---
Confirmed, started with r8-2709-g12659e10c7820071.

[Bug c++/106890] New: virtual inheritance triggers compiler error when instatiating derived class with in-class initialization

[thomas at thomaslabs dot org via Gcc-bugs]

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

Bug ID: 106890
   Summary: virtual inheritance triggers compiler error when
instatiating derived class with in-class
initialization
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas at thomaslabs dot org
  Target Milestone: ---

Created attachment 53549
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53549=edit
The exact source code used to trigger the error

The following code sample triggers an internal compiler error. This happends
when using the virtual keyword in the definition of B and is related to the
function call to f inside the class definition. When later attempting to
instantiate the class B the compiler fails.

I'm working with GCC version 12.2.0 but this bug seems to be present as early
as version 8.5.0. Version 7.5.0 managed to compile without a problem.

* Command line 

g++ bug.cpp

* Compiler output:

during RTL pass: expand
bug.cpp: In constructor ‘B::B(int) [with T = int]’:
bug.cpp:26:5: internal compiler error: in expand_expr_real_1, at expr.cc:10586
   26 | B(int a) {
  | ^
0x1b286a6 internal_error(char const*, ...)
???:0
0x6ccc1e fancy_abort(char const*, int, char const*)
???:0

* Compiler version:

GNU C++17 (GCC) version 12.2.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 12.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.23-GMP

* System

GNU/Guix x86_64

* Source code

class O
{
public:
int f() {
return 1;
}
};

template
class A
{
public:
A();
A(int a);

protected:
O p = O();
};

template
class B : virtual public A
{
public:
B() {
}
B(int a) {
}

protected:
using A::p;
unsigned int k = p.f();
};

template class B;

int main()
{
return 0;
}

[Bug other/106872] [13 regression] gcc.dg/uninit-pred-12.c fails after r13-2500-g0a4a2667dc115c

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-09-08
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |13.0

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

[Bug tree-optimization/106886] [13 Regression] ICE in vect_schedule_slp_node since r13-2348-gd2694766dcfff027

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
  Component|c   |tree-optimization
Version|12.0|13.0

[Bug sanitizer/106885] -(a-b) is folded to b-a before the UBSAN pass is run

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-09-08
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
We have ugly TYPE_OVERFLOW_SANITIZED checks in folding but it would be much
better if the sanitizing would happen before any folding is invoked ...

#0  fold_unary_loc (loc=258791, code=NEGATE_EXPR, 
type=, op0=)
at /home/rguenther/src/trunk/gcc/fold-const.cc:9275
#1  0x00f5d084 in fold (expr=)
at /home/rguenther/src/trunk/gcc/fold-const.cc:13421
#2  0x00beca8c in c_fully_fold_internal (
expr=, in_init=false, 
maybe_const_operands=0x7fffd5ab, maybe_const_itself=0x7fffd5aa, 
for_int_const=false, lval=false)
at /home/rguenther/src/trunk/gcc/c/c-fold.cc:494
#3  0x00beab7e in c_fully_fold (expr=, 
in_init=false, maybe_const=0x7fffd5ab, lval=false)
at /home/rguenther/src/trunk/gcc/c/c-fold.cc:125
#4  0x00b7a840 in c_finish_return (loc=258791, 
retval=, origtype=)
at /home/rguenther/src/trunk/gcc/c/c-typeck.cc:10927

and match.pd exempts itself:

/* -(A - B) -> B - A.  */
(simplify
 (negate (minus @0 @1))
 (if ((ANY_INTEGRAL_TYPE_P (type) && !TYPE_OVERFLOW_SANITIZED (type))
  || (FLOAT_TYPE_P (type)
  && !HONOR_SIGN_DEPENDENT_ROUNDING (type)
  && !HONOR_SIGNED_ZEROS (type)))
  (minus @1 @0)))

but fold_negate_expr_1 does not:

638 case MINUS_EXPR:
639   /* - (A - B) -> B - A  */
640   if (!HONOR_SIGN_DEPENDENT_ROUNDING (type)
641   && !HONOR_SIGNED_ZEROS (type))
642 return fold_build2_loc (loc, MINUS_EXPR, type,
643 TREE_OPERAND (t, 1), TREE_OPERAND (t,
0));
644   break;

[Bug tree-optimization/106884] ifcombine may move shift so it shifts more than bitwidth

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-09-08
 Depends on||106811

--- Comment #1 from Richard Biener  ---
Confirmed.  r13-131-gc2a0d2e6f636c6 addressed some issues, but leaves others
such as shifts seen here.  It's not clear if (int)1 << 33 is undefined behavior
in
GIMPLE, see PR106811.  Note that ifcombine doesn't simply transform this to
(x & c) & (x & (1 << b)), thus removing the short-circuiting, instead it
computes tem = c | (1

[Bug c/106886] [13 Regression] ICE in vect_schedule_slp_node since r13-2348-gd2694766dcfff027

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-09-08
Summary|ice in  |[13 Regression] ICE in
   |vect_schedule_slp_node  |vect_schedule_slp_node
   ||since
   ||r13-2348-gd2694766dcfff027
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Started with r13-2348-gd2694766dcfff027.

[Bug tree-optimization/106888] [RISCV] Negative optimization that excess andi instructions are generated in gcc.dg/pr90838.c

[shihua at iscas dot ac.cn via Gcc-bugs]

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

--- Comment #1 from shihua at iscas dot ac.cn  ---
This patch is 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c23a9c87cc62bd177fd0d4db6ad34b34e1b9a31f

[Bug c++/106889] New: __builtin_strlen fails for some constexpr constructs

[m.cencora at gmail dot com via Gcc-bugs]

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

Bug ID: 106889
   Summary: __builtin_strlen fails for some constexpr constructs
   Product: gcc
   Version: 10.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.cencora at gmail dot com
  Target Milestone: ---

Compiling following program on any gcc version, with C++14 or newer standard
fails with
"'__builtin_strlen(...)' is not a constant expression" for some of the static
asserts.

It compiles successfuly on clang.


g++ -std=c++14

constexpr unsigned constexpr_strlen(const char* str)
{
#ifdef WORKAROUND
if (!__builtin_constant_p(str))
{
unsigned i = 0;
while (str[i] != '\0')
{
   ++i;
}
return i;
}
#endif
return __builtin_strlen(str);
}

struct StaticString
{
constexpr StaticString(const char ()[4])
: buf{src[0], src[1], src[2], src[3]}
{}

constexpr const char* data() const
{
return [0];
}

char buf[4];
};

constexpr StaticString createStaticString()
{
return {"foo"};
}

constexpr const char *s1 = "foo";
constexpr const char s2[] = "foo";
constexpr StaticString s3{"foo"};
constexpr StaticString s4 = s2;
constexpr StaticString s5 = s4;
constexpr StaticString s6 = createStaticString();

void test()
{
constexpr const char *s7 = "foo";
constexpr const char s8[] = "foo";
constexpr StaticString s9{"foo"};
constexpr StaticString s10 = s8;
constexpr StaticString s11 = s10;
constexpr StaticString s12 = createStaticString();

static constexpr const char *s13 = "foo";
static constexpr const char s14[] = "foo";
static constexpr StaticString s15{"foo"};
static constexpr StaticString s16 = s14;
static constexpr StaticString s17 = s6;
static constexpr StaticString s18 = createStaticString();

static_assert(constexpr_strlen(s1) == 3, "");
static_assert(constexpr_strlen(s2) == 3, "");
static_assert(constexpr_strlen(s3.data()) == 3, "");
static_assert(constexpr_strlen(s4.data()) == 3, ""); // ERROR
static_assert(constexpr_strlen(s5.data()) == 3, ""); // ERROR 
static_assert(constexpr_strlen(s6.data()) == 3, ""); // ERROR
static_assert(constexpr_strlen(s7) == 3, "");
static_assert(constexpr_strlen(s8) == 3, ""); // ERROR
static_assert(constexpr_strlen(s9.data()) == 3, ""); // ERROR
static_assert(constexpr_strlen(s10.data()) == 3, ""); // ERROR
static_assert(constexpr_strlen(s11.data()) == 3, ""); // ERROR
static_assert(constexpr_strlen(s12.data()) == 3, ""); // ERROR
static_assert(constexpr_strlen(s13) == 3, "");
static_assert(constexpr_strlen(s14) == 3, "");
static_assert(constexpr_strlen(s15.data()) == 3, "");
static_assert(constexpr_strlen(s16.data()) == 3, ""); // ERROR
static_assert(constexpr_strlen(s17.data()) == 3, ""); // ERROR
static_assert(constexpr_strlen(s18.data()) == 3, ""); // ERROR
}

[Bug tree-optimization/106883] SLSR may generate signed wrap

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-09-08
 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Confirmed - thanks for reporting!  Since there's a VRP pass after SLSR it might
be possible to craft a testcase that fails at runtime.

[Bug gcov-profile/97923] [GCOV]Wrong code coverage for multiple expressions with Logical OR Operator at multiple lines

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

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

--- Comment #3 from Martin Liška  ---
Really, I see still the same:

$ gcc --version
gcc (GCC) 13.0.0 20220908 (experimental)
$ gcc -O0 --coverage test.c; ./a.out; gcov a-test.c; cat test.c.gcov
File 'test.c'
Lines executed:80.00% of 5
Creating 'test.c.gcov'

Lines executed:80.00% of 5
-:0:Source:test.c
-:0:Graph:a-test.gcno
-:0:Data:a-test.gcda
-:0:Runs:1
1:1:int foo(int c)
-:2:{
#:3:  return ((c >= 'A' && c <= 'Z')
   1*:4:   || (c >= 'a' && c <= 'z')
   2*:5:   || (c >= '0' && c <= '0'));
-:6:}
-:7:
1:8:int main() { foo(0); }

[Bug regression/106888] New: [RISCV] Excess andi instructions are generated in gcc.dg/pr90838.c

[shihua at iscas dot ac.cn via Gcc-bugs]

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

Bug ID: 106888
   Summary: [RISCV] Excess andi instructions are generated  in
gcc.dg/pr90838.c
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shihua at iscas dot ac.cn
  Target Milestone: ---

After this patch（
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c23a9c87cc62bd177fd0d4db6ad34b34e1b9a31f），gcc.dg/pr90838.c
failed.

Before：


.attribute arch, "rv64i2p0_m2p0_a2p0_f2p0_d2p0_c2p0_zbb1p0"
.attribute unaligned_access, 0
.attribute stack_align, 16
.text

.align  1
.globl  ctz2
.type   ctz2, @function
ctz2:
ctzwa0,a0
ret
.size   ctz2, .-ctz2
.align  1
.globl  ctz3
.type   ctz3, @function
ctz3:
ctzwa0,a0
ret
.size   ctz3, .-ctz3


After:

.attribute arch, "rv64i2p0_m2p0_a2p0_f2p0_d2p0_c2p0_zbb1p0"
.attribute unaligned_access, 0
.attribute stack_align, 16
.text
.align  1
.globl  ctz1
.type   ctz1, @function
ctz2:
ctzwa0,a0
andia0,a0,127
ret
.size   ctz2, .-ctz2
.align  1
.globl  ctz3
.type   ctz3, @function
ctz3:
ctzwa0,a0
andia0,a0,127
ret
.size   ctz3, .-ctz3

[Bug tree-optimization/106881] [13 Regression] ice in init_from_control_deps, at gimple-predicate-analysis.cc:1740 since r13-2500-g0a4a2667dc115ca7

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Mine.

[Bug testsuite/106879] [13 regression] new test case gcc.dg/vect/bb-slp-layout-19.c fails

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug tree-optimization/106878] [11/12/13 Regression] ICE: verify_gimple failed at -O2 with pointers and bitwise caluclation

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/106877] [12/13 Regression] ICE in move_for_stack_reg, at reg-stack.cc:1076 since r12-248-gb58dc0b803057c0e

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.3

[Bug c/106874] [10/11/12/13 Regression] out of memory allocating 9223372036854453969 bytes after a total of 462848 bytes

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.5

[Bug c/106874] [10/11/12/13 Regression] out of memory allocating 9223372036854453969 bytes after a total of 462848 bytes

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-09-08
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Hmm, with GCC 11 I see

> gcc-11 -c function_macro_file.c -traditional-cpp
function_macro_file.h:2:1: error: expected '=', ',', ';', 'asm' or
'__attribute__' at end of input
2 | f
  | ^

I can confirm with GCC 10.  Also with a dev build of GCC 11, but not 12. 
Backtrace there:

#0  0x76762c7e in exit () from /lib64/libc.so.6
#1  0x021bd904 in xexit (code=1)
at ../../src/gcc-11-branch/libiberty/xexit.c:51
#2  0x021bd9e4 in xmalloc_failed (size=9223372036854299649)
at ../../src/gcc-11-branch/libiberty/xmalloc.c:137
#3  0x021bdaed in xrealloc (oldmem=0x32c9df0, size=9223372036854299649)
at ../../src/gcc-11-branch/libiberty/xmalloc.c:181
#4  0x0217459b in check_output_buffer (pfile=0x3245a80, 
n=18446744073709234176) at ../../src/gcc-11-branch/libcpp/traditional.c:114
#5  0x02174eb3 in _cpp_scan_out_logical_line (pfile=0x3245a80, 
macro=0x0, builtin_macro_arg=false)
at ../../src/gcc-11-branch/libcpp/traditional.c:418
#6  0x02174b4d in _cpp_read_logical_line_trad (pfile=0x3245a80)
at ../../src/gcc-11-branch/libcpp/traditional.c:321
#7  0x00aff763 in scan_translation_unit_trad (pfile=0x3245a80)
at ../../src/gcc-11-branch/gcc/c-family/c-ppoutput.c:420
#8  0x00afeb80 in preprocess_file (pfile=0x3245a80)
at ../../src/gcc-11-branch/gcc/c-family/c-ppoutput.c:97
#9  0x00afcb25 in c_common_init ()
...

#4  0x0217459b in check_output_buffer (pfile=0x3245a80, 
n=18446744073709234176) at ../../src/gcc-11-branch/libcpp/traditional.c:114
114   pfile->out.base = XRESIZEVEC (unsigned char, pfile->out.base,
new_size);
(gdb) l
109   if (n > (size_t) (pfile->out.limit - pfile->out.cur))
110 {
111   size_t size = pfile->out.cur - pfile->out.base;
112   size_t new_size = (size + n) * 3 / 2;
113
114   pfile->out.base = XRESIZEVEC (unsigned char, pfile->out.base,
new_size);
(gdb) up
#5  0x02174eb3 in _cpp_scan_out_logical_line (pfile=0x3245a80, 
macro=0x0, builtin_macro_arg=false)
at ../../src/gcc-11-branch/libcpp/traditional.c:418
418   check_output_buffer (pfile, RLIMIT (context) - cur);
(gdb) p *context
$2 = {next = 0x0, prev = 0x0, u = {iso = {first = {token = 0x32aa023, 
ptoken = 0x32aa023}, last = {token = 0x325c820, ptoken = 0x325c820}}, 
trad = {cur = 0x32aa023 "\n\n", rlimit = 0x325c820 "\n"}}, buff = 0x0, 
  c = {mc = 0x0, macro = 0x0}, tokens_kind = TOKENS_KIND_INDIRECT}

[Bug fortran/106856] [12/13 Regression] ICE in gfc_conv_expr_present, at fortran/trans-expr.cc:1977 since r12-4346-geb92cd57a1ebe7cd

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

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

--- Comment #2 from Tobias Burnus  ---
Created attachment 53548
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53548=edit
draft patch

Draft patch - the actual issue seems to work fine (first testcase, extended) –
however, I have still once ICE and bogus attribute errors (both: second
testcase)

Currently running out of time to work on this → deferred.

[Bug c++/106847] deprecated class data member makes the class generate diagnostics even when the member is not used

[avi at scylladb dot com via Gcc-bugs]

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

--- Comment #3 from Avi Kivity  ---
But I need it to be copied. It's a struct of options:


struct options {
 bool frob = false;
 [[derecated]] bool quux = false; // will be removed soon
 bool grue = false;
 };


The fact that it's deprecated doesn't mean it can be coerced to false.

Sure, I can create custom constructors and assignment operators, but I lose
designated initializers.

btw, the destructor doesn't trigger the deprecation warning, even though it
does use the deprecated member.


I think it's more reasonable to only emit the warning when the member is
explicitly used.

[Bug target/106887] ICE in extract_insn, at recog.cc:2791 since r13-2111-g6910cad55ffc330d

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||hjl at gcc dot gnu.org
   Last reconfirmed||2022-09-08
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Host||x86_64-linux-gnu
   Target Milestone|--- |13.0

[Bug target/106887] New: ICE in extract_insn, at recog.cc:2791 since r13-2111-g6910cad55ffc330d

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

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

Bug ID: 106887
   Summary: ICE in extract_insn, at recog.cc:2791 since
r13-2111-g6910cad55ffc330d
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: lingling.kong7 at gmail dot com
  Target Milestone: ---

The following crashes:

$ cat bf16.i
typedef __bf16 v16bf __attribute__((__vector_size__(32)));

void
vec_init_dup_v16bf() {
  __bf16 a1;
  (v16bf){a1, a1, a1, a1, a1, a1, a1, a1, a1, a1, a1, a1, a1, a1, a1, a1};
}

$ gcc bf16.i -c -mf16c
bf16.i: In function ‘vec_init_dup_v16bf’:
bf16.i:7:1: error: unrecognizable insn:
7 | }
  | ^
(insn 11 10 12 2 (set (reg:V16BF 83)
(vec_concat:V16BF (reg:V16QI 84)
(reg:V16QI 84))) "bf16.i":6:10 -1
 (nil))
during RTL pass: vregs
bf16.i:7:1: internal compiler error: in extract_insn, at recog.cc:2791
0x77971c _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/marxin/Programming/gcc/gcc/rtl-error.cc:108
0x77973e _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/rtl-error.cc:116
0x77794b extract_insn(rtx_insn*)
/home/marxin/Programming/gcc/gcc/recog.cc:2791
0xbf1315 instantiate_virtual_regs_in_insn
/home/marxin/Programming/gcc/gcc/function.cc:1611
0xbf1315 instantiate_virtual_regs
/home/marxin/Programming/gcc/gcc/function.cc:1985
0xbf1315 execute
/home/marxin/Programming/gcc/gcc/function.cc:2034
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug gcov-profile/97923] [GCOV]Wrong code coverage for multiple expressions with Logical OR Operator at multiple lines

[yangyibiao at nju dot edu.cn via Gcc-bugs]

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

Yibiao Yang  changed:

   What|Removed |Added

 CC||yangyibiao at nju dot edu.cn

--- Comment #2 from Yibiao Yang  ---
In the trunk version, Line #5 has no coverage info which considered as
''safe''. 
I was wondering taht whether this bug can be marked as fixed.

[Bug c/106886] ice in vect_schedule_slp_node

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
Reduced C code seems to be:

rl2GeomExport64_little_endian, rl2GeomExport64_little_endian_arch;
rl2GeomExport64(unsigned char *p, double value) {
  union {
unsigned char byte[8];
double double_value
  } convert;
  convert.double_value = value;
  if (rl2GeomExport64_little_endian_arch)
if (rl2GeomExport64_little_endian) {
  *(p + 7) = convert.byte[0];
  *(p + 6) = convert.byte[1];
  *(p + 5) = convert.byte[2];
  *(p + 4) = convert.byte[3];
  *(p + 3) = convert.byte[4];
  *(p + 2) = convert.byte[5];
  *(p + 1) = convert.byte[6];
  *p = convert.byte[7];
} else
  *p = convert.byte[7];
}