[Bug c++/91415] Invalid warning for C++17 sequencing of shift operator E1<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91415 Nicolai Josuttis changed: What|Removed |Added CC||nico at josuttis dot de --- Comment #11 from Nicolai Josuttis --- int j = i++ << i++; is still not handled correctly in 9.3, 10.1, and 11.0.
[Bug tree-optimization/98133] [11 Regression] ICE in vectorizable_conversion, at tree-vect-stmts.c:4690
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98133 Richard Biener changed: What|Removed |Added Summary|ICE in |[11 Regression] ICE in |vectorizable_conversion, at |vectorizable_conversion, at |tree-vect-stmts.c:4690 |tree-vect-stmts.c:4690 Priority|P3 |P1 Target Milestone|--- |11.0
[Bug tree-optimization/98133] ICE in vectorizable_conversion, at tree-vect-stmts.c:4690
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98133
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC||joel.hutton at arm dot com
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #2 from Richard Biener ---
#5 0x019c9eeb in vectorizable_conversion (vinfo=0x3985f80,
stmt_info=0x39c0f70, gsi=0x0, vec_stmt=0x0, slp_node=0x0,
cost_vec=0x7fffc4f8) at ../../src/trunk/gcc/tree-vect-stmts.c:4686
4686ncopies = vect_get_num_copies (loop_vinfo, vectype_in);
(gdb) p debug_generic_expr (vectype_in)
vector(8) short int
$1 = void
(gdb) p loop_vinfo->vectorization_factor
$2 = {> = {coeffs = {4, 0}}, }
that can't work.
(gdb) p debug_gimple_stmt (stmt_info->stmt)
patt_10 = (a_15(D)) <<< ??? >>> (-30574);
the TREE_CODE of this is WIDEN_PLUS_EXPR (we seem to miss an entry for
tree_code_name and pretty-printing for this ... so much for using new
tree-codes).
vectorizable_conversion has
code = gimple_assign_rhs_code (stmt);
if (!CONVERT_EXPR_CODE_P (code)
&& code != FIX_TRUNC_EXPR
&& code != FLOAT_EXPR
&& code != WIDEN_PLUS_EXPR
&& code != WIDEN_MINUS_EXPR
&& code != WIDEN_MULT_EXPR
&& code != WIDEN_LSHIFT_EXPR)
return false;
so it's supposed to handle this case. I think the special-case is that
the whole stmt is invariant and thus not participating in determining
the vectorization factor (all ops are invariant). So we're running into
/* If op0 is an external or constant def, infer the vector type
from the scalar type. */
if (!vectype_in)
vectype_in = get_vectype_for_scalar_type (vinfo, rhs_type, slp_node);
now we should always be able to use vectype_out for determining ncopies,
we just have to correctly interpret it for WIDEN/NARROW or adjust it.
Leaving to arm folks to resolve.
[Bug target/98124] Z: Load and test LTDBR instruction gets not used for comparison against 0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98124 --- Comment #2 from Andreas Krebbel --- (In reply to Andreas Krebbel from comment #1) > LTDBR turns SNaNs into QNaNs and that's not supposed to happen in your > testcase. We emit LTDBR only with -fno-trapping-math ... or if the result of LTDBR isn't used.
[Bug target/98124] Z: Load and test LTDBR instruction gets not used for comparison against 0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98124 Andreas Krebbel changed: What|Removed |Added CC||krebbel at gcc dot gnu.org Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andreas Krebbel --- LTDBR turns SNaNs into QNaNs and that's not supposed to happen in your testcase. We emit LTDBR only with -fno-trapping-math
[Bug tree-optimization/98133] ICE in vectorizable_conversion, at tree-vect-stmts.c:4690
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98133 Richard Biener changed: What|Removed |Added Last reconfirmed||2020-12-04 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I will have a look.
[Bug c++/98130] [11 regression] placement new fails on webkit-gtk-2.28.4 since r11-4745-g58c9de46541ade79
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130
--- Comment #2 from Richard Biener ---
Confirmed. The issue is that placement new is _not_ __attribute__((malloc)),
it makes PTA consider the object not escaping and then we have DSE do
;; Function append (_ZL6appendPi, funcdef_no=1, decl_uid=2355, cgraph_uid=2,
symbol_order=3)
Deleted dead store: MEM[(int * *)_4] = value_5(D);
__attribute__((always_inline))
void append (int * value)
{
void * _2;
void * _4;
:
_2 = p;
_4 = operator new (8, _2);
return;
}
[Bug testsuite/98125] [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125 Richard Biener changed: What|Removed |Added Summary|New test case |[11 Regression] New test |g++.dg/pr93195a.C in|case g++.dg/pr93195a.C in |r11-5656 has excess errors |r11-5656 has excess errors Target Milestone|--- |11.0 --- Comment #6 from Richard Biener --- dg-skip-if I suppose
[Bug c++/80780] Front-end support needed for experimental::source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80780 --- Comment #13 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9715663f7db7ac57121c9a60dd0078787e274f66 commit r11-5736-g9715663f7db7ac57121c9a60dd0078787e274f66 Author: Jakub Jelinek Date: Fri Dec 4 08:08:39 2020 +0100 c++: Change __builtin_source_location to use __PRETTY_FUNCTION__ instead of __FUNCTION__ [PR80780] On Tue, Dec 01, 2020 at 01:03:52PM +, Jonathan Wakely via Gcc-patches wrote: > I mentioned in PR 80780 that a __builtin__PRETTY_FUNCTION would have > been nice, because __FUNCTION__ isn't very useful for C++, because of > overloading and namespace/class scopes. There are an unlimited number > of functions that have __FUNCTION__ == "s", e.g. "ns::s(int)" and > "ns::s()" and "another_scope::s::s(T...)" etc. > > Since __builtin_source_location() can do whatever it wants (without > needing to add __builtin__PRETTY_FUNCTION) it might be nice to use the > __PRETTY_FUNCTION__ string. JeanHeyd's tests would still need changes, > because the name would be "s::s(void*)" not "s::s" but that still > seems better for users. When I've added template tests for the previous patch, I have noticed that the current __builtin_source_location behavior is not really __FUNCTION__, just close, because e.g. in function template __FUNCTION__ is still "bar" but __builtin_source_location gave "bar<0>". Anyway, this patch implements above request to follow __PRETTY_FUNCTION__ (on top of the earlier posted patch). 2020-12-04 Jakub Jelinek PR c++/80780 * cp-gimplify.c (fold_builtin_source_location): Use 2 instead of 0 as last argument to cxx_printable_name. * g++.dg/cpp2a/srcloc1.C (quux): Use __PRETTY_FUNCTION__ instead of function. * g++.dg/cpp2a/srcloc2.C (quux): Likewise. * g++.dg/cpp2a/srcloc15.C (S::S): Likewise. (bar): Likewise. Adjust expected column. * g++.dg/cpp2a/srcloc17.C (S::S): Likewise. (bar): Likewise. Adjust expected column. * testsuite/18_support/source_location/1.cc (main): Adjust for __builtin_source_location using __PRETTY_FUNCTION__-like names instead __FUNCTION__-like. * testsuite/18_support/source_location/consteval.cc (main): Likewise.
[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461 --- Comment #24 from Martin Liška --- @Honza: PING
[Bug tree-optimization/98123] if-to-switch tests fail on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98123 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #3 from Martin Liška --- Should be really fixed, please reopen if not.
[Bug c/98132] ‘target_mem_ref’ not supported by expression internal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98132 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |WAITING Last reconfirmed||2020-12-04 --- Comment #1 from Martin Liška --- Can't reproduce that. Moreover, GCC 6.4.0 is out of support, can you please test the lastest GCC release (10.x)?
[Bug c++/98130] [11 regression] placement new fails on webkit-gtk-2.28.4 since r11-4745-g58c9de46541ade79
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Summary|[11 regression] placement |[11 regression] placement |new fails on|new fails on |webkit-gtk-2.28.4 |webkit-gtk-2.28.4 since ||r11-4745-g58c9de46541ade79 Target Milestone|--- |11.0 CC||hubicka at gcc dot gnu.org, ||marxin at gcc dot gnu.org Keywords||wrong-code Status|UNCONFIRMED |NEW Priority|P3 |P1 Last reconfirmed||2020-12-04 --- Comment #1 from Martin Liška --- Started with r11-4745-g58c9de46541ade79, -fno-strict-aliasing is not needed.
[Bug testsuite/98125] New test case g++.dg/pr93195a.C in r11-5656 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125 Alan Modra changed: What|Removed |Added Status|WAITING |NEW --- Comment #5 from Alan Modra --- The default implementation of -fpatchable-function-entry is broken and useless on powerpc64 ELFv1 and ELFv2. For ELFv1 we get .section".opd","aw" .align 3 _Z3foov: .quad .L._Z3foov,.TOC.@tocbase,0 .previous .type _Z3foov, @function .L._Z3foov: .section__patchable_function_entries,"awo",@progbits,_Z3foov .align 3 .8byte .LPFE1 .section.text._Z3foov,"axG",@progbits,_Z3foov,comdat .LPFE1: nop So the "o" flag symbol is one in the .opd section, rather than what would be correct here, .L._Z3foov. The implementation is even more useless for ELFv2, with the nop appearing in the global entry code (so providing patch space for only some calls of the function), which results in assembler complaints about ".localentry expression is not a power of 2". I don't think there is anything wrong with the new testcase, just a lack of xfail powerpc64*-*-*.
[Bug tree-optimization/98133] New: ICE in vectorizable_conversion, at tree-vect-stmts.c:4690
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98133
Bug ID: 98133
Summary: ICE in vectorizable_conversion, at
tree-vect-stmts.c:4690
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org, rsandifo at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux
Target: aarch64-linux-gnu
The following fails:
$ g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/vect/pr96022.cc -Ofast
--param=max-completely-peeled-insns=0 -fno-tree-loop-im -fno-tree-pre -c
during GIMPLE pass: vect
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/vect/pr96022.cc: In function
‘void test(short int, bool, int)’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/vect/pr96022.cc:6:6: internal
compiler error: in vectorizable_conversion, at tree-vect-stmts.c:4690
6 | void test(short a, bool, int p8) {
| ^~~~
0x6a2afb vectorizable_conversion
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-vect-stmts.c:4690
0xf08773 vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*,
_slp_instance*, vec*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-vect-stmts.c:10694
0xf23c08 vect_analyze_loop_operations
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-vect-loop.c:1758
0xf23c08 vect_analyze_loop_2
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-vect-loop.c:2478
0xf23c08 vect_analyze_loop(loop*, vec_info_shared*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-vect-loop.c:2925
0xf48321 try_vectorize_loop_1
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-vectorizer.c:995
0xf48d19 vectorize_loops()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-vectorizer.c:1229
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #35 from abebeos at lazaridis dot com --- (In reply to abebeos from comment #11) > (In reply to John Paul Adrian Glaubitz from comment #10) > [...] > > The main problem is apparently that the target hasn't been properly worked > > on for a long time. > [...] > > Yes, this seems to result in this barrier: > > => missing stable development environment for the work on the avr backend > itself (build/test/simulate). > > So this issue here splits into 3 major steps: > > A) create a stable dev environment fro work on the avr backend [...] See https://github.com/abebeos/avr-gnu, should work as described. My tests show: => pipcet's aborted non-cc0 backend results in 4 issues. => saaadhu's "shelved" non-cc0 backend results in 0 issues. Tests should be easily reproducible. We can "talk business" now, i don't need to focus anymore.
[Bug other/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121 H.J. Lu changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-Decembe ||r/561075.html --- Comment #10 from H.J. Lu --- A patch set is posted at https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561075.html
[Bug c/98132] New: ‘target_mem_ref’ not supported by expression internal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98132
Bug ID: 98132
Summary: ‘target_mem_ref’ not supported by expression internal
error
Product: gcc
Version: 6.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: thutt at vmware dot com
Target Milestone: ---
#if 0
The program below, compiled with:
x86_64-vmk-linux-gnu-gcc (GCC) 6.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
fails with the following internal gcc error and an incorrect warning:
#‘target_mem_ref’ not supported by expression#’./main.c: In function ‘main’:
./main.c:15:12: warning: is used uninitialized in this function
[-Wuninitialized]
return (*(uint16*)[i] >> i) & 0x1ff;
^~~
./main.c:19:1: note: ‘ote’ was declared here
f1(t0_t ote)
^~
The compiler used was built in-house.
The command line is:
CC=
${CC} \
-nostdinc \
-O2 \
-Wuninitialized \
-o ./main.o \
-c ./main.c
#endif
typedef unsigned char uint8;
typedef unsigned short int uint16;
typedef struct t0_t {
uint8 field[5];
} t0_t;
extern t0_t ote;
static unsigned
f0(t0_t ote, unsigned i)
{
return (*(uint16*)[i] >> i) & 0x1ff;
}
static unsigned
f1(t0_t ote)
{
int i;
for (i = 0; i < 4; i++) {
unsigned j = f0(ote, i);
if (j == 1) {
return 1;
}
}
return 0;
}
int
main(int argc, char **argv)
{
return f1(ote);
}
[Bug tree-optimization/98131] new test case g++.dg/cpp2a/concepts-nodiscard1.C in r11-5719 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98131 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Jason Merrill --- Added XFAIL for now.
[Bug c++/57111] Generalize -Wfree-nonheap-object to delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57111 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #13 from Martin Sebor --- (In reply to Jonathan Wakely from comment #12) > (In reply to Martin Sebor from comment #11) > > It detects the bug in the test case in comment #0 but only with optimization > > (to see through inlined calls) and with -Wsystem-headers. > > This seems like a warning that should not be suppressed in system headers. > > Diagnostic pragmas could be added to system headers to suppress false > positives. I agree. I thought it was due to an omission on my part but after checking I see that the code does jump through all the necessary hoops to trigger even in system headers, so it's a bug that it doesn't.Let me see what's going on.
[Bug bootstrap/98128] [11 Regression] Bootstrap failed on 32-bit hosts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98128 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jason Merrill --- Fixed in r11-5733 (with the wrong PR in the comment).
[Bug c++/98019] Concepts: compound requirement expression from 'requires' expression is considered discarded-value expression for [[nodiscard]], false positive warning emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98019 Jason Merrill changed: What|Removed |Added Status|RESOLVED|ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Resolution|FIXED |--- Last reconfirmed||2020-12-03 --- Comment #4 from Jason Merrill --- Oops, not actually fixed yet, it was only working for me because of another WIP patch in my tree.
[Bug middle-end/87736] New attributes to mark custom alloc/free function pair
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87736 Bug 87736 depends on bug 87731, which changed state. Bug 87731 Summary: Detection of mismatched alloc/free pairs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87731 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/87731] Detection of mismatched alloc/free pairs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87731 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |11.0 Resolution|--- |FIXED --- Comment #8 from Martin Sebor --- Implemented for GCC 11 in r11-5732.
[Bug c++/87403] [Meta-bug] Issues that suggest a new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 87731, which changed state. Bug 87731 Summary: Detection of mismatched alloc/free pairs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87731 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/87736] New attributes to mark custom alloc/free function pair
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87736 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |11.0 --- Comment #5 from Martin Sebor --- Implemented GCC 11 in r11-5732.
[Bug c++/87403] [Meta-bug] Issues that suggest a new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 94527, which changed state. Bug 94527 Summary: RFE: Add an __attribute__ that marks a function as freeing an object https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94527 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/94527] RFE: Add an __attribute__ that marks a function as freeing an object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94527 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Martin Sebor --- Done for GCC 11.
[Bug c++/87403] [Meta-bug] Issues that suggest a new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 90629, which changed state. Bug 90629 Summary: Support for -Wmismatched-new-delete https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90629 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/90629] Support for -Wmismatched-new-delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90629 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |11.0 --- Comment #6 from Martin Sebor --- Done for GCC 11.
[Bug middle-end/94527] RFE: Add an __attribute__ that marks a function as freeing an object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94527 --- Comment #13 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:dce6c58db87ebf7f4477bd3126228e73e497 commit r11-5732-gdce6c58db87ebf7f4477bd3126228e73e497 Author: Martin Sebor Date: Thu Dec 3 15:41:25 2020 -0700 Add support for detecting mismatched allocation/deallocation calls. PR c++/90629 - Support for -Wmismatched-new-delete PR middle-end/94527 - Add an __attribute__ that marks a function as freeing an object gcc/ChangeLog: PR c++/90629 PR middle-end/94527 * builtins.c (access_ref::access_ref): Initialize new member. (compute_objsize): Use access_ref::deref. Handle simple pointer assignment. (expand_builtin): Remove handling of the free built-in. (call_dealloc_argno): Same. (find_assignment_location): New function. (fndecl_alloc_p): Same. (gimple_call_alloc_p): Same. (call_dealloc_p): Same. (matching_alloc_calls_p): Same. (warn_dealloc_offset): Same. (maybe_emit_free_warning): Same. * builtins.h (struct access_ref): Declare new member. (maybe_emit_free_warning): Make extern. Make use of access_ref. Handle -Wmismatched-new-delete. * calls.c (initialize_argument_information): Call maybe_emit_free_warning. * doc/extend.texi (attribute malloc): Update. * doc/invoke.texi (-Wfree-nonheap-object): Expand documentation. (-Wmismatched-new-delete): Document new option. (-Wmismatched-dealloc): Document new option. gcc/c-family/ChangeLog: PR c++/90629 PR middle-end/94527 * c-attribs.c (handle_dealloc_attribute): New function. (handle_malloc_attribute): Handle argument forms of attribute. * c.opt (-Wmismatched-dealloc): New option. (-Wmismatched-new-delete): New option. gcc/testsuite/ChangeLog: PR c++/90629 PR middle-end/94527 * g++.dg/asan/asan_test.cc: Fix a bug. * g++.dg/warn/delete-array-1.C: Add expected warning. * g++.old-deja/g++.other/delete2.C: Add expected warning. * g++.dg/warn/Wfree-nonheap-object-2.C: New test. * g++.dg/warn/Wfree-nonheap-object.C: New test. * g++.dg/warn/Wmismatched-new-delete.C: New test. * g++.dg/warn/Wmismatched-dealloc-2.C: New test. * g++.dg/warn/Wmismatched-dealloc.C: New test. * gcc.dg/Wmismatched-dealloc.c: New test. * gcc.dg/analyzer/malloc-1.c: Prune out expected warning. * gcc.dg/attr-malloc.c: New test. * gcc.dg/free-1.c: Adjust text of expected warning. * gcc.dg/free-2.c: Same. * gcc.dg/torture/pr71816.c: Prune out expected warning. * gcc.dg/tree-ssa/pr19831-2.c: Add an expected warning. * gcc.dg/Wfree-nonheap-object-2.c: New test. * gcc.dg/Wfree-nonheap-object-3.c: New test. * gcc.dg/Wfree-nonheap-object.c: New test. libstdc++-v3/ChangeLog: * testsuite/ext/vstring/modifiers/clear/56166.cc: Suppress a false positive warning.
[Bug c++/90629] Support for -Wmismatched-new-delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90629 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:dce6c58db87ebf7f4477bd3126228e73e497 commit r11-5732-gdce6c58db87ebf7f4477bd3126228e73e497 Author: Martin Sebor Date: Thu Dec 3 15:41:25 2020 -0700 Add support for detecting mismatched allocation/deallocation calls. PR c++/90629 - Support for -Wmismatched-new-delete PR middle-end/94527 - Add an __attribute__ that marks a function as freeing an object gcc/ChangeLog: PR c++/90629 PR middle-end/94527 * builtins.c (access_ref::access_ref): Initialize new member. (compute_objsize): Use access_ref::deref. Handle simple pointer assignment. (expand_builtin): Remove handling of the free built-in. (call_dealloc_argno): Same. (find_assignment_location): New function. (fndecl_alloc_p): Same. (gimple_call_alloc_p): Same. (call_dealloc_p): Same. (matching_alloc_calls_p): Same. (warn_dealloc_offset): Same. (maybe_emit_free_warning): Same. * builtins.h (struct access_ref): Declare new member. (maybe_emit_free_warning): Make extern. Make use of access_ref. Handle -Wmismatched-new-delete. * calls.c (initialize_argument_information): Call maybe_emit_free_warning. * doc/extend.texi (attribute malloc): Update. * doc/invoke.texi (-Wfree-nonheap-object): Expand documentation. (-Wmismatched-new-delete): Document new option. (-Wmismatched-dealloc): Document new option. gcc/c-family/ChangeLog: PR c++/90629 PR middle-end/94527 * c-attribs.c (handle_dealloc_attribute): New function. (handle_malloc_attribute): Handle argument forms of attribute. * c.opt (-Wmismatched-dealloc): New option. (-Wmismatched-new-delete): New option. gcc/testsuite/ChangeLog: PR c++/90629 PR middle-end/94527 * g++.dg/asan/asan_test.cc: Fix a bug. * g++.dg/warn/delete-array-1.C: Add expected warning. * g++.old-deja/g++.other/delete2.C: Add expected warning. * g++.dg/warn/Wfree-nonheap-object-2.C: New test. * g++.dg/warn/Wfree-nonheap-object.C: New test. * g++.dg/warn/Wmismatched-new-delete.C: New test. * g++.dg/warn/Wmismatched-dealloc-2.C: New test. * g++.dg/warn/Wmismatched-dealloc.C: New test. * gcc.dg/Wmismatched-dealloc.c: New test. * gcc.dg/analyzer/malloc-1.c: Prune out expected warning. * gcc.dg/attr-malloc.c: New test. * gcc.dg/free-1.c: Adjust text of expected warning. * gcc.dg/free-2.c: Same. * gcc.dg/torture/pr71816.c: Prune out expected warning. * gcc.dg/tree-ssa/pr19831-2.c: Add an expected warning. * gcc.dg/Wfree-nonheap-object-2.c: New test. * gcc.dg/Wfree-nonheap-object-3.c: New test. * gcc.dg/Wfree-nonheap-object.c: New test. libstdc++-v3/ChangeLog: * testsuite/ext/vstring/modifiers/clear/56166.cc: Suppress a false positive warning.
[Bug tree-optimization/96344] 3rdd case of gnat.dg/opt86a.adb fails because of VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96344 --- Comment #5 from Eric Botcazou --- > A fresh build of trunk on x86_64 shows the following Ada failures: > > ! FAIL: gnat.dg/opt86a.adb (1: +1) > ! FAIL: gnat.dg/opt86b.adb (1: +1) > ! FAIL: gnat.dg/opt86c.adb (1: +1) > > The logs show this: > > $ grep "FAIL: gnat.dg/opt86" gcc/testsuite/gnat/gnat.log > FAIL: gnat.dg/opt86a.adb scan-tree-dump-times optimized ">>" 4 > FAIL: gnat.dg/opt86b.adb scan-tree-dump-not optimized "> 29" > FAIL: gnat.dg/opt86c.adb scan-tree-dump-not optimized "> 26" Introduced on 12/01, probably by: 2020-12-01 Martin Liska PR tree-optimization/14799 PR ipa/88702 * Makefile.in: Add gimple-if-to-switch.o. * dbgcnt.def (DEBUG_COUNTER): Add new debug counter. * passes.def: Include new pass_if_to_switch pass. * timevar.def (TV_TREE_IF_TO_SWITCH): New timevar. * tree-pass.h (make_pass_if_to_switch): New. * tree-ssa-reassoc.c (struct operand_entry): Move to the header. (dump_range_entry): Move to header file. (debug_range_entry): Likewise. (no_side_effect_bb): Make it global. * tree-switch-conversion.h (simple_cluster::simple_cluster): Add inline for couple of functions in order to prevent error about multiple defined symbols. * gimple-if-to-switch.cc: New file. * tree-ssa-reassoc.h: New file.
[Bug tree-optimization/96344] 3rdd case of gnat.dg/opt86a.adb fails because of VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96344 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #4 from Martin Sebor --- Also seen on x86_64-linux. I was about to open a bug with this: A fresh build of trunk on x86_64 shows the following Ada failures: ! FAIL: gnat.dg/opt86a.adb (1: +1) ! FAIL: gnat.dg/opt86b.adb (1: +1) ! FAIL: gnat.dg/opt86c.adb (1: +1) The logs show this: $ grep "FAIL: gnat.dg/opt86" gcc/testsuite/gnat/gnat.log FAIL: gnat.dg/opt86a.adb scan-tree-dump-times optimized ">>" 4 FAIL: gnat.dg/opt86b.adb scan-tree-dump-not optimized "> 29" FAIL: gnat.dg/opt86c.adb scan-tree-dump-not optimized "> 26"
[Bug c++/98126] -Wsequence-point is non-linear for certain cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98126 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-12-03 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Marek Polacek --- I have a (simple, stupid) patch.
[Bug tree-optimization/98131] New: new test case g++.dg/cpp2a/concepts-nodiscard1.C in r11-5719 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98131 Bug ID: 98131 Summary: new test case g++.dg/cpp2a/concepts-nodiscard1.C in r11-5719 has excess errors Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:5ea36d20c352a3ca436aa764404f6210b090866b, r11-5719 make -k check-gcc RUNTESTFLAGS="dg.exp=g++.dg/cpp2a/concepts-nodiscard1.C" FAIL: g++.dg/cpp2a/concepts-nodiscard1.C -std=c++2a (test for excess errors) # of unexpected failures1 # of unsupported tests 3 Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../ /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp2a/concepts-nodiscard1.C -fdiagnostics-plain-output -nostdinc++ -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++2a -pedantic-errors -Wno-long-long -S -o concepts-nodiscard1.s (timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../ /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp2a/concepts-nodiscard1.C -fdiagnostics-plain-output -nostdinc++ -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++2a -pedantic-errors -Wno-long-long -S -o concepts-nodiscard1.s /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp2a/concepts-nodiscard1.C:8:10: warning: ignoring return value of 'int foo()', declared with attribute 'nodiscard' [-Wunused-result] /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp2a/concepts-nodiscard1.C:6:19: note: declared here Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../ exceptions_enabled107545.cc-fdiagnostics-plain-output -nostdinc++ -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 -S -o exceptions_enabled107545.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../ exceptions_enabled107545.cc -fdiagnostics-plain-output -nostdinc++ -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 -S -o exceptions_enabled107545.s FAIL: g++.dg/cpp2a/concepts-nodiscard1.C -std=c++2a (test for excess errors) Excess errors: /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp2a/concepts-nodiscard1.C:8:10: warning: ignoring return value of 'int foo()', declared with attribute 'nodiscard' [-Wunused-result] testcase /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/dg.exp completed in 0 seconds === g++ Summary === # of unexpected failures1 # of unsupported tests 3
[Bug bootstrap/98128] [11 Regression] Bootstrap failed on 32-bit hosts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98128 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 c++/98130] New: [11 regression] placement new fails on webkit-gtk-2.28.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130
Bug ID: 98130
Summary: [11 regression] placement new fails on
webkit-gtk-2.28.4
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Initial problem is observed on liferea crash at startup against
webkit-gtk-2.28.4 built with gcc-11.
If I reduced original source correctly here is minimized version of the crash:
//$ cat a.cc
/*
$ g++-10.2.0 -O1 -fno-strict-aliasing a.cc -o a-10 && ./a-10
=0x7ffc83475894
$ g++-11.0.0 -O1 -fno-strict-aliasing a.cc -o a-11 && ./a-11
Illegal instruction (core dumped) ./a-11
*/
#if 0
# include
#else
inline void* operator new(unsigned long, void* __p) { return __p; }
#endif
#include
typedef int* T;
static T storage;
static T* p =
// '__attribute__((__always_inline__))' seems to be the trigger
static inline __attribute__((__always_inline__)) void append(T value)
{
new (p) T(value);
}
int main() {
int a;
append();
if (!*p)
__builtin_trap();
fprintf(stderr, "=%p\n", *p);
}
[Bug testsuite/98125] New test case g++.dg/pr93195a.C in r11-5656 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125 H.J. Lu changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #4 from H.J. Lu --- (In reply to seurer from comment #0) > g:694d4a6d0c466d0fbc97920a9c6641a7b349ca35, r11-5656 > > make -k check-gcc RUNTESTFLAGS="dg.exp=g++.dg/pr93195a.C" > FAIL: g++.dg/pr93195a.C -std=gnu++98 (test for excess errors) > FAIL: g++.dg/pr93195a.C -std=gnu++14 (test for excess errors) > FAIL: g++.dg/pr93195a.C -std=gnu++17 (test for excess errors) > FAIL: g++.dg/pr93195a.C -std=gnu++2a (test for excess errors) > # of unexpected failures 4 > > The errors are all this: > > collect2: error: ld returned 1 exit status > compiler exited with status 1 > FAIL: g++.dg/pr93195a.C -std=gnu++14 (test for excess errors) > Excess errors: > `.text._Z3foov' referenced in section `__patchable_function_entries' of > /tmp/ccwJ1d6k.o: defined in discarded section `.text._Z3foov[_Z3foov]' of > /tmp/ccwJ1d6k.o This is a PowerPC specific issue. I don't know how __patchable_function_entries works on PowerPC.
[Bug libfortran/98129] New: Failure on reading big chunk of /dev/urandom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129 Bug ID: 98129 Summary: Failure on reading big chunk of /dev/urandom Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- The following program program main implicit none integer, parameter :: n = 10**7 integer :: u,v integer, dimension(:), allocatable :: a open (newunit=u,file="/dev/urandom",form="unformatted",access="stream") open (newunit=v,file="/dev/null",form="unformatted",access="stream") allocate (a(n)) read (u) a write (v) a end program main fails on Linux with At line 9 of file read.f90 Fortran runtime error: End of file Error termination. Backtrace: #0 0x7fa9c7be372f in read_block_direct at ../../../trunk/libgfortran/io/transfer.c:664 #1 0x7fa9c7be372f in unformatted_read at ../../../trunk/libgfortran/io/transfer.c:1127 #2 0x400bf3 in ??? #3 0x400c9c in ??? #4 0x7fa9c6e64349 in __libc_start_main at ../csu/libc-start.c:308 #5 0x400909 in ??? at ../sysdeps/x86_64/start.S:120 #6 0x in ???
[Bug bootstrap/98128] [11 Regression] Bootstrap failed on 32-bit hosts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98128 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- (In reply to H.J. Lu from comment #1) > It is likely caused by r11-5695. Yes, it's since this revision. I see that same issue.
[Bug rtl-optimization/97459] __uint128_t remainder for division by 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459 --- Comment #26 from Thomas Koenig --- Yep, it's implemented and works great. For a simple "sum of digits" program in base ten, it's an acceleration by more than a factor of two. Thanks!
[Bug libgcc/97543] powerpc64le: libgcc has unexpected long double in .gnu_attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543 --- Comment #10 from CVS Commits --- The master branch has been updated by Michael Meissner : https://gcc.gnu.org/g:9f1a6501994a2d18ec4fe2a6664637f48021b210 commit r11-5728-g9f1a6501994a2d18ec4fe2a6664637f48021b210 Author: Michael Meissner Date: Thu Dec 3 14:50:26 2020 -0500 PowerPC: PR libgcc/97543 and libgcc/97643, fix long double issues If you use a compiler with long double defaulting to 64-bit instead of 128-bit with IBM extended double, you get linker warnings about mis-matches in the gnu attributes for long double (PR libgcc/97543). Even if the compiler is configured to have long double be 64 bit as the default with the configuration option '--without-long-double-128' you get the warnings. You also get the same issues if you use a compiler with long double defaulting to IEEE 128-bit instead of IBM extended double (PR libgcc/97643). The issue is the way libgcc.a/libgcc.so is built. Right now when building libgcc under Linux, the long double size is set to 128-bits when building libgcc. However, the gnu attributes are set, leading to the warnings. One feature of the current GNU attribute implementation is if you have a shared library (such as libgcc_s.so), the GNU attributes for the shared library is an inclusive OR of all of the objects within the library. This means if any object file that uses the -mlong-double-128 option and uses long double, the GNU attributes for the library will indicate that it uses 128-bit IBM long doubles. If you have a static library, you will get the warning only if you actually reference an object file with the attribute set. This patch does two things: 1) All of the object files that support IBM 128-bit long doubles explicitly set the ABI to IBM extended double. 2) I turned off GNU attributes for building the shared library or for building the IBM 128-bit long double support. libgcc/ 2020-12-03 Michael Meissner PR libgcc/97543 PR libgcc/97643 * config/rs6000/t-linux (IBM128_STATIC_OBJS): New make variable. (IBM128_SHARED_OBJS): New make variable. (IBM128_OBJS): New make variable. Set all objects to use the explicit IBM format, and disable gnu attributes. (IBM128_CFLAGS): New make variable. (gcc_s_compile): Add -mno-gnu-attribute to all shared library modules.
[Bug c++/97643] Accepts invalid qualification conversion involving array of unknown bound [P0388]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97643 --- Comment #2 from CVS Commits --- The master branch has been updated by Michael Meissner : https://gcc.gnu.org/g:9f1a6501994a2d18ec4fe2a6664637f48021b210 commit r11-5728-g9f1a6501994a2d18ec4fe2a6664637f48021b210 Author: Michael Meissner Date: Thu Dec 3 14:50:26 2020 -0500 PowerPC: PR libgcc/97543 and libgcc/97643, fix long double issues If you use a compiler with long double defaulting to 64-bit instead of 128-bit with IBM extended double, you get linker warnings about mis-matches in the gnu attributes for long double (PR libgcc/97543). Even if the compiler is configured to have long double be 64 bit as the default with the configuration option '--without-long-double-128' you get the warnings. You also get the same issues if you use a compiler with long double defaulting to IEEE 128-bit instead of IBM extended double (PR libgcc/97643). The issue is the way libgcc.a/libgcc.so is built. Right now when building libgcc under Linux, the long double size is set to 128-bits when building libgcc. However, the gnu attributes are set, leading to the warnings. One feature of the current GNU attribute implementation is if you have a shared library (such as libgcc_s.so), the GNU attributes for the shared library is an inclusive OR of all of the objects within the library. This means if any object file that uses the -mlong-double-128 option and uses long double, the GNU attributes for the library will indicate that it uses 128-bit IBM long doubles. If you have a static library, you will get the warning only if you actually reference an object file with the attribute set. This patch does two things: 1) All of the object files that support IBM 128-bit long doubles explicitly set the ABI to IBM extended double. 2) I turned off GNU attributes for building the shared library or for building the IBM 128-bit long double support. libgcc/ 2020-12-03 Michael Meissner PR libgcc/97543 PR libgcc/97643 * config/rs6000/t-linux (IBM128_STATIC_OBJS): New make variable. (IBM128_SHARED_OBJS): New make variable. (IBM128_OBJS): New make variable. Set all objects to use the explicit IBM format, and disable gnu attributes. (IBM128_CFLAGS): New make variable. (gcc_s_compile): Add -mno-gnu-attribute to all shared library modules.
[Bug bootstrap/98128] [11 Regression] Bootstrap failed on 32-bit hosts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98128
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
--- gcc/cp/parser.c.jj 2020-12-03 20:41:57.194174600 +0100
+++ gcc/cp/parser.c 2020-12-03 20:46:28.626125729 +0100
@@ -30589,7 +30589,7 @@ cp_parser_late_parsing_default_args (cp_
tree copy;
unsigned ix;
- tree parmdecl = parms[i];
+ tree parmdecl = (*parms)[i];
pushdecl (parmdecl);
if (!default_arg)
@@ -30618,8 +30618,8 @@ cp_parser_late_parsing_default_args (cp_
parm = NULL_TREE;
for (int i = parms->length () - 1; i >= 0; --i)
{
- DECL_CHAIN (parms[i]) = parm;
- parm = parms[i];
+ DECL_CHAIN ((*parms)[i]) = parm;
+ parm = (*parms)[i];
}
pop_defarg_context ();
seems to work for me.
So does:
--- gcc/cp/cp-tree.h.jj 2020-12-02 22:55:36.328252325 +0100
+++ gcc/cp/cp-tree.h2020-12-03 20:49:11.746293467 +0100
@@ -963,6 +963,7 @@ public:
/* Breaks pointer/value consistency for convenience. */
tree& operator[] (unsigned i) const { return (*v)[i]; }
+ tree& operator[] (int i) const { return (*v)[i]; }
~releasing_vec() { release_tree_vector (v); }
private:
[Bug libstdc++/88322] Implement C++20 library features.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322 Bug 88322 depends on bug 88812, which changed state. Bug 88812 Summary: Implement C++20 LWG 2499/P0487R1 - Fixing operator>>(basic_istream&, CharT*) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88812 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/88812] Implement C++20 LWG 2499/P0487R1 - Fixing operator>>(basic_istream&, CharT*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88812 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely --- This was fixed in r11-2581 17abcc773415848dce593016512636cda3de20d5
[Bug fortran/95342] [9/10/11 Regression] ICE in gfc_match_subroutine, at fortran/decl.c:7913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95342 --- Comment #5 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:30b606bb9b9314010a446ea4bed3481632008f75 commit r11-5727-g30b606bb9b9314010a446ea4bed3481632008f75 Author: Harald Anlauf Date: Thu Dec 3 20:33:22 2020 +0100 PR fortran/95342 - ICE in gfc_match_subroutine, at fortran/decl.c:7913 Add checks for NULL pointers before dereferencing them. gcc/fortran/ChangeLog: PR fortran/95342 * decl.c (gfc_match_function_decl): Avoid NULL pointer dereference. (gfc_match_subroutine): Likewise. gcc/testsuite/ChangeLog: PR fortran/95342 * gfortran.dg/pr95342.f90: New test.
[Bug bootstrap/98128] [11 Regression] Bootstrap failed on 32-bit hosts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98128 H.J. Lu changed: What|Removed |Added Last reconfirmed||2020-12-03 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from H.J. Lu --- It is likely caused by r11-5695.
[Bug bootstrap/98128] New: [11 Regression] Bootstrap failed on 32-bit hosts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98128
Bug ID: 98128
Summary: [11 Regression] Bootstrap failed on 32-bit hosts
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: jakub at redhat dot com, jason at redhat dot com
Target Milestone: ---
On Linux/x86, r11-5702 failed to bootstrap:
../../src-master/gcc/cp/parser.c: In function ??void
cp_parser_late_parsing_default_args(cp_parser*, tree)??:
../../src-master/gcc/cp/parser.c:30592:28: error: ambiguous overload for
??operator[]?? (operand types are ??releasing_vec?? and ??int??)
30592 | tree parmdecl = parms[i];
|^
../../src-master/gcc/cp/parser.c:30592:28: note: candidate:
??operator[](releasing_vec::vec_t* {aka vec*}, int)??
(built-in)
In file included from ../../src-master/gcc/cp/parser.c:25:
../../src-master/gcc/cp/cp-tree.h:965:9: note: candidate: ??tree_node*&
releasing_vec::operator[](unsigned int) const??
965 | tree& operator[] (unsigned i) const { return (*v)[i]; }
| ^~~~
In file included from ../../src-master/gcc/c-family/c-common.h:26,
from ../../src-master/gcc/cp/cp-tree.h:40,
from ../../src-master/gcc/cp/parser.c:25:
../../src-master/gcc/cp/parser.c:30621:24: error: ambiguous overload for
??operator[]?? (operand types are ??releasing_vec?? and ??int??)
30621 | DECL_CHAIN (parms[i]) = parm;
|^
../../src-master/gcc/tree.h:286:26: note: in definition of macro
??CONTAINS_STRUCT_CHECK??
286 | (contains_struct_check ((T), (STRUCT), __FILE__, __LINE__,
__FUNCTION__))
| ^
../../src-master/gcc/tree.h:2424:27: note: in expansion of macro ??TREE_CHAIN??
2424 | #define DECL_CHAIN(NODE) (TREE_CHAIN (DECL_MINIMAL_CHECK (NODE)))
| ^~
../../src-master/gcc/tree.h:431:33: note: in expansion of macro
??CONTAINS_STRUCT_CHECK??
431 | #define DECL_MINIMAL_CHECK(T) CONTAINS_STRUCT_CHECK (T,
TS_DECL_MINIMAL)
| ^
../../src-master/gcc/tree.h:2424:39: note: in expansion of macro
??DECL_MINIMAL_CHECK??
2424 | #define DECL_CHAIN(NODE) (TREE_CHAIN (DECL_MINIMAL_CHECK (NODE)))
| ^~
../../src-master/gcc/cp/parser.c:30621:7: note: in expansion of macro
??DECL_CHAIN??
30621 | DECL_CHAIN (parms[i]) = parm;
| ^~
../../src-master/gcc/cp/parser.c:30621:24: note: candidate:
??operator[](releasing_vec::vec_t* {aka vec*}, int)??
(built-in)
30621 | DECL_CHAIN (parms[i]) = parm;
|^
../../src-master/gcc/tree.h:286:26: note: in definition of macro
??CONTAINS_STRUCT_CHECK??
r11-5693 is OK.
[Bug libstdc++/88322] Implement C++20 library features.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322 Bug 88322 depends on bug 93121, which changed state. Bug 93121 Summary: std::bit_cast missing https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93121 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/93121] std::bit_cast missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93121 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.0 Status|ASSIGNED|RESOLVED --- Comment #11 from Jonathan Wakely --- Added for GCC 11.
[Bug c++/96960] [C++20] ICE in tsubst_copy_and_build, at cp/pt.c:20531 from lambda in return-type-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96960 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Summary|ICE in |[C++20] ICE in |tsubst_copy_and_build, at |tsubst_copy_and_build, at |cp/pt.c:20531 from lambda |cp/pt.c:20531 from lambda |in return-type-requirement |in return-type-requirement --- Comment #2 from Jason Merrill --- This has to do with type_deducible_p's use of tf_partial. That function is left over from the days before P1084; we still kind of treat return type requirements as deduction rather than simply checking the constraint. Though other places where we do need to do deduction work properly: C0 auto x = 42; int f(C0 auto x); int y = f(42);
[Bug libstdc++/93121] std::bit_cast missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93121 --- Comment #10 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:9e433b3461ab64b38350817392a77efb67bb78b4 commit r11-5722-g9e433b3461ab64b38350817392a77efb67bb78b4 Author: Jonathan Wakely Date: Thu Dec 3 19:17:13 2020 + libstdc++: Add std::bit_cast for C++20 [PR 93121] Thanks to Jakub's addition of the built-in, we can add this to the library now. The compiler tests for the built-in are quite extensive, including verifying the constraints, so this only adds minimal tests to the library testsuite. This doesn't add a new _GLIBCXX_HAVE_BUILTIN_BIT_CAST because using __has_builtin(__builtin_bit_cast) works for GCC and versions of Clang that provide the built-in. libstdc++-v3/ChangeLog: PR libstdc++/93121 * include/std/bit (__cpp_lib_bit_cast, bit_cast): Define. * include/std/version (__cpp_lib_bit_cast): Define. * testsuite/26_numerics/bit/bit.cast/bit_cast.cc: New test. * testsuite/26_numerics/bit/bit.cast/version.cc: New test.
[Bug other/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121 --- Comment #9 from H.J. Lu --- Created attachment 49675 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49675=edit A patch
[Bug target/98086] [9/10/11 Regression] ICE in extract_insn, at recog.c:2315
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98086 Uroš Bizjak changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Assignee|jakub at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #8 from Uroš Bizjak --- Fixed for gcc-9.4, gcc-10.3 and gcc-11.0.
[Bug c++/98019] Concepts: compound requirement expression from 'requires' expression is considered discarded-value expression for [[nodiscard]], false positive warning emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98019 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.0 --- Comment #3 from Jason Merrill --- Fixed for GCC 11.
[Bug c++/98019] Concepts: compound requirement expression from 'requires' expression is considered discarded-value expression for [[nodiscard]], false positive warning emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98019 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:5ea36d20c352a3ca436aa764404f6210b090866b commit r11-5719-g5ea36d20c352a3ca436aa764404f6210b090866b Author: Jason Merrill Date: Thu Dec 3 13:55:51 2020 -0500 c++: Add testcase for PR98019 This has already been fixed on trunk, but I don't see a testcase for it. gcc/testsuite/ChangeLog: PR c++/98019 * g++.dg/cpp2a/concepts-nodiscard1.C: New test.
[Bug target/98086] [9/10/11 Regression] ICE in extract_insn, at recog.c:2315
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98086 --- Comment #7 from Uroš Bizjak --- https://gcc.gnu.org/g:521c839fad4e4a30cdadda254fb3f07706285033 commit r9-9096-g521c839fad4e4a30cdadda254fb3f07706285033 Author: Uros Bizjak Date: Thu Dec 3 19:08:23 2020 +0100 i386: Fix up ix86_md_asm_adjust for TImode [PR98086] ix86_md_asm_adjust assumes that dest_mode can be only [QHSD]Imode and nothing else. The patch rewrites zero-extension part to use convert_to_mode to handle TImode and hypothetically even wider modes. 2020-12-03 Uroš Bizjak Jakub Jelinek gcc/ PR target/98086 * config/i386/i386.c (ix86_md_asm_adjustmd): Rewrite zero-extension part to use convert_to_mode. gcc/testsuite/ PR target/98086 * gcc.target/i386/pr98086.c: New test.
[Bug target/98086] [9/10/11 Regression] ICE in extract_insn, at recog.c:2315
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98086 --- Comment #6 from Uroš Bizjak --- https://gcc.gnu.org/g:4fa2ab664324eca33bd67981698c453820f70b86 commit r10-9116-g4fa2ab664324eca33bd67981698c453820f70b86 Author: Uros Bizjak Date: Thu Dec 3 17:49:42 2020 +0100 i386: Fix up ix86_md_asm_adjust for TImode [PR98086] ix86_md_asm_adjust assumes that dest_mode can be only [QHSD]Imode and nothing else. The patch rewrites zero-extension part to use convert_to_mode to handle TImode and hypothetically even wider modes. 2020-12-03 Uroš Bizjak Jakub Jelinek gcc/ PR target/98086 * config/i386/i386.c (ix86_md_asm_adjustmd): Rewrite zero-extension part to use convert_to_mode. gcc/testsuite/ PR target/98086 * gcc.target/i386/pr98086.c: New test. (cherry picked from commit 756f55e62f73eb32787497eb9e564d4b21a6e637)
[Bug target/98086] [9/10/11 Regression] ICE in extract_insn, at recog.c:2315
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98086 --- Comment #5 from Uroš Bizjak --- https://gcc.gnu.org/g:756f55e62f73eb32787497eb9e564d4b21a6e637 commit r11-5713-g756f55e62f73eb32787497eb9e564d4b21a6e637 Author: Uros Bizjak Date: Thu Dec 3 17:49:42 2020 +0100 i386: Fix up ix86_md_asm_adjust for TImode [PR98086] ix86_md_asm_adjust assumes that dest_mode can be only [QHSD]Imode and nothing else. The patch rewrites zero-extension part to use convert_to_mode to handle TImode and hypothetically even wider modes. 2020-12-03 Uroš Bizjak Jakub Jelinek gcc/ PR target/98086 * config/i386/i386.c (ix86_md_asm_adjustmd): Rewrite zero-extension part to use convert_to_mode. gcc/testsuite/ PR target/98086 * gcc.target/i386/pr98086.c: New test.
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 Eric Botcazou changed: What|Removed |Added CC||sch...@linux-m68k.org --- Comment #39 from Eric Botcazou --- *** Bug 98127 has been marked as a duplicate of this bug. ***
[Bug ada/98127] [11 regression] libada lacks objects needed for 128-bit types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98127 Eric Botcazou changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Eric Botcazou --- . *** This bug has been marked as a duplicate of bug 97504 ***
[Bug c++/97059] C++20: compound requirement uses inconsistent return type (adds ref)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97059
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Jason Merrill ---
(In reply to Dimitri Gorokhovik from comment #0)
> template
> concept S = requires (T t)
> {
> { t.n } -> std::same_as #if NOBUG
> &
> #endif
> >;
> requires std::is_same_v ;
> };
>
> Compilation succeeds when NOBUG is defined, i.e., the compound requirement
> '{ t.n } ->' produces the return type as 'const std::size_t &' instead of
> 'const std::size_t'. Which is inconsistent elsewhere (see the source code
> above).
For the second 'requires' to be equivalent to the return-type-requirement, you
need another set of parentheses around "t.n".
7.5.7.3: "The immediately-declared constraint (13.2) of the type-constraint for
decltype((E)) shall be satisfied."
It's the extra parentheses that result in the reference type rather than
non-reference. GCC is correct here.
[Bug ada/98127] New: [11 regression] libada lacks objects needed for 128-bit types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98127 Bug ID: 98127 Summary: [11 regression] libada lacks objects needed for 128-bit types Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: ebotcazou at gcc dot gnu.org Target Milestone: --- Target: powerpc*-*-* === acats configuration === target gcc is /daten/gcc/gcc-20201201/Build/gcc/xgcc -B/daten/gcc/gcc-20201201/Build/gcc/ Reading specs from /daten/gcc/gcc-20201201/Build/gcc/specs COLLECT_GCC=/daten/gcc/gcc-20201201/Build/gcc/xgcc COLLECT_LTO_WRAPPER=/daten/gcc/gcc-20201201/Build/gcc/lto-wrapper Target: powerpc64-suse-linux Configured with: ../configure --prefix=/usr --build=powerpc64-suse-linux --enable-shared --with-system-zlib CFLAGS='-O2 -g' CXXFLAGS='-O2 -g' --enable-checking=release --with-cpu-64=power4 --enable-secureplt --with-long-double-128 Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.0.0 20201201 (experimental) [HEAD revision 69157fe75823] (GCC) host=powerpc64-suse-linux target=powerpc64-suse-linux gnatmake is /daten/gcc/gcc-20201201/Build/gcc/gnatmake GNATLS 11.0.0 20201201 (experimental) [HEAD revision 69157fe75823] Copyright (C) 1997-2020, Free Software Foundation, Inc. Source Search Path: /daten/gcc/gcc-20201201/Build/gcc/ada/rts /usr/lib64/gcc/powerpc64-suse-linux/11.0.0/adainclude Object Search Path: /daten/gcc/gcc-20201201/Build/gcc/ada/rts /usr/lib64/gcc/powerpc64-suse-linux/11.0.0/adalib Project Search Path: /usr/powerpc64-suse-linux/lib/gnat /usr/powerpc64-suse-linux/share/gpr /usr/share/gpr /usr/lib/gnat === acats support === Generating support files.../daten/gcc/gcc-20201201/Build/gcc/gnatmake --GNATBIND=/daten/gcc/gcc-20201201/Build/gcc/gnatbind --GNATLINK=/daten/gcc/gcc-20201201/Build/gcc/gnatlink --GCC=/daten/gcc/gcc-20201201/Build/gcc/xgcc -B/daten/gcc/gcc-20201201/Build/gcc/ -gnatws -O2 /daten/gcc/gcc-20201201/gcc/testsuite/ada/acats/support/impbit.adb -largs --GCC=/daten/gcc/gcc-20201201/Build/gcc/xgcc -B/daten/gcc/gcc-20201201/Build/gcc/ /daten/gcc/gcc-20201201/Build/gcc/xgcc -c -I/daten/gcc/gcc-20201201/gcc/testsuite/ada/acats/support/ -B/daten/gcc/gcc-20201201/Build/gcc/ -gnatws -O2 -I- /daten/gcc/gcc-20201201/gcc/testsuite/ada/acats/support/impbit.adb /daten/gcc/gcc-20201201/Build/gcc/gnatbind -x impbit.ali error: "s-imgllli.ali" not found, "s-imgllli.ads" must be compiled gnatmake: *** bind failed. Failed to compile impbit
[Bug target/98086] [9/10/11 Regression] ICE in extract_insn, at recog.c:2315
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98086 Uroš Bizjak changed: What|Removed |Added Attachment #49661|0 |1 is obsolete|| --- Comment #4 from Uroš Bizjak --- Created attachment 49674 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49674=edit Proposed v2 patch
[Bug testsuite/98125] New test case g++.dg/pr93195a.C in r11-5656 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125 --- Comment #3 from H.J. Lu --- (In reply to seurer from comment #2) > #define HAVE_GAS_SECTION_LINK_ORDER 1 Please show the command line options passed to ld, pass --dependency-file=FILE to ld to list all linker input files and upload all linker input files so that I can investigate with a cross linker.
[Bug c++/98122] [10/11 Regression] Accessing union member through pointer-to-member is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98122 Marek Polacek changed: What|Removed |Added Priority|P3 |P2
[Bug c++/98122] [10/11 Regression] Accessing union member through pointer-to-member is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98122 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-12-03 Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Keywords||rejects-valid Summary|[regression] Accessing |[10/11 Regression] |union member through|Accessing union member |pointer-to-member is not a |through pointer-to-member |constant expression |is not a constant ||expression Target Milestone|--- |10.3 --- Comment #1 from Marek Polacek --- Started with r276563.
[Bug target/98112] Add -fdirect-access-external-data & drop HAVE_LD_PIE_COPYRELOC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112
--- Comment #2 from Fangrui Song ---
Note: -fdirect-access-external-data is architecture-independent. For example,
currently Clang on aarch64 can perform the following optimization:
// clang -target aarch64 -fPIE -O3
adrpx8, :got:var
ldr x8, [x8, :got_lo12:var]
ldr w0, [x8]
ret
// clang -target aarch64 -fPIE -O3 -mpie-copy-relocations
adrpx8, var
ldr w0, [x8, :lo12:var]
ret
A better name for -mpie-copy-relocations is -fno-direct-access-external-data:
1. the option can affect -fno-pic and -fpic
2. for -no-pie and -pie links, there is not necessary a copy relocation
(-fpic can use this option as well, but keep in mind that DSOs do not support
copy relocations. So if such code is used for -shared links and the data turns
out to be undefined, the linker will reject the object file)
---
The second thing about the feature request is that x86-64 should default to
-fno-direct-access-external-data for -fpie to address the protected symbol
issues.
(-fno-direct-access-external-data for -fpie is the behavior on most
architectures.)
(1): PC32 referencing a protected function is unnecessarily rejected in a
-shared link (this also affects aarch64)
// gcc -fpic -fuse-ld=bfd -shared -fvisibility=protected b.c => relocation
R_X86_64_PC32 against protected symbol `f' can not be used when making a shared
object
// aarch64-linux-gnu-gcc -fpic -fuse-ld=bfd -shared -fvisibility=protected
b.c => relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `f' which may bind
externally can not be used when making a shared object; recompile with -fPIC
// gold is good
void f() {}
void *g() { return }
This can be fixed by making GNU ld more permissive.
(2) protected data access can use slightly more efficient PC32. Currently it
uses the slightly pessimized REX_GOTPCRELX.
int a __attribute__((visibility("protected")));
int f() { return a; }
[Bug c++/98126] New: -Wsequence-point is non-linear for certain cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98126
Bug ID: 98126
Summary: -Wsequence-point is non-linear for certain cases
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
This script generates C++ programs that show that -Wsequence-point exhibits
non-linear behavior:
#!/bin/bash
n=$1
printf "struct T { bool operator==(const T ) const; };
struct C {
bool operator==(const C ) const {
return\n"
for i in $(seq $n); do printf " t$i == ot.t$i &&\n"; done
printf " true;
}
"
for i in $(seq $n); do printf " T t$i;\n"; done
printf "};\n"
$ ./gen.sh 100 > gen.cc && time -p ./cc1plus -quiet -fsyntax-only -Wall gen.cc
real 0.60
$ ./gen.sh 200 > gen.cc && time -p ./cc1plus -quiet -fsyntax-only -Wall gen.cc
real 4.50
$ ./gen.sh 300 > gen.cc && time -p ./cc1plus -quiet -fsyntax-only -Wall gen.cc
real 14.62
$ ./gen.sh 400 > gen.cc && time -p ./cc1plus -quiet -fsyntax-only -Wall gen.cc
real 34.46
$ ./gen.sh 500 > gen.cc && time -p ./cc1plus -quiet -fsyntax-only -Wall gen.cc
real 67.27
$ ./gen.sh 600 > gen.cc && time -p ./cc1plus -quiet -fsyntax-only -Wall gen.cc
real 117.33
$ ./gen.sh 700 > gen.cc && time -p ./cc1plus -quiet -fsyntax-only -Wall gen.cc
real 179.78
$ ./gen.sh 800 > gen.cc && time -p ./cc1plus -quiet -fsyntax-only -Wall gen.cc
real 278.54
Note that
$ ./gen.sh 800 > gen.cc && time -p ./cc1plus -quiet -fsyntax-only -Wall gen.cc
-Wno-sequence-point
real 0.14
[Bug other/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121
--- Comment #8 from Jozef Lawrynowicz ---
(In reply to Jozef Lawrynowicz from comment #7)
> (In reply to Florian Weimer from comment #6)
> > (In reply to Jozef Lawrynowicz from comment #4)
> > > GAS merges the "R" flag state in .section declarations, silently, and with
> > > logical OR, and GCC should do the same. So if you have:
> > >
> > > int __attribute__((section(".data.foo"))) foo1 = 1;
> > > int __attribute__((used,section(".data.foo"))) foo2 = 2;
> > >
> > > .data.foo should have SECTION_RETAIN set within GCC. The addition of the
> > > "used" attribute to the second declaration of section(".data.foo") should
> > > not cause any warning/error messages to be emitted either. So option 3
> > > from
> > > above.
> > >
> > > Just need to do something similar to what is already done for
> > > SECTION_NOTYPE
> > > in varasm.c:get_section.
> >
> > I don't now the details, but I think foo1 should not implicitly be marked as
> > “used”. The difference matters for static functions, for example. GCC should
> > still drop them if they are not referenced, even if they are located in a
> > retained section. So free_slotinfo in comment 5.
>
> With the suggested approach, GCC would still drop foo1 if it is not used,
> since it is only the section being marked with SECTION_RETAIN, and this only
> affects whether the "R" flag is output in the .section directive for the
> decl.
>
> GCC will only keep an unreferenced decl if it has DECL_PRESERVE_P and we
> haven't changed that with the "used" applies SHF_GNU_RETAIN functionality.
>
> If foo1 somehow makes it into the assembler code, it will be kept, even if
> it is not used, since we lose the ability to remove individual decls once
> they are put in sections.
Sorry, in my foo1/foo2 example they are not static so will not be dropped by
GCC.
For the free_slotinfo example, it would be dropped by GCC if unused, even
though another function with the same section was marked "used" and has
SECTION_RETAIN.
[Bug other/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121
--- Comment #7 from Jozef Lawrynowicz ---
(In reply to Florian Weimer from comment #6)
> (In reply to Jozef Lawrynowicz from comment #4)
> > GAS merges the "R" flag state in .section declarations, silently, and with
> > logical OR, and GCC should do the same. So if you have:
> >
> > int __attribute__((section(".data.foo"))) foo1 = 1;
> > int __attribute__((used,section(".data.foo"))) foo2 = 2;
> >
> > .data.foo should have SECTION_RETAIN set within GCC. The addition of the
> > "used" attribute to the second declaration of section(".data.foo") should
> > not cause any warning/error messages to be emitted either. So option 3 from
> > above.
> >
> > Just need to do something similar to what is already done for SECTION_NOTYPE
> > in varasm.c:get_section.
>
> I don't now the details, but I think foo1 should not implicitly be marked as
> “used”. The difference matters for static functions, for example. GCC should
> still drop them if they are not referenced, even if they are located in a
> retained section. So free_slotinfo in comment 5.
With the suggested approach, GCC would still drop foo1 if it is not used, since
it is only the section being marked with SECTION_RETAIN, and this only affects
whether the "R" flag is output in the .section directive for the decl.
GCC will only keep an unreferenced decl if it has DECL_PRESERVE_P and we
haven't changed that with the "used" applies SHF_GNU_RETAIN functionality.
If foo1 somehow makes it into the assembler code, it will be kept, even if it
is not used, since we lose the ability to remove individual decls once they are
put in sections.
[Bug testsuite/98125] New test case g++.dg/pr93195a.C in r11-5656 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125 --- Comment #2 from seurer at gcc dot gnu.org --- #define HAVE_GAS_SECTION_LINK_ORDER 1
[Bug other/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121
--- Comment #6 from Florian Weimer ---
(In reply to Jozef Lawrynowicz from comment #4)
> GAS merges the "R" flag state in .section declarations, silently, and with
> logical OR, and GCC should do the same. So if you have:
>
> int __attribute__((section(".data.foo"))) foo1 = 1;
> int __attribute__((used,section(".data.foo"))) foo2 = 2;
>
> .data.foo should have SECTION_RETAIN set within GCC. The addition of the
> "used" attribute to the second declaration of section(".data.foo") should
> not cause any warning/error messages to be emitted either. So option 3 from
> above.
>
> Just need to do something similar to what is already done for SECTION_NOTYPE
> in varasm.c:get_section.
I don't now the details, but I think foo1 should not implicitly be marked as
“used”. The difference matters for static functions, for example. GCC should
still drop them if they are not referenced, even if they are located in a
retained section. So free_slotinfo in comment 5.
[Bug other/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121
--- Comment #5 from H.J. Lu ---
[hjl@gnu-cfl-2 tmp]$ cat x.c
struct dtv_slotinfo_list
{
struct dtv_slotinfo_list *next;
};
extern struct dtv_slotinfo_list *list;
static int __attribute__ ((section ("__libc_freeres_fn")))
free_slotinfo (struct dtv_slotinfo_list **elemp)
{
if (!free_slotinfo (&(*elemp)->next))
return 0;
return 1;
}
__attribute__ ((used, section ("__libc_freeres_fn")))
static void free_mem (void)
{
free_slotinfo ();
}
[hjl@gnu-cfl-2 tmp]$ /usr/gcc-11.0.0-x32/bin/gcc -S -O2 x.c -fPIC
x.c: In function ‘free_mem’:
x.c:17:13: error: ‘free_mem’ causes a section type conflict with
‘free_slotinfo.isra’
17 | static void free_mem (void)
| ^~~~
x.c:9:1: note: ‘free_slotinfo.isra’ was declared here
9 | free_slotinfo (struct dtv_slotinfo_list **elemp)
| ^
[hjl@gnu-cfl-2 tmp]$
[Bug c++/98115] [11 Regression] error: partial specialization ‘class Stringify’ is not more specialized than [-fpermissive] since r11-5663-g329ae1d7751346ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98115 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Nathan Sidwell --- Fixed 7254a78cf4c
[Bug c++/98116] [11 Regression] ICE in strip_typedefs, at cp/tree.c:1744 since r11-5663-g329ae1d7751346ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98116 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Nathan Sidwell --- Fixed 7254a78cf4c
[Bug c++/98115] [11 Regression] error: partial specialization ‘class Stringify’ is not more specialized than [-fpermissive] since r11-5663-g329ae1d7751346ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98115 --- Comment #1 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:7254a78cf4c419a9b9361289d8c535130cf1dfd0 commit r11-5712-g7254a78cf4c419a9b9361289d8c535130cf1dfd0 Author: Nathan Sidwell Date: Thu Dec 3 08:40:43 2020 -0800 c++: Testcases [PR 98115] These two testcases provide coverage for 98115, which doesn't trigger on all hosts. PR c++/98115 PR c++/98116 gcc/testsuite/ * g++.dg/template/pr98115.C: New. * g++.dg/template/pr98116.C: New.
[Bug c++/98116] [11 Regression] ICE in strip_typedefs, at cp/tree.c:1744 since r11-5663-g329ae1d7751346ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98116 --- Comment #1 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:7254a78cf4c419a9b9361289d8c535130cf1dfd0 commit r11-5712-g7254a78cf4c419a9b9361289d8c535130cf1dfd0 Author: Nathan Sidwell Date: Thu Dec 3 08:40:43 2020 -0800 c++: Testcases [PR 98115] These two testcases provide coverage for 98115, which doesn't trigger on all hosts. PR c++/98115 PR c++/98116 gcc/testsuite/ * g++.dg/template/pr98115.C: New. * g++.dg/template/pr98116.C: New.
[Bug other/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121
--- Comment #4 from Jozef Lawrynowicz ---
(In reply to H.J. Lu from comment #2)
> The issue here is that what should happen when definitions marked with used
> attribute and unmarked definitions are put in the same section. It has
> nothing
> to do with .retain.
This bug report doesn't mention that. It looks to me that Florian was looking
to discuss the conceptual issue of whether the "used" attribute should apply
SHF_GNU_RETAIN.
I assume you're referring to the glibc bug 27002 with though.
(In reply to H.J. Lu from comment #3)
> If we cant to use SHF_GNU_RETAIN on used attribute, compiler can do
>
> 1. Issue an error.
> 2. issue a warning and mark the unmarked definition as used.
> 3. Silently mark the unmarked definition as used.
GAS merges the "R" flag state in .section declarations, silently, and with
logical OR, and GCC should do the same. So if you have:
int __attribute__((section(".data.foo"))) foo1 = 1;
int __attribute__((used,section(".data.foo"))) foo2 = 2;
.data.foo should have SECTION_RETAIN set within GCC. The addition of the "used"
attribute to the second declaration of section(".data.foo") should not cause
any warning/error messages to be emitted either. So option 3 from above.
Just need to do something similar to what is already done for SECTION_NOTYPE in
varasm.c:get_section.
[Bug c++/96299] Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96299 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Looking at this now.
[Bug testsuite/98125] New test case g++.dg/pr93195a.C in r11-5656 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2020-12-03 --- Comment #1 from H.J. Lu --- Please show $ grep HAVE_GAS_SECTION_LINK_ORDER auto-host.h
[Bug testsuite/98125] New: New test case g++.dg/pr93195a.C in r11-5656 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125 Bug ID: 98125 Summary: New test case g++.dg/pr93195a.C in r11-5656 has excess errors Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:694d4a6d0c466d0fbc97920a9c6641a7b349ca35, r11-5656 make -k check-gcc RUNTESTFLAGS="dg.exp=g++.dg/pr93195a.C" FAIL: g++.dg/pr93195a.C -std=gnu++98 (test for excess errors) FAIL: g++.dg/pr93195a.C -std=gnu++14 (test for excess errors) FAIL: g++.dg/pr93195a.C -std=gnu++17 (test for excess errors) FAIL: g++.dg/pr93195a.C -std=gnu++2a (test for excess errors) # of unexpected failures4 The errors are all this: collect2: error: ld returned 1 exit status compiler exited with status 1 FAIL: g++.dg/pr93195a.C -std=gnu++14 (test for excess errors) Excess errors: `.text._Z3foov' referenced in section `__patchable_function_entries' of /tmp/ccwJ1d6k.o: defined in discarded section `.text._Z3foov[_Z3foov]' of /tmp/ccwJ1d6k.o
[Bug tree-optimization/98107] [11 regression] ICE at hash-table.c:137 starting with r11-5663
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98107 Nathan Sidwell changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Nathan Sidwell --- Fixed 62fb1b9e0da
[Bug tree-optimization/98107] [11 regression] ICE at hash-table.c:137 starting with r11-5663
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98107 --- Comment #2 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:62fb1b9e0da44a15b0434def20724f989d61e27b commit r11-5708-g62fb1b9e0da44a15b0434def20724f989d61e27b Author: Nathan Sidwell Date: Thu Dec 3 07:42:09 2020 -0800 c++: Fix array type dependency [PR 98107] I'd missed some paths through build_cplus_array_type, plus, some arrays come via the C-type builder. This propagates dependency in more places and asserts that in the cases where TYPE_DEPENDENT_P_VALID is unset, the type is non-dependent. PR c++/98107 gcc/cp/ * tree.c (build_cplus_array_type): Mark dependency of new variant. (cp_build_qualified_type_real, strip_typedefs): Assert TYPE_DEPENDENT_P_VALID, or not a dependent type.
[Bug target/98124] New: Z: Load and test LTDBR instruction gets not used for comparison against 0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98124
Bug ID: 98124
Summary: Z: Load and test LTDBR instruction gets not used for
comparison against 0.0
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
#include
double sign(double in)
{
return in == 0.0 ? 0.0 : copysign(1.0, in);
}
Command line:
gcc m64 -O2 -save-temps copysign.C
Output:
_Z4signd:
.LFB234:
.cfi_startproc
larl%r5,.L8
lzdr%f2
cdbr%f0,%f2
je .L6
ld %f2,.L9-.L8(%r5)
cpsdr %f0,%f0,%f2
br %r14
Use of LTDBR expected instead of lzdr%f2 + cdbr%f0,%f2
[Bug tree-optimization/98123] if-to-switch tests fail on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98123 Martin Liška changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #2 from Martin Liška --- Should be fixed on master, can you please re-check it?
[Bug tree-optimization/98123] if-to-switch tests fail on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98123 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Last reconfirmed||2020-12-03 --- Comment #1 from Martin Liška --- All right, I'm gonna test it with a cross compiler.
[Bug other/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121 H.J. Lu changed: What|Removed |Added Last reconfirmed||2020-12-03 Component|target |other Ever confirmed|0 |1 Target Milestone|--- |11.0 Status|UNCONFIRMED |NEW --- Comment #3 from H.J. Lu --- (In reply to H.J. Lu from comment #2) > The issue here is that what should happen when definitions marked with used > attribute and unmarked definitions are put in the same section. It has > nothing > to do with .retain. If we cant to use SHF_GNU_RETAIN on used attribute, compiler can do 1. Issue an error. 2. issue a warning and mark the unmarked definition as used. 3. Silently mark the unmarked definition as used.
[Bug middle-end/98099] ICE in gen_lowpart_common, at emit-rtl.c:1554
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |11.0 Resolution|--- |FIXED --- Comment #5 from Eric Botcazou --- .
[Bug middle-end/98082] [11 Regression] ICE in set_rtl, at cfgexpand.c:178 since r11-3257-g225a08220e444371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98082 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Eric Botcazou --- .
[Bug middle-end/98099] ICE in gen_lowpart_common, at emit-rtl.c:1554
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099 --- Comment #4 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:277ff3406d533990e98cf1c2075b9dc9db6fa48a commit r11-5706-g277ff3406d533990e98cf1c2075b9dc9db6fa48a Author: Eric Botcazou Date: Thu Dec 3 15:54:14 2020 +0100 Fix PR middle-end/98099 this replaces the ICE by a sorry message for the use of reverse scalar storage order with 128-bit decimal floating-point type on 32-bit targets. gcc/ChangeLog: PR middle-end/98099 * expmed.c (flip_storage_order): In the case of a non-integer mode, sorry out if the integer mode to be used instead is not supported. gcc/testsuite/ChangeLog: * gcc.dg/pr98099.c: New test.
[Bug middle-end/98082] [11 Regression] ICE in set_rtl, at cfgexpand.c:178 since r11-3257-g225a08220e444371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98082 --- Comment #8 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:5d103763b9bc6a998dd4a453861663b229d7a24a commit r11-5705-g5d103763b9bc6a998dd4a453861663b229d7a24a Author: Eric Botcazou Date: Thu Dec 3 15:52:15 2020 +0100 Fix PR middle-end/98082 this fixes an ICE introduced by the fix for PR middle-end/97078 where use_register_for_decl was changed to return true at -O0 for a parameter of a thunk. It turns out that we need to do the same for a result in this case. gcc/ChangeLog: PR middle-end/98082 * function.c (use_register_for_decl): Also return true for a result if cfun->tail_call_marked is true. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/pr98082.C: New test.
[Bug middle-end/97078] [11 Regression] ICE in set_rtl building glibc tests with -ffloat-store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97078 --- Comment #5 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:5d103763b9bc6a998dd4a453861663b229d7a24a commit r11-5705-g5d103763b9bc6a998dd4a453861663b229d7a24a Author: Eric Botcazou Date: Thu Dec 3 15:52:15 2020 +0100 Fix PR middle-end/98082 this fixes an ICE introduced by the fix for PR middle-end/97078 where use_register_for_decl was changed to return true at -O0 for a parameter of a thunk. It turns out that we need to do the same for a result in this case. gcc/ChangeLog: PR middle-end/98082 * function.c (use_register_for_decl): Also return true for a result if cfun->tail_call_marked is true. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/pr98082.C: New test.
[Bug target/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121 --- Comment #2 from H.J. Lu --- The issue here is that what should happen when definitions marked with used attribute and unmarked definitions are put in the same section. It has nothing to do with .retain.
[Bug libstdc++/93121] std::bit_cast missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93121 --- Comment #9 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:896048cf43d5eb21ab7c16553bb9d13b0f890b81 commit r11-5704-g896048cf43d5eb21ab7c16553bb9d13b0f890b81 Author: Jakub Jelinek Date: Thu Dec 3 15:46:54 2020 +0100 c++: Add __builtin_bit_cast to implement std::bit_cast [PR93121] The following patch adds __builtin_bit_cast builtin, similarly to clang or MSVC which implement std::bit_cast using such an builtin too. It checks the various std::bit_cast requirements, when not constexpr evaluated acts pretty much like VIEW_CONVERT_EXPR of the source argument to the destination type and the hardest part is obviously the constexpr evaluation. I've left out PDP11 handling of those, couldn't figure out how exactly are bitfields laid out there 2020-12-03 Jakub Jelinek PR libstdc++/93121 * fold-const.h (native_encode_initializer): Add mask argument defaulted to nullptr. (find_bitfield_repr_type): Declare. (native_interpret_aggregate): Declare. * fold-const.c (find_bitfield_repr_type): New function. (native_encode_initializer): Add mask argument and support for filling it. Handle also some bitfields without integral DECL_BIT_FIELD_REPRESENTATIVE. (native_interpret_aggregate): New function. * gimple-fold.h (clear_type_padding_in_mask): Declare. * gimple-fold.c (struct clear_padding_struct): Add clear_in_mask member. (clear_padding_flush): Handle buf->clear_in_mask. (clear_padding_union): Copy clear_in_mask. Don't error if buf->clear_in_mask is set. (clear_padding_type): Don't error if buf->clear_in_mask is set. (clear_type_padding_in_mask): New function. (gimple_fold_builtin_clear_padding): Set buf.clear_in_mask to false. * doc/extend.texi (__builtin_bit_cast): Document. * c-common.h (enum rid): Add RID_BUILTIN_BIT_CAST. * c-common.c (c_common_reswords): Add __builtin_bit_cast. * cp-tree.h (cp_build_bit_cast): Declare. * cp-tree.def (BIT_CAST_EXPR): New tree code. * cp-objcp-common.c (names_builtin_p): Handle RID_BUILTIN_BIT_CAST. (cp_common_init_ts): Handle BIT_CAST_EXPR. * cxx-pretty-print.c (cxx_pretty_printer::postfix_expression): Likewise. * parser.c (cp_parser_postfix_expression): Handle RID_BUILTIN_BIT_CAST. * semantics.c (cp_build_bit_cast): New function. * tree.c (cp_tree_equal): Handle BIT_CAST_EXPR. (cp_walk_subtrees): Likewise. * pt.c (tsubst_copy): Likewise. * constexpr.c (check_bit_cast_type, cxx_eval_bit_cast): New functions. (cxx_eval_constant_expression): Handle BIT_CAST_EXPR. (potential_constant_expression_1): Likewise. * cp-gimplify.c (cp_genericize_r): Likewise. * g++.dg/cpp2a/bit-cast1.C: New test. * g++.dg/cpp2a/bit-cast2.C: New test. * g++.dg/cpp2a/bit-cast3.C: New test. * g++.dg/cpp2a/bit-cast4.C: New test. * g++.dg/cpp2a/bit-cast5.C: New test.
[Bug target/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121 jozefl at gcc dot gnu.org changed: What|Removed |Added CC||jozefl at gcc dot gnu.org --- Comment #1 from jozefl at gcc dot gnu.org --- The feedback after I originally submitted a patch that implements a "retain" attribute to apply SHF_GNU_RETIAN, was that "used" should instead apply SHF_GNU_RETAIN: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557097.html The discussions went on about other aspects of the implementation in other threads, but there were no objections to the idea of "used" applying SHF_GNU_RETAIN. I think the logic is sound that a declaration marked with the "used" attribute should not be removed by the compiler, or garbage collected by the linker. Basically, if you mark a declaration as "used", it should be retained in the final program, even if it was not referenced. The issue lies in the fact that the "used" attribute has been around for so long, that the change in behavior has the potential to affect existing applications that make use of it. However, the new behavior is only enabled when using the latest GCC and latest Binutils. Some change in behavior can be expected when using the latest versions of the tools. This new behavior should really be documented in the release notes though. I didn't want to have "used" change section attributes in assembler directives, the original plan was to use a separate assembler ".retain" directive to apply SHF_GNU_RETAIN. This would mean we could leave .section assembler directives for a particular "used" declaration untouched, and just emit a ".retain " directive. The assembler therefore handles the application of the SHF_GNU_RETAIN flag to a particular section, instead of forcing the compiler to have to make these additional considerations about section attributes. I even did a patch for that, but there was staunch objection from H.J. on this, on multiple occasions, I realized we weren't going to get anywhere: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557931.html https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558400.html https://sourceware.org/pipermail/binutils/2020-November/114077.html I would be more than happy to add the .retain attribute to Binutils, but we would need a Binutils global maintainer to approve that, and no one gave the OK for my original ".retain " patch the first time round. I could then change the GCC implementation to use the ".retain" directive, which would ensure that section attributes in assembler code output by GCC are not contaminated with the "R" flag when the "used" attribute is applied. Thanks, Jozef
[Bug tree-optimization/98123] New: if-to-switch tests fail on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98123 Bug ID: 98123 Summary: if-to-switch tests fail on arm Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- The recently introduced if-to-switch-* tests fail on arm: gcc.dg/tree-ssa/if-to-switch-2.c scan-tree-dump iftoswitch "Condition chain with 3 BBs transformed into a switch statement." gcc.dg/tree-ssa/if-to-switch-3.c scan-tree-dump iftoswitch "Condition chain with 3 BBs transformed into a switch statement." gcc.dg/tree-ssa/if-to-switch-4.c scan-tree-dump-not iftoswitch "Condition chain" gcc.dg/tree-ssa/if-to-switch-5.c scan-tree-dump iftoswitch "Condition chain with 5 BBs transformed into a switch statement." gcc.dg/tree-ssa/if-to-switch-6.c scan-tree-dump-not iftoswitch "Condition chain" gcc.dg/tree-ssa/if-to-switch-8.c scan-tree-dump-not iftoswitch "Condition chain" When GCC is configured with: --target arm-none-linux-gnueabihf --with-mode thumb --with-cpu cortex-a5 --with-fpu vfpv3-d16-fp16 Configuring for cortex-a9 instead of cortex-a5 shows less failures, only: gcc.dg/tree-ssa/if-to-switch-4.c scan-tree-dump-not iftoswitch "Condition chain" gcc.dg/tree-ssa/if-to-switch-6.c scan-tree-dump-not iftoswitch "Condition chain" gcc.dg/tree-ssa/if-to-switch-8.c scan-tree-dump-not iftoswitch "Condition chain"
[Bug tree-optimization/98113] [11 Regression] popcnt is not vectorized on s390 since f5e18dd9c7da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98113 --- Comment #6 from Ilya Leoshkevich --- With the patch, vxe/popcount-1.c works on s390 again: vpopctf: .LFB2: .cfi_startproc vpopctf %v24,%v24 br %r14 Thanks!
