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

2022-08-19 Thread janezz55 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689

--- Comment #6 from Janez Zemva  ---
I have since changed the repo. You can still demonstrate the bug by
uncommenting the line:

//[&a, &r, &s]() noexcept -> bool // uncomment for bug

[Bug debug/106263] BTF_KIND_FUNC type does not encode linkage

2022-08-19 Thread james.hilliard1 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106263

--- Comment #2 from James Hilliard  ---
Should this be backported to the gcc 12 branch?

[Bug fortran/106684] inconsistent array initialization

2022-08-19 Thread jorn--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684

--- Comment #7 from Jorn Bruggeman  ---
None from me; thanks for the explanation!

[Bug c/106694] New: Redundant move instructions in ARM SVE intrinsics use cases

2022-08-19 Thread juzhe.zhong at rivai dot ai via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106694

Bug ID: 106694
   Summary: Redundant move instructions in ARM SVE intrinsics use
cases
   Product: gcc
   Version: rust/master
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juzhe.zhong at rivai dot ai
  Target Milestone: ---

Here is the example: https://godbolt.org/z/4zPK7j8vT

The codes:
#include "arm_sve.h"

int coalesce (svbool_t pg, int64_t* base, int n, int32_t *in1, int64_t *in2,
int64_t*out)
{
  svint64x4_t result = svld4_s64 (pg, base);
  svint64_t v0 = svget4_s64(result, 0);
  svint64_t v1 = svget4_s64(result, 1);
  svint64_t v2 = svget4_s64(result, 2);
  svint64_t v3 = svget4_s64(result, 3);

  for (int i = 0; i < n; i += 1)
{
svint64_t v18 = svld1_s64(pg, in1);
svint64_t v19 = svld1_s64(pg, in2);
v0 = svmad_s64_z(pg, v0, v18, v19);
v1 = svmad_s64_z(pg, v1, v18, v19);
v2 = svmad_s64_z(pg, v2, v18, v19);
v3 = svmad_s64_z(pg, v3, v18, v19);
}
  svst1_s64(pg, out+0,v0);
  svst1_s64(pg, out+1,v1);
  svst1_s64(pg, out+2,v2);
  svst1_s64(pg, out+3,v3);
}

Assembly:
coalesce:
ld4d{z24.d - z27.d}, p0/z, [x0]
mov z5.d, z24.d
mov z4.d, z25.d
mov z3.d, z26.d
mov z2.d, z27.d
cmp w1, 0
ble .L2
mov w0, 0
ld1dz1.d, p0/z, [x2]
ld1dz0.d, p0/z, [x3]
.L3:
add w0, w0, 1
movprfx z5.d, p0/z, z5.d
mad z5.d, p0/m, z1.d, z0.d
movprfx z4.d, p0/z, z4.d
mad z4.d, p0/m, z1.d, z0.d
movprfx z3.d, p0/z, z3.d
mad z3.d, p0/m, z1.d, z0.d
movprfx z2.d, p0/z, z2.d
mad z2.d, p0/m, z1.d, z0.d
cmp w1, w0
bne .L3
.L2:
add x3, x4, 8
add x2, x4, 16
add x1, x4, 24
st1dz5.d, p0, [x4]
st1dz4.d, p0, [x3]
st1dz3.d, p0, [x2]
st1dz2.d, p0, [x1]
ret

The "mov" instructions are redundant. I think the issue is that GCC doesn't
have the register coalescing like LLVM.

The subreg can not propagate accorss basic blocks.

Can someone implement register coalesing or subreg forwarding across basic
blocks?

Thanks.

[Bug target/106691] Section anchors is not efficient for riscv

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106691

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Waterman from comment #3)
> Relaxation to gp happens at link time

Doing any kind of relaxation like this is REALLY REALLY BAD at link time.
Sorry but the whole relaxation in the RISCV linker needs to be thrown away ...

[Bug target/106691] Section anchors is not efficient for riscv

2022-08-19 Thread andrew at sifive dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106691

--- Comment #3 from Andrew Waterman  ---
Relaxation to gp happens at link time, and because of the relatively small
load/store offsets, the small-data limit is actually useful.  I don't think we
should turn it off, because when we relax to gp, we get lower instruction count
than we'd get with anchors.  (But it's obviously a gamble, since we aren't
guaranteed to get relaxation, depending on the section size.)

I do see that for -fPIC (where gp relaxation isn't enabled) and for large
objects, anchors seem to be working.

[Bug middle-end/106692] [10/11/12/13 Regression] Cray pointer comparison wrongly optimized away

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106692

--- Comment #2 from Andrew Pinski  ---
(In reply to Marek Polacek from comment #1)
> Started with r238754 but removing that match.pd doesn't help, so the problem
> is elsewhere.
> 
> We optimize away zz1_1(D) != 0:
> 
>  __attribute__((fn spec (". w ")))
>  void shape_cray (real(kind=4) & restrict zz1)
>  {
>integer(kind=8) ptrzz;
> -  integer(kind=8) _2;
> +  integer(kind=8) _3;
>  
> :
> -  _2 = (integer(kind=8)) zz1_1(D);
> -  if (zz1_1(D) != 0)
> -goto ; [INV]
> -  else
> -goto ; [INV]
> -
> -   :
> +  _3 = (integer(kind=8)) zz1_1(D);
>_gfortran_abort ();

I suspect there was a patch which special case references to say they cannot be
null in the middle-end.

[Bug target/106691] Section anchors is not efficient for riscv

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106691

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|Section anchors is not  |Section anchors is not
   |implemented for riscv   |efficient for riscv
   Last reconfirmed||2022-08-19
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Oh it is because -msmall-data-limit defaults to 8.

And default_use_anchors_for_symbol_p returns false for small data sections:
  /* Don't use anchors for small data sections.  The small data register
 acts as an anchor for such sections.  */
  if (sect->common.flags & SECTION_SMALL)
return false;

But there is no small data register ...

[Bug middle-end/106692] [10/11/12/13 Regression] Cray pointer comparison wrongly optimized away

2022-08-19 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106692

--- Comment #1 from Marek Polacek  ---
Started with r238754 but removing that match.pd doesn't help, so the problem is
elsewhere.

We optimize away zz1_1(D) != 0:

 __attribute__((fn spec (". w ")))
 void shape_cray (real(kind=4) & restrict zz1)
 {
   integer(kind=8) ptrzz;
-  integer(kind=8) _2;
+  integer(kind=8) _3;

:
-  _2 = (integer(kind=8)) zz1_1(D);
-  if (zz1_1(D) != 0)
-goto ; [INV]
-  else
-goto ; [INV]
-
-   :
+  _3 = (integer(kind=8)) zz1_1(D);
   _gfortran_abort ();

-   :
-  return;
-
 }

[Bug target/106691] Section anchors is not implemented for riscv

2022-08-19 Thread andrew at sifive dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106691

Andrew Waterman  changed:

   What|Removed |Added

 CC||andrew at sifive dot com

--- Comment #1 from Andrew Waterman  ---
Oddly enough, I remember that section anchors used to work for RISC-V, and I
see TARGET_MIN_ANCHOR_OFFSET and TARGET_MAX_ANCHOR_OFFSET are still defined.

[Bug ada/106693] New: gnat: poisoned calloc in gcc/ada/adaint.[hc] due to use of sched.h on musl

2022-08-19 Thread andrewathalye at outlook dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106693

Bug ID: 106693
   Summary: gnat: poisoned calloc in gcc/ada/adaint.[hc] due to
use of sched.h on musl
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrewathalye at outlook dot com
  Target Milestone: ---

On musl libc, sched.h makes use of calloc in a definition, which triggers GCC's
#pragma GNU poision from system.h. adaint.h and adaint.c cause this problem to
occur while building a native compiler, since they both conditionally include
sched.h.

Alpine Linux bypasses this by dropping the include and using void* instead of
cpu_set_t*. It could also be resolved the same way as the earlier bug 106102,
for example by creating a define USE_SCHED_H and implementing it before calloc
is poisoned.

[Bug middle-end/106692] New: [10/11/12/13 Regression] Cray pointer comparison wrongly optimized away

2022-08-19 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106692

Bug ID: 106692
   Summary: [10/11/12/13 Regression] Cray pointer comparison
wrongly optimized away
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

The following program crashes with -O but not -O0:
$ ./f951 -quiet -frecursive -fPIC -ffixed-line-length-132 -fautomatic
-fcray-pointer -O x.f; gfortran x.s; ./a.out

Program aborted. Backtrace:
#0  0x7fa618e23a12 in ???
#1  0x7fa618e2444d in ???
#2  0x7fa619078d0c in ???
#3  0x401153 in ???
#4  0x401161 in ???
#5  0x401192 in ???
#6  0x7fa618a2954f in __libc_start_call_main
at ../sysdeps/nptl/libc_start_call_main.h:58
#7  0x7fa618a29608 in __libc_start_main_impl
at ../csu/libc-start.c:389
#8  0x401084 in ???
#9  0x in ???
Aborted (core dumped)

$ cat x.f
  program test
  k=1
  call  test_cray(k)
  end

  subroutine test_cray(k)
pointer(ptrzz1 , zz1)
ptrzz1=0
if (ptrzz1 .ne. 0) then
  call abort()
else
  call shape_cray(zz1)
end if
  end

  subroutine shape_cray(zz1)
pointer(ptrzz , zz)
ptrzz=loc(zz1)
if (ptrzz .ne. 0) then
  call abort()
end if
  end

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

2022-08-19 Thread janezz55 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689

--- Comment #5 from Janez Zemva  ---
The workaround is very simple, just put "[&]() noexcept -> bool" into sq2.hpp.

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

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug target/106691] New: Section anchors is not implemented for riscv

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106691

Bug ID: 106691
   Summary: Section anchors is not implemented for riscv
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: riscv

Take:
static int a, b;

int f(void)
{
  return a+b;
}

void g(int c, int d)
{
 a = c;
 b = d;
}
--- CUT ---
Right now riscv32-linux-gnu produces:
f:
lui a5,%hi(a)
lw  a0,%lo(a)(a5)
lui a5,%hi(b)
lw  a5,%lo(b)(a5)
add a0,a0,a5
ret
g:
lui a5,%hi(a)
sw  a0,%lo(a)(a5)
lui a5,%hi(b)
sw  a1,%lo(b)(a5)
ret

While aarch64 produces:
f:
adrpx0, .LANCHOR0
add x2, x0, :lo12:.LANCHOR0
ldr w1, [x0, #:lo12:.LANCHOR0]
ldr w0, [x2, 4]
add w0, w1, w0
ret
g:
adrpx2, .LANCHOR0
add x3, x2, :lo12:.LANCHOR0
str w0, [x2, #:lo12:.LANCHOR0]
str w1, [x3, 4]
ret

One less instruction.

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

2022-08-19 Thread janezz55 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689

--- Comment #4 from Janez Zemva  ---
Created attachment 53482
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53482&action=edit
preprocessed source

[Bug tree-optimization/106247] GCC12 warning in Eigen: array subscript is partly outside array bounds

2022-08-19 Thread glisse at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106247

Marc Glisse  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #6 from Marc Glisse  ---
(In reply to Andrew Pinski from comment #2)
> the warning is correct in the sense the load is there in IR, though it looks
> like it is dead (but only because b and a are unused):

#include 
Eigen::Array a;
Eigen::Array b;
void f(){
b.col(0).tail(2) = a.col(1);
}

still warns about some 256 bit code which is still very dead (we later optimize
the whole function to just
  _64 = MEM  [(char * {ref-all})&a + 16B];
  MEM  [(char * {ref-all})&b + 8B] = _64;
)
so the fact that a and b are unused in the original testcase is not important.

I assume there were good reasons to put the warning this early (VRP1), but it
means that some dead code that will be removed later is still around.

(@Daniel: it can be easier to track things with separate issues, if you have a
different testcase to provide)

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

2022-08-19 Thread janezz55 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689

--- Comment #3 from Janez Zemva  ---
BTW: I already tried to make a minimal test case, but failed, all compiled
fine. Maybe tomorrow.

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

2022-08-19 Thread janezz55 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689

--- Comment #2 from Janez Zemva  ---
Sorry, I can't, because I already changed the code a little and I'm keeping the
repo such as it is so as to not invalidate this bug report. Why not clone the
repo and do what you need to do? I'm keeping it in exact state of my bug
report.

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

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Can you attach the preprocessed source which should be easy to get with
-freport-bug ? You can compress it if you need to.

[Bug testsuite/106690] check_effective_target_bswap should be enabled for riscv if ZBB ISA extension is enabled

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106690

--- Comment #2 from Andrew Pinski  ---
Created attachment 53481
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53481&action=edit
patch under testing

[Bug testsuite/106690] check_effective_target_bswap should be enabled for riscv if ZBB ISA extension is enabled

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106690

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
The easiest way is to check if __riscv_zbb > 0.

Mine.

[Bug testsuite/106690] New: check_effective_target_bswap should be enabled for riscv if ZBB ISA extension is enabled

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106690

Bug ID: 106690
   Summary: check_effective_target_bswap should be enabled for
riscv if ZBB ISA extension is enabled
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

While looking into __builtin_bswap testcases to quickly run before doing a fun
test run, I Noticed check_effective_target_bswap does not see if ZBB is enabled
for RISCV.

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

2022-08-19 Thread janezz55 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689

Bug ID: 106689
   Summary: gcc crash while compiling a generic lambda
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janezz55 at gmail dot com
  Target Milestone: ---

Reproducing the crash is easy, clone my repository:

https://github.com/user1095108/sq2

then compile:

g++ -std=c++20 -Ofast sq2.cpp -s -o sq2 -lsqlite3

In file included from sq2.cpp:5:
sq2.hpp: In instantiation of 'sq2::bind<>(std::unique_ptr&, double&&, int&&) requires  bool(sizeof ...
((sq2::bind::a ...)))::)> [with auto ...J =
{0, 1}; std::index_sequence = std::integer_sequence]':
sq2.hpp:172:6:   required from 'auto sq2::bind(auto:26&&, auto:27&& ...)
requires  bool(sizeof ... ((sq2::bind::a ...))) [with int I = 1; auto:26 =
std::unique_ptr&; auto:27 =
{double, int}]'
sq2.cpp:62:14:   required from here
sq2.hpp:108:11: internal compiler error: trying to capture 'a#0' in
instantiation of generic lambda
  108 | [&a, &r, s(detail::get(stmt))]() noexcept -> bool
  |   ^
0x19ea8d8 internal_error(char const*, ...)
???:0
0x71c477 add_capture(tree_node*, tree_node*, tree_node*, bool, bool)
???:0
0x71c4e3 add_default_capture(tree_node*, tree_node*, tree_node*)
???:0
0x7e224a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
???:0
0x7e0aca tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
???:0
0x7f7957 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x7e205f tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
???:0
0x7e05c7 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
???:0
0x7e8cac tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
???:0
0x7dfea9 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
???:0
0x7daf63 instantiate_decl(tree_node*, bool, bool)
???:0
0x6edadb mark_used(tree_node*, int)
???:0
0x68b81f build_op_call(tree_node*, vec**, int)
???:0
0x810e4d finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x7e1e2c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
???:0
0x7daf63 instantiate_decl(tree_node*, bool, bool)
???:0
0x6edadb mark_used(tree_node*, int)
???:0
0x68ad5b build_new_function_call(tree_node*, vec**, int)
???:0
0x810680 finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x7c79bc c_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

uname -a
Linux e5-2620v2 5.19.2-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 17 Aug 2022 13:48:51
+ x86_64 GNU/Linux

clang 14 also crashes. Amazing, but we don't care.

[Bug target/99089] unnecessary zero extend before AND

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99089

--- Comment #3 from Andrew Pinski  ---
The zero extend is gone on the trunk ...

[Bug middle-end/106688] out of ssa Coalescing sometimes chooses the wrong thing causing an extra move

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106688

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
I Knew there was an older bug about a similar thing. See PR 86270 and PR 70359.

[Bug middle-end/106688] out of ssa Coalescing sometimes chooses the wrong thing causing an extra move

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106688

--- Comment #6 from Andrew Pinski  ---
-fno-tree-coalesce-vars also fixes the issue.

[Bug middle-end/106688] out of ssa Coalescing sometimes chooses the wrong thing causing an extra move

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106688

Andrew Pinski  changed:

   What|Removed |Added

Summary|leaving SSA emits   |out of ssa Coalescing
   |assignment into the inner   |sometimes chooses the wrong
   |loop|thing causing an extra move

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> Oh yes out of ssa used the wrong coalescing:
> Coalesce list: (24)buf_24 & (33)_33 [map: 9, 16] : Success -> 9
> 
> Just by accident.

The reason why nothing in the RTL can clean it up is because the psedu-register
is used inside the loop and outside of the loop.

[Bug middle-end/106688] leaving SSA emits assignment into the inner loop

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106688

Andrew Pinski  changed:

   What|Removed |Added

  Component|rtl-optimization|middle-end

--- Comment #4 from Andrew Pinski  ---
Oh yes out of ssa used the wrong coalescing:
Coalesce list: (24)buf_24 & (33)_33 [map: 9, 16] : Success -> 9

Just by accident.

[Bug rtl-optimization/106688] leaving SSA emits assignment into the inner loop

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106688

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||ra
   Severity|normal  |enhancement
  Component|tree-optimization   |rtl-optimization
   Last reconfirmed||2022-08-19
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
With --param lim-expensive=0, the cast was pulled out of the loop and the move
is gone too.

But then again the register move should have been removed during register
allocation ...

[Bug tree-optimization/106688] leaving SSA emits assignment into the inner loop

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106688

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |tree-optimization

--- Comment #2 from Andrew Pinski  ---
_33 = (const unsigned char *) ivtmp.18_7;
  invariant up to level 2, cost 1.

[Bug middle-end/106688] leaving SSA emits assignment into the inner loop

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106688

--- Comment #1 from Andrew Pinski  ---
(In reply to Alexander Monakov from comment #0)
> It looks as if going out of SSA places in the loop a register copy
> corresponding to a phi node which is outside of the loop. Strangely, RTL
> optimizations do not clean it up either.

No it is IVOPTs that places the copy inside the loop:
   [local count: 1006632961]:
  # buf_25 = PHI 
  # vs1_28 = PHI 
  __asm__("pmovzxbw %1, %0" : "=x" b_17 : "m" MEM[(i8v8 *)buf_25]);
  vs1_18 = b_17 + vs1_28;
  _15 = (unsigned long) buf_25;
  _14 = _15 + 8;
  _2 = (const unsigned char *) _14;
  __asm__("pmovzxbw %1, %0" : "=x" b_19 : "m" MEM[(i8v8 *)_2]);
  vs1_20 = vs1_18 + b_19;
  buf_21 = buf_25 + 16;
  _33 = (const unsigned char *) ivtmp.18_7;
  if (buf_21 != _33)
goto ; [93.75%]
  else
goto ; [6.25%]

Notice the cast is of ivtmp.18_7 assigned to _33 here. The cast is an
invariant.

I don't know why LIM4 didn't pull out the invariant.

[Bug fortran/106684] inconsistent array initialization

2022-08-19 Thread sgk at troutmask dot apl.washington.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684

--- Comment #6 from Steve Kargl  ---
On Fri, Aug 19, 2022 at 07:16:21PM +, j...@bolding-bruggeman.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684
> 
> --- Comment #5 from Jorn Bruggeman  ---
> Thanks; it does look like older gfortran versions (and ifort) are too 
> forgiving
> here, and that, given the F2018 definition of "conformable", the latest
> gfortran releases are correct.
> 
> As for "stand-alone" variables, I just means regular variables (i.e., not a
> component of a derived type). What surprised me is that this still compiles
> fine in latest gfortran versions:
> 
> program p
>implicit none
> 
>real :: a(2,2)
>data a /0., 1., 2., 3./
> end program
> 
> with the data assigned to "a" seemingly being of rank 1. However, this seems 
> to
> work because the rules governing "data" statements for arrays explicitly
> describe the target elements ("a") being unpacked in array order, and the 
> total
> number of values having to match.
> 
> Conversely, this is [correctly] rejected by the latest gfortran versions:
> 
> program p
>implicit none
> 
>real :: a(2,2) = (/0., 1., 2., 3./)
> end program
> 
> All in all, I accept this change in 10.4 and 11.3 was not a bug but an
> improvement. It unfortunately does mean that the code (not my own, but one I
> depend on) will need changes in >100 places...
> 

I see.  I suspect we're seeing mixing of old FORTRAN 77 
and the new fangle Fortran.  DATA statements go back to 
at leaset F77 (if not F66, to lazy to check).

F2018: 8.6.7 DATA statement

   The data-stmt-object-list is expanded to form a sequence of
   pointers and scalar variables, referred to as "sequence of
   variables" in subsequent text.  A nonpointer array whose
   unqualified name appears as a data-stmt-object or data-i-do-object
   is equivalent to a complete sequence of its array elements in
   array element order (9.5.3.2).

If there's no onjection I'll close this with INVALID.

[Bug middle-end/106688] New: leaving SSA emits assignment into the inner loop

2022-08-19 Thread amonakov at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106688

Bug ID: 106688
   Summary: leaving SSA emits assignment into the inner loop
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

For the following testcase, gcc -O2

unsigned foo(const unsigned char *buf, long size);
unsigned bar(const unsigned char *buf, long size)
{
typedef char  i8v8  __attribute__((vector_size(8)));
typedef short i16v8 __attribute__((vector_size(16)));
long chunk_sz = 15*16;
for (; size >= chunk_sz; size -= chunk_sz) {
i16v8 vs1 = { 0 };
const unsigned char *end = buf + chunk_sz;
for (; buf != end; buf += 16) {
i16v8 b;
asm("pmovzxbw %1, %0" : "=x"(b) : "m"(*(i8v8*)buf));
vs1 += b;
asm("pmovzxbw %1, %0" : "=x"(b) :
"m"(*(i8v8*)(buf+8)));
vs1 += b;
}
asm("" :: "x"(vs1));
}
return foo(buf, size);
}

(asms needed due to PR 31667)

generates

bar:
cmp rsi, 239
jle .L2
lea rdx, [rdi+240]
.L4:
lea rax, [rdx-240]
pxorxmm0, xmm0
.L3:
pmovzxbw QWORD PTR [rax], xmm1
add rax, 16
paddw   xmm0, xmm1

mov rdi, rdx ; <<< ehhh

pmovzxbw QWORD PTR [rax-8], xmm1
paddw   xmm0, xmm1
cmp rax, rdx
jne .L3
sub rsi, 240
add rdx, 240
cmp rsi, 239
jg  .L4
.L2:
jmp foo

It looks as if going out of SSA places in the loop a register copy
corresponding to a phi node which is outside of the loop. Strangely, RTL
optimizations do not clean it up either.

[Bug fortran/106684] inconsistent array initialization

2022-08-19 Thread jorn--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684

--- Comment #5 from Jorn Bruggeman  ---
Thanks; it does look like older gfortran versions (and ifort) are too forgiving
here, and that, given the F2018 definition of "conformable", the latest
gfortran releases are correct.

As for "stand-alone" variables, I just means regular variables (i.e., not a
component of a derived type). What surprised me is that this still compiles
fine in latest gfortran versions:

program p
   implicit none

   real :: a(2,2)
   data a /0., 1., 2., 3./
end program

with the data assigned to "a" seemingly being of rank 1. However, this seems to
work because the rules governing "data" statements for arrays explicitly
describe the target elements ("a") being unpacked in array order, and the total
number of values having to match.

Conversely, this is [correctly] rejected by the latest gfortran versions:

program p
   implicit none

   real :: a(2,2) = (/0., 1., 2., 3./)
end program

All in all, I accept this change in 10.4 and 11.3 was not a bug but an
improvement. It unfortunately does mean that the code (not my own, but one I
depend on) will need changes in >100 places...

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

2022-08-19 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101

--- Comment #13 from Segher Boessenkool  ---
(Sorry I missed this)

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

So you are suggesting that every strict_low_part after reload can just be
removed?  If that is true, should we not just do exactly that then?

[Bug fortran/106684] inconsistent array initialization

2022-08-19 Thread sgk at troutmask dot apl.washington.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684

--- Comment #4 from Steve Kargl  ---
On Fri, Aug 19, 2022 at 06:01:46PM +, j...@bolding-bruggeman.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684
> 
> --- Comment #2 from Jorn Bruggeman  ---
> 
> Are you effectively saying that 10.3 and 11.2 (as well as all ifort versions I
> am aware of) are too forgiving in both cases (accepting data of different rank
> as long at the totals number of elements is the same), while 10.4 and 11.3 are
> still too forgiving when it comes to stand-alone array variables?
> 

What I am saying is that the code is nonconforming.  Intel
and older versions of gfortran do not detect or report the
nonconformance.  Newer versions of gfortran have grown an
ability to detect the shape mismatch in your code and so
reported an error.  ifort might flag an issue if you give
it the right option to request strict standard conformance.

I don't know want you mean be stand-alone variable.  The program
I posted shows the non-conformance due to different shapes.

[Bug fortran/106684] inconsistent array initialization

2022-08-19 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
Many other compilers give similar error messages as gfortran.

Crayftn:

   data c /t(1, (/0., 1., 2., 3./))/
^
ftn-360 crayftn: ERROR P, File = pr106684.f90, Line = 12, Column = 17 
  The rank of derived type constructor component number 2 does not match the
declared rank.

Cray Fortran : Version 14.0.0
(20220420160222_c98838affc7b58fed2a72f164d77c35e1bc8772f)
Cray Fortran : Compile time:  0.0412 seconds
Cray Fortran : 14 source lines
Cray Fortran : 1 errors, 0 warnings, 0 other messages, 0 ansi
Cray Fortran : "explain ftn-message number" gives more information about each
message.


NAG:

NAG Fortran Compiler Release 7.0(Yurakucho) Build 7009
Warning: pr106684.f90, line 13: Local variable A is initialised but never used
Warning: pr106684.f90, line 13: Local variable C is initialised but never used
Error: pr106684.f90, line 12: Rank 1 value for rank 2 array A
Errors in declarations, no further processing for P
[NAG Fortran Compiler error termination, 1 error, 2 warnings]


Oracle/Sunstudio:

   data c /t(1, (/0., 1., 2., 3./))/
^
"pr106684.f90", Line = 12, Column = 17: ERROR: The rank of derived type
constructor component "A" does not match the declared rank.


Nvidia gives a warning, but otherwise swallows the code.


As there is pretty good agreement here, and if you likely want portable code,
I'd recommend to adjust your code as Steve suggested.  Don't rely only on
Intel.

[Bug fortran/106684] inconsistent array initialization

2022-08-19 Thread jorn--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684

--- Comment #2 from Jorn Bruggeman  ---
I interpret the quoted F2018, 7.5.10 as "the same rules should govern
initialization of components of derived types and initialization of stand-alone
variables". That was previously (in 10.3, 11.2, and other compilers such as
ifort) the case: multidimensional arrays could be initialized with 1d data,
whether they were stand-alone variables or components of a derived type (note
that it was not just accepted by the compiler - it worked fine too). Now, in
10.4 and 11.3, that is no longer the case: the requirements on initialization
of type components have become more stringent as they demand the expression to
have the same rank. Assignments to stand-alone variables can still have
different rank.

Are you effectively saying that 10.3 and 11.2 (as well as all ifort versions I
am aware of) are too forgiving in both cases (accepting data of different rank
as long at the totals number of elements is the same), while 10.4 and 11.3 are
still too forgiving when it comes to stand-alone array variables?

Adding reshape does work - but it means the shape needs to be repeated twice,
once in the declaration and once in the assigned value, which seems suboptimal.

[Bug target/106600] __builtin_bswap32 is not hooked up for ZBB

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106600

--- Comment #2 from Andrew Pinski  ---
Created attachment 53480
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53480&action=edit
Patch which is under test

[Bug target/106601] __builtin_bswap16 code gen could be improved with ZBB enabled

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106601

--- Comment #3 from Andrew Pinski  ---
Created attachment 53479
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53479&action=edit
Patch which is under test

[Bug fortran/106684] inconsistent array initialization

2022-08-19 Thread kargl at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684

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 ---
F2018, 7.5.10 Construction of derived-type values

   For a nonpointer component, the declared type and type parameters of the
   component and expr shall conform in the same way as for a variable and
   expr in an intrinsic assignment statement (10.2.1.2).

F2018, 10.2.1.2 Intrinsic assignment statement

   In an intrinsic assignment statement,
   ...
   (3) the variable and expr shall be conformable unless the variable
   is an allocatable array that has the same rank as expr and is
   not a coarray,

F2018:
   3.36
   conformable
   of two data entities having the same shape, or one being an array
   and the other being scalar


% cat a.f90
program p
   implicit none
   a = (/0., 1., 2., 3./)
end program

% gfcx -o z a.f90
a.f90:13:3:

   13 |a = (/0., 1., 2., 3./)
  |   1
Error: Incompatible ranks 2 and 1 in assignment at (1)


Looks like a bug in your program.  The quoted text is not a numbered constraint
so a Fortran compiler is not required to report an issue.  In this case,
gfortran was able to diagnose an issue in your code.  Simple fix is to use
`reshape([0.,1.,2.,3.],[2.2]) in your constrcutor.

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

2022-08-19 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106686

--- Comment #1 from Tobias Burnus  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600033.html

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

2022-08-19 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 105348, which changed state.

Bug 105348 Summary: Overly aggressive -Warray-bounds after conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105348

   What|Removed |Added

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

[Bug middle-end/105348] Overly aggressive -Warray-bounds after conditional

2022-08-19 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105348

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Resolved as invalid per comment #3.

[Bug tree-optimization/106247] GCC12 warning in Eigen: array subscript is partly outside array bounds

2022-08-19 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106247

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed|2022-07-10 00:00:00 |2022-08-19
 Ever confirmed|0   |1
 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
This instance of -Warray-bounds (with the text "partly outside the bounds") is
often issued for aliasing violations where an object of one type is being
access by an lvalue of a larger struct.  The ultimate access may be to a member
of the larger struct whose offset is within the bounds of the smaller object,
but the access is (or could be) wrong nonetheless (due to the aliasing rules)
and hence the warning.

Here's an example:

$ cat a.c && gcc -O2 -S -Wall a.c
struct A { int i; };
struct B { struct A a; int j; };

void* f (void)
{
  struct A *p = __builtin_malloc (sizeof *p);
  ((struct B*)p)->a.i = 0;
  return p;
}
a.c: In function ‘f’:
a.c:7:17: warning: array subscript ‘struct B[0]’ is partly outside array bounds
of ‘unsigned char[4]’ [-Warray-bounds]
7 |   ((struct B*)p)->a.i = 0;
  | ^~
a.c:6:17: note: object of size 4 allocated by ‘__builtin_malloc’
6 |   struct A *p = __builtin_malloc (sizeof *p);
  | ^~~~

If your case is comparable this should be resolved as invalid; otherwise, if
it's substantially different please post a reproducible test case.

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

2022-08-19 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 106446, which changed state.

Bug 106446 Summary: -Warray-bounds false positive on downcast under condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106446

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

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

2022-08-19 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106446

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Martin Sebor  ---
The compiler doesn't know what D2::is_me() might return so it must emit code
for both branches in bar().  In the true branch, because struct D1 has no
member val, the warning triggers.  This is by design.

[Bug c++/106648] [C++23] P2071 - Named universal character escapes

2022-08-19 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106648

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #53471|0   |1
is obsolete||

--- Comment #2 from Jakub Jelinek  ---
Created attachment 53478
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53478&action=edit
gcc13-pr106648-wip.patch.xz

Updated WIP patch.  This has fixed bugs in the generator and a routine that
implements the mapping (tested on names from glibc UTF-8 and
https://eel.is/c++draft/lex.charset table so far), but isn't actually wired up
for \N{name}.
It does for now just exact matching, for fixit hints we'll need to do something
slightly different.

[Bug tree-optimization/106687] [13 Regression] Wrong code with -O2

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106687

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-19
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Target Milestone|--- |13.0
  Known to fail||13.0
  Known to work||12.1.0

--- Comment #1 from Andrew Pinski  ---
Something more reduced:
bool var_0 = (bool)0;
unsigned int var_7 = 42;
char var_215;

int main() {
unsigned b = var_0;
unsigned p2 = var_7;
unsigned *tp;
if (b < p2)
  tp = &p2;
else
  tp = &b;
unsigned tt = *tp;
unsigned t = tt ^ (var_7 - var_0);
var_215 = t ? t : 42;
if (var_215 != 42)
  __builtin_abort();
}

[Bug tree-optimization/106687] New: [13 Regression] Wrong code with -O2

2022-08-19 Thread vsevolod.livinskiy at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106687

Bug ID: 106687
   Summary: [13 Regression] Wrong code with -O2
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskiy at gmail dot com
  Target Milestone: ---

Link to the Compiler Explorer: https://godbolt.org/z/a8PTr5sqM

The error disappears if I use another definition of max (b > p2 ? b : p2).

Reproducer:
#include 

bool var_0 = (bool)0;
unsigned int var_7 = 42;
char var_215;

const unsigned &a(const unsigned &b, unsigned &p2) { return b < p2 ? p2 : b; }
void test() { var_215 = a(var_0, var_7) ^ (var_7 - var_0) ?: 42; }

int main() {
  test();
  printf("%d\n", var_215);
  if (var_215 != 42)
__builtin_abort();
}

Error:
>$ g++ -O1 small.cpp && ./a.out 
42
>$ g++ -O2 small.cpp && ./a.out 
0
Aborted (core dumped)

gcc version 13.0.0 20220819 (81e20a6eb9e6b7eb62a09ac58811387f0343bd14)

[Bug c/106683] internal compiler error for unusua inline assembly constraint

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106683

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
I suspect it was fixed for GCC 9.5.0 by the patch which fixed PR 104786.

Anyways it was fixed in GCC 9.5.0.

[Bug c/106683] internal compiler error for unusua inline assembly constraint

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106683

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.5

[Bug c++/106685] ICE with concepts and ptr to member functions in requires

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106685

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
  Known to fail||12.1.0, 6.1.0, 8.1.0
   Last reconfirmed||2022-08-19

--- Comment #4 from Andrew Pinski  ---
Confirmed. the code has always ICE since concepts has been added.

[Bug c++/106685] ICE with concepts and ptr to member functions in requires

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106685

--- Comment #3 from Andrew Pinski  ---
Created attachment 53477
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53477&action=edit
No more headers

[Bug c++/106685] [12/13 Regerssion] ICE during GIMPLE pass: vrp

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106685

--- Comment #2 from Andrew Pinski  ---
Created attachment 53476
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53476&action=edit
More reduced

[Bug c++/106685] [12/13 Regerssion] ICE during GIMPLE pass: vrp

2022-08-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106685

--- Comment #1 from Andrew Pinski  ---
Created attachment 53475
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53475&action=edit
testcase

Please next time attach the testcase instead of linking to godbolt

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

2022-08-19 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106646

--- Comment #2 from Marek Polacek  ---
Thanks, I can look into that for C++.

I notice that with your patch we say "#warning before C2X is a GCC extension"
even when compiling with cc1plus; I suppose the C2X message should be guarded
by CPP_OPTION (pfile, cplusplus).

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

2022-08-19 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106686

Bug ID: 106686
   Summary: [lto][offloading] lto-wrapper leaves "target.o"
temporay files behind when error diagnostic occurred
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I found a couple of /tmp/ccGARvpn.target.o files - which are surely unintended
leftovers.

The filename is returned by lto-wrapper.cc's compile_offload_image and then
collected in
  offload_names[next_name_entry] = compile_offload_image (...)
and processed as
  if (offload_names)
{
  find_crtoffloadtable (save_temps, dumppfx);
  for (i = 0; offload_names[i]; i++)
printf ("%s\n", offload_names[i]);

That seems to work well if not error occurred - but if there was an error, it
seems to be the only file suffix which is not cleaned up.


Reproducer:
- You need a GCC configured for offload (nvptx, gcn or intelmic)
- You need to get it to fail.

On mainline, one way is to compile the following with offloading: 'gcc -fopenmp
*.c'
which outputs:
  lto1: error: OpenMP 'requires' directive with 'unified_shared_memory'
specified only in some compilation units
  lto1: fatal error: errors during merging of translation units

Input:
--- 1.c --
#pragma omp requires unified_shared_memory
int i;
void foo() {
  #pragma omp target enter data map(to:i)
}

--- 2.c --
int j;
void foo() {
  #pragma omp target enter data map(to:j)
}

[Bug c++/106685] New: [12/13 Regerssion] ICE

2022-08-19 Thread egor.pugin at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106685

Bug ID: 106685
   Summary: [12/13 Regerssion] ICE
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egor.pugin at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/987rxevMh

[Bug tree-optimization/105646] g++ does not raise "xxx may be used uninitialized" warning on dead code when optimizing

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105646

Richard Biener  changed:

   What|Removed |Added

Summary|g++ does not raise "xxx is  |g++ does not raise "xxx may
   |used uninitialized" warning |be used uninitialized"
   |under some conditions   |warning on dead code when
   ||optimizing
   Last reconfirmed||2022-08-19
  Component|c++ |tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from Richard Biener  ---
The issue is that for f3() we'd emit a may-uninitialized warning because f1()
could have thrown and thus v3{v3} is only executed conditionally.  For f2()
v2{v2} is always executed (when f2 is entered).  The late diagnostic pass
that would emit may-uninitialized warnings doesn't get to see the v3{v3}
initialization because it was removed as dead code.

When not optimizing we choose to diagnose may-uninit before eliminating v3{v3}.

Confirmed.  Not sure if we want to fix this.  We eventually might use a
different predicate than post-domination for whether a stmt is considered
always executed (ignoring EH and abnormal control flow).  Greedily
following "fallthru" edges might work for this, also implementing the
unreachable edge honoring the ??? comment says.

I have a patch.

[Bug tree-optimization/105937] [12/13 Regression] maybe-uninitialized with std::optional

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105937

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
The predicate analysis has difficulties in handling this case, its like

void foo (int val)
{
  int uninit;
  for (;;)
{
  if (..)
{
  .. = val;  (*)
  val = uninit;
}
  # val = PHI <..>
}
}

and we diagnose (*), figuring the loop PHI of 'val' eventually leads to
the PHI that post-dominates the use we want to diagnose.  One issue with
this is that the predicates provided are from a different iteration than
those used so we won't have a chance to compare things meanigfully here.

I think the best thing is to avoid diagnosing possibly uninitialized
uses in the next iteration of a loop because we have no chance to 
prove the path is unreachable and thus we'll always warn.

At least I think so.

I do have a patch.

[Bug tree-optimization/106511] [13 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106511

--- Comment #2 from Richard Biener  ---
VRP could use max_stmt_executions here (note it doesn't properly handle loop
nests so the name is somewhat misleading)

[Bug tree-optimization/106511] [13 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106511

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
The missed optimization is

 symTotal = 0;
 for (i = 0; i < 16; i++) {
  if (t&(1 << (15-i))) {
   k = get_bits(bd, 16);
   for (j = 0; j < 16; j++)
if (k&(1 << (15-j)))
 symToByte[symTotal++] = (16*i)+j;
  }
 }
...
 symCount = symTotal+2;
 for (j = 0; j < groupCount; j++) {
  unsigned char length[258], temp[20 +1];
  int minLen, maxLen, pp;
# 235 "bunzip2.c"
  t = get_bits(bd, 5)-1;
  for (i = 0; i < symCount; i++) {
...
   length[i] = t+1;
  }

  minLen = maxLen = length[0];

to see that symCount cannot be zero and thus the loop header copy check for the
loop on the last line can be elided.  It looks quite obvious to me that
should be able to compute a range for symTotal and thus symCount.  SCEV
is likely of not much help here but we should be able to compute
the maximum number of times symTotal++ is executed by looking at the number
of iterations of the loop nest.

Note that with -O we do not run VRP and with -O2 we don't warn.  But
the testcase

void link_error ();
int bar ();
void foo ()
{
  int symTotal = 0;
  for (int i = 0; i < 16; ++i)
{
  if (bar())
symTotal++;
}
  if (symTotal < 0 || symTotal > 16)
link_error ();
}

shows that even with -O2 VRP only figures that symTotal is positive, it doesn't
get the upper bound:

   [local count: 63136016]:
  # RANGE [irange] int [0, +INF] NONZERO 0x7fff
  # symTotal_19 = PHI 
  if (symTotal_19 > 16)

given that loop header copying short-cuts the initialization of length[]
it's clear that we diagnose the unconditional use after the loop.

[Bug c/105660] [12/13 Regression] ICE in warn_parm_array_mismatch when merging two function decls and VLA arguments since r12-1218-gc6503fa93b5565c9

2022-08-19 Thread romain at dolbeau dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105660

--- Comment #6 from Romain Dolbeau  ---
Please consider this for 12.2, it's a trivial bug with a trivial fix that's
been available for two months.

[Bug fortran/106684] New: inconsistent array initialization

2022-08-19 Thread jorn--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684

Bug ID: 106684
   Summary: inconsistent array initialization
   Product: gcc
   Version: 10.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: j...@bolding-bruggeman.com
  Target Milestone: ---

The minor update of 10.3 to 10.4 causes gfortran to no longer accept
initialization of multidimensional array components with 1d data. However,
standalone multidimensional arrays can still be initialized with 1d data. That
seems inconsistent. The same behavior is found in recent releases of 11 and 12
(tested: 11.3.0, 12.1.0)

Example:

program p
   implicit none

   real :: a(2,2)
   data a /0., 1., 2., 3./

   type t
  integer :: b
  real :: a(2,2)
   end type
   type (t) c
   data c /t(1, (/0., 1., 2., 3./))/
end program

This results in the following error with gfortran 10.4:

test_array_init.F90:12:16:

   12 |data c /t(1, (/0., 1., 2., 3./))/
  |1
Error: The rank of the element in the structure constructor at (1) does not
match that of the component (1/2)

However, the above code is accepted by gfortran 9.x and 10.3, as well as ifort.

[Bug rtl-optimization/106590] [12/13 Regression] x86-64 miscompilation starting with r12-8233-g1ceddd7497e15d w/ mtune=skylake

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106590

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #10 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug target/106609] [12/13 Regression] sh3eb-elf cross compiler is being miscompiled since r12-1525-g3155d51bfd1de8b6c4645

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #11 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug libstdc++/106589] [12/13 Regression] visit rejects lambdas that do not return void

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106589

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #4 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug libstdc++/106608] [12/13 Regression] std::optional requires unavailable dtor

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106608

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #5 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug tree-optimization/106570] [12/13 Regression] DCE sometimes fails with depending if statements since r12-2305-g398572c1544d8b75

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106570

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #3 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug bootstrap/106482] [12/13 Regression] bootstrap of 12.1.0 using 4.8.2 fails with C++ errors

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106482

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #3 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug c++/106395] [12/13 regression] [mingw] "redeclared without dllimport attribute: previous dllimport ignored" on C++ friend since r12-299-ga0fdff3cf33f72

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106395

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #3 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

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

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #16 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

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

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #33 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

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

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106434

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #5 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug target/106342] [12/13 Regression] internal compiler error: in extract_insn, at recog.cc:2791 since r12-4240-g2b8453c401b699

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106342

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #9 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

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

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106022

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #21 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug tree-optimization/106297] [12/13 Regression] stringop-overflow misbehaviour on atomic since r12-4725-g88b504b7a8c5affb

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106297

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #7 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug c/105972] [12/13 Regression] ICE in lower_stmt, at gimple-low.cc:312 since r12-4608-gb4702276615ff8d4

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105972

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #3 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug rtl-optimization/105952] [12/13 Regression] ICE in sel_redirect_edge_and_branch, at sel-sched-ir.cc:5680

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105952

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #2 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug analyzer/106206] [12/13 Regression] ICE: canonical types differ for identical types 'int(...)' and 'int(...)' since r12-1931-ge61ffa201403e3

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106206

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #2 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug tree-optimization/105705] [12/13 Regression] std::equal triggers incorrect -Wnonnull warning

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105705

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #8 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug tree-optimization/105918] [12/13 Regression] Spurious Warray-bounds in std::to_chars since r12-2132-ga110855667782dac

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105918

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #3 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug tree-optimization/106199] [12/13 Regression] incorrect warning: memcpy writing 1 or more bytes into a region of size 0 overflows the destination with std::vector::insert

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106199

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #6 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug tree-optimization/105867] [12/13 Regression] incorrect dangling-pointer warning

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105867

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #3 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug tree-optimization/105679] [12 Regression] extra -Warray-bounds warning added with -fsanitize=shift due to jump threading

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #8 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug tree-optimization/106155] [12/13 Regression] spurious "may be used uninitialized" warning

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106155

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #5 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug c++/105841] [12/13 Regression] Change in behavior of CTAD for alias templates

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105841

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #6 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug target/105617] [12/13 Regression] Slp is maybe too aggressive in some/many cases

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #16 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

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

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #12 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug libstdc++/105580] [12/13 Regression] warning "potential null pointer dereference" raised when using istreambuf_iterator and any "-O" flag

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105580

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #3 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

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

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #16 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug rtl-optimization/106041] [12/13 Regression] infinite loop in fast_dce at -O1 with aarch64

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106041

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #8 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug tree-optimization/105545] [12/13 Regression] Warning for string assignment with _GLIBCXX_ASSERTIONS since r12-3347-g8af8abfbbace49e6

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105545

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #8 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug target/105010] [12/13 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #16 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug tree-optimization/106514] [12/13 Regression] ranger slowness in path query

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106514

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #9 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug tree-optimization/105937] [12/13 Regression] maybe-uninitialized with std::optional

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105937

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #3 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug target/105069] [12/13 regression] sh-elf internal compiler errors and test failures with -Os

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105069

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #11 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug target/104912] [12/13 Regression] 416.gamess regression after r12-7612-g69619acd8d9b58

2022-08-19 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104912

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #12 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

  1   2   3   >