[Bug target/113155] large overhead for cast float to uint64_t. Arm cortex-m4 (ARMv7E-M, fpv4-sp-d16, ieee 754). Compiler: arm-none-eabi-gcc

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

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

--- Comment #3 from Andrew Pinski  ---
Can you provide the following:
* How you configured/built GCC?
* What command line options that you pass to GCC for building your application?

I am suspecting you are not using the correct options to get the  __aeabi_f2ulz
that does not convert to double first.

[Bug target/113155] large overhead for cast float to uint64_t. Arm cortex-m4 (ARMv7E-M, fpv4-sp-d16, ieee 754). Compiler: arm-none-eabi-gcc

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2023-12-27

--- Comment #2 from Andrew Pinski  ---
>The current version cannot be used for embedded systems.

I am thinking you don't have the multilibs set up correctly.

How did you configure GCC here?

[Bug target/113155] large overhead for cast float to uint64_t. Arm cortex-m4 (ARMv7E-M, fpv4-sp-d16, ieee 754). Compiler: arm-none-eabi-gcc

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

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

--- Comment #1 from Andrew Pinski  ---
I looked into the sources of libgcc, __aeabi_f2ulz is defined as __fixunssfdi
which is defined in soft-fp/fixunssfdi.c and that does:
```
UDItype
__fixunssfdi (SFtype a)
{
  FP_DECL_EX;
  FP_DECL_S (A);
  UDItype r;

  FP_INIT_EXCEPTIONS;
  FP_UNPACK_RAW_S (A, a);
  FP_TO_INT_S (r, A, DI_BITS, 0);
  FP_HANDLE_EXCEPTIONS;

  return r;
}
```

FP_TO_INT_S is defined to _FP_TO_INT which basically does what you want except
it can handle FP exceptions.

[Bug target/113155] large overhead for cast float to uint64_t. Arm cortex-m4 (ARMv7E-M, fpv4-sp-d16, ieee 754). Compiler: arm-none-eabi-gcc

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization
  Component|libgcc  |target

[Bug libgcc/113155] New: large overhead for cast float to uint64_t. Arm cortex-m4 (ARMv7E-M, fpv4-sp-d16, ieee 754). Compiler: arm-none-eabi-gcc

[kirdyankinsp at gmail dot com via Gcc-bugs]

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

Bug ID: 113155
   Summary: large overhead for cast float to uint64_t. Arm
cortex-m4 (ARMv7E-M, fpv4-sp-d16, ieee 754). Compiler:
arm-none-eabi-gcc
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kirdyankinsp at gmail dot com
  Target Milestone: ---

To cast float to uint64 the initial value first converted to double. Cortex-M4
does not have hardware support for "double". Therefore, such an implementation
adds several kilobytes of code, which is unacceptable for embeded systems with
limited resources. In addition, increasing the code size is, of course, low
performance.
I think it is necessary to separate the softfloat functions for platforms that
have hardware "float" support and do not have a hardware "double". The current
version cannot be used for embedded systems. Additional functions need to be
written.
Below is the __aeabi_f2ulz code for fpv4-sp-d16 (ieee 754):

uint64_t __aeabi_f2ulz(float f)
{
  uint32_t result = *((uint32_t*) );
  uint32_t exp;
  result &= (~0x8000);
  exp = result >> 23;
  result &= 0x7F;
  result |= 0x80;
#if CHECK_UB
  if (exp == 0xFF) // if NaN or inf
  {
return 0x8000; // 
  }
  if(exp > (0x96 + 40)) // if the variable value is too large
  {
return 0x8000; // 
  }
#endif
  if (exp < 0x7F)
  {
return 0;
  }
  if (exp <= 0x96U)
  {
exp = 0x96 - exp;
result >>= exp;
return (uint64_t) result;
  }
  exp -= 0x96U;
  return (uint64_t) result << exp;
}

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

[sean--- via Gcc-bugs]

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

Sean  changed:

   What|Removed |Added

 CC||s...@rogue-research.com

--- Comment #49 from Sean  ---
>>will you support expressions:
>>
>>struct P {
>>  int k;
>>  int x[.k * 4];
>>}
> 
>Maybe the size expressions should be limited to very simple
>expressions without side effects.

Simple expressions without side effects would be useful for libusb, whose
public API has structures like:

struct libusb_bos_dev_capability_descriptor {
/** Size of this descriptor (in bytes) */
uint8_t  bLength;

uint8_t  other1;
uint8_t  other2;

/** Device Capability data (bLength - 3 bytes) */
uint8_t  dev_capability_data[];
};

Here it seems we'd want to tag it with __attribute__((__element_count__(bLength
- 3)));

See
https://github.com/libusb/libusb/blob/37dee8f9dd429558e4d5bc4a804ab586abe7262a/libusb/libusb.h#L859C1-L859C51

[Bug go/113143] Remove usage of ucontext.h

[kallisti5 at unixzen dot com via Gcc-bugs]

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

--- Comment #9 from Alexander von Gluck  ---
Doing a little research, it looks like complaints of ucontext.h have come up
before multiple times:

Similar issue on OpenBSD a long time ago:
https://gcc-help.gcc.gnu.narkive.com/Xx1bResV/can-t-build-go-support-in-gcc-4-8-1-on-openbsd

muslc not supporting ucontext.h:
https://wiki.musl-libc.org/open-issues

(and a long list of google results)


I guess the root questions of this bug are:

1. Should any and all references to ucontext.h be wrapped with a HAVE macro?
(this seems to be what most folks do).   Since (get/set/swap)context don't seem
to be called on non-BSD platforms, this seems possible?

2. Should libgo double down and implement processor-specific calls for each
architecture as called out by Ian in the above thread in 2013?

"It's possible to fix this by writing processor-dependent functions
that would serve the same purpose as the *context functions, and in
fact that would be more efficient. But I have not actually done this."

3. Is the expectation that all platforms which libgo targets include ucontext.h
compatibility libraries for calls no-longer standard in the posix
specifications since 2008.   (muslc pushed against this... i'd be interested if
libgo compiles under musl systems)

[Bug go/113143] Remove usage of ucontext.h

[kallisti5 at unixzen dot com via Gcc-bugs]

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

--- Comment #8 from Alexander von Gluck  ---
Not at all a dumb question :-)

I'm working through compiling libgo / gccgo on Haiku.We have our own lovely
libc which tests posix compliant.

Some historic consideration behind us not having ucontext.h is here:
https://dev.haiku-os.org/ticket/5324

We have around 3000 ports (including an old (c)go 1.4, rust, gcc, ruby, etc)
none of which have complained about a missing ucontext.h.  This is kinda why I
feel like it's an anti-pattern to require it in libgo.

Even Google's go doesn't consider ucontext.h a requirement on non-bsd
platforms.


Here's the guys of our libc for context:
https://cgit.haiku-os.org/haiku/tree/headers/posix

[Bug libstdc++/113154] [11 only] std::views::values not working with rvalue references to ranges

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.5
Summary|std::views::values not  |[11 only]
   |working with rvalue |std::views::values not
   |references to ranges|working with rvalue
   ||references to ranges
   Keywords||needs-bisection
  Component|c++ |libstdc++

--- Comment #1 from Andrew Pinski  ---
I doubt, the patch which fixed this can/will be backported to the GCC 11
releases.

[Bug c++/113153] suboptimal error message when using reserved identifier and `enum class`

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|suboptimal error message|suboptimal error message
   |when using reserved |when using reserved
   |identifier  |identifier and `enum class`
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-12-27

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

[Bug go/113143] Remove usage of ucontext.h

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

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

--- Comment #7 from Andrew Pinski  ---
Let me ask a dumb question, are you porting GCC/gccgo to a libc which does not
have ucontext.h ?  If so what is the libc my I ask?

[Bug c++/113153] suboptimal error message when using reserved identifier

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

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

--- Comment #2 from Andrew Pinski  ---
If you remove the class, GCC has a decent error message:
```
:1:11: error: expected identifier before 'register'
1 | enum  register { rax, rcx, rdx, rbx };
  |   ^~~~
```

[Bug c++/113153] suboptimal error message when using reserved identifier

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

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


Note clang is just as bad:
```
:1:16: error: expected identifier or '{'
1 | enum class register { rax, rcx, rdx, rbx };
  |^
1 error generated.
```

EDG/ICC is slightly better:
```
(1): error: expected an identifier
  enum class register { rax, rcx, rdx, rbx };
 ^
```

MSVC is bad too:
```
(1): error C2332: 'enum': missing tag name
(1): error C2059: syntax error: 'function-style cast'
(1): error C2143: syntax error: missing ';' before '{'
(1): error C2447: '{': missing function header (old-style formal list?)
```

[Bug c++/113154] New: std::views::values not working with rvalue references to ranges

[ivan.lazaric.gcc at gmail dot com via Gcc-bugs]

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

Bug ID: 113154
   Summary: std::views::values not working with rvalue references
to ranges
   Product: gcc
   Version: 11.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ivan.lazaric.gcc at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/a3c4P9sY6

```
#include 
#include 

void fn(){
std::map m;
m | std::views::values; // works
std::map{} | std::views::values; // does not work

}
```

not an issue in newer versions, checked 13.2 and it worked

came across this by wanting to do:
```
std::map produce_map();

std::cout << std::ranges::max(produce_map | std::views::values) << std::endl;
```

options used: -std=c++20 -O3

[Bug go/113143] Remove usage of ucontext.h

[kallisti5 at unixzen dot com via Gcc-bugs]

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

--- Comment #6 from Alexander von Gluck  ---
For added clairity. Searching the upstream go sources:

```
 grep -R getcontext
src/cmd/vendor/golang.org/x/sys/unix/syscall_netbsd.go:// getcontext
src/cmd/vendor/golang.org/x/sys/unix/zsysnum_freebsd_386.go:SYS_GETCONTEXT 
 = 421 // { int getcontext(struct __ucontext *ucp); }
src/cmd/vendor/golang.org/x/sys/unix/zsysnum_freebsd_amd64.go:  SYS_GETCONTEXT 
 = 421 // { int getcontext(struct __ucontext *ucp); }
src/cmd/vendor/golang.org/x/sys/unix/zsysnum_freebsd_arm.go:SYS_GETCONTEXT 
 = 421 // { int getcontext(struct __ucontext *ucp); }
src/cmd/vendor/golang.org/x/sys/unix/zsysnum_freebsd_arm64.go:  SYS_GETCONTEXT 
 = 421 // { int getcontext(struct __ucontext *ucp); }
src/cmd/vendor/golang.org/x/sys/unix/zsysnum_netbsd_386.go: SYS_GETCONTEXT 
 = 307 // { int|sys||getcontext(struct __ucontext *ucp); }
src/cmd/vendor/golang.org/x/sys/unix/zsysnum_netbsd_amd64.go:   SYS_GETCONTEXT 
 = 307 // { int|sys||getcontext(struct __ucontext *ucp); }
src/cmd/vendor/golang.org/x/sys/unix/zsysnum_netbsd_arm.go: SYS_GETCONTEXT 
 = 307 // { int|sys||getcontext(struct __ucontext *ucp); }
src/cmd/vendor/golang.org/x/sys/unix/zsysnum_netbsd_arm64.go:   SYS_GETCONTEXT 
 = 307 // { int|sys||getcontext(struct __ucontext *ucp); }
src/runtime/cgo/gcc_solaris_amd64.c:if (getcontext() != 0)
src/runtime/cgo/gcc_solaris_amd64.c:perror("runtime/cgo: getcontext
failed");
src/runtime/os3_solaris.go://go:cgo_import_dynamic libc_getcontext getcontext
"libc.so"
src/runtime/os3_solaris.go://go:linkname libc_getcontext libc_getcontext
src/runtime/os3_solaris.go: libc_getcontext,
src/runtime/os3_solaris.go:func getcontext(context *ucontext) /* int32 */ {
src/runtime/os3_solaris.go: sysvicall1(_getcontext,
uintptr(unsafe.Pointer(context)))
src/runtime/os_netbsd.go:func getcontext(ctxt unsafe.Pointer)
src/runtime/os_netbsd.go:   getcontext(unsafe.Pointer())
src/runtime/sys_netbsd_386.s:#define SYS_getcontext 307
src/runtime/sys_netbsd_386.s:TEXT runtime·getcontext(SB),NOSPLIT,$-4
src/runtime/sys_netbsd_386.s:   MOVL$SYS_getcontext, AX
src/runtime/sys_netbsd_amd64.s:#define SYS_getcontext   307
src/runtime/sys_netbsd_amd64.s:TEXT runtime·getcontext(SB),NOSPLIT,$-8
src/runtime/sys_netbsd_amd64.s: MOVL$SYS_getcontext, AX
src/runtime/sys_netbsd_arm.s:#define SYS_getcontext
SWI_OS_NETBSD | 307
src/runtime/sys_netbsd_arm.s:TEXT runtime·getcontext(SB),NOSPLIT|NOFRAME,$0
src/runtime/sys_netbsd_arm.s:   SWI $SYS_getcontext
src/runtime/sys_netbsd_arm64.s:#define SYS_getcontext   307
src/runtime/sys_netbsd_arm64.s:TEXT runtime·getcontext(SB),NOSPLIT,$-8
src/runtime/sys_netbsd_arm64.s: SVC $SYS_getcontext
src/syscall/zsysnum_freebsd_386.go: SYS_GETCONTEXT   = 421 // {
int getcontext(struct __ucontext *ucp); }
src/syscall/zsysnum_freebsd_amd64.go:   SYS_GETCONTEXT   = 421 // {
int getcontext(struct __ucontext *ucp); }
src/syscall/zsysnum_freebsd_arm.go: SYS_GETCONTEXT   = 421 // {
int getcontext(struct __ucontext *ucp); }
src/syscall/zsysnum_freebsd_arm64.go:   SYS_GETCONTEXT   = 421 // {
int getcontext(struct __ucontext *ucp); }
src/syscall/zsysnum_netbsd_386.go:  SYS_GETCONTEXT   = 307 // {
int|sys||getcontext(struct __ucontext *ucp); }
src/syscall/zsysnum_netbsd_amd64.go:SYS_GETCONTEXT   = 307 // {
int|sys||getcontext(struct __ucontext *ucp); }
src/syscall/zsysnum_netbsd_arm.go:  SYS_GETCONTEXT   = 307 // {
int|sys||getcontext(struct __ucontext *ucp); }
src/syscall/zsysnum_netbsd_arm64.go:SYS_GETCONTEXT   = 307 // {
int|sys||getcontext(struct __ucontext *ucp); }
```

Those all appear to be BSD-specific references, unless i'm missing an
invocation of (get|set|swap)context somewhere?

[Bug go/113143] Remove usage of ucontext.h

[kallisti5 at unixzen dot com via Gcc-bugs]

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

--- Comment #5 from Alexander von Gluck  ---
> I understand that makecontext/getcontext/setcontext were removed from POSIX. 
> However, there is no adequate replacement.  Their functionality is absolutely 
> required for what libgo does.

No Linux-specific code calls these in gccgo, or upstream go.  Only FreeBSD,
Solaris, and OpenBSD.

Thus my question, why is ucontext.h referenced in cross-platform code when
signal.h will suffice?

[Bug c++/113153] New: suboptimal error message when using reserved identifier

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

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

Bug ID: 113153
   Summary: suboptimal error message when using reserved
identifier
   Product: gcc
   Version: 13.2.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: ---

When using a keyword as the name of an enum, gcc will issue a diagnostic about
the enum being "unnamed". This can be very confusing:

enum class register { rax, rcx, rdx, rbx };

compiled with -std=c++23 produces

error: unnamed scoped enum is not allowed
1 | enum class register {};
  |^~~~
warning: elaborated-type-specifier for a scoped enum must not use the 'class'
keyword
1 | enum class register {};
  |  ^
  |  -
error: expected identifier before 'register'
1 | enum class register {};
  |^~~~
error: expected unqualified-id before '{' token
1 | enum class register {};
  | ^

https://godbolt.org/z/s1ocevaWe

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

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

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Created attachment 56953
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56953=edit
test program

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

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

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Created attachment 56952
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56952=edit
file that git cannot find

Put in libgfortran/intrinsics

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

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

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Created attachment 56951
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56951=edit
file that git cannot find

Put file in libgfortran/intrinsics

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

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

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

--- Comment #1 from kargl at gcc dot gnu.org ---
Created attachment 56950
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56950=edit
new file that git cannot diff

Put file in libgfortran/intrinsics.

[Bug fortran/113152] New: Fortran 2023 half-cycle trigonometric functions

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

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

Bug ID: 113152
   Summary: Fortran 2023 half-cycle trigonometric functions
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 56949
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56949=edit
patch with implementation

The attach patch implements the half-cycle trigonometric functions that
are now contained within Fortran 2023.  There a few things to note.

1) IEEE 754-2008, ISO/IEC TS 18661-4, C23, and Fortran 2023 all contain
   these functions.  This likely means that the functions acospi(), asinpi(),
   ..., tanpi() may be available as part of an operating system's libm.  In
   fact, FreeBSD has implementations of cospi, sinpi, and tanpi in libm, and
   these conform to the requirements of IEEE 754-2008 and ISO/IEC TS 18661-4.
   The file libgfortran/intrinsics/trigpi_fallback1.c provides fallbacks for
   float, double, and long double functions.  As I don't know the internals
   for libquadmath or ibm double-double, the REAL(16) (and GFC_REAL_17)
   fallback functions are in libgfortran/intrinsics/trigpi_fallback1.F90.
   I have tested REAL(16) that sits on top of libquadmath.  I have not tested
   the double-double situation.  Finally, the fallback functions do not go
   to any length in meeting all of the requirements of IEEE 754-2008. For
   example, sinpi(n+0.5) is exactly +-1 for representable integer n.  The
   fallbacks may raise an FE_INEXACT exception. 

2) I tried adding math builtins in gcc/fortran/mathbuiltins.def to directly
   map to libm functions, but this ultimately led to much frustration.  I gave
   up and wrap, for example, cospi() in _gfortran_cospi_r8().  So, there is a
   level of in-direction.  This is done in libgfortran/intrinsics/trigpi.c.
   Someone smarter than I can do the math builtins.

3) I tried inserting GFC_ISYM_ACOSPI, ..., GFC_ISYM_TANPI in alphabetical
   order in 'enum gfc_isym_id' of gfortran.h.  This runs into some obscure
   issue with libgomp where C_ASSOCIATED is no longer recognized.  So, I
   placed the new members of the enum at its end.

4) I don't use git.  I tried to do 'git add libgfortran/intrinsics/trigpi\*'
   followed by 'git commit libgfortran/intrinsics/trigpi\*', and then 
   finally 'git diff > z_halfcycle.diff'.  This does not generate one 
   unified diff file.  Sigh.  I'll attach the new files along with the
   mangled diff.

[Bug go/113143] Remove usage of ucontext.h

[ian at airs dot com via Gcc-bugs]

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

--- Comment #4 from Ian Lance Taylor  ---
I understand that makecontext/getcontext/setcontext were removed from POSIX.
However, there is no adequate replacement.  Their functionality is absolutely
required for what libgo does.  Fortunately GNU/Linux systems continue to
provide them.

[Bug target/113148] [14 Regression] ICE: maximum number of generated reload insns per insn achieved

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

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

Xi Ruoyao  changed:

   What|Removed |Added

   Priority|P3  |P1
Summary|14.0 ICE: maximum number of |[14 Regression] ICE:
   |generated reload insns per  |maximum number of generated
   |insn achieved   |reload insns per insn
   ||achieved

[Bug target/113148] 14.0 ICE: maximum number of generated reload insns per insn achieved

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

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

--- Comment #4 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #3)
> Patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641443.html

I've successfully built Xwayland with patched GCC.

[Bug target/113148] 14.0 ICE: maximum number of generated reload insns per insn achieved

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

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

Xi Ruoyao  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-Decembe
   ||r/641443.html
   Keywords||patch

--- Comment #3 from Xi Ruoyao  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641443.html

[Bug analyzer/112792] -Wanalyzer-out-of-bounds false positives seen on Linux kernel with certain unions

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

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

--- Comment #4 from David Malcolm  ---
Should be fixed on trunk by r14-6622-g5f1bed2a7af828103ca23a3546466a23e8dd2f30

Keeping open to track backporting to GCC 13.

[Bug sanitizer/113151] Need for a TBAA / strict aliasing sanitizer (TySan)

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Severity|normal  |enhancement
   Last reconfirmed||2023-12-26
 Status|UNCONFIRMED |NEW

--- Comment #1 from Xi Ruoyao  ---
Confirm as I like this idea very much.  At least it would prevent many invalid
bug reports :).

[Bug target/113148] 14.0 ICE: maximum number of generated reload insns per insn achieved

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

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

--- Comment #2 from Xi Ruoyao  ---
A bug in loongarch_secondary_reload is causing an infinite loop:

diff --git a/gcc/config/loongarch/loongarch.cc
b/gcc/config/loongarch/loongarch.cc
index 5ffd06ce9be..c0a0af3dda5 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -6951,7 +6951,8 @@ loongarch_secondary_reload (bool in_p ATTRIBUTE_UNUSED,
rtx x,
  return NO_REGS;
}

-  if (reg_class_subset_p (rclass, FP_REGS) && MEM_P (x))
+  if (reg_class_subset_p (rclass, FP_REGS)
+ && (regno == -1 || MEM_P (x)))
return GR_REGS;

   return NO_REGS;

[Bug target/113148] 14.0 ICE: maximum number of generated reload insns per insn achieved

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

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

Xi Ruoyao  changed:

   What|Removed |Added

   Last reconfirmed||2023-12-26
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Xi Ruoyao  ---
Confirmed.

[Bug other/113147] Building a crosscompiler fails under MigW-W64/MSYS2 @ Windows 10

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

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

--- Comment #1 from Andrew Pinski  ---
# Use the "pic" build of libiberty if --enable-host-shared or
--enable-host-pie,
# unless we are building for mingw.
LIBIBERTY_PICDIR=$(if $(findstring mingw,$(target)),,pic)
ifneq ($(enable_host_shared)$(enable_host_pie),)
LIBIBERTY = ../libiberty/$(LIBIBERTY_PICDIR)/libiberty.a
else
LIBIBERTY = ../libiberty/libiberty.a
endif
ifeq ($(enable_host_shared),yes)
BUILD_LIBIBERTY = $(build_libobjdir)/libiberty/$(LIBIBERTY_PICDIR)/libiberty.a
else
BUILD_LIBIBERTY = $(build_libobjdir)/libiberty/libiberty.a
endif


Don't use `--disable-host-shared` basically.
Though the above check for mingw really should be the host rather than the
target ...

[Bug c/80130] Wrong diagnostic: dereferencing type-punned pointer

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

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

--- Comment #6 from Sam James  ---
I filed a bug for tysan: PR113151.

[Bug sanitizer/113151] New: Need for a TBAA / strict aliasing sanitizer (TySan)

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

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

Bug ID: 113151
   Summary: Need for a TBAA / strict aliasing sanitizer (TySan)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org,
marxin at gcc dot gnu.org, xry111 at gcc dot gnu.org
  Target Milestone: ---

It's well-known that -Wstrict-aliasing in GCC has false negatives and is also
easy to confuse/bypass. Aliasing is a common footgun and it's hard because this
is one of the few things that compilers optimise on which UBsan and friends are
no help for.

Ultimately, that's not really the fault of the warning, the fact is some of
this stuff can only really be done at runtime.

LLVM has had stalled and stop-start attempts at this a bunch of times, although
I noticed earlier today that some new PRs got opened for it. They plan on
calling it Type Sanitizer (TySan) with -fsanitize=type. See linked PRs.

(I feel like we must have a bug for this somewhere but I couldn't find it.)

[Bug analyzer/113150] New: FAIL: c-c++-common/analyzer/fd-glibc-byte-stream-socket.c -std=c++98 (test for excess errors)

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

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

Bug ID: 113150
   Summary: FAIL:
c-c++-common/analyzer/fd-glibc-byte-stream-socket.c
-std=c++98 (test for excess errors)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

Created attachment 56948
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56948=edit
Preprocessed source

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../xg++
-B
/home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../
/home/dave/gnu/gcc/gcc/gcc/
testsuite/c-c++-common/analyzer/fd-glibc-byte-stream-socket.c
-fdiagnostics-plai
n-output -nostdinc++
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0
-std=c++98 -fanalyzer -Wanalyzer-too-complex -fanalyzer-call-summaries -S -o
fd-glibc-byte-stream-socket.s
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/analyzer/fd-glibc-byte-stream-socket.c:
In function 'int main()':
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/analyzer/fd-glibc-byte-stream-socket.c:42:17:
warning: leak of file descriptor 'socket(2, 1, 0)' [CWE-775]
[-Wanalyzer-fd-leak]
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/analyzer/fd-glibc-byte-stream-socket.c:42:17:
note: (1) socket created here
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/analyzer/fd-glibc-byte-stream-socket.c:42:17:
note: (2) when 'socket' succeeds
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/analyzer/fd-glibc-byte-stream-socket.c:42:17:
note: (3) 'socket(2, 1, 0)' leaks here
FAIL: c-c++-common/analyzer/fd-glibc-byte-stream-socket.c  -std=c++98 (test for
excess errors)
Excess errors:
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/analyzer/fd-glibc-byte-stream-socket.c:42:17:
warning: leak of file descriptor 'socket(2, 1, 0)' [CWE-775]
[-Wanalyzer-fd-leak]

I tried modifying the test to close sock, but that didn't help.  _exit() didn't
work either.

Similar g++ fails:
FAIL: c-c++-common/analyzer/fd-glibc-byte-stream-socket.c  -std=c++14 (test for
excess errors)
FAIL: c-c++-common/analyzer/fd-glibc-byte-stream-socket.c  -std=c++17 (test for
excess errors)
FAIL: c-c++-common/analyzer/fd-glibc-byte-stream-socket.c  -std=c++20 (test for
excess errors)
FAIL: c-c++-common/analyzer/fd-manpage-getaddrinfo-client.c  -std=c++98 (test
for excess errors)
FAIL: c-c++-common/analyzer/fd-manpage-getaddrinfo-client.c  -std=c++14 (test
for excess errors)
FAIL: c-c++-common/analyzer/fd-manpage-getaddrinfo-client.c  -std=c++17 (test
for excess errors)
FAIL: c-c++-common/analyzer/fd-manpage-getaddrinfo-client.c  -std=c++20 (test
for excess errors)
FAIL: c-c++-common/analyzer/fd-mappage-getaddrinfo-server.c  -std=c++98 (test
for excess errors)
FAIL: c-c++-common/analyzer/fd-mappage-getaddrinfo-server.c  -std=c++14 (test
for excess errors)
FAIL: c-c++-common/analyzer/fd-mappage-getaddrinfo-server.c  -std=c++17 (test
for excess errors)
FAIL: c-c++-common/analyzer/fd-mappage-getaddrinfo-server.c  -std=c++20 (test
for excess errors)
FAIL: c-c++-common/analyzer/fd-symbolic-socket.c  -std=c++98 (test for excess
errors)
FAIL: c-c++-common/analyzer/fd-symbolic-socket.c  -std=c++14 (test for excess
errors)
FAIL: c-c++-common/analyzer/fd-symbolic-socket.c  -std=c++17 (test for excess
errors)
FAIL: c-c++-common/analyzer/fd-symbolic-socket.c  -std=c++20 (test for excess
errors)

[Bug target/113149] Function multiversioning prefers arch=x86-64-v3 to actual processors

[ed at catmur dot uk via Gcc-bugs]

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

--- Comment #1 from Ed Catmur  ---
>From b4ca8bf55100eddeaa14a52f1bc8e73fac565d83 Mon Sep 17 00:00:00 2001
From: Ed Catmur 
Date: Tue, 26 Dec 2023 11:46:26 -0600
Subject: [PATCH] Swap P_PROC_AVX2 with P_X86_64_V3, etc.

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

Any processor with feature priority P_PROC_AVX2 necessarily supports at least
all of the x86-64-v3 psABI level, but almost certainly supports more
instructions; e.g. Haswell supports pclmul and rdrnd. So if there are
multiversion targets for arch=x86-64-v3 and e.g. arch=haswell, the target for
the specific processor should be preferred.

Similarly, swap P_PROC_AVX512F with P_X86_64_V4.
---
 gcc/common/config/i386/i386-cpuinfo.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/common/config/i386/i386-cpuinfo.h
b/gcc/common/config/i386/i386-cpuinfo.h
index 38fa7650de28f..593d71626e440 100644
--- a/gcc/common/config/i386/i386-cpuinfo.h
+++ b/gcc/common/config/i386/i386-cpuinfo.h
@@ -141,11 +141,11 @@ enum feature_priority
   P_PROC_FMA,
   P_BMI2,
   P_AVX2,
-  P_PROC_AVX2,
   P_X86_64_V3,
+  P_PROC_AVX2,
   P_AVX512F,
-  P_PROC_AVX512F,
   P_X86_64_V4,
+  P_PROC_AVX512F,
   P_PROC_DYNAMIC
 };

[Bug target/113149] New: Function multiversioning prefers arch=x86-64-v3 to actual processors

[ed at catmur dot uk via Gcc-bugs]

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

Bug ID: 113149
   Summary: Function multiversioning prefers arch=x86-64-v3 to
actual processors
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ed at catmur dot uk
  Target Milestone: ---

Since #101696, we can write

__attribute__ ((target ("arch=x86-64-v3")))
char const* f() { return "x86-64-v3"; }

But x86-64-v3 is preferred to any of the processors that support this feature
set, which seems backwards - even Haswell supports pclmul and rdrnd, which
aren't in x86-64-v3.

It feels that it should be OK to swap the ordering of P_PROC_AVX2 with
P_X86_64_V3, and P_PROC_AVX512F with P_X86_64_V4, in enum feature_priority.

[Bug target/113148] New: 14.0 ICE: maximum number of generated reload insns per insn achieved

[xen0n at gentoo dot org via Gcc-bugs]

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

Bug ID: 113148
   Summary: 14.0 ICE: maximum number of generated reload insns per
insn achieved
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xen0n at gentoo dot org
CC: chenglulu at loongson dot cn, xry111 at gcc dot gnu.org
  Target Milestone: ---
Target: loongarch64

Created attachment 56947
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56947=edit
Minimized reproducer

I just discovered this ICE while building xwayland-23.2.3 on a mostly
up-to-date Gentoo, but I suspect the bug is present on vanilla GCC as well,
because I remember there are recently some refactoring around LoongArch FCC
handling.

The attached reproducer is minified from xwayland's mi/miarc.c with minor
modifications.

[Bug libstdc++/113099] locale without RTTI uses dynamic_cast before gcc 13.2 or has ODR violation since gcc 13.2

[andysem at mail dot ru via Gcc-bugs]

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

--- Comment #13 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #12)
> (In reply to andysem from comment #11)
> > > I'm not sure what you mean by "the compiler is free to generate code that 
> > > takes it into account." Takes what into account? What problem does that 
> > > freedom cause?
> > 
> > I mean the compiler could move (some part of) dynamic_cast to precede the
> > check for the standard facet. I.e. of something like this:
> > 
> >   template< typename _Facet >
> >   const _Facet* __try_use_facet(locale const& loc)
> >   {
> > const size_t __i = _Facet::id._M_id();
> > const locale::facet** __facets = __loc._M_impl->_M_facets;
> > const _Facet* __dyn_facet = __dynamic_cast< const _Facet*
> > >(__facets[__i]);
> > 
> > // checks for every standard facet type
> > if (__is_same(_Facet, ...))
> >   return static_cast(__facets[__i]);
> > 
> > return __dyn_facet;
> >   }
> 
> But why? Maybe I'm being slow but I still don't understand what problem is
> being solved here.
> 
> Also this would defeat the optimization that avoids the unnecessary overhead
> of dynamic_cast for standard facets.

I have seen gcc sometimes reorder code like this (i.e. move code from under a
branch before it), presumably to improve ILP or prefetch data, I'm not sure.
Yes, that defeats the branch, if it is used as an optimization, and I had to
prevent this by adding compiler fences in those cases. Granted, in my case it
happened with inlined code, but I imagine LTO makes it possible to perform
similar code transformations with out-of-line code as well.

I'm not saying this is what actually happens. I'm just pointing out that even
the code that is apparently unreachable may influence codegen and cause ODR
issues.

> > AFAIK, the standard or libstdc++ docs do not require RTTI for std::locale to
> > function.
> 
> The standard requires RTTI, period. Using -fno-rtti is completely
> non-standard and so the standard has nothing to say about it.

Yes, but the standard is written with implementations in mind.

[Bug other/113147] New: Building a crosscompiler fails under MigW-W64/MSYS2 @ Windows 10

[jdx at o2 dot pl via Gcc-bugs]

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

Bug ID: 113147
   Summary: Building a crosscompiler fails under MigW-W64/MSYS2 @
Windows 10
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdx at o2 dot pl
  Target Milestone: ---
  Host: x86_64-w64-mingw32
Target: h8300-elf, arm-elf

The following error occurs when I try to build a crosscompiler under
MigW-W64/MSYS2:

[...]
rm -rf libcommon.a
ar  rc libcommon.a diagnostic-spec.o diagnostic.o diagnostic-color.o
diagnostic-format-json.o diagnostic-format-sarif.o diagnostic-show-locus.o
edit-context.o pretty-print.o intl.o json.o sbitmap.o vec.o input.o
hash-table.o ggc-none.o memory-block.o selftest.o selftest-diagnostic.o sort.o
text-art/box-drawing.o text-art/canvas.o text-art/ruler.o text-art/selftests.o
text-art/style.o text-art/styled-string.o text-art/table.o text-art/theme.o
text-art/widget.o
ranlib   libcommon.a
make[2]: *** No rule to make target '../libiberty/pic/libiberty.a', needed by
'cc1-checksum.cc'.  Stop.
make[2]: Leaving directory '/d/Works/xcomp/gcc-build/gcc'
make[1]: *** [Makefile:4683: all-gcc] Error 2
make[1]: Leaving directory '/d/Works/xcomp/gcc-build'
make: *** [Makefile:1049: all] Error 2

Configure options:
../../gcc/configure --prefix=/usr/local --with-sysroot=$CWD/sysroot
--target=h8300-elf --disable-nls --disable-threads --disable-tls
--enable-checking=release --enable-languages=c --with-newlib --without-headers
--enable-multilib --enable-lto --disable-shared --enable-static
--disable-host-shared --disable-bootstrap --disable-libatomic --disable-libgomp
--disable-libitm --disable-libquadmath --disable-libsanitizer --disable-libssp
--disable-libvtv --with-system-zlib

Everything is fine on Ubuntu with the same options.

[Bug tree-optimization/113091] Over-estimate SLP vector-to-scalar cost for non-live pattern statement

[fxue at os dot amperecomputing.com via Gcc-bugs]

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

--- Comment #7 from Feng Xue  ---
> The issue here is that because the "outer" pattern consumes
> patt_64 = (int) patt_63 it should have adjusted _2 = (int) _1
> stmt-to-vectorize
> as being the outer pattern root stmt for all this logic to work correctly.

We could not simply make this adjustment since pattern recognition does not
require replaced SSA to be of single-use. If we change the above case to attach
another scalar use to "_2" as:

  int foo(char *a, char *b)
  {
unsigned array[8];
int a0 = a[0];  // _2 = (int) _1;

array[0] = (a0 - b[0]);
array[1] = (a[1] - b[1]);
array[2] = (a[2] - b[2]);
array[3] = (a[3] - b[3]);
array[4] = (a[4] - b[4]);
array[5] = (a[5] - b[5]);
array[6] = (a[6] - b[6]);
array[7] = (a[7] - b[7]);

return test(array) + a0;
  }

The pattern statement "patt_64 = (int) patt_63" for "_2 = (int) _1" should be
kept. So we also need the check of "identifying whether a scalar stmt takes
part
in vectorization or not" to ensure the adjustment is doable.

[Bug target/110625] [14 Regression][AArch64] Vect: SLP fails to vectorize a loop as the reduction_latency calculated by new costs is too large

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

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

--- Comment #23 from Tamar Christina  ---
Found the costing bug and have a patch undergoing testing.

Will post tomorrow.  Sorry for the delay in fixing it.

[Bug tree-optimization/113144] [14 regression] ICE when building dpkg-1.21.15 in verify_dominators (error: dominator of 9 should be 48, not 12)

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

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

Tamar Christina  changed:

   What|Removed |Added

   Priority|P3  |P1
   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org
   Last reconfirmed||2023-12-26
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |14.0
 Ever confirmed|0   |1

--- Comment #4 from Tamar Christina  ---
Thanks for the report and testcases.

[Bug tree-optimization/113136] [14 regression] ICE when building Perl

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

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

Tamar Christina  changed:

   What|Removed |Added

   Priority|P3  |P1
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |14.0
   Last reconfirmed||2023-12-26
   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org

--- Comment #4 from Tamar Christina  ---
Thanks for the report and testcases.

[Bug tree-optimization/113137] [14 regression] Failed bootstrap with -O3 -march=znver2

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

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

Tamar Christina  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |14.0
   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-12-26
   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org

--- Comment #6 from Tamar Christina  ---
Thanks for the report and testcases.

[Bug tree-optimization/113137] [14 regression] Failed bootstrap with -O3 -march=znver2

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

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

--- Comment #5 from Tamar Christina  ---
Simpler reproducer:

int b;
void a() __attribute__((__noreturn__));
void c() {
  char *buf;
  int bufsz = 64;
  while (b) {
!bufsz ? a(), 0 : *buf++ = bufsz--;
b -= 4;
  }
}

The loop has an inverted control flow that accesses memory.
The testcase doesn't seem to have existing cases for these, but due to the
inverted nature the loop's main exit is before the latch exit which we now
consider the early exit.

because we only analyze early exits we miss that there's a memory reference
that needs to be moved, and because it wasn't moved the vUSEs don't line up.

will fix tomorrow when back at work.

[Bug tree-optimization/113144] [14 regression] ICE when building dpkg-1.21.15 in verify_dominators (error: dominator of 9 should be 48, not 12)

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

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

--- Comment #3 from Tamar Christina  ---
loop has weird shape, peeling should have recalculated all dominators but seems
to have missed one.

Will fix tomorrow when back at work.

[Bug tree-optimization/113136] [14 regression] ICE when building Perl

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

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

--- Comment #3 from Tamar Christina  ---
This shouldn't have vectorized as outer-loop vectorization isn't supported. In
addition switch statements are not supported, but I guess the nested if
confused the code doing the analysis.

Will fix when back at work tomorrow.

[Bug tree-optimization/113137] [14 regression] Failed bootstrap with -O3 -march=znver2

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

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

--- Comment #4 from Tamar Christina  ---
*** Bug 113135 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/113139] [14 regression] ICE when building Binutils

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #2 from Tamar Christina  ---
dup

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

[Bug tree-optimization/113135] [14 regression] ICE when building unrar (error: PHI node with wrong VUSE on edge from BB 46)

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #5 from Tamar Christina  ---
dup

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

[Bug tree-optimization/113137] [14 regression] Failed bootstrap with -O3 -march=znver2

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

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

--- Comment #2 from Tamar Christina  ---
*** Bug 113146 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/113137] [14 regression] Failed bootstrap with -O3 -march=znver2

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

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

--- Comment #3 from Tamar Christina  ---
*** Bug 113139 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/113146] [14 regression] ICE when building dialog

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #1 from Tamar Christina  ---
duplicate

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

[Bug tree-optimization/113146] New: [14 regression] ICE when building dialog

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

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

Bug ID: 113146
   Summary: [14 regression] ICE when building dialog
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: tnfchris at gcc dot gnu.org
  Target Milestone: ---

Created attachment 56946
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56946=edit
progressbox.i.xz

```
$ gcc -c progressbox.i -march=znver2 -O3
progressbox.c: In function ‘dlg_progressbox’:
progressbox.c:373:1: error: PHI node with wrong VUSE on edge from BB 32
.MEM_393 = PHI <.MEM_292(32)>
expected .MEM_364
progressbox.c:373:1: error: multiple virtual PHI nodes in BB 123
.MEM_314 = PHI <.MEM_364(33)>
.MEM_392 = PHI <.MEM_292(33)>
progressbox.c:373:1: error: PHI node with wrong VUSE on edge from BB 123
.MEM_317 = PHI <.MEM_392(123), .MEM_393(128)>
expected .MEM_314
during GIMPLE pass: vect
progressbox.c:373:1: internal compiler error: verify_ssa failed
0x556bfe5c3a88 verify_ssa(bool, bool)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-ssa.cc:1203
0x556bfe1c5a9d execute_function_todo
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/passes.cc:2095
0x556bfe1c5f30 execute_todo
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/passes.cc:2142
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.
```

```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/14/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/14
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/14/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl,df
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 14.0.0 p,
commit 2250dc0cc8c46999ad1c1d79b9aeed9056459bb6' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-libgomp --disable-libssp --disable-libada
--disable-cet --disable-systemtap --disable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --with-zstd --without-isl
--enable-default-pie --enable-host-pie --disable-host-bind-now
--enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231225 (experimental)
0beeddd6b1b1cb41104c4df925323e8fc0437ba8 (Gentoo 14.0.0 p, commit
2250dc0cc8c46999ad1c1d79b9aeed9056459bb6)
```

'gcc -c -O3 -march=znver2 progressbox.i' is enough to repro.

[Bug libstdc++/107761] Implement C++23

[cooky.ykooc922 at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Desmond Gold  ---
Here's an updated version of the implementation with following changes:
+ followed coding style of GNU (maybe not all)
+ added initial implementation of std::submdspan facilities (without
constraints and preconditions yet)
+ tweaked some of the problems in previous implementation

https://godbolt.org/z/Mxs1YP8n7

summary
+ implemented c++23 
+ implemented c++26 std::submdspan facilities in 
  + added c++23 feature (concepts only): '__tuple_like' and '__pair_like'
to be used by '__mdspan::__index_pair_like'
  + added alias template '_Nth_type_t' which would supposedly be placed
inside 
+ still no documentations, incomplete preconditions and constraints, and
incomplete tests

[Bug tree-optimization/113145] [14 regression] ICE when building mit-krb5-1.21.2

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

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

--- Comment #1 from Sam James  ---
Created attachment 56945
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56945=edit
reduced.i

[Bug tree-optimization/113145] New: [14 regression] ICE when building mit-krb5-1.21.2

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

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

Bug ID: 113145
   Summary: [14 regression] ICE when building mit-krb5-1.21.2
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: tnfchris at gcc dot gnu.org
  Target Milestone: ---

Created attachment 56944
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56944=edit
spnego_mech.so.i.xz

```
$ gcc -c spnego_mech.so.i -O3 -march=znver2
/var/tmp/portage/app-crypt/mit-krb5-1.21.2/work/krb5-1.21.2/src/lib/gssapi/spnego/spnego_mech.c:
In function ‘spnego_gss_display_status’:
/var/tmp/portage/app-crypt/mit-krb5-1.21.2/work/krb5-1.21.2/src/lib/gssapi/spnego/spnego_mech.c:1791:1:
error: dominator of 18 should be 29, not 3
 1791 | spnego_gss_display_status(
  | ^
during GIMPLE pass: vect
/var/tmp/portage/app-crypt/mit-krb5-1.21.2/work/krb5-1.21.2/src/lib/gssapi/spnego/spnego_mech.c:1791:1:
internal compiler error: in verify_dominators, at dominance.cc:1194
0x560e9cdce5ea verify_dominators(cdi_direction)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/dominance.cc:1194
0x560e9dfd0199 checking_verify_dominators(cdi_direction)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/dominance.h:76
0x560e9dfd0199 slpeel_tree_duplicate_loop_to_edge_cfg(loop*, edge_def*, loop*,
edge_def*, edge_def*, edge_def**, bool, vec*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-loop-manip.cc:1846
0x560e9dfd2b38 vect_do_peeling(_loop_vec_info*, tree_node*, tree_node*,
tree_node**, tree_node**, tree_node**, int, bool, bool, tree_node**)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-loop-manip.cc:3307
0x560e9dfc1dd7 vect_transform_loop(_loop_vec_info*, gimple*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-loop.cc:11911
0x560e9e00a2f2 vect_transform_loops
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vectorizer.cc:1006
0x560e9e00a956 try_vectorize_loop_1
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vectorizer.cc:1152
0x560e9e00a956 try_vectorize_loop
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vectorizer.cc:1182
0x560e9e00af74 execute
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vectorizer.cc:1298
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.
```

```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/14/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/14
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/14/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl,df
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 14.0.0 p,
commit 2250dc0cc8c46999ad1c1d79b9aeed9056459bb6' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-libgomp --disable-libssp --disable-libada
--disable-cet --disable-systemtap --disable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --with-zstd --without-isl
--enable-default-pie --enable-host-pie --disable-host-bind-now
--enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231225 (experimental)
0beeddd6b1b1cb41104c4df925323e8fc0437ba8 (Gentoo 14.0.0 p, commit
2250dc0cc8c46999ad1c1d79b9aeed9056459bb6)
```

[Bug go/113143] Remove usage of ucontext.h

[kallisti5 at unixzen dot com via Gcc-bugs]

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

--- Comment #3 from Alexander von Gluck  ---
Good call out.  It looks like in 2004 these functions were flagged as
obsolescent though:
https://pubs.opengroup.org/onlinepubs/009695399/functions/makecontext.html

Here's the note on it in the linux man page for getcontext:
"
  glibc 2.1.  SUSv2, POSIX.1-2001.  Removed in POSIX.1-2008, citing
  portability issues, and recommending that applications be
  rewritten to use POSIX threads instead.
"


upstream go usage:

* makecontext: no code matches as of go 1.22 (main)
* getcontext:  netbsd,solaris,freebsd code usage as of go 1.22 (main)
* setcontext:  netbsd,freebsd code usages as of go 1.22 (main)
* swapcontext: freebsd code usages as of go 1.22 (main)


Per the 2004 spec:

"The obsolescent functions getcontext(), makecontext(), and swapcontext() can
be replaced using POSIX threads functions."

Essentially, for quite some time, (get|make|set)context are only used on the
BSD's and Solaris... thus invocation of include should be guarded /
masked off on all other platforms.

[Bug libstdc++/113099] locale without RTTI uses dynamic_cast before gcc 13.2 or has ODR violation since gcc 13.2

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

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to andysem from comment #11)
> > I'm not sure what you mean by "the compiler is free to generate code that 
> > takes it into account." Takes what into account? What problem does that 
> > freedom cause?
> 
> I mean the compiler could move (some part of) dynamic_cast to precede the
> check for the standard facet. I.e. of something like this:
> 
>   template< typename _Facet >
>   const _Facet* __try_use_facet(locale const& loc)
>   {
> const size_t __i = _Facet::id._M_id();
> const locale::facet** __facets = __loc._M_impl->_M_facets;
> const _Facet* __dyn_facet = __dynamic_cast< const _Facet*
> >(__facets[__i]);
> 
> // checks for every standard facet type
> if (__is_same(_Facet, ...))
>   return static_cast(__facets[__i]);
> 
> return __dyn_facet;
>   }

But why? Maybe I'm being slow but I still don't understand what problem is
being solved here.

Also this would defeat the optimization that avoids the unnecessary overhead of
dynamic_cast for standard facets.

> AFAIK, the standard or libstdc++ docs do not require RTTI for std::locale to
> function.

The standard requires RTTI, period. Using -fno-rtti is completely non-standard
and so the standard has nothing to say about it.

[Bug target/113112] RISC-V: Dynamic LMUL feature stabilization for GCC-14 release

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Pan Li :

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

commit r14-6836-gf83cfb8148bcf0876df76761a9a4545bc939667d
Author: Juzhe-Zhong 
Date:   Tue Dec 26 16:42:27 2023 +0800

RISC-V: Some minior tweak on dynamic LMUL cost model

Tweak some codes of dynamic LMUL cost model to make computation more
predictable and accurate.

Tested on both RV32 and RV64 no regression.

Committed.

PR target/113112

gcc/ChangeLog:

* config/riscv/riscv-vector-costs.cc (compute_estimated_lmul):
Tweak LMUL estimation.
(has_unexpected_spills_p): Ditto.
(costs::record_potential_unexpected_spills): Ditto.

gcc/testsuite/ChangeLog:

* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-1.c: Add more
checks.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-2.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-3.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-4.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-5.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-6.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-7.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-1.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-2.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-3.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-4.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-5.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-1.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-2.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-3.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-5.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-6.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-7.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-8.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-1.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-10.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-11.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-2.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-3.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-4.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-5.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-6.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-7.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-8.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-9.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-12.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/pr113112-2.c: New test.