[Bug c++/104669] [11 Regression] ICE in is_function_default_version, at attribs.cc:1219

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

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

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

[Bug target/100643] [11/12/13/14 Regression] ICE in ix86_mangle_function_version_assembler_name, at config/i386/i386-features.c:2809 since r11-7693-g1c7bec8bfbc5457c

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #9 from Andrew Pinski  ---
Dup in the end.

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

[Bug rtl-optimization/84842] [11/12/13/14 Regression] ICE in verify_target_availability, at sel-sched.c:1569

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P2  |P4

[Bug middle-end/106208] [12 Regression] ICE in branch_prob, at profile.cc:1459 since r12-5275-gbcebd05720540e25

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[12/13/14 Regression] ICE   |[12 Regression] ICE in
   |in branch_prob, at  |branch_prob, at
   |profile.cc:1459 since   |profile.cc:1459 since
   |r12-5275-gbcebd05720540e25  |r12-5275-gbcebd05720540e25

--- Comment #7 from Andrew Pinski  ---
>Should we still add these Fortran test cases -- or is in fact 'gfortran' still 
>generating "undesirable" location information? 


The function (_caf_init.0) is a machine generated function and does not really
have any location information associated with it. it is an artifact of
fcoarray=lib registering the coarray at initialization time.

So I am going to say this just needs a testcase, removing the 13/14 regression
marker otherwise.

[Bug rtl-optimization/104447] [11 Regression] ICE: maximum number of LRA assignment passes is achieved (30)

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
Summary|[11/12/13/14 Regression]|[11 Regression] ICE:
   |ICE: maximum number of LRA  |maximum number of LRA
   |assignment passes is|assignment passes is
   |achieved (30)   |achieved (30)

--- Comment #8 from Jeffrey A. Law  ---
Fixed back in the gcc-12 era.  Adjusting regression markers.

[Bug tree-optimization/103725] [11/12 Regression] warning: assuming signed overflow does not occur when simplifying conditional to constant

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
Summary|[11/12/13/14 Regression]|[11/12 Regression] warning:
   |warning: assuming signed|assuming signed overflow
   |overflow does not occur |does not occur when
   |when simplifying|simplifying conditional to
   |conditional to constant |constant

--- Comment #8 from Jeffrey A. Law  ---
Per c#6.

[Bug rtl-optimization/101958] [11/12/13/14 Regression] compiling with "-O2 -fselective-scheduling2 -fno-tree-ch" produce bad result

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P2  |P4

[Bug tree-optimization/100801] [11/12 Regression] Aggressive loop optimizations cause incorrect warning

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
Summary|[11/12/13/14 Regression]|[11/12 Regression]
   |Aggressive loop |Aggressive loop
   |optimizations cause |optimizations cause
   |incorrect warning   |incorrect warning

--- Comment #8 from Jeffrey A. Law  ---
Works with gcc-13 and the trunk.  Adjusting markers.

[Bug target/100623] [11 Regression] wrong code with -Os -fno-dce -fno-defer-pop -fno-forward-propagate -flive-range-shrinkage -fno-rerun-cse-after-loop -mno-push-args since r10-7515-g2c0fa3ecf70d199a

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11 Regression] wrong code
   |wrong code with -Os |with -Os -fno-dce
   |-fno-dce -fno-defer-pop |-fno-defer-pop
   |-fno-forward-propagate  |-fno-forward-propagate
   |-flive-range-shrinkage  |-flive-range-shrinkage
   |-fno-rerun-cse-after-loop   |-fno-rerun-cse-after-loop
   |-mno-push-args since|-mno-push-args since
   |r10-7515-g2c0fa3ecf70d199a  |r10-7515-g2c0fa3ecf70d199a
 CC||law at gcc dot gnu.org

--- Comment #8 from Jeffrey A. Law  ---
Fixed in gcc-12 and newer.  Adjusting regression markers.

[Bug rtl-optimization/100554] [11/12/13/14 Regression] -fcompare-debug failure w/ -Os -fmodulo-sched -fno-tree-loop-optimize

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P2  |P4

[Bug sanitizer/86899] [11/12 regression] TSAN incorrect warning: control reaches end of non-void function

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
Summary|[11/12/13/14 regression]|[11/12 regression] TSAN
   |TSAN incorrect warning: |incorrect warning: control
   |control reaches end of  |reaches end of non-void
   |non-void function   |function

--- Comment #14 from Jeffrey A. Law  ---
Works with gcc-13 and the trunk.  Adjusting regression markers.

[Bug c++/86689] [11/12 Regression] Some combination of SFINAE, overloading, and type deduction showing version inconsistency

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12 Regression] Some
   |Some combination of SFINAE, |combination of SFINAE,
   |overloading, and type   |overloading, and type
   |deduction showing version   |deduction showing version
   |inconsistency   |inconsistency
 CC||law at gcc dot gnu.org

--- Comment #6 from Jeffrey A. Law  ---
Works with gcc-13 and the trunk.  Adjusting regression markers.

[Bug target/110027] [11/12/13/14 regression] Misaligned vector store on detect_stack_use_after_return

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

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

--- Comment #12 from Hongtao Liu  ---
(In reply to Sam James from comment #11)
> Calling it a 11..14 regression as we know 14 is bad and 7.5 is OK, but I
> can't test 11/12 on an avx512 machine right now.

I can't reproduce that with 11/12, but with gcc13 for the case in PR114276.

It looks like the codegen is already wrong in .expand, the offensive part is
mentioned in #c0

>Now, if `__asan_option_detect_stack_use_after_return` is 0, the variable at 
>>%rcx-128 is correctly aligned to 64. However, if it is 1, 
>__asan_stack_malloc_1 >returns something aligned to 64 << 1 (as per 
>https://github.com/gcc->mirror/gcc/blob/master/gcc/asan.cc#L1917) and adding 
>160 results in %rcx-128 >being only aligned to 32. And thus the segfault.


;; Function foo (_Z3foov, funcdef_no=14, decl_uid=3962, cgraph_uid=10,
symbol_order=9)

(note 1 0 37 NOTE_INSN_DELETED)
;; basic block 2, loop depth 0, maybe hot
;;  prev block 0, next block 3, flags: (NEW, REACHABLE, RTL, MODIFIED)
;;  pred:   ENTRY (FALLTHRU)
(note 37 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 37 3 2 (parallel [
(set (reg:DI 105)
(plus:DI (reg/f:DI 19 frame)
(const_int -160 [0xff60])))
(clobber (reg:CC 17 flags))
]) "test1.cc":7:12 247 {*adddi_1}
 (nil))
(insn 3 2 4 2 (set (reg:DI 106)
(reg:DI 105)) "test1.cc":7:12 82 {*movdi_internal}
 (nil))
(insn 4 3 5 2 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/c:SI (symbol_ref:DI
("__asan_option_detect_stack_use_after_return") [flags 0x40]  ) [4
__asan_option_detect_stack_use_after_return+0 S4 A32])
(const_int 0 [0]))) "test1.cc":7:12 7 {*cmpsi_ccno_1}
 (nil))
(jump_insn 5 4 93 2 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 11)
(pc))) "test1.cc":7:12 995 {*jcc}
 (nil)
 -> 11)
;;  succ:   5
;;  3 (FALLTHRU)

;; basic block 3, loop depth 0, maybe hot
;;  prev block 2, next block 4, flags: (NEW, REACHABLE, RTL, MODIFIED)
;;  pred:   2 (FALLTHRU)
(note 93 5 6 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 6 93 7 3 (set (reg:DI 5 di)
(const_int 128 [0x80])) "test1.cc":7:12 82 {*movdi_internal}
 (nil))
(call_insn 7 6 8 3 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:DI ("__asan_stack_malloc_1") [flags 0x41] 
) [0  S1 A8])
(const_int 0 [0]))) "test1.cc":7:12 1013 {*call_value}
 (expr_list:REG_EH_REGION (const_int -2147483648 [0x8000])
(nil))
(expr_list (use (reg:DI 5 di))
(nil)))
(insn 8 7 9 3 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:DI 0 ax)
(const_int 0 [0]))) "test1.cc":7:12 8 {*cmpdi_ccno_1}
 (nil))
(jump_insn 9 8 94 3 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 11)
(pc))) "test1.cc":7:12 995 {*jcc}
 (nil)
 -> 11)
;;  succ:   5
;;  4 (FALLTHRU)
;; basic block 4, loop depth 0, maybe hot
;;  prev block 3, next block 5, flags: (NEW, REACHABLE, RTL, MODIFIED)
;;  pred:   3 (FALLTHRU)
(note 94 9 10 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 10 94 11 4 (set (reg:DI 105)
(reg:DI 0 ax)) "test1.cc":7:12 82 {*movdi_internal}
 (nil))
;;  succ:   5 (FALLTHRU)

[Bug target/100354] [11/12/13/14 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[11/12/13 regression]   |[11/12/13/14 regression]
   |aarch64: non-deligitimized  |aarch64: non-deligitimized
   |UNSPEC UNSPEC_TLS (76)  |UNSPEC UNSPEC_TLS (76)
   |found in variable location  |found in variable location

--- Comment #12 from Andrew Pinski  ---
I am still able to reproduce it on the trunk with `-g -O -fchecking` on
aarch64-linux-gnu built as of last night.

[Bug target/100354] [11/12/13 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[11/12/13/14 regression]|[11/12/13 regression]
   |aarch64: non-deligitimized  |aarch64: non-deligitimized
   |UNSPEC UNSPEC_TLS (76)  |UNSPEC UNSPEC_TLS (76)
   |found in variable location  |found in variable location
 CC||law at gcc dot gnu.org

--- Comment #11 from Jeffrey A. Law  ---
Seems to be working on the trunk.  Removing gcc-14 regression marker.

[Bug rtl-optimization/100533] [11/12/13/14 Regression] aarch64: -fcompare-debug failure with -O -fmodulo-sched

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P2  |P4
 CC||law at gcc dot gnu.org

[Bug middle-end/95351] [11/12/13 Regression] Comparison with NAN optimizes incorrectly with -ffast-math disabled

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||14.0
Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
   |Comparison with NAN |Comparison with NAN
   |optimizes incorrectly with  |optimizes incorrectly with
   |-ffast-math disabled|-ffast-math disabled

--- Comment #6 from Andrew Pinski  ---
Fixed on the trunk will backport in a few days.

[Bug middle-end/95351] [11/12/13/14 Regression] Comparison with NAN optimizes incorrectly with -ffast-math disabled

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

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

--- Comment #5 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:31ce2e993d09dcad1ce139a2848a28de5931056d

commit r14-9422-g31ce2e993d09dcad1ce139a2848a28de5931056d
Author: Andrew Pinski 
Date:   Sun Mar 10 22:17:09 2024 +

Fold: Fix up merge_truthop_with_opposite_arm for NaNs [PR95351]

The problem here is that merge_truthop_with_opposite_arm would
use the type of the result of the comparison rather than the operands
of the comparison to figure out if we are honoring NaNs.
This fixes that oversight and now we get the correct results in this
case.

Committed as obvious after a bootstrap/test on x86_64-linux-gnu.

PR middle-end/95351

gcc/ChangeLog:

* fold-const.cc (merge_truthop_with_opposite_arm): Use
the type of the operands of the comparison and not the type
of the comparison.

gcc/testsuite/ChangeLog:

* gcc.dg/float_opposite_arm-1.c: New test.

Signed-off-by: Andrew Pinski 

[Bug c++/99795] [11/12 Regression] -Wnarrowing/-Woverflow false-negative in constant expression in undeduced context

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12 Regression]
   |-Wnarrowing/-Woverflow  |-Wnarrowing/-Woverflow
   |false-negative in constant  |false-negative in constant
   |expression in undeduced |expression in undeduced
   |context |context
 CC||law at gcc dot gnu.org

--- Comment #8 from Jeffrey A. Law  ---
Works with gcc-13 and the trunk. Adjusting regression markers.

[Bug target/99706] [11 Regression] ICE: maximum number of generated reload insns per insn achieved (90)

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11 Regression] ICE:
   |ICE: maximum number of  |maximum number of generated
   |generated reload insns per  |reload insns per insn
   |insn achieved (90)  |achieved (90)
 CC||law at gcc dot gnu.org

--- Comment #15 from Jeffrey A. Law  ---
Adjusting regression markers per c#13.

[Bug rtl-optimization/99469] [11/12/13/14 Regression] ICE: qsort checking failed with selective scheduling on aarch64

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P2  |P4

[Bug rtl-optimization/99332] [11/12/13/14 Regression] ICE:in reset_sched_cycles_in_current_ebb, at sel-sched.c:7147 with -fprofile-generate -O3 -fselective-scheduling -fselective-scheduling2 -fsel-sch

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P2  |P4

[Bug rtl-optimization/99199] [11 Regression] Very large boolean expression leads to quite a few return statements

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11 Regression] Very large
   |Very large boolean  |boolean expression leads to
   |expression leads to quite a |quite a few return
   |few return statements   |statements

--- Comment #12 from Jeffrey A. Law  ---
Fixed for gcc-12, so adjusting the regression markers.

[Bug rtl-optimization/99015] [11/12/13 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE:
   |ICE: Max. number of |Max. number of generated
   |generated reload insns per  |reload insns per insn is
   |insn is achieved (90)   |achieved (90)
 CC||law at gcc dot gnu.org

--- Comment #6 from Jeffrey A. Law  ---
Works on the trunk, gcc-13 still fails.  Removing gcc-14 regression marker.

[Bug c++/98662] [11/12/13 Regression] checking ICE in friend_accessible_p since r227023

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
   |checking ICE in |checking ICE in
   |friend_accessible_p since   |friend_accessible_p since
   |r227023 |r227023

--- Comment #9 from Jeffrey A. Law  ---
The trunk no longer ICEs.  Also note that it's rejected by clang++.  Removing
gcc-14 regression marker.

[Bug target/111822] [12/13/14 Regression] during RTL pass: lr_shrinkage ICE: in operator[], at vec.h:910 with -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions since r12-5301-g04520645038

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

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

--- Comment #16 from Hongtao Liu  ---
(In reply to Uroš Bizjak from comment #11)
> (In reply to Richard Biener from comment #10)
> > The easiest fix would be to refuse applying STV to a insn that
> > can_throw_internal () (that's an insn that has associated EH info).  
> > Updating
> > in this case would require splitting the BB or at least moving the now
> > no longer throwing insn to the next block (along the fallthru edge).
> 
> This would be simply:
> 
> --cut here--
> diff --git a/gcc/config/i386/i386-features.cc
> b/gcc/config/i386/i386-features.cc
> index 1de2a07ed75..90acb33db49 100644
> --- a/gcc/config/i386/i386-features.cc
> +++ b/gcc/config/i386/i386-features.cc
> @@ -437,6 +437,10 @@ scalar_chain::add_insn (bitmap candidates, unsigned int
> insn_uid,
>&& !HARD_REGISTER_P (SET_DEST (def_set)))
>  bitmap_set_bit (defs, REGNO (SET_DEST (def_set)));
>  
> +  if (cfun->can_throw_non_call_exceptions
> +  && can_throw_internal (insn))
> +return false;
> +
>/* ???  The following is quadratic since analyze_register_chain
>   iterates over all refs to look for dual-mode regs.  Instead this
>   should be done separately for all regs mentioned in the chain once.  */
> --cut here--
> 
> But I think, we could do better. Adding CC.

It looks like the similar issue we have solved in PR89650 with
r9-6543-g12fb7712a8a20f. We manually split the block after insn.

[Bug middle-end/67739] name clash between builtin functions and local variables when optimization is on

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

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

--- Comment #6 from Andrew Pinski  ---
Created attachment 57664
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57664=edit
Better testcase

With the original testcase, the stores to sincosf were optimized away and no
longer did the sin->sinf transformation so do it manually.

[Bug middle-end/106190] [10 Regression] ICE in expand_builtin_eh_common with -fnon-call-exceptions -fsanitize=address,undefined -fno-sanitize-recover=all

[chenxiaolong at loongson dot cn via Gcc-bugs]

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

chenxiaolong  changed:

   What|Removed |Added

 CC||chenxiaolong at loongson dot cn

--- Comment #17 from chenxiaolong  ---
(In reply to Andrew Pinski from comment #1)
> int
> main ()
> {
>   int a;
>   int *b[1];
>   int c[10];
>   int d[1][1];
>   for (a = 0; a < 1; a++)
> d[1][a] = 0;
>   return 0;
> }

[Bug middle-end/41639] __sync synchronisation primitives take unsigned as input and output values.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
>(tested on SH with a non-linux, in house runtime, implementation)


The bug is in your runtime implementation I think.

Which has a mismatch in the return type vs what GCC internals think these
should be.

Note libgcc/sync.c does:
```
#if SIZE == 1 && __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1

typedef unsigned int UQItype __attribute__((mode (QI)));
DEFINE (FN, 1, UQItype)

#elif SIZE == 2 && __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2

typedef unsigned int UHItype __attribute__((mode (HI)));
DEFINE (FN, 2, UHItype)

#elif SIZE == 4 && __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4

typedef unsigned int USItype __attribute__((mode (SI)));
DEFINE (FN, 4, USItype)

#elif SIZE == 8 && __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8

typedef unsigned int UDItype __attribute__((mode (DI)));
DEFINE (FN, 8, UDItype)

#elif SIZE == 16 && __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16

typedef unsigned int UOItype __attribute__((mode (OI)));
DEFINE (FN, 8, UOItype)


```

Which matches the internals of GCC.

[Bug middle-end/41639] __sync synchronisation primitives take unsigned as input and output values.

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||sh*-*

--- Comment #3 from Andrew Pinski  ---
So I looked into the history here and the code was correct even when this bug
was fixed.

Basically resolve_overloaded_builtin will resolve __sync_sub_and_fetch into
__sync_sub_and_fetch_1 and add a cast for the return value to the same type as
the first argument this is done in sync_resolve_return.


48ae6c138ca3 (Richard Henderson 2005-04-14 16:37:47 -0700 8801)
result = build_function_call (new_function, params);
48ae6c138ca3 (Richard Henderson 2005-04-14 16:37:47 -0700 8802)
if (orig_code != BUILT_IN_BOOL_COMPARE_AND_SWAP_N
48ae6c138ca3 (Richard Henderson 2005-04-14 16:37:47 -0700 8803)
&& orig_code != BUILT_IN_LOCK_RELEASE_N)
48ae6c138ca3 (Richard Henderson 2005-04-14 16:37:47 -0700 8804)
  result = sync_resolve_return (params, result);


So unless there is something wrong with the way sh implements these functions
in libgcc there is no issue in the middle-end.

[Bug libstdc++/114298] std::lazy_split_view constructor is currently not explicit

[michael.kenzel at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Michael Kenzel  ---
I just learned that this was apparently only added in C++23 (P2711 [1]), so I
was likely a bit too quick to open this issue…

[1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2711r1.html

[Bug middle-end/52907] Underflowing floating point expressions wrongly folded to zero

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2012-04-10 00:00:00 |2024-3-10

--- Comment #3 from Andrew Pinski  ---
Still happens.

[Bug c++/98356] [11/12/13 Regression] ICE in cp_parser_dot_deref_incomplete, at cp/parser.c:7899 since r9-4841-g2139fd74f31449c0

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE
   |ICE in  |in
   |cp_parser_dot_deref_incompl |cp_parser_dot_deref_incompl
   |ete, at cp/parser.c:7899|ete, at cp/parser.c:7899
   |since   |since
   |r9-4841-g2139fd74f31449c0   |r9-4841-g2139fd74f31449c0
 CC||law at gcc dot gnu.org

--- Comment #9 from Jeffrey A. Law  ---
Fixed for gcc-14.  Adjusting regression markers.

[Bug rtl-optimization/97972] [11/12/13/14 Regression] ICE in moving_insn_creates_bookkeeping_block_p, at sel-sched.c:2031 since r9-2064-gc4c5ad1d6d1e1e1f

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P2  |P4

[Bug middle-end/97968] [11 Regression] Unnecessary mov instruction with comparison and cmov

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11 Regression] Unnecessary
   |Unnecessary mov instruction |mov instruction with
   |with comparison and cmov|comparison and cmov
 CC||law at gcc dot gnu.org

--- Comment #8 from Jeffrey A. Law  ---
Per c#3 and c#7.

[Bug target/97140] [11/12/13/14 Regression] ICE in error: unable to generate reloads for since r10-400-gecfdb16c54ad06ac

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Jeffrey A. Law  ---
Per c#4 and c#6.

[Bug middle-end/96564] [11/12/13/14 Regression] New maybe use of uninitialized variable warning since r11-959

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #12 from Jeffrey A. Law  ---
So I think we could solve this with a bit of help from the alias oracle.  We
have  the routine ptrs_compare_unequal, but points-to-null is going to get in
the way.

I think VRP and DOM have enough information to rule out NULL for both objects
in question.  So if we could query the points-to information, ignoring NULL
then we could likely solve this particular bug.

Essentially VRP or DOM would prove NULL isn't in the set of possible values at
the comparison point.  Then we query the alias information ignoring NULL. 
Voila we compute a static result for the comparison of the two pointers and the
problematical block becomes unreachable and the bogus warning goes away.

Richi, any thoughts in viability of such an API?

[Bug tree-optimization/114301] gimple_can_duplicate_bb_p check for returns twice can be moved to the check of the last statement

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-10
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Noticed while looking PR 97333 .
Mine for GCC 15.

[Bug tree-optimization/114301] New: gimple_can_duplicate_bb_p check for returns twice can be moved to the check of the last statement

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

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

Bug ID: 114301
   Summary: gimple_can_duplicate_bb_p check for returns twice can
be moved to the check of the last statement
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: compile-time-hog, internal-improvement
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: pinskia at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

It is the case that the returns twice function will always be the last
statement of the BB so the check for that can be moved up to the check of the
last statement part. This is a small optimization as gimple_call_flags (which
calls flags_from_decl_or_type) can call special_function_p and
special_function_p does string comparisons in the end. So removing as many
calls to gimple_call_flags  can speed up GCC slightly.

[Bug ipa/109817] internal error in ICF pass on Ada interfaces

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

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

Eric Botcazou  changed:

   What|Removed |Added

Summary|[14 regression] internal|internal error in ICF pass
   |error in ICF pass on Ada|on Ada interfaces
   |interfaces  |

--- Comment #4 from Eric Botcazou  ---
The Ada front-end has generated null thunks, i.e. mere forwarders, for the last
couple of decades.  Nothing wrong with that, but this is clearly inefficient.

Not a (recent) regression in any case.

[Bug tree-optimization/97333] [meta-bug] [gimple_can_duplicate_bb_p == false, tree-ssa-threadupdate] ICE in duplicate_block, at cfghooks.c:1093

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |14.0
 Status|NEW |RESOLVED

--- Comment #9 from Andrew Pinski  ---
I ran a bootstrap and test with gimple_can_duplicate_bb_p returning false
always. The only ICE was in the vectorizer while vectorizing OpenMP reduction
code. I tried to reproduce that ICE without the patch and could not get the
vectorizer to fail so closing as fixed.

[Bug middle-end/95072] [11/12/13 Regression] -Warray-bounds false positive with flexible array bounds (regression from GCC 9)

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
   |-Warray-bounds false|-Warray-bounds false
   |positive with flexible  |positive with flexible
   |array bounds (regression|array bounds (regression
   |from GCC 9) |from GCC 9)
 CC||law at gcc dot gnu.org

--- Comment #7 from Jeffrey A. Law  ---
No longer triggers on the trunk.  Not sure about gcc-13.

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

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

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

Bug 94335 Summary: [11/12/13/14 Regression] False positive -Wstringop-overflow 
warning with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335

   What|Removed |Added

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

[Bug tree-optimization/94335] [11/12/13/14 Regression] False positive -Wstringop-overflow warning with -O2

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #17 from Jeffrey A. Law  ---
Per c#12, c#13, c#14.

[Bug debug/113777] ICE: in add_child_die_after, at dwarf2out.cc:5785 with -g -fsso-struct and __attribute__((__hardbool__))

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

[Bug target/93930] [11/12/13/14 Regression] Unnecessary broadcast instructions for AVX512

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Jeffrey A. Law  ---
Per c#9.

[Bug debug/113777] ICE: in add_child_die_after, at dwarf2out.cc:5785 with -g -fsso-struct=big-endian and __attribute__((__hardbool__))

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

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

--- Comment #3 from Eric Botcazou  ---
> This works with __attribute__((may_alias)) though, so what's special with
> __attribute__((__hardbool__)) ?

Replying myself: this creates an enumeration type under the hood, so this is a
duplicate of PR debug/113519.

[Bug c/93631] [11/12/13/14 Regression] ICE on an invalid strcmp call in gimple_call_arg, at gimple.h:3258

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||law at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #13 from Jeffrey A. Law  ---
Per c#10.

[Bug ada/114300] New: Bug box when compiling a program that instantiates a package with a nested ghost package.

[d.van.raaij at gmail dot com via Gcc-bugs]

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

Bug ID: 114300
   Summary: Bug box when compiling a program that instantiates a
package with a nested ghost package.
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.van.raaij at gmail dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

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

The code included in this report generates a bug box upon compilation. The code
is an isolated reproducer of the bug box that appears when compiling a program
that instantiates SPARKlib package "SPARK.Higher_Order.Fold.Sum".

Issue found on 14.0.1 (20240228), but occurs on 13.2.1 as well.

*** Compiler output ***

$ gcc -c reproducer.adb
+===GNAT BUG DETECTED==+
| 14.0.1 20240228 (Red Hat 14.0.1-0) (x86_64-redhat-linux) GCC error:  |
| in gnat_to_gnu_entity, at ada/gcc-interface/decl.cc:377  |
| Error detected at reproducer.adb:33:42   |
| Compiling reproducer.adb |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

reproducer.adb

gcc: internal compiler error: Segmentation fault signal terminated program
gnat1
Please submit a full bug report, with preprocessed source (by using
-freport-bug).

*** Compiler version ***

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/14/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu
--enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-14.0.1-20240228/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none,amdgcn-amdhsa --enable-offload-defaulted
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240228 (Red Hat 14.0.1-0) (GCC)

[Bug middle-end/95351] [11/12/13/14 Regression] Comparison with NAN optimizes incorrectly with -ffast-math disabled

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
I have a patch to fix this:
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 43105d20be3..299c22bf391 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -6420,7 +6420,6 @@ static tree
 merge_truthop_with_opposite_arm (location_t loc, tree op, tree cmpop,
 bool rhs_only)
 {
-  tree type = TREE_TYPE (cmpop);
   enum tree_code code = TREE_CODE (cmpop);
   enum tree_code truthop_code = TREE_CODE (op);
   tree lhs = TREE_OPERAND (op, 0);
@@ -6436,6 +6435,8 @@ merge_truthop_with_opposite_arm (location_t loc, tree op,
tree cmpop,
   if (TREE_CODE_CLASS (code) != tcc_comparison)
 return NULL_TREE;

+  tree type = TREE_TYPE (TREE_OPERAND (cmpop, 0));
+
   if (rhs_code == truthop_code)
 {
   tree newrhs = merge_truthop_with_opposite_arm (loc, rhs, cmpop,
rhs_only);

[Bug d/113081] static linking does not work

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #3 from Iain Buclaw  ---
(In reply to Iain Buclaw from comment #2)

> If I recall correctly, this trick is not guaranteed to work (for a
> drtbegin.o and drtend.o object), as there really no control over where in
> the TLS section these variables will land.
> 
> ```
> #ifdef DRT_BEGIN
> _Thread_local __SIZE_TYPE__ __tls_start = 3;
> #endif
> 
> #ifdef DRT_END
> _Thread_local __SIZE_TYPE__ __tls_end;
> #endif
> ```
Both of these rely on the default linker script of:
 .tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
 .tbss  : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
to group the sections in that order.

According to some old commit notes of mine for gdc in 2013, ld can reorder
.tdata after .tdata.*, despite what the linker script says.

[Bug d/113081] static linking does not work

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #2 from Iain Buclaw  ---
It could be moved to drtstuff.o to avoid it being in the library, but unless
there's an equivalent function available there'll be crashes caused by the GC
free'ing live objects as it did not scan all TLS variables for the executing
thread.

If I recall correctly, this trick is not guaranteed to work (for a drtbegin.o
and drtend.o object), as there really no control over where in the TLS section
these variables will land.

```
#ifdef DRT_BEGIN
_Thread_local __SIZE_TYPE__ __tls_start = 3;
#endif

#ifdef DRT_END
_Thread_local __SIZE_TYPE__ __tls_end;
#endif
```

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[dilyan.palauzov at aegee dot org via Gcc-bugs]

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

--- Comment #34 from Дилян Палаузов  ---
Created attachment 57662
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57662=edit
Proposed patch

This fixes the problem.

I do not understand the build system to say, that this is the best approach, so
if there are questions I might or might not be able to answer them.

I also do not know, if 2×`maybe-`  is necessary.

[Bug tree-optimization/114293] [14 Regression] ICE: in verify_range, at value-range.cc:1132 at -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-03-10
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Better reduced testcase:
```
__SIZE_TYPE__ bar (int b)
{
  __builtin_memset (, 5, -1);
  return __builtin_strlen ((char *) );
}
```


Confirmed.

[Bug tree-optimization/114293] [14 Regression] ICE: in verify_range, at value-range.cc:1132 at -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug d/112290] self-referencing `in` parameter with `-fpreview=in` causes ICE

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #4 from Iain Buclaw  ---
Fix committed and backported.

[Bug d/112285] `in` class parameter with `gdc -fpreview=in` causes ICE

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #4 from Iain Buclaw  ---
Fix committed and backported.

[Bug d/112285] `in` class parameter with `gdc -fpreview=in` causes ICE

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Iain Buclaw
:

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

commit r12-10202-gec3a01024dd86c51d1e563df9395123765cf548d
Author: Iain Buclaw 
Date:   Sun Mar 10 17:49:06 2024 +0100

d: Fix -fpreview=in ICEs with forward referenced parameter [PR112285]

The way that the target hook preferPassByRef is implemented, it relied
on the GCC "back-end" tree type to determine whether or not to use `ref'
ABI for D `in' parameters; e.g: prefer by value if it is expected that
the target will pass the type around in registers.

Building the GCC tree type depends on the AST type being complete - all
semantic processing is finished - but as this hook is called from the
front-end, this will not be the case for forward referenced or
self-referencing types.

The consensus in upstream is that `in' parameters should always be
implicitly `ref', but as the front-end does not yet support all types
being rvalue references, limit this just static arrays and structs.

PR d/112285
PR d/112290

gcc/d/ChangeLog:

* d-target.cc (Target::preferPassByRef): Return true for all static
array and struct types.

gcc/testsuite/ChangeLog:

* gdc.dg/pr112285.d: New test.
* gdc.dg/pr112290.d: New test.
* gdc.test/compilable/previewin.d: Adjust testcase.

(cherry picked from commit 025ff57c19efae6c8d76df6b93e7d9827017acc9)

[Bug d/112290] self-referencing `in` parameter with `-fpreview=in` causes ICE

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Iain Buclaw
:

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

commit r12-10202-gec3a01024dd86c51d1e563df9395123765cf548d
Author: Iain Buclaw 
Date:   Sun Mar 10 17:49:06 2024 +0100

d: Fix -fpreview=in ICEs with forward referenced parameter [PR112285]

The way that the target hook preferPassByRef is implemented, it relied
on the GCC "back-end" tree type to determine whether or not to use `ref'
ABI for D `in' parameters; e.g: prefer by value if it is expected that
the target will pass the type around in registers.

Building the GCC tree type depends on the AST type being complete - all
semantic processing is finished - but as this hook is called from the
front-end, this will not be the case for forward referenced or
self-referencing types.

The consensus in upstream is that `in' parameters should always be
implicitly `ref', but as the front-end does not yet support all types
being rvalue references, limit this just static arrays and structs.

PR d/112285
PR d/112290

gcc/d/ChangeLog:

* d-target.cc (Target::preferPassByRef): Return true for all static
array and struct types.

gcc/testsuite/ChangeLog:

* gdc.dg/pr112285.d: New test.
* gdc.dg/pr112290.d: New test.
* gdc.test/compilable/previewin.d: Adjust testcase.

(cherry picked from commit 025ff57c19efae6c8d76df6b93e7d9827017acc9)

[Bug middle-end/114299] ICE: SIGSEGV: in dyn_cast (is-a.h:282) with -mgeneral-regs-only and __bf16

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
  Component|target  |middle-end

--- Comment #1 from Andrew Pinski  ---
There is an error_mark going through gimple_simplify which should have not
happened ...

[Bug tree-optimization/114299] New: ICE: SIGSEGV: in dyn_cast (is-a.h:282) with -mgeneral-regs-only and __bf16

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114299
   Summary: ICE: SIGSEGV: in dyn_cast
(is-a.h:282) with -mgeneral-regs-only and __bf16
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: error-recovery
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -mgeneral-regs-only testcase.c  -wrapper valgrind,-q
testcase.c: In function 'foo':
testcase.c:10:3: error: invalid conversion from type '__bf16' without option
'-msse2'
   10 |   return __builtin_shufflevector(v, a, 1, 2, 5, 0, 1, 6, 6, 4);
  |   ^~
testcase.c:8:1: error: SSE register return with SSE disabled
8 | foo(void)
  | ^~~
==9563== Invalid read of size 1
==9563==at 0x1AAA648: dyn_cast (is-a.h:282)
==9563==by 0x1AAA648: gimple_simplify_VEC_PERM_EXPR(gimple_match_op*,
gimple**, tree_node* (*)(tree_node*), code_helper, tree_node*, tree_node*,
tree_node*, tree_node*) (gimple-match-4.cc:17752)
==9563==by 0x1C8F915: gimple_resimplify3(gimple**, gimple_match_op*,
tree_node* (*)(tree_node*)) (gimple-match-exports.cc:1107)
==9563==by 0x1C90EF7: gimple_simplify(gimple*, gimple_match_op*, gimple**,
tree_node* (*)(tree_node*), tree_node* (*)(tree_node*))
(gimple-match-exports.cc:898)
==9563==by 0x117063C: fold_stmt_1(gimple_stmt_iterator*, bool, tree_node*
(*)(tree_node*)) (gimple-fold.cc:6362)
==9563==by 0x11C14A0: gimplify_modify_expr(tree_node**, gimple**, gimple**,
bool) (gimplify.cc:6582)
==9563==by 0x11AABE9: gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int) (gimplify.cc:17786)
==9563==by 0x11AD2D6: gimplify_stmt(tree_node**, gimple**)
(gimplify.cc:7480)
==9563==by 0x11BB6A0: gimplify_and_add (gimplify.cc:493)
==9563==by 0x11BB6A0: gimplify_return_expr(tree_node*, gimple**)
(gimplify.cc:1883)
==9563==by 0x11AB9CA: gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int) (gimplify.cc:18048)
==9563==by 0x11AD2D6: gimplify_stmt(tree_node**, gimple**)
(gimplify.cc:7480)
==9563==by 0x11AE3D9: gimplify_bind_expr(tree_node**, gimple**)
(gimplify.cc:1614)
==9563==by 0x11AB957: gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int) (gimplify.cc:17987)
==9563==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==9563== 
testcase.c:10:10: internal compiler error: Segmentation fault
   10 |   return __builtin_shufflevector(v, a, 1, 2, 5, 0, 1, 6, 6, 4);
  |  ^
0x151311f crash_signal
/repo/gcc-trunk/gcc/toplev.cc:319
0x1aaa648 gassign* dyn_cast(gimple*)
/repo/gcc-trunk/gcc/is-a.h:282
0x1aaa648 gimple_simplify_VEC_PERM_EXPR(gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), code_helper, tree_node*, tree_node*, tree_node*, tree_node*)
/repo/build-gcc-trunk-amd64/gcc/gimple-match-4.cc:17752
0x1c8f915 gimple_resimplify3
/repo/gcc-trunk/gcc/gimple-match-exports.cc:1107
0x1c90ef7 gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
/repo/gcc-trunk/gcc/gimple-match-exports.cc:898
0x117063c fold_stmt_1
/repo/gcc-trunk/gcc/gimple-fold.cc:6362
0x11c14a0 gimplify_modify_expr
/repo/gcc-trunk/gcc/gimplify.cc:6582
0x11aabe9 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:17786
0x11ad2d6 gimplify_stmt(tree_node**, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:7480
0x11bb6a0 gimplify_and_add(tree_node*, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:493
0x11bb6a0 gimplify_return_expr
/repo/gcc-trunk/gcc/gimplify.cc:1883
0x11ab9ca gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:18048
0x11ad2d6 gimplify_stmt(tree_node**, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:7480
0x11ae3d9 gimplify_bind_expr
/repo/gcc-trunk/gcc/gimplify.cc:1614
0x11ab957 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:17987
0x11c2574 gimplify_stmt(tree_node**, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:7480
0x11c2574 gimplify_body(tree_node*, bool)
/repo/gcc-trunk/gcc/gimplify.cc:19053
0x11c299a gimplify_function_tree(tree_node*)
/repo/gcc-trunk/gcc/gimplify.cc:19252
0xfd0ce7 cgraph_node::analyze()
/repo/gcc-trunk/gcc/cgraphunit.cc:687
0xfd3607 analyze_functions
/repo/gcc-trunk/gcc/cgraphunit.cc:1251
Please submit a full bug report, with preprocessed 

[Bug d/112285] `in` class parameter with `gdc -fpreview=in` causes ICE

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

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

--- Comment #2 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:025ff57c19efae6c8d76df6b93e7d9827017acc9

commit r13-8415-g025ff57c19efae6c8d76df6b93e7d9827017acc9
Author: Iain Buclaw 
Date:   Sun Mar 10 17:49:06 2024 +0100

d: Fix -fpreview=in ICEs with forward referenced parameter [PR112285]

The way that the target hook preferPassByRef is implemented, it relied
on the GCC "back-end" tree type to determine whether or not to use `ref'
ABI for D `in' parameters; e.g: prefer by value if it is expected that
the target will pass the type around in registers.

Building the GCC tree type depends on the AST type being complete - all
semantic processing is finished - but as this hook is called from the
front-end, this will not be the case for forward referenced or
self-referencing types.

The consensus in upstream is that `in' parameters should always be
implicitly `ref', but as the front-end does not yet support all types
being rvalue references, limit this just static arrays and structs.

PR d/112285
PR d/112290

gcc/d/ChangeLog:

* d-target.cc (Target::preferPassByRef): Return true for all static
array and struct types.

gcc/testsuite/ChangeLog:

* gdc.dg/pr112285.d: New test.
* gdc.dg/pr112290.d: New test.
* gdc.test/compilable/previewin.d: Adjust testcase.

(cherry picked from commit a84b98c62d90bf9e8b01038f624a62725e6a44db)

[Bug d/112290] self-referencing `in` parameter with `-fpreview=in` causes ICE

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

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

--- Comment #2 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:025ff57c19efae6c8d76df6b93e7d9827017acc9

commit r13-8415-g025ff57c19efae6c8d76df6b93e7d9827017acc9
Author: Iain Buclaw 
Date:   Sun Mar 10 17:49:06 2024 +0100

d: Fix -fpreview=in ICEs with forward referenced parameter [PR112285]

The way that the target hook preferPassByRef is implemented, it relied
on the GCC "back-end" tree type to determine whether or not to use `ref'
ABI for D `in' parameters; e.g: prefer by value if it is expected that
the target will pass the type around in registers.

Building the GCC tree type depends on the AST type being complete - all
semantic processing is finished - but as this hook is called from the
front-end, this will not be the case for forward referenced or
self-referencing types.

The consensus in upstream is that `in' parameters should always be
implicitly `ref', but as the front-end does not yet support all types
being rvalue references, limit this just static arrays and structs.

PR d/112285
PR d/112290

gcc/d/ChangeLog:

* d-target.cc (Target::preferPassByRef): Return true for all static
array and struct types.

gcc/testsuite/ChangeLog:

* gdc.dg/pr112285.d: New test.
* gdc.dg/pr112290.d: New test.
* gdc.test/compilable/previewin.d: Adjust testcase.

(cherry picked from commit a84b98c62d90bf9e8b01038f624a62725e6a44db)

[Bug tree-optimization/114297] [14 Regression] Yet more problems with "definition in block does not dominate use in block"

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-03-10
 Status|UNCONFIRMED |NEW
 Target|x86_64  |x86_64 aarch64

--- Comment #1 from Andrew Pinski  ---
Reduced testcase:
```

void h() __attribute__((__noreturn__));
struct Extremes {
  int w;
  int h;
};
struct Extremes *array;
int f(int num, int size1)
{
  int sw = 0, sh = 0;
  for (int i = 0; i < size1; ++i)
  {
if (num - i == 0)
  h();
sw += array[i].w;
sh += array[i].h;
  }
  return (sw) +  (sh);
}
```

Also ICEs on aarch64 with just -O3.

[Bug tree-optimization/114297] [14 Regression] Yet more problems with "definition in block does not dominate use in block"

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Yet more problems with  |[14 Regression] Yet more
   |"definition in block does   |problems with "definition
   |not dominate use in block"  |in block does not dominate
   ||use in block"
   Target Milestone|--- |14.0
 Target||x86_64

[Bug d/112285] `in` class parameter with `gdc -fpreview=in` causes ICE

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Iain Buclaw :

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

commit r14-9420-ga84b98c62d90bf9e8b01038f624a62725e6a44db
Author: Iain Buclaw 
Date:   Sun Mar 10 17:49:06 2024 +0100

d: Fix -fpreview=in ICEs with forward referenced parameter [PR112285]

The way that the target hook preferPassByRef is implemented, it relied
on the GCC "back-end" tree type to determine whether or not to use `ref'
ABI for D `in' parameters; e.g: prefer by value if it is expected that
the target will pass the type around in registers.

Building the GCC tree type depends on the AST type being complete - all
semantic processing is finished - but as this hook is called from the
front-end, this will not be the case for forward referenced or
self-referencing types.

The consensus in upstream is that `in' parameters should always be
implicitly `ref', but as the front-end does not yet support all types
being rvalue references, limit this just static arrays and structs.

PR d/112285
PR d/112290

gcc/d/ChangeLog:

* d-target.cc (Target::preferPassByRef): Return true for all static
array and struct types.

gcc/testsuite/ChangeLog:

* gdc.dg/pr112285.d: New test.
* gdc.dg/pr112290.d: New test.

[Bug d/112290] self-referencing `in` parameter with `-fpreview=in` causes ICE

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Iain Buclaw :

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

commit r14-9420-ga84b98c62d90bf9e8b01038f624a62725e6a44db
Author: Iain Buclaw 
Date:   Sun Mar 10 17:49:06 2024 +0100

d: Fix -fpreview=in ICEs with forward referenced parameter [PR112285]

The way that the target hook preferPassByRef is implemented, it relied
on the GCC "back-end" tree type to determine whether or not to use `ref'
ABI for D `in' parameters; e.g: prefer by value if it is expected that
the target will pass the type around in registers.

Building the GCC tree type depends on the AST type being complete - all
semantic processing is finished - but as this hook is called from the
front-end, this will not be the case for forward referenced or
self-referencing types.

The consensus in upstream is that `in' parameters should always be
implicitly `ref', but as the front-end does not yet support all types
being rvalue references, limit this just static arrays and structs.

PR d/112285
PR d/112290

gcc/d/ChangeLog:

* d-target.cc (Target::preferPassByRef): Return true for all static
array and struct types.

gcc/testsuite/ChangeLog:

* gdc.dg/pr112285.d: New test.
* gdc.dg/pr112290.d: New test.

[Bug tree-optimization/110199] [12/13/14 Regression] Missing VRP transformation with MIN_EXPR and known relation

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Jeff Law :

https://gcc.gnu.org/g:8fe27ed193d60f6cd8b34761858a720c95eabbdb

commit r14-9419-g8fe27ed193d60f6cd8b34761858a720c95eabbdb
Author: jlaw 
Date:   Sun Mar 10 11:58:00 2024 -0600

[committed] [PR tree-optimization/110199] Simplify MIN/MAX more often

So as I mentioned in the BZ, the case of

t = MIN_EXPR (A, B)

where we know something about the relationship between A and B can be
trivially
handled by some existing code in DOM.  That existing code would simplify
when A
== B.  But by testing GE and LE instead of EQ we can cover more cases with
minimal effort.  When applicable the MIN/MAX turns into a simple copy.

I made one other change.  We have other binary operations that we simplify
when
we know something about the relationship between the operands.  That code
was
not canonicalizing the order of operands when building the expression to
lookup
in the hash tables to discover that relationship.  Since those paths are
only
testing for equality, we can trivially reverse them and not have to worry
about
changing codes or anything like that.  So extremely safe and avoids having
to
come back and fix that code to match the MIN_EXPR/MAX_EXPR case later.

Bootstrapped on x86 and also tested on the crosses.  I briefly thought
there
was an sh regression, but that was actually the recent fwprop changes
twiddling
code generation for one test.

PR tree-optimization/110199
gcc/
* tree-ssa-scopedtables.cc
(avail_exprs_stack::simplify_binary_operation): Generalize handling
of MIN_EXPR/MAX_EXPR to allow additional simplifications. 
Canonicalize
comparison operands for other cases.

gcc/testsuite

* gcc.dg/tree-ssa/minmax-27.c: New test.
* gcc.dg/tree-ssa/minmax-28.c: New test.

[Bug libfortran/93727] Fortran 2018: EX edit descriptor

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

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

--- Comment #7 from Jerry DeLisle  ---
(In reply to Thomas Henlich from comment #6)
--- snip ---
> Just some thoughts:
> 
> Have you tried "%LA" for long double?
> 
> Have you tried quadmath_snprintf
> (https://gcc.gnu.org/onlinedocs/libquadmath/quadmath_005fsnprintf.html) with
> "%QA" for quad precision?

That was the hint I needed.

#include 
int main()
  {
 float x =   1.0f / 3.0f;
 double y =  1.0l / 3.0l;
 long double z = 1.0L / 3.0L;
 printf("   FLOAT: %.18A\n", x);
 printf("  DOUBLE: %.18lA\n", y);
 printf("LONG DBL: %.18LA\n", z);
 printf("  123456789012345678901234567890\n");
 printf("   FLOAT: %.20f\n", x);
 printf("  DOUBLE: %.20lf\n", y);
 printf("LONG DBL: %.20Lf\n", z);
  }

$ gcc hexfloat.c 
$ ./a.out 
   FLOAT: 0X1.56P-2
  DOUBLE: 0X1.50P-2
LONG DBL: 0XA.AAB000P-5
  123456789012345678901234567890
   FLOAT: 0.3334326744079590
  DOUBLE: 0.1483
LONG DBL: 0.3334

I will check the libqudmath version as well.

Thanks.

[Bug c++/114298] New: std::lazy_split_view constructor is currently not explicit

[michael.kenzel at gmail dot com via Gcc-bugs]

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

Bug ID: 114298
   Summary: std::lazy_split_view constructor is currently not
explicit
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michael.kenzel at gmail dot com
  Target Milestone: ---

[range.lazy.split.view][1] specifies the following constructor

constexpr explicit lazy_split_view(V base, Pattern pattern);

However, libstdc++ seems to currently be missing the explicit:
https://github.com/gcc-mirror/gcc/blob/993c6de642ffeb2867edbe80ff2a72c0a2eb604e/libstdc%2B%2B-v3/include/std/ranges#L3589-L3592

[1]: https://eel.is/c++draft/range.lazy.split.view

[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #13 from dave.anglin at bell dot net ---
On 2024-03-10 12:15 a.m., law at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288
>
> --- Comment #12 from Jeffrey A. Law  ---
> Aren't we compiling for PA2.0?  If so, shouldn't we have a full 14 bit offset
> support, even when a load/store hits the FP register file (feel free to 
> correct
> me if I'm wrong, it's only been 20 years since I worked on this stuff ;-)
Unfortunately, the PA2.0 relocation for 14-bit offsets in floating-point loads
and stores is broken
and can't be used on linux.  Works fine on hpux.

Needs to  be fixed.
>
> So I don't really see why the offsets are an issue here.
At this time, we are limited to 5-bit offsets for floating-point loads and
stores.
>
>
> If we were compiling for PA1.0/PA1.1, then yes, there's a real issue, but it's
> with allowing the larger offsets as a legitimate address.  That's lying to the
> compiler, reload in particular and as I said, it's ultimately going to 
> backfire
> -- even with the workaround since you're going to have DImode loads/stores to
> the FP register file due to xmpyu or potentially even memcpy and friends.  I
> already tried what you're doing years ago.  It's doomed to failure.
>
> You might think this is a reload problem.  But I'm far from convinced.  It
> smells much more like a PA backend issue to me.
I think the problem is with pa_secondary_reload.  There is code in
pa_emit_move_sequence
to handle reloads for for floating-point loads/stores from REG+D addresses but
it isn't being
used.

In non-pic code, the reloads appear to be handled correctly.  In pic code,
reload doesn't know
how to handle a REG+D address where the REG contains the address of a
symbol_ref:

(insn 10 11 12 2 (set (reg/f:SI 146)
     (mem/u/c:SI (lo_sum:SI (reg:SI 113)
     (unspec:SI [
     (symbol_ref:SI ("indirect_child") )
     ] UNSPEC_DLTIND14R)) [0  S4 A32])) "beta.c":18:32 42
{*pa.md:2195}
  (expr_list:REG_DEAD (reg:SI 113)
     (expr_list:REG_EQUIV (symbol_ref:SI ("indirect_child") )
     (nil

In theory, it seems to me reload could try reloading D to a register.  The
offsets are limited to 14 bits
and the ldo instruction can handle that directly.

[Bug c++/114297] New: Yet more problems with "definition in block does not dominate use in block"

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 114297
   Summary: Yet more problems with "definition in block does not
dominate use in block"
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C++ code:

void __assert_fail(char *, int, const char *) __attribute__((__noreturn__));
template  void max(T, T);
template  struct SimpleVector {
  T array;
  int num;
  T *getRef(int i) {
num - i ? void() : __assert_fail("", 7, __PRETTY_FUNCTION__);
return  + i;
  }
};
struct Extremes {
  int minWidth;
  int maxWidth;
};
int forceCalcColumnExtremes_cs;
struct Table {
  SimpleVector colExtremes;
  void forceCalcColumnExtremes();
};
void Table::forceCalcColumnExtremes() {
  int minSumCols, maxSumCols;
  for (int i; i; ++i) {
minSumCols += colExtremes.getRef(i)->minWidth;
maxSumCols += colExtremes.getRef(i)->maxWidth;
  }
  max(forceCalcColumnExtremes_cs, minSumCols);
  max(forceCalcColumnExtremes_cs, maxSumCols);
}

compiled by recent gcc trunk, does this:

cvise $ ~/gcc/results/bin/g++ -c -w -O3 bug1022.cc
cvise $ ~/gcc/results/bin/g++ -c -w -O3 -march=znver3 bug1022.cc
bug1022.cc: In member function ‘void Table::forceCalcColumnExtremes()’:
bug1022.cc:20:6: error: definition in block 5 does not dominate use in block 3
   20 | void Table::forceCalcColumnExtremes() {
  |  ^
for SSA_NAME: vect_maxSumCols_16.16_76 in statement:
vect_maxSumCols_16.16_90 = PHI 
PHI argument
vect_maxSumCols_16.16_76
for PHI node
vect_maxSumCols_16.16_90 = PHI 
during GIMPLE pass: vect
bug1022.cc:20:6: internal compiler error: verify_ssa failed
0x159e432 verify_ssa(bool, bool)
../../trunk.20210101/gcc/tree-ssa.cc:1203
0x1204a9d execute_function_todo
../../trunk.20210101/gcc/passes.cc:2095

The bug first seems to occur sometime between g:71244316cf714725
and g:10cbfcd60f9e5bdb, which is a distance of 43 commits.

[Bug tree-optimization/110501] [13/14 regression] Invalid -Wuse-after-free / realloc with a store/load happening

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

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

Sam James  changed:

   What|Removed |Added

Summary|[12/13/14 regression]   |[13/14 regression] Invalid
   |Invalid -Wuse-after-free /  |-Wuse-after-free / realloc
   |realloc with a store/load   |with a store/load happening
   |happening   |

--- Comment #8 from Sam James  ---
oh, right, it was added in 12. But given 12 only warns with -O0 and 13+ warn
with optimisation, let's call it a 13/14 regression.

[Bug ipa/106716] Identical Code Folding (-fipa-icf) confuses between functions with different [[likely]] attributes

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

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

--- Comment #6 from Jan Hubicka  ---
The reason why GIMPLE_PREDICT is ignored is that it is never used after ipa-icf
and gets removed at the very beggining of late optimizations.  

GIMPLE_PREDICT is consumed by profile_generate pass which is run before
ipa-icf.  The reason why GIMPLE_PREDICT statements are not stripped during ICF
is early inlining.  If we early inline, we throw away its profile and estimate
it again (in the context of function it was inlined to) and for that it is a
good idea to keep predicts.

There is no convenient place to remove them after early inlining was done and
before IPA passes and that is the only reason why they are around.  We may
revisit that since streaming them to LTO bytecode is probably more harmful then
adding extra pass after early opts to strip them.

ICF doesn't code to compare edge profiles and stmt histograms.  It knows how to
merge them (so resulting BB profile is consistent with merging) but I suppose
we may want to have some threshold on when we do not want to marge functions
with very different branch probabilities in the hot part of their bodies...

[Bug preprocessor/8270] [11/12/13/14 Regression] back-slash white space newline with comments, no warning

[verodeving at gmail dot com via Gcc-bugs]

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

veronica alphonso  changed:

   What|Removed |Added

 CC||verodeving at gmail dot com

--- Comment #70 from veronica alphonso  ---
Any update on this bug?

[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e

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

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

--- Comment #6 from Sam James  ---
Created attachment 57660
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57660=edit
reduced.c

Bit smaller.

[Bug modula2/114296] ICE when attempting to create a constant set with a variable element

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

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

Gaius Mulley  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-10
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

[Bug modula2/114296] New: ICE when attempting to create a constant set with a variable element

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

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

Bug ID: 114296
   Summary: ICE when attempting to create a constant set with a
variable element
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

As reported on the mailing list attempting to create a constant set using a
variable will cause an ICE.

MODULE tiny2 ;

VAR
   x: CARDINAL ;
   ch: CHAR ;
BEGIN
   x := 6 ;
   ch := {7 .. x};
END tiny2.

[Bug middle-end/114195] [14] RISC-V vector ICE: in vectorizable_store, at tree-vect-stmts.cc:8690

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

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

--- Comment #4 from Li Pan  ---
Hi Patrick,

Could you please help to double-check if upstream has this problem? As well as
PR114198.

Thanks.

[Bug target/111822] [12/13/14 Regression] during RTL pass: lr_shrinkage ICE: in operator[], at vec.h:910 with -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions since r12-5301-g04520645038

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

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

--- Comment #15 from Eric Botcazou  ---
> Preloading stuff is simply loading from the same DImode address, so I'd
> think that EH_NOTE should be moved from the original insn to the new insn
> without much problems.

Old reload and LRA need to do that too; see copy_reg_eh_region_note_forward
and its callers for a possible way out.

[Bug modula2/114295] New: incorrect error location if attempting to compile implementation module without a definition module

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

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

Bug ID: 114295
   Summary: incorrect error location if attempting to compile
implementation module without a definition module
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

When attempting to compile an implementation module and the definition module
cannot be found the compiler reports the error in the SYSTEM module:

gm2 -g -c impls/UTF8.mod 
/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/14.0.1/m2/m2cor/SYSTEM.def:27:19:
error: the file containing the definition module ‘UTF8’ cannot be found
   27 | DEFINITION MODULE SYSTEM ;
  |   ^~

[Bug modula2/114294] expression causes ICE

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

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

Gaius Mulley  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-10
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Gaius Mulley  ---
Confirmed on gm2-14 (and reported broken in gm2-13).

[Bug modula2/114294] New: expression causes ICE

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

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

Bug ID: 114294
   Summary: expression causes ICE
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

gm2 ICE occurs if:


MODULE example ;

FROM NumberIO IMPORT WriteInt ;

TYPE
   multidimarray = ARRAY [0..2] OF ARRAY [0..2] OF REAL ;

PROCEDURE foo (VAR c : multidimarray) ;
BEGIN
  WriteInt(1 + HIGH(c[0]), 0)
END foo ;

VAR
   bar: multidimarray ;
BEGIN
   foo (bar)
END example.

[Bug libfortran/93727] Fortran 2018: EX edit descriptor

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

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

--- Comment #6 from Thomas Henlich  ---
(In reply to Jerry DeLisle from comment #5)
> I have been studying this a bit by looking at the 2023 std and functionality
> of printf().
> Specifically printf() provides the 'A' descriptor which can be used for
> float (kind=4) and double (kind=8).  It will accept a long double (80 bit
> aka kind=10). I am noticing that the results of double and long double are
> identical, no extra precision visible. It is very possible I am not doing
> that correctly.
> 
> I do not see anything related to quad precision floats.  I am posting this
> as i think we will have to do some of our own translating byte portions of
> floats ourselves. Portability may be an issue. For example IBM 360 128bit
> precision or some other processor may not follow the same internal
> representations.
> 
> Regardless I have preliminary code for the frontend that results in calling
> anew fucntion write_ex in transfer.c
> 
> I think that kind=4 and kind=8 will be fine. Any thoughts on kind=10 or
> kind=16 I would appreciate as I further explore this.

Just some thoughts:

Have you tried "%LA" for long double?

Have you tried quadmath_snprintf
(https://gcc.gnu.org/onlinedocs/libquadmath/quadmath_005fsnprintf.html) with
"%QA" for quad precision?

[Bug ipa/109817] [14 regression] internal error in ICF pass on Ada interfaces

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
Summary|[14 Regression] internal|[14 regression] internal
   |error in ICF pass on Ada|error in ICF pass on Ada
   |interfaces  |interfaces
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org

--- Comment #3 from Eric Botcazou  ---
I'll have a look.

[Bug tree-optimization/114293] New: [14 Regression] ICE: in verify_range, at value-range.cc:1132 at -O2

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114293
   Summary: [14 Regression] ICE: in verify_range, at
value-range.cc:1132 at -O2
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 testcase.c
testcase.c: In function 'bar':
testcase.c:4:3: warning: '__builtin_memset' specified bound
18374966859414961920 exceeds maximum object size 9223372036854775807
[-Wstringop-overflow=]
4 |   __builtin_memset (, a, 0xFF00FF00FF00FF00);
  |   ^~~~
during GIMPLE pass: strlen
testcase.c: In function 'foo':
testcase.c:9:1: internal compiler error: in verify_range, at
value-range.cc:1132
9 | foo (void)
  | ^~~
0x8a195e irange::verify_range()
/repo/gcc-trunk/gcc/value-range.cc:1132
0x1853427 irange::set(tree_node*, generic_wide_int const&,
generic_wide_int const&, value_range_kind)
/repo/gcc-trunk/gcc/value-range.cc:1076
0x17394e8 int_range<2u, false>::int_range(tree_node*,
generic_wide_int const&, generic_wide_int
const&, value_range_kind)
/repo/gcc-trunk/gcc/value-range.h:1047
0x17394e8 set_strlen_range(tree_node*, generic_wide_int,
generic_wide_int, tree_node*)
/repo/gcc-trunk/gcc/tree-ssa-strlen.cc:1942
0x17455f8 strlen_pass::handle_builtin_strlen()
/repo/gcc-trunk/gcc/tree-ssa-strlen.cc:2344
0x1745ab5 strlen_pass::check_and_optimize_call(bool*)
/repo/gcc-trunk/gcc/tree-ssa-strlen.cc:5412
0x1746499 strlen_pass::check_and_optimize_stmt(bool*)
/repo/gcc-trunk/gcc/tree-ssa-strlen.cc:5670
0x17468d6 strlen_pass::before_dom_children(basic_block_def*)
/repo/gcc-trunk/gcc/tree-ssa-strlen.cc:5854
0x2615eae dom_walker::walk(basic_block_def*)
/repo/gcc-trunk/gcc/domwalk.cc:311
0x1746dd7 printf_strlen_execute
/repo/gcc-trunk/gcc/tree-ssa-strlen.cc:5913
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.

$ 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-9409-20240309093707-ge9753f4b633-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/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
--disable-bootstrap --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 --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9409-20240309093707-ge9753f4b633-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240309 (experimental) (GCC)