[Bug rtl-optimization/107182] [13 Regression] Commit r13-2871-g1b74b5cb4e9d7191f298245063a8f9c3a1bbeff4 breaks profiledbootstrap

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #5 from Jeffrey A. Law  ---
Should be fixed now.

[Bug rtl-optimization/107182] [13 Regression] Commit r13-2871-g1b74b5cb4e9d7191f298245063a8f9c3a1bbeff4 breaks profiledbootstrap

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jeff Law :

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

commit r13-3211-gdb24bdc743cf23ea12d2dcf8254d86ab366bb46d
Author: Jeff Law 
Date:   Tue Oct 11 00:44:26 2022 -0400

[PR rtl-optimization/107182] Clear EDGE_CROSSING for jump->ret optimization

When turning a jump to a return into a return, we need to clear
EDGE_CROSSING
of the fallthru edge to prevent a checking failure.

I considered not applying the transformation when the edge has
EDGE_CROSSING
set, but it still seems like we ought to eliminate the unnecessary jump in
that case.

gcc/
PR rtl-optimization/107182
* cfgrtl.cc (fixup_reorder_chain): When optimizing a jump to a
return, clear EDGE_CROSSING on the appropriate edge.

[Bug analyzer/107210] New: [13 Regression] ICE in tree_to_uhwi, at tree.cc:6392

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 107210
   Summary: [13 Regression] ICE in tree_to_uhwi, at tree.cc:6392
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gfortran 13.0.0 20221009 snapshot (g:e95e91eccd022a4a3a86da2749809fbad9afd20e)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/gfortran.dg/sizeof.f90, w/ -O1 -fanalyzer:

subroutine check_int (j)
  INTEGER(4) :: i, ia(5), ib(5,4), ip, ipa(:)
  target :: ib
  POINTER :: ip, ipa
  logical :: l(5)

  l = (/ sizeof(i) == 4, sizeof(ia) == 20, sizeof(ib) == 80, &
   sizeof(ip) == 4, sizeof(ipa) == 8 /)

  if (any(.not.l)) STOP 4

end subroutine check_int

% gfortran-13 -O1 -fanalyzer -c twz5zkp4.f90
during IPA pass: analyzer
twz5zkp4.f90:8:43:

8 |sizeof(ip) == 4, sizeof(ipa) == 8 /)
  |   ^
internal compiler error: in tree_to_uhwi, at tree.cc:6392
0x7ad4c3 tree_to_uhwi(tree_node const*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/tree.cc:6392
0x7ad4c3 tree_to_uhwi(tree_node const*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/tree.cc:6390
0x13dbc17 ana::constant_svalue::maybe_fold_bits_within(tree_node*,
ana::bit_range const&, ana::region_model_manager*) const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/analyzer/svalue.cc:891
0x13dbc17 ana::constant_svalue::maybe_fold_bits_within(tree_node*,
ana::bit_range const&, ana::region_model_manager*) const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/analyzer/svalue.cc:870
0x13a089d ana::region_model_manager::maybe_fold_bits_within_svalue(tree_node*,
ana::bit_range const&, ana::svalue const*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/analyzer/region-model-manager.cc:1025
0x13a11aa ana::region_model_manager::get_or_create_bits_within(tree_node*,
ana::bit_range const&, ana::svalue const*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/analyzer/region-model-manager.cc:1116
0x13cc1e3 ana::binding_cluster::maybe_get_compound_binding(ana::store_manager*,
ana::region const*) const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/analyzer/store.cc:1736
0x1374a96 ana::region_model::get_store_value(ana::region const*,
ana::region_model_context*) const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/analyzer/region-model.cc:3210
0x137537c ana::region_model::get_rvalue(ana::path_var,
ana::region_model_context*) const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/analyzer/region-model.cc:3104
0x137c717 ana::region_model::on_assignment(gassign const*,
ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/analyzer/region-model.cc:1088
0x134f294 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::uncertainty_t*,
ana::path_context*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/analyzer/engine.cc:1447
0x135233f ana::exploded_graph::process_node(ana::exploded_node*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/analyzer/engine.cc:4033
0x13531fa ana::exploded_graph::process_worklist()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/analyzer/engine.cc:3436
0x13558ec ana::impl_run_checkers(ana::logger*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/analyzer/engine.cc:6084
0x135693e ana::run_checkers()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/analyzer/engine.cc:6158
0x13451f8 execute
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/analyzer/analyzer-pass.cc:86

[Bug middle-end/107208] [aarch64] _complex integer return types could be improved

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[aarch64] llvm generate |[aarch64] _complex integer
   |better code than gcc base   |return types could be
   |on _Complex type mul|improved
  Component|rtl-optimization|middle-end
   Last reconfirmed||2022-10-11
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Yes it is due to return value and how it is done:

(insn 32 28 33 2 (clobber (reg/i:CDI 0 x0)) "/app/example.cpp":6:1 -1
 (nil))
(insn 33 32 34 2 (set (reg:DI 0 x0)
(reg:DI 102 [  ])) "/app/example.cpp":6:1 -1
 (nil))
(insn 34 33 35 2 (set (reg:DI 1 x1 [+8 ])
(reg:DI 103 [ +8 ])) "/app/example.cpp":6:1 -1
 (nil))
(insn 35 34 0 2 (use (reg/i:CDI 0 x0)) "/app/example.cpp":6:1 -1
 (nil))


So this is not _Complex integer multiplies at all but rather just the return
values and the register allocator.

I wonder why Complex float is expanded slightly differently (and better here):

(insn 34 33 35 2 (set (reg:SF 32 v0)
(reg:SF 115)) "/app/example.cpp":6:1 -1
 (nil))
(insn 35 34 36 2 (set (reg:SF 33 v1)
(reg:SF 118)) "/app/example.cpp":6:1 -1
 (nil))
(insn 36 35 37 2 (use (reg:SF 32 v0)) "/app/example.cpp":6:1 -1
 (nil))
(insn 37 36 0 2 (use (reg:SF 33 v1)) "/app/example.cpp":6:1 -1
 (nil))

Who chose CDI for the integer case but a pair of SF for the float case ...

[Bug tree-optimization/107209] New: [13 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 107209
   Summary: [13 Regression] ICE: verify_gimple failed (error:
statement marked for throw, but doesn't)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-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 20221009 snapshot (g:e95e91eccd022a4a3a86da2749809fbad9afd20e) ICEs
when compiling the following testcase, reduced from
gcc/testsuite/gcc.target/aarch64/simd/vmulx_f64_2.c, w/ -O2
-fnon-call-exceptions -fno-tree-fre:

#include 

float64x1_t
foo (void)
{
  float64_t v1 = 3.14159265359;
  float64_t v2 = 1.383894;
  float64_t vec_1_data[] = {v1};
  float64_t vec_2_data[] = {v2};
  float64x1_t vec_1 = vld1_f64 (vec_1_data);
  float64x1_t vec_2 = vld1_f64 (vec_2_data);

  return vmulx_f64 (vec_1, vec_2);
}

% aarch64-linux-gnu-gcc-13 -O2 -fnon-call-exceptions -fno-tree-fre -c
i2myytft.c
i2myytft.c: In function 'foo':
i2myytft.c:14:1: error: statement marked for throw, but doesn't
   14 | }
  | ^
_24 = 4.34763122374727917218706352286972105503082275390625e+0;
during GIMPLE pass: evrp
i2myytft.c:14:1: internal compiler error: verify_gimple failed
0xf7ec8d verify_gimple_in_cfg(function*, bool)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/tree-cfg.cc:5648
0xe3af47 execute_function_todo
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/passes.cc:2091
0xe3b47e execute_todo
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/passes.cc:2145

[Bug rtl-optimization/107208] [aarch64] llvm generate better code than gcc base on _Complex type mul

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization
  Component|c++ |rtl-optimization

--- Comment #1 from Andrew Pinski  ---
Most likely this is a register allocation issue. I suspect it is due to the way
incoming and returns are represented for complex integer types.

Note complex integer types are an extension to the c language so I doubt many
people use them anyways.

[Bug c++/107208] New: [aarch64] llvm generate better code than gcc base on _Complex type mul

[zhongyunde at huawei dot com via Gcc-bugs]

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

Bug ID: 107208
   Summary: [aarch64] llvm generate better code than gcc base on
_Complex type mul
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhongyunde at huawei dot com
  Target Milestone: ---

* gcc now generate 2 redundant mov instrunction compared to llvm
```
mul64(unsigned long _Complex, unsigned long _Complex):
mov x4, x1// redundant ??
mov x5, x0// redundant ??
mul x6, x1, x2
mul x2, x0, x2
maddx1, x5, x3, x6
msubx0, x4, x3, x2
ret
```

* test case, https://godbolt.org/z/EWE3bc5b3
```
unsigned long _Complex mul64 (unsigned long _Complex mul0,
  unsigned long _Complex mul1)
{
return mul0 * mul1;
}
```

[Bug debug/107193] [13 regression] bootstrap error caused by r13-3172-gf30e9fd33e56a5

[erozen at microsoft dot com via Gcc-bugs]

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

--- Comment #8 from Eugene Rozenfeld  ---
Created attachment 53690
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53690=edit
Proposed patch

[Bug c/107207] Code uses locale.h for thousands separator. Worked well in version 11.3.0, but not in 12.1.0

[ceh2624 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Charles Hildebrant  ---
(In reply to Andrew Pinski from comment #2)
> Most likely you want to report it to these folks:
> Built by Equation Solution .

That's interesting, Andrew.

I'll do that.

Cheers
Charles

[Bug c/107207] Code uses locale.h for thousands separator. Worked well in version 11.3.0, but not in 12.1.0

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

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

--- Comment #2 from Andrew Pinski  ---
Most likely you want to report it to these folks:
Built by Equation Solution .

[Bug c/107207] Code uses locale.h for thousands separator. Worked well in version 11.3.0, but not in 12.1.0

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
locale.h does NOT come from GCC but rather your libc provider.
In this case mingw. Please report it to the mingw folks.

[Bug c/107207] New: Code uses locale.h for thousands separator. Worked well in version 11.3.0, but not in 12.1.0

[ceh2624 at gmail dot com via Gcc-bugs]

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

Bug ID: 107207
   Summary: Code uses locale.h for thousands separator. Worked
well in version 11.3.0, but not in 12.1.0
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ceh2624 at gmail dot com
  Target Milestone: ---

Created attachment 53689
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53689=edit
All the relevant files in a zip file

See and compile the primes.c file.  In version 12.1.0 the thousands separator
no longer shows as a result in printf() output. For example...
when prompted a user might enter "1" then the next line is...
printf("You entered %'d.\n", iTop);
it should show 10,000 nut actually shows 1

[Bug target/103109] madd not used for multiply add on POWER9

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

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

--- Comment #4 from HaoChen Gui  ---
(In reply to Peter Bergner from comment #3)
> (In reply to HaoChen Gui from comment #2)
> > Fixed by r13-2107.
> 
> This is marked version = GCC 12.  Were you planning on backporting this?


Not sure if the patch needs to be back ported. It's not a functional issue.

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

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

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

--- Comment #11 from H.J. Lu  ---
Assuming (reg:CCC 17 flags) is set to 1 by compare properly, how should

(insn 50 49 51 2 (parallel [
(set (reg:SI 93)
(neg:SI (ltu:SI (reg:CCC 17 flags)
(const_int 0 [0]
(clobber (reg:CC 17 flags))
]) "107172.c":4:10 1258 {*x86_movsicc_0_m1_neg}
 (expr_list:REG_DEAD (reg:CCC 17 flags)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil

work?

[Bug c++/107206] New: Bogus -Wuninitialized in std::optional

[ed at catmur dot uk via Gcc-bugs]

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

Bug ID: 107206
   Summary: Bogus -Wuninitialized in std::optional
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ed at catmur dot uk
  Target Milestone: ---

Since 12, at -std=c++17 -O -Wuninitialized:

#include 
struct X {
X() = default;
X(X const& r) : i(r.i) {}
int i;
};
struct Y {
Y() : x() {}
X x;
std::optional o;
};
struct Z {
Y y;
explicit Z(Y y) : y(y) {}
};
void f(Y const&);
void test() {
Y const y;
Z z(y);
z.y.o = 1;
auto const w = z;
f(w.y);
}

In copy constructor 'Y::Y(const Y&)',
inlined from 'void test()' at :19:10:
:7:8: warning: '*(int*)((char*) + offsetof(const Y,
Y::o.std::optional::.std::_Optional_base::))' is used uninitialized [-Wuninitialized]
7 | struct Y {
  |^
: In function 'void test()':
:18:13: note: 'y' declared here
   18 | Y const y;
  | ^

Most similar to #80635 and #86465, I think? Although this is -Wuninitialized,
not -Wmaybe-uninitialized.

[Bug debug/107193] [13 regression] bootstrap error caused by r13-3172-gf30e9fd33e56a5

[erozen at microsoft dot com via Gcc-bugs]

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

--- Comment #7 from Eugene Rozenfeld  ---
No, locus won't be changed by the loop. But the purpose of the loop is to
change statement locations (by adding discriminators) in this line:

  gimple_set_location (stmt, dloc);

I think the code would more clear if this line
  location_t locus = last ? gimple_location (last) : UNKNOWN_LOCATION;
were moved to after the loop.

I'll include that change in the patch.

[Bug debug/107193] [13 regression] bootstrap error caused by r13-3172-gf30e9fd33e56a5

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

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

--- Comment #6 from H.J. Lu  ---
 gimple *last = last_stmt (bb);
  location_t locus = last ? gimple_location (last) : UNKNOWN_LOCATION;
  location_t curr_locus = UNKNOWN_LOCATION;
  int curr_discr = 0;

  /* Traverse the basic block, if two function calls within a basic block
are mapped to the same line, assign a new discriminator because a call
stmt could be a split point of a basic block.  */
  for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next ())
{
  gimple *stmt = gsi_stmt (gsi);
  expanded_location curr_locus_e;
  if (curr_locus == UNKNOWN_LOCATION)
{
  curr_locus = gimple_location (stmt);
  curr_locus_e = expand_location (curr_locus);
}
  else if (!same_line_p (curr_locus, _locus_e, gimple_location
(stmt)))
{
  curr_locus = gimple_location (stmt);
  curr_locus_e = expand_location (curr_locus);
  curr_discr = 0;
}
  else if (curr_discr != 0)
{
  location_t loc = gimple_location (stmt);
  location_t dloc = location_with_discriminator (loc, curr_discr);
  gimple_set_location (stmt, dloc);
}
  /* Allocate a new discriminator for CALL stmt.  */
  if (gimple_code (stmt) == GIMPLE_CALL)
curr_discr = next_discriminator_for_locus (curr_locus);
}

  if (locus == UNKNOWN_LOCATION)
  Will it be changed by the loop above?
continue;

[Bug debug/107193] [13 regression] bootstrap error caused by r13-3172-gf30e9fd33e56a5

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

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #5 from H.J. Lu  ---
*** Bug 107205 has been marked as a duplicate of this bug. ***

[Bug bootstrap/107205] [13 Regression] Bootstrap failure with --with-arch=native --with-cpu=native caused by r13-3172

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
Dup

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

[Bug bootstrap/107205] New: [13 Regression] Bootstrap failure with --with-arch=native --with-cpu=native caused by r13-3172

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

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

Bug ID: 107205
   Summary: [13 Regression] Bootstrap failure with
--with-arch=native --with-cpu=native caused by
r13-3172
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: x86-64

On x86-64 with AVX2 and AVX512, bootstrap failed when configured with

--with-arch=native --with-cpu=native

caused by r13-3172:

/export/build/gnu/tools-build/gcc-native/build-x86_64-linux/./gcc/xgcc
-B/export/build/gnu/tools-build/gcc-native/build-x86_64-linux/./gcc/
-B/usr/gcc-13.0.0-native/x86_64-pc-linux-gnu/bin/
-B/usr/gcc-13.0.0-native/x86_64-pc-linux-gnu/lib/ -isystem
/usr/gcc-13.0.0-native/x86_64-pc-linux-gnu/include -isystem
/usr/gcc-13.0.0-native/x86_64-pc-linux-gnu/sys-include   -fno-checking PIC flag
-fPIC -DPIC works... libtool: link:
/export/build/gnu/tools-build/gcc-native/build-x86_64-linux/./gcc/xgcc
-B/export/build/gnu/tools-build/gcc-native/build-x86_64-linux/./gcc/
-B/usr/gcc-13.0.0-native/x86_64-pc-linux-gnu/bin/
-B/usr/gcc-13.0.0-native/x86_64-pc-linux-gnu/lib/ -isystem
/usr/gcc-13.0.0-native/x86_64-pc-linux-gnu/include -isystem
/usr/gcc-13.0.0-native/x86_64-pc-linux-gnu/sys-include -fno-checking  -m32
-shared  -DPIC  .libs/alloc.o .libs/atomic.o .libs/barrier.o .libs/critical.o
.libs/env.o .libs/error.o .libs/icv.o .libs/icv-device.o .libs/iter.o
.libs/iter_ull.o .libs/loop.o .libs/loop_ull.o .libs/ordered.o .libs/parallel.o
.libs/scope.o .libs/sections.o .libs/single.o .libs/task.o .libs/team.o
.libs/work.o .libs/lock.o .libs/mutex.o .libs/proc.o .libs/sem.o .libs/bar.o
.libs/ptrlock.o .libs/time.o .libs/fortran.o .libs/affinity.o .libs/target.o
.libs/splay-tree.o .libs/libgomp-plugin.o .libs/oacc-parallel.o
.libs/oacc-host.o .libs/oacc-init.o .libs/oacc-mem.o .libs/oacc-async.o
.libs/oacc-plugin.o .libs/oacc-cuda.o .libs/priority_queue.o
.libs/affinity-fmt.o .libs/teams.o .libs/allocator.o .libs/oacc-profiling.o
.libs/oacc-target.o .libs/openacc.o   -ldl -lc  -pthread -mshstk -m32 -O1 -m32
--version-script libgomp.ver   -soname libgomp.so.1 -o .libs/libgomp.so.1.0.0
xgcc: error: unrecognized command-line option '--version-script'
xgcc: error: unrecognized command-line option '-soname'
make[10]: *** [Makefile:730: libgomp.la] Error 1

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

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

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

--- Comment #10 from Segher Boessenkool  ---
The input to combine has

(insn 49 10 50 2 (parallel [
(set (reg:CCC 17 flags)
(ne:CCC (reg:SI 82 [ a.1_2 ])
(const_int 0 [0])))
(set (reg:SI 92)
(neg:SI (reg:SI 82 [ a.1_2 ])))
]) "107172.c":4:10 680 {*negsi_ccc_1}
 (expr_list:REG_DEAD (reg:SI 82 [ a.1_2 ])
(expr_list:REG_UNUSED (reg:SI 92)
(nil
(insn 50 49 51 2 (parallel [
(set (reg:SI 93)
(neg:SI (ltu:SI (reg:CCC 17 flags)
(const_int 0 [0]
(clobber (reg:CC 17 flags))
]) "107172.c":4:10 1258 {*x86_movsicc_0_m1_neg}
 (expr_list:REG_DEAD (reg:CCC 17 flags)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil

This is incorrect already: insn 49 has to do a cmp, not a ne, for it to be
valid.  It was created by the ce1 pass.

[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Mikael Morin
:

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

commit r10-11029-gb394ebd90e1f9c125216c70beedf97d6d8739773
Author: Mikael Morin 
Date:   Sat Sep 3 11:58:47 2022 +0200

fortran: Move clobbers after evaluation of all arguments [PR106817]

For actual arguments whose dummy is INTENT(OUT), we used to generate
clobbers on them at the same time we generated the argument reference
for the function call.  This was wrong if for an argument coming
later, the value expression was depending on the value of the just-
clobbered argument, and we passed an undefined value in that case.

With this change, clobbers are collected separatedly and appended
to the procedure call preliminary code after all the arguments have been
evaluated.

PR fortran/106817

gcc/fortran/ChangeLog:

* trans-expr.c (gfc_conv_procedure_call): Collect all clobbers
to their own separate block.  Append the block of clobbers to
the procedure preliminary block after the argument evaluation
codes for all the arguments.

gcc/testsuite/ChangeLog:

* gfortran.dg/intent_optimize_4.f90: New test.

(cherry picked from commit 29919bf3b6449bafd02e795abbb1966e3990c1fc)

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

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

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

--- Comment #35 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Mikael Morin
:

https://gcc.gnu.org/g:9d18ff4606dabadc5bda11e6cdadc4383ec2f4e5

commit r10-11028-g9d18ff4606dabadc5bda11e6cdadc4383ec2f4e5
Author: Mikael Morin 
Date:   Mon Aug 29 11:19:29 2022 +0200

fortran: Fix invalid function decl clobber ICE [PR105012]

The fortran frontend, as result symbol for a function without
declared result symbol, uses the function symbol itself.  This caused
an invalid clobber of a function decl to be emitted, leading to an
ICE, whereas the intended behaviour was to clobber the function result
variable.  This change fixes the problem by getting the decl from the
just-retrieved variable reference after the call to
gfc_conv_expr_reference, instead of copying it from the frontend symbol.

PR fortran/105012

gcc/fortran/ChangeLog:

* trans-expr.c (gfc_conv_procedure_call): Retrieve variable
from the just calculated variable reference.

gcc/testsuite/ChangeLog:

* gfortran.dg/intent_out_15.f90: New test.

(cherry picked from commit edaf1e005c90b311c39b46d85cea17befbece112)

[Bug debug/107193] [13 regression] bootstrap error caused by r13-3172-gf30e9fd33e56a5

[erozen at microsoft dot com via Gcc-bugs]

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

--- Comment #4 from Eugene Rozenfeld  ---
Yes, that's the problem. Sorry about that, will send a patch with the fix
shortly.

[Bug target/107204] gcc/config/sh/divtab-sh4.cc: 2 * possible float conversion overflow

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

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

--- Comment #1 from Andrew Pinski  ---
Oh this code is not used directly.
The table after it is generated is copied into libgcc/config/sh/lib1funcs.S .

So I doubt anyone has ran this code recently (since 2006 when it was added).

[Bug go/107203] Possible missing sanity check in gofrontend/ast-dump.cc ?

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Ian Lance Taylor  ---
Thanks, but the code is fine.  It is only run when as_pairs is true, meaning
that the list consists of pairs of values.

[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Mikael Morin
:

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

commit r11-10300-gfee1edea459ca655917f14605bdd38fe0e8f344e
Author: Mikael Morin 
Date:   Sat Sep 3 11:58:47 2022 +0200

fortran: Move clobbers after evaluation of all arguments [PR106817]

For actual arguments whose dummy is INTENT(OUT), we used to generate
clobbers on them at the same time we generated the argument reference
for the function call.  This was wrong if for an argument coming
later, the value expression was depending on the value of the just-
clobbered argument, and we passed an undefined value in that case.

With this change, clobbers are collected separatedly and appended
to the procedure call preliminary code after all the arguments have been
evaluated.

PR fortran/106817

gcc/fortran/ChangeLog:

* trans-expr.c (gfc_conv_procedure_call): Collect all clobbers
to their own separate block.  Append the block of clobbers to
the procedure preliminary block after the argument evaluation
codes for all the arguments.

gcc/testsuite/ChangeLog:

* gfortran.dg/intent_optimize_4.f90: New test.

(cherry picked from commit 29919bf3b6449bafd02e795abbb1966e3990c1fc)

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

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

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

--- Comment #34 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Mikael Morin
:

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

commit r11-10299-ge34e5195025acd623c2383c36b99cc88ca026acf
Author: Mikael Morin 
Date:   Mon Aug 29 11:19:29 2022 +0200

fortran: Fix invalid function decl clobber ICE [PR105012]

The fortran frontend, as result symbol for a function without
declared result symbol, uses the function symbol itself.  This caused
an invalid clobber of a function decl to be emitted, leading to an
ICE, whereas the intended behaviour was to clobber the function result
variable.  This change fixes the problem by getting the decl from the
just-retrieved variable reference after the call to
gfc_conv_expr_reference, instead of copying it from the frontend symbol.

PR fortran/105012

gcc/fortran/ChangeLog:

* trans-expr.c (gfc_conv_procedure_call): Retrieve variable
from the just calculated variable reference.

gcc/testsuite/ChangeLog:

* gfortran.dg/intent_out_15.f90: New test.

(cherry picked from commit edaf1e005c90b311c39b46d85cea17befbece112)

[Bug go/107203] Possible missing sanity check in gofrontend/ast-dump.cc ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
git blame says:

706cd57f714f (Roberto Lublinerman 2011-08-24 19:22:44 + 278)  ++it;

[Bug target/107204] New: gcc/config/sh/divtab-sh4.cc: 2 * possible float conversion overflow

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 107204
   Summary: gcc/config/sh/divtab-sh4.cc: 2 * possible float
conversion overflow
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

1.
trunk.git/gcc/config/sh/divtab-sh4.cc:75:34: warning: Undefined behaviour:
float (5.72662e+09) to integer conversion overflow. [floatConversionOverflow]

Source code is

  printf ("\t.long\t0x%X\n", (unsigned) r);

2.

trunk.git/gcc/config/sh/divtab-sh4-300.cc:67:34: warning: Undefined behaviour:
float (8.58993e+09) to integer conversion overflow. [floatConversionOverflow]

Duplicate.

[Bug go/107203] New: Possible missing sanity check in gofrontend/ast-dump.cc ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 107203
   Summary: Possible missing sanity check in
gofrontend/ast-dump.cc ?
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Static analyser cppcheck says:

trunk.git/gcc/go/gofrontend/ast-dump.cc:267:8: warning: Missing bounds check
for extra iterator increment in loop. [StlMissingComparison]

Source code is

  ++it;
  (*it)->dump_expression(this);

I will ignore the dubious benefits of incrementing iterators in loops,
and just mention that a sanity for bounds might be wise before using 
the iterator.

[Bug c++/106937] [10/11/12 Regression] ICE tree check: expected identifier_node, have tree_list in pp_tree_identifier, at tree-pretty-print.cc:4606 since r10-1214-g1bf32c1141e23074

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[10/11/12/13 Regression]|[10/11/12 Regression] ICE
   |ICE tree check: expected|tree check: expected
   |identifier_node, have   |identifier_node, have
   |tree_list in|tree_list in
   |pp_tree_identifier, at  |pp_tree_identifier, at
   |tree-pretty-print.cc:4606   |tree-pretty-print.cc:4606
   |since   |since
   |r10-1214-g1bf32c1141e23074  |r10-1214-g1bf32c1141e23074
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Marek Polacek  ---
Fixed for GCC 13.

[Bug tree-optimization/107200] False positive -Wdangling-pointer?

[remi.galanalfonso at gmail dot com via Gcc-bugs]

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

Rémi Galan Alfonso  changed:

   What|Removed |Added

 CC||remi.galanalfonso at gmail dot 
com

--- Comment #3 from Rémi Galan Alfonso  ---
Hello,

If I remember correctly, Eigen uses expression templates (and the names in the
inline stack make it look like it).
In that case your auto would not be Eigen::Vector2d (which you can see in your
godbolt by adding e.g. "static_assert(std::is_same::value, "Not Eigen::Vector2d.");"), it would be a type that
represents the expression "0.5 * Eigen::Vector2d{1.0, 2.0}", which probably
contains a reference to the temporary Vector2d, which is destroyed at the end
of the line, before the "x(0)" and "x(1)". And that would explain why you don't
see the problem when you replace the auto with "Eigen::Vector2d", as in that
case that causes the evaluation of the expression template while the temporary
still exists.

Moreover, if you enable "Execute the code" on godbolt and add the option
"-fsanitize=address", it trigger the address sanitizer with auto and not
Vector2d, with "ERROR: AddressSanitizer: stack-use-after-scope".
(And bonus: when running the code without sanitizer in O3, what is printed is
not the "expected" result, for example I get "0, 1.03725e-317" on godbolt, GCC
optimized assuming the code doesn't use the dangling values)

So I think the warning is correct, but you probably want to wait for
confirmation from a GCC developer ;).

[Bug c++/106937] [10/11/12/13 Regression] ICE tree check: expected identifier_node, have tree_list in pp_tree_identifier, at tree-pretty-print.cc:4606 since r10-1214-g1bf32c1141e23074

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:67efffec943656a509e036cd3c785a5c3d6885e1

commit r13-3202-g67efffec943656a509e036cd3c785a5c3d6885e1
Author: Marek Polacek 
Date:   Thu Sep 29 17:49:32 2022 -0400

c-family: ICE with [[gnu::nocf_check]] [PR106937]

When getting the name of an attribute, we ought to use
get_attribute_name, which handles both [[]] and __attribute__(())
forms.  Failure to do so may result in an ICE, like here.

pp_c_attributes_display wasn't able to print the [[]] form of
attributes, so this patch teaches it to.

When printing a pointer to function with a standard attribute, the
attribute
should be printed after the parameter-list.  With this patch we print:

  aka 'void (*)(int) [[gnu::nocf_check]]'

or, in C++ with noexcept:

  aka 'void (*)(int) noexcept [[gnu::nocf_check]]'

pp_c_attributes has been unused since its introduction in r56273 so
this patch removes it.

PR c++/106937

gcc/c-family/ChangeLog:

* c-pretty-print.cc (pp_c_specifier_qualifier_list): Print only GNU
attributes here.
(c_pretty_printer::direct_abstract_declarator): Print the standard
[[]]
attributes here.
(pp_c_attributes): Remove.
(pp_c_attributes_display): Print the [[]] form if appropriate.  Use
get_attribute_name.  Don't print a trailing space when printing the
[[]] form.
* c-pretty-print.h (pp_c_attributes): Remove.

gcc/cp/ChangeLog:

* error.cc: Include "attribs.h".
(dump_type_prefix): Print only GNU attributes here.
(dump_type_suffix): Print standard attributes here.

gcc/testsuite/ChangeLog:

* c-c++-common/pointer-to-fn1.c: New test.

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

[brendandg at nyu dot edu via Gcc-bugs]

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

--- Comment #28 from Brendan Dolan-Gavitt  ---
(In reply to H.J. Lu from comment #27)
> (In reply to Florian Weimer from comment #25)
> > (In reply to H.J. Lu from comment #24)
> > > Dropping crtfastmath.o with -shared makes sense.
> > 
> > Are you going to send a patch? I can give it a try as well (although I'm not
> > familiar with the GCC specs language).
> 
> Please give the patch at comment #26 a try.

It may be worth expanding this patch to other architectures that currently have
crtfastmath.o, since they similarly use global FPU state. The ones I have
confirmed are: ia64, loongarch, aarch64, alpha, mips, arm, and sparc.

(Details in this Twitter thread, unfortunately didn't write it up elsewhere:
https://threadreaderapp.com/thread/1567612053363347461.html ).

[Bug c++/107202] New: inheriting assignment operators from CRTP-base

[h2+bugs at fsfe dot org via Gcc-bugs]

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

Bug ID: 107202
   Summary: inheriting assignment operators from CRTP-base
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: h2+bugs at fsfe dot org
  Target Milestone: ---

I stumbled over the following:


```cpp
#define OPTION 0 // or 1-4

template 
struct Base
{
Base() = default;
Base(Base const &) = default;
Base(Base &&) = default;
//Base & operator=(Base const &) = delete;
//Base & operator=(Base &&) = delete;

#if OPTION == 1
Derived const & operator=(Derived &)
{
return static_cast(*this);
}
#elif OPTION == 2
Derived const & operator=(Derived &) const
{
return static_cast(*this);
}
#elif OPTION == 3
Derived const & operator=(Derived const &)
{
return static_cast(*this);
}
#elif OPTION == 4
Derived const & operator=(Derived const &) const
{
return static_cast(*this);
}
#endif
};

struct D : Base
{
D() = default;
D(D const &) = default;
D(D &&) = default;
//D & operator=(D const &) = delete;
//D & operator=(D &&) = delete;

using Base::operator=;
};

int main()
{
D d1;
D d2;
d1 = d2;
}
```


OPTION == 0 → no valid overload (expected!)
OPTION == 1 → well-formed
OPTION == 2 → ambiguous overload
OPTION == 3 → no valid overload
OPTION == 4 → no valid overload

Clang behaves the same as GCC. MSVC never sees any valid overloads.

My assumption was that implicit assignment operators are inhibited in all cases
(this is also shown by OPTION == 0), but that any of the inherited operators
should be valid. Should the implicit deletion of the assignment-operator in D
prevent inheriting the user-defined assignment operators from Base, why does
this affect some of them and not others?

[Bug fortran/105371] The result of the merge function is different when it's type of parameters is the extensions type of derived type

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> Thing is, I have to find a compiler that gives the result the reporter
> expects.

Update: the NAG compiler 7.1 seems to be the only compiler that behaves
as expected by the user.

The somewhat modified testcase shows that not only simplification of MERGE,
but also the generated code behaves inconsistently:

program p
  implicit none
  type t
 integer :: c
  end type
  type, extends (t) :: t2
 integer :: c2
  end type
  class(t), allocatable :: x, y, r
  integer :: i = 1
  x = t2(1,-1)
  y = t2(2,-2)
  r = x
  call check_type()
  r = merge (x, x, i == 1)
  call check_type ()
  r = merge (y, y, i == 2)
  call check_type ()
  r = merge (x, y, i == 2)
  call check_type ()
contains
  subroutine check_type ()
select type (z => r)
type is (t)
   print *, "type is (t) :", z% c
type is (t2)
   print *, "type is (t2):", z% c, z% c2
end select
  end subroutine
end program p

NAG 7.1 prints:

 type is (t2): 1 -1
 type is (t2): 1 -1
 type is (t2): 2 -2
 type is (t2): 2 -2

Current gfortran:

 type is (t2):   1  -1
 type is (t) :   1
 type is (t) :   2
 type is (t2):   2  -2

As MERGE is expanded inline, I was hoping to understand what happens here,
but a first look at the dump-tree looked strange for the second and third
case.  Needs further investigation.

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

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

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

--- Comment #9 from H.J. Lu  ---
(In reply to Segher Boessenkool from comment #7)
> Please show the (relevant part of) output of -fdump-rtl-combine-all ?  At
> least
> those parts where it decided (ltu:SI (const_int 1) (const_int 0)) is valid
> (it
> isn't) and where optimising that to (const_int 0) is valid (it isn't).

Trying 6, 62 -> 63:
6: r87:SI=0x2
   62: {flags:CCC=r87:SI!=0;r96:SI=-r87:SI;}
  REG_DEAD r87:SI
  REG_UNUSED r96:SI
   63: {r97:SI=-ltu(flags:CCC,0);clobber flags:CC;}
  REG_DEAD flags:CCC
  REG_UNUSED flags:CC
Failed to match this instruction:
(parallel [
(set (reg:SI 97)
(const_int 0 [0]))
(clobber (reg:CC 17 flags))
(set (reg:SI 96)
(const_int -2 [0xfffe]))
])
Failed to match this instruction:
(parallel [
(set (reg:SI 97)
(const_int 0 [0]))
(set (reg:SI 96)
(const_int -2 [0xfffe]))
])
Successfully matched this instruction:
(set (reg:SI 96)
(const_int -2 [0xfffe]))
Successfully matched this instruction:
(set (reg:SI 97)
(const_int 0 [0]))
allowing combination of insns 6, 62 and 63
original costs 4 + 0 + 8 = 0
replacement costs 4 + 4 = 8
deferring deletion of insn with uid = 62.
deferring deletion of insn with uid = 6.
modifying insn i262: r96:SI=0xfffe
deferring rescan insn with uid = 62.
modifying insn i363: r97:SI=0
deferring rescan insn with uid = 63.

[Bug target/107160] [13 regression] r13-2641-g0ee1548d96884d causes verification failure in spec2006

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

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

--- Comment #5 from seurer at gcc dot gnu.org ---
I added that option and 554.roms_r now runs OK.

[Bug tree-optimization/107200] False positive -Wdangling-pointer?

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Carlos Galvez  ---
Created attachment 53688
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53688=edit
Preprocessed source

Attaching preprocessed source. Had to use a tarball since it exceeds the 1 MB
limit. Alternatively, you can get the same by adding "-E" to the flags in the
Compiler Explorer example I posted above.

Let me know if I can provide more info! Thanks for looking into it :)

[Bug c/92286] Possible improvement for -Wduplicated-cond warning

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
A quick grep suggests two problems in gcc source code:

trunk.git/gcc/ada/sysdep.c:423:26: style: Expression is always true because
'else if' condition is opposite to previous condition at line 415.
[multiCondition]
trunk.git/libsanitizer/sanitizer_common/sanitizer_allocator_primary64.h:547:27:
style: Expression is always true because 'else if' condition is opposite to
previous condition at line 538. [multiCondition]

and 34 cases in the linux-6.0 kernel.

[Bug c/92286] Possible improvement for -Wduplicated-cond warning

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #4 from David Binderman  ---
Is there a simpler case which is worth addressing, where a condition
is a simple opposite of a predecessor ?

Something like:

void f2( int a, int b)
{
if (a < b)
g( a);
else if (a >= b)
g( b);
else
g( a + b);
}

Static analyser cppcheck can find this:

feb23b.cc:20:13: style: Expression is always true because 'else if' condition
is
 opposite to previous condition at line 18. [multiCondition]
 else if (a >= b)
^
feb23b.cc:18:8: note: first condition
 if (a < b)
   ^
feb23b.cc:20:13: note: else if condition is opposite to first condition
 else if (a >= b)
^

[Bug tree-optimization/107195] [13 Regression] wrong code with "-O1 -fno-tree-ccp" on x86_64-linux-gnu since r13-3090-gdf4c584c567263fd

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

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

--- Comment #6 from Aldy Hernandez  ---
Created attachment 53687
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53687=edit
untested patch

[Bug tree-optimization/107195] [13 Regression] wrong code with "-O1 -fno-tree-ccp" on x86_64-linux-gnu since r13-3090-gdf4c584c567263fd

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #5 from Aldy Hernandez  ---
When solving 0 = _15 & 1, we calculate _15 as:

[irange] int [-INF, -2][0, +INF] NONZERO 0xfffe

The known value of _15 is [0, 1] NONZERO 0x1 which is intersected with
the above, yielding:

[0, 1] NONZERO 0x0

The final nonzero bits tells us the range is 0, but the range is still
[0, 1], which causes logical_combine to assume the range is not-zero,
as irange::zero_p() ignores the nonzero bits.

I think we should just normalize a nonzero mask of 0 to [0, 0] at
creation, thus avoiding all this.

[Bug tree-optimization/107195] [13 Regression] wrong code with "-O1 -fno-tree-ccp" on x86_64-linux-gnu since r13-3090-gdf4c584c567263fd

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

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

--- Comment #4 from Aldy Hernandez  ---
*** Bug 107194 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/107194] [13 Regression] wrong code at -O1 on x86_64-linux-gnu since r13-3090-gdf4c584c567263fd

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #3 from Aldy Hernandez  ---
This is the same issue as 107195.  I have added this testcase to my upcoming
patch.

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

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

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

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

--- Comment #8 from Segher Boessenkool  ---
Bah, scratch that last part, of course it is valid (I thought this was using 0
in a MODE_CC but I just cannot read).

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #7 from Segher Boessenkool  ---
Please show the (relevant part of) output of -fdump-rtl-combine-all ?  At least
those parts where it decided (ltu:SI (const_int 1) (const_int 0)) is valid (it
isn't) and where optimising that to (const_int 0) is valid (it isn't).

[Bug tree-optimization/103633] Missed popcount recognition

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

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

--- Comment #2 from Andrew Pinski  ---
A few extra testcase:
```
unsigned short fs(unsigned int execs)
{
  unsigned i;
  unsigned short num_algorithms = 0;
for (i=0; i<32; i++) {
if ((1<

[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

--- Comment #26 from David Blaikie  ---
FWIW I'm not sure it's a pragma I'd want, but it might be sufficient (put the
pragma at the start of very long/autogenerated files) - I'd have thought what
some folks (myself/LLVM included, I think) is a version of the warning that is
"best effort" and otherwise quiet.

"Tell me when you know I have misleading indentation, otherwise say nothing" -
which is how most warnings work, basically - they all have false negatives.

[Bug middle-end/107190] [aarch64] regression with optimization -fexpensive-optimizations

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|rtl-optimization|middle-end

--- Comment #2 from Andrew Pinski  ---
I think it is the expansion of the add with overflow causing things to be
worse.
(insn 16 15 17 (set (reg:DI 102 [ _17+8 ])
(const_int 0 [0])) -1
 (nil))

(insn 17 16 18 (parallel [
(set (reg:CC_C 66 cc)
(compare:CC_C (plus:DI (reg:DI 109 [ m ])
(reg:DI 111 [ m1 ]))
(reg:DI 109 [ m ])))
(set (reg:DI 112)
(plus:DI (reg:DI 109 [ m ])
(reg:DI 111 [ m1 ])))
]) -1
 (nil))

(jump_insn 18 17 19 (set (pc)
(if_then_else (ltu (reg:CC_C 66 cc)
(const_int 0 [0]))
(label_ref 21)
(pc))) -1
 (int_list:REG_BR_PROB 536868 (nil)))

(jump_insn 19 18 20 (set (pc)
(label_ref 23)) -1
 (nil))

(barrier 20 19 21)

(code_label 21 20 22 3 (nil) [0 uses])

(insn 22 21 23 (set (reg:DI 102 [ _17+8 ])
(const_int 1 [0x1])) -1
 (nil))

(code_label 23 22 24 2 (nil) [0 uses])


I don't see why we need to expand to a jump here rather than a cset?
I think there is another bug about this already too.

[Bug rtl-optimization/107190] [aarch64] regression with optimization -fexpensive-optimizations

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |rtl-optimization

--- Comment #1 from Andrew Pinski  ---
(In reply to vfdff from comment #0)
> This case is simplify from
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107090, and we can see that the
> codegen of function `test_m` has some regression with optimization
> -fexpensive-optimizations, https://gcc.godbolt.org/z/zbKrEox4j
> 
> This is because the pass 208t.widening_mul is controlled by
> -fexpensive-optimizations (default on at -O3), it conversion
> 
> ```
>   m_12 = m_9 + m1_10;
>   if (m1_10 > m_12)
> ```
> into
> 
> ```
>   _17 = .ADD_OVERFLOW (m_9, m1_10);
>   m_12 = REALPART_EXPR <_17>;
>   _18 = IMAGPART_EXPR <_17>;
>   if (_18 != 0)``

This should always be better. If ifcvt.cc does not handle this case, then it
should be improved.

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

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

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

--- Comment #27 from H.J. Lu  ---
(In reply to Florian Weimer from comment #25)
> (In reply to H.J. Lu from comment #24)
> > Dropping crtfastmath.o with -shared makes sense.
> 
> Are you going to send a patch? I can give it a try as well (although I'm not
> familiar with the GCC specs language).

Please give the patch at comment #26 a try.

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

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

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

--- Comment #26 from H.J. Lu  ---
Created attachment 53686
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53686=edit
A patch not to add crtfastmath.o for -shared on x86

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

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

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

--- Comment #32 from Segher Boessenkool  ---
(In reply to Peter Bergner from comment #31)
> (In reply to Segher Boessenkool from comment #30)
> > We have to disallow all (*all*) operands that require prefixed insns, until
> > we can handle those properly.
> 
> So if we can't disallow pcrel addresses in asm operands in 
> rs6000_legitimate_address_p, then where can we disallow them when they're
> used with all of the current memory constraints?  Ie, not the new pcrel
> address friendly constraint we don't have yet?

Maybe we can do something like

  "m!"(xx)

to mean prefixed addressing is allowed.  This would be handled adjacent to
where we handle "m<>" already (in recog.cc mostly).

[Bug c++/107200] False positive -Wdangling-pointer?

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Can you attach the preprocessed source?

[Bug target/107183] [10/11/12/13 Regression] -fcompare-debug failure (length) with -fsanitize=float-cast-overflow since r7-5708-gcfd719e7769fd43f

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Martin Liška from comment #2)
> Likely started with r7-5708-gcfd719e7769fd43f.

Exposed by 

[Bug target/107201] New: [avr] -nodevicelib not working for devices -mmcu=avr...

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

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

Bug ID: 107201
   Summary: [avr] -nodevicelib not working for devices
-mmcu=avr...
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

The -nodevicelib option can be used so that the executable is not linked
against -l when a device is specified as -mmcu=.  This is
useful if such a library is not avilable.

This is achieved by the following spec in the device-specs file specs-:

*avrlibc_devicelib:
%{!nodevicelib:-lavr64dd64}

However, in a spec function, the driver in
./gcc/config/avr/driver-avr.c[c]::avr_devicespecs_file() removes that option
because it thinks that -mmcu=avr* is a device *family* like avr25 or avrxmega2
etc.:

#if defined (WITH_AVRLIBC)
 " %{mmcu=avr*:" X_NODEVLIB "} %{!mmcu=*:" X_NODEVLIB "}",
#else

where X_NODEVLIB resolves to "%

[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

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

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

--- Comment #25 from Lewis Hyatt  ---
This patch would make the note controllable via #pragma GCC diagnostic in the
same way as the warning is:

=
diff --git a/gcc/c-family/c-indentation.cc b/gcc/c-family/c-indentation.cc
index 85a3ae1b303..3b5d3b17cc9 100644
--- a/gcc/c-family/c-indentation.cc
+++ b/gcc/c-family/c-indentation.cc
@@ -310,7 +310,8 @@ should_warn_for_misleading_indentation (const
token_indent_info _tinfo,
   if (!guard_exploc.column || !body_exploc.column || !next_stmt_exploc.column)
 {
   static bool issued_note = false;
-  if (!issued_note)
+  if (!issued_note
+ && warning_enabled_at (guard_loc, OPT_Wmisleading_indentation))
{
  /* Notify the user the first time this happens.  */
  issued_note = true;

=

I am not quite sure how to interpret Jakub's comments though (comment 14 and
comment 16)... not sure whether he was saying this change would be undesirable,
or just explaining why it doesn't seem strictly necessary.

[Bug tree-optimization/107096] Fully masking vectorization with AVX512 ICEs gcc.dg/vect/vect-over-widen-*.c

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

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

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
(In reply to rguent...@suse.de from comment #7)
> more like precision but x86 uses QImode for two-element, four-element
> and eight-element masks (rather than two partial integer modes with
> two and four bits precision).
Ah, OK.  So yeah, maybe the precision of the vector boolean element *
the number of elements.

[Bug c++/107188] using concept type-constraint declared in nested namespace causes incorrect compilation error

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

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 CC||ppalka at gcc dot gnu.org
   Last reconfirmed||2022-10-10
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Patrick Palka  ---
Confirmed, not a regression.  Reduced:

namespace N {
  template concept C = true;
}

struct X {
  N::C auto f() { return 0; }
};

[Bug c++/107200] New: False positive -Wdangling-pointer?

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

Bug ID: 107200
   Summary: False positive -Wdangling-pointer?
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carlosgalvezp at gmail dot com
  Target Milestone: ---

Hi, 

The following code triggers a -Wdangling-pointer on GCC 12 and GCC 13:

#include 
#include 

Eigen::Vector2d foo() { 
return {1.0, 2.0};
}

int main()
{
auto x = 0.5 * foo();
std::cout << x(0) << ", " << x(1) << std::endl;
}

: In function 'int main()':
:10:23: note: unnamed temporary defined here
   10 | auto x = 0.5 * foo();
  |~~~^~
In member function 'const Eigen::internal::scalar_product_op::result_type Eigen::internal::scalar_product_op::operator()(const LhsScalar&, const RhsScalar&) const [with
LhsScalar = double; RhsScalar = double]',
inlined from
'Eigen::internal::binary_evaluator,
Eigen::internal::IndexBased, Eigen::internal::IndexBased>::CoeffReturnType
Eigen::internal::binary_evaluator,
Eigen::internal::IndexBased, Eigen::internal::IndexBased>::coeff(Eigen::Index)
const [with BinaryOp = Eigen::internal::scalar_product_op; Lhs
= const Eigen::CwiseNullaryOp,
const Eigen::Matrix >; Rhs = const Eigen::Matrix]'
at
/opt/compiler-explorer/libs/eigen/v3.3.9/Eigen/src/Core/CoreEvaluators.h:719:21,
inlined from 'Eigen::DenseCoeffsBase::CoeffReturnType
Eigen::DenseCoeffsBase::coeff(Eigen::Index) const [with Derived =
Eigen::CwiseBinaryOp, const
Eigen::CwiseNullaryOp, const
Eigen::Matrix >, const Eigen::Matrix >]' at
/opt/compiler-explorer/libs/eigen/v3.3.9/Eigen/src/Core/DenseCoeffsBase.h:144:59,
inlined from 'Eigen::DenseCoeffsBase::CoeffReturnType
Eigen::DenseCoeffsBase::operator()(Eigen::Index) const [with
Derived = Eigen::CwiseBinaryOp, const
Eigen::CwiseNullaryOp, const
Eigen::Matrix >, const Eigen::Matrix >]' at
/opt/compiler-explorer/libs/eigen/v3.3.9/Eigen/src/Core/DenseCoeffsBase.h:181:19,
inlined from 'int main()' at :11:37:
/opt/compiler-explorer/libs/eigen/v3.3.9/Eigen/src/Core/functors/BinaryFunctors.h:86:128:
warning: using a dangling pointer to an unnamed temporary [-Wdangling-pointer=]
   86 |   EIGEN_DEVICE_FUNC EIGEN_STRONG_INLINE const result_type operator()
(const LhsScalar& a, const RhsScalar& b) const { return a * b; }
  | 

Reproducible on Godbolt: https://godbolt.org/z/7475f7WvK

The warning goes away with this change:

-auto x = 0.5 * foo();
+Eigen::Vector2d x = 0.5 * foo();

What could be the reason for this behavior?

Thanks!

[Bug c++/107198] [13 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:752 since r13-3175-g6ffbf87ca66f4ed9

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|[13 Regression] ICE in  |[13 Regression] ICE in
   |cp_gimplify_expr, at|cp_gimplify_expr, at
   |cp/cp-gimplify.cc:752   |cp/cp-gimplify.cc:752 since
   ||r13-3175-g6ffbf87ca66f4ed9
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-10-10

--- Comment #1 from Martin Liška  ---
Started with r13-3175-g6ffbf87ca66f4ed9.

[Bug debug/107193] [13 regression] bootstrap error caused by r13-3172-gf30e9fd33e56a5

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-10-10
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org

[Bug tree-optimization/107195] [13 Regression] wrong code with "-O1 -fno-tree-ccp" on x86_64-linux-gnu since r13-3090-gdf4c584c567263fd

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

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-reduction |
 CC||aldyh at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=107194
Summary|[13 Regression] wrong code  |[13 Regression] wrong code
   |with "-O1 -fno-tree-ccp" on |with "-O1 -fno-tree-ccp" on
   |x86_64-linux-gnu|x86_64-linux-gnu since
   ||r13-3090-gdf4c584c567263fd

--- Comment #3 from Martin Liška  ---
Also started with r13-3090-gdf4c584c567263fd.

[Bug target/99723] [11/12/13 Regression] arm: ICE in build_function_type during selftests

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

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

--- Comment #4 from CVS Commits  ---
The trunk branch has been updated by Andrea Corallo :

https://gcc.gnu.org/g:248c8aeebc49aae3fd96bd587367d12e7c8b3c3a

commit r13-3201-g248c8aeebc49aae3fd96bd587367d12e7c8b3c3a
Author: Andrea Corallo 
Date:   Tue Sep 27 16:20:28 2022 +0200

Don't ICE running selftests if errors were raised [PR99723]

Hi all

this is to address PR 99723.

In the PR GCC crashes as the initialization of common trees is not
performed as no compilation is happening, this is because we raise an
error earlier while processing the arch flags.

This patch changes the code to execute selftests only if no errors
where raised before.

Bootstrapped on aarch64, okay for trunk?

Best Regards

  Andrea

2022-09-27  Andrea Corallo  

PR other/99723
* toplev.cc (toplev::main): Don't run self tests in case of
previous error.

[Bug tree-optimization/107194] [13 Regression] wrong code at -O1 on x86_64-linux-gnu since r13-3090-gdf4c584c567263fd

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|[13 Regression] wrong code  |[13 Regression] wrong code
   |at -O1 on x86_64-linux-gnu  |at -O1 on x86_64-linux-gnu
   ||since
   ||r13-3090-gdf4c584c567263fd

--- Comment #2 from Martin Liška  ---
Started with r13-3090-gdf4c584c567263fd.

[Bug target/107183] [10/11/12/13 Regression] -fcompare-debug failure (length) with -fsanitize=float-cast-overflow since r7-5708-gcfd719e7769fd43f

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-10-10
 Status|UNCONFIRMED |NEW
Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression]
   |-fcompare-debug failure |-fcompare-debug failure
   |(length) with   |(length) with
   |-fsanitize=float-cast-overf |-fsanitize=float-cast-overf
   |low |low since
   ||r7-5708-gcfd719e7769fd43f
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Likely started with r7-5708-gcfd719e7769fd43f.

[Bug tree-optimization/107096] Fully masking vectorization with AVX512 ICEs gcc.dg/vect/vect-over-widen-*.c

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #7 from rguenther at suse dot de  ---
On Mon, 10 Oct 2022, rsandifo at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107096
> 
> --- Comment #6 from rsandifo at gcc dot gnu.org  
> ---
> The PR means supporting targets where this assumption doesn't hold.
> But I think we should test for it explicitly somehow.  For now we
> can probably assume that the assumption holds when the two mask
> modes have equal size.

more like precision but x86 uses QImode for two-element, four-element
and eight-element masks (rather than two partial integer modes with
two and four bits precision).

[Bug target/107199] New: AVX512 fully masked loop vectorization needs extract_last pattern for vectorization of live variables

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

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

Bug ID: 107199
   Summary: AVX512 fully masked loop vectorization needs
extract_last pattern for vectorization of live
variables
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

For fully masked vectorization with AVX512 we'd need to define extract_last
which given a loop mask {kN} extracts the lane of the vector corresponding
to the last set bit in {kN} (the last iteration of the loop).

I don't see a kOP for this so I suppose moving {kN} to a GPR and then
doing BSR, moving it back and then doing a compress might work.

[Bug tree-optimization/107096] Fully masking vectorization with AVX512 ICEs gcc.dg/vect/vect-over-widen-*.c

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

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
I don't think we should key this off whether the masks are integers
or vectors.  In principle there's no reason why a vector-based
couldn't work the AVX512 way, or an integer approach the SVE way.
(build_truth_vector_type_for_mode is currently hard-coded to 1 bit
per element for integers, but that could change.)

At the moment:

   We make the simplifying assumption that if a sequence of nV masks is
   suitable for one (nS,nL) pair, we can reuse it for (nS/2,nL/2) by
   VIEW_CONVERTing it.  This holds for all current targets that support
   fully-masked loops.

The PR means supporting targets where this assumption doesn't hold.
But I think we should test for it explicitly somehow.  For now we
can probably assume that the assumption holds when the two mask
modes have equal size.

[Bug tree-optimization/107096] Fully masking vectorization with AVX512 ICEs gcc.dg/vect/vect-over-widen-*.c

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

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

--- Comment #5 from Richard Biener  ---
(In reply to Andrew Stubbs from comment #4)
> I don't understand rgroups, but I can say that GCN masks are very simply
> one-bit-one-lane. There are always 64-lanes, regardless of the type, so
> V64QI mode has fewer bytes and bits than V64DImode (when written to memory).
> 
> This is different to most other architectures where the bit-size remains the
> same and number of lanes varies with the inner type, and has caused us some
> issues with invalid assumptions in GCC (e.g. "there's no need for
> sign-extends in vector registers" is not true for GCN).
> 
> However, I think it's the same as you're describing for AVX512, at least in
> this respect.
> 
> Incidentally I'm on the cusp of adding multiple "virtual" vector sizes in
> the GCN backend (in lieu of implementing full mask support everywhere in the
> middle-end and fixing all the cost assumptions), so these VIEW_CONVERT_EXPR
> issues are getting worse. I have a bunch of vec_extract patterns that fix up
> some of it. Within the backed, the V32, V16, V8, V4 and V2 vectors are all
> really just 64-lane vectors with the mask preset, so the mask has to remain
> DImode or register allocation becomes tricky.

For the documentation test case GCN seems to skirt the issue by using
different "sized" vectors so it manages to get two different nV here, one
for the float and one for the double rgroup.  With AVX512 I get the
same nV and wrong code, re-using the mask of the floats:

  _51 = VIEW_CONVERT_EXPR>(loop_mask_40);

(but the verifier not ICEing because it only checks modes).

GCN gets nV == 1 for both for

void foo (float *f, double * __restrict d, int n)
{
  for (int i = 0; i < n; ++i)
{
  f[i] += 1.0f;
  d[i] += 3.0;
}
}

and here sharing the mask is OK.

So it looks like the sharing logic depends on how we get to assign
vector modes - GCN insists on handing out only 64 lane vectors.  If
you'd change that and allow mixing I guess you'll run into similar
issues as AVX512.

Only handing out 8-lane vectors would limit AVX512 quite a bit so
that doesn't sound like a viable option to us.  RVV might be in the
same situation as GCN here.

For GCN with DImode mask vectors at the point where V_C_Es would be
emitted we could assert that the number of lanes are the same (we
probably should, otherwise we'd have wrong-code).

So eventually special-casing integer mode masks might work out.

[Bug tree-optimization/107096] Fully masking vectorization with AVX512 ICEs gcc.dg/vect/vect-over-widen-*.c

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

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

--- Comment #4 from Andrew Stubbs  ---
I don't understand rgroups, but I can say that GCN masks are very simply
one-bit-one-lane. There are always 64-lanes, regardless of the type, so V64QI
mode has fewer bytes and bits than V64DImode (when written to memory).

This is different to most other architectures where the bit-size remains the
same and number of lanes varies with the inner type, and has caused us some
issues with invalid assumptions in GCC (e.g. "there's no need for sign-extends
in vector registers" is not true for GCN).

However, I think it's the same as you're describing for AVX512, at least in
this respect.

Incidentally I'm on the cusp of adding multiple "virtual" vector sizes in the
GCN backend (in lieu of implementing full mask support everywhere in the
middle-end and fixing all the cost assumptions), so these VIEW_CONVERT_EXPR
issues are getting worse. I have a bunch of vec_extract patterns that fix up
some of it. Within the backed, the V32, V16, V8, V4 and V2 vectors are all
really just 64-lane vectors with the mask preset, so the mask has to remain
DImode or register allocation becomes tricky.

[Bug tree-optimization/107153] [13 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645

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

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

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

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

commit r13-3191-ga99f511c57b5b02edfd5969148c580b4a8737ee8
Author: Jakub Jelinek 
Date:   Mon Oct 10 12:04:56 2022 +0200

Require fgraphite effective target for pr107153.c test [PR107153]

The test uses -floop-parallelize-all which emits a sorry when graphite
isn't configured in.

2022-10-10  Jakub Jelinek  

PR tree-optimization/107153
* gcc.dg/autopar/pr107153.c: Require fgraphite effective target.

[Bug tree-optimization/107096] Fully masking vectorization with AVX512 ICEs gcc.dg/vect/vect-over-widen-*.c

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||ams at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
(In reply to rsand...@gcc.gnu.org from comment #2)
> See the comment above rgroup_controls in tree-vectorizer.h for the
> current assumptions around loop predication.  If AVX512 wants something
> different then some extensions will be needed :-)

Coming back to this now.  Crucially

   If only the first three lanes are active, the masks we need are:

 f rgroup: 1 1 | 1 1 | 1 1 | 0 0
 d rgroup:  1  |  1  |  1  |  0

   Here we can use a mask calculated for f's rgroup for d's, but not
   vice versa.

that seems to assume that the space in the mask vector for the "bools"
in the d rgroup is twice as large as in that for the f rgroup.

For AVX512 there's a single bit for each lane, independently on the
width of the actual data.  So instead of 

   Thus for each value of nV, it is enough to provide nV masks, with the
   mask being calculated based on the highest nL (or, equivalently, based
   on the highest nS) required by any rgroup with that nV.  We therefore
   represent the entire collection of masks as a two-level table, with the
   first level being indexed by nV - 1 (since nV == 0 doesn't exist) and
   the second being indexed by the mask index 0 <= i < nV.

we need a set of nV masks for each value of nS, and we can pick the
smallest nV for each nS and generate the corresponding larger nV
masks by a series of shifts.  In fact we can re-use the first vector
(excess bits are OK).  So for the example in tree-vectorizer.h

 float *f;
 double *d;
 for (int i = 0; i < n; ++i)
   {
 f[i * 2 + 0] += 1.0f;
 f[i * 2 + 1] += 2.0f;
 d[i] += 3.0;
   }

we'd need to perform two WHILE_ULT.  For

 float *f;
 double *d;
 for (int i = 0; i < n; ++i)
   {
 f[i] += 1.0f;
 d[i] += 3.0;
   }

we'd compute the mask for the f rgroup with a WHILE_ULT and we'll
have nV_d = 2 * nV_f and the first mask vector from f can be reused
for d (but not the other way around).  The second mask vector for
d can be obtained by kshiftr.

There's no other way to do N bit to two N/2 bit hi/lo (un)packing
(there's a 2x N/2 bit -> N bit operation, for whatever reason).
There's also no way to transform the d rgroup mask into the
f rgroup mask for the first example aka duplicate bits in place,
{ b0, b1, b2, ... bN } -> { b0, b0, b1, b1, b2, b2, ... bN, bN },
nor the reverse.

So in reality it seems we need a set of mask vectors for the full
set of nS * nV combinations with AVX512.  Doing fully masking with
AVX2 style vectors would work with the existing rgroup control scheme.

Currently the "key" to the AVX512 behavior is the use of scalar modes
for the mask vectors but then that's also what GCN uses.  Do GCN
mask bits really map to bytes to allow the currently used rgroup scheme?

[Bug tree-optimization/107090] [aarch64] sequence logic should be combined with mul and umulh

[zhongyunde at huawei dot com via Gcc-bugs]

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

vfdff  changed:

   What|Removed |Added

  Attachment #53684|0   |1
is obsolete||

--- Comment #7 from vfdff  ---
Created attachment 53685
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53685=edit
[PHIOPT] Add A ? B + CST : B match and simplify optimizations

Thank you for your guidance, I have referred to your patch linked to supplement
the various types of operations.
Due to an error in building the (op @1 (cond^ @0 @2 {build_zero_cst (type);})),
I have not incorporated the modifications into your patch at this time. If it
is your consent, I would like to merge these modifications separately. And then
finish up that patch, after asking for further information.

[Bug c++/107198] [13 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:752

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
   Target Milestone|--- |13.0

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

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

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

--- Comment #25 from Florian Weimer  ---
(In reply to H.J. Lu from comment #24)
> Dropping crtfastmath.o with -shared makes sense.

Are you going to send a patch? I can give it a try as well (although I'm not
familiar with the GCC specs language).

[Bug tree-optimization/107184] Copy warnings in dump files

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

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

--- Comment #3 from Marc Glisse  ---
(In reply to Richard Biener from comment #2)
> Confirmed - for array-bounds I added some "array-bound warning for %E"
> printing the SSA name/stmt in the dump file.

Sounds good, I'll try that next time the warning is of the array-bound type.

> What I find useful in tracking down things is to -fdump-tree-FOO-lineno which
> at least gets you the locations in the dump.

Ah, I didn't know that one (-lineno isn't part of -all). It is nice, but with
inlining and all the corresponding source line actually appears hundreds of
times in the dump, and this does not tell me which of those causes the warning.

[Bug c/107197] valgrind error in function same_line_p during build

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #7)
> (In reply to Richard Biener from comment #5)
> > Probably the same as PR107193
> 
> I guess so, see comment3 in PR107193.

It looks like exact below warns for.
==107792== Conditional jump or move depends on uninitialised value(s)
==107792==at 0xD5004B: same_line_p (tree-cfg.cc:1160)
==107792==by 0xD5004B: assign_discriminators (tree-cfg.cc:1224)
==107792==by 0xD5004B: build_gimple_cfg (tree-cfg.cc:251)
==107792==by 0xD5004B: execute_build_cfg (tree-cfg.cc:371)

[Bug c/107197] valgrind error in function same_line_p during build

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #7 from Hongtao.liu  ---
(In reply to Richard Biener from comment #5)
> Probably the same as PR107193

I guess so, see comment3 in PR107193.

[Bug c++/107198] New: [13 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:752

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 107198
   Summary: [13 Regression] ICE in cp_gimplify_expr, at
cp/cp-gimplify.cc:752
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++ 13.0.0 20221009 snapshot (g:e95e91eccd022a4a3a86da2749809fbad9afd20e) ICEs
when compiling the following testcase, reduced from
gcc/testsuite/g++.dg/eh/aggregate1.C, w/ -fno-exceptions:

struct A {
  A() { throw 0; }
  A(int i) { throw i; }
  A(const A&) { throw 10; }
};

void try_idx (int i)
{
  int t = 10;
  try {
struct X {
  A e1[2], e2;
}
x2[3] = { { 1, 2, 3 }, { 4, 5, 6 } };
  } catch (int x) { t = x; }
}

% g++-13 -fno-exceptions -c bqn7qvfj.C
bqn7qvfj.C: In constructor 'A::A()':
bqn7qvfj.C:2:15: error: exception handling disabled, use '-fexceptions' to
enable
2 |   A() { throw 0; }
  |   ^
bqn7qvfj.C: In function 'void try_idx(int)':
bqn7qvfj.C:15:25: error: 'x' was not declared in this scope
   15 |   } catch (int x) { t = x; }
  | ^
bqn7qvfj.C:14:40: internal compiler error: in cp_gimplify_expr, at
cp/cp-gimplify.cc:752
   14 | x2[3] = { { 1, 2, 3 }, { 4, 5, 6 } };
  |^
0x6b0a60 cp_gimplify_expr(tree_node**, gimple**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/cp/cp-gimplify.cc:752
0xef9bb6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:16237
0xf00459 gimplify_init_ctor_eval_range
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:4881
0xf00459 gimplify_init_ctor_eval
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:4960
0xf002c5 gimplify_init_ctor_eval
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:4985
0xf00b93 gimplify_init_constructor
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:5399
0xf0e0db gimplify_modify_expr
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:6076
0xefa515 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:16328
0xf0c307 gimplify_stmt(tree_node**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:7187
0xf0c307 gimplify_compound_expr
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:6380
0xefad3c gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:16318
0xefce06 gimplify_stmt(tree_node**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:7187
0xefe5fc gimplify_cleanup_point_expr
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:6928
0xefb05a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:16721
0xefce06 gimplify_stmt(tree_node**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:7187
0xefb7a3 gimplify_statement_list
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:2021
0xefb7a3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:16773
0xefce06 gimplify_stmt(tree_node**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:7187
0xefb7a3 gimplify_statement_list
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:2021
0xefb7a3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:16773

[Bug debug/107193] [13 regression] bootstrap error caused by r13-3172-gf30e9fd33e56a5

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
1212  /* Traverse the basic block, if two function calls within a basic
block
 1213are mapped to the same line, assign a new discriminator because a
call
 1214stmt could be a split point of a basic block.  */
 1215  for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next ())
 1216{
 1217  gimple *stmt = gsi_stmt (gsi);
 1218  expanded_location curr_locus_e;


Shouldn't curr_locus_e be defined outside of the loop?
orelse, the second iteration, it will be uninitialized and pased to
same_line_p？
 1219  if (curr_locus == UNKNOWN_LOCATION)
 1220{
 1221  curr_locus = gimple_location (stmt);
 1222  curr_locus_e = expand_location (curr_locus);
 1223}
 1224  else if (!same_line_p (curr_locus, _locus_e,
gimple_location (stmt)))
 1225{
 1226  curr_locus = gimple_location (stmt);
 1227  curr_locus_e = expand_location (curr_locus);
 1228  curr_discr = 0;
 1229}
 1230  else if (curr_discr != 0)
 1231{
 1232  location_t loc = gimple_location (stmt);
 1233  location_t dloc = location_with_discriminator (loc,
curr_discr);
 1234  gimple_set_location (stmt, dloc);
 1235}
 1236  /* Allocate a new discriminator for CALL stmt.  */
 1237  if (gimple_code (stmt) == GIMPLE_CALL)
 1238curr_discr = next_discriminator_for_locus (curr_locus);
 1239}

[Bug debug/107193] [13 regression] bootstrap error caused by r13-3172-gf30e9fd33e56a5

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---

> 
> reproduce with attached testcase
> 
> ./gcc/xgcc -B ./gcc -O2 _sd_to_udi.i -g -m32
> 
> And It looks like there's some random when reproducing.(sometimes pass,
> sometimes failed).

configure of gcc:
 --with-cpu=native --with-arch=native --disable-libsanitizer
--enable-checking=yes,rtl,extra

On cascadelake.
Remove --with-cpu=native --with-arch=native seems hide the issue.

[Bug c/107197] valgrind error in function same_line_p during build

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
Git hash  09df0d8b14dda66c seems good. Trying fce601fd07fd04f5.

[Bug target/107185] [13 Regression] during RTL pass: vregs ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -ffast-math and lrintf()

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
Fixed in GCC13.

[Bug target/107185] [13 Regression] during RTL pass: vregs ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -ffast-math and lrintf()

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:9b8520fa9d745b3a974d5eb98cb4b9a9021b215d

commit r13-3189-g9b8520fa9d745b3a974d5eb98cb4b9a9021b215d
Author: liuhongt 
Date:   Sun Oct 9 15:30:10 2022 +0800

Fix unrecognizable insn of cvtss2si.

Adjust lrintmn2 operand preidcates according to real instructions.

gcc/ChangeLog:

PR target/107185
* config/i386/i386.md (lrint2): Swap
predicate of operands[0] and operands[1].

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr107185.c: New test.

[Bug debug/107193] [13 regression] bootstrap error caused by r13-3172-gf30e9fd33e56a5

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Hongtao.liu  ---
Looks similar as
https://gcc.gnu.org/pipermail/gcc-regression/2022-October/077050.html

[Bug c/107197] valgrind error in function same_line_p during build

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||erozen at microsoft dot com

--- Comment #5 from Richard Biener  ---
Probably the same as PR107193

[Bug libfortran/105764] libgfortran fails to build with a custom thread model

[lh_mouse at 126 dot com via Gcc-bugs]

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

LIU Hao  changed:

   What|Removed |Added

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

--- Comment #2 from LIU Hao  ---
This has been fixed on trunk with decbb5bf7cc7317fefa53f0d64082cf020e85e42.

[Bug ipa/107196] [13 Regression] llvm-14.0.6 is miscompiles by gcc-13 in -O3: hangs llvm testsuite (inliner seems to break it)

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Keywords||wrong-code

[Bug tree-optimization/107195] [13 Regression] wrong code with "-O1 -fno-tree-ccp" on x86_64-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-10-10
   Keywords||needs-reduction
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
Version|unknown |13.0

[Bug tree-optimization/107194] [13 Regression] wrong code at -O1 on x86_64-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||needs-bisection, wrong-code
   Last reconfirmed||2022-10-10
Summary|wrong code at -O1 on|[13 Regression] wrong code
   |x86_64-linux-gnu|at -O1 on x86_64-linux-gnu
 Ever confirmed|0   |1
  Known to work||12.2.0
Version|unknown |13.0
   Target Milestone|--- |13.0

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug debug/107193] [13 regression] bootstrap error caused by r13-3172-gf30e9fd33e56a5

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/107184] Copy warnings in dump files

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Confirmed - for array-bounds I added some "array-bound warning for %E" printing
the SSA name/stmt in the dump file.

What I find useful in tracking down things is to -fdump-tree-FOO-lineno which
at least gets you the locations in the dump.

So - patches to amend dump files welcome!

[Bug c/107197] valgrind error in function same_line_p during build

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
Git hash e2a228438919d846 seems good. Trying 09df0d8b14dda66c.

[Bug c++/106925] [12/13 Regression] ICE in maybe_splice_retval_cleanup at gcc/cp/except.cc:1330 since r12-8066-g4822108e61ab8790

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Carlos Galvez  ---
Hi, is there any progress on the issue?