[Bug ipa/114321] [11 regression] ipa/modref: incorrect result with O2 since r11-3308

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

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

--- Comment #2 from Andrew Pinski  ---
> does not clobber ref: ret alias sets: 46->46


Is specificly saying the function does not do any stores that would cause
aliasing set 46 to change.

[Bug ipa/114321] [11 regression] ipa/modref: incorrect result with O2 since r11-3308

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Yes this is 100% an alias violations. 

You do the store as an uint32_t but then read it as uint64_t.

[Bug ipa/114321] New: [11 regression] ipa/modref: incorrect result with O2 since r11-3308

[yinyuefengyi at gmail dot com via Gcc-bugs]

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

Bug ID: 114321
   Summary: [11 regression] ipa/modref: incorrect result with O2
since r11-3308
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yinyuefengyi at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/hz4E1q4dK

Though the code is somewhat flaw, uint64_t pointer is passed to a function and
modified as uint32_t pointer, the function call is removed by fre1 pass as:


ipa-modref: call stmt MurmurHash3_x86_32 (_8, _2, 123456, );
ipa-modref: call to void MurmurHash3_x86_32(const void*, int, uint32_t,
uint64_t*)/554 does not clobber ref: ret alias sets: 46->46
Setting value number of _10 to 0 (changed)
Value numbering stmt = ret ={v} {CLOBBER(eol)};
Setting value number of .MEM_11 to .MEM_11 (changed)
Value numbering stmt = return _10;
marking outgoing edge 2 -> 1 executable
RPO iteration over 1 blocks visited 1 blocks in total discovering 1 executable
blocks iterating 1.0 times, a block was visited max. 1 times
RPO tracked 9 values available at 3 locations and 9 lattice elements
Replaced MEM[(const struct basic_string *)trace_id_6(D)]._M_dataplus._M_p with
_7 in all uses of _8 = MEM[(const struct basic_string
*)trace_id_6(D)]._M_dataplus._M_p;
Replaced ret with 0 in all uses of _10 = ret;
Removing dead stmt _10 = ret;
Removing dead stmt _8 = MEM[(const struct basic_string
*)trace_id_6(D)]._M_dataplus._M_p;


Not sure whether this is valid, it works before gcc11.  Disable with
-fno-ipa-modref or -fno-strict-aliasing could work.  Please take a look?

[Bug rtl-optimization/64081] [11/12 Regression] r217828 prevents RTL loop unroll

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12 Regression] r217828
   |r217828 prevents RTL loop   |prevents RTL loop unroll
   |unroll  |
 CC||law at gcc dot gnu.org

--- Comment #70 from Jeffrey A. Law  ---
Per c#68.  Given there's been ~6 years since any significant work was done on
this BZ, I'm not too keen on actually bisecting.  I'm just happy it's behaving
as expected.

Removing gcc-14 and gcc-13 regression markers.

[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%) since r13-5154-g733a1b777f1

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

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

--- Comment #7 from Jeffrey A. Law  ---
Yea, there are various limits on the size of various lists the scheduler
maintains.  This looks independent of those various clamps.

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

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

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

--- Comment #22 from Xi Ruoyao  ---
(In reply to Sam James from comment #21)
> (In reply to Xi Ruoyao from comment #20)
> > Also failing on LoongArch.
> 
> The testcase from comment 19 or the test?
> 
> Not sure if we should move the comment 19 issue into its own PR?

The c23-stdarg-6.c test itself.  Though I guess comment 19 test case will fail
too.

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

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

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

--- Comment #21 from Sam James  ---
(In reply to Xi Ruoyao from comment #20)
> Also failing on LoongArch.

The testcase from comment 19 or the test?

Not sure if we should move the comment 19 issue into its own PR?

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #20 from Xi Ruoyao  ---
Also failing on LoongArch.

[Bug testsuite/114320] New test case in r14-9439-g4aa87b856067d4 fails

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

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

Kewen Lin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-03-13
 Ever confirmed|0   |1
 CC||linkw at gcc dot gnu.org

--- Comment #1 from Kewen Lin  ---
These new test cases require "-Wno-psabi" to suppress the warning.

[Bug c++/66108] [CWG 349] incorrect cv-qualification deduction on conversion operator template

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||94404
 Status|UNCONFIRMED |NEW
  Alias||cwg349
Summary|incorrect cv-qualification  |[CWG 349] incorrect
   |deduction on conversion |cv-qualification deduction
   |operator template   |on conversion operator
   ||template
   Last reconfirmed||2024-03-13
 Ever confirmed|0   |1

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
[Bug 94404] [meta-bug] C++ core issues

[Bug c++/66108] incorrect cv-qualification deduction on conversion operator template

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

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

--- Comment #3 from Andrew Pinski  ---
https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#349

[Bug c++/114311] Possibly wrong "error: ‘this’ is not a constant expression" with consteval member function

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Carlo Wood from comment #5)
> Hey Andrew :)
> You probably mean https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98752
> But they are different in that I think that this report is invalid...
> See "discussion" here: https://stackoverflow.com/a/78142737/1487069
> But I'd definitely like to hear your expert view on it. If it's invalid then
> sorry for wasting your time :/.

No I am thinking of PR 114124 .

[Bug c++/114311] Possibly wrong "error: ‘this’ is not a constant expression" with consteval member function

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

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

--- Comment #5 from Carlo Wood  ---
Hey Andrew :)
You probably mean https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98752
But they are different in that I think that this report is invalid...
See "discussion" here: https://stackoverflow.com/a/78142737/1487069
But I'd definitely like to hear your expert view on it. If it's invalid then
sorry for wasting your time :/.

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

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

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

--- Comment #35 from Eric Gallager  ---
(In reply to Дилян Палаузов from comment #34)
> Created attachment 57662 [details]
> 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.

Please send this patch to the gcc-patches mailing list and cc the build system
maintainers. I think the `maybe-` things are supposed to get generated in some
sort of way that would require digging into the whole autogen generation method
a bit more deeply, but I'm not too sure myself... maybe this ought to be a
`depend=` entry in Makefile.def instead?

[Bug target/63599] "wrong" branch optimization with Ofast in a loop

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||5.1.0, 6.1.0
   Keywords|wrong-code  |missed-optimization
 Status|UNCONFIRMED |RESOLVED
  Known to work||7.1.0
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #5 from Andrew Pinski  ---
Fixed for GCC 7.

[Bug middle-end/61785] Sigsegv with enabled optimize -Os , -O2 in sample_format_size

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
No feedback in over 9 years so closing.

[Bug fortran/114001] is_contiguous considers unlimited polymorphic dummy always as contiguous

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2024-03-12

--- Comment #2 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2024-March/060320.html

[Bug target/46993] Optimization on i386 lead to user-visible traps during floating-point operations

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=42834
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |4.6.0

--- Comment #2 from Andrew Pinski  ---
Fixed in GCC 4.6.0; most likely by r0-101269-g70f348148c0946 (and maybe
another).

[Bug c/83294] int32_t & related definitions wrong with -funsigned-bitfields

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

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

--- Comment #9 from Andrew Pinski  ---
https://inbox.sourceware.org/gcc-patches/7a5ec7af-fdbf-470f-9414-bf4110331...@ventanamicro.com/

[Bug c++/86769] g++ destroys condition variable in for statement too early

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||gnu4u at flonatel dot org

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

[Bug c++/36016] for-loop scoping problem: Method gets called after destructor

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Since PR 86769 has more analysis and a start of a patch, marking this as a dup
of that one.

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

[Bug c++/86769] g++ destroys condition variable in for statement too early

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

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

--- Comment #6 from Andrew Pinski  ---
Created attachment 57684
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57684=edit
Testcase from godbolt

[Bug target/33671] incorrect vector codegen on PPU at O3 level optimization

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||janis at gcc dot gnu.org

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

[Bug target/34038] 176.gcc segfaults when compiled with -O2 -ftree-vectorize -maltivec

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #10 from Andrew Pinski  ---
Dup.

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

[Bug target/34038] 176.gcc segfaults when compiled with -O2 -ftree-vectorize -maltivec

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

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

--- Comment #9 from Andrew Pinski  ---
https://gcc.gnu.org/legacy-ml/gcc-patches/2007-08/msg00438.html

[Bug c/24414] Old-style asms don't clobber memory

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
  Known to fail||
   Target Milestone|--- |7.0

--- Comment #21 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-patches/2016-May/447597.html

So fixed (r7-1269-g93671519e202e3).

[Bug tree-optimization/114151] [14 Regression] weird and inefficient codegen and addressing modes since r14-9193

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #21 from Andrew Macleod  ---
(In reply to Richard Biener from comment #19)

> 
> While ranger has a range_on_exit API this doesn't work on GENERIC expressions
> as far as I can see but only SSA names but I guess that could be "fixed"
> given range_on_exit also looks at the last stmt and eventually defers to
> range_of_expr (or range_on_entry), but possibly get_tree_range needs
> variants for on_entry/on_exit (it doesn't seem to use it's 'stmt' context
> very consistently, notably not for SSA_NAMEs ...).

That would appear to be an oversight. That API has not been used very much for
arbitrary generic trees.  I think the original reason support for tree
expressions was added was a "try this" for some other PR. It was simple to do
so we lef tit in, but it never got any real traction.  At least as far as I can
recall :-)

Currently, I think mosrt, if not all, uses of get_tree_range() are either
!gimple_ssa_range_p() (commonly constants or unsupported types) or ssa_names on
abnormal edges. 

For abnormal edges, we ought to be getting the global range directly these days
instad of calling that routine.   Then in get_tree_range (), we ought to be
calling range_of_expr for SSA_NAMES with the provided context.  I'll poke at
that too. The support for general tree expressions changed the original intent
of the function, and it should be adjusted. 

As for the on-exit/on-entry bits... we haven't had a need for entry/exit
outside of ranger in the past.  I had toyed with exporting those routines and
making them a part of the official API for value-query, but hadn't run across
the need as yet.

Let me think about that for a minute. It can certainly be done. I guess we
really only need an on-entry and on-exit version of range_of_expr to do
everything.  So if we end up with something like:  
  range_of_expr (r, expr, stmt)
  range_of_expr_on_entry  (r, expr, bb)
  range_of_expr_on_exit (r, expr, bb)

And have that all work with general trees expressions.. That would solve much
of this for you?



> 
> Interestingly enough we somehow still need the
> 

> 
> hunk of Andrews patch to do it :/
> 

That probably means there is another call somewhere in the chain with no
context. However, I will say that functionality is more important than it
seems. Should have been there from the start :-P.

[Bug testsuite/114320] New: New test case in r14-9439-g4aa87b856067d4 fails

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

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

Bug ID: 114320
   Summary: New test case in r14-9439-g4aa87b856067d4 fails
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:4aa87b856067d4911de8fb66b3a27659dc75ca6d, r14-9439-g4aa87b856067d4

This new test works on our powerpc64 systesm built with IEEE128 as default but
fails everywhere else (both BE and LE).

make  -k check-gcc-c++ RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
modules.exp=target-powerpc-1_a.C"
FAIL: g++.dg/modules/target-powerpc-1_a.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/target-powerpc-1_a.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/target-powerpc-1_a.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/target-powerpc-1_a.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/target-powerpc-1_a.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/target-powerpc-1_a.C -std=c++2b (test for excess errors)


cc1plus: warning: Using IEEE extended precision 'long double' [-Wpsabi]
FAIL: g++.dg/modules/target-powerpc-1_b.C -std=c++2a (test for excess errors)
Excess errors:
cc1plus: warning: Using IEEE extended precision 'long double' [-Wpsabi]


commit 4aa87b856067d4911de8fb66b3a27659dc75ca6d (HEAD)
Author: Nathaniel Shead 
Date:   Sun Mar 10 22:06:18 2024 +1100

c++: Support target-specific nodes when streaming modules [PR111224]

[Bug c++/111592] [11/12/13/14 Regression] ICE on expanding argument pack into variadic constructor

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Started with r6-6795-g0fd9d4921f7ba2.  But that's only adding an assert so the
problem was probably latent.

[Bug fortran/110826] Fortran array of derived type with a pointer to function with dimensional arguments fails

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:81ee1298b47d3f3b3712ef3f3b2929ca26c4bcd2

commit r14-9442-g81ee1298b47d3f3b3712ef3f3b2929ca26c4bcd2
Author: Harald Anlauf 
Date:   Mon Mar 11 22:05:51 2024 +0100

Fortran: handle procedure pointer component in DT array [PR110826]

gcc/fortran/ChangeLog:

PR fortran/110826
* array.cc (gfc_array_dimen_size): When walking the ref chain of an
array and the ultimate component is a procedure pointer, do not try
to figure out its dimension even if it is a array-valued function.

gcc/testsuite/ChangeLog:

PR fortran/110826
* gfortran.dg/proc_ptr_comp_53.f90: New test.

[Bug middle-end/114319] htobe64-like function is not optimized on 32-bit x86

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Pali Rohár from comment #3)
> --with-arch-32=i686

This basically causes SSE to be disabled for 32bit by default ...
With the default options to configure GCC, -m32 for x86_64 still enables sse
...

[Bug middle-end/114319] htobe64-like function is not optimized on 32-bit x86

[pali at kernel dot org via Gcc-bugs]

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

--- Comment #3 from Pali Rohár  ---
For details, here is the compiler which produces the mentioned code:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-14'
--with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-14)

I guess that with these configure options you should be able to compile gcc
which produces the mentioned code.

[Bug middle-end/114319] htobe64-like function is not optimized on 32-bit x86

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-03-12
 Target|x86 |ILP32
 Blocks||94094
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed. I see the trunk even without -mno-sse does not produce the 2 bswaps.

Looks like the store-merging pass is not recognizing bswap<<32 for some reason.

Also I thought there was a dup somewhere ...


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94094
[Bug 94094] [meta-bug] store-merging and/or bswap load/store-merging missed
optimizations

[Bug middle-end/114319] htobe64-like function is not optimized on 32-bit x86

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||11.4.0

--- Comment #1 from Andrew Pinski  ---
>But compiling it for 32-bit x86 via "gcc -m32 -O2" produces not so optimized 
>code:


I get that code generation for GCC 11.4.0 and before.

For GCC 12.1.0 and above I get:
```
movl8(%esp), %ecx
bswap   %ecx
movl%ecx, %eax
movl4(%esp), %ecx
bswap   %ecx
movl%ecx, %edx
movl12(%esp), %ecx
movl%eax, (%ecx)
movl%edx, 4(%ecx)
ret
```

Which just has a few extra moves.

But adding  -mno-sse, GCC 12 produces worse code.

[Bug rtl-optimization/112560] [14 Regression] ICE in try_combine on pr112494.c

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Uroš Bizjak  ---
v3 patch at [1]

[1] https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647634.html

[Bug middle-end/114319] htobe64-like function is not optimized on 32-bit x86

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |middle-end
   Severity|normal  |enhancement
   Keywords||missed-optimization

[Bug target/114319] New: htobe64-like function is not optimized on 32-bit x86

[pali at kernel dot org via Gcc-bugs]

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

Bug ID: 114319
   Summary: htobe64-like function is not optimized on 32-bit x86
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pali at kernel dot org
  Target Milestone: ---
Target: x86

Here is very simple and straightforward implementation of htobe64 function
which takes 64-bit number stored in unsigned long long variable and encodes it
into byte buffer unsigned char[].

void test1(unsigned long long val, unsigned char *buf) {
  buf[0] = val >> 56;
  buf[1] = val >> 48;
  buf[2] = val >> 40;
  buf[3] = val >> 32;
  buf[4] = val >> 24;
  buf[5] = val >> 16;
  buf[6] = val >> 8;
  buf[7] = val;
}

Compiling it for 64-bit x86 via "gcc -m64 -O2" produces optimized code:

 :
   0:   48 0f cfbswap  %rdi
   3:   48 89 3emov%rdi,(%rsi)
   6:   c3  retq

But compiling it for 32-bit x86 via "gcc -m32 -O2" produces not so optimized
code:

 :
   0:   8b 54 24 08 mov0x8(%esp),%edx
   4:   8b 44 24 0c mov0xc(%esp),%eax
   8:   89 d1   mov%edx,%ecx
   a:   88 70 02mov%dh,0x2(%eax)
   d:   c1 e9 18shr$0x18,%ecx
  10:   88 50 03mov%dl,0x3(%eax)
  13:   88 08   mov%cl,(%eax)
  15:   89 d1   mov%edx,%ecx
  17:   8b 54 24 04 mov0x4(%esp),%edx
  1b:   c1 e9 10shr$0x10,%ecx
  1e:   0f ca   bswap  %edx
  20:   88 48 01mov%cl,0x1(%eax)
  23:   89 50 04mov%edx,0x4(%eax)
  26:   c3  ret


I tried to compile it for 32-bit powerpc via "powerpc-linux-gnu-gcc -m32 -O2"
and it produces optimized code:

 :
   0:   90 65 00 00 stw r3,0(r5)
   4:   90 85 00 04 stw r4,4(r5)
   8:   4e 80 00 20 blr

Same for 64-bit powerpc via "powerpc-linux-gnu-gcc -m64 -O2":

 <.test1>:
   0:   f8 64 00 00 std r3,0(r4)
   4:   4e 80 00 20 blr


As a next experiment I tried to rewrite the simple implementation to use gcc
builtins.

void test2(unsigned long long val, unsigned char *buf) {
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
  val = __builtin_bswap64(val);
#endif
  __builtin_memcpy(buf, , sizeof(val));
}

If I compile it for 32-bit x86 then I get optimized code:

0030 :
  30:   8b 4c 24 0c mov0xc(%esp),%ecx
  34:   8b 44 24 04 mov0x4(%esp),%eax
  38:   8b 54 24 08 mov0x8(%esp),%edx
  3c:   0f c8   bswap  %eax
  3e:   89 41 04mov%eax,0x4(%ecx)
  41:   0f ca   bswap  %edx
  43:   89 11   mov%edx,(%ecx)
  45:   c3  ret

If I compile it for 64-bit x86 then I get exactly same code as for test1:

0010 :
  10:   48 0f cfbswap  %rdi
  13:   48 89 3emov%rdi,(%rsi)
  16:   c3  retq

I tried to compile it for powerpc too and the result of test1 and test2 was
same.



So it looks like that the issue here is specific for 32-bit x86 and gcc does
not detect that test1 function on x86 is doing bswap64.

All tests I have done on (amd64) Debian gcc and for powerpc target I used
Debian's powerpc-linux-gnu-gcc cross compiler.

[Bug target/99829] MVE: ICE in lra_assign at -O3

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

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

--- Comment #6 from Thiago Jung Bauermann  
---
Created attachment 57683
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57683=edit
Preprocessed source file.

I was able to reproduce the ICE on my x86_64 laptop with the following
commands. There's no timeout problem involved.
I'm attaching the Preprocessed source file.

$ mkdir -p ~/.cache/builds/combined-tree-src
$ mkdir -p ~/.cache/builds/combined-tree-arm-eabi
$ cd ~/src/newlib-cygwin && find . -print | cpio -pdlm
~/.cache/builds/combined-tree-src
$ cd ~/src/binutils-gdb && find . -print | cpio -pdlmu
~/.cache/builds/combined-tree-src
$ cd ~/src/gcc && find . -print | cpio -pdlmu ~/.cache/builds/combined-tree-src
$ cd ~/.cache/builds/combined-tree-arm-eabi
$ ../combined-tree-src/configure \
SHELL=/bin/bash \
--with-gnu-as \
--with-gnu-ld \
--disable-libmudflap \
--disable-gdb \
--disable-gprof \
--disable-gprofng \
--enable-lto \
--enable-shared \
--without-included-gettext \
--enable-nls \
--with-system-zlib \
--disable-sjlj-exceptions \
--enable-gnu-unique-object \
--enable-linker-build-id \
--disable-libstdcxx-pch \
--enable-c99 \
--enable-clocale=gnu \
--enable-libstdcxx-debug \
--enable-long-long \
--with-cloog=no \
--with-ppl=no \
--with-isl=no \
--enable-threads=no \
--disable-multiarch \
--disable-multilib \
--with-mode=thumb \
--with-arch=armv8.1-m.main+mve.fp+fp.dp \
--with-float=hard \
--with-sysroot=/tmp/install/arm-eabi \
--with-headers=yes \
--with-native-system-header-dir=/include \
--with-newlib \
--enable-checking=yes \
--disable-bootstrap \
--enable-languages=c,c++,lto \
--prefix=/tmp/install \
--build=x86_64-pc-linux-gnu \
--host=x86_64-pc-linux-gnu \
--target=arm-eabi
$ make \
SHELL=/bin/bash \
-w \
-j 8 \
LDFLAGS_FOR_TARGET=" --specs=rdimon.specs" \
CFLAGS_FOR_BUILD="-pipe -g -O2" \
CXXFLAGS_FOR_BUILD="-pipe -g -O2" \
LDFLAGS_FOR_BUILD="-static-libgcc" \
MAKEINFOFLAGS=--force
$
/home/bauermann/.cache/builds/combined-tree-arm-eabi/gcc/testsuite/g++/../../xg++
\
   
-B/home/bauermann/.cache/builds/combined-tree-arm-eabi/gcc/testsuite/g++/../../
\
   
/home/bauermann/.cache/builds/combined-tree-src/gcc/testsuite/c-c++-common/torture/vshuf-v16qi.c
\
-fdiagnostics-plain-output \
-nostdinc++ \
   
-I/home/bauermann/.cache/builds/combined-tree-arm-eabi/arm-eabi/libstdc++-v3/include/arm-eabi
\
   
-I/home/bauermann/.cache/builds/combined-tree-arm-eabi/arm-eabi/libstdc++-v3/include
\
-I/home/bauermann/.cache/builds/combined-tree-src/libstdc++-v3/libsupc++ \
   
-I/home/bauermann/.cache/builds/combined-tree-src/libstdc++-v3/include/backward
\
   
-I/home/bauermann/.cache/builds/combined-tree-src/libstdc++-v3/testsuite/util \
-fmessage-length=0 \
-O3 \
-g \
-S \
-o vshuf-v16qi.s
during RTL pass: reload
In file included from
/home/bauermann/.cache/builds/combined-tree-src/gcc/testsuite/c-c++-common/torture/vshuf-v16qi.c:5:
/home/bauermann/.cache/builds/combined-tree-src/gcc/testsuite/c-c++-common/torture/vshuf-main.inc:
In function ‘int main()’:
/home/bauermann/.cache/builds/combined-tree-src/gcc/testsuite/c-c++-common/torture/vshuf-main.inc:26:1:
internal compiler error: in lra_assign, at lra-assigns.cc:1657
0x10b2b19 lra_assign(bool&)
../../combined-tree-src/gcc/lra-assigns.cc:1657
0x10acf3f lra(_IO_FILE*, int)
../../combined-tree-src/gcc/lra.cc:2493
0x10617ef do_reload
../../combined-tree-src/gcc/ira.cc:5973
0x10617ef execute
../../combined-tree-src/gcc/ira.cc:6161
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug testsuite/114307] [ARM] Vectorization tests not disabled for vector-less targets

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

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

--- Comment #6 from Andrew Pinski  ---
The easiest way to fix this testcase is to rename the testcase to O3-pr113576.c
and remove the dg-options

Though we should audit all of the other ones that use dg-options too:
gimplefe-40.c:/* { dg-options "-fgimple -Wno-psabi -w" } */
gimplefe-41.c:/* { dg-options "-fgimple -Wno-psabi -w" } */
pr101145inf.c:/* { dg-options "-O3" } */
pr101145inf_1.c:/* { dg-options "-O3" } */
pr108316.c:/* { dg-options "-O3" } */
pr84711.c:/* { dg-options "-O2 -Wno-psabi" } */
pr85597.c:/* { dg-options "-O3" } */
pr88497-1.c:/* { dg-options "-O2 -ffast-math -fdump-tree-reassoc1" } */
pr88497-2.c:/* { dg-options "-O2 -ffast-math -fdump-tree-reassoc1" } */
pr88497-3.c:/* { dg-options "-O2 -ffast-math -fdump-tree-reassoc1" } */
pr88497-4.c:/* { dg-options "-O2 -ffast-math -fdump-tree-reassoc1" } */
pr88497-5.c:/* { dg-options "-O2 -ffast-math -fdump-tree-reassoc1" } */
pr88497-6.c:/* { dg-options "-O2 -mavx512f -ffast-math -fdump-tree-reassoc1" }
*/
pr88497-7.c:/* { dg-options "-O2 -mavx512f -ffast-math -fdump-tree-reassoc1" }
*/
pr92347.c:/* { dg-options "-O1 -fopenmp-simd" } */
pr93069.c:/* { dg-options "-O2 -fopenmp-simd" } */
pr97241.c:/* { dg-options "-O3 --param max-loop-header-insns=2" } */
pr99102.c:/* { dg-options "-O2 -ftree-vectorize -fno-vect-cost-model
-fdump-tree-vect-details" } */
vect-fold-1.c:/* { dg-options "-O2 -fdump-tree-ccp1" } */
vect-reduc-epilogue-gaps.c:/* { dg-options "-O3 -fno-vect-cost-model" } */
vect-singleton_1.c:/* { dg-options "-Warray-bounds -O2 -fno-inline -std=c99" }
*/

Use dg-additional-options instead and/or rename if needed.

[Bug target/99829] MVE: ICE in lra_assign at -O3

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

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

--- Comment #5 from Maxim Kuvyrkov  ---
Hi Vladimir,

The email you got from Linaro CI was about tests the ICE changing "names" due
to assert in lra-assigns.cc changing line numbers.  E.g.,
FAIL: c-c++-common/torture/vshuf-v16qi.c -O3 -g  (internal compiler error: in
lra_assign, at lra-assigns.cc:1651)
... becoming ...
FAIL: c-c++-common/torture/vshuf-v16qi.c -O3 -g  (internal compiler error: in
lra_assign, at lra-assigns.cc:1657)
These are not real regressions, and that report can be ignored.

This PR though, is about fixing the ICE triggered by this test.  We are seeing
the ICEs using these configure options:
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/lastSuccessfulBuild/artifact/artifacts/notify/configure-make.txt/*view*/
.

Where did you see the timeouts, btw?

[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

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

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

--- Comment #15 from Jerry DeLisle  ---
(In reply to Tobias Burnus from comment #14)
--- snip ---
> The question is whether the following show give an error as shown above:
>   real :: x(3)
>   character(len=1) :: s
>   ...
>   write(99, '(a)') '1.23435 1243.24 13.24 ;'
>   read(99, *) x, s
> 
> Or whether reading this line should work, i.e. reading ';' as character – as
> it does with ifort and flang.
> 
> Or in other words:
> * Does ';' count as character, readable by list-directed formatted I/O?
> (ifort, ifx, flang)
> * Or doesn't it? (gfortran since at least 4.9)
> 

This error caught my attention right away as being odd. With the regression
part out of the way at the moment I will study this further. My initial thought
is we have an eat_seprator out of place where we only need an eat_spaces.
Regardless, I am looking into it.

[Bug target/99829] MVE: ICE in lra_assign at -O3

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

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

--- Comment #4 from Vladimir Makarov  ---
(In reply to Maxim Kuvyrkov from comment #3)
> Hi Vladimir,
> 
> Could you take a look at this, please?

I already got a message from automatic linaro tester yesterday about the new
test failures and looked at them.

I was not able to reproduce them but after I looked at the provided log files. 
I see that the tests failed because of timeout.

My recent patch resulted in LRA doing a bit more job and therefore the tests
(all with -O3) failed because of the timeout.

I'd recommend to increase the timeout threshold for the tester.

[Bug testsuite/114307] [ARM] Vectorization tests not disabled for vector-less targets

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

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

--- Comment #5 from Maxim Kuvyrkov  ---
Thanks to Christophe L. for explaining the logic behind "is-effective-target
arm_neon_ok".

The issue is that "/* { dg-options "-O3" } */" in pr113576.c overrides
DEFAULT_VECTFLAGS set by check_vect_support_and_set_flags, which contains
"-mfpu=neon" -- as added by "is-effective-target arm_neon_ok".

It so happens that pr113576.c is the only test that both uses "dg-options" and
"tree-vect.h", thus the new error.

[Bug c++/114309] Undesirable warning with [[unlikely]]

[terra at gnome dot org via Gcc-bugs]

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

--- Comment #11 from M Welinder  ---
> Anyway, in GCC's testcase we have:
>
>   9   if (a == 123)
>  10 [[likely]] c = 5;   // { dg-warning "both" }
>  11   else
>  12 [[likely]] b = 77;

> Here we have two possible paths, and the attributes tell the compiler that the
> first is more likely than the second, and the second is more likely than the
> first. Obviously that's suspicious.

That interpretation is contrary to the C++ standard.

Ok, so I don't actually have the final standard but here's the proposed
wording: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0479r5.html

"Note: The use of the likely attribute is intended to allow implementations to
optimize for the case where paths of execution including it are arbitrarily
more likely than any alternative path of execution that does not include such
an attribute on a statement or label."

The use of "[[likely]]" in the above example therefore does not say that either
branch is more likely than the other.  Since both paths of execution include
"[[likely]]" the standard has no opinion on the matter.

"[[likely]]" and "[[unlikely]]" are not a perfect fit with the old
"builtin_expect".  They are more expressive and not tied to "if":
   {
 [[likely]] foo();
 [[unlikely]] bar();
   }
No "if" in sight, yet this tells us that foo is likely to be called, but that
it is unlikely to return normally.

Unrelatedly, the do-while work-around is fine for the simplified case I posted.
 It won't work in the much more complicated case where this comes from because
that hairy macro allows printing extra information:

   barf("foo") << something << " and " << something_else;

[Bug middle-end/114313] ICE: in limb_access_type, at gimple-lower-bitint.cc:591 with _BitInt() in a bitfield

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 57682
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57682=edit
gcc14-pr114313.patch

Untested fix.

[Bug c++/112652] g++.dg/cpp26/literals2.C FAILs

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

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #4 from Jakub Jelinek  ---
> Given that C++ says e.g. in https://eel.is/c++draft/lex.ccon#3.1
> that program is ill-formed if some character lacks encoding in the execution
> character set, I'm afraid the Solaris iconv behavior results in violation of
> the C++ standard requirements, it is hard to argue that in the Solaris case
> e.g. ISO-8859-1 execution charset would be some special character set where ?
> character represents all Unicode characters which don't have a representation
> in the character set in addition to ?.

I've now started digging into this myself.

* Solaris iconv(1) says

   output. If no conversion exists for a particular character,  an  imple-
   mentation-defined conversion is performed on this character.

* This seems to at least partially match with XPG7:

-s  Suppress any messages written to standard error concerning invalid
characters. When -s is not used, the results of encountering invalid
characters in the input stream (either those that are not valid
characters in the codeset of the input file or that have no
corresponding character in the codeset of the output file) shall be
specified in the system documentation. The presence or absence of -s
shall not affect the exit status of iconv.

  AFAIU that's related to what Solaris iconv(1) does, although they
  don't specify the output '?' and produce no message.  However, they
  still exit with 0, which seems wrong to me.

I've not yet tried to understand what either iconv(3) has to say on the
matter.

> I'm afraid we don't want to maintain iconv replacement inside of libcpp 
> though.

Agreed.

[Bug target/99829] MVE: ICE in lra_assign at -O3

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

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #3 from Maxim Kuvyrkov  ---
Hi Vladimir,

Could you take a look at this, please?

[Bug target/99829] MVE: ICE in lra_assign at -O3

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

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

Thiago Jung Bauermann  changed:

   What|Removed |Added

 CC||thiago.bauermann at linaro dot 
org

--- Comment #2 from Thiago Jung Bauermann  
---
We are still seeing this ICE in the Linaro CI:

spawn -ignore SIGHUP /path/to/install/bin/arm-eabi-g++
/path/to/gcc.git/gcc/testsuite/c-c++-common/torture/vshuf-v16qi.c -mthumb
-march=armv8.1-m.main+mve.fp+fp.dp -mtune=cortex-m55 -mfloat-abi=hard
-mfpu=auto -fdiagnostics-plain-output -nostdinc++
-I/path/to/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/include/arm-eabi
-I/path/to/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/include
-I/path/to/gcc.git/libstdc++-v3/libsupc++
-I/path/to/gcc.git/libstdc++-v3/include/backward
-I/path/to/gcc.git/libstdc++-v3/testsuite/util -fmessage-length=0 -O3 -g -S -o
vshuf-v16qi.s
during RTL pass: reload
In file included from
/path/to/gcc.git/gcc/testsuite/c-c++-common/torture/vshuf-v16qi.c:5:
/path/to/gcc.git/gcc/testsuite/c-c++-common/torture/vshuf-main.inc: In function
'int main()':
/path/to/gcc.git/gcc/testsuite/c-c++-common/torture/vshuf-main.inc:26:1:
internal compiler error: in lra_assign, at lra-assigns.cc:1657
0x10c07d1 lra_assign(bool&)
../../../../../../gcc/gcc/lra-assigns.cc:1657
0x10ba784 lra(_IO_FILE*, int)
../../../../../../gcc/gcc/lra.cc:2493
0x106fa8f do_reload
../../../../../../gcc/gcc/ira.cc:5973
0x106fa8f execute
../../../../../../gcc/gcc/ira.cc:6161
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

This is with trunk from March 8, commit cebbaa2a8458 ("[PR113790][LRA]: Fixing
LRA ICE on riscv64")

The same problem also happens in other related tests:

FAIL: c-c++-common/torture/vshuf-v2di.c -O3 -g  (internal compiler error: in
lra_assign, at lra-assigns.cc:1657)
FAIL: c-c++-common/torture/vshuf-v4sf.c -O3 -g  (internal compiler error: in
lra_assign, at lra-assigns.cc:1657)
FAIL: c-c++-common/torture/vshuf-v4si.c -O3 -g  (internal compiler error: in
lra_assign, at lra-assigns.cc:1657)
FAIL: c-c++-common/torture/vshuf-v8hi.c -O3 -g  (internal compiler error: in
lra_assign, at lra-assigns.cc:1657)

GCC is configured with:

/path/to/gcc.git/configure \
SHELL=/bin/bash \
--with-mpc=/path/to/install \
--with-mpfr=/path/to/install \
--with-gmp=/path/to/install \
--with-gnu-as \
--with-gnu-ld \
--disable-libmudflap \
--enable-lto \
--enable-shared \
--without-included-gettext \
--enable-nls \
--with-system-zlib \
--disable-sjlj-exceptions \
--enable-gnu-unique-object \
--enable-linker-build-id \
--disable-libstdcxx-pch \
--enable-c99 \
--enable-clocale=gnu \
--enable-libstdcxx-debug \
--enable-long-long \
--with-cloog=no \
--with-ppl=no \
--with-isl=no \
--enable-threads=no \
--disable-multiarch \
--disable-multilib \
--with-mode=thumb \
--with-arch=armv8.1-m.main+mve.fp+fp.dp \
--with-float=hard \
--with-sysroot=/path/to/install/arm-eabi \
--with-headers=yes \
--with-native-system-header-dir=/include \
--with-newlib \
--enable-checking=yes \
--disable-bootstrap \
--enable-languages=c,c++,lto \
--prefix=/path/to/install \
--build=x86_64-pc-linux-gnu \
--host=x86_64-pc-linux-gnu \
--target=arm-eabi

[Bug tree-optimization/114318] Missing Optimization after multiple function calls

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Richard Biener from comment #1)
> That's because main is cold.

Or rather known to be called once which causes the path to be considered cold
unless there is a loop.

[Bug target/112548] [14 regression] 5% exec time regression in 429.mcf on AMD zen4 CPU (since r14-5076-g01c18f58d37865)

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

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

--- Comment #9 from Sam James  ---
(In reply to Filip Kastl from comment #8)
> I'd like to help but I'm afraid I cannot send you the SPEC binaries with PGO
> applied since SPEC is licensed nor can I give you access to a Zen4 computer.
> I suppose someone else will have to analyze this bug.

Could you perhaps send only the gcda files so Robin can build again with
-fprofile-use?

[Bug testsuite/114307] [ARM] GCC generates instruction that assembler rejects

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

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

--- Comment #4 from Maxim Kuvyrkov  ---
What I don't understand is why vect.exp tests run at all for 32-bit ARM
non-neon targets.

All vect.exp are predicated on check_vect_support_and_set_flags, which, as far
as I can tell, has only arm_neon_ok clause for 32-bit ARM.

I'm reproducing this problem locally to understand .exp flow.  If anyone knows
the answer off-hand -- please share.

Thanks!

[Bug ipa/114317] Missing optimization for multiple condition statements

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #2 from Jan Hubicka  ---
> (it would need to elide the stores of course).

We do have way to elide stores, since we can optimize out write-only
values.  What we do not have readilly available is the value written to
a reference (ipa-refs only connects variables/functions to statements
that write/load/take address).  

I think the plan is to add summary template for references, like we have
for callgraph edges and symbols.  Then we can keep track of values and
do optimizations like this.  It is on my todo for quite some time ;)

[Bug ipa/114317] Missing optimization for multiple condition statements

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-12
  Component|tree-optimization   |ipa
 Status|UNCONFIRMED |NEW
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  I think this is known and there's possibly a duplicate.  IPA
reference doesn't consider writing the same value as in the initializer
as a way to turn the variable read-only (it would need to elide the stores
of course).

[Bug tree-optimization/114318] Missing Optimization after multiple function calls

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Richard Biener  ---
That's because main is cold.

[Bug middle-end/114312] ICE: SIGSEGV: infinite recursion in chrec_fold_plus_1 (tree-chrec.cc:336) at -O3 with _BitInt()

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Meh, fixed by

commit 73dac51b32575f980289c073969c6d825963d076 (origin/master, origin/HEAD)
Author: Richard Biener 
Date:   Tue Mar 12 14:00:05 2024 +0100

tree-optimization/114121 - chrec_fold_{plus,multiply} and recursion

The following addresses endless recursion in the
chrec_fold_{plus,multiply} functions when handling sign-conversions.
We only need to apply tricks when we'd fail (there's a chrec in the
converted operand) and we need to make sure to not turn the other
operand into something worse (for the chrec-vs-chrec case).

PR tree-optimization/114121
* tree-chrec.cc (chrec_fold_plus_1): Guard recursion with
converted operand properly.
(chrec_fold_multiply): Likewise.  Handle missed recursion.

* gcc.dg/torture/pr114312.c: New testcase.

[Bug libstdc++/110167] excessive compile time for std::to_array with huge arrays

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

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

--- Comment #13 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:

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

commit r13-8421-g4c6bb36e88d5c8e510b10d12c01e3461c2aa4259
Author: Jonathan Wakely 
Date:   Thu Jun 8 12:24:43 2023 +0100

libstdc++: Optimize std::to_array for trivial types [PR110167]

As reported in PR libstdc++/110167, std::to_array compiles extremely
slowly for very large arrays. It needs to instantiate a very large
specialization of std::index_sequence and then create a very large
aggregate initializer from the pack expansion. For trivial types we can
simply default-initialize the std::array and then use memcpy to copy the
values. For non-trivial types we need to use the existing
implementation, despite the compilation cost.

As also noted in the PR, using a generic lambda instead of the
__to_array helper compiles faster since gcc-13. It also produces
slightly smaller code at -O1, due to additional inlining. The code at
-Os, -O2 and -O3 seems to be the same. This new implementation requires
__cpp_generic_lambdas >= 201707L (i.e. P0428R2) but that is supported
since Clang 10 and since Intel icc 2021.5.0 (and since GCC 10.1).

libstdc++-v3/ChangeLog:

PR libstdc++/110167
* include/std/array (to_array): Initialize arrays of trivial
types using memcpy. For non-trivial types, use lambda
expressions instead of a separate helper function.
(__to_array): Remove.
* testsuite/23_containers/array/creation/110167.cc: New test.

(cherry picked from commit 960de5dd886572711ef86fa1e15e30d3810eccb9)

[Bug tree-optimization/114318] New: Missing Optimization after multiple function calls

[carnet at student dot ethz.ch via Gcc-bugs]

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

Bug ID: 114318
   Summary: Missing Optimization after multiple function calls
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carnet at student dot ethz.ch
  Target Milestone: ---

GCC -O3 does not inline the function if there are more than two calls. This
also only happens in the main function. Changing the name of the main function
and/or reducing the number of function calls, enables the optimization.

https://godbolt.org/z/KM71WrYac

Source
int a, c, d;
int *b, *e;
static int *f() {
  int *g = 
  int **h = 
  *g = 1;
  *h = 
  if (*b)
for (; d; d = d + 8)
  ;
  return 
}
int main() {
  f();
  f();
  f();
}

x86 -O3 Assembly:
f.part.0:
movld(%rip), %eax
testl   %eax, %eax
je  .L1
movl$0, d(%rip)
.L1:
ret
main:
movl$1, d(%rip)
movlc(%rip), %ecx
testl   %ecx, %ecx
je  .L5
xorl%eax, %eax
callf.part.0
.L5:
movl$1, d(%rip)
movlc(%rip), %edx
testl   %edx, %edx
je  .L6
xorl%eax, %eax
callf.part.0
.L6:
movl$1, d(%rip)
movlc(%rip), %eax
movq$c, b(%rip)
testl   %eax, %eax
je  .L7
xorl%eax, %eax
callf.part.0
.L7:
xorl%eax, %eax
ret
e:
.zero   8
b:
.zero   8
d:
.zero   4
c:
.zero   4
a:
.zero   4

[Bug tree-optimization/114121] wrong code with _BitInt() arithmetics at -O2

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

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

--- Comment #17 from GCC Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:73dac51b32575f980289c073969c6d825963d076

commit r14-9440-g73dac51b32575f980289c073969c6d825963d076
Author: Richard Biener 
Date:   Tue Mar 12 14:00:05 2024 +0100

tree-optimization/114121 - chrec_fold_{plus,multiply} and recursion

The following addresses endless recursion in the
chrec_fold_{plus,multiply} functions when handling sign-conversions.
We only need to apply tricks when we'd fail (there's a chrec in the
converted operand) and we need to make sure to not turn the other
operand into something worse (for the chrec-vs-chrec case).

PR tree-optimization/114121
* tree-chrec.cc (chrec_fold_plus_1): Guard recursion with
converted operand properly.
(chrec_fold_multiply): Likewise.  Handle missed recursion.

* gcc.dg/torture/pr114312.c: New testcase.

[Bug tree-optimization/114317] New: Missing optimization for multiple condition statements

[carnet at student dot ethz.ch via Gcc-bugs]

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

Bug ID: 114317
   Summary: Missing optimization for multiple condition statements
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carnet at student dot ethz.ch
  Target Milestone: ---

GCC -O3 is not able to optimize the [b && (g = 0)] statement even though g is
static and 0. So the statement does not change the value of g. This further
prevents the optimiziation of the later statements.

https://godbolt.org/z/r7P7qajYn

Source:
int b;
int *e = 
static int g = 0;

int main() {
b && (g = 0);
if (3 - g){
*e = b;
}
if (253 - (9 | g)){
*e = b;
}
return *e;
}

x86 -O3 Assembly:
main:
movlb(%rip), %eax
testl   %eax, %eax
je  .L2
movqe(%rip), %rdx
xorl%edi, %edi
movl%edi, g(%rip)
movl%eax, (%rdx)
movlb(%rip), %eax
.L3:
movl%eax, (%rdx)
ret
.L2:
movlg(%rip), %ecx
movqe(%rip), %rdx
cmpl$3, %ecx
je  .L3
xorl%esi, %esi
orl $9, %ecx
movl%esi, (%rdx)
cmpl$253, %ecx
jne .L8
ret
.L8:
movlb(%rip), %eax
jmp .L3
e:
.quad   b
b:
.zero   4

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 98688 Summary: [modules] does not work on PowerPC with opaque MMA types 
vector_pair/vector_quad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98688

   What|Removed |Added

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

[Bug target/98688] [modules] does not work on PowerPC with opaque MMA types vector_pair/vector_quad

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Assignee|nathan at gcc dot gnu.org  |nshead at gcc dot 
gnu.org
   Target Milestone|--- |14.0
 Resolution|--- |FIXED
 CC||nshead at gcc dot gnu.org

--- Comment #5 from Nathaniel Shead  ---
Fixed for GCC 14.

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 98645 Summary: [modules] does not work on PowerPC with IEEE 128-bit long 
double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98645

   What|Removed |Added

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

[Bug c++/98645] [modules] does not work on PowerPC with IEEE 128-bit long double

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|nathan at gcc dot gnu.org  |nshead at gcc dot 
gnu.org
   Target Milestone|--- |14.0
 CC||nshead at gcc dot gnu.org

--- Comment #10 from Nathaniel Shead  ---
Fixed for GCC 14.

[Bug c++/98645] [modules] does not work on PowerPC with IEEE 128-bit long double

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

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

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

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

commit r14-9439-g4aa87b856067d4911de8fb66b3a27659dc75ca6d
Author: Nathaniel Shead 
Date:   Sun Mar 10 22:06:18 2024 +1100

c++: Support target-specific nodes when streaming modules [PR111224]

Some targets make use of POLY_INT_CSTs and other custom builtin types,
which currently violate some assumptions when streaming. This patch adds
support for them, such as types like Aarch64 __fp16, PowerPC __ibm128,
and vector types thereof.

This patch doesn't provide "full" support of AArch64 SVE, however, since
for that we would need to support 'target' nodes (tracked in PR108080).

Adding the new builtin types means that on Aarch64 we now have 217
global trees created on initialisation (up from 191), so this patch also
slightly bumps the initial size of the fixed_trees allocation to 250.

PR c++/98645
PR c++/98688
PR c++/111224

gcc/cp/ChangeLog:

* module.cc (enum tree_tag): Add new tag for builtin types.
(trees_out::start): POLY_INT_CSTs can be emitted.
(trees_in::start): Likewise.
(trees_out::core_vals): Stream POLY_INT_CSTs.
(trees_in::core_vals): Likewise.
(trees_out::type_node): Handle vectors with multiple coeffs.
(trees_in::tree_node): Likewise.
(init_modules): Register target-specific builtin types. Bump
initial capacity slightly.

gcc/testsuite/ChangeLog:

* g++.dg/modules/target-aarch64-1_a.C: New test.
* g++.dg/modules/target-aarch64-1_b.C: New test.
* g++.dg/modules/target-powerpc-1_a.C: New test.
* g++.dg/modules/target-powerpc-1_b.C: New test.
* g++.dg/modules/target-powerpc-2_a.C: New test.
* g++.dg/modules/target-powerpc-2_b.C: New test.

Signed-off-by: Nathaniel Shead 
Reviewed-by: Patrick Palka 

[Bug c++/111224] modules: xtreme-header-1_a.H etc. ICE (in core_vals, at cp/module.cc:6108) on AArch64 with SVE types

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

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

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

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

commit r14-9439-g4aa87b856067d4911de8fb66b3a27659dc75ca6d
Author: Nathaniel Shead 
Date:   Sun Mar 10 22:06:18 2024 +1100

c++: Support target-specific nodes when streaming modules [PR111224]

Some targets make use of POLY_INT_CSTs and other custom builtin types,
which currently violate some assumptions when streaming. This patch adds
support for them, such as types like Aarch64 __fp16, PowerPC __ibm128,
and vector types thereof.

This patch doesn't provide "full" support of AArch64 SVE, however, since
for that we would need to support 'target' nodes (tracked in PR108080).

Adding the new builtin types means that on Aarch64 we now have 217
global trees created on initialisation (up from 191), so this patch also
slightly bumps the initial size of the fixed_trees allocation to 250.

PR c++/98645
PR c++/98688
PR c++/111224

gcc/cp/ChangeLog:

* module.cc (enum tree_tag): Add new tag for builtin types.
(trees_out::start): POLY_INT_CSTs can be emitted.
(trees_in::start): Likewise.
(trees_out::core_vals): Stream POLY_INT_CSTs.
(trees_in::core_vals): Likewise.
(trees_out::type_node): Handle vectors with multiple coeffs.
(trees_in::tree_node): Likewise.
(init_modules): Register target-specific builtin types. Bump
initial capacity slightly.

gcc/testsuite/ChangeLog:

* g++.dg/modules/target-aarch64-1_a.C: New test.
* g++.dg/modules/target-aarch64-1_b.C: New test.
* g++.dg/modules/target-powerpc-1_a.C: New test.
* g++.dg/modules/target-powerpc-1_b.C: New test.
* g++.dg/modules/target-powerpc-2_a.C: New test.
* g++.dg/modules/target-powerpc-2_b.C: New test.

Signed-off-by: Nathaniel Shead 
Reviewed-by: Patrick Palka 

[Bug target/98688] [modules] does not work on PowerPC with opaque MMA types vector_pair/vector_quad

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

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

commit r14-9439-g4aa87b856067d4911de8fb66b3a27659dc75ca6d
Author: Nathaniel Shead 
Date:   Sun Mar 10 22:06:18 2024 +1100

c++: Support target-specific nodes when streaming modules [PR111224]

Some targets make use of POLY_INT_CSTs and other custom builtin types,
which currently violate some assumptions when streaming. This patch adds
support for them, such as types like Aarch64 __fp16, PowerPC __ibm128,
and vector types thereof.

This patch doesn't provide "full" support of AArch64 SVE, however, since
for that we would need to support 'target' nodes (tracked in PR108080).

Adding the new builtin types means that on Aarch64 we now have 217
global trees created on initialisation (up from 191), so this patch also
slightly bumps the initial size of the fixed_trees allocation to 250.

PR c++/98645
PR c++/98688
PR c++/111224

gcc/cp/ChangeLog:

* module.cc (enum tree_tag): Add new tag for builtin types.
(trees_out::start): POLY_INT_CSTs can be emitted.
(trees_in::start): Likewise.
(trees_out::core_vals): Stream POLY_INT_CSTs.
(trees_in::core_vals): Likewise.
(trees_out::type_node): Handle vectors with multiple coeffs.
(trees_in::tree_node): Likewise.
(init_modules): Register target-specific builtin types. Bump
initial capacity slightly.

gcc/testsuite/ChangeLog:

* g++.dg/modules/target-aarch64-1_a.C: New test.
* g++.dg/modules/target-aarch64-1_b.C: New test.
* g++.dg/modules/target-powerpc-1_a.C: New test.
* g++.dg/modules/target-powerpc-1_b.C: New test.
* g++.dg/modules/target-powerpc-2_a.C: New test.
* g++.dg/modules/target-powerpc-2_b.C: New test.

Signed-off-by: Nathaniel Shead 
Reviewed-by: Patrick Palka 

[Bug tree-optimization/79534] [11/12 Regression] tree-ifcombine aarch64 performance regression with trunk@245151

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12 Regression]
   |tree-ifcombine aarch64  |tree-ifcombine aarch64
   |performance regression with |performance regression with
   |trunk@245151|trunk@245151
 CC||law at gcc dot gnu.org

--- Comment #23 from Jeffrey A. Law  ---
Per c#22.  Adjusting regression markers.

[Bug target/80491] [11/12/13 Regression] Compiler regression for long-add case.

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
   |Compiler regression for |Compiler regression for
   |long-add case.  |long-add case.

--- Comment #27 from Jeffrey A. Law  ---
Per c#26.  Adjusting regression marker.

[Bug ipa/80899] [11/12/13/14 Regression] Devirtualization causes incorrect code generation with placement new in some cases

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #20 from Jeffrey A. Law  ---
Per c#18.

[Bug ipa/111571] [13/14 Regression] ICE in modify_call, at ipa-param-manipulation.cc:656

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Priority|P1  |P2

--- Comment #3 from Jakub Jelinek  ---
GCC 13.{1,2} has been released with this bug, so P2.

[Bug analyzer/111305] [13/14 Regression] GCC Static Analyzer -Wanalyzer-out-of-bounds FP and ICE problem

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P2
 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
GCC 13.{1,2} has been released with this bug, so P2.

[Bug c++/111160] [11/12/13/14 Regression] ICE on assigning volatile through ternary operator

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Priority|P1  |P2

--- Comment #3 from Jakub Jelinek  ---
GCC 6-13 has been released with this bug, so P2.

[Bug middle-end/110141] [12/13/14 Regression] Wrong code at -O2 on x86_64-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Priority|P1  |P2

--- Comment #4 from Jakub Jelinek  ---
GCC 12-13 has been released with this bug, so P2.

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P2

--- Comment #11 from Jakub Jelinek  ---
GCC 7-13 has been released with this bug, so P2.

[Bug c/110682] [12/13/14 Regression] ICE: internal compiler error: in gimplify_expr after error

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P2
 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
GCC 12-13 has been released with this bug, so P2.

[Bug c++/111592] [11/12/13/14 Regression] ICE on expanding argument pack into variadic constructor

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Priority|P1  |P2

--- Comment #2 from Jakub Jelinek  ---
GCC 6-13 has been released with this bug, so P2.

[Bug analyzer/111099] [13/14 Regression] -fanalyzer -Os segmentation fault due to infinite recursion in ana::constraint_manager::eval_condition

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Priority|P1  |P2

--- Comment #3 from Jakub Jelinek  ---
GCC 13.{1,2} has been released with this bug, so P2.

[Bug c++/82894] [11/12 Regression] Inherited member functions do not create ambiguity

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
Summary|[11/12/13/14 Regression]|[11/12 Regression]
   |Inherited member functions  |Inherited member functions
   |do not create ambiguity |do not create ambiguity

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

[Bug tree-optimization/111873] [12/13/14 Regression] runtime Segmentation fault with '-O3 -fno-code-hoisting -fno-early-inlining -fno-tree-fre -fno-tree-pre'

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P2
 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
GCC 12-13 has been released with this bug, so P2.

[Bug middle-end/111921] [11/12/13/14 Regression] ICE with nested function after an error since r6-205-g5c4abbb8e80153

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Priority|P1  |P2

--- Comment #5 from Jakub Jelinek  ---
GCC 6-13 has been released with this bug, so P2.

[Bug sanitizer/112709] [13/14 Regression] address sanitize and returns_twice causes an ICE

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P2

--- Comment #8 from Jakub Jelinek  ---
GCC 13.{1,2} has been released with this bug, so P2.

[Bug middle-end/112499] [11/12/13/14 Regression] ICE in output_operand: invalid expression as operand with addition of 2 differences of address of labels

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P2

--- Comment #3 from Jakub Jelinek  ---
GCC 6-13 has been released with this bug, so P2.

[Bug analyzer/113496] [12/13/14 Regression] ICE: in cmp, at analyzer/constraint-manager.cc:782 with -fanalyzer -fdump-analyzer

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P2
 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
GCC 1{2,3} has been released with this bug, so P2.

[Bug ipa/112815] [11/12/13/14 Regression] ICE: in vague_linkage_p, at cp/decl2.cc:2329 with -flto -fno-weak

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Priority|P1  |P2

--- Comment #2 from Jakub Jelinek  ---
GCC 6-13 has been released with this bug, so P2.

[Bug c++/113141] [13/14 Regression] ICE on conversion to reference in aggregate initialization

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Priority|P1  |P2

--- Comment #6 from Jakub Jelinek  ---
GCC 13.{1,2} has been released with this bug, so P2.

[Bug tree-optimization/113662] [13/14 Regression] Wrong code for std::sort with fancy pointer since r13-6945-g429a7a88438cc8

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P2
 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
GCC 13.{1,2} has been released with this bug, so P2.

[Bug tree-optimization/84204] [11/12/13/14 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

[Bug c++/84318] [11/12/13 Regression] attribute deprecated on function templates different than class templates

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
   |attribute deprecated on |attribute deprecated on
   |function templates  |function templates
   |different than class|different than class
   |templates   |templates
 CC||law at gcc dot gnu.org

--- Comment #13 from Jeffrey A. Law  ---
Appears to have been fixed on the trunk.  Adjusting regression markers.

[Bug libstdc++/114316] assert failure with _GLIBCXX_DEBUG and empty range of singular iterators passed to std:: algorithm

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

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

--- Comment #1 from Jonathan Wakely  ---
For a debug mode _Safe_iterator pair __valid_range uses this overload:

  template
inline bool
__valid_range(const _Safe_iterator<_Iterator, _Sequence,
   _Category>& __first,
  const _Safe_iterator<_Iterator, _Sequence,
   _Category>& __last)
{
  typename _Distance_traits<_Iterator>::__type __dist;
  return __first._M_valid_range(__last, __dist);
}


Which calls:

  template
bool
_Safe_iterator<_Iterator, _Sequence, _Category>::
_M_valid_range(const _Safe_iterator& __rhs,
   std::pair& __dist,
   bool __check_dereferenceable) const
{
  if (_M_singular() || __rhs._M_singular() || !_M_can_compare(__rhs))
return false;

So it doesn't consider whether the range is empty.

For non-debug mode iterators we have:

  template
_GLIBCXX_CONSTEXPR
inline bool
__valid_range_aux(_InputIterator __first, _InputIterator __last,
  std::input_iterator_tag)
{
  return __first == __last
|| (!__gnu_debug::__check_singular(__first)
  && !__gnu_debug::__check_singular(__last));
}

which gets it right.

[Bug target/112548] [14 regression] 5% exec time regression in 429.mcf on AMD zen4 CPU (since r14-5076-g01c18f58d37865)

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

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

--- Comment #8 from Filip Kastl  ---
(In reply to Robin Dapp from comment #7)
> I built executables with and without the commit (-Ofast -march=znver4
> -flto).  There is no difference so it must really be something that happens
> with PGO.
> I'd really need access to a zen4 box or the pgo executables at least.

I'd like to help but I'm afraid I cannot send you the SPEC binaries with PGO
applied since SPEC is licensed nor can I give you access to a Zen4 computer. I
suppose someone else will have to analyze this bug.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

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

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

Bug 114269 Summary: [14 Regression] Multiple 3-6% exec time regressions of 
434.zeusmp since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269

   What|Removed |Added

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

[Bug tree-optimization/114269] [14 Regression] Multiple 3-6% exec time regressions of 434.zeusmp since r14-9193-ga0b1798042d033

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

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

Filip Kastl  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED
Summary|[14 Regression] Multiple|[14 Regression] Multiple
   |3-27% exec time regressions |3-6% exec time regressions
   |of 434.zeusmp since |of 434.zeusmp since
   |r14-9193-ga0b1798042d033|r14-9193-ga0b1798042d033

--- Comment #7 from Filip Kastl  ---
Nice, our LNT instance already shows that the patch sped up 434.zeusmp. However
I'd like to reopen this bug since the benchmark didn't return to its original
values. At least some configurations are still slower than before
r14-9193-ga0b1798042d033:

Intel Skylake -Ofast -march=native (~5% regression)
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=798.80.0

Intel Skylake -Ofast -march=native -flto PGO (~5% regression)
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=785.80.0

AMD Zen3 -Ofast -march=native -flto (~6% regression)
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=476.80.0

AMD Zen3 -Ofast -march=native -flto PGO (~4% regression)
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=474.80.0

AMD Zen2 -Ofast -march=native -flto (~3% regression)
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=289.80.0

[Bug middle-end/114312] ICE: SIGSEGV: infinite recursion in chrec_fold_plus_1 (tree-chrec.cc:336) at -O3 with _BitInt()

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
I will have a look.

[Bug target/114310] [11/12/13/14 Regression] [aarch64] __sync_val_compare_and_swap fails on __int128_t with newval = 0

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||aarch64
   Priority|P3  |P2

[Bug fortran/114308] ICE in fold_convert_loc, at fold-const.cc:2627

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-03-12
 Ever confirmed|0   |1
   Keywords||ice-on-valid-code

--- Comment #2 from Richard Biener  ---
Confirmed on trunk, not sure if valid or invalid.  We call fold_convert to
convert an object of type b to type a, this is not a conversion supported
this way.  Building a VIEW_CONVERT_EXPR would be what's supported but not
sure whether that's the correct thing to do.

> ./f951 -quiet t.f90
t.f90:20:58:

   20 |   a_array = [a_array, b_instance] ! This one throws an ICE
  |  1
internal compiler error: in fold_convert_loc, at fold-const.cc:2757
0x126cdc0 fold_convert_loc(unsigned int, tree_node*, tree_node*)
/space/rguenther/src/gcc/gcc/fold-const.cc:2757
0xeef77b gfc_trans_array_ctor_element
/space/rguenther/src/gcc/gcc/fortran/trans-array.cc:1956
0xeefeeb gfc_trans_array_constructor_value
/space/rguenther/src/gcc/gcc/fortran/trans-array.cc:2144
0xef2369 trans_array_constructor
/space/rguenther/src/gcc/gcc/fortran/trans-array.cc:2976
0xef2daa gfc_add_loop_ss_code
/space/rguenther/src/gcc/gcc/fortran/trans-array.cc:3269
0xef9ebc gfc_conv_loop_setup(gfc_loopinfo*, locus*)
/space/rguenther/src/gcc/gcc/fortran/trans-array.cc:5656
0xf63110 gfc_trans_assignment_1
/space/rguenther/src/gcc/gcc/fortran/trans-expr.cc:12216
0xf64810 gfc_trans_assignment(gfc_expr*, gfc_expr*, bool, bool, bool, bool)
/space/rguenther/src/gcc/gcc/fortran/trans-expr.cc:12679
0xf64888 gfc_trans_assign(gfc_code*)
/space/rguenther/src/gcc/gcc/fortran/trans-expr.cc:12691
0xee858c trans_code
/space/rguenther/src/gcc/gcc/fortran/trans.cc:2363
0xee8bdf gfc_trans_code(gfc_code*)
/space/rguenther/src/gcc/gcc/fortran/trans.cc:2718
0xf34d1b gfc_generate_function_code(gfc_namespace*)
/space/rguenther/src/gcc/gcc/fortran/trans-decl.cc:7879

[Bug libstdc++/77776] C++17 std::hypot implementation is poor

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

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

--- Comment #22 from Matthias Kretz (Vir)  ---
I took your hypot3_scale and reduced latency and throughput. I don't think the
sqrtmax/sqrtmin limits are correct (sqrtmax² * 3 -> infinity).

  TYPE  Latency Speedup Throughput
Speedup 
  [cycles/call] [per value]  [cycles/call] [per
value]  
 float,46.5   1   12.7 
 1  
 float, hypot3_scale   35.51.31 27 
  0.47  
 float, hypot3_mkretz  30.21.54 12 
  1.06  
--
 
  TYPE  Latency Speedup Throughput
Speedup 
  [cycles/call] [per value]  [cycles/call] [per
value]  
double,59.6   1 60 
 1  
double, hypot3_scale   51.21.16   48.8 
  1.23  
double, hypot3_mkretz  40.11.49 35 
  1.71


template 
  constexpr T 
  hypot(T x, T y, T z)
  { 
using limits = std::numeric_limits;

auto prev_power2 = [](const T value) constexpr noexcept -> T 
{ 
  return std::exp2(std::floor(std::log2(value)));
};

constexpr T sqrtmax = std::sqrt(limits::max());
constexpr T sqrtmin = std::sqrt(limits::min());
constexpr T scale_up = prev_power2(sqrtmax);
constexpr T scale_down = T(1) / scale_up;
constexpr T zero = 0;

if (not (std::isnormal(x) && std::isnormal(y) && std::isnormal(z)))
[[unlikely]]
  { 
if (std::isinf(x) | std::isinf(y) | std::isinf(z))
  return limits::infinity();
else if (std::isnan(x) | std::isnan(y) | std::isnan(z))
  return limits::quiet_NaN();
const bool xz = x == zero;
const bool yz = y == zero;
const bool zz = z == zero;
if (xz)
  { 
if (yz)
  return zz ? zero : z;
else if (zz)
  return y;
  } 
else if (yz && zz)
  return x;
  } 

x = std::abs(x);
y = std::abs(y);
z = std::abs(z);

T a = std::max(std::max(x, y), z);
T b = std::min(std::max(x, y), z);
T c = std::min(x, y);

if (a >= sqrtmin && a <= sqrtmax) [[likely]]
  return std::sqrt(__builtin_assoc_barrier(c * c + b * b) + a * a);

const T scale = a >= sqrtmin ? scale_down : scale_up;

a *= scale;
b *= scale;
c *= scale;

return std::sqrt(__builtin_assoc_barrier(c * c + b * b) + a * a) / scale;
  }

[Bug sanitizer/112709] [13/14 Regression] address sanitize and returns_twice causes an ICE

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

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

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

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

commit r14-9438-gad860cc27b3312f9119c7fecb8638a7c1f6d77c9
Author: Jakub Jelinek 
Date:   Tue Mar 12 11:34:50 2024 +0100

asan: Instrument  stores in callees rather than callers [PR112709]

asan currently instruments since PR69276 r6-6758 fix calls which store
the return value into memory on the caller side, before the call it
verifies the memory is writable.
Now PR112709 where we ICE on trying to instrument such calls made me
think about whether that is what we want to do.

There are 3 different cases.

One is when a function returns an aggregate which is passed e.g. in
registers, say like struct S { int a[4]; }; returning on x86_64.
That would be ideally instrumented in between the actual call and
storing of the aggregate into memory, but asan currently mostly
works as a GIMPLE pass and arranging for the instrumentation to happen
at that spot would be really hard.  We could diagnose after the call
but generally asan attempts to diagnose stuff before something is
overwritten rather than after, or keep the current behavior (that is
what this patch does, which has the disadvantage that it can complain
about UB even for functions which never return and so never actually store,
and doesn't check whether the memory wasn't e.g. poisoned during the call)
or could e.g. instrument both before and after the call (that would have
the disadvantage the current state has but at least would check post-factum
the store again afterwards).

Another case is when a function returns an aggregate through a hidden
reference, struct T { int a[128]; }; on x86_64 or even the above struct S
on ia32 as example.  In the actual program such stores happen when storing
something to  or its parts in the callee, because  there
expands to *hidden_retval.  So, IMHO we should instrument those in the
callee rather than caller, that is where the writes are and we can do that
easily.  This is what the patch below does.

And the last case is for builtins/internal functions.  Usually those don't
return aggregates, but in case they'd do and can be expanded inline, it is
better to instrument them in the caller (as before) rather than not
instrumenting the return stores at all.

I had to tweak the expected output on the PR69276 testcase, because
with the patch it keeps previous behavior on x86_64 (structure returned
in registers, stored in the caller, so reported as UB in A::A()),
while on i686 it changed the behavior and is reported as UB in the
vnull::operator vec which stores the structure, A::A() is then a frame
above it in the backtrace.

2024-03-12  Jakub Jelinek  

PR sanitizer/112709
* asan.cc (has_stmt_been_instrumented_p): Don't instrument call
stores on the caller side unless it is a call to a builtin or
internal function or function doesn't return by hidden reference.
(maybe_instrument_call): Likewise.
(instrument_derefs): Instrument stores to RESULT_DECL if
returning by hidden reference.

* gcc.dg/asan/pr112709-1.c: New test.
* g++.dg/asan/pr69276.C: Adjust expected output for some targets.

[Bug tree-optimization/114151] [14 Regression] weird and inefficient codegen and addressing modes since r14-9193

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

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

--- Comment #20 from Richard Biener  ---
Created attachment 57681
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57681=edit
patch for context sensitive range during SCEV

This is the patch I was playing with.

[Bug tree-optimization/114151] [14 Regression] weird and inefficient codegen and addressing modes since r14-9193

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

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

--- Comment #19 from Richard Biener  ---
So what remains here is differences like

-  (chrec = {(long unsigned int) (col_stride_10 * _105), +, (long unsigned int)
col_stride_10}_2)
+  (chrec = (long unsigned int) (int) {(unsigned int) col_stride_10 * (unsigned
int) _105, +, (unsigned int) col_stride_10}_2)

where we can't pull the sign-extension inside the CHREC because it might
overflow.

And

 (set_scalar_evolution 
   instantiated_below = 22 
   (scalar = _59)
-  (scalar_evolution = {(long unsigned int) (col_stride_10 * _105) * 2, +,
(long unsigned int) col_stride_10 * 2}_2))
+  (scalar_evolution = _59))
+)

which is failure to analyze at all.  This one looks like

   [local count: 118111600]:
  # col_stride_10 = PHI 
  if (size_15(D) > 0)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 118111600]:
  return;
...
   [local count: 343854870]:
  # RANGE [irange] int [0, 2147483646]
  # j_73 = PHI <_105(22), _68(19)>
...
  col_i_61 = col_stride_10 * j_73;
  # RANGE [irange] long unsigned int [0, 2147483647][18446744071562067968,
+INF]
  _60 = (long unsigned int) col_i_61;
  # RANGE [irange] long unsigned int [0, 4294967294][18446744069414584320,
18446744073709551614] MASK 0xfffe VALUE 0x0
  _59 = _60 * 2;

j_73 is {_105, +, 1}_2
col_i_61 is (int) {(unsigned int) col_stride_10 * (unsigned int) _105, +,
(unsigned int) col_stride_10}_2
_60 is (long unsigned int) (int) {(unsigned int) col_stride_10 * (unsigned int)
_105, +, (unsigned int) col_stride_10}_2

and on the _60 * 2 multiply we fail.  When applying Andrews proposed patch
this doesn't help since the range of col_stride_10 can only conditionally
be adjusted to positive.

SCEV caches a scalar evolution based on SSA_NAME and 'instantiated below'
block which is "block_before_loop" which is a loops preheader or the
function ENTRY block for analyses of scalars in the loop tree root.
A conservative context for analysis of the SCEV might be
 1) the definition stmt of the SSA name
 2) the instantiated-below block (on-exit ranges of it)

With doing 2) by feeding the last stmt of the block as context (when the
block is empty that won't work :/) the testcase is optimized again when
I discard the SCEV cache at the start of IVOPTs and wrap IVOPTs in a
ranger instance.

While ranger has a range_on_exit API this doesn't work on GENERIC expressions
as far as I can see but only SSA names but I guess that could be "fixed"
given range_on_exit also looks at the last stmt and eventually defers to
range_of_expr (or range_on_entry), but possibly get_tree_range needs
variants for on_entry/on_exit (it doesn't seem to use it's 'stmt' context
very consistently, notably not for SSA_NAMEs ...).

Interestingly enough we somehow still need the

diff --git a/gcc/gimple-range.cc b/gcc/gimple-range.cc
index c16b776c1e3..c0eda5fc51d 100644
--- a/gcc/gimple-range.cc
+++ b/gcc/gimple-range.cc
@@ -102,7 +102,15 @@ gimple_ranger::range_of_expr (vrange , tree expr, gimple
*stmt)
   if (!stmt)
 {
   Value_Range tmp (TREE_TYPE (expr));
-  m_cache.get_global_range (r, expr);
+  // If there is no global range for EXPR yet, try to evaluate it.
+  // THis call does set R to a global range regardless.
+  if (!m_cache.get_global_range (r, expr))
+   {
+ gimple *s = SSA_NAME_DEF_STMT (expr);
+ // Calculate a range for S if it is safe to do so.
+ if (s && gimple_bb (s) && gimple_get_lhs (s) == expr)
+   return range_of_stmt (r, s);
+   }
   // Pick up implied context information from the on-entry cache
   // if current_bb is set.  Do not attempt any new calculations.
   if (current_bb && m_cache.block_range (tmp, current_bb, expr, false))

hunk of Andrews patch to do it :/

There's one other detail - the problematical multiply folding is
col_stride_10 * {_105, +, 1}_2
I'm thinking that similar to CHREC_LEFT == 0 we can handle CHREC_RIGHT == 1
without unsigned promotion.  In the second iteration we are replacing
(_105 + 1) * col_stride_10 with _105 * col_stride_10 + col_stride_10
but we know already that _105 * col_stride_10 doesn't overflow as we
computed that in the first iteration.  And 1 * X never overflows.
The third iteration is problematic - we don't know whether 2 * col_stride_10
overflows if _105 was zero, if it was not it might have been -1 which
means the second iteration computed 0 * col_stride_10 originally.  Hmm,
so _105 == -1 is problematic, so no - I don't think we can handle
CHREC_RIGHT == 1 specially.

[Bug libstdc++/114316] assert failure with _GLIBCXX_DEBUG and empty range of singular iterators passed to std:: algorithm

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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