[Bug target/110740] [14 regression] gcc.target/powerpc/p9-vec-length-epil-1.c

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

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

Kewen Lin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 CC||linkw at gcc dot gnu.org
   Last reconfirmed||2023-07-20
   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Kewen Lin  ---
I'll have a look first, it's likely a test issue.

[Bug c++/110747] New: GCC rejects the syntax for an immediately invoked lambda as a template argument in a requires-clause

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 110747
   Summary: GCC rejects the syntax for an immediately invoked
lambda as a template argument in a requires-clause
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

Maybe dup of Bug 91309:

template
struct S;

int main() {
  return requires { typename S<[]{ return 0; }()>;};
}

https://godbolt.org/z/Mha4Waceo

[Bug other/110744] [14 regression] gcc.dg/tree-ssa/pr84512.c fails after r14-2267-gb8806f6ffbe72

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

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

--- Comment #7 from Li Pan  ---
Thanks a lot for the explanation, Kewen. 

Looks you are taking care of this already, anything is required from my-side
please feel free to let me know.

[Bug other/110744] [14 regression] gcc.dg/tree-ssa/pr84512.c fails after r14-2267-gb8806f6ffbe72

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

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

--- Comment #6 from Kewen Lin  ---
The root cause is that the length and bias handling about LEN_STORE in sccvn
was missed to be updated, the below diff can fix the failure.

diff --git a/gcc/tree-ssa-sccvn.cc b/gcc/tree-ssa-sccvn.cc
index 11061a374a2..c0b3ec420c5 100644
--- a/gcc/tree-ssa-sccvn.cc
+++ b/gcc/tree-ssa-sccvn.cc
@@ -3299,11 +3299,14 @@ vn_reference_lookup_3 (ao_ref *ref, tree vuse, void
*data_,
return (void *)-1;
  break;
case IFN_LEN_STORE:
- len = gimple_call_arg (call, 2);
- bias = gimple_call_arg (call, 4);
- if (!tree_fits_uhwi_p (len) || !tree_fits_shwi_p (bias))
-   return (void *)-1;
- break;
+ {
+   int len_index = internal_fn_len_index (fn);
+   len = gimple_call_arg (call, len_index);
+   bias = gimple_call_arg (call, len_index + 1);
+   if (!tree_fits_uhwi_p (len) || !tree_fits_shwi_p (bias))
+ return (void *) -1;
+   break;
+ }
default:
  return (void *)-1;
}

Fully testing it.

[Bug other/110744] [14 regression] gcc.dg/tree-ssa/pr84512.c fails after r14-2267-gb8806f6ffbe72

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

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

--- Comment #5 from Kewen Lin  ---
(In reply to Li Pan from comment #2)
> Hi there,
> 
> Just try to reproduce this bug with powerPC cross compiler (sorry we don't
> have a real powerPC) with the below options. Unfortunately, I failed to
> reproduce this bug as above mentioned.

Cfarm (https://cfarm.tetaneutral.net/) recently gets one Power10 machine, you
can have a try there. :) But yeah, for this kind of compilation issue, cross
compiler is normally enough.

> 
> Could you please help to take a look if there is something missing or
> incorrect?
> 
> 1. Build cross compiler
> 
> ../configure \
>   --target=powerpc-unknown-elf \

I can reproduce it with --target=powerpc64le-unknown-linux-gnu.

powerpc is 32bit Power, unfortunately lxvl and stxvl (vector with length)
hardware instructions require 64bit GPR (for holding length in some of its high
bits), so partial vector is not enabled there.

>   --prefix=${INSTALL_DIR} \
>   --disable-shared \
>   --enable-threads \
>   --enable-tls \
>   --enable-languages=c,c++ \
>   --with-system-zlib \
>   --with-newlib \
>   --disable-libmudflap \
>   --disable-libssp \
>   --disable-libquadmath \
>   --disable-libgomp \
>   --enable-nls \
>   --disable-tm-clone-registry \
>   --enable-multilib \
>   --src=`pwd`/../ \
>   --enable-werror \
> 
> make -j $(nproc) all-gcc && make install-gcc
>

[Bug other/110744] [14 regression] cc.dg/tree-ssa/pr84512.c fails after r14-2267-gb8806f6ffbe72

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

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

Kewen Lin  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-07-20

--- Comment #4 from Kewen Lin  ---
Assigning to myself as discussing with Juzhe.

[Bug other/110744] [14 regression] cc.dg/tree-ssa/pr84512.c fails after r14-2267-gb8806f6ffbe72

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #3 from JuzheZhong  ---
Kewen from IBM will soon send a patch to fix it.
Sorry for causing this issue.

Thanks.

[Bug preprocessor/103902] GCC requires a space between string-literal and identifier in a literal-operator-id where the identifier is not in basic character set

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Lewis Hyatt :

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

commit r14-2665-gb2cfe5233e682fc04a9b6fc91f3d30685515630b
Author: Lewis Hyatt 
Date:   Wed Jul 19 22:07:54 2023 -0400

testsuite: Fix C++ UDL tests failing on 32-bit arch [PR103902]

These tests need to use "size_t" rather than "unsigned long"
for the user-defined literal function arguments.

gcc/testsuite/ChangeLog:

PR preprocessor/103902
* g++.dg/cpp0x/udlit-extended-id-1.C: Change "unsigned long" to
"size_t" throughout.
* g++.dg/cpp0x/udlit-extended-id-3.C: Likewise.

[Bug pch/110746] gcc-12 fails: sorry, unimplemented: PCH allocation failure

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Host||freebsd

--- Comment #9 from Andrew Pinski  ---
I suspect freebsd needs some host support for relocatable PCH and nobody has
implemented it yet.

Maybe it is best not to try PCH with the program you are compiling.

[Bug pch/110746] gcc-12 fails: sorry, unimplemented: PCH allocation failure

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |pch
Summary|gcc-12 and gcc-13 fails:|gcc-12 fails: sorry,
   |sorry, unimplemented: PCH   |unimplemented: PCH
   |allocation failure  |allocation failure

--- Comment #8 from Andrew Pinski  ---
  result = host_hooks.gt_pch_use_address (mmi.preferred_base, mmi.size,
  fileno (f), mmi.offset);

  /* We could not mmap or otherwise allocate the required memory at the
 address needed.  */
  if (result < 0)
{
  sorry_at (input_location, "PCH allocation failure");
  /* There is no point in continuing from here, we will only end up
 with a crashed (most likely hanging) compiler.  */
  exit (-1);
}

[Bug c++/110746] gcc-12 fails: sorry, unimplemented: PCH allocation failure

[yuri at tsoft dot com via Gcc-bugs]

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

--- Comment #7 from Yuri  ---
gcc-13 has the same problem.

[Bug c++/110746] gcc-12 fails: sorry, unimplemented: PCH allocation failure

[yuri at tsoft dot com via Gcc-bugs]

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

--- Comment #6 from Yuri  ---
FAILED:
src/plugins/score-plugin-avnd/CMakeFiles/score_plugin_avnd.dir/__/__/__/midiscaler_avnd.cpp.o
 
/usr/local/libexec/ccache/g++13 -DBOOST_ASIO_DISABLE_CONCEPTS=1
-DBOOST_MATH_DISABLE_FLOAT128=1 -DBOOST_NO_RTTI=1 -DLIBREMIDI_ALSA
-DLIBREMIDI_JACK -DQT_CORE_LIB -DQT_DISABLE_DEPRECATED_BEFORE=0x0605ff
-DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_NO_JAVA_STYLE_ITERATORS
-DQT_NO_KEYWORDS -DQT_NO_LINKED_LIST -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT
-DQT_NO_USING_NAMESPACE -DQT_OPENGL_LIB -DQT_QMLINTEGRATION_LIB -DQT_QML_LIB
-DQT_SERIALPORT_LIB -DQT_SHADERTOOLS_LIB -DQT_STATEMACHINE_LIB
-DQT_STATICPLUGIN -DQT_USE_QSTRINGBUILDER -DQT_WEBSOCKETS_LIB -DQT_WIDGETS_LIB
-DRAPIDJSON_HAS_STDSTRING=1 -DSCORE_LIB_BASE -DSCORE_LIB_DEVICE
-DSCORE_LIB_INSPECTOR -DSCORE_LIB_LOCALTREE -DSCORE_LIB_PROCESS
-DSCORE_LIB_STATE -DSCORE_PLUGIN_AUDIO -DSCORE_PLUGIN_AUTOMATION
-DSCORE_PLUGIN_AVND_EXPORTS -DSCORE_PLUGIN_CURVE -DSCORE_PLUGIN_DATAFLOW
-DSCORE_PLUGIN_DEVICEEXPLORER -DSCORE_PLUGIN_ENGINE -DSCORE_PLUGIN_GFX
-DSCORE_PLUGIN_LIBRARY -DSCORE_PLUGIN_MEDIA -DSCORE_PLUGIN_SCENARIO
-DSCORE_PLUGIN_TRANSPORT -DSCORE_STATIC_PLUGINS -DSERVUS_USE_AVAHI_CLIENT
-DTINYSPLINE_DOUBLE_PRECISION
-I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-plugin-avnd
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-plugin-avnd
-I/usr/ports/multimedia/ossia-score/work/.build
-I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-plugin-engine
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-plugin-engine
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/3rdparty
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/3rdparty/zipdownloader/src
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/3rdparty/QProgressIndicator
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/3rdparty/Qt-Color-Widgets
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/3rdparty/Qt-Color-Widgets/src
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/3rdparty/Qt-Color-Widgets/QtColorWidgets
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/3rdparty/libossia/3rdparty/verdigris/src
-I/usr/ports/multimedia/ossia-score/work/.build/src/lib
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/lib
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/3rdparty/libossia/3rdparty/Flicks
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/3rdparty/libossia/src
-I/usr/ports/multimedia/ossia-score/work/.build/3rdparty/libossia/src
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/3rdparty/libossia/3rdparty/Servus/servus/..
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/3rdparty/QCodeEditor/include
-I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-lib-device
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-lib-device
-I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-lib-state
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-lib-state
-I/usr/local/include/qt6/QtDBus/6.4.2
-I/usr/local/include/qt6/QtDBus/6.4.2/QtDBus
-I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-lib-process
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-lib-process
-I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-lib-inspector
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-lib-inspector
-I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-lib-localtree
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-lib-localtree
-I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-plugin-library
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-plugin-library
-I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-plugin-deviceexplorer
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-plugin-deviceexplorer
-I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-plugin-transport
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-plugin-transport
-I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-plugin-scenario
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-plugin-scenario
-I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-plugin-curve
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-plugin-curve
-I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-plugin-automation
-I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-plugin-automation
-I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-plugin-audio

[Bug other/110744] [14 regression] cc.dg/tree-ssa/pr84512.c fails after r14-2267-gb8806f6ffbe72

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

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

--- Comment #2 from Li Pan  ---
Hi there,

Just try to reproduce this bug with powerPC cross compiler (sorry we don't have
a real powerPC) with the below options. Unfortunately, I failed to reproduce
this bug as above mentioned.

Could you please help to take a look if there is something missing or
incorrect?

1. Build cross compiler

../configure \
  --target=powerpc-unknown-elf \
  --prefix=${INSTALL_DIR} \
  --disable-shared \
  --enable-threads \
  --enable-tls \
  --enable-languages=c,c++ \
  --with-system-zlib \
  --with-newlib \
  --disable-libmudflap \
  --disable-libssp \
  --disable-libquadmath \
  --disable-libgomp \
  --enable-nls \
  --disable-tm-clone-registry \
  --enable-multilib \
  --src=`pwd`/../ \
  --enable-werror \

make -j $(nproc) all-gcc && make install-gcc

2. Compile the source file.

>> ./bin/powerpc-unknown-elf-gcc -mcpu=power10 -O3 -fdump-tree-optimized -c -S 
>> ../gcc/gcc/testsuite/gcc.dg/tree-ssa/pr84512.c -o -
.file   "pr84512.c"
.machine power10
.section".text"
.align 2
.align 4
.globl foo
.type   foo, @function
foo:
.LFB0:
li 3,285
blr
.LFE0:
.size   foo, .-foo
.section.eh_frame,"aw",@progbits
.Lframe1:
.4byte  .LECIE1-.LSCIE1
.LSCIE1:
.4byte  0
.byte   0x3
.string ""
.byte   0x1
.byte   0x7c
.byte   0x41
.byte   0xc
.byte   0x1
.byte   0
.align 2
.LECIE1:
.LSFDE1:
.4byte  .LEFDE1-.LASFDE1
.LASFDE1:
.4byte  .LASFDE1-.Lframe1
.4byte  .LFB0
.4byte  .LFE0-.LFB0
.align 2
.LEFDE1:
.ident  "GCC: (GNU) 14.0.0 20230720 (experimental)"

>> cat pr84512.c.257t.optimized

;; Function foo (foo, funcdef_no=0, decl_uid=3445, cgraph_uid=1,
symbol_order=0)

int foo ()
{
   [local count: 97603129]:
  return 285;

}

[Bug preprocessor/103902] GCC requires a space between string-literal and identifier in a literal-operator-id where the identifier is not in basic character set

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

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

--- Comment #10 from Thiago Jung Bauermann  
---
(In reply to Lewis Hyatt from comment #9)
> Thanks, sorry about that, I need to replace "unsigned long" with "size_t".
> Will fix it.

No problem. Thank you!

[Bug preprocessor/103902] GCC requires a space between string-literal and identifier in a literal-operator-id where the identifier is not in basic character set

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

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

--- Comment #9 from Lewis Hyatt  ---
Thanks, sorry about that, I need to replace "unsigned long" with "size_t". Will
fix it.

[Bug c++/108179] [11/12 regression] ICE related to template template parameters in tsubst, at cp/pt.cc:15782

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

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

--- Comment #9 from Jason Merrill  ---
This patch caused PR110566.

[Bug c++/110746] gcc-12 fails: sorry, unimplemented: PCH allocation failure

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-07-20
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #5 from Andrew Pinski  ---
Can you provide the command which is failing?

[Bug c++/110746] gcc-12 fails: sorry, unimplemented: PCH allocation failure

[yuri at tsoft dot com via Gcc-bugs]

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

--- Comment #4 from Yuri  ---
This happens during the build of the Ossia Score project:
https://github.com/ossia/score

[Bug preprocessor/103902] GCC requires a space between string-literal and identifier in a literal-operator-id where the identifier is not in basic character set

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

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

Thiago Jung Bauermann  changed:

   What|Removed |Added

 CC||thiago.bauermann at linaro dot 
org

--- Comment #8 from Thiago Jung Bauermann  
---
Hello,

The new tests udlit-extended-id-1.C and udlit-extended-id-3.C are failing on
armv8l-linux-gnueabihf (tested on Ubuntu 22.04):

Running g++:g++.dg/dg.exp ...
FAIL: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++14 (test for excess errors)
UNRESOLVED: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++14 compilation failed to
produce executable
FAIL: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++17 (test for excess errors)
UNRESOLVED: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++17 compilation failed to
produce executable
FAIL: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++20 (test for excess errors)
UNRESOLVED: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++20 compilation failed to
produce executable
FAIL: g++.dg/cpp0x/udlit-extended-id-3.C -std=c++14 (test for excess errors)
FAIL: g++.dg/cpp0x/udlit-extended-id-3.C -std=c++17 (test for excess errors)
FAIL: g++.dg/cpp0x/udlit-extended-id-3.C -std=c++20 (test for excess errors)

Looking at g++.log, the errors are:

/home/thiago.bauermann/src/gcc/gcc/testsuite/g++.dg/cpp0x/udlit-extended-id-1.C:24:14:
error: 'const char* operator""_1\U03c3(const char*, long unsigned int)' has
invalid argument list
/home/thiago.bauermann/src/gcc/gcc/testsuite/g++.dg/cpp0x/udlit-extended-id-1.C:29:14:
error: 'const char* operator""_\U03a32(const char*, long unsigned int)' has
invalid argument list
/home/thiago.bauermann/src/gcc/gcc/testsuite/g++.dg/cpp0x/udlit-extended-id-1.C:34:14:
error: 'const char* operator""_\U00e61(const char*, long unsigned int)' has
invalid argument list
/home/thiago.bauermann/src/gcc/gcc/testsuite/g++.dg/cpp0x/udlit-extended-id-1.C:39:13:
error: 'const char* operator""_\U01532(const char*, long unsigned int)' has
invalid argument list
/home/thiago.bauermann/src/gcc/gcc/testsuite/g++.dg/cpp0x/udlit-extended-id-1.C:
In function 'int main()':
/home/thiago.bauermann/src/gcc/gcc/testsuite/g++.dg/cpp0x/udlit-extended-id-1.C:56:15:
error: unable to find string literal operator 'operator""_1\U03c3' with
'const char [4]', 'unsigned int' arguments
/home/thiago.bauermann/src/gcc/gcc/testsuite/g++.dg/cpp0x/udlit-extended-id-1.C:58:15:
error: unable to find string literal operator 'operator""_\U03a32' with
'const char [5]', 'unsigned int' arguments
/home/thiago.bauermann/src/gcc/gcc/testsuite/g++.dg/cpp0x/udlit-extended-id-1.C:60:15:
error: unable to find string literal operator 'operator""_1\U03c3' with
'const char [7]', 'unsigned int' arguments
/home/thiago.bauermann/src/gcc/gcc/testsuite/g++.dg/cpp0x/udlit-extended-id-1.C:62:15:
error: unable to find string literal operator 'operator""_1\U03c3' with
'const char [8]', 'unsigned int' arguments
/home/thiago.bauermann/src/gcc/gcc/testsuite/g++.dg/cpp0x/udlit-extended-id-1.C:65:15:
error: unable to find string literal operator 'operator""_\U03a32' with
'const char [7]', 'unsigned int' arguments
/home/thiago.bauermann/src/gcc/gcc/testsuite/g++.dg/cpp0x/udlit-extended-id-1.C:67:15:
error: unable to find string literal operator 'operator""_\U00e61' with
'const char [4]', 'unsigned int' arguments
/home/thiago.bauermann/src/gcc/gcc/testsuite/g++.dg/cpp0x/udlit-extended-id-1.C:69:15:
error: unable to find string literal operator 'operator""_\U01532' with
'const char [4]', 'unsigned int' arguments
compiler exited with status 1

Any idea what could be going wrong? They do pass on aarch64-linux, so I wonder
if this is a 32-bit issue?

[Bug c++/110746] gcc-12 fails: sorry, unimplemented: PCH allocation failure

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

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

--- Comment #3 from Andrew Pinski  ---
Or it is while creating pch.

Please mention what you were doing when the message came up.

[Bug c++/110746] gcc-12 fails: sorry, unimplemented: PCH allocation failure

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

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

--- Comment #2 from Andrew Pinski  ---
It means pch is not fully supported due to pie. This has been improved/fixed in
gcc 13 though.

[Bug c++/110746] gcc-12 fails: sorry, unimplemented: PCH allocation failure

[yuri at tsoft dot com via Gcc-bugs]

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

--- Comment #1 from Yuri  ---
OS: FreeBSD 13.2

[Bug c++/110746] New: gcc-12 fails: sorry, unimplemented: PCH allocation failure

[yuri at tsoft dot com via Gcc-bugs]

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

Bug ID: 110746
   Summary: gcc-12 fails: sorry, unimplemented: PCH allocation
failure
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yuri at tsoft dot com
  Target Milestone: ---

> : sorry, unimplemented: PCH allocation failure

This message is in the GCC source code.

What does this mean "PCH allocation failure"? What is wrong?

[Bug libstdc++/110593] The std::ratio meta arithmetic can accept non-std::ratio

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Fixed for GCC 14. Thanks for the report.

[Bug libstdc++/109921] [13 Regression] c++17/floating_from_chars.cc: compile error: ‘from_chars_strtod’ was not declared in this scope

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|13.3|13.2
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #9 from Jonathan Wakely  ---
This should be fixed for gcc-13 now. There should be a release candidate for
GCC 13.2 in the next day or so. If possible please download the RC tarball and
test it for your target, so that if there are still problems we can fix them
for the 13.2 release.

[Bug libstdc++/109921] [13 Regression] c++17/floating_from_chars.cc: compile error: ‘from_chars_strtod’ was not declared in this scope

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

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

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

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

commit r13-7593-gcd2f934bb09c04e62beb8eb5421467184598983b
Author: Jonathan Wakely 
Date:   Thu May 25 10:32:33 2023 +0100

libstdc++: Fix preprocessor conditions for std::from_chars [PR109921]

We use the from_chars_strtod function with __strtof128 to read a
_Float128 value, but from_chars_strtod is not defined unless uselocale
is available. This can lead to compilation failures for some targets,
because we try to define the _Float128 overload in terms of a
non-existing from_chars_strtod function.

Only try to use __strtof128 if uselocale is available and therefore we
can use the from_chars_strtod function template.

This is a simpler change than r14-1431-g7037e7b6e4ac41 on trunk, because
that caused unwanted ABI regressions (PR libstdc++/110077).

libstdc++-v3/ChangeLog:

PR libstdc++/109921
* src/c++17/floating_from_chars.cc (USE_STRTOF128_FOR_FROM_CHARS):
Only define when USE_STRTOD_FOR_FROM_CHARS is also defined.
(USE_STRTOD_FOR_FROM_CHARS): Do not undefine when long double is
binary64.
(from_chars(const char*, const char*, double&, chars_format)):
Check __LDBL_MANT_DIG__ == __DBL_MANT_DIG__ here.

[Bug other/110744] [14 regression] cc.dg/tree-ssa/pr84512.c fails after r14-2267-gb8806f6ffbe72

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #1 from JuzheZhong  ---
I am really sorry for causing the inconvience.
Working on it.

[Bug libstdc++/110077] [14 regression] libstdc++-abi/abi_check FAILs on Solaris

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

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

--- Comment #17 from Jonathan Wakely  ---
I hope this is fixed now.

[Bug libstdc++/110077] [14 regression] libstdc++-abi/abi_check FAILs on Solaris

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

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:0867d30a68de68f4c809757348447bef94ef1491

commit r14-2661-g0867d30a68de68f4c809757348447bef94ef1491
Author: Jonathan Wakely 
Date:   Wed Jul 19 21:15:17 2023 +0100

libstdc++: Do not define inaccurate from_chars for _Float128 [PR110077]

I think r14-1431-g7037e7b6e4ac41 was wrong to try to define the
_Float128 overload unconditionally. Not all targets need it, so defining
the lossy fallback using long double is not useful (and caused an ABI
change on Solaris x86).

Making the definition depend on USE_STRTOF128_FOR_FROM_CHARS again
partially reverts the change for PR 109921, however that should still be
fixed because the changes to make USE_STRTOF128_FOR_FROM_CHARS depend on
USE_STRTOD_FOR_FROM_CHARS are not reverted.

libstdc++-v3/ChangeLog:

PR libstdc++/110077
* src/c++17/floating_from_chars.cc (from_chars): Only define
_Float128 overload when using __strfromf128.

[Bug libstdc++/109921] [13 Regression] c++17/floating_from_chars.cc: compile error: ‘from_chars_strtod’ was not declared in this scope

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:0867d30a68de68f4c809757348447bef94ef1491

commit r14-2661-g0867d30a68de68f4c809757348447bef94ef1491
Author: Jonathan Wakely 
Date:   Wed Jul 19 21:15:17 2023 +0100

libstdc++: Do not define inaccurate from_chars for _Float128 [PR110077]

I think r14-1431-g7037e7b6e4ac41 was wrong to try to define the
_Float128 overload unconditionally. Not all targets need it, so defining
the lossy fallback using long double is not useful (and caused an ABI
change on Solaris x86).

Making the definition depend on USE_STRTOF128_FOR_FROM_CHARS again
partially reverts the change for PR 109921, however that should still be
fixed because the changes to make USE_STRTOF128_FOR_FROM_CHARS depend on
USE_STRTOD_FOR_FROM_CHARS are not reverted.

libstdc++-v3/ChangeLog:

PR libstdc++/110077
* src/c++17/floating_from_chars.cc (from_chars): Only define
_Float128 overload when using __strfromf128.

[Bug libstdc++/110593] The std::ratio meta arithmetic can accept non-std::ratio

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r14-2660-g2d614822e9ea2a3d8800045d66e3220743753d09
Author: Jonathan Wakely 
Date:   Wed Jul 19 18:18:46 2023 +0100

libstdc++: Check for std::ratio in arithmetic and comparisons [PR110593]

The standard says that it should be ill-formed to use std::ratio_equal
etc. with types which are not specializations of std::ratio. This
implements that requirement.

We don't need to add assertions to every one of the class templates,
because many of them are implemented in terms of other ones. For
example, ratio_divide and ratio_subtract can rely on the assertions in
ratio_multiply and ratio_add respectively.

libstdc++-v3/ChangeLog:

PR libstdc++/110593
* include/bits/chrono.h (duration): Improve static assert
messages.
(__is_ratio): Move to ...
* include/std/ratio (__is_ratio): ... here.
(__is_ratio_v): New variable template and partial
specialization.
(__are_both_ratios): New function template.
(__ratio_multiply, ratio_equal, ratio_less, __ratio_add):
Add static assertion.
* testsuite/20_util/ratio/requirements/type_constraints.cc:
New test.
* testsuite/20_util/duration/requirements/typedefs_neg1.cc:
Adjust expected error.
* testsuite/20_util/duration/requirements/typedefs_neg2.cc:
Likewise.

[Bug c/110737] GCC: internal compiler error: Segmentation fault when processing __builtin_isinf and _Atomic long double together

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

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

--- Comment #5 from Andrew Pinski  ---
build_atomic_assign does not handle this in a reasonable fashion.
Note there is code like :
  if (modifycode != NOP_EXPR)
add_stmt (rhs);

  /* NOP_EXPR indicates it's a straight store of the RHS. Simply issue
 an atomic_store.  */
  if (modifycode == NOP_EXPR)
{
...
  /* VAL is the value which was stored, return a COMPOUND_STMT of
 the statement and that value.  */
  return build2 (COMPOUND_EXPR, nonatomic_lhs_type, compound_stmt, val);
}

Which definitely could be improved too.

[Bug c++/110745] Improve printing of base classes

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Fixed.

[Bug c++/110745] Improve printing of base classes

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

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

--- Comment #1 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r14-2659-ge92ca8d3b4cab96a9f79466b5158381cb3103f9d
Author: Marek Polacek 
Date:   Wed Jul 19 16:50:00 2023 -0400

c++: Improve printing of base classes [PR110745]

This patch changes

  warning: missing initializer for member 'D::'
[-Wmissing-field-initializers]

to

  warning: missing initializer for member 'D::B'
[-Wmissing-field-initializers]

PR c++/110745

gcc/cp/ChangeLog:

* error.cc (dump_simple_decl): Print base class name.

gcc/testsuite/ChangeLog:

* g++.dg/diagnostic/base.C: New test.

[Bug analyzer/110700] ICE with -fanalyzer --analyzer-checker=taint on division of tainted floating-point values

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

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

--- Comment #3 from David Malcolm  ---
Should be fixed on trunk by the above patch.  Keeping open to track backporting
to branches for gcc 12 and gcc 13.

[Bug analyzer/110700] ICE with -fanalyzer --analyzer-checker=taint on division of tainted floating-point values

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r14-2658-gb86c0fe327a5196a316bd698d12765b08de5dce7
Author: David Malcolm 
Date:   Wed Jul 19 17:55:09 2023 -0400

analyzer: fix ICE on division of tainted floating-point values [PR110700]

gcc/analyzer/ChangeLog:
PR analyzer/110700
* region-model-manager.cc
(region_model_manager::get_or_create_int_cst): Assert that we have
an integral or pointer type.
* sm-taint.cc (taint_state_machine::check_for_tainted_divisor):
Don't check non-integral types.

gcc/testsuite/ChangeLog:
PR analyzer/110700
* gcc.dg/analyzer/taint-divisor-2.c: New test.

Signed-off-by: David Malcolm 

[Bug c/110737] GCC: internal compiler error: Segmentation fault when processing __builtin_isinf and _Atomic long double together

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

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

--- Comment #4 from Andrew Pinski  ---
You can also get ICE with _Atomic int with a similar testcase:
```
_Atomic int c;
void f(void);
int g(void)
{
return (c += f());
}
```

[Bug tree-optimization/110742] [14 Regression] cc1plus ICE "Floating point exception" during SLP and profiled bootstrap

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

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

--- Comment #10 from Thiago Jung Bauermann  
---
Thank you very much for digging into this!

[Bug c/110737] GCC: internal compiler error: Segmentation fault when processing __builtin_isinf and _Atomic long double together

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||6.1.0, 8.1.0

--- Comment #3 from Andrew Pinski  ---
In GCC 4.9-5.x, this just ICEd. Before GCC 4.9, GCC didn't recongize _Atomic.

[Bug c/110737] GCC: internal compiler error: Segmentation fault when processing __builtin_isinf and _Atomic long double together

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

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

--- Comment #2 from Andrew Pinski  ---
7137  /* TARGET_EXPR temps aren't part of the enclosing block, so add
it
7138 to the temps list.  Handle also variable length TARGET_EXPRs. 
*/
7139  if (!poly_int_tree_p (DECL_SIZE (temp)))
7140{
7141  if (!TYPE_SIZES_GIMPLIFIED (TREE_TYPE (temp)))
7142gimplify_type_sizes (TREE_TYPE (temp), _pre_p);
7143  /* FIXME: this is correct only when the size of the type does
(gdb) p temp
$1 = (tree) 0x7760d3f0
(gdb) p debug_tree(temp)
 >
addressable used ignored read VOID t5.c:4:1

(slightly different compiler)
  TARGET_EXPR ;
  TARGET_EXPR (__atomic_load_16 ((const volatile void *) , 5)))>;
  TARGET_EXPR ;,
__builtin_ia32_fnclex ();;, TARGET_EXPR ;,
TARGET_EXPR ;;, __builtin_ia32_ldmxcsr
(D.2771);;

  if (__atomic_compare_exchange_16 ((volatile void *) , (void *) ,
VIEW_CONVERT_EXPR<__int128 unsigned>(D.2764), 0, 5, 5))


Note for C++ front-end, it uses error_mark_node for here rather than a void
type for D.2762 ( D.4640)

[Bug c++/110064] spurious missing initializer for member for anonymous

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed for GCC 14.

[Bug c++/110064] spurious missing initializer for member for anonymous

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r14-2657-gb1ae46bdd19fc2aaea41bc894168bdaf4799be80
Author: Marek Polacek 
Date:   Wed Jul 19 13:31:52 2023 -0400

c++: -Wmissing-field-initializers and empty class [PR110064]

Let's suppress -Wmissing-field-initializers for empty classes.

Here I don't think I need the usual COMPLETE_TYPE_P/dependent_type_p
checks.

PR c++/110064

gcc/cp/ChangeLog:

* typeck2.cc (process_init_constructor_record): Don't emit
-Wmissing-field-initializers for empty classes.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wmissing-field-initializers-3.C: New test.

[Bug libstdc++/110077] [14 regression] libstdc++-abi/abi_check FAILs on Solaris

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

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

--- Comment #15 from Jonathan Wakely  ---
I now think the right fix is:

--- a/libstdc++-v3/src/c++17/floating_from_chars.cc
+++ b/libstdc++-v3/src/c++17/floating_from_chars.cc
@@ -1325,24 +1325,14 @@ _ZSt10from_charsPKcS0_RDF128_St12chars_format(const
char* first,
  __ieee128& value,
  chars_format fmt) noexcept
 __attribute__((alias ("_ZSt10from_charsPKcS0_Ru9__ieee128St12chars_format")));
-#elif __FLT128_MANT_DIG__ == 113 && __LDBL_MANT_DIG__ != 113
+#elif defined(USE_STRTOF128_FOR_FROM_CHARS)
 // Overload for _Float128 is not defined inline in , define it here.
 from_chars_result
 from_chars(const char* first, const char* last, _Float128& value,
   chars_format fmt) noexcept
 {
-#ifdef USE_STRTOF128_FOR_FROM_CHARS
   // fast_float doesn't support IEEE binary128 format, but we can use strtold.
   return from_chars_strtod(first, last, value, fmt);
-#else
-  // Read a long double. This might give an incorrect result (e.g. values
-  // out of range of long double give an error, even if they fit in
_Float128).
-  long double ldbl_val;
-  auto res = std::from_chars(first, last, ldbl_val, fmt);
-  if (res.ec == errc{})
-value = ldbl_val;
-  return res;
-#endif
 }
 #endif


I think r14-1431-g7037e7b6e4ac41 was wrong to try to define that overload
unconditionally.  Not all targets need it, so defining the lossy fallback using
long double is not useful (and caused this ABI change on Solaris x86).

[Bug c++/110745] Improve printing of base classes

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-07-19
 Status|UNCONFIRMED |ASSIGNED
   Keywords||diagnostic
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

[Bug c++/110745] New: Improve printing of base classes

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

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

Bug ID: 110745
   Summary: Improve printing of base classes
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Prompted by :

struct B { int i; };
struct D : B {
int x;
int y;
};

int
main ()
{
  D d = {.x=1, .y=2};
  (void)d;
}

$ ./cc1plus -quiet q.C -Wmissing-field-initializers
q.C: In function ‘int main()’:
q.C:10:20: warning: missing initializer for member 'D::'
[-Wmissing-field-initializers]
   10 |   D d = {.x=1, .y=2};
  |^

We should be able to say 'D::B' instead.

[Bug sanitizer/80578] -fsanitize=undefined report yields memory leak

[marc.mutz at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from Marc Mutz  ---
Still in GCC 11 and GCC 13.

[Bug modula2/110284] [14 Regression] Bootstrap failures with m2

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #16 from Gaius Mulley  ---
optimistically closing again - please re-open if it fails on large builds -
thanks!

[Bug c++/110535] Internal error when performing a surrogate call with unsatisfied constraints

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 13.2, thanks for the report.

[Bug c++/67491] [meta-bug] concepts issues

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

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

Bug 110535 Summary: Internal error when performing a surrogate call with 
unsatisfied constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110535

   What|Removed |Added

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

[Bug tree-optimization/101832] __builtin_object_size(P->M, 1) where M ends with a flex-array behaves like sizeof()

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

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

--- Comment #14 from qinzhao at gcc dot gnu.org ---
since it's opened again GCC12, the patch need to be backported to GCC12. then
will be closed at that time.

[Bug modula2/110284] [14 Regression] Bootstrap failures with m2

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

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

--- Comment #15 from CVS Commits  ---
The master branch has been updated by Gaius Mulley :

https://gcc.gnu.org/g:01f6e8b013237041adeac370f8d229aea6304591

commit r14-2654-g01f6e8b013237041adeac370f8d229aea6304591
Author: Gaius Mulley 
Date:   Wed Jul 19 21:01:53 2023 +0100

PR modula2/110284 Make-lang-in m2flex.o and m2pp.o

This patch moves the rule c-family/m2pp.o from Make-lang.in into
Make-maintainer.in.  It also adds m2/gm2-gcc/rtegraph.o and
m2/gm2-compiler-boot/m2flex.o to m2_OBJS.  The object
m2/gm2-compiler-boot/m2flex.o is needed by cc1gm2 whereas
m2/gm2-compiler/m2flex.o is required by m2/stage2/cc1gm2
(which is only built in maintainer to allow debugging via m2
sources rather than the translated to C++ sources).

PR modula2/110284
* Make-lang.in (m2_OBJS): Add m2/gm2-gcc/rtegraph.o and
m2/gm2-compiler-boot/m2flex.o.
(c-family/m2pp.o): Remove.
* Make-maintainer.in (c-family/m2pp.o): Add.

Signed-off-by: Gaius Mulley 

[Bug c++/110535] Internal error when performing a surrogate call with unsatisfied constraints

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:92f6240baf80f998ca6c1408c3ee09d5d2ae68d7

commit r13-7592-g92f6240baf80f998ca6c1408c3ee09d5d2ae68d7
Author: Patrick Palka 
Date:   Tue Jul 18 09:21:40 2023 -0400

c++: constrained surrogate call functions [PR110535]

We weren't checking constraints on pointer/reference-to-function conversion
functions during overload resolution, which caused us to ICE on the first
testcase and reject the second testcase.

PR c++/110535

gcc/cp/ChangeLog:

* call.cc (add_conv_candidate): Check constraints.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-surrogate1.C: New test.
* g++.dg/cpp2a/concepts-surrogate2.C: New test.

(cherry picked from commit 1e0f37df1b12cd91a6dbb523f5c722f9a961edaa)

[Bug libstdc++/109921] c++17/floating_from_chars.cc: compile error: ‘from_chars_strtod’ was not declared in this scope

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|13.2|13.3
 Depends on||110077

--- Comment #6 from Jonathan Wakely  ---
I want to backport this to gcc-13 but I need to fix PR 110077 first, or that
will regress on the branch.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
[Bug 110077] [14 regression] libstdc++-abi/abi_check FAILs on Solaris

[Bug analyzer/110387] [14 Regression] ICE: in key_t, at analyzer/region.h:1110 with -fanalyzer

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

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

David Malcolm  changed:

   What|Removed |Added

   Last reconfirmed||2023-07-19
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from David Malcolm  ---
Thanks for filing this bug.

Confirmed: https://godbolt.org/z/zxfzzr7fj

[Bug libstdc++/110432] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #17 from Jonathan Wakely  ---
The fix has been backported to gcc-13 now. There should be a release candidate
for 13.2 in the next day or so, please try it out on macOS to make sure the fix
works.

[Bug libstdc++/110432] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16

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

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

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

https://gcc.gnu.org/g:61bf34d17473d611bb2695329808810dbd5af478

commit r13-7591-g61bf34d17473d611bb2695329808810dbd5af478
Author: Jonathan Wakely 
Date:   Fri Jun 30 11:07:35 2023 +0100

libstdc++: Fix iostream init for Clang on darwin [PR110432]

The __has_attribute(init_priority) check in  is true for Clang
on darwin, which means that user code including  thinks the
library will initialize the global streams. However, when libstdc++ is
built by GCC on darwin, the __has_attribute(init_priority) check is
false, which means that the library thinks that user code will do the
initialization when  is included. This means that the
initialization is never done.

Add an autoconf check so that the header and the library both make their
decision based on the static properties of GCC at build time, with a
consistent outcome.

As a belt and braces check, also do the initialization in  if
the compiler including that header doesn't support the attribute (even
if the library also containers the initialization). This might result in
redundant initialization done in , but ensures the
initialization happens somewhere if there's any doubt about the
attribute working correctly due to missing linker support.

libstdc++-v3/ChangeLog:

PR libstdc++/110432
* acinclude.m4 (GLIBCXX_CHECK_INIT_PRIORITY): New.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Use GLIBCXX_CHECK_INIT_PRIORITY.
* include/std/iostream: Use new autoconf macro as well as
__has_attribute.
* src/c++98/ios_base_init.h: Use new autoconf macro instead of
__has_attribute.

Reviewed-by: Patrick Palka 
(cherry picked from commit fe2651affa8c15624188bfd062fb894648743431)

[Bug tree-optimization/110315] [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #6 from Andrew Macleod  ---
I think the difference is actually Aldys work to reduce the size of Value_Range
rather than other stack saving changes.  I think I can make some adjustments so
that our usage of Value_Range are on leaf functions in some places instead of
remaining in the call chain.

I'll get back to you

[Bug tree-optimization/101832] __builtin_object_size(P->M, 1) where M ends with a flex-array behaves like sizeof()

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

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

--- Comment #13 from qinzhao at gcc dot gnu.org ---
the fix has been committed into GCC14.

[Bug tree-optimization/101832] __builtin_object_size(P->M, 1) where M ends with a flex-array behaves like sizeof()

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-07-19
 Status|UNCONFIRMED |ASSIGNED

[Bug c++/110122] [13/14 Regression] using an aggregate with a member variable with a user defined copy constructor in a class NTTP causes capture and use of the `this` pointer in a generic lambda to p

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #9 from Patrick Palka  ---
Fixed for GCC 13.2 -- at least, the original testcase is.  The comment #1
testcase isn't a regression and is only fixed on trunk by the followup commit
r14-1698.

[Bug c++/110122] [13/14 Regression] using an aggregate with a member variable with a user defined copy constructor in a class NTTP causes capture and use of the `this` pointer in a generic lambda to p

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:33a84d438883b5d6616048636a5fc47f6dd4ed28

commit r13-7590-g33a84d438883b5d6616048636a5fc47f6dd4ed28
Author: Patrick Palka 
Date:   Sun Jun 11 11:09:16 2023 -0400

c++: extend lookup_template_class shortcut [PR110122]

Here when substituting the injected class name A during regeneration of
the lambda, we find ourselves in lookup_template_class for A with
V=_ZTAXtl3BarEE (i.e. the template parameter object for Foo{}).  The call
to coerce_template_parms within then undesirably tries to make a copy of
this class NTTP argument, which fails because Foo is not copyable.  But it
seems clear that this testcase shouldn't require copyability of Foo.

lookup_template_class has a shortcut for looking up the current class
scope, which would avoid the problematic coerce_template_parms call, but
the shortcut doesn't trigger because it only considers the innermost
class scope which in this case in the lambda type.  So this patch fixes
this by extending the lookup_template_class shortcut to consider outer
class scopes too (and skipping over lambda types since they are never
specialized from lookup_template_class).  We also need to avoid calling
coerce_template_parms when specializing a templated non-template nested
class for the first time (such as A::B in the testcase).  Coercion should
be unnecessary there because the innermost arguments belong to the context
and so should have already been coerced.

PR c++/110122

gcc/cp/ChangeLog:

* pt.cc (lookup_template_class): Extend shortcut for looking up the
current class scope to consider outer class scopes too, and use
current_nonlambda_class_type instead of current_class_type.  Only
call coerce_template_parms when specializing a primary template.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/nontype-class57.C: New test.
* g++.dg/cpp2a/nontype-class58.C: New test.

(cherry picked from commit 682d401a6ba723b2bf98779d056efc8ff2640178)

[Bug tree-optimization/110742] [14 Regression] cc1plus ICE "Floating point exception" during SLP and profiled bootstrap

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

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

--- Comment #9 from Andrew Pinski  ---
Backtrace and some debug:
Program received signal SIGFPE, Arithmetic exception.
0x01d00dd2 in multiple_p (a=2, b=0) at
../../gcc/poly-int.h:2123
2123  return a % b == 0;
(gdb) bt
#0  0x01d00dd2 in multiple_p (a=2, b=0) at
../../gcc/poly-int.h:2123
#1  0x01cf0c61 in vect_prologue_cost_for_slp (node=0x3a6a098,
cost_vec=0x7fffceb0) at ../../gcc/tree-vect-slp.cc:6088

(gdb) up
#1  0x01cf0c61 in vect_prologue_cost_for_slp (node=0x3a6a098,
cost_vec=0x7fffceb0) at ../../gcc/tree-vect-slp.cc:6088
6088  && ! multiple_p (const_nunits, group_size))
(gdb) p group_size
$2 = 0
(gdb) p const_nunits
$3 = 2

[Bug tree-optimization/110742] [14 Regression] cc1plus ICE "Floating point exception" during SLP and profiled bootstrap

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||14.0
  Known to work||13.1.0

--- Comment #8 from Andrew Pinski  ---
Note my reduced testcase worked with GCC 13.1.0 so this is still a GCC 14
regression .

[Bug tree-optimization/110315] [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #5 from Andrew Macleod  ---
(In reply to Andrew Macleod from comment #4)
> (In reply to Richard Biener from comment #2)
> > Confirmed.  Not sure whether it's possible to backport any of the stack
> > usage reduction in ranger from trunk or whether it's other recursion
> > limiting that
> > avoids this there (besides different IL from the frontend ...).
> > 
> > Andrew/Aldy?  The call chain is 2 frames deep when it faults on me
> > (with a -O0 built cc1plus running in gdb).
> 
> huh.  I am not seeing this with the current gcc 13 release branch?  or at
> least I cant get my stage 1 compiler to fail like this

hold on.. I think it was picking up the wrong code nbase.  stay tuned. :-P

[Bug tree-optimization/110742] [14 Regression] cc1plus ICE "Floating point exception" during SLP and profiled bootstrap

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

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

--- Comment #7 from Andrew Pinski  ---
Removed reference to g:08b99fe8ad6 in the summary since the ICE is in SLP and
just happens to be compiling the code that was changed with g:08b99fe8ad6 .

[Bug tree-optimization/110742] [14 Regression] cc1plus ICE "Floating point exception" during profiled bootstrap since commit g:08b99fe8ad6

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-07-19
   Host|armv8l-unknown-linux-gnueab |
   |ihf |
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

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

[Bug tree-optimization/110742] [14 Regression] cc1plus ICE "Floating point exception" during profiled bootstrap since commit g:08b99fe8ad6

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

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

--- Comment #5 from Andrew Pinski  ---
Created attachment 55585
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55585=edit
Reduced testcase

options required:
`-O2  -fprofile-generate-march=armv8-a+simd -mfpu=neon-fp-armv8
-mfloat-abi=hard`

[Bug c++/110566] [13/14 Regression] ICE when instantiating function template with template template parameter with 2 or more auto parameters with a dependent member template, ICE in tsubst, at cp/pt.c

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Marek Polacek  ---
Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624952.html

[Bug libstdc++/99832] std::chrono::system_clock::to_time_t needs ABI tag for 32-bit time_t

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug libstdc++/110593] The std::ratio meta arithmetic can accept non-std::ratio

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug tree-optimization/110315] [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #4 from Andrew Macleod  ---
(In reply to Richard Biener from comment #2)
> Confirmed.  Not sure whether it's possible to backport any of the stack
> usage reduction in ranger from trunk or whether it's other recursion
> limiting that
> avoids this there (besides different IL from the frontend ...).
> 
> Andrew/Aldy?  The call chain is 2 frames deep when it faults on me
> (with a -O0 built cc1plus running in gdb).

huh.  I am not seeing this with the current gcc 13 release branch?  or at least
I cant get my stage 1 compiler to fail like this

[Bug target/110634] Incorrect RISC-V assembly with -fno-omit-frame-pointer

[cleger at rivosinc dot com via Gcc-bugs]

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

Clément Léger  changed:

   What|Removed |Added

 CC||cleger at rivosinc dot com

--- Comment #5 from Clément Léger  ---
(In reply to Andrew Pinski from comment #1)
> I don't see where in any of the spec mentioned that storing of ra is needed
> at all. That is it does not read ambigous to me at all. It just mentions for
> a frame pointer, the frame pointer needs to be saved and nothing about ra.
> 
> This is totally different from the power ABI.

I also stumbled on this problem and looking at the spec, it seems specified
what needs to be stored in a frame record:

"A frame record consists of two XLEN values on the stack; the return address
and the link to the next frame record. The frame pointer register will point to
the innermost frame, thereby starting the linked list. By convention, the
lowest XLEN value shall point to the previous frame, while the next XLEN value
shall be the return address."

So storing ra is actually specified unless you refer to an older version of
this spec but this clarification was added in a (somehow) not so recent commit:
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/e353f995d0645078e4ce5cb1acd355d37cb3e9c2

Regarding frame pointer generation wrt to leaf functions, either GCC should not
generate the frame record or generate a non bogus one. The current one is
unusable since it is malformed. But this behavior should probably depends on
-f(no)omit-frame-leaf-pointer.

[Bug tree-optimization/110731] [11/12 Regression] Wrong-code because of wide-int division since r5-424

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12 Regression]
   |Wrong-code because of   |Wrong-code because of
   |wide-int division since |wide-int division since
   |r5-424  |r5-424
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #5 from Jakub Jelinek  ---
Fixed for 13.2+ so far.

[Bug fortran/110725] [13/14 Regression] internal compiler error: in expand_expr_real_1, at expr.cc:10897

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

  Known to fail||14.0
  Known to work||12.2.0

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
> That would make it accepts-invalid then?

I'm not an expert with OpenMP, so cannot make a decision here.
Note, the original code compiles with 12.2.0.  I don't have 
13.x installed for testing.

While reducing the code to something much smaller, I notice the
idiom of

!$omp target
!$omp teams
!$omp distribute parallel do simd
  DO 75 I=1,M

   75 CONTINUE
!$omp end teams
!$omp end target

everywhere except for the one occurrence in the reduce code of

!$omp target
!$omp teams
!$omp distribute parallel do simd
  DO 75 I=1,M
 U(I+1,N+1) = U(I+1,1)
 V(I,1) = V(I,N+1)
   75 CONTINUE
!$omp end teams
  U(1,N+1) = U(M+1,1)  <-- This seems out-of-place when compared
  V(M+1,1) = V(1,N+1)  <-- to all other code.
!$omp end target
  END SUBROUTINE

If I move the '!$omp end teams' down two lines, the code compiles.  If I remove
the two lines of Fortran code, the code compiles.

[Bug c/91951] goto + mixed declarations + cleanup attribute considered harmful

[ndesaulniers at google dot com via Gcc-bugs]

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

Nick Desaulniers  changed:

   What|Removed |Added

 CC||ndesaulniers at google dot com

--- Comment #3 from Nick Desaulniers  ---
Not sure if it's possible to rename the title of bugs, but a more precise title
for this bug might be:

missed (optimization-level dependent) diagnostic for goto when cleanup
attribute callback is not invoked

[Bug middle-end/110728] should __attribute__((cleanup())) callback get invoked for indirect edges of asm goto

[rjmccall at gmail dot com via Gcc-bugs]

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

--- Comment #8 from John McCall  ---
> Let me clarify.  If GCC were change behavior of `asm goto` to
> invoke the destructor/cleanup function before the backwards edge
> of `asm goto`, I would submit a patch to clang to implement that
> behavior as well.

Ah, thank you, I understand what you're saying now.  Yes, we would take that.

I think this test case might be a little more illuminating and separates out
the issue of the back-edge and the uninitialized variable:
https://godbolt.org/z/doG7414va

```
#include 

#define GOTO 1
#define COMPUTED_GOTO 2
#define ASM_GOTO 3

#define CASE ASM_GOTO

static void free_from(int **ptr) {
free(*ptr);
}

int test() {
#if CASE == COMPUTED_GOTO
void *lbl = &
#endif
if (1) {
__attribute__((cleanup(free_from))) int *p = calloc(sizeof(int), 1);
#if CASE == GOTO
goto label;
#elif CASE == COMPUTED_GOTO
goto *lbl;
#elif CASE == ASM_GOTO
asm goto("<<< asm goto %l0 >>>"label);
#endif
}
label:
return 0;
}
```

GCC produces this output for CASE == ASM_GOTO (stripping the .LFB labels):

```
test:
pushrbp
mov rbp, rsp
sub rsp, 16
mov esi, 1
mov edi, 4
callcalloc
mov QWORD PTR [rbp-8], rax
<<< asm goto .L3 >>>
lea rax, [rbp-8]
mov rdi, rax
callfree_from
.L3:
mov eax, 0
leave
ret
``

It does something similar for CASE == COMPUTED_GOTO.  In both cases, the branch
avoids the cleanup with no diagnostic.  But it does the right thing with CASE
== GOTO.

[Bug tree-optimization/110742] [14 Regression] cc1plus ICE "Floating point exception" during profiled bootstrap since commit g:08b99fe8ad6

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

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

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

[Bug analyzer/109106] GCC Static Analyzer doesn't model printf

[geoffreydgr at icloud dot com via Gcc-bugs]

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

--- Comment #5 from Geoffrey  ---
(In reply to David Malcolm from comment #4)
> Thanks for filing this, and for the comments; marking it as a dup of PR
> 107017
> 
> *** This bug has been marked as a duplicate of bug 107017 ***

Hi, David. I want to ask a question that does GSA supports printf now?

The gcc online docs
(https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-fanalyzer-checker)
says that GSA has hardcoded knowledge about the behavior of this function. But
I find that GSA still cannot handle printf (see
https://godbolt.org/z/6ooW44sPq). Then I checked the source code, I find that
you have modeled `sprintf`. 
I am wondering why GCC static analysis misses `printf`. IMO, it seems
straightforward to model. Or actually it is hard to model?

[Bug target/109558] bpf: support BTF and DWARF tag annotations for BPF

[david.faust at oracle dot com via Gcc-bugs]

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

--- Comment #2 from David Faust  ---
Patches for btf_type_tag WIP, but DWARF for type_tags in certain cases is
incorrect seemingly due to PR debug/110439.  I am still investigating.

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

[Bug tree-optimization/110742] [14 Regression] cc1plus ICE "Floating point exception" during profiled bootstrap since commit g:08b99fe8ad6

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

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

--- Comment #3 from Andrew Pinski  ---
I can reproduce this via a cross compiler:
./cc1plus t.ii  -nostdinc -O2  -fprofile-generate   -fno-exceptions -fno-rtti
-march=armv8-a+simd -mfpu=neon-fp-armv8 -mfloat-abi=hard -mthumb

/home/thiago.bauermann/src/gcc/gcc/ira.cc: In function ‘void
setup_reg_class_relations()’:
/home/thiago.bauermann/src/gcc/gcc/ira.cc:1198:1: internal compiler error:
Floating point exception


So reducing ...

[Bug target/109558] bpf: support BTF and DWARF tag annotations for BPF

[david.faust at oracle dot com via Gcc-bugs]

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

--- Comment #1 from David Faust  ---
v1 patch series for btf_decl_tag:

https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624156.html

This also adds infrastructure which will be used for btf_type_tag.

[Bug middle-end/110728] should __attribute__((cleanup())) callback get invoked for indirect edges of asm goto

[ndesaulniers at google dot com via Gcc-bugs]

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

--- Comment #7 from Nick Desaulniers  ---
(In reply to Andrew Pinski from comment #1)
> I suspect PR 91951 is the same really.

PR 91951 seems to be about a missing diagnostic dependent on optimization
level.  This bug report is more so a question about codegen.

(In reply to Andrew Pinski from comment #2)
> Techincally x does not go out of scope until the } so I don't see how this
> would act any other way.

Compare the codegen with my example vs replacing the `asm goto (..., l0);` with
`goto l0;`.

With `goto`, the destructor is invoked before taking the backward edge.  With
`asm goto` it is not.  That inconsistency leads me to think there might be a
bug (with `asm goto`).

(In reply to Andrew Pinski from comment #4)
> Oh and computed goto has a similar issue too (PR 37722 which is for C++
> deconstructors but cleanup is the same idea there).

Right, that came up in our discussions, too.  I think the difference may be
that with `asm goto` we have the list of labels of possible jump targets and
thus possible edges. With computed goto ("indirect goto") we don't.  So I think
it makes sense to not run destructors for computed goto, and perhaps the
documentation should be made more explicit about that case (then PR 37722
closed as "Working as intended").

(In reply to John McCall from comment #5)
> > If this gets changed in GCC, I'd be happy to modify clang to match that 
> > updated behavior.
> 
> Policy-wise, I don't think clang would accept a patch making this UB
> (effectively what not calling the destructor/cleanup means) instead of
> ill-formed unless a standards body forced us to.  Not calling the
> destructor/cleanup seems like clearly undesirable behavior, and if we can
> define that away in the compiler with relative ease, we should.

Let me clarify.  If GCC were change behavior of `asm goto` to invoke the
destructor/cleanup function before the backwards edge of `asm goto`, I would
submit a patch to clang to implement that behavior as well.  I think we're
(John and I) in agreement that the destructors should be run.

[Bug middle-end/37722] destructors not called on computed goto

[ndesaulniers at google dot com via Gcc-bugs]

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

Nick Desaulniers  changed:

   What|Removed |Added

 CC||ndesaulniers at google dot com

--- Comment #6 from Nick Desaulniers  ---
(In reply to Jakub Jelinek from comment #5)
> I'm afraid for computed gotos all we can do is just document something
> similar

Right, clang behaves this way, too. And I don't see how we'd change that, for
all of the reasons above.  If the documentation doesn't mention this edge case
with the computed goto extension, it should be revised to do so.

Then this bug can be closed as "Working as intended" IMO.

[Bug other/110744] New: [14 regression] cc.dg/tree-ssa/pr84512.c fails after r14-2267-gb8806f6ffbe72

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

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

Bug ID: 110744
   Summary: [14 regression] cc.dg/tree-ssa/pr84512.c fails after
r14-2267-gb8806f6ffbe72
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:b8806f6ffbe72ed8fb7aba3b3a9196ec4d13e614, r14-2267-gb8806f6ffbe72e

make  -k check-gcc RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/pr84512.c"
FAIL: gcc.dg/tree-ssa/pr84512.c scan-tree-dump optimized "return 285;"
# of expected passes1
# of unexpected failures1

commit b8806f6ffbe72ed8fb7aba3b3a9196ec4d13e614 (HEAD)
Author: Ju-Zhe Zhong 
Date:   Mon Jul 3 17:10:26 2023 +0800

Middle-end: Change order of LEN_MASK_LOAD/LEN_MASK_STORE arguments


Hmmm.  There is PR84935 which looks to be the same sort of thing but this just
started occurring for me on powerpc64 with r14-2267-gb8806f6ffbe72.

[Bug tree-optimization/110410] Missed optimization in DOM with a single value range

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|14.0|---
   Keywords|wrong-code  |
Summary|[14 Regression] Different   |Missed optimization in DOM
   |results between -O0 and -O2 |with a single value range

--- Comment #7 from Andrew Pinski  ---
The reduced testcase in comment #3 still has the missed optimization so keeping
this open and changing the summary and removing the regression marker.

[Bug tree-optimization/110410] [14 Regression] Different results between -O0 and -O2

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

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

Bug 110252 Summary: [14 Regression] Wrong code at -O2/3/s on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110252

   What|Removed |Added

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

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #19 from Andrew Pinski  ---
Fixed finally.

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

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

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

--- Comment #18 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r14-2650-g8c79b49cd4fa742f7be739dd21fd2aa040cc1ba3
Author: Andrew Pinski 
Date:   Fri Jul 14 15:55:34 2023 -0700

[PATCH] Fix tree-opt/110252: wrong code due to phiopt using flow sensitive
info during match

Match will query ranger via tree_nonzero_bits/get_nonzero_bits for 2 and
3rd
operand of the COND_EXPR and phiopt tries to do create the COND_EXPR even
if we moving
one statement. That one statement could have some flow sensitive
information on it
based on the condition that is for the COND_EXPR but that might create
wrong code
if the statement was moved out.

This is similar to the previous version of the patch except now we use
flow_sensitive_info_storage instead of manually doing the save/restore
and also handle all defs on a gimple statement rather than just for lhs
of the gimple statement. Oh and a few more testcases were added that
was failing before.

OK? Bootsrapped and tested on x86_64-linux-gnu with no regressions.

PR tree-optimization/110252

gcc/ChangeLog:

* tree-ssa-phiopt.cc (class auto_flow_sensitive): New class.
(auto_flow_sensitive::auto_flow_sensitive): New constructor.
(auto_flow_sensitive::~auto_flow_sensitive): New deconstructor.
(match_simplify_replacement): Temporarily
remove the flow sensitive info on the two statements that might
be moved.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/phi-opt-25b.c: Updated as
__builtin_parity loses the nonzerobits info.
* gcc.c-torture/execute/pr110252-1.c: New test.
* gcc.c-torture/execute/pr110252-2.c: New test.
* gcc.c-torture/execute/pr110252-3.c: New test.
* gcc.c-torture/execute/pr110252-4.c: New test.

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #12 from Andrew Pinski  ---
Fixed.

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

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

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

--- Comment #11 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r14-2648-gbf20b770d9aabb15faf2644b5e3106249cb175f3
Author: Andrew Pinski 
Date:   Tue Jul 18 21:11:46 2023 +

Fix PR110726: a | (a == b) can sometimes produce wrong code

So I had missed/forgot that EQ_EXPR could have an non boolean
type for generic when I implemented r14-2556-g0407ae8a7732d9.
This patch adds check for one bit precision intergal type
which fixes the problem.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

PR tree-optimization/110726

gcc/ChangeLog:

* match.pd ((a|b)&(a==b),a|(a==b),(a)|(a==b)):
Add checks to make sure the type was one bit precision
intergal type.

gcc/testsuite/ChangeLog:

* gcc.c-torture/execute/bitops-1.c: New test.

[Bug tree-optimization/110742] [14 Regression] cc1plus ICE "Floating point exception" during profiled bootstrap since commit g:08b99fe8ad6

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|rtl-optimization|tree-optimization
   Keywords|ra, wrong-code  |build, ice-on-valid-code

--- Comment #2 from Andrew Pinski  ---
Note I think g:08b99fe8ad6 is just exposing the failure. In that the change
exposed the ICE in SLP in the code that g:08b99fe8ad6 changed.

[Bug rtl-optimization/110742] [14 Regression] cc1plus ICE "Floating point exception" during profiled bootstrap since commit g:08b99fe8ad6

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |rtl-optimization
   Keywords||ra, wrong-code
   Target Milestone|--- |14.0

[Bug modula2/110284] [14 Regression] Bootstrap failures with m2

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

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

--- Comment #14 from Gaius Mulley  ---
The first patch was pushed on 2023-06-18 and the second one hasn't been pushed
yet.  It has been tested though - I'll re-test it against master and push.

[Bug tree-optimization/108402] False positive Wuninitialized with ftrivial-auto-var-init=pattern

[arnd at linaro dot org via Gcc-bugs]

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

Arnd Bergmann  changed:

   What|Removed |Added

 CC||arnd at linaro dot org

--- Comment #7 from Arnd Bergmann  ---
I ran into a probably related issue and opened bug #110743 for it, with a
reduced test case. I also found another variation in bug #104550, but that
testcase was fixed by the referenced commit.

[Bug c/110743] New: Unexpected -ftrivial-auto-var-init=pattern behavior with partial bitfields

[arnd at linaro dot org via Gcc-bugs]

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

Bug ID: 110743
   Summary: Unexpected -ftrivial-auto-var-init=pattern behavior
with partial bitfields
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

A warning showed up in Linux kernel builds with code that has a data structure
with sub-byte holes in it, making it appear as though the structure was
uninitialized even though there is no user before the intialization:

struct spi_mem_op {
  struct {
int a : 1;
  };
  struct {
char b : 1;
long c;
  };
};
void spi_nor_read_any_reg(struct spi_mem_op *);
void s25fs256t_post_bfpt_fixup_nor(void) {
  struct spi_mem_op op;
  spi_nor_read_any_reg();
}

$ x86_64-linux-gnu-gcc-12 -O2 -ftrivial-auto-var-init=pattern -Wuninitialized
 x86-64 gcc 12.3 (Editor #1)
x86-64 gcc 12.3 - 905ms (5966B) ~392 lines filtered

Output of x86-64 gcc 12.3 (Compiler #1)

: In function 's25fs256t_post_bfpt_fixup_nor':
:12:21: warning: 'op' is used uninitialized [-Wuninitialized]
   12 |   struct spi_mem_op op;
  | ^~
:12:21: note: 'op' declared here
   12 |   struct spi_mem_op op;
  | ^~

See also https://godbolt.org/z/o96GfTaaT

gcc-11 and earlier don't show this behavior because they do not support
-ftrivial-auto-var-init=pattern. I notice that in the example above, the first
16 bytes of the structure are intialized to zero with an x86 SSE instruction
since they do not contain any actual data bytes, just single bits.

This seems to be the same underlying problem as in bug #104550, but that one is
marked fixed and I cannot reproduce it on gcc-12 or gcc-13.

[Bug libstdc++/110719] Should chrono formatters always use std::time_put for locale's representation?

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:86b36e9f7e3839e923db2fda4962cd3faf2ea47b

commit r14-2646-g86b36e9f7e3839e923db2fda4962cd3faf2ea47b
Author: Jonathan Wakely 
Date:   Wed Jul 19 14:38:08 2023 +0100

libstdc++: Fix locale-specific duration formatting [PR110719]

The r14-2640-gf4bce119f617dc commit only removed fractional seconds for
time points, but it needs to be done for durations and hh_mm_ss types
too.

libstdc++-v3/ChangeLog:

PR libstdc++/110719
* include/bits/chrono_io.h (__formatter_chrono::_S_floor_seconds):
Handle duration and hh_mm_ss.
* testsuite/20_util/duration/io.cc: Check locale-specific
formats.
* testsuite/std/time/hh_mm_ss/io.cc: Likewise.

[Bug c++/110742] [14 Regression] cc1plus ICE "Floating point exception" during profiled bootstrap since commit 08b99fe8ad6

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

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

--- Comment #1 from Thiago Jung Bauermann  
---
Created attachment 55584
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55584=edit
Preprocessed ira.cc.

[Bug c++/110742] New: [14 Regression] cc1plus ICE "Floating point exception" during profiled bootstrap since commit 08b99fe8ad6

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

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

Bug ID: 110742
   Summary: [14 Regression] cc1plus ICE "Floating point exception"
during profiled bootstrap since commit 08b99fe8ad6
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago.bauermann at linaro dot org
CC: saaadhu at gcc dot gnu.org
  Target Milestone: ---
  Host: armv8l-unknown-linux-gnueabihf
Target: armv8l-unknown-linux-gnueabihf

Created attachment 55583
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55583=edit
Output of running with "-v -save-temps -freport-bug".

Our CI detected that commit 08b99fe8ad6c "ira: Skip empty regclass when setting
up reg class relations" introduced an ICE in a profiled bootstrap build on
armv8l-linux-gnueabihf:

/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/./prev-gcc/xg++
-B/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/./prev-gcc/
-B/usr/local/armv8l-unknown-linux-gnueabihf/bin/ -nostdinc++
-B/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/prev-armv8l-unknown-linux-gnueabihf/libstdc++-v3/src/.libs
-B/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/prev-armv8l-unknown-linux-gnueabihf/libstdc++-v3/libsupc++/.libs

-I/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/prev-armv8l-unknown-linux-gnueabihf/libstdc++-v3/include/armv8l-unknown-linux-gnueabihf

-I/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/prev-armv8l-unknown-linux-gnueabihf/libstdc++-v3/include
 -I/home/thiago.bauermann/src/gcc/libstdc++-v3/libsupc++
-L/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/prev-armv8l-unknown-linux-gnueabihf/libstdc++-v3/src/.libs
-L/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/prev-armv8l-unknown-linux-gnueabihf/libstdc++-v3/libsupc++/.libs
 -fno-PIE -c   -g -O2 -fno-checking -gtoggle -fprofile-generate -DIN_GCC   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H
-fno-PIE -I. -I. -I/home/thiago.bauermann/src/gcc/gcc
-I/home/thiago.bauermann/src/gcc/gcc/.
-I/home/thiago.bauermann/src/gcc/gcc/../include 
-I/home/thiago.bauermann/src/gcc/gcc/../libcpp/include
-I/home/thiago.bauermann/src/gcc/gcc/../libcody 
-I/home/thiago.bauermann/src/gcc/gcc/../libdecnumber
-I/home/thiago.bauermann/src/gcc/gcc/../libdecnumber/dpd -I../libdecnumber
-I/home/thiago.bauermann/src/gcc/gcc/../libbacktrace   -o ira.o -MT ira.o -MMD
-MP -MF ./.deps/ira.TPo /home/thiago.bauermann/src/gcc/gcc/ira.cc
during GIMPLE pass: slp
/home/thiago.bauermann/src/gcc/gcc/ira.cc: In function ‘void
setup_reg_class_relations()’:
/home/thiago.bauermann/src/gcc/gcc/ira.cc:1198:1: internal compiler error:
Floating point exception
 1198 | setup_reg_class_relations (void)
  | ^
0x12ff9a5 crash_signal
/home/thiago.bauermann/src/gcc/gcc/toplev.cc:314
0xf7a0d6df ???
../sysdeps/unix/sysv/linux/arm/sigrestorer.S:64
0xf79fdb05 ???
../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
0xf7a3d2c9 __pthread_kill_implementation
./nptl/pthread_kill.c:43
0xf7a0c83f __GI_raise
../sysdeps/posix/raise.c:26
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.
make[3]: *** [Makefile:1181: ira.o] Error 1
make[3]: Leaving directory
'/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/gcc'
make[2]: *** [Makefile:5150: all-stageprofile-gcc] Error 2
make[2]: Leaving directory
'/home/thiago.bauermann/.cache/builds/gcc-native-aarch32'
make[1]: *** [Makefile:26321: stageprofile-bubble] Error 2
make[1]: Leaving directory
'/home/thiago.bauermann/.cache/builds/gcc-native-aarch32'
make: *** [Makefile:1085: all] Error 2

I confirmed that the problem is still present in trunk as of commit
e029635cb72e "[modula2] Variable analysis understands DISPOSE and NIL" from
today.

I'm attaching the output of running with "-v -save-temps -freport-bug", as well
as the corresponding ira.ii.

Tested on Ubuntu 22.04 with:

$ src/gcc/configure \
SHELL=/bin/bash \
--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 \
--disable-multilib \

[Bug d/110712] d: ICE: verify_gimple_failed (conversion of register to a different size in 'view_convert_expr')

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #3 from Iain Buclaw  ---
(In reply to Iain Buclaw from comment #2)
> I think some extra errors during the D front-end codegen pass are likely the
> most appropriate thing to do here, as you say, such things are rejected by
> C/C++, so GDC ought to reject them too.
This might be reviewed in future, so maybe D does define va_list as a pointer
type on targets where it's a static array.  But IIRC, this requires some care
to ensure that it doesn't start generating code inconsistently with what the
middle-end/back-end expect.

[Bug d/110712] d: ICE: verify_gimple_failed (conversion of register to a different size in 'view_convert_expr')

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #2 from Iain Buclaw  ---
(In reply to Richard Biener from comment #1)
> this_2(D)->ap = VIEW_CONVERT_EXPR(ap_3(D));
> 
> it looks odd since ap_3(D) is a is_gimple_reg but a struct[1] definitely
> would not.  Maybe you are missing a dereference here?  In C
> struct[1] would decay to a pointer so
> 
>  this.ap = ap;
> 
> wouldn't work (besides that va_list copying requires va_copy).

Static arrays in D are passed around by value, rather than decaying to a
pointer. However va_list is an inconsistent type on this front.

In some D compilers, it's always a pointer type to get around the
incompatibility with C/C++ - though this requires locals and fields to be
specially initialized before being passed to va_start() or va_copy().

i.e, underneath the hood it does:
---
void va_start(T)(out va_list ap, ref T parmn,
 va_list storage = alloca(__va_list_tag.sizeof))
{
ap = storage;
// initialize *ap
}

void va_copy(out va_list ap, va_list src,
 va_list storage = alloca(__va_list_tag.sizeof))
{
ap = storage;
// copy *src.
}
---

GDC doesn't do this, rather - in a way that mimics C/C++ - va_list static
arrays are decayed to a pointer type when used as a parameter, but semantically
it's still treated as a static array.

I think some extra errors during the D front-end codegen pass are likely the
most appropriate thing to do here, as you say, such things are rejected by
C/C++, so GDC ought to reject them too.