[Bug target/106460] internal compiler error: output_operand: invalid expression as operand on -O1

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

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

--- Comment #1 from Jiu Fu Guo  ---
The ice occur when output rtx "(high:DI (symbol_ref:DI ("var_48")..))) to
constant pool.
This rtx is generated at function "recog_for_combine"(in combine.cc) after
invoking "force_const_mem".

This kind of rtx represents the high part of a symbol_ref/address when passed
as an argument to "cannot_force_const_mem".  Actually, this kind of rtx can not
be put into a constant pool.  
So "cannot_force_const_mem" should return 'true' for them.

[Bug rtl-optimization/106460] New: internal compiler error: output_operand: invalid expression as operand on -O1

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

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

Bug ID: 106460
   Summary: internal compiler error: output_operand: invalid
expression as operand on -O1
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guojiufu at gcc dot gnu.org
  Target Milestone: ---

For code:

extern short var_48;
void
foo (double *r)
{
  if (var_48)
*r = 1234.5678;
}

On gcc trunk, using the below command, an ICE is raised:
> gcc -mcpu=power10 -O1 t.c

t.c:22:1: internal compiler error: output_operand: invalid expression as
operand
   22 | }
  | ^
0x10bdb24b output_operand_lossage(char const*, ...)
/home/guojiufu/gcc/gcc-mainline-base/gcc/final.cc:3234
0x10bdd2b7 output_addr_const(_IO_FILE*, rtx_def*)
/home/guojiufu/gcc/gcc-mainline-base/gcc/final.cc:3831
0x11a64e57 assemble_integer_with_op(char const*, rtx_def*)
/home/guojiufu/gcc/gcc-mainline-base/gcc/varasm.cc:2866
0x11a64f67 default_assemble_integer(rtx_def*, unsigned int, int)
/home/guojiufu/gcc/gcc-mainline-base/gcc/varasm.cc:2882
0x11b0343f rs6000_assemble_integer
/home/guojiufu/gcc/gcc-mainline-base/gcc/config/rs6000/rs6000.cc:14420
0x11a65063 assemble_integer(rtx_def*, unsigned int, unsigned int, int)
/home/guojiufu/gcc/gcc-mainline-base/gcc/varasm.cc:2898
0x11a6b727 output_constant_pool_2
/home/guojiufu/gcc/gcc-mainline-base/gcc/varasm.cc:4074
0x11a6c20b output_constant_pool_1
/home/guojiufu/gcc/gcc-mainline-base/gcc/varasm.cc:4191
0x11a6cd87 output_constant_pool_contents
/home/guojiufu/gcc/gcc-mainline-base/gcc/varasm.cc:4348
0x11a6d95b output_shared_constant_pool()
/home/guojiufu/gcc/gcc-mainline-base/gcc/varasm.cc:4546
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 target/106459] Compiler crashing for loongarch64-linux-gnu on windows

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

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

--- Comment #5 from Andrew Pinski  ---
It might also be:
#define IMM16_OPERAND(VALUE) \
  ((unsigned HOST_WIDE_INT) (VALUE) + 0x8000 < 0x1)

[Bug target/106459] Compiler crashing for loongarch64-linux-gnu on windows

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

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

--- Comment #4 from Andrew Pinski  ---
I suspect it is this macro which is causing the issue:
/* True if VALUE can be loaded into a register using LU12I.  */

#define LU12I_OPERAND(VALUE) \
  (((VALUE) | ((1UL << 31) - IMM_REACH)) == ((1UL << 31) - IMM_REACH) \
   || ((VALUE) | ((1UL << 31) - IMM_REACH)) + IMM_REACH == 0)

It should either use ULL or use HOST_WIDE_INT_1U instead of 1UL.

[Bug target/106459] Compiler crashing for loongarch64-linux-gnu on windows

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |target

--- Comment #3 from Andrew Pinski  ---
This is most likely a loongarch64 backend issue where it uses long instead of
host wide int for testing the value of a const_int.

[Bug c++/106459] Compiler crashing for loongarch64-linux-gnu on windows

[unlvsur at live dot com via Gcc-bugs]

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

cqwrteur  changed:

   What|Removed |Added

  Component|other   |c++

--- Comment #2 from cqwrteur  ---
I think it is the bug in the front end for windows that fails to create
temporary files.

[Bug other/106459] Compiler crashing for loongarch64-linux-gnu on windows

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
It does not crash on linux host but crash on windows host.

[Bug other/106459] New: Compiler crashing for loongarch64-linux-gnu on windows

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 106459
   Summary: Compiler crashing for loongarch64-linux-gnu on windows
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 53367
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53367=edit
preprocessor file

D:\hg\fast_io\.sha512>loongarch64-linux-gnu-g++ -S sha512.cc -Ofast -std=c++23
-I../include
In file included from ../include/fast_io_crypto/hash/sha512.h:183,
 from ../include/fast_io_crypto/hash/impl.h:6,
 from ../include/fast_io_crypto.h:25,
 from sha512.cc:1:
../include/fast_io_crypto/hash/sha512_scalar.h: In function 'void
fast_io::details::sha512::sha512_runtime_routine(uint_least64_t*, const
std::byte*, const std::byte*)':
../include/fast_io_crypto/hash/sha512_scalar.h:99:1: error: unrecognizable
insn:
   99 | }
  | ^
(insn 30 29 31 4 (set (reg:DI 1071)
(ior:DI (zero_extend:DI (subreg:SI (reg:DI 1071) 0))
(const_int 2867079648641024 [0xa2f98])))
"../include/fast_io_crypto/hash/sha512.h":90:5 -1
 (nil))
during RTL pass: vregs
../include/fast_io_crypto/hash/sha512_scalar.h:99:1: internal compiler error:
in extract_insn, at recog.cc:2791
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

D:\hg\fast_io\.sha512>loongarch64-linux-gnu-g++ -S sha512.cc -Ofast -std=c++23
-I../include -freport-bug
In file included from ../include/fast_io_crypto/hash/sha512.h:183,
 from ../include/fast_io_crypto/hash/impl.h:6,
 from ../include/fast_io_crypto.h:25,
 from sha512.cc:1:
../include/fast_io_crypto/hash/sha512_scalar.h: In function 'void
fast_io::details::sha512::sha512_runtime_routine(uint_least64_t*, const
std::byte*, const std::byte*)':
../include/fast_io_crypto/hash/sha512_scalar.h:99:1: error: unrecognizable
insn:
   99 | }
  | ^
(insn 30 29 31 4 (set (reg:DI 1071)
(ior:DI (zero_extend:DI (subreg:SI (reg:DI 1071) 0))
(const_int 2867079648641024 [0xa2f98])))
"../include/fast_io_crypto/hash/sha512.h":90:5 -1
 (nil))
during RTL pass: vregs
../include/fast_io_crypto/hash/sha512_scalar.h:99:1: internal compiler error:
in extract_insn, at recog.cc:2791
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source.
See  for instructions.
loongarch64-linux-gnu-g++: fatal error: cannot execute
'd:/x86_64-windows-gnu/loongarch64-linux-gnu/bin/../libexec/gcc/loongarch64-linux-gnu/13.0.0/cc1plus.exe':
open temporary output file
compilation terminated.

[Bug lto/106170] [13 Regression] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #17 from cqwrteur  ---
(In reply to Martin Liška from comment #15)
> Feel free to provide Windows implementation of the critical section.

case $target in
  riscv*)
# do not use locking as pthread depends on libatomic
;;
  *-linux*)
use_locking=yes
;;
esac


This should be $host, not $target

case $host in
  riscv*)
# do not use locking as pthread depends on libatomic
;;
  *-linux*)
use_locking=yes
;;
esac

[Bug lto/106170] [13 Regression] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #16 from cqwrteur  ---
(In reply to Martin Liška from comment #15)
> Feel free to provide Windows implementation of the critical section.

make[4]: Leaving directory
'/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/loongarch64-linux-gnu/gcc/gmp/doc'
/home/cqwrteur/toolchains/native/x86_64-w64-mingw32/lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/bin/ld:
cannot find -lpthread: No such file or directory
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:472: liblto_plugin.la] Error 1
make[3]: Leaving directory
'/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/loongarch64-linux-gnu/gcc/lto-plugin'
make[2]: *** [Makefile:383: all] Error 2
make[2]: Leaving directory
'/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/loongarch64-linux-gnu/gcc/lto-plugin'
make[1]: *** [Makefile:12790: all-lto-plugin] Error 2
make[1]: *** Waiting for unfinished jobs

It still has not yet fixed

[Bug analyzer/99860] RFE: analyzer does not respect "restrict"

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

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

--- Comment #2 from David Malcolm  ---
Quoting Paul Eggert here:
  https://lists.gnu.org/archive/html/bug-gnulib/2022-07/msg00066.html

> I looked into this a bit more, and it turns out that GCC was wrong
> about 
> what happens when some parameters have 'restrict' and others do not,
> and 
> this was partly because the C Standard itself is so opaque. (The GCC
> bug 
> has been fixed.)
> 
> In 2018 Troy Johnson and Bill Homer of Cray proposed[1] adding
> examples 
> to the C standard to try to make it clearer what happens when some 
> function parameters are 'restrict' and others are not. These examples
> have been added (with some changes) to section 6.7.3.1 of the current
> (June 2022) draft of the next C standard.[2] Perhaps they will help 
> explain things better.
> 
> The confusion in this obscure area for so many years suggests that 
> Gnulib would be better off following the lead of POSIX and the C 
> standard, by using 'restrict' on all relevant parameters rather than 
> trying to be clever and use 'restrict' with only some parameters. 
> Although omitting some 'restrict's shortens the code, it complicates 
> analysis (for both humans and compilers) so much that it's more
> trouble 
> than its worth.
> 
> [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2260.pdf
> [2] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2912.pdf
>

[Bug c++/106430] [modules] ICE on function result of imported type with user-declared constexpr SMF

[johelegp at gmail dot com via Gcc-bugs]

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

Johel Ernesto Guerrero Peña  changed:

   What|Removed |Added

Summary|[modules] ICE on function   |[modules] ICE on function
   |result of imported type |result of imported type
   |with user-declared  |with user-declared
   |constexpr destructor|constexpr SMF

--- Comment #1 from Johel Ernesto Guerrero Peña  ---
See https://godbolt.org/z/T8591z1nT with copy constructor:

`mod.cpp`:
```C++
export module mod;

export struct X {
  bool b = true;
  X() = default;
  constexpr X(const X&) { }
};

export constexpr X id(X x) { return x; }
```

`test.cpp`:
```C++
import mod;
static_assert(id(X{}).b);
int main() { }
```

Output:
```
test.cpp:2:25:   in 'constexpr' expansion of 'id@mod(X@mod)()'
test.cpp:2:25: internal compiler error: in cxx_eval_call_expression, at
cp/constexpr.cc:2850
2 | static_assert(id(X{}).b);
  | ^
0x230869e internal_error(char const*, ...)
???:0
0xa90716 fancy_abort(char const*, int, char const*)
???:0
0xaf60ac maybe_constant_value(tree_node*, tree_node*, bool)
???:0
0xce6baf finish_static_assert(tree_node*, tree_node*, unsigned int, bool, bool)
???:0
0xc66a77 c_parse_file()
???:0
0xda0269 c_common_parse_file()
???:0
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 analyzer/105285] False positive with -Wanalyzer-null-dereference in git.git's reftable/reader.c

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #14 from David Malcolm  ---
(In reply to David Malcolm from comment #11)
> Should be fixed on trunk for GCC 13 by the above commit.
> 
> I hope to backport this to GCC 12; keeping this open until that's done.

Backported to GCC 12 (for 12.2), so marking this as resolved.

[Bug analyzer/106358] [meta-bug] tracker bug for building the Linux kernel with -fanalyzer

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

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

Bug 106204 Summary: False positive from -Wanalyzer-use-of-uninitialized-value 
with -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106204

   What|Removed |Added

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

[Bug analyzer/106204] False positive from -Wanalyzer-use-of-uninitialized-value with -ftrivial-auto-var-init=zero

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #6 from David Malcolm  ---
Backported to gcc 12, so marking as resolved.

[Bug analyzer/106358] [meta-bug] tracker bug for building the Linux kernel with -fanalyzer

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

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

Bug 106225 Summary: False positives from -Wanalyzer-tainted-divisor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106225

   What|Removed |Added

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

[Bug analyzer/106225] False positives from -Wanalyzer-tainted-divisor

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Backported to gcc 12, so marking as resolved.

[Bug analyzer/106225] False positives from -Wanalyzer-tainted-divisor

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:71a4f739c218746df70612eeb844024d1fe206bb

commit r12-8638-g71a4f739c218746df70612eeb844024d1fe206bb
Author: David Malcolm 
Date:   Wed Jul 27 17:38:55 2022 -0400

analyzer: fix false positives from -Wanalyzer-tainted-divisor [PR106225]

(cherry picked from r13-1562-g897b3b31f0a94b)

gcc/analyzer/ChangeLog:
PR analyzer/106225
* sm-taint.cc (taint_state_machine::on_stmt): Move handling of
assignments from division to...
(taint_state_machine::check_for_tainted_divisor): ...this new
function.  Reject warning when the divisor is known to be non-zero.
* sm.cc: Include "analyzer/program-state.h".
(sm_context::get_old_region_model): New.
* sm.h (sm_context::get_old_region_model): New decl.

gcc/testsuite/ChangeLog:
PR analyzer/106225
* gcc.dg/analyzer/taint-divisor-1.c: Add test coverage for various
correct and incorrect checks against zero.

Signed-off-by: David Malcolm 

[Bug analyzer/106204] False positive from -Wanalyzer-use-of-uninitialized-value with -ftrivial-auto-var-init=zero

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:09cb9c88ef8e2c0c89ada9cde2caf1a960db7a77

commit r12-8637-g09cb9c88ef8e2c0c89ada9cde2caf1a960db7a77
Author: David Malcolm 
Date:   Wed Jul 27 17:38:55 2022 -0400

analyzer: fix uninit false positive with -ftrivial-auto-var-init=
[PR106204]

(cherry picked from r13-1517-gb33dd7874523af)

-fanalyzer handles -ftrivial-auto-var-init= by special-casing
IFN_DEFERRED_INIT to be a no-op, so that e.g.:

  len_2 = .DEFERRED_INIT (4, 2, &"len"[0]);

is treated as a no-op, so that len_2 is still uninitialized after the
stmt.

PR analyzer/106204 reports that -fanalyzer gives false positives from
-Wanalyzer-use-of-uninitialized-value on locals that have their address
taken, due to e.g.:

  _1 = .DEFERRED_INIT (4, 2, &"len"[0]);
  len = _1;

where -fanalyzer leaves _1 uninitialized, and then complains about
the assignment to "len".

Fixed thusly by suppressing the warning when assigning from such SSA
names.

gcc/analyzer/ChangeLog:
PR analyzer/106204
* region-model.cc (within_short_circuited_stmt_p): Move extraction
of assign_stmt to caller.
(due_to_ifn_deferred_init_p): New.
(region_model::check_for_poison): Move extraction of assign_stmt
from within_short_circuited_stmt_p to here.  Share logic with
call to due_to_ifn_deferred_init_p.

gcc/testsuite/ChangeLog:
PR analyzer/106204
* gcc.dg/analyzer/torture/uninit-pr106204.c: New test.
* gcc.dg/analyzer/uninit-pr106204.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/105285] False positive with -Wanalyzer-null-dereference in git.git's reftable/reader.c

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:05530fcea07a9ee5c7501867f3f11f0fbc504a06

commit r12-8632-g05530fcea07a9ee5c7501867f3f11f0fbc504a06
Author: David Malcolm 
Date:   Wed Jul 27 17:38:53 2022 -0400

analyzer: handle repeated accesses after init of unknown size [PR105285]

(cherry-picked from r13-7-g00c4405cd7f6a144d0a439e4d848d246920e6ff3)

PR analyzer/105285 reports a false positive from
-Wanalyzer-null-dereference on git.git's reftable/reader.c.

A reduced version of the problem can be seen in test_1a of
gcc.dg/analyzer/symbolic-12.c in the following:

void test_1a (void *p, unsigned next_off)
{
  struct st_1 *r = p;

  external_fn();

  if (next_off >= r->size)
return;

  if (next_off >= r->size)
/* We should have already returned if this is the case.  */
__analyzer_dump_path (); /* { dg-bogus "path" } */
}

where the analyzer erroneously considers this path, where
(next_off >= r->size) is both false and then true:

symbolic-12.c: In function âtest_1aâ:
symbolic-12.c:22:5: note: path
   22 | __analyzer_dump_path (); /* { dg-bogus "path" } */
  | ^~~
  âtest_1aâ: events 1-5
|
|   17 |   if (next_off >= r->size)
|  |  ^
|  |  |
|  |  (1) following âfalseâ branch...
|..
|   20 |   if (next_off >= r->size)
|  |  ~~~~
|  |  | |
|  |  | (2) ...to here
|  |  (3) following âtrueâ branch...
|   21 | /* We should have already returned if this is the case. 
*/
|   22 | __analyzer_dump_path (); /* { dg-bogus "path" } */
|  | ~~~
|  | |
|  | (4) ...to here
|  | (5) here
|

The root cause is that, at the call to the external function, the
analyzer considers the cluster for *p to have been touched, binding it
to a conjured_svalue, but because p is void * no particular size is
known for the write, and so the cluster is bound using a symbolic key
covering the base region.  Later, the accesses to r->size are handled by
binding_cluster::get_any_binding, but binding_cluster::get_binding fails
to find a match for the concrete field lookup, due to the key for the
binding being symbolic, and reaching this code:

1522  /* If this cluster has been touched by a symbolic write, then the
content
1523 of any subregion not currently specifically bound is "UNKNOWN". 
*/
1524  if (m_touched)
1525{
1526  region_model_manager *rmm_mgr = mgr->get_svalue_manager ();
1527  return rmm_mgr->get_or_create_unknown_svalue (reg->get_type ());
1528}

Hence each access to r->size is an unknown svalue, and thus the
condition (next_off >= r->size) isn't tracked, leading to the path with
contradictory conditions being treated as satisfiable.

In the original reproducer in git's reftable/reader.c, the call to the
external fn is:
  reftable_record_type(rec)
which is considered to possibly write to *rec, which is *tab, where tab
is the void * argument to reftable_reader_seek_void, and thus after the
call to reftable_record_type some arbitrary amount of *rec could have
been written to.

This patch fixes things by detecting the "this cluster has been 'filled'
with a conjured value of unknown size" case, and handling
get_any_binding on it by returning a sub_svalue of the conjured_svalue,
so that repeated accesses to r->size give the same symbolic value, so
that the constraint manager rejects the bogus execution path, fixing the
false positive.

gcc/analyzer/ChangeLog:
PR analyzer/105285
* store.cc (binding_cluster::get_any_binding): Handle accessing
sub_svalues of clusters where the base region has a symbolic
binding.

gcc/testsuite/ChangeLog:
PR analyzer/105285
* gcc.dg/analyzer/symbolic-12.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/105285] False positive with -Wanalyzer-null-dereference in git.git's reftable/reader.c

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:1321183a13540b5c3503586b94c758198471c7b3

commit r12-8631-g1321183a13540b5c3503586b94c758198471c7b3
Author: David Malcolm 
Date:   Wed Jul 27 17:38:53 2022 -0400

analyzer: add .fpath.txt dumps to -fdump-analyzer-feasibility

(cherry picked from r13-6-gd8586b00dd00a1783862da5f0c8811a740400074)

I found this extension to -fdump-analyzer-feasibility very helpful when
debugging PR analyzer/105285.

gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (epath_finder::process_worklist_item):
Call dump_feasible_path when a path that reaches the the target
enode is found.
(epath_finder::dump_feasible_path): New.
* engine.cc (feasibility_state::dump_to_pp): New.
* exploded-graph.h (feasibility_state::dump_to_pp): New decl.
* feasible-graph.cc (feasible_graph::dump_feasible_path): New.
* feasible-graph.h (feasible_graph::dump_feasible_path): New
decls.
* program-point.cc (function_point::print): Fix missing trailing
newlines.
* program-point.h (program_point::print_source_line): Remove
unimplemented decl.

gcc/ChangeLog:
* doc/invoke.texi (-fdump-analyzer-feasibility): Mention the
fpath.txt output.

Signed-off-by: David Malcolm 

[Bug c++/105842] rejects-valid: static member function overload set constrained by concepts for class template results in ambiguous call

[joeloser at fastmail dot com via Gcc-bugs]

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

--- Comment #6 from Joe Loser  ---
(In reply to Patrick Palka from comment #5)
> Fixed for GCC 12.2/13

Thanks for the fix, Patrick!

[Bug c/106416] -Wint-conversion should be an error, not a pedwarn

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Yes, definitely in the same category.

[Bug target/106458] [12 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12

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

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

--- Comment #3 from John David Anglin  ---
Created attachment 53366
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53366=edit
.s file generated with gcc-12

[Bug target/106458] [12 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12

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

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

--- Comment #2 from John David Anglin  ---
Created attachment 53365
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53365=edit
.s file generated with gcc-11

[Bug target/106458] [12 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12

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

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

--- Comment #1 from John David Anglin  ---
Created attachment 53364
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53364=edit
.i file

[Bug target/106458] New: [12 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12

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

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

Bug ID: 106458
   Summary: [12 Regression] glibc's malloc/tst-scratch_buffer.c
test is miscompiled with gcc-12
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 53363
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53363=edit
.c file

dave@atlas:~/gnu/glibc/objdir$ make test t=malloc/tst-scratch_buffer
make -r PARALLELMFLAGS="" -C ../glibc objdir=`pwd` test
make[1]: Entering directory '/home/dave/gnu/glibc/glibc'
make subdir=malloc -C malloc/ ..=../
/home/dave/gnu/glibc/objdir/malloc/tst-scratch_buffer.out
make[2]: Entering directory '/home/dave/gnu/glibc/glibc/malloc'
gcc tst-scratch_buffer.c -c -std=gnu11 -fgnu89-inline  -g -O2 -Wall
-Wwrite-strings -Wundef -Werror -fmerge-all-constants -frounding-math
-fno-stack-protector -fno-common -Wstrict-prototypes -Wold-style-definition
-fmath-errno-fno-pie -I../include
-I/home/dave/gnu/glibc/objdir/malloc  -I/home/dave/gnu/glibc/objdir 
-I../sysdeps/unix/sysv/linux/hppa  -I../sysdeps/hppa/nptl 
-I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux 
-I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu 
-I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix 
-I../sysdeps/posix  -I../sysdeps/hppa/hppa1.1  -I../sysdeps/wordsize-32 
-I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/hppa/fpu
 -I../sysdeps/hppa  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio
-I. -nostdinc -isystem /usr/lib/gcc/hppa-linux-gnu/12/include -isystem
/usr/include -D_LIBC_REENTRANT -include
/home/dave/gnu/glibc/objdir/libc-modules.h -DMODULE_NAME=testsuite_internal
-include ../include/libc-symbols.h   -DTOP_NAMESPACE=glibc -o
/home/dave/gnu/glibc/objdir/malloc/tst-scratch_buffer.o -MD -MP -MF
/home/dave/gnu/glibc/objdir/malloc/tst-scratch_buffer.o.dt -MT
/home/dave/gnu/glibc/objdir/malloc/tst-scratch_buffer.o
gcc -o /home/dave/gnu/glibc/objdir/malloc/tst-scratch_buffer -nostdlib
-nostartfiles -Wl,-z,relro  /home/dave/gnu/glibc/objdir/csu/crt1.o
/home/dave/gnu/glibc/objdir/csu/crti.o `gcc  --print-file-name=crtbegin.o`
/home/dave/gnu/glibc/objdir/malloc/tst-scratch_buffer.o
/home/dave/gnu/glibc/objdir/support/libsupport_nonshared.a 
-Wl,-dynamic-linker=/lib/ld.so.1
-Wl,-rpath-link=/home/dave/gnu/glibc/objdir:/home/dave/gnu/glibc/objdir/math:/home/dave/gnu/glibc/objdir/elf:/home/dave/gnu/glibc/objdir/dlfcn:/home/dave/gnu/glibc/objdir/nss:/home/dave/gnu/glibc/objdir/nis:/home/dave/gnu/glibc/objdir/rt:/home/dave/gnu/glibc/objdir/resolv:/home/dave/gnu/glibc/objdir/mathvec:/home/dave/gnu/glibc/objdir/support:/home/dave/gnu/glibc/objdir/crypt:/home/dave/gnu/glibc/objdir/nptl
-lgcc -Wl,--as-needed -lgcc_s  -Wl,--no-as-needed
/home/dave/gnu/glibc/objdir/libc.so.6
/home/dave/gnu/glibc/objdir/libc_nonshared.a -Wl,--as-needed
/home/dave/gnu/glibc/objdir/elf/ld.so -Wl,--no-as-needed -lgcc -Wl,--as-needed
-lgcc_s  -Wl,--no-as-needed `gcc  --print-file-name=crtend.o`
/home/dave/gnu/glibc/objdir/csu/crtn.o
env GCONV_PATH=/home/dave/gnu/glibc/objdir/iconvdata
LOCPATH=/home/dave/gnu/glibc/objdir/localedata LC_ALL=C  
/home/dave/gnu/glibc/objdir/elf/ld.so.1 --library-path
/home/dave/gnu/glibc/objdir:/home/dave/gnu/glibc/objdir/math:/home/dave/gnu/glibc/objdir/elf:/home/dave/gnu/glibc/objdir/dlfcn:/home/dave/gnu/glibc/objdir/nss:/home/dave/gnu/glibc/objdir/nis:/home/dave/gnu/glibc/objdir/rt:/home/dave/gnu/glibc/objdir/resolv:/home/dave/gnu/glibc/objdir/mathvec:/home/dave/gnu/glibc/objdir/support:/home/dave/gnu/glibc/objdir/crypt:/home/dave/gnu/glibc/objdir/nptl
/home/dave/gnu/glibc/objdir/malloc/tst-scratch_buffer  >
/home/dave/gnu/glibc/objdir/malloc/tst-scratch_buffer.out; \
../scripts/evaluate-test.sh malloc/tst-scratch_buffer $? false false >
/home/dave/gnu/glibc/objdir/malloc/tst-scratch_buffer.test-result
make[2]: Leaving directory '/home/dave/gnu/glibc/glibc/malloc'
FAIL: malloc/tst-scratch_buffer
original exit status 1
tst-scratch_buffer.c:167: error: blob comparison failed
  blob length: 1040 bytes
  left (evaluated from r):
 

[Bug tree-optimization/106457] New: array_at_struct_end_p returns TRUE for a two-dimension array which is not inside any structure

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

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

Bug ID: 106457
   Summary: array_at_struct_end_p returns TRUE for a two-dimension
array which is not inside any structure
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

During my work on updating array_at_struct_end_p with the new
-fstrict-flex-array control, I noticed the following issue in the routine
"array_at_struct_end_p" for the following small testing case:
gcc/testsuite/g++.dg/debug/debug5.C

// { dg-do compile }
// { dg-require-effective-target alloca }

int foo()
{
  int a = 1;
  int b = 1;
  int e[a][b];
  e[0][0] = 0;
  return e[a-1][b-1];
}


when compiled with -O1 with the latest trunk gcc, when I used the gdb to debug
it as:

(gdb) break array_at_struct_end_p
Breakpoint 1 at 0x1d4cdf8: file ../../latest_gcc/gcc/tree.cc, line 12690.
(gdb) run
Starting program: /home/opc/Work/GCC/build/gcc/cc1plus -quiet -iprefix
/home/opc/Work/GCC/build/gcc/../lib/gcc/aarch64-unknown-linux-gnu/13.0.0/
-isystem /home/opc/Work/GCC/build/gcc/testsuite/g++/../../include -isystem
/home/opc/Work/GCC/build/gcc/testsuite/g++/../../include-fixed -D_GNU_SOURCE
t.C -quiet -dumpbase debug5.C -dumpbase-ext .C -mlittle-endian -mabi=lp64 -O1
-o debug5.s
...

Breakpoint 1, array_at_struct_end_p (ref=0xf57a2b88) at
../../latest_gcc/gcc/tree.cc:12690
12690 if (TREE_CODE (ref) == ARRAY_REF
...
(gdb) break 12784
Breakpoint 2 at 0x1d4d50c: file ../../latest_gcc/gcc/tree.cc, line 12784.
(gdb) c
Continuing.

Breakpoint 2, array_at_struct_end_p (ref=0xf5771a70) at
../../latest_gcc/gcc/tree.cc:12784
12784 if (TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (atype))) != INTEGER_CST
(gdb) n
12786 || TREE_CODE (TYPE_MIN_VALUE (TYPE_DOMAIN (atype))) !=
INTEGER_CST)
(gdb) n
12784 if (TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (atype))) != INTEGER_CST
(gdb) n
12787   return true;
(gdb) n
12803   }

it's obvious that the array reference " e[0][0]" is NOT an array at the end of
a structure. 

the utility routine "array_at_struct_end_p" should NOT result true for such
array reference.

We should fix this issue in this routine.

[Bug target/106415] loop-ivopts prevents correct usage of dbra with 16-bit loop counters on m68k

[undefinedopcode2 at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Undefined Opcode  ---
(In reply to Kewen Lin from comment #5)
> At the top of tree-ssa-loop-ivopts.cc file, there are some useful comments
> describing the costs for iv candidate itself and group, it may help.
> 
> :
>   cand  cost
>   0 5
>   1 5
>   2 5
>   3 4
>   4 5
>   5 5
>   6 5
>   7 5
>   8 5
> 
> This part is for "variable costs".
> 
> :
> Group 0:
>   candcostcompl.  inv.expr.   inv.vars
>   0   400 0   NIL;NIL;
>   7   0   0   NIL;NIL;
>   8   400 0   NIL;NIL;
> 
> This part is for "group/use costs".
> 
> There would be no dumping for a candidate when it has infinite cost for the
> group, so the above means only candidate 0, 7 and 8 are valid to be used for
> group 0.
> 
> Final cost looks like:
> 
> cost: 7 (complexity 0)
> reg_cost: 2
> cand_cost: 5
> cand_group_cost: 0 (complexity 0)
> candidates: 7
>  group:0 --> iv_cand:7, cost=(0,0)
>  group:1 --> iv_cand:7, cost=(0,0)
> invariant variables:
> invariant expressions:
> 
> 
> 
> By quick checking, it looks the inf cost for the pair (cand 3, group 0) is
> due to:
> 
>   /* Check if we have enough precision to express the values of use.  */
>   if (TYPE_PRECISION (utype) > TYPE_PRECISION (ctype))
> return infinite_cost;

Some debug prints confirm this is indeed what's happening, the pass thinks
candidate 3 is trying to fit a 32-bit value into 16-bits and bails. What's not
clear to me is why. Does it have some notion of -1 requiring 32-bits to store
even though it'll fit just fine in 16 for our purposes?

[Bug target/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)

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

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

--- Comment #37 from Iain Sandoe  ---
(In reply to Eric Gallager from comment #36)
> Note that the solution to this has caused downstream MacPorts bug 65236:
> https://trac.macports.org/ticket/65236

the macports ticket does not contain enough information to figure out the
problem ... 

I build and test regularly on Darwin9-21 and have used a range of installed
Xcode CLT:

e.g. here's the latest I have:

gcc/as -arch x86_64 -v -mmacosx-version-min=12.0 -mllvm
-x86-pad-for-align=false -force_cpusubtype_ALL -o /Volumes/ramdisk/ccuqyehz.o
/Volumes/ramdisk/ccN3ilQO.s
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Users/Shared/XC/13.4/CommandLineTools/usr/bin
 "/Users/Shared/XC/13.4/CommandLineTools/usr/bin/clang" -cc1as -triple
x86_64-apple-macosx12.0.0 -filetype obj -main-file-name ccN3ilQO.s -target-cpu
penryn -fdebug-compilation-dir=/scratch/12-mon/gcc-master -dwarf-debug-producer
"Apple clang version 13.1.6 (clang-1316.0.21.2.5)" -dwarf-version=4
-mrelocation-model pic --mrelax-relocations -mllvm -x86-pad-for-align=false
-mllvm -disable-aligned-alloc-awareness=1 -o /Volumes/ramdisk/ccuqyehz.o
/Volumes/ramdisk/ccN3ilQO.s

works fine (i.e the assembler is accepting the flag) .. so I am not sure where
the problem is arising in the bias stuff.

Perhaps, by some strange mechanism, the cctools assembler is being invoked ?

[Bug analyzer/106298] RFE: analyzer handling of dup, dup2, and dup3

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

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

David Malcolm  changed:

   What|Removed |Added

   Last reconfirmed||2022-07-27
   Assignee|dmalcolm at gcc dot gnu.org|mir at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from David Malcolm  ---
Immad's looking at this one.

[Bug target/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)

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

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

--- Comment #36 from Eric Gallager  ---
Note that the solution to this has caused downstream MacPorts bug 65236:
https://trac.macports.org/ticket/65236

[Bug c++/46476] Missing Warning about unreachable code after return [-Wunreachable-code-return]

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

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

--- Comment #30 from Andrew Pinski  ---
*** Bug 106456 has been marked as a duplicate of this bug. ***

[Bug c/106456] -Wunreachable-code seems very broken

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 46476.

-Wunreachable-code was removed a long time ago (over 12 years ago) because of
all of the false positives it was generating.

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

[Bug c/106456] -Wunreachable-code seems very broken

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

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

--- Comment #1 from Andrew Pinski  ---
Wunreachable-code
Common Ignore Warning
Does nothing. Preserved for backward compatibility.

[Bug c++/106448] [OpenMP] atomic compare – g++ wrongly accepts parenthesized condition

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

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

--- Comment #2 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #1)
> is incorrectly accepted in C and rejected in C++.

I mean is correctly rejected in C++.

[Bug c++/106448] [OpenMP] atomic compare – g++ wrongly accepts parenthesized condition

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

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

--- Comment #1 from Jakub Jelinek  ---
int x;

void
bar (void)
{
  #pragma omp atomic
  x = (x + 6);
  #pragma omp atomic
  x = (x * 6);
}

is incorrectly accepted in C and rejected in C++.

[Bug c/91093] Error on implicit int by default

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

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

--- Comment #2 from Florian Weimer  ---
It seems that

auto x = 1.0;

will change meaning in C2X (as implemented by GCC) and use type double instead
of int for x. We are probably way too late to fix this (by rejecting the
construct in earlier language modes) before C2X support arrives in GCC.

This may require the same careful treatment as bug 91092 and bug 106416.

[Bug c/106416] -Wint-conversion should be an error, not a pedwarn

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

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #1 from Florian Weimer  ---
This will likely need the same preparatory treatment as rejecting implicit
function declarations (bug 91092), for the same reason: Without some care
upfront, introducing the new compiler error will change configure test results
in fully consistent ways, resulting in silently dropped features.

[Bug middle-end/106449] ICE in #pragma omp parallel for simd since r6-4544-ge01d41e553aae245

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

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

--- Comment #7 from Tobias Burnus  ---
Comment on attachment 53362
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53362
gcc13-pr106449.patch

The code does not seem to work. If I add:

void foobar(int *a, int*b) {
  __builtin_printf("%lu\n", b-a);
}

and use it in place for the ';' in the loops, when then calling
  foo();
  bar(64, 128);

While foo() with and without OpenMP and - with -fno-openmp - also bar(64,128)
give all identical result. But -fopenmp, 'bar' does not call 'foobar' at all
(no printf output).

[Bug c/106455] bad style: comparatives over booleans ?

[schwab--- via Gcc-bugs]

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

--- Comment #4 from Andreas Schwab  ---
bool > bool is evaluated as (int)bool > (int)bool.

[Bug c/106455] bad style: comparatives over booleans ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
(In reply to Andrew Pinski from comment #1)
> bool > bool works just fine and is exactly what we want to test here.

Confused. So is false > true or true > false ?

[Bug c/106455] bad style: comparatives over booleans ?

[schwab--- via Gcc-bugs]

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

--- Comment #2 from Andreas Schwab  ---
negative && !other_negative is definitely easier to understand than negative >
other_negative.  In fact, given the condition negative != other_negative,
negative already implies !other_negative, so this can be simplified to just if
(negative != other_negative) return negative.

[Bug c/106455] bad style: comparatives over booleans ?

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This is not bad style at all.

bool > bool works just fine and is exactly what we want to test here.
Basically it means

negative && !other_negative

[Bug middle-end/106449] ICE in #pragma omp parallel for simd since r6-4544-ge01d41e553aae245

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

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

--- Comment #6 from Tobias Burnus  ---
Comment on attachment 53362
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53362
gcc13-pr106449.patch

> +   t = fold_convert (sizetype, fd->loops[i + 1].n1);
> +   t = fold_build_pointer_plus (t2, t);

I think the first line is not needed, given that fold_build_pointer_plus_loc
has:

  return fold_build2_loc (loc, POINTER_PLUS_EXPR, TREE_TYPE (ptr),
  ptr, convert_to_ptrofftype_loc (loc, off));

and the convert_to_ptrofftype_loc does:

  if (ptrofftype_p (TREE_TYPE (off)))
return off;
  return fold_convert_loc (loc, sizetype, off);

where the last line matches your first line. Hence, just calling

  t = fold_build_pointer_plus (t2, fd->loops[i + 1].n1);

should gives the same result and is more compact (avoids a line and a
2-character indent).

[Bug c/106456] New: -Wunreachable-code seems very broken

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 106456
   Summary: -Wunreachable-code seems very broken
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

I tried out this simple example:

extern void g( int);

int f( int a)
{
return 2 * a;
g( a);
}

gcc doesn't seem able to find the problem:

$ /home/dcb/gcc/results/bin/g++ -c -g -O2 -Wall -Wextra -Wunreachable-code
jul27d.cc
$

clang++ can:

$ clang++ -c -g -O2 -Wall -Wextra -Wunreachable-code jul27d.cc
jul27d.cc:7:2: warning: code will never be executed [-Wunreachable-code]
g( a);
^
1 warning generated.
$

Following on from this, there are a couple of examples in the gcc source code:

trunk.git/gcc/value-range-storage.h:149:3: style: Statements following return,
break, continue, goto or throw will never be executed. [unreachableCode]
trunk.git/gcc/value-range-storage.h:210:3: style: Statements following return,
break, continue, goto or throw will never be executed. [unreachableCode]

[Bug c/106455] New: bad style: comparatives over booleans ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 106455
   Summary: bad style: comparatives over booleans ?
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Static analyser cppcheck says for recent gcc trunk:

trunk.git/gcc/sreal.h:72:25: style: Comparison of a variable having boolean
value using relational (<, >, <= or >=) operator.
[comparisonOfBoolWithBoolError]

Source code is

  bool negative = m_sig < 0;
  bool other_negative = other.m_sig < 0;

  if (negative != other_negative)
return negative > other_negative;

I agree - this looks bad style to me. I don't think > should work on booleans.

[Bug middle-end/106449] ICE in #pragma omp parallel for simd since r6-4544-ge01d41e553aae245

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

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

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

Untested fix.

[Bug analyzer/106003] RFE: -fanalyzer could complain about misuse of file-descriptors

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

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

Bug 106286 Summary: fd_diagnostic should implement get_meaning_for_state_change 
vfunc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106286

   What|Removed |Added

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

[Bug analyzer/106286] fd_diagnostic should implement get_meaning_for_state_change vfunc

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

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

Immad Mir  changed:

   What|Removed |Added

 CC||mir at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Immad Mir  ---
Issue resolved.

[Bug analyzer/106286] fd_diagnostic should implement get_meaning_for_state_change vfunc

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Immad Mir :

https://gcc.gnu.org/g:0f82c0ea8d86ee3bb404c460a04ff2ccfb56d2a0

commit r13-1860-g0f82c0ea8d86ee3bb404c460a04ff2ccfb56d2a0
Author: Immad Mir 
Date:   Wed Jul 27 19:16:36 2022 +0530

analyzer: add get_meaning_for_state_change vfunc to fd_diagnostic in
sm-fd.cc [PR106286]

This patch adds get_meaning_for_state_change vfunc to
fd_diagnostic in sm-fd.cc which could be used by SARIF output.

Lightly tested on x86_64 Linux.

gcc/analyzer/ChangeLog:
PR analyzer/106286
* sm-fd.cc:
(fd_diagnostic::get_meaning_for_state_change): New.

gcc/testsuite/ChangeLog:
PR analyzer/106286
* gcc.dg/analyzer/fd-meaning.c: New test.

Signed-off-by: Immad Mir 

[Bug rtl-optimization/106419] ICE in lra_assign, at lra-assigns.cc:1649

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

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

--- Comment #10 from Segher Boessenkool  ---
(In reply to Kewen Lin from comment #9)
> (In reply to Segher Boessenkool from comment #8)
> > So for which pseudo and which hard register did this ICE, and what did the
> > code look like at that point?
> 
> The culprit pseudo is r133, the values of those related expressions in the
> check:
> 
> lra_reg_info[i].nrefs  -> 4
> 
> reg_renumber[i] -> 97
> 
> overlaps_hard_reg_set_p(lra_reg_info[i].conflict_hard_regs, E_SImode, 97) ->
> true
> 
> Before IRA, the code looks like:

> (insn 34 33 35 4 (set (reg:SI 97 ctr)
> (reg/v/f:SI 133 [ foo ])) "test.f":17:72 562 {*movsi_internal1}
>  (nil))  

> in IRA, the hard reg assignment is:

> choosing r3 for r133.

Doing ctr (reg 97) instead (as LRA seems to change it to?) is
counterproductive.

We have that

> (insn 33 32 34 4 (set (reg:SI 3 3)
> (reg/v/f:SI 137 [ g ])) "test.f":17:72 562 {*movsi_internal1}
>  (nil))

right before 34, so if we want to use hard reg 3 for pseudo 97 we could
swap insns 33 and 34 (both of which are trivial assignments), much nicer
than the current dance via memory.

But all of this is a distraction from the actual bug here, sorry.

[Bug rtl-optimization/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

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

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

--- Comment #47 from Richard Earnshaw  ---
Created attachment 53361
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53361=edit
Possible patch

A slightly more thorough attempt to avoid the problem by detecting when the
alias sets are known to conflict.  We track through the list of same values
that CSELIB has recorded to find one that writes the same location (because the
addresses are considered equal).

[Bug analyzer/106454] -Wanalyzer-malloc-leak false positive when returning heap-allocation through array in struct after function call

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

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

--- Comment #2 from David Malcolm  ---
...i.e. it's getting confused about liveness.  It's considering that the call
to c could have overwritten the old value of d with a new value (or d->args),
and thus that this hypothetical new value of d->args[0] could cease to be live
at function exit.  Which seems like a false positive to me.

[Bug analyzer/106454] -Wanalyzer-malloc-leak false positive when returning heap-allocation through array in struct after function call

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #1 from David Malcolm  ---
Thanks for filing this bug.

Confirmed on trunk, and with gcc 12.1, gcc 11.3, and gcc 10.4

Compiler Explorer link:
  https://godbolt.org/z/ja681nMe3

Adding __analyzer_dump (); after the malloc shows:

rmodel:
stack depth: 1
  frame (index 0): frame: 'foo'@1
clusters within root region
  cluster for: (*INIT_VAL(d_5(D))): UNKNOWN(struct a) (ESCAPED) (TOUCHED)
  cluster for: (*SUB(CONJURED(c ();, (*INIT_VAL(d_5(D,
(*INIT_VAL(d_5(D))).args)): _ALLOCATED_REGION(14)
m_called_unknown_fn: TRUE
constraint_manager:
  equiv classes:
ec0: {(void *)0B == [m_constant]'0B'}
ec1: {INIT_VAL(d_5(D))}
ec2: {SUB(CONJURED(c ();, (*INIT_VAL(d_5(D, (*INIT_VAL(d_5(D))).args)}
  constraints:
0: ec1: {INIT_VAL(d_5(D))} != ec0: {(void *)0B == [m_constant]'0B'}
1: ec2: {SUB(CONJURED(c ();, (*INIT_VAL(d_5(D,
(*INIT_VAL(d_5(D))).args)} != ec0: {(void *)0B == [m_constant]'0B'}

[Bug middle-end/106449] ICE in #pragma omp parallel for simd since r6-4544-ge01d41e553aae245

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug target/106450] [13 Regression] ICE in final_scan_insn_1, at final.cc:2860 (error: could not split insn) since r13-1607-gc3ed9e0d6e96d869

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com

--- Comment #3 from Roger Sayle  ---
I'm bootstrapping and regression testing a fix now.

[Bug middle-end/106449] ICE in #pragma omp parallel for simd since r6-4544-ge01d41e553aae245

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

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

--- Comment #4 from Jakub Jelinek  ---
void
foo (void)
{
  int a[1024];
  int *p, *q;
  #pragma omp simd collapse(2)
  for (p = [0]; p < [512]; p++)
for (q = p + 64; q < p + 128; q++)
  ;
}

is enough to reproduce it.

[Bug debug/106261] [10/11/12 Regression] ICE in output_call_frame_info, at dwarf2out.cc:943

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11/12/13 Regression]|[10/11/12 Regression] ICE
   |ICE in  |in output_call_frame_info,
   |output_call_frame_info, at  |at dwarf2out.cc:943
   |dwarf2out.cc:943|

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug middle-end/106332] Possible out of bound buffer access in opts-common.c

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Assert added.  Closing as INVALID because it wasn't really a bug.

[Bug analyzer/106454] New: -Wanalyzer-malloc-leak false positive when returning heap-allocation through array in struct after function call

[raimue at codingfarm dot de via Gcc-bugs]

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

Bug ID: 106454
   Summary: -Wanalyzer-malloc-leak false positive when returning
heap-allocation through array in struct after function
call
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: raimue at codingfarm dot de
  Target Milestone: ---

Here is the most minimal test case I could come up with to trigger a
false-positive in -fanalyzer.

Source:

#include 

void c(void);

struct a { 
  char **args;
};

void foo(struct a *d) {
  c();
  d->args[0] = malloc(42);
}


Compiler output:

$ gcc-12 -Wall -fanalyzer -c -o foo.o foo.c
foo.c: In function 'foo':
foo.c:12:1: warning: leak of 'malloc(42)' [CWE-401] [-Wanalyzer-malloc-leak]
   12 | }
  | ^
  'foo': events 1-2
|
|   11 |   d->args[0] = malloc(42);
|  |^~
|  ||
|  |(1) allocated here
|   12 | }
|  | ~   
|  | |
|  | (2) 'malloc(42)' leaks here; was allocated at (1)
|


Notes:

The warning no longer triggers if I either remove the function call to c()
completely or move the function call to c() after the assignment.


This was discovered with GCC 12.0.1 on Ubuntu 22.04:
$ gcc-12 --version
gcc-12 (Ubuntu 12-20220319-1ubuntu1) 12.0.1 20220319 (experimental) [master
r12-7719-g8ca61ad148f]

[Bug tree-optimization/94920] Failure to optimize abs pattern from arithmetic with selected operands based on comparisons with 0

[gabravier at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Gabriel Ravier  ---
So, is this fully fixed, or did I miss something ?

[Bug debug/106261] [10/11/12/13 Regression] ICE in output_call_frame_info, at dwarf2out.cc:943

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

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

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

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

commit r13-1856-gf9671b60f9395cb1dca128b92f5dd215f5aeaae1
Author: Jakub Jelinek 
Date:   Wed Jul 27 12:06:22 2022 +0200

cgraphunit: Don't emit asm thunks for -dx [PR106261]

When -dx option is used (didn't know we have it and no idea what is it
useful for), we just expand functions to RTL and then omit all further
RTL passes, so the normal functions aren't actually emitted into assembly,
just variables.
The following testcase ICEs, because we don't emit the methods, but do
emit thunks pointing to that and those thunks have unwind info and rely on
at least some real functions to be emitted (which is normally the case,
thunks are only emitted for locally defined functions) because otherwise
there are no CIEs, only FDEs and dwarf2out is upset about it.

The following patch fixes that by not emitting assembly thunks for -dx
either.

2022-07-27  Jakub Jelinek  

PR debug/106261
* cgraphunit.cc (cgraph_node::assemble_thunks_and_aliases): Don't
output asm thunks for -dx.

* g++.dg/debug/pr106261.C: New test.

[Bug middle-end/106332] Possible out of bound buffer access in opts-common.c

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

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

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

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

commit r13-1855-gcc078cf85295ec5d0a63a16afbd045efac0d455e
Author: Jakub Jelinek 
Date:   Wed Jul 27 12:04:50 2022 +0200

opts: Add an assertion to help static analyzers [PR106332]

This function would have UB if called with empty candidates vector
(accessing p[-1] where p is malloc (0) result).
As analyzed in the PR, we never call it with empty vector, so this just
adds an assertion to make it clear.

2022-07-27  Jakub Jelinek  

PR middle-end/106332
* opts-common.cc (candidates_list_and_hint): Add gcc_assert
that candidates is not an empty vector.

[Bug tree-optimization/94920] Failure to optimize abs pattern from arithmetic with selected operands based on comparisons with 0

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

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

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

https://gcc.gnu.org/g:0bc1566dec0cab9410723c96d2ef3280fdab8e8e

commit r13-1854-g0bc1566dec0cab9410723c96d2ef3280fdab8e8e
Author: Jakub Jelinek 
Date:   Wed Jul 27 12:02:12 2022 +0200

testsuite: Add -Wno-psabi to pr94920 tests [PR94920]

These tests fail on ia32, because we get -Wpsabi warnings.
Fixed by adding -Wno-psabi.  The pr94920.C test still fails the
ABS_EXPR scan-tree-dump though, I think we'll need to add vect
options and use vect_int effective target or something similar.

2022-07-27  Jakub Jelinek  

PR tree-optimization/94920
* g++.dg/pr94920.C: Add -Wno-psabi to dg-options.
* g++.dg/pr94920-1.C: Add dg-additional-options -Wno-psabi.

[Bug tree-optimization/106397] [13 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645 since r13-1450-gd2a898666609452e

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

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

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

https://gcc.gnu.org/g:3044a7a824981496875acc6debf467fb904c55f2

commit r13-1853-g3044a7a824981496875acc6debf467fb904c55f2
Author: Jakub Jelinek 
Date:   Wed Jul 27 12:00:36 2022 +0200

testsuite: Add extra ia32 options so that -fprefetch-loop-arrays works
[PR106397]

-fprefetch-loop-arrays isn't supported on ia32 with just -march=i386 and
similar, the following patch adds extra options similar testcases use.

2022-07-27  Jakub Jelinek  

PR tree-optimization/106397
* gcc.dg/pr106397.c: For ia32, add dg-additional-options
-march=i686 -msse.

[Bug target/106453] New: Redundant zero extension after crc32q

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

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

Bug ID: 106453
   Summary: Redundant zero extension after crc32q
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

On 64-bit x86, straightforward use of SSE 4.2 crc instruction looks like

#include 
#include 

uint32_t f(uint32_t c, uint64_t *p, size_t n)
{
for (size_t i = 0; i < n; i++)
c = _mm_crc32_u64(c, p[i]);
return c;
}

On the ISA level, the crc32q instruction takes 64-bit operands, and resulting
assembly is (gcc -O2 -msse4.2):

f:
mov eax, edi
testrdx, rdx
je  .L1
lea rdx, [rsi+rdx*8]
.L3:
mov eax, eax
add rsi, 8
crc32   rax, QWORD PTR [rsi-8]
cmp rdx, rsi
jne .L3
.L1:
ret

Note zero-extension of 'eax' (which is usually not move-eliminated since
destination is the same as source).

The crc32q instruction zero-extends rax from the 32-bit result (it also ignores
high 32 bits when reading the destination operand), so I think it should be
possible to model zero extension in the .md pattern, allowing to eliminate the
explicit extension.

A source-level workaround is using a 64-bit variable in the loop, so the
extension happens just once before the loop.

[Bug libstdc++/106452] New: Iteration of filesystem::path("//") results in path("//") and not path("/")

[services+gccbugs at vasama dot org via Gcc-bugs]

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

Bug ID: 106452
   Summary: Iteration of filesystem::path("//") results in
path("//") and not path("/")
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: services+gccbugs at vasama dot org
  Target Milestone: ---

path("//").begin()->string() returns "//"s and not "/"s as might be expected.
path("//.").begin()->string() returns "/"s as expected.

https://godbolt.org/z/4YdY6bq3a

#include 
#include 
int main() {
assert(
std::filesystem::path("//").begin()->string() ==
std::filesystem::path("//.").begin()->string());
}

[Bug lto/106129] [12 Regression] LTO option merging broken

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||12.1.1, 13.0
 Status|NEW |RESOLVED
  Known to fail||12.1.0
 Resolution|--- |FIXED

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

[Bug lto/106129] [12 Regression] LTO option merging broken

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-8628-gd2892faac6d760ebc47f8f6ebee51e5cf6255cc8
Author: Joseph Myers 
Date:   Thu Jun 30 16:41:40 2022 +

lto: Fix option merging [PR106129]

The LTO merging of options from different input files was broken by:

commit 227a2ecf663d69972b851f51f1934d18927b62cd
Author: Martin Liska 
Date:   Fri Mar 12 11:53:47 2021 +0100

lto-wrapper: Use vec data type.

Previously, find_and_merge_options would merge options it read into
those in *opts. After this commit, options in *opts on entry to
find_and_merge_options are ignored; the only merging that takes place
is between multiple sets of options in the same input file that are
read in the same call to this function (not sure how that case can
occur at all). The effects include, for example, that if some objects
are built with PIC enabled and others with it disabled, and the last
LTO object processed has PIC enabled, the choice of PIC for the last
object will result in the whole program being built as PIC, when the
merging logic is intended to ensure that a mixture of PIC and non-PIC
objects results in the whole program being built as non-PIC.

Fix this with an extra argument to find_and_merge_options to determine
whether merging should take place.  This shows up a second issue with
that commit (which I think wasn't actually intended to change code
semantics at all): once merging is enabled again, the check for
-Xassembler options became an infinite loop in the case where both
inputs had -Xassembler options, with the same first option, so fix
that loop to restore the previous semantics.

Note that I'm not sure how LTO option merging might be tested in the
testsuite (clearly there wasn't sufficient, if any, coverage to detect
these bugs).

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

PR lto/106129
* lto-wrapper.cc (find_option): Add argument start.
(merge_and_complain): Loop over existing_opt_index and
existing_opt2_index for Xassembler check.  Update calls to
find_option.
(find_and_merge_options): Add argument first to determine whether
to merge options with those passed in *opts.
(run_gcc): Update calls to find_and_merge_options.

(cherry picked from commit 8a8ee37a3325f1009034245676ef4e482c0444a2)

[Bug tree-optimization/106087] [12 Regression] ICE with inline-asm with multiple output and assigned only static vars

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to work||12.1.1
 Status|ASSIGNED|RESOLVED
  Known to fail||12.1.0

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

[Bug tree-optimization/106063] [12 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
  Known to work||13.0
  Known to fail|13.0|12.1.0

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

[Bug tree-optimization/106063] [12 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:019a9ef7f7466c0f41bdc8c5838f4f4926c938aa

commit r12-8626-g019a9ef7f7466c0f41bdc8c5838f4f4926c938aa
Author: Dimitar Dimitrov 
Date:   Sun Jul 10 11:15:39 2022 +0300

testsuite: Require int128 for gcc.dg/pr106063.c

Require effective target int128 for gcc.dg/pr106063.c.

PR tree-optimization/106063

gcc/testsuite/ChangeLog:

* gcc.dg/pr106063.c: Require effective target int128.

Signed-off-by: Dimitar Dimitrov 
(cherry picked from commit 4ebbf3906895bcb40d7ff2729cf46deae66bc268)

[Bug tree-optimization/105665] [12 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-397-gda9e6e63d1ae22

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||12.1.0
  Known to work||12.1.1
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

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

[Bug tree-optimization/106189] [10/11/12 Regression] ICE: Floating point exception since r9-1948-gd893b683f40884cd

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-8629-g5b8458bc35b5df34c1b4b8735975f2686444f6c8
Author: Richard Biener 
Date:   Mon Jul 25 17:24:57 2022 +0200

tree-optimization/106189 - avoid division by zero exception

The diagnostic code can end up with zero sized array elements
with T[][0] and the wide-int code nicely avoids exceptions when
dividing by zero in one codepath but not in another.  The following
fixes the exception by using wide-int in both paths.

PR tree-optimization/106189
* gimple-array-bounds.cc (array_bounds_checker::check_mem_ref):
Divide using offset_ints.

* gcc.dg/pr106189.c: New testcase.

(cherry picked from commit bb04f9f23ac0dee2c003118c85372ece50a52220)

[Bug middle-end/100810] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776

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

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

--- Comment #17 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-8624-g4ca164a6372412a1b3dc62b6fbde77d338e22bd4
Author: Alexandre Oliva 
Date:   Fri Jun 3 03:59:03 2022 -0300

[PR105665] ivopts: check defs of names in base for undefs

The patch for PR 100810 tested for undefined SSA_NAMEs appearing
directly in the base expression of the potential IV candidate, but
that's not enough.  The testcase for PR105665 shows an undefined
SSA_NAME has the same ill effect if it's referenced as an PHI_NODE arg
in the referenced SSA_NAME.  The variant of that test shows it can be
further removed from the referenced SSA_NAME.

To avoid deep recursion, precompute maybe-undefined SSA_NAMEs: start
from known-undefined nonvirtual default defs, and propagate them to
any PHI nodes reached by a maybe-undefined arg, as long as there
aren't intervening non-PHI uses, that would imply the maybe-undefined
name must be defined at that point, otherwise it would invoke
undefined behavior.  Also test for intervening non-PHI uses of DEFs in
the base expr.

The test for intervening uses implemented herein relies on dominance;
this could be further extended, regarding conditional uses in every
path leading to a point as an unconditional use dominating that point,
but I haven't implemented that.

for  gcc/ChangeLog

PR tree-optimization/105665
PR tree-optimization/100810
* tree-ssa-loop-ivopts.cc
(ssa_name_maybe_undef_p, ssa_name_set_maybe_undef): New.
(ssa_name_any_use_dominates_bb_p, mark_ssa_maybe_undefs): New.
(find_ssa_undef): Check precomputed flag and intervening uses.
(tree_ssa_iv_optimize): Call mark_ssa_maybe_undefs.

for  gcc/testsuite/ChangeLog

PR tree-optimization/105665
PR tree-optimization/100810
* gcc.dg/torture/pr105665.c: New.

(cherry picked from commit be2861fe8c527a5952257462ceca899bb43b1452)

[Bug tree-optimization/106087] [12 Regression] ICE with inline-asm with multiple output and assigned only static vars

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

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

--- Comment #17 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-8627-ge0e388998b797da09a8c018f6f94d1358fd4b8f1
Author: Andrew Pinski 
Date:   Thu Jul 7 22:06:19 2022 +

Fix tree-opt/PR106087: ICE with inline-asm with multiple output and
assigned only static vars

The problem here is that when we mark the ssa name that was referenced in
the now removed
dead store (to a write only static variable), the inline-asm would also be
removed
even though it was defining another ssa name. This fixes the problem by
checking
to make sure that the statement was only defining one ssa name.

Committed as approved after a bootstrapped and tested on x86_64 with no
regressions.

PR tree-optimization/106087

gcc/ChangeLog:

* tree-ssa-dce.cc (simple_dce_from_worklist): Check
to make sure the statement is only defining one operand.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/inline-asm-1.c: New test.

(cherry picked from commit 71e3daa31cfa35ee58e5899cb00767be92227fd2)

[Bug tree-optimization/106063] [12 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:13d23c313374e15186f33fa6d57a0c9fd5d8b486

commit r12-8625-g13d23c313374e15186f33fa6d57a0c9fd5d8b486
Author: Tamar Christina 
Date:   Fri Jul 8 08:30:22 2022 +0100

middle-end: don't lower past veclower [PR106063]

Hi All,

My previous patch can cause a problem if the pattern matches after veclower
as it may replace the construct with a vector sequence which the target may
not
directly support.

As such don't perform the rewriting if after veclower unless the target
supports
the operation.  If before veclower do the rewriting as well if the target
didn't
support the original operation either.

gcc/ChangeLog:

PR tree-optimization/106063
* match.pd: Do not apply pattern after veclower is not supported.

gcc/testsuite/ChangeLog:

PR tree-optimization/106063
* gcc.dg/pr106063.c: New test.

(cherry picked from commit f7854e2faf7640230062dec3596e71773ca500ed)

[Bug tree-optimization/105665] [12 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-397-gda9e6e63d1ae22

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-8624-g4ca164a6372412a1b3dc62b6fbde77d338e22bd4
Author: Alexandre Oliva 
Date:   Fri Jun 3 03:59:03 2022 -0300

[PR105665] ivopts: check defs of names in base for undefs

The patch for PR 100810 tested for undefined SSA_NAMEs appearing
directly in the base expression of the potential IV candidate, but
that's not enough.  The testcase for PR105665 shows an undefined
SSA_NAME has the same ill effect if it's referenced as an PHI_NODE arg
in the referenced SSA_NAME.  The variant of that test shows it can be
further removed from the referenced SSA_NAME.

To avoid deep recursion, precompute maybe-undefined SSA_NAMEs: start
from known-undefined nonvirtual default defs, and propagate them to
any PHI nodes reached by a maybe-undefined arg, as long as there
aren't intervening non-PHI uses, that would imply the maybe-undefined
name must be defined at that point, otherwise it would invoke
undefined behavior.  Also test for intervening non-PHI uses of DEFs in
the base expr.

The test for intervening uses implemented herein relies on dominance;
this could be further extended, regarding conditional uses in every
path leading to a point as an unconditional use dominating that point,
but I haven't implemented that.

for  gcc/ChangeLog

PR tree-optimization/105665
PR tree-optimization/100810
* tree-ssa-loop-ivopts.cc
(ssa_name_maybe_undef_p, ssa_name_set_maybe_undef): New.
(ssa_name_any_use_dominates_bb_p, mark_ssa_maybe_undefs): New.
(find_ssa_undef): Check precomputed flag and intervening uses.
(tree_ssa_iv_optimize): Call mark_ssa_maybe_undefs.

for  gcc/testsuite/ChangeLog

PR tree-optimization/105665
PR tree-optimization/100810
* gcc.dg/torture/pr105665.c: New.

(cherry picked from commit be2861fe8c527a5952257462ceca899bb43b1452)

[Bug target/106346] [11/12/13 Regression] Potential regression on vectorization of left shift with constants since r11-5160-g9fc9573f9a5e94

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #7 from rguenther at suse dot de  ---
On Wed, 27 Jul 2022, tnfchris at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106346
> 
> --- Comment #6 from Tamar Christina  ---
> (In reply to Richard Biener from comment #5)
> > (In reply to Tamar Christina from comment #4)
> > > I believe the problem is actually 
> > > g:27842e2a1eb26a7eae80b8efd98fb8c8bd74a68e
> > > 
> > > We added an optab for the widening left shift pattern there however the
> > > operation requires a uniform shift constant to work. See
> > > https://godbolt.org/z/4hqKc69Ke
> > > 
> > > The existing pattern that deals with this is 
> > > vect_recog_widen_shift_pattern
> > > which is a scalar pattern.  during build_slp it validates that constants 
> > > are
> > > the same and when they're not it aborts SLP.  This is why we lose
> > > vectorization.  Eventually we hit V4HI for which we have no widening shift
> > > optab for and it vectorizes using that low VF.
> > > 
> > > This example shows a number of things wrong:
> > > 
> > > 1. The generic costing seems off, this sequence shouldn't have been
> > > generated, as a vector sequence it's more inefficient than the scalar
> > > sequence. Using -mcpu=neover-n1 or any other costing structure correctly
> > > only gives scalar.
> > > 
> > > 2. vect_recog_widen_shift_pattern is implemented in the wrong place.  It
> > > predates the existence of the SLP pattern matcher. Because of the uniform
> > > requirements it's better to use the SLP pattern matcher where we have 
> > > access
> > > to all the constants to decide whether the pattern is a match or not.  
> > > That
> > > way we don't abort SLP. Are you ok with this as a fix Richi?
> > 
> > patterns are difficult beasts - I think vect_recog_widen_shift_pattern is
> > at the correct place but instead what is lacking is SLP discovery support
> > for scrapping it - that is, ideally the vectorizer would take patterns as
> > a hint and ignore them when they are not helpful.
> 
> Hmm, yes but the problem is that we've consumed additional related statements
> which now need to be handled by build_slp as well. I suppose you could do an
> in-place build_slp on the pattern stmt seq iterator.  Though that seems like
> undoing a mistake.

Yes.  But it would be actually undoing a mistake, so ... ;)  The issue
is of course that we have many ways to vectorize things and patterns
just add to that - and SLP discovery needs to somehow pick one and
we stick to it (and cost based selection is only done on the vector mode
choice).

I'm not sure what's the best thing to do in the very end - for patterns
one could think of adding alternate (sub-)SLP-graph overlays instead
of forking the whole SLP graph for every combination of 
pattern/non-pattern which would surely explode.  At analysis time
one could choose the locally cheapest variant assuming the local
choice does not influence analysis of the rest of the graph (which
some widening patterns do after all, at least in the loop case by
influencing the VF).

> > 
> > Now - in theory, for SLP vectorization, all patterns could be handled
> > as SLP patterns and scalar patterns disabled.  But that isn't easy to
> > do either.
> 
> As long as we still have the non-SLP loop vect it's probably not a good idea
> no?
> since we then lose all patterns for it.  The widening shift was already
> sufficiently
> limited that it wouldn't really regress here.

Well, we'd need both obviously.  But yes, if we get to the point (sorry
for it taking forever) that we have SLP data structures for everything
we could shelve the stmt based patterns.

> > 
> > I fear to fight this regression the easiest route is to pretend the
> > ISA can do widen shift by vector and fixup in the expander ...
> 
> I can do this, but we're hiding the cost then. Or did you want me to fudge the
> numbers in the costing hooks?

Yes.

> > 
> > > 3. The epilogue costing seems off..
> > > 
> > > This example https://godbolt.org/z/YoPcWv6Td ends up generating an
> > > exceptionally high epilogue cost and so thinks vectorization at the higher
> > > VF is not profitable.
> > > 
> > > *src1_18(D) 1 times vec_to_scalar costs 2 in epilogue
> > > MEM[(uint16_t *)src1_18(D) + 2B] 1 times vec_to_scalar costs 2 in epilogue
> > > MEM[(uint16_t *)src1_18(D) + 4B] 1 times vec_to_scalar costs 2 in epilogue
> > > MEM[(uint16_t *)src1_18(D) + 6B] 1 times vec_to_scalar costs 2 in epilogue
> > > MEM[(uint16_t *)src1_18(D) + 8B] 1 times vec_to_scalar costs 2 in epilogue
> > > MEM[(uint16_t *)src1_18(D) + 10B] 1 times vec_to_scalar costs 2 in 
> > > epilogue
> > > MEM[(uint16_t *)src1_18(D) + 12B] 1 times vec_to_scalar costs 2 in 
> > > epilogue
> > > MEM[(uint16_t *)src1_18(D) + 14B] 1 times vec_to_scalar costs 2 in 
> > > epilogue
> > > /app/example.c:16:12: note: Cost model analysis for part in loop 0:
> > >   Vector cost: 23
> > >   Scalar cost: 17
> > 
> > I don't see any epilogue cost - the 

[Bug middle-end/106449] ICE in #pragma omp parallel for simd since r6-4544-ge01d41e553aae245

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
Summary|ICE in #pragma omp parallel |ICE in #pragma omp parallel
   |for simd|for simd since
   ||r6-4544-ge01d41e553aae245

--- Comment #3 from Martin Liška  ---
Btw. started with r6-4544-ge01d41e553aae245.

[Bug target/106450] [13 Regression] ICE in final_scan_insn_1, at final.cc:2860 (error: could not split insn) since r13-1607-gc3ed9e0d6e96d869

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
Summary|[13 Regression] ICE in  |[13 Regression] ICE in
   |final_scan_insn_1, at   |final_scan_insn_1, at
   |final.cc:2860 (error: could |final.cc:2860 (error: could
   |not split insn) |not split insn) since
   ||r13-1607-gc3ed9e0d6e96d869

--- Comment #2 from Martin Liška  ---
Started with r13-1607-gc3ed9e0d6e96d869.

[Bug tree-optimization/106446] -Warray-bounds false positive on downcast under condition

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Started with r10-4300-g49fb45c81f4ac068.

[Bug target/106346] [11/12/13 Regression] Potential regression on vectorization of left shift with constants since r11-5160-g9fc9573f9a5e94

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

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

--- Comment #6 from Tamar Christina  ---
(In reply to Richard Biener from comment #5)
> (In reply to Tamar Christina from comment #4)
> > I believe the problem is actually g:27842e2a1eb26a7eae80b8efd98fb8c8bd74a68e
> > 
> > We added an optab for the widening left shift pattern there however the
> > operation requires a uniform shift constant to work. See
> > https://godbolt.org/z/4hqKc69Ke
> > 
> > The existing pattern that deals with this is vect_recog_widen_shift_pattern
> > which is a scalar pattern.  during build_slp it validates that constants are
> > the same and when they're not it aborts SLP.  This is why we lose
> > vectorization.  Eventually we hit V4HI for which we have no widening shift
> > optab for and it vectorizes using that low VF.
> > 
> > This example shows a number of things wrong:
> > 
> > 1. The generic costing seems off, this sequence shouldn't have been
> > generated, as a vector sequence it's more inefficient than the scalar
> > sequence. Using -mcpu=neover-n1 or any other costing structure correctly
> > only gives scalar.
> > 
> > 2. vect_recog_widen_shift_pattern is implemented in the wrong place.  It
> > predates the existence of the SLP pattern matcher. Because of the uniform
> > requirements it's better to use the SLP pattern matcher where we have access
> > to all the constants to decide whether the pattern is a match or not.  That
> > way we don't abort SLP. Are you ok with this as a fix Richi?
> 
> patterns are difficult beasts - I think vect_recog_widen_shift_pattern is
> at the correct place but instead what is lacking is SLP discovery support
> for scrapping it - that is, ideally the vectorizer would take patterns as
> a hint and ignore them when they are not helpful.

Hmm, yes but the problem is that we've consumed additional related statements
which now need to be handled by build_slp as well. I suppose you could do an
in-place build_slp on the pattern stmt seq iterator.  Though that seems like
undoing a mistake.

> 
> Now - in theory, for SLP vectorization, all patterns could be handled
> as SLP patterns and scalar patterns disabled.  But that isn't easy to
> do either.

As long as we still have the non-SLP loop vect it's probably not a good idea
no?
since we then lose all patterns for it.  The widening shift was already
sufficiently
limited that it wouldn't really regress here.

> 
> I fear to fight this regression the easiest route is to pretend the
> ISA can do widen shift by vector and fixup in the expander ...

I can do this, but we're hiding the cost then. Or did you want me to fudge the
numbers in the costing hooks?

> 
> > 3. The epilogue costing seems off..
> > 
> > This example https://godbolt.org/z/YoPcWv6Td ends up generating an
> > exceptionally high epilogue cost and so thinks vectorization at the higher
> > VF is not profitable.
> > 
> > *src1_18(D) 1 times vec_to_scalar costs 2 in epilogue
> > MEM[(uint16_t *)src1_18(D) + 2B] 1 times vec_to_scalar costs 2 in epilogue
> > MEM[(uint16_t *)src1_18(D) + 4B] 1 times vec_to_scalar costs 2 in epilogue
> > MEM[(uint16_t *)src1_18(D) + 6B] 1 times vec_to_scalar costs 2 in epilogue
> > MEM[(uint16_t *)src1_18(D) + 8B] 1 times vec_to_scalar costs 2 in epilogue
> > MEM[(uint16_t *)src1_18(D) + 10B] 1 times vec_to_scalar costs 2 in epilogue
> > MEM[(uint16_t *)src1_18(D) + 12B] 1 times vec_to_scalar costs 2 in epilogue
> > MEM[(uint16_t *)src1_18(D) + 14B] 1 times vec_to_scalar costs 2 in epilogue
> > /app/example.c:16:12: note: Cost model analysis for part in loop 0:
> >   Vector cost: 23
> >   Scalar cost: 17
> 
> I don't see any epilogue cost - the example doesn't have a loop.  With BB
> vect you could see no epilogue costs?

That was my expectation, but see e.g. https://godbolt.org/z/MGEMYEe86 the SLP
shows the
above output.  I don't understand where the vec_to_scalar costs come from.

> 
> > For some reason it thinks it needs a scalar epilogue? using
> > -fno-vect-cost-model gives the desired codegen.

[Bug c++/106434] [12/13 Regression] Spurious -Wnull-dereference when using std::unique_copy() since r12-5187-g1ae8edf5f73ca5c3

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|Spurious -Wnull-dereference |[12/13 Regression] Spurious
   |when using  |-Wnull-dereference when
   |std::unique_copy()  |using std::unique_copy()
   ||since
   ||r12-5187-g1ae8edf5f73ca5c3
 CC||jwakely.gcc at gmail dot com,
   ||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started with r12-5187-g1ae8edf5f73ca5c3.

[Bug target/106346] [11/12/13 Regression] Potential regression on vectorization of left shift with constants since r11-5160-g9fc9573f9a5e94

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

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

--- Comment #5 from Richard Biener  ---
(In reply to Tamar Christina from comment #4)
> I believe the problem is actually g:27842e2a1eb26a7eae80b8efd98fb8c8bd74a68e
> 
> We added an optab for the widening left shift pattern there however the
> operation requires a uniform shift constant to work. See
> https://godbolt.org/z/4hqKc69Ke
> 
> The existing pattern that deals with this is vect_recog_widen_shift_pattern
> which is a scalar pattern.  during build_slp it validates that constants are
> the same and when they're not it aborts SLP.  This is why we lose
> vectorization.  Eventually we hit V4HI for which we have no widening shift
> optab for and it vectorizes using that low VF.
> 
> This example shows a number of things wrong:
> 
> 1. The generic costing seems off, this sequence shouldn't have been
> generated, as a vector sequence it's more inefficient than the scalar
> sequence. Using -mcpu=neover-n1 or any other costing structure correctly
> only gives scalar.
> 
> 2. vect_recog_widen_shift_pattern is implemented in the wrong place.  It
> predates the existence of the SLP pattern matcher. Because of the uniform
> requirements it's better to use the SLP pattern matcher where we have access
> to all the constants to decide whether the pattern is a match or not.  That
> way we don't abort SLP. Are you ok with this as a fix Richi?

patterns are difficult beasts - I think vect_recog_widen_shift_pattern is
at the correct place but instead what is lacking is SLP discovery support
for scrapping it - that is, ideally the vectorizer would take patterns as
a hint and ignore them when they are not helpful.

Now - in theory, for SLP vectorization, all patterns could be handled
as SLP patterns and scalar patterns disabled.  But that isn't easy to
do either.

I fear to fight this regression the easiest route is to pretend the
ISA can do widen shift by vector and fixup in the expander ...

> 3. The epilogue costing seems off..
> 
> This example https://godbolt.org/z/YoPcWv6Td ends up generating an
> exceptionally high epilogue cost and so thinks vectorization at the higher
> VF is not profitable.
> 
> *src1_18(D) 1 times vec_to_scalar costs 2 in epilogue
> MEM[(uint16_t *)src1_18(D) + 2B] 1 times vec_to_scalar costs 2 in epilogue
> MEM[(uint16_t *)src1_18(D) + 4B] 1 times vec_to_scalar costs 2 in epilogue
> MEM[(uint16_t *)src1_18(D) + 6B] 1 times vec_to_scalar costs 2 in epilogue
> MEM[(uint16_t *)src1_18(D) + 8B] 1 times vec_to_scalar costs 2 in epilogue
> MEM[(uint16_t *)src1_18(D) + 10B] 1 times vec_to_scalar costs 2 in epilogue
> MEM[(uint16_t *)src1_18(D) + 12B] 1 times vec_to_scalar costs 2 in epilogue
> MEM[(uint16_t *)src1_18(D) + 14B] 1 times vec_to_scalar costs 2 in epilogue
> /app/example.c:16:12: note: Cost model analysis for part in loop 0:
>   Vector cost: 23
>   Scalar cost: 17

I don't see any epilogue cost - the example doesn't have a loop.  With BB
vect you could see no epilogue costs?

> For some reason it thinks it needs a scalar epilogue? using
> -fno-vect-cost-model gives the desired codegen.

[Bug target/106346] [11/12/13 Regression] Potential regression on vectorization of left shift with constants since r11-5160-g9fc9573f9a5e94

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

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

Tamar Christina  changed:

   What|Removed |Added

Summary|Potential regression on |[11/12/13 Regression]
   |vectorization of left shift |Potential regression on
   |with constants since|vectorization of left shift
   |r11-5160-g9fc9573f9a5e94|with constants since
   ||r11-5160-g9fc9573f9a5e94
   Priority|P3  |P2
 CC||rguenth at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org
   Target Milestone|--- |11.5
 Status|NEW |ASSIGNED

--- Comment #4 from Tamar Christina  ---
I believe the problem is actually g:27842e2a1eb26a7eae80b8efd98fb8c8bd74a68e

We added an optab for the widening left shift pattern there however the
operation requires a uniform shift constant to work. See
https://godbolt.org/z/4hqKc69Ke

The existing pattern that deals with this is vect_recog_widen_shift_pattern
which is a scalar pattern.  during build_slp it validates that constants are
the same and when they're not it aborts SLP.  This is why we lose
vectorization.  Eventually we hit V4HI for which we have no widening shift
optab for and it vectorizes using that low VF.

This example shows a number of things wrong:

1. The generic costing seems off, this sequence shouldn't have been generated,
as a vector sequence it's more inefficient than the scalar sequence. Using
-mcpu=neover-n1 or any other costing structure correctly only gives scalar.

2. vect_recog_widen_shift_pattern is implemented in the wrong place.  It
predates the existence of the SLP pattern matcher. Because of the uniform
requirements it's better to use the SLP pattern matcher where we have access to
all the constants to decide whether the pattern is a match or not.  That way we
don't abort SLP. Are you ok with this as a fix Richi?

3. The epilogue costing seems off..

This example https://godbolt.org/z/YoPcWv6Td ends up generating an
exceptionally high epilogue cost and so thinks vectorization at the higher VF
is not profitable.

*src1_18(D) 1 times vec_to_scalar costs 2 in epilogue
MEM[(uint16_t *)src1_18(D) + 2B] 1 times vec_to_scalar costs 2 in epilogue
MEM[(uint16_t *)src1_18(D) + 4B] 1 times vec_to_scalar costs 2 in epilogue
MEM[(uint16_t *)src1_18(D) + 6B] 1 times vec_to_scalar costs 2 in epilogue
MEM[(uint16_t *)src1_18(D) + 8B] 1 times vec_to_scalar costs 2 in epilogue
MEM[(uint16_t *)src1_18(D) + 10B] 1 times vec_to_scalar costs 2 in epilogue
MEM[(uint16_t *)src1_18(D) + 12B] 1 times vec_to_scalar costs 2 in epilogue
MEM[(uint16_t *)src1_18(D) + 14B] 1 times vec_to_scalar costs 2 in epilogue
/app/example.c:16:12: note: Cost model analysis for part in loop 0:
  Vector cost: 23
  Scalar cost: 17

For some reason it thinks it needs a scalar epilogue? using
-fno-vect-cost-model gives the desired codegen.

[Bug target/106022] [12 Regression] Enable vectorizer generates extra load

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

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

--- Comment #20 from Richard Biener  ---
Probably OK to backport for 12.2 (but no later)

[Bug rtl-optimization/101347] [11/12 Regression] ICE in cfg_layout_initialize with __builtin_setjmp and -fprofile-generate -fprofile-use

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||13.0
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
  Known to fail||11.3.1, 12.1.1
   Target Milestone|11.4|13.0

--- Comment #7 from Richard Biener  ---
The issue is most definitely latent forever, let's close this bug and be done
with it (it's unlikely to hit in practice).

[Bug other/106451] [13 regression] gcc.dg/pr56837.c fails after r13-1762-gf9d4c3b45c5ed5

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
dup then

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

[Bug tree-optimization/106375] [13 regreesion] Lowering complex type mov regressed loop distribution for memset/memcpy/memmov.

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
*** Bug 106451 has been marked as a duplicate of this bug. ***

[Bug middle-end/106449] ICE in #pragma omp parallel for simd

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

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

--- Comment #2 from Richard Biener  ---
(In reply to Tobias Burnus from comment #1)
> My impression is that the ICE is due to having
>   fold_build2_loc (0, PLUS_EXPR, type, op0, op1)
> with
> (gdb) p debug_tree(type)
>   (gdb) p debug_tree(op0)
>   constant 256>
> (gdb) p debug_tree(op1)
>   type  
> Namely: variable PLUS_EXPR integer_cst  - instead of a POINTER_PLUS_EXPR.
> 
> 
> Patch would be something like the following – except that there are several
> additional PLUS_EXPR in that function and that fold_build_pointer_plus
> assumes that the first argument is the pointer and the second the offset,
> which is converted via convert_to_ptrofftype_loc ...

I think the above also shows that op0 is the offset and op1 the base
and thus the arguments should be reversed here.

> --- a/gcc/omp-expand.cc
> +++ b/gcc/omp-expand.cc
> @@ -6882 +6882,4 @@ expand_omp_simd (struct omp_region *region, struct
> omp_for_data *fd)
> - t = fold_build2 (PLUS_EXPR, TREE_TYPE (t), t, t2);
> + if (POINTER_TYPE_P (TREE_TYPE (t)))
> +   t = fold_build_pointer_plus (t, t2);
> + else
> +   t = fold_build2 (PLUS_EXPR, TREE_TYPE (t), t, t2);

[Bug middle-end/102633] [11/12/13 Regression] warning for self-initialization despite -Wno-init-self

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #7 from Martin Uecker  ---
Sorry, somehow I missed this. I will look at this once I am back from travel
(if Marek hasen't fixed it)