[Bug c++/105852] [13 Regression] ice in instantiate_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105852
--- Comment #1 from David Binderman ---
Reduced C++ code seems to be:
template struct Local { friend Local False(int *); };
Local source_map_url;
Local False(int *);
void New() { False; }
Local False(int *) {}
[Bug c/105853] New: ice in pieces_addr constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105853 Bug ID: 105853 Summary: ice in pieces_addr constructor Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 53086 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53086&action=edit C source code The attached C code does this: $ ../results/bin/gcc -c -w -march=bdver2 bug818.c during RTL pass: expand lib/packets.c: In function ‘compose_nd_ns’: lib/packets.c:1701:5: internal compiler error: Segmentation fault 0xdad1c9 crash_signal(int) /home/dcb/gcc/working/gcc/../../trunk.git/gcc/toplev.cc:322 0x955a4d pieces_addr::pieces_addr(rtx_def*, bool, rtx_def* (*)(void*, void*, long, fixed_size_mode), void*) /home/dcb/gcc/working/gcc/../../trunk.git/gcc/expr.cc:996 0x955a4d op_by_pieces_d::op_by_pieces_d(unsigned int, rtx_def*, bool, rtx_def*, bool, rtx_def* (*)(void*, void*, l ong, fixed_size_mode), void*, unsigned long, unsigned int, bool, bool) /home/dcb/gcc/working/gcc/../../trunk.git/gcc/expr.cc:1174 The code seems to break sometime between git hash 919822adc923b00e and aec868578d851576. I will have my usual go at reducing the code.
[Bug middle-end/105853] [13 regression] ice in pieces_addr constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105853 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0 Version|12.0|13.0 Summary|ice in pieces_addr |[13 regression] ice in |constructor |pieces_addr constructor Keywords||ice-on-valid-code Component|c |middle-end
[Bug middle-end/105853] [13 regression] ice in pieces_addr constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105853
--- Comment #1 from David Binderman ---
Reduced C code seems to be:
struct {
struct {
short e16[3];
}
} const eth_addr_zero = {{}};
void compose_nd_na_ipv6_src() { packet_set_nd(eth_addr_zero); }
Note no -march= setting is required.
[Bug libstdc++/80331] unused const std::string not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331 --- Comment #10 from Marc Glisse --- (In reply to AK from comment #9) > can't repro this with gcc 12.1 Seems like this is fixed? No. As stated in other comments, it still reproduces with a longer string (or with -D_GLIBCXX_USE_CXX11_ABI=0).
[Bug target/105854] New: ICE: in extract_constrain_insn, at recog.cc:2692 (insn does not satisfy its constraints: sse2_lshrv1ti3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105854
Bug ID: 105854
Summary: ICE: in extract_constrain_insn, at recog.cc:2692 (insn
does not satisfy its constraints: sse2_lshrv1ti3)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 53087
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53087&action=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -fcaller-saves -mavx512vl testcase.c
testcase.c: In function 'foo':
testcase.c:29:1: error: insn does not satisfy its constraints:
29 | }
| ^
(insn 326 325 321 2 (set (reg:V1TI 52 xmm16 [128])
(lshiftrt:V1TI (reg:V1TI 52 xmm16 [128])
(const_int 0 [0]))) "testcase.c":18:14 6365 {sse2_lshrv1ti3}
(nil))
during RTL pass: cprop_hardreg
testcase.c:29:1: internal compiler error: in extract_constrain_insn, at
recog.cc:2692
0x775bee _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x775c7b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.cc:118
0x7647b9 extract_constrain_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2692
0x130f4d4 copyprop_hardreg_forward_1
/repo/gcc-trunk/gcc/regcprop.cc:826
0x13108b3 execute
/repo/gcc-trunk/gcc/regcprop.cc:1406
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-992-20220605001627-gad6919374be-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-992-20220605001627-gad6919374be-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220605 (experimental) (GCC)
[Bug tree-optimization/105855] New: missed optimization - vectorization -fsanitize=signed-integer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105855
Bug ID: 105855
Summary: missed optimization - vectorization
-fsanitize=signed-integer-overflow
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
It would be nice if -fsanitize=signed-integer-overflow
would impact optimization less, so it could be used
in production more often.
In the following example, using this flag prevents
vectorization:
void f(int i, float * restrict a, float * restrict b)
{
for (int j = i; j < i + 4; ++j)
a[j] = b[j] + 1.;
}
https://godbolt.org/z/raqdd794x
[Bug tree-optimization/105855] missed optimization - vectorization -fsanitize=signed-integer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105855 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/105855] missed optimization - vectorization -fsanitize=signed-integer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105855 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization --- Comment #1 from Andrew Pinski --- You could in theory version the loop for the no overflow case. Now is the question becomes is it worth the cost of implementing it in the compiler. I doubt it.
[Bug c++/105851] Error: "Duplicate key positions selected" when recreating cfns.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105851 --- Comment #4 from Eric Tang --- (In reply to Andreas Schwab from comment #3) > $$ is makefile quoting, you need to resolve the quoting manually if you want > to run the command outside of make. Is there a means to check that? I removed cfns.h and configured with --enable-maintainer-mode but the header file was not recreated and build failed with: ../.././gcc/cp/except.c:1023:18: fatal error: cfns.h: No such file or directory compilation terminated.
[Bug target/105856] New: ice in emit_move_insn, at expr.cc:4011
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105856
Bug ID: 105856
Summary: ice in emit_move_insn, at expr.cc:4011
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
This C code:
#pragma pack(1)
struct {
unsigned f0;
} static g_251 = {6};
void g_329_3() { func_19(g_251); }
when compiled with -O2 on a arm-32 compiler natively or cross, does this:
during RTL pass: expand
bug819.c: In function ‘g_329_3’:
bug819.c:5:18: internal compiler error: in emit_move_insn, at expr.cc:4011
5 | void g_329_3() { func_19(g_251); }
| ^~
0x67dcba emit_move_insn(rtx_def*, rtx_def*)
/home/dcb/gcc/trunk.git/gcc/expr.cc:4011
0xa2940d load_register_parameters
/home/dcb/gcc/trunk.git/gcc/calls.cc:2192
0xa2c59b expand_call(tree_node*, rtx_def*, int)
/home/dcb/gcc/trunk.git/gcc/calls.cc:3593
0xba77d0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier,
rtx_def**, bool)
/home/dcb/gcc/trunk.git/gcc/expr.cc:11621
The bug appears sometime in the week before git hash aec868578d851576.
[Bug target/105856] ice in emit_move_insn, at expr.cc:4011
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105856 --- Comment #1 from David Binderman --- The bug first appears sometime after git hash de57440858591a88.
[Bug target/105506] Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506 --- Comment #4 from Brecht Sanders --- I just ran `gcc -print-prog-name=cc1` and saw the output was only `cc1` while on working versions it reports a full path to `cc1.exe` (e.g. `d:/prog/winlibs64_stage/custombuilt/share/gcc/bin/../libexec/gcc/x86_64-w64-mingw32/12.1.0/cc1.exe`). In this minimal case Process Monitor also shows the handle to `cc1.exe` is successfully opened but the subsequent calls to QueryInformationVolume and QueryAllInformationFile fail with BUFFER_OVERFLOW.
[Bug target/105506] Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506 --- Comment #5 from Brecht Sanders --- Created attachment 53088 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53088&action=edit Process Monitor when running `gcc -print-prog-name=cc1` Process Monitor when running `gcc -print-prog-name=cc1`
[Bug libstdc++/105857] New: codecvt::do_length causes unexpected buffer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
Bug ID: 105857
Summary: codecvt::do_length causes unexpected buffer overflow
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Consider the following test case:
#include
#include
const std::size_t max_size = 10u;
const char text[] = "
!\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~";
int main()
{
std::locale loc;
std::codecvt< wchar_t, char, std::mbstate_t > const& fac =
std::use_facet< std::codecvt< wchar_t, char, std::mbstate_t > >(loc);
std::mbstate_t mbs = std::mbstate_t();
const char* from = text;
const char* from_to = from + max_size;
std::size_t max = ~static_cast< std::size_t >(0u);
return static_cast< std::size_t >(fac.length(mbs, from, from_to, max));
}
$ g++ -g2 -O0 -o codecvt_length_bug codecvt_length_bug.cpp
Running this causes a crash with a buffer overflow:
Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=140737348011840) at
./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737348011840)
at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=140737348011840) at
./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=140737348011840, signo=signo@entry=6) at
./nptl/pthread_kill.c:89
#3 0x77b56476 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
#4 0x77b3c7f3 in __GI_abort () at ./stdlib/abort.c:79
#5 0x77b9d6f6 in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x77cef943 "*** %s ***: terminated\n") at
../sysdeps/posix/libc_fatal.c:155
#6 0x77c4a76a in __GI___fortify_fail (msg=msg@entry=0x77cef8e9
"buffer overflow detected") at ./debug/fortify_fail.c:26
#7 0x77c490c6 in __GI___chk_fail () at ./debug/chk_fail.c:28
#8 0x77c4a199 in __mbsnrtowcs_chk (dst=, src=, nmc=, len=, ps=,
dstlen=) at ./debug/mbsnrtowcs_chk.c:27
#9 0x77e290d2 in std::codecvt::do_length(__mbstate_t&, char const*, char const*, unsigned long)
const () from /lib/x86_64-linux-gnu/libstdc++.so.6
#10 0x52d3 in std::__codecvt_abstract_base::length (this=0x77f86090, __state=..., __from=0x6040
"
!\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~",
__end=0x604a
"*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~",
__max=18446744073709551615) at /usr/include/c++/11/bits/codecvt.h:219
#11 0x523d in main () at codecvt_length_bug.cpp:14
The problem appears to be that std::codecvt< wchar_t, char, std::mbstate_t
>::do_length() accesses characters outside the [s, s + max_size) range,
apparently using the ~static_cast< std::size_t >(0u) as the size limit. This is
against the do_length() definition in the C++ standard, see
[locale.codecvt.virtuals]/12-14
(http://eel.is/c++draft/locale.codecvt.virtuals#lib:codecvt,do_length):
Effects: The effect on the state argument is as if it called do_in(state,
from, from_end, from, to, to+max, to) for to pointing to a buffer of at least
max elements.
That is, max is only referred to as the size of the potential output buffer,
and the source buffer is specified as [from, from_end). There is no requirement
for max to be within [from, from_end) bounds. If I change max to (sizeof(text)
- 1u) then the buffer overflow does not happen.
(As to the purpose of this code, it is supposed to calculate the size, in
bytes, of the initial sequence of complete characters not larger than
max_size.)
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.2.0-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i68
[Bug libstdc++/105857] codecvt::do_length causes unexpected buffer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857 --- Comment #1 from andysem at mail dot ru --- Created attachment 53089 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53089&action=edit Test case to reproduce the problem.
[Bug libstdc++/105857] codecvt::do_length causes unexpected buffer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857 --- Comment #2 from andysem at mail dot ru --- > outside the [s, s + max_size) range This should be [from, from_to) range. Sorry, posted a little too soon.
[Bug tree-optimization/105835] Dead Code Elimination Regression at -O1 (trunk vs. 12.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105835 Roger Sayle changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com --- Comment #2 from Roger Sayle --- Patch proposed https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596200.html
[Bug c/105858] New: MinGW-w64 64-bit build with --libstdcxx-pch: fatal error: cannot write PCH file: required memory segment unavailable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105858 Bug ID: 105858 Summary: MinGW-w64 64-bit build with --libstdcxx-pch: fatal error: cannot write PCH file: required memory segment unavailable Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: brechtsanders at users dot sourceforge.net Target Milestone: --- When building the Windows 64-bit version of GCC 12.1.0 against MinGW-w64 build with --libstdcxx-pch the following error occurs: In file included from R:/winlibs64_stage/gcc-12.1.0/libstdc++-v3/include/precompiled/extc++.h:82: R:/winlibs64_stage/gcc-12.1.0/build_mingw/x86_64-w64-mingw32/libstdc++-v3/include/ext/enc_filebuf.h:63:1: fatal error: cannot write PCH file: required memory segment unavailable 63 | } // namespace | ^ compilation terminated. This error does not happen when building the 32-bit version.
[Bug c++/105859] New: ICE in instantiate_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105859
Bug ID: 105859
Summary: ICE in instantiate_decl
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sam at gentoo dot org
Target Milestone: ---
Originally reported downstream in Gentoo (https://bugs.gentoo.org/849791) by
Toralf Förster (toralf). Noticed when building dev-games/wfmath-1.0.2.
(Ionen in the downstream bug mentions 11.3.0 is fine, but it fails for me with
11.3.1 20220602 too.)
Reproducer:
```
template struct Vector {
friend Vector Cross(const Vector &, const Vector &);
Vector &rotate(const int &);
};
template <> Vector<> &Vector<>::rotate(const int &) {
Vector __trans_tmp_8 = Cross(__trans_tmp_8, *this);
}
Vector<> Cross(const Vector<> &, const Vector<> &) {}
```
Seems to not require any specific flags:
```
$ g++ foo.ii
foo.ii:3:53: warning: friend declaration ‘Vector< > Cross(const
Vector< >&, const Vector< >&)’ declares a non-template
function [-Wnon-template-friend]
3 | friend Vector Cross(const Vector &, const Vector &);
| ^
foo.ii:3:53: note: (if this is not what you intended, make sure the function
template has already been declared and add ‘<>’ after the function name here)
foo.ii: In member function ‘Vector< >& Vector<
>::rotate(const int&) [with int = 3]’:
foo.ii:8:1: warning: no return statement in function returning non-void
[-Wreturn-type]
8 | }
| ^
foo.ii: In function ‘Vector<> Cross(const Vector<>&, const Vector<>&)’:
foo.ii:9:53: warning: no return statement in function returning non-void
[-Wreturn-type]
9 | Vector<> Cross(const Vector<> &, const Vector<> &) {}
| ^
foo.ii: At global scope:
foo.ii:7:31: internal compiler error: Segmentation fault
7 | Vector __trans_tmp_8 = Cross(__trans_tmp_8, *this);
| ~^~
0xd06f86 crash_signal
/usr/src/debug/sys-devel/gcc-12.1.1_p20220604/gcc-12-20220604/gcc/toplev.cc:322
0x163c55e instantiate_decl(tree_node*, bool, bool)
/usr/src/debug/sys-devel/gcc-12.1.1_p20220604/gcc-12-20220604/gcc/cp/pt.cc:26488
0x130a940 instantiate_pending_templates(int)
/usr/src/debug/sys-devel/gcc-12.1.1_p20220604/gcc-12-20220604/gcc/cp/pt.cc:26809
0x1303070 c_parse_final_cleanups()
/usr/src/debug/sys-devel/gcc-12.1.1_p20220604/gcc-12-20220604/gcc/cp/decl2.cc:5128
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/105859] ICE in instantiate_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105859 --- Comment #1 from Sam James --- Created attachment 53090 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53090&action=edit minimised.ii
[Bug c++/105859] ICE in instantiate_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105859 --- Comment #2 from Sam James --- Created attachment 53091 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53091&action=edit vector.ii.orig.xz
[Bug target/105506] Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506 Martin Storsjö changed: What|Removed |Added CC||martin at martin dot st --- Comment #6 from Martin Storsjö --- This is an old longstanding issue that seems to have reappeared, but which has been fixed differently recently in the very latest mingw-w64 git. But first a brief history of the issue: GCC uses the access() function for checking whether a binary exists and is executable (with the X_OK flag as parameter). On Windows, there's no separate "execute" permission bit, but the X_OK bit (which isn't a documented parameter from Microsoft's side) used to be ignored. In Vista, msvcrt.dll's access() function suddenly stopped ignoring the bit that was used for X_OK (which mingw had decided to use for that purpose), and started erroring out when this bit was set. This was dealt with in 2007 in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33281, by adding a reimplementation of the access() function in mingw. By defining __USE_MINGW_ACCESS, the access() function is redirected to the __mingw_access() function. GCC set -D__USE_MINGW_ACCESS when building on mingw to include this workaround. After some time, it seems like Microsoft reverted this behaviour in msvcrt.dll's access() function, because now it no longer seems like this behaviour is present, not on modern Windows 10, but not even on "modern" installations of Vista either. So the need for -D__USE_MINGW_ACCESS has vanished (and bitrotted in GCC somewhat). UCRT's access() function does have the same issue though - if passed the undocumented, mingw-invented X_OK bit, it errors out. As GCC did try to define __USE_MINGW_ACCESS, the workaround should have been picked up though, but as GCC's codebase had evolved, the define wasn't being set in all the cases where it might have been needed. This was fixed for GCC 11 in https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=89e95ad2e7679322b2f5ee9070ff2721d5ca1d6d (and later backported to GCC 9 and 10 in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101238). But apparently something has changed further in GCC 12, so that this define doesn't end up set in all the places where it needs to. (It'd be interesting to know why/where/when!) In mingw-w64, we decided to enable this workaround unconditionally for UCRT (as a more general fix for other audiences, although GCC is the only one I've heard of needing it) - skipping the UCRT provided access() function and always using the mingw reimplementation, see https://github.com/mingw-w64/mingw-w64/commit/bceadc54d8f32b3f14c69074892e2718eac08e3b. So to successfully build GCC 12 running on UCRT, you'd need to use another GCC install, with the very latest mingw-w64 (or an older release with that fix cherry-picked, plus the following Makefile.in update from https://github.com/mingw-w64/mingw-w64/commit/89bacd2be60fa92dd74d3b5f2074b06a32d8c784), to build GCC 12. Alternatively, see if you can manually pass -D__USE_MINGW_ACCESS to the GCC 12 build, if it'd end up in all the places where it's needed.
[Bug c++/105859] ICE in instantiate_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105859 --- Comment #3 from Sam James --- Ah, it's probably a dupe of bug 105852.
[Bug c++/105859] ICE in instantiate_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105859 Sam James changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Sam James --- . *** This bug has been marked as a duplicate of bug 105852 ***
[Bug c++/105852] [13 Regression] ice in instantiate_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105852 --- Comment #2 from Sam James --- *** Bug 105859 has been marked as a duplicate of this bug. ***
[Bug c++/105852] [13 Regression] ice in instantiate_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105852 --- Comment #3 from Sam James --- Thanks for reporting, beat me to it. Looks like it's same on latest 11 (11.3.1 20220602) and 12 (12.1.1 20220604) snapshots.
[Bug target/105856] [13 Regression] ice in emit_move_insn, at expr.cc:4011
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105856 Roger Sayle changed: What|Removed |Added Summary|ice in emit_move_insn, at |[13 Regression] ice in |expr.cc:4011|emit_move_insn, at ||expr.cc:4011 Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com CC||roger at nextmovesoftware dot com Priority|P3 |P1 Version|12.0|13.0 Status|UNCONFIRMED |ASSIGNED Keywords||ice-on-valid-code Target Milestone|--- |13.0 Last reconfirmed||2022-06-05 Target||arm* Ever confirmed|0 |1 --- Comment #2 from Roger Sayle --- Mine. Sorry for the breakage. I've a fix that avoids the ICE on ARM, and allows GCC to generate the following code for this testcase: g_329_3: mov r0, #6 b func_19 [i.e. the same code as without the #pragma pack(1)]. This is a big improvement on GCC v12 which generates (both with and without #pragma pack(1)): g_329_3: movw r3, #:lower16:.LANCHOR0 movt r3, #:upper16:.LANCHOR0 ldr r0, [r3] b func_19 I'm bootstrapping and regression testing on x86_64 now.
[Bug middle-end/105853] [13 regression] ice in pieces_addr constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105853 Roger Sayle changed: What|Removed |Added Last reconfirmed||2022-06-05 Priority|P3 |P1 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 CC||roger at nextmovesoftware dot com Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com --- Comment #2 from Roger Sayle --- Doh! Mine. Sorry for the breakage. My patch/solution for PR 105856 also resolves this PR. Calling expand_expr with a DECL_INITIAL CONSTRUCTOR from load_register_parameters can trigger unintended pathways, instead we/I need to call the lower level store_constructor directly.
[Bug target/105854] ICE: in extract_constrain_insn, at recog.cc:2692 (insn does not satisfy its constraints: sse2_lshrv1ti3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105854 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #1 from Hongtao.liu --- 21114(define_insn_and_split "ssse3_palignrdi" 21115 [(set (match_operand:DI 0 "register_operand" "=y,x,Yv") 21116(unspec:DI [(match_operand:DI 1 "register_operand" "0,0,Yv") 21117(match_operand:DI 2 "register_mmxmem_operand" "ym,x,Yv") 21118(match_operand:SI 3 "const_0_to_255_mul_8_operand")] 21119 UNSPEC_PALIGNR))] 21120 "(TARGET_MMX || TARGET_MMX_WITH_SSE) && TARGET_SSSE3" Alternative 2 requires Yw instead of Yv since it's splitted to vpsrldq which requires AVX512VL & AVX512BW for evex version.
