[Bug tree-optimization/109271] New: Unnecessary vectorization alias versioning check

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

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

Bug ID: 109271
   Summary: Unnecessary vectorization alias versioning check
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Split out from PR80198

void __attribute__((noipa)) generic(int * a, int * b, int c)
{
  int i;
  a = __builtin_assume_aligned (a, 16);
  b = __builtin_assume_aligned (b, 16);
  for (i=0; i < 256; i++) {
  a[i] = b[i] | c;
  }
}

is versioned for aliasing by the vectorizer, not realizing the alignment
guarantees allow vectorizing with 16byte vectors without.  Actually
the CCP pass after the vectorizer is able to elide the check, so this
but is merely to track the cost side of this (also when mixed with
a more complex required versioning check it might fail to optimize later).

[Bug tree-optimization/80198] [10/11/12/13 Regression] does not vectorize generic inplace integer operation

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|11.4|10.0
  Known to work||10.1.0
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #25 from Richard Biener  ---
I think the regression is fixed - we perform alias versioning unnecessarily
but we are now entering the vectorized loop for a == b (in fact RTL opts
eventually elide the versioning check, so the resulting code is optimal).

This was fixed in GCC 10.

I've split out remaining missed optimization to PR109271.

[Bug tree-optimization/65917] [6 Regression] XFAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 "if " 2

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

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

Bug 80198 Summary: [10/11/12/13 Regression] does not vectorize generic inplace 
integer operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80198

   What|Removed |Added

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

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

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

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

Bug 80198 Summary: [10/11/12/13 Regression] does not vectorize generic inplace 
integer operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80198

   What|Removed |Added

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

[Bug tree-optimization/109271] Unnecessary vectorization alias versioning check

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

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

--- Comment #1 from Richard Biener  ---
A related(?) case from the same PR is the following where one could argue
we should have propagated the equivalence.

void __attribute__((noinline)) generic(int * a, int * b, int c)
{
  if (a == b) {
  for (int i=0; i < 256; i++) {
  a[i] = b[i] | c;
  }
  }
}

[Bug c/105208] incorrect -Wunused-but-set-variable for static const variables used in const expressions

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #1 from Martin Uecker  ---
Still affects 12.x but seems to have disappeared on trunk.

[Bug middle-end/109267] generates empty functions with .cfi_startproc/.cfi_endproc that conflict with other functions

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|-Og generates empty |generates empty functions
   |functions with  |with
   |.cfi_startproc/.cfi_endproc |.cfi_startproc/.cfi_endproc
   |that conflict with other|that conflict with other
   |functions   |functions
  Component|c++ |middle-end
Version|unknown |13.0

--- Comment #4 from Richard Biener  ---
I'm quite sure we dont "remove" any such empty functions with -O2, we might
more aggressively inline and thus if they are static they will be elided.

But the "problem" if there is any, should be generic.

void foo () { __builtin_unreachable (); }
int __attribute__((cold)) bar () { return 0; }

compiled with -O2 gets you the following where foo and bar have the same
address.

.section.text.unlikely,"ax",@progbits
.globl  foo
.type   foo, @function
foo:
.LFB0:
.file 1 "t.i"
.loc 1 1 13 view -0
.cfi_startproc
.loc 1 1 15 view .LVU1
.cfi_endproc
.LFE0:
.size   foo, .-foo
.globl  bar
.type   bar, @function
bar:
.LFB1:
.loc 1 2 34 view -0
.cfi_startproc
.loc 1 2 36 view .LVU3
.loc 1 2 46 is_stmt 0 view .LVU4
xorl%eax, %eax
ret
.cfi_endproc
.LFE1:
.size   bar, .-bar

[Bug tree-optimization/109265] [13 Regression] ICE for 527.cam4_r after r13-6787-g0963cb5fde158c

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |13.0
  Component|middle-end  |tree-optimization

--- Comment #2 from Richard Biener  ---
Btw, cannot reproduce on x86_64, but this might be the DOM pass after
vectorizing / loop optimizing and s390 adjusts some --param defaults that
affect unrolling for example.

[Bug tree-optimization/109265] [13 Regression] ICE for 527.cam4_r after r13-6787-g0963cb5fde158c

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

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

--- Comment #3 from Richard Biener  ---
Note it's probably enough to print what 'name' is on the failing assert and
maybe dump some context on the stmt we are processing.

[Bug tree-optimization/107822] [13/14 Regression] Dead Code Elimination Regression at -Os (trunk vs. 12.2.0)

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|13.0|14.0
Summary|[13 Regression] Dead Code   |[13/14 Regression] Dead
   |Elimination Regression at   |Code Elimination Regression
   |-Os (trunk vs. 12.2.0)  |at -Os (trunk vs. 12.2.0)
   Priority|P1  |P2

--- Comment #4 from Richard Biener  ---
I don't see us realistically fixing this for GCC 13, so postponing to GCC 14
and downgrading from P1 to P2.

Besides bringing back a pass that performs propagation itself possibly using
value-range and range-op helpers it might be possible to teach the on-demand
ranger to process SSA SCCs in the special way the old code did (but
only when asked for?).  But teaching ranger about SCCs probably requires
extensive changes in the code doing the global "propagation", and I'm not
sure that's a) desirable or b) even possible in some reasonable manner.
Adding ad-hoc SCC discovery ontop of the existing "propagation" probably
does not make much sense.

[Bug c++/107484] [13 Regression] ICE: Segmentation fault (in decls_match)

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords|ice-checking|accepts-invalid
   Priority|P2  |P1

--- Comment #2 from Richard Biener  ---
Also crashes with a release checking build:

> ./cc1plus -quiet t.ii
t.ii:5:52: internal compiler error: Segmentation fault
5 | friend void qualified_friend_no_match::f(double);
  |^
0xe2c7af crash_signal
/home/rguenther/src/trunk/gcc/toplev.cc:314
0x793c24 decls_match(tree_node*, tree_node*, bool)
/home/rguenther/src/trunk/gcc/cp/decl.cc:1075
0x7b6de6 find_last_decl
/home/rguenther/src/trunk/gcc/cp/decl2.cc:1630

since it's not error-recovery it's still P1.

Also crashes with

namespace qualified_friend_no_match {
  void f(int);
  template void f(T*);
  struct X {
friend void qualified_friend_no_match::f(double *);
  };
}

which looks more valid to me, but I'm not a C++ expert (but clang++ 13 accepts
it - but that also accepts the original testcase).

[Bug tree-optimization/99739] [11/12 Regression] missing optimization of a repeated conditional

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

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

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

https://gcc.gnu.org/g:86111e7b3027de1029718e23ee5fab0ee011e191

commit r13-6845-g86111e7b3027de1029718e23ee5fab0ee011e191
Author: Jakub Jelinek 
Date:   Fri Mar 24 09:39:59 2023 +0100

testsuite: Add testcase for already fixed PR [PR99739]

This PR was fixed by r13-1268-g8c99e307b20, I'm adding testcase
to make sure we don't regress on it in the future.

2023-03-24  Jakub Jelinek  

PR tree-optimization/99739
* gcc.dg/tree-ssa/pr99739.c: New test.

[Bug middle-end/107443] [10/11/12/13 Regression] Removing switch with __builtin_unreachable causes missed optimizations

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/109137] [12 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

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

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

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

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

commit r13-6846-g0d9e52675c009139a14182d92ddb446ba2feabce
Author: Jakub Jelinek 
Date:   Fri Mar 24 09:42:18 2023 +0100

testsuite: Fix up gcc.target/i386/pr109137.c testcase [PR109137]

The testcase has a couple of small problems:
1) had -m32 in dg-options, that should never be done, instead the test
   should be guarded on ia32
2) adds -fPIC unconditionally (that should be guarded on fpic effective
   target)
3) using #include  for a RA test seems unnecessary,
__builtin_memset
   handles it without the header

2023-03-24  Jakub Jelinek  

PR target/109137
* gcc.target/i386/pr109137.c: Remove -m32 from dg-options, instead
require ia32 effective target.  Only add -fPIC for fpic effective
target.  Remove #include , use __builtin_memset instead
of
memset.

[Bug c++/109247] [13 Regression] optional o; o = {x}; wants to use explicit optional(U) constructor since r13-6765-ga226590fefb35ed6

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

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

Martin Liška  changed:

   What|Removed |Added

   See Also||https://github.com/WebKit/W
   ||ebKit/pull/11910

--- Comment #8 from Martin Liška  ---
> But webkit should probably fix their code anyway, perhaps by changing 
> 
>  m_brush = {setPattern_pattern};
> 
> to
> 
>  m_brush = Brush{setPattern_pattern};

Thank you Jason for the analysis, I've just suggested the change to upstream
project:
https://github.com/WebKit/WebKit/pull/11910

[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #22 from Richard Biener  ---
We've not noticed other fallout in switching to GCC 13 for openSUSE, closing as
INVALID.  As far as I see the previous GCC "extension" was never documented.

[Bug c/109272] New: RISCV: vbool*_t better opportunities of code generation

[pan2.li at intel dot com via Gcc-bugs]

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

Bug ID: 109272
   Summary: RISCV: vbool*_t better opportunities of code
generation
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pan2.li at intel dot com
  Target Milestone: ---

Assume we have sample code as below.
#include "riscv_vector.h"

void
test_vbool8_then_vbool16(int8_t * restrict in, int8_t * restrict out) {
vbool8_t v1 = *(vbool8_t*)in;
vbool16_t v2 = *(vbool16_t*)in;

*(vbool8_t*)(out + 100) = v1;
*(vbool16_t*)(out + 200) = v2;
}

It will generate the assembly code like

test_vbool8_then_vbool16:
csrrt0,vlenb
sllit1,t0,1
csrra3,vlenb
sub sp,sp,t1
csrra5,vlenb
sllia3,a3,1
add a3,a3,sp
addia2,a1,100
srlia5,a5,3
vsetvli a4,zero,e8,m1,ta,ma
sub a5,a3,a5
vlm.v   v24,0(a0)
vsm.v   v24,0(a2)
vsm.v   v24,0(a5)
addia1,a1,200
csrrt0,vlenb
vsetvli a3,zero,e8,mf2,ta,ma
sllit1,t0,1
vlm.v   v24,0(a5)
vsm.v   v24,0(a1)
add sp,sp,t1
jr  ra

Actually we can optimize the generated code to:

test_vbool8_then_vbool4:
addia3,a1,100
vsetvli a4,zero,e8,m1,ta,ma
addia1,a1,200
vlm.v   v24,0(a0)
vsm.v   v24,0(a3)
vsetvli a3,zero,e8,mf2,ta,ma
vlm.v   v24,0(a0)
vsm.v   v24,0(a1)
ret

[Bug middle-end/109258] [13 Regression] go.test/test/fixedbugs/bug207.go ICEs

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

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

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

https://gcc.gnu.org/g:5450833e4f9993f81ac16cbbcf4e46881a519f85

commit r13-6847-g5450833e4f9993f81ac16cbbcf4e46881a519f85
Author: Jakub Jelinek 
Date:   Fri Mar 24 10:38:42 2023 +0100

builtins: Fix up ICE in inline_string_cmp [PR109258]

The PR109086 r13-6690 inline_string_cmp change to
  if (diff != result)
emit_move_insn (result, diff);
regressed
FAIL: go.test/test/fixedbugs/bug207.go,  -O2 -g  (internal compiler error:
in emit_move_insn, at expr.cc:4224)
The problem is the Go FE doesn't mark __builtin_memcmp as pure (I'll also
send patch for that) and so result is const0_rtx when the call lost its lhs
and the above move ICEs because moving something into const0_rtx is
obviously
invalid.
I think it is better not to rely on all FEs having these *cmp functions
pure anD DCE being performed.  The following patch just punts from the
inline expansion in that case, so we just emit normal library call.

2023-03-24  Jakub Jelinek  

PR middle-end/109258
* builtins.cc (inline_expand_builtin_bytecmp): Return NULL_RTX
early
if target == const0_rtx.

[Bug target/104713] gcc does not reject -march=i686 -fcf-protection

[jay+ggcc--- via Gcc-bugs]

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

James Addison  changed:

   What|Removed |Added

 CC||jay+g...@jp-hosting.net

--- Comment #9 from James Addison  ---
(In reply to James Addison from comment #7)
> Something that's unclear to me is whether fcf-protection requires NOPL
> (multi-byte NOP).  I understand that it requires endbr32.

(and now I also understand that the endbr32 instruction is a repurposing of a
previously-existing long-NOP - and that it's required to implement
fcf-protection, aka Intel CET)

[Bug target/98612] _mm_comieq_sd has wrong semantics

[andysem at mail dot ru via Gcc-bugs]

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

andysem at mail dot ru changed:

   What|Removed |Added

 CC||andysem at mail dot ru

--- Comment #9 from andysem at mail dot ru ---
Some relevant discussion here:

https://stackoverflow.com/questions/75818896/mm-comieq-ss-difference-between-clang-and-gcc

Indeed, the description for _mm_comieq_ss in the Intrinsics Guide 3.6.5 as of
2022-01-24 takes NaNs into account:

https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html#text=comiss&ig_expand=1424

I think, the point that the intrinsic should correspond to the naked
instruction is not correct in this case. The intrinsic corresponds to the same
instruction either way, the question is only which flags are considered the
result of the intrinsic. And it seems that the intended behavior (as indicated
by the updated docs, icc and clang) is to check ZF & PF, not just ZF as gcc is
currently doing.

[Bug c++/109268] Guard variable still provided for static constinit variable with an empty destructor

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Agreed, the constinit is irrelevant.
As for constexpr dtors generally, even those can have important side-effects,
and even for the case where the ctor is also constexpr and the var has constant
expression initializer, so to me this looks like dup of PR19661.
We'd need to track in some extra bit if the dtor does something non-trivial and
propagate it from dtors of the elements/bases.
struct X {
  constexpr X () : p (nullptr) {}
  constexpr ~X () { delete p; }
  int *p;
};
int
main ()
{
  static constinit X data;
  data.p = new int;
}

[Bug bootstrap/109188] Building genmodes under MinGW-W64/MSYS2 fails due to undefined HOST_EXTRA_OBJS_SYMBOL

[costas.argyris at gmail dot com via Gcc-bugs]

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

--- Comment #15 from Costas Argyris  ---
patch that makes symbol optional was pushed to master:

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=08ef17c75777ef9e4e7ead132ccd7a6d03ae6020

[Bug driver/108865] gcc on Windows fails with Unicode path to source file

[costas.argyris at gmail dot com via Gcc-bugs]

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

--- Comment #29 from Costas Argyris  ---
patch that makes symbol optional was pushed to master:

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=08ef17c75777ef9e4e7ead132ccd7a6d03ae6020

[Bug target/109273] New: [11/12/13 Regression] unaligned stp generated with -mstrict-align

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

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

Bug ID: 109273
   Summary: [11/12/13 Regression] unaligned stp generated with
-mstrict-align
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-*-*

With -O2 -mstrict-align, for

void f(void *p)
{
  __builtin_memset(p, 0, 16);
}

gcc-10 and before, targeting aarch64, used to generate

f:
mov x2, 16
mov w1, 0
b   memset

but gcc-11 and newer emit a potentially-misaligned 'stp':

f:
stp xzr, xzr, [x0]
ret

[Bug tree-optimization/109265] [13 Regression] ICE for 527.cam4_r after r13-6787-g0963cb5fde158c

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-03-24

--- Comment #4 from Martin Liška  ---
I've got a self-contained test-case, reducing right now..

[Bug target/109273] [11/12/13 Regression] unaligned stp generated with -mstrict-align

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 103100 which I have submitted a new patch for.

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

[Bug target/103100] [11/12/13 Regression] unaligned access generated with memset or {} and -O2 -mstrict-align

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

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

[Bug tree-optimization/109265] [13 Regression] ICE for 527.cam4_r after r13-6787-g0963cb5fde158c

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

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

--- Comment #5 from Martin Liška  ---
Created attachment 54740
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54740&action=edit
Reduced test-case

s390x-linux-gnu-gcc sgexx.F90 -c -O3
during GIMPLE pass: dom
sgexx.F90:14:23:

   14 |   SUBROUTINE SLAMC2( BETA, T, RND, EPS, EMIN, RMIN, EMAX, RMAX )
  |   ^
internal compiler error: Segmentation fault
0xc36fbf crash_signal
/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/toplev.cc:314
0x1459624 range_def_chain::in_chain_p(tree_node*, tree_node*)
   
/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/gimple-range-gori.cc:126
0x1459624 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
   
/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/gimple-range-gori.cc:667
0x145a437 gori_compute::compute_operand1_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
   
/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/gimple-range-gori.cc:1174
0x14594c5 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
   
/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/gimple-range-gori.cc:726
0x145ac07 gori_compute::compute_operand2_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
   
/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/gimple-range-gori.cc:1254
0x145b054 gori_compute::compute_operand1_and_operand2_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
   
/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/gimple-range-gori.cc:1274
0x1459402 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
   
/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/gimple-range-gori.cc:723
0x145c7c8 gori_compute::outgoing_edge_range_p(vrange&, edge_def*, tree_node*,
range_query&)
   
/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/gimple-range-gori.cc:1384
0x144f319 ranger_cache::edge_range(vrange&, edge_def*, tree_node*,
ranger_cache::rfd_mode)
   
/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/gimple-range-cache.cc:964
0x144e86f ranger_cache::resolve_dom(vrange&, tree_node*, basic_block_def*)
   
/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/gimple-range-cache.cc:1407
0x144ee30 ranger_cache::range_from_dom(vrange&, tree_node*, basic_block_def*,
ranger_cache::rfd_mode)
   
/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/gimple-range-cache.cc:1518
0x145087f ranger_cache::range_from_dom(vrange&, tree_node*, basic_block_def*,
ranger_cache::rfd_mode)
   
/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/gimple-range-cache.cc:1421
0x145087f ranger_cache::fill_block_cache(tree_node*, basic_block_def*,
basic_block_def*)
   
/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/gimple-range-cache.cc:1212
0x1451382 ranger_cache::block_range(vrange&, basic_block_def*, tree_node*,
bool)
   
/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/gimple-range-cache.cc:1039
0x1448ed1 gimple_ranger::range_on_entry(vrange&, basic_block_def*, tree_node*)
/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/gimple-range.cc:156
0xda06d3 path_range_query::range_on_path_entry(vrange&, tree_node*)
   
/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/gimple-range-path.cc:160
0xda06d3 path_range_query::internal_range_of_expr(vrange&, tree_node*, gimple*)
   
/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/gimple-range-path.cc:176
0xda08a8 path_range_query::internal_range_of_expr(vrange&, tree_node*, gimple*)
   
/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/gimple-range-path.cc:210
0xda08a8 path_range_query::range_of_expr(vrange&, tree_node*, gimple*)
   
/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/gimple-range-path.cc:202
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/100955] varargs causes extra stores to/from stack

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
There is no reason not to lower __builtin_va_start (&arg, 0) to arg = .VA_START
();
for the problematic cases of __builtin_va_list being a struct and add support
for expanding both __builtin_va_start (&arg, 0) and arg = .VA_START () using
some helper code.  We already similarly transform __builtin_va_start (&arg, 0)
to arg = __builtin_next_arg (0) if __builtin_va_list is a pointer (e.g. ia32). 
And for the x86_64 style __builtin_va_list
where it is struct [1] we already emit the optimal code.
I'm surprised aarch64 uses a struct rather than struct [1], that must be
terribly inefficient even if you simply pass down va_list through several
functions.

[Bug c++/109274] New: ice in in_chain_p, at gimple-range-gori.cc:119

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 109274
   Summary: ice in in_chain_p, at gimple-range-gori.cc:119
   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: ---

This C++ code:

float mulsignf_cb, mulsignf_t, mulsignf_bpa;
int mulsignf___trans_tmp_1;
float mulsignf() {
  mulsignf_cb = 0 * -(2.0f * mulsignf_bpa);
  mulsignf___trans_tmp_1 = mulsignf_cb != mulsignf_cb ? 0 : mulsignf();
  mulsignf_t = mulsignf_bpa;
}

when compiled by recent g++ trunk and flag -O2, does this:

bug902.cc: In function ‘float mulsignf()’:
bug902.cc:7:1: warning: no return statement in function returning non-void
[-Wre
turn-type]
7 | }
  | ^
during GIMPLE pass: vrp
bug902.cc:3:7: internal compiler error: in in_chain_p, at
gimple-range-gori.cc:1
19
3 | float mulsignf() {
  |   ^~~~
0x92e285 range_def_chain::in_chain_p(tree_node*, tree_node*)
../../trunk.year/gcc/gimple-range-gori.cc:119
0x1fd69f4 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
t
ree_node*, fur_source&, value_relation*)
../../trunk.year/gcc/gimple-range-gori.cc:667

The bug first seems to appear sometime from git hash g:454a4d5041f53cd1 to
g:0963cb5fde158cce, a distance of 41 commits.

[Bug target/109254] Bug in gcc (13.0.1) support for ARM SVE, which randomly modifies the prediction register

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

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

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

Those patches break bootstrap though (in libobjc) and regress some
__builtin_apply*/__builtin_return* testcases.
Trying this now instead.

[Bug fortran/109275] New: Bad error messages for interfaces describing surrounding program unit

[rhidalgochar at bloomberg dot net via Gcc-bugs]

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

Bug ID: 109275
   Summary: Bad error messages for interfaces describing
surrounding program unit
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rhidalgochar at bloomberg dot net
  Target Milestone: ---

The following example, where an interface is defined for the surrounding
program unit fails to compile:

  function foo(arg1) result(res)

  interface foo
function foo(arg1)
  integer*2 foo(3)
  integer*8 arg1
end function foo
  end interface

  integer*2 res(3)
  integer*8 arg1
  res = (/1,2,int(arg1,4)/)
  end function

Giving the error:

recursive-interface.f:4:8:

4 | function foo(arg1)
  |1
Error: Procedure pointer result ‘foo’ at (1) is missing the pointer attribute

Given you can use this function with that interface, this appears to be an
incorrect warning.

It gives even stranger warnings if you follow its advice and add the pointer
attribute to foo in the interface (i.e. integer*2, pointer :: foo(3)):

recursive-interface.f:4:8:

4 | function foo(arg1)
  |1
Error: Array pointer ‘ppr@’ at (1) must have a deferred shape or assumed rank
recursive-interface.f:1:6:

1 |   function foo(arg1) result(res)
  |  1
Error: Array pointer ‘foo’ at (1) must have a deferred shape or assumed rank

It appears that "ppr@" is some internal return variable that should not be
getting exposed. Following this advice further and making foo assumed shape
(foo(:)) it goes back to complaining about it not having the pointer attribute
even though it does.

While I don't see any reason why a correctly defined interface would not be
allowed, especially if it's not even used and result is used to disambiguate
the symbol, other compilers do fail to compile and complain about using an
interface with the same name as the surrounding program unit. XLF complained
for normal interfaces, while Sun Studio just complains for generic interface.

GFortrans error message should at least be more informative, explicitly saying
it's not allowed if this is the case.

I came across this issue because a library had an include with many interfaces,
and was then trying to use some of those interfaces in the definitions of those
program units.

[Bug c++/99575] [coroutines] unexpected move when co_awaiting a nonmoveable object

[niget.tom at gmail dot com via Gcc-bugs]

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

Tom Niget  changed:

   What|Removed |Added

 CC||niget.tom at gmail dot com

--- Comment #3 from Tom Niget  ---
FWIW, the code in Paweł's comment compiles under 12.1 (and doesn't compile
under 11.3). Maybe this can be closed?

[Bug tree-optimization/109265] [13 Regression] ICE for 527.cam4_r after r13-6787-g0963cb5fde158c

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/109274] [13 Regression] ice in in_chain_p, at gimple-range-gori.cc:119 starting with r13-6787

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Priority|P3  |P1
Summary|ice in in_chain_p, at   |[13 Regression] ice in
   |gimple-range-gori.cc:119|in_chain_p, at
   ||gimple-range-gori.cc:119
   ||starting with r13-6787
 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org
   Last reconfirmed||2023-03-24
  Component|c++ |tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r13-6787-g0963cb5fde158cce986.  Perhaps dup of PR109265?
Cleaned up testcase, still for -O2:

float a, b, c;
int d;
float bar (void);

void
foo (void)
{
  a = 0 * -(2.0f * c);
  d = a != a ? 0 : bar ();
  b = c;
}

[Bug tree-optimization/109265] [13 Regression] ICE for 527.cam4_r after r13-6787-g0963cb5fde158c

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

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

--- Comment #6 from Jakub Jelinek  ---
Perhaps the same bug as PR109274?

[Bug middle-end/109258] [13 Regression] go.test/test/fixedbugs/bug207.go ICEs

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed now (though still would like to fix the Go FE too).

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

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

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

--- Comment #20 from Jakub Jelinek  ---
Tried valgrind on the cross d21 on x86_64 and didn't see anything.
Perhaps modify the makefiles such that it uses -fdump-tree-all -da already when
compiling typeinfo.lo?

[Bug tree-optimization/109265] [13 Regression] ICE for 527.cam4_r after r13-6787-g0963cb5fde158c

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

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

--- Comment #7 from Richard Biener  ---
Without USE:

module sgexx
integer,parameter :: r8 = selected_real_kind(12) ! 8 byte real
contains
  SUBROUTINE SLACPY( UPLO, M, N, A, LDA, B, LDB )
  END SUBROUTINE SLACPY
  SUBROUTINE SLARFB( SIDE, TRANS, DIRECT, STOREV, M, N, K, V, LDV, &
 T, LDT, C, LDC, WORK, LDWORK )
  REAL(r8)   C( LDC, * ), T( LDT, * ), V( LDV, * ), &
 WORK( LDWORK, * )
  END SUBROUTINE SLARFB
  SUBROUTINE SLAMC2( BETA, T, RND, EPS, EMIN, RMIN, EMAX, RMAX )
  LOGICALFIRST, IEEE, IWARN, LIEEE1, LRND
  INTEGERGNMIN, GPMIN, I, LBETA, LEMAX, LEMIN, LT, &
 NGNMIN, NGPMIN
  REAL(r8)   A, B, C, HALF, LEPS, LRMAX, LRMIN, ONE, RBASE, &
 SIXTH, SMALL, THIRD, TWO, ZERO
  IF( FIRST ) THEN
SMALL = SLAMC3( SMALL*RBASE, ZERO )
 A = SLAMC3( ONE, SMALL )
 CALL SLAMC4( GPMIN, A, LBETA )
 CALL SLAMC4( GNMIN, -A, LBETA )
  END IF
  END SUBROUTINE SLAMC2
  FUNCTION SLAMC3( A, B )
  real(r8) slamc3
  REAL(r8)   A, B
  SLAMC3 = A + B
  END FUNCTION SLAMC3
  SUBROUTINE SLAMC4( EMIN, START, BASE )
  INTEGERBASE, EMIN
  REAL(r8)   START
  REAL(r8)   A, B1, B2, C1, C2, D1, D2, ONE, RBASE, ZERO
  A = START
  ZERO = 0
  C1 = A
  C2 = A
  D1 = A
   10 CONTINUE
  IF( ( C1.EQ.A ) .AND. ( C2.EQ.A ) .AND. ( D1.EQ.A ) .AND. &
  ( D2.EQ.A ) ) THEN
 D2 = ZERO
 GO TO 10
  END IF
  END SUBROUTINE SLAMC4
  SUBROUTINE SGEMV ( TRANS, M, N, ALPHA, A, LDA, X, INCX, &
 BETA, Y, INCY )
  END SUBROUTINE SGEMV
  SUBROUTINE STRMM ( SIDE, UPLO, TRANSA, DIAG, M, N, ALPHA, A, LDA, &
 B, LDB )
  END SUBROUTINE STRMM
end module sgexx

[Bug tree-optimization/109274] [13 Regression] ice in in_chain_p, at gimple-range-gori.cc:119 starting with r13-6787-g0963cb5fde158cce986

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

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

--- Comment #2 from Richard Biener  ---
(gdb) p *vrel_ptr
$4 = {related = VREL_VARYING, name1 = , name2 = }

and we pass on NULL here:

666   if (op1_in_chain)
667 res = in_chain_p (vrel_ptr->op1 (), op1)
668   && in_chain_p (vrel_ptr->op2 (), op1);

very likely a duplicate.

[Bug tree-optimization/106912] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032 since r13-1575-gcf3a120084e94614

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

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

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

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

commit r13-6849-ged626f18b189920aeed9974aded3f9cb6f25b543
Author: Richard Biener 
Date:   Thu Mar 16 13:51:19 2023 +0100

tree-optimization/106912 - clear const attribute from fntype

The following makes sure that after clearing pure/const from
instrumented function declarations we are adjusting call statements
fntype as well to handle indirect calls and because gimple_call_flags
looks at both decl and fntype.

Like the pure/const flag clearing on decls we refrain from touching
calls to known functions that do not have a body in the current TU.

PR tree-optimization/106912
* tree-profile.cc (tree_profiling): Update stmts only when
profiling or testing coverage.  Make sure to update calls
fntype, stripping 'const' there.

* gcc.dg/profile-generate-4.c: New testcase.

[Bug tree-optimization/106912] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032 since r13-1575-gcf3a120084e94614

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #14 from Richard Biener  ---
Fixed, but possibly latent.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #20 from Jakub Jelinek  ---
> Tried valgrind on the cross d21 on x86_64 and didn't see anything.
> Perhaps modify the makefiles such that it uses -fdump-tree-all -da already 
> when
> compiling typeinfo.lo?

I'll give that a whirl.  However, my SPARC box is pretty busy right now
with the weekly bootstraps, so this will be later this weekend only.

In the meantime, I try to reproduce the issue on gcc211.

[Bug target/109137] [12 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

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

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

--- Comment #20 from Vladimir Makarov  ---
(In reply to CVS Commits from comment #19)
> The master branch has been updated by Jakub Jelinek :
> 
> https://gcc.gnu.org/g:0d9e52675c009139a14182d92ddb446ba2feabce
> 
> commit r13-6846-g0d9e52675c009139a14182d92ddb446ba2feabce
> Author: Jakub Jelinek 
> Date:   Fri Mar 24 09:42:18 2023 +0100
> 
> testsuite: Fix up gcc.target/i386/pr109137.c testcase [PR109137]
> 
> The testcase has a couple of small problems:
> 1) had -m32 in dg-options, that should never be done, instead the test
>should be guarded on ia32
> 2) adds -fPIC unconditionally (that should be guarded on fpic effective
>target)
> 3) using #include  for a RA test seems unnecessary,
> __builtin_memset
>handles it without the header

Thank you for the test correction, Jakub.

[Bug tree-optimization/109238] [13 Regression] tst-realloc.i:42:19: error: pointer ‘p’ may be used after ‘realloc’ [-Werror=use-after-free] in glibc tests

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

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

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

https://gcc.gnu.org/g:0409aa5a2de9ce3164933814a4a7adc91f6acb96

commit r13-6850-g0409aa5a2de9ce3164933814a4a7adc91f6acb96
Author: Andrew MacLeod 
Date:   Thu Mar 23 10:28:34 2023 -0400

Ranger cache dominator queries should ignore backedges.

When querying dominators for cache values, ignore back edges in
read-only mode.

PR tree-optimization/109238
gcc/
* gimple-range-cache.cc (ranger_cache::resolve_dom): Ignore
predecessors which this block dominates.

gcc/testsuite/
* gcc.dg/pr109238.c: New.

[Bug tree-optimization/109274] [13 Regression] ice in in_chain_p, at gimple-range-gori.cc:119 starting with r13-6787-g0963cb5fde158cce986

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

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

--- Comment #3 from Jakub Jelinek  ---
I think:
--- gcc/gimple-range-gori.cc.jj 2023-03-23 15:25:47.060741116 +0100
+++ gcc/gimple-range-gori.cc2023-03-24 14:30:38.272043631 +0100
@@ -632,10 +632,11 @@ gori_compute::compute_operand_range (vra
   if (!vrel_ptr && k == VREL_VARYING && op1 == op2)
k = VREL_EQ;
   if (k != VREL_VARYING)
-   {
-vrel.set_relation (k, op1, op2);
-vrel_ptr = &vrel;
-   }
+   {
+ vrel.set_relation (k, op1, op2);
+ if (vrel.kind () != VREL_VARYING)
+   vrel_ptr = &vrel;
+   }
 }

   // Handle end of lookup first.
should fix this.

[Bug bootstrap/109188] Building genmodes under MinGW-W64/MSYS2 fails due to undefined HOST_EXTRA_OBJS_SYMBOL

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #16 from Richard Biener  ---
duplicate

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

[Bug driver/108865] gcc on Windows fails with Unicode path to source file

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||jdx at o2 dot pl

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

[Bug libgcc/109270] ssp/ssp.h should be adapted to use __builtin_dynamic_object_size()

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

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-03-24
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |siddhesh at gcc dot 
gnu.org

[Bug tree-optimization/109238] [13 Regression] tst-realloc.i:42:19: error: pointer ‘p’ may be used after ‘realloc’ [-Werror=use-after-free] in glibc tests

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/109265] [13 Regression] ICE for 527.cam4_r after r13-6787-g0963cb5fde158c

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

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

--- Comment #8 from Jakub Jelinek  ---
My PR109274 patch fixes this too.

[Bug ipa/107769] [12/13 Regression] -flto with -Os/-O2/-O3 emitted code with gcc 12.x segfaults via mutated global in .rodata since r12-2887-ga6da2cddcf0e959d

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

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

Martin Jambor  changed:

   What|Removed |Added

   Assignee|hubicka at gcc dot gnu.org |jamborm at gcc dot 
gnu.org

--- Comment #4 from Martin Jambor  ---
Indeed, I hope I know what is going on.

[Bug tree-optimization/109265] [13 Regression] ICE for 527.cam4_r after r13-6787-g0963cb5fde158c

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

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

--- Comment #9 from Jakub Jelinek  ---
Adjusted testcase:
module pr109265
  integer, parameter :: r8 = selected_real_kind (12)
contains
  subroutine foo (b, c, d, e, f)
implicit none
logical :: b
real (kind = r8) :: c, d, e, f, i
if (b) then
  c = bar (c * d, e)
  i = bar (f, c)
  call baz (i)
  call baz (-i)
end if
  end subroutine foo
  function bar (a, b)
implicit none
real (kind = r8) :: bar
real (kind = r8) :: a, b
bar = a + b
  end function bar
  subroutine baz (b)
implicit none
real (kind = r8) :: b, d, e, f, g, h, i
d = b
i = 0
e = d
f = d
g = d
  10 continue
if ((e.eq.d) .and. (f.eq.d) .and. (g.eq.d) .and. (h.eq.d)) then
  h = i
  go to 10
end if
  end subroutine baz
end module pr109265

It uses one uninitialized variable (h, D2 in the above one; but we shouldn't
ICE on it).

[Bug fortran/109275] Bad error messages for interfaces describing surrounding program unit

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Raoul Hidalgo Charman from comment #0)
> The following example, where an interface is defined for the surrounding
> program unit fails to compile:
> 
>   function foo(arg1) result(res)
> 
>   interface foo
> function foo(arg1)
>   integer*2 foo(3)
>   integer*8 arg1
> end function foo
>   end interface
> 
>   integer*2 res(3)
>   integer*8 arg1
>   res = (/1,2,int(arg1,4)/)
>   end function
> 
> Giving the error:
> 
> recursive-interface.f:4:8:
> 
> 4 | function foo(arg1)
>   |1
> Error: Procedure pointer result ‘foo’ at (1) is missing the pointer attribute
> 
> Given you can use this function with that interface, this appears to be an
> incorrect warning.

It's not a warning.  It is an error.  And, yes it seems wrong.

> 
> While I don't see any reason why a correctly defined interface would not be
> allowed, especially if it's not even used and result is used to disambiguate
> the symbol, other compilers do fail to compile and complain about using an
> interface with the same name as the surrounding program unit. XLF complained
> for normal interfaces, while Sun Studio just complains for generic interface.
> 
> GFortrans error message should at least be more informative, explicitly
> saying it's not allowed if this is the case.
> 
> I came across this issue because a library had an include with many
> interfaces, and was then trying to use some of those interfaces in the
> definitions of those program units.

It seems to be invalid Fortran.  From Fortran 2018

 C1501 (R1501) An interface-block in a subprogram shall not contain
 an interface-body for a procedure defined by that subprogram.

It seems gfortran is missing a check for C1501.

[Bug tree-optimization/109274] [13 Regression] ice in in_chain_p, at gimple-range-gori.cc:119 starting with r13-6787-g0963cb5fde158cce986

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Full untested patch.

[Bug tree-optimization/109274] [13 Regression] ice in in_chain_p, at gimple-range-gori.cc:119 starting with r13-6787-g0963cb5fde158cce986

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||stefansf at linux dot ibm.com

--- Comment #5 from Jakub Jelinek  ---
*** Bug 109265 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/109265] [13 Regression] ICE for 527.cam4_r after r13-6787-g0963cb5fde158c

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
Dup.

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

[Bug target/103628] ICE: Segmentation fault (in gfc_conv_tree_to_mpfr)

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

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

--- Comment #7 from Segher Boessenkool  ---
(In reply to HaoChen Gui from comment #5)
> The memory representation of IBM long double is not unique. It's actually
> the sum of two 64-bit doubles. 

Yes, and the first of those two DP numbers is required to be the full
number rounded to double precision (with round-to-nearest).

What happened here?  I cannot make much sense of those numbers, but it
seems to contain something with uppercase ASCII overwritten?

[Bug tree-optimization/109274] [13 Regression] ice in in_chain_p, at gimple-range-gori.cc:119 starting with r13-6787-g0963cb5fde158cce986

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

  Attachment #54742|0   |1
is obsolete||

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

Before floating point relations were added, we tried to sanitize 
value-relation records to not include non-sensensical records... ie 
x != x or x < x.   Instead, we made a VREL_VARYING record with no 
operands. 

When floating point relations were supported, some of these were no 
longer non-sensical, AND we expanded the use of value_relation records 
into GORI. 

As a result, this sanitization is no longer needed.  The Oracle 
does not create records with op1 == op2, so its only within GORI 
that these records can exist, and we shouldn't try to interpret them. 

The bug occurs because the "sanitized" records doesn't set op1 and op2, and
changes the relation to VARYING..  and we have a record so expected the
operands it to be set the way they were just set.

We should not be setting a VREL_VARYING record if asked to set something else.

[Bug tree-optimization/109274] [13 Regression] ice in in_chain_p, at gimple-range-gori.cc:119 starting with r13-6787-g0963cb5fde158cce986

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Agree your patch is better, but can you please also include the Fortran
testcase from my patch?  Or I could commit it incrementally of course.

[Bug other/109163] SARIF (and other JSON) output files are non-deterministic

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

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

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

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

commit r13-6851-g7f1e15f743357e037d7c4f6f6000863c26f3dfc3
Author: David Malcolm 
Date:   Fri Mar 24 11:38:14 2023 -0400

json: preserve key-insertion order [PR109163]

PR other/109163 notes that when we write out JSON files, we traverse
the keys within each object via hash_map iteration, and thus the
ordering is non-deterministic - it can arbitrarily vary from run to
run and from different machines, making it harder for users to compare
results and determine if anything has "really" changed.

I'm running into this issue with SARIF output, but there are several
places where we're currently emitting JSON:

  * -fsave-optimization-record emits SRCFILE.opt-record.json.gz
"This option is experimental and the format of the data within
the compressed JSON file is subject to change."; see
optinfo-emit-json.{h,cc}, dumpfile.cc, etc
  * -fdiagnostics-format= with the various "sarif" and "json" options
  * -fdump-analyzer-json is a developer option in the analyzer
  * gcov has:
 "-j, --json-format: Output JSON intermediate format into
 .gcov.json.gz file"

This patch adds an auto_vec to class json::object to preserve
key-insertion order, and use it when writing out objects.  Potentially
this slightly slows down JSON output, but I believe that this isn't
normally a bottleneck, and that the benefits to the user of
deterministic output are worth it.

I had first attempted to use ordered_hash_map.h for this, but ran into
impenetrable template errors, so this patch uses a simpler approach of
just adding an auto_vec to json::object.

Testing showed a failure of diagnostic-format-json-5.c, which was using
a convoluted set of regexps to consume the output; I believe that this
was brittle, and was intermittently failing for some of the random
orderings of output.  I rewrote these regexps to work with the expected
output order.  The other such tests seem to pass with the
now-deterministic orderings.

gcc/ChangeLog:
PR other/109163
* json.cc: Update comments to indicate that we now preserve
insertion order of keys within objects.
(object::print): Traverse keys in insertion order.
(object::set): Preserve insertion order of keys.
(selftest::test_writing_objects): Add an additional key to verify
that we preserve insertion order.
* json.h (object::m_keys): New field.

gcc/testsuite/ChangeLog:
PR other/109163
* c-c++-common/diagnostic-format-json-1.c: Update comment.
* c-c++-common/diagnostic-format-json-2.c: Likewise.
* c-c++-common/diagnostic-format-json-3.c: Likewise.
* c-c++-common/diagnostic-format-json-4.c: Likewise.
* c-c++-common/diagnostic-format-json-5.c: Rewrite regexps.
* c-c++-common/diagnostic-format-json-stderr-1.c: Update comment.

Signed-off-by: David Malcolm 

[Bug c++/97740] [10/11/12/13 Regression] Weird error message about accessing a private member of my own class inside of std::string_view inside of constexpr

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |10.5
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=96716
Summary|Weird error message about   |[10/11/12/13 Regression]
   |accessing a private member  |Weird error message about
   |of my own class inside of   |accessing a private member
   |std::string_view inside of  |of my own class inside of
   |constexpr   |std::string_view inside of
   ||constexpr
 CC||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #3 from Patrick Palka  ---
Here's a reduced C++11 testcase that became rejects-valid after
r10-6416-g8fda2c274ac66d:

struct A {
  constexpr const int* get() const { return &m; }
private:
  int m = 42;
} a;

struct B { const int* p; };

template
void f() {
  constexpr B b = {a.get()};
}

template void f();

: In function ‘void f()’:
:11:25: error: ‘int A::m’ is private within this context
:4:7: note: declared private here
: In instantiation of ‘void f() [with  = int]’:
:14:22:   required from here
:11:25: error: ‘int A::m’ is private within this context
:4:7: note: declared private here

[Bug ipa/105685] [10/11/12/13 Regression] Bogus `-Wsuggest-attribute=cold` on function already marked as `__attribute__((cold))`

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/97740] [10/11/12/13 Regression] Weird error message about accessing a private member of my own class inside of std::string_view inside of constexpr

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

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

--- Comment #4 from Patrick Palka  ---
A C++14 version that's more similar to the original testcase using a generic
lambda and dependent initializer:

struct A {
  constexpr const int* get() const { return &m; }
private:
  int m = 42;
} a;

struct B { const int* p; };

template
void f() {
  [] (auto) {
constexpr B b = {arg->get()};
  }(0);
}

template void f<&a>();

[Bug target/105980] [11/12 Regression] ICE in final_scan_insn_1, at final.cc:2811

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12/13 Regression] ICE   |[11/12 Regression] ICE in
   |in final_scan_insn_1, at|final_scan_insn_1, at
   |final.cc:2811   |final.cc:2811

--- Comment #10 from Jakub Jelinek  ---
Fixed on the trunk.

[Bug fortran/104949] [OpenMP] omp target: firstprivate of allocatable array – only descriptor firstprivatized

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

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

commit r13-6852-ge8fec6998b656dac02d4bc6c69b35a0fb5611e87
Author: Thomas Schwinge 
Date:   Thu Mar 23 12:32:35 2023 +0100

Add caveat/safeguard to OpenMP: Handle descriptors in target's firstprivate
[PR104949]

Follow-up to commit 49d1a2f91325fa8cc011149e27e5093a988b3a49
"OpenMP: Handle descriptors in target's firstprivate [PR104949]".

PR fortran/104949
libgomp/
* target.c (gomp_map_vars_internal) : Add
caveat/safeguard.

[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le

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

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

--- Comment #35 from Jakub Jelinek  ---
Ping again.

[Bug c++/105481] [10/11/12/13 Regression] ICE: unexpected expression of kind template_parm_index

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

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

--- Comment #8 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r13-6853-g4e2cdb1ddb5f6ace909358775e94bfe23046ad5a
Author: Jason Merrill 
Date:   Thu Mar 23 18:20:52 2023 -0400

c++: default template arg, partial ordering [PR105481]

The default argument code in type_unification_real was assuming that all
targs we've deduced by that point are non-dependent, but that's not the
case
for partial ordering.

PR c++/105481

gcc/cp/ChangeLog:

* pt.cc (type_unification_real): Adjust for partial ordering.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/fntmpdefarg-partial1.C: New test.

[Bug libgcc/108891] libatomic: AArch64 SEQ_CST 16-byte load missing barrier

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Wilco Dijkstra :

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

commit r13-6855-g1f641d6aba284e0c277e6684cd6b2c73591cd14d
Author: Wilco Dijkstra 
Date:   Fri Feb 10 17:41:05 2023 +

libatomic: Fix SEQ_CST 128-bit atomic load [PR108891]

The LSE2 ifunc for 16-byte atomic load requires a barrier before the LDP -
without it, it effectively has Load-AcquirePC semantics similar to LDAPR,
which is less restrictive than what __ATOMIC_SEQ_CST requires.  This patch
fixes this and adds comments to make it easier to see which sequence is
used for each case.  Use a load/store exclusive loop for store to simplify
testing memory ordering is correct (it is slightly faster too).

libatomic/
PR libgcc/108891
* config/linux/aarch64/atomic_16.S: Fix libat_load_16_i1.
Add comments describing the memory order.

[Bug libgcc/108891] libatomic: AArch64 SEQ_CST 16-byte load missing barrier

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

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

Wilco  changed:

   What|Removed |Added

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

--- Comment #2 from Wilco  ---
Fixed

[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le

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

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

--- Comment #36 from Peter Bergner  ---
(In reply to Jakub Jelinek from comment #34)
> What is the state of this PR?  I see patches posted in August, but don't see
> anything committed...

I've seen some patch submissions and pings in February and it looks like it
just needs a review.  I'll work with the team to get this reviewed.

[Bug rtl-optimization/109276] New: ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de via Gcc-bugs]

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

Bug ID: 109276
   Summary: ICE: in assign_stack_local_1, at function.cc:429 with
-mpreferred-stack-boundary=2
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: max.aehle at scicomp dot uni-kl.de
  Target Milestone: ---

Created attachment 54745
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54745&action=edit
verbose output, preprocessed source, .i and .s file

Compiling the attached bug.c with GCC 12.2.0 via

gcc -m32 -O0 -c bug.c -mpreferred-stack-boundary=2

prints

during RTL pass: split1
bug.c: In function 'fun':
bug.c:23:1: internal compiler error: in assign_stack_local_1, at
function.cc:429
   23 | }
  | ^
0x6d3b9b assign_stack_local_1(machine_mode, poly_int<1u, long>, int, int)
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/function.cc:429
0xf81d50 assign_386_stack_local(machine_mode, ix86_stack_slot)
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/config/i386/i386.cc:16558
0x13bdd87 gen_split_65(rtx_insn*, rtx_def**)
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/config/i386/i386.md:5471
0x17d3e0a split_insns(rtx_def*, rtx_insn*)
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/config/i386/i386.md:15646
0x9295fe try_split(rtx_def*, rtx_insn*, int)
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/emit-rtl.cc:3795
0xc01fb1 split_insn
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/recog.cc:3384
0xc072f2 split_all_insns()
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/recog.cc:3488
0xc073e8 execute
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/recog.cc:4406
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.

We have attached:
- the stdout/stderr output with the additional flag -v,
- the preprocessed source produced with -freport-bug, 
- the files bug.i and bug.s produced with -save-temps.

The GCC 12.2.0 build was configured only with a --prefix option. gcc -v shows

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/ramdisk/aehle/gcc/gcc-install/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/configure
--prefix=/ramdisk/aehle/gcc/gcc-obj/../gcc-install
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (GCC) 

uname -a says "Linux  5.4.0-122-generic #138-Ubuntu SMP Wed Jun 22
15:00:31 UTC 2022 x86_64 GNU/Linux". /proc/cpuinfo shows a list of 96 cores
with the model name "AMD EPYC 7F72 24-Core Processor". All of the above
commands were executed in a Singularity container based on Debian 11.3.

The source file is a minimal example condensed from Valgrind's m_libcbase.c.

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de via Gcc-bugs]

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

--- Comment #1 from Max Aehle  ---
Created attachment 54746
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54746&action=edit
source code of minimal example

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de via Gcc-bugs]

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

--- Comment #2 from Max Aehle  ---
Created attachment 54747
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54747&action=edit
output with additional flag -v

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de via Gcc-bugs]

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

--- Comment #3 from Max Aehle  ---
Created attachment 54748
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54748&action=edit
preprocessed source produced with -freport-bug

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de via Gcc-bugs]

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

--- Comment #4 from Max Aehle  ---
Created attachment 54749
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54749&action=edit
produces with -save-temps

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de via Gcc-bugs]

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

--- Comment #5 from Max Aehle  ---
Created attachment 54750
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54750&action=edit
produced with -save-temps

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de via Gcc-bugs]

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

Max Aehle  changed:

   What|Removed |Added

  Attachment #54745|0   |1
is obsolete||

--- Comment #6 from Max Aehle  ---
Comment on attachment 54745
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54745
verbose output, preprocessed source, .i and .s file

I submitted the zip archive because I though that only a single file could be
attached. Afterwards, I attached all files in the archive to this bug report
individually.

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||11.1.0, 13.0
Summary|ICE: in |[11/12/13 Regression] ICE:
   |assign_stack_local_1, at|in assign_stack_local_1, at
   |function.cc:429 with|function.cc:429 with
   |-mpreferred-stack-boundary= |-mpreferred-stack-boundary=
   |2   |2
   Target Milestone|--- |11.4
   Keywords||ice-on-valid-code
  Known to work||10.1.0, 10.4.0, 9.5.0

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com,
   ||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
This started to ICE with r11-508-gdfa4fcdba374ed44 in the newly added pass
there,
and since r11-2259-g0a9d711df36b42b6494b73 it ICEs similarly like on the trunk.

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

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

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

--- Comment #8 from Andrew Pinski  ---
A workaround is to do:
long long int digit __attribute__((aligned(8)));

Note manually setting the digit alignment to 4 does not cause an ICE for GCC
10.4 either.

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-03-24

--- Comment #9 from Andrew Pinski  ---
Confirmed.

[Bug tree-optimization/109175] error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]

[malat at debian dot org via Gcc-bugs]

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

--- Comment #5 from Mathieu Malaterre  ---
c-reduce(d) ugly version:

% cat demo3.cc
struct d {
  using b = float &;
};
template  using c = d::b;
struct e {
  using b = c;
};
template  struct j;
template  using h = typename j::b;
template  struct p;
template  struct p<0, k, l...> { using b = k; };
template  class m;
template  struct aa {
  aa(n t) : o(t) {}
  static n ab(aa t) { return t.o; }
  n o;
};
template  struct q;
template 
struct q : q<1, s...>, aa {
  q(n t, s... ac) : q<1, s...>(ac...), aa(t) {}
};
template  struct q : aa {
  q(n t) : aa(t) {}
};
template  class m : public q<0, ad, ae> {
public:
  m(ad t, ae ac) : q<0, ad, ae>(t, ac) {}
};
template  struct j> {
  using b = typename p::b;
};
template  n ag(q t) {
  return q::ab(t);
}
template  h> ai(m t) { return ag(t);
}
class u {
  struct aj {
using b = float *;
  };

public:
  using ak = aj::b;
  u(ak t, int) : al(t, long()) {}
  ak w() { return ai<0>(al); }
  m al;
};
struct x : u {
  using u::u;
};
class y {
  x al;

public:
  using ak = u::ak;
  using am = int;
  template  y(an t, am ac) : al(t, ac) {}
  e::b operator[](long t) { return z()[t]; }
  ak z() { return al.w(); }
};
void *ao();
template  ap *aq(long t) {
  if (t)
return nullptr;
  return static_cast(ao());
}
template  using ar = y;
template  ar as(long t, void *) {
  return ar(aq(t), int());
}
template  ar as(long t) { return as(t, nullptr); }
float v;
void at(long t) {
  long a = sizeof(0), i = 0;
  auto b = as(t);
  for (; i < a; ++i)
b[i] = v;
  for (; i < t; ++i)
b[i] = 0.0f;
}

 % /usr/lib/gcc-snapshot/bin/g++ -Wall -O2 -o t.o -c demo3.cc
demo3.cc: In function 'void at(long int)':
demo3.cc:79:10: warning: 'void* __builtin_memset(void*, int, long unsigned
int)' writing 4 or more bytes into a region of size 0 overflows the destination
[-Wstringop-overflow=]
   79 | b[i] = 0.0f;
cc1plus: note: destination object is likely at address zero

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

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

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

--- Comment #10 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #7)
> This started to ICE with r11-508-gdfa4fcdba374ed44 in the newly added pass
> there,
> and since r11-2259-g0a9d711df36b42b6494b73 it ICEs similarly like on the
> trunk.

The new pass should just stack alignment requirements when alignment of
stack variable is increased.

[Bug fortran/85877] [10/11/12/13 Regression] ICE in fold_convert_loc, at fold-const.c:2449

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:0257ba766443f11cf61c52db9b480337e44b48c8

commit r11-10594-g0257ba766443f11cf61c52db9b480337e44b48c8
Author: Harald Anlauf 
Date:   Fri Mar 17 22:24:49 2023 +0100

Fortran: procedures with BIND(C) attribute require explicit interface
[PR85877]

gcc/fortran/ChangeLog:

PR fortran/85877
* resolve.c (resolve_fl_procedure): Check for an explicit interface
of procedures with the BIND(C) attribute (F2018:15.4.2.2).

gcc/testsuite/ChangeLog:

PR fortran/85877
* gfortran.dg/pr85877.f90: New test.

(cherry picked from commit 5426ab34643d9e6502f3ee572891a03471fa33ed)

[Bug fortran/109186] nearest(huge(x),-1.0_kind(x)) half of correct value

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

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

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

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

commit r11-10595-g4b722050fe8e7f06a3e653f290a39ccdc4d03174
Author: Harald Anlauf 
Date:   Sun Mar 19 21:29:46 2023 +0100

Fortran: simplification of NEAREST for large argument [PR109186]

gcc/fortran/ChangeLog:

PR fortran/109186
* simplify.c (gfc_simplify_nearest): Fix off-by-one error in
setting
up real kind-specific maximum exponent for mpfr.

gcc/testsuite/ChangeLog:

PR fortran/109186
* gfortran.dg/nearest_6.f90: New test.

(cherry picked from commit 4410a08b80cc40342eeaa5b6af824cd4352b218c)

[Bug fortran/99036] [11/12/13 Regression] ICE in gfc_current_interface_head, at fortran/interface.c:4699

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:2055702e8d492be6e978fa93a7bfefd358d5d9e3

commit r11-10596-g2055702e8d492be6e978fa93a7bfefd358d5d9e3
Author: Harald Anlauf 
Date:   Tue Mar 21 19:58:31 2023 +0100

Fortran: reject MODULE PROCEDURE outside generic module interface [PR99036]

gcc/fortran/ChangeLog:

PR fortran/99036
* decl.c (gfc_match_modproc): Reject MODULE PROCEDURE if not in a
generic module interface.

gcc/testsuite/ChangeLog:

PR fortran/99036
* gfortran.dg/pr99036.f90: New test.

(cherry picked from commit dd282b16bfd3c6e218dffb7798a375365b10ae22)

[Bug fortran/99036] [11/12/13 Regression] ICE in gfc_current_interface_head, at fortran/interface.c:4699

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #14 from anlauf at gcc dot gnu.org ---
Fixed on all affected branches.  Closing.

Thanks for the report!

[Bug fortran/85877] [10/11/12/13 Regression] ICE in fold_convert_loc, at fold-const.c:2449

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

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

--- Comment #15 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

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

commit r10-11264-gdca8e28c990547648543175de9b6e05356f77e8a
Author: Harald Anlauf 
Date:   Fri Mar 17 22:24:49 2023 +0100

Fortran: procedures with BIND(C) attribute require explicit interface
[PR85877]

gcc/fortran/ChangeLog:

PR fortran/85877
* resolve.c (resolve_fl_procedure): Check for an explicit interface
of procedures with the BIND(C) attribute (F2018:15.4.2.2).

gcc/testsuite/ChangeLog:

PR fortran/85877
* gfortran.dg/pr85877.f90: New test.

(cherry picked from commit 5426ab34643d9e6502f3ee572891a03471fa33ed)

[Bug fortran/109186] nearest(huge(x),-1.0_kind(x)) half of correct value

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

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

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

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

commit r10-11265-gb9f6e7e234bab6ef8b5425c3e8b88bf8dfbc5089
Author: Harald Anlauf 
Date:   Sun Mar 19 21:29:46 2023 +0100

Fortran: simplification of NEAREST for large argument [PR109186]

gcc/fortran/ChangeLog:

PR fortran/109186
* simplify.c (gfc_simplify_nearest): Fix off-by-one error in
setting
up real kind-specific maximum exponent for mpfr.

gcc/testsuite/ChangeLog:

PR fortran/109186
* gfortran.dg/nearest_6.f90: New test.

(cherry picked from commit 4410a08b80cc40342eeaa5b6af824cd4352b218c)

[Bug fortran/32630] [meta-bug] ISO C binding

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

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

Bug 85877 Summary: [10/11/12/13 Regression] ICE in fold_convert_loc, at 
fold-const.c:2449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85877

   What|Removed |Added

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

[Bug fortran/85877] [10/11/12/13 Regression] ICE in fold_convert_loc, at fold-const.c:2449

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #16 from anlauf at gcc dot gnu.org ---
Fixed on all affected branches.  Closing.

Thanks for the report!

[Bug fortran/109186] nearest(huge(x),-1.0_kind(x)) half of correct value

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
Fixed on all open branches.  Closing.

Thanks for the report!

[Bug tree-optimization/109175] error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]

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

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

--- Comment #6 from Andrew Pinski  ---
Reduced all the way removing all of the classes showing exactly what I thought
it was:
```
void *ao();
float *aq(long t) {
  if (t)
return nullptr;
  return static_cast(ao());
}
float v;
void at(long t) {
  long a = sizeof(0), i = 0;
  auto b = aq(t);
  for (; i < a; ++i)
b[i] = v;
  for (; i < t; ++i)
b[i] = 0.0f;
}
```

Notice how there is no check for null on aq.

[Bug c++/106969] [12/13 Regression] member function constness incorrectly propagates to local class member function return type deduction

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

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

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

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

commit r13-6856-gbbf2424c57c2e13d1a972c4ef4e871c3119b9cb4
Author: Patrick Palka 
Date:   Fri Mar 24 14:51:24 2023 -0400

c++: outer 'this' leaking into local class [PR106969]

Here when resolving the implicit object for '&wrapped' within the
local class Foo, we expect to obtain a dummy object of type Foo& since
there's no 'this' available in this context.  And yet at this point
current_class_ref still corresponds to the outer class Context (and is
const), which confuses maybe_dummy_object into propagating the cv-quals
of current_class_ref and returning an object of type const Foo&.  Thus
decltype(&wrapped) wrongly yields const int* instead of int*.

The problem ultimately seems to be that the 'this' from the enclosing
class appears available for use when parsing the local class, but 'this'
shouldn't persist across classes like that.  This patch fixes this by
clearing current_class_ptr/ref before parsing a class definition.

After this change, for the test name-clash11.C in C++98 mode we would
now complain about an invalid use of 'this' in e.g.

  ASSERT (sizeof (this->A) == 16);

due to the way the test defines the ASSERT macro via a local class.
This patch redefines the macro using a local typedef instead.

PR c++/106969

gcc/cp/ChangeLog:

* parser.cc (cp_parser_class_specifier): Clear current_class_ptr
and current_class_ref sooner, before parsing a class definition.

gcc/testsuite/ChangeLog:

* g++.dg/lookup/name-clash11.C: Fix ASSERT macro definition in
C++98 mode.
* g++.dg/lookup/this2.C: New test.

[Bug c++/106969] [12 Regression] member function constness incorrectly propagates to local class member function return type deduction

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[12/13 Regression] member   |[12 Regression] member
   |function constness  |function constness
   |incorrectly propagates to   |incorrectly propagates to
   |local class member function |local class member function
   |return type deduction   |return type deduction

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 13 so far

[Bug c++/109277] New: [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

Bug ID: 109277
   Summary: [13 Regression] type_traits:1417:30: error: invalid
use of incomplete type ‘class v8::internal::WasmArray’
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: redi at gcc dot gnu.org
  Target Milestone: ---

Reduced from chromium, gcc-12 accepts the code:

GCC 13 pre-processed source code:
https://gist.githubusercontent.com/marxin/377cbc8221f7c36e87aebe48a55b52ba/raw/b80443940faf20f6f5db124fb6a56d9bee994fee/promise13.ii

$ g++ -std=gnu++20 promise13.ii -c -w
In file included from /usr/include/math.h:398,
 from /usr/include/c++/13/cmath:47,
 from ../v8/src/utils/utils.h:12,
 from ../v8/src/zone/zone.h:15,
 from ../v8/src/handles/handles.h:14,
 from ../v8/src/ast/ast-value-factory.h:36,
 from ../v8/src/ast/ast.h:10,
 from
gen/v8/torque-generated/src/builtins/promise-all-element-closure-tq-csa.cc:1:
/usr/include/bits/mathcalls-helper-functions.h: In static member function
‘static int __iseqsig_type<_Float128>::__call(_Float128, _Float128)’:
/usr/include/bits/mathcalls-helper-functions.h:41:36: note:   initializing
argument 1 of ‘int __iseqsigl(long double, long double)’
   41 | __MATHDECL_ALIAS (int, __iseqsig,, (_Mdouble_ __x, _Mdouble_ __y),
iseqsig);
  |^~~
/usr/include/bits/mathcalls-helper-functions.h:41:53: note:   initializing
argument 2 of ‘int __iseqsigl(long double, long double)’
   41 | __MATHDECL_ALIAS (int, __iseqsig,, (_Mdouble_ __x, _Mdouble_ __y),
iseqsig);
  | ^~~
In file included from /usr/include/c++/13/bits/move.h:57,
 from /usr/include/c++/13/bits/new_allocator.h:36,
 from
/usr/include/c++/13/aarch64-suse-linux/bits/c++allocator.h:33,
 from /usr/include/c++/13/bits/allocator.h:46,
 from /usr/include/c++/13/memory:65,
 from ../v8/src/ast/ast.h:8:
/usr/include/c++/13/type_traits: In instantiation of ‘struct
std::is_convertible’:
../v8/src/codegen/tnode.h:273:72:   required from ‘const bool
v8::internal::is_subtype::value’
../v8/src/codegen/tnode.h:361:75:   required by substitution of ‘template::value, int>::type  >
v8::internal::TNode::TNode(const
v8::internal::TNode&) [with U = v8::internal::WasmArray; typename
std::enable_if::value,
int>::type  = ]’
/usr/include/c++/13/tuple:188:12:   required from ‘struct std::_Head_base<0,
v8::internal::TNode, false>’
/usr/include/c++/13/tuple:259:12:   required from ‘struct std::_Tuple_impl<0,
v8::internal::TNode,
v8::internal::TNode,
v8::internal::TNode >’
/usr/include/c++/13/tuple:746:11:   required from ‘class
std::tuple,
v8::internal::TNode,
v8::internal::TNode >’
gen/v8/torque-generated/csa-types.h:487:80:   required from here
/usr/include/c++/13/type_traits:1417:30: error: invalid use of incomplete type
‘class v8::internal::WasmArray’
 1417 | : public __bool_constant<__is_convertible(_From, _To)>
  |  ^~~~
In file included from ../v8/src/heap/factory-base.h:15,
 from ../v8/src/heap/factory.h:18,
 from ../v8/src/ast/ast.h:18:
gen/v8/torque-generated/class-forward-declarations.h:291:7: note: forward
declaration of ‘class v8::internal::WasmArray’
In file included from ../v8/src/codegen/interface-descriptors.h:13,
 from ../v8/src/codegen/callable.h:8,
 from ../v8/src/codegen/code-factory.h:8,
 from ../v8/src/codegen/code-stub-assembler.h:12,
 from ../v8/src/builtins/builtins-array-gen.h:8,
 from
gen/v8/torque-generated/src/builtins/promise-all-element-closure-tq-csa.cc:2:
../v8/src/codegen/tnode.h: In instantiation of ‘const bool
v8::internal::is_subtype::value’:
../v8/src/codegen/tnode.h:361:75:   required by substitution of ‘template::value, int>::type  >
v8::internal::TNode::TNode(const
v8::internal::TNode&) [with U = v8::internal::WasmArray; typename
std::enable_if::value,
int>::type  = ]’
/usr/include/c++/13/tuple:188:12:   required from ‘struct std::_Head_base<0,
v8::internal::TNode, false>’
/usr/include/c++/13/tuple:259:12:   required from ‘struct std::_Tuple_impl<0,
v8::internal::TNode,
v8::internal::TNode,
v8::internal::TNode >’
/usr/include/c++/13/tuple:746:11:   required from ‘class
std::tuple,
v8::internal::TNode,
v8::internal::TNode >’
gen/v8/torque-generated/csa-types.h:487:80:   required from here
../v8/src/codegen/tnode.h:273:72: error: ‘value’ is not a member of
‘std::is_convertible’

GCC 12 pre-processed source cod

[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-03-24
 Status|UNCONFIRMED |NEW
 CC||jason at gcc dot gnu.org

[Bug fortran/109275] Bad error messages for interfaces describing surrounding program unit

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2023-03-24
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||diagnostic

[Bug tree-optimization/109175] error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]

[jan.wassenberg at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Jan Wassenberg  ---
Thanks, I will be changing the code to add a nullptr check.