[Bug bootstrap/108711] New: [13 Regression] ICE in get_equiv, at lra-constraints.cc:534

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

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

Bug ID: 108711
   Summary: [13 Regression] ICE in get_equiv, at
lra-constraints.cc:534
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: vmakarov at gcc dot gnu.org
  Target Milestone: ---
  Host: i586-linux-gnu
Target: i586-linux-gnu

I see the bootstrap is broken due to:

[ 1890s]
/home/abuild/rpmbuild/BUILD/gcc-13.0.1+git5733/obj-i586-suse-linux/./prev-gcc/xg++
-B/home/abuild/rpmbuild/BUILD/gcc-13.0.1+git5733/obj-i586-suse-linux/./prev-gcc/
-B/usr/i586-suse-linux/bin/ -nostdinc++
-B/home/abuild/rpmbuild/BUILD/gcc-13.0.1+git5733/obj-i586-suse-linux/prev-i586-suse-linux/libstdc++-v3/src/.libs
-B/home/abuild/rpmbuild/BUILD/gcc-13.0.1+git5733/obj-i586-suse-linux/prev-i586-suse-linux/libstdc++-v3/libsupc++/.libs

-I/home/abuild/rpmbuild/BUILD/gcc-13.0.1+git5733/obj-i586-suse-linux/prev-i586-suse-linux/libstdc++-v3/include/i586-suse-linux

-I/home/abuild/rpmbuild/BUILD/gcc-13.0.1+git5733/obj-i586-suse-linux/prev-i586-suse-linux/libstdc++-v3/include
 -I/home/abuild/rpmbuild/BUILD/gcc-13.0.1+git5733/libstdc++-v3/libsupc++
-L/home/abuild/rpmbuild/BUILD/gcc-13.0.1+git5733/obj-i586-suse-linux/prev-i586-suse-linux/libstdc++-v3/src/.libs
-L/home/abuild/rpmbuild/BUILD/gcc-13.0.1+git5733/obj-i586-suse-linux/prev-i586-suse-linux/libstdc++-v3/libsupc++/.libs
 -fno-PIE -c  -DIN_GCC_FRONTEND -fomit-frame-pointer -O2 -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=3 -funwind-tables -fasynchronous-unwind-tables
-fstack-clash-protection -Werror=return-type -g -U_FORTIFY_SOURCE -DIN_GCC
-fPIC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -Igo
-I../../gcc -I../../gcc/go -I../../gcc/../include 
-I../../gcc/../libcpp/include -I../../gcc/../libcody 
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/../libbacktrace   -o go/expressions.o -MT go/expressions.o -MMD -MP
-MF go/.deps/expressions.TPo -I ../../gcc/go -I ../../gcc/go/gofrontend
../../gcc/go/gofrontend/expressions.cc
[ 1890s] during RTL pass: reload
[ 1890s] ../../gcc/go/gofrontend/expressions.cc: In member function 'virtual
Expression* Composite_literal_expression::do_copy()':
[ 1890s] ../../gcc/go/gofrontend/expressions.cc:17358:1: internal compiler
error: in get_equiv, at lra-constraints.cc:534
[ 1890s] 17358 | }
[ 1890s]   | ^
[ 1890s] 0x84f9177 _start

I'm reducing that right now.

[Bug rtl-optimization/108711] [13 Regression] ICE in get_equiv, at lra-constraints.cc:534

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Keywords||build, ra
   Severity|normal  |blocker
  Component|bootstrap   |rtl-optimization
 Target|i586-linux-gnu  |i586-linux-gnu
   ||x86_64-linux-gnu
   Host|i586-linux-gnu  |

--- Comment #1 from Andrew Pinski  ---
Also reported by me:
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611549.html

[Bug rtl-optimization/108711] [13 Regression] ICE in get_equiv, at lra-constraints.cc:534

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I see it too, on i686-linux as
during RTL pass: reload
../../gcc/d/dmd/expression.d: In function ‘syntaxCopy’:
../../gcc/d/dmd/expression.d:4237:5: internal compiler error: in get_equiv, at
lra-constraints.cc:534
 4237 | }
  | ^
/home/jakub/src/gcc/obj11/./prev-gcc/gdc
-B/home/jakub/src/gcc/obj11/./prev-gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -O2
-g -B/home/jakub/src/gcc/obj11/prev-i686-pc-linux-gnu/libphob
0x8fdfe94 get_equiv
../../gcc/lra-constraints.cc:534
0x8fef557 lra_constraints(bool)
../../gcc/lra-constraints.cc:5052
0x8fd58a3 lra(_IO_FILE*)
../../gcc/lra.cc:2375
0x8f7398b do_reload
../../gcc/ira.cc:5955
0x8f73e40 execute
../../gcc/ira.cc:6141
and on x86_64 when building 32-bit libgo:
during RTL pass: reload
../../../../libgo/go/reflect/type.go: In function ‘reflect.rtype.Method’:
../../../../libgo/go/reflect/type.go:604:1: internal compiler error: in
get_equiv, at lra-constraints.cc:534
0x7ed869 get_equiv
../../gcc/lra-constraints.cc:534
0x127ef32 lra_constraints(bool)
../../gcc/lra-constraints.cc:5052
0x1269b04 lra(_IO_FILE*)
../../gcc/lra.cc:2375
0x121b7e9 do_reload
../../gcc/ira.cc:5955
0x121b7e9 execute
../../gcc/ira.cc:6141
Please submit a full bug report, with preprocessed source (by using
-freport-bug).

Reverting r13-5730-gf661c0bb6371f355966a67b5ce71398e80792948 makes it work
again.

[Bug c/108712] New: Missing optimization with memory-barrier

[klaus.doldinger64 at googlemail dot com via Gcc-bugs]

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

Bug ID: 108712
   Summary: Missing optimization with memory-barrier
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: klaus.doldinger64 at googlemail dot com
  Target Milestone: ---

In the following example the increments of `g` could be optimized to a `g+=20`
equivalent.

But avr-gcc hoists the load of `g` outside the loop but the stores remain
inside the loop.

That produces unneccessary overhead.

(I know that the idionatic solution would be to volatile-qualify the variable
`flag` 
make a volatile-access like std::experimental::volatile_load()` or
`ACCESS_ONCE()` (linux kernel).

https://godbolt.org/z/1b6xG5YP4


#include 
#include 
//#include  // do not include that stub: wrong sig_atomic_t

typedef signed char sig_atomic_t; // __SIG_ATOMIC_TYPE__

#include 

static sig_atomic_t flag;
static uint8_t g; 

void func(void) {
for(uint8_t i = 0; i < 20; i++) {
__asm__ __volatile__ ("" : "+m" (flag));
++g;
if (flag) {
flag = 0;
}
__asm__ __volatile__ ("" : "+m" (flag));
 }
}

ISR(USART_RXC_vect) {
__asm__ __volatile__ ("" : "+m" (flag));
flag = 1;
}

[Bug rtl-optimization/108711] [13 Regression] ICE in get_equiv, at lra-constraints.cc:534

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2023-02-08
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #3 from Martin Liška  ---
Reduced test-case:

$ cat goexpr.ii

struct Expression_list {
  Expression_list *copy();
} vals_;
struct Parser_expression {
  Parser_expression();
};
struct Composite_literal_expression : Parser_expression {
  Composite_literal_expression(bool has_keys, Expression_list *,
   bool all_are_names)
  : has_keys_(has_keys), all_are_names_(all_are_names) {}
  void do_copy();
  bool has_keys_;
  bool all_are_names_;
};
void Composite_literal_expression::do_copy() {
  new Composite_literal_expression(has_keys_, vals_.copy(), all_are_names_);
}

$
/home/abuild/rpmbuild/BUILD/gcc-13.0.1+git5733/obj-i586-suse-linux/./prev-gcc/xg++
-B/home/abuild/rpmbuild/BUILD/gcc-13.0.1+git5733/obj-i586-suse-linux/./prev-gcc/
-fno-exceptions   -O2 goexpr.ii -c
during RTL pass: reload
goexpr.ii: In member function 'void Composite_literal_expression::do_copy()':
goexpr.ii:17:1: internal compiler error: in get_equiv, at
lra-constraints.cc:534
   17 | }
  | ^
0x84f9177 _start
../sysdeps/i386/start.S:111
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 middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||rguenther at suse dot de

--- Comment #12 from David Binderman  ---
Perhaps Richard would be willing to offer their best advice.

[Bug middle-end/108712] Missing optimization with memory-barrier

[klaus.doldinger64 at googlemail dot com via Gcc-bugs]

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

--- Comment #1 from Wilhelm M  ---
And using

__asm__ __volatile__ ("" : : : "memory"); 


there is no optimization at all.

[Bug rtl-optimization/108713] New: ICE during RTL pass: into_cfglayout for x86_64-pc-linux-gnu '-m32', C++ 'libgomp.c-c++-common/for-11.c'

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

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

Bug ID: 108713
   Summary: ICE during RTL pass: into_cfglayout for
x86_64-pc-linux-gnu '-m32', C++
'libgomp.c-c++-common/for-11.c'
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

With GCC sources based on 2023-01-27 commit
84eb39556cc8449e04b5f48bd5c131941a7a2529, with a bunch of local OMP changes on
top (but those shouldn't be touching the relevant area of code), standard
bootstrap build, I've observed an ICE as follows on our x86_64-pc-linux-gnu
testing system amd_ryzen1, in routine libgomp testing for '-m32':

[...]
spawn -ignore SIGHUP gcc -x c++
../source-gcc/libgomp/testsuite/libgomp.c++/../libgomp.c-c++-common/for-11.c
-m32 -foffload-options=amdgcn-amdhsa=-march=gfx900
-I../source-gcc/libgomp/testsuite/../../include
-I../source-gcc/libgomp/testsuite/.. -fmessage-length=0
-fno-diagnostics-show-caret -fdiagnostics-color=never -fopenmp -O2 -lstdc++ -lm
-o ./for-11.exe
during RTL pass: into_cfglayout
In file included from
../source-gcc/libgomp/testsuite/libgomp.c++/../libgomp.c-c++-common/for-1.h:13,
 from
../source-gcc/libgomp/testsuite/libgomp.c++/../libgomp.c-c++-common/for-5.c:114,
 from
../source-gcc/libgomp/testsuite/libgomp.c++/../libgomp.c-c++-common/for-11.c:4:
   
../source-gcc/libgomp/testsuite/libgomp.c++/../libgomp.c-c++-common/for-2.h: In
function 'f34_ttdpfs_ds128_auto() [clone ._omp_fn.1]':
   
../source-gcc/libgomp/testsuite/libgomp.c++/../libgomp.c-c++-common/for-2.h:520:17:
internal compiler error: Segmentation fault
0x16a482f crash_signal
[...]/source-gcc/gcc/toplev.cc:314
0x268a3e2 compact_blocks()
[...]/source-gcc/gcc/cfg.cc:182
0x26951cf cleanup_cfg(int)
[...]/source-gcc/gcc/cfgcleanup.cc:3131
0x11b682a execute
[...]/source-gcc/gcc/cfgrtl.cc:3703
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.
compiler exited with status 1
FAIL: libgomp.c++/../libgomp.c-c++-common/for-11.c (internal compiler
error: Segmentation fault)
[...]

Nothing interesting in 'dmesg', as far as I can tell.

'gcc/cfgrtl.cc':

3693 class pass_into_cfg_layout_mode : public rtl_opt_pass
3694 {
3695 public:
3696   pass_into_cfg_layout_mode (gcc::context *ctxt)
3697 : rtl_opt_pass (pass_data_into_cfg_layout_mode, ctxt)
3698   {}
3699 
3700   /* opt_pass methods: */
3701   unsigned int execute (function *) final override
3702 {
3703   cfg_layout_initialize (0);

'gcc/cfgcleanup.cc':

3109 bool
3110 cleanup_cfg (int mode)
3111 {
[...]
3131   compact_blocks ();

'gcc/cfg.cc':

167 void
168 compact_blocks (void)
169 {
170   int i;
171 
172   SET_BASIC_BLOCK_FOR_FN (cfun, ENTRY_BLOCK, ENTRY_BLOCK_PTR_FOR_FN
(cfun));
173   SET_BASIC_BLOCK_FOR_FN (cfun, EXIT_BLOCK, EXIT_BLOCK_PTR_FOR_FN
(cfun));
174 
175   if (df)
176 df_compact_blocks ();
177   else
178 {
179   basic_block bb;
180 
181   i = NUM_FIXED_BLOCKS;
182   FOR_EACH_BB_FN (bb, cfun)
183 {
184   SET_BASIC_BLOCK_FOR_FN (cfun, i, bb);
185   bb->index = i;
186   i++;
187 }

This is the first/only time I've seen this; the ICE doesn't reproduce now for a
few manual re-invocations.  Maybe just "cosmic rays"...

A run with '-wrapper valgrind' did find a lot of stuff in IRA and LRA, but it's
a GCC build without '--enable-valgrind-annotations', so I'm not sure what that
means.

[...]
==24856== Conditional jump or move depends on uninitialised value(s)
==24856==at 0x14B18E5: mark_pseudo_regno_live(int) (in
[...]/install/libexec/gcc/x86_64-pc-linux-gnu/13.0.1/cc1plus)
==24856==by 0x14B3260: process_bb_node_lives(ira_loop_tree_node*) (in
[...]/install/libexec/gcc/x86_64-pc-linux-gnu/13.0.1/cc1plus)
==24856==by 0x1491F28: ira_traverse_loop_tree(bool,
ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void
(*)(ira_loop_tree_node*)) (in
[...]/install/libexec/gcc/x86_64-pc-linux-gnu/13.0.1/cc1plus)
==24856==by 0x14B45BF: ira_create_allocno_live_ranges() (in
[...]/install/libexec/gcc/x86_64-pc-linux-gnu/13.0.1/cc1plus)
==24856==by 0x1496424: ira_build() (in
[...]/install/libexec/gcc/x86_64-pc-linux-gnu/13.0.1/cc1plus)
==24856==by 0x148DB0E: (anonymous
namespace)::pass_ira::execute(function*) (in

[Bug libstdc++/108714] New: Algorithms in require predicates to be copyable

[b.stanimirov at abv dot bg via Gcc-bugs]

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

Bug ID: 108714
   Summary: Algorithms in  require predicates to be
copyable
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.stanimirov at abv dot bg
  Target Milestone: ---

Simple repro:

```
#include 
#include 

struct noncopyable {
noncopyable();
noncopyable(const noncopyable&) = delete;
noncopyable(noncopyable&&) noexcept = default;
template 
bool operator()(const T&);
};

bool all_of_vec(const std::vector& vec) {
return std::all_of(vec.begin(), vec.end(), noncopyable{});
}
```

This does not compile, because the predicate to `all_of` is not copyable. The
same error appears for all other algorithms which allow a predicate.

It does compile and work and expected with Microsoft STL and with libc++

Live demo showing compilation errors with libstdc++ and successful compilation
with libc++ and Microsoft STL: https://godbolt.org/z/xaa35G35e

[Bug rtl-optimization/108713] ICE during RTL pass: into_cfglayout for x86_64-pc-linux-gnu '-m32', C++ 'libgomp.c-c++-common/for-11.c'

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

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

--- Comment #1 from Jakub Jelinek  ---
If you can reproduce it with vanilla trunk, it is worth it, sure, but without a
reliable reproducer there isn't much to do.  Is the ICE in an offload compiler
or on the host?

[Bug rtl-optimization/108713] ICE during RTL pass: into_cfglayout for x86_64-pc-linux-gnu '-m32', C++ 'libgomp.c-c++-common/for-11.c'

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

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

--- Comment #2 from Thomas Schwinge  ---
(In reply to Jakub Jelinek from comment #1)
> If you can reproduce it with vanilla trunk, it is worth it, sure, but
> without a reliable reproducer there isn't much to do.

I'll attempt to reproduce with clean sources, and Valgrind enabled.

> Is the ICE in an
> offload compiler or on the host?

Host; as of "Remove support for Intel MIC offloading", there's no offloading
configurations anymore for '-m32'...  ;-\

[Bug c++/108588] __is_constructible returns wrong value for invalid (but non deleted) default constructor

[fchelnokov at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Fedor Chelnokov  ---
According to this StackOverflow answer, the behavior of GCC is incorrect here:
https://stackoverflow.com/a/75380301/7325599

[Bug c/108715] New: Infinite loop in the generated assembly with -Os when strlen is defined in the code

[daniel at eyoman dot com via Gcc-bugs]

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

Bug ID: 108715
   Summary: Infinite loop in the generated assembly with -Os when
strlen is defined in the code
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel at eyoman dot com
  Target Milestone: ---

Created attachment 54426
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54426&action=edit
C file

Hi,

The attached source file is compiled on GCC 12.2.1 with the following command:
gcc -save-temps -Wall -Wextra -Os strlen_bug.c -o strlen_bug

The assembly file, obtained with objdump -d strlen_bug, shows that:
- the for loop dealing with the length calculation has been removed by strlen
- the strlen label jumps to itself
- the program never ends

If the strlen function is removed from the code, the problem doesn't occur.

I wanted to attach the assembly and preprocessed files but I could attach only
one.

[Bug c/108715] Infinite loop in the generated assembly with -Os when strlen is defined in the code

[daniel at eyoman dot com via Gcc-bugs]

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

--- Comment #1 from Daniel Zaoui  ---
Created attachment 54427
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54427&action=edit
Preprocessed file

[Bug c/108715] Infinite loop in the generated assembly with -Os when strlen is defined in the code

[daniel at eyoman dot com via Gcc-bugs]

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

--- Comment #2 from Daniel Zaoui  ---
Created attachment 54428
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54428&action=edit
Assembly file

[Bug c/108715] Infinite loop in the generated assembly with -Os when strlen is defined in the code

[daniel at eyoman dot com via Gcc-bugs]

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

Daniel Zaoui  changed:

   What|Removed |Added

  Attachment #54427|0   |1
is obsolete||

--- Comment #3 from Daniel Zaoui  ---
Comment on attachment 54427
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54427
Preprocessed file

I attached the wrong file by mistake

[Bug c/108715] Infinite loop in the generated assembly with -Os when strlen is defined in the code

[daniel at eyoman dot com via Gcc-bugs]

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

Daniel Zaoui  changed:

   What|Removed |Added

  Attachment #54428|0   |1
is obsolete||

--- Comment #4 from Daniel Zaoui  ---
Comment on attachment 54428
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54428
Assembly file

I attached the wrong file by mistake

[Bug c/108715] Infinite loop in the generated assembly with -Os when strlen is defined in the code

[daniel at eyoman dot com via Gcc-bugs]

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

--- Comment #5 from Daniel Zaoui  ---
Created attachment 54429
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54429&action=edit
Preprocessed file

[Bug c/108715] Infinite loop in the generated assembly with -Os when strlen is defined in the code

[daniel at eyoman dot com via Gcc-bugs]

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

--- Comment #6 from Daniel Zaoui  ---
Created attachment 54430
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54430&action=edit
Assembly file

[Bug c/108715] Infinite loop in the generated assembly with -Os when strlen is defined in the code

[daniel at eyoman dot com via Gcc-bugs]

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

--- Comment #7 from Daniel Zaoui  ---
With the -fno-builtin option, the assembly is correct and the program behaves
as expected.

[Bug debug/108716] New: [10/11/12/13 Regression] Incorrect DW_AT_decl_{line,column} in DW_TAG_imported_decl

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

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

Bug ID: 108716
   Summary: [10/11/12/13 Regression] Incorrect
DW_AT_decl_{line,column} in DW_TAG_imported_decl
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

On the following testcase we used to emit DW_TAG_imported_decl with correct
DW_AT_decl_line before r0-90102-gd19c0f4b4cdf4bdffa31 , the PR37410 fix
resulted
in no DW_TAG_imported_decl being emitted at all and since
r0-92015-g98381eb4870eb42b220822 we emit it with a wrong line - one with }
closing the main function rather than the line on which it actually appears.

// PR debug/1X
// { dg-options "-gdwarf-5 -dA -fno-merge-debug-strings" }
// { dg-final { scan-assembler "DIE \\(\[^\n\r\]*\\)
DW_TAG_imported_module\[^\n\r\]*\[\n\r]*\[^\n\r\]*
DW_AT_decl_file\[^\n\r\]*\[\n\r]*\[^\n\r\]*0xc\[^\n\r\]*
DW_AT_decl_line\[^\n\r\]*\[\n\r]*(\[^\n\r\]*0x13\[^\n\r\]*
DW_AT_decl_column\[^\n\r\]*\[\n\r]*)?" } }

namespace M {
  int x = 1;
}

int
main ()
{
  using namespace M;
  return 0;
}

[Bug debug/108716] [10/11/12/13 Regression] Incorrect DW_AT_decl_{line,column} in DW_TAG_imported_decl

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2023-02-08
   Target Milestone|--- |10.5
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Priority|P3  |P2
   Keywords||wrong-debug

[Bug debug/108716] [10/11/12/13 Regression] Incorrect DW_AT_decl_{line,column} in DW_TAG_imported_decl

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 54431
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54431&action=edit
gcc13-pr108716.patch

Untested fix.

[Bug ipa/108695] [13 Regression] Wrong code since r13-5215-gb1f30bf42d8d47 for dd_rescue package

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

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

--- Comment #6 from Martin Liška  ---
(In reply to Andrew Pinski from comment #5)
> I am 99% sure there is aliasing violations in this code too:
> #if _MSC_VER
> #define GETU32(p) SWAP(*((u32 *)(p)))
> #define PUTU32(ct, st)  \
> {   \
> *((u32 *)(ct)) = SWAP((st));\
> }

Yes, I'm also suspecting this code and I can verify that using optimize("O0")
for rijndaelEncrypt fixes the issue.

The thing below is cast from 'const u8 *' and I thought it's valid to case
to 'u32 *' and then access it. Can you explain to me how exactly the violation
happens?

> #else   /* _MSC_VER */
> # if __BYTE_ORDER == __BIG_ENDIAN
> #define GETU32(p) *((u32*)(p))
> #define PUTU32(ct, st) *((u32*)(ct)) = (st)
> #else   /* BIG_ENDIAN */
> #if 0 //def HAVE_LINUX_SWAB_H
> #define GETU32(p) __swab32(*((u32*)(p)))
> #define PUTU32(ct, st) *((u32*)(ct)) = __swab32((st))
> #else   /* __GNUC__ */
> #include 
> #define GETU32(p) ntohl(*((u32*)(p)))
> #define PUTU32(ct, st) *((u32*)(ct)) = htonl((st))
> #endif  /* __GNUC__ */
> #endif  /* BIG_ENDIAN */
> #endif  /*_MSC_VER */
> 

This part below is guarded with '#if 0'..

> #if 0
> #define GETU32(pt) (((u32)(pt)[0] << 24) ^ ((u32)(pt)[1] << 16) ^
> ((u32)(pt)[2] << 8) ^ ((u32)(pt)[3]))
> #define PUTU32(ct, st)  \
> {   \
> (ct)[0] = (u8)((st) >> 24); \
> (ct)[1] = (u8)((st) >> 16); \
> (ct)[2] = (u8)((st) >> 8);  \
> (ct)[3] = (u8)(st); \
> }
> #endif
> 
> A few other places too ...

[Bug libstdc++/90192] std::vector::resize() requires more than it should (CopyInsertable)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
dup

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

[Bug libstdc++/83981] vector::resize(size_type) should not require T to be CopyInsertable when std=c++14

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||lemo1234 at gmail dot com

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

[Bug libstdc++/83981] vector::resize(size_type) should not require T to be CopyInsertable when std=c++14

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||dan.raviv at gmail dot com

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

[Bug libstdc++/106239] vector::resize(size_type, const value_type&) should not require copy-assignability

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Dup of PR 90192 and PR 83981

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

[Bug middle-end/108715] Infinite loop in the generated assembly with -Os when strlen is defined in the code

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end

--- Comment #8 from Andrew Pinski  ---
There is a dup of this bug already filed. And a related bug when defining
"memcpy" too.

C is special.

[Bug libstdc++/108714] Algorithms in require predicates to be copyable

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Not a bug, the standard is clear about this:

[Note 2 : Unless otherwise specified, algorithms that take function objects as
arguments can copy those function objects freely. If object identity is
important, a wrapper class that points to a non-copied implementation object
such as reference_wrapper (22.10.6), or some equivalent solution, can be
used. — end note]

[Bug ipa/108695] [13 Regression] Wrong code since r13-5215-gb1f30bf42d8d47 for dd_rescue package

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #6)
> Yes, I'm also suspecting this code and I can verify that using optimize("O0")
> for rijndaelEncrypt fixes the issue.
> 
> The thing below is cast from 'const u8 *' and I thought it's valid to case
> to 'u32 *' and then access it. Can you explain to me how exactly the
> violation happens?

A cast is fine, what matters are the accesses.  If the object has u32 type,
then casting
its address to const u8 * and later on back to u32 * and accessing through that
type
is fine, but if it has an incompatible type, it is not.  Similarly, if it is
heap allocated, the type is given to it through the stores to it and later
reads from it should be done with a compatible (aliasing wise) type.
See section 6.5 in e.g. C17 for the details (definition of effective type and
the aliasing requirements).

[Bug middle-end/108715] Infinite loop in the generated assembly with -Os when strlen is defined in the code

[daniel at eyoman dot com via Gcc-bugs]

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

--- Comment #9 from Daniel Zaoui  ---
(In reply to Andrew Pinski from comment #8)
> There is a dup of this bug already filed. And a related bug when defining
> "memcpy" too.
> 
> C is special.

Do you have any bug ID? I searched before opening the bug without success.

[Bug middle-end/108715] Infinite loop in the generated assembly with -Os when strlen is defined in the code

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
PR56888 ?

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

[asolokha at gmx dot com via Gcc-bugs]

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

Arseny Solokha  changed:

   What|Removed |Added

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

--- Comment #11 from Arseny Solokha  ---
Actually, testcase from comment 0 still ICEs for me, as well as its slightly
modified version:

subroutine foo()
  implicit none
  integer :: x
  integer :: a(0:1)

10 x = x + 1
20 if ((a(x) .ne. (-1)) .or. (a(x + 1) .ne. (-1))) then
 x = x + 1
 go to 20
  end if

  call undefined()
  go to 10

  return

end subroutine foo

% gfortran-13 -O1 -fpeel-loops -funreachable-traps -c comment0.f
during GIMPLE pass: cunroll
comment0.f:1:23:

1 |   SUBROUTINE YYPARS(LSTACK,YYPS,YYSTAT)
  |   ^
internal compiler error: in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:645
0x7804b7 check_loop_closed_ssa_def
   
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/tree-ssa-loop-manip.cc:645
0x10fc384 check_loop_closed_ssa_bb
   
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/tree-ssa-loop-manip.cc:659
0x10fd746 verify_loop_closed_ssa(bool, loop*)
   
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/tree-ssa-loop-manip.cc:695
0x10fd746 verify_loop_closed_ssa(bool, loop*)
   
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/tree-ssa-loop-manip.cc:679
0x10e5461 tree_unroll_loops_completely
   
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/tree-ssa-loop-ivcanon.cc:1499
0x10e54d1 execute
   
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/tree-ssa-loop-ivcanon.cc:1603
0x10e54d1 execute
   
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/gcc/tree-ssa-loop-ivcanon.cc:1593

% gfortran-13 -O1 -fpeel-loops -funreachable-traps -c comment11.f90
during GIMPLE pass: cunroll
comment11.f90:1:14:

1 | subroutine foo()
  |  ^
internal compiler error: in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:645


% gfortran-13 -v
Using built-in specs.
COLLECT_GCC=gfortran-13
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/13/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230205/work/gcc-13-20230205/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/13
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/13/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/13/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --disable-nls
--disable-libunwind-exceptions --enable-checking=yes
--with-gcc-major-version-only --enable-esp --enable-libstdcxx-time
--disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib
--with-multilib-list=m64 --disable-fixed-point --enable-targets=all
--enable-libgomp --disable-libssp --disable-libada --disable-cet
--disable-systemtap --enable-valgrind-annotations --disable-vtable-verify
--disable-libvtv --without-zstd --enable-lto --with-isl
--disable-isl-version-check --enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.1 20230205 (experimental) (GCC)

[Bug target/96342] [SVE] Add support for "omp declare simd"

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

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

--- Comment #10 from avieira at gcc dot gnu.org ---
yang I assume you are no longer working on this?

[Bug tree-optimization/108688] [13 Regression] error: ‘bit_field_ref’ of non-mode-precision operand

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||avieira at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
   Keywords|needs-bisection |

--- Comment #3 from Jakub Jelinek  ---
Slightly cleaned up:

union U { signed int d : 7; signed int e : 2; } u;
int a, b;

void
foo (void)
{
  for (int i = 0; i < 64; i++)
{
  u.d = a;
  u.e ^= b;
}
}

Yes, indeed started with r13-3219-g25413fdb2ac2493321 .

[Bug tree-optimization/108688] [13 Regression] error: ‘bit_field_ref’ of non-mode-precision operand

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

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

--- Comment #4 from Jakub Jelinek  ---
I think the bug is in the match.pd
/* Simplify a bit extraction from a bit insertion for the cases with
   the inserted element fully covering the extraction or the insertion
   not touching the extraction.  */
(simplify
 (BIT_FIELD_REF (bit_insert @0 @1 @ipos) @rsize @rpos)
 (with
  {
unsigned HOST_WIDE_INT isize;
if (INTEGRAL_TYPE_P (TREE_TYPE (@1)))
  isize = TYPE_PRECISION (TREE_TYPE (@1));
else
  isize = tree_to_uhwi (TYPE_SIZE (TREE_TYPE (@1)));
  }
  (switch
   (if (wi::leu_p (wi::to_wide (@ipos), wi::to_wide (@rpos))
&& wi::leu_p (wi::to_wide (@rpos) + wi::to_wide (@rsize),
  wi::to_wide (@ipos) + isize))
(BIT_FIELD_REF @1 @rsize { wide_int_to_tree (bitsizetype,
 wi::to_wide (@rpos)
 - wi::to_wide (@ipos)); }))
   (if (wi::geu_p (wi::to_wide (@ipos),
   wi::to_wide (@rpos) + wi::to_wide (@rsize))
|| wi::geu_p (wi::to_wide (@rpos),
  wi::to_wide (@ipos) + isize))
(BIT_FIELD_REF @0 @rsize @rpos)
which folds
  _ifc__35 = BIT_INSERT_EXPR <_ifc__34, _2, 0 (7 bits)>;
  _ifc__31 = BIT_FIELD_REF <_ifc__35, 2, 0>;
where 34/35 have unsigned char type, 31 signed:2 and 2 signed:7.

So, in this case it wants to extract low 2 bits out of the 7 bits _2 which is
invalid
because _2 doesn't have mode precision.  If it tried to extract 7 bits out of
it, we have:
(simplify
 (BIT_FIELD_REF @0 @1 integer_zerop)
 (if (tree_int_cst_equal (@1, TYPE_SIZE (TREE_TYPE (@0
  (view_convert @0)))
simplification but that one wouldn't trigger, because those signed:2 types have
TYPE_SIZE 8 rather than 7, only TYPE_PRECISION of 7.

[Bug tree-optimization/108688] [13 Regression] error: ‘bit_field_ref’ of non-mode-precision operand

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Oh I might have a fix for this already just didn't have a testcase for the
upstream compiler at the time.

[Bug middle-end/108715] Infinite loop in the generated assembly with -Os when strlen is defined in the code

[daniel at eyoman dot com via Gcc-bugs]

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

--- Comment #11 from Daniel Zaoui  ---
I checked on GCC 5.2.0 and 10.2 (RISC-V toolchain) and it doesn't happen.

I didn't understand what is the conclusion for the duplicate tickets. In
107415, it seems to be an expected behavior. Although I don't see how strlen
invoking strlen is a correct behavior.

Isn't there supposed to be a fix in GCC for that?

Thanks

[Bug middle-end/108715] Infinite loop in the generated assembly with -Os when strlen is defined in the code

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

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

--- Comment #12 from Jakub Jelinek  ---
While the strlen pattern recognition has been added later than memcpy/memset,
it is really the same thing.  With -ffreestanding which you are supposed to use
when you are providing C library yourself (or parts thereof as in this case)
they aren't recognized for years.  Without -ffreestanding,
-fno-tree-loop-distribute-patterns turns off those pattern recognitions.  As
mentioned in the other PR, while disabling pattern recognition of say memcpy
within function named memcpy and similarly for strlen wouldn't be that hard
(where currently without any of the above options we end up with tail
recursion), there is always the case where say memcpy could be implemented by
calling say memcpy_impl and only that one would contain the recognized pattern.
 Such indirect recursion would be much harder to deal with.

[Bug tree-optimization/108688] [13 Regression] error: ‘bit_field_ref’ of non-mode-precision operand

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

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Andrew Pinski from comment #5)
> Oh I might have a fix for this already just didn't have a testcase for the
> upstream compiler at the time.

Note, it is just the first case from the above because @0 already ought to be
guaranteed to have mode precision because BIT_INSERT_EXPR requires it too.
On the other side, we should for the first case differentiate between @1 has
mode precision, then we can do what we do right now, or when isize == rsize and
rpos == ipos (then we can just simplify to possibly casted @1) and finally
otherwise, IMHO we should just punt.

[Bug c++/108717] New: pasting """_" and "µm" does not give a valid preprocessing token in user-defined literal operator

[pacoarjonilla at yahoo dot es via Gcc-bugs]

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

Bug ID: 108717
   Summary: pasting """_" and "µm" does not give a valid
preprocessing token in user-defined literal operator
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pacoarjonilla at yahoo dot es
  Target Milestone: ---

The following code is accepted by clang and MSVC, but not GCC:

$ g++-13 --std=c++2b
'''
int operator""_µm(long double magnitude) noexcept // Micro sign, unicode 0x00b5
{
return magnitude;
}
'''
But character 'µ' is unicode XID_Start, so it should be accepted.

Compiler output:

:1:16: error: expected initializer before '\U00b5m'
1 | int operator""_µm(long double magnitude) noexcept \
  |^~
Compiler returned: 1

[Bug c++/108525] [13 Regression] ICE in write_method_parms with static on lambda with ... argument

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

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

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

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

commit r13-5737-ga58a4a57f9a4445f93b495f776f45e1118777e88
Author: Jakub Jelinek 
Date:   Wed Feb 8 13:57:00 2023 +0100

testsuite: Fix up PR108525 test [PR108525]

Seems when committing the PR108525 fix I've missed that a test with
the same name had been added a few hours before for PR108526.

This patch separates the PR108525 test into a new file.

2023-02-08  Jakub Jelinek  

PR c++/108525
* g++.dg/cpp23/static-operator-call5.C: Move PR108525 testcase
incorrectly applied into PR108526 testcase ...
* g++.dg/cpp23/static-operator-call6.C: ... here.  New test.

[Bug c++/108706] [13 Regression] Indefinite recursion when compiling gcc/testsuite/g++.dg/cpp23/static-operator-call5.C w/ -g

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-02-08
   Target Milestone|--- |13.0
   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Keywords||ABI

--- Comment #1 from Jakub Jelinek  ---
It is in the PR108526 part of the test (I've screwed up applying the PR108525
fix and fixed it in r13-5737).
The endless recursion is during mangling, I'm afraid I don't know how it should
mangle.

[Bug target/108316] [13 Regression] ICE in maybe_gen_insn via expand_SCATTER_STORE when vectorizing for SVE since r13-2737-g4a773bf2f08656

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

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

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

https://gcc.gnu.org/g:740a3be7df29b280f39a04c441fd4917af4eef5e

commit r13-5739-g740a3be7df29b280f39a04c441fd4917af4eef5e
Author: Richard Sandiford 
Date:   Wed Feb 8 13:40:29 2023 +

vect: Check gather/scatter offset types [PR108316]

The gather/scatter support can over-widen an offset if the target
requires it, but this relies on using a pattern sequence to add
the widening conversion.  That failed in the testcase because an
earlier pattern (bool) took priority.

I think we should allow patterns to be applied to other patterns,
but that's quite an invasive change and isn't suitable for stage 4.
This patch instead punts if the offset type doesn't match the
expected one.

If we switched to using the SLP representation for everything,
we would probably handle both patterns by rewriting the graph,
which should be much easier.

gcc/
PR tree-optimization/108316
* tree-vect-stmts.cc (get_load_store_type): When using
internal functions for gather/scatter, make sure that the type
of the offset argument is consistent with the offset vector type.

gcc/testsuite/
PR tree-optimization/108316
* gcc.dg/vect/pr108316.c: New test.

[Bug c/108718] New: csmith: possible bad code with -O2

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108718
   Summary: csmith: possible bad code with -O2
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

The attached C code, produced by csmith, does this:

$ ../results/bin/gcc -w -O1 bug883.c && ./a.out
checksum = 7A94E377
$ ../results/bin/gcc -w -O2 bug883.c && ./a.out
checksum = 842F1622
$ 

The bug seems to exist since sometime before 20220703

$ ../results.20220703/bin/gcc -w -O2 bug883.c && ./a.out
checksum = 842F1622
$ 

I will have a go at a reduction.

[Bug c++/108717] Greek letters not accepted as part of identifier in user-defined literal operators

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2023-02-08
 Ever confirmed|0   |1
   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW

[Bug target/108583] [13 Regression] wrong code with vector division by uint16 at -O2

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

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

--- Comment #24 from Tamar Christina  ---
> Sure that works I think, I'll do that then.

Just to check, I'm regtesting the patch, I assume you want me to revert the
hook as well right? Since nothing will be using it.

[Bug c/108718] csmith: possible bad code with -O2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Bisection shows the result is different between -O1 and -O2 since
r5-1351-gec18e2ebbf6a04097c7204032aba3f2646bede4a

[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
Summary|csmith: possible bad code   |[10/11/12/13 Regression]
   |with -O2|csmith: possible bad code
   ||with -O2
   Target Milestone|--- |10.5
 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Seems the testcase allows to be called with argument 1 and in that case it
prints verbose output, which between r11-1351^ and r11-1351 at -O2 differs
starting with:
--- 1   2023-02-08 09:10:13.0 -0500
+++ 2   2023-02-08 09:10:22.0 -0500
@@ -48,1210 +48,1210 @@ index = [2][2]
 index = [2][3]
 ...checksum after hashing g_5[i][j].f4 : ADCB0EBF
 index = [2][4]
-...checksum after hashing g_5[i][j].f4 : C953D56F
+...checksum after hashing g_5[i][j].f4 : 367D9AB8
 index = [2][5]
-...checksum after hashing g_5[i][j].f4 : 37A7B1F1
+...checksum after hashing g_5[i][j].f4 : 7EFE68AE
 index = [2][6]
-...checksum after hashing g_5[i][j].f4 : A0619D0A
+...checksum after hashing g_5[i][j].f4 : 6C5E59F1

The only changes in optimized dump as well as in assembly are in main.

[Bug ipa/108702] [13 Regression] ICE in get_partitioning_class, at symtab.cc:2096 since r13-4161-g32d16fe9d7e347bc

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[13 Regression] ICE in  |[13 Regression] ICE in
   |get_partitioning_class, at  |get_partitioning_class, at
   |symtab.cc:2096  |symtab.cc:2096 since
   ||r13-4161-g32d16fe9d7e347bc
   Last reconfirmed||2023-02-08
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started with r13-4161-g32d16fe9d7e347bc.

[Bug ipa/108695] [13 Regression] Wrong code since r13-5215-gb1f30bf42d8d47 for dd_rescue package

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

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

--- Comment #8 from Martin Liška  ---
Ok, one suspicious casting of memory comes from:

typedef union _roundkey {
unsigned char data[16];
unsigned int data32[4];
} roundkey;

...

typedef struct _sec_fields {
...
roundkey ekeys[40];

...
uchar *rkeys = (uchar*)crypto->ekeys;   //malloc(alg->ctx_size);

It's then passed to rijndaelEncrypt(const u8 *rkeys /*u32 rk[4*(Nr + 1)]*/,
uint Nr, const u8 pt[16], u8 ct[16])
 as the first argument, where it's later used as:

const u32 *rk = (u32*)rkeys;

Might be the violation we face? Here are mixed 'roundkey *' and 'u32*'.

[Bug ipa/108695] [13 Regression] Wrong code since r13-5215-gb1f30bf42d8d47 for dd_rescue package

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

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

--- Comment #9 from Martin Liška  ---
Actually, looking at the tree dumps before and after the revision, it's leading
to a different place:

First difference happens in:
test_aes.ltrans0.ltrans.116t.dse2

[local count: 8687547526]:
-  _118 = MEM[(ulong *)iv_4(D)];
-  _120 = MEM[(ulong *)input_19];
-  _121 = _118 ^ _120;
-  MEM[(ulong *)iv_4(D)] = _121;
-  _129 = MEM[(ulong *)iv_4(D) + 8B];
-  _131 = MEM[(ulong *)input_19 + 8B];
-  _132 = _129 ^ _131;
-  MEM[(ulong *)iv_4(D) + 8B] = _132;

(there's one more optimized out block like this. Which maps to:

int  AES_Gen_CBC_Enc(AES_Crypt_Blk_fn *cryptfn,
 const uchar* rkeys, uint rounds,
 uchar *iv, uint pad,
 const uchar *input, uchar *output,
 ssize_t len, ssize_t *olen)
{
*olen = len;
while (len >= 16) {
XOR16(iv, input, iv);
cryptfn(rkeys, rounds, iv, iv);
memcpy(output, iv, 16);
len -= 16; input += 16; output += 16;
}
if (len || pad == PAD_ALWAYS) {
uchar *in = crypto->blkbuf2;
fill_blk(input, in, len, pad);
XOR16(iv, in, iv);
cryptfn(rkeys, rounds, iv, output);
/* Store last IV */
memcpy(iv, output, 16);
*olen += 16-(len&15);
//memset(in, 0, 16);
//LFENCE;
}
return (pad == PAD_ALWAYS || (len&15))? 16-(len&15): 0;
}

where the XOR16 is implemented as:

#define XORN(in1,in2,out,len)   \
do {\
uint _i;\
for (_i = 0; _i < len/sizeof(ulong); ++_i)  \
*((ulong*)(out)+_i) = *((ulong*)(in1)+_i) ^
*((ulong*)(in2)+_i);\
} while(0)

[Bug ipa/108695] [13 Regression] Wrong code since r13-5215-gb1f30bf42d8d47 for dd_rescue package

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

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

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #10 from Martin Liška  ---
> where the XOR16 is implemented as:
> 
> #define XORN(in1,in2,out,len) \
> do {  \
>   uint _i;\
>   for (_i = 0; _i < len/sizeof(ulong); ++_i)  \
>   *((ulong*)(out)+_i) = *((ulong*)(in1)+_i) ^ 
> *((ulong*)(in2)+_i);\
> } while(0)

I can confirm that changing that to:

#define XORN(in1, in2, out, len)  \
do\
{ \
uint _i;  \
for (_i = 0; _i < len; ++_i)  \
*(out + _i) = *(in1 + _i) ^ *(in2 + _i); \
} while (0)

fixes the problem. It seems very close to what I saw here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83201#c13

[Bug ipa/108695] [13 Regression] Wrong code since r13-5215-gb1f30bf42d8d47 for dd_rescue package

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #11 from Sam James  ---
Can you drop a link in here if/when reported upstream? Thanks

[Bug ipa/108695] [13 Regression] Wrong code since r13-5215-gb1f30bf42d8d47 for dd_rescue package

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

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

--- Comment #12 from Martin Liška  ---
(In reply to Sam James from comment #11)
> Can you drop a link in here if/when reported upstream? Thanks

I was unable to find a bugzilla insntance for the dd_rescue project. Is there
any?

[Bug analyzer/108719] New: RFE: allow specifying argument indexes for __attribute__((tainted_args))

[clopez at suse dot de via Gcc-bugs]

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

Bug ID: 108719
   Summary: RFE: allow specifying argument indexes for
__attribute__((tainted_args))
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: clopez at suse dot de
  Target Milestone: ---

Consider allowing developers to specify which function arguments are tainted,
very much like the nonnull attribute, e.g.:

__attribute__((tainted_args (2, 3)))

When no indexes are specified, all arguments should be considered tainted -
this is the behavior currently implemented.

Specifically, there is a common pattern for callbacks where the first argument
corresponds to untainted data (often either a structure provided by caller of
the callback or some opaque pointer requested by the callee). A prime example
of this are Linux device drivers, where the first parameter is a
kernel-provided structure:

struct file_operations {
...
ssize_t (*read) (struct file *, char *, size_t, loff_t *);
ssize_t (*write) (struct file *, const char *, size_t, loff_t *);
...
}

Another example would be qemu MMIO callbacks:

struct MemoryRegionOps {
uint64_t (*read)(void *opaque, hwaddr addr, unsigned size);
void (*write)(void *opaque, hwaddr addr, uint64_t data, unsigned size);
...
}

[Bug ipa/108695] [13 Regression] Wrong code since r13-5215-gb1f30bf42d8d47 for dd_rescue package

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

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

--- Comment #13 from Martin Liška  ---
Got it:
https://sourceforge.net/p/ddrescue/tickets/6/

[Bug ipa/108695] [13 Regression] Wrong code since r13-5215-gb1f30bf42d8d47 for dd_rescue package

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

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

--- Comment #14 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #10)
> > where the XOR16 is implemented as:
> > 
> > #define XORN(in1,in2,out,len)   \
> > do {\
> > uint _i;\
> > for (_i = 0; _i < len/sizeof(ulong); ++_i)  \
> > *((ulong*)(out)+_i) = *((ulong*)(in1)+_i) ^ 
> > *((ulong*)(in2)+_i);\
> > } while(0)
> 
> I can confirm that changing that to:
> 
> #define XORN(in1, in2, out, len)  \
>   do\
>   { \
>   uint _i;  \
>   for (_i = 0; _i < len; ++_i)  \
>   *(out + _i) = *(in1 + _i) ^ *(in2 + _i); \
>   } while (0)
> 
> fixes the problem. It seems very close to what I saw here:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83201#c13

It depends on if those arrays were stored as ulong or will be later read as
ulong or something else.
One could also use typedef ulong ulong_alias __attribute__((may_alias));
and use ulong_alias* above, or memcpy to/out of ulong temporaries.

[Bug ipa/108695] [13 Regression] Wrong code since r13-5215-gb1f30bf42d8d47 for dd_rescue package

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

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

--- Comment #15 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to Martin Liška from comment #10)
> > > where the XOR16 is implemented as:
> > > 
> > > #define XORN(in1,in2,out,len) \
> > > do {  \
> > >   uint _i;\
> > >   for (_i = 0; _i < len/sizeof(ulong); ++_i)  \
> > >   *((ulong*)(out)+_i) = *((ulong*)(in1)+_i) ^ 
> > > *((ulong*)(in2)+_i);\
> > > } while(0)
> > 
> > I can confirm that changing that to:
> > 
> > #define XORN(in1, in2, out, len)  \
> > do\
> > { \
> > uint _i;  \
> > for (_i = 0; _i < len; ++_i)  \
> > *(out + _i) = *(in1 + _i) ^ *(in2 + _i); \
> > } while (0)
> > 
> > fixes the problem. It seems very close to what I saw here:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83201#c13
> 
> It depends on if those arrays were stored as ulong or will be later read as
> ulong or something else.

Yes, that's what happens, they are stored with the aforementioned XORN function
as ulong types. And later are read with 
#define GETU32(p) ntohl(*((u32*)(p)))
as u32. That's the aliasing violation.

[Bug ipa/108702] [13 Regression] ICE in get_partitioning_class, at symtab.cc:2096 since r13-4161-g32d16fe9d7e347bc

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

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

--- Comment #2 from Jakub Jelinek  ---
Without -flto, the testcase can't be linked:
./cc1plus -quiet -std=c++23 stmtexpr19.C; g++ -o stmtexpr19{,.s}
/usr/bin/ld: /tmp/ccUo7FRx.o:(.rodata+0x0): undefined reference to
`setup()::inner'
collect2: error: ld returned 1 exit status

On the other side, when static constexpr vars are defined inside of constexpr
functions or even consteval functions, it works ok:

extern "C" void abort ();

constexpr const int *
foo ()
{
  static constexpr int a = 1;
  return &a;
}

consteval const int *
bar ()
{
  static constexpr int a = 1;
  return &a;
}

[[gnu::noipa]] void
baz (const int *x)
{
  if (*x != 1)
abort ();
}

int
main ()
{
  constexpr const int *p = foo ();
  constexpr const int *q = bar ();
  baz (p);
  baz (q);
  if (p == q)
abort ();
}

[Bug tree-optimization/108688] [13 Regression] error: ‘bit_field_ref’ of non-mode-precision operand

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
I did mention about this exact match.pd pattern issue in bug 88739 comment #63,
I have a slightly simplified patch from that one referenced there too.

[Bug target/108163] mesa LTO compiling ICEs with unable to generate reloads for neon_vld4qav16qi on arm-linux-gnueabihf

[david at ixit dot cz via Gcc-bugs]

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

--- Comment #2 from David Heidelberg (okias)  ---
I have suspicion it could be some parts of mesa compiled with

-mfpu=neon

while other parts are compiled without this option explicitly stated.

I think the test case could be passing it to different parts of the code which
gets interlinked.

[Bug tree-optimization/108688] [13 Regression] error: ‘bit_field_ref’ of non-mode-precision operand

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

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

--- Comment #8 from Andrew Pinski  ---
Created attachment 54433
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54433&action=edit
Patch which I had around and will be testing

I had this patch around while I was working on full bitfield lowering.

[Bug c/108720] New: INT_MIN * -1 is incorrect

[amk7r at mtmail dot mtsu.edu via Gcc-bugs]

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

Bug ID: 108720
   Summary: INT_MIN * -1 is incorrect
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amk7r at mtmail dot mtsu.edu
  Target Milestone: ---

Created attachment 54434
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54434&action=edit
Attached is a file with the source code (.c) and the preprocessed file (.i)

Version of GCC: 11.3.0
System type: Ubuntu 22.04.1 LTS
Options given when GCC was configured/built: ../src/configure -v
--with-pkgversion='Ubuntu 11.3.0-1ubuntu1~22.04'
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2

Complete command line that triggers the bug: gcc err_file.c

The compiler output (error messages, warnings, ect.): n/a; there were no errors
or warnings
Expected behavior: 
   The program should print out the value of y, and then print out “true 4” 
   because -INT_MIN  is equal to INT_MIN, which is less than 0.
Actual behavior: 
   The program prints out the value of y, and then prints out “true 2.”  
   Case 1: y>= 0. "true 1" should not be printed because y is INT_MIN.  -> Test
Pass
   Case 2: (x-1)>= 0. "true 2" should not be printed because x is INT_MIN. ->
Test Fail
 o INT_MIN * -1 = INT_MIN.  
   Case 3: (x-1)>= zero. "true 3" should not be printed because x is INT_MIN. 
-> Test Pass
 o INT_MIN * -1 = INT_MIN and int zero has 0 
   Case 4: (x-1)< 0. "true 4" should be printed because x is INT_MIN. 
 o INT_MIN * -1 = INT_MIN and INT_MIN is less than 0 -> Test Fail

More information:
If you translate the C code into assembly code using the command “gcc -s
err_file.c,” and check the .L2 block: 
In .L2:
The assembly code should be:  
#equivalent c code
cmpl $0, -8(%rbp) #because it has the result of x * -1 
 if ((x*-1)>=0)  
js .L3#instead of jg .L3 

Explanation:
* x *-1 is INT_MIN. 
* “jg” instruction will skip the statement in “if block” if (x*-1) or
INT_MIN is greater than 0. 
* Since, (x*-1) or INT_MIN is not greater than 0, the statement in the
“if block” is printed (“true 2”).
* But “true 2” should only be printed if (x*-1) or INT_MIN is greater
than or equal to 0 (check c code line 9).
* In this case, doing  “js .L3” would make more sense and will give the
expected result.

[Bug c/108720] INT_MIN * -1 is incorrect

[amk7r at mtmail dot mtsu.edu via Gcc-bugs]

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

--- Comment #1 from Abigail Kelly  ---
Created attachment 54435
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54435&action=edit
preprocessed file

[Bug c/108720] INT_MIN * -1 is incorrect

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
INT_MIN * -1 or -INT_MIN is undefined behavior in C/C++, so any expectations
about it are incorrect.

[Bug c/108720] INT_MIN * -1 is incorrect

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

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

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

int x = 
# 6 "err_file.c" 3 4
   (-0x7fff - 1)
# 6 "err_file.c"
  ;
int y = x * -1;


x*-1 invokes undefined behavior because signed integer overflow is undefined.
So anything can happen after undefined behavior including but not limited to
inconsistent results.

You can detect signed integer overflow at run time with -fsanitize=undefined.

[Bug c/108720] INT_MIN * -1 is incorrect

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

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

--- Comment #4 from Andrew Pinski  ---
Also if you want to make signed integer overflow as being defined, you can use
-fwrapv .

[Bug c/108721] New: csmith: really old bug with -O2

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108721
   Summary: csmith: really old bug with -O2
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

For the attached C code, generated from csmith, does this:

$ ../results/bin/gcc -w -O1 bug884.c && ./a.out
checksum = 749D4681
$ ../results/bin/gcc -w -O2 bug884.c && ./a.out
checksum = F8019D24
$ 

The bug seems to exist since sometime before 20220206, about a year ago.

$ ../results.20220206/bin/gcc -w -O2 bug884.c && ./a.out
checksum = F8019D24
$ 

The git hash for 20220206 is g:8eb329e963593342855b6072e5692659107337b7

[Bug middle-end/108721] csmith: really old bug with -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end

--- Comment #1 from Andrew Pinski  ---
There could be aliasing issues here as -fno-strict-aliasing fixes the issue ...

[Bug c/108721] [10/11/12/13 Regression] csmith: really old bug with -O2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|csmith: really old bug with |[10/11/12/13 Regression]
   |-O2 |csmith: really old bug with
   ||-O2
   Priority|P3  |P2
  Component|middle-end  |c
 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |10.5

--- Comment #2 from Jakub Jelinek  ---
This one bisected to differences starting with
r0-107468-g605896f5527472717f9fe91ad90f9ce3778cc540

[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2

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

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

--- Comment #3 from Andrew Pinski  ---
This also changes with  -fno-strict-aliasing  ...

[Bug tree-optimization/108696] querying relations is slow

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #1 from Andrew Macleod  ---
I think that change will end up missing equivalences and transitives.  The
m_relation_set bitmap is only used to track non-equivalence relations
registered with the oracle. Equivalences are handled separately in the
equivalence oracle.

The speedup you are seeing is likely because it is bailing on checking for
equivalences and transitive relations through equivalences.

[Bug c++/108702] [13 Regression] ICE in get_partitioning_class, at symtab.cc:2096 since r13-4161-g32d16fe9d7e347bc

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Component|ipa |c++
   Priority|P3  |P1
 CC||jason at gcc dot gnu.org
   Target Milestone|--- |13.0

--- Comment #3 from Jakub Jelinek  ---
Seems the reason why the above testcase works and stmtexpr19.C doesn't is in
make_rtl_for_nonlocal_decl's
7732  /* We defer emission of local statics until the corresponding
7733 DECL_EXPR is expanded.  But with constexpr its function might
never
7734 be expanded, so go ahead and tell cgraph about the variable now. 
*/
7735  defer_p = ((DECL_FUNCTION_SCOPE_P (decl)
7736  && !var_in_maybe_constexpr_fn (decl))
7737 || DECL_VIRTUAL_P (decl));
while in stmtexpr19.C the inner decl isn't in constexpr fn, it is in a
statement expression inside of a static variable initializer.
The initializer evaluates to constant expression (ADDR_EXPR of inner), so the
statement expression disappears and so there is no DECL_EXPR for the inner var
nor any reasonable spot to stick it to.

I think the options are somehow discover these before they are folded away and
mark them some way, so that we don't defer_p them or otherwise arrange for
rest_of_decl_compilation to be done on them later, or, as statement expressions
are a GNU extension, simply declare that such variables in statement
expressions cause it to be not a constant expression, only DECL_EXPRs of
var_in_maybe_constexpr_fn (decl) would be accepted.
Or, do we ever need to defer_p the static variables we are talking about here
(i.e. constexpr ones or ones with constant initializers, for which it really
doesn't matter where exactly we initialize them because they are initialized in
.rodata already.

[Bug c++/108717] Greek letters not accepted as part of identifier in user-defined literal operators

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

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

--- Comment #1 from Andrew Pinski  ---
It works with normal identifiers though:
int µm = 1;

[Bug c++/108717] Greek letters not accepted as part of identifier in user-defined literal operators

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

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

--- Comment #2 from Andrew Pinski  ---
This is accepted:
```
int operator"" _µm(long double magnitude) noexcept // Micro sign, unicode
0x00b5
{
return magnitude;
}
```

NOTE the space.

[Bug c++/108717] Greek letters not accepted as part of identifier in user-defined literal operators without a space

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Dup of bug 103902.

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

[Bug preprocessor/103902] GCC requires a space between string-literal and identifier in a literal-operator-id where the identifier is not in basic character set

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

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

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

[Bug tree-optimization/108692] [11/12/13 Regression] Miscompilation of orc_test.c since r11-5160

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

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

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

https://gcc.gnu.org/g:6ad1c1027628f094260037536f6b6fcdb63b5add

commit r13-5742-g6ad1c1027628f094260037536f6b6fcdb63b5add
Author: Jakub Jelinek 
Date:   Wed Feb 8 18:41:21 2023 +0100

vect-patterns: Fix up vect_widened_op_tree [PR108692]

The following testcase is miscompiled on aarch64-linux since r11-5160.
Given
   [local count: 955630225]:
  # i_22 = PHI 
  # r_23 = PHI 
...
  a.0_5 = (unsigned char) a_15;
  _6 = (int) a.0_5;
  b.1_7 = (unsigned char) b_17;
  _8 = (int) b.1_7;
  c_18 = _6 - _8;
  _9 = ABS_EXPR ;
  r_19 = _9 + r_23;
...
where SSA_NAMEs 15/17 have signed char, 5/7 unsigned char and rest is int
we first pattern recognize c_18 as
patt_34 = (a.0_5) w- (b.1_7);
which is still correct, 5/7 are unsigned char subtracted in wider type,
but then vect_recog_sad_pattern turns it into
SAD_EXPR 
which is incorrect, because 15/17 are signed char and so it is
sum of absolute signed differences rather than unsigned sum of
absolute unsigned differences.
The reason why this happens is that vect_recog_sad_pattern calls
vect_widened_op_tree with MINUS_EXPR, WIDEN_MINUS_EXPR on the
patt_34 = (a.0_5) w- (b.1_7); statement's vinfo and vect_widened_op_tree
calls vect_look_through_possible_promotion on the operands of the
WIDEN_MINUS_EXPR, which looks through the further casts.
vect_look_through_possible_promotion has careful code to stop when there
would be nested casts that need to be preserved, but the problem here
is that the WIDEN_*_EXPR operation itself has an implicit cast on the
operands already - in this case of WIDEN_MINUS_EXPR the unsigned char
5/7 SSA_NAMEs are widened to unsigned short before the subtraction,
and vect_look_through_possible_promotion obviously isn't told about that.

Now, I think when we see those WIDEN_{MULT,MINUS,PLUS}_EXPR codes, we had
to look through possible promotions already when creating those and so
vect_look_through_possible_promotion again isn't really needed, all we need
to do is arrange what that function will do if the operand isn't result
of any cast.  Other option would be let
vect_look_through_possible_promotion
know about the implicit promotion from the WIDEN_*_EXPR, but I'm afraid
that would be much harder.

2023-02-08  Jakub Jelinek  

PR tree-optimization/108692
* tree-vect-patterns.cc (vect_widened_op_tree): If rhs_code is
widened_code which is different from code, don't call
vect_look_through_possible_promotion but instead just check op is
SSA_NAME with integral type for which vect_is_simple_use is true
and call set_op on this_unprom.

* gcc.dg/pr108692.c: New test.

[Bug tree-optimization/108692] [11/12 Regression] Miscompilation of orc_test.c since r11-5160

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12/13 Regression]   |[11/12 Regression]
   |Miscompilation of   |Miscompilation of
   |orc_test.c since r11-5160   |orc_test.c since r11-5160

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

[Bug middle-end/108715] Infinite loop in the generated assembly with -Os when strlen is defined in the code

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #13 from Andrew Pinski  ---
Dup of bug 102725.

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

[Bug tree-optimization/102725] -fno-builtin leads to call of strlen since r12-4283-g6f966f06146be768

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||daniel at eyoman dot com

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

[Bug target/108722] New: gcc.dg/analyzer/file-CWE-1341-example.c fails on power 9 BE

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

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

Bug ID: 108722
   Summary: gcc.dg/analyzer/file-CWE-1341-example.c fails on power
9 BE
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:9ada45967b4cf543aa47091e99a760d0718013cc, r13-4218-g9ada45967b4cf5

This is only failing on a power 9 BE machine.  It fails since the test case's
introduction.

make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
analyzer.exp=gcc.dg/analyzer/file-CWE-1341-example.c"
FAIL: gcc.dg/analyzer/file-CWE-1341-example.c (test for excess errors)
# of expected passes3
# of unexpected failures1

spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/file-CWE-1341-example.c
-m32 -fdiagnostics-plain-output -fanalyzer -Wanalyzer-too-complex
-fanalyzer-call-summaries -S -o file-CWE-1341-example.s
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/file-CWE-1341-example.c:
In function 'example_1':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/file-CWE-1341-example.c:38:16:
warning: double 'fclose' of FILE 'f' [CWE-1341] [-Wanalyzer-double-fclose]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/file-CWE-1341-example.c:29:13:
note: (1) opened here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/file-CWE-1341-example.c:30:6:
note: (2) assuming 'f' is non-NULL
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/file-CWE-1341-example.c:30:6:
note: (3) following 'true' branch (when 'f' is non-NULL)...
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/file-CWE-1341-example.c:32:12:
note: (4) ...to here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/file-CWE-1341-example.c:35:16:
note: (5) first 'fclose' here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/file-CWE-1341-example.c:38:16:
note: (6) second 'fclose' here; first 'fclose' was at (5)
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/file-CWE-1341-example.c:38:16:
warning: double-'fclose' of 'f' [CWE-415] [-Wanalyzer-double-free]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/file-CWE-1341-example.c:29:13:
note: (1) allocated here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/file-CWE-1341-example.c:30:6:
note: (2) assuming 'f' is non-NULL
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/file-CWE-1341-example.c:30:6:
note: (3) following 'true' branch (when 'f' is non-NULL)...
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/file-CWE-1341-example.c:32:12:
note: (4) ...to here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/file-CWE-1341-example.c:35:16:
note: (5) first 'fclose' here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/file-CWE-1341-example.c:38:16:
note: (6) second 'fclose' here; first 'fclose' was at (5)
PASS: gcc.dg/analyzer/file-CWE-1341-example.c  (test for warnings, line 29)
PASS: gcc.dg/analyzer/file-CWE-1341-example.c  (test for warnings, line 35)
PASS: gcc.dg/analyzer/file-CWE-1341-example.c  (test for warnings, line 38)
Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/  exceptions_enabled4193687.cc  -m32 
 -fdiagnostics-plain-output  -S -o exceptions_enabled4193687.s(timeout =
300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled4193687.cc -m32
-fdiagnostics-plain-output -S -o exceptions_enabled4193687.s
FAIL: gcc.dg/analyzer/file-CWE-1341-example.c (test for excess errors)
Excess errors:
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/file-CWE-1341-example.c:38:16:
warning: double-'fclose' of 'f' [CWE-415] [-Wanalyzer-double-free]

[Bug middle-end/108715] Infinite loop in the generated assembly with -Os when strlen is defined in the code

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

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

--- Comment #14 from Jakub Jelinek  ---
It isn't really a dup, that other PR is about strlen pattern in some function
with a different name.

[Bug tree-optimization/108696] querying relations is slow

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #2 from Andrew Macleod  ---
Created attachment 54437
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54437&action=edit
possible patch

This patch should successfully short circuit unnecessary checks. untested in
compiler.i

Where did you get a 17% time in DOM?  when I run compiler.i I get
dominator optimization :  38.28 (  2%) 
where most of the time is in
machine dep reorg  :1447.64 ( 60%) 

I'll check this patch for correctness and to see if it generally makes any time
improvements that are measurable elsewhere.

[Bug middle-end/108715] Infinite loop in the generated assembly with -Os when strlen is defined in the code

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

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

--- Comment #15 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #14)
> It isn't really a dup, that other PR is about strlen pattern in some
> function with a different name.

PR 103858 was also marked as a dup much earlier.
I think the original code in valgrind (which PR 102725 is about) used strlen as
the name of the function and the reporter change the name just to show what was
happening ...

[Bug tree-optimization/108696] querying relations is slow

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #3 from rguenther at suse dot de  ---
> Am 08.02.2023 um 18:50 schrieb amacleod at redhat dot com 
> :
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108696
> 
> --- Comment #2 from Andrew Macleod  ---
> Created attachment 54437
>  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54437&action=edit
> possible patch
> 
> This patch should successfully short circuit unnecessary checks. untested in
> compiler.i
> 
> Where did you get a 17% time in DOM?

When using -O1 as recommended for this kind of testcase.

>  when I run compiler.i I get
> dominator optimization :  38.28 (  2%) 
> where most of the time is in
> machine dep reorg  :1447.64 ( 60%) 

Ah. Another thing to investigate…

> 
> I'll check this patch for correctness and to see if it generally makes any 
> time
> improvements that are measurable elsewhere.
> 
> -- 
> You are receiving this mail because:
> You reported the bug.

[Bug rtl-optimization/108711] [13 Regression] ICE in get_equiv, at lra-constraints.cc:534

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Patch was reverted by r13-5738-gad2bd0ad0413c2448fee0d4a

[Bug fortran/103259] [11/12/13 Regression] ICE in resolve_common_vars, at fortran/resolve.c:956 since r11-3866-g4d2a56a0f7135469

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

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

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

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

commit r13-5743-g7e9f20f5517429cfaadec14d6b04705e59078565
Author: Steve Kargl 
Date:   Tue Feb 7 20:18:42 2023 +0100

Fortran: error handling of global entity appearing in COMMON block
[PR103259]

gcc/fortran/ChangeLog:

PR fortran/103259
* resolve.cc (resolve_common_vars): Avoid NULL pointer dereference
when a symbol's location is not set.

gcc/testsuite/ChangeLog:

PR fortran/103259
* gfortran.dg/pr103259.f90: New test.

[Bug target/108505] [13 Regression] Arm: arm-none-eabi toolchain build failing with compiler error.

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by SRINATH PARVATHANENI
:

https://gcc.gnu.org/g:2eeda82d6288fb2a8fbc302d98ed51337e01

commit r13-5744-g2eeda82d6288fb2a8fbc302d98ed51337e01
Author: Srinath Parvathaneni 
Date:   Wed Feb 8 18:39:06 2023 +

arm: Optimize arm-mlib.h header inclusion [pr108505].

I have committed a fix [1] into gcc trunk for a build
issue mentioned in pr108505 and latter received few upstream
comments proposing more robust fix for this issue.

In this patch I'm addressing those comments and sending this
as a followup patch.

gcc/ChangeLog:

2023-01-27  Srinath Parvathaneni  

PR target/108505
* config.gcc (tm_mlib_file): Define new variable.

[Bug analyzer/108704] [13 Regression] Many -Wanalyzer-use-of-uninitialized-value false positives seen in qemu's softfloat.c

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

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

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

https://gcc.gnu.org/g:77bb54b1b07add45007c664724b726541d672ef3

commit r13-5745-g77bb54b1b07add45007c664724b726541d672ef3
Author: David Malcolm 
Date:   Wed Feb 8 13:47:36 2023 -0500

analyzer: fix overzealous state purging with on-stack structs [PR108704]

PR analyzer/108704 reports many false positives seen from
-Wanalyzer-use-of-uninitialized-value on qemu's softfloat.c on code like
the following:

   struct st s;
   s = foo ();
   s = bar (s); // bogusly reports that s is uninitialized here

where e.g. "struct st" is "floatx80" in the qemu examples.

The root cause is overzealous purging of on-stack structs in the code I
added in r12-7718-gfaacafd2306ad7, where at:

s = bar (s);

state_purge_per_decl::process_point_backwards "sees" the assignment to 's'
and stops processing, effectively treating 's' as unneeded before this
stmt, not noticing the use of 's' in the argument.

Fixed thusly.

The patch greatly reduces the number of
-Wanalyzer-use-of-uninitialized-value warnings from my integration tests:
  ImageMagick-7.1.0-57:  10 ->  6   (-4)
  qemu-7.2: 858 -> 87 (-771)
 haproxy-2.7.1:   1 ->  0   (-1)
All of the above that I've examined appear to be false positives.

gcc/analyzer/ChangeLog:
PR analyzer/108704
* state-purge.cc (state_purge_per_decl::process_point_backwards):
Don't stop processing the decl if it's fully overwritten by
this stmt if it's also used by this stmt.

gcc/testsuite/ChangeLog:
PR analyzer/108704
* gcc.dg/analyzer/uninit-7.c: New test.
* gcc.dg/analyzer/uninit-pr108704.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/108704] Many -Wanalyzer-use-of-uninitialized-value false positives seen in qemu's softfloat.c

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

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

David Malcolm  changed:

   What|Removed |Added

Summary|[13 Regression] Many|Many
   |-Wanalyzer-use-of-uninitial |-Wanalyzer-use-of-uninitial
   |ized-value false positives  |ized-value false positives
   |seen in qemu's softfloat.c  |seen in qemu's softfloat.c

--- Comment #4 from David Malcolm  ---
Should be fixed on trunk for GCC 13 by the above commit.

I introduced the bug in r12-7718-gfaacafd2306ad7 so in theory it affects GCC 12
as well, but I haven't been able to reproduce it there.  The bug is probably
present there but latent, so I'm keeping this bug open to track backporting the
fix to the gcc 12 branch.

[Bug testsuite/108723] New: [13 Regression] Recent changes broke risc-v testsuite

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

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

Bug ID: 108723
   Summary: [13 Regression] Recent changes broke risc-v testsuite
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at gcc dot gnu.org
  Target Milestone: ---

This change:

commit 3cd08f7168c196d7a481b9ed9f4289fd1f14eea8 (refs/bisect/bad)
Author: Andreas Schwab 
Date:   Wed Jan 25 12:00:09 2023 +0100

riscv: Enable -fasynchronous-unwind-tables by default on Linux

Broke several tests in the risc-v testsuite for riscv64-unknown-linux-gnu:

FAIL: gcc.target/riscv/shorten-memrefs-2.c   -Os   scan-assembler
store1a:\n\taddi
FAIL: gcc.target/riscv/shorten-memrefs-2.c   -Os   scan-assembler
load1r:\n\taddi
FAIL: gcc.target/riscv/shorten-memrefs-2.c   -Os   scan-assembler
load2r:\n\taddi
XPASS: gcc.target/riscv/shorten-memrefs-3.c   -Os   scan-assembler-not
load1a:\n\taddi
FAIL: gcc.target/riscv/shorten-memrefs-5.c   -Os   scan-assembler
store1a:\n\taddi
FAIL: gcc.target/riscv/shorten-memrefs-5.c   -Os   scan-assembler
load1r:\n\taddi
XPASS: gcc.target/riscv/shorten-memrefs-6.c   -Os   scan-assembler-not
load1a:\n\taddi
FAIL: gcc.target/riscv/shorten-memrefs-8.c   -Os   scan-assembler
store:\n\taddi\ta[0-7],a[0-7],1
FAIL: gcc.target/riscv/shorten-memrefs-8.c   -Os   scan-assembler
load:\n\taddi\ta[0-7],a[0-7],1


I'm pretty sure the change causes new labels to be inserted in places where the
scan-assembler strings are not expecting to find them.

[Bug c++/107079] [10/11/12/13 Regression] ICE initializing lifetime-extended constexpr variable that stores its this pointer

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
I'll post...something.

[Bug tree-optimization/108684] [12/13 Regression] ICE: verify_ssa failed

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-Februar
   ||y/611584.html
   Keywords||patch

--- Comment #11 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611584.html

[Bug target/108724] New: [11 regression] Poor codegen when summing two arrays without AVX or SSE

[gbs at canishe dot com via Gcc-bugs]

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

Bug ID: 108724
   Summary: [11 regression] Poor codegen when summing two arrays
without AVX or SSE
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gbs at canishe dot com
  Target Milestone: ---

This program:

void foo(int *a, const int *__restrict b, const int *__restrict c)
{
  for (int i = 0; i < 16; i++) {
a[i] = b[i] + c[i];
  }
}


When compiled for x86 by GCC 11.1+ with -O3 -mno-avx -mno-sse, produces:

foo:
movq%rdx, %rax
subq$8, %rsp
movl(%rsi), %edx
movq%rsi, %rcx
addl(%rax), %edx
movl4(%rax), %esi
movq$0, (%rsp)
movl%edx, (%rsp)
movq(%rsp), %rdx
addl4(%rcx), %esi
movq%rdx, -8(%rsp)
movl%esi, -4(%rsp)
movq-8(%rsp), %rdx
movq%rdx, (%rdi)
movl8(%rax), %edx
addl8(%rcx), %edx
movq$0, -16(%rsp)
movl%edx, -16(%rsp)
movq-16(%rsp), %rdx
movl12(%rcx), %esi
addl12(%rax), %esi
movq%rdx, -24(%rsp)
movl%esi, -20(%rsp)
movq-24(%rsp), %rdx
movq%rdx, 8(%rdi)
[snip more of the same]
movl48(%rcx), %edx
movq$0, -96(%rsp)
addl48(%rax), %edx
movl%edx, -96(%rsp)
movq-96(%rsp), %rdx
movl52(%rcx), %esi
addl52(%rax), %esi
movq%rdx, -104(%rsp)
movl%esi, -100(%rsp)
movq-104(%rsp), %rdx
movq%rdx, 48(%rdi)
movl56(%rcx), %edx
movq$0, -112(%rsp)
addl56(%rax), %edx
movl%edx, -112(%rsp)
movq-112(%rsp), %rdx
movl60(%rcx), %ecx
addl60(%rax), %ecx
movq%rdx, -120(%rsp)
movl%ecx, -116(%rsp)
movq-120(%rsp), %rdx
movq%rdx, 56(%rdi)
addq$8, %rsp
ret

(Godbolt link: https://godbolt.org/z/qq9dbP8ed)

This is bizarre - it's storing intermediate results on the stack, instead of
keeping them in registers or writing them directly to *a, which is bound to be
slow. (GCC 10.4, and Clang, produce more or less what I would expect, using
only the provided arrays and a register.) I haven't done any benchmarking
myself, but Jonathan Wakely's results (on list:
https://gcc.gnu.org/pipermail/gcc-help/2023-February/142181.html) seem to bear
this out.

>From a bisect, this behavior seems to have been introduced by commit
33c0f246f799b7403171e97f31276a8feddd05c9 (tree-optimization/97626 - handle SCCs
properly in SLP stmt analysis) from Oct 2020, and persists into GCC trunk.

[Bug tree-optimization/108724] Poor codegen when summing two arrays without AVX or SSE

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
Summary|[11 regression] Poor|Poor codegen when summing
   |codegen when summing two|two arrays without AVX or
   |arrays without AVX or SSE   |SSE
  Component|target  |tree-optimization

--- Comment #1 from Andrew Pinski  ---
I noticed that on aarch64, with -mgeneral-regs-only, the problem of trying to
do a vectorization has been there since at least GCC 5 ...

[Bug middle-end/108712] Missing optimization with memory-barrier

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||inline-asm,
   ||missed-optimization

--- Comment #2 from Andrew Pinski  ---
The inline-asm is causing GCC not to optimize the code.
Doing the following on x86_64 allows GCC to optimize the g load/stores out of
the loop:
static volatile int flag;
static int g; 

void func(void) {
for(int i = 0; i < 20; i++) {
++g;
if (flag) {
flag = 0;
}
 }
}

[Bug analyzer/108725] New: -Wanalyzer-use-of-uninitialized-value on ternary pointer access seen in qemu-7.2.0's dump/win_dump.c

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

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

Bug ID: 108725
   Summary: -Wanalyzer-use-of-uninitialized-value on ternary
pointer access seen in qemu-7.2.0's dump/win_dump.c
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54438
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54438&action=edit
Reproducer

We get two false positives from the attached at -O1 and above, with both trunk
and gcc 12:

Trunk: https://godbolt.org/z/KboceYY7q
GCC 12.2: https://godbolt.org/z/jEPa6vaPd

: In function 'cpu_read_ptr':
:15:24: warning: use of uninitialized value 'ptr64' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
   15 | *ptr = x64 ? ptr64 : ptr32;
  |^~~
  'cpu_read_ptr': events 1-5
|
|   11 | uint64_t ptr64;
|  |  ^
|  |  |
|  |  (1) region created on stack here
|  |  (2) capacity: 8 bytes
|..
|   15 | *ptr = x64 ? ptr64 : ptr32;
|  |~~~
|  ||
|  |(3) following 'true' branch (when 'x64 !=
0')...
|  |(4) ...to here
|  |(5) use of uninitialized value 'ptr64' here
|
:15:24: warning: use of uninitialized value 'ptr32' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
   15 | *ptr = x64 ? ptr64 : ptr32;
  |^~~
  'cpu_read_ptr': events 1-5
|
|   10 | uint32_t ptr32;
|  |  ^
|  |  |
|  |  (1) region created on stack here
|  |  (2) capacity: 4 bytes
|..
|   15 | *ptr = x64 ? ptr64 : ptr32;
|  |~~~
|  ||
|  |(3) following 'false' branch (when 'x64 ==
0')...
|  |(4) ...to here
|  |(5) use of uninitialized value 'ptr32' here
|
Compiler returned: 0

where the analyzer isn't treating the argument pointer as potentially having
been written through (presumably confused by the ternary operator).