[Bug driver/101383] GCC 11 Reproducibility Issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101383 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:4f3b383cf8825197e714a4a21852eca071f8e67e commit r12-2318-g4f3b383cf8825197e714a4a21852eca071f8e67e Author: Richard Biener Date: Fri Jul 9 11:13:11 2021 +0200 driver/101383 - handle -gtoggle in driver The driver amends assembler options with for example --gdwarf-5 when debugging is enabled but the check for that does not consider the effect of -gtoggle which is not handled in the common option machinery. The following alters debug_info_level according to -gtoggle mimicing what process_options later does in the compiler. This in particular avoids changing of the cc1-checksum with every bootstrap (debug) cycle as we compute that from stage2 where we use -g -gtoggle but with --gdwarf-5 and no debug info from the compiler the assembler will fill the line table with the temporary assembler file names. 2021-07-09 Richard Biener PR driver/101383 * gcc.c (process_command): Process -gtoggle like process_options would after parsing options.
[Bug middle-end/101457] [12 regression] new test cases in r12-2300 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101457 Tamar Christina changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org Last reconfirmed||2021-7-15 --- Comment #1 from Tamar Christina --- Sorry about that. These are testism, I'll get them fix. There's a bug in our (aarch64) testsuite when interpreting the result code of run which caused me to miss these during testing.
[Bug c++/101095] Bogus "error: conflicting global module declaration" for abbreviated function template using placeholder type in noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101095 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:0b7a11874d4eb428c18a91f38786032ce0e77a96 commit r12-2313-g0b7a11874d4eb428c18a91f38786032ce0e77a96 Author: Jason Merrill Date: Wed Jul 14 17:10:49 2021 -0400 c++: fix tree_contains_struct for C++ types [PR101095] Many of the types from cp-tree.def were only marked as having tree_common, when actually most of them have type_non_common. This broke g++.dg/modules/xtreme-header-2, as the modules code relies on tree_contains_struct to know what bits it needs to stream. We don't seem to use type_non_common for TYPE_ARGUMENT_PACK, so I bumped it down to TS_TYPE_COMMON. I tried doing the same in cp_tree_size, but that breaks without more extensive changes to tree_node_structure. Why do we need the init_ts function anyway? It seems redundant with tree_node_structure. PR c++/101095 gcc/cp/ChangeLog: * cp-objcp-common.c (cp_common_init_ts): Mark types as types. (cp_tree_size): Remove redundant entries.
[Bug driver/101447] Remove legacy external declarations in toplev.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101447 --- Comment #3 from ashimida --- Submitted at https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575252.html
[Bug middle-end/101397] [11/12 Regression] spurious warning writing to the result of stpcpy minus 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101397 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #3 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575251.html
[Bug target/101456] Unnecessary vzeroupper when upper bits of YMM registers already zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101456 --- Comment #3 from H.J. Lu --- (In reply to Arjan van de Ven from comment #1) > Actually it's not that they're zero (they are) but they're in "init" state > since the vpxor wrote to xmm not ymm We generate: vxorpd %xmm0, %xmm0, %xmm0 # 5 [c=4 l=4] movv4df_internal/0 to zero all bits in YMM and ZMM registers.
[Bug target/101456] Unnecessary vzeroupper when upper bits of YMM registers already zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101456 --- Comment #2 from H.J. Lu --- Created attachment 51153 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51153=edit A patch
[Bug middle-end/101457] New: [12 regression] new test cases in r12-2300 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101457 Bug ID: 101457 Summary: [12 regression] new test cases in r12-2300 fail Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:1e0ab1c4ba6159ad7ce71c6cddd5e04d2a636742, r12-2300: 68 failures FAIL: gcc.dg/vect/vect-reduc-dot-10.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/vect-reduc-dot-10.c execution test FAIL: gcc.dg/vect/vect-reduc-dot-11.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/vect-reduc-dot-11.c execution test FAIL: gcc.dg/vect/vect-reduc-dot-12.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/vect-reduc-dot-12.c execution test FAIL: gcc.dg/vect/vect-reduc-dot-13.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/vect-reduc-dot-13.c execution test FAIL: gcc.dg/vect/vect-reduc-dot-14.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/vect-reduc-dot-14.c execution test FAIL: gcc.dg/vect/vect-reduc-dot-15.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/vect-reduc-dot-15.c execution test FAIL: gcc.dg/vect/vect-reduc-dot-16.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/vect-reduc-dot-16.c execution test FAIL: gcc.dg/vect/vect-reduc-dot-17.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/vect-reduc-dot-17.c execution test FAIL: gcc.dg/vect/vect-reduc-dot-18.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/vect-reduc-dot-18.c execution test FAIL: gcc.dg/vect/vect-reduc-dot-22.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/vect-reduc-dot-22.c execution test FAIL: gcc.dg/vect/vect-reduc-dot-9.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/vect-reduc-dot-9.c execution test There is no output from the failures. Looking at just one of them: Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-10.c -fdiagnostics-plain-output -maltivec -mpower8-vector -ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -lm -o ./vect-reduc-dot-10.exe(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-10.c -fdiagnostics-plain-output -maltivec -mpower8-vector -ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -lm -o ./vect-reduc-dot-10.exe Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled4019628.cc -fdiagnostics-plain-output -S -o exceptions_enabled4019628.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled4019628.cc -fdiagnostics-plain-output -S -o exceptions_enabled4019628.s PASS: gcc.dg/vect/vect-reduc-dot-10.c (test for excess errors) Setting LD_LIBRARY_PATH to :/home/seurer/gcc/git/build/gcc-test/gcc::/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./isl/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-isl/.libs Execution timeout is: 300 spawn [open ...] FAIL: gcc.dg/vect/vect-reduc-dot-10.c execution test PASS: gcc.dg/vect/vect-reduc-dot-10.c scan-tree-dump-not vect "vect_recog_dot_prod_pattern: detected" Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-10.c -fdiagnostics-plain-output -flto -ffat-lto-objects -maltivec -mpower8-vector -ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -lm -o ./vect-reduc-dot-10.exe (timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-10.c -fdiagnostics-plain-output -flto -ffat-lto-objects -maltivec -mpower8-vector -ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -lm -o ./vect-reduc-dot-10.exe PASS: gcc.dg/vect/vect-reduc-dot-10.c -flto -ffat-lto-objects (test for excess errors) Setting LD_LIBRARY_PATH to
[Bug target/101456] Unnecessary vzeroupper when upper bits of YMM registers already zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101456 Arjan van de Ven changed: What|Removed |Added CC||arjan at linux dot intel.com --- Comment #1 from Arjan van de Ven --- Actually it's not that they're zero (they are) but they're in "init" state since the vpxor wrote to xmm not ymm
[Bug target/101456] New: Unnecessary vzeroupper when upper bits of YMM registers already zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101456
Bug ID: 101456
Summary: Unnecessary vzeroupper when upper bits of YMM
registers already zero
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com
Target Milestone: ---
Target: i386, x86-64
Unnecessary vzeroupper:
[hjl@gnu-cfl-2 tmp]$ cat x.c
#include
extern __m256d x;
void
foo (void)
{
x = _mm256_setzero_pd ();
}
[hjl@gnu-cfl-2 tmp]$ gcc -S -O2 x.c -mavx2
c[hjl@gnu-cfl-2 tmp]$ cat x.s
.file "x.c"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB5667:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
vxorpd %xmm0, %xmm0, %xmm0
vmovapd %ymm0, x(%rip)
movq%rsp, %rbp
.cfi_def_cfa_register 6
vzeroupper << Not needed since upper bits of YMM0 are zero.
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE5667:
.size foo, .-foo
.ident "GCC: (GNU) 11.1.1 20210531 (Red Hat 11.1.1-3)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 tmp]$
[Bug tree-optimization/100299] [11 Regression] cc1plus taking all RAM in EVRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100299 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Andrew Macleod --- fixed.
[Bug tree-optimization/101223] [11 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101223 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #15 from Andrew Macleod --- checked into gcc11
[Bug tree-optimization/101223] [11 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101223 --- Comment #14 from CVS Commits --- The releases/gcc-11 branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:b977e6b29c67be81df882d1f5cc7eb6a5d8c98a0 commit r11-8751-gb977e6b29c67be81df882d1f5cc7eb6a5d8c98a0 Author: Andrew MacLeod Date: Wed Jun 30 14:15:53 2021 -0400 Fix build_gt and build_lt for signed 1 bit values. Signed 1 bit values have a range of [-1, 0] but neither (0 - 1) nor (-1 + 1) can be represented. For signed values, add or subtract -1 as appropriate. PR tree-optimization/101223 gcc/ * range-op.cc (build_lt): Add -1 for signed values. (built_gt): Subtract -1 for signed values. gcc/testsuite/ * gcc.dg/pr101223.c: New. (cherry picked from commit 84f7bab89279ca1234fef88929c74caeda8cb55e)
[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101014 --- Comment #21 from CVS Commits --- The releases/gcc-11 branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:85c22c517e9571d1f0f487fd708fbb01f36f172a commit r11-8750-g85c22c517e9571d1f0f487fd708fbb01f36f172a Author: Andrew MacLeod Date: Tue Jun 22 17:46:05 2021 -0400 Do not continue propagating values which cannot be set properly. If the on-entry cache cannot properly represent a range, do not continue trying to propagate it. PR tree-optimization/101148 PR tree-optimization/101014 * gimple-range-cache.cc (ranger_cache::ranger_cache): Adjust. (ranger_cache::~ranger_cache): Adjust. (ranger_cache::block_range): Check if propagation disallowed. (ranger_cache::propagate_cache): Disallow propagation if new value can't be stored properly. * gimple-range-cache.h (ranger_cache::m_propfail): New member.
[Bug tree-optimization/101148] [12 Regression] ranger compile-tme hog when building 527.cam4_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101148 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:85c22c517e9571d1f0f487fd708fbb01f36f172a commit r11-8750-g85c22c517e9571d1f0f487fd708fbb01f36f172a Author: Andrew MacLeod Date: Tue Jun 22 17:46:05 2021 -0400 Do not continue propagating values which cannot be set properly. If the on-entry cache cannot properly represent a range, do not continue trying to propagate it. PR tree-optimization/101148 PR tree-optimization/101014 * gimple-range-cache.cc (ranger_cache::ranger_cache): Adjust. (ranger_cache::~ranger_cache): Adjust. (ranger_cache::block_range): Check if propagation disallowed. (ranger_cache::propagate_cache): Disallow propagation if new value can't be stored properly. * gimple-range-cache.h (ranger_cache::m_propfail): New member.
[Bug tree-optimization/100781] [12 Regression] Emitted binary code changes when -g is enabled at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100781 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:263a7e20c88a35bdfaebfac3c9abb313c5867590 commit r11-8747-g263a7e20c88a35bdfaebfac3c9abb313c5867590 Author: Andrew MacLeod Date: Tue Jun 8 09:43:17 2021 -0400 Don't process lookups for debug statements in Ranger. Although PR 100781 is not an issue in GCC11, its possible that a similar situation may arise. The identical fix cannot be easily introduced. With EVRP always running in hybrid mode, there is no need for ranger to spawn a lookup for a debug statement in this release. * gimple-range.cc (gimple_ranger::range_of_expr): Treat debug statments as contextless queries to avoid additional lookups.
[Bug tree-optimization/100299] [11 Regression] cc1plus taking all RAM in EVRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100299 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:52f0aa4dee8401ef3958dbf789780b0ee877beab commit r11-8746-g52f0aa4dee8401ef3958dbf789780b0ee877beab Author: Andrew MacLeod Date: Mon Jun 7 13:18:55 2021 -0400 Implement a sparse bitmap representation for Rangers on-entry cache. Use a sparse representation for the on entry cache, and utilize it when the number of basic blocks in the function exceeds param_evrp_sparse_threshold. PR tree-optimization/100299 * gimple-range-cache.cc (class sbr_sparse_bitmap): New. (sbr_sparse_bitmap::sbr_sparse_bitmap): New. (sbr_sparse_bitmap::bitmap_set_quad): New. (sbr_sparse_bitmap::bitmap_get_quad): New. (sbr_sparse_bitmap::set_bb_range): New. (sbr_sparse_bitmap::get_bb_range): New. (sbr_sparse_bitmap::bb_range_p): New. (block_range_cache::block_range_cache): initialize bitmap obstack. (block_range_cache::~block_range_cache): Destruct obstack. (block_range_cache::set_bb_range): Decide when to utilze the sparse on entry cache. * gimple-range-cache.h (block_range_cache): Add bitmap obstack. * params.opt (-param=evrp-sparse-threshold): New. (cherry picked from commit 9858cd1a6827ee7a928318acb5e86389f79b4012)
[Bug target/101129] [11/12 Regression] wrong code at -O1 since r11-5839
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101129 --- Comment #8 from Bill Schmidt --- Small change required to actually check that it's a SET insn. (oops) Otherwise looks like it passed regstrap. Testing the revised patch now. Thanks for the pre-review!
[Bug target/101129] [11/12 Regression] wrong code at -O1 since r11-5839
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101129 --- Comment #7 from Segher Boessenkool --- That patch is pre-approved (if it works ;-) ) Bill. Thanks!
[Bug c++/101095] Bogus "error: conflicting global module declaration" for abbreviated function template using placeholder type in noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101095 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 target/101129] [11/12 Regression] wrong code at -O1 since r11-5839
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101129
--- Comment #6 from Bill Schmidt ---
Testing this patch.
diff --git a/gcc/config/rs6000/rs6000-p8swap.c
b/gcc/config/rs6000/rs6000-p8swap.c
index 21cbcb2e28a..00693e6dc60 100644
--- a/gcc/config/rs6000/rs6000-p8swap.c
+++ b/gcc/config/rs6000/rs6000-p8swap.c
@@ -1523,6 +1523,20 @@ replace_swap_with_copy (swap_web_entry *insn_entry,
unsigned i)
insn->set_deleted ();
}
+/* INSN is known to contain a SUBREG, which we can normally handle,
+ but if the SUBREG itself contains a MULT then we need to leave it alone
+ to avoid turning a mult_hipart into a mult_lopart, for example. */
+static bool
+has_part_mult (rtx_insn *insn)
+{
+ rtx body = PATTERN (insn);
+ rtx src = SET_SRC (body);
+ if (GET_CODE (src) != SUBREG)
+return false;
+ rtx inner = XEXP (src, 0);
+ return (GET_CODE (inner) == MULT);
+}
+
/* Make NEW_MEM_EXP's attributes and flags resemble those of
ORIGINAL_MEM_EXP. */
static void
@@ -2501,6 +2515,9 @@ rs6000_analyze_swaps (function *fun)
insn_entry[uid].is_swappable = 0;
else if (special != SH_NONE)
insn_entry[uid].special_handling = special;
+ else if (insn_entry[uid].contains_subreg
+ && has_part_mult (insn))
+ insn_entry[uid].is_swappable = 0;
else if (insn_entry[uid].contains_subreg)
insn_entry[uid].special_handling = SH_SUBREG;
}
[Bug c++/88252] Deduction guide assume the constructor parameter is a forwarding reference if constructor defined outside class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88252 --- Comment #1 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:bebd8e9da838c51a7f911985083d5a2b2498a23a commit r12-2309-gbebd8e9da838c51a7f911985083d5a2b2498a23a Author: Patrick Palka Date: Wed Jul 14 15:37:30 2021 -0400 c++: CTAD and forwarding references [PR88252] Here during CTAD we're incorrectly treating T&& as a forwarding reference even though T is a template parameter of the class template. This happens because the template parameter T in the out-of-line definition of the constructor doesn't have the flag TEMPLATE_TYPE_PARM_FOR_CLASS set, and during duplicate_decls the the redeclaration (which is in terms of this unflagged T) prevails. To fix this, we could perhaps be more consistent about setting the flag, but it appears we don't really need this flag to make the determination. Since the template parameters of an synthesized guide consist of the template parameters of the class template followed by those of the constructor (if any), it should suffice to look at the index of the template parameter to determine whether it comes from the class template or the constructor (template). This patch replaces the TEMPLATE_TYPE_PARM_FOR_CLASS flag with this approach. PR c++/88252 gcc/cp/ChangeLog: * cp-tree.h (TEMPLATE_TYPE_PARM_FOR_CLASS): Remove. * pt.c (push_template_decl): Remove TEMPLATE_TYPE_PARM_FOR_CLASS handling. (redeclare_class_template): Likewise. (forwarding_reference_p): Define. (maybe_adjust_types_for_deduction): Use it instead. Add 'tparms' parameter. (unify_one_argument): Pass tparms to maybe_adjust_types_for_deduction. (try_one_overload): Likewise. (unify): Likewise. (rewrite_template_parm): Remove TEMPLATE_TYPE_PARM_FOR_CLASS handling. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/class-deduction96.C: New test.
[Bug c++/82632] copy deduction candidate erroneously preferred over deduction-guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82632
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #3 from Patrick Palka ---
(In reply to Luke Dalessandro from comment #2)
> Is this demonstrating the same behavior, and is clang wrong to accept?
>
> ```
> template
> struct Foo
> {
> Foo() = default;
> Foo(Foo const&) = delete;
>
> template
> Foo(Foo const&) {}
> };
>
> template
> Foo(Foo) -> Foo;
>
> Foo a;
> Foo b = a;
> ```
>
> https://godbolt.org/z/njqPEKMM1
It seems clang is correct to accept, since a user defined deduction guide is
preferred over an equally specialized copy deduction candidate according to
[over.match.best]. I think this is instead a symptom of the recently fixed
PR86439; GCC trunk accepts this testcase after r12-1744.
Before closing this PR, we ought to add these two testcases to the testsuite.
[Bug inline-asm/101438] Compiler hang on inline asm with local register and VLA operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101438 --- Comment #3 from Andrey Vihrov --- Created attachment 51152 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51152=edit Alternative testcase using __builtin_alloca() Thanks. This code is the result of minimization. It seems that it is sufficient to make inline asm depend on arr in any form. "m"(arr[0]) (and initializing the array element) reproduces the issue as well. I've also attached a similar testcase that compiles and runs at -O0, but hangs the compiler at -O1 (and which likewise references the pointer itself with "m").
[Bug c/101453] ICE on compilable code: *** buffer overflow detected ***: terminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101453 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-07-14 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Keywords||ice-on-invalid-code Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- This is a buffer overflow. char buffer[20]; sprintf (buffer, "-O%ld", (long) TREE_INT_CST_LOW (value)); vec_safe_push (optimize_args, ggc_strdup (buffer)); so a 64bit signed integer max takes 20 bytes. Add in "-O", you are up to 22 bytes and then add the null, you are at 23 bytes. So the fix is simple just increase buffer to be 23. so maybe a better definition is: char buffer[((int)((sizeof(long)*CHARBITS)/3.32))+1+3]; The magic 3.32 is log(10)/log(2) that is for every base 10 digit, it takes ~3.32 bits to represent. The first +1 is a round up because the cast is truncating. The +3 is for "-O" part including the null character.
[Bug target/101153] [12 regression] gcc.target/powerpc/float128-minmax.c fails after r12-1605
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101153 Michael Meissner changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Michael Meissner --- Fixed in: commit 730d021e3e4acc7c0031113ec720c82e31d405e5 Author: Michael Meissner Date: Wed Jun 30 14:54:48 2021 -0400
[Bug middle-end/101437] [12 Regression] ICE: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101437 Andrew Pinski changed: What|Removed |Added Component|c |middle-end --- Comment #6 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #3) > The ICE is because since the above change when we see the empty type > volatile *p = s; store, we gimplify it as s and *p (which seems wrong for > volatiles, because that is load from *p instead of store to *p) and that *p > is gimplified as read from *p into a temporary vol.0 and hits the same case, > where we when we try to gimplify for vol.0 = *p the from_p part *p, we > gimplify it as vol.1 = *p and like that until we eat all of the stack. At first I was trying to understand why a change from zero-sized to empty check would cause a problem but this make sense now. Basically before it was not a zero-sized struct but still empty. And now with the change we go in circles.
[Bug tree-optimization/100081] [11/12 Regression] Compile time hog in irange since r11-4135-ge864d395b4e862ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100081 Andrew Macleod changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Andrew Macleod --- Fixed in both gcc 11 and trunk I believe.
[Bug inline-asm/101438] Compiler hang on inline asm with local register and VLA operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101438 --- Comment #2 from Andrew Pinski --- This code is almost definitely invalid: "m"(arr) You are asigning the array/pointer that the VLA is. This is very much related to PR 71572 for similar reasons.
[Bug target/100809] PPC: __int128 divide/modulo does not use P10 instructions vdivsq/vdivuq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100809 Michael Meissner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Michael Meissner --- Patch applied to mainline and GCC 11 branches. PR closed.
[Bug middle-end/101455] New: missing -Wstringop-overflow on buffer overflow by a complex number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101455
Bug ID: 101455
Summary: missing -Wstringop-overflow on buffer overflow by a
complex number
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The store in the function below overflows the buffer and should be diagnosed by
-Wstringop-overflow (which is enabled by default) but isn't. It's only
diagnosed by -Warray-bounds (which is included in -Wall).
$ cat a.c && gcc -O2 -S -fdump-tree-strlen=/dev/stdout a.c
void* f (double x, double i)
{
_Complex double *p = __builtin_malloc (sizeof (double));
*p = __builtin_complex (x, i);
return p;
}
;; Function f (f, funcdef_no=0, decl_uid=1944, cgraph_uid=1, symbol_order=0)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
void * f (double x, double i)
{
complex double * p;
[local count: 1073741824]:
p_3 = __builtin_malloc (8);
REALPART_EXPR <*p_3> = x_4(D);
IMAGPART_EXPR <*p_3> = i_5(D);
return p_3;
}
[Bug target/100809] PPC: __int128 divide/modulo does not use P10 instructions vdivsq/vdivuq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100809 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Michael Meissner : https://gcc.gnu.org/g:8ebcd3608584e544ae8e7c422b3f2400758c47f5 commit r11-8743-g8ebcd3608584e544ae8e7c422b3f2400758c47f5 Author: Michael Meissner Date: Wed Jul 14 13:23:51 2021 -0400 Generate 128-bit int divide/modulus on power10. This patch adds support for the VDIVSQ, VDIVUQ, VMODSQ, and VMODUQ instructions to do 128-bit arithmetic. Backported from master: 2021-07-07 Michael Meissner 2021-07-14 Michael Meissner gcc/ PR target/100809 * config/rs6000/rs6000.md (udivti3): New insn. (divti3): New insn. (umodti3): New insn. (modti3): New insn. gcc/testsuite/ PR target/100809 * gcc.target/powerpc/p10-vdivq-vmodq.c: New test.
[Bug debug/101454] New: debug info for unreachable var forces another var to be output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101454 Bug ID: 101454 Summary: debug info for unreachable var forces another var to be output Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: aoliva at gcc dot gnu.org Target Milestone: --- If some IPA pass replaces the only reference to a constant non-public non-automatic variable with its initializer, namely the address of another such variable, the former becomes unreferenced and it's discarded by symbol_table::remove_unreachable_nodes. It calls debug_hooks->late_global_decl while at that, and this expands the initializer, which assigs RTL to the latter variable and forces it to be retained by remove_unreferenced_decls, and eventually be output despite not being referenced. Without debug information, it's not output. This has caused a bootstrap-debug compare failure in libdecnumber/decContext.o, while developing a transformation that ends up enabling the above substitution in constprop. I've proposed a patch that makes reference_to_unused slightly more conservative about such variables at the end of IPA passes, falling back onto expand_debug_expr for expressions referencing symbols that might or might not be output, avoiding the loss of debug information when the symbol is output, while avoiding a symbol output only because of debug info. https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575043.html richi suggested using symbolic DIE references, later resolved by note_variable_values. Maybe we do this unconditionally for the initializers of removed decls. That seems doable and desirable. decContext.c doesn't generate location or const_value for neither mfctop nor mfcone, even after removing rtl_for_decl_location from add_location_or_const_value_attribute, despite lookup_decl_loc's finding a location expression. Alas, I haven't managed to come up with a testcase to trigger the problem without the patchset that I'm not yet ready to contribute. https://gcc.gnu.org/pipermail/gcc/2021-July/236780.html The kicker, in case someone wants to force it, is that at materialize_all_clones, the reference to mfctop in a constprop-ed decContextTestEndian gets substituted by its constant initializer, , so mfctop becomes unreachable and goes through late_global_decl in remove_unreachable_nodes. Eventually, ccp2 resolves the mfcone dereference to a constant, and no reason remains for mfcone to be output. However, when outputting debug info, the expand_expr of mfctop's initializer will have already generated RTL for mfcone, committing it to be output, wehreas without debug info, mfcone is not output at all. What enables these transformations during IPA is the introduction of a wrapper for decContextTestEndian, moving its body to a clone that is materialized early, at the end of all_small_ipa_passes. This clone, being a local function, seems to be what enables the substitution of the mfctop constant initializer. I haven't found a way to cause such a difference without my pass, even getting a constprop (local) clone for the function, and preventing its inlining into an exported function. Hopefully this is enough information to enable the issue to be investigated.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #236 from The Written Word --- (In reply to John Buddery from comment #235) > Interesting - that's with a 32 bit gas? $ file bin/gcc111/ia64-hp-hpux11.31/bin/as bin/gcc111/ia64-hp-hpux11.31/bin/as:ELF-32 executable object file - IA64 $% bin/gcc111/ia64-hp-hpux11.31/bin/as --version GNU assembler (GNU Binutils) 2.30 Copyright (C) 2018 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `ia64-hp-hpux11.31'. > It could be a change between 2.30 and 2.36 I guess, I might see if I can > narrow it down. We prefer to build with HP C and only use GCC when we must. 2.36 didn't build as easily out-of-the-box with HP C and we haven't tried to fix it so we've stuck with 2.30 for newer GCC releases.
[Bug target/67288] [9/10/11/12 regression] non optimal simple function (useless additional shift/remove/shift/add)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288 --- Comment #23 from Segher Boessenkool --- -m32 is required here. With -fno-unroll-loops -m32 you now get flush_dcache_range: rlwinm 3,3,0,0,27 addi 4,4,15 subf 4,3,4 srwi. 4,4,4 beqlr 0 mtctr 4 .p2align 4,,15 .L3: dcbf 0, 3 addi 3,3,16 bdnz .L3 sync blr So yup, it has been fixed. Thanks!
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #235 from John Buddery --- Interesting - that's with a 32 bit gas ? It does look like you have got past the point in stage1 where ld was crashing. It could be a change between 2.30 and 2.36 I guess, I might see if I can narrow it down.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #234 from The Written Word --- (In reply to John Buddery from comment #233) > One additional note - when building the patched binutils 2.36, it must be > built as 64 bit executables. > > It seems that a 32 bit gas does not produce 64 bit object files properly on > this platform, causing the linker to crash when making the 64 bit > libstdc++.so. > > Build binutils as 64 bit, by using a configure something like: > > CFLAGS="-O2 -mlp64" ./configure -prefix=/usr/local Odd. We currently have a build of 11.1.0 going with as from binutils-2.30 built using the HP C compiler and: $ file ./.o/prev-ia64-hp-hpux11.31/libstdc++-v3/src/.libs/libstdc++.so ./.o/prev-ia64-hp-hpux11.31/hpux64/libstdc++-v3/src/.libs/libstdc++.so ./.o/prev-ia64-hp-hpux11.31/libstdc++-v3/src/.libs/libstdc++.so:ELF-32 shared object file - IA64 ./.o/prev-ia64-hp-hpux11.31/hpux64/libstdc++-v3/src/.libs/libstdc++.so: ELF-64 shared object file - IA64
[Bug c++/101361] Bogus -Wstringop-overread warning with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101361 Jonathan Wakely changed: What|Removed |Added Component|libstdc++ |c++ --- Comment #11 from Jonathan Wakely --- Changing component back to c++ for the remaining issue with the original testcase in comment 0.
[Bug libstdc++/101411] missing constraint in std::as_writable_bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101411 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely --- Fixed for 10.4 and 11.2
[Bug libstdc++/101361] Bogus -Wstringop-overread warning with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101361 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a8ae5dbc60eedade3514e51e3cb35fd28ec1d4c8 commit r10-9982-ga8ae5dbc60eedade3514e51e3cb35fd28ec1d4c8 Author: Jonathan Wakely Date: Tue Jul 13 12:21:27 2021 +0100 libstdc++: Simplify basic_string_view::ends_with [PR 101361] The use of npos triggers a diagnostic as described in PR c++/101361. This change replaces the use of npos with the exact length, which is already known. We can further simplify it by inlining the effects of compare and substr, avoiding the redundant range checks in the latter. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR c++/101361 * include/std/string_view (ends_with): Use traits_type::compare directly. (cherry picked from commit 4d3eaeb4f505b0838c673ee28e7dba8687fc8272)
[Bug libstdc++/101411] missing constraint in std::as_writable_bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101411 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a34c0973c994d750fb1231da7af96038417b7fe3 commit r10-9981-ga34c0973c994d750fb1231da7af96038417b7fe3 Author: Jonathan Wakely Date: Mon Jul 12 16:09:34 2021 +0100 libstdc++: Constrain std::as_writable_bytes [PR101411] The std::as_writable_bytes function should be constrained to only accept writable spans. Currently it can be called but then gives an error in the function body. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/101411 * include/std/span (as_writable_bytes): Add requires-clause. * testsuite/23_containers/span/101411.cc: New test. (cherry picked from commit 9d4393af9d2b37b78eb5b1f84f5d4da3a6f7fba6)
[Bug c++/101371] [9/10/11 Regression] constexpr expansions trigger internal Compiler Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101371 Marek Polacek changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[9/10/11 Regression] |constexpr expansions|constexpr expansions |trigger internal Compiler |trigger internal Compiler |Error |Error --- Comment #7 from Marek Polacek --- Fixed on trunk so far.
[Bug c/101453] New: ICE on compilable code: *** buffer overflow detected ***: terminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101453
Bug ID: 101453
Summary: ICE on compilable code: *** buffer overflow detected
***: terminated
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cnsun at uwaterloo dot ca
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.Rxxf6w92un-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210714 (experimental) [master revision
:8b95b2de5:a7098d6ef4e4e799dab8ef925c62b199d707694b] (GCC)
$ cat mutant.c
__attribute__((optimize(0x8080808080808080ull))) bak() {}
$ gcc-trunk mutant.c
*** buffer overflow detected ***: terminated
mutant.c:1:1: internal compiler error: Aborted
1 | __attribute__((optimize(0x8080808080808080ull))) bak() {}
| ^
0xf27883 crash_signal
/tmp/tmp.Rxxf6w92un-gcc-builder/gcc/gcc/toplev.c:328
0x9a0bb3 sprintf
/usr/include/x86_64-linux-gnu/bits/stdio2.h:36
0x9a0bb3 parse_optimize_options(tree_node*, bool)
/tmp/tmp.Rxxf6w92un-gcc-builder/gcc/gcc/c-family/c-common.c:5802
0x9e54a8 handle_optimize_attribute
/tmp/tmp.Rxxf6w92un-gcc-builder/gcc/gcc/c-family/c-attribs.c:5395
0x8e5f76 decl_attributes(tree_node**, tree_node*, int, tree_node*)
/tmp/tmp.Rxxf6w92un-gcc-builder/gcc/gcc/attribs.c:720
0x902f77 start_function(c_declspecs*, c_declarator*, tree_node*)
/tmp/tmp.Rxxf6w92un-gcc-builder/gcc/gcc/c/c-decl.c:9452
0x96095e c_parser_declaration_or_fndef
/tmp/tmp.Rxxf6w92un-gcc-builder/gcc/gcc/c/c-parser.c:2440
0x968e33 c_parser_external_declaration
/tmp/tmp.Rxxf6w92un-gcc-builder/gcc/gcc/c/c-parser.c:1777
0x969899 c_parser_translation_unit
/tmp/tmp.Rxxf6w92un-gcc-builder/gcc/gcc/c/c-parser.c:1650
0x969899 c_parse_file()
/tmp/tmp.Rxxf6w92un-gcc-builder/gcc/gcc/c/c-parser.c:22121
0x9cb935 c_common_parse_file()
/tmp/tmp.Rxxf6w92un-gcc-builder/gcc/gcc/c-family/c-opts.c:1219
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #233 from John Buddery --- One additional note - when building the patched binutils 2.36, it must be built as 64 bit executables. It seems that a 32 bit gas does not produce 64 bit object files properly on this platform, causing the linker to crash when making the 64 bit libstdc++.so. Build binutils as 64 bit, by using a configure something like: CFLAGS="-O2 -mlp64" ./configure -prefix=/usr/local
[Bug fortran/100949] [9/10/11/12 Regression] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1975
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100949 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:269ca408e2839d7f3554a91515d73d4d95352f68 commit r12-2303-g269ca408e2839d7f3554a91515d73d4d95352f68 Author: Harald Anlauf Date: Wed Jul 14 17:25:29 2021 +0200 Fortran - ICE in gfc_conv_expr_present initializing non-dummy class variable gcc/fortran/ChangeLog: PR fortran/100949 * trans-expr.c (gfc_trans_class_init_assign): Call gfc_conv_expr_present only for dummy variables. gcc/testsuite/ChangeLog: PR fortran/100949 * gfortran.dg/pr100949.f90: New test.
[Bug target/101448] Use GCC 9.3.0 to build Ceph crimson-osd on Arm64, linker failed for relocation truncated to fit: R_AARCH64_CALL26 against symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101448 --- Comment #3 from Richard Earnshaw --- What optimization level are you building with? The R_AARCH64_CALL26 relocation has a branch range of +/-2^27 bytes, or 128MBytes, so that puts a limit on the size of the code segment of a binary. If you're not building with optimization turned on code can bloat very quickly. You could try just -Og if you want minimal optimization or -Os if you really want to reduce code size as much as possible.
[Bug c/101446] -Wpedantic causes an error with zero size array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101446 --- Comment #8 from joseph at codesourcery dot com --- I think this is a bug. Negative-size arrays are an unconditional error. Zero-size arrays should be a pedwarn-if-pedantic, regardless of whether the 0 is explicit or deduced from an initializer.
[Bug libstdc++/101361] Bogus -Wstringop-overread warning with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101361 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:96205c97294d5db94bd89cd731830058d9c49abd commit r11-8741-g96205c97294d5db94bd89cd731830058d9c49abd Author: Jonathan Wakely Date: Tue Jul 13 12:21:27 2021 +0100 libstdc++: Simplify basic_string_view::ends_with [PR 101361] The use of npos triggers a diagnostic as described in PR c++/101361. This change replaces the use of npos with the exact length, which is already known. We can further simplify it by inlining the effects of compare and substr, avoiding the redundant range checks in the latter. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR c++/101361 * include/std/string_view (ends_with): Use traits_type::compare directly. (cherry picked from commit 4d3eaeb4f505b0838c673ee28e7dba8687fc8272)
[Bug libstdc++/101411] missing constraint in std::as_writable_bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101411 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:df115674b39d4004252b7d5e41d9751f2b77b0d8 commit r11-8739-gdf115674b39d4004252b7d5e41d9751f2b77b0d8 Author: Jonathan Wakely Date: Mon Jul 12 16:09:34 2021 +0100 libstdc++: Constrain std::as_writable_bytes [PR101411] The std::as_writable_bytes function should be constrained to only accept writable spans. Currently it can be called but then gives an error in the function body. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/101411 * include/std/span (as_writable_bytes): Add requires-clause. * testsuite/23_containers/span/101411.cc: New test. (cherry picked from commit 9d4393af9d2b37b78eb5b1f84f5d4da3a6f7fba6)
[Bug target/101448] Use GCC 9.3.0 to build Ceph crimson-osd on Arm64, linker failed for relocation truncated to fit: R_AARCH64_CALL26 against symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101448 --- Comment #2 from Kevin Zhao --- Hi Richard, Thanks for your comments. Since we have built this with some of the .so file with -fPIC, and -mcmodel=large is incompatible with -fPIC, so rebuild with -mcmodel is hard to achieve.
[Bug debug/101452] New: [debug, dwarf-5] undefined static member removed by -feliminate-unused-debug-symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101452
Bug ID: 101452
Summary: [debug, dwarf-5] undefined static member removed by
-feliminate-unused-debug-symbols
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Test-case:
...
$ cat test.c
struct a {
int a;
static int sa;
};
int
main (void)
{
struct a a;
a.a = 1;
return 0;
}
...
Compile with dwarf v4:
...
$ ./install/bin/g++ test.c -c -g -gdwarf-4
$ readelf -wi test.o
...
<1><2d>: Abbrev Number: 2 (DW_TAG_structure_type)
<2e> DW_AT_name: a
...
<2><38>: Abbrev Number: 3 (DW_TAG_member)
<39> DW_AT_name: a
...
<2><43>: Abbrev Number: 4 (DW_TAG_member)
<44> DW_AT_name: sa
...
<2><4e>: Abbrev Number: 0
...
Compile with dwarf v5:
...
$ ./install/bin/g++ test.c -c -g -gdwarf-5
$ readelf -wi test.o
...
<1><2e>: Abbrev Number: 2 (DW_TAG_structure_type)
<2f> DW_AT_name: a
...
<2><39>: Abbrev Number: 3 (DW_TAG_member)
<3a> DW_AT_name: a
...
<2><44>: Abbrev Number: 0
...
The sa member is dropped by -feliminate-unused-debug-symbols.
Fixed by:
...
$ git diff
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 82783c4968b..fa9a97f3ebb 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -29952,7 +29952,8 @@ prune_unused_types_walk (dw_die_ref die)
if (get_AT (die, DW_AT_external))
{
for (c = die->die_parent; c; c = c->die_parent)
- if (c->die_tag == DW_TAG_subprogram)
+ if (c->die_tag == DW_TAG_subprogram
+ || c->die_tag == DW_TAG_structure_type)
break;
if (!c)
return;
...
Note that actually defining the var using this:
...
int a::sa;
...
also brings back the missing DIE.
[Bug c/101451] New: Incorrect -Wstringop-truncation warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101451
Bug ID: 101451
Summary: Incorrect -Wstringop-truncation warning
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: quentin at armitage dot org.uk
Target Milestone: ---
Created attachment 51151
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51151=edit
The .i file produced by the compile command
Command: gcc -v -save-temps -Wstringop-truncation -O2 -o strncat1 strncat1.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-11.1.1-20210531/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.1 20210531 (Red Hat 11.1.1-3) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wstringop-truncation' '-O2' '-o'
'strncat1' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/11/cc1 -E -quiet -v strncat1.c
-mtune=generic -march=x86-64 -Wstringop-truncation -O2 -fpch-preprocess -o
strncat1.i
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/11/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/11/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-redhat-linux/11/include
/usr/local/include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wstringop-truncation' '-O2' '-o'
'strncat1' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/11/cc1 -fpreprocessed strncat1.i -quiet
-dumpbase strncat1.c -dumpbase-ext .c -mtune=generic -march=x86-64 -O2
-Wstringop-truncation -version -o strncat1.s
GNU C17 (GCC) version 11.1.1 20210531 (Red Hat 11.1.1-3) (x86_64-redhat-linux)
compiled by GNU C version 11.1.1 20210531 (Red Hat 11.1.1-3), GMP
version 6.2.0, MPFR version 4.1.0-p13, MPC version 1.2.1, isl version
isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 11.1.1 20210531 (Red Hat 11.1.1-3) (x86_64-redhat-linux)
compiled by GNU C version 11.1.1 20210531 (Red Hat 11.1.1-3), GMP
version 6.2.0, MPFR version 4.1.0-p13, MPC version 1.2.1, isl version
isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 147699dd2c10be2630d381074a06fb9f
strncat1.c: In function ‘bad’:
strncat1.c:12:30: warning: ‘strncat’ output may be truncated copying 15 bytes
from a string of length 15 [-Wstringop-truncation]
12 | do { dest[0] = '\0'; strncat(dest, src, sizeof(dest) - 1); }
while (0);
| ^~~~
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wstringop-truncation' '-O2' '-o'
'strncat1' '-mtune=generic' '-march=x86-64'
as -v --64 -o strncat1.o strncat1.s
GNU assembler version 2.35.1 (x86_64-redhat-linux) using BFD version version
2.35.1-41.fc34
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/11/:/usr/libexec/gcc/x86_64-redhat-linux/11/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/11/:/usr/lib/gcc/x86_64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/11/:/usr/lib/gcc/x86_64-redhat-linux/11/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/11/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wstringop-truncation' '-O2' '-o'
'strncat1' '-mtune=generic' '-march=x86-64' '-dumpdir' 'strncat1.'
/usr/libexec/gcc/x86_64-redhat-linux/11/collect2 -plugin
/usr/libexec/gcc/x86_64-redhat-linux/11/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/11/lto-wrapper
-plugin-opt=-fresolution=strncat1.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o strncat1
[Bug tree-optimization/99728] code pessimization when using wrapper classes around SIMD types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728
--- Comment #19 from Richard Biener ---
Created attachment 51150
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51150=edit
patch
This is what I bootstrapped & tested on x86_64-unknown-linux-gnu. It causes
FAIL: g++.dg/warn/Wparentheses-22.C -std=gnu++14 correct warning (test for
warnings, line 104)
FAIL: g++.dg/warn/Wparentheses-22.C -std=gnu++14 correct warning (test for
warnings, line 33)
...
FAIL: g++.dg/warn/Wparentheses-23.C -std=gnu++14 (test for warnings, line
117)
FAIL: g++.dg/warn/Wparentheses-23.C -std=gnu++14 (test for warnings, line
118)
...
interfering with the intent to warn about code like
if (a = b) // { dg-warning "assignment" "correct warning" }
foo (0);
where a and b are aggregates convertible to bool. We end up generating
something that acts as a valid "fix" for the diagnostic:
if ((a = b), a)
similarly we'd beforehand not diagnose the case of an empty aggregate
assignment not wrapped in parentheses.
Adjusting the warning code to also look for the COMPOUND_EXPR case
wouldn't be valid if we'd not somehow mark those "fake" COMPOUND_EXPRs
in a special way.
Not sure what to do here. Maybe simply ignore the lost diagnostic and
XFAIL the testcase or adjust it to have a second member in the aggregate
used.
[Bug target/93897] Poor trivial structure initialization code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93897
--- Comment #7 from H.J. Lu ---
Another testcase:
[hjl@gnu-cfl-1 tmp]$ cat x.c
extern int foo();
extern int bar();
typedef int (*func_t)(int);
struct test
{
func_t func1;
func_t func2;
};
void mainfunc (struct test *iface)
{
iface->func1 = foo;
iface->func2 = bar;
}
[hjl@gnu-cfl-1 tmp]$ gcc -S -O2 x.c
[hjl@gnu-cfl-1 tmp]$ cat x.s
.file "x.c"
.text
.p2align 4
.globl mainfunc
.type mainfunc, @function
mainfunc:
.LFB0:
.cfi_startproc
movq$foo, (%rdi)
movq$bar, 8(%rdi)
ret
.cfi_endproc
.LFE0:
.size mainfunc, .-mainfunc
.ident "GCC: (GNU) 11.1.1 20210531 (Red Hat 11.1.1-3)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 tmp]$ gcc -S -O3 x.c -march=skylake
[hjl@gnu-cfl-1 tmp]$ cat x.s
.file "x.c"
.text
.p2align 4
.globl mainfunc
.type mainfunc, @function
mainfunc:
.LFB0:
.cfi_startproc
movl$foo, %edx
movl$bar, %eax
vmovq %rdx, %xmm0
vpinsrq $1, %rax, %xmm0, %xmm0
vmovdqu %xmm0, (%rdi)
ret
.cfi_endproc
.LFE0:
.size mainfunc, .-mainfunc
.ident "GCC: (GNU) 11.1.1 20210531 (Red Hat 11.1.1-3)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 tmp]$
[Bug target/101448] Use GCC 9.3.0 to build Ceph crimson-osd, linker failed for "relocation truncated to fit" against symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101448 Richard Biener changed: What|Removed |Added Target||aarch64 Component|c++ |target --- Comment #1 from Richard Biener --- Can you try compiling with -mcmodel=large? OTOH 2G size should be within the 4G limit of the standard small model.
[Bug tree-optimization/101450] GCC doesn't vectorize loop due to evolution of base is not affine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101450 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-07-14 Blocks||53947 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Yes, as I said in some other PRs the SCEV framework would need to be extended to track 'assumptions' under which its result would be valid, much like niter analysis does. Currently it simply gives up here. Of course 'assumptions' would need support from quite some mid-stream infrastructure and some way to carry it since currently a SCEV is a tree expression. Thus it's quite some work to do this. The mid-stream users is mostly data dependence analysis. There's effective duplicates of this bug. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug c++/59314] [DR 1054] [C++11] access to volatile through reference should cause load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59314
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2021-07-14
Known to fail||12.0
Status|UNCONFIRMED |NEW
Keywords||wrong-code
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
> ./cc1plus -quiet t.ii -std=c++03
t.ii: In function 'void foo()':
t.ii:5:5: warning: implicit dereference will not access object of type
'volatile int' in statement
5 | r;
| ^
> ./cc1plus -quiet t.ii -std=c++11
t.ii: In function 'void foo()':
t.ii:5:5: warning: implicit dereference will not access object of type
'volatile int' in statement
5 | r;
| ^
> cat t.ii
void foo()
{
volatile int i=0;
volatile int& r = i;
r;
}
[Bug c++/69494] Optimizer eliminates assignment to volatile subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69494 --- Comment #5 from Richard Biener --- Note since 'dev' is an automatic variable which address doesn't escape there's no way to observe the access thus GCC is correct in eliding it. We could behave the same as we do for a volatile automatic variable which we seem to instantinate on the stack quite easily though when we compute forced_stack_vars in cfgexpand.c
[Bug target/101395] [11/12 regression] Compile failure with -march=native -m32 on sapphirerapids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101395 --- Comment #12 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:cc11b924bfe7752edbba052ca71653f46a60887a commit r12-2296-gcc11b924bfe7752edbba052ca71653f46a60887a Author: H.J. Lu Date: Fri Jul 9 09:16:01 2021 -0700 x86: Don't enable UINTR in 32-bit mode UINTR is available only in 64-bit mode. Since the codegen target is unknown when the the gcc driver is processing -march=native, to properly handle UINTR for -march=native: 1. Pass "arch [32|64]" and "tune [32|64]" to host_detect_local_cpu to indicate 32-bit and 64-bit codegen. 2. Change ix86_option_override_internal to enable UINTR only in 64-bit mode for -march=CPU when PTA_CPU includes PTA_UINTR. gcc/ PR target/101395 * config/i386/driver-i386.c (host_detect_local_cpu): Check "arch [32|64]" and "tune [32|64]" for 32-bit and 64-bit codegen. Enable UINTR only for 64-bit codegen. * config/i386/i386-options.c (ix86_option_override_internal::DEF_PTA): Skip PTA_UINTR if not in 64-bit mode. * config/i386/i386.h (ARCH_ARG): New. (CC1_CPU_SPEC): Pass "[arch|tune] 32" for 32-bit codegen and "[arch|tune] 64" for 64-bit codegen. gcc/testsuite/ PR target/101395 * gcc.target/i386/pr101395-1.c: New test. * gcc.target/i386/pr101395-2.c: Likewise. * gcc.target/i386/pr101395-3.c: Likewise.
[Bug target/101142] [11 regression] Regression due to supporting bitwise operators on AVX512 masks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101142 --- Comment #8 from Hongtao.liu --- (In reply to Hongtao.liu from comment #6) > Not sure backport to GCC11, this patch only modifies the cost model of RA on > the back end, no functional changes. Backport to GCC11, along with r12-1800
[Bug target/101185] [12 Regression] pr96814.c failed after r12-1669 on non-avx512 platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101185 --- Comment #15 from CVS Commits --- The releases/gcc-11 branch has been updated by hongtao Liu : https://gcc.gnu.org/g:5bde7650caa84aa1dee979122834619a8cc748d4 commit r11-8738-g5bde7650caa84aa1dee979122834619a8cc748d4 Author: liuhongt Date: Thu Jun 24 16:14:13 2021 +0800 Revert x86_order_regs_for_local_alloc changes in r12-1669. Still put general regs as first alloca order. gcc/ChangeLog: PR target/101185 * config/i386/i386.c (x86_order_regs_for_local_alloc): Revert r12-1669. gcc/testsuite/ChangeLog PR target/101185 * gcc.target/i386/bitwise_mask_op-3.c: Add xfail to temporarily avoid regression, eventually xfail should be removed.
[Bug target/101142] [11 regression] Regression due to supporting bitwise operators on AVX512 masks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101142 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by hongtao Liu : https://gcc.gnu.org/g:c34da273aa1f3f2f5457c43dd815fd0ee8c3b627 commit r11-8737-gc34da273aa1f3f2f5457c43dd815fd0ee8c3b627 Author: liuhongt Date: Tue Jun 15 16:25:16 2021 +0800 Disparage slightly the mask register alternative for bitwise operations. The avx512 supports bitwise operations with mask registers, but the throughput of those instructions is much lower than that of the corresponding gpr version, so we would additionally disparages slightly the mask register alternative for bitwise operations in the LRA. Also when allocano cost of GENERAL_REGS is same as MASK_REGS, allocate MASK_REGS first since it has already been disparaged. gcc/ChangeLog: PR target/101142 * config/i386/i386.md: (*anddi_1): Disparage slightly the mask register alternative. (*and_1): Ditto. (*andqi_1): Ditto. (*andn_1): Ditto. (*_1): Ditto. (*qi_1): Ditto. (*one_cmpl2_1): Ditto. (*one_cmplsi2_1_zext): Ditto. (*one_cmplqi2_1): Ditto. * config/i386/i386.c (x86_order_regs_for_local_alloc): Change the order of mask registers to be before general registers. gcc/testsuite/ChangeLog: PR target/101142 * gcc.target/i386/spill_to_mask-1.c: Adjust testcase. * gcc.target/i386/spill_to_mask-2.c: Adjust testcase. * gcc.target/i386/spill_to_mask-3.c: Adjust testcase. * gcc.target/i386/spill_to_mask-4.c: Adjust testcase.
[Bug tree-optimization/101450] New: GCC doesn't vectorize loop due to evolution of base is not affine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101450
Bug ID: 101450
Summary: GCC doesn't vectorize loop due to evolution of base is
not affine.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
the testcase is extracted from coremark
cat test.c
void
matrix_add_const(unsigned int N, short *A, short val)
{
unsigned int i, j;
for (i = 0; i < N; i++)
{
for (j = 0; j < N; j++)
{
A[i * N + j] += val;
}
}
}
gcc failed to vectorize it since there could be wrap for i*N + j, but we can do
multi-versioning for it?
llvm seems does that.
https://godbolt.org/z/Er44ffTE3
[Bug c/101437] [12 Regression] ICE: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101437 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Jakub Jelinek --- Created attachment 51149 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51149=edit gcc12-pr101437.patch Untested fix.
[Bug tree-optimization/99728] code pessimization when using wrapper classes around SIMD types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728
--- Comment #18 from Richard Biener ---
OTOH we call is_really_empty_class which for not trivially empty classes ends
up
walking all non-FIELD_DECL fields as well:
for (field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
if (TREE_CODE (field) == FIELD_DECL
&& !DECL_ARTIFICIAL (field)
/* An unnamed bit-field is not a data member. */
&& !DECL_UNNAMED_BIT_FIELD (field)
&& !is_really_empty_class (TREE_TYPE (field), ignore_vptr))
return false;
So the following performs single-member copying optimization (also avoiding
the as-base special-casing when the copy involves a single member). The
copy_single_member function is based on is_really_empty_class which could
be refactored to also compute this as alternate output. In principle the
single member to copy could be inside an aggregate member/base so as-is
this doesn't always avoid an aggregate copy if the single member in 'type'
is an aggregate. It fixes the testcase fully.
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index e4df72ec1a3..31eea7c935b 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8881,6 +8881,41 @@ immediate_invocation_p (tree fn, int nargs)
&& (nargs > 1 || !source_location_current_p (fn)));
}
+/* Return the FIELD_DECL of the single member of TYPE that needs to be copied
+ by copy assignment if any or NULL_TREE if there are none or multiple. */
+
+static tree
+copy_single_member (tree type)
+{
+ if (!CLASS_TYPE_P (type))
+return NULL_TREE;
+
+ tree binfo;
+ tree base_binfo;
+ int i;
+ for (binfo = TYPE_BINFO (type), i = 0;
+ BINFO_BASE_ITERATE (binfo, i, base_binfo); ++i)
+if (!is_really_empty_class (BINFO_TYPE (base_binfo), true))
+ return NULL_TREE;
+
+ tree single_field = NULL_TREE;
+ for (tree field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
+{
+ if (TREE_CODE (field) != FIELD_DECL)
+ continue;
+ if (!(!DECL_ARTIFICIAL (field)
+ /* An unnamed bit-field is not a data member. */
+ && !DECL_UNNAMED_BIT_FIELD (field)
+ && !is_really_empty_class (TREE_TYPE (field), true)))
+ continue;
+ if (single_field)
+ return NULL_TREE;
+ single_field = field;
+}
+
+ return single_field;
+}
+
/* Subroutine of the various build_*_call functions. Overload resolution
has chosen a winning candidate CAND; build up a CALL_EXPR accordingly.
ARGS is a TREE_LIST of the unconverted arguments to the call. FLAGS is a
@@ -9501,6 +9536,16 @@ build_over_call (struct z_candidate *cand, int flags,
tsubst_flags_t complain)
val = build2 (COMPOUND_EXPR, type, arg, to);
suppress_warning (val, OPT_Wunused);
}
+ else if (tree field = copy_single_member (type))
+ {
+ arg = cp_build_fold_indirect_ref (arg);
+ tree t = build2 (MODIFY_EXPR, TREE_TYPE (field),
+ build3 (COMPONENT_REF, TREE_TYPE (field),
+ to, field, NULL_TREE),
+ build3 (COMPONENT_REF, TREE_TYPE (field),
+ arg, field, NULL_TREE));
+ val = build2 (COMPOUND_EXPR, type, t, to);
+ suppress_warning (val, OPT_Wunused);
+ }
else if (tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE (as_base)))
{
if (is_std_init_list (type)
[Bug tree-optimization/101445] [11/12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101445 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Known to fail||11.1.0 Status|ASSIGNED|RESOLVED Known to work||11.1.1, 12.0 --- Comment #7 from Richard Biener --- Fixed.
[Bug tree-optimization/101445] [11/12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101445 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:1eee5fa556432fb6eab3a479c95609c5f3791ccb commit r11-8736-g1eee5fa556432fb6eab3a479c95609c5f3791ccb Author: Richard Biener Date: Wed Jul 14 11:06:58 2021 +0200 tree-optimization/101445 - fix negative stride SLP vect with gaps The following fixes the IV adjustment for the gap in a negative stride SLP vectorization. The adjustment was in the wrong direction, now fixes as in the patch. 2021-07-14 Richard Biener PR tree-optimization/101445 * tree-vect-stmts.c (vectorizable_load): Do the gap adjustment of the IV in the correct direction for negative stride accesses. * gcc.dg/vect/pr101445.c: New testcase. (cherry picked from commit a967a3efd39280fe3f5774e45490e991f8e99059)
[Bug c/101437] [12 Regression] ICE: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101437
--- Comment #4 from Jakub Jelinek ---
struct S { int : 1; };
void
bar (volatile struct S *p)
{
*p;
}
ICEs too.
[Bug c/101437] [12 Regression] ICE: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101437
Jakub Jelinek changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
The ICE is because since the above change when we see the empty type volatile
*p = s; store, we gimplify it as s and *p (which seems wrong for volatiles,
because that is load from *p instead of store to *p) and that *p is gimplified
as read from *p into a temporary vol.0 and hits the same case, where we when we
try to gimplify for vol.0 = *p the from_p part *p, we gimplify it as vol.1 = *p
and like that until we eat all of the stack.
The difference between the struct S {}; case that was handled like that forever
and worked fine is in:
else if (COMPLETE_TYPE_P (TREE_TYPE (*expr_p))
&& TYPE_MODE (TREE_TYPE (*expr_p)) != BLKmode)
{
/* Historically, the compiler has treated a bare reference
to a non-BLKmode volatile lvalue as forcing a load. */
tree type = TYPE_MAIN_VARIANT (TREE_TYPE (*expr_p));
/* Normally, we do not want to create a temporary for a
TREE_ADDRESSABLE type because such a type should not be
copied by bitwise-assignment. However, we make an
exception here, as all we are doing here is ensuring that
we read the bytes that make up the type. We use
create_tmp_var_raw because create_tmp_var will abort when
given a TREE_ADDRESSABLE type. */
tree tmp = create_tmp_var_raw (type, "vol");
gimple_add_tmp_var (tmp);
gimplify_assign (tmp, *expr_p, pre_p);
*expr_p = NULL;
}
else
/* We can't do anything useful with a volatile reference to
an incomplete type, so just throw it away. Likewise for
a BLKmode type, since any implicit inner load should
already have been turned into an explicit one by the
gimplification process. */
*expr_p = NULL;
The empty struct has BLKmode and so is thrown away, while the struct with
unsigned int : 1; has QImode or so and goes through the "vol" handling.
I guess we should figure out what a volatile load or store of empty non-zero
size type means, if it can be optimized away or not, and depending on that
either add && !is_empty_type (TREE_TYPE (*expr_p)) to the "vol" handling
condition, or stop doing the gimplify_modify_expr optimization if lhs or rhs is
volatile (and either isn't a zero size type or always).
[Bug c++/101449] New: [modules] internal compiler error: in cxx_eval_call_expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101449
Bug ID: 101449
Summary: [modules] internal compiler error: in
cxx_eval_call_expression
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
Target Milestone: ---
$ cat str.cpp
export module str;
export struct str {
constexpr str() {
ptr = new char[42];
}
constexpr ~str() { delete[] ptr; }
const char* ptr = nullptr;
};
export constexpr str get_str() { return str{}; }
$ cat main.cpp
import str;
int main() {
str a = get_str();
}
$ g++ -std=c++2b -fmodules-ts str.cpp main.cpp
main.cpp: In function ‘int main()’:
main.cpp:4:21: in ‘constexpr’ expansion of ‘get_str@str()()’
main.cpp:4:21: internal compiler error: in cxx_eval_call_expression, at
cp/constexpr.c:2742
4 | str a = get_str();
| ^
0x652ee9 cxx_eval_call_expression
../../gcc/gcc/cp/constexpr.c:2742
0x9e54f1 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:6250
0x9e8829 cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/constexpr.c:7282
0x9ed921 maybe_constant_value(tree_node*, tree_node*, bool)
../../gcc/gcc/cp/constexpr.c:7556
0xa20665 cp_fully_fold(tree_node*)
../../gcc/gcc/cp/cp-gimplify.c:2146
0xa207f4 cp_fully_fold(tree_node*)
../../gcc/gcc/cp/cp-gimplify.c:2140
0xa207f4 cp_fully_fold_init(tree_node*)
../../gcc/gcc/cp/cp-gimplify.c:2167
0xc16e03 store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/gcc/cp/typeck2.c:816
0xa3a300 check_initializer
../../gcc/gcc/cp/decl.c:7169
0xa5dfd0 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:8103
0xb4a89f cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:22258
0xb2608d cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:14801
0xb27d69 cp_parser_declaration_statement
../../gcc/gcc/cp/parser.c:13936
0xb28743 cp_parser_statement
../../gcc/gcc/cp/parser.c:12066
0xb2904e cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:12433
0xb29128 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:12382
0xb48ff0 cp_parser_function_body
../../gcc/gcc/cp/parser.c:24448
0xb48ff0 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:24499
0xb49aea cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:30572
0xb4ac96 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:30488
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/101448] New: Use GCC 9.3.0 to build Ceph crimson-osd, linker failed for "relocation truncated to fit" against symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101448 Bug ID: 101448 Summary: Use GCC 9.3.0 to build Ceph crimson-osd, linker failed for "relocation truncated to fit" against symbol Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kevin.zhao at linaro dot org Target Milestone: --- Use GCC 9.3.0 binutils 2.34 to build Ceph, I experienced relocation truncated to fit: R_AARCH64_CALL26 This binary after Linking usually around 2G size, I'm not sure if this is related with the failure. Btw, build with Clang 10 works well. This is the regression point: https://github.com/ceph/ceph/commit/80961c27d1adaa969e9ad3647d2fb9944b77904a#diff-195c71729a932038ce1774c2539247ffb0189fb3a7d10162403b06b26f2fdb54R264 After taking into this line, the Linking failed. The corresponding function in seastar is: https://github.com/scylladb/seastar/blob/master/src/core/prometheus.cc#L599 Log: [462/462] Linking CXX executable bin/crimson-osd FAILED: bin/crimson-osd : && /usr/bin/ccache /usr/bin/c++ -g -rdynamic src/crimson/osd/CMakeFiles/crimson-osd.dir/backfill_state.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/ec_backend.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/heartbeat.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/main.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/osd.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/osd_meta.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/pg.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/pg_backend.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/pg_meta.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/replicated_backend.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/shard_services.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/object_context.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/ops_executer.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/osd_operation.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/osd_operations/client_request.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/osd_operations/client_request_common.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/osd_operations/compound_peering_request.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/osd_operations/internal_client_request.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/osd_operations/peering_event.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/osd_operations/pg_advance_map.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/osd_operations/replicated_request.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/osd_operations/background_recovery.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/osd_operations/recovery_subrequest.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/pg_recovery.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/recovery_backend.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/replicated_recovery_backend.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/scheduler/scheduler.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/scheduler/mclock_scheduler.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/osdmap_gate.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/pg_map.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/pg_interval_interrupt_condition.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/objclass.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/__/__/objclass/class_api.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/__/__/osd/ClassHandler.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/__/__/osd/osd_op_util.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/__/__/osd/OSDCap.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/__/__/osd/PeeringState.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/__/__/osd/PGPeeringEvent.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/__/__/osd/PGStateUtils.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/__/__/osd/MissingLoc.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/__/__/osd/PGLog.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/__/__/osd/recovery_types.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/__/__/osd/osd_perf_counters.cc.o src/crimson/osd/CMakeFiles/crimson-osd.dir/watch.cc.o -o bin/crimson-osd -Wl,-rpath,::: lib/libcrimson-admin.a lib/libcrimson-common.a lib/libcrimson-os.a lib/libcrimson.a /usr/lib/aarch64-linux-gnu/libfmt.a lib/libdmclock.a lib/libcrimson-cyanstore.a lib/libcrimson-os.a lib/libcrimson-cyanstore.a lib/libcrimson-alienstore.a lib/libkv.a /usr/lib/aarch64-linux-gnu/libleveldb.so src/rocksdb/librocksdb.a /usr/lib/aarch64-linux-gnu/libsnappy.so /usr/lib/aarch64-linux-gnu/liblz4.so /usr/lib/aarch64-linux-gnu/libz.so lib/libheap_profiler.a lib/libcrimson-alien-common.a /usr/lib/aarch64-linux-gnu/libblkid.so /usr/lib/aarch64-linux-gnu/libudev.so lib/libblk.a /usr/lib/aarch64-linux-gnu/libaio.so ../src/spdk/build/lib/libspdk_lvol.a ../src/spdk/build/lib/libspdk_env_dpdk.a -Wl,--whole-archive
[Bug c/101437] [12 Regression] ICE: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101437
Jakub Jelinek changed:
What|Removed |Added
Priority|P4 |P1
Keywords|error-recovery, |ice-on-valid-code
|ice-on-invalid-code |
--- Comment #2 from Jakub Jelinek ---
It ICEs also on
struct S { int : 1; };
void
foo (volatile struct S *p)
{
struct S s = {};
*p = s;
}
so this isn't just error recovery.
[Bug c/101437] [12 Regression] ICE: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101437 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2021-07-14 Ever confirmed|0 |1 CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Jakub Jelinek --- Started with r12-1150-g34aae6b561871d6d8b10c810f303cb6f18b5fdd0
[Bug tree-optimization/101445] [11/12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101445 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:a967a3efd39280fe3f5774e45490e991f8e99059 commit r12-2294-ga967a3efd39280fe3f5774e45490e991f8e99059 Author: Richard Biener Date: Wed Jul 14 11:06:58 2021 +0200 tree-optimization/101445 - fix negative stride SLP vect with gaps The following fixes the IV adjustment for the gap in a negative stride SLP vectorization. The adjustment was in the wrong direction, now fixes as in the patch. 2021-07-14 Richard Biener PR tree-optimization/101445 * tree-vect-stmts.c (vectorizable_load): Do the gap adjustment of the IV in the correct direction for negative stride accesses. * gcc.dg/vect/pr101445.c: New testcase.
[Bug c/101446] -Wpedantic causes an error with zero size array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101446 --- Comment #7 from İsmail Dönmez --- Well, it's even more confusing, grepping through glibc build log: ../include/stdlib.h:297:8: warning: ISO C forbids zero-size array 'msg' [-Wpedantic] 297 | char msg[0]; |^~~ ../inet/netinet/ip6.h:92:21: warning: ISO C forbids zero-size array 'ip6r0_addr' [-Wpedantic] 92 | struct in6_addr ip6r0_addr[0]; | ^~ So even the zero-size array warning behaves differently.
[Bug c++/101443] [9/10/11/12 Regression] internal compiler error: in wide_int_to_tree_1, at tree.c:1519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101443 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |9.5 Summary|internal compiler error: in |[9/10/11/12 Regression] |wide_int_to_tree_1, at |internal compiler error: in |tree.c:1519 |wide_int_to_tree_1, at ||tree.c:1519 Keywords|needs-bisection | --- Comment #6 from Jakub Jelinek --- On the small testcase started with r0-117521-gec62cbe19bf3a8ff16a33f7b3026f25faf93e25c
[Bug c++/101443] internal compiler error: in wide_int_to_tree_1, at tree.c:1519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101443 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 51148 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51148=edit gcc12-pr101443.patch Untested fix. I think it is best to optimize away these comparisons, as NULLPTR_TYPE has only one possible value, we can always determine the result, ==, <= and >= will be always true and !=, < and > will be always false. And keeping it around in the IL can break various optimizations, e.g. the range stuff (in fold-const and reassoc), or dom, anything that will try to build_int_cst 1 or -1 or something similar when it sees a comparison of something with INTEGER_CST.
[Bug driver/101447] Remove legacy external declarations in toplev.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101447 --- Comment #2 from ashimida --- (In reply to Jonathan Wakely from comment #1) > Yes, they are declared and never defined. > > If you submit a patch to gcc-patches I imagine it will be approved easily. Thanks,I will submit this patch later.
[Bug c/101446] -Wpedantic causes an error with zero size array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101446 --- Comment #6 from İsmail Dönmez --- (In reply to Richard Biener from comment #4) > -Wpedantic was added as fix for PR44774 to make -Werror=pedantic work > (as opposed to -Werror=edantic) The problem is that it's inconsistent, here is a list of other -Wpedantic warnings that do not result in an error: ISO C does not support the '_Float128' type [-Wpedantic] ISO C does not support the '_Float32' type [-Wpedantic] ISO C does not support the '_Float32x' type [-Wpedantic] ISO C does not support the '_Float64' type [-Wpedantic] ISO C does not support the '_Float64x' type [-Wpedantic] ISO C does not support the ‘_Float128’ type [-Wpedantic] ISO C does not support the ‘_Float32x’ type [-Wpedantic] ISO C does not support the ‘_Float32’ type [-Wpedantic] ISO C does not support the ‘_Float64x’ type [-Wpedantic] ISO C does not support the ‘_Float64’ type [-Wpedantic] ISO C forbids 'goto *expr;' [-Wpedantic] ISO C forbids 'return' with expression, in function returning void [-Wpedantic] ISO C forbids an empty translation unit [-Wpedantic] ISO C forbids assignment between function pointer and 'void *' [-Wpedantic] ISO C forbids braced-groups within expressions [-Wpedantic] ISO C forbids conditional expr with only one void side [-Wpedantic] ISO C forbids conversion of function pointer to object pointer type [-Wpedantic] ISO C forbids conversion of object pointer to function pointer type [-Wpedantic] ISO C forbids empty initializer braces [-Wpedantic] ISO C forbids forward references to 'enum' types [-Wpedantic] ISO C forbids initialization between function pointer and 'void *' [-Wpedantic] ISO C forbids label declarations [-Wpedantic] ISO C forbids omitting the middle term of a '?:' expression [-Wpedantic] ISO C forbids passing argument 1 of '_dl_addr' between function pointer and 'void *' [-Wpedantic] ISO C forbids return between function pointer and 'void *' [-Wpedantic] ISO C forbids specifying range of elements to initialize [-Wpedantic]
[Bug c/101446] -Wpedantic causes an error with zero size array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101446
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2021-07-14
Status|RESOLVED|NEW
CC||jsm28 at gcc dot gnu.org
Resolution|INVALID |---
Ever confirmed|0 |1
--- Comment #5 from Richard Biener ---
OK, so the complaint is that
> ./cc1 -quiet t.c -pedantic
t.c:1:47: warning: ISO C forbids empty initializer braces [-Wpedantic]
1 | static const char __gbk_from_ucs4_tab9[][2] = {};
| ^
t.c:1:19: error: zero or negative size array '__gbk_from_ucs4_tab9'
1 | static const char __gbk_from_ucs4_tab9[][2] = {};
| ^~~~
errors and not only -pedantic-errors
> ./cc1 -quiet t.c -pedantic-errors
t.c:1:47: error: ISO C forbids empty initializer braces [-Wpedantic]
1 | static const char __gbk_from_ucs4_tab9[][2] = {};
| ^
t.c:1:19: error: zero or negative size array '__gbk_from_ucs4_tab9'
1 | static const char __gbk_from_ucs4_tab9[][2] = {};
| ^~~~
-Wpedantic is just an alias for -pedantic - but see the documentation which
explicitely says some constructs are rejected (not only warned on).
-pedantic-errors says
@item -pedantic-errors
@opindex pedantic-errors
Give an error whenever the @dfn{base standard} (see @option{-Wpedantic})
requires a diagnostic, in some cases where there is undefined behavior
at compile-time and in some other cases that do not prevent compilation
of programs that are valid according to the standard. This is not
equivalent to @option{-Werror=pedantic}, since there are errors enabled
by this option and not enabled by the latter and vice versa.
so I still think it works as designed even if the new -Wpedantic alias
suggests that -pedantic is a pure warning option.
[Bug c++/101442] [9/10/11/12 Regression] Destructor not called for a temporary object, if it's bound to a ref member of an object subject to NRVO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101442
--- Comment #5 from Jonathan Wakely ---
Reduced:
bool destroyed = false;
struct A
{
A() {}
A(const A &) = delete;
A =(const A &) = delete;
~A() {destroyed = true;}
};
struct B
{
const A
struct string {
string(const char*) { }
~string() { }
} s;
};
B foo()
{
B ret{ A{}, "" };
return ret;
}
int main()
{
{
B b = foo();
}
if (!destroyed)
__builtin_abort();
}
[Bug c++/101442] [9/10/11/12 Regression] Destructor not called for a temporary object, if it's bound to a ref member of an object subject to NRVO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101442 Jonathan Wakely changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #4 from Jonathan Wakely --- The regression happened after r180941 and not after r180959. Almost certainly this one, as it's the only C++ change in the range: commit b25dd954c41bf75d2bc892c7e9114908eaa7d314 Author: Jason Merrill Date: Fri Nov 4 12:54:08 2011 re PR c++/48370 (G++ fails to extend reference temporary lifetime in some situations) PR c++/48370 * call.c (extend_ref_init_temps, extend_ref_init_temps_1): New. (set_up_extended_ref_temp): Use it. Change cleanup parm to VEC. (initialize_reference): Just call convert_like. * decl.c (grok_reference_init): Just call initialize_reference. (build_init_list_var_init): Remove. (check_initializer): Change cleanup parm to VEC. Handle references like other types. Call perform_implicit_conversion instead of build_init_list_var_init. Don't use build_aggr_init for aggregate initialization of arrays. (cp_finish_decl): Change cleanup to VEC. * typeck2.c (store_init_value): Call extend_ref_init_temps. Use build_vec_init for non-constant arrays. * init.c (expand_aggr_init_1): Adjust. (build_vec_init): Avoid re-converting an initializer that's already digested. * mangle.c (mangle_ref_init_variable): Add a discriminator. * cp-tree.h: Adjust. * typeck.c (convert_for_initialization): Adjust. * decl2.c (maybe_emit_vtables): Adjust. From-SVN: r180944
[Bug c/101446] -Wpedantic causes an error with zero size array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101446 --- Comment #4 from Richard Biener --- -Wpedantic was added as fix for PR44774 to make -Werror=pedantic work (as opposed to -Werror=edantic)
[Bug c/101446] -Wpedantic causes an error with zero size array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101446
--- Comment #3 from İsmail Dönmez ---
(In reply to Richard Biener from comment #2)
> -Wpedantic is the same as -pedantic and that affects correctness of programs.
>
> @item -Wpedantic
> @itemx -pedantic
> @opindex pedantic
> @opindex Wpedantic
> @opindex Wno-pedantic
> Issue all the warnings demanded by strict ISO C and ISO C++;
> reject all programs that use forbidden extensions, and some other
> programs that do not follow ISO C and ISO C++. For ISO C, follows the
> version of the ISO C standard specified by any @option{-std} option used.
>
> Valid ISO C and ISO C++ programs should compile properly with or without
> this option (though a rare few require @option{-ansi} or a
> @option{-std} option specifying the required version of ISO C)@. However,
> without this option, certain GNU extensions and traditional C and C++
> features are supported as well. With this option, they are rejected.
Well, not quite so. I enabled -Wpedantic with glibc and have hundreds of
warnings and only the zero-size array one errors out. There is clearly an
inconsistency here.
[Bug c/101446] -Wpedantic causes an error with zero size array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101446
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Richard Biener ---
-Wpedantic is the same as -pedantic and that affects correctness of programs.
@item -Wpedantic
@itemx -pedantic
@opindex pedantic
@opindex Wpedantic
@opindex Wno-pedantic
Issue all the warnings demanded by strict ISO C and ISO C++;
reject all programs that use forbidden extensions, and some other
programs that do not follow ISO C and ISO C++. For ISO C, follows the
version of the ISO C standard specified by any @option{-std} option used.
Valid ISO C and ISO C++ programs should compile properly with or without
this option (though a rare few require @option{-ansi} or a
@option{-std} option specifying the required version of ISO C)@. However,
without this option, certain GNU extensions and traditional C and C++
features are supported as well. With this option, they are rejected.
[Bug c++/101442] [9/10/11/12 Regression] Destructor not called for a temporary object, if it's bound to a ref member of an object subject to NRVO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101442 Jonathan Wakely changed: What|Removed |Added Known to work||4.6.4 Known to fail||4.7.4 Summary|Destructor not called for a |[9/10/11/12 Regression] |temporary object, if it's |Destructor not called for a |bound to a ref member of an |temporary object, if it's |object subject to NRVO |bound to a ref member of an ||object subject to NRVO --- Comment #3 from Jonathan Wakely --- Works correctly in GCC 4.6.4 too. I'll bisect.
[Bug driver/101447] Remove legacy external declarations in toplev.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101447 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-07-14 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- Yes, they are declared and never defined. If you submit a patch to gcc-patches I imagine it will be approved easily.
[Bug c/101446] -Wpedantic causes an error with zero size array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101446 --- Comment #1 from Jonathan Wakely --- It's been that way since GCC 4.1 at least.
[Bug driver/101447] New: Remove legacy external declarations in toplev.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101447 Bug ID: 101447 Summary: Remove legacy external declarations in toplev.h Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: ashimida at linux dot alibaba.com Target Milestone: --- External declarations in ./gcc/toplev.h is no longer used in newest version of gcc and should be cleaned up to avoid misunderstandings : +extern unsigned int min_align_loops_log; +extern unsigned int min_align_jumps_log; +extern unsigned int min_align_labels_log; +extern unsigned int min_align_functions_log; The history FYI: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e6de53356769e13178975c18b4ce019a800ea946;hp=118f2d8bc3e6804996ca2953b86454ec950054bf
[Bug c++/101443] internal compiler error: in wide_int_to_tree_1, at tree.c:1519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101443
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
Reduced testcase for -O2:
template struct e { a c; };
template struct f { void operator()(d g, d h) { g < h; } };
template struct n;
template using j = typename n::k;
template class ah {};
template
struct n> : n> {};
template struct n<0, ah> { typedef ag k;
};
template j> aj(ah);
template struct o { static bool am(int g, m h) { 0 <
aj(h) || o::am(g, h); return false; } };
template void operator<(ah, ah)
{
using ar = o, 0>;
ar::am;
}
template ah as(ai...);
template struct F { d operator*(); };
template struct p { typedef F ay; };
template > struct q {
void operator[](az g) { typename p>::ay i; bh()(g, (*i).c); }
ba bh();
};
struct r {
template static int aj(bj... g) {
auto a = as(g...);
using bc = decltype(a);
q b;
b[a];
return 0;
}
template static int bn(bj... g) { aj(g...); return 0; }
};
int main() { r::bn(0, nullptr); }
Even simpler testcase:
decltype(nullptr) foo ();
bool bar () { return 0 < foo () || foo () < 0; }
[Bug tree-optimization/101445] [11/12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101445
--- Comment #4 from Richard Biener ---
Simplified testcase, fails at -O2 -ftree-loop-vectorize
int a[35] = {1, 1, 3};
void __attribute__((noipa))
foo ()
{
for (int b = 4; b >= 0; b--)
{
int tem = a[b * 5 + 3 + 1];
a[b * 5 + 3] = tem;
a[b * 5 + 2] = tem;
a[b * 5 + 1] = tem;
a[b * 5 + 0] = tem;
}
}
int main()
{
foo ();
for (int d = 0; d < 25; d++)
if (a[d] != 0)
__builtin_abort ();
return 0;
}
the load is vectorized in an odd way, but "correct" - but the final IV
update(s)
are bogus.
vectp_a.7_34 = + 84; // [21]
# vectp_a.6_35 = PHI
...
vect_tem_9.8_37 = MEM [(int *)vectp_a.6_35];
vect_tem_9.9_38 = VEC_PERM_EXPR ;
vectp_a.6_39 = vectp_a.6_35 + 18446744073709551600; // -16
vect_tem_9.10_40 = MEM [(int *)vectp_a.6_39];
vect_tem_9.11_41 = VEC_PERM_EXPR ;
vectp_a.6_42 = vectp_a.6_39 + 18446744073709551604; // -12
vect_tem_9.12_43 = VEC_PERM_EXPR ;
...
vectp_a.6_36 = vectp_a.6_42 + 18446744073709551600; // -16
we're doing VMAT_CONTIGUOUS_REVERSE but the group has gaps and we fail to
account for the reverse when computing group_gap_adj (which should have been
+12, not -12).
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #232 from John Buddery --- The #undef MAKE_DECL_ONE_ONLY is only for older builds, it's not needed with the gcc 11 patches. It was an alternative single line fix which works for 4.7.2 and 4.9.4, which you need to build if you're starting from scratch. This was never really the right fix, and as support for systems without MAKE_DECL_ONE_ONLY has deteriorated in later versions it became harder and harder to follow this route. I did get some intermediate versions working with a lot of hacking, but for any vaguely recent release I would recommend using the 11.1 patches instead.
[Bug c/101446] New: -Wpedantic causes an error with zero size array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101446
Bug ID: 101446
Summary: -Wpedantic causes an error with zero size array
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ismail at i10z dot com
Target Milestone: ---
The test-case minimized but originally from glibc:
; cat gbk.c
static const char __gbk_from_ucs4_tab9[][2] =
{
};
; gcc -c gbk.c
; gcc -c -Wpedantic gbk.c
gbk.c:2:1: warning: ISO C forbids empty initializer braces [-Wpedantic]
2 | {
| ^
gbk.c:1:19: error: zero or negative size array ‘__gbk_from_ucs4_tab9’
1 | static const char __gbk_from_ucs4_tab9[][2] =
| ^~~~
; gcc -v
(base)
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d,jit
--enable-offload-targets=nvptx-none,amdgcn-amdhsa, --without-cuda-driver
--enable-host-shared --enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/11 --enable-ssp --disable-libssp
--disable-libvtv --enable-cet=auto --disable-libcc1 --enable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-11 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic
--with-build-config=bootstrap-lto-lean --enable-link-mutex
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.1 20210625 [revision 62bbb113ae68a7e724255e17143520735bcb9ec9]
(SUSE Linux)
I believe no warning flag should result in an error.
[Bug go/101407] non-determinism in -fdump-go-spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101407 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3be762c2ed79e36b9c8faaea2be04725c967a34e commit r12-2293-g3be762c2ed79e36b9c8faaea2be04725c967a34e Author: Jakub Jelinek Date: Wed Jul 14 10:22:50 2021 +0200 godump: Fix -fdump-go-spec= reproduceability issue [PR101407] pot_dummy_types is a hash_set from whose traversal the code prints some type lines. hash_set normally uses default_hash_traits which for pointer types (the hash set hashes const char *) uses pointer_hash which hashes the addresses of the pointers except of the least significant 3 bits. With address space randomization, that results in non-determinism in the -fdump-go-specs= generated file, each invocation can have different order of the lines emitted from pot_dummy_types traversal. This patch fixes it by hashing the string contents instead to make the hashes reproduceable. 2021-07-14 Jakub Jelinek PR go/101407 * godump.c (godump_str_hash): New type. (godump_container::pot_dummy_types): Use string_hash instead of ptr_hash in the hash_set.
[Bug target/101384] [9/10/11/12 Regression] wrong code at -Og and above with vector shift/multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101384
--- Comment #7 from Jakub Jelinek ---
E.g. p8, on gcc112.fsffrance.org, vanilla gcc configured with
../configure --enable-languages=all,obj-c++,lto,go,d
--enable-checking=yes,rtl,extra
with the https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575118.html
testsuite/gcc.dg/pr101384.c testcase:
./xgcc -B ./ -O2 -o pr101384{,.c}; ./pr101384; echo $?
Aborted
134
or
./xgcc -B ./ -O2 -mcpu=power8 -o pr101384{,.c}; ./pr101384; echo $?
Aborted
134
It works fine with the 4.8 system gcc:
gcc -o pr101384{,.c} -std=c99 -Dnoipa='noinline,noclone' -O2; ./pr101384; echo
$?
0
And with the patched compiler:
./xgcc -B ./ -O2 -o pr101384{,.c}; ./pr101384; echo $?
0
The broken compilers will not load the { 0x80, 0xff, 0xff, 0xff, 0x80, 0xff,
0xff, 0xff, 0x80, 0xff, 0xff, 0xff, 0x80, 0xff, 0xff, 0xff } vector (and the
other one too) from .rodata, but computes it using vspltisw reg,-1; vslb
reg,reg,reg but that constructs { 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80,
0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80 } vector instead.
[Bug tree-optimization/101445] [11/12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101445 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Last reconfirmed||2021-07-14 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- I will have a look.
[Bug testsuite/101444] [12 regression] cc.target/powerpc/pr86731-fwrapv-longlong.c fails after r12-2266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101444 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0
[Bug c++/101442] Destructor not called for a temporary object, if it's bound to a ref member of an object subject to NRVO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101442 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-07-14 Version|unknown |11.1.1 Ever confirmed|0 |1 Keywords||wrong-code Known to fail||10.3.1, 11.1.1, 12.0, 7.5.0 Status|UNCONFIRMED |NEW --- Comment #2 from Richard Biener --- Confirmed. Works with clang.
[Bug inline-asm/101438] Compiler hang on inline asm with local register and VLA operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101438
Richard Biener changed:
What|Removed |Added
Keywords||accepts-invalid,
||compile-time-hog, ra
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-07-14
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
At -O0 we get
t3.c: In function 'main':
t3.c:21:5: error: 'asm' operand has impossible constraints
21 | __asm__ (""
| ^~~
likely because there's not enough registers to pass in 'arr' (and we need a FP
to allocate arr). At -O1 it looks like we think we can manage but do not make
progress reloading.
So confirmed, a diagnostic would be nice.
[Bug c/101437] [12 Regression] ICE: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101437 Richard Biener changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code Priority|P3 |P4 Target Milestone|--- |12.0
