[Bug target/113288] [i386] Missing #define for -mavx10.1-256 and -mavx10.1-512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113288 --- Comment #6 from Haochen Jiang --- Fixed on trunk.
[Bug target/113288] [i386] Missing #define for -mavx10.1-256 and -mavx10.1-512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113288 --- Comment #5 from GCC Commits --- The master branch has been updated by Haochen Jiang : https://gcc.gnu.org/g:4ab847b354ee9e13e6052f78f49f575eae3abf3f commit r14-7168-g4ab847b354ee9e13e6052f78f49f575eae3abf3f Author: Haochen Jiang Date: Wed Jan 10 10:20:37 2024 +0800 i386: Add AVX10.1 related macros gcc/ChangeLog: PR target/113288 * config/i386/i386-c.cc (ix86_target_macros_internal): Add __AVX10_1__, __AVX10_1_256__ and __AVX10_1_512__.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 110997, which changed state. Bug 110997 Summary: [13 Regression] internal compiler error: in cxx_eval_constant_expression, at cp/constexpr.cc:8005 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110997 What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |---
[Bug c++/107687] [C++23] P2564 - consteval needs to propagate up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107687 Bug 107687 depends on bug 110997, which changed state. Bug 110997 Summary: [13 Regression] internal compiler error: in cxx_eval_constant_expression, at cp/constexpr.cc:8005 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110997 What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |---
[Bug c++/110997] [13 Regression] internal compiler error: in cxx_eval_constant_expression, at cp/constexpr.cc:8005
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110997 Richard Biener changed: What|Removed |Added Resolution|FIXED |--- Summary|[13/14 Regression] internal |[13 Regression] internal |compiler error: in |compiler error: in |cxx_eval_constant_expressio |cxx_eval_constant_expressio |n, at cp/constexpr.cc:8005 |n, at cp/constexpr.cc:8005 Status|RESOLVED|ASSIGNED Known to work||14.0
[Bug other/113344] [14 regression] gcc.dg/pr15784-1.c fails after r14-7139-g897b95a12b7fe5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113344 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener --- testing a fix (on GENERIC, is_truth_type_for doesn't work for non-vector compares since we tend to have just 'int' as result)
[Bug c++/110997] [13/14 Regression] internal compiler error: in cxx_eval_constant_expression, at cp/constexpr.cc:8005
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110997 --- Comment #5 from Andrew Pinski --- Hmm, the target milestone is set to 13.3.0 but only references patches which have gone in for gcc 14 only
[Bug tree-optimization/113126] [14 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:325 at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113126 Hongtao Liu changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org --- Comment #6 from Hongtao Liu --- > as I thought with AVX512VL we can handle this, but for V2SFmode we get > V2SImode as mask_mode. And changing the test to V4SF/V4DFmode reveals > that we don't use float-extend (I'd have to trace vector lowering and > forwprop). There might be an opportunity to improve what we do > for convertvector. Yes, it's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107432 > > But it fixes the testcase.
[Bug c++/113347] [13 Regression] ICE during gimplification building TVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113347 Richard Biener changed: What|Removed |Added Summary|ICE during gimplification |[13 Regression] ICE during |building TVM|gimplification building TVM Target Milestone|--- |13.3 Known to work||13.2.0 Priority|P3 |P1 --- Comment #3 from Richard Biener --- Hmm, and 13.2.0 worked for me.
[Bug c++/113347] ICE during gimplification building TVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113347 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code, ||needs-bisection --- Comment #2 from Richard Biener --- Reducing it, bisection to the duplicate bug (if any) would be nice.
[Bug c++/113347] ICE during gimplification building TVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113347 --- Comment #1 from Richard Biener --- Created attachment 57047 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57047=edit preprocessed source
[Bug c++/113347] New: ICE during gimplification building TVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113347 Bug ID: 113347 Summary: ICE during gimplification building TVM Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- I see > ./cc1plus -fpreprocessed cross_thread_reduction.cc.ii -quiet -dumpbase-ext > .cc -mtune=generic -march=x86-64 -g -g -O2 -O2 -O2 -Wall -Werror=return-type > -std=c++17 -version -faligned-new=1 -fPIC -fstack-protector-strong > -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -o > cross_thread_reduction.cc.s GNU C++17 (GCC) version 13.2.1 20240112 (x86_64-pc-linux-gnu) compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version 4.0.2-p6, MPC version 1.1.0, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: b21c83316346ea37120ce6d56dd5bdc5 In member function 'tvm::tir::ExprRV tvm::meta_schedule::CrossThreadReductionNode::GetThreadIdxExtentFromTrace(const tvm::tir::Trace&)': cc1plus: internal compiler error: Segmentation fault 0x19cbf8f crash_signal /home/rguenther/src/gcc-13-branch/gcc/toplev.cc:314 0xcc7260 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) /home/rguenther/src/gcc-13-branch/gcc/tree.h:3653 0xd9e44f cp_gimplify_expr(tree_node**, gimple**, gimple**) /home/rguenther/src/gcc-13-branch/gcc/cp/cp-gimplify.cc:552 0x15b96fd gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /home/rguenther/src/gcc-13-branch/gcc/gimplify.cc:16291 0x158d62a gimplify_stmt(tree_node**, gimple**) /home/rguenther/src/gcc-13-branch/gcc/gimplify.cc:7226 0x158a696 gimplify_compound_expr /home/rguenther/src/gcc-13-branch/gcc/gimplify.cc:6412 ... on the GCC 13 branch head. The ICE doesn't occur on trunk.
[Bug target/112280] [14 regression] ICE building libgcrypt-1.10.2 on s390 (during GIMPLE pass: ccp)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112280 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Richard Biener --- Fixed.
[Bug target/112280] [14 regression] ICE building libgcrypt-1.10.2 on s390 (during GIMPLE pass: ccp)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112280 --- Comment #10 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:655b6cb1ea3a0e23124d77dccd5d174ac59c429c commit r14-7166-g655b6cb1ea3a0e23124d77dccd5d174ac59c429c Author: Richard Biener Date: Thu Jan 11 14:55:50 2024 +0100 target/112280 - properly guard permute query The following adds guards avoiding code generation to expand_perm_as_a_vlbr_vstbr_candidate when d.testing_p. PR target/112280 * config/s390/s390.cc (expand_perm_as_a_vlbr_vstbr_candidate): Do not generate code when d.testing_p.
[Bug target/113346] [14 Regression] epiphany-elf build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113346 --- Comment #1 from Richard Biener --- This was with r14-7159-g1a80e9558dd7fe
[Bug target/113346] [14 Regression] epiphany-elf build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113346 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code, ra CC||amylaar at gcc dot gnu.org Target||epiphany-elf Target Milestone|--- |14.0
[Bug target/113346] New: [14 Regression] epiphany-elf build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113346
Bug ID: 113346
Summary: [14 Regression] epiphany-elf build failure
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
[ 297s] libtool: compile:
/home/abuild/rpmbuild/BUILD/gcc-14.0.0+git7159/obj-x
86_64-suse-linux/./gcc/xgcc
-B/home/abuild/rpmbuild/BUILD/gcc-14.0.0+git7159/obj
-x86_64-suse-linux/./gcc/ -B/usr/epiphany-elf/bin/ -B/usr/epiphany-elf/lib/
-isy
stem /usr/epiphany-elf/include -isystem /usr/epiphany-elf/sys-include
--sysroot=
/usr/epiphany-elf/sys-root -DHAVE_CONFIG_H -I.
-I../../../../../libstdc++-v3/src
/libbacktrace -I../.. -I ../../../../../libstdc++-v3/../include -I
../../../../.
./libstdc++-v3/../libgcc -I ../../../libgcc -I .. -I
../../../../../libstdc++-v3
-I ../../../../../libstdc++-v3/../libbacktrace -I
../../../../../libstdc++-v3/.
./libiberty -include
../../../../../libstdc++-v3/src/libbacktrace/backtrace-rena
me.h -D_GNU_SOURCE -DHAVE_SYNC_FUNCTIONS=1 -DHAVE_FCNTL=1
-DBACKTRACE_ELF_SIZE=3
2 -W -Wall -Wwrite-strings -Wmissing-format-attribute -Wcast-qual
-Wstrict-proto
types -Wmissing-prototypes -Wold-style-definition -Wno-unused-but-set-variable
-
g -O2 -c elf.c -o std_stacktrace-elf.o
[ 297s] elf.c: In function 'elf_zlib_verify_checksum':
[ 297s] elf.c:2646:1: error: unable to generate reloads for:
[ 297s] 2646 | }
[ 297s] | ^
[ 297s] (insn 590 577 579 18 (parallel [
[ 297s] (set (reg:CC 349)
[ 297s] (reg:CC 368 [349]))
[ 297s] (use (const_int -4337 [0xef0f]))
[ 297s] (clobber (reg:SI 369))
[ 297s] ]) 46 {*movcc_i}
[ 297s] (expr_list:REG_UNUSED (reg:SI 369)
[ 297s] (nil)))
[ 297s] during RTL pass: reload
[ 297s] elf.c:2646:1: internal compiler error: in curr_insn_transform, at
lra-constraints.cc:4234
[ 297s] 0x424ed2 _fatal_insn(char const*, rtx_def const*, char const*, int,
char const*)
[ 297s]../../gcc/rtl-error.cc:108
[ 297s] 0x41d516 curr_insn_transform
[ 297s]../../gcc/lra-constraints.cc:4234
[ 297s] 0x88ba0f lra_constraints(bool)
[ 297s]../../gcc/lra-constraints.cc:5437
[ 297s] 0x8796ea lra(_IO_FILE*, int)
[ 297s]../../gcc/lra.cc:2442
[ 297s] 0x83500f do_reload
[ 297s]../../gcc/ira.cc:5973
[ 297s] 0x83500f execute
[ 297s]../../gcc/ira.cc:6161
configured with
31s] + ../configure 'CFLAGS= -O2 -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g'
'CXXFLAGS= -O2 -funwind-tables -fasynchronous-unwind-tables
-fstack-clash-protection -Werror=return-type -g' 'XCFLAGS= -O2 -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g'
'TCFLAGS= -O2 -funwind-tables -fasynchronous-unwind-tables
-fstack-clash-protection -Werror=return-type -g' 'GDCFLAGS= -O2 -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection -g' --prefix=/usr
--infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64
--libexecdir=/usr/lib64 --enable-languages=c,c++ --enable-checking=release
--disable-werror --with-gxx-include-dir=/usr/include/c++/14
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --enable-ssp --disable-libssp
--disable-libvtv --enable-cet=auto --disable-libcc1 --disable-plugin
--with-bugurl=https://bugs.opensuse.org/ '--with-pkgversion=SUSE Linux'
--with-slibdir=/usr/epiphany-elf/sys-root/lib64 --with-system-zlib
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linux-futex --enable-gnu-indirect-function --program-suffix=-14
--program-prefix=epiphany-elf- --target=epiphany-elf --disable-nls
--with-sysroot=/usr/epiphany-elf/sys-root
--with-build-sysroot=/usr/epiphany-elf/sys-root
--with-build-time-tools=/usr/epiphany-elf/bin --with-newlib --disable-bootstrap
--enable-link-serialization --disable-libsanitizer --build=x86_64-suse-linux
--host=x86_64-suse-linux
[Bug target/113312] Update __attribute__((interrupt)) for Intel FRED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312 --- Comment #16 from H.J. Lu --- I updated users/hjl/pr113312/master branch to handle function pointers.
[Bug target/113345] miss optimization for psign{b,w,d}.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113345 Hongtao Liu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Hongtao Liu --- I realize it should psignb will select 0 when the second operand is 0. it's b < 0 ? -a : ((b == 0) ? 0 : a).
[Bug target/113039] [14 Regression] -fcf-protection -fcf-protection=branch doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113039 Hongtao Liu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Hongtao Liu --- Fixed.
[Bug target/113039] [14 Regression] -fcf-protection -fcf-protection=branch doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113039 --- Comment #4 from GCC Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:75ed46558a2e085ba12641a47112e37f114faee0 commit r14-7164-g75ed46558a2e085ba12641a47112e37f114faee0 Author: liuhongt Date: Mon Jan 8 14:04:38 2024 +0800 Update documents for fcf-protection= After r14-2692-g1c6231c05bdcca, the option is defined as EnumSet and -fcf-protection=branch won't unset any others bits since they're in different groups. So to override -fcf-protection, an explicit -fcf-protection=none needs to be added and then with -fcf-protection=XXX gcc/ChangeLog: PR target/113039 * doc/invoke.texi (fcf-protection=): Update documents.
[Bug target/113345] miss optimization for psign{b,w,d}.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113345 --- Comment #1 from Hongtao Liu --- > > maybe we can just refactor the pattern as blow, then combine can generate > the pattern for us. > > 22115(define_insn "_psign3" > 22116 [(set (match_operand:VI124_AVX2 0 "register_operand" "=x,x") > 22117(unspec:VI124_AVX2 > 22118 [(match_operand:VI124_AVX2 1 "register_operand" "0,x") > (neg:VI124:(match_dup 1) > 22119 (match_operand:VI124_AVX2 2 "vector_operand" "xja,xjm")] > 22120 UNSPEC_PBLENDV))] Not for VI2, but ok for VI14.
[Bug target/113345] New: miss optimization for psign{b,w,d}.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113345
Bug ID: 113345
Summary: miss optimization for psign{b,w,d}.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: liuhongt at gcc dot gnu.org
Target Milestone: ---
void
foo (short* __restrict a, short* b, short* c)
{
for (int i = 0; i != 1000; i++)
{
a[i] = c[i] < 0 ? -b[i] : b[i];
}
}
gcc -O2 -mavx2
foo(char*, char*, char*):
xorl %eax, %eax
vpxor %xmm2, %xmm2, %xmm2
.L2:
vmovq (%rsi,%rax), %xmm0
vmovq (%rdx,%rax), %xmm1
vpsubb %xmm0, %xmm2, %xmm3
vpcmpgtb %xmm1, %xmm2, %xmm1
vpblendvb %xmm1, %xmm3, %xmm0, %xmm0
vmovq %xmm0, (%rdi,%rax)
addq $8, %rax
cmpq $1000, %rax
jne .L2
ret
it can be optimized with psignw.
22115(define_insn "_psign3"
22116 [(set (match_operand:VI124_AVX2 0 "register_operand" "=x,x")
22117(unspec:VI124_AVX2
22118 [(match_operand:VI124_AVX2 1 "register_operand" "0,x")
22119 (match_operand:VI124_AVX2 2 "vector_operand" "xja,xjm")]
22120 UNSPEC_PSIGN))]
maybe we can just refactor the pattern as blow, then combine can generate the
pattern for us.
22115(define_insn "_psign3"
22116 [(set (match_operand:VI124_AVX2 0 "register_operand" "=x,x")
22117(unspec:VI124_AVX2
22118 [(match_operand:VI124_AVX2 1 "register_operand" "0,x")
(neg:VI124:(match_dup 1)
22119 (match_operand:VI124_AVX2 2 "vector_operand" "xja,xjm")]
22120 UNSPEC_PBLENDV))]
[Bug fortran/113338] Valid Code Rejected, bind(C) procedure with pointer argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113338 --- Comment #2 from Brad Richardson --- The addition of CFI_cdesc_t in 2018 means it is possible to pass non-interoperable types to C so long as it doesn't need to know anything about its type (i.e. doesn't try to modify or copy it). And yes, in this example it's possible to add bind(C) to the type, but in the code I'm trying to write I can't.
[Bug target/113312] Update __attribute__((interrupt)) for Intel FRED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312 --- Comment #15 from H. Peter Anvin --- That should be fine for this use case, obviously. I should add the following: the reason the assembly stub isn't a problem for FRED whereas it is a bit of a nuisance for IDT-style delivery is that with FRED, vector dispatch is done in software, not hardware. This is exactly because *most* operating systems do need some amount of common entry/exit code anyway, and having to duplicate it is a severe nuisance. In the specific case of Linux, the full register set, including saved registers, are a required part of the exception frame in order for things like ptrace() and fork() to work correctly, so relying on the compiler to save the "saved" registers doesn't work for us anyway. So since there is only *one* instance of the assembly stub needed, it means there isn't a whole separate stub needed for every handler.
[Bug target/113312] Update __attribute__((interrupt)) for Intel FRED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312 --- Comment #14 from H.J. Lu --- Here is a branch for __attribute__((no_callee_saved_registers)): https://gitlab.com/x86-gcc/gcc/-/commits/users/hjl/pr113312/master Calling a function with __attribute__((no_callee_saved_registers)) doesn't work since GCC won't restore clobbered caller-saved registers. Also calling a function with __attribute__((no_callee_saved_registers)) via a function pointer won't work correctly.
[Bug other/113344] [14 regression] gcc.dg/pr15784-1.c fails after r14-7139-g897b95a12b7fe5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113344 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-01-12 Target Milestone|--- |14.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||missed-optimization, ||testsuite-fail --- Comment #2 from Andrew Pinski --- .
[Bug other/113344] [14 regression] gcc.dg/pr15784-1.c fails after r14-7139-g897b95a12b7fe5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113344 --- Comment #3 from Andrew Pinski --- https://gcc.gnu.org/pipermail/gcc-regression/2024-January/078983.html
[Bug other/113344] [14 regression] gcc.dg/pr15784-1.c fails after r14-7139-g897b95a12b7fe5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113344 --- Comment #1 from Andrew Pinski --- Confirmed, it fails everywhere too.
[Bug c++/102609] [C++23] P0847R7 - Deducing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609 --- Comment #29 from waffl3x --- https://cplusplus.github.io/CWG/issues/2789.html My alteration to CWG2789 came up on reddit and I realized I should probably post about it here. Instead of: "if both are non-static member functions, they have the same types for their object parameters, and" We assumed it would be more correct for it to consider corresponding object parameters: "if both are non-static member functions, they have corresponding object parameters, and" Without this change in wording, the behavior of overload resolution is different for member function templates with constraints and member functions that are not templates with constraints. I felt that would be undesirable so I assumed that the second wording was closer to the intentions behind CWG2789. This is the behavior that's currently been implemented, are there any objections?
[Bug libstdc++/113258] Pre-C++17 code that replaces malloc/free crashes when mixed with post-C++17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 --- Comment #25 from Jonathan Wakely --- Fixed on trunk only so far.
[Bug other/113344] New: [14 regression] gcc.dg/pr15784-1.c fails after r14-7139-g897b95a12b7fe5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113344 Bug ID: 113344 Summary: [14 regression] gcc.dg/pr15784-1.c fails after r14-7139-g897b95a12b7fe5 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:897b95a12b7fe549ec2cb8ef3a3f0e4fbabf9737, r14-7139-g897b95a12b7fe5 make -k check-gcc RUNTESTFLAGS="dg.exp=gcc.dg/pr15784-1.c" FAIL: gcc.dg/pr15784-1.c scan-tree-dump-times gimple "ABS_EXPR" 0 # of expected passes1 # of unexpected failures1 commit 897b95a12b7fe549ec2cb8ef3a3f0e4fbabf9737 (HEAD) Author: Richard Biener Date: Thu Jan 11 12:02:43 2024 +0100 tree-optimization/113126 - vector extension compare optimization
[Bug jit/113343] New: Float values are not correct when cross-compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113343 Bug ID: 113343 Summary: Float values are not correct when cross-compiling Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Values created by gcc_jit_context_new_rvalue_from_double are wrong when cross-compiling to an arch where the encoding of floats is different than the host. I'll soon post a patch for to fix this.
[Bug c++/110065] [11/12/13/14 Regression] [C++20/2b] auto return type in template argument causes ICE, also accepts-invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110065 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- I think we need to bring the check back into cp_parser_template_type_arg; parser->auto_is_implicit_function_template_parm_p is false here so we won't pedwarn.
[Bug libstdc++/113200] std::char_traits::move is not constexpr when the argument is a string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113200 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #13 from Jonathan Wakely --- Fixed for 12.4 and 13.3, thanks for the report.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 113200, which changed state. Bug 113200 Summary: std::char_traits::move is not constexpr when the argument is a string literal https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113200 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/113200] std::char_traits::move is not constexpr when the argument is a string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113200 --- Comment #12 from GCC Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:26a9e8cee4d20e5b08c0336439c8f69a2f06af1c commit r12-10090-g26a9e8cee4d20e5b08c0336439c8f69a2f06af1c Author: Jonathan Wakely Date: Wed Jan 3 15:01:09 2024 + libstdc++: Fix std::char_traits::move [PR113200] The current constexpr implementation of std::char_traits::move relies on being able to compare the pointer parameters, which is not allowed for unrelated pointers. We can use __builtin_constant_p to determine whether it's safe to compare the pointers directly. If not, then we know the ranges must be disjoint and so we can use char_traits::copy to copy forwards from the first character to the last. If the pointers can be compared directly, then we can simplify the condition for copying backwards to just two pointer comparisons. libstdc++-v3/ChangeLog: PR libstdc++/113200 * include/bits/char_traits.h (__gnu_cxx::char_traits::move): Use __builtin_constant_p to check for unrelated pointers that cannot be compared during constant evaluation. * testsuite/21_strings/char_traits/requirements/113200.cc: New test. (cherry picked from commit 15cc291887dc9dd92b2c93f4545e20eb6c190122)
[Bug c++/113342] Template parameter does not shadow member enum value.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113342 --- Comment #2 from Andrew Pinski --- Note there was a change between `clang 10` and `clang 11` which changed clang into accepting the code. So I am 99% sure it is that paper which caused the change ...
[Bug c++/113342] Template parameter does not shadow member enum value.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113342 --- Comment #1 from Andrew Pinski --- Note MSVC has the same behavior as GCC here: ``` (13): error C2244: 'Job::create': unable to match function definition to an existing declaration (13): note: see declaration of 'Job::create' (13): note: definition (13): note: 'void Job::create(Ref)' (13): note: existing declarations (13): note: 'void Job::create(Ref)' ``` This is most likely related to https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1787r6.html paper.
[Bug c++/113342] New: Template parameter does not shadow member enum value.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113342
Bug ID: 113342
Summary: Template parameter does not shadow member enum value.
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: courteauxmartijn at gmail dot com
Target Milestone: ---
Consider the boolean template parameter named "GPU" (think: the "Ref"
references something on a GPU):
template
struct Ref {};
struct Job{
enum Device { CPU, GPU };
template
void create(Ref ref);
};
template
void Job::create(Ref ref) {}
The Job::Device enum has as second value "GPU". The implementation on the last
line of Job::create(Ref ref) treats GPU as this second enum value, instead
of the boolean template argument. I believe the existence of the template
argument named "GPU" should shadow the enum value. However, the compiler
outputs this:
:12:6: error: no declaration matches 'void Job::create(Ref)'
12 | void Job::create(Ref ref) {}
| ^~~
:8:10: note: candidate is: 'template void
Job::create(Ref)'
8 | void create(Ref ref);
| ^~
:4:8: note: 'struct Job' defined here
4 | struct Job{
|^~~
Notice in the first line that it treated the GPU as a "true", which would
originate from the fact that CPU has value 0, and GPU value 1 in that enum,
which gets converted to a bool implicitly.
https://godbolt.org/z/ro9hPvsz3
(Clang does compile this example as I expect it.)
[Bug libstdc++/105505] P1951R1 (Default Arguments for pair's Forwarding Constructor) is unimplemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105505 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |14.0
[Bug libstdc++/113320] libstdc++ accepts std::format(std::move(runtime_fmt), 42);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113320 --- Comment #2 from Jonathan Wakely --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642741.html
[Bug libstdc++/110512] C++20 random access iterators run sequentially with PSTL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110512 --- Comment #9 from Jonathan Wakely --- Patch posted for review: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642732.html
[Bug target/113341] Using GCC as the bootstrap compiler breaks LLVM on 32-bit PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341 --- Comment #8 from Jessica Clarke --- The clang/ subdirectory should be building itself with -fno-strict-aliasing on GCC already
[Bug libfortran/113313] execute_command_line hangs at run time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313 --- Comment #6 from john.harper at vuw dot ac.nz --- I know nothing about either applying gfortran patches or MatterMost but I'm willing to try. On Thu, 11 Jan 2024, jvdelisle at gcc dot gnu.org wrote: > Date: Thu, 11 Jan 2024 20:18:36 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/113313] execute_command_line hangs at run time > Resent-Date: Fri, 12 Jan 2024 09:18:48 +1300 (NZDT) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313 > > Jerry DeLisle changed: > > What|Removed |Added > > CC||jvdelisle at gcc dot gnu.org > > --- Comment #4 from Jerry DeLisle --- > I just started looking at this today. I will give the patch a spin in the next > few days and if tests OK I can commit. > > John, are you able tp apply Steve's patch and try it? If not would you like to > learn how? I can show people the ropes. We have a MatterMost workspace you > can join and I can linkup with you there. (I will send you an invite, just let > me know.) > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug target/113341] Using GCC as the bootstrap compiler breaks LLVM on 32-bit PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #7 from Andrew Pinski ---
`-fno-lifetime-dse` is already used but I get the feeling there might be strict
aliasing issues in the code though. What happens if you add
-fno-strict-aliasing ?
This code gives me strict aliasing violation vibes:
```
T **getAddressOfPointer(ExternalASTSource *Source) const {
// Ensure the integer is in pointer form.
(void)get(Source);
return reinterpret_cast();
}
```
[Bug target/113341] Using GCC as the bootstrap compiler breaks LLVM on 32-bit PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341 --- Comment #6 from Andrew Pinski --- The backtrace in the llvm bug report is not very useful either. Maybe look into that first to see if it is obvious which function might be compiling "incorrectly". Maybe there is a bug in the new clang code which only shows up on powerpc ...
[Bug target/113341] Using GCC as the bootstrap compiler breaks LLVM on 32-bit PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341 --- Comment #5 from Segher Boessenkool --- (In reply to John Paul Adrian Glaubitz from comment #3) > (In reply to Segher Boessenkool from comment #2) > > We need a reduced testcase. > > Any suggestion on how to proceed here? Nothing in particular, no. We need that for *any* bug though!
[Bug c++/113124] g++ should relax designated initialiser rules for trivial classes (read: C structures) and C arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-01-11 CC||jason at gcc dot gnu.org --- Comment #9 from Jason Merrill --- Doing this for constant initializers for C compatibility makes sense to me. But it isn't just a matter of adjusting the diagnostic, we would also need to actually do the sorting to make the initialization work. Still probably not that much work, but not trivial.
[Bug target/113341] Using GCC as the bootstrap compiler breaks LLVM on 32-bit PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341 --- Comment #4 from Andrew Pinski --- I should mention that LLVM has/had known issues with -flifetime-dse so it might be useful also to show how stage1 of LLVM/clang was being built.
[Bug target/113341] Using GCC as the bootstrap compiler breaks LLVM on 32-bit PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341 --- Comment #3 from John Paul Adrian Glaubitz --- (In reply to Andrew Pinski from comment #1) > This could still be a bug in LLVM too. > > Without much more information, it is hard to decide. I fully agree. I filed this bug report to broaden the audience looking for suggestions how to debug this. (In reply to Segher Boessenkool from comment #2) > We need a reduced testcase. Any suggestion on how to proceed here?
[Bug target/113341] Using GCC as the bootstrap compiler breaks LLVM on 32-bit PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341 --- Comment #2 from Segher Boessenkool --- We need a reduced testcase.
[Bug target/113341] Using GCC as the bootstrap compiler breaks LLVM on 32-bit PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-01-11 Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- This could still be a bug in LLVM too. Without much more information, it is hard to decide.
[Bug target/113341] New: Using GCC as the bootstrap compiler breaks LLVM on 32-bit PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341 Bug ID: 113341 Summary: Using GCC as the bootstrap compiler breaks LLVM on 32-bit PowerPC Product: gcc Version: 13.2.1 URL: https://github.com/llvm/llvm-project/issues/72279 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de CC: jrtc27 at jrtc27 dot com, segher at gcc dot gnu.org, sjames at gcc dot gnu.org Target Milestone: --- Using GCC on 32-bit PowerPC as the bootstrap compiler to build LLVM leads to clang crashing during stage 2 with a backtrace. This does not happen when LLVM is used as the bootstrap compiler. The backtrace that clang generates can be found in the LLVM bug report [1]. The problem was observed with LLVM 17, so I initially suspected a regression in LLVM. I was able to bisect issue which lead to the following commit in LLVM: bc73ef0031b50f7443615fef614fb4ecaaa4bd11 is the first bad commit commit bc73ef0031b50f7443615fef614fb4ecaaa4bd11 Author: Richard Smith Date: Thu Mar 30 14:21:31 2023 -0700 PR60985: Fix merging of lambda closure types across modules. However, since the problem does not show when using LLVM as the bootstrap compiler instead of GCC, I'm suspecting that GCC is miscompiling the code. > [1] https://github.com/llvm/llvm-project/issues/72279
[Bug c++/113191] [11/12/13/14 Regression] Incorrect overload resolution when base class function introduced with a using declaration is more constrained than a function declared in the derived class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113191 --- Comment #3 from GCC Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:61b493f17e6fea5a0fb45b6a050259ca326c13a7 commit r14-7157-g61b493f17e6fea5a0fb45b6a050259ca326c13a7 Author: Jason Merrill Date: Tue Jan 9 05:15:01 2024 -0500 c++: corresponding object parms [PR113191] As discussed, our handling of corresponding object parameters needed to handle the using-declaration case better. And I took the opportunity to share code between the add_method and cand_parms_match uses. This patch specifically doesn't compare reversed parameters, but a follow-up patch will. PR c++/113191 gcc/cp/ChangeLog: * class.cc (xobj_iobj_parameters_correspond): Add context parm. (object_parms_correspond): Factor out of... (add_method): ...here. * method.cc (defaulted_late_check): Use it. * call.cc (class_of_implicit_object): New. (object_parms_correspond): Overload taking two candidates. (cand_parms_match): Use it. (joust): Check reversed before comparing constraints. * cp-tree.h (object_parms_correspond): Declare. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-memfun4.C: New test.
[Bug c++/102609] [C++23] P0847R7 - Deducing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #28 from Jakub Jelinek ---
It doesn't help that the mangling issue doesn't have implementation in form of
a mangling ABI patch, that would help to figure out e.g. whether it either H or
CV-qualifiers ref-qualifiers.
Anyway, I think for the mangler the likely change on the GCC side is
--- gcc/cp/mangle.cc.jj 2024-01-10 12:19:08.068675921 +0100
+++ gcc/cp/mangle.cc2024-01-11 22:55:14.112489966 +0100
@@ -1247,6 +1247,8 @@ write_nested_name (const tree decl)
write_char ('R');
}
}
+ else if (DECL_XOBJ_MEMBER_FUNCTION_P (decl))
+write_char ('H');
/* Is this a template instance? */
if (tree info = maybe_template_info (decl))
but one would need to add support for the libiberty demangler as well.
[Bug c++/102609] [C++23] P0847R7 - Deducing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #27 from Gašper Ažman ---
I think there is an example in the standard that distinguishes those two as
far as overload resolution is concerned.
On Thu, Jan 11, 2024, 21:08 waffl3x at protonmail dot com <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
>
> --- Comment #26 from waffl3x ---
> (In reply to corentinjabot from comment #25)
> > Hey folks.
> > Congrats on landing support for deducing this in GCC.
>
> Thanks!
>
> > While there is no spec for it, after discussion here,
> > https://github.com/itanium-cxx-abi/cxx-abi/issues/148 explicit objects
> > parameters are mangled with `H`
> > This is the form that has been adopted for Clang.
> >
> > The reason we need mangling is because WG21 made the following
> well-formed
> > (and that was reaffirmed. In fact, some complexity was added by P2797)
> >
> >
> >struct S {
> > static void f(S);
> > void f(this S);
> >};
> >
> > And we need a way to distinguish both functions
> > I wasn't sure you were aware of this; I hope that form of mangling will
> work
> > for you.
> >
> >
> > Thanks
>
> I don't have the experience to comment but my gut says this is a weird
> outcome. Oh well! I think I know how to implement this so I'll give it
> a go at some point today. If I have any trouble I'll leave it for
> someone else.
>
> Thanks for informing us.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
[Bug c++/113308] derived class doesn't currently allow inherited explicit object member function post increment operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113308 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Jonathan Wakely --- Yes, I think gcc is correct here. Explicit object functions aren't immune to name hiding.
[Bug c++/113340] ICE when an explicit object parameter is attempted to be used in a destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113340
--- Comment #2 from Marek Polacek ---
I suppose the following would be one way to fix it:
--- a/gcc/cp/decl2.cc
+++ b/gcc/cp/decl2.cc
@@ -312,6 +312,12 @@ maybe_retrofit_in_chrg (tree fn)
basetype = TREE_TYPE (TREE_VALUE (arg_types));
arg_types = TREE_CHAIN (arg_types);
+ if (!DECL_ARGUMENTS (fn))
+{
+ gcc_checking_assert (seen_error ());
+ return;
+}
+
parms = DECL_CHAIN (DECL_ARGUMENTS (fn));
/* If this is a subobject constructor or destructor, our caller will
[Bug tree-optimization/113339] `-a/-b` is not simplified to `a/b` if done in seperate statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113339 --- Comment #3 from Andrew Pinski --- So I looked into the wrong part of fold, but anyways PR 23669 added the folding to fold instead (and I just noticed I implemented it originally).
[Bug c++/102609] [C++23] P0847R7 - Deducing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #26 from waffl3x ---
(In reply to corentinjabot from comment #25)
> Hey folks.
> Congrats on landing support for deducing this in GCC.
Thanks!
> While there is no spec for it, after discussion here,
> https://github.com/itanium-cxx-abi/cxx-abi/issues/148 explicit objects
> parameters are mangled with `H`
> This is the form that has been adopted for Clang.
>
> The reason we need mangling is because WG21 made the following well-formed
> (and that was reaffirmed. In fact, some complexity was added by P2797)
>
>
>struct S {
> static void f(S);
> void f(this S);
>};
>
> And we need a way to distinguish both functions
> I wasn't sure you were aware of this; I hope that form of mangling will work
> for you.
>
>
> Thanks
I don't have the experience to comment but my gut says this is a weird
outcome. Oh well! I think I know how to implement this so I'll give it
a go at some point today. If I have any trouble I'll leave it for
someone else.
Thanks for informing us.
[Bug c++/113340] ICE when an explicit object parameter is attempted to be used in a destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113340 Marek Polacek changed: What|Removed |Added Keywords||ice-on-invalid-code Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Last reconfirmed||2024-01-11 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/113340] New: ICE when an explicit object parameter is attempted to be used in a destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113340
Bug ID: 113340
Summary: ICE when an explicit object parameter is attempted to
be used in a destructor
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: friedkeenan at protonmail dot com
Target Milestone: ---
GCC segfaults on the following code:
struct S {
~S(this S &) = default;
};
Godbolt link: https://godbolt.org/z/G6rq3ra6W
It should be noted that explicit object parameters are not allowed for
destructors in the first place, but nonetheless an ICE should not occur when it
is attempted.
[Bug libstdc++/112477] [13/14 Regression] Assignment of value-initialized iterators differs from value-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112477 --- Comment #11 from GCC Commits --- The releases/gcc-13 branch has been updated by Francois Dumont : https://gcc.gnu.org/g:ffc5684a4d3d3c457e5d311e7088f3487cf5083e commit r13-8212-gffc5684a4d3d3c457e5d311e7088f3487cf5083e Author: François Dumont Date: Wed Jan 10 19:06:48 2024 +0100 libstdc++: [_GLIBCXX_DEBUG] Fix assignment of value-initialized iterator [PR112477] Now that _M_Detach do not reset iterator _M_version value we need to reset it when the iterator is attached to a new sequence. Even if this sequence is null like when assigning a value-initialized iterator. In this case _M_version shall be reset to 0. libstdc++-v3/ChangeLog: PR libstdc++/112477 * src/c++11/debug.cc (_Safe_iterator_base::_M_attach): Reset _M_version to 0 if attaching to null sequence. (_Safe_iterator_base::_M_attach_single): Likewise. (_Safe_local_iterator_base::_M_attach): Likewise. (_Safe_local_iterator_base::_M_attach_single): Likewise. * testsuite/23_containers/map/debug/112477.cc: New test case. Reviewed-by: Jonathan Wakely
[Bug c++/102609] [C++23] P0847R7 - Deducing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
corentinjabot at gmail dot com changed:
What|Removed |Added
CC||corentinjabot at gmail dot com
--- Comment #25 from corentinjabot at gmail dot com ---
Hey folks.
Congrats on landing support for deducing this in GCC.
While there is no spec for it, after discussion here,
https://github.com/itanium-cxx-abi/cxx-abi/issues/148 explicit objects
parameters are mangled with `H`
This is the form that has been adopted for Clang.
The reason we need mangling is because WG21 made the following well-formed (and
that was reaffirmed. In fact, some complexity was added by P2797)
struct S {
static void f(S);
void f(this S);
};
And we need a way to distinguish both functions
I wasn't sure you were aware of this; I hope that form of mangling will work
for you.
Thanks
[Bug libfortran/113313] execute_command_line hangs at run time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #4) > I just started looking at this today. I will give the patch a spin in the > next few days and if tests OK I can commit. > > John, are you able tp apply Steve's patch and try it? If not would you like > to learn how? I can show people the ropes. We have a MatterMost workspace > you can join and I can linkup with you there. (I will send you an invite, > just let me know.) Jerry, there are 2 paths through the function execute_command_line() in execute_command_line.c One is for synchronous execution and one is for asynchronous. For async, exitstat is untouched. For synchronous, exitstat is set. EXITSTAT (optional) shall be a scalar of type integer with a decimal exponent range of at least nine. It is an INTENT(INOUT) argument. If the command is executed synchronously, it is assigned the value of the processor-dependent exit status. Otherwise, the value of EXITSTAT is unchanged. If I read the code correctly, it tries to save a copy of the input value of exitstat, and then uses that to compare to the returned value. if exitstat is present, then is should simply be set to the return value.
[Bug libfortran/113313] execute_command_line hangs at run time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #4 from Jerry DeLisle --- I just started looking at this today. I will give the patch a spin in the next few days and if tests OK I can commit. John, are you able tp apply Steve's patch and try it? If not would you like to learn how? I can show people the ropes. We have a MatterMost workspace you can join and I can linkup with you there. (I will send you an invite, just let me know.)
[Bug target/113324] internal compiler error: in reload_combine_note_use, at postreload.c:1534
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113324 Roland Illig changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #3 from Roland Illig --- (In reply to Mikael Pettersson from comment #2) > I can reproduce with gcc-10.5.0 hosted on x86_64-pc-linux-gnu targeting > vax-netbsdelf, but not with gcc-11.4.0. 12.3.0, or 13.2.0. Thanks for the confirmation, I'll wait until NetBSD updates to GCC 12 then.
[Bug fortran/113338] Valid Code Rejected, bind(C) procedure with pointer argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113338 --- Comment #1 from anlauf at gcc dot gnu.org --- NAG also rejects the code. The code compiles with gfortran if one declares t interoperable: type, bind(c) :: t Note that F2008 still had: "(5) any dummy argument without the VALUE attribute corresponds to a formal parameter of the prototype that is of a pointer type, and the dummy argument is interoperable with an entity of the referenced type (ISO/IEC 9899:1999, 6.2.5, 7.17, and 7.18.1) of the formal parameter, ..." I wonder why the interoperability requirement was dropped.
[Bug analyzer/113333] analyzer: False positives with calloc()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2024-01-11
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #1 from David Malcolm ---
Thanks for filing this bug.
Looking at trunk with:
extern void __analyzer_describe (int verbosity, ...);
extern void __analyzer_eval (int);
#include
char **f(void) {
char **vec = calloc(1, sizeof(char *));
if (vec)
{
char **p=vec;
__analyzer_describe (0, p);
__analyzer_describe (0, *p);
__analyzer_eval (*p == 0);
}
return vec;
}
https://gcc.godbolt.org/z/z3vnxbTaT
source>: In function 'f':
:10:11: warning: svalue: '_ALLOCATED_REGION(14)'
10 | __analyzer_describe (0, p);
| ^~
:11:11: warning: svalue: 'CAST(char *, REPEATED(outer_size: (long
unsigned int)8, inner_val: (char)0))'
11 | __analyzer_describe (0, *p);
| ^~~
:12:11: warning: UNKNOWN
12 | __analyzer_eval (*p == 0);
| ^
i.e. the analyzer "sees" that *p is the 0-byte repeated 8 times, cast to a char
*, but doesn't simplify that to just a NULL pointer.
I'm looking at a fix.
[Bug tree-optimization/113339] `-a/-b` is not simplified to `a/b` if done in seperate statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113339 --- Comment #2 from Andrew Pinski --- Note the fold was added here: https://gcc.gnu.org/pipermail/gcc-patches/1999-October/020476.html .
[Bug tree-optimization/113339] `-a/-b` is not simplified to `a/b` if done in seperate statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113339 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2024-01-11 --- Comment #1 from Andrew Pinski --- This is currently done only in fold: ``` /* (-A) / (-B) -> A / B */ if (TREE_CODE (arg0) == NEGATE_EXPR && negate_expr_p (arg1)) return fold_build2_loc (loc, RDIV_EXPR, type, TREE_OPERAND (arg0, 0), negate_expr (arg1)); if (TREE_CODE (arg1) == NEGATE_EXPR && negate_expr_p (arg0)) return fold_build2_loc (loc, RDIV_EXPR, type, negate_expr (arg0), TREE_OPERAND (arg1, 0)); return NULL_TREE; ``` I am going to handle the simple cases for GCC 15 here ...
[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182 --- Comment #20 from dave.anglin at bell dot net --- On 2024-01-11 2:05 p.m., jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182 > > --- Comment #19 from Jakub Jelinek --- > I think stringpool hash table is never purged (unless libgccjit and > reinitializes stuff), so once something is looked up, it will be findable > later > on as well. Okay, then maybe get_identifier is the correct function to use.
[Bug tree-optimization/113339] New: `-a/-b` is not simplified to `a/b` if done in seperate statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113339
Bug ID: 113339
Summary: `-a/-b` is not simplified to `a/b` if done in seperate
statements
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
int unopt(int a, int b) {
a = -a;
b = -b;
return a / b;
}
int opt(int a, int b) {
return -a / -b;
}
```
I would have expected these 2 would produce the same assembly but only opt is
optimized to a/b and the neg is removed.
Note LLVM does not do either: https://github.com/llvm/llvm-project/issues/77717
.
[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182 --- Comment #19 from Jakub Jelinek --- I think stringpool hash table is never purged (unless libgccjit and reinitializes stuff), so once something is looked up, it will be findable later on as well.
[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182 --- Comment #18 from dave.anglin at bell dot net --- On 2024-01-11 1:25 p.m., jakub at gcc dot gnu.org wrote: > The allocation is completely intentional, exactly to be able to track whether > it was referenced or not. Otherwise the exercise makes no sense. In assemble_external_libcall, it's intentional. But in process_pending_assemble_externals, all the allocations that are going to happen should have already happened. It is called in final. When the name encoding wasn't stripped, get_identifier just created a new identifier node that wasn't referenced. I tend to think there's a problem if the identifier node doesn't already exist in process_pending_assemble_externals.
[Bug fortran/113338] New: Valid Code Rejected, bind(C) procedure with pointer argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113338
Bug ID: 113338
Summary: Valid Code Rejected, bind(C) procedure with pointer
argument
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: everythingfunctional at protonmail dot com
Target Milestone: ---
The following example is rejected by gfortran, but should be valid.
Fortran Program:
program example
use iso_c_binding
implicit none
type :: t
integer :: i
end type
interface
subroutine c_proc(x) bind(c)
import t
implicit none
type(t), pointer, intent(in) :: x
end subroutine
end interface
type(t), target :: x
x%i = 42
call c_proc(x)
contains
subroutine f_proc(x) bind(c)
type(t), pointer, intent(in) :: x
print *, x%i
end subroutine
end program
C code:
#include
extern void f_proc(CFI_cdesc_t* x);
extern void c_proc(CFI_cdesc_t* x)
{
f_proc(x);
}
Is rejected with the following messages:
main.f90:11:27:
11 | subroutine c_proc(x) bind(c)
| 1
Error: Variable ‘x’ at (1) is a dummy argument to the BIND(C) procedure
‘c_proc’ but is not C interoperable because derived type ‘t’ is not C
interoperable
main.f90:23:23:
23 | subroutine f_proc(x) bind(c)
| 1
Error: Variable ‘x’ at (1) is a dummy argument to the BIND(C) procedure
‘f_proc’ but is not C interoperable because derived type ‘t’ is not C
interoperable
But the standard says:
> A Fortran procedure interface is interoperable with a C function prototype if
> ...
> (5) any dummy argument without the VALUE attribute corresponds to a formal
> parameter of the prototype that is of a pointer type, and either
> ...
> * the dummy argument is allocatable, assumed-shape, assumed-rank, or a
> pointer without the CONTIGUOUS attribute, and the formal parameter is a
> pointer to CFI_cdesc_t
I.e., that argument need not be interoperable, because it has the pointer
attribute.
[Bug libstdc++/112477] [13/14 Regression] Assignment of value-initialized iterators differs from value-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112477 --- Comment #10 from GCC Commits --- The master branch has been updated by Francois Dumont : https://gcc.gnu.org/g:46afbeb81414302829fbf10c107e5466a3cf44d7 commit r14-7151-g46afbeb81414302829fbf10c107e5466a3cf44d7 Author: François Dumont Date: Wed Jan 10 19:06:48 2024 +0100 libstdc++: [_GLIBCXX_DEBUG] Fix assignment of value-initialized iterator [PR112477] Now that _M_Detach do not reset iterator _M_version value we need to reset it when the iterator is attached to a new sequence, even if this sequencer is null when assigning a value-initialized iterator. In this case _M_version shall be resetted to 0. libstdc++-v3/ChangeLog: PR libstdc++/112477 * src/c++11/debug.cc (_Safe_iterator_base::_M_attach): Reset _M_version to 0 if attaching to null sequence. (_Safe_iterator_base::_M_attach_single): Likewise. (_Safe_local_iterator_base::_M_attach): Likewise. (_Safe_local_iterator_base::_M_attach_single): Likewise. * testsuite/23_containers/map/debug/112477.cc: New test case. Reviewed-by: Jonathan Wakely
[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182 --- Comment #17 from Jakub Jelinek --- The allocation is completely intentional, exactly to be able to track whether it was referenced or not. Otherwise the exercise makes no sense.
[Bug libstdc++/111550] The range adaptor closure object generated by adaptor(args...) is not a perfect forwarding call wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111550 --- Comment #4 from Patrick Palka --- The perfect forwarding issue is incidentally fixed in C++23 mode (when deducing this is available) after r14-7150-gd2cb4693a0b383.
[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182 --- Comment #16 from dave.anglin at bell dot net --- On 2024-01-11 12:37 p.m., jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182 > > --- Comment #14 from Jakub Jelinek --- > (In reply to John David Anglin from comment #13) >> Although the patch fixes the udlit-namespace.C test, I think the patch >> still isn't correct. I think the code should use maybe_get_identifier >> instead of get_identifier. See assemble_name_resolve. > Why do you think so? When assemble_external_libcall is called, it calls > get_identifier to make sure such an identifier exists. get_identifier allocates a new identifier node if one doesn't exist. While it may not matter much at this point, I don't think this code should be allocating new identifier nodes. assemble_name_resolve avoids creating new nodes. > > Though, if the targetm.strip_name_encoding call is needed, it should be done > not just in process_pending_assemble_externals, but also in > assemble_external_libcall. Will look at.
[Bug tree-optimization/113301] [12/13/14 Regression] Missed optimization: (1/(x+1))/2 => 0 since gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113301 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|12.4|14.0 --- Comment #10 from Andrew Pinski --- Fixed for GCC 14, not expecting to backport ...
[Bug middle-end/113322] [14 Regression] internal compiler error: tree check: expected none of vector_type, have vector_type in expand_single_bit_test, at expr.cc:13375
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113322 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- Fixed.
[Bug middle-end/113322] [14 Regression] internal compiler error: tree check: expected none of vector_type, have vector_type in expand_single_bit_test, at expr.cc:13375
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113322
--- Comment #3 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:a2be4e155992151b60fca6969a97d6efd91e82b5
commit r14-7149-ga2be4e155992151b60fca6969a97d6efd91e82b5
Author: Andrew Pinski
Date: Wed Jan 10 22:13:03 2024 -0800
expr: Limit the store flag optimization for single bit to non-vectors
[PR113322]
The problem here is after the recent vectorizer improvements, we end up
with a comparison against a vector bool 0 which then tries
expand_single_bit_test
which is not expecting vector comparisons at all.
The IR was:
vector(4) mask_patt_5.13;
_Bool _12;
mask_patt_5.13_44 = vect_perm_even_41 != { 0.0, 1.0e+0, 2.0e+0, 3.0e+0 };
_12 = mask_patt_5.13_44 == { 0, 0, 0, 0 };
and we tried to call expand_single_bit_test for the last comparison.
Rejecting the vector comparison is needed.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR middle-end/113322
gcc/ChangeLog:
* expr.cc (do_store_flag): Don't try single bit tests with
comparison on vector types.
gcc/testsuite/ChangeLog:
* gcc.c-torture/compile/pr113322-1.c: New test.
Signed-off-by: Andrew Pinski
[Bug tree-optimization/113301] [12/13/14 Regression] Missed optimization: (1/(x+1))/2 => 0 since gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113301 --- Comment #9 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:7f56a90269b393fcc55ef08e0990fafb7b1c24b4 commit r14-7148-g7f56a90269b393fcc55ef08e0990fafb7b1c24b4 Author: Andrew Pinski Date: Wed Jan 10 14:25:37 2024 -0800 match: Delay folding of 1/x into `(x+1u)<2u?x:0` until late [PR113301] Since currently ranger does not work with the complexity of COND_EXPR in some cases so delaying the simplification of `1/x` for signed types help code generation. tree-ssa/divide-8.c is a new testcase where this can help. Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR tree-optimization/113301 gcc/ChangeLog: * match.pd (`1/x`): Delay signed case until late. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/divide-8.c: New test. Signed-off-by: Andrew Pinski
[Bug libstdc++/113258] Pre-C++17 code that replaces malloc/free crashes when mixed with post-C++17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 --- Comment #24 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f50f2efae9fb0965d8ccdb62cfdb698336d5a933 commit r14-7146-gf50f2efae9fb0965d8ccdb62cfdb698336d5a933 Author: Jonathan Wakely Date: Tue Jan 9 15:22:46 2024 + libstdc++: Prefer posix_memalign for aligned-new [PR113258] As described in PR libstdc++/113258 there are old versions of tcmalloc which replace malloc and related APIs, but do not repalce aligned_alloc because it didn't exist at the time they were released. This means that when operator new(size_t, align_val_t) uses aligned_alloc to obtain memory, it comes from libc's aligned_alloc not from tcmalloc. But when operator delete(void*, size_t, align_val_t) uses free to deallocate the memory, that goes to tcmalloc's replacement version of free, which doesn't know how to free it. If we give preference to the older posix_memalign instead of aligned_alloc then we're more likely to use a function that will be compatible with the replacement version of free. Because posix_memalign has been around for longer, it's more likely that old third-party malloc replacements will also replace posix_memalign alongside malloc and free. libstdc++-v3/ChangeLog: PR libstdc++/113258 * libsupc++/new_opa.cc: Prefer to use posix_memalign if available.
[Bug libstdc++/112477] [13/14 Regression] Assignment of value-initialized iterators differs from value-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112477 --- Comment #9 from Jonathan Wakely --- I see that this is actually causing lots of failures for PSTL tests when run with -D_GLIBCXX_DEBUG
[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
--- Comment #15 from Jakub Jelinek ---
So, I'm going to bootstrap/regtest:
2024-01-11 John David Anglin
Jakub Jelinek
PR middle-end/113182
* varasm.cc (process_pending_assemble_externals,
assemble_external_libcall): Use targetm.strip_name_encoding
before calling get_identifier.
--- gcc/varasm.cc.jj2024-01-08 21:56:04.968516120 +0100
+++ gcc/varasm.cc 2024-01-11 18:44:19.171399167 +0100
@@ -2543,7 +2543,8 @@ process_pending_assemble_externals (void
for (rtx list = pending_libcall_symbols; list; list = XEXP (list, 1))
{
rtx symbol = XEXP (list, 0);
- tree id = get_identifier (XSTR (symbol, 0));
+ const char *name = targetm.strip_name_encoding (XSTR (symbol, 0));
+ tree id = get_identifier (name);
if (TREE_SYMBOL_REFERENCED (id))
targetm.asm_out.external_libcall (symbol);
}
@@ -2631,7 +2632,8 @@ assemble_external_libcall (rtx fun)
reference to it will mark its tree node as referenced, via
assemble_name_resolve. These are eventually emitted, if
used, in process_pending_assemble_externals. */
- get_identifier (XSTR (fun, 0));
+ const char *name = targetm.strip_name_encoding (XSTR (fun, 0));
+ get_identifier (name);
pending_libcall_symbols = gen_rtx_EXPR_LIST (VOIDmode, fun,
pending_libcall_symbols);
}
[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182 --- Comment #14 from Jakub Jelinek --- (In reply to John David Anglin from comment #13) > Although the patch fixes the udlit-namespace.C test, I think the patch > still isn't correct. I think the code should use maybe_get_identifier > instead of get_identifier. See assemble_name_resolve. Why do you think so? When assemble_external_libcall is called, it calls get_identifier to make sure such an identifier exists. Though, if the targetm.strip_name_encoding call is needed, it should be done not just in process_pending_assemble_externals, but also in assemble_external_libcall.
[Bug tree-optimization/113012] [13 regression] ICE when building xorg-server with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113012 Siddhesh Poyarekar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Siddhesh Poyarekar --- ... and now fixed on the 13 branch too.
[Bug tree-optimization/113012] [13 regression] ICE when building xorg-server with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113012 --- Comment #12 from GCC Commits --- The releases/gcc-13 branch has been updated by Siddhesh Poyarekar : https://gcc.gnu.org/g:db86a6009fc83e8cb21cae49c7c55fc2b1186008 commit r13-8210-gdb86a6009fc83e8cb21cae49c7c55fc2b1186008 Author: Siddhesh Poyarekar Date: Mon Dec 18 09:44:00 2023 -0500 tree-object-size: Always set computed bit for bdos [PR113012] It is always safe to set the computed bit for dynamic object sizes at the end of collect_object_sizes_for because even in case of a dependency loop encountered in nested calls, we have an SSA temporary to actually finish the object size expression. The reexamine pass for dynamic object sizes is only for propagation of unknowns and gimplification of the size expressions, not for loop resolution as in the case of static object sizes. gcc/ChangeLog: PR tree-optimization/113012 * tree-object-size.cc (compute_builtin_object_size): Expand comment for dynamic object sizes. (collect_object_sizes_for): Always set COMPUTED bitmap for dynamic object sizes. gcc/testsuite/ChangeLog: PR tree-optimization/113012 * gcc.dg/ubsan/pr113012.c: New test case. Signed-off-by: Siddhesh Poyarekar (cherry picked from commit 576c1fc4401a9dae9757ac2e4fa37d05e130fa3d)
[Bug libgcc/113337] New: Rethrown uncaught exceptions don't invoke std::terminate if SEH-based unwinding is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113337
Bug ID: 113337
Summary: Rethrown uncaught exceptions don't invoke
std::terminate if SEH-based unwinding is used
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: matteo at mitalia dot net
Target Milestone: ---
Created attachment 57046
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57046=edit
Test program to reproduce the bug
Sample code:
```
#include
#include
#include
#include
static void custom_terminate_handler() {
fprintf(stderr, "custom_terminate_handler invoked\n");
std::exit(1);
}
int main(int argc, char *argv[]) {
std::set_terminate(_terminate_handler);
if (argc < 2) return 1;
const char *mode = argv[1];
fprintf(stderr, "%s\n", mode);
if (strcmp(mode, "throw") == 0) {
throw std::exception();
} else if (strcmp(mode, "rethrow") == 0) {
try {
throw std::exception();
} catch (...) {
throw;
}
} else {
return 1;
}
return 0;
}
```
Compiling and running this on e.g. Linux, it prints "custom_terminate_handler
invoked" both when invoked as `./a.out throw` and `./a.out rethrow`. If instead
this is compiled with a 64 bit gcc+mingw64 build that uses SEH exceptions, it
behaves correctly in the "throw" case, but in the rethrow case it crashes in
std::abort (so, you get an "abnormal program termination"/the JIT debugger is
invoked).
Diving in the problem, I think I found the culprit: on rethrow,
`__cxxabiv1::__cxa_rethrow` (libstdc++-v3/libsupc++/eh_throw.cc) invokes
`_Unwind_Resume_or_Rethrow` (libgcc/unwind-seh.c), which goes like this:
```
_Unwind_Reason_Code
_Unwind_Resume_or_Rethrow (struct _Unwind_Exception *exc)
{
if (exc->private_[0] == 0)
_Unwind_RaiseException (exc);
else
_Unwind_ForcedUnwind_Phase2 (exc);
abort ();
}
```
The problem here is that unconditional abort(); I don't know exactly about the
else branch, but I think that the "regular", first branch case should read
`return _Unwind_RaiseException (exc);` as, if no handler is found,
`_Unwind_RaiseException` does return to allow the runtime to call
`std::terminate`, as per the relevant comment
```
/* The exception handler installed in crt0 will continue any GCC
exception that reaches there (and isn't marked non-continuable).
Returning allows the C++ runtime to call std::terminate. */
return _URC_END_OF_STACK;
```
Indeed, patching the binary on the fly to change the `std::abort` call to a
return fixes the problem, as `__cxa_rethrow` does call `std::terminate` if
`_Unwind_Resume_or_Rethrow` returns.
Comparing with the code from libgcc/unwind.inc (used in the SjLj and Dwarf2
case, from what I gather)
```
/* Resume propagation of an FORCE_UNWIND exception, or to rethrow
a normal exception that was handled. */
_Unwind_Reason_Code LIBGCC2_UNWIND_ATTRIBUTE
_Unwind_Resume_or_Rethrow (struct _Unwind_Exception *exc)
{
struct _Unwind_Context this_context, cur_context;
_Unwind_Reason_Code code;
unsigned long frames;
/* Choose between continuing to process _Unwind_RaiseException
or _Unwind_ForcedUnwind. */
if (exc->private_1 == 0)
return _Unwind_RaiseException (exc);
uw_init_context (_context);
cur_context = this_context;
code = _Unwind_ForcedUnwind_Phase2 (exc, _context, );
gcc_assert (code == _URC_INSTALL_CONTEXT);
uw_install_context (_context, _context, frames);
}
```
I see that the `_Unwind_RaiseException` case is indeed implemented forwarding
the error code back to the caller, while the `_Unwind_ForcedUnwind_Phase2` case
terminates either in a failed `gcc_assert`, or in a `uw_install_context` (which
is noreturn and boils down to a longjmp, at least in the sjlj case).
So again, I'm not entirely sure about the `_UA_FORCE_UNWIND` case, but the
"regular rethrown exception" branch should surely forward back the error code
instead of crashing on `abort`.
[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182 --- Comment #13 from John David Anglin --- Although the patch fixes the udlit-namespace.C test, I think the patch still isn't correct. I think the code should use maybe_get_identifier instead of get_identifier. See assemble_name_resolve.
[Bug tree-optimization/113334] wrong code with _BitInt() shift at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113334 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-01-11 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 57045 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57045=edit gcc14-pr113334.patch Untested fix.
[Bug target/112817] RISC-V: RVV: provide attribute riscv_rvv_vector_bits for VLS codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817 --- Comment #13 from Vineet Gupta --- Yeah Greg from Rivos started working on it. He'll update here as he makes progress.
[Bug target/113312] Update __attribute__((interrupt)) for Intel FRED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312 --- Comment #13 from H. Peter Anvin --- No, it will not. Most OSes flows will want to merge the kernel and user flows at some point for some handlers, so it isn't clear that that makes sense.
[Bug target/113312] Update __attribute__((interrupt)) for Intel FRED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #12 from Florian Weimer --- Can you make fred_handler noreturn and use inline assembler to do the exit? Will FRED restore the processor state in this case?
[Bug other/113336] New: libatomic (testsuite) regressions on armv6-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113336 Bug ID: 113336 Summary: libatomic (testsuite) regressions on armv6-linux-gnueabihf Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: roger at nextmovesoftware dot com Target Milestone: --- As suggested by Richard Earnshaw, this opens a bugzilla PR for tracking this issue. All the tests in libatomic currently fail on a raspberry pi running raspbian, but passed back in December 2020. https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642168.html The regression (which isn't really a regression) was caused by: 2023-09-26 Hans-Peter Nilsson PR target/107567 PR target/109166 * builtins.cc (expand_builtin) : Handle failure from expand_builtin_atomic_test_and_set. * optabs.cc (expand_atomic_test_and_set): When all attempts fail to generate atomic code through target support, return NULL instead of emitting non-atomic code. Also, for code handling targetm.atomic_test_and_set_trueval != 1, gcc_assert result from calling emit_store_flag_force instead of returning NULL. Prior to this, when -fno-sync-libcalls was specified on the command line, the __atomic_test_and_set built-in simply expanded to a non-atomic code sequence, which then passed libatomic's configure tests for HAVE_ATOMIC_TAS. Now that this hole/bug/correctness issue has been fixed, and HAVE_ATOMIC_TAS is now detected as false, the libatomics's tas_n.c can no longer implement tas_8_2_.o without (a missing helper function) tas_1_2_.o. Hence libatomic has (always?) been broken on armv6, but synchronization primitives can now be supported with the above change. We've just not noticed that necessary pieces of the runtime were missing, until the above correctness fix resulted in a link error.
[Bug libstdc++/113335] New: [C++23] Implement LWG3617 function/packaged_task deduction guides and deducing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113335 Bug ID: 113335 Summary: [C++23] Implement LWG3617 function/packaged_task deduction guides and deducing this Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Depends on: 102609 Blocks: 106749 Target Milestone: --- Now that 'deducing this' is supported, we need these changes: https://cplusplus.github.io/LWG/issue3617 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609 [Bug 102609] [C++23] P0847R7 - Deducing this https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749 [Bug 106749] Implement C++23 library features
[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
