[Bug ipa/106716] Identical Code Folding (-fipa-icf) confuses between functions with different [[likely]] attributes

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

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

--- Comment #3 from Andrew Pinski  ---

[[unlikely]]/[[likely]] attribute gets expanded into
PREDICT_EXPR:PRED_HOT_LABEL/PRED_COLD_LABEL:TAKEN/NOT_TAKEN see
cp/cp-gimplify.cc (process_stmt_hotness_attribute) and is removed.
And that is all done in the front-end.

PREDICT_EXPR gets expanded into GIMPLE_PREDICT (via gimplify_expr in
gimplify.cc)

And then the code in sem_function::init ignores GIMPLE_PREDICT .

Which was done in r5-7496-a8d9381738d22
(https://gcc.gnu.org/pipermail/gcc-patches/2015-March/413730.html )

[Bug ipa/106716] Identical Code Folding (-fipa-icf) confuses between functions with different [[likely]] attributes

[tomerv at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Tomer Vromen  ---
IMO, attribute information should be checked in this optimization stage, so
that ipa-icf knows the functions are different. It seems like maybe this is
already partially the behavior - removing the attribute from one of the
functions makes them different again after ipa-icf. Maybe the existence of the
attribute is considered, but not its value? There's some code in
sem_item::compare_referenced_symbol_properties() that looks like it's trying to
do this.

[Bug tree-optimization/106099] [13 Regression] ICE in execute_todo, at passes.cc:2134 since r13-1204-gd68d366425369649

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #11 from Zdenek Sojka  ---
And with another degenerate flags on the testcase above:
# x86_64-pc-linux-gnu-gcc -O -fno-tree-forwprop -fno-tree-dominator-opts
-fharden-conditional-branches -funreachable-traps -fno-tree-ccp
--param=max-loop-header-insns=0 --param=scev-max-expr-size=0 testcase.c
during GIMPLE pass: optimized
testcase.c: In function 'foo':
testcase.c:2:1: internal compiler error: in execute_todo, at passes.cc:2140
2 | foo (void)
  | ^~~
0x75d426 execute_todo
/repo/gcc-trunk/gcc/passes.cc:2140
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 tree-optimization/106717] New: [13 Regression] ICE: tree check: expected integer_cst, have poly_int_cst in get_len, at tree.h:6247

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 106717
   Summary: [13 Regression] ICE: tree check: expected integer_cst,
have poly_int_cst in get_len, at tree.h:6247
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: aarch64-linux-gnu

gcc 13.0.0 20220821 snapshot (g:d6a39c25c05c6ed5df8ce49eda719d17e40e29bb) ICEs
when compiling the following testcase w/ -mcpu=neoverse-512tvb -O2:

void
foo (int *p)
{
  int *a = p;
  int i;

  p[0] = 0;

  for (i = 0; i < 3; ++i)
{
  ++*a;
  ++a;
}

  p[1] = 0;
}

% aarch64-linux-gnu-gcc-13.0.0 -mcpu=neoverse-512tvb -O2 -c yhugtech.c
during GIMPLE pass: slp
yhugtech.c: In function 'foo':
yhugtech.c:2:1: internal compiler error: tree check: expected integer_cst, have
poly_int_cst in get_len, at tree.h:6247
2 | foo (int *p)
  | ^~~
0x7ff2be tree_check_failed(tree_node const*, char const*, int, char const*,
...)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/tree.cc:8817
0x1d34223 tree_check(tree_node const*, char const*, int, char const*,
tree_code)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/tree.h:3764
0x1d34223 wi::extended_tree<576>::get_len() const
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/tree.h:6247
0x1d34223 wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int >
const&)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/wide-int.h:985
0x1d34223 wide_int_ref_storage::wide_int_ref_storage >
>(generic_wide_int > const&, unsigned int)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/wide-int.h:1034
0x1d34223 generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/wide-int.h:790
0x1d34223 bool wi::eq_p >,
int>(generic_wide_int > const&, int const&)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/wide-int.h:1872
0x1d34223 bool wi::ne_p >,
int>(generic_wide_int > const&, int const&)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/wide-int.h:1910
0x1d34223 wi::binary_traits >, int,
wi::int_traits > >::precision_type,
wi::int_traits::precision_type>::predicate_result
operator!= >,
int>(generic_wide_int > const&, int const&)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/wide-int.h:3308
0x1d34223 if_nonpoly2 >, int, bool,
poly_int_traits > >::is_poly,
poly_int_traits::is_poly>::type
maybe_ne >,
int>(generic_wide_int > const&, int const&)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/poly-int.h:1313
0x1d34223 bool ranges_maybe_overlap_p
>, generic_wide_int >,
generic_wide_int >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&,
generic_wide_int > const&,
generic_wide_int > const&)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/poly-int.h:2635
0x1d34223 bool ranges_maybe_overlap_p
>, generic_wide_int >,
generic_wide_int >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&,
generic_wide_int > const&,
generic_wide_int > const&)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/poly-int.h:2629
0x1d27c8a dr_may_alias_p(data_reference const*, data_reference const*, loop*)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/tree-data-ref.cc:2980
0x1d300f9 initialize_data_dependence_relation(data_reference*, data_reference*,
vec)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/tree-data-ref.cc:3469
0x1d488f9 vect_slp_analyze_node_dependences
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/tree-vect-data-refs.cc:747
0x1d4af64 vect_slp_analyze_instance_dependence(vec_info*, _slp_instance*)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/tree-vect-data-refs.cc:855
0x12663fb vect_slp_analyze_bb_1
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/tree-vect-slp.cc:5902
0x12663fb vect_slp_region
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/tree-vect-slp.cc:5977
0x1267d84 vect_slp_bbs
   

[Bug other/91085] [10/11 only] fixincludes breaks

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.5
Summary|fixincludes breaks  |[10/11 only] fixincludes
   |  |breaks 
   Keywords||build
  Known to work||12.1.0

[Bug rtl-optimization/106707] [13 Regression] ICE: in cselib_record_set, at cselib.cc:2687 with -Oz -g -fno-cprop-registers -fno-dce since r13-1945-gfc6ef90173478521

[yinyuefengyi at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Xionghu Luo (luoxhu at gcc dot gnu.org)  ---
Maybe guard the pattern with...

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 58fcc382fa2..2a9d70da6d0 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -3045,6 +3045,7 @@ (define_peephole2
  "optimize_size > 1
   && (REGNO (operands[0]) == AX_REG
   || REGNO (operands[1]) == AX_REG)
+  && REGNO(operands[0]) != REGNO(operands[1])
   && optimize_insn_for_size_p ()
   && peep2_reg_dead_p (1, operands[1])"
   [(parallel [(set (match_dup 0) (match_dup 1))

[Bug testsuite/106516] New test case gcc.dg/pr104992.c fails on power 10

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

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #5 from Kewen Lin  ---
Created attachment 53492
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53492=edit
Adjust pr104992.c with vect_int_mod

> So it sounds like we want a generic target supports test that is true on
> targets (like power10) with a vector mod and key off that.  Any ideas how we
> can do that?

Add one effective target vect_int_mod for it, one quick grepping for i386 and
aarch64 shows they don't have such support.

[Bug tree-optimization/103035] [meta-bug] YARPGen bugs

[amacleod at redhat dot com via Gcc-bugs]

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

Bug 106687 Summary: [13 Regression] Wrong code with -O2 since 
r13-438-gcf2141a0c640fc9b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106687

   What|Removed |Added

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

[Bug tree-optimization/106687] [13 Regression] Wrong code with -O2 since r13-438-gcf2141a0c640fc9b

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Macleod  ---
fixed.

[Bug tree-optimization/106687] [13 Regression] Wrong code with -O2 since r13-438-gcf2141a0c640fc9b

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

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

commit r13-2147-gde6d9e0b3d5c08896cbf047b299fc7f8d1e42be7
Author: Andrew MacLeod 
Date:   Mon Aug 22 15:40:48 2022 -0400

Return the correct relation

With an input condition of op1 > op2, and evaluating the unsigned
expression:
LHS = op1 - op2
range-ops was returning LHS < op1 , which is incorrect as op2 coould be
zero.  This patch adjusts it to return LHS <= op1.

PR tree-optimization/106687
gcc/
* range-op.cc (operator_minus::lhs_op1_relation): Return VREL_LE
for the VREL_GT case as well.

gcc/testsuite/
* g++.dg/pr106687.C: New.

[Bug ipa/106716] Identical Code Folding (-fipa-icf) confuses between functions with different [[likely]] attributes

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

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

--- Comment #1 from Andrew Pinski  ---
I suspect fipa-icf does not compare the branch predication data while doing the
comparison. I don't know if this is the right thing to do or not. Because if
there was exact data from profiling feedback then it would not merge any
function ...

[Bug ipa/106716] New: Identical Code Folding (-fipa-icf) confuses between functions with different [[likely]] attributes

[tomerv at gmail dot com via Gcc-bugs]

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

Bug ID: 106716
   Summary: Identical Code Folding (-fipa-icf) confuses between
functions with different [[likely]] attributes
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tomerv at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I have 2 functions that are almost identical, except that they have different
attributes: one with [[likely]] and the other with [[unlikely]]:

bool is_prime_unlikely(int n)
{
for (int i = 2; i * i < n; ++i) {
if (n % i == 0) {
[[unlikely]]
return false;
}
}
return true;
}

bool is_prime_likely(int n)
{
for (int i = 2; i * i < n; ++i) {
if (n % i == 0) {
[[likely]]
return false;
}
}
return true;
}

Running g++ with -fipa-icf (which is default for -O2) causes them to merge into
a single function, as can be seen either with assembly output, or ipa dump:

g++ -c snippet.cpp -O1 -fipa-icf -S -fdump-ipa-all -masm=intel


snippet.s:

_Z15is_prime_likelyi:
.LFB3:
.cfi_startproc
endbr64
jmp _Z17is_prime_unlikelyi
.cfi_endproc


snippet.cpp.077i.icf:

bool is_prime_likely (int n)
{
  bool retval.2;

   [local count: 972273221]:
  retval.2_2 = is_prime_unlikely (n_1(D)); [tail call]
  return retval.2_2;

}


Can also be seen in Compiler Explorer: https://godbolt.org/z/jz11a3xx8

[Bug libstdc++/105678] Undefined reference to stacktrace standard library

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |12.3

[Bug libstdc++/106695] [11/12/13 Regression] Explicit copy constructor does not work for a parameter passed via std::async

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

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

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

https://gcc.gnu.org/g:5abe0657553580bd1b7488dd84d55138a8d9f23c

commit r13-2144-g5abe0657553580bd1b7488dd84d55138a8d9f23c
Author: Jonathan Wakely 
Date:   Mon Aug 22 15:42:17 2022 +0100

libstdc++: Fix for explicit copy ctors in  and  [PR106695]

When I changed std::thread and std::async to avoid unnecessary move
construction of temporaries, I introduced a regression where types with
an explicit copy constructor could not be passed to std::thread or
std::async. The fix is to add a constructor instead of using aggregate
initialization of an unnamed temporary.

libstdc++-v3/ChangeLog:

PR libstdc++/106695
* include/bits/std_thread.h (thread::_State_impl): Forward
individual arguments to _Invoker constructor.
(thread::_Invoker): Add constructor. Delete copies.
* include/std/future (__future_base::_Deferred_state): Forward
individual arguments to _Invoker constructor.
(__future_base::_Async_state_impl): Likewise.
* testsuite/30_threads/async/106695.cc: New test.
* testsuite/30_threads/thread/106695.cc: New test.

[Bug libstdc++/105678] Undefined reference to stacktrace standard library

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

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

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

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

commit r13-2145-gcc4fa7a210b638d6a46f14dab17f2361389d18e1
Author: Jonathan Wakely 
Date:   Mon Aug 22 17:24:27 2022 +0100

libstdc++: Document linker option for C++23  [PR105678]

libstdc++-v3/ChangeLog:

PR libstdc++/105678
* doc/xml/manual/using.xml: Document -lstdc++_libbacktrace
requirement for using std::stacktrace. Also adjust -frtti and
-fexceptions to document non-default (i.e. negative) forms.
* doc/html/*: Regenerate.

[Bug libstdc++/106607] Regex integer overflow on large backreference value

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

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

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

https://gcc.gnu.org/g:1b09eea33f2bf9d1eae73b25cc25efb05ea1dc3f

commit r13-2143-g1b09eea33f2bf9d1eae73b25cc25efb05ea1dc3f
Author: Jonathan Wakely 
Date:   Mon Aug 22 15:16:16 2022 +0100

libstdc++: Check for overflow in regex back-reference [PR106607]

Currently we fail to notice integer overflow when parsing a
back-reference expression, or when converting the parsed result from
long to int. This changes the result to be int, so no conversion is
needed, and uses the overflow-checking built-ins to detect an
out-of-range back-reference.

libstdc++-v3/ChangeLog:

PR libstdc++/106607
* include/bits/regex_compiler.tcc (_Compiler::_M_cur_int_value):
Use built-ins to check for integer overflow in back-reference
number.
* testsuite/28_regex/basic_regex/106607.cc: New test.

[Bug fortran/100948] [12/13 Regression] ICE in gfc_conv_expr_val, at fortran/trans-expr.c:9069

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

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to José Rui Faustino de Sousa from comment #6)
> Created attachment 51002 [details]
> Patch and changelog

I took a look at the attached patch.

While it does resolve the ICE on the original testcase, I get an ICE
with the testcase that is attached to the patch.

I also get a wrong result for the original testcase, so there is likely
more to do here (or some other patch missing here)...

[Bug target/106564] PRU: Inefficient zero-extend from 32-bit to 64-bit unsigned values

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

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

Dimitar Dimitrov  changed:

   What|Removed |Added

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

--- Comment #2 from Dimitar Dimitrov  ---
Fixed.

[Bug target/106564] PRU: Inefficient zero-extend from 32-bit to 64-bit unsigned values

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Dimitar Dimitrov :

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

commit r13-2140-g10dd6dea95c5fc41c789c6506338e101e0590a02
Author: Dimitar Dimitrov 
Date:   Sun Aug 14 18:50:18 2022 +0300

PR target/106564: pru: Optimize 64-bit sign- and zero-extend

Add new patterns to optimize 64-bit sign- and zero-extend operations for
the PRU target.

The new 64-bit zero-extend patterns are straightforward define_insns.

The old 16/32-bit sign-extend pattern has been rewritten from scratch
in order to add 64-bit support.  The new pattern expands into several
optimized insns for filling bytes with zeros or ones, and for
conditional branching on bit-test.  The bulk of this patch is to
implement the patterns for those new optimized insns.

PR target/106564

gcc/ChangeLog:

* config/pru/constraints.md (Um): New constraint for -1.
(Uf): New constraint for IOR fill-bytes constants.
(Uz): New constraint for AND zero-bytes constants.
* config/pru/predicates.md (const_fillbytes_operand): New
predicate for IOR fill-bytes constants.
(const_zerobytes_operand): New predicate for AND zero-bytes
constants.
* config/pru/pru-protos.h (pru_output_sign_extend): Remove.
(struct pru_byterange): New struct to describe a byte range.
(pru_calc_byterange): New declaration.
* config/pru/pru.cc (pru_rtx_costs): Add penalty for
64-bit zero-extend.
(pru_output_sign_extend): Remove.
(pru_calc_byterange): New helper function to extract byte
range info from a constant.
(pru_print_operand): Remove 'y' and 'z' print modifiers.
* config/pru/pru.md (zero_extendqidi2): New pattern.
(zero_extendhidi2): New pattern.
(zero_extendsidi2): New pattern.
(extend2): Rewrite as an expand.
(@pru_ior_fillbytes): New pattern.
(@pru_and_zerobytes): New pattern.
(di3): Rewrite as an expand and handle ZERO and FILL
special cases.
(pru_di3): New name for di3.
(@cbranch_qbbx_const_): New pattern to
handle bit-test for 64-bit registers.

gcc/testsuite/ChangeLog:

* gcc.target/pru/pr106564-1.c: New test.
* gcc.target/pru/pr106564-2.c: New test.
* gcc.target/pru/pr106564-3.c: New test.
* gcc.target/pru/pr106564-4.c: New test.

Signed-off-by: Dimitar Dimitrov 

[Bug testsuite/106516] New test case gcc.dg/pr104992.c fails on power 10

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

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

--- Comment #4 from Peter Bergner  ---
(In reply to Kewen Lin from comment #2)
> Confirmed, this is a test issue, power10 and up specific.
> 
> The difference comes from the function thud, it aims to test the pattern
> works for vector type. Power10 starts to support the insn vmodsw for vector
> integer mod.
[snip]
> We can adjust the test case to expect 6 times "%" on target power10_ok
> specially, but I wonder if we also find this fail on some other targets
> which supports vector mod, if so, one overall complete guard would be better.

So it sounds like we want a generic target supports test that is true on
targets (like power10) with a vector mod and key off that.  Any ideas how we
can do that?

[Bug fortran/106557] nesting intrinsics ibset and transfer gives wrong result

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Fixed for gcc-13.  Closing.

Thanks for the report!

[Bug fortran/106557] nesting intrinsics ibset and transfer gives wrong result

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r13-2139-g7e51df048ae849115e12bf12702bdf1b65893be7
Author: Harald Anlauf 
Date:   Sat Aug 20 20:36:28 2022 +0200

Fortran: fix simplification of intrinsics IBCLR and IBSET [PR106557]

gcc/fortran/ChangeLog:

PR fortran/106557
* simplify.cc (gfc_simplify_ibclr): Ensure consistent results of
the simplification by dropping a redundant memory representation
of argument x.
(gfc_simplify_ibset): Likewise.

gcc/testsuite/ChangeLog:

PR fortran/106557
* gfortran.dg/pr106557.f90: New test.

[Bug c++/106713] Coroutine regression in GCC 11.3.0: if (co_await ...) crashes with a jump to ud2

[arsen at aarsen dot me via Gcc-bugs]

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

--- Comment #2 from Arsen Arsenović  ---
Created attachment 53491
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53491=edit
Reduced test case

Alright, managed to get a reduced test case out of C-Vise. Though, this doesn't
build on clang (since the std:: namespace also got reduced; this can be
recovered by replacing the first one with  and the second one with
 and fixing a deduction failure that happens on it)

[Bug middle-end/106715] [OpenMP][5.2] Permit 'order' clause with 'for simd'/'do simd'

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

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

Tobias Burnus  changed:

   What|Removed |Added

Summary|[OpenMP][5.2] Permit|[OpenMP][5.2] Permit
   |'order' clause with 'for|'order' clause with 'for
   |simd'/'do simd' + improve   |simd'/'do simd'
   |error message   |
   Keywords|diagnostic  |

--- Comment #2 from Tobias Burnus  ---
(In reply to Jakub Jelinek from comment #1)
> It is not just internally, it is what the standard says.
> So, ordered is closely nested in simd, but not closely nested in
> worksharing-loop.

OK - let's strike that part. (I have to admit that I do not really understand
the fine print of "composite constructs" - contrary to combined constructs.)


Nonetheless, the following C/C++ issue remains for this PR:

#pragma omp for simd ordered(1)

is now in OpenMP 5.2 permitted, but currently reject.

[And likewise: 'doaccross' as synonym of 'depend' w/ sink/source.]

[Bug middle-end/106715] [OpenMP][5.2] Permit 'order' clause with 'for simd'/'do simd' + improve error message

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

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

--- Comment #1 from Jakub Jelinek  ---
It is not just internally, it is what the standard says.
So, ordered is closely nested in simd, but not closely nested in
worksharing-loop.

[Bug middle-end/106715] New: [OpenMP][5.2] Permit 'order' clause with 'for simd'/'do simd' + improve error message

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

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

Bug ID: 106715
   Summary: [OpenMP][5.2] Permit 'order' clause with 'for
simd'/'do simd' + improve error message
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: diagnostic, openmp, rejects-valid
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

In OpenMP 5.1's 2.11.5.2, there is the restriction for
worksharing-loop SIMD constructs:
"* No ordered clause with a parameter can be specified."


This is gone with OpenMP 5.2. However, 5.2 does have the following restriction
(from 17.1 Nesting of Regions):

"An ordered region that corresponds to an ordered construct without the simd
clause specified must be closely nested inside a worksharing-loop region."


So, this is now allowed:

integer :: i, n, a(0:5)
n = 5
!$omp do ordered(1)
do i=1,n
   a(i) = a(i) + 1
end do
end

and this would also be allowed:

integer :: i, n, a(0:5)
n = 5
!$omp do simd ordered(1)
do i=1,n
   a(i) = a(i) + 1
end do
end
-

Remark: Both Fortran snippets are already accepted; as is the C/C++ version of
the first example. However, the C/C++ version of the second is rejected by GCC:

foo44.c:4:31: error: ‘ordered’ clause with parameter may not be specified on
‘#pragma omp for simd’ construct
4 |   #pragma omp for simd ordered(1)


void foo()
{
  int i, n = 5, a[5];
  #pragma omp for simd ordered(1)
  for(i=0; i < n; i++)
a[i] += 1;
}



However, this would not be allowed:

integer :: i, n, a(0:5)
n = 5
!$omp do simd ordered(1)
do i=1,n
   !$omp ordered depend(sink:i-1)  ! 'depend' -> 'doaccross' in 5.2
   a(i) = a(i) + a(i-1)
   !$omp ordered depend(source)  ! 'depend' -> 'doaccross' in 5.2
end do
end


Remark: GCC outputs the following:
  Error: ‘ordered’ construct with ‘depend’ clause must be closely nested inside
a
  loop with ‘ordered’ clause with a parameter

Printing an error is fine. However, I think this message is a bit misleading as
'ordered' construct is closely nested in a loop - and that loop has an
'ordered' clause with a parameter. It is just that the "for simd" is internally
a "for" + "simd" and the 'ordered' is only only the outer 'for' bit.


Likewise for the C/C++ version of the latter (same error diagnostic):

void foo()
{
  int i, n = 5, a[5];
  #pragma omp for ordered(1)
  for(i=0; i < n; i++)
{
  #pragma omp ordered depend(sink:i-1)
  a[i] += 1;
  #pragma omp ordered depend(source)
}
}

[Bug target/106714] New: Incorrect casts macros in amxtileintrin.h

[hjl.tools at gmail dot com via Gcc-bugs]

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

Bug ID: 106714
   Summary: Incorrect casts macros in amxtileintrin.h
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com
  Target Milestone: ---
Target: x86-64

macros amxtileintrin.h cast to long for stride in memory operand. But on 64-bit
Windows, long is 32 bits and pointer is 64 bits. __PTRDIFF_TYPE__ should be
used
instead of long.

[Bug middle-end/106662] [OpenMP] 'for simd firstprivate(j) lastprivate(j)' with 'parallel shared(j)' gives unexpected result

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

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

--- Comment #1 from Tobias Burnus  ---
"Likewise with a combined construct:" – Strike that I think that's not quite
right.

Seems that one expert on omp-lang believes that for this "worksharing-simd
construct and firstprivate" example in comment 0, the proper result is "22"
also with "for simd".

[Bug target/103370] [12/13 Regression] Assembler error building glibc for ColdFire soft-float

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

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

--- Comment #8 from Joseph S. Myers  ---
This build failure has come back on GCC mainline, some time between commit
3cab897a67af120aa18efa7ddd7ee49b9a29e5dd and
7f5ec900e53f6c7f7c06c641b4fb303ebdc83785.

[Bug c++/106712] Incorrect propagation of C++11 attributes to subsequent function declarations

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-08-22
 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Thanks for the report.  I plan to take a look.  Probably not a regression.

[Bug tree-optimization/106709] [12/13 Regression] GCC incorrectly warns about stringop-overread

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.3

[Bug tree-optimization/106709] [12/13 Regression] GCC incorrectly warns about stringop-overread

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|GCC incorrectly warns about |[12/13 Regression] GCC
   |stringop-overread   |incorrectly warns about
   ||stringop-overread
   Last reconfirmed||2022-08-22

--- Comment #1 from Andrew Pinski  ---
We don't optimize away the call to mwe3 until fre3 (I don't know when the
diagnostic is in the optimization pipeline though).

[Bug c++/106713] Coroutine regression in GCC 11.3.0: if (co_await ...) crashes with a jump to ud2

[arsen at aarsen dot me via Gcc-bugs]

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

--- Comment #1 from Arsen Arsenović  ---
Created attachment 53490
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53490=edit
Preprocessed test (gz-compressed)

[Bug c++/106599] Wrong copy elision in delegating to copy-constructor

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

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

--- Comment #5 from Jonathan Wakely  ---
This delegating constructor example seems like a third case of
https://wg21.link/cwg2403

[Bug c++/106713] New: Coroutine regression in GCC 11.3.0: if (co_await ...) crashes with a jump to ud2

[arsen at aarsen dot me via Gcc-bugs]

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

Bug ID: 106713
   Summary: Coroutine regression in GCC 11.3.0: if (co_await ...)
crashes with a jump to ud2
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arsen at aarsen dot me
  Target Milestone: ---

I can reproduce the jump to ud2 on 11.3.0, GCC 12.2.0, as well as
g:b6316324fceaef431799a8b386de5cc9881d6898 but not 11.2.0, on x86_64 Gentoo
Linux with glibc 2.35.

GCC command line: g++ -v -save-temps -fsanitize=undefined -Wall -Wextra
-std=c++20 -I. -o bad bad-test.ii
(though, this is also reproducible with just g++ -std=c++20 -o bad bad-test.ii)

Compiler output:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/11.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-11.3.0/work/gcc-11.3.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/11.3.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.3.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.3.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.3.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/g++-v11
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/11.3.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 11.3.0 p5'
--disable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-libgomp --disable-libssp --disable-libada
--disable-cet --disable-systemtap --disable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --without-zstd --enable-lto
--without-isl --enable-default-pie --enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.3.0 (Gentoo 11.3.0 p5) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fsanitize=undefined' '-Wall' '-Wextra'
'-std=c++20' '-I' '.' '-o' 'bad' '-shared-libgcc' '-mtune=generic'
'-march=x86-64' '-dumpdir' 'bad-'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/11.3.0/cc1plus -fpreprocessed bad-test.ii
-quiet -dumpdir bad- -dumpbase bad-test.ii -dumpbase-ext .ii -mtune=generic
-march=x86-64 -Wall -Wextra -std=c++20 -version -fsanitize=undefined -o
bad-bad-test.s
GNU C++20 (Gentoo 11.3.0 p5) version 11.3.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 11.3.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++20 (Gentoo 11.3.0 p5) version 11.3.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 11.3.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e1914a2c1e0f5aa3fac1881c1e8f375c
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fsanitize=undefined' '-Wall' '-Wextra'
'-std=c++20' '-I' '.' '-o' 'bad' '-shared-libgcc' '-mtune=generic'
'-march=x86-64' '-dumpdir' 'bad-'
 /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/bin/as
-v -I . --64 -o bad-bad-test.o bad-bad-test.s
GNU assembler version 2.38 (x86_64-pc-linux-gnu) using BFD version (Gentoo 2.38
p4) 2.38
COMPILER_PATH=/usr/libexec/gcc/x86_64-pc-linux-gnu/11.3.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/11.3.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fsanitize=undefined' '-Wall' '-Wextra'
'-std=c++20' '-I' '.' '-o' 'bad' '-shared-libgcc' '-mtune=generic'
'-march=x86-64' '-dumpdir' 'bad.'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/11.3.0/collect2 -plugin
/usr/libexec/gcc/x86_64-pc-linux-gnu/11.3.0/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/x86_64-pc-linux-gnu/11.3.0/lto-wrapper
-plugin-opt=-fresolution=bad.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc

[Bug c++/106599] Wrong copy elision in delegating to copy-constructor

[fchelnokov at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Fedor Chelnokov  ---
And if one deletes copy constructor of A:

struct A {   
constexpr A() = default;
constexpr A(const A&) = delete;
constexpr A(int) : A(A()) {}
};

A a(2);

Then Clang rejects the program, but GCC accepts it (ignoring that selected
constructor is deleted), online demo: https://gcc.godbolt.org/z/s8Kjx6qPW

Is it ok?

[Bug tree-optimization/106711] Incorrect format overflow warning with previously checked strings

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed. I suspect what is happening is that GCC finds the strlen for each
string seperately and sees its max is 4094 (because add) and does not take into
account the strings are done together.


  _1 = strlen (in1_8(D));
  _2 = strlen (in2_9(D));
  _3 = _1 + _2;
  _4 = _3 + 2;
  if (_4 <= 4096)
goto ; [38.32%]
  else
goto ; [61.68%]

   [local count: 411457864]:
  sprintf (outbuf_10(D), "%s/%s", in1_8(D), in2_9(D));

[Bug libstdc++/103629] [11/12/13 Regression] Possible miscompilation visible using pthread + exception

[malat at debian dot org via Gcc-bugs]

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

Mathieu Malaterre  changed:

   What|Removed |Added

  Known to fail||12.1.0

--- Comment #21 from Mathieu Malaterre  ---
Any chance this issue could be fixed on 12.x branch (11.x is ?

[Bug target/106101] [12/13 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b

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

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

--- Comment #17 from Segher Boessenkool  ---
(In reply to Andreas Krebbel from comment #16)
> (In reply to Segher Boessenkool from comment #15)
> > (In reply to Andreas Krebbel from comment #14)
> > > > So you are suggesting that every strict_low_part after reload can just 
> > > > be
> > > > removed?  If that is true, should we not just do exactly that then?
> > > 
> > > I think we have 3 options:
> > > (1) Prevent reload from removing SUBREGs in STRICT_LOW_PARTs.
> > > (2) Remove the STRICT_LOW_PART when resolving the inner SUBREG
> > > (3) Define what a (STRICT_LOW_PART (reg:mode x)) means. 
> ...
> > > (3) E.g. it means that the bits of hardreg x in its hardware mode (the 
> > > mode
> > > for UNITS_PER_WORD) which are not covered by MODE are not touched by the 
> > > SET.
> > 
> > But say you have (strict_low_part (subreg:HI (reg:SI) 0)) and the hardware
> > is 64-bit.  That only means the low 32 bits of the reg aren't clobbered, the
> > high 32 bits are fair game.  That does not agree with your proposed
> > semantics.
> 
> In that case I would have expected reload to turn this into 
> (strict_low_part (reg:HI xx))
> already.

Yes, but that says the high 48 bits of the hardware reg are untouched, which
is not true (only the high 16 of the low 32 are guaranteed unmodified).

[Bug target/106101] [12/13 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b

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

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

--- Comment #16 from Andreas Krebbel  ---
(In reply to Segher Boessenkool from comment #15)
> (In reply to Andreas Krebbel from comment #14)
> > > So you are suggesting that every strict_low_part after reload can just be
> > > removed?  If that is true, should we not just do exactly that then?
> > 
> > I think we have 3 options:
> > (1) Prevent reload from removing SUBREGs in STRICT_LOW_PARTs.
> > (2) Remove the STRICT_LOW_PART when resolving the inner SUBREG
> > (3) Define what a (STRICT_LOW_PART (reg:mode x)) means. 
...
> > (3) E.g. it means that the bits of hardreg x in its hardware mode (the mode
> > for UNITS_PER_WORD) which are not covered by MODE are not touched by the 
> > SET.
> 
> But say you have (strict_low_part (subreg:HI (reg:SI) 0)) and the hardware
> is 64-bit.  That only means the low 32 bits of the reg aren't clobbered, the
> high 32 bits are fair game.  That does not agree with your proposed
> semantics.

In that case I would have expected reload to turn this into 
(strict_low_part (reg:HI xx))
already.

[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop

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

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #26 from Segher Boessenkool  ---
(In reply to Paweł Bylica from comment #25)
> Is this issue resolved then?

If we don't want backports it is done yes.  Originally I wanted backports, but
given we needed fixup patches etc., this was a bit dangerous.  And now it is
two years ago.

Closing.  Thanks!

[Bug target/99555] [OpenMP/nvptx] Execution-time hang for simple nested OpenMP 'target'/'parallel'/'task' constructs

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

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

--- Comment #16 from Jakub Jelinek  ---
(In reply to Tobias Burnus from comment #15)
> Besides the post-commit comment by Thomas (last comment before mine; comment
> 14),
> there is another issue:
> The commit causes for SPEC HPC2021's 521.miniswp_t (OpenMP) 400% slowdown.

Does it perhaps call omp_get_team_num () too often and is shared var access
slow?
Previously that function was returning an internal register, now it reads a
shared variable because we can't artificially lower number of teams to what the
hw actually provides, so need to be able to iterate if user asks for more teams
than supported by hw.
Perhaps we should make omp_get_team_num const after omp-expand (like we I think
do for omp_get_thread_num?) to avoid some calls?  Or try to make it cheaper
somehow?

[Bug target/106101] [12/13 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b

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

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

--- Comment #15 from Segher Boessenkool  ---
(In reply to Andreas Krebbel from comment #14)
> > So you are suggesting that every strict_low_part after reload can just be
> > removed?  If that is true, should we not just do exactly that then?
> 
> I think we have 3 options:
> (1) Prevent reload from removing SUBREGs in STRICT_LOW_PARTs.
> (2) Remove the STRICT_LOW_PART when resolving the inner SUBREG
> (3) Define what a (STRICT_LOW_PART (reg:mode x)) means. 
> 
> (1) For that, all passes after reload must be able to deal with these
> SUBREGs. Since SUBREGs are rare after reload it is hard to say how robust
> that handling is right now.

On some targets you always have subregs to describe the action of certain
machine instructions (like mulh one PowerPC).

In the past there were subregs of mem as well.  Those shouldn't occur anymore,
but most (all?) late passes still know how to handle it.


> (2) Here the question to me is which passes after reload currently do
> something with the strict-low-part info. Clearly a non-option if we would
> loose any optimizations with that.

Yes.  This potentially even changes semantics, unless we are sure nothing uses
the "high part" at all.


> (3) E.g. it means that the bits of hardreg x in its hardware mode (the mode
> for UNITS_PER_WORD) which are not covered by MODE are not touched by the SET.

But say you have (strict_low_part (subreg:HI (reg:SI) 0)) and the hardware
is 64-bit.  That only means the low 32 bits of the reg aren't clobbered, the
high 32 bits are fair game.  That does not agree with your proposed semantics.

[Bug target/99555] [OpenMP/nvptx] Execution-time hang for simple nested OpenMP 'target'/'parallel'/'task' constructs

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

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

--- Comment #15 from Tobias Burnus  ---
Besides the post-commit comment by Thomas (last comment before mine; comment
14),
there is another issue:
The commit causes for SPEC HPC2021's 521.miniswp_t (OpenMP) 400% slowdown.

The question is whether we can get it more lightweight - at least in some
cases/sm_*/hardware combination?

[Bug c++/106712] Incorrect propagation of C++11 attributes to subsequent function declarations

[ed at catmur dot uk via Gcc-bugs]

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

--- Comment #1 from Ed Catmur  ---
I believe this is happening because start_decl can modify prefix_attributes (by
first chaining it onto attributes, then passing the merged chain to
grokdeclarator  which can then chain onto that merged chain).  If the attribute
list is empty, prefix_attributes is NULL_TREE and so is not affected.

If so, the simplest fix would be for start_decl to copy_list(prefix_attributes)
prior to chaining it.

[Bug c++/106712] New: Incorrect propagation of C++11 attributes to subsequent function declarations

[ed at catmur dot uk via Gcc-bugs]

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

Bug ID: 106712
   Summary: Incorrect propagation of C++11 attributes to
subsequent function declarations
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ed at catmur dot uk
  Target Milestone: ---

In [[first-attribute]] int f [[second-attribute]](), g();

the [[first-attribute]] should apply to both f and g, the [[second-attribute]]
to f only:

> The attribute-specifier-seq appertains to each of the entities declared by 
> the declarators of the init-declarator-list.
http://eel.is/c++draft/dcl.dcl#dcl.pre-3.sentence-5

> The attribute-specifier-seq affects the type only for the declaration it 
> appears in, not other declarations involving the same type.
http://eel.is/c++draft/dcl.dcl#dcl.spec.general-1.sentence-3

However, gcc instead applies [[second-attribute]] to both functions, but only
if [[first-attribute]] is non-empty.

This can lead to rejects-valid:

[[gnu::cold]] int g() { return 1; }
[[gnu::cold]] int f [[gnu::fastcall]](), g(); // error: ambiguating new
declaration of 'int g()'

Or to miscompilation, e.g.:

[[gnu::cold]] int f [[gnu::const]](), g();
int g() {
static int i;
return ++i;
}
#include 
int main() { assert(g() + g() == 3); } // fails

Or erroneous warnings (with only standard attributes):

[[noreturn]] int f [[nodiscard]](), g();
int main() { g(); }

[Bug lto/106700] [13 Regression] O_NONBLOCK does not exist for x86_64-w64-mingw32 host

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Should be fixed now.

[Bug lto/106700] [13 Regression] O_NONBLOCK does not exist for x86_64-w64-mingw32 host

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:827f64135957ce21617cd0345508077439fa29d8

commit r13-2137-g827f64135957ce21617cd0345508077439fa29d8
Author: Martin Liska 
Date:   Thu Aug 18 13:03:42 2022 +0200

jobserver: detect properly O_NONBLOCK

PR lto/106700

gcc/ChangeLog:

* configure.ac: Detect O_NONBLOCK flag for open.
* config.in: Regenerate.
* configure: Regenerate.
* opts-common.cc (jobserver_info::connect): Set is_connected
  properly based on O_NONBLOCK.
* opts-jobserver.h (struct jobserver_info): Add is_connected
  member variable.

gcc/lto/ChangeLog:

* lto.cc (wait_for_child): Ask if we are connected to jobserver.
(stream_out_partitions): Likewise.

[Bug libstdc++/106607] Regex integer overflow on large backreference value

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2022-08-22
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

[Bug c++/106599] Wrong copy elision in delegating to copy-constructor

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Fedor Chelnokov from comment #0)
> So we need to consider the constructors, and select A(const A&) : v(1)

We do select that, but then for C++17 (and later) the copy is elided, which is
permitted as far as I can see. With -std=c++14 the static assert passes.

[Bug c/106711] New: Incorrect format overflow warning with previously checked strings

[ljrk at ljrk dot org via Gcc-bugs]

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

Bug ID: 106711
   Summary: Incorrect format overflow warning with previously
checked strings
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ljrk at ljrk dot org
  Target Milestone: ---

GCC complains about the following code snippet:

#include 
#include 
#include 

char *mwe(char outbuf[PATH_MAX], char *in1, char *in2)
{
if (strlen(in1) + 2 + strlen(in2) <= PATH_MAX) {
(void)sprintf(outbuf, "%s/%s", in1, in2);
return (outbuf);
}
return (NULL);
}


with:

$ gcc -O2 -Wall -c -o mwe.o mwe.c
mwe.c: In function ‘mwe’:
mwe.c:9:43: warning: ‘%s’ directive writing up to 4094 bytes into a
region of size between 1 and 4095 [-Wformat-overflow=]
9 | (void)sprintf(outbuf, "%s/%s", in1, in2);
  |   ^~
mwe.c:9:23: note: ‘sprintf’ output between 2 and 8190 bytes into a
destination of size 4096
9 | (void)sprintf(outbuf, "%s/%s", in1, in2);
  |   ^~


Ideally, GCC could record the condition in the if-statement and compare it to
the formula implictly given for the length with sprintf as
`strlen(in1)+1+strlen(in2)+1` to check whether this condition is already
checked for.

I couldn't find an existing bug tracking this but maybe I've just looked at the
wrong place?

[Bug middle-end/101674] gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite

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

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

--- Comment #9 from Richard Biener  ---
uninit analysis has the guarding condition r_14(D) <= 18 but the guard of
the PHI is computed in non-optimal way since this is a PHI use of a PHI
with an uninitialized val on an edge but the paths we construct in
predicate::use_cannot_happen only consider the second PHI uninit edge.

bb 12:
# v_31 = PHI 
...

bb 14:
# v_32 = PHI 
..

 = blah (v_32);

when we visit v_31 we determine an uninit use in v_32 on the 23->14 edge
and queue that PHI for analysis where we then find the blah (v_32) use.
But this queueing forgets that the paths that guard this uninit use
PHI def need all go through 12 -> 11.

The code in tree-ssa-uninit.cc does this, so the gimple-predicate-analysis.cc
code doesn't know anything about this.  That's a weakness in the API,
predicate::is_use_guarded (the API is somewhat awkward generally).

It might be we want the path from BB 12 through BB 14 to the use in the
'use_preds' or like suggested above in the def preds instead.  When
the put it into the 'use_preds' we get r_14(D) <= 18 && _7 != 0 && l_18(D) >
100
where we fail to open-code _7 (defined as _1 & _6).  At least we then
get the proper PHI def chain into the uninit use edge so such change alone
would be a correctness improvement here.

Now, we do pick up the definition of _1 & _6 but only after normalization
which we apply to the predicate of the PHI def but not to the predicate
of the use until after the use_cannot_happen test is complete.

But one issue is that normalization does nothing to !((_1 & _2) != 0)
which would be !(_1 != 0) | !(_2 != _0) but we don't do anything to that
in the chain normalization case (we'd need to duplicate here).  The
single pred case would also not do this because of the is_neq_zero_form_p
guard.

Not to say that the use_preds.use_cannot_happen case looks awfully similar
to the superset_of.  The main difference seems to be that init_from_phi_def
picks up a PHI def predicate starting only from the immediate dominator
while use_cannot_happen tries to build "fancy" predicates starting from
function entry.  And some use m_eval to compute 'opnds' while others
use the mask passed in to is_use_guarded.

The code is somewhat of a mess here.  It's all mightly complicated but
limited at the same time :/

[Bug c/106710] New: Ability to disable -Wfree-nonheap-object for specific free() implementations

[ljrk at ljrk dot org via Gcc-bugs]

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

Bug ID: 106710
   Summary: Ability to disable -Wfree-nonheap-object for specific
free() implementations
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ljrk at ljrk dot org
  Target Milestone: ---

If a library or a system is free-standing, they may have their own free()
implementation that allows not only passing a pointer to the start of the
block-to-be-freed but also to a pointer within.

Currently, GCC warns when it detects a function called `free` which is passed
memory with a nonzero offset from a head object, even if this function is not
the (g)libc's.  Perhaps a similar annotation like for `printf` could be
introduced to annotate functions as memory-handling with selective on/off
switches whether they allow for such behavior or not?

[Bug c/106709] New: GCC incorrectly warns about stringop-overread

[ljrk at ljrk dot org via Gcc-bugs]

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

Bug ID: 106709
   Summary: GCC incorrectly warns about stringop-overread
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ljrk at ljrk dot org
  Target Milestone: ---

Created attachment 53489
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53489=edit
Minimal Working/Reproducing Example

GCC incorrectly warns with default flags and optimization level -O2 about a
number of buffer overruns, in this example from `libmdigest` as part of the
schilytools in a call to `SHA1Update` at
https://codeberg.org/schilytools/schilytools/src/branch/master/libmdigest/sha1.c#L251:


==> COMPILING "OBJ/x86_64-linux-gcc/sha1.o"
In function 'SHA1Update',
inlined from 'SHA1Pad' at sha1.c:251:2:
sha1.c:228:25: warning: 'SHA1Transform' reading 64 bytes from a region
of size 1 [-Wstringop-overread]
  228 | SHA1Transform(context->state, (UInt8_t
*)[i]);
  |
^~
sha1.c:228:25: note: referencing argument 2 of type 'const uint8_t[64]'
{aka 'const unsigned char[64]'}




In this example we have the following code snippet in `SHA1Pad`:


SHA1Update(context, /* data: */ (UInt8_t *)"\200", /* len: */
1);



with the inlined update function being: 


j = (size_t)((context->count[0] >> 3) & 63);
/* ... */
if ((j + len) > 63) {
/* ... */ i = 64-j /*...*/;
SHA1Transform(context->state, context->buffer);
for (; i + 63 < len; i += 64)
SHA1Transform(context->state, (UInt8_t
*)[i]);
j = 0;
} else /* ... */



Depending on the value of `count[0]`, both `j` may be up to 63 (if `count[0]`
is 0x3f00 or more).  Only in this case, with `len = 1` from `SHA1Update`, we
would enter this code block and correctly copy `i = 64-63 = 1` bytes from the 1
byte data buffer.  The loop would start with `i+63 = 1+63 < len = 1` and thus
not call `SHA1Transform` in any case.

Setting `j = 63` directly silences the warning, so it seems like GCC can't keep
track of `j <= 63`.

I've attached a minimized mwe.c as well:

$ gcc -c -O2 -o mwe.o mwe.c
In function ‘mwe2’,
inlined from ‘mwe’ at mwe.c:17:2:
mwe.c:11:25: warning: ‘mwe3’ reading 64 bytes from a region of size 1
[-Wstringop-overread]
   11 | mwe3((unsigned char*)[i]);
  | ^~
mwe.c:11:25: note: referencing argument 1 of type ‘const unsigned
char[64]’
mwe.c: In function ‘mwe’:
mwe.c:3:13: note: in a call to function ‘mwe3’
3 | extern void mwe3(const unsigned char buffer[64]);
  | ^~~~
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (GCC) 


It seems like this bug is related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105424 but I'm not sure.  If so,
feel free to close it.

Thanks for maintaining this great piece of software!

[Bug demangler/106622] Bug report

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

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

--- Comment #2 from Jonathan Wakely  ---
Also please check whether this is a duplicate of Bug 104435, Bug 105115, Bug
106224, or Bug 106641.

[Bug demangler/105115] `demangle_const` causes infinite recursion and stack overflow

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

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

--- Comment #3 from Jonathan Wakely  ---
Maybe a dup of PR 104435

[Bug demangler/106622] Bug report

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

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

--- Comment #1 from Jonathan Wakely  ---
Please provide a more useful title than "Bug report". Everything in bugzilla is
a bug report.

[Bug c++/106631] Unhelpful diagnostic on variable template specialization with unknown name

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c++/106629] GCC accepts invalid program involving {1,2,3,4} as template argument

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #4)
> Even though cppreference is not part of the C++ standard. It would be useful
> to put a reference to that defect report on
> https://en.cppreference.com/w/cpp/language/template_parameters .

The issue is still open, I don't think cppreference documents issues that
aren't resolved and applied to the draft yet.

[Bug libstdc++/106695] [11/12/13 Regression] Explicit copy constructor does not work for a parameter passed via std::async

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/106695] [11/12/13 Regression] Explicit copy constructor does not work for a parameter passed via std::async

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

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

--- Comment #2 from Jonathan Wakely  ---
Probably r11-2736-gbb1b7f087bdd02

[Bug c++/106614] GCC skips using copy constructor when creating object using direct initialization in A a({A{}});

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Dup

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

[Bug c++/106599] Wrong copy elision in delegating to copy-constructor

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jlame646 at gmail dot com

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

[Bug libstdc++/78717] no definition of string::find when lowered to gimple

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

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

--- Comment #4 from Jonathan Wakely  ---
This is because the std::basic_string::find function isn't marked 'inline' and
there is an explicit instantiation declaration for std::string. GCC simply
won't inline a non-inline function if there's an explicit instantiation of it.

With GCC 12 and -std=c++20 all members of std::basic_string are 'constexpr' and
so implicitly 'inline', and it gets inlined.

[Bug c++/82113] RVO isn't applied to base class constructor call in C++17

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

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

--- Comment #2 from Jonathan Wakely  ---
c.f. https://wg21.link/cwg2403

[Bug c++/90413] Bad diagnostic when trying to copy an uncopyable type

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Same bug as your recent PR 106176?

[Bug c++/106176] Compiler diagnostic doesn't show where it's coming from in my code

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
I think this is fundamentally the same issue as PR 80858.

[Bug c++/106176] Compiler diagnostic doesn't show where it's coming from in my code

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||accelerator0099 at gmail dot 
com

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

[Bug c++/106584] g++ not showing correct line number in "use of deleted function" error

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Maybe a closer dup of PR 106176 (but I think that's a dup of PR 80858).

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

[Bug gcov-profile/106659] [13 Regression] error: no member named 'fancy_abort' in namespace 'std'; did you mean simply 'fancy_abort'

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Martin Liška  ---
Fixed.

[Bug c++/80858] When trying to copy std::unordered_map illegally, error message doesn't tell what's wrong

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||accelerator0099 at gmail dot 
com

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

[Bug c++/106584] g++ not showing correct line number in "use of deleted function" error

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
I think this is another dup of PR 80858. When the copy constructor is implicit
defined there is no line number, and the diagnostic is unhelpful.

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

[Bug c++/106696] Fallthrough between functions without proper return statement when optimizing

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #3)
> Because of the C++ vs. C differences, -Wreturn-type warning is on by default
> in C++ while it is only included in -Wall for C, users just shouldn't ignore
> this warning unless it is really impossible to reach it at runtime.

If you find it too easy to ignore those warnings, use -Werror=return-type to
prevent such bugs from compiling. That can't be the default though, because
it's possible to get false positives, or warnings for branches that GCC thinks
are reachable (and so the warning is correct) but which are never actually
reached at runtime given the possible function inputs. For the cases where the
diagnostic can safely be ignored, you can explicitly annotate the code with
__builtin_unreachable() or std::abort() or similar.

[Bug target/106101] [12/13 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b

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

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

--- Comment #14 from Andreas Krebbel  ---
(In reply to Segher Boessenkool from comment #13)
> (Sorry I missed this)
> 
> (In reply to Andreas Krebbel from comment #11)
> > I've tried to change our movstrict backend patterns to use a predicate on
> > the dest operand which enforces a subreg. However, since reload strips the
> > subreg away when assigning hard regs we end up with a STRICT_LOW_PART of a
> > reg again. At least after reload something like this should be acceptable -
> > right?
> > 
> > 298r.ira:
> > (insn 8 16 17 3 (set (strict_low_part (subreg:SI (reg/v:DI 64 [ e ]) 4))
> > (const_int 0 [0])) "t.cc":37:17 1485 {movstrictsi}
> >  (nil))
> > 
> > 299r.reload:
> > (insn 8 16 17 3 (set (strict_low_part (reg:SI 11 %r11 [orig:64 e+4 ] [64]))
> > (mem/u/c:SI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0  S4 A32]))
> > "t.cc":37:17 1485 {movstrictsi}
> >  (nil))
> 
> So you are suggesting that every strict_low_part after reload can just be
> removed?  If that is true, should we not just do exactly that then?

I think we have 3 options:
(1) Prevent reload from removing SUBREGs in STRICT_LOW_PARTs.
(2) Remove the STRICT_LOW_PART when resolving the inner SUBREG
(3) Define what a (STRICT_LOW_PART (reg:mode x)) means. 

(1) For that, all passes after reload must be able to deal with these SUBREGs.
Since SUBREGs are rare after reload it is hard to say how robust that handling
is right now.

(2) Here the question to me is which passes after reload currently do something
with the strict-low-part info. Clearly a non-option if we would loose any
optimizations with that.

(3) E.g. it means that the bits of hardreg x in its hardware mode (the mode for
UNITS_PER_WORD) which are not covered by MODE are not touched by the SET.

[Bug libstdc++/105562] [12 Regression] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

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

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

--- Comment #19 from Jonathan Wakely  ---
I suppose the libstdc++ header could do something like:

#pragma GCC diagnostic push
#if defined __SANITIZE_ADDRESS__ && defined __OPTIMIZE__
#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
#endif
...
#pragma GCC diagnostic pop

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

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

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

--- Comment #14 from Jonathan Wakely  ---
Running out of stack space is not acceptable, that's why this is considered a
bug. As already stated in comment 8, I started work on fixing it, but the
rewritten code had bugs that I haven't had time to resolve yet.

[Bug c/106672] support Apple's old __private_extern__ keyword

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

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

--- Comment #1 from Jonathan Wakely  ---
The macro seems appropriate for old code relying on a deprecated feature. I
don't think GCC should support this.

[Bug c++/106423] -Wc++20-compat diagnostics not suppressed by #pragma GCC diagnostic ignored

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed, thanks.

[Bug c++/106572] A programmatic list of all possible compiler warnings

[j.badwaik--- via Gcc-bugs]

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

--- Comment #8 from Jayesh Badwaik  ---
> Oh and you don't need the tr either that is any whitespace in a response
> file is will be treated as a seperator.
> So just:
> g++ -Q --help=warnings | tail -n +2 | awk '{print $1}' > cxxflags.opt

Okay, so, now that we do have a use case for it,what criteria does this use
case have to satisfy for it to be an actual option like
"-WIreallywanteverything"?

[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop

[chfast at gmail dot com via Gcc-bugs]

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

Paweł Bylica  changed:

   What|Removed |Added

 CC||chfast at gmail dot com

--- Comment #25 from Paweł Bylica  ---
Is this issue resolved then?

[Bug c++/106572] A programmatic list of all possible compiler warnings

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug preprocessor/106426] UTF-8 character literals do not have unsigned type in the preprocessor in -fchar8_t mode

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Done. Thanks, Tom.

[Bug c++/106646] [C++23] P2437R1 - Support for #warning

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-22
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

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

Untested implementation.

[Bug lto/106328] Build doesn't respect -j N flag

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

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

--- Comment #11 from Martin Liška  ---
> Ah, indeed.  That still leaves the question whether we execute the
> WPA stage with the FDs open - I suppose you checked?

Yes, I can confirm it correctly works on Linux with FDs provided by jobserver.

> And whether
> pex_* "properly" does this for all host OSs (how does make jobserver
> work on mingw/cygwin?).

Based on the testing of Tamar, it also uses --jobserver-auth=3,4 on MinGW.

> I wonder because Honza once said he didn't
> implement jobserver support because it would require more fiddling
> to get it actually work.

I asked him and he didn't remember any details.

> 
> And IIRC BSD 'make' is not GNU make but I think gmake is available
> from the ports repo.  The documentation about -flto=jobserver mentions
> that already.

[Bug target/106708] New: [rs6000] 64bit constant generation with oris xoris

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

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

Bug ID: 106708
   Summary: [rs6000] 64bit constant generation with oris xoris
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guojiufu at gcc dot gnu.org
  Target Milestone: ---

For code: t.c
void foo (long *arg)
{
  *arg++ = 0x98765432ULL;
  *arg++ = 0x7cdeab55ULL;
  *arg++ = 0x6543ULL;
}

gcc -O2 -S t.c
lis 10,0x
lis 8,0x9876
ori 10,10,0x7cde
lis 9,0x
ori 8,8,0x5432
sldi 10,10,16
ori 9,9,0x6543
rldicl 8,8,0,32
ori 10,10,0xab55
sldi 9,9,16

Below sequences would be better:
li 8,21554
li 10,-21675
lis 9,0xe543
oris 8,8,0x9876
xoris 10,10,0x8321
xoris 9,9,0x8000

[Bug c++/98940] Implement C++23 language features

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

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

Bug 106645 Summary: [C++23] P2290R3 - Delimited escape sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106645

   What|Removed |Added

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

[Bug c++/106645] [C++23] P2290R3 - Delimited escape sequences

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Implemented for 13+.

[Bug lto/106686] [lto][offloading] lto-wrapper leaves "target.o" temporay files behind when error diagnostic occurred

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #3 from Tobias Burnus  ---
FIXED on GCC 13 (mainline).

[Bug rtl-optimization/106707] [13 Regression] ICE: in cselib_record_set, at cselib.cc:2687 with -Oz -g -fno-cprop-registers -fno-dce since r13-1945-gfc6ef90173478521

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||sayle at gcc dot gnu.org,
   ||ubizjak at gmail dot com
Summary|[13 Regression] ICE: in |[13 Regression] ICE: in
   |cselib_record_set, at   |cselib_record_set, at
   |cselib.cc:2687 with -Oz -g  |cselib.cc:2687 with -Oz -g
   |-fno-cprop-registers|-fno-cprop-registers
   |-fno-dce|-fno-dce since
   ||r13-1945-gfc6ef90173478521
   Keywords|needs-bisection |

--- Comment #3 from Martin Liška  ---
Started with r13-1945-gfc6ef90173478521.

[Bug c++/106689] gcc crash while compiling a generic lambda

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Keywords|needs-reduction |

--- Comment #8 from Martin Liška  ---
Reduced to something like:

cat ice.C
template 
using remove_reference_t = _Tp;
template 
using remove_extent_t = _Tp;
template 
struct integer_sequence {};
template 
using make_integer_sequence = integer_sequence<_Tp, __integer_pack(_Num)...>;
template 
using index_sequence = integer_sequence;
template 
using make_index_sequence = make_integer_sequence;
auto bind(auto... a) {
  [&](index_sequence) {
([a] {
  using A = remove_reference_t;
  is_same_v>(J);
} ||
 ...);
  }
  (make_index_sequence());
}
auto operator_sq2(bind(1.3));

[Bug lto/106686] [lto][offloading] lto-wrapper leaves "target.o" temporay files behind when error diagnostic occurred

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

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

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

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

commit r13-2135-ge228683b244c6afbe3bdfef7ba607fbda813bd0f
Author: Tobias Burnus 
Date:   Mon Aug 22 09:49:52 2022 +0200

lto-wrapper.cc: Delete offload_names temp files in case of error [PR106686]

Usually, the caller takes care of the .o files for the offload compilers
(suffix: ".target.o"). However, if an error occurs during processing
(e.g. fatal error by lto1), they were not deleted.

gcc/ChangeLog:

PR lto/106686
* lto-wrapper.cc (free_array_of_ptrs): Move before tool_cleanup.
(tool_cleanup): Unlink offload_names.
(compile_offload_image): Take filename argument to set it early.
(compile_images_for_offload_targets): Update call; set
offload_names to NULL after freeing the array.

[Bug libstdc++/106695] [11/12/13 Regression] Explicit copy constructor does not work for a parameter passed via std::async

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-08-22
 CC||jwakely.gcc at gmail dot com,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
It's very likely related to change in header files.

[Bug libstdc++/105562] [12 Regression] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

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

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

--- Comment #18 from Richard Biener  ---
(In reply to Sven Hesse from comment #17)
> I still get this with gcc 12.2.0 (Gentoo 12.2.0 p9), but only when compiling
> with (at least with) -O1 -fsanitize=address, in addition to any warning flag
> that enables -Wmaybe-uninitialized (like -Wall, -Wextra or -Wuninitialized).
> 
> -O0 and/or no ASan, and the offending code compiles cleanly without any
> warnings. Somehow, the combination of enabling ASan and optimization
> (anything > -O0, but not -Os) triggers it again, it seems?
> 
> I can observe this with the testcase attached here in this bug report.

-fsanitize=address is likely to derail optimization enough to make such
occurences more likely, I think we have plenty of duplicate bugreports
for this.

[Bug c++/106675] [10/11/12/13 Regression] g++ crashes on funky operators

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Likely started with r9-6526-gdcfa8518868d9eb8 with -std=c++17.

[Bug target/106704] [12/13 Regression] avx intrinsic not generating vblendvps instruction with -mavx

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Hongtao.liu  ---
  _5 = VIEW_CONVERT_EXPR(mask_4(D));
  _6 = _5 < { 0, 0, 0, 0, 0, 0, 0, 0 };
  _7 = VEC_COND_EXPR <_6, b_3(D), a_2(D)>;

It's lowered ly veclower since vcondv8sfv8si and vec_cmpv8si is define under
AVX2.

vec_cmpv8si is defined under avx2 since vpcmpeqd/vpcmpgtq is defined under
AVX2.

[Bug target/106704] [12/13 Regression] avx intrinsic not generating vblendvps instruction with -mavx

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Hongtao.liu  ---
(In reply to Richard Biener from comment #3)
> get_vcond_icode (vmode=E_V8SFmode, cmode=E_V8SImode, uns=false) at
> /home/rguenther/src/trunk/gcc/optabs-query.h:117
> 
> gets us CODE_FOR_nothing though, because
> 
> 5168enum insn_code
> 5169raw_optab_handler (unsigned scode)
> 5170{
> 5171  int i = lookup_handler (scode);
> 5172  return (i >= 0 && this_fn_optabs->pat_enable[i]
> 5173  ? pats[i].icode : CODE_FOR_nothing);
> (gdb) p i
> $12 = 313
> (gdb) p this_fn_optabs->pat_enable[i]
> $14 = false
> (gdb) p pats[i].icode
> $15 = CODE_FOR_vcondv8sfv8si
> 
> #define HAVE_vcondv8sfv8si (TARGET_AVX2 \
>&& (GET_MODE_NUNITS (V8SFmode) \
>== GET_MODE_NUNITS (V8SImode)))
> 
> huh.  Where's AVX2 coming from here ... ah, there's also
> 
> (define_expand "vcond"
>   [(set (match_operand:V_256 0 "register_operand")
> (if_then_else:V_256
>   (match_operator 3 ""
> [(match_operand:VI_256 4 "nonimmediate_operand")
>  (match_operand:VI_256 5 "general_operand")])
>   (match_operand:V_256 1)
>   (match_operand:V_256 2)))]
>   "TARGET_AVX2
>&& (GET_MODE_NUNITS (mode)
>== GET_MODE_NUNITS (mode))"
> {
>   bool ok = ix86_expand_int_vcond (operands);
>   gcc_assert (ok);
>   DONE;
> })
> 
> that looks like a duplicate and that shadows(?) the earlier pattern?
> Hmm, or rather - are the patterns using the "wrong" modes?  Should
> they be "vcond" instead?  I think so.
> 
> @cindex @code{vcond@var{m}@var{n}} instruction pattern
> @item @samp{vcond@var{m}@var{n}}
> Output a conditional vector move.  Operand 0 is the destination to
> receive a combination of operand 1 and operand 2, which are of mode @var{m},
> dependent on the outcome of the predicate in operand 3 which is a signed
> vector comparison with operands of mode @var{n} in operands 4 and 5.  The
> modes @var{m} and @var{n} should have the same size.  Operand 0
> will be set to the value @var{op1} & @var{msk} | @var{op2} & ~@var{msk}
> where @var{msk} is computed by element-wise evaluation of the vector
> comparison with a truth value of all-ones and a false value of all-zeros.

there's 2 modes, var{n} is comparison mode, is mode of operands 4 and 5, 
var{m} is mode of vector to be moved, is mode of operand 0, operand 1 and
operand 2, vcond should be right.

[Bug c/106702] [11 Regression] ICE with LTO: internal compiler error: tree code ‘c_maybe_const_expr’ is not supported in LTO streams

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

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Fixed on master with r12-5347-g2c2148d8c144d738, and started with
r11-3303-g6450f07388f9fe57.

[Bug target/106704] [12/13 Regression] avx intrinsic not generating vblendvps instruction with -mavx

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #6 from Hongtao.liu  ---
(In reply to Jakub Jelinek from comment #4)
> So perhaps the r12-1834-g28560c6d4043d8f6ac570f3 change for TARGET_AVX &&
> !TARGET_AVX2 should be done only if we can fold the VEC_COND_EXPR into a
> constant or something it can handle and otherwise keep the builtin as is?

I've just keep the builtin when there's no avx2, i'm testing the patch.

[Bug rtl-optimization/106707] [13 Regression] ICE: in cselib_record_set, at cselib.cc:2687 with -Oz -g -fno-cprop-registers -fno-dce

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This is invalid RTL, one insn can't set the same destination multiple times.

[Bug target/106704] [12/13 Regression] avx intrinsic not generating vblendvps instruction with -mavx

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #5 from rguenther at suse dot de  ---
On Mon, 22 Aug 2022, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106704
> 
> --- Comment #4 from Jakub Jelinek  ---
> So perhaps the r12-1834-g28560c6d4043d8f6ac570f3 change for TARGET_AVX &&
> !TARGET_AVX2 should be done only if we can fold the VEC_COND_EXPR into a
> constant or something it can handle and otherwise keep the builtin as is?

I think the patterns are wrong instead.