[Bug fortran/110360] ABI issue with character,value dummy argument

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

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #4 from Mikael Morin  ---
(In reply to anlauf from comment #0)
> but the second line contains junk, as the tree-dump shows:
> 
>   static void val (character(kind=1)[1:1], integer(kind=8));
>   static integer(kind=4) a = 65;
> 
>   val ("A", 1);
>   {
> character(kind=1) char.1;
> 
> char.1 = (character(kind=1)) a;
> val (&char.1, 1);
>   }
> 
> Clearly, the second case is inconsistent with the ABI, see the prototype, and
> 
Yes, but it's not worse than the first one: "A" is a pointer, not a value.
I would say that it is the middle-end that is inconsistent here.


(In reply to anlauf from comment #3)
> Created attachment 55381 [details]
> Revised patch
> 
> This patch actually regtests OK.  The previous one failed on one of the
> c_char_tests.

Looks good.
I would suggest to create an overload that avoids duplicating the 
build_int_cst (integer_type_node, 1) in several places.
Shouldn't it be build_int_cst (gfc_charlen_type_node, 1) by the way?

[Bug fortran/110360] ABI issue with character,value dummy argument

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

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

--- Comment #5 from Mikael Morin  ---
This is out of the scope of this PR, but in the [character, value, bind(c)]
case, only constant values and variables are supported?

[Bug tree-optimization/110335] int converted to double should be considered non-nan and non-nan*non-nan is still non-nan

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

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

--- Comment #1 from Andrew Pinski  ---
Another testcase:
```
  void
  h3(int to)
  {
double dto = to;
double damt = dto +2;
if (damt != damt)
 __builtin_trap();
  }
```


Note we do optimize:
```
  void
  done(int to)
  {
double dto = to;
double damt = -dto;
if (damt != damt)
 __builtin_trap();
  }
```
But via match and simplify.

Note there is tree_expr_maybe_nan_p and tree_expr_finite_p in fold-const.cc
Which can be used as a model for some frange related things too.

[Bug tree-optimization/110332] [14 regression] ICE in dominated_by_p when building LLVM with -O3

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

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

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

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

commit r14-2031-g2ac41866270e9fbab504bbda7a942a97abaa203a
Author: Richard Biener 
Date:   Thu Jun 22 09:04:01 2023 +0200

tree-optimization/110332 - fix ICE with phiprop

The following fixes an ICE that occurs when we visit an edge
inserted load from the code validating correctness for inserting
an aggregate copy there.  We can simply skip those loads here.

PR tree-optimization/110332
* tree-ssa-phiprop.cc (propagate_with_phi): Always
check aliasing with edge inserted loads.

* g++.dg/torture/pr110332.C: New testcase.
* gcc.dg/torture/pr110332-1.c: Likewise.
* gcc.dg/torture/pr110332-2.c: Likewise.

[Bug tree-optimization/110332] [14 regression] ICE in dominated_by_p when building LLVM with -O3

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c/108964] Attribute target should be implemented for C backend (not only c++)

[rouca at debian dot org via Gcc-bugs]

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

rouca  changed:

   What|Removed |Added

Version|12.2.0  |14.0

--- Comment #1 from rouca  ---
Hi,

On the debian side we will really like to have it.

[Bug tree-optimization/110310] vector epilogue handling is inefficient

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

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

--- Comment #2 from avieira at gcc dot gnu.org ---
I can't remember the exact reason either, though I do vaguely remember niter
updating being something that we felt 'needed more future work' at the time.

Just a side question, AVX512 has predication right? So how come you are
expecting an epilogue?

I'm also curious about the condition on that snippet of code, 'known_eq (vf,
lowest_vf)' seems odd.. lowest_vf is by definition constant, so known_eq only
succeeds if vf is constant and the same as lowest_vf, but lowest_vf is the
constant lower bound of vf, i.e. that seems like a very convoluted way of doing
vf.is_constant (&lowest_vf)? Maybe this helper function wasn't around back
then. Either way, it feels like we shouldn't be doing this if loop_vinfo is
predicated? But I also agree that we probably want to be doing all of this
during analysis, seems odd to be ruling out loop_vinfo's during transformation.

[Bug libgomp/94648] [OpenMP] DEVICE_HOST_FALLBACK when no actual device + omp_target_alloc + omp_get_default_device

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #1 from Tobias Burnus  ---
Seemingly it was fixed at some point.

The testcase fails with GCC 10.3.1 20210507 but works with GCC 11.4.1 20230621
and GCC 12/13/mainline.

Close as FIXED:

[Bug tree-optimization/110332] [14 regression] ICE in dominated_by_p when building LLVM with -O3

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

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

--- Comment #13 from Sergei Trofimovich  ---
The fix fixes llvm-12 build for me. Thank you!

[Bug target/110100] __builtin_aarch64_st64b stores to the wrong address

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

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

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

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

commit r12-9718-gc0ab0d4af51382d9d8d4e6b026865842d8e06d7e
Author: Alex Coplan 
Date:   Tue Jun 6 11:04:45 2023 +0100

aarch64: Fix whitespace in ls64 builtin implementation [PR110100]

The ls64 builtin code was using incorrect GNU style with eight spaces where
there should be a tab. Fixed thusly.

gcc/ChangeLog:

PR target/110100
* config/aarch64/aarch64-builtins.cc
(aarch64_init_ls64_builtins_types):
Replace eight consecutive spaces with tabs.
(aarch64_init_ls64_builtins): Likewise.
(aarch64_expand_builtin_ls64): Likewise.
* config/aarch64/aarch64.md (ld64b): Likewise.
(st64b): Likewise.
(st64bv): Likewise
(st64bv0): Likewise.

(cherry picked from commit 713613541254039a34e1dd8fd4a613a299af1fd6)

[Bug target/110100] __builtin_aarch64_st64b stores to the wrong address

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Alex Coplan
:

https://gcc.gnu.org/g:0112ed013847ca9dbef4ba21f1c3f94c5bbe310b

commit r12-9719-g0112ed013847ca9dbef4ba21f1c3f94c5bbe310b
Author: Alex Coplan 
Date:   Tue Jun 6 11:52:19 2023 +0100

aarch64: Fix wrong code with st64b builtin [PR110100]

The st64b pattern incorrectly had an output constraint on the register
operand containing the destination address for the store, leading to
wrong code. This patch fixes that.

gcc/ChangeLog:

PR target/110100
* config/aarch64/aarch64-builtins.cc (aarch64_expand_builtin_ls64):
Use input operand for the destination address.
* config/aarch64/aarch64.md (st64b): Fix constraint on address
operand.

gcc/testsuite/ChangeLog:

PR target/110100
* gcc.target/aarch64/acle/pr110100.c: New test.

(cherry picked from commit 737a0b749a7bc3e7cb904ea2d4b18dc130514b85)

[Bug target/110132] aarch64: Bogus -Wbuiltin-declaration-mismatch with ls64 builtins

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Alex Coplan
:

https://gcc.gnu.org/g:4481d70c9edcd89a8d9f6c0d705b05230aa080e3

commit r12-9720-g4481d70c9edcd89a8d9f6c0d705b05230aa080e3
Author: Alex Coplan 
Date:   Tue Jun 6 15:19:03 2023 +0100

aarch64: Allow compiler to define ls64 builtins [PR110132]

This patch refactors the ls64 builtins to allow the compiler to define them
directly instead of having wrapper functions in arm_acle.h. This should be
not
only easier to maintain, but it makes two important correctness fixes:
 - It fixes PR110132, where the builtins ended up getting declared with
   invisible bindings in the C FE, so the FE ended up synthesizing
   incompatible implicit definitions for these builtins.
 - It allows the builtins to be used with LTO, which didn't work
previously.

We also take the opportunity to add test coverage from C++ for these
builtins.

gcc/ChangeLog:

PR target/110132
* config/aarch64/aarch64-builtins.cc
(aarch64_general_simulate_builtin):
New. Use it ...
(aarch64_init_ls64_builtins): ... here. Switch to declaring public
ACLE
names for builtins.
(aarch64_general_init_builtins): Ensure we invoke the arm_acle.h
setup if in_lto_p, just like we do for SVE.
* config/aarch64/arm_acle.h: (__arm_ld64b): Delete.
(__arm_st64b): Delete.
(__arm_st64bv): Delete.
(__arm_st64bv0): Delete.

gcc/testsuite/ChangeLog:

PR target/110132
* lib/target-supports.exp
(check_effective_target_aarch64_asm_FUNC_ok):
Extend to ls64.
* g++.target/aarch64/acle/acle.exp: New.
* g++.target/aarch64/acle/ls64.C: New test.
* g++.target/aarch64/acle/ls64_lto.C: New test.
* gcc.target/aarch64/acle/ls64_lto.c: New test.
* gcc.target/aarch64/acle/pr110132.c: New test.

(cherry picked from commit 9963029a24f2d2510b82e7106fae3f364da33c5d)

[Bug target/110100] __builtin_aarch64_st64b stores to the wrong address

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

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

Alex Coplan  changed:

   What|Removed |Added

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

--- Comment #10 from Alex Coplan  ---
Should be fixed on all affected branches, thanks for the report.

[Bug target/110132] aarch64: Bogus -Wbuiltin-declaration-mismatch with ls64 builtins

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

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

Alex Coplan  changed:

   What|Removed |Added

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

--- Comment #7 from Alex Coplan  ---
Fixed on all affected branches.

[Bug target/54089] [SH] Refactor shift patterns

[klepikov.alex+bugs at gmail dot com via Gcc-bugs]

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

--- Comment #89 from Alexander Klepikov  
---
Here's what I did

sh.md:

(define_expand "ashrsi3"
  [(parallel [(set (match_operand:SI 0 "arith_reg_dest" "")
   (ashiftrt:SI (match_operand:SI 1 "arith_reg_operand" "")
(match_operand:SI 2 "nonmemory_operand" "")))
  (clobber (reg:SI T_REG))])]
  ""
{
  if (expand_ashiftrt (operands))
DONE;
  if (!CONST_INT_P (operands[2]))
FAIL;
  int value = INTVAL (operands[2]) & 31;
  emit_insn (gen_ashrsi3_n_call (operands[0], operands[1], GEN_INT(value)));
  DONE;
})

(define_insn_and_split "ashrsi3_n_call"
  [(set (match_operand:SI 0 "arith_reg_dest" "=r")
(ashiftrt:SI (match_operand:SI 1 "arith_reg_operand" "0")
(match_operand:SI 2 "const_int_operand")))
(clobber (reg:SI T_REG))]
  "TARGET_SH1"
  "#"
  "&& can_create_pseudo_p ()"
  [(const_int 0)]
{
char func[18];
int value;
rtx wrk;

cfun->machine->ashrsi3_libcall_expanded++;

if (expand_ashiftrt (operands))
  DONE;
if (!CONST_INT_P (operands[2]))
  FAIL;
value = INTVAL (operands[2]) & 31;

if (dump_file)
  fprintf(dump_file, "ashrsi3_n_call: Expanding ashrsi3 libcall\n");

wrk = gen_reg_rtx (Pmode);
/* Load the value into an arg reg and call a helper.  */
emit_move_insn (gen_rtx_REG (SImode, 4), operands[1]);
sprintf (func, "__ashiftrt_r4_%d", value);
rtx lab = function_symbol (wrk, func, SFUNC_STATIC).lab;
emit_insn (gen_ashrsi3_n (GEN_INT (value), wrk, lab));
emit_move_insn (operands[0], gen_rtx_REG (SImode, 4));
DONE;
})


sh.cc:

bool
expand_ashiftrt (rtx *operands)
{
  rtx wrk;
  int value;

  if (TARGET_DYNSHIFT)
{
  if (!CONST_INT_P (operands[2]))
{
  rtx count = copy_to_mode_reg (SImode, operands[2]);
  emit_insn (gen_negsi2 (count, count));
  emit_insn (gen_ashrsi3_d (operands[0], operands[1], count));
  return true;
}
  else if (ashiftrt_insns[INTVAL (operands[2]) & 31]
   > 1 + SH_DYNAMIC_SHIFT_COST)
{
  rtx count
= force_reg (SImode, GEN_INT (- (INTVAL (operands[2]) & 31)));
  emit_insn (gen_ashrsi3_d (operands[0], operands[1], count));
  return true;
}
}
  if (!CONST_INT_P (operands[2]))
return false;

  value = INTVAL (operands[2]) & 31;

  if (value == 31)
{
  /* If we are called from abs expansion, arrange things so that we
 we can use a single MT instruction that doesn't clobber the source,
 if LICM can hoist out the load of the constant zero.  */
  if (currently_expanding_to_rtl)
{
  emit_insn (gen_cmpgtsi_t (force_reg (SImode, CONST0_RTX (SImode)),
operands[1]));
  emit_insn (gen_mov_neg_si_t (operands[0], get_t_reg_rtx ()));
  return true;
}
  emit_insn (gen_ashrsi2_31 (operands[0], operands[1]));
  return true;
}
  else if (value >= 16 && value <= 19)
{
  wrk = gen_reg_rtx (SImode);
  emit_insn (gen_ashrsi2_16 (wrk, operands[1]));
  value -= 16;
  while (value--)
gen_ashift (ASHIFTRT, 1, wrk);
  emit_move_insn (operands[0], wrk);
  return true;
}
  /* Expand a short sequence inline, longer call a magic routine.  */
  else if (value <= 5)
{
  wrk = gen_reg_rtx (SImode);
  emit_move_insn (wrk, operands[1]);
  while (value--)
gen_ashift (ASHIFTRT, 1, wrk);
  emit_move_insn (operands[0], wrk);
  return true;
}
  return false;
}


Now GCC falls into infinite loop when compiling this:

int f_short_rshift_signed(char v){
return v >> 5;
}

It looks like it splits and then combines again.

[Bug ipa/110334] [13/14 Regresssion] unused functions not eliminated before LTO streaming

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

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

--- Comment #3 from Richard Biener  ---
So it's actually that we require the instantiations but we are not able to
fully optimize avx::[rect_]memset* before LTO streaming.  In fact we're not too
far from that:

void skvx::Vec<2, unsigned int>::Vec (struct Vec * const this, unsigned int
D.78460)
{ 
  unsigned int _3(D);

   [local count: 1073741824]:
  MEM[(struct VecStorage *)this_2(D)] ={v} {CLOBBER};
  MEM[(struct Vec *)this_2(D)] ={v} {CLOBBER};
  MEM[(struct Vec *)this_2(D)].val = _3(D);
  MEM[(struct Vec *)this_2(D) + 4B] ={v} {CLOBBER};
  MEM[(struct Vec *)this_2(D) + 4B].val = _3(D);
  return;
}

void skvx::Vec<4, unsigned int>::Vec (struct Vec * const this, unsigned int
D.78672)
{ 
  unsigned int _3(D);
  struct Vec * _4;
  struct Vec * _5;

   [local count: 1073741824]:
  MEM[(struct VecStorage *)this_2(D)] ={v} {CLOBBER};
  _4 = &MEM[(struct VecStorage *)this_2(D)].lo;
  skvx::Vec<2, unsigned int>::Vec (_4, _3(D));
  _5 = &MEM[(struct VecStorage *)this_2(D)].hi;
  skvx::Vec<2, unsigned int>::Vec (_5, _3(D));
  return;

}

void avx::memsetT (unsigned int * buffer, unsigned int value, int
count)
{
  struct Vec wideValue;
  long unsigned int _17;

   [local count: 118111600]:
  MEM[(struct VecStorage *)&wideValue] ={v} {CLOBBER};
  skvx::Vec<4, unsigned int>::Vec (&MEM[(struct VecStorage *)&wideValue].lo,
value_8(D));
  skvx::Vec<4, unsigned int>::Vec (&MEM[(struct VecStorage *)&wideValue].hi,
value_8(D));


we go inlining skvx::Vec<8, unsigned int>::Vec here which eventually
expands

__attribute__((always_inline))
void skvx::VecStorage<8, unsigned int>::VecStorage (struct VecStorage * const
this, unsigned int s)
{

but we do not inline into that function and as we do not iterate early
inlining we stop here.

Removing all always_inline from the TU fixes the issue.

[Bug tree-optimization/110361] New: [13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r13-2020-g16b013c9d9b

[theodort at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 110361
   Summary: [13/14 Regression] Missed Dead Code Elimination when
using __builtin_unreachable since
r13-2020-g16b013c9d9b
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theodort at inf dot ethz.ch
  Target Milestone: ---

https://godbolt.org/z/qab3679sq

Given the following code:

void foo(void);
static int a, b, d, p, k;
static int *c, *e, *g;
static short f;
static unsigned h;
static int **i = &c, **o = &g;
void __assert_fail() __attribute__((__noreturn__));
static void j(char, unsigned r) {
h = r == 0 ?: 2 % r;
int l = h;
if (!(((l) >= 1) && ((l) <= 1))) {
__builtin_unreachable();
}
int m;
*i = &m;
}
static int *n();
static short q(short t) {
*o = &p;
return t;
}
static unsigned s() {
int *j = n();
if (e == 0 || e == &a || e == &d)
;
else
__assert_fail();
return *j;
}
static int *n() {
if (b) {
if (c) __assert_fail();
e = 0;
}
return &k;
}
int main() {
j(q(s()), f);
if (e == 0 || e == &a || e == &d)
;
else
foo();
f = 0;
}

gcc-trunk -O2 does not eliminate the call to foo:

main:
subq$24, %rsp
movqe(%rip), %rax
movswl  f(%rip), %edx
testq   %rax, %rax
je  .L2
cmpq$a, %rax
je  .L4
cmpq$d, %rax
jne .L17
.L4:
movq$p, g(%rip)
testl   %edx, %edx
je  .L18
leaq12(%rsp), %rdx
movq%rdx, c(%rip)
cmpq$a, %rax
je  .L5
cmpq$d, %rax
je  .L5
callfoo
.L5:
xorl%eax, %eax
movw%ax, f(%rip)
xorl%eax, %eax
addq$24, %rsp
ret
.L18:
leaq12(%rsp), %rax
movq%rax, c(%rip)
jmp .L5
.L2:
movq$p, g(%rip)
leaq12(%rsp), %rax
movq%rax, c(%rip)
jmp .L5
.L17:
xorl%eax, %eax
call__assert_fail

gcc-12.3.0 -O2 eliminates the call to foo:

main:
subq$24, %rsp
movqe(%rip), %rax
testq   %rax, %rax
je  .L2
cmpq$a, %rax
je  .L2
cmpq$d, %rax
jne .L14
.L2:
movq$p, g(%rip)
leaq12(%rsp), %rax
movq%rax, c(%rip)
xorl%eax, %eax
movw%ax, f(%rip)
xorl%eax, %eax
addq$24, %rsp
ret
.L14:
xorl%eax, %eax
call__assert_fail

Bisects to r13-2020-g16b013c9d9b

[Bug target/54089] [SH] Refactor shift patterns

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

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

--- Comment #90 from Oleg Endo  ---
(In reply to Alexander Klepikov from comment #89)
> Here's what I did
> ...

Can you attach it here as a patch please?

[Bug ipa/110334] [13/14 Regresssion] unused functions not eliminated before LTO streaming

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

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

--- Comment #4 from Richard Biener  ---
So we run into

  /* Never inline regular functions into always-inline functions
 during incremental inlining.  This sucks as functions calling
 always inline functions will get less optimized, but at the
 same time inlining of functions calling always inline
 function into an always inline function might introduce
 cycles of edges to be always inlined in the callgraph.

 We might want to be smarter and just avoid this type of inlining.  */
  || (DECL_DISREGARD_INLINE_LIMITS (node->decl)
  && lookup_attribute ("always_inline",
   DECL_ATTRIBUTES (node->decl

which I think is sensible but the issue is that for some reason the
skvx::Vec<4, unsigned int>::Vec (_1, s_6(D)) calls are not always_inline.

(gdb) p node->callees
$3 =  -> )>
(gdb) p node->callees->next_callee 
$4 =  -> )>

__attribute__((always_inline))
void skvx::VecStorage<8, unsigned int>::VecStorage (struct VecStorage * const
this, unsigned int s)
{
  struct Vec * _1;
  struct Vec * _2;

   :
  *this_4(D) ={v} {CLOBBER};
  _1 = &this_4(D)->lo;
  skvx::Vec<4, unsigned int>::Vec (_1, s_6(D));
  _2 = &this_4(D)->hi;
  skvx::Vec<4, unsigned int>::Vec (_2, s_6(D));
  return;

the location info points to

__attribute__((always_inline)) Vec(typename ConvertNative::type
native) : Vec(bit_pun(native)) {}

I'm not sure what fails to work here.

[Bug fortran/110311] [14 Regression] gfortran 14.0 regression

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #9 from Jürgen Reuter  ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Jürgen Reuter from comment #7)
> > The problem seems really connected to optimization, if I compile our code
> > with -g -O0 or -g -O1, everything works ok. Next, I will try to check why it
> > is actually failing (my guess, unconfirmed yet, is that some data structures
> > are optimized away such that the program runs then on inconsistent data).
> > Then I will check that specific commit. We are sure that it was introduced
> > within this time frame, because we have a weekly CI that clones gcc, and
> > then builds and runs our code and testsuite. That was working on the morning
> > of June 12, but failed on the morning of June 19.
> 
> Do you know if -fno-tree-vectorizer causes the issue to go away?

Hi Andrew,
you were right. Compiling and running with -fno-tree-vectorize does not show
any issues. All our checks work without problems.
Cheers,
   Juergen

[Bug fortran/110326] [14 Regression]

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #1 from Jürgen Reuter  ---
This should be closed as a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

[Bug fortran/110326] [14 Regression]

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #2 from Jürgen Reuter  ---
Closed as a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

[Bug fortran/110326] [14 Regression]

[juergen.reuter at desy dot de via Gcc-bugs]

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

Jürgen Reuter  changed:

   What|Removed |Added

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

--- Comment #3 from Jürgen Reuter  ---
Duplicate of 110311.

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

[Bug fortran/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #10 from Jürgen Reuter  ---
*** Bug 110326 has been marked as a duplicate of this bug. ***

[Bug ipa/110334] [13/14 Regresssion] unused functions not eliminated before LTO streaming

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
So the CTOR we call is built (well, cloned from that) via

implicitly_declare_fn (kind=sfk_inheriting_constructor, type=, const_p=false, pattern_fn=, inherited_parms=) at
/space/rguenther/src/gcc11queue/gcc/cp/method.cc:3245

and 'pattern_fn' has the always_inline attribute here but we don't seem
to copy that anywhere?

-fno-new-inheriting-ctors also "fixes" the optimization issue for me.

So do we fail to copy DECL_ATTRIBUTES for these kind of implicitely
declared functions (which are in fact explicitely declared?!)?

[Bug tree-optimization/110362] New: Range information on lower bytes of __uint128_t

[antoshkka at gmail dot com via Gcc-bugs]

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

Bug ID: 110362
   Summary: Range information on lower bytes of __uint128_t
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the following example:

int test (__uint128_t a, __uint128_t b) {
  __uint128_t __a = b | (a << 32);
  return __a & 0x;
}

At the moment GCC-14 with -O2 generates the following assembly:

test(unsigned __int128, unsigned __int128):
mov rsi, rdi
mov rax, rdx
sal rsi, 32
or  rax, rsi
ret


Which could be simplified to just:

test(unsigned __int128, unsigned __int128):
mov rax, rdx
ret

Godbolt playground: https://godbolt.org/z/K9x5vnhxq

[Bug tree-optimization/110310] vector epilogue handling is inefficient

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #3 from rguenther at suse dot de  ---
On Thu, 22 Jun 2023, avieira at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110310
> 
> --- Comment #2 from avieira at gcc dot gnu.org ---
> I can't remember the exact reason either, though I do vaguely remember niter
> updating being something that we felt 'needed more future work' at the time.
> 
> Just a side question, AVX512 has predication right? So how come you are
> expecting an epilogue?

I'm asking to only predicate the epilogues.

> I'm also curious about the condition on that snippet of code, 'known_eq (vf,
> lowest_vf)' seems odd.. lowest_vf is by definition constant, so known_eq only
> succeeds if vf is constant and the same as lowest_vf, but lowest_vf is the
> constant lower bound of vf, i.e. that seems like a very convoluted way of 
> doing
> vf.is_constant (&lowest_vf)? Maybe this helper function wasn't around back
> then. Either way, it feels like we shouldn't be doing this if loop_vinfo is
> predicated? But I also agree that we probably want to be doing all of this
> during analysis, seems odd to be ruling out loop_vinfo's during 
> transformation.

OK, so I take away from this that you don't think this is done the way
it is on purpose.

[Bug target/54089] [SH] Refactor shift patterns

[klepikov.alex+bugs at gmail dot com via Gcc-bugs]

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

Alexander Klepikov  changed:

   What|Removed |Added

  Attachment #55367|0   |1
is obsolete||

--- Comment #91 from Alexander Klepikov  
---
Created attachment 55382
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55382&action=edit
Draft libcall/sh_loop patch, causes infinite loop

Please patch with '-p2'.

[Bug tree-optimization/96208] non-grouped load can be SLP vectorized for 2-element vectors case

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

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

--- Comment #3 from Richard Biener  ---
Smaller testcase, avoiding reductions and negative step:

void
test(double * __restrict a, double *b, double *k, int n)
{
  for (int i = 0; i < n; ++i)
{
  a[2*i] = b[2*i] * k[ONE*i];
  a[2*i + 1] = b[2*i + 1] * k[ONE*i];
}
}

this is vectorized with interleaving with -DONE=1 as SLP discovery fails:

t.c:4:21: missed:   Build SLP failed: not grouped load _9 = *_8;

.L4:
movupd  (%r8,%rax,2), %xmm1
movupd  (%rdx,%rax), %xmm2
movupd  16(%r8,%rax,2), %xmm0
movlpd  8(%r8,%rax,2), %xmm0
movhpd  16(%r8,%rax,2), %xmm1
mulpd   %xmm2, %xmm1
mulpd   %xmm2, %xmm0
movapd  %xmm1, %xmm2
unpcklpd%xmm0, %xmm2
unpckhpd%xmm0, %xmm1
movups  %xmm2, (%rdi,%rax,2)
movups  %xmm1, 16(%rdi,%rax,2)
addq$16, %rax
cmpq%rax, %rsi
jne .L4

but when we make the access to 'k' non-unit-stride with -DONE=2
SLP works fine

t.c:4:21: note:   Vectorizing SLP tree:
t.c:4:21: note:   node 0x48580d0 (max_nunits=2, refcnt=1) vector(2) double
t.c:4:21: note:   op template: *_8 = _9;
t.c:4:21: note: stmt 0 *_8 = _9;
t.c:4:21: note: stmt 1 *_14 = _15;
t.c:4:21: note: children 0x4858158
t.c:4:21: note:   node 0x4858158 (max_nunits=2, refcnt=1) vector(2) double
t.c:4:21: note:   op template: _9 = _5 * _7;
t.c:4:21: note: stmt 0 _9 = _5 * _7;
t.c:4:21: note: stmt 1 _15 = _7 * _13;
t.c:4:21: note: children 0x4858268 0x48582f0
t.c:4:21: note:   node 0x4858268 (max_nunits=2, refcnt=1) vector(2) double
t.c:4:21: note:   op template: _5 = *_4;
t.c:4:21: note: stmt 0 _5 = *_4;
t.c:4:21: note: stmt 1 _13 = *_12;
t.c:4:21: note:   node 0x48582f0 (max_nunits=2, refcnt=1) vector(2) double
t.c:4:21: note:   op template: _7 = *_6;
t.c:4:21: note: stmt 0 _7 = *_6;
t.c:4:21: note: stmt 1 _7 = *_6;
t.c:4:21: note: load permutation { 0 0 }

and we get

.L4:
movupd  (%rdx,%rax), %xmm0
movupd  (%rsi,%rax,2), %xmm2
unpcklpd%xmm0, %xmm0
mulpd   %xmm2, %xmm0
movups  %xmm0, (%rdi,%rax,2)
addq$8, %rax
cmpq%rax, %r8
jne .L4

[Bug c++/110363] New: New use-after-move warning

[antoshkka at gmail dot com via Gcc-bugs]

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

Bug ID: 110363
   Summary: New use-after-move warning
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

There's a quite common rule "after the object was moved from it is in the
indeterminate state; it should be either destroyed or a new value should be
assigned to it". The C++ Standard Library follows that rule, many libraries and
companies follow that rule.


Please introduce some '-Wuse-after-move' that warns if the object could be used
after move:


struct resource {
resource(resource&&) noexcept;
~resource();

void kill_it() && noexcept;
void should_warn_use_after_move() const & noexcept;
};

void should_warn_use_after_move(resource& r) noexcept;

void do_something(resource r) {
static_cast(r).kill_it(); // moved out
should_warn_use_after_move(r);// warn
r.should_warn_use_after_move();   // warn
}


Some related request on stackoverflow
https://stackoverflow.com/questions/72532377/g-detect-use-after-stdmove

[Bug rtl-optimization/110362] Range information on lower bytes of __uint128_t

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2023-06-22
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

Also on the GIMPLE level we have

   [local count: 1073741824]:
  # RANGE [irange] __int128 unsigned [0, 0][4294967296, +INF] NONZERO
0x
  _1 = a_2(D) << 32;
  __a_4 = _1 | b_3(D);
  _5 = (int) __a_4;

the lowpart cast (int) __a_4 can be simplified to (int) b_3(D) based on
the range info of _1.  For example via

(simplify
 (convert (ior:c with_possible_nonzero_bits@0 @1))
 (if ( ... @0 has all zeros in lower TYPE_PRECSION (type) bits ...)
  (convert @1)))

I suppose a variant with b & (a << 32) is already optimized (to zero)?

[Bug tree-optimization/110361] [13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r13-2020-g16b013c9d9b

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.2
   Keywords||missed-optimization

[Bug libgomp/110364] New: [OpenMP] Environment vars - doc and device-specific cleanup; make GOMP_DEBUG more useful; janitorial takes

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

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

Bug ID: 110364
   Summary: [OpenMP] Environment vars - doc and device-specific
cleanup; make GOMP_DEBUG more useful; janitorial takes
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: documentation, openmp
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

OpenMP TR11 added the _ALL, _DEV, and _DEV_ suffix.


After the patch work stated, the following addition was done to the spec:
• Device-specific environment variables must not specify the initial device.

TODO: Implement this.


OMP_STACKSIZE_DEV etc. → Make this applicable to the non-host devices,
→ GCN_STACK_SIZE and nvptx's nvptx_stacks_size() (which is per warp!).


Improve the documentation (and implementation) with regards to the
device-specific ICVs - namely: which are handled, which aren't + possibly
implement some if needed.
Cross ref: PR 109620 (OMP_CANCELLATION), PR109875 (OMP_NUM_TEAMS)

(First step for the documentation bit was commit
r14-2032-g2cd0689a79498dcaaadc8cc5c1c4d0a452a4fb09)


GOMP_DEBUG: Currently, it is a 0 or all flag, it would be much more useful it
the numeric values could be used - either as (n) less output than (n+1) or
using some bitmap flags like 1<<0, 1<<1, 1<<2 turning on different outputs
(possibly with supporting some a comma-separated list of names for them.

In particular, plugin-nvptx outputs too much - and GCN has its own GCN_DEBUG.

* * *

BTW: While all OMP_* env vars are documented, the "OpenMP Runtime Library
Routines" lacks many routines there were added.

I additionally wonder whether the named-constants and kinds documentation
should be moved from Fortran's ../gcc/fortran/intrinsic.texi to libgomp and
extended to cover also the C/C++.

[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

--- Comment #12 from Neil Carlson  ---
Paul,

> [...] there are some humdingers going back a long way that I will take a look 
> at,
> once I am done with associate.

That would be great, thanks!

[Bug debug/110308] [14 Regression] ICE on audiofile-0.3.6: RTL: vartrack: Segmentation fault in mode_to_precision(machine_mode)

[thiago.bauermann at linaro dot org via Gcc-bugs]

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

Thiago Jung Bauermann  changed:

   What|Removed |Added

 CC||thiago.bauermann at linaro dot 
org

--- Comment #14 from Thiago Jung Bauermann  
---
(In reply to manolis.tsamis from comment #10)
> Created attachment 55369 [details]
> ICE-fix-proposal-1

This patch fixes the ICEs I reported on the mailing list with profiled
bootstrap lto in both armv8l-linux-gnueabihf and aarch64-linux-gnu. Thanks!

[Bug testsuite/101002] Some powerpc tests fail with -mlong-double-64

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

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

--- Comment #10 from David Edelsohn  ---
Please be careful about the effect on AIX.  AIX defaults to long-double-64.

[Bug tree-optimization/110310] vector epilogue handling is inefficient

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

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

--- Comment #4 from avieira at gcc dot gnu.org ---
> OK, so I take away from this that you don't think this is done the way
it is on purpose.

I don't think so, I think I just found a place where it was safe to do so, i.e.
where we knew the vectorization factor would not change after. 

I have a vague recollection that vect_analyze_loop used to be somewhat more
complex, but given the now clear separation between main loop and epilogue
vinfo selection we have now, we could probably do this as we analyze
loop_vinfos for epilogue?

Assuming that during analysis we've had determined vf, peeling and use of
masks, which I'm pretty sure we have.

Might be worth asking Richard Sandiford if he can think of anything that we
might not be 'fixing' during analysis.

[Bug analyzer/110198] [14 regression] g++.dg/analyzer/pr100244.C fails after r14-1632-g9589a46ddadc8b

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

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

--- Comment #5 from Hans-Peter Nilsson  ---
(In reply to Benjamin Priour from comment #4)
> Yes, has been fixed and regtested a week ago. However I was in vacation
> last week.
> I will submit it shortly. though I would prefer to perform another
> regtesting on a freshly pulled trunk first.

You may need to rebase your changes again: after one of the changes in 
ce47d3c2cf59..0e466e978c72, gcc.dg/analyzer/pr101962.c appears to be fixed and
there's just g++.dg/analyzer/pr100244.C left (for cris-elf).

But please send your patches soon and let others test them, if your bootstrap
cycles is longer than a day!

[Bug rtl-optimization/110307] ICE in move_insn, at haifa-sched.cc:5473 when building Ruby on alpha with -fPIC -O2 (or -fpeephole2 -fschedule-insns2)

[matoro_gcc_bugzilla at matoro dot tk via Gcc-bugs]

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

matoro  changed:

   What|Removed |Added

  Known to fail||12.3.1, 13.1.1

--- Comment #9 from matoro  ---
I have a gcc 12 build, this does repro there as well.  Assertions enabled on
this one so I see the same instruction dump now.  It takes about 2 days, so I
will go ahead and kick off a build of 13 with those two patches mentioned
above.  Any other changes I should include in the build?

[Bug tree-optimization/110365] New: wrong code at -O2 and -O3 on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 110365
   Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a recent regression.

Compiler Explorer: https://godbolt.org/z/aP9aMrsGq

[725] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230622 (experimental) [master r14-924-gd709841ae0f] (GCC) 
[726] % 
[726] % gcctk -O1 small.c; ./a.out
[727] % 
[727] % gcctk -O2 small.c
[728] % ./a.out
Aborted
[729] % 
[729] % cat small.c
int a = 1;
void b() {
  int *c = &a, d = a;
  if (a < -1)
d = a + d;
  a = d;
  if (a > 0)
*c = 1;
  int e = -a;
  if (e < a) {
e = a;
if (!a)
  __builtin_abort();
  }
  a = e;
}
int main() {
  b();
  if (a != 1)
__builtin_abort();
  return 0;
}

[Bug c/105863] RFE: C23 #embed

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

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

--- Comment #5 from Marek Polacek  ---
Latest rev: https://open-std.org/JTC1/SC22/WG14/www/docs/n3017.htm

[Bug tree-optimization/110365] wrong code at -O2 and -O3 on x86_64-linux-gnu

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

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

--- Comment #1 from Andrew Pinski  ---

phiopt match-simplify trying:
d_6 > 0 ? 1 : e_1
Matching expression match.pd:1990, gimple-match-5.cc:23
Matching expression match.pd:1990, gimple-match-5.cc:23
Applying pattern match.pd:4742, gimple-match-2.cc:16205
Folded into the sequence:
_16 = d_6 > 0;
_8 = (int) _16;
_13 = e_1 | _8;
statement un-sinked:
e_1 = -d_6;
Removing basic block 5
;; basic block 5, loop depth 0
;;  pred:   4
;;  succ:   6

[Bug tree-optimization/110252] [14 Regression] Wrong code at -O2/3/s on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||zhendong.su at inf dot ethz.ch

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

[Bug tree-optimization/110365] wrong code at -O2 and -O3 on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Duplicate of bug 110252 really.

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

[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type

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

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

--- Comment #12 from kargl at gcc dot gnu.org ---
(In reply to Alexander Westbrooks from comment #11)
> (In reply to vegard from comment #10)
> > (In reply to kargl from comment #9)
> > > (In reply to alig from comment #8)
> > > > The problem still persists with GNU Fortran (GCC) 11.1.0.
> > > 
> > > The problem is likely to persist for the foreseeable future
> > > as there is no one left to work on gfortran bugs.  Lacking 
> > > a sudden influx of new volunteer contributors, it seems
> > > the only way forward is to NOT use parameterized derived 
> > > types with gfortran.
> > 
> > Any news here? I seem to be having this issue with gfortran (Homebrew GCC)
> > 12.2.0
> > 
> > As a side note: I'm somewhat new to the fortran community, but could see
> > myself contributing to gfortran in the future. Do you think you could point
> > me to where I should read up on contributing?
> 
> Hello!
> 
> I'm new to the community as well. I have had the same issue with this bug
> and first encountered it 5 years ago while working on my thesis. Two weeks
> ago I decided to tackle this bug. I have found the issues in the code, and I
> was able to successfully compiles the following example. I made sure that
> the LEN type parameter condition was enforced as ja...@gcc.gnu.org stated in
> Comment #6 and I used inheritance in this example to test the added logic to
> ensure that a PDT instance belonged to a PDT template. 
> 
> The only things I have left to do is write applicable test cases (which I
> haven't done before. I am learning how to use the DejaGNU framework as I
> work on this) and obtain some guidance on how to get this code verified by
> others and ultimately accepted as fixed code into the compiler. I am reading
> the documentation of the GNU Fortran rules and I hope to get the test cases
> completed and have the fix under review within the next couple of weeks.

Your contribution will likely be most welcomed.  I encourage you to send the
patch to fort...@gcc.gnu.org and gcc-patc...@gcc.gnu.org to open up discussion.
For testcases, look in gcc/testsuite/gfortran.dg for files with the string
'pdt' in the name.  Copy one of those and adjust it to suit your needs.

[Bug rtl-optimization/110307] ICE in move_insn, at haifa-sched.cc:5473 when building Ruby on alpha with -fPIC -O2 (or -fpeephole2 -fschedule-insns2)

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

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

--- Comment #10 from Alexander Monakov  ---
I think the first patch may result in duplicated notes, so I wouldn't recommend
picking it.

[Bug c++/110346] [C++26] P2752R3 - Static storage for braced initializers

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

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

Marek Polacek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Last reconfirmed||2023-06-22
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #3 from Marek Polacek  ---
Resolved by Jason; let me update the docs at least.

[Bug rtl-optimization/110307] ICE in move_insn, at haifa-sched.cc:5473 when building Ruby on alpha with -fPIC -O2 (or -fpeephole2 -fschedule-insns2)

[matoro_gcc_bugzilla at matoro dot tk via Gcc-bugs]

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

--- Comment #11 from matoro  ---
(In reply to Alexander Monakov from comment #10)
> I think the first patch may result in duplicated notes, so I wouldn't
> recommend picking it.

Oh okay, so just the second patch then?  Let me try that.

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

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

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|janus at gcc dot gnu.org   |pault at gcc dot gnu.org

--- Comment #35 from Paul Thomas  ---
Created attachment 55383
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55383&action=edit
Fix for this PR

Hello again Neil,

I had a tedious job to do, which I alleviated by fixing this bug :-)

Dejagnu-style testcase below.

Now the earliest surviving bug is gfortran-20160129.f90 and there are 22/64
remaining failures (there might be fewer; my octave test harness doesn't cope
with multiple sources yet).

Regards

Paul

! { dg-do run }
!
! Contributed by Neil Carlson  
!
program main
  character(2) :: c

  type :: S
integer :: n
  end type
  type(S) :: Sobj

  type, extends(S) :: S2
integer :: m
  end type
  type(S2) :: S2obj

  type :: T
class(S), allocatable :: x
  end type
  type(T) :: Tobj

  Sobj = S(1)
  Tobj = T(Sobj)

  S2obj = S2(1,2)
  Tobj = T(S2obj)! Failed here
  select type (x => Tobj%x)
type is (S2)
  if ((x%n .ne. 1) .or. (x%m .ne. 2)) stop 1
class default
  stop 2
  end select

  c = "  "
  call pass_it (T(Sobj))
  if (c .ne. "S ") stop 3
  call pass_it (T(S2obj))! and here
  if (c .ne. "S2") stop 4

contains

  subroutine pass_it (foo)
type(T), intent(in) :: foo
select type (x => foo%x)
  type is (S)
c = "S "
if (x%n .ne. 1) stop 5
  type is (S2)
c = "S2"
if ((x%n .ne. 1) .or. (x%m .ne. 2)) stop 6
  class default
stop 7
end select
  end subroutine

end program

[Bug libstdc++/110366] New: [C++26] P2641R4 Checking if a union alternative is active

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

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

Bug ID: 110366
   Summary: [C++26] P2641R4 Checking if a union alternative is
active
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 110339
  Target Milestone: ---

https://wg21.link/p2641r4

This needs a new built-in. We can't use __builtin_constant_p(&x) because the
address of a union member is a constant even if that isn't the active member.
We can't use __builtin_constant_p(x) because not all types usable in constexpr
contexts are boolean testable.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339
[Bug 110339] Implement C++26 library features

[Bug c++/110367] New: [C++26] Add new built-in for std::is_within_lifetime

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

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

Bug ID: 110367
   Summary: [C++26] Add new built-in for std::is_within_lifetime
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 110366
  Target Milestone: ---

This is needed for https://wg21.link/p2641r4 which was recently voted into the
C++26 draft.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110366
[Bug 110366] [C++26] P2641R4 Checking if a union alternative is active

[Bug c++/110367] [C++26] Add new built-in for std::is_within_lifetime

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2023-06-22
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

[Bug libstdc++/110366] [C++26] P2641R4 Checking if a union alternative is active

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2023-06-22
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

[Bug c/110368] New: Incorrect "is used uninitialized" warning message

[clugstj at gmail dot com via Gcc-bugs]

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

Bug ID: 110368
   Summary: Incorrect "is used uninitialized" warning message
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clugstj at gmail dot com
  Target Milestone: ---

Created attachment 55384
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55384&action=edit
Code that causes warning

The attached code, when compiled with:

>gcc -O2 -Wall -Wextra -c uninit.c

results in the following error messages:

uninit.c: In function 'cksum':
uninit.c:20:13: warning: 'l' is used uninitialized [-Wuninitialized]
   20 |unsigned l = len;
  | ^
uninit.c:21:13: warning: 'n' is used uninitialized [-Wuninitialized]
   21 |unsigned n = protocol;
  | ^

[Bug c/110368] Incorrect "is used uninitialized" warning message

[clugstj at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Jon Clugston  ---
Created attachment 55385
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55385&action=edit
gcc -v

[Bug c/110368] Incorrect "is used uninitialized" warning message

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

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

--- Comment #2 from Andrew Pinski  ---
The warning is due to the code having undefined behavior in it. The code stores
in a variable as int but reads part of it via short type. That is an aliasing
violation.

[Bug c/110368] Incorrect "is used uninitialized" warning message

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
As explained undefined code.

[Bug c/110368] Incorrect "is used uninitialized" warning message

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

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

--- Comment #4 from Andrew Pinski  ---
The code can fixed using memcpy
Replace:
c   += *data_16++

With:
unsigned tmp;
memcpy(&tmp, data_16, sizeof(tmp));
data_16++;
c += tmp;

[Bug c/110368] Incorrect "is used uninitialized" warning message

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> The code can fixed using memcpy
> Replace:
> c   += *data_16++
> 
> With:
> unsigned tmp;
> memcpy(&tmp, data_16, sizeof(tmp));
> data_16++;
> c += tmp;

Small typo, the type of tmp should have been `unsigned short`.

[Bug tree-optimization/110369] New: wrong code on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 110369
   Summary: wrong code on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a recent regression. I'm unsure how interesting the test is as
it uses a few non-default flags, but here it is.

Compiler Explorer: https://godbolt.org/z/rvsrfzb1K

[813] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230622 (experimental) [master r14-924-gd709841ae0f] (GCC) 
[814] % 
[814] % gcctk -O3 -fno-thread-jumps -fsel-sched-pipelining
-fsel-sched-pipelining-outer-loops -fno-split-loops -fno-tree-loop-ivcanon
-fselective-scheduling2 -w small.c
[815] % timeout -s 9 5 ./a.out
Killed
[816] % 
[816] % gcctk -O3 -w small.c; ./a.out
[817] % 
[817] % cat small.c
int printf(const char *, ...);
int a, b[2] = {0, 0}, c;
void d() {
  int e, f;
  for (f = 0; f < 2; f++)
if (a) {
  for (e = 0; e < 5; e++) {
printf("%d", b[e]);
if (c)
  printf("\n");
  }
}
}
int main() { d(); }

[Bug tree-optimization/110370] New: wrong code on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 110370
   Summary: wrong code on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

Similar to PR 110369, this test also uses a number of non-default flags. It is
a regression from 10.*, and affects 11.* and later. 

Compiler Explorer: https://godbolt.org/z/d1T6vh7sf

[782] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230622 (experimental) [master r14-924-gd709841ae0f] (GCC) 
[783] % 
[783] % gcctk -O2 -fno-tree-copy-prop -fira-loop-pressure -ftracer
-fno-tree-vrp -fno-tree-forwprop -fno-tree-ccp -fno-code-hoisting -fno-gcse
-fno-tree-dominator-opts -fno-tree-fre -fno-tree-pre -fsel-sched-pipelining
-fno-tree-ter -fschedule-insns -fselective-scheduling2 small.c
[784] % ./a.out
Floating point exception
[785] % 
[785] % gcctk -O2 small.c; ./a.out
[786] % 
[786] % cat small.c
int printf(const char *, ...);
int a;
long b;
short c = 1;
unsigned long d = 5;
int main() {
  short f = 1;
  int g, i = 0;
  unsigned h = 3, j = 1;
  for (; i < 4; i++) {
int k, m = c * (f % d);
long l = f & d;
if (d || !j || g) {
  k = g = l % h | b;
  b = (j < b) & (f > k);
  if (!m)
printf("%d", g);
  if (!c)
printf("%d", a);
}
g = k;
b = l;
a = m;
  }
  return 0;
}

[Bug tree-optimization/110365] wrong code at -O2 and -O3 on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

--- Comment #3 from Zhendong Su  ---
(In reply to Andrew Pinski from comment #2)
> Duplicate of bug 110252 really.
> 
> *** This bug has been marked as a duplicate of bug 110252 ***

Sorry about the dup, and thanks for triaging it.

[Bug c++/110346] [C++26] P2752R3 - Static storage for braced initializers

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Docs updated.

[Bug c++/110338] Implement C++26 language features

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

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

Bug 110346 Summary: [C++26] P2752R3 - Static storage for braced initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110346

   What|Removed |Added

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

[Bug tree-optimization/110369] wrong code on x86_64-linux-gnu

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I don't think it's wrong code:

110369.c:8:9: warning: iteration 2 invokes undefined behavior
[-Waggressive-loop-optimizations]
8 | printf("%d", b[e]);
  | ^~
110369.c:7:21: note: within this loop
7 |   for (e = 0; e < 5; e++) {
  |   ~~^~~

The behavior changed in r14-338.

[Bug tree-optimization/110369] wrong code on x86_64-linux-gnu

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #2 from Alexander Monakov  ---
The loop over 'e' is never entered, because 'a' is zero.

[Bug tree-optimization/110369] [14 Regression] wrong code on x86_64-linux-gnu

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|wrong code on   |[14 Regression] wrong code
   |x86_64-linux-gnu|on x86_64-linux-gnu
   Last reconfirmed||2023-06-22
   Keywords||wrong-code
   Target Milestone|--- |14.0
 Ever confirmed|0   |1
 CC||pinskia at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

[Bug fortran/110360] ABI issue with character,value dummy argument

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

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #4)
> (In reply to anlauf from comment #0)
> > but the second line contains junk, as the tree-dump shows:
> > 
> >   static void val (character(kind=1)[1:1], integer(kind=8));
> >   static integer(kind=4) a = 65;
> > 
> >   val ("A", 1);
> >   {
> > character(kind=1) char.1;
> > 
> > char.1 = (character(kind=1)) a;
> > val (&char.1, 1);
> >   }
> > 
> > Clearly, the second case is inconsistent with the ABI, see the prototype, 
> > and
> > 
> Yes, but it's not worse than the first one: "A" is a pointer, not a value.
> I would say that it is the middle-end that is inconsistent here.

Hmm.  Have a look at the following:

subroutine s
  implicit none
  interface
 subroutine val (c)
   character, value :: c
 end
  end interface
  call val ("A")
  call val ("ABCDEF")
end

Dump-tree:

  val ("A", 1);
  val ("ABCDEF", 6);

I am not good at reading assembler, but it appears that "ABCDEF" is
awfully copied (pushed?) on the stack. --> missed optimization.

(I've played a little but didn't find a quick, working solution for the
truncation, only some awful lengthy code.  Will add a TODO in the patch.)

Changing the interface to use "character, intent(in) :: c"
produces what I assume is the ordinary by-reference.

> Looks good.
> I would suggest to create an overload that avoids duplicating the 
> build_int_cst (integer_type_node, 1) in several places.
> Shouldn't it be build_int_cst (gfc_charlen_type_node, 1) by the way?

That's true.  I copied that from another snippet.

It is not clear to me what you mean by "overload" here.  Do you want to
elaborate?

I've also extended the testcase to sample most things that came to my mind,
except for the [character, value, bind(c)] case.  We'd better track this
elsewhere.

[Bug c++/80242] [C++17+] "Trailing return types" with "non-type template arguments" which could be "constant expressions" produce a parsing error

[roland at rschulz dot eu via Gcc-bugs]

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

Roland Schulz  changed:

   What|Removed |Added

 CC||roland at rschulz dot eu

--- Comment #2 from Roland Schulz  ---
Is https://stackoverflow.com/questions/76534613/ a duplicate of this?

[Bug c/102989] Implement C2x's n2763 (_BitInt)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #55376|0   |1
is obsolete||

--- Comment #68 from Jakub Jelinek  ---
Created attachment 55386
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55386&action=edit
gcc14-bitint-wip.patch

Further progress, this handles also constants, left shifts by small amount (0
to limb_prec - 1) and ==/!= comparisons and calls.

[Bug fortran/110360] ABI issue with character,value dummy argument

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

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2023-June/059503.html

[Bug fortran/110371] New: gfortran ICE "verify_gimple failed" in gfortran.dg/vect/pr51058-2.f90

[thiago.bauermann at linaro dot org via Gcc-bugs]

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

Bug ID: 110371
   Summary: gfortran ICE "verify_gimple failed" in
gfortran.dg/vect/pr51058-2.f90
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago.bauermann at linaro dot org
  Target Milestone: ---

Created attachment 55387
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55387&action=edit
Output of running gfortran with -freport-bug

In today's trunk (tested commit 33ebb0dff9bb "configure: Implement
--enable-host-bind-now") I get these new failures on aarch64-linux-gnu:

Running gcc:gcc.target/aarch64/sve/aarch64-sve.exp ...
FAIL: gcc.target/aarch64/sve/pack_fcvt_signed_1.c scan-assembler-times
\\tfcvtzs\\tz[0-9]+\\.s, p[0-7]/m, z[0-9]+\\.d\\n 2
FAIL: gcc.target/aarch64/sve/pack_fcvt_signed_1.c scan-assembler-times
\\tuzp1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
FAIL: gcc.target/aarch64/sve/pack_fcvt_unsigned_1.c scan-assembler-times
\\tfcvtzu\\tz[0-9]+\\.s, p[0-7]/m, z[0-9]+\\.d\\n 2
FAIL: gcc.target/aarch64/sve/pack_fcvt_unsigned_1.c scan-assembler-times
\\tuzp1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
FAIL: gcc.target/aarch64/sve/unpack_fcvt_signed_1.c scan-assembler-times
\\tscvtf\\tz[0-9]+\\.d, p[0-7]/m, z[0-9]+\\.s\\n 2
FAIL: gcc.target/aarch64/sve/unpack_fcvt_signed_1.c scan-assembler-times
\\tzip1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
FAIL: gcc.target/aarch64/sve/unpack_fcvt_signed_1.c scan-assembler-times
\\tzip2\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
FAIL: gcc.target/aarch64/sve/unpack_fcvt_unsigned_1.c scan-assembler-times
\\tucvtf\\tz[0-9]+\\.d, p[0-7]/m, z[0-9]+\\.s\\n 2
FAIL: gcc.target/aarch64/sve/unpack_fcvt_unsigned_1.c scan-assembler-times
\\tzip1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
FAIL: gcc.target/aarch64/sve/unpack_fcvt_unsigned_1.c scan-assembler-times
\\tzip2\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
=== gfortran tests ===

Running gfortran:gfortran.dg/dg.exp ...
FAIL: gfortran.dg/pr68251.f90 -O  (internal compiler error: verify_gimple
failed)
FAIL: gfortran.dg/pr68251.f90 -O  (test for excess errors)

Running gfortran:gfortran.dg/vect/vect.exp ...
FAIL: gfortran.dg/vect/pr51058-2.f90 -O  (internal compiler error:
verify_gimple failed)
FAIL: gfortran.dg/vect/pr51058-2.f90 -O  (test for excess errors)

Looking into this failure:

FAIL: gfortran.dg/vect/pr51058-2.f90 -O  (internal compiler error:
verify_gimple failed)

The problem is:

spawn -ignore SIGHUP
/home/thiago.bauermann/.cache/builds/gcc-wt-native/gcc/testsuite/gfortran/../../gfortran
-B/home/thiago.bauermann/.cache/builds/gcc-wt-native/gcc/testsuite/gfortran/../../
-B/home/thiago.bauermann/.cache/builds/gcc-wt-native/aarch64-unknown-linux-gnu/./libgfortran/
/home/thiago.bauermann/src/gcc-wt/gcc/testsuite/gfortran.dg/vect/pr51058-2.f90
-fdiagnostics-plain-output -fdiagnostics-plain-output -O -O2 -ftree-vectorize
-fvect-cost-model=unlimited -fdump-tree-vect-details -S -o pr51058-2.s
/home/thiago.bauermann/src/gcc-wt/gcc/testsuite/gfortran.dg/vect/pr51058-2.f90:3:18:
Error: invalid types in nop conversion
real(kind=8)
integer(kind=4)
vect__53.48_312 = (vector(2) real(kind=8)) vect__54.46_306;
/home/thiago.bauermann/src/gcc-wt/gcc/testsuite/gfortran.dg/vect/pr51058-2.f90:3:18:
Error: invalid types in nop conversion
real(kind=8)
integer(kind=4)
vect__53.48_314 = (vector(2) real(kind=8)) vect__54.46_308;
during GIMPLE pass: vect
dump file: pr51058-2.f90.173t.vect
/home/thiago.bauermann/src/gcc-wt/gcc/testsuite/gfortran.dg/vect/pr51058-2.f90:3:18:
internal compiler error: verify_gimple failed
0xf5844b verify_gimple_in_cfg(function*, bool, bool)
/home/thiago.bauermann/src/gcc-wt/gcc/tree-cfg.cc:5646
0xde3e03 execute_function_todo
/home/thiago.bauermann/src/gcc-wt/gcc/passes.cc:2098
0xde442f execute_todo
/home/thiago.bauermann/src/gcc-wt/gcc/passes.cc:2152
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
FAIL: gfortran.dg/vect/pr51058-2.f90   -O  (internal compiler error:
verify_gimple failed)

I'm attaching the output of running with -freport-bug, and also the generated
dump file.

Our CI bisected the problem to commit 6f19cf752616 "Use intermiediate integer
type for float_expr/fix_trunc_expr when direct optab is not existed."
And indeed, if I revert that commit from trunk, all the mentioned tests pass.

[Bug fortran/110371] gfortran ICE "verify_gimple failed" in gfortran.dg/vect/pr51058-2.f90

[thiago.bauermann at linaro dot org via Gcc-bugs]

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

--- Comment #1 from Thiago Jung Bauermann  
---
Created attachment 55388
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55388&action=edit
Dump file.

This is the dump file generated by the -freport-bug run from the previous
attachment.

[Bug c/105863] RFE: C23 #embed

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #6 from joseph at codesourcery dot com  ---
The latest version should be taken to be what's in the working draft 
N3096, plus the editorial fixes from CD2 comments GB-081 through GB-084.

[Bug rtl-optimization/110369] [14 Regression] wrong code on x86_64-linux-gnu with sel-scheduling

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[14 Regression] wrong code  |[14 Regression] wrong code
   |on x86_64-linux-gnu |on x86_64-linux-gnu with
   ||sel-scheduling
  Component|tree-optimization   |rtl-optimization

--- Comment #3 from Andrew Pinski  ---
The first difference (after my patch) is in VRP:
Before:
```
Folding statement: f_14 = f_20 + 1;
   Loops range found for f_20: [irange] int [0, 1] NONZERO 0x1 and calculated
range :[irange] int [0, 1] NONZERO 0x1
Matching expression match.pd:2404, gimple-match.cc:852
Matching expression match.pd:2407, gimple-match.cc:925
Matching expression match.pd:2414, gimple-match.cc:985
Matching expression match.pd:1924, gimple-match.cc:802
Matching expression match.pd:1896, gimple-match.cc:720
Global Exported: f_14 = [irange] int [1, 2] NONZERO 0x3
Folded into: f_14 = _18 ? 1 : 2;
```

After:
```
Folding statement: f_14 = f_20 + 1;
   Loops range found for f_20: [irange] int [0, 1] NONZERO 0x1 and calculated
range :[irange] int [0, 1] NONZERO 0x1
Matching expression match.pd:2404, gimple-match.cc:852
Matching expression match.pd:2407, gimple-match.cc:925
Matching expression match.pd:2414, gimple-match.cc:985
Matching expression match.pd:1924, gimple-match.cc:802
Applying pattern match.pd:4720, gimple-match.cc:11377
Applying pattern match.pd:3998, gimple-match.cc:39957
gimple_simplified to _8 = f_20 + 1;
f_14 = _8;
 Registering value_relation (_8 > f_20) (bb12) at _8 = f_20 + 1;
 Registering value_relation (f_14 == _8) (bb12) at f_14 = _8;
Global Exported: f_14 = [irange] int [1, 2] NONZERO 0x3
Folded into: f_14 = _8;
```

Note _18 is defined as:
_18 = f_20 == 0;

Which is ok and 100% correct.

And then another difference:
Before:
```
Folding statement: if (f_14 != 2)

Visiting conditional with predicate: if (f_14 != 2)

With known ranges
f_14: [irange] int [1, 2] NONZERO 0x3

Predicate evaluates to: DON'T KNOW
Matching expression match.pd:2404, gimple-match.cc:852
Matching expression match.pd:2407, gimple-match.cc:925
Matching expression match.pd:2414, gimple-match.cc:985
Applying pattern match.pd:5945, gimple-match.cc:24663
Matching expression match.pd:1924, gimple-match.cc:802
Applying pattern match.pd:4600, gimple-match.cc:176366
Applying pattern match.pd:3998, gimple-match.cc:39802
gimple_simplified to if (_18 != 0)
Folded into: if (_18 != 0)
```
After:
```
Folding statement: if (f_14 != 2)

Visiting conditional with predicate: if (f_14 != 2)

With known ranges
f_14: [irange] int [1, 2] NONZERO 0x3

Predicate evaluates to: DON'T KNOW
Matching expression match.pd:2404, gimple-match.cc:852
Matching expression match.pd:2407, gimple-match.cc:925
Matching expression match.pd:2414, gimple-match.cc:985
Not folded
```

I don't get why VRP folded it differently.


Anyways we just have a missed optimization inside VRP after my commit, not
wrong code.

The wrong code is due to sel scheduling.


The code at .optimized:
Before:
```
  if (f_20 == 0)
```
After:
```
  # RANGE [irange] int [-INF, +INF] NONZERO 0x3
  _8 = f_20 + 1;
  if (_8 != 2)
```
(which is basically f_21 != 1 or rather f_21 == 0 here)

[Bug target/110372] New: [14 Regression] ICE: insn does not satisfy its constraints: {*movdi_internal} with -mno-sse2

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 110372
   Summary: [14 Regression] ICE: insn does not satisfy its
constraints: {*movdi_internal} with -mno-sse2
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

Created attachment 55389
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55389&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -mno-sse2 testcase.c
testcase.c: In function 'foo0':
testcase.c:11:1: error: insn does not satisfy its constraints:
   11 | }
  | ^
(insn 36 3 41 2 (set (reg:DI 0 ax [123])
(reg:DI 20 xmm0 [orig:98 u ] [98])) "testcase.c":9:14 90
{*movdi_internal}
 (nil))
during RTL pass: reload
testcase.c:11:1: internal compiler error: in extract_constrain_insn, at
recog.cc:2692
0x7cc337 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x7cc3be _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.cc:118
0x7bcc54 extract_constrain_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2692
0x12476b4 check_rtl
/repo/gcc-trunk/gcc/lra.cc:2147
0x124be5b lra(_IO_FILE*)
/repo/gcc-trunk/gcc/lra.cc:2565
0x11fb609 do_reload
/repo/gcc-trunk/gcc/ira.cc:5967
0x11fb609 execute
/repo/gcc-trunk/gcc/ira.cc:6153
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-2031-20230622101115-g2ac41866270-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-2031-20230622101115-g2ac41866270-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230622 (experimental) (GCC)

[Bug rtl-optimization/110369] [14 Regression] wrong code on x86_64-linux-gnu with sel-scheduling

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

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

--- Comment #4 from Andrew Pinski  ---
Here is another testcase which shows the same behavior but turning off VRP and
a few others:
```
//-fselective-scheduling2  -O3 -fno-thread-jumps -fno-split-loops
-fno-tree-loop-ivcanon  -fsel-sched-pipelining
-fsel-sched-pipelining-outer-loops  -fno-tree-vrp -fno-tree-forwprop

int printf(const char *, ...);
int a, b[2] = {0, 0}, c;
void d() {
  int e, f = 0, f1 = 0;
  for (;;)
  {
if (a) {
  for (e = 0; e < 5; e++) {
printf("%d", b[e]);
if (c)
  printf("\n");
  }
}
f = f+1;
if (f!=2)
  f = 1;
else
  return;
  }
}
int main() { d(); }
```

The behavior I think changes with the above testcase with r14-162 (but still
just a latent bug)

[Bug fortran/100650] Passing a derived-type array constructor to the reshape intrinsic gives incorrect results

[damian at archaeologic dot codes via Gcc-bugs]

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

--- Comment #4 from Damian Rouson  ---
Thanks, Paul.  No urgency.  The workaround is simple and painless.

[Bug tree-optimization/110365] wrong code at -O2 and -O3 on x86_64-linux-gnu

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Zhendong Su from comment #3)
> Sorry about the dup, and thanks for triaging it.

I really should fix PR 110252 before more different new testcases are produced.

[Bug tree-optimization/110373] New: __builtin_object_size does not recognize subarrays in multi-dimensional arrays

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

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

Bug ID: 110373
   Summary: __builtin_object_size does not recognize subarrays in
multi-dimensional arrays
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: siddhesh at gcc dot gnu.org
  Target Milestone: ---

const char example[][32] = {
"abcd",
"xyzt",
"1234",
"5678"
};

__SIZE_TYPE__ foo (void) {
return __builtin_dynamic_object_size(example[1], 1);
}

$ gcc/cc1 -quiet -O -o - ~/src/random/fortify-module/fortify-module1.c 
.file   "fortify-module1.c"
.text
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movl$96, %eax
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.globl  example
.section.rodata
.align 32
.type   example, @object
.size   example, 128
example:
.string "abcd"
.zero   27
.string "xyzt"
.zero   27
.string "1234"
.zero   27
    .string "5678"
.zero   27
.ident  "GCC: (GNU) 14.0.0 20230622 (experimental)"
.section.note.GNU-stack,"",@progbits


Clang returns 32 instead, recognizing the subarray correctly.  This appears to
be happening very early on in the frontend; addr_object_size doesn't see that
this is a subarray reference since it only compares the pt_var with the operand
of the ADDR_EXPR.  If pt_var is an ARRAY_REF, it should also additionally see
if this is a subarray reference.

[Bug tree-optimization/110283] Bogus Warray-bounds

[c_antonio_sanchez at msn dot com via Gcc-bugs]

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

Antonio Sanchez  changed:

   What|Removed |Added

 CC||c_antonio_sanchez at msn dot 
com

--- Comment #3 from Antonio Sanchez  ---
@Andrew Pinsky can you elaborate on what's potentially wrong in the Eigen code?

The template argument will ignore the `may_alias` attribute, but the `typedef`s
do not, so `Packet4f` and `unpacket_traits::half` are still marked as
`may_alias` and do allow aliasing without strict-aliasing warnings.

[Bug tree-optimization/110283] Bogus Warray-bounds

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Antonio Sanchez from comment #3)
> @Andrew Pinsky can you elaborate on what's potentially wrong in the Eigen
> code?
> 
> The template argument will ignore the `may_alias` attribute, but the
> `typedef`s do not, so `Packet4f` and `unpacket_traits::half` are
> still marked as `may_alias` and do allow aliasing without strict-aliasing
> warnings.

As I said potentially wrong because of the template arguments ignorning the
attributes and I didn't look further into the code to see if Eigen used that
template argument in anyway except for matching.


But that is a different issue overall.

Anyways the warning here is complex due to how complex the code Eigen causes to
be inlined and someone will have to figure out why the warning is happening if
it is a true bug or just warning about dead code or something GCC could not
figure out is not out of bounds.

[Bug tree-optimization/110371] [14 Regression] gfortran ICE "verify_gimple failed" in gfortran.dg/vect/pr51058-2.f90 since r14-2007

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
Summary|gfortran ICE "verify_gimple |[14 Regression] gfortran
   |failed" in  |ICE "verify_gimple failed"
   |gfortran.dg/vect/pr51058-2. |in
   |f90 |gfortran.dg/vect/pr51058-2.
   ||f90 since r14-2007
   Keywords||testsuite-fail

[Bug tree-optimization/104292] (bool)(bool0 + bool1) should be simplified into bool0 | bool1

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

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

--- Comment #4 from Andrew Pinski  ---
This should do it I think:

(for neeq (ne eq)
 (simplify
  (neeq (plus zero_one_valued_p@0 zero_one_valued_p@1) INTEGER_CST@2)
  (with {
tree_code newcode = ERROR_MARK;
bool notatend = false;
tree cst1 = build_one_cst (type);
wide_int cst = wi::to_wide (@2);
// a + b == 2 -> a & b
// a + b != 2 -> ~(a & b)
if (cst == 2)
  newcode = BIT_AND_EXPR, notatend = neeq == NE_EXPR;
// a + b == 1 -> a ^ b
// a + b != 1 -> ~(a ^ b) -> a == b
else if (cst == 1)
  newcode = BIT_XOR_EXPR, notatend = neeq == NE_EXPR;
// a + b == 0 -> ~(a | b)
// a + b != 0 -> a | b
else if (cst == 0)
  newcode = BIT_IOR_EXPR, notatend = neeq == EQ_EXPR;
   }
  (if (notatend)
   (switch
(if (newcode == BIT_IOR_EXPR)
 (bit_xor (bit_ior @0 @1) { cst1; }))
(if (newcode == BIT_AND_EXPR)
 (bit_xor (bit_and @0 @1) { cst1; }))
(if (newcode == BIT_XOR_EXPR)
 (eq @0 @1)))
   (switch
(if (newcode == BIT_IOR_EXPR)
 (bit_ior @0 @1))
(if (newcode == BIT_AND_EXPR)
 (bit_and @0 @1))
(if (newcode == BIT_XOR_EXPR)
 (bit_xor @0 @1)))
  )
 )
)

[Bug tree-optimization/104292] (bool)(bool0 + bool1) should be simplified into bool0 | bool1

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug tree-optimization/101703] (bool0 + bool1) & 1 and (bool0 + bool1) == 1 can be optimized to bool0 ^ bool1

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-06-23
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

--- Comment #1 from Andrew Pinski  ---
For most see PR 104292 but we need one more:
(simplify
  (bit_and (plus zero_one_valued_p@0 zero_one_valued_p@1) integer_onep)
  (bit_xor @0 @1)))

[Bug tree-optimization/101703] (bool0 + bool1) & 1 and (bool0 + bool1) == 1 can be optimized to bool0 ^ bool1

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

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

--- Comment #2 from Andrew Pinski  ---
bool f(bool a, bool b)
{
int t = a;
int t1 = b;
return (t + t1) & 2;
}
bool f1(bool a, bool b)
{
int t = a;
int t1 = b;
return (t & t1);
}

This is needed too:
```
(simplify
  (ne (bit_and (plus zero_one_valued_p@0 zero_one_valued_p@1) INTEGER_CST@2)
integer_zerop)
  (if (wi::to_wide (@2) == 2)
(convert (bit_and @0 @1))
(if (wi::to_wide (@2) == 1)
 (convert (bit_xor @0 @1)))
  )
)
```

As we don't want to convert `(bool+bool)&2` into `(bool^bool)<<1`

[Bug target/110372] [14 Regression] ICE: insn does not satisfy its constraints: {*movdi_internal} with -mno-sse2

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug middle-end/82259] missed optimization: use LEA to add 1 to flip the low bit when copying before AND with 1

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2021-08-02 00:00:00 |2023-6-22
  Component|rtl-optimization|middle-end

--- Comment #9 from Andrew Pinski  ---
This is an expansion issue not taking into cost of expanding using shifts
rather than test/set.

I am still working in this area and might improve this for GCC 14 but still
deciding on how to get some good infrastructure for the cost modeling ...

[Bug tree-optimization/101703] (bool0 + bool1) & 1 and (bool0 + bool1) == 1 can be optimized to bool0 ^ bool1

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

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

--- Comment #3 from Andrew Pinski  ---
A few more things to optimize:
```
bool minusne(bool a, bool b)
{
  return (a - b) != 1;
}
bool ornot(bool a, bool b)
{
  return !a | b; // or a <= b
}

bool minusne0(bool a, bool b)
{
  return (a - b) != -1;
}
bool ornot0(bool a, bool b)
{
  return a | !b; // or b <= a
}


bool minuseq(bool a, bool b)
{
  return (a - b) == 1;
}
bool andnot(bool a, bool b)
{
  return a & !b; // or b < a
}

bool minuseq0(bool a, bool b)
{
  return (a - b) == -1;
}
bool andnot0(bool a, bool b)
{
  return !a & b; // or a < b
}
```
minusne{,0} should be optimized into ornot{,0}.
minuseq{,0} should be optimized into andnot{,0}.

[Bug target/54089] [SH] Refactor shift patterns

[klepikov.alex+bugs at gmail dot com via Gcc-bugs]

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

--- Comment #92 from Alexander Klepikov  
---
I remembered why I used two different insns - first to eliminate infinite loop
with help of marking insn with attribute, and second because I could not set
attribute when emitting insn from C code. Whe have 'get_attr_*' functions but
we have not 'set_attr_*'.

[Bug tree-optimization/110371] [14 Regression] gfortran ICE "verify_gimple failed" in gfortran.dg/vect/pr51058-2.f90 since r14-2007

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

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

--- Comment #2 from Sam James  ---
Created attachment 55390
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55390&action=edit
pixman-matrix.c.i

I think I've hit the same thing building pixman.

```
# gcc
/var/tmp/portage/x11-libs/pixman-0.42.2/work/pixman-0.42.2-.arm64/./pixman/libpixman-1.so.0.42.2.p/pixman-matrix.c.i
-c -O3
../pixman-0.42.2/pixman/pixman-matrix.c: In function
‘pixman_f_transform_from_pixman_transform’:
../pixman-0.42.2/pixman/pixman-matrix.c:739:1: error: invalid types in nop
conversion
double
int
vect__17.229_49 = (vector(2) double) vect__16.227_44;
../pixman-0.42.2/pixman/pixman-matrix.c:739:1: error: invalid types in nop
conversion
double
int
vect__17.229_51 = (vector(2) double) vect__16.228_46;
during GIMPLE pass: vect
../pixman-0.42.2/pixman/pixman-matrix.c:739:1: internal compiler error:
verify_gimple failed
0xbd2c01f7 verify_gimple_in_cfg(function*, bool, bool)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-cfg.cc:5646
0xbd0ec22f execute_function_todo
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/passes.cc:2098
0xbd0ec91f execute_todo
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/passes.cc:2152
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.
```

I can reduce it if needed, but I assume there's no point given the testsuite
already fails on it.

[Bug target/54089] [SH] Refactor shift patterns

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

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

--- Comment #93 from Oleg Endo  ---
(In reply to Alexander Klepikov from comment #92)
> I remembered why I used two different insns - first to eliminate infinite
> loop with help of marking insn with attribute, and second because I could
> not set attribute when emitting insn from C code. Whe have 'get_attr_*'
> functions but we have not 'set_attr_*'.

Yes, I thought so.  I'll give it a try myself with your patch ... please hold
on.

[Bug tree-optimization/110371] [14 Regression] gfortran ICE "verify_gimple failed" in gfortran.dg/vect/pr51058-2.f90 since r14-2007

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

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

--- Comment #3 from Richard Biener  ---
Looks like NOP_EXPR is used instead of FLOAT_EXPR?