[Bug tree-optimization/104964] Wrong *** buffer overflow detected ***: terminated - acl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964 --- Comment #17 from Martin Liška --- (In reply to Sam James from comment #16) > I think I might have hit the same thing in qt_readlink: > https://bugs.gentoo.org/847145. Martin, did you chase down the Qt issue you > had? Yes, for Qt5, one needs to following patch: https://build.opensuse.org/package/view_file/KDE:Qt:5.15/libqt5-qtbase/mitigate-FORTIFY_SOURCE-3.patch?expand=1
[Bug c/105378] [OpenMP][5.1] 'nowait' on 'taskwait' not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105378 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b43836914bdc2a37563cf31359b2c4803bfe4374 commit r13-724-gb43836914bdc2a37563cf31359b2c4803bfe4374 Author: Jakub Jelinek Date: Tue May 24 09:12:44 2022 +0200 openmp: Add taskwait nowait depend support [PR105378] This patch adds support for (so far C/C++) #pragma omp taskwait nowait depend(...) directive, which is like #pragma omp task depend(...) ; but slightly optimized on the library side, so that it creates the task only for the purpose of dependency tracking and doesn't actually schedule it and wait for it when the dependencies are satisfied, instead makes its dependencies satisfied right away. 2022-05-24 Jakub Jelinek PR c/105378 gcc/ * omp-builtins.def (BUILT_IN_GOMP_TASKWAIT_DEPEND_NOWAIT): New builtin. * gimplify.cc (gimplify_omp_task): Diagnose taskwait with nowait clause but no depend clauses. * omp-expand.cc (expand_taskwait_call): Use BUILT_IN_GOMP_TASKWAIT_DEPEND_NOWAIT rather than BUILT_IN_GOMP_TASKWAIT_DEPEND if nowait clause is present. gcc/c/ * c-parser.cc (OMP_TASKWAIT_CLAUSE_MASK): Add nowait clause. gcc/cp/ * parser.cc (OMP_TASKWAIT_CLAUSE_MASK): Add nowait clause. gcc/testsuite/ * c-c++-common/gomp/taskwait-depend-nowait-1.c: New test. libgomp/ * libgomp_g.h (GOMP_taskwait_depend_nowait): Declare. * libgomp.map (GOMP_taskwait_depend_nowait): Export at GOMP_5.1.1. * task.c (empty_task): New function. (gomp_task_run_post_handle_depend_hash): Declare earlier. (gomp_task_run_post_handle_depend): Declare. (GOMP_task): Optimize fn == empty_task if there is nothing to wait for. (gomp_task_run_post_handle_dependers): Optimize task->fn == empty_task. (GOMP_taskwait_depend_nowait): New function. * testsuite/libgomp.c-c++-common/taskwait-depend-nowait-1.c: New test.
[Bug tree-optimization/105705] [12/13 Regression] std::equal triggers incorrect -Wnonnull warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105705 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-05-24 Priority|P3 |P2 --- Comment #2 from Richard Biener --- (In reply to Andrew Pinski from comment #1) > if (_14 != _15) > goto ; [50.00%] > else > goto ; [50.00%] > > ... > >[local count: 507317172]: > _50 = _15 - _14; > if (_50 != 0) > goto ; [50.00%] > else > goto ; [50.00%] > >[local count: 253658586]: > _51 = (long unsigned int) _50; > _52 = __builtin_memcmp (_14, 0B, _51); > _53 = _52 == 0; > >[local count: 507317172]: > # _54 = PHI <1(16), _53(17)> > > > The function call is in an unreachable basic block. > > Since _15 == _14 holds true in bb16, _50 == 0 will hold true. so bb 17 is > never entered. > Looks like a pass ordering issue ... All ranger, DOM and VN know this trick though... We warn from post_ipa_warn here, not sure why. The late diagnostics code is spread all over the place which makes it not sensible places :/ It seems this is _specifically_ for -Wnonnull. Jakub - do you remember why you added the pass at this point, right after inlining but before scalar cleanup gets the chance to remove dead code? The memcmp is gone after 112.fre3, there's NEXT_PASS (pass_post_ipa_warn); /* Must run before loop unrolling. */ NEXT_PASS (pass_warn_access, /*early=*/true); NEXT_PASS (pass_complete_unrolli); NEXT_PASS (pass_backprop); NEXT_PASS (pass_phiprop); NEXT_PASS (pass_forwprop); /* pass_build_alias is a dummy pass that ensures that we execute TODO_rebuild_alias at this point. */ NEXT_PASS (pass_build_alias); NEXT_PASS (pass_return_slot); NEXT_PASS (pass_fre, true /* may_iterate */);
[Bug target/105710] ICE on powerpc darwin with TLS enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105710 --- Comment #6 from Sergey Fedorov --- > Correct (even if it did exist it would only be for 10.7+) so --enable-tls is > a configuration error. > > (as I have said several times, the idea of configure is to choose the > correct settings for the target _automatically_ - extra config options > should only be added if there is a very good reason and you know exactly > what they do). Got it, thank you!
[Bug tree-optimization/105705] [12/13 Regression] std::equal triggers incorrect -Wnonnull warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105705 --- Comment #3 from Jakub Jelinek --- (In reply to Richard Biener from comment #2) > Jakub - do you remember why you added the pass at this point, right after > inlining but before scalar cleanup gets the chance to remove dead code? Which exact pass? I don't think I've added pass_post_ipa_warn nor pass_warn_access, Martin added both. If you mean r12-2270-gdddb6ffdc5c25, that was just moving pass_object_sizes a few passes earlier.
[Bug c++/105712] New: [13 Regression] Rejected valid code since r13-76-gdcb4bd0789d13dd4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105712
Bug ID: 105712
Summary: [13 Regression] Rejected valid code since
r13-76-gdcb4bd0789d13dd4
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
The is reduced from libqt5-qtwebengine package:
$ cat jumbo.ii
struct Lock {};
struct ThreadSafeThreadTraits {
struct {
Lock lock_;
} Lock;
};
$ g++ jumbo.ii -c
jumbo.ii:5:5: error: declaration of ‘ThreadSafeThreadTraits::
ThreadSafeThreadTraits::Lock’ changes meaning of ‘Lock’ [-fpermissive]
5 | } Lock;
| ^~~~
jumbo.ii:4:5: note: used here to mean ‘struct Lock’
4 | Lock lock_;
| ^~~~
jumbo.ii:1:8: note: declared here
1 | struct Lock {};
|^~~~
$ g++-11 jumbo.ii -c
$ clang++ jumbo.ii -c
[Bug c++/105712] [13 Regression] Rejected valid code since r13-76-gdcb4bd0789d13dd4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105712 --- Comment #1 from Andrew Pinski --- I think this code is invalid (no diagnostic required; there was some talk about changing this for C++23 to require a diagnostic) and GCC actually does the right thing here.
[Bug tree-optimization/105705] [12/13 Regression] std::equal triggers incorrect -Wnonnull warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105705 --- Comment #4 from Jakub Jelinek --- Ah, sorry, bad archeology, the pass_post_ipa_warn was indeed added by me and the rationale for placing it where it is was given in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78817#c9 The warning shouldn't have been added at all or not enabled at -Wall nor -Wextra. When it is, e.g. the unrolling or other optimizations (worst is certainly jump threading) can result in further false positives.
[Bug c++/105712] [13 Regression] Rejected valid code since r13-76-gdcb4bd0789d13dd4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105712 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- The testcases are explictly testing for this case even. So yes this is invalid.
[Bug rtl-optimization/105711] [12/13 Regression] ICE: in simplify_subreg, at simplify-rtx.cc:7346 with -O2 --param=sccvn-max-alias-queries-per-access=0 since r12-6173-g9ff206d3865df5cb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105711 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-05-24 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||ubizjak at gmail dot com Status|UNCONFIRMED |NEW Summary|[12/13 Regression] ICE: in |[12/13 Regression] ICE: in |simplify_subreg, at |simplify_subreg, at |simplify-rtx.cc:7346 with |simplify-rtx.cc:7346 with |-O2 |-O2 |--param=sccvn-max-alias-que |--param=sccvn-max-alias-que |ries-per-access=0 |ries-per-access=0 since ||r12-6173-g9ff206d3865df5cb --- Comment #1 from Martin Liška --- Started with r12-6173-g9ff206d3865df5cb.
[Bug c++/105699] [Concepts] Constrained virtual functions are accepted by GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105699
--- Comment #2 from Fedor Chelnokov ---
Another aspect is that the order of destructors in the class change its
behavior:
#include
template
struct X {
~X() requires (N==1);
virtual ~X();
};
// X is NOT polymorphic in GCC
static_assert( !std::is_polymorphic_v> );
template
struct Y {
virtual ~Y();
~Y() requires (N==1);
};
// Y is polymorphic in GCC
static_assert( std::is_polymorphic_v> );
Demo: https://gcc.godbolt.org/z/493qr5K9d
[Bug rtl-optimization/105711] [12/13 Regression] ICE: in simplify_subreg, at simplify-rtx.cc:7346 with -O2 --param=sccvn-max-alias-queries-per-access=0 since r12-6173-g9ff206d3865df5cb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105711
--- Comment #2 from Richard Biener ---
Confirmed. We are expanding
MEM [(char *)&c] = { 0, 0 };
with 'c' expanded as
(concat:CQI (reg/v:QI 93 [ c ])
(reg/v:QI 94 [ c+1 ]))
doing read_complex_part from
(subreg:CQI (const_vector:V2QI [
(const_int 0 [0]) repeated x2
]) 0)
which is a) a missed subreg simplification (do we have const complex in RTL?).
We get into extract_bit_field_1 which eventually does
/* Make sure we are playing with integral modes. Pun with subregs
if we aren't. */
opt_scalar_int_mode op0_mode = int_mode_for_mode (GET_MODE (op0));
scalar_int_mode imode;
if (!op0_mode.exists (&imode) || imode != GET_MODE (op0))
{
if (MEM_P (op0))
op0 = adjust_bitfield_address_size (op0, op0_mode.else_blk (),
0, MEM_SIZE (op0));
else if (op0_mode.exists (&imode))
{
op0 = gen_lowpart (imode, op0);
getting us a HImode (const_int 0 [0]) as op0. But extract_bit_field_as_subreg
which eventually ICEs only gets op0 but not its mode ...
I'm testing a patch.
[Bug rtl-optimization/105711] [12/13 Regression] ICE: in simplify_subreg, at simplify-rtx.cc:7346 with -O2 --param=sccvn-max-alias-queries-per-access=0 since r12-6173-g9ff206d3865df5cb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105711 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |12.2 Priority|P3 |P2 Status|NEW |ASSIGNED
[Bug c/105713] New: [gimplefe] need a way to specify TREE_ADDRESSABLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105713
Bug ID: 105713
Summary: [gimplefe] need a way to specify TREE_ADDRESSABLE
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
For PR105711 a RTL expansion GIMPLE testcase would have been nice:
typedef char v2qi __attribute__((vector_size(2)));
void __GIMPLE (ssa,startwith("optimized"))
foo (__complex__ char c)
{
__BB(2):
__MEM (&c) = _Literal (v2qi) { _Literal (char) 0, _Literal (char) 0
};
return;
}
but here 'c' ends up TREE_ADDRESSABLE while with the original setup it is not.
That's because the C FE parsing marks 'c' addressable when parsing &c. The
GIMPLE FE should fix this up on the optimistic side somehow and allow
specifying TREE_ADDRESSABLE at the declaration.
[Bug c/105713] [gimplefe] need a way to specify TREE_ADDRESSABLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105713 Richard Biener changed: What|Removed |Added Severity|normal |enhancement Blocks||101057 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101057 [Bug 101057] [gimplefe] GIMPLE frontend issues
[Bug c++/105699] [Concepts] Constrained virtual functions are accepted by GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105699 Jonathan Wakely changed: What|Removed |Added Blocks||67491 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-05-24 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug c++/103865] virtual function can have a requires clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103865 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=105699| Blocks||67491 Status|NEW |RESOLVED --- Comment #2 from Jonathan Wakely --- PR 105699 is a dup of this one, but since it has more details and examples there, let's close this one instead. *** This bug has been marked as a duplicate of bug 105699 *** Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug c++/105699] [Concepts] Constrained virtual functions are accepted by GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105699 Jonathan Wakely changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=103865| --- Comment #3 from Jonathan Wakely --- *** Bug 103865 has been marked as a duplicate of this bug. ***
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 103865, which changed state. Bug 103865 Summary: virtual function can have a requires clause https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103865 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug sanitizer/105714] New: ASan in gcc trunk missed a buffer-overflow at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105714
Bug ID: 105714
Summary: ASan in gcc trunk missed a buffer-overflow at -Os
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
For the following code, `gcc-trunk -Os -fsanitize=address` reported nothing,
however other opt levels reported the global buffer-overflow at the end of
function g().
Initially, I thought it might due to optimization at -Os, but I indeed found
the overflowed buffer be loaded in the assembly code and gcc-11 -Os did not
miss this bug: https://godbolt.org/z/r4rhM8bjz
$cat a.c
struct a {
int x
};
struct a b[2];
struct a *c = b, *d = b;
int e;
int g() {
for (e = 0; e < 1; e++) {
int i[1];
i;
}
for (int h = 0; h < 3; h++)
*c = *d;
*c = *(b+3);
return c->x;
}
void main() {
g();
}
$
$gcc-trunk -Os -fsanitize=address a.c && ./a.out
$
$gcc-trunk -O3 -fsanitize=address a.c && ./a.out
==12272==ERROR: AddressSanitizer: global-buffer-overflow on address
0x004042ac at pc 0x0040132a bp 0x7ffdbc905820 sp 0x7ffdbc905818
READ of size 4 at 0x004042ac thread T0
#0 0x401329 in g /local/home/shaoli/a.c:15
#1 0x7fc367b2f082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x40111d in _start (/local/home/shaoli/a.out+0x40111d)
0x004042ac is located 4 bytes to the right of global variable 'b' defined
in 'a.c:4:10' (0x4042a0) of size 8
SUMMARY: AddressSanitizer: global-buffer-overflow /local/home/shaoli/a.c:15 in
g
Shadow bytes around the buggy address:
0x80078800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078810: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
0x80078820: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 f9
0x80078830: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
0x80078840: f9 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 04 f9 f9 f9
=>0x80078850: f9 f9 f9 f9 00[f9]f9 f9 f9 f9 f9 f9 00 00 00 00
0x80078860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078890: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800788a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user:f7
Container overflow: fc
Array cookie:ac
Intra object redzone:bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone:cb
==12272==ABORTING
[Bug c/105378] [OpenMP][5.1] 'nowait' on 'taskwait' not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105378 --- Comment #4 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:4fb2b4f7ea6b80ae75d3efb6f86e7c6179080535 commit r13-726-g4fb2b4f7ea6b80ae75d3efb6f86e7c6179080535 Author: Tobias Burnus Date: Tue May 24 10:41:43 2022 +0200 OpenMP: Support nowait with Fortran [PR105378] Fortran part to C/C++/libgomp commit r13-724-gb43836914bdc2a37563cf31359b2c4803bfe4374 gcc/fortran/ PR c/105378 * openmp.cc (gfc_match_omp_taskwait): Accept nowait. gcc/testsuite/ PR c/105378 * gfortran.dg/gomp/taskwait-depend-nowait-1.f90: New. libgomp/ PR c/105378 * libgomp.texi (OpenMP 5.1): Set 'taskwait nowait' to 'Y'. * testsuite/libgomp.fortran/taskwait-depend-nowait-1.f90: New.
[Bug c/105378] [OpenMP][5.1] 'nowait' on 'taskwait' not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105378 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Implemented now.
[Bug sanitizer/105714] [12/13 Regression] ASan in gcc trunk missed a buffer-overflow at -Os since r12-5138-ge82c382971664d6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105714 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-05-24 Summary|ASan in gcc trunk missed a |[12/13 Regression] ASan in |buffer-overflow at -Os |gcc trunk missed a ||buffer-overflow at -Os ||since ||r12-5138-ge82c382971664d6f CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r12-5138-ge82c382971664d6f.
[Bug tree-optimization/105705] [12/13 Regression] std::equal triggers incorrect -Wnonnull warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105705 --- Comment #5 from Jonathan Wakely --- The warning started to be given without -Wsystem-headers with r12-1992 It was already present with -Wsystem-headers, but suppressed by default.
[Bug tree-optimization/105705] [12/13 Regression] std::equal triggers incorrect -Wnonnull warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105705 --- Comment #6 from Jonathan Wakely --- The warning seems to have started with r11-5391 Before that there was no warning even with -Wsystem-headers
[Bug sanitizer/105714] [12/13 Regression] ASan in gcc trunk missed a buffer-overflow at -Os since r12-5138-ge82c382971664d6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105714 --- Comment #2 from Jakub Jelinek --- I'll have a look...
[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #18 from Artem S. Tashkinov --- (In reply to Sam James from comment #17) > libtool recently got a new maintainer and had a new release (2.4.7). It's > possible 2.4.7 is related. Fedora 36 still features an old version: libtool-2.4.6-50.fc36.x86_64 Here's its changelog: https://src.fedoraproject.org/rpms/libtool/commits/f36
[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #19 from Artem S. Tashkinov --- I'm curious: Fedora 36 takes probably half an hour to be downloaded and installed in a VM/chroot/etc., so you could probably debug the issue in a few minutes ;-)
[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #20 from Andrew Pinski --- Note gcc sources have its own local copy of libtool so it does not matter what the distros have.
[Bug rtl-optimization/105715] New: [13 Regression] missed RTL if-conversion with COND_EXPR change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105715
Bug ID: 105715
Summary: [13 Regression] missed RTL if-conversion with
COND_EXPR change
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
gcc.target/i386/pr45685.c with -march=cascadelake shows missing RTL
if-conversion. The cruical GIMPLE difference is
_36 = _3 > 0;
iftmp.0_13 = _36 ? 1 : -1;
prephitmp_31 = ABS_EXPR <_3>;
prephitmp_32 = _36 ? -1 : 1;
prephitmp_33 = _36 ? 4294967295 : 1;
prephitmp_35 = _36 ? 1 : 4294967295;
...
_29 = prephitmp_31 != _42;
val_12 = _29 ? prephitmp_32 : iftmp.0_13;
prephitmp_37 = _29 ? prephitmp_33 : prephitmp_35;
vs.
iftmp.0_13 = _3 > 0 ? 1 : -1;
prephitmp_31 = ABS_EXPR <_3>;
prephitmp_32 = _3 > 0 ? -1 : 1;
prephitmp_33 = _3 > 0 ? 4294967295 : 1;
prephitmp_35 = _3 > 0 ? 1 : 4294967295;
...
val_12 = i.1_6 == prephitmp_31 ? iftmp.0_13 : prephitmp_32;
prephitmp_37 = i.1_6 != prephitmp_31 ? prephitmp_33 : prephitmp_35;
where the split out condition is now CSEd and the multi-use makes us not
TER the comparison. Previously we got two compare & jump sequences while
now we get the compare computing a QImode value and the then two
compare & jump sequences.
While without -march=cascadelake we do get the desired number of cmovs
the generated code is still worse.
The testcase is unfortunately a bit obfuscated due to the many
if-conversions taking place. Smaller GIMPLE testcases do not exhibit
jumpy RTL expansion.
void __GIMPLE(ssa, startwith("optimized"))
foo (long *p, long a, long b, long c, long d, long e, long f)
{
_Bool _2;
long _3;
long _8;
__BB(2):
_2 = a_1(D) < b_10(D);
_3 = _2 ? c_4(D) : d_5(D);
_8 = _2 ? f_6(D) : e_7(D);
__MEM (p_9(D)) = _3;
__MEM (p_9(D) + 4) = _8;
return;
}
#if __GNUC__ < 13
void __GIMPLE(ssa, startwith("optimized"))
bar (long *p, long a, long b, long c, long d, long e, long f)
{
long _3;
long _8;
__BB(2):
_3 = a_1(D) < b_10(D) ? c_4(D) : d_5(D);
_8 = a_1(D) >= b_10(D) ? e_7(D) : f_6(D);
__MEM (p_9(D)) = _3;
__MEM (p_9(D) + 4) = _8;
return;
}
#endif
[Bug sanitizer/105714] [12/13 Regression] ASan in gcc trunk missed a buffer-overflow at -Os since r12-5138-ge82c382971664d6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105714 --- Comment #3 from Jakub Jelinek --- The problem is we have: [local count: 354334800]: # h_21 = PHI *c.3_5 = *d.2_4; h_15 = h_21 + 1; if (h_15 != 3) goto ; [75.00%] else goto ; [25.00%] [local count: 118111600]: *c.3_5 = MEM[(struct a *)&b + 12B]; _13 = c.3_5->x; return _13; We instrument in the *c.3_5 = *d.2_4 both the load and store, but then when considering instrumentation of *c.3_5 = MEM[(struct a *)&b + 12B]; has_stmt_been_instrumented_p returns true because *c.3_5 has been indeed instrumented in a dominating bb. But the rhs hasn't been...
[Bug c++/105716] New: CTAD failure with member function returning auto as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105716
Bug ID: 105716
Summary: CTAD failure with member function returning auto as
template argument
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: j-l.wynen at hotmail dot de
Target Milestone: ---
gcc 12 fails to compile the following code (tested 12.1 and trunk). Tried with
c++17 and c++20.
template struct Func {
static auto apply() {}
};
template
struct A {
T x;
};
template
A(T) -> A;
int main() {
A a{Func::apply};
}
with an error of
error: 'A a' has incomplete type
The code compiles fine with gcc 11, 10, and 9 as well as clang and MSCV.
Changing static auto apply() {} to static void apply() {} or any other concrete
return type (and proper return statement) makes the code compiles.
Also, specifying the template argument of A in main makes it compile.
https://godbolt.org/z/c9cGnGEPq
[Bug tree-optimization/105705] [12/13 Regression] std::equal triggers incorrect -Wnonnull warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105705 --- Comment #7 from rguenther at suse dot de --- On Tue, 24 May 2022, redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105705 > > --- Comment #5 from Jonathan Wakely --- > The warning started to be given without -Wsystem-headers with r12-1992 > > It was already present with -Wsystem-headers, but suppressed by default. Skimming that it looks for whether the inline stack contains _only_ system headers now which means that any system header content inlined into user code will now be warned on without -Wsystem-header. That might be OK if the system header code is just abstraction but for more complicated code it's going to expose details not helpful to the user. We might want to change this to set m_allsyslocs to true if the "tail" of the inline stack is in system header which boils down to asking it for the original location - the intent wasn't to do extra suppression (like for user code inlined into system header context) but to expose more code to diagnostics which we are not ready to do [in late diagnostics at least].
[Bug sanitizer/105714] [12/13 Regression] ASan in gcc trunk missed a buffer-overflow at -Os since r12-5138-ge82c382971664d6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105714 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 53028 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53028&action=edit gcc13-pr105714.patch Untested fix.
[Bug libgcc/105708] libgcc: aarch64: init_lse_atomics can race with user-defined constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708 Wilco changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #10 from Wilco --- Increasing the priority of the constructor is perfectly reasonable given that it has no effect on correctness and doing it as early as possible is better for performance if other constructors use atomics.
[Bug rtl-optimization/105711] [12/13 Regression] ICE: in simplify_subreg, at simplify-rtx.cc:7346 with -O2 --param=sccvn-max-alias-queries-per-access=0 since r12-6173-g9ff206d3865df5cb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105711 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:91c7c5edd2c1d31bf379be1d077b39644391cc31 commit r13-727-g91c7c5edd2c1d31bf379be1d077b39644391cc31 Author: Richard Biener Date: Tue May 24 10:09:25 2022 +0200 middle-end/105711 - properly handle CONST_INT when expanding bitfields This is another place where we fail to pass down the mode of a CONST_INT. 2022-05-24 Richard Biener PR middle-end/105711 * expmed.cc (extract_bit_field_as_subreg): Add op0_mode parameter and use it. (extract_bit_field_1): Pass down the mode of op0 to extract_bit_field_as_subreg. * gcc.target/i386/pr105711.c: New testcase.
[Bug c++/105716] [12/13 Regression] CTAD failure with member function returning auto as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105716 Richard Biener changed: What|Removed |Added Summary|CTAD failure with member|[12/13 Regression] CTAD |function returning auto as |failure with member |template argument |function returning auto as ||template argument Target Milestone|--- |12.2 Keywords||rejects-valid Known to work||11.3.1
[Bug libgcc/105708] libgcc: aarch64: init_lse_atomics can race with user-defined constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek --- How can changing the constructor priority in libgcc affect anything? Constructor priorities are within the same shared library or within the same executable, not inside of the same process. So, e.g. when using libgcc_s.so.1, it might change order with other constructors inside of that shared library (there are likely none), but nothing else. For libgcc.a, it might affect even ctors of the other objects with which the library is linked, but still not between different shared libraries or binaries.
[Bug rtl-optimization/105715] [13 Regression] missed RTL if-conversion with COND_EXPR change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105715 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0 --- Comment #1 from Richard Biener --- Btw, I'm hoping for a smaller/simpler testcase to appear - and yes, something like this was expected I guess (but also latent since the new IL was valid before as well).
[Bug libstdc++/105717] New: [9/10/11/12/13 Regression] cannot create unordered_map from range of types convertible to value_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105717
Bug ID: 105717
Summary: [9/10/11/12/13 Regression] cannot create unordered_map
from range of types convertible to value_type
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: unassigned at gcc dot gnu.org
Target Milestone: ---
+++ This bug was initially created as a clone of Bug #56112 +++
François observed that I fixed construction for PR 56112, but we still don't
support insertion of such types:
#include
#include
#include
struct Key
{
explicit Key(const int* p) : value(p) { }
~Key() { value = nullptr; }
bool operator==(const Key& k) const
{ return *value == *k.value; }
const int* value;
};
struct hash
{
std::size_t operator()(const Key& k) const noexcept
{ return *k.value; }
};
struct S
{
static int _count;
int value;
operator std::pair() const
{
++_count;
return { Key(&value), value };
}
};
int S::_count = 0;
int main()
{
S s[1] = { {2} };
std::unordered_map m(s, s + 1);
assert( S::_count == 1 );
std::unordered_multimap mm(s, s + 1);
assert( S::_count == 2 );
m.insert(s, s + 1);
assert( S::_count == 3 );
mm.insert(s, s + 1);
assert( S::_count == 4 );
}
This worked in 4.7
[Bug libstdc++/105717] [9/10/11/12/13 Regression] cannot create unordered_map from range of types convertible to value_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105717 Jonathan Wakely changed: What|Removed |Added CC|unassigned at gcc dot gnu.org | Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-05-24
[Bug rtl-optimization/105715] [13 Regression] missed RTL if-conversion with COND_EXPR change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105715
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2022-05-24
Status|UNCONFIRMED |NEW
--- Comment #2 from Richard Biener ---
(In reply to Richard Biener from comment #0)
>
> void __GIMPLE(ssa, startwith("optimized"))
> foo (long *p, long a, long b, long c, long d, long e, long f)
> {
> _Bool _2;
> long _3;
> long _8;
>
> __BB(2):
> _2 = a_1(D) < b_10(D);
> _3 = _2 ? c_4(D) : d_5(D);
> _8 = _2 ? f_6(D) : e_7(D);
> __MEM (p_9(D)) = _3;
> __MEM (p_9(D) + 4) = _8;
> return;
> }
>
> #if __GNUC__ < 13
> void __GIMPLE(ssa, startwith("optimized"))
> bar (long *p, long a, long b, long c, long d, long e, long f)
> {
> long _3;
> long _8;
>
> __BB(2):
> _3 = a_1(D) < b_10(D) ? c_4(D) : d_5(D);
> _8 = a_1(D) >= b_10(D) ? e_7(D) : f_6(D);
> __MEM (p_9(D)) = _3;
> __MEM (p_9(D) + 4) = _8;
> return;
> }
> #endif
So with the above we do have (on the GCC 12 branch)
foo:
.LFB0:
.cfi_startproc
cmpq%rdx, %rsi
setl%al
testb %al, %al
cmovne 8(%rsp), %r9
cmove %r8, %rcx
movq%rcx, (%rdi)
movq%r9, 4(%rdi)
ret
vs.
bar:
.LFB1:
.cfi_startproc
cmpq%rdx, %rsi
cmovl 8(%rsp), %r9
cmovge %r8, %rcx
movq%rcx, (%rdi)
movq%r9, 4(%rdi)
ret
which shows an optimization difference when the condition is split out.
It also shows the condition is split out anyway in the end, it's just
the RTL representation with CCnn modes doesn't nicely match up the
GIMPLE so we somehow need to improve the plumbing here. But CCnn
get clobbered quite a lot and so any clever "CSE"ing of the (different!)
modes involved is going to require code motion or CCnn spilling (bad).
[Bug rtl-optimization/105715] [13 Regression] missed RTL if-conversion with COND_EXPR change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105715
--- Comment #3 from Richard Biener ---
So I guess the trick might be to notice that ...
;; _2 = a_1(D) < b_10(D);
(insn 12 11 13 (set (reg:CCGC 17 flags)
(compare:CCGC (reg/v:DI 86 [ a ])
(reg/v:DI 87 [ b ]))) -1
(nil))
(insn 13 12 14 (set (reg:QI 92)
(lt:QI (reg:CCGC 17 flags)
(const_int 0 [0]))) -1
(nil))
(insn 14 13 0 (set (reg:QI 82 [ _2 ])
(reg:QI 92)) -1
(nil))
... we expand to CCGCmode here ...
_3 replace with --> _3 = _2 ? c_4(D) : d_5(D);
;; *p_9(D) = _3;
(insn 15 14 16 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:QI 82 [ _2 ])
(const_int 0 [0]))) "t2.c":12:7 -1
(nil))
(insn 16 15 17 (set (reg:DI 93)
(if_then_else:DI (ne (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg/v:DI 88 [ c ])
(reg/v:DI 89 [ d ]))) "t2.c":12:7 -1
(nil))
... and thus want to use a CCGCmode based compare here as well? We can
of course force-forward ("un-CSE") the condition during RTL expansion.
But the question would be what's the best approach to deal with the
situation so that followup RTL passes have a chance to optimize the
redundant compares?
[Bug libgcc/105708] libgcc: aarch64: init_lse_atomics can race with user-defined constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708 --- Comment #12 from Wilco --- (In reply to Jakub Jelinek from comment #11) > How can changing the constructor priority in libgcc affect anything? > Constructor priorities are within the same shared library or within the same > executable, not inside of the same process. So, e.g. when using > libgcc_s.so.1, > it might change order with other constructors inside of that shared library > (there are likely none), but nothing else. For libgcc.a, it might affect > even ctors of the other objects with which the library is linked, but still > not between different shared libraries or binaries. The outline atomics are linked with each .so (to avoid the PLT and GOT), so there are multiple copies and any initialization order issues are within the .so.
[Bug other/105527] configure option --with-zstd is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105527 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:3677eb80b683cead7db972bc206fd2e75d997bd2 commit r13-728-g3677eb80b683cead7db972bc206fd2e75d997bd2 Author: Bruno Haible Date: Wed May 11 17:10:07 2022 +0200 Extend --with-zstd documentation The patch that was so far added for documenting --with-zstd is pretty minimal: - it refers to undocumented options --with-zstd-include and --with-zstd-lib; - it suggests that --with-zstd can be used without an argument; - it does not clarify how this option applies to cross-compilation. How about adding the same details as for the --with-isl, --with-isl-include, --with-isl-lib options, mutatis mutandis? This patch does that. PR other/105527 gcc/ChangeLog: * doc/install.texi (Configuration): Add more details about --with-zstd. Document --with-zstd-include and --with-zstd-lib Signed-off-by: Bruno Haible
[Bug other/105527] configure option --with-zstd is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105527 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Martin Liska : https://gcc.gnu.org/g:f4c0f9257ef2615add8ecb30e7a568755b692473 commit r12-8411-gf4c0f9257ef2615add8ecb30e7a568755b692473 Author: Martin Liska Date: Wed May 11 13:21:26 2022 +0200 docs: document --with-zstd PR other/105527 gcc/ChangeLog: * doc/install.texi: Document the configure option --with-zstd. (cherry picked from commit 8fa689767a8a55c889683d178ae3a003ec689927)
[Bug other/105527] configure option --with-zstd is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105527 --- Comment #7 from CVS Commits --- The releases/gcc-12 branch has been updated by Martin Liska : https://gcc.gnu.org/g:394ff2fbfc84eb6d6cfc56b04e28ee9b42a5ab57 commit r12-8412-g394ff2fbfc84eb6d6cfc56b04e28ee9b42a5ab57 Author: Bruno Haible Date: Wed May 11 17:10:07 2022 +0200 Extend --with-zstd documentation The patch that was so far added for documenting --with-zstd is pretty minimal: - it refers to undocumented options --with-zstd-include and --with-zstd-lib; - it suggests that --with-zstd can be used without an argument; - it does not clarify how this option applies to cross-compilation. How about adding the same details as for the --with-isl, --with-isl-include, --with-isl-lib options, mutatis mutandis? This patch does that. PR other/105527 gcc/ChangeLog: * doc/install.texi (Configuration): Add more details about --with-zstd. Document --with-zstd-include and --with-zstd-lib Signed-off-by: Bruno Haible (cherry picked from commit 3677eb80b683cead7db972bc206fd2e75d997bd2)
[Bug other/105527] configure option --with-zstd is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105527 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Martin Liška --- Fixed on gcc-12 branch, closing.
[Bug libstdc++/105717] [9/10/11/12/13 Regression] cannot create unordered_map from range of types convertible to value_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105717 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.4
[Bug tree-optimization/52171] memcmp/strcmp/strncmp can be optimized when the result is tested for [in]equality with 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52171 --- Comment #17 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:9e7a0e42a15eb53850496e91f2e484ed74ac3617 commit r13-738-g9e7a0e42a15eb53850496e91f2e484ed74ac3617 Author: Roger Sayle Date: Tue May 24 14:29:27 2022 +0100 Minor improvement to genpreds.cc This simple patch implements Richard Biener's suggestion in comment #6 of PR tree-optimization/52171 (from February 2013) that the insn-preds code generated by genpreds can avoid using strncmp when matching constant strings of length one. The effect of this patch is best explained by the diff of insn-preds.cc: < if (!strncmp (str + 1, "g", 1)) --- > if (str[1] == 'g') 3104c3104 < if (!strncmp (str + 1, "m", 1)) --- > if (str[1] == 'm') 3106c3106 < if (!strncmp (str + 1, "c", 1)) --- > if (str[1] == 'c') ... The equivalent optimization is performed by GCC (but perhaps not by the host compiler), but generating simpler/smaller code may encourage further optimizations (such as use of a switch statement). 2022-05-24 Roger Sayle gcc/ChangeLog * genpreds.cc (write_lookup_constraint_1): Avoid generating a call to strncmp for strings of length one.
[Bug c++/105716] [12/13 Regression] CTAD failure with member function returning auto as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105716 Patrick Palka changed: What|Removed |Added Last reconfirmed||2022-05-24 Status|UNCONFIRMED |NEW Known to fail||12.1.0, 13.0 Ever confirmed|0 |1 CC||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Confirmed, started with r12-1270-ga1b3484a8e6c53.
[Bug c++/105718] New: Forward Declarations of Constrained Partially Specialized Class Templates Rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105718 Bug ID: 105718 Summary: Forward Declarations of Constrained Partially Specialized Class Templates Rejected Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mate.kelemen.12 at gmail dot com Target Milestone: --- Created attachment 53029 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53029&action=edit Preprocessed source run with: g++ -v --save-temps -std=c++20. Multiple forward declarations of partially specialized class templates with constraints (C++20 concepts) get rejected at the second declaration. Equivalent code with explicit specializations compiles without issues. See the [example](https://godbolt.org/z/1hd8Y6Ghh) on godbolt (Clang and MSVC don't reject it). Source and preprocessed file in the attachments. This issue seems to be a duplicate of #99501 from 03.2021, which hasn't gotten any attention yet.
[Bug target/105710] ICE on powerpc darwin with TLS enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105710 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=52268, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=53504 --- Comment #7 from Eric Gallager --- (In reply to Sergey Fedorov from comment #4) > (In reply to Andrew Pinski from comment #3) > > (In reply to Sergey Fedorov from comment #2) > > > (In reply to Andrew Pinski from comment #1) > > > > >TLS enabled > > > > > > > > TLS support for powerpc darwin was never added. > > > > > > Iain writes that emulated TLS is supported on all Darwin versions starting > > > from 10.5: > > > https://github.com/ruby/ruby/pull/5927?notification_referrer_id=NT_kwDOBXwLlrMzNjYyMzQ0NjYzOjkyMDE1NTEw#issuecomment-1133843490 > > > > That is enabled by default though --enable-tls tries to enable native TLS > > support. > > From what I understand, native TLS does not exist with gcc, at least for > Darwin. That's bug 52268, for reference. (In reply to Iain Sandoe from comment #5) > Correct (even if it did exist it would only be for 10.7+) so --enable-tls is > a configuration error. > > (as I have said several times, the idea of configure is to choose the > correct settings for the target _automatically_ - extra config options > should only be added if there is a very good reason and you know exactly > what they do). Well we could at least make the error happen earlier rather than letting it turn into an ICE. I think making the configure script smarter about whether TLS works or not could be worthwhile; see bug 53504
[Bug libgcc/105708] libgcc: aarch64: init_lse_atomics can race with user-defined constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708 Wilco changed: What|Removed |Added Ever confirmed|0 |1 Status|RESOLVED|ASSIGNED Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org Last reconfirmed||2022-05-24 Resolution|WONTFIX |---
[Bug target/105710] ICE on powerpc darwin with TLS enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105710 --- Comment #8 from Iain Sandoe --- (In reply to Eric Gallager from comment #7) > > (as I have said several times, the idea of configure is to choose the > > correct settings for the target _automatically_ - extra config options > > should only be added if there is a very good reason and you know exactly > > what they do). > > Well we could at least make the error happen earlier rather than letting it > turn into an ICE. I think making the configure script smarter about whether > TLS works or not could be worthwhile; see bug 53504 If we try to do this for every irrelevant configure option, that's going to be quite a lot of work. Really [IMO, at least], configure options are not intended for end-users - the goal for end users is that: configure --prefix=xx && make && install should 'just work' (OK, we don't quite achieve that, but actually we're quite close) adding out-of-band configure options is for distributions and expert use (we assume distributions are expert in the options they need to apply to customise the install). However, of course, if you want to write patches to respond to all the options that Darwin does not need, I'm happy to review :)
[Bug middle-end/105629] [13 Regression] g++.dg/opt/pr94589-2.C for cris, m68k, s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105629 --- Comment #10 from Hans-Peter Nilsson --- (In reply to Richard Biener from comment #9) > Shoudl be fixed. Confirmed, thanks!
[Bug target/105710] ICE on powerpc darwin with TLS enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105710 --- Comment #9 from Sergey Fedorov --- (In reply to Iain Sandoe from comment #8) > If we try to do this for every irrelevant configure option, that's going to > be quite a lot of work. > > Really [IMO, at least], configure options are not intended for end-users > - the goal for end users is that: > > configure --prefix=xx && make && install > > should 'just work' (OK, we don't quite achieve that, but actually we're > quite close) > > adding out-of-band configure options is for distributions and expert use > (we assume distributions are expert in the options they need to apply to > customise the install). > > However, of course, if you want to write patches to respond to all the > options > that Darwin does not need, I'm happy to review :) I agree with Iain here, in fact it is a problem with Macports, since it’s `--disable-tls` option lists a reason totally unrelated to PPC or Darwin version: ># see https://lists.macports.org/pipermail/macports-dev/2017-August/036209.html ># --disable-tls does not limit functionality ># it only determines how std::call_once works >configure.args-append \ >--disable-tls Then it was me who misunderstood Iain’s reply in my PR to Ruby. I thought that Macports disables TLS for no clear reason, while Ruby wants it provided by the compiler, and tried to build it with `--enable-tls`. Sorry for a confusion. I just had an impression that all ICEs have to be reported.
[Bug tree-optimization/105668] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O -ftracer -fno-tree-fre since r13-458-gd75d4293dcc029a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105668 --- Comment #6 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:793f847ba7dbe7638f1c27178868edbefd3a8108 commit r13-739-g793f847ba7dbe7638f1c27178868edbefd3a8108 Author: Roger Sayle Date: Tue May 24 15:15:12 2022 +0100 PR tree-optimization/105668: Provide vcond_mask_v1tiv1ti pattern. This patch is an alternate/supplementary fix to PR tree-optimization/105668 that provides a vcond_mask_v1titi optab/define_expand to the i386 backend. An undocumented feature/bug of GCC's vectorization is that any target that provides a vec_cmpeq has to also provide a matching vcond_mask. This backend patch preserves the status quo, rather than fixes the underlying problem. One aspect of this clean-up is that ix86_expand_sse_movcc provides fallback implementations using pand/pandn/por that effectively make V2DImode and V1TImode vcond_mask available on any TARGET_SSE2, not just TARGET_SSE4_2. This allows a simplification as V2DI mode can be handled by using a VI_128 mode iterator instead of a VI124_128 mode iterator, and instead this define_expand is effectively renamed to provide a V1TImode vcond_mask expander (as V1TI isn't in VI_128). 2022-05-24 Roger Sayle gcc/ChangeLog PR tree-optimization/105668 * config/i386/i386-expand.cc (ix86_expand_sse_movcc): Support V1TImode, just like V2DImode. * config/i386/sse.md (vcond_mask_): Use VI_128 mode iterator instead of VI124_128 to include V2DI. (vcond_mask_v2div2di): Delete. (vcond_mask_v1tiv1ti): New define_expand. gcc/testsuite/ChangeLog PR tree-optimization/105668 * gcc.target/i386/pr105668.c: New test case.
[Bug target/93082] macOS Authorization.h needs fixinclude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082 --- Comment #12 from Eric Gallager --- (In reply to Iain Sandoe from comment #10) > I do not currently have a plan to try and build a second fix includes tree > for Frameworks, but happy to review patches if someone else does :) OK I'll open a separate bug for that and self-assign
[Bug other/12300] gcc fails looking for "home frameworks" under MacOS X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12300 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Andrew Pinski from comment #1) > FSF's gcc does not have Framework support yet. Report this to Apple. So... Apple eventually contributed this back to FSF gcc, right? For historical purposes, any idea when that happened?
[Bug bootstrap/44252] fixincludes fork vs. vms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44252 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Jay from comment #1) > Created attachment 20729 [details] > trivial two line untested patch Hi, if this patch still applies and works, please send it to the gcc-patches mailing list for review.
[Bug preprocessor/51776] fixincludes hacks around a C++ deficiency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51776 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to Bruce Korb from comment #0) > CF: bug #51705 comment #25 (In reply to Andreas Tobler from comment #1) > PR bootstrap/57105 OK so there are two similar-looking bug numbers here; I'm assuming the first one is the correct one, and the second was a typo?
[Bug target/90835] Incompatibilities with macOS 10.15 headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835 Eric Gallager changed: What|Removed |Added Status|WAITING |NEW --- Comment #29 from Eric Gallager --- (In reply to Eric Gallager from comment #28) > (I recently got a new laptop and am now on Catalina and ran into this bug, > so that's why I'm coming back to it) (Thus, moving from WAITING to NEW)
[Bug target/105719] New: RFE: fixincludes should handle Frameworks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105719
Bug ID: 105719
Summary: RFE: fixincludes should handle Frameworks
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: egallager at gcc dot gnu.org
CC: bkorb at gnu dot org
Target Milestone: ---
Target: *-*-darwin
This is split off from bug 93082. Basically, if there is a header that needs to
be fixincluded in /Systems/Library/Frameworks or /Library/Frameworks or
${SDKROOT}/Library/Frameworks, fixincludes currently won't find it. This should
be fixed by adding another include tree (or trees) for fixincludes to search.
[Bug target/105719] RFE: fixincludes should handle Frameworks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105719 Eric Gallager changed: What|Removed |Added Last reconfirmed||2022-05-24 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- Mine.
[Bug target/105719] RFE: fixincludes should handle Frameworks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105719 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=37036 --- Comment #2 from Eric Gallager --- Related: bug 37036
[Bug bootstrap/102665] ELF-specific configure flags should be rejected on non-ELF platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102665 Eric Gallager changed: What|Removed |Added Last reconfirmed||2022-05-24 Assignee|unassigned at gcc dot gnu.org |egallager at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #3 from Eric Gallager --- Mine.
[Bug target/18469] configure incorrectly defines gid_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18469 Eric Gallager changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #7 from Eric Gallager --- (In reply to Jonathan Wakely from comment #6) > The sparc-sun-solaris2.8 target is no logner supported. Is this an issue on > supported versions of Solaris? Hm, no reply, so, I'm guessing it isn't, and thus closing this.
[Bug bootstrap/44425] configure should probe prefix for gmp/mpfr/mpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44425 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- Mine.
[Bug libstdc++/21549] Configure options are poorly documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21549 Eric Gallager changed: What|Removed |Added Summary|Configure options hard to |Configure options are |find|poorly documented --- Comment #8 from Eric Gallager --- retitling
[Bug target/90835] Incompatibilities with macOS 10.15 headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835 --- Comment #30 from Iain Sandoe --- (In reply to Eric Gallager from comment #29) > (In reply to Eric Gallager from comment #28) > > (I recently got a new laptop and am now on Catalina and ran into this bug, > > so that's why I'm coming back to it) > > (Thus, moving from WAITING to NEW) perhaps you'd like to draft a documentation change? (I'm happy to review, but extremely short of darwin-time right now, so addressing backports and fixes as a priority).
[Bug other/58312] libssp configure check for "usable vsnprintf" is broken on cross-compilers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58312 Eric Gallager changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |egallager at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-05-24 --- Comment #7 from Eric Gallager --- (In reply to Brooks Moses from comment #6) > (In reply to Eric Gallager from comment #5) > > Is that patch still relevant? > > The relevant part of the libssp configure.ac hasn't changed much (if at all) > since I posted the patch, so I think it's still worth applying just on basic > of general correctness and avoiding unnecessary runtime checks in configure > files for things that may be cross-compiled. > OK, I'll try taking it, then.
[Bug other/82383] Some new toplevel directories are not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82383 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED Keywords||easyhack Assignee|unassigned at gcc dot gnu.org |egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- (In reply to Eric Gallager from comment #4) > (In reply to Eric Gallager from comment #1) > > Confirmed, they should be listed here: > > https://gcc.gnu.org/onlinedocs/gccint/Top-Level.html#Top-Level > > but they're not. > > That page is generated from sourcebuild.texi, for reference. I'll try adding a few sentences to it.
[Bug bootstrap/43301] top-level configure script ignores ---with-build-time-tools
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43301 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- (In reply to Eric Gallager from comment #3) > Patches go to the gcc-patches mailing list if you still want to see this > fixed Actually I guess I can try taking it myself
[Bug target/101891] Adjust -fzero-call-used-regs to always use XOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Qing Zhao : https://gcc.gnu.org/g:79ae75cc252154cf4ad75d28c3c909ff90f0cc76 commit r12-8413-g79ae75cc252154cf4ad75d28c3c909ff90f0cc76 Author: Qing Zhao Date: Tue May 24 15:03:40 2022 + i386: Adjust -fzero-call-used-regs to always use XOR [PR101891] Currently on i386, -fzero-call-used-regs uses a pattern of: XOR regA,regA MOV regA,regB MOV regA,regC ... RET However, this introduces both a register ordering dependency (e.g. the CPU cannot clear regB without clearing regA first), and while greatly reduces available ROP gadgets, it does technically leave a set of "MOV" ROP gadgets at the end of functions (e.g. "MOV regA,regC; RET"). This patch will switch to always use XOR on i386: XOR regA,regA XOR regB,regB XOR regC,regC ... RET gcc/ChangeLog: PR target/101891 * config/i386/i386.cc (zero_call_used_regno_mode): use V2SImode as a generic MMX mode instead of V4HImode. (zero_all_mm_registers): Use SET to zero instead of MOV for zeroing scratch registers. (ix86_zero_call_used_regs): Likewise. gcc/testsuite/ChangeLog: * gcc.target/i386/zero-scratch-regs-1.c: Add -fno-stack-protector -fno-PIC. * gcc.target/i386/zero-scratch-regs-10.c: Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-13.c: Add -msse. * gcc.target/i386/zero-scratch-regs-14.c: Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-15.c: Add -fno-stack-protector -fno-PIC. * gcc.target/i386/zero-scratch-regs-16.c: Likewise. * gcc.target/i386/zero-scratch-regs-17.c: Likewise. * gcc.target/i386/zero-scratch-regs-18.c: Add -fno-stack-protector -fno-PIC, adjust mov to xor. * gcc.target/i386/zero-scratch-regs-19.c: Add -fno-stack-protector -fno-PIC. * gcc.target/i386/zero-scratch-regs-2.c: Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-20.c: Add -msse. * gcc.target/i386/zero-scratch-regs-21.c: Add -fno-stack-protector -fno-PIC, Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-22.c: Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-23.c: Likewise. * gcc.target/i386/zero-scratch-regs-26.c: Likewise. * gcc.target/i386/zero-scratch-regs-27.c: Likewise. * gcc.target/i386/zero-scratch-regs-28.c: Likewise. * gcc.target/i386/zero-scratch-regs-3.c: Add -fno-stack-protector. * gcc.target/i386/zero-scratch-regs-31.c: Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-4.c: Add -fno-stack-protector -fno-PIC. * gcc.target/i386/zero-scratch-regs-5.c: Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-6.c: Add -fno-stack-protector. * gcc.target/i386/zero-scratch-regs-7.c: Likewise. * gcc.target/i386/zero-scratch-regs-8.c: Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-9.c: Add -fno-stack-protector. (cherry picked from commit 0b86943aca51175968e40bbb6f2662dfe3fbfe59)
[Bug target/80782] Configure options to use llvm/clang assembler on Mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80782 --- Comment #15 from Eric Gallager --- (In reply to Iain Sandoe from comment #12) > please could you be more specific about exactly what's not working? > - i.e if you're on an older version of the OS. > - version of Xcode. So I'm assuming that this is the part that this is still in WAITING for?
[Bug target/34422] Bootstrap error with --enable-fixed-point (configure should reject --enable-fixed-point on platforms that don't support it)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34422 Eric Gallager changed: What|Removed |Added Summary|Bootstrap error with|Bootstrap error with |--enable-fixed-point|--enable-fixed-point ||(configure should reject ||--enable-fixed-point on ||platforms that don't ||support it) Assignee|unassigned at gcc dot gnu.org |egallager at gcc dot gnu.org --- Comment #8 from Eric Gallager --- (In reply to Eric Gallager from comment #6) > (In reply to Andrew Pinski from comment #5) > > fixed point support is only currently supported for the MIPS target. > > So could the configure script error out earlier, then, if it is passed > --enable-fixed-point for a target other than MIPS? I'm going to re-title and self-assign on that basis.
[Bug libobjc/48626] --enable-objc-gc should be automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626 Eric Gallager changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #4 from Eric Gallager --- (In reply to Eric Gallager from comment #3) > I'll probably keep --enable-objc-gc in my configure flags anyways even if it > becomes automatic, but becoming automatic could help increase test coverage > of it. I guess I'll confirm this. Note that Iain Sandoe generally prefers configure detecting things automatically instead of requiring additional flags; I'm not quite sure how to go about making this one automatic now that boehm-gc is no longer in-tree, though.
[Bug target/90835] Incompatibilities with macOS 10.15 headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |egallager at gcc dot gnu.org --- Comment #31 from Eric Gallager --- (In reply to Iain Sandoe from comment #30) > (In reply to Eric Gallager from comment #29) > > (In reply to Eric Gallager from comment #28) > > > (I recently got a new laptop and am now on Catalina and ran into this bug, > > > so that's why I'm coming back to it) > > > > (Thus, moving from WAITING to NEW) > > perhaps you'd like to draft a documentation change? For install.texi? Sure; taking.
[Bug target/93082] macOS Authorization.h needs fixinclude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082 --- Comment #13 from Eric Gallager --- (In reply to Eric Gallager from comment #12) > OK I'll open a separate bug for that and self-assign (that's bug 105719 now, for reference)
[Bug target/34422] Bootstrap error with --enable-fixed-point (configure should reject --enable-fixed-point on platforms that don't support it)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34422 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug libstdc++/105720] New: std::views::split_view wrong behaviour in case of partial match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105720
Bug ID: 105720
Summary: std::views::split_view wrong behaviour in case of
partial match
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: andij.cr at gmail dot com
Target Milestone: ---
compiled with
g++-10 -std=c++20 split_view_wrong.cpp -lfmt
godbolt link https://gcc.godbolt.org/z/47TxWovd4
fmtlib used for exposition only
#include
#include
#include
#include
auto words_no_bug = std::string_view{"Hello-_-C++-_-20-_-!-_-"};
auto words_bug = std::string_view{"Hello--_-C++-_-20-_-!-_-"};
auto delim = std::string_view{"-_-"};
// needed because split_view is lazy in gcc 10.3
auto range_to_str = [](auto &&r) {
return fmt::format("{}", fmt::join(r, ""));
};
int main() {
fmt::print("no bug: '{}' tokens: {}\n", words_no_bug,
words_no_bug | std::views::split(delim) |
std::views::transform(range_to_str));
fmt::print("bug: '{}' tokens: {}\n", words_bug,
words_bug | std::views::split(delim) |
std::views::transform(range_to_str));
}
this code applies split to tokenize a text
compiled with gcc-10.3 it wrongly produces
no bug: 'Hello-_-C++-_-20-_-!-_-' tokens: ["Hello", "C++", "20", "!"]
bug: 'Hello--_-C++-_-20-_-!-_-' tokens: ["Hello-", "20", "!"]
while compiled with gcc-11.3 is correctly produces
no bug: 'Hello-_-C++-_-20-_-!-_-' tokens: ["Hello", "C++", "20", "!"]
bug: 'Hello--_-C++-_-20-_-!-_-' tokens: ["Hello-", "C++", "20", "!"]
notice how the substring "--_-C++" instead of being split in ["-", "C++"]
is split as ["-"], skipping the "C++" token.
it's fixed from gcc-11, but i couldn't find a mention in the release notes
about it
[Bug target/80782] Configure options to use llvm/clang assembler on Mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80782 --- Comment #16 from Iain Sandoe --- (In reply to Eric Gallager from comment #15) > (In reply to Iain Sandoe from comment #12) > > please could you be more specific about exactly what's not working? > > - i.e if you're on an older version of the OS. > > - version of Xcode. > > So I'm assuming that this is the part that this is still in WAITING for? I guess so... cctools 'as' already automatically calls 'clang -cc1as' where the system supports it and GCC's configuration process detects that this is in force (where it matters to assembler options). ... so we are already using this on the platform versions for which Apple defaults to using the LLVM back end (i.e. clang -cc1as) for the assembler. For some versions of Xcode (before this became the default) it would be possible modify the configure to add the '-q' flag to force the use of 'clang -cc1as' instead of the GAS-1.38 based assembler - however, at that point we would clearly be making it possible to generate instructions that the OS toolchain was not expecting, so not sure of how useful it would be. from the original description: > As a result, GCC generates code that fails to assemble when using > optimisation for >any CPU that has support for AVX or newer intrinsics. A > pity and often annoying >because the failure can happen only late during a > build process. We should not be trying to generate such instructions on systems that do not support them - so this implies some different issue is in play.
[Bug libobjc/48626] --enable-objc-gc should be automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626 --- Comment #5 from Iain Sandoe --- (In reply to Eric Gallager from comment #4) > (In reply to Eric Gallager from comment #3) > > I'll probably keep --enable-objc-gc in my configure flags anyways even if it > > becomes automatic, but becoming automatic could help increase test coverage > > of it. I guess I'll confirm this. > > Note that Iain Sandoe generally prefers configure detecting things > automatically instead of requiring additional flags; I'm not quite sure how > to go about making this one automatic now that boehm-gc is no longer > in-tree, though. this seems to be another set of crossed wires. Darwin only ever used boehm-gc for Java, not for NeXT ObjC the configure option is related to GC for the GNU runtime. In that case, the configuration should work the same as it does for Linux. === The NeXT GC support (if it was implemented, which it isn't) on Darwin uses system-provided libraries (libauto.dylib). Objective-C GC was retired sometime around darwin16, so the motivation is low to put effort into implementing it ahead of more critical missing pieces.
[Bug target/101891] Adjust -fzero-call-used-regs to always use XOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Qing Zhao : https://gcc.gnu.org/g:c8d636cbe38b6a369528f58227c96b2b77b1fd3a commit r11-10029-gc8d636cbe38b6a369528f58227c96b2b77b1fd3a Author: Qing Zhao Date: Tue May 24 15:54:06 2022 + i386: Adjust -fzero-call-used-regs to always use XOR [PR101891] Currently on i386, -fzero-call-used-regs uses a pattern of: XOR regA,regA MOV regA,regB MOV regA,regC ... RET However, this introduces both a register ordering dependency (e.g. the CPU cannot clear regB without clearing regA first), and while greatly reduces available ROP gadgets, it does technically leave a set of "MOV" ROP gadgets at the end of functions (e.g. "MOV regA,regC; RET"). This patch will switch to always use XOR on i386: XOR regA,regA XOR regB,regB XOR regC,regC ... RET gcc/ChangeLog: PR target/101891 * config/i386/i386.c (zero_call_used_regno_mode): use V2SImode as a generic MMX mode instead of V4HImode. (zero_all_mm_registers): Use SET to zero instead of MOV for zeroing scratch registers. (ix86_zero_call_used_regs): Likewise. gcc/testsuite/ChangeLog: * gcc.target/i386/zero-scratch-regs-1.c: Add -fno-stack-protector -fno-PIC. * gcc.target/i386/zero-scratch-regs-10.c: Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-13.c: Add -msse. * gcc.target/i386/zero-scratch-regs-14.c: Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-15.c: Add -fno-stack-protector -fno-PIC. * gcc.target/i386/zero-scratch-regs-16.c: Likewise. * gcc.target/i386/zero-scratch-regs-17.c: Likewise. * gcc.target/i386/zero-scratch-regs-18.c: Add -fno-stack-protector -fno-PIC, adjust mov to xor. * gcc.target/i386/zero-scratch-regs-19.c: Add -fno-stack-protector -fno-PIC. * gcc.target/i386/zero-scratch-regs-2.c: Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-20.c: Add -msse. * gcc.target/i386/zero-scratch-regs-21.c: Add -fno-stack-protector -fno-PIC, Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-22.c: Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-23.c: Likewise. * gcc.target/i386/zero-scratch-regs-26.c: Likewise. * gcc.target/i386/zero-scratch-regs-27.c: Likewise. * gcc.target/i386/zero-scratch-regs-28.c: Likewise. * gcc.target/i386/zero-scratch-regs-3.c: Add -fno-stack-protector. * gcc.target/i386/zero-scratch-regs-31.c: Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-4.c: Add -fno-stack-protector -fno-PIC. * gcc.target/i386/zero-scratch-regs-5.c: Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-6.c: Add -fno-stack-protector. * gcc.target/i386/zero-scratch-regs-7.c: Likewise. * gcc.target/i386/zero-scratch-regs-8.c: Adjust mov to xor. * gcc.target/i386/zero-scratch-regs-9.c: Add -fno-stack-protector. (cherry picked from commit 0b86943aca51175968e40bbb6f2662dfe3fbfe59)
[Bug target/101891] Adjust -fzero-call-used-regs to always use XOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891 qinzhao at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from qinzhao at gcc dot gnu.org --- fixed in gcc11 and gcc12 too.
[Bug target/104816] -fcf-protection=branch should generate endbr instead of notrack jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104816 --- Comment #11 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:2f4f7de787e5844515d27b2269fc472f95a9916a commit r13-744-g2f4f7de787e5844515d27b2269fc472f95a9916a Author: H.J. Lu Date: Fri Mar 11 12:51:34 2022 -0800 x86: Document -mcet-switch When -fcf-protection=branch is used, the compiler will generate jump tables for switch statements where the indirect jump is prefixed with the NOTRACK prefix, so it can jump to non-ENDBR targets. Since the indirect jump targets are generated by the compiler and stored in read-only memory, this does not result in a direct loss of hardening. But if the jump table index is attacker-controlled, the indirect jump may not be constrained by CET. Document -mcet-switch to generate jump tables for switch statements with ENDBR and skip the NOTRACK prefix for indirect jump. This option should be used when the NOTRACK prefix is disabled. PR target/104816 * config/i386/i386.opt: Remove Undocumented. * doc/invoke.texi: Document -mcet-switch.
[Bug target/105666] RISC-V 507.cactuBSSN_r build has costly FMV instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105666 Vineet Gupta changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Vineet Gupta --- Commited by Kito. commit b646d7d279ae0c0d35564542d09866bf3e8afac0 Author: Vineet Gupta Date: Mon May 23 11:12:09 2022 -0700 RISC-V: Inhibit FP <--> int register moves via tune param Under extreme register pressure, compiler can use FP <--> int moves as a cheap alternate to spilling to memory. This was seen with SPEC2017 FP benchmark 507.cactu: ML_BSSN_Advect.cc:ML_BSSN_Advect_Body()
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 105666, which changed state. Bug 105666 Summary: RISC-V 507.cactuBSSN_r build has costly FMV instructions https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105666 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug bootstrap/102665] ELF-specific configure flags should be rejected on non-ELF platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102665 --- Comment #4 from Eric Gallager --- Hm, looking in gcc/configure.ac (where these are defined), it looks like there's a bunch of other flags that this bug could apply to, too...
[Bug bootstrap/44425] configure should probe prefix for gmp/mpfr/mpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44425 --- Comment #3 from Eric Gallager --- This would be done in the top-level configure script... where it looks like it already does this for FreeBSD targets?
[Bug bootstrap/102665] ELF-specific configure flags should be rejected on non-ELF platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102665 --- Comment #5 from Iain Sandoe --- (In reply to Eric Gallager from comment #4) > Hm, looking in gcc/configure.ac (where these are defined), it looks like > there's a bunch of other flags that this bug could apply to, too... Note that I would try to clarify: It is my understanding that the purpose of configure is to isolate the end user from having to know about all the nasty little nooks and crannies of their target. As such it is not a "maintainer preference" to avoid end user having to manipulate many such options but, rather, that if we reach that situation, then the configure script is not doing its job and needs work. As far as I understand things the right behaviour of configure is to choose a correct default value for each option based on the target. The way that the options work it is usually possible to ignore one for a specific target if it does not apply at all. Therefore: 1. making sure defaults are correct is valuable 2. perhaps just ignoring ELF-specific options (for Darwin)is useful (you could, even diagnose that the option has been ignored if the user attempts to set it). 3. As you have noted, there are quite likely more options that could/should/maybe already are ignored for Darwin.
[Bug libbacktrace/105721] New: libbacktrace: update README
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105721 Bug ID: 105721 Summary: libbacktrace: update README Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: documentation, easyhack Severity: trivial Priority: P3 Component: libbacktrace Assignee: unassigned at gcc dot gnu.org Reporter: egallager at gcc dot gnu.org CC: ian at gcc dot gnu.org Target Milestone: --- libbacktrace/README says: "As of September 2012, libbacktrace only supports ELF executables with DWARF debugging information." While that may have been true as of September 2012, it is no longer true now; I'm pretty sure it's been updated to support more formats (mach-o for one). That sentence should be updated to a more recent "as of" along with a more current list of formats supported.
[Bug target/101891] Adjust -fzero-call-used-regs to always use XOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891 Arjan van de Ven changed: What|Removed |Added CC||arjan at linux dot intel.com --- Comment #7 from Arjan van de Ven --- from a performance angle, the xor-only sequence is not so great at all; modern CPUs are really good at eliminating mov's so that's why the code originally was added to do a combo of xor and mov.. I can understand the security versus performance tradeoff. (the original tuning was done to basically make it entirely free, so that it could just be always enabled)
[Bug libstdc++/105720] std::views::split_view wrong behaviour in case of partial match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105720 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org Target Milestone|--- |10.4 --- Comment #1 from Patrick Palka --- I think you're running into the LWG issue https://wg21.link/lwg3505 which has been adopted as a defect report against C++20, and implemented for libstdc++ 10.4 (not yet released) and 11+ (as you've noticed). It's been backported to the 10 release branch as r10-9740-g4c17b2bbbc1bef on April 20, 2021, so any snapshot of libstdc++ 10 after that date should behave correctly.
[Bug c++/105718] Forward Declarations of Constrained Partially Specialized Class Templates Rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105718 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Patrick Palka --- Thanks for the bug report. I think this (and PR99501) is ultimately a duplicate of the earlier PR96363. *** This bug has been marked as a duplicate of bug 96363 ***
[Bug c++/96363] bogus error with constrained partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96363 Patrick Palka changed: What|Removed |Added CC||mate.kelemen.12 at gmail dot com --- Comment #2 from Patrick Palka --- *** Bug 105718 has been marked as a duplicate of this bug. ***
[Bug c++/99501] Can't forward declare partial specialization of template with NTTP previously partially specialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99501 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Patrick Palka --- dup *** This bug has been marked as a duplicate of bug 96363 ***
[Bug c++/96363] bogus error with constrained partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96363 Patrick Palka changed: What|Removed |Added CC||johelegp at gmail dot com --- Comment #3 from Patrick Palka --- *** Bug 99501 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/104964] Wrong *** buffer overflow detected ***: terminated - acl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964 --- Comment #18 from Sam James --- Thanks. I reported the Qt issue upstream at https://bugreports.qt.io/browse/QTBUG-103782. I've hit the ACL issue independently in Gentoo and will forward that upstream too (https://bugs.gentoo.org/847280).
