[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753 --- Comment #13 from Richard Biener --- I think the issue might be that whoever is creating __static_initialization_and_destruction_0 fails to honor the active target pragma. Which means back to my suggestion to have multiple ones when different target options are on the individual CTORs and any of them have always-inline (with always-inline we can't rely on an out-of-line copy to exist). Yes, for libstdc++ purposes which seems to get more and more "always-inline" it would be good to have a different attribute that would only cause to disregard inline limits and not have "always-inline" semantics. [[inline_without_limits]] or [[inline_no_limits]]
[Bug target/113326] Optimize vector shift with constant delta on shifting-count operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113326
--- Comment #5 from Andrew Pinski ---
One more thing:
```
vect_shift_0 = vect_value >> { 0, 1, 2, 3 };
vect_shift_1 = vect_value >> { 4, 5, 6, 7 };
vect_shift_2 = vect_value >> { 8, 9, 10, 11 };
vect_shift_3 = vect_value >> { 12, 13, 14, 15 };
```
vs
```
vect_shift_0 = vect_value >> { 0, 1, 2, 3 };
vect_shift_1 = vect_shift_0 >> { 4, 4, 4, 4 };
vect_shift_2 = vect_shift_0 >> { 8, 8, 8, 8 };
vect_shift_3 = vect_shift_0 >> { 12, 12, 12, 12 };
```
the first has fully independent operations while in the second case, there is
one dependent and the are independent operations.
On cores which has many vector units the first one might be faster than the
second one. So this needs a cost model too.
[Bug ipa/113197] [12/13/14 Regression] ICE in in handle_call_arg, at tree-ssa-structalias.cc:4119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113197 Richard Biener changed: What|Removed |Added Priority|P1 |P2
[Bug middle-end/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112740 --- Comment #14 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:e1f2d58a1e2536f13d3f2ea2d7373ae62cec9125 commit r14-7129-ge1f2d58a1e2536f13d3f2ea2d7373ae62cec9125 Author: Richard Biener Date: Wed Jan 10 14:54:10 2024 +0100 middle-end/112740 - vector boolean CTOR expansion issue The optimization to expand uniform boolean vectors by sign-extension works only for dense masks but it failed to check that. PR middle-end/112740 * expr.cc (store_constructor): Check the integer vector mask has a single bit per element before using sign-extension to expand an uniform vector. * gcc.dg/pr112740.c: New testcase.
[Bug tree-optimization/111003] [14 Regression] Dead Code Elimination Regression at -O3 since r14-2161-g237e83e2158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111003 --- Comment #6 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:96fb3908d9b8e30f8d8355fbb133d25625a0fee9 commit r14-7130-g96fb3908d9b8e30f8d8355fbb133d25625a0fee9 Author: Richard Biener Date: Thu Jan 11 08:52:48 2024 +0100 tree-optimization/111003 - new testcase Testcase for fixed PR. PR tree-optimization/111003 gcc/testsuite/ * gcc.dg/tree-ssa/pr111003.c: New testcase.
[Bug middle-end/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112740 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Richard Biener --- Should be fixed now.
[Bug middle-end/88670] [meta-bug] generic vector extension issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88670 Bug 88670 depends on bug 112740, which changed state. Bug 112740 Summary: [14 Regression] wrong code with vector compare on riscv64 at -O0 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112740 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug analyzer/109839] -Wanalyzer-fd-leak false positive with routine dup2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109839
Donald Buczek changed:
What|Removed |Added
CC||buczek at molgen dot mpg.de
--- Comment #1 from Donald Buczek ---
Correct, dup2() does not allocate a new file descriptor, so the returned file
descriptor can't be leaked.
Reduced test case:
#include
void f(int old, int new) {
int r = dup2(old, new);
}
https://gcc.godbolt.org/z/6sP9v1r5a
[Bug analyzer/113329] New: analyzer: False positive analyzer-fd-use-without-check with dup2()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113329
Bug ID: 113329
Summary: analyzer: False positive analyzer-fd-use-without-check
with dup2()
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: buczek at molgen dot mpg.de
Target Milestone: ---
Using a closed file descriptor as the second argument of dup2() is a valid
usage. It makes sense, because the implicit close of dup2() doesn't return
close errors to the caller, so an explicit close might be preferred.
** Code:
#include
void f(int oldfd, int newfd) {
close(newfd);
dup2(oldfd, newfd);
}
** Result:
: In function 'f':
:4:5: warning: 'dup2' on possibly invalid file descriptor 'newfd'
[-Wanalyzer-fd-use-without-check]
4 | dup2(oldfd, newfd);
| ^~
'f': events 1-2
|
|3 | close(newfd);
| | ^~~~
| | |
| | (1) closed here
|4 | dup2(oldfd, newfd);
| | ~~
| | |
| | (2) 'newfd' could be invalid
|
Compiler returned: 0
https://gcc.godbolt.org/z/8zac19e15
[Bug testsuite/113319] Random LTO test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113319 Richard Biener changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #3 from Richard Biener --- I'm also doing this and remember running into this once. This is because of the -save-temps use (I asked for them to be removed ...), without -save-temps temporary filenames are used. -save-temps should never be used (IIRC assembler scanning triggers it though)
[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 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Priority|P3 |P1
[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 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Keywords||ice-on-valid-code Ever confirmed|0 |1 Last reconfirmed||2024-01-11 --- Comment #1 from Richard Biener --- I wonder if you can try newer GCC since 10.5 is no longer maintained?
[Bug libstdc++/106308] Consider using statx(2) for std::filesystem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106308 Ken Matsui changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug target/113326] Optimize vector shift with constant delta on shifting-count operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113326
--- Comment #6 from Richard Biener ---
(In reply to Andrew Pinski from comment #5)
> One more thing:
> ```
> vect_shift_0 = vect_value >> { 0, 1, 2, 3 };
> vect_shift_1 = vect_value >> { 4, 5, 6, 7 };
> vect_shift_2 = vect_value >> { 8, 9, 10, 11 };
> vect_shift_3 = vect_value >> { 12, 13, 14, 15 };
> ```
> vs
> ```
> vect_shift_0 = vect_value >> { 0, 1, 2, 3 };
> vect_shift_1 = vect_shift_0 >> { 4, 4, 4, 4 };
> vect_shift_2 = vect_shift_0 >> { 8, 8, 8, 8 };
> vect_shift_3 = vect_shift_0 >> { 12, 12, 12, 12 };
> ```
>
> the first has fully independent operations while in the second case, there
> is one dependent and the are independent operations.
>
> On cores which has many vector units the first one might be faster than the
> second one. So this needs a cost model too.
Note the vectorizer has the shift values dependent as well (across iterations),
we just constant propagate after unrolling here.
Note this is basically asking for "strength-reduction" of expensive
constants which could be more generally useful and not only for this
specific shift case. Consider the same example but with an add instead
of a shift for example, the same exact set of constants will appear.
[Bug tree-optimization/113330] New: ICE: verify_gimple failed: conversion of register to a different size in 'view_convert_expr' with -O -fstack-check=generic and _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113330 Bug ID: 113330 Summary: ICE: verify_gimple failed: conversion of register to a different size in 'view_convert_expr' with -O -fstack-check=generic and _BitInt() Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57036 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57036&action=edit reduced testcase Maybe related to PR113297 Compiler output: $ x86_64-pc-linux-gnu-gcc -O --param=large-stack-frame=131072 -fstack-check=generic --param=sccvn-max-alias-queries-per-access=0 testcase.c testcase.c: In function 'foo': testcase.c:15:1: error: conversion of register to a different size in 'view_convert_expr' 15 | } | ^ VIEW_CONVERT_EXPR<_BitInt(65535)>(SR.6_11); _4 = VIEW_CONVERT_EXPR<_BitInt(65535)>(SR.6_11); during GIMPLE pass: esra testcase.c:15:1: internal compiler error: verify_gimple failed 0x1557dbd verify_gimple_in_cfg(function*, bool, bool) /repo/gcc-trunk/gcc/tree-cfg.cc:5666 0x13c7774 execute_function_todo /repo/gcc-trunk/gcc/passes.cc:2088 0x13c7cce execute_todo /repo/gcc-trunk/gcc/passes.cc:2142 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <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-r14-7127-20240110200826-g2105c49bbe8-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.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-r14-7127-20240110200826-g2105c49bbe8-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20240111 (experimental) (GCC)
[Bug target/113077] [14 Regression] ICE in dwarf2out_frame_debug_cfa_offset with `-O2 -fstack-protector-strong -fstack-clash-protection`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113077 Alex Coplan changed: What|Removed |Added URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma |il/gcc-patches/2024-January |il/gcc-patches/2024-January |/642313.html|/642530.html --- Comment #12 from Alex Coplan --- v3 patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642530.html
[Bug target/113331] New: AMDGCN: Compilation failure due to duplicate .LEHB/.LEHE symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113331 Bug ID: 113331 Summary: AMDGCN: Compilation failure due to duplicate .LEHB/.LEHE symbols Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jules at gcc dot gnu.org Target Milestone: --- Created attachment 57037 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57037&action=edit Test case The attached file fails to compile with AMD GCN offloading on current mainline. It also fails on GCC 13.2.0 as packaged in Debian, so this doesn't appear to be a regression. $ g++ -fopenmp -foffload=amdgcn-amdhsa -save-temps dup-syms.cc -o dup-syms ./dup-syms.xamdgcn-amdhsa.mkoffload.2.s:256:1: error: symbol '.LEHB0' is already defined .LEHB0: ^ ./dup-syms.xamdgcn-amdhsa.mkoffload.2.s:258:1: error: symbol '.LEHE0' is already defined .LEHE0: ^ ./dup-syms.xamdgcn-amdhsa.mkoffload.2.s:288:1: error: symbol '.LEHB1' is already defined .LEHB1: ^ ./dup-syms.xamdgcn-amdhsa.mkoffload.2.s:290:1: error: symbol '.LEHE1' is already defined .LEHE1: ^ The test case doesn't trigger with NVPTX offloading, but I don't think that definitely implies that this is something GCN-specific (vs. generically offload-related).
[Bug target/113326] Optimize vector shift with constant delta on shifting-count operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113326
--- Comment #7 from Feng Xue ---
(In reply to Richard Biener from comment #6)
> (In reply to Andrew Pinski from comment #5)
> > One more thing:
> > ```
> > vect_shift_0 = vect_value >> { 0, 1, 2, 3 };
> > vect_shift_1 = vect_value >> { 4, 5, 6, 7 };
> > vect_shift_2 = vect_value >> { 8, 9, 10, 11 };
> > vect_shift_3 = vect_value >> { 12, 13, 14, 15 };
> > ```
> > vs
> > ```
> > vect_shift_0 = vect_value >> { 0, 1, 2, 3 };
> > vect_shift_1 = vect_shift_0 >> { 4, 4, 4, 4 };
> > vect_shift_2 = vect_shift_0 >> { 8, 8, 8, 8 };
> > vect_shift_3 = vect_shift_0 >> { 12, 12, 12, 12 };
> > ```
> >
> > the first has fully independent operations while in the second case, there
> > is one dependent and the are independent operations.
> >
> > On cores which has many vector units the first one might be faster than the
> > second one. So this needs a cost model too.
>
> Note the vectorizer has the shift values dependent as well (across
> iterations),
> we just constant propagate after unrolling here.
>
> Note this is basically asking for "strength-reduction" of expensive
> constants which could be more generally useful and not only for this
> specific shift case. Consider the same example but with an add instead
> of a shift for example, the same exact set of constants will appear.
It is. But only find that vector shift has special treatment to constant
operands based on its numerical pattern. No sure any other operator would be.
BTW, here is a scalar-version strength-reduction for shift, like:
int a = value >> n;
int b = value >> (n + 6);
==>
int a = value >> n;
int b = a >> 6; // (n + 6) is not needed
But this is not covered by current scalar strength-reduction pass.
[Bug c++/113332] New: [12/13/14 regression] ICE when building fcitx-5.1.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113332
Bug ID: 113332
Summary: [12/13/14 regression] ICE when building fcitx-5.1.6
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
Created attachment 57038
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57038&action=edit
ibusfrontend.cpp.ii.xz
Originally reported downstream by Toralf Förster at
https://bugs.gentoo.org/921765 with GCC 13 (13.2.1 20231216) but I can
reproduce it with 14 (14.0.0 20240107) too.
```
$ g++ -c ibusfrontend.cpp.ii
In file included from
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/unique_ptr.h:37,
from
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/memory:78,
from
/var/tmp/portage/app-i18n/fcitx-5.1.6/work/fcitx5-5.1.6/src/lib/fcitx/../fcitx-utils/dbus/servicewatcher.h:10,
from
/var/tmp/portage/app-i18n/fcitx-5.1.6/work/fcitx5-5.1.6/src/frontend/ibusfrontend/ibusfrontend.h:11,
from
/var/tmp/portage/app-i18n/fcitx-5.1.6/work/fcitx5-5.1.6/src/frontend/ibusfrontend/ibusfrontend.cpp:8:
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/tuple: In substitution of
‘template, std::allocator > >
>::_TCC::value>::__is_implicitly_default_constructible(),
bool>::type > constexpr
std::tuple, std::allocator > > >::tuple() [with _Dummy = void; typename
std::enable_if, std::allocator > >
>::_TCC::value>::__is_implicitly_default_constructible(),
bool>::type = ]’:
/var/tmp/portage/app-i18n/fcitx-5.1.6/work/fcitx5-5.1.6/src/frontend/ibusfrontend/ibusfrontend.cpp:594:0:
recursively required from ‘constexpr
fcitx::dbus::DBusStruct::DBusStruct() [with Args =
{std::vector,
std::allocator >
>}]’
594 | FCITX_OBJECT_VTABLE_PROPERTY(
/var/tmp/portage/app-i18n/fcitx-5.1.6/work/fcitx5-5.1.6/src/frontend/ibusfrontend/ibusfrontend.cpp:594:0:
required from here
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/tuple:763:62: internal
compiler error: in lambda_expr_this_capture, at cp/lambda.cc:825
763 | _TCC<_Dummy>::__is_implicitly_default_constructible(),
| ~~~^~
0x55781543e3c2 lambda_expr_this_capture(tree_node*, int)
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/lambda.cc:825
0x5578166f2080 maybe_dummy_object(tree_node*, tree_node**)
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/tree.cc:4408
0x5578165d0e8e finish_call_expr(tree_node*, vec**,
bool, bool, int)
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/semantics.cc:2968
0x55781678c531 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/pt.cc:20845
0x5578167bc701 tsubst_template_arg(tree_node*, tree_node*, int, tree_node*)
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/pt.cc:12693
0x5578167bc701 tsubst_template_arg(tree_node*, tree_node*, int, tree_node*)
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/pt.cc:12681
0x5578167bc701 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/pt.cc:13845
0x557816831076 tsubst_aggr_type_1
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/pt.cc:14120
0x557816831076 tsubst_aggr_type
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/pt.cc:14090
0x5578167093ed tsubst(tree_node*, tree_node*, int, tree_node*)
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/pt.cc:1
0x557816a1a5e2 type_unification_real
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/pt.cc:23316
0x557816a18cb7 fn_type_unification(tree_node*, tree_node*, tree_node*,
tree_node* const*, unsigned int, tree_node*, unification_kind_t, int,
conversion**, bool, bool)
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/pt.cc:22390
0x557816a17a82 add_template_candidate_real(z_candidate**, tree_node*,
tree_node*, tree_node*, tree_node*, vec const*,
tree_node*, tree_node*, tree_node*, int, tree_node*, unification_kind_t, bool,
int) [clone .isra.0]
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/call.cc:3631
0x5578165de1b0 add_template_candidate
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/call.cc:3721
0x5578165de1b0 add_candidates
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/call.cc:6686
0x5578168bf6e1 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/usr/src/debug/sys-devel/gcc-14.0.0_pre2
[Bug analyzer/113333] New: analyzer: False positives with calloc()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
Bug ID: 11
Summary: analyzer: False positives with calloc()
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: buczek at molgen dot mpg.de
Target Milestone: ---
Analyzer assumen that a pointer allocated by calloc() can be != NULL.
** Code:
#include
char **f(void) {
char **vec = calloc(1, sizeof(char *));
if (vec)
for (char **p=vec ; *p ; p++);
return vec;
}
** Result:
: In function 'f':
:5:29: warning: heap-based buffer over-read [CWE-126]
[-Wanalyzer-out-of-bounds]
5 | for (char **p=vec ; *p ; p++);
| ^~
'f': events 1-6
|
|3 | char **vec = calloc(1, sizeof(char *));
| | ^
| | |
| | (1) capacity: 8 bytes
|4 | if (vec)
| |~
| ||
| |(2) following 'true' branch (when 'vec' is non-NULL)...
|5 | for (char **p=vec ; *p ; p++);
| | ~ ~~ ~~~
| | | | |
| | | | (5) ...to here
| | | (4) following 'true' branch...
| | | (6) out-of-bounds read from byte 8
till byte 15 but region ends at byte 8
| | (3) ...to here
|
:5:29: note: read of 8 bytes from after the end of the region
5 | for (char **p=vec ; *p ; p++);
| ^~
:5:29: warning: use of uninitialized value '*p' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
'f': events 1-6
|
|3 | char **vec = calloc(1, sizeof(char *));
| | ^
| | |
| | (1) region created on heap here
|4 | if (vec)
| |~
| ||
| |(2) following 'true' branch (when 'vec' is non-NULL)...
|5 | for (char **p=vec ; *p ; p++);
| | ~ ~~ ~~~
| | | | |
| | | | (5) ...to here
| | | (4) following 'true' branch...
| | | (6) use of uninitialized value '*p'
here
| | (3) ...to here
|
Compiler returned: 0
https://gcc.godbolt.org/z/h6bPeYc3T
[Bug target/113077] [14 Regression] ICE in dwarf2out_frame_debug_cfa_offset with `-O2 -fstack-protector-strong -fstack-clash-protection`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113077 --- Comment #13 from GCC Commits --- The master branch has been updated by Alex Coplan : https://gcc.gnu.org/g:5400778f69d19a94017561c7de02510d9c0899e6 commit r14-7132-g5400778f69d19a94017561c7de02510d9c0899e6 Author: Alex Coplan Date: Thu Jan 11 10:16:24 2024 + aarch64: Fix dwarf2cfi ICEs due to recent CFI note changes [PR113077] In r14-6604-gd7ee988c491cde43d04fe25f2b3dbad9d85ded45 we changed the CFI notes attached to callee saves (in aarch64_save_callee_saves). That patch changed the ldp/stp representation to use unspecs instead of PARALLEL moves. This meant that we needed to attach CFI notes to all frame-related pair saves such that dwarf2cfi could still emit the appropriate CFI (it cannot interpret the unspecs directly). The patch also attached REG_CFA_OFFSET notes to individual saves so that the ldp/stp pass could easily preserve them when forming stps. In that change I chose to use REG_CFA_OFFSET, but as the PR shows, that choice was problematic in that REG_CFA_OFFSET requires the attached store to be expressed in terms of the current CFA register at all times. This means that even scheduling of frame-related insns can break this invariant, leading to ICEs in dwarf2cfi. The old behaviour (before that change) allowed dwarf2cfi to interpret the RTL directly for sp-relative saves. This change restores that behaviour by using REG_FRAME_RELATED_EXPR instead of REG_CFA_OFFSET. REG_FRAME_RELATED_EXPR effectively just gives a different pattern for dwarf2cfi to look at instead of the main insn pattern. That allows us to attach the old-style PARALLEL move representation in a REG_FRAME_RELATED_EXPR note and means we are free to always express the save addresses in terms of the stack pointer. Since the ldp/stp fusion pass can combine frame-related stores, this patch also updates it to preserve REG_FRAME_RELATED_EXPR notes, and additionally gives it the ability to synthesize those notes when combining sp-relative saves into an stp (the latter always needs a note due to the unspec representation, the former does not). gcc/ChangeLog: PR target/113077 * config/aarch64/aarch64-ldp-fusion.cc (filter_notes): Add fr_expr param to extract REG_FRAME_RELATED_EXPR notes. (combine_reg_notes): Handle REG_FRAME_RELATED_EXPR notes, and synthesize these if needed. Update caller ... (ldp_bb_info::fuse_pair): ... here. (ldp_bb_info::try_fuse_pair): Punt if either insn has writeback and either insn is frame-related. (find_trailing_add): Punt on frame-related insns. * config/aarch64/aarch64.cc (aarch64_save_callee_saves): Use REG_FRAME_RELATED_EXPR instead of REG_CFA_OFFSET. gcc/testsuite/ChangeLog: PR target/113077 * gcc.target/aarch64/pr113077.c: New test.
[Bug target/113077] [14 Regression] ICE in dwarf2out_frame_debug_cfa_offset with `-O2 -fstack-protector-strong -fstack-clash-protection`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113077 Alex Coplan changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Alex Coplan --- Should be fixed, thanks for the report, and sorry for the breakage.
[Bug libstdc++/113320] libstdc++ accepts std::format(std::move(runtime_fmt), 42);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113320 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-01-11 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- I implemented the R0 paper, not the final spec. I already have a patch to fix this.
[Bug c++/113332] [12/13/14 regression] ICE when building fcitx-5.1.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113332 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.4
[Bug target/113331] AMDGCN: Compilation failure due to duplicate .LEHB/.LEHE symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113331 --- Comment #1 from Richard Biener --- These are exception handling region labels, possibly nvptx has no way to do EH.
[Bug target/113233] LoongArch: target options from LTO objects not respected during linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233
--- Comment #7 from GCC Commits ---
The master branch has been updated by LuluCheng :
https://gcc.gnu.org/g:ea2a9c76a1dcffbbec6e53655bef9236d3a8e691
commit r14-7134-gea2a9c76a1dcffbbec6e53655bef9236d3a8e691
Author: Yang Yujie
Date: Thu Jan 11 09:07:10 2024 +0800
LoongArch: Implement option save/restore
LTO option streaming and target attributes both require per-function
target configuration, which is achieved via option save/restore.
We implement TARGET_OPTION_{SAVE,RESTORE} to switch the la_target
context in addition to other automatically maintained option states
(via the "Save" option property in the .opt files).
Tested on loongarch64-linux-gnu without regression.
PR target/113233
gcc/ChangeLog:
* config/loongarch/genopts/loongarch.opt.in: Mark options with
the "Save" property.
* config/loongarch/loongarch.opt: Same.
* config/loongarch/loongarch-opts.cc: Refresh -mcmodel= state
according to la_target.
* config/loongarch/loongarch.cc: Implement TARGET_OPTION_{SAVE,
RESTORE} for the la_target structure; Rename option conditions
to have the same "la_" prefix.
* config/loongarch/loongarch.h: Same.
[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 Richard Biener changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #3 from Richard Biener --- diff --git a/gcc/match.pd b/gcc/match.pd index 876a9d1c06e..abbd03742f9 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -6792,11 +6792,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) && exact_real_truncate (TYPE_MODE (double_type_node), &orig)) type1 = double_type_node; } - tree newtype -= (element_precision (TREE_TYPE (@00)) > element_precision (type1) - ? TREE_TYPE (@00) : type1); + tree newtype += (element_precision (TREE_TYPE (@00)) > element_precision (type1) + ? TREE_TYPE (@00) : type1); } - (if (element_precision (TREE_TYPE (@0)) > element_precision (newtype)) + (if (element_precision (TREE_TYPE (@0)) > element_precision (newtype) + && is_truth_type_for (newtype, type)) (cmp (convert:newtype @00) (convert:newtype @10 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. But it fixes the testcase.
[Bug testsuite/113319] Random LTO test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113319 Tamar Christina changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org Target Milestone|--- |14.0
[Bug libstdc++/113250] std::filesystem::equivalent("", "/") should throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113250 --- Comment #3 from GCC Commits --- The master branch has been updated by Ken Matsui : https://gcc.gnu.org/g:df147e2ee7199d33d66959c6509ce9c21072077f commit r14-7135-gdf147e2ee7199d33d66959c6509ce9c21072077f Author: Ken Matsui Date: Wed Jan 10 22:08:07 2024 -0800 libstdc++: Fix error handling in filesystem::equivalent [PR113250] This patch made std::filesystem::equivalent correctly throw an exception when either path does not exist as per [fs.op.equivalent]/4. PR libstdc++/113250 libstdc++-v3/ChangeLog: * src/c++17/fs_ops.cc (fs::equivalent): Use || instead of &&. * src/filesystem/ops.cc (fs::equivalent): Likewise. * testsuite/27_io/filesystem/operations/equivalent.cc: Handle error codes. * testsuite/experimental/filesystem/operations/equivalent.cc: Likewise. Signed-off-by: Ken Matsui Reviewed-by: Jonathan Wakely
[Bug libstdc++/113250] std::filesystem::equivalent("", "/") should throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113250 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Ken Matsui : https://gcc.gnu.org/g:3e51890ef351e7fb9e836c6a48f20ca97294dc16 commit r13-8209-g3e51890ef351e7fb9e836c6a48f20ca97294dc16 Author: Ken Matsui Date: Wed Jan 10 22:08:07 2024 -0800 libstdc++: Fix error handling in filesystem::equivalent [PR113250] This patch made std::filesystem::equivalent correctly throw an exception when either path does not exist as per [fs.op.equivalent]/4. PR libstdc++/113250 libstdc++-v3/ChangeLog: * src/c++17/fs_ops.cc (fs::equivalent): Use || instead of &&. * src/filesystem/ops.cc (fs::equivalent): Likewise. * testsuite/27_io/filesystem/operations/equivalent.cc: Handle error codes. * testsuite/experimental/filesystem/operations/equivalent.cc: Likewise. Signed-off-by: Ken Matsui Reviewed-by: Jonathan Wakely (cherry picked from commit df147e2ee7199d33d66959c6509ce9c21072077f)
[Bug libstdc++/113250] std::filesystem::equivalent("", "/") should throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113250 --- Comment #5 from GCC Commits --- The releases/gcc-12 branch has been updated by Ken Matsui : https://gcc.gnu.org/g:da19967df3ad5d123888ef24b4fd84be047df226 commit r12-10089-gda19967df3ad5d123888ef24b4fd84be047df226 Author: Ken Matsui Date: Wed Jan 10 22:08:07 2024 -0800 libstdc++: Fix error handling in filesystem::equivalent [PR113250] This patch made std::filesystem::equivalent correctly throw an exception when either path does not exist as per [fs.op.equivalent]/4. PR libstdc++/113250 libstdc++-v3/ChangeLog: * src/c++17/fs_ops.cc (fs::equivalent): Use || instead of &&. * src/filesystem/ops.cc (fs::equivalent): Likewise. * testsuite/27_io/filesystem/operations/equivalent.cc: Handle error codes. * testsuite/experimental/filesystem/operations/equivalent.cc: Likewise. Signed-off-by: Ken Matsui Reviewed-by: Jonathan Wakely (cherry picked from commit df147e2ee7199d33d66959c6509ce9c21072077f)
[Bug libstdc++/113250] std::filesystem::equivalent("", "/") should throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113250 --- Comment #6 from GCC Commits --- The releases/gcc-11 branch has been updated by Ken Matsui : https://gcc.gnu.org/g:6c4882dd9453d096429cfb4652f25915a931e155 commit r11-11188-g6c4882dd9453d096429cfb4652f25915a931e155 Author: Ken Matsui Date: Wed Jan 10 22:08:07 2024 -0800 libstdc++: Fix error handling in filesystem::equivalent [PR113250] This patch made std::filesystem::equivalent correctly throw an exception when either path does not exist as per [fs.op.equivalent]/4. PR libstdc++/113250 libstdc++-v3/ChangeLog: * src/c++17/fs_ops.cc (fs::equivalent): Use || instead of &&. * src/filesystem/ops.cc (fs::equivalent): Likewise. * testsuite/27_io/filesystem/operations/equivalent.cc: Handle error codes. * testsuite/experimental/filesystem/operations/equivalent.cc: Likewise. Signed-off-by: Ken Matsui Reviewed-by: Jonathan Wakely (cherry picked from commit df147e2ee7199d33d66959c6509ce9c21072077f)
[Bug libstdc++/109162] C++23 improvements to std::format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162 Jonathan Wakely changed: What|Removed |Added Depends on||113318 --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > I remain confused about how to implement this. We could use > newlocale(loc.name()) to try to open a C locale from the C++ locale's name, > and if that works use nl_langinfo_l to get the locale's encoding, P1185 (PR 113318) provides a standard API for doing that. So it probably makes sense to implement that part of P1185 before doing P2419. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113318 [Bug 113318] [C++23] Implement P1185R12, Naming text encodings to demystify them
[Bug ipa/113291] [14 Regression] compilation never (?) finishes with recursive always_inline functions at -O and above since r14-2172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291 --- Comment #3 from Richard Biener --- We're endlessly inlining during IPA. Honza, please have a look.
[Bug c/113315] during GIMPLE pass: bitintlower0 ICE: in lower_mergeable_stmt, at gimple-lower-bitint.cc:2310 with _BitInt() used as array index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113315 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-01-11 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 57039 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57039&action=edit gcc14-pr113315.patch Untested fix.
[Bug tree-optimization/113334] New: wrong code with _BitInt() shift at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113334 Bug ID: 113334 Summary: wrong code with _BitInt() shift at -O0 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57040 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57040&action=edit reduced testcase I cannot tell for sure that the code is defined, but I don't see anything breaking pre-C23 rules, if applied to _BitInt(). Output: $ x86_64-pc-linux-gnu-gcc testcase.c $ ./a.out Aborted It works fine on -O1 and above. $ 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-r14-7127-20240110200826-g2105c49bbe8-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.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-r14-7127-20240110200826-g2105c49bbe8-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20240111 (experimental) (GCC)
[Bug libstdc++/113250] std::filesystem::equivalent("", "/") should throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113250 Ken Matsui changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |11.5 --- Comment #7 from Ken Matsui --- Fixed in 11.5, 12.4, 13.3. Thank you for filing this issue, Davide!
[Bug tree-optimization/112636] [14 Regression] ICE on valid code at -O1 (but not at -O{0,s,2,3}) with "-ftree-vectorize": in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1069
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112636
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #2 from Richard Biener ---
The issue is that should_duplicate_loop_header_p we call after
basic_block header = loop->header;
if (!get_max_loop_iterations_int (loop))
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "Loop %d never loops.\n", loop->num);
scale_loop_profile (loop, profile_probability::always (), 0);
loops_to_unloop.safe_push (loop);
loops_to_unloop_nunroll.safe_push (0);
continue;
ends up calling estimate_numbers_of_iterations () only then actually
updating the upper bound we check above. It does so hidden via
#0 estimate_numbers_of_iterations (loop=0x7700e4b0)
at /space/rguenther/src/gcc/gcc/tree-ssa-loop-niter.cc:4806
#1 0x019434ef in loop_exits_before_overflow (
base=, step=,
at_stmt=, loop=0x7700e4b0)
at /space/rguenther/src/gcc/gcc/tree-ssa-loop-niter.cc:5259
#2 0x019440b0 in scev_probably_wraps_p (var=,
base=, step=,
at_stmt=, loop=0x7700e4b0,
use_overflow_semantics=true)
at /space/rguenther/src/gcc/gcc/tree-ssa-loop-niter.cc:5511
#3 0x01bb97ea in get_scev_info (r=...,
name=, stmt=,
l=0x7700e4b0, init=@0x7fffa898: ,
step=@0x7fffa890: ,
dir=@0x7fffa88c: EV_DIR_DECREASES)
at /space/rguenther/src/gcc/gcc/vr-values.cc:204
#4 0x01bb9d6d in range_of_var_in_loop (v=...,
name=, l=0x7700e4b0,
stmt=, query=0x4961550)
at /space/rguenther/src/gcc/gcc/vr-values.cc:271
#5 0x02edf824 in fold_using_range::range_of_ssa_name_with_loop_info (
this=0x7fffb46f, r=..., name=,
...
#22 0x018f3f77 in should_duplicate_loop_header_p (
header=, loop=0x7700e4b0,
ranger=0x4961550, limit=0x7fffd88c, invariant_exits=0x47e60f0,
static_exits=0x4961040)
at /space/rguenther/src/gcc/gcc/tree-ssa-loop-ch.cc:251
#23 0x018f59d7 in (anonymous namespace)::ch_base::copy_headers (
this=0x47f2a30, fun=0x771e2000)
at /space/rguenther/src/gcc/gcc/tree-ssa-loop-ch.cc:831
The best is to analyze niters for the loop we try to process.
[Bug c++/113332] [12/13/14 regression] ICE when building fcitx-5.1.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113332 --- Comment #1 from Sam James --- Created attachment 57041 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57041&action=edit invalid.ii Here's an invalid reduced version. Re-reducing...
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753 --- Comment #14 from Jan Hubicka --- > I think the issue might be that whoever is creating > __static_initialization_and_destruction_0 fails to honor the active > target pragma. Which means back to my suggestion to have multiple ones > when different target options are on the individual CTORs and any of them > have always-inline (with always-inline we can't rely on an out-of-line copy > to exist). If I remember right, __static_initialization_and_destruction_0 call all static constructors of priority 0. So it has really no active pragma since it may change across translation unit. We also have similar code in IPA where we collect constructors across whole program. Motivation was to get them inlined and obtain better code locality. Back then Firefox had iostram constructor in every object file and those ctors made whole text segment to be loaded on demand during startup. Probably correct solution would be to group construtor into groups by compatible optimization/target pgramas in the inliner's definition. A quick hack would be to generate wrapper calls which will "eat" the always inline...
[Bug tree-optimization/113316] during GIMPLE pass: bitintlower ICE: SIGSEGV in var_to_partition (tree-ssa-live.h:163) at -O with uninitialized _BitInt() function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113316 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2024-01-11 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Jakub Jelinek --- Created attachment 57042 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57042&action=edit gcc14-pr113316.patch Untested fix.
[Bug tree-optimization/112505] [11/12/13/14 Regression] internal compiler error: in build_vector_from_val, at tree.cc:2104 since r10-4076
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112505 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Richard Biener --- I have a patch.
[Bug libstdc++/107466] [12 Regression] invalid -Wnarrowing error with std::subtract_with_carry_engine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107466
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #9 from Jonathan Wakely ---
I'm reopening this because the fix changes the behaviour of some code:
https://cplusplus.github.io/LWG/issue4014
As noted there, std::ranlux48_base(UINT_MAX+1LL)() changed behaviour.
Originally that yielded 22575453646312 but after the commits above it yields
23223501020940
This is what I proposed for 4014 and restores the original behaviour:
--- a/libstdc++-v3/include/bits/random.tcc
+++ b/libstdc++-v3/include/bits/random.tcc
@@ -541,8 +541,16 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
subtract_with_carry_engine<_UIntType, __w, __s, __r>::
seed(result_type __value)
{
+ // _GLIBCXX_RESOLVE_LIB_DEFECTS
+ // 3809. Is std::subtract_with_carry_engine supposed to work?
+ // 4014. LWG 3809 changes behavior of some existing code
+ if (__value == 0u)
+ __value = default_seed;
+ else
+ __value %= 2147483563u;
+
std::linear_congruential_engine
- __lcg(__value == 0u ? default_seed : __value);
+ __lcg(__value);
const size_t __n = (__w + 31) / 32;
[Bug tree-optimization/113323] ICE: tree check: expected none of vector_type, have vector_type in bitint_precision_kind, at gimple-lower-bitint.cc:131 with _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113323 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-01-11 --- Comment #1 from Jakub Jelinek --- Created attachment 57043 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57043&action=edit gcc14-pr113323.patch Untested fix.
[Bug tree-optimization/112636] [14 Regression] ICE on valid code at -O1 (but not at -O{0,s,2,3}) with "-ftree-vectorize": in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1069
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112636 --- Comment #3 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:05e8ef2a05b477589cae25af3311bad0f68a90fe commit r14-7138-g05e8ef2a05b477589cae25af3311bad0f68a90fe Author: Richard Biener Date: Thu Jan 11 13:35:51 2024 +0100 tree-optimization/112636 - estimate niters before header copying The following avoids a mismatch between an early query for maximum number of iterations of a loop and a late one when through ranger we'd get iterations estimated. Instead make sure we compute niters before querying the iteration bound. PR tree-optimization/112636 * tree-ssa-loop-ch.cc (ch_base::copy_headers): Call estimate_numbers_of_iterations before querying get_max_loop_iterations_int. (pass_ch::execute): Initialize SCEV and loops appropriately. * gcc.dg/pr112636.c: New testcase.
[Bug tree-optimization/112636] [14 Regression] ICE on valid code at -O1 (but not at -O{0,s,2,3}) with "-ftree-vectorize": in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1069
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112636 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/111043] [14 regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1068 since r14-2675-gef28aadad6e5cf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111043 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Biener --- Fixed by r14-7138-g05e8ef2a05b477
[Bug tree-optimization/110769] [14 Regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1023 since r14-2675-gef28aadad6e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110769 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Richard Biener --- Fixed by r14-7138-g05e8ef2a05b477
[Bug tree-optimization/110641] [14 Regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1023 since r14-2230-g7e904d6c7f2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110641 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed by r14-7138-g05e8ef2a05b477
[Bug tree-optimization/110769] [14 Regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1023 since r14-2675-gef28aadad6e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110769 Bug 110769 depends on bug 110641, which changed state. Bug 110641 Summary: [14 Regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1023 since r14-2230-g7e904d6c7f2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110641 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug other/113317] New test case libgomp.c++/ind-base-2.C fails with ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113317 jules at gcc dot gnu.org changed: What|Removed |Added CC||jules at gcc dot gnu.org --- Comment #2 from jules at gcc dot gnu.org --- I haven't been able to reproduce this with our local testing infrastructure on the powerpc64le machine available to me (i.e., the test works for me there). I'd be a bit surprised about a machine dependence at this early stage in parsing, but here we go! Let me know if there's any other information that might help track this down.
[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 --- Comment #2 from Mikael Pettersson --- 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.
[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|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2024-01-11 --- Comment #9 from Richard Biener --- I have a patch.
[Bug tree-optimization/113330] ICE: verify_gimple failed: conversion of register to a different size in 'view_convert_expr' with -O -fstack-check=generic and _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113330 Jakub Jelinek changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- This is the invalid build_bitint_type (65536, 0) case I was talking about in https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642423.html but not really sure where it should punt on that.
[Bug tree-optimization/112505] [11/12/13/14 Regression] internal compiler error: in build_vector_from_val, at tree.cc:2104 since r10-4076
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112505 --- Comment #6 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ec345df53556ec581590347f71c3d9ff3cdbca76 commit r14-7140-gec345df53556ec581590347f71c3d9ff3cdbca76 Author: Richard Biener Date: Thu Jan 11 14:00:33 2024 +0100 tree-optimization/112505 - bit-precision induction vectorization Vectorization of bit-precision inductions isn't implemented but we don't check this, instead we ICE during transform. PR tree-optimization/112505 * tree-vect-loop.cc (vectorizable_induction): Reject bit-precision induction. * gcc.dg/vect/pr112505.c: New testcase.
[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 --- Comment #4 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:897b95a12b7fe549ec2cb8ef3a3f0e4fbabf9737 commit r14-7139-g897b95a12b7fe549ec2cb8ef3a3f0e4fbabf9737 Author: Richard Biener Date: Thu Jan 11 12:02:43 2024 +0100 tree-optimization/113126 - vector extension compare optimization The following makes sure the resulting boolean type is the same when eliding a float extension. PR tree-optimization/113126 * match.pd ((double)float CMP (double)float -> float CMP float): Make sure the boolean type is the same. * fold-const.cc (fold_binary_loc): Likewise. * gcc.dg/torture/pr113126.c: New testcase.
[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 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/113330] ICE: verify_gimple failed: conversion of register to a different size in 'view_convert_expr' with -O -fstack-check=generic and _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113330 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2024-01-11 --- Comment #2 from Jakub Jelinek --- Created attachment 57044 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57044&action=edit gcc14-pr113330.patch Untested fix.
[Bug rtl-optimization/112918] [m68k] [LRA] ICE: maximum number of generated reload insns per insn achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918 --- Comment #16 from GCC Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:a729b6e002fe76208f33fdcdee49d6a310a1940e commit r14-7141-ga729b6e002fe76208f33fdcdee49d6a310a1940e Author: Vladimir N. Makarov Date: Thu Jan 11 08:46:26 2024 -0500 [PR112918][LRA]: Fixing IRA ICE on m68k Some GCC tests on m68K port of LRA is failed on `maximum number of generated reload insns per insn achieved`. The problem is in that for subreg reload LRA can not narrow reg class more from ALL_REGS to GENERAL_REGS and then to data regs or address regs. The patch permits narrowing reg class from reload insns if this results in successful matching of reg operand. This is the second version of the patch to fix the PR. This version adds matching with and without narrowing reg class and preferring match without narrowing classes. gcc/ChangeLog: PR rtl-optimization/112918 * lra-constraints.cc (SMALL_REGISTER_CLASS_P): Move before in_class_p. (in_class_p): Restrict condition for narrowing class in case of allow_all_reload_class_changes_p. (process_alt_operands): Try to match operand without and with narrowing reg class. Discourage narrowing the class. Finish insn matching only if there is no class narrowing. (curr_insn_transform): Pass true to in_class_p for reg operand win.
[Bug testsuite/113319] Random LTO test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113319 --- Comment #4 from GCC Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:da1e651e9c00b9c6100b2ea915631eba0e0d07ba commit r14-7142-gda1e651e9c00b9c6100b2ea915631eba0e0d07ba Author: Tamar Christina Date: Thu Jan 11 14:44:18 2024 + testsuite: remove -save-temps from many tests [PR113319] This removes -save-temps from the tests I've introduced to fix the LTO mismatches. gcc/testsuite/ChangeLog: PR testsuite/113319 * gcc.dg/bic-bitmask-13.c: Remove -save-temps. * gcc.dg/bic-bitmask-14.c: Likewise. * gcc.dg/bic-bitmask-15.c: Likewise. * gcc.dg/bic-bitmask-16.c: Likewise. * gcc.dg/bic-bitmask-17.c: Likewise. * gcc.dg/bic-bitmask-18.c: Likewise. * gcc.dg/bic-bitmask-19.c: Likewise. * gcc.dg/bic-bitmask-20.c: Likewise. * gcc.dg/bic-bitmask-21.c: Likewise. * gcc.dg/bic-bitmask-22.c: Likewise. * gcc.dg/bic-bitmask-7.c: Likewise. * gcc.dg/vect/vect-early-break-run_1.c: Likewise. * gcc.dg/vect/vect-early-break-run_10.c: Likewise. * gcc.dg/vect/vect-early-break-run_2.c: Likewise. * gcc.dg/vect/vect-early-break-run_3.c: Likewise. * gcc.dg/vect/vect-early-break-run_4.c: Likewise. * gcc.dg/vect/vect-early-break-run_5.c: Likewise. * gcc.dg/vect/vect-early-break-run_6.c: Likewise. * gcc.dg/vect/vect-early-break-run_7.c: Likewise. * gcc.dg/vect/vect-early-break-run_8.c: Likewise. * gcc.dg/vect/vect-early-break-run_9.c: Likewise.
[Bug testsuite/113319] Random LTO test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113319 Tamar Christina changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Tamar Christina --- Fixed, sorry for the breakage.
[Bug c++/86689] [11/12/13/14 Regression] Some combination of SFINAE, overloading, and type deduction showing version inconsistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86689 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=105481 --- Comment #5 from Patrick Palka --- Looks like this is fixed on trunk and the 13/12 release branches by the fix for PR105481 r13-6853-g4e2cdb1ddb5f6a.
[Bug c++/113332] [12/13/14 regression] ICE when building fcitx-5.1.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113332 Patrick Palka changed: What|Removed |Added Last reconfirmed||2024-01-11 Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=105637 CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #2 from Patrick Palka --- Started with r13-984-g44a5bd6d933d86
[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
[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 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 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 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/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 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&action=edit gcc14-pr113334.patch Untested fix.
[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 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&action=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(&custom_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 (&this_context);
cur_context = this_context;
code = _Unwind_ForcedUnwind_Phase2 (exc, &cur_context, &frames);
gcc_assert (code == _URC_INSTALL_CONTEXT);
uw_install_context (&this_context, &cur_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 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 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 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 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 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 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 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 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 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 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/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 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 #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++/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 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 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 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 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 #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] `-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 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 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: '&HEAP_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 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 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 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 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 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 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
